natty · how it works

How natty finds a path to a peer

You want a QUIC connection to Bea. You know her key and her relay. You do not know her address. Both of you are behind NAT.

You and Bea, each behind a NAT, and one relay on the internet INTERNET relay relay.example.net tls 443 · stun udp 3478 cap 1 MiB/s for each session you kq8xt3ry… 192.168.1.20 Bea e4hzwnbo… 10.0.0.5 YOUR NETWORK BEA'S NETWORK NAT203.0.113.7 NAT198.51.100.24 udp 203.0.113.7:40112 udp 198.51.100.24:47809 no probe got an answer

  1. Sessions

    Each endpoint has an Ed25519 key and keeps one TLS session to the relay. Bea's address is her key and her relay host: e4hzwnbo…@relay.example.net.

    A NAT lets out all packets. It lets in only answers to packets that went out. The relay can reach both of you, because each of you opened a session to it.

    Press → or a step number to continue. The arrow keys also work.

  2. Handshake through the relay

    Your endpoint sends the QUIC handshake to the relay, addressed to Bea's key. The relay forwards it on Bea's session. The handshake fails unless the peer holds the key that you dialed.

    The connection is ready now. The steps that follow change only its path. The relay cannot read the QUIC payload.

  3. Public addresses from STUN

    Each endpoint sends a STUN request from its UDP socket to the relay. The relay answers with the source address that it saw. That address is the public address that the NAT gave to the socket.

    The probes in step 3 use the same socket. Most NATs send them through the same opening, with the same public address. For now the NAT lets in only the answer from the relay.

  4. Candidates, then probes

    Your endpoint allowed Bea's key when you dialed her. Bea's application allowed your key. Only allowed keys get candidates and probes.

    Each of you sends candidates through the relay: a local and a public address. Candidates are signed, but not encrypted.

    Then each of you sends an opener to each candidate of the other: a UDP packet with TTL 2. It goes to Bea through the opening from step 2, so your NAT now lets in packets from her. It expires before her NAT. Some NATs change the port when a packet from outside arrives first, so the opener must not reach her.

    200 ms later, both of you send probes. Both NATs are open now.

  5. Direct path

    Bea answers your probe. The QUIC connection moves to the direct path. It is the same connection, so your application sees no change.

    The relay session stays open as a fallback. When the path is silent for 25 s, a probe keeps the NAT mappings open.

    Measured on real networks: a direct path through one NAT, and between two NATs that change the port on an early packet. Not yet shown: double NAT and carrier-grade NAT. See results.md.

  6. Or: the relay continues

    Some pairs of NATs drop every probe. Then no probe gets an answer, and the relay continues to forward the packets. The connection does not fail.

    The relay applies a rate cap to each session, 1 MiB/s by default. The relay also carries the connection again when a direct path stops answering for 5 s.

    A study measured 4.4 million DCUtR punch attempts in IPFS (Trautwein et al., IMC 2026). 29% failed before the punch started, and 70% ± 7.1% of the rest succeeded. So about half of all pairs stay on the relay, and the relay path is a normal path.

TLS session NAT QUIC packet, encrypted STUN candidates, signed opener or probe direct UDP path