A most elegant TCP hole punching algorithm

Original Article ↗ Hacker News Discussion ↗

An article proposing an “elegant” TCP hole punching algorithm for peer‑to‑peer connections behind NATs prompts debate over how well such techniques work in practice, given real-world router behaviors like source-port randomization, carrier‑grade NAT, and restrictive firewalls. Commenters compare TCP and UDP hole punching, point to existing standards (e.g., NAT behavioral RFCs, STUN/UPnP), and argue that IPv6 simplifies addressability but does not eliminate the need to traverse stateful firewalls. Several note that success hinges on non-uniform, often opaque middlebox implementations, making any single algorithm inherently limited in coverage despite its theoretical neatness.

Simultaneous TCP connect and firewall behavior

  • Several comments note that TCP simultaneous open is standardized, so a separate listener isn’t strictly required.
  • Others argue many firewalls/NATs drop inbound SYN-without-ACK packets, so simultaneous connect can fail in practice.
  • There’s disagreement on how common this is: some say “plenty” of setups do early stateless filtering; others insist dropping SYN,!ACK in presence of conntrack is niche.

NAT behavior, port preservation, and “equal delta mapping”

  • The algorithm relies on NATs preserving source ports (“equal delta mapping”) for simplicity.
  • Multiple commenters report that some devices (e.g., pfSense, certain enterprise firewalls) randomize ports by default; others (e.g., some consumer routers, Cisco ASA) often preserve ports when possible.
  • One person notes you can configure pfSense for non-randomized outbound ports (full-cone NAT), which helps P2P/WireGuard.
  • Another clarifies that hole punching only truly requires predictability of external ports, not strict equality.

Timestamp bucket / coordination critique

  • The timestamp-based bucket selection for shared port candidates is called clever but potentially flawed.
  • One critique: hosts near a bucket boundary (e.g., 61s vs 62s) can choose different buckets despite small clock skew; checking adjacent buckets is suggested.
  • Another notes that “coordination” is the hard part; assuming an external coordinator sidesteps the main complexity.

Effectiveness and standardization of TCP hole punching

  • Some ask whether TCP hole punching actually works reliably on common CPEs/CGNATs; experience appears mixed and largely anecdotal.
  • RFCs on NAT behavioral requirements for TCP/UDP are cited, but it’s unclear how widely they are implemented.
  • Several feel TCP punching is more fragile than UDP and underused.

IPv6, NAT, and firewalls

  • Many argue IPv6 would reduce or eliminate the need for NAT traversal, but others point out:
    • Stateful firewalls still block unsolicited inbound traffic, so “hole punching” is still needed, just without address guessing.
    • IPv6 NAT and prefix translation do exist in some setups (e.g., multi-uplink routers).
  • Debate continues over whether IPv6 is a realistic near-term fix, given uneven adoption and existing firewall practices.

Broader views: NAT, firewalls, and P2P

  • Some call NAT and hole punching an architectural “own-goal” and propose more uniform address leasing models.
  • Others argue working around firewalls you don’t control is illegitimate, clashing with those who want P2P (e.g., VoIP on mobile) without provider cooperation.
  • One commenter envisions using this deterministic punch to build fully decentralized P2P agent networks without STUN/TURN or DNS.