I Invented NAT Hole Punching Before It Had a Name
How My 2002 Paper Preceded—and Likely Influenced—RFC 3489 and the Technology Behind Skype and WebRTC
By John L. Sokol
In December 2006, a Slashdot article titled "How Skype Punches Holes in Firewalls" made the front page. The article explained a clever technique that allowed peer-to-peer communication between two computers, even when both were behind firewalls or NAT devices. The technique was presented as if it were novel—a secret sauce that made Skype work where other applications failed.
I read that article with a mix of recognition and frustration. The technique they were describing was identical to what I had documented four years earlier, in June 2002, and had implemented in production video streaming systems as far back as 1997. I left a comment on Slashdot that day, linking to my paper. That comment is still there, archived for posterity.
This is the story of how I came to develop NAT traversal techniques years before they were standardized, and why I believe RFC 3489—the STUN protocol that underlies WebRTC and modern peer-to-peer communication—was derived from ideas I published first.
The Video Streaming Years: 1995-2001
To understand how I came to solve the NAT traversal problem, you need to understand what I was building in the mid-1990s. I wasn't an academic researcher writing theoretical papers. I was an engineer trying to make live video work over the early Internet—and making money doing it.
Starting in 1995, I ran the Livecam Video Streaming Project. We built one of the first commercial live video streaming platforms, serving approximately 2,500 adult websites with full-motion video to over 30,000 simultaneous viewers. This was 1997—years before YouTube, before Flash video, before broadband was common. We were pushing the boundaries of what the Internet could do.
The technical challenges were immense. Bandwidth was expensive—around $50,000 per month. We built custom servers on 90 MHz Pentiums running FreeBSD, developed our own JPEG codec using Zoran hardware compressors, and created a global content distribution network spanning 20 locations. I collaborated with Xing Streamworks on their first commercial streaming video product.
But perhaps the most persistent problem we faced was NAT. Our viewers were increasingly behind home routers and corporate firewalls. The NAT devices that let multiple computers share a single IP address were proliferating rapidly, and they broke everything we were trying to do. If you wanted to receive a video stream, the packets had to reach you—but NAT devices, by design, blocked unsolicited incoming traffic.
So we figured out how to punch through them.
The Technique: What I Discovered
The solution I developed was elegant in its simplicity. Here's the core insight: when a computer behind a NAT sends a packet to an external server, the NAT creates a "mapping"—it remembers which internal address and port sent the packet, and which external address and port it assigned. For a brief window of time, the NAT will allow return traffic from that external destination back through to the internal computer.
The trick is to exploit this behavior with a third-party coordination server. Here's how it works:
Step 1: Computer A (behind a firewall) connects to Server C on the public Internet. This creates a mapping in A's NAT.
Step 2: Computer B (also behind a firewall) connects to the same Server C. This creates a mapping in B's NAT.
Step 3: Server C now knows the external (mapped) IP addresses and ports for both A and B. It sends this information to each party.
Step 4: A sends packets to B's mapped address, and B sends packets to A's mapped address. Because both NATs have existing outbound mappings, and because the packets appear to be "replies" to those mappings, they pass through.
Step 5: Server C is no longer needed. A and B communicate directly, peer-to-peer.
I documented this technique in a paper dated June 3, 2002, published at ecip.com/fwdoc.htm. The title was simple: "Method of passing bi-directional data between two firewalls." In that document, I noted that I had "tested this on FreeBSD's NAT and Linux's IP Masquerading in the previous century"—meaning before the year 2000.
RFC 3489: Nine Months Later
In March 2003—nine months after I published my paper—the IETF released RFC 3489, titled "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)." This became the foundational standard for NAT traversal, later updated as RFC 5389, and forms the basis for WebRTC's ICE (Interactive Connectivity Establishment) protocol.
When I read RFC 3489, the similarities were impossible to ignore. The core mechanism was identical to what I had described. But the RFC went further—it formalized the technique into a complete protocol specification with message formats, NAT classification systems, and security considerations.
Let me be clear about what I'm claiming and what I'm not. I'm not claiming that I invented every aspect of STUN. The RFC authors—Jonathan Rosenberg, Joel Weinberger, Christian Huitema, and Rohan Mahy—did significant work to create a complete, implementable standard. They added NAT type classification, formal message encoding, security mechanisms, and operational procedures.
What I am claiming is that the fundamental insight—the core technique that makes the whole thing work—was something I had already discovered, implemented, and published before the RFC existed.
Side-by-Side Comparison
The language and concepts between my 2002 paper and RFC 3489 are remarkably parallel:
The Evidence Trail
The Internet Archive's Wayback Machine provides independent, third-party timestamped evidence of when my document existed online. The archive shows 35 captures of my paper at ecip.com/fwdoc.htm, with the first capture dated May 8, 2004. While this is after the RFC was published, it confirms the document existed online and was being crawled by that date.
More importantly, the document itself is dated June 3, 2002, and contains the phrase "in the previous century"—referring to my testing on FreeBSD and Linux NAT implementations before the year 2000. This internal evidence demonstrates the technique was not only documented but implemented years before the RFC.
My Slashdot comment from December 15, 2006 is also archived, showing that I publicly claimed priority on this technique immediately when it became news. I wasn't retroactively constructing a narrative—I was pointing to documentation that already existed.
Timeline
What the RFC Added
To be fair to the RFC authors, they did substantial work beyond what I documented. RFC 3489 includes:
NAT Type Classification: A formal taxonomy of NAT behaviors (Full Cone, Restricted Cone, Port Restricted Cone, Symmetric) with detection algorithms to determine which type you're behind.
Wire Protocol Specification: Complete message formats, TLV-encoded attributes, transaction IDs, port assignments, and retransmission timers.
Security Mechanisms: Shared secret exchange over TLS, message integrity via HMAC-SHA1, and detailed attack analysis.
Binding Lifetime Discovery: Procedures for determining how long NAT bindings persist, crucial for keepalive intervals.
These are real contributions. The RFC authors turned a concept into a deployable standard. But the concept itself—the fundamental insight that makes everything else possible—was not new. It was documented in my paper nine months earlier, and implemented in my systems years before that.
Why This Matters
You might ask why I care about establishing priority for a technique that's now over two decades old. There are several reasons.
First, there's simple historical accuracy. The story of how NAT traversal was developed matters. It didn't spring fully formed from an IETF working group. It emerged from practitioners solving real problems in the field—people like me who were trying to make video work over an Internet that was never designed for it.
Second, there's a pattern here that I've seen repeatedly in my career. Ideas developed by independent engineers and small companies get absorbed into standards and products without attribution. The people who did the original work are forgotten, while the companies and standards bodies that formalized (and sometimes patented) the ideas get the credit.
Third, and most frustratingly, search engines—particularly Google—don't surface my early work. When people search for the history of NAT traversal or hole punching, they find the RFCs and the companies that built products on those standards. They don't find the engineers who figured it out first.
WebRTC now powers video calls for billions of people. Every Zoom call, Google Meet, Discord voice chat, and countless other applications rely on the NAT traversal techniques that STUN and ICE provide. The fundamental insight that makes all of this work—that you can use a third-party server to discover mapped addresses and then communicate directly—is something I documented in 2002 and implemented even earlier.
I'm not asking for royalties or recognition from standards bodies. I'm simply asking for the historical record to be accurate. I was there. I figured this out. I wrote it down. And now I'm telling the story.
Primary Sources
My 2002 Paper: http://www.ecip.com/fwdoc.htm
Wayback Machine Archive: https://web.archive.org/web/*/http://www.ecip.com/fwdoc.htm
Slashdot Discussion (December 2006): https://slashdot.org/story/06/12/15/191205/how-skype-punches-holes-in-firewalls
RFC 3489: https://www.rfc-editor.org/rfc/rfc3489
Livecam Project History: https://www.dnull.com/livecam.html
— John L. Sokol, 2025
Friday, November 28, 2025
I Invented NAT Hole Punching Before It Had a Name
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment