RFC 5128
State of Peer-to-Peer (P2P) Communication across Network Address Translators (NATs)
Part 1 of 8 🎀
RFC 5128 🦋 State of Peer-to-Peer (P2P) Communication across Network Address Translators (NATs) ✨
Okay bestie, let's get the title block sorted first 💅
- Authors: P. Srisuresh (Kazeon Systems), B. Ford (M.I.T.), and D. Kegel (kegel.com) 👑
- Working group: Network Working Group
- Category: Informational
- Date: March 2008
- Obsoletes / Updates: the header doesn't list anything this one obsoletes or updates, so there's nothing to report there 🙈
Status of This Memo 🌸
Quick vibe check: this memo gives information to the Internet community. It does not specify an Internet standard of any kind, so don't treat it as one 💜 And distribution is unlimited, so share away 🫶
Abstract ✨
So this memo is basically a catalogue of the methods applications use to set up direct communication when Network Address Translators (NATs) are in the way, as of right now 🧚 It's mostly descriptive, BUT the Security Considerations section has some purely advisory recommendations about how to handle security holes that applications could accidentally create when they use these methods. It covers NAT traversal for both TCP-based and UDP-based applications 🔥 And to be clear, this memo is not an endorsement of any of the methods. It's just an attempt to write them down in one place 📝
Table of Contents 🍓
1. Introduction and Scope ..........................................3
2. Terminology and Conventions Used ................................4
2.1. Endpoint ...................................................5
2.2. Endpoint Mapping ...........................................5
2.3. Endpoint-Independent Mapping ...............................5
2.4. Endpoint-Dependent Mapping .................................5
2.5. Endpoint-Independent Filtering .............................6
2.6. Endpoint-Dependent Filtering ...............................6
2.7. P2P Application ............................................7
2.8. NAT-Friendly P2P Application ...............................7
2.9. Endpoint-Independent Mapping NAT (EIM-NAT) .................7
2.10. Hairpinning ...............................................7
3. Techniques Used by P2P Applications to Traverse NATs ............7
3.1. Relaying ...................................................8
3.2. Connection Reversal ........................................9
3.3. UDP Hole Punching .........................................11
3.3.1. Peers behind Different NATs ........................12
3.3.2. Peers behind the Same NAT ..........................14
3.3.3. Peers Separated by Multiple NATs ...................16
3.4. TCP Hole Punching .........................................18
3.5. UDP Port Number Prediction ................................19
3.6. TCP Port Number Prediction ................................21
4. Recent Work on NAT Traversal ...................................22
5. Summary of Observations ........................................23
5.1. TCP/UDP Hole Punching .....................................23
5.2. NATs Employing Endpoint-Dependent Mapping .................23
5.3. Peer Discovery ............................................24
5.4. Hairpinning ...............................................24
6. Security Considerations ........................................24
6.1. Lack of Authentication Can Cause Connection Hijacking .....24
6.2. Denial-of-Service Attacks .................................25
6.3. Man-in-the-Middle Attacks .................................26
6.4. Security Impact from EIM-NAT Devices ......................26
7. Acknowledgments ................................................27
8. References .....................................................27
8.1. Normative References ......................................27
8.2. Informative References ....................................271. Introduction and Scope 💖
Okay so the Internet is literally everywhere now, and NATs are everywhere with it 🌈 There are tons of NAT devices and tons of network layouts that use them, and the asymmetric addressing and connectivity they set up have created real problems for peer-to-peer (P2P) apps and protocols. Think teleconferencing and multiplayer online games 🎮 And ngl, these issues are likely to stick around even in the IPv6 world 💀
During the move to IPv6, some form of NAT may be required so IPv4-only nodes can talk to IPv6-only nodes [NAT-PT], though the right protocols and guidelines for that kind of NAT are still unresolved [NAT-PT-HIST]. Even a future "pure IPv6 world" may still have firewalls that filter the way NATs do, just without the address translation [V6-CPE-SEC]. That filtering gets in the way of P2P apps, so IPv6 apps using the NAT traversal techniques in this document may also work with firewalls that filter similarly to NATs ✨
Now the vibe of today's NATs: they were built mostly around the client/server model, where fairly anonymous client machines inside a private network start connections to public servers that have stable IP addresses and DNS names 🦋 NAT devices along the way hand out dynamic addresses to those clients. The "illusion" of anonymity (private IP addresses) and inaccessibility of hosts behind a NAT is totally fine for things like web browsers, which only ever start outgoing connections. People sometimes see that illusion as a privacy perk. As noted in Section 2.2 of [RFC4941], that perceived privacy may be illusory in a majority of cases using Small-Office-Home-Office (SOHO) NATs 🙈
In the peer-to-peer model, hosts that would normally be "clients" don't just start sessions with peers, they also accept sessions that peers start 🔥 The initiator and the responder might be behind different NAT devices, and neither endpoint has a permanent IP address or any other form of public network presence. For example, a common online game setup has every participating host contact a publicly addressable rendezvous server to register itself and find peer hosts. After that chat with the rendezvous server, the hosts set up direct connections with each other for fast, efficient sharing of updates during gameplay 🎮 A file sharing app works similarly: it might ping a well-known rendezvous server for resource discovery or searching, then make direct connections with peers for the actual data transfer 📦 Here's the catch: hosts behind a NAT device normally have no permanently visible public ports on the Internet that incoming TCP or UDP connections from other peers can reach, and that's what makes P2P connections so tricky 😭 RFC 3235 [NAT-APPL] briefly covers this issue.
NAT traversal strategies that involve explicit signaling between applications and NAT devices are out of scope here. That includes [NAT-PMP], [NSIS-NSLP], [SOCKS], [RSIP], [MIDCOM], and [UPNP]. If those are available, they're a complement to the techniques in this document. [UNSAF] is in scope 👑
In this document we summarize the currently known methods apps use to work around NAT devices without directly changing the NAT devices themselves 🧚 The techniques described predate the BEHAVE documents ([BEH-UDP], [BEH-TCP], and [BEH-ICMP]). The scope is limited to describing currently known techniques for setting up 2-way communication between the endpoints of an application. Stuff like timeouts, RST processing, keepalives, and so forth, which concern a session that's already running, is out of scope 💅 The scope is also limited to techniques for TCP-based and UDP-based applications. This document is not trying to solve NAT traversal for applications in general [BEH-APP], or for one specific class of applications [ICE]. Not its job, bestie 🫶
2. Terminology and Conventions Used 🎀
Okay, the examples. This document uses the IP addresses 192.0.2.1, 192.0.2.128, and 192.0.2.254 as example public IP addresses [RFC3330]. Yes, they're all in the same /24, but that's just a limitation of the example addresses available in [RFC3330]. In real life they'd be on different networks 🌸 For ports: all clients use ports in the range of 1-2000, servers use ports in the range of 20000-21000, and NAT devices use ports 30000 and above for endpoint mapping 🍓
Readers are urged to check out [NAT-TERM] for NAT taxonomy and terminology 📚 Unless a NAT type is written in front of it or it's explicitly said otherwise, the term NAT used throughout this document refers to Traditional NAT [NAT-TRAD]. Traditional NAT comes in two flavours, Basic NAT and Network Address Port Translator (NAPT). Of those, NAPT is by far the most commonly deployed 💖 NAPT lets multiple private hosts share a single public IP address at the same time.
Here's a question that matters a lot for P2P apps: how does the NAT behave when an internal host starts multiple simultaneous sessions from one single endpoint (private IP, private port) to multiple distinct endpoints on the external network? 🧐
[STUN] further sorts NAT implementations into "Full Cone", "Restricted Cone", "Port Restricted Cone", and "Symmetric". Honestly, that terminology has caused a lot of confusion 😭 So this document adapts terminology from [BEH-UDP] to tell NAT implementations apart. Here are the terms used throughout the document.
2.1. Endpoint ✨
An endpoint is a session-specific tuple on an end host. An endpoint may be represented differently for each IP protocol. For example, a UDP or TCP session endpoint is represented as a tuple of (IP address, UDP/TCP port) 🦋
2.2. Endpoint Mapping 🌈
When a host in a private realm starts an outgoing session to a host in the public realm through a NAT device, the NAT device assigns a public endpoint to translate the private endpoint. That way, response packets from the external host can be received by the NAT, translated, and forwarded to the private endpoint. This assignment, translating a private endpoint to a public endpoint and back again, is called Endpoint Mapping. The NAT uses Endpoint Mapping to do translation for the duration of the session 🔥
2.3. Endpoint-Independent Mapping 💜
"Endpoint-Independent Mapping" is defined in [BEH-UDP] as follows:
The NAT reuses the port mapping for subsequent packets sent from
the same internal IP address and port (X:x) to any external IP
address and port.(part 2 coming up next, don't go anywhere 💅🦋)
2.4. Endpoint-Dependent Mapping
okay so "Endpoint-Dependent Mapping" is basically the combo of two behaviours from [BEH-UDP] 🦋: "Address-Dependent Mapping" and "Address and Port-Dependent Mapping."
Address-Dependent Mapping 🌸: the NAT reuses the same port mapping for later packets that go from the same internal IP address and port (X:x) to the same external IP address, no matter which external port it's going to.
Address and Port-Dependent Mapping ✨: the NAT reuses the port mapping for later packets from that same internal IP address and port (X:x), but only when they go to the same external IP address and port, and only while the mapping is still active.
2.5. Endpoint-Independent Filtering
"Endpoint-Independent Filtering" is defined in [BEH-UDP] and it's giving very open energy 🌈. The NAT only filters out packets that aren't aimed at the internal address and port X:x, and it doesn't care what the external IP address and port source (Z:z) is. Any packets aimed at X:x get forwarded. So basically, if the internal side sends packets out to any external IP address, that's enough to let packets come back in to the internal endpoint 💅.
A NAT device using both "Endpoint-Independent Mapping" and "Endpoint-Independent Filtering" will accept incoming traffic on a mapped public port from ANY external endpoint on the public network. Wild, right? 😭
2.6. Endpoint-Dependent Filtering
"Endpoint-Dependent Filtering" is the combo of "Address-Dependent Filtering" and "Address and Port-Dependent Filtering," both from [BEH-UDP] 🎀.
Address-Dependent Filtering 💜: the NAT filters out packets that aren't aimed at the internal address X:x. On top of that, it also filters out packets coming from Y:y to the internal endpoint X:x if X:x hasn't sent anything to Y:any earlier (no matter what port Y uses). Put simply, to receive packets from a particular external endpoint, the internal endpoint has to send packets to that endpoint's IP address first.
Address and Port-Dependent Filtering 🧚: the NAT filters out packets that aren't aimed at the internal address X:x. It also filters out packets from Y:y to X:x if X:x hasn't already sent packets to Y:y. So to receive from a specific external endpoint, the internal endpoint has to send to that endpoint's IP address and port first.
A NAT device using "Endpoint-Dependent Filtering" will only accept incoming traffic on a mapped public port from a restricted set of external endpoints on the public network 🔒.
2.7. P2P Application
A P2P application is an application that uses the same endpoint to start outgoing sessions to peering hosts and also to accept incoming sessions from those peering hosts 🍓. A P2P application may use multiple endpoints for its peer-to-peer communication.
2.8. NAT-Friendly P2P Application
A NAT-friendly P2P application is a P2P application built to keep working well even when the peering nodes are sitting in different IP address realms, with one or more NATs in between 🫶.
One popular way P2P apps set up peering sessions and stay NAT-friendly is by using a publicly addressable rendezvous server for registration and peer discovery. Very smart, very iconic 👑.
2.9. Endpoint-Independent Mapping NAT (EIM-NAT)
An Endpoint-Independent Mapping NAT (EIM-NAT, for short) is a NAT device that uses Endpoint-Independent Mapping 🌸. An EIM-NAT can have any type of filtering behaviour at all. BEHAVE-compliant NAT devices are good examples of EIM-NATs ✨. A NAT device using Address-Dependent Mapping is an example of a NAT device that is not an EIM-NAT 🙈.
2.10. Hairpinning
Hairpinning is defined in [BEH-UDP] like this 💀: if two hosts (called X1 and X2) are behind the same NAT and exchanging traffic, the NAT may allocate an outside address for X2, called X2':x2'. If X1 sends traffic to X2':x2', the traffic goes to the NAT, which must relay it from X1 to X2. That's the hairpinning move, and it's giving loop-de-loop 🌀.
Not all NATs currently out in the wild support hairpinning, so don't assume it's there 🥺.
3. Techniques Used by P2P Applications to Traverse NATs ✨
This section goes through, in detail, the techniques we currently know about for doing peer-to-peer communication over existing NAT devices. It's written from the point of view of the application or protocol designer, so grab your snacks 🍿.
3.1. Relaying
The most reliable (but least efficient) way to do peer-to-peer communication when a NAT device is in the picture is to make the peer-to-peer traffic look to the network like plain client/server communication, using relaying 🫠. Check out figure 1. Two client hosts, A and B, have each started TCP or UDP connections to a well-known rendezvous server S. The Rendezvous Server S has a publicly addressable IP address and is used for registration, discovery, and relay. Hosts behind NATs register with the server, and peer hosts can find those hosts and relay all end-to-end messages through the server 💖. The clients live on separate private networks, and their NAT devices stop either client from starting a connection directly to the other one 🚧.
Registry, Discovery
Combined with Relay
Server S
192.0.2.128:20001
|
+----------------------------+----------------------------+
| ^ Registry/ ^ ^ Registry/ ^ |
| | Relay-Req Session(A-S) | | Relay-Req Session(B-S) | |
| | 192.0.2.128:20001 | | 192.0.2.128:20001 | |
| | 192.0.2.1:62000 | | 192.0.2.254:31000 | |
| |
+--------------+ +--------------+
| 192.0.2.1 | | 192.0.2.254 |
| | | |
| NAT A | | NAT B |
+--------------+ +--------------+
| |
| ^ Registry/ ^ ^ Registry/ ^ |
| | Relay-Req Session(A-S) | | Relay-Req Session(B-S) | |
| | 192.0.2.128:20001 | | 192.0.2.128:20001 | |
| | 10.0.0.1:1234 | | 10.1.1.3:1234 | |
| |
Client A Client B
10.0.0.1:1234 10.1.1.3:1234
Figure 1: Use of a Relay Server to communicate with peersInstead of trying a direct connection, the two clients can just use server S to relay messages between them 📨. For example, to send a message to client B, client A simply sends it to server S over its already established client/server connection, and then server S forwards it on to client B over its existing client/server connection with B. Easy peasy 🍭.
This method has the big advantage that it will always work as long as both clients can reach the server 🏆. The NAT device along the way is not required to be an EIM-NAT, which is so nice. The obvious downsides of relaying are that it eats up the server's processing power and network bandwidth, and the communication latency between the peering clients is likely to go up, even if the server has plenty of I/O bandwidth and sits in a good spot topology-wise 🐢. The TURN protocol [TURN] defines a way to do application-agnostic, session-oriented packet relay in a relatively secure fashion 🔐, so that's a glow-up option to look into 🌟.
3.2. Connection Reversal 🔄✨
okay so connection reversal is a trick that only works when ONE of the peers is behind a NAT and the other one is not 🫶 Picture figure 2: Client A is stuck behind a NAT, but client B has a publicly addressable IP address. There's also Rendezvous Server S, which has its own publicly addressable IP and is basically the matchmaker 💅 Hosts behind a NAT register their endpoints with the server, and peer hosts use the server to discover those endpoints. Iconic teamwork 👑
Registry and Discovery
Server S
192.0.2.128:20001
|
+----------------------------+----------------------------+
| ^ Registry Session(A-S) ^ ^ Registry Session(B-S) ^ |
| | 192.0.2.128:20001 | | 192.0.2.128:20001 | |
| | 192.0.2.1:62000 | | 192.0.2.254:1234 | |
| |
| ^ P2P Session (A-B) ^ | P2P Session (B-A) | |
| | 192.0.2.254:1234 | | 192.0.2.1:62000 | |
| | 192.0.2.1:62000 | v 192.0.2.254:1234 v |
| |
+--------------+ |
| 192.0.2.1 | |
| | |
| NAT A | |
+--------------+ |
| |
| ^ Registry Session(A-S) ^ |
| | 192.0.2.128:20001 | |
| | 10.0.0.1:1234 | |
| |
| ^ P2P Session (A-B) ^ |
| | 192.0.2.254:1234 | |
| | 10.0.0.1:1234 | |
| |
Private Client A Public Client B
10.0.0.1:1234 192.0.2.254:1234
Figure 2: Connection reversal using Rendezvous serverSo, Client A has the private IP 10.0.0.1, and its app is using TCP port 1234 🎀 A has already connected to server S at 192.0.2.128 on port 20001. NAT A grabbed TCP port 62000 on its own public IP 192.0.2.1 to be the temporary public address for A's session with S, which means server S thinks client A lives at 192.0.2.1 port 62000 🧚 Client B, meanwhile, has its own permanent IP, 192.0.2.254, and its app is accepting TCP connections on port 1234 ⭐
Now, let's say client B wants a direct session with client A 💖 B could try the address A thinks it has, 10.0.0.1:1234, or the address S saw for A, 192.0.2.1:62000. Either way, it fails 💀 The first one is dead on arrival because traffic to 10.0.0.1 just gets dropped, since that's not a publicly routable IP. The second one is sad too: the TCP SYN from B shows up at NAT A aimed at port 62000, but NAT A rejects it because only outgoing connections are allowed 🙅♀️
After the direct attempt flops, client B can ask server S to pass along a request telling client A to start a "reversed" connection to client B 🦋 Client A gets the relayed request through S and opens a TCP connection to B at B's public IP and port number. NAT A lets it through because the connection starts inside the firewall, and client B can take the call because it isn't behind a NAT 🌈
Tons of current peer-to-peer apps use this trick 🔥 The big catch, obviously, is that it only works while just one of the peers is behind a NAT. If the NAT is EIM-NAT, the public client can ask the external server S for the exact public endpoint to expect the Client-A-originated connection from, and then only allow connections from those endpoints 💅 If the NAT is EIM-NAT, the public client can once again contact the external server S to find the specific public endpoint where connections from client A will come from, and allow connections from just that one endpoint 🫶 If the NAT is not EIM-NAT, though, the public client has no way of knowing which specific public endpoint to expect connections from client A on 😭 And in the increasingly common situation where both peers are behind NATs, Connection Reversal just flat-out fails 💀 It is NOT a general solution to the peer-to-peer connection problem, bestie 🙈 If neither a "forward" nor a "reverse" connection can be established, apps usually fall back to something else, like relaying 🍓
3.3. UDP Hole Punching 🕳️💖
UDP hole punching is built on the properties of EIM-NATs 🦋 It lets well-designed peer-to-peer apps "punch holes" through the NAT device(s) along the way, so they can talk directly even when both hosts are behind NATs. The catch: if one host is behind a NAT that is NOT EIM-NAT, the peer can't predictably figure out the mapped endpoint to start a connection to 😵 Plus, the app on that non-EIM-NAT host couldn't reuse an existing endpoint mapping to talk to different external destinations, so the hole punching would fail 💔
This technique got a quick mention in Section 5.1 of RFC 3027 [NAT-PROT], was first described in [KEGEL], and has been used in some newer protocols [TEREDO, ICE] ✨ If you want the scoop on "TCP hole punching," check out Section 3.4 🧚
We're going to look at two specific scenarios and how apps are designed to handle both gracefully 👑 In the first one, which is the common case, two clients who want to talk directly are each behind a different NAT. In the second one, the two clients are actually behind the same NAT, but they might not know that they are 🙈🌸
3.3.1. Peers behind Different NATs ✨
okay so picture this bestie 🦋 Clients A and B both have private IP addresses and they're each chilling behind a different NAT device (see figure 3). Rendezvous Server S has a publicly addressable IP address and it's the MVP for registration, discovery, and limited relay. Hosts behind a NAT register their public endpoints with the server, and peer hosts find those public endpoints through the server too. Unlike in Section 3.1, the peers only use the server to relay just connection initiation control messages, not every end-to-end message. 💅
The peer-to-peer app on clients A and B uses UDP port 1234, and the rendezvous server S uses UDP port 20001. A and B have each started a UDP session with server S. So NAT A gave A's session with S its own public UDP port 62000, and NAT B gave B's session with S port 31000. 🎀
Registry and Discovery Combined
with Limited Relay
Server S
192.0.2.128:20001
|
+----------------------------+----------------------------+
| ^ Registry Session(A-S) ^ ^ Registry Session(B-S) ^ |
| | 192.0.2.128:20001 | | 192.0.2.128:20001 | |
| | 192.0.2.1:62000 | | 192.0.2.254:31000 | |
| |
| ^ P2P Session (A-B) ^ ^ P2P Session (B-A) ^ |
| | 192.0.2.254:31000 | | 192.0.2.1:62000 | |
| | 192.0.2.1:62000 | | 192.0.2.254:31000 | |
| |
+--------------+ +--------------+
| 192.0.2.1 | | 192.0.2.254 |
| | | |
| EIM-NAT A | | EIM-NAT B |
+--------------+ +--------------+
| |
| ^ Registry Session(A-S) ^ ^ Registry Session(B-S) ^ |
| | 192.0.2.128:20001 | | 192.0.2.128:20001 | |
| | 10.0.0.1:1234 | | 10.1.1.3:1234 | |
| |
| ^ P2P Session (A-B) ^ ^ P2P Session (B-A) ^ |
| | 192.0.2.254:31000 | | 192.0.2.1:62000 | |
| | 10.0.0.1:1234 | | 10.1.1.3:1234 | |
| |
Client A Client B
10.0.0.1:1234 10.1.1.3:1234
Figure 3: UDP Hole Punching to set up direct connectivityNow say client A wants a UDP session directly with client B. If A just starts blasting UDP messages at B's public endpoint 192.0.2.254:31000, NAT B will typically toss them out (unless it's using Endpoint-Independent Filtering) 🙈. Why? Because the source address and port don't match S, which is who the original outgoing session was set up with. Same deal the other way round: if B just starts sending to A's public endpoint, NAT A will typically discard those messages too.
So here's the trick 🧚. A starts sending UDP messages to B's public endpoint and at the same time relays a request through server S asking B to start sending UDP messages to A's public endpoint. A's outgoing messages to B's public endpoint (192.0.2.254:31000) make EIM-NAT A open up a brand new communication session between A's private endpoint and B's public endpoint. At the same moment, B's messages to A's public endpoint (192.0.2.1:62000) make EIM-NAT B open up a new session between B's private endpoint and A's public endpoint. Once both new UDP sessions exist in each direction, clients A and B can talk directly without the server S doing any more work. Server S ends up acting like an "introduction" server for the peers, which is honestly iconic behaviour from a server 👑
The UDP hole punching technique has some really useful properties 🌈. Once a direct peer-to-peer UDP connection exists between two clients behind NAT devices, either party on that connection can take over as the "introducer" and help the other party set up peer-to-peer connections with more peers. That takes load off the original introduction server S. The app also doesn't need to figure out what kind of NAT device it's behind, because the procedure above sets up peer-to-peer channels just as well if one or both clients aren't behind a NAT device at all. And it even works automatically with multiple NATs, where one or both clients are separated from the public Internet by two or more levels of address translation. ⭐
3.3.2. Peers behind the Same NAT 🌸
Now let's look at the case where the two clients (probably without realising it 💀) happen to live behind the same EIM-NAT, so they're in the same private IP address space, as in figure 4. A well-known Rendezvous Server S has a publicly addressable IP address and is used for registration, discovery, and limited relay. Hosts behind the NAT register with the server. Peer hosts discover hosts behind the NAT using the server and relay messages through it. Unlike in Section 3.1, peer hosts use the server to relay just control messages, instead of all end-to-end messages.
Client A has established a UDP session with server S, and the common EIM-NAT assigned it public port number 62000. Client B has similarly established a session with S, and the EIM-NAT assigned it public port number 62001. 🍓
Registry and Discovery Combined
with Limited Relay
Server S
192.0.2.128:20001
|
^ Registry Session(A-S) ^ | ^ Registry Session(B-S) ^
| 192.0.2.128:20001 | | | 192.0.2.128:20001 |
| 192.0.2.1:62000 | | | 192.0.2.1:62001 |
|
+--------------+
| 192.0.2.1 |
| |
| EIM-NAT |
+--------------+
|
+-----------------------------+----------------------------+
| ^ Registry Session(A-S) ^ ^ Registry Session(B-S) ^ |
| | 192.0.2.128:20001 | | 192.0.2.128:20001 | |
| | 10.0.0.1:1234 | | 10.1.1.3:1234 | |
| |
| ^ P2P Session-try1(A-B) ^ ^ P2P Session-try1(B-A) ^ |
| | 192.0.2.1:62001 | | 192.0.2.1:62000 | |
| | 10.0.0.1:1234 | | 10.1.1.3:1234 | |
| |
| ^ P2P Session-try2(A-B) ^ ^ P2P Session-try2(B-A) ^ |
| | 10.1.1.3:1234 | | 10.0.0.1:1234 | |
| | 10.0.0.1:1234 | | 10.1.1.3:1234 | |
| |
Client A Client B
10.0.0.1:1234 10.1.1.3:1234
Figure 4: Use of local and public endpoints to communicate with peersSuppose A and B use the UDP hole punching technique we just went over to set up a communication channel, with server S as the introducer. Then A and B will learn each other's public endpoints as observed by server S, and start sending each other messages at those public endpoints. The two clients can keep talking this way as long as the NAT lets hosts on the internal network open translated UDP sessions with other internal hosts, and not just with external hosts. This situation is called "Hairpinning", because packets that arrive at the NAT from the private network get translated and then looped straight back into the private network, instead of being passed through to the public network. 🔁
Let's walk through P2P session-try1 above as an example 🎀. When A sends a UDP packet to B's public endpoint, the packet starts out with a source endpoint of 10.0.0.1:1234 and a destination endpoint of 192.0.2.1:62001. The NAT receives it, translates it to have a source endpoint of 192.0.2.1:62000 and a destination endpoint of 10.1.1.3:1234, and then forwards it on to B.
Even if the NAT device supports hairpinning, that translate-and-forward step is clearly unnecessary here. It adds latency to the chat between A and B, and it burdens the NAT for no reason 😭. The fix is pretty straightforward, so here's how it works. 🧠
When A and B first swap address info through the Rendezvous server S, they include their own IP addresses and port numbers as "observed" by themselves, as well as their public endpoints as observed by S. The clients then simultaneously start sending packets to each other at each of the alternative addresses they know about, and they use the first address that leads to successful communication. If the two clients are behind the same NAT, as in figure 4 above, then the packets aimed at their private endpoints (tried through P2P session-try2) are likely to arrive first, which gives a direct communication channel that doesn't involve the NAT at all ✨. If the two clients are behind different NATs, then packets aimed at their private endpoints will fail to reach each other entirely, but the clients will hopefully connect using their respective public endpoints instead. It's really important that these packets get authenticated in some way, though. In the different-NAT case it's totally possible for A's messages aimed at B's private endpoint to reach some other, unrelated node on A's private network (or the other way round) 🙀.
The [ICE] protocol uses this technique really effectively. Multiple candidate endpoints, both private and public, get shared between the peering end hosts during an offer/answer exchange. The endpoints that offer the most efficient end-to-end connection(s) are eventually picked for the actual end-to-end data transfer 👑
3.3.3. Peers Separated by Multiple NATs ✨
okay so this one is a whole topology puzzle 🧩 In some setups with multiple NAT devices, two clients can't set up an "optimal" P2P route between them unless they know the topology. Check out figure 5 🦋
Registry and Discovery Combined
with Limited Relay
Server S
192.0.2.128:20001
|
^ Registry Session(A-S) ^ | ^ Registry Session(B-S) ^
| 192.0.2.128:20001 | | | 192.0.2.128:20001 |
| 192.0.2.1:62000 | | | 192.0.2.1:62001 |
|
+--------------+
| 192.0.2.1 |
| |
| EIM-NAT X |
| (Supporting |
| Hairpinning) |
+--------------+
|
+----------------------------+----------------------------+
| ^ Registry Session(A-S) ^ ^ Registry Session(B-S) ^ |
| | 192.0.2.128:20001 | | 192.0.2.128:20001 | |
| | 192.168.1.1:30000 | | 192.168.1.2:31000 | |
| |
| ^ P2P Session (A-B) ^ ^ P2P Session (B-A) ^ |
| | 192.0.2.1:62001 | | 192.0.2.1:62000 | |
| | 192.168.1.1:30000 | | 192.168.1.2:31000 | |
| |
+--------------+ +--------------+
| 192.168.1.1 | | 192.168.1.2 |
| | | |
| EIM-NAT A | | EIM-NAT B |
+--------------+ +--------------+
| |
| ^ Registry Session(A-S) ^ ^ Registry Session(B-S) ^ |
| | 192.0.2.128:20001 | | 192.0.2.128:20001 | |
| | 10.0.0.1:1234 | | 10.1.1.3:1234 | |
| |
| ^ P2P Session (A-B) ^ ^ P2P Session (B-A) ^ |
| | 192.0.2.1:62001 | | 192.0.2.1:62000 | |
| | 10.0.0.1:1234 | | 10.1.1.3:1234 | |
| |
Client A Client B
10.0.0.1:1234 10.1.1.3:1234
Figure 5: Use of Hairpinning in setting up direct communicationSo the setup is this 💅 NAT X is an EIM-NAT run by a big ISP that squishes lots of customers onto a few public IPs. NAT A and NAT B are small consumer NAT gateways that two of the ISP's customers set up on their own, so their home networks fit onto the ISP-given addresses. Only server S and NAT X have globally routable IPs. The "public" addresses on NAT A and NAT B are actually private inside the ISP's realm, and the addresses of client A and client B are private inside the realms of NAT A and NAT B. Same as the last section, server S handles registration, discovery, and limited relay. Peers only use the server to relay connection initiation control messages, not every end-to-end message.
Now say clients A and B want a direct peer-to-peer UDP connection. The ideal move is for client A to send to client B's public address at NAT B, which is 192.168.1.2:31000 in the ISP's realm, and for client B to send to A's public address at NAT B, which is 192.168.1.1:30000. The problem is A and B have no way to learn those addresses, because server S only sees the "global" public endpoints of the clients, 192.0.2.1:62000 and 192.0.2.1:62001. Even if they somehow did learn them, there's no promise they'd work, because the addresses in the ISP's private realm could clash with random unrelated addresses in the clients' private realms 😭 So the clients have no choice but to use their global public endpoints as seen by S for P2P, and rely on NAT X to do hairpinning. Iconic? Kind of. Chaotic? Also yes 🌈
3.4. TCP Hole Punching 🦋
okay now we're on to TCP hole punching, which is for setting up a direct TCP connection between two nodes that are both behind EIM-NAT devices. Just like with UDP hole punching, it depends on EIM-NAT properties so well-designed P2P apps can "punch holes" through the NAT and connect directly, even when both hosts are behind NATs. People also call this technique "Simultaneous TCP Open" 🫶
Most TCP sessions start with one endpoint sending a SYN packet, and the other side replies with a SYN-ACK. It's allowed, though, for two endpoints to start a session by sending each other SYN packets at the same time, and each party then replies with its own separate ACK. That's the "Simultaneous TCP Open" technique, and you can find it in figure 6 of the original TCP specification ([TCP]). BUT ngl, "Simultaneous TCP Open" isn't implemented correctly on lots of systems, NAT devices included 💀
If a NAT device gets a TCP SYN from outside the private network trying to start an incoming connection, it usually rejects the attempt by either dropping the SYN or sending back a TCP RST (connection reset) packet. When there's a SYN timeout or a connection reset, the application endpoint keeps resending its SYN until the peer does the same from its end.
Now let's look at a NAT device that does support "Simultaneous TCP Open" sessions. When a SYN shows up with source and destination endpoints matching a TCP session the NAT thinks is already active, the NAT lets the packet through. Specifically, if the NAT recently saw and sent an outgoing SYN with the same address and port numbers, it counts the session as active and lets the incoming SYN in. So if clients A and B can each start an outgoing TCP connection to the other, timed so each client's outgoing SYN gets through its local NAT before either SYN reaches the opposite NAT, a working peer-to-peer TCP connection comes out of it 🎀
This technique isn't always reliable though, for the following reason(s) 🙈 If either node's SYN reaches the remote NAT too fast, before the peer has had a chance to send its own SYN, the remote NAT may drop that SYN or reject it with a RST. This could make the local NAT close the new NAT session right away, or start an end-of-session timeout (see Section 2.6 of [NAT-TERM]) so it closes the session once the timeout ends. Even when both peers keep retransmitting SYNs at the same time, some remote NAT devices might not let the incoming SYNs through if the NAT session is in an end-of-session timeout state. That can stop the TCP connection from ever getting established 😭
Here's the good news, though 🌸 In reality, the majority of NAT devices (more than 50%) support Endpoint-Independent Mapping and don't send ICMP errors or RSTs in reply to unsolicited incoming SYNs. Because of that, the Simultaneous TCP Open technique works across NAT devices for the majority of TCP connection attempts ([P2P-NAT], [TCP-CHARACT]). Main character energy for the win 👑
3.5. UDP Port Number Prediction 🔮
okay so there's a variant of the UDP hole punching trick that can still make peer-to-peer UDP sessions happen when some NATs are using Endpoint-Dependent Mapping 👀 people sometimes call it the "N+1" technique [BIDIR], and Takeda digs into it in detail in [SYM-STUN]. the idea is to watch how the NAT behaves and then try to predict which public port number it'll hand out to your next session. and it's honestly pretty predictable, bc most NATs assign mapping ports in sequence 🧠
check out figure 6. two clients, A and B, are each chilling behind their own NAT, and each one has a separate UDP connection going with rendezvous server S. S has a publicly addressable IP address and is used for registration and discovery. hosts behind a NAT register their endpoints with the server, and peer hosts use the server to find the endpoints of hosts behind NAT.
Registry and Discovery
Server S
192.0.2.128:20001
|
|
+----------------------------+----------------------------+
| ^ Registry Session(A-S) ^ ^ Registry Session(B-S) ^ |
| | 192.0.2.128:20001 | | 192.0.2.128:20001 | |
| | 192.0.2.1:62000 | | 192.0.2.254:31000 | |
| | |
| ^ P2P Session (A-B) ^ ^ P2P Session (B-A) ^ |
| | 192.0.2.254:31001 | | 192.0.2.1:62001 | |
| | 192.0.2.1:62001 | | 192.0.2.254:31001 | |
| |
+---------------------+ +--------------------+
| 192.0.2.1 | | 192.0.2.254 |
| | | |
| NAT A | | NAT B |
| (Endpoint-Dependent | | (Endpoint-Dependent|
| Mapping) | | Mapping) |
+---------------------+ +--------------------+
| |
| ^ Registry Session(A-S) ^ ^ Registry Session(B-S) ^ |
| | 192.0.2.128:20001 | | 192.0.2.128:20001 | |
| | 10.0.0.1:1234 | | 10.1.1.3:1234 | |
| |
| ^ P2P Session (A-B) ^ ^ P2P Session (B-A) ^ |
| | 192.0.2.254:31001 | | 192.0.2.1:62001 | |
| | 10.0.0.1:1234 | | 10.1.1.3:1234 | |
| |
Client A Client B
10.0.0.1:1234 10.1.1.3:1234
Figure 6: UDP Port Prediction to set up direct connectivityNAT A gave its UDP port 62000 to the A-S session, and NAT B gave its port 31000 to the B-S session. by chatting with S, A and B learn each other's public endpoints as S sees them ✨ then A starts sending UDP messages to port 31001 at address 192.0.2.254 (notice the +1!), and B simultaneously starts sending messages to port 62001 at address 192.0.2.1. if NATs A and B assign port numbers to new sessions sequentially, and not much time has passed since the A-S and B-S sessions started, then a working bidirectional channel between A and B should result 🤞 A's messages to B make NAT A open up a new session, and NAT A will (hopefully) give it public port 62001, bc 62001 comes right after the 62000 it already gave to the session between A and S. same energy for B: its messages to A make NAT B open a new session that it'll (hopefully) label with port 31001. if both clients guessed the port numbers each NAT assigns to the new sessions correctly, then a bidirectional UDP channel has been established 🦋
but there are SO many things that can go wrong 😭 if the predicted port at either NAT is already in use by an unrelated session, the NAT skips over that number and the connection attempt fails. if either NAT sometimes or always picks port numbers non-sequentially, the trick flops. and if a different client behind NAT A (or B, respectively) opens a new outgoing UDP connection to any external destination after A (B) sets up its connection with S but before A (B) sends its first message to B (A), that random client will "steal" the desired port number. rude 💀 so this trick is much less likely to work when either NAT involved is under load.
this trick also has to keep working even when one of the NATs is EIM-NAT, so an application would need to detect beforehand what kind of NAT is on each end and adjust its behavior to match. that adds complexity and makes the whole network more brittle 🫠
finally, port number prediction has very little chance of working if either client is behind two or more levels of NAT and the NAT closest to the client uses Endpoint-Dependent Mapping 🙈
3.6. TCP Port Number Prediction 🎯
this is a variant of the "TCP Hole Punching" technique for setting up direct peer-to-peer TCP sessions across NATs that use Address-Dependent Mapping.
ngl this one may be even more fragile and timing-sensitive than the UDP port number prediction trick from before 😩 first, predicting the public port a NAT will assign could be wrong. also, if either client's SYN reaches the opposite NAT device too quickly, the remote NAT device may reject that SYN with a RST packet. then the local NAT device closes the new session, and any future SYN retransmission attempts using the same port numbers are futile 💔
4. Recent Work on NAT Traversal 📚
[P2P-NAT] has a detailed discussion of the UDP and TCP hole punching techniques for NAT traversal 🧭 it also lists empirical results from running a test program, [NAT-CHECK], across a bunch of commercial NAT devices. the results show that UDP hole punching works widely, on more than 80% of the NAT devices, whereas TCP hole punching works on just over 60% of them. the results also show that TCP or UDP hairpinning isn't widely available on commercial NAT devices yet, since less than 25% of the devices passed the tests ([NAT-CHECK]) for Hairpinning. if you want more, [JENN-RESULT] and [SAIK-RESULT] have empirical test results for classifying publicly available NAT devices. [JENN-RESULT] classifies NATs using tests that span different IP protocols, and [SAIK-RESULT] focuses only on classifying NAT devices by their TCP behavioral characteristics 🤓
[TCP-CHARACT] and [NAT-BLASTER] both focus on TCP hole punching and explore and compare several alternative approaches 💅 [NAT-BLASTER] is the analytical one: it looks at different cases of observed NAT behavior and the ways applications might deal with them. [TCP-CHARACT] is more empirical, measuring how common the different types of NAT behavior relevant to TCP hole punching are. its big finding is that, using more sophisticated techniques than the ones in [P2P-NAT], up to 88% of currently deployed NATs can support TCP hole punching 🎉
[TEREDO] is a NAT traversal service that uses relay technology to connect IPv4 nodes behind NAT devices to IPv6 nodes that sit outside the NAT devices 🌈 it gets peer communication across NAT devices by tunneling packets over UDP, across the NAT device(s), to a relay node. Teredo relays act as Rendezvous servers, relaying traffic from private IPv4 nodes to nodes in the external realm and vice versa.
[ICE] is a NAT traversal protocol for setting up media sessions between peer nodes for a class of multimedia applications 🎀 [ICE] requires peering nodes to run the Simple Traversal of the UDP Protocol through NAT (STUN) protocol [STUN] on the same port number they use to terminate media session(s). applications that use signaling protocols like SIP ([SIP]) can embed the NAT traversal attributes for the media session inside the signaling sessions, and use an offer/answer style of exchange between peer nodes to set up end-to-end media session(s) across NAT devices. and [ICE-TCP] extends ICE to cover TCP-based media sessions 🧚
a bunch of online gaming and media-over-IP apps, including Instant Messaging apps, use the techniques in this document for peer-to-peer connection establishment 🎮 some apps use multiple distinct rendezvous servers for registration, discovery, and relay functions, for load balancing and other reasons. for example, the well-known media-over-IP app "Skype" uses a central public server for login and different public servers for the end-to-end relay function 🍓
5. Summary of Observations 📝
5.1. TCP/UDP Hole Punching 🕳️
TCP/UDP hole punching seems to be the most efficient existing method for setting up direct TCP/UDP peer-to-peer communication between two nodes that are both behind NATs 👑 it's been used with a wide variety of existing NATs. still, applications may need to be ready to fall back to simple relaying when direct communication can't be established.
the TCP/UDP hole punching technique has a catch: it only works when the traversing NAT is EIM-NAT 😬 when the NAT device along the way isn't EIM-NAT, the application can't reuse an endpoint mapping it already has for communication with different external destinations, and the technique would fail. the good news is that many of the NAT devices deployed on the Internet are EIM-NAT devices, which makes TCP/UDP hole punching broadly applicable [P2P-NAT]. but a substantial fraction of deployed NATs do use Endpoint-Dependent Mapping and don't support TCP/UDP hole punching, so that's a real limitation 💔
5.2. NATs Employing Endpoint-Dependent Mapping 🙃
NATs employing Endpoint-Dependent Mapping weren't a problem for client-server apps like Web browsers, which only ever need to start outgoing connections 🌸 but lately P2P apps like Instant Messaging and Voice-over-IP have been in wide use, and NATs employing Endpoint-Dependent Mapping aren't suitable for them. techniques like TCP/UDP hole punching won't work across those NAT devices 😭
5.3. Peer Discovery 🔍
application peers may be inside the same NAT domain or outside the NAT domain. so that all peers (inside or outside the NAT domain) can find the application endpoint, an application may choose to register its private endpoints in addition to its public endpoints with the rendezvous server 🫶
5.4. Hairpinning 🎀
okay so hairpinning is literally SO good for hosts stuck behind an EIM-NAT 🦋. It lets them talk to other hosts behind that very same NAT device by using their public, possibly translated, endpoints ✨. It's especially iconic on big-capacity NATs sitting at the first level of a multi-level NAT setup 👑. Like, remember Section 3.3.3? Hosts behind the same first-level NAT but different second-level NATs have no way to reach each other with TCP/UDP hole punching 😭, unless that first-level NAT supports hairpinning. And this is the case even when every NAT device in the deployment preserves endpoint identities 💀. Not me needing hairpinning to save the day 🫶.
6. Security Considerations 🔥
ngl this part is serious, so let's be real 💅. This document doesn't inherently create new security issues 🌸. BUT there can still be security risks in the techniques we just covered 🙈. This section is all about the risks applications could accidentally create while trying to support direct communication across NAT devices 🔐.
6.1. Lack of Authentication Can Cause Connection Hijacking 😈
Applications MUST use appropriate authentication mechanisms to protect their connections from accidental confusion with other connections, as well as from malicious connection hijacking or denial-of-service attacks 🚨. Like, apps have to deal with multiple distinct IP address domains, but they usually don't know the exact topology or admin policies behind those domains 🧩. So while they're trying to establish TCP/UDP hole-punched connections, their packets can frequently land on a totally different host than the one they were meant for 😭.
For example, a lot of consumer NAT devices run DHCP services that hand out site-local IP addresses from a particular range by default 🏠. Say a certain consumer NAT device hands out addresses starting at 192.168.1.100 by default. Most private home networks using that device will have a host at that address, and many of them will probably also have a host at 192.168.1.101 🥹. So if host A at 192.168.1.101 on one private network tries to connect via UDP hole punching with host B at 192.168.1.100 on a different private network, then host A sends discovery packets to 192.168.1.100 on its own local network, and host B sends discovery packets to 192.168.1.101 on its network 📦. Obviously these packets won't reach the intended machine, since the two hosts are on different private networks 🙃. BUT they're very likely to reach SOME machine on those respective networks at the standard UDP port numbers this app uses 😬. That can cause real confusion, especially if the app is also running on those other machines and doesn't properly authenticate its messages 💀.
This aliasing risk is present even without a malicious attacker 🫠. And if one endpoint, say host A, is actually malicious, then without proper authentication the attacker could make host B connect and interact in unintended ways with another host on its private network that has the same IP address as the attacker's (claimed) private address 👀. Hosts A and B probably found each other through a public rendezvous server S, which provides registration, discovery, and limited relay services 🧚. Neither S nor B has any way to verify A's reported private address 🤷♀️. So applications may be advised to treat any IP address they find suspicious as suspect until they've successfully established authenticated two-way communication 🔒✨.
6.2. Denial-of-Service Attacks 🌩️
Applications and the public servers that support them MUST protect themselves against denial-of-service attacks, and make sure they can't be used by an attacker to launch denial-of-service attacks against other targets 🛡️. To protect themselves, applications and servers MUST avoid taking any action that requires significant local processing or storage resources until authenticated two-way communication is established 🧠. And to avoid being used as a tool for denial-of-service attacks, applications and servers MUST minimize the amount and rate of traffic they send to any newly discovered IP address until authenticated two-way communication is established with the intended target 🚦.
For example, applications that register with a public rendezvous server can claim to have any private IP address, or maybe several 🎭. A well-connected host or group of hosts that can collectively attract a big flood of connection attempts (say, by offering popular content) could mount a denial-of-service attack on a target host C just by including C's IP address in the list of IP addresses it registers with the rendezvous server 😤. The rendezvous server has no way to verify those IP addresses, since they could well be legit private network addresses that other hosts use for network-local communication 🏡. So the application protocol MUST be designed to size- and rate-limit traffic sent to unverified IP addresses, to avoid the damage that such a concentration effect could cause 📉.
6.3. Man-in-the-Middle Attacks 🕵️♀️
Any network device on the path between a client and a public rendezvous server can pull off a variety of man-in-the-middle attacks by pretending to be a NAT 🎭. Like, suppose host A tries to register with rendezvous server S, but a network-snooping attacker can see that registration request 👁️. The attacker could then flood server S with requests identical to the client's original request, except with a modified source IP address, such as the attacker's own 😈. If the attacker convinces the server to register the client using the attacker's IP address, then the attacker becomes an active component on the path of all future traffic from the server AND other hosts to the original client 🚨. Even if the attacker could only originally snoop the path from the client to the server, that's still a huge win for them 💀.
The client can't protect itself from this attack by authenticating its source IP address to the rendezvous server 🙅♀️. Why? Because to be NAT-friendly, the application has to let intervening NATs change the source address silently 🔄. This appears to be an inherent security weakness of the NAT paradigm 😩. The only defense is for the client to authenticate and potentially encrypt the actual content of its communication using appropriate higher-level identities, so the interposed attacker can't take advantage of its position 🔐. Even if all application-level communication is authenticated and encrypted, though, this attack could still be used as a traffic analysis tool to observe who the client is talking to 👀🫣.
6.4. Security Impact from EIM-NAT Devices 🦋
Designing NAT devices to preserve endpoint identities does NOT weaken the security a NAT device provides 💖. For example, a NAT device using Endpoint-Independent Mapping and Endpoint-Dependent Filtering is no more "promiscuous" than a NAT device using Endpoint-Dependent Mapping and Endpoint-Dependent Filtering 🙌. Filtering incoming traffic aggressively with Endpoint-Dependent Filtering while using Endpoint-Independent Mapping lets a NAT device be friendly to applications without compromising the principle of rejecting unsolicited incoming traffic 🌈.
Endpoint-Independent Mapping could arguably make traffic leaving the NAT device more predictable, since it reveals the relationships between different TCP/UDP sessions and, by extension, the behavior of applications inside the enclave 🔍. That predictability could conceivably help an attacker exploit other network- or application-level vulnerabilities 😬. If a deployment's security requirements are so critical that subtle information channels are a concern, then maybe the NAT device should not have been configured to allow unrestricted outgoing TCP/UDP traffic in the first place 🧐. A NAT device configured to allow communication originating from specific applications at specific ports, or through tightly controlled application-level gateways, may meet the security requirements of those deployment scenarios 🏰✨.
7. Acknowledgments 💐
The authors want to thank Henrik Bergstrom, David Anderson, Christian Huitema, Dan Wing, Eric Rescorla, and the other BEHAVE work group members 🫶 for their valuable feedback on early versions of this document 💜. The authors also want to thank Francois Audet, Kaushik Biswas, Spencer Dawkins, Bruce Lowekamp, and Brian Stucker for agreeing to be technical reviewers for this document 🌟.
8. References 📚
8.1. Normative References
[NAT-TERM] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations", RFC
2663, August 1999.
[NAT-TRAD] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022,
January 2001.
[BEH-UDP] Audet, F., Ed., and C. Jennings, "Network Address
Translation (NAT) Behavioral Requirements for Unicast
UDP", BCP 127, RFC 4787, January 2007.8.2. Informative References 🦋
Okay bestie, these are the informative refs, the "for more tea, go read these" list 📚. Each one is a doc the RFC points to for extra context. Here they are, in full:
[BEH-APP] Ford, B., Srisuresh, P., and D. Kegel, "Application Design Guidelines for Traversal through Network Address Translators", Work in Progress, March 2007. 🧚
[BEH-ICMP] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT Behavioral Requirements for ICMP protocol", Work in Progress, February 2008. 💅
[BEH-TCP] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. Srisuresh, "NAT Behavioral Requirements for TCP", Work in Progress, April 2007. 🌸
[BIDIR] Peer-to-Peer Working Group, NAT/Firewall Working Committee, "Bidirectional Peer-to-Peer Communication with Interposing Firewalls and NATs", August 2001. http://www.peer-to-peerwg.org/tech/nat/ 🫶
[ICE] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Methodology for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", Work in Progress, October 2007. ✨
[ICE-TCP] Rosenberg, J., "TCP Candidates with Interactive Connectivity Establishment (ICE)", Work in Progress, July 2007. 🎀
[JENN-RESULT] Jennings, C., "NAT Classification Test Results", Work in Progress, July 2007. 📊
[KEGEL] Kegel, D., "NAT and Peer-to-Peer Networking", July 1999. http://www.alumni.caltech.edu/~dank/peer-nat.html 🍓
[MIDCOM] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and A. Rayhan, "Middlebox communication architecture and framework", RFC 3303, August 2002. 🌈
[NAT-APPL] Senie, D., "Network Address Translator (NAT)-Friendly Application Design Guidelines", RFC 3235, January 2002. 💜
[NAT-BLASTER] Biggadike, A., Ferullo, D., Wilson, G., and Perrig, A., "Establishing TCP Connections Between Hosts Behind NATs", ACM SIGCOMM ASIA Workshop, April 2005. 🔥
[NAT-CHECK] Ford, B., "NAT check Program" available online as http://midcom-p2p.sourceforge.net, February 2005. 🙈
[NAT-PMP] Cheshire, S., Krochmal, M., and K. Sekar, "NAT Port Mapping Protocol (NAT-PMP)", Work in Progress, October 2006. 👑
[NAT-PROT] Holdrege, M. and P. Srisuresh, "Protocol Complications with the IP Network Address Translator", RFC 3027, January 2001. ⭐
[NAT-PT] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - Protocol Translation (NAT-PT)", RFC 2766, February 2000. 🦋
[NAT-PT-HIST] Aoun, C. and E. Davies, "Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status", RFC 4966, July 2007. 💀
[NSIS-NSLP] Stiemerling, M., Tschofenig, H., Aoun, C., and E. Davies, "NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", Work in Progress, July 2007. 🫶
[P2P-NAT] Ford, B., Srisuresh, P., and Kegel, D., "Peer-to-Peer Communication Across Network Address Translators", Proceedings of the USENIX Annual Technical Conference (Anaheim, CA), April 2005. 🌸
[RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330, September 2002. 💅
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, September 2007. 🧚
[RSIP] Borella, M., Lo, J., Grabelsky, D., and G. Montenegro, "Realm Specific IP: Framework", RFC 3102, October 2001. 🎀
[SAIK-RESULT] Guha, Saikat, "NAT STUNT Results" available online as https://www.guha.cc/saikat/stunt-results.php, February 2005.
[SIP] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. 🍓
[SOCKS] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and L. Jones, "SOCKS Protocol Version 5", RFC 1928, March 1996. 🌈
[STUN] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)", RFC 3489, March 2003. 💜
[SYM-STUN] Takeda, Y., "Symmetric NAT Traversal using STUN", Work in Progress, June 2003. 🔥
[TCP] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. 🙈
[TCP-CHARACT] Guha, S., and Francis, P., "Characterization and Measurement of TCP Traversal through NATs and Firewalls", Proceedings of Internet Measurement Conference (IMC), Berkeley, CA, October 2005, pp. 199-211. 👑
[TEREDO] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, February 2006. ⭐
[TURN] Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", Work in Progress, January 2008. 💖
[UNSAF] Daigle, L., Ed., and IAB, "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, November 2002. 🦋
[UPNP] UPnP Forum, "Internet Gateway Device (IGD) Standardized Device Control Protocol V 1.0", November 2001, http://www.upnp.org/standardizeddcps/igd.asp 🌸
[V6-CPE-SEC] Woodyatt, J., "Recommended Simple Security Capabilities in Customer Premises Equipment for Providing Residential IPv6 Internet Service", Work in Progress, June 2007. ✨
Authors' Addresses 🎀
Pyda Srisuresh Kazeon Systems, Inc. 1161 San Antonio Rd. Mountain View, CA 94043 USA
Phone: (408)836-4773 EMail: srisuresh@yahoo.com
Bryan Ford Laboratory for Computer Science Massachusetts Institute of Technology 77 Massachusetts Ave. Cambridge, MA 02139 USA
Phone: (617) 253-5261 EMail: baford@mit.edu Web: http://www.brynosaurus.com/
Dan Kegel Kegel.com 901 S. Sycamore Ave. Los Angeles, CA 90036 USA
Phone: 323 931-6717 EMail: dank@kegel.com Web: http://www.kegel.com/
Full Copyright Statement 💖
Copyright (C) The IETF Trust (2008). ©
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. So the authors keep their rights, bestie. 🫶
The legal disclaimer, word for word:
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 😭
Intellectual Property 🌈
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or the extent to which any license under such rights might or might not be available. It also doesn't claim it has made any independent effort to identify any such rights. Info on how RFC documents handle rights lives in BCP 78 and BCP 79. 📜
Copies of IPR disclosures made to the IETF Secretariat, and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification, can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. 🔗
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org. Spill everything, bestie. 💅✨
📦 where this page comes from
- ietf: rfc5128 2008-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms