Can libp2p punch through NATs?

Introduction

Peer-to-peer networks built on libp2p need nodes behind NAT to be reachable from the Internet. Live measurement of the IPFS Amino DHT (the public IPFS Kademlia-based DHT) puts NAT prevalence at ~91% of peers, and a network that depends on inbound connectivity for DHT serving, content exchange and gossipsub mesh membership needs those peers publicly dialable.

libp2p's Direct Connection Upgrade through Relay (DCUtR) protocol addresses the problem of undialable peers behind NATs. Two peers connected over a circuit-v2 relay, at least one of them behind NAT, use DCUtR to dial each other's public address simultaneously. Each outbound dial opens a pinhole (a transient inbound rule) in its own NAT for the other side's incoming packet, the two SYNs (or QUIC packets) cross in transit, and a direct connection comes up. The relay carries only the signalling; the resulting data connection is direct, peer-to-peer, with no STUN, TURN or dedicated rendezvous server involved. Signalling costs so little that any publicly reachable libp2p peer can serve as the relay.

The first large-scale measurement of DCUtR in production was carried out by Trautwein et al. (ACM Internet Measurement Conference, IMC '26), reporting a conditional hole-punch success rate of 70% ± 7.1% aggregated across all NAT types. The paper left two questions open by design:

1. What is the per-NAT-class decomposition? Punchr, the tool developed for that study, observes only the success or failure of each attempt. It does not classify peers along the RFC 4787 mapping × filtering axes that determine whether a punch is possible at all. The 70% baseline is a weighted mean across NAT regimes that behave very differently.
2. Do the production implementations (go-libp2p, rust-libp2p) interoperate correctly across the NAT regimes the spec targets? Cross-implementation interoperability and spec compliance were not independently audited.

The ProbeLab team ran a study to close that gap. We evaluated DCUtR's protocol behaviour, the production implementations that support it, and its success on the live network, classified by NAT type. Alongside the performance outcomes, the study covers:

• Specification audit: we audited the DCUtR spec for underspecified behaviour with real or theoretical impact.
• Cross-implementation testbed and code analysis: we evaluated go-libp2p and rust-libp2p against every relevant RFC 4787 NAT and transport combination.
• Live measurement campaign: we deployed a multi-region honeypot on the live IPFS Amino DHT that classifies real peers by NAT type and hole-punches the eligible ones.

This post covers our main findings. The full project report is here, and the tools we built to run the hole punches and monitor success rates, along with the runbooks and deployment scripts, are in this repository.

For guidance on using, wiring and deploying libp2p's NAT detection stack, and on integrating it with existing libp2p protocols, see the separate report from our team here.

Results TL;DR

On the live network, Port-Restricted Cone NAT hole-punches successfully in 82.9% of cases. Symmetric NAT succeeds at ~40%, despite symmetric NAT being considered unpunchable: the port mapping is not fixed and therefore not predictable. The symmetric sample is small, though. Only 536 peers were tested as symmetric against 3,669 tested as cone, because very few symmetric-NAT peers were reachable over circuit relay during our live experiments. Aggregated per-class rates match the 70% overall success rate reported by Trautwein et al.

One limit on performance has nothing to do with the protocol: ~36% of DCUtR-advertising NAT'd peers never secure a relay reservation, concentrated in specific operator fleets. DCUtR needs a circuit-relay connection to synchronise the two peers, so without a reservation there is no hole punch to attempt.

In the controlled testbed, go-libp2p and rust-libp2p interoperate at 100% across every punchable NAT. The audit turned up three minor findings, all in error handling, none of which affect the measured results. Details are in the Live Network Measurement and Implementation and Spec Audit Findings sections of the report.

Live network measurement methodology

The main contribution of this report is a multi-region non-cooperative honeypot campaign that classifies real IPFS peers along the RFC 4787 mapping × filtering axes and measures DCUtR hole-punch success per mapping/filtering combination. Non-cooperative is the key difference from Punchr and the IMC '26 study, which require an instrumented client running on the measured peer. Our setup needs no cooperation from IPFS clients: the classification comes entirely from our own passive observations (organic incoming DHT connections) and active probing (outbound dials and relay-coordinated hole punches) of those peers.

NAT distribution on the live network

The IPFS network is overwhelmingly NAT'd. Of the 50,052 distinct peers we observed, 43,684 produced enough observations to classify and place in a NAT bucket. The resulting classification is shown in the table below.

DCUtR hole-punch success per NAT class

Scoped to the DCUtR-eligible cohort only, meaning the peers that both advertise /libp2p/dcutr and hold a relay reservation, the classification is:

Three things stand out.

• Port-Restricted Cone hole-punches at 82.9%, and 99.3% of those are real simultaneous-open hole punches rather than connections that came up by another path.
• Symmetric: 39.7%. The 213 successes are in doubt, because a true ADPM peer should not be punchable by DCUtR, or at least not at that rate. The receive port is unpredictable from what was advertised over the relay. Two explanations are plausible:
  • (a) A within-window misclassification. An ADPM verdict requires a peer to present more than one external port to the same honeypot within the comparison window (30 s for QUIC). A peer whose mapping refreshes faster than that window, say a very short UDP timeout, or a client that opens a fresh source port per connection rather than reusing its listener socket, could trip the ADPM signal while remaining endpoint-independent at any single instant.
  • (b) A network change between classification and probe. A mobile peer that switched from cellular to Wi-Fi mid-campaign keeps its peer-id but presents a fundamentally different NAT. Further work could measure (i) the misclassification rate, which the cross-transport disagreement count suggests is non-trivial, or (ii) why only 2 of 54 peers classified ADPM on every transport we observed hold a relay reservation, against ~30% in the broader ADPM cohort.
• APDF-unresolved sits at 37%, consistent with that cohort being a mixture of PR-Cone (punchable) and Symmetric (not punchable).

Where this leaves DCUtR

This study follows several years in which the success rate of libp2p's NAT hole punching was simply unknown, and it confirms that libp2p does connect peers behind NATs: 82.9% for the dominant Port-Restricted Cone class. Similar P2P technologies, such as holepunch.to and iroh, claim higher rates, at times above 90%, though we haven't seen a study backing those numbers.

The live-network results both validate the IMC '26 paper 70% baseline and extend it. Two studies with different sampling biases (Trautwein's cooperative Punchr, where volunteers run an instrumented client, and this work's non-cooperative honeypot plus cross-region probes) converge on the same aggregate hole-punch rate and the same TCP ≈ QUIC equivalence on the live IPFS network. Reaching the same numbers from two directions is what makes both sets credible. What this work adds is the decomposition of that unstratified 70% by NAT class, with the dominant Port-Restricted Cone hole-punching at 82.9%.