Large-Scale Measurement of NAT Traversal for the Decentralized Web: A Case Study of DCUtR in IPFS Dennis Trautwein
University of Göttingen Germany [email protected]
Cornelius Ihle
University of Göttingen Germany [email protected]
arXiv:2604.12484v1 [cs.NI] 14 Apr 2026
Corinna Breitinger
Bela Gipp
University of Göttingen Germany [email protected]
Abstract The promise of decentralized peer-to-peer (P2P) systems is fundamentally gated by the challenge of Network Address Translation (NAT) traversal, with existing solutions often reintroducing the very centralization they seek to avoid. This paper presents the first largescale measurement study of a fully decentralized NAT traversal protocol, Direct Connection Upgrade through Relay (DCUtR), within the production libp2p-based InterPlanetary File System (IPFS) network. Drawing on over 4.4 million traversal attempts from 85,000+ distinct networks across 167 countries, we provide an empirical analysis of modern P2P connectivity. We establish a conditional success rate of 70% ± 7.1% for the hole-punching stage, given that prerequisite relay reservation and public address discovery succeed, providing a crucial new benchmark for the field. Critically, we empirically challenge the long-held belief of UDP’s superiority for NAT traversal, demonstrating that DCUtR’s high-precision, RTT-based synchronization yields statistically indistinguishable success rates for both TCP and QUIC (∼ 70%). Our analysis further validates the protocol’s design for permissionless environments by showing that success is independent of relay characteristics and that the mechanism is highly efficient, with 97.6% of successful connections established on the first attempt. Building on this analysis, we propose a concrete roadmap of protocol enhancements aimed at achieving universal connectivity and contribute our complete dataset to foster further research in this domain.
CCS Concepts • Networks → Protocol testing and verification; Network protocol design; Network measurement; Network experimentation; Network performance analysis.
Keywords p2p, libp2p, NAT traversal, hole punching, STUN, TURN, ICE
This work is licensed under a Creative Commons Attribution 4.0 International License. IMC ’26, Karlsruhe, Germany © 2026 Copyright held by the owner/author(s). ACM ISBN 979-8-4007-2327-8/2026/10 https://doi.org/10.1145/3777912.3809138
Moritz Schubotz
FIZ Karlsruhe – Leibniz Institute for Information Infrastructure Germany [email protected]
University of Göttingen Germany [email protected] ACM Reference Format: Dennis Trautwein, Cornelius Ihle, Moritz Schubotz, Corinna Breitinger, and Bela Gipp. 2026. Large-Scale Measurement of NAT Traversal for the Decentralized Web: A Case Study of DCUtR in IPFS. In Proceedings of the 2026 ACM Internet Measurement Conference (IMC ’26), October 12–16, 2026, Karlsruhe, Germany. ACM, New York, NY, USA, 17 pages. https://doi.org/10. 1145/3777912.3809138
1
Introduction
Services like Facebook, TikTok, YouTube, Netflix, and Amazon have been criticized due to the potential risks of serving as single points of technical or organizational failures, becoming data monopolies, or acting as gatekeepers [4, 8]. The resulting compromised privacy and loss of self-sovereign control over one’s data poses significant risks. The vast amounts of personal information collected by these services have put them in a position of unprecedented power to influence users’ lives and societies. Unlike other institutions that are legitimized by democratic principles, these influential services lack the same legitimization [24]. A growing movement, colloquially referred to as the “Decentralized Web” [33] is challenging the power hierarchy of the current Web by eliminating intermediaries in web transactions using peerto-peer (P2P) architectures. P2P replaces the current client-server paradigm and introduces the challenge of opening connections unilaterally and across restrictive Network Address Translators (NATs). NAT technology was initially developed to address IPv4 address space depletion and is widely used by Internet Service Providers (ISPs) and corporate networks to enable devices to share a single public IP address. This usually results in unobstructed access from within a local area network (LAN) to the Internet, but hinders incoming connections. NAT traversal techniques, such as NAT “hole punching”, have been developed to overcome the challenge of ubiquitous P2P connectivity [12]. In its simplest form, NAT hole punching allows two peers behind NATs to establish a direct connection by simultaneously opening a connection to the public IP/Port combinations of each other. Traditional hole punching techniques like the ones used by WebRTC [1], rely on a centralized signaling server to facilitate the synchronization. This provides an opportunity to decentralize
IMC ’26, October 12–16, 2026, Karlsruhe, Germany
infrastructure and bolster a network’s resilience against targeted attacks and censorship efforts. Decentralization alleviates the burden of operating and maintaining such infrastructure. As a result, the Direct Connection Upgrade through Relay protocol (DCUtR) [31] was designed. DCUtR draws inspiration from related protocols, including STUN, TURN, and ICE [20, 26, 27] but achieved independence from centralized infrastructure. In this paper, we specifically focus on the decentralized InterPlanetary File System (IPFS) [3, 32] network with its around 7k online peers1 . IPFS is built upon the libp2p peer-to-peer networking stack, which includes the DCUtR protocol. At any given time, there are typically around 100k [16] compatible libp2p nodes online beyond IPFS. We evaluate DCUtR’s real-world performance using five central hypotheses (see Section 3.4). First, we establish its baseline efficacy (H1) and verify that its behavior is independent of relay characteristics (H2). Next, we examine both the efficiency and the transport-agnostic nature of its synchronization mechanism (H3a, H3b). Finally, we assess the practical impact of its built-in optimizations (H4). In a large-scale measurement campaign, we provide empirical evidence to validate or challenge these core hypotheses. Our contributions are as follows: (1) We present the first largescale measurement study on a decentralized NAT traversal protocol in a production P2P network, (2) we empirically challenge long-the standing belief that UDP-based protocols are inherently superior for NAT traversal, (3) we validate DCUtR’s core design; and (4) we provide a unique, large-scale and open access dataset for the research community.
2
The Challenge of NAT for Peer-to-Peer Connectivity
Network Address Translation (NAT) is a prevalent technique used in network gateways to modify IP address information; primarily, to mitigate IPv4 address exhaustion [9]. The most common variant, Network Address Port Translation (NAPT), also known as Port Address Translation (PAT), allows multiple devices within a private network to share a single public IP address [15]. The NAPT device maintains a dynamic translation table, mapping an internal source ‘(IP:port)‘ tuple to a public-facing ‘(IP:port)‘ tuple for each outbound connection. This mapping and filtering mechanism allows outgoing connections but blocks unsolicited inbound traffic, which obstructs peer-to-peer (P2P) networking. A gateway only forwards an incoming packet if it matches a recent outgoing connection; otherwise, the packet is dropped. Hence, this mechanism requires specialized NAT traversal techniques to establish direct P2P links.
2.1
Taxonomy of NAT Behavior
The viability of any NAT traversal technique depends fundamentally on the NAT’s mapping and filtering behavior [10], as standardized in RFC 4787 [17]. Rather than examining these properties in isolation, it is more useful to consider how they combine to form distinct NAT archetypes, each with direct implications for P2P connectivity. The most P2P-friendly NATs are known as Cone NATs. Their defining feature is Endpoint-Independent Mapping (EIM), where 1 https://probelab.io/ipfs/kpi/
Trautwein et al.
the NAT assigns a stable public endpoint ‘(IP:port)‘ to an internal endpoint, reusing this mapping for all subsequent outbound connections, regardless of the destination. This predictability is essential for hole punching, as a peer can learn its public endpoint once and reliably share it with others. Cone NATs differ primarily in their filtering policies. Full Cone NATs (Endpoint-Independent Filtering) are the most permissive, accepting inbound traffic from any external source once a mapping exists. Restricted Cone NATs (Address-Dependent or Address and Port-Dependent Filtering) enforce stricter rules, allowing inbound packets only from external endpoint ‘(IP:port)‘ to which the internal peer has recently transmitted traffic. At the opposite end of the spectrum are Symmetric NATs, which pose the greatest challenge for P2P connectivity. A symmetric NAT uses Address and Port-Dependent Mapping (APDM), generating a unique public mapping for each distinct destination endpoint. As a result, the public address that a peer observes when contacting a discovery server differs from the one created when attempting to contact another peer. This unpredictability makes traditional hole punching ineffective, as the advertised public endpoint is no longer valid for new connections. This behavior, combined with restrictive filtering, often leaves relay-based solutions the only practical means of establishing peer-to-peer connectivity.
2.2
NAT Traversal Techniques
The de facto standard for handling the complexities of NAT is the Interactive Connectivity Establishment (ICE) framework [1, 29], which coordinates several techniques to find the most efficient communication path between peers. ICE systematically attempts connectivity using the following steps: Address Discovery with STUN: Peers first query a centralized Session Traversal Utilities for NAT (STUN) server [26]. The STUN server reflects the peer’s public IP address and port as observed from the public internet (its "server reflexive" address) and helps classify the behavior of the NAT. Direct Connection via Hole Punching: Equipped with their respective public addresses, peers exchange this information through a signaling channel (typically, a centralized service) and attempt to establish a direct connection using hole punching [11]. This technique involves sending simultaneous connection-request packets to each other, taking advantage of the temporary NAT mappings created by their own outbound traffic. Relay Fallback with TURN: If direct connection attempts fail, most commonly because one or both peers are behind a Symmetric NAT, ICE falls back to relaying traffic through a Traversal Using Relays around NAT (TURN) server [27]. Although TURN guarantees connectivity, it increases latency and requires the TURN server to handle the full bandwidth of the session. The staged NAT traversal approach of ICE aims to overcome the barriers that NATs impose on peer-to-peer communication, by offering a range of solutions from “best-effort” (hole punching) to guaranteed connectivity (TURN relaying). Other mechanisms, such as UPnP [5] for automatic port forwarding or Application-Level Gateways (ALGs) [15], exist but are not universally reliable or often disabled due to security concerns2 . 2 https://www.cisa.gov/news-events/news/home-network-security
NAT Traversal Measurement Campaign
IMC ’26, October 12–16, 2026, Karlsruhe, Germany
Therefore, the robustness of the modern P2P ecosystem, particularly in applications like WebRTC, relies on the availability of centralized STUN, TURN, and signaling infrastructure. This dependency introduces operational costs and single points of failure, which oppose the principles of fully decentralized systems. This limitation motivated the development and analysis of protocols such as DCUtR.
3
3.1
libp2p
Identify, AutoNAT, and Circuit v2 protocols allow peers to discover their external network addresses and reachability. Further, the protocols establish preliminary connections without sole reliance on centralized STUN and TURN servers. 3.1.1 Identify. The Identify protocol provides functionality similar to STUN, is lightweight, and all libp2p peers support it by default. Upon establishing a connection, whether direct or relayed, peers exchange messages that allow each side to learn its own externally observed public IP address(es) and port as seen by the remote peer. Identify leverages existing connections, thus avoiding the need for separate centralized STUN infrastructure, and can potentially offer more reliable address information, since it uses the same transport protocols that will be used for the subsequent direct connection. 3.1.2 AutoNAT. Complementing this, the AutoNAT protocol determines a peer’s actual reachability at its observed addresses. A peer requests that other peers attempt to dial back to the address it advertises. A successful dial-back classifies the peer as public, whereas failure indicates a private peer that likely cannot receive unsolicited inbound connections. On top of AutoNAT, a libp2p host also attempts to establish port mappings using Universal Plug and Play (UPnP) and/or the Port-Mapping Protocol (PMP). However, this mechanism is only advisory, since: (i) routers may not reliably report the mapping’s status, and (ii) mappings may silently expire at any time. AutoNAT provides the authoritative signal by informing the libp2p host which of its addresses are actually dialable from the outside. 3 https://libp2p.io
4 https://docs.libp2p.io/concepts/fundamentals/protocols/#identify 5 https://docs.libp2p.io/concepts/nat/autonat/
6 https://docs.libp2p.io/concepts/nat/circuit-relay/
3 SYNC 0 CONNECTION REVERSAL NAT
Listener
The libp2p DCUtR Protocol
The Direct Connection Upgrade Through Relay (DCUtR) protocol is based on libp2p3 , a modular peer-to-peer networking stack in which DCUtR is implemented. libp2p is used by major peerto-peer networks, such as Ethereum [6] and IPFS [3, 32], since it provides foundational tools for peer discovery, connection establishment, stream multiplexing, and secure communication. Within libp2p, several precursor protocols play a crucial role in gathering the necessary information and establishing initial connectivity for hole punching. These are notably the Identify4 , AutoNAT5 , and the Circuit v26 relay protocol. To understand our following measurement methodology and evaluation, we give a brief overview of these precursor protocols as well as the DCUtR protocol operations. We point the reader to [31] for a more comprehensive description of the DCUtR protocol.
1 CONNECT
RELAY
2 CONNECT
NAT 4 ATTEMPT
Initiator
Figure 1: DCUtR protocol flow diagram
3.1.3 Circuit v2. For private peers, the Circuit v2 protocol provides lightweight relaying services, primarily for signaling and coordination tasks such as those required by DCUtR. Crucially, Circuit v2 is designed to minimize resource usage, imposing negligible processing and bandwidth costs on relays; unlike traditional TURN relays, which forwards all application traffic. Circuit v2 achieves this efficiency by requiring private peers to obtain reservations from relays, with strict limits on the number, duration, and data volume of relayed connections. This design enables most public libp2p peers to serve as relays without incurring significant resource burden. The establishment of this initial relayed connection via Circuit v2 is the precursor from which DCUtR attempts to upgrade to a direct connection.
3.2
The DCUtR Protocol
The DCUtR protocol attempts to upgrade an existing relayed libp2p connection to a direct one. The process involves an initiator, the peer that accepted the relayed connection, and a listener, which waits for the initiator to begin the DCUtR exchange. Figure 1 depicts the protocol exchange which proceeds as follows. The setup begins with the initiator holding a valid reservation at any relay in the network. The listener can then use that relay to establish a “limited” relayed connection to start the exchange of Identify and DCUtR messages. Before attempting hole punching, the initiator may attempt a “Connection Reversal”: if the listener appears public based on the Identify data obtained over the relayed connection, the initiator directly dials the listener’s advertised addresses 0 . If this succeeds, a direct connection is formed without performing any hole punching. If Connection Reversal fails, or if the listener is private, DCUtR proceeds with the full hole punching workflow: Address Exchange: The initiator sends a CONNECT message 1 containing its candidate public addresses (from Identify) to the listener via the relay. The listener responds with its own CONNECT message 2 containing its addresses. The initiator also uses this exchange to measure the relayed path round-trip time (RTT). Synchronization: The initiator then sends a SYNC message 3 to the listener over the relay and waits half the measured RTT before initiating dialing. Dialing: Upon receiving SYNC, the listener immediately attempts to establish a direct connection to the initiator’s advertised addresses. After waiting half an RTT, the initiator also dials the listener’s addresses 4 . This timing aims for near-simultaneous packet arrival at both NATs, increasing the likelihood of creating compatible NAT mappings.
IMC ’26, October 12–16, 2026, Karlsruhe, Germany
Transport-specific mechanisms, such as TCP Simultaneous Open or QUIC’s approach of using dummy UDP packets to establish NAT state, are leveraged. If the first synchronized attempt fails, the synchronization and synchronized dialing steps are retried twice. Once a direct connection is successfully established, the relayed connection is closed. The DCUtR coordination phase is intentionally lightweight, typically requiring only two network round trips and exchanging fewer than 500 bytes per direction over the relay. A detailed sequence diagram appears in Appendix A.1. A comprehensive description is provided by Seemann et al. [31]. DCUtR is shipped as a default component in the main libp2p implementations (go-libp2p, rust-libp2p, and js-libp2p) and is therefore active in all applications built on these stacks, including IPFS and Ethereum nodes.
3.3
Walk the DHT Some DCUtR Capable Peer
Inbound connection by chance
honeypot
Initiate Hole Punch Perform Hole Punch
Relay v2
Save all inbound connections Query DB
server Insert
Request Peer to Hole Punch
clients
Connect to Peer via Relay
Report Hole Punch Outcome
Figure 2: Measurement infrastructure architecture. The central components honeypot, server, and clients allow us to detect, serve and hole punch DCUtR-capable remote peers.
ICE/STUN/TURN Architectural Comparison
DCUtR departs from the ICE framework (Section 2) which depends on dedicated STUN and TURN servers. DCUtR on the other hand leverages the libp2p’s Identify protocol and ephemeral Circuit v2 relays. Unlike the high-bandwidth fallback provided by TURN, DCUtR’s relays are limited to signaling, meaning the system trades guaranteed connectivity for reduced infrastructure overhead. DCUtR also streamlines the handshake process using RTT-based synchronized dialing rather than systematic candidate checks and extends native support to both TCP and QUIC. This architectural pivot toward permissionless P2P networking informs the empirical analysis that follows.
3.4
Trautwein et al.
Protocol Hypotheses
We formulate a set of testable hypotheses to examine DCUtR’s realworld performance and behavior. Each hypothesis reflects either a core design goal of the protocol or a known challenge in NAT traversal. The measurement campaign described in Section 4 provides the empirical data needed to validate or refute these claims. Viability and Efficacy. The most fundamental requirement for any new protocol is basic efficacy. The public internet is a challenging environment for peer-to-peer communication, with a significant fraction of NAT devices (e.g., Symmetric NATs) intentionally designed to be exceptionally difficult to traverse [7]. Hole punching is a best effort technique with no guaranteed success. To consider DCUtR a viable connection strategy, we set a conservative but essential viability benchmark above 50% and require that it must succeed more often than it fails. H1: We hypothesize that DCUtR achieves a success rate greater than 50% for the hole punching stage, demonstrating its fundamental viability as a robust and effective decentralized NAT traversal solution in a heterogeneous real-world environment. Evaluated in Section 5.2.1. Relay Independence. A defining property of the protocol is its decentralized architecture, which allows any public peer to serve as a signaling relay. This design is robust only if success does not depend on a small subset of privileged, high-performance, or strategically located relays. H2: We hypothesize that the success of a DCUtR hole punch is largely independent of the network characteristics of the relay used. This would validate the architectural choice of allowing any
public peer to act as a relay in a permissionless network. Evaluated in Section 5.2.2. Effective Synchronization. DCUtR relies on an RTT-based synchronization mechanism to coordinate the hole punch. If effective, this synchronization mechanism should yield two outcomes: (i) high efficiency: most successes occurring on the first attempt; and (ii) transport-agnostic behavior: mitigating the timing challenges that historically made TCP hole punching significantly harder than UDP-based methods. These considerations lead to two related hypotheses, evaluated in Section 5.2.3: H3a: We hypothesize that the DCUtR synchronization mechanism is highly efficient, with successful traversals predominantly occurring in the initial attempt. H3b: We hypothesize that DCUtR’s performance is not fundamentally tied to the underlying transport protocol, achieving comparable success rates for both TCP and QUIC and challenging the conventional assumption of UDP’s inherent superiority. Optimization Effectiveness. The protocol includes “Connection Reversal” as a fast-path optimization to bypass the full hole-punching procedure when a peer already has a valid port mapping (e.g., via UPnP). An empirical evaluation must confirm whether this optimizations provides meaningful benefit in practice. H4: We hypothesize that the Connection Reversal mechanism is an effective optimization that can substantially increase the likelihood of establishing direct connections for peers with favorable NAT configurations and avoiding the overhead of the full holepunching exchange. Evaluated in Section 5.2.4.
4
Measurement Methodology & Campaign
The objective of our measurements is to assess the performance of the DCUtR protocol, with a specific focus on validating or refuting the hypotheses in Section 3.4 and to gather insights into areas for protocol improvement. To achieve these objectives, we conducted a measurement campaign designed to comprehensively assess the performance of the DCUtR protocol. This section covers the measurement architecture, details on our measurement campaign, and the dataset of our research.
NAT Traversal Measurement Campaign
4.1
Methodology
A central challenge in evaluating the performance of the DCUtR protocol is discovering peers that actually support DCUtR. For a meaningful assessment of NAT traversal capabilities, target peers must be located behind NATs, which makes them unreachable from the public internet. This characteristic complicates their discovery in decentralized, permissionless peer-to-peer networks as they typically, and specifically in the case of the IPFS network, lack a central registry of participants or of the protocols they support. Standard peer discovery mechanisms, such as querying public Distributed Hash Tables (DHTs) [32], are insufficient for this task. By default, only publicly reachable peers announce themselves to the DHT. NATed peers, precisely those required for our measurement campaign, do not. To overcome this limitation, we introduce a honeypot. 4.1.1 Honeypot. The honeypot is a DHT server peer designed to be highly stable and to announce itself to the network by slowly crawling it [32]. This behavior increases the likelihood that other peers insert the honeypot into their routing tables. As a result, server peers increasingly redirect client traffic to the honeypot, thereby raising the number of inbound connections it receives. The honeypot tracks all inbound connections from peers that satisfy both of the following conditions: (i) the peer supports the DCUtR protocol (ii) the peer is reachable only through relay addresses, indicating it is behind a NAT. “Tracking all inbound connections” means that these connections are stored in the shared database, which is subsequently queried and served by the server component. 4.1.2 Server. The server component exposes a Google Remote Procedure Call (gRPC) API that allows clients to query for NATed and DCUtR-capable peers previously discovered by the honeypot. It is also responsible for tracking the results of hole-punching attempts and provides a centralized interface through which clients retrieve information about potential peers to hole punch. A key element of our methodology is the “protocol filter”, a mechanism that enables us to isolate and evaluate the performance of specific transport protocols (TCP and QUIC) independently. When a client queries the server for a peer to hole punch, the server randomly assigns a “protocol filter”, which the client should apply to the hole punch. For example, under a “TCP” protocol filter, the client will (i) announce only its public TCP listening address to the remote peer over the relay and (ii) attempt the hole punch using only the remote peer’s public TCP Multiaddress. This ensures that both endpoints rely exclusively on the designated transport protocol, despite potentially listening on additional ones. 4.1.3 Clients. Clients periodically query the server for peers to probe. Using the returned information, they perform hole-punching attempts and report their results back to the server. Clients connect to each peer via its advertised relay address, thereby acting as the previously introduced listener. They then wait for the remote peer, initiator, to initiate the hole punch protocol. This component generates the empirical data for the measurement campaign, enabling the server to collect and aggregate results. The client is written in Go and is available in two forms: a command-line interface (CLI) and a graphical user interface (GUI). The GUI version was developed to
IMC ’26, October 12–16, 2026, Karlsruhe, Germany
simplify onboarding of participants in the measurement study. The source code is openly available at https://github.com/libp2p/punchr. 4.1.4 Interplay. Figure 2 illustrates the interaction between the components. The honeypot continuously crawls or “walks” the DHT to increase the likelihood that NATed, DCUtR-capable peers connect to it. These inbound connections are stored in a database, which is then queried and served to clients. Clients use the provided relay address(es) to connect to the remote peer and initiate the DCUtR hole-punching process. After either (i) successfully establishing direct connection, (ii) three consecutive DCUtR failures, or (iii) a timeout in establishing the connection, the client reports the outcome to the server. The server then persists these results for subsequent analysis.
4.2
Study
Our measurement study ran from December 1, 2022, to January 1, 2023. We announced the study both publicly in libp2p and IPFS community channels. Interested participants were invited to sign up via a form that collected general information about the network in which they primarily intended to run the client. The participants received an API key from us, which allowed us to link the collected data points with their questionnaire responses. Importantly, we imposed no restrictions on client mobility: participants were free to move their client between networks at their discretion. This introduces a challenge in the data analysis, as data points for a given client must be associated with the specific network in which they occurred. We discuss this challenge in Section 5.1, but we believe that allowing such flexibility was crucial to maximizing participation. Participation did not require registration. Users could download the source code, run the clients themselves, and report results directly to our server. In these cases, the server generated a random API-Key for the participant. Any detected abuse by non-registered clients could be excluded from the dataset; however, we did not observe any such behavior.
4.3
Dataset
In total, we tracked over 6.25 million hole punches across 212 API keys while registering 148 sign-ups. Figures 3a and 3b show that the clients were deployed in 39 countries and hole-punched remote peers in 167 countries. The maps also show the number of data points contributed from each country. While the sample distibution is skewed toward the U.S., our dataset captures globally distributed measurements. Each time a client completes a hole punch probe, it reports a hole punch result, which may contain multiple hole punch attempts, as each hole punch is tried up to three times. Each attempt has an individual “outcome” in addition to the overall result. Tables 1 and 2 list the possible outcomes for a hole punch result and attempt, respectively. Understanding these outcomes is important for interpreting our evaluation. Each data point includes the following information: the client and remote peer identifiers, all IP addresses and ports that the client is listening on, the set of addresses used to connect to the remote peer (typically a single relay address), the set of addresses used to directly connect to the peer, any open connections to the remote
IMC ’26, October 12–16, 2026, Karlsruhe, Germany
Trautwein et al. ×106
1.25
(a)
1.00 0.75 0.50 0.25
1.4 1.2
(b)
1.0 0.8 0.6 0.4 0.2
Contributed Hole Punch Results
1.50
Contributed Hole Punch Results
×106
Figure 3: (a) Geographic distribution of controlled client peers in the measurement study that contributed hole punch results. (b) Geographic distribution of remote peers that interacted with the IPFS network that contributed hole punch results in the measurement campaign. Table 1: The possible outcomes of an individual hole punch result as reported by the clients. Each hole punch results can consists of up to three “attempt” data points. Their outcomes are listed in table 2 Outcome UNKNOWN NO_CONNECTION NO_STREAM CONNECTION_REVERSED
CANCELLED FAILED SUCCESS
Description There is no information why and how the hole punch completed. The client could not connect to the remote peer via any of the provided multi addresses. The client could connect to the remote peer via any of the provided multi addresses but no /libp2p/dcutr stream was opened within 15s. That stream is necessary to perform the hole punch. The client only used one or more relay multi addresses to connect to the remote peer, the /libp2p/dcutr stream was not opened within 15s, and we still end up with a direct connection. This means the remote peer successfully reversed it. The user stopped the client (also returned by the rust client for quic multi addresses). The hole punch was attempted multiple times but none succeeded OR the /libp2p/dcutr was opened but we have not received the internal start event OR there was a general protocol error. Any of the hole punch attempts succeeded.
Table 2: The possible outcomes of an individual hole punch attempt as reported by clients. Each hole punch results can consists of up to three “attempts” data points with the possible outcomes listed below. The outcome of the attempts informs the overall outcome of the result in table 1 Outcome UNKNOWN DIRECT_DIAL PROTOCOL_ERROR CANCELLED TIMEOUT FAILED SUCCESS
Description There was no information why and how the hole punch attempt completed. The connection reversal from our side succeeded (should never happen). This can happen if e.g., the stream was reset mid-flight. The user stopped the client. We waited for the internal start event for 15s but timed out. We exchanged CONNECT and SYNC messages on the /libp2p/dcutr stream but the final direct connection attempt failed; the hole punch was unsuccessful. We were able to directly connect to the remote peer.
peer after the hole punch, and any active port mappings on the client side. We make our dataset available under the CC BY-SA license with the following IPFS content identifier: bafybeia7sq3nfd7c4obcy7ahjvnoka7ujdiob33r7rqyeycgicdt3iknki
A detailed description of the dataset structure and content is found in Appendix A.2. Personally identifiable information has been anonymized. 4.3.1 Limitations. We acknowledge several methodological limitations that may affect interpretation of the evaluation results. Client Sampling. Our client fleet was recruited from volunteers in the IPFS and libp2p communities. This group is likely more technically proficient and may operate on more stable or less restrictive networks than the general P2P user base. This selection bias may
lead to an overestimation of the protocol’s success rate (H1) and may limit the generalizability of our findings. Discovery Bias. Our measurement setup relies on a ’honeypot’ that discovers remote, NATed peers by accepting inbound relayed connections. This approach systematically excludes peers behind highly restrictive NATs or firewalls that prevent even relayed connections. Consequently, the set of remote peers in our study is pre-filtered for a baseline level of reachability, which may inflate the observed hole-punching success rate. NAT Type Classification. Our measurement architecture observes only the outcome of hole-punch attempts (success or failure), not the internal mapping and filtering behavior of remote NAT devices. Classifying NAT types as defined in RFC 4787 [17] requires
NAT Traversal Measurement Campaign
IMC ’26, October 12–16, 2026, Karlsruhe, Germany
1.00 70.9%
0.75
4
2
(b)
0.50 0.25
20.9% 8.1%
0
CDF
(a)
Hole Punch Results
×106
0.3‰ 0 1 2 >2 Number of Networks
0.00 0
10 20 30 Unique Networks
Figure 4: (a) Network identifications per hole punch result. Most could be linked to a single network based on the reported IP addresses that the client listens on. (b) CDF of the number of unique networks per client, showing that over 60% of clients operated from a single network throughout the study. dedicated multi-server probing techniques [22] that were outside the scope of our campaign. This also extends to Carrier-Grade NAT (CGNAT) deployments, which introduce an additional NAT layer and frequently employ EDM translation [28]; our data cannot distinguish single-NAT from CGNAT peers. As a result, we cannot and do not attribute individual failures to specific NAT configurations.
5
Evaluation
In this section, we evaluate the data collected during our study to empirically test the hypotheses outlined in Section 3.4. We describe our data-preparation steps, analyze the protocol’s overall success rate and its dependence on network and transport factors, and assess its efficiency.
5.1
Data Preparation – Network Identification
Our analysis of DCUtR’s performance begins with identifying the individual networks from which clients operated. Because clients are mobile, it is necessary to segment each client’s data by the network environment in which the measurements occurred. This avoids conflating results from different network conditions (e.g., distinct NAT devices and policies). We identify individual networks using two assumptions: (i) data points belong to the same network if the client reports the same public IP address, and (ii) if a client’s public IP changes but remains within the same Autonomous System (AS), we treat the measurements as coming from the same network provided that the set of locally assigned private IP addresses remains unchanged. We acknowledge that the second heuristic may conflate distinct networks when a client moves between locations served by the same AS, since consumer NAT devices within a single provider can assign similar private address ranges. Applying this method, we identify 859 distinct networks that the clients operate in (no two clients operated from the same network) and 86, 769 networks for remote peers. Figure 4a shows that our network identification process successfully associated approximately 4.43 million data points (70.9% of the 6.25 million reported hole-punch results) with a single, unambiguous client network. In contrast, 20.9% of data points were associated with “0 public networks,” meaning the client did not advertise a
public IP address. This can occur when no relay reservation was in place yet or when the Identify protocal is unable to determine a public address. An additional 8.1% of data points correspond to clients that reported multiple public IPs across different networks, which can arise when a client is assigned more than one public IP address. Figure 4b further illustrates that the majority (over 60%) of clients operated exclusively within a single network. At the other extreme, one highly mobile client was observed operating from 28 distinct networks during the measurement period. For the following analysis, we only consider hole punch results that we could unambiguously associate with a single network. The excluded data points represent fundamental failures in the broader connectivity stack upon which DCUtR depends. While our subsequent analysis focuses on the efficacy of the hole-punching stage itself, this initial failure rate underscores the multi-layered challenges inherent in establishing P2P connectivity under real-world conditions. We revisit this and other limitations in Section 6.
5.2
Analysis
In the following sections, we evaluate the hypotheses from Section 3.4. 5.2.1 H1: Viability and Efficacy. To test our primary hypothesis regarding the viability of decentralized NAT traversal (H1), we first establish the baseline success rate of the DCUtR protocol across our large-scale deployment. Figure 5a shows the daily number of reported hole punch results grouped by outcome categories defined in Table 1. The graph shows that the number of contributed hole punches increased after December 1, declined over Christmas, and tapered off following the distribution of the campaign termination notice in early January. This pattern aligns with the timing of our study and expected client availability during the holiday period (see Figures 3a and 3b). To derive the success rate that a peer would experience when attempting to connect to a random peer in the IPFS network, we consider only hole-punch results that meet the following criteria: (i) no port mapping was already in place, (ii) the client contributed more than 1,000 data points from the respective network, and (iii) the outcome is either SUCCESS or FAILED (see Table 1), ensuring that a hole-punch attempt was actually performed. The 1,000 data point threshold ensures statistical stability of per-network success rates by excluding transient or minimally contributing clients whose small sample sizes would introduce high variance into the aggregate metric. Figure 5b shows the per-network success rates, visualized as shaded points averaged per day. The secondary y-axis indicates the number of data points that satisfy the filtering criteria, providing context for the sample size. A linear fit across all networks over the measurement period yields an average conditional hole-punch success rate of 70% ± 7.1%. This rate depends on successful relay reservation and public address discovery which themselves fail for approximately 29% of attempts (see Section 6). Consequently, the end-to-end probability of establishing a direct connection from scratch is lower than the hole-punch success rate. This consistently high success rate across a diverse and global set of networks provides strong evidence in support of H1, demonstrating that DCUtR is an effective protocol for establishing direct P2P connections. We
IMC ’26, October 12–16, 2026, Karlsruhe, Germany
CONNECTION_REVERSED CANCELLED
100
FAILED SUCCESS
40k Individual Network
Hole Punch Results/Day 35k
Campaign start
Campaign end
80 60
(b) 40 20
0 8 5 2 1 8 5 2 1 8 1− 0 1− 1 1−2 −12−0 −12−0 −12−1 −12−2 1− 0 1− 0 2−1 022−1 022−1 2 2 2 2 3 − 0 023 − 0 202 2 2 202 202 202 202 202 2 Date
Success Rate per Day in %
(a)
Hole Punch Results per Day in 103
100
80
30k 25k
60
20k 40
15k 10k
20
5k 0 1 8 5 2 1 8 08 15 22 2− 0 2− 0 2− 1 2− 2 1− 0 1− 0 11− 2−11− 2−11− − 2 2−1 022−1 022−1 022−1 3−0 023−0 202 202 202 202 2 2 2 202 2
Number of Hole Punches per Day
NO_CONNECTION NO_STREAM
Trautwein et al.
0k
Date
Figure 5: (a) Reported hole punch results over the course of the duration of our measurement campaign split by their individual outcomes according to table 1. (b) Daily success rates of hole punches for individual networks across the entire measurement period. The dashed orange line is the line of best fit across all success rates. discuss the implications of this rate further in Section 6. However, we acknowledge that this number is not indicative of any individuals’ experienced success rate. It instead gives a statistical average across the network and tells how likely it is for two random peers behind NAT devices to establish a direct connection using DCUtR. Having established the viability of the DCUtR protocol with a consistent success rate (H1), we now quantify the tangible performance benefits for peers that successfully establish a direct connection. Figure 6a illustrates the latency reduction achieved when upgrading from a relayed to a direct path. For each successful hole punch, we compute the ratio between the direct RTT to the remote peer and the RTT measured via the relay. For example, if the RTT through the relay is 1 s and the post-hole punch direct RTT is 0.7 s, the resulting ration is 70%. The figure shows that 50% of peers experience a reduction to 70% or less of their original RTT. Approximately 10% of peers report a higher RTT after the hole punch (all points above 100 ), while 90% benefit from a reduced RTT. These results confirm that hole punching can significantly improve performance and enable delay-sensitive applications. Cases where the direct path is slower than the relayed path can occur if the relay is located on a high-speed internet backbone, while the direct peer-to-peer path traverses slower consumer-grade ISP networks.
100% of the distance, then the RTT from the client to the relay reflects the fraction of the path the relay occupies. For example, if the RTT to the remote peer through the relay is 1 s and the RTT to the relay is 700 ms, we define the relay as being 70% away from the client to the remote peer. Figure 7a shows the success rate (blue) as a function of the relay’s fractional path position to the remote peer (binned in 5% increments), along with the number of hole punch results in which the relay was in that specific path location (red). The data shows that the success rates are largely independent of the location of the relay along the path. Most relay nodes fall near the midpoint between us and the remote peer, with a slight skew toward proximity to the client. This skew is expected, since peers by default request reservations with two relays. Clients then dial remote peers via all available relay addresses. It is natural that the connection to the closer relay, and thus to the remote peer through it, succeeds first. Taken together, these findings demonstrate only a minor effect from elevated RTTs and no measurable dependence on relay path location, providing compelling evidence for H2. The performance of DCUtR is thus robust to the position and latency of the facilitating relay, which is a critical characteristic for a permissionless, decentralized P2P system.
5.2.2 H2: Relay Independence. A key requirement for a decentralized relay system is independence from relay-specific characteristics (H2). We first test this hypothesis by investigating the influence of the round-trip time (RTT) through the relay on the hole-punch outcome. Figure 6b compares two Cumulative Distribution Functions (CDFs) of RTTs to the remote peer via the relay: one for successful hole punches (solid blue) and one for failures (dashed red). While failed attempts exhibit slightly higher RTTs, suggesting a weak negative correlation, the overall difference is minor as the two CDFs remain closely aligned. To further validate our hypothesis of relay independence (H2), we analyze whether the relay’s location along the network path between the two peers affects success rates. The client-reported data include both the RTT to the relay and the RTT to the remote peer via the relay, enabling us to infer the relay’s relative location. If we define the RTT through the relay to the remote peer to be
5.2.3 H3: Effective Synchronization. The protocol’s synchronized dialing mechanism is central to its design. We now test two related hypotheses: that synchronization is highly efficient (H3a) and sufficiently accurate to render the protocol transport-agnostic (H3b). Effective synchronization requires that RTT measurements are accurate enough to coordinate simultaneous connection attempts. That is, packets from each peer must have departed their respective routers before packets from the other peer arrive. Figure 7b aggregates all RTT measurements collected during the measurement study. Each RTT measurement represents up to ten ping samples. We categorize the dataset into three RTT scenarios: (1) client → relay, (2) client → remote peer via relay, and (3) client → remote peer directly following a successful hole punch. The results show that for the critical relay-mediated RTTs (scenario 2), over 90% of measurements exhibit a standard deviation less than half of the average RTT, indicating a substantial synchronization margin. As
NAT Traversal Measurement Campaign
IMC ’26, October 12–16, 2026, Karlsruhe, Germany
1.0
(a)
CDF
0.8 0.6 0.4
(b)
0.2
CDF in %
100 Outcome SUCCESS FAILED
50 0
0.0
10−2 10−1 100 101 RTT After Hole Punch / RTT Through Relay
10−2 10−1 100 101 Round Trip Time Through Relay in s
Figure 6: (a) The direct RTT as a fraction of the RTT through the relay. (b) RTT distributions for hole punches with the outcomes SUCCESS and FAILED. The sample sizes are 897, 747 and 684, 376, respectively. expected, latency measurements to the relay and to the remote peers exhibit similar distributions, with RTT variations generally smaller than those observed in the measurements involving the relay path to the remote peer. Attempts (H3a). With RTT measurement accuracy established, we assess H3a. Figure 9a reveals that 97.6% of successful hole punches complete on the very first attempt, with only 2.4% requiring additional retries. This finding has direct implications for protocol optimization: if later attempts contribute only marginal gains, the DCUtR protocol may be simplified by reducing retries or adjusting the retry strategy. We discuss such protocol optimizations in Section 7. Transport Protocol Dependence (H3b). We now evaluate H3b, which challenges the conventional assumption that UDP-based hole punching is inherently more effective than TCP-based techniques. This assumption is rooted in fundamental differences in how NATs handle TCP and UDP flows, and how NATs and firewalls process their traffic. We discuss these arguments in Section 6. To test transport agnosticism, we analyze the success rates for hole punches when explicitly restricted to either TCP or QUIC. Figure 8a shows that when transport is unrestricted, roughly ∼ 80% of resulting connections use QUIC. This reflects only that QUIC’s connection establishment latency is lower than TCP’s, a finding consistent with Liang et al. [21], and does not directly speak to hole-punch success. When we restrict hole-punch attempts to a specific transport protocol, Figure 8b shows that both TCP and QUIC achieve success rates near ∼ 70%, strongly validating H3b. DCUtR’s deterministic synchronization mechanism effectively mitigates the traditional challenges of TCP traversal, demonstrating that the protocol is indeed transport-agnostic. 5.2.4 H4: Effectiveness of the Connection Reversal Optimization. The DCUtR protocol includes Connection Reversal as a fast-path optimization. To test its real-world effectiveness (H4), we analyze the distribution of outcomes for peers that report an active port mapping. As noted in Section 3, libp2p attempts to register port mappings with routers using UPnP or PMP. Hole punch result data points from our fleet of clients also comprise information about active port mappings in their local network. However, while these mappings are considered advisory due to potential router dishonesty or unannounced expirations, their presence is expected
to influence hole punching outcomes. Specifically, a higher share of CONNECTION_REVERSAL outcomes would be anticipated when an active port mapping is reported, as this allows a direct connection without the need for a full hole punch. Figure 9b shows the distribution of cases where a port mapping was active and inactive respectively. One can clearly see the significantly higher share of CONNECTION_REVERSAL outcomes in the case of active port mappings on the clients’ side of the connection. This observation empirically validates the importance of the connection reversal technique within the DCUtR protocol. If a direct connection can be established via a pre-existing port mapping, it is highly advantageous to prioritize this method over initiating a full hole punch. Connection reversal avoids the inherent complexities, timing sensitivities, and resource consumption associated with the hole punching procedure, making it a more efficient and reliable path to direct connectivity when applicable. This empirical validation of the Connection Reversal mechanism confirms H4 and underscores the value of including such preliminary checks to avoid the overhead of the full hole-punching procedure when possible. We note that this analysis is based on port-mapping reports from our 212 volunteer clients, whose network configurations may not be representative of the broader population.
6
Discussion
Our empirical evaluation validates the core hypotheses regarding DCUtR’s performance. The confirmation of relay independence (H2) is especially important for permissionless P2P systems, demonstrating that the protocol does not rely on a subset of privileged or well-positioned relays for correct operation. This robustness to the position and latency of the relay is essential when relay selection is random and relay quality is not guaranteed. Furthermore, our establishment of a contemporary, conditional baseline success rate of roughly 70% across a large and diverse set of networks over an extended period (H1) substantially expands on the scale and recency of prior work and provides a crucial benchmark for future optimizations and comparisons. Earlier studies, e.g. Halkes et al. [14] in 2011 found that “approximately 64% of all peers are behind a NAT box or firewall which should allow hole punching to work, and more than 80% of hole punching attempts between these peers succeed.” To the best of our knowledge, only Guha et al. [13] reported “in the wild” hole-punching success rates. They reported
Trautwein et al.
80 Success Rate
Hole Punches
75
60
50
40
25
20
0
0
10
20 30 40 50 60 70 80 Relay Location to Remote in %
90 100
0
1.0 0.8
(b)
CDF
(a)
Success Rate in %
100
# of Hole Punches in 103
IMC ’26, October 12–16, 2026, Karlsruhe, Germany
0.6 RTT to Relay RTT to Remote RTT through Relay
0.4 0.2 0.0 0.0
0.2
0.4
0.6 0.8 1.0 RTT Ratio STD/AVG
1.2
1.4
100 80 60
(b)
40 20 0
TCP
QUIC
Success Rate in %
(a)
Share of Successful Hole Punches in %
Figure 7: (a) Success rate dependence on relay location along the path. (b) Ratio of the mean over the standard deviation of the RTT measurements 100 80 60 40 20 0
TCP
QUIC
Figure 8: (a) If the hole punch was successful, which transport was the final connection using (b) If the attempts were restricted to using a single transport, what are the respective success rates.
an “88% average success rate for TCP connection establishment with NATs in the wild.” However, their measurements comprised just 93 home NATs, which offers limited statistical power and lower representativeness than our considerably larger dataset. Moreover, all studies we identified rely on data that is considerably outdated. This may not accurately reflect the current internet landscape and underscores the need for renewed, large-scale measurement of NAT traversal in the current Internet. Transport Protocol Dependence. The validation of H3b (transport agnosticism) merits further discussion. TCP hole punching is widely considered difficult due to constraints of the three-way handshake and susceptibility to RST packets from stateful firewalls, which are well-documented [11, 13]. Additionally, the standard Berkeley sockets API does not inherently support the simultaneous open and listening on the same port required for TCP hole punching. While SO_REUSEADDR and SO_REUSEPORT options can facilitate this, their improper use may violate TCP standards and introduce complex, hard-to-debug issues. Also, the repetitive SYN transmissions inherent in traditional TCP hole punching simultaneous open attempts can be misconstrued as SYN flood attacks by network security systems, leading to blocked connections or temporary IP blacklisting. TCP’s stateful nature can also consume router resources under repeated failed attempts, potentially degrading network performance, leading to denial-of-service conditions in constrained network environments or prohibiting subsequent retries.
The findings of our empirical study on transport protocol dependence present a counterpoint to this conventional understanding. Our data show similar success rates, around 70%, for both TCP and QUIC. This contradicts the long-held common assumption that “UDP hole punching is easier than TCP”. The reconciliation of this non-intuitive finding with the detailed theoretical difficulties of TCP hole punching suggests DCUtR’s synchronization effectiveness. By having the initiator wait for 12 · RTTrelayed before dialing, the protocol assumes approximately symmetrical network delays so that both peers’ SYN packets depart before either arrives at the opposite NAT. Under this assumption, unsolicited SYN packets would only reach the other peer’s NAT if the RTT measurement error exceeds the direct one-way latency between the two NATs. Our RTT accuracy measurements support this: the standard deviation is less than half of the measured RTT in the large majority of cases. When path asymmetry is significant, however, the synchronization margin shrinks, which may partly explain the remaining ∼ 30% failure rate. The synchronization accuracy means the problem space for DCUtR largely becomes deterministic rather than stochastic. This insight motivates the optimizations described in Section 7. Limitations. As noted in Section 5.1, approximately 29% of collected data points are excluded because prerequisite stages, such as establishing a relayed connection via Circuit v2 or discovering public addresses via Identify, failed before a hole-punch would be attempted. Our reported 70% success rates, therefore, characterize the performance of the DCUtR hole-punching stage, conditional on earlier steps succeeding. The unconditional end-to-end connectivity metric for establishing a direct connection from scratch is necessarily lower once these prerequisite failure modes are taken into account. Furthermore, as discussed in Section 4.3.1, our dataset does not support a definitive classification of remote NAT types, preventing us from attributing individual failures to specific NAT mapping or filtering behaviors rendering this a promising avenue for future work. This distinction underscores the multiple challenges that arise when enabling P2P connectivity in the wild. Security Considerations. DCUtR’s permissionless design introduces several security trade-offs. During the handshake, both peers disclose their public IP addresses and port numbers via CONNECT messages routed through the relay. Because any peer including malicious actors can initiate this exchange, systematic collection
100 80 60 40 20 0
IMC ’26, October 12–16, 2026, Karlsruhe, Germany
97.6% Samples: 1,200,947
1
Samples: 21,612
Samples: 7,366
1.8%
0.6%
2 Attempts
3
(b)
Share of all Hole Punch Results in %
(a)
Share in %
NAT Traversal Measurement Campaign
100
Outcome CONNECTION_REVERSED FAILED NO_CONNECTION NO_STREAM SUCCESS
80 60 40 20 0
Active Inactive Port Mapping
Figure 9: (a) If successful, with which attempt succeeded the hole punch. (b) Influence of active port mappings on the hole punch outcome. of these addresses through repeated hole-punch probes could facilitate targeted scanning or exploitation of inadvertently exposed services. The relay itself represents a trust boundary. It can observe the addresses and connection patterns of both parties, enabling behavioral profiling over time. On the denial-of-service front, repeated failed TCP simultaneous-open attempts can be misidentified as SYN floods by stateful firewalls, risking IP denylisting, while resource-constrained NATs may exhaust their session tables under sustained probing.
7
Optimizations & Future Work
The remaining ∼ 30% failure rate represents the next frontier for DCUtR improvement. Failures can arise from transient network conditions, misconfigurations, overly restrictive firewalls, or the prevalence of Symmetric NATs. We propose a multi-tiered roadmap to universal connectivity. The viability of this roadmap is underscored by the central finding of transport-agnosticism of DCUtR as a result of the effective RTT-based synchronization.
7.1
Probabilistic Traversal via the Birthday Paradox
The ∼ 30% failure rate, despite the protocol’s general efficacy (H1), is likely due, in part, to challenging NAT configurations, such as Endpoint-Dependent Mappings (EDM). To address this class of failures, which cannot be solved by simple synchronization, we propose exploring techniques based on the birthday paradox, a known method for traversing EDM NATs by creating a high probability of a port collision. Halkes et al. [14] observed in 2011 that approximately 11% of their monitored peer cohort were behind EDM NAT devices. As discussed in Section 2, these devices make it impossible to predict the assigned port when establishing connections to other peers in the network, rendering the port information exchanged via the relay in the DCUtR protocol ineffective. To address this challenge, we can exploit the statistical properties of port allocation to create collisions within the 216 port search space that would otherwise be computationally intractable. For example, if the peer behind the EDM NAT opens 256 ports simultaneously while the connecting peer probes 256 randomly selected ports (representing 0.4% of the total search space), the probability of establishing a successful connection reaches 64%. When the search space coverage increases to 3.1% (2,048 ports), the success probability rises to 99.9%. However, when both peers operate behind EDM
NATs, the success probability drops significantly to 0.01% when probing 2,048 ports on one side and 256 on the other [2]. Based on the EDM NAT prevalence reported by Halkes et al. [14], we expect to encounter approximately 19.6% mixed EDM/EIM peer combinations and 1.2% combinations where both peers are behind EDM NATs. If birthday paradox techniques achieve a 64% success rate for the 19.6% of mixed connection attempts, the overall DCUtR success rate could improve 12.5%. We assume conservative values for port probing and opening operations, as NAT devices maintain limited active session capacities and may interpret intensive port scanning as malicious behavior, potentially blocking the peer’s IP address for extended periods. Without these constraints, success rates could be substantially higher. Beyond NAT resource limits, opening a high volume of ports (e.g., 256–2,048) simultaneously also increases a node’s attack surface: each open port represents a potential entry point for fingerprinting or exploitation by adversaries who may be aware of the technique. Aggressive port allocation patterns may trigger network-level intrusion detection systems. Deployments of birthday-paradox-based traversal must therefore balance the probability of successful traversal against the security exposure introduced by maintaining many concurrent open ports. The data from Halkes et al. [14] presents limitations due to its age (2011) and relatively small sample size (fewer than 2,000 peers). Two conflicting trends have emerged since their study: (i) the expected reduction in EDM NAT deployment as vendors increasingly comply with the BEHAVE RFC [17], and (ii) the proliferation of Carrier-Grade NAT (CGNAT) deployments, which employed EDM translation in 40% of cases as of 2016 [28]. Future empirical studies are necessary to establish more accurate contemporary estimates of expected success rate improvements.
7.2
Protocol Optimizations
Refining RTT Calculation by Removing Local Latency. A powerful optimization would let users choose a proxy with advantageous NAT properties (e.g., a full-cone NAT). This strategy, however, introduces an additional network hop, making the timing of the hole punch even more critical. The current DCUtR protocol utilizes Round Trip Time (RTT) measurements between peers to coordinate hole punching attempts. However, it is the RTT between the respective NAT devices, rather than the peers themselves, that is
IMC ’26, October 12–16, 2026, Karlsruhe, Germany
truly pertinent. Although our measurements indicate that peer-topeer RTT often serves as a reasonable approximation, this approach may be insufficient in more complex network topologies. In such cases, the resulting discrepancy can cause the SYNC packet to arrive outside the optimal time window, thereby increasing the likelihood of connection failures. Therefore, we propose an enhancement where the listener includes its observed RTTListener - NAT to its NAT (or an equivalent near-edge network element) within its CONNECT message. The initiator, upon receiving this information, can then compute a more accurate wait time 𝑇wait for sending its SYNC packet by also incorporating the RTTInitiator - NAT to its NAT. The refined calculation for the protocol’s RTT then reads as follows: 𝑇wait = 1/2(RTTListener - Initiator +RTTListener - NAT −RTTInitiator - NAT ). This approach aims to better estimate the one-way traversal to the remote peer’s NAT by factoring out local latency on each side, thus improving the timing precision of the SYNC message in topologies where the local network segment between a peer and its NAT introduces significant delay. Alternating Roles on Connection Retries. The validation of H4 reveals that retries exhibit diminishing returns. This suggests that repeating the same action is suboptimal. We propose an alternative retry strategy for subsequent attempts to increase the success rate. In the case of QUIC hole punching, upon receiving the SYNC message from the initiator, the listener immediately dials back. The initiator, on the other hand, starts to send UDP packets filled with random bytes to the listener upon expiry of the 1/2 RTT timer to prime its NAT. This will result in a QUIC connection where the listener is the client and the initiator is the server. If we assume that the initiator is behind an EDM NAT but the listener is not, the listener’s client hello will not be able to traverse the initiator’s NAT because of the unpredictable nature of the port mappings. We propose to alternate the roles in subsequent attempts. The above scenario would succeed on the second try, given that the initiator is not behind a symmetric NAT. Contrary to a TCP simultaneous open, having both parties sending client hellos might result in two distinct QUIC connections, which can also be acceptable in some scenarios. Proactive NAT Priming to Prevent Denylisting. Some NATs or firewalls denylist external IPs if inbound UDP packets arrive before any outbound state exists [11]. To mitigate this, we propose a more cautious NAT priming strategy. Instead of sending random UDP payloads that might reach the initiator’s NAT, the listener should send low Time-To-Live (TTL) packets (e.g., TTL=3) to the initiator’s advertised addresses. This limits propagation while priming the listener’s NAT. Similarly, once the initiator receives the listener’s CONNECT message, it should send low-TTL packets to the listener until its SYNC timer fires. This staggered priming reduces denylisting risk while establishing outbound mappings before hole punching begins.
7.3
Ecosystem Strategies
Long-term success also depends on improving the network environment itself through a combination of standards advocacy and better use of existing mechanisms. This echoes a long-standing hope in the community (e.g. by Halkes et al. [14] in 2011), that broader vendor compliance with standards like IETF’s BEHAVE [17] would reduce
Trautwein et al.
the prevalence of such “hard” NATs. In parallel, our findings confirm that Connection Reversal optimization is highly effective when a port mapping is available (H4). Client software should actively assist users in enabling UPnP/PMP on their routers, explaining the direct connectivity benefits while acknowledging potential security trade-offs.
8
Related Work
NAT hole punching, or NAT traversal, has been a recognized technique for enabling direct peer-to-peer communication across Network Address Translators for over two decades. The concept was initially introduced by Dan Kegel in 1999 [18], who outlined a NAT traversal protocol utilizing UDP packets, primarily motivated by the requirements of peer-to-peer gaming applications. One of the foundational publications in this domain is by Ford et al. [12], which describes early approaches to peer-to-peer communication across NATs. Subsequent research has explored various facets of NAT traversal. Guha and Francis [13] provided an empirical characterization and measurement of TCP traversal through NATs and firewalls, offering insights into the challenges posed by TCP’s connectionoriented nature. Similarly, Halkes and Pouwelse [14] investigated UDP NAT and firewall puncturing in real-world scenarios, contributing to the understanding of UDP’s behavior in NAT environments. The Interactive Connectivity Establishment (ICE) protocol [20, 29] unifies several NAT traversal techniques, including Session Traversal Utilities for NAT (STUN) [26] and Traversal Using Relays around NAT (TURN) [27], to provide a comprehensive framework for establishing peer-to-peer connections in complex network topologies. ICE is widely adopted in real-time communication protocols, such as WebRTC [1]. Further studies have delved into the specific aspects and challenges of NAT traversal. Ford et al. [12] provided a comprehensive overview of the state of peer-to-peer communication across NATs, detailing various techniques and their limitations. Richter et al. [28] conducted a multi-perspective analysis of Carrier-Grade NAT (CGNAT) deployment, highlighting its prevalence and impact on network behavior. Other works have explored edge-case integration into established NAT traversal techniques [19], knowledge-based NAT-traversal for home networks [25], and the revisiting of NAT hole punching strategies [23]. Additionally, research has examined peer NAT proxies for peer-to-peer games [30]. Liang et al. [21] show that QUIC-based hole punching is theoretically 0.5 RTT faster than TCP-based hole punching due to its integrated 1-RTT handshake compared to TCP’s 3-way handshake followed by a separate TLS handshake.
9
Conclusion
This paper presents a large-scale empirical evaluation of DCUtR, validating its design principles and establishing a contemporary benchmark for decentralized NAT traversal. We show that hole punching succeeds at a conditional rate of approximately 70%, given successful relay reservation and address discovery (H1), that this performance is independent of relay characteristics (H2), and that synchronization is highly effective, with most successes occurring on the first attempt (H3a). Contrary to long-standing belief, TCP and QUIC exhibit comparable success
NAT Traversal Measurement Campaign
rates (H3b). We also validate key protocol optimizations such as Connection Reversal (H4) and demonstrate significant latency reductions after successful traversal.Our CC BY-SA licensed dataset of over 4.4 million measurements across more than 85k networks globally provides a valuable resource for future research. DCUtR meaningfully advances decentralization by reducing reliance on centralized intermediaries, thus mitigating single points of failure and enhancing self-sovereign control over data. While not a full replacement for STUN/TURN today, it can already offload significant traffic and, when combined with suitable relays (e.g. VPN or SSH gateways), has the potential to eliminate dependence on these services entirely. The proposed optimizations of role alternation on retries, refined RTT calculation, proactive NAT priming, and the birthday paradox exploitation offer concrete paths toward higher direct-connectivity rates and strengthen the protocol as a building block for the decentralized Internet.
Acknowledgments We thank Max Inden for his invaluable contributions in proposing the honeypot component, building the Rust client, and suggesting the alternating roles on connection retries optimization. We also extend our sincere thanks to Elena Frank for her dedicated work on the Rust client.
IMC ’26, October 12–16, 2026, Karlsruhe, Germany
IMC ’26, October 12–16, 2026, Karlsruhe, Germany
References [1] Harald T. Alvestrand. 2021. Overview: Real-Time Protocols for Browser-Based Applications. RFC 8825. doi:10.17487/RFC8825 [2] David Anderson. 2020. How NAT traversal works. https://tailscale.com/blog/hownat-traversal-works Accessed: 2025-05-18. [3] Juan Benet. 2014. IPFS-content addressed, versioned, P2P file system. arXiv:1407.3561 (2014). [4] C Bommelaer de Leusse and Carl Gahnberg. 2019. The Global Internet Report: Consolidation in the Internet Economy. Internet Society (2019). [5] Mohamed Boucadair, Reinaldo Penno, and Dan Wing. 2013. Universal Plug and Play (UPnP) Internet Gateway Device - Port Control Protocol Interworking Function (IGD-PCP IWF). RFC 6970. doi:10.17487/RFC6970 [6] Vitalik Buterin. 2013. Ethereum White Paper: A Next Generation Smart Contract & Decentralized Application Platform. (2013). https://github.com/ethereum/ wiki/wiki/White-Paper [7] Lucia D’Acunto, J.A. Pouwelse, and Henk Sips. 2009. A Measurement of NAT & Firewall Characteristics in Peer to Peer Systems. Proc. 15-th ASCI Conference 5031 (01 2009). [8] Trinh Viet Doan, Roland van Rijswijk-Deij, Oliver Hohlfeld, and Vaibhav Bajpai. 2022. An Empirical View on Consolidation of the Web. ACM Trans. Internet Technol. 22, 3, Article 70 (Feb. 2022), 30 pages. doi:10.1145/3503158 [9] Kjeld Borch Egevang and Paul Francis. 1994. The IP Network Address Translator (NAT). RFC 1631. doi:10.17487/RFC1631 [10] Bryan Ford, Saikat Guha, Kaushik Biswas, Senthil Sivakumar, and Pyda Srisuresh. 2008. NAT Behavioral Requirements for TCP. RFC 5382. doi:10.17487/RFC5382 [11] Bryan Ford, Dan Kegel, and Pyda Srisuresh. 2008. State of Peer-to-Peer (P2P) Communication across Network Address Translators (NATs). RFC 5128. doi:10. 17487/RFC5128 [12] Bryan Ford, Pyda Srisuresh, and Dan Kegel. 2005. Peer-to-Peer Communication Across Network Address Translators. In USENIX Annual Technical Conference, General Track. [13] Saikat Guha and Paul Francis. 2005. Characterization and measurement of TCP traversal through NATs and firewalls. In Proceedings of the 5th ACM SIGCOMM Conference on Internet Measurement (Berkeley, CA) (IMC ’05). USENIX Association, USA, 18. [14] Gertjan Halkes and Johan Pouwelse. 2011. UDP NAT and firewall puncturing in the wild. In Lecture Notes in Computer Science. Springer Berlin Heidelberg, Berlin, Heidelberg, 1–12. [15] Matt Holdrege and Pyda Srisuresh. 1999. IP Network Address Translator (NAT) Terminology and Considerations. RFC 2663. doi:10.17487/RFC2663 [16] Max Inden. 2022. Introduction to and State of libp2p By Max Inden Paris P2P Festival #1. Youtube. https://youtu.be/Sbd7odDFT1w?si=CcqK6wWeUENawMIh&t=129 [17] Cullen Fluffy Jennings and Francois Audet. 2007. Network Address Translation (NAT) Behavioral Requirements for Unicast UDP. RFC 4787. doi:10.17487/ RFC4787 [18] Dan Kegel. 1999. NAT and Peer-to-peer networking. http://www.kegel.com/peernat.html. Accessed: 2023-03-08. [19] Simon Keller, Tobias Hoßfeld, and Sebastian von Mammen. 2022. Edge-Case Integration into Established NAT Traversal Techniques. In 2022 IEEE Ninth International Conference on Communications and Electronics (ICCE). 75–80. doi:10.1109/ICCE55644.2022.9852092 [20] Ari Keränen, Christer Holmberg, and Jonathan Rosenberg. 2018. Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal. RFC 8445. doi:10.17487/RFC8445 [21] Jinyu Liang, Wei Xu, Taotao Wang, Qing Yang, and Shengli Zhang. 2024. Implementing NAT Hole Punching with QUIC. doi:10.48550/arXiv.2408.01791 [22] Derek MacDonald and Bruce Lowekamp. 2010. NAT Behavior Discovery Using Session Traversal Utilities for NAT (STUN). RFC 5780. doi:10.17487/RFC5780 [23] Daniel Maier, Oliver Haase, Jürgen Wäsch, and Marcel Waldvogel. 2011. NAT hole punching revisited. In IEEE 36th Conference on Local Computer Networks, LCN 2011. 147–150. doi:10.1109/LCN.2011.6115173 [24] Daniel McIntosh. 2018. We need to talk about data: How digital monopolies arise and why they have power and influence. J. Tech. L. & Pol’y 23 (2018), 185. [25] Andreas Müller, Andreas Klenk, and Georg Carle. 2008. On the Applicability of Knowledge Based NAT-Traversal for Home Networks. In NETWORKING 2008 Ad Hoc and Sensor Networks, Wireless Networks, Next Generation Internet, Amitabha Das, Hung Keng Pung, Francis Bu Sung Lee, and Lawrence Wai Choong Wong (Eds.). Springer Berlin Heidelberg, Berlin, Heidelberg, 264–275. [26] Marc Petit-Huguenin, Gonzalo Salgueiro, Jonathan Rosenberg, Dan Wing, Rohan Mahy, and Philip Matthews. 2020. Session Traversal Utilities for NAT (STUN). RFC 8489. doi:10.17487/RFC8489 [27] Tirumaleswar Reddy.K, Alan Johnston, Philip Matthews, and Jonathan Rosenberg. 2020. Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN). RFC 8656. doi:10.17487/RFC8656 [28] Philipp Richter, Florian Wohlfart, Narseo Vallina-Rodriguez, Mark Allman, Randy Bush, Anja Feldmann, Christian Kreibich, Nicholas Weaver, and Vern Paxson.
Trautwein et al.
2016. A Multi-perspective Analysis of Carrier-Grade NAT Deployment. In Proceedings of the 2016 Internet Measurement Conference (Santa Monica, California, USA) (IMC ’16). Association for Computing Machinery, New York, NY, USA, 215–229. doi:10.1145/2987443.2987474 [29] Jonathan Rosenberg. 2010. Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols. RFC 5245. doi:10.17487/RFC5245 [30] Daryl Seah, Wai Kay Leong, Qingwei Yang, Ben Leong, and Ali Razeen. 2009. Peer NAT proxies for peer-to-peer games. In Proceedings of the 8th Annual Workshop on Network and Systems Support for Games (Paris, France) (NetGames ’09). IEEE Press, Article 6, 6 pages. [31] Marten Seemann, Max Inden, and Dimitris Vyzovitis. 2022. Decentralized Hole Punching. In 2022 IEEE 42nd International Conference on Distributed Computing Systems Workshops (ICDCSW) (Bologna, Italy). IEEE. [32] Dennis Trautwein, Aravindh Raman, Gareth Tyson, Ignacio Castro, Will Scott, Moritz Schubotz, Bela Gipp, and Yiannis Psaras. 2022. Design and Evaluation of IPFS: A Storage Layer for the Decentralized Web. In Proceedings of the ACM SIGCOMM 2022 Conference (Amsterdam, Netherlands) (SIGCOMM ’22). Association for Computing Machinery, New York, NY, USA, 739–752. doi:10.1145/3544216.3544232 [33] Stanislav Vojíř and Jan Kučera. 2022. Towards Re-Decentralized Future of the Web: Privacy, Security and Technology Development. Acta Informatica Pragensia 10 (01 2022), 349–369. doi:10.18267/j.aip.169
NAT Traversal Measurement Campaign
IMC ’26, October 12–16, 2026, Karlsruhe, Germany
A Appendix A.1 DCUtR Sequence Diagram
Figure 10: DCUtR Protocol Sequence Diagram
IMC ’26, October 12–16, 2026, Karlsruhe, Germany
Trautwein et al.
Figure 11: Postgres database UML diagram
A.2
Dataset
In this section, we will provide a detailed overview of the dataset used in our analysis. The provided dataset is a Postgres database dump available via this IPFS CID bafybeia7sq3nfd7c4obcy7ahjvnoka7ujdiob33r7rqyeycgicdt3iknki Figure 11 shows the corresponding UML diagram. This includes information on the time scope of the data, as well as instructions on how to download the dataset and set up a database for storage. Additionally, we will describe the process for restoring the data, and how we obtained the database dump. A.2.1 Peers/Multiaddresses. We collect agent version, supported protocols, and Multihashes of all peers that interact with our measurement infrastructure. Similarly, when we get hand of a multi address we extract the underlying IP address, corresponding Geolocation (continent, country), if it’s a public address or not, if it’s a relayed address or not, if the IP address belongs to a known datacenter, and the corresponding Autonomous System Number. A.2.2 Connection Events. As discussed in Section 4, the honeypot component tracks inbound connections from DCUtR capable peers. We call these events “Connection Events”. A Connection event consists of the following information: • local_id – The internal database peer ID of the honeypot • remote_id – The internal database peer ID of the peer that connected to the honeypot • conn_multi_address_id – The multiaddress of the connection to the honeypot • connection_events_x_multi_addresses – All advertised multi addresses of the remote peer. They strictly won’t contain a public IP address that is not a relayed address. This set will be served to clients. A.2.3 Hole Punch Results/Attempts. A “Hole Punch Result” is what gets reported back by the clients and can consist of multiple “Hole Punch Attempts”. Both data points can have different outcomes that are listed in Table 1 and Table 2.
NAT Traversal Measurement Campaign
IMC ’26, October 12–16, 2026, Karlsruhe, Germany
A.2.4 Latency Measurements. Before clients attempt to hole punch a remote peer, the client measures several latencies. It measures the latencies to all relays that the remote peer claims to be reachable through. It also measures the latency to the remote peer through one of the relays. Finally, if the hole punch succeeds, the client also measures latency of the direct connection. The database field mtype is TO_RELAY, TO_REMOTE_THROUGH_RELAY, and TO_REMOTE_AFTER_HOLEPUNCH respectively. A.2.5 Port Mappings. For each hole punch result, we track any active port mappings that get reported back from AutoNAT. If a port mapping is in place it is more likely for an outcome of CONNECTION_REVERSED. With this data we can test this hypothesis. Each port mapping consists of the following data: • The hole punch it refers to • Internal Port of the client in the local network • External Port of the router • Transport used for port mapping • External facing address A.2.6 Authorizations/Clients. Each time someone signed up through our Google Form we generated a UUID API-Key and saved it alongside the email address (from the form) into this table. We asked participants to provide the API Key to their client installations (GUI or CLI). Every hole punch result reported from these clients contained the API key so that we can associate the result with the Google Form information. Importantly, the Go-Client generated ten peer identities upon startup. Each peer ID would listen on a different port. For each hole punch we ‘round robin’ through the ten peers. This way we mitigated persistent port mappings to yield a high number of CONNECTION_REVERSED results. When the client starts up it reports the identities of these ten clients to the server. This fills the ‘clients‘ table where you have a mapping between peer ID and authorization ID. So, to map a hole punch result to an authorization, you’d need to map the local_id field onto the clients table and then to the authorizations table.
A.3
Ethics
The research followed strict ethical guidelines. Participants either signed up, receiving detailed information and providing explicit consent regarding data collection (including IP addresses and libp2p PeerIDs) and its academic use, or voluntarily ran a tool whose documentation (README) clearly stated data collection (including IP addresses and libp2p PeerIDs) for research. Initially, IP addresses were stored in clear text for network analysis (e.g., geographic distribution, network identification for the DCUtR protocol) and securely on a restricted-access research server, accessible only to the core researcher. After core analysis for this paper, all IP addresses were irreversibly anonymized or deleted, preventing deanonymization while allowing statistical correlation. Data from remote, non-consenting peers was collected based on their operation of public, permissionless P2P nodes (IPFS, libp2p), which inherently expose network metadata (IP, PeerID, protocols) through standard interactions. The “honeypot” acted as a regular libp2p node, observing public addresses and sending standard protocol messages. Collected data (e.g., hole punch success) was a byproduct of these standard interactions, with no non-standard or privacy-invasive data gathered beyond what a public P2P node inherently exposes.