• Like
  • Save
NAT Behavioral Requirements, as Defined by the IETF (RFC 4787) - Part 1. Mapping Behavior
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

NAT Behavioral Requirements, as Defined by the IETF (RFC 4787) - Part 1. Mapping Behavior

  • 278 views
Published

Download a PDF file: http://www.netmanias.com/en/?m=view&id=techdocs&no=6058 …

Download a PDF file: http://www.netmanias.com/en/?m=view&id=techdocs&no=6058
You can also find and download more materials from http://www.netmanias.com

Published in Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
278
On SlideShare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
0
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. NETMANIAS TECH-BLOG Please visit www.netmanias.com to view more posts NAT Behavioral Requirements, as Defined by the IETF (RFC 4787) - Part 1. Mapping Behavior September 12, 2013 | By Andrew Johnson and Chris Yoo (tech@netmanias.com) Many applications like Skype, Kakao Talk Voice, online games, etc. are all Peer-to-Peer (P2P) applications based on UDP. When running these applications, two devices communicate with each other without a server in between. We learned in our previous post that Korean telecom operators have already employed NATs in all of their access networks (Wi-Fi, 3G and LTE) except for wired networks. These P2P applications and NATs do not really get along with each other (usually P2P apps are victimized by NATs). It is impossible for two user devices with different private IP addresses in different locations (one behind a NAT, the other on the other side of the NAT) to directly communicate with each other through a NAT. This is because an external host cannot connect (i.e. send a packet) to an internal host behind a NAT first. For example, if Device 1 (e.g. Host A in the figure below) sends a packet to Device 2 (e.g. Host B), a NAT ahead of Device 2 will drop the packet. If Device 2 sends one to Device 1, this time the NAT ahead of Device 1 will drop it. To address this issue, NAT Traversal techniques , such as Session Traversal Utilities for NAT (STUN), RFC 5389/RFC 5780), Traversal Using Relays around NAT, RFC 5766 (TURN), Interactive Connectivity Establishment (ICE), RFC 5245), etc., have been standardized. These techniques can be summarized as follows:  STUN: This technique describes how a host (a STUN client) communicates with a STUN server (a server with public IP addresses) to find out i) if the host is within a private network (i.e. has a NAT), ii) if any, how the NAT behaves, and iii) what public IP addresses and source port values are translated by the NAT, etc.  TURN: This describes how a host behind a NAT communicates with another host located on the opposing side of the NAT through a "Turn Server", a relay server with public IP addresses. One drawback of this method is that the communication has to be through the relay server. So, this will inevitably slow response.  ICE: It describes how to find an optimal way of establishing sessions between hosts using STUN or TURN. As such, decisions on which NAT Traversal technique to use are made based on the operational characteristics of a NAT. So, in 2007, "NAT Behavioral Requirements for Effective Nat Traversal""were standardized in RFC 4787. 1
  • 2. Netmanias Tech-Blog: NAT Behavioral Requirements (RFC 4787) - Part 1. Mapping Behavior The three subsequent posts will present the ideal NAT behaviors for P2P applications described in the RFC 4787. Before we continue, please see the following definitions of some important terms first (see the figure below):  Internal Endpoint: a user device that has a private IP address and is located behind a NAT, e.g. Host A in the figure below (e.g. a user device that is located in the same operator network as a NAT)  External Endpoint: a user device that has a public IP address and is located on the opposing side of the NAT, e.g. Host B in the figure below (e.g. a user device that is not located in the same operator network as a NAT)  Outbound Packet (Traffic): a packet (traffic) sent from an Internal Endpoint to an External Endpoint via a NAT  Inbound Packet (Traffic): a packet (traffic) sent from an External Endpoint to an Internal Endpoint via a NAT  Internal Address and Internal Port: the Source IP (10.1.1.1) and Source Port (5000) of a packet sent by an Internal Endpoint (Host A)  External Address and External Port: the Source IP (5.5.5.1) and Source Port (1000) of a packet translated by a NAT and then sent to an External Endpoint (Host B)  In general, the destination information (i.e. Destination IP (1.1.1.1) and Destination Port (80)) of a packet sent by an Internal Endpoint (Host A) is forwarded to an External Endpoint (Host B) transparently without being translated by a NAT.  When an External Endpoint (Host B) receives the packet, it returns a packet comprising of following information to the Internal Endpoint as a response:  Destination IP = the Source IP address of the received packet, i.e. the External Address (5.5.5.1)  Destination Port = the Source Port of the received packet, i.e. the External Port (1000)  Source IP = the Destination IP address of the received packet (1.1.1.1), i.e. the IP address of the External Endpoint (Host B)  Source Port = the Destination Port of the received packet (80) Internal Endpoint External Endpoint 10.1.1.1 5.5.5.1 1.1.1.1 Private/Internal Host A Public/External NAT Host B Source Port (Internal Port) Source IP (Internal IP) Destination Port Destination IP 5000 10.1.1.1 80 1.1.1.1 1000 5.5.5.1 80 1.1.1.1 Translated Outbound Packet (Traffic) 10.1.1.1 5000 1.1.1.1 80 Translated Inbound Packet (Traffic) Source Port (External Port) Source IP (External IP) Destination Port Destination IP 5.5.5.1 1000 1.1.1.1 80 Source Port (= Outbound Packet’s Destination Port) Source IP (= Outbound Packet’s Destination IP) Destination Port (= Outbound Packet’s Internal Port) Destination IP (= Outbound Packet’s Internal IP) Source Port (= Outbound Packet’s Destination Port) Source IP (= Outbound Packet’s Destination IP) Destination Port (= Outbound Packet’s External Port) Destination IP (= Outbound Packet’s External IP) 2
  • 3. Netmanias Tech-Blog: NAT Behavioral Requirements (RFC 4787) - Part 1. Mapping Behavior 1. Network Address and Port Translation Behavior 1.1 Address and Port Mapping ■ Endpoint-Independent Mapping In "Endpoint-Independent Mapping", the Endpoint refers to an External Endpoint. "Endpoint-Independent Mapping" uses the same External Port Mapping value (Translated Port = 1000) for all the packets that are sent by the same Internal Endpoint (Host A), and thus have the same i) Source IP Address (10.1.1.1) and ii) Source Port (5000), regardless of their Destination IP Address (1.1.1.1 or 2.2.2.2) and Destination Port (80 or 8080). Endpoint-Independent Mapping 10.1.1.1 5.5.5.1 1.1.1.1 Host A 2.2.2.2 Host B Private Host C Public NAT 5000 10.1.1.1 80 1.1.1.1 1000 5.5.5.1 80 1.1.1.1 (10.1.1.1:5000 to AnyIP:AnyPort) mapping to (5.5.5.1:1000) 5000 10.1.1.1 8080 2.2.2.2 1000 5.5.5.1 8080 2.2.2.2 (10.1.1.1:5000 to AnyIP:AnyPort) mapping to (5.5.5.1:1000) ■ Address-Dependent Mapping In "Address-Dependent Mapping", the Address refers to the Destination IP Address of a packet sent by an Internal Endpoint. "Address-Dependent Mapping" uses the same External Port Mapping value (Translated Port = 1000) for packets sent by the same Internal Endpoint (Host A) to the same external IP address, and thus have the same i) Source IP Address (10.1.1.1), ii) Source Port (5000) and iii) Destination IP Address (1.1.1.1), regardless of their Destination Port (80 or 8080). Address-Dependent Mapping 10.1.1.1 5.5.5.1 Private Host A 1.1.1.1 Host B NAT 5000 10.1.1.1 80 1.1.1.1 2.2.2.2 Host C Public 1000 5.5.5.1 80 1.1.1.1 (10.1.1.1:5000 to 1.1.1.1:AnyPort) mapping to (5.5.5.1:1000) 5000 10.1.1.1 8080 1.1.1.1 1000 5.5.5.1 8080 1.1.1.1 (10.1.1.1:5000 to 1.1.1.1:AnyPort) mapping to (5.5.5.1:1000) 3
  • 4. Netmanias Tech-Blog: NAT Behavioral Requirements (RFC 4787) - Part 1. Mapping Behavior In the figure below, for the two packets with the same Source IP Address (10.1.1.1) and Source Port (5000), but with different Destination IP Addresses (1.1.1.1 and 2.2.2.2), different External Port Mapping values (Translated Port = 1000 and 1002) are used. Address-Dependent Mapping 10.1.1.1 5.5.5.1 Private Host A 1.1.1.1 2.2.2.2 Host B Host C Public NAT 5000 10.1.1.1 80 1.1.1.1 1000 5.5.5.1 80 1.1.1.1 (10.1.1.1:5000 to 1.1.1.1:AnyPort) mapping to (5.5.5.1:1000) 5000 10.1.1.1 8080 2.2.2.2 1002 5.5.5.1 8080 2.2.2.2 (10.1.1.1:5000 to 2.2.2.2:AnyPort) mapping to (5.5.5.1:1002) ■ Address and Port-Dependent Mapping In "Address and Port-Dependent Mapping", the Address and Port respectively refer to the Destination IP Address and Destination Port of the packet sent by an Internal Endpoint. "Address and Port-Dependent Mapping" uses the same External Port Mapping for packets sent by the same Internal Endpoint (Host A) to the same External Endpoint, and thus all the i) Source IP Address, ii) Source Port, iii) Destination IP Address, and iv) Destination Port of the packet are same. In the figure below, different External Port Mapping values (Translated Port = 1000 and 1002) are used for the two packets because they have different Destination IP Addresses (1.1.1.1 and 2.2.2.2). Address & Port-Dependent Mapping 10.1.1.1 5.5.5.1 Private Host A 1.1.1.1 Host B Host C Public NAT 5000 10.1.1.1 80 1.1.1.1 2.2.2.2 1000 5.5.5.1 80 1.1.1.1 (10.1.1.1:5000 to 1.1.1.1:80) mapping to (5.5.5.1:1000) 5000 10.1.1.1 80 2.2.2.2 1002 5.5.5.1 80 2.2.2.2 (10.1.1.1:5000 to 2.2.2.2:80) mapping to (5.5.5.1:1002) In the figure below, different External Port Mapping values (Translated Port = 1000 and 1004) are used because the two packets have different Destination Ports (80 and 8080). 4
  • 5. Netmanias Tech-Blog: NAT Behavioral Requirements (RFC 4787) - Part 1. Mapping Behavior Address & Port-Dependent Mapping 10.1.1.1 5.5.5.1 Private Host A 1.1.1.1 Host B NAT 5000 10.1.1.1 80 1.1.1.1 2.2.2.2 Host C Public 1000 5.5.5.1 80 1.1.1.1 (10.1.1.1:5000 to 1.1.1.1:80) mapping to (5.5.5.1:1000) 5000 10.1.1.1 8080 1.1.1.1 1004 5.5.5.1 8080 1.1.1.1 (10.1.1.1:5000 to 1.1.1.1:8080) mapping to (5.5.5.1:1004) RFC 4787 Recommendation (REQ-1): A NAT MUST have an "Endpoint-Independent Mapping" behavior RFC 4787 states that "Failure to meet REQ-1 will force the use of a UDP relay, which is very often impractical. 1.2 IP Address Pooling APs and Wi-Fi Hotspot APs use one public IP address to perform NAPT (Network Address Port Translation). However, Large Scale NATs (LSNs, also called Carrier Glade NATs (CGNs)) employed in 3G/LTE networks use multiple public IP addresses (a pool of IP addresses on the external side of the NAT). ■ Arbitrary NATs use different External IP Addresses even for packets sent by one Internal Endpoint (i.e. those with the same Source IP Addresses), if their sessions (tuple of {Source IP, Source Port, Destination IP, Destination Port}) are different. As seen in the figure below, the NAT allocates two different External IP Addresses (5.5.5.1 and 5.5.5.2) for two different sessions that the Internal Endpoint 10.1.1.1 (Host A) has established to the External Endpoint 1.1.1.1 (Host B).  Session 1: {10.1.1.1:5000 to 1.1.1.1:80} -> {5.5.5.1:1000 to 1.1.1.1:80}  Session 2: {10.1.1.1:5001 to 1.1.1.1:8080} -> {5.5.5.2:1001 to 1.1.1.1:8080} 5
  • 6. Netmanias Tech-Blog: NAT Behavioral Requirements (RFC 4787) - Part 1. Mapping Behavior NAT Address Pooling: Arbitrary External Address Range : 5.5.5.1 ~ 5.5.5.10 10.1.1.1 Private Host A 1.1.1.1 Public NAT 5000 10.1.1.1 80 1.1.1.1 Host B 1000 5.5.5.1 80 1.1.1.1 (10.1.1.1:5000) mapping to (5.5.5.1:1000) 5001 10.1.1.1 8080 1.1.1.1 1001 5.5.5.2 8080 1.1.1.1 (10.1.1.1:5001) mapping to (5.5.5.2:1001) ■ Paired NATs use the same External IP Address for packets sent by one Internal Endpoint (i.e. those with the same Source IP Addresses) even when their sessions (tuple of {Source IP, Source Port, Destination IP, Destination Port}) are different. As seen in the figure below, the NAT allocates the same External IP Addresses (5.5.5.1) for two different sessions that the Internal Endpoint 10.1.1.1 (Host A) has established to the External Endpoint 1.1.1.1 (Host B). NAT Address Pooling: Paired External Address Range : 5.5.5.1 ~ 5.5.5.10 10.1.1.1 Private Host A NAT 5000 10.1.1.1 80 1.1.1.1 1.1.1.1 Public Host B 1000 5.5.5.1 80 1.1.1.1 (10.1.1.1:5000) mapping to (5.5.5.1:1000) 5001 10.1.1.1 8080 1.1.1.1 1001 5.5.5.1 8080 1.1.1.1 (10.1.1.1:5001) mapping to (5.5.5.1:1001) RFC 4787 Recommendation (REQ-2): It is RECOMMENDED that a NAT have an "IP address pooling" behavior of "Paired" 1.3 Port Assignment ■ Port Preservation NATs preserve the Source Port (Internal/Local Port) value used by the Internal Endpoint which sent a packet, even after implementing NAT (External Port = Internal Port). 6
  • 7. Netmanias Tech-Blog: NAT Behavioral Requirements (RFC 4787) - Part 1. Mapping Behavior Port Preservation External Address Range : 5.5.5.1 ~ 5.5.5.5 10.1.1.1 10.1.1.2 Private Host A Host B 1.1.1.1 Public NAT Host C 5000 10.1.1.1 80 1.1.1.1 5000 5.5.5.1 80 1.1.1.1 5000 10.1.1.2 80 1.1.1.1 5000 5.5.5.2 80 1.1.1.1 Internal Port (5000) = External Port (5000) ■ No Port Preservation NATs do not preserve the Source Port (Internal Port) value used by the Internal Endpoint, and allocate a Source Port (External Port) value randomly (External Port != Internal Port). No Port Preservation 10.1.1.1 10.1.1.2 External Address Range : 5.5.5.1 ~ 5.5.5.5 Private Host A Host B 1.1.1.1 Public NAT Host C 5000 10.1.1.1 80 1.1.1.1 6000 5.5.5.1 80 1.1.1.1 5000 10.1.1.2 80 1.1.1.1 7000 5.5.5.1 80 1.1.1.1 Internal Port (5000) != External Port (6000/7000) ■ Port Overloading (in Port Preservation) Let us suppose a NAT supporting port preservation runs out of External IP Addresses (Public IP Addresses). What should the NAT do if an outbound packet with the same Source Port value arrives? Port overloading is a simple but reckless method. NATs simply overwrite an existing binding entry in case of port collisions. That is, they always use port preservation. Then, as seen in the figure below, the binding entry generated forHost B would be overwritten by Host A. As a result, each packet that Host A and Host B sent to Host C through the NAT would have the same External Address (5.5.5.5) and External Port (5000). This will lead the NAT to forward all the inbound packets from Host C to Host A. Eventually, communication between Host B and Host C will be impossible. Of course, no vendor would actually manufacture products that support this method. 7
  • 8. Netmanias Tech-Blog: NAT Behavioral Requirements (RFC 4787) - Part 1. Mapping Behavior Port Preservation & Port Overloading 10.1.1.6 10.1.1.5 External Address Range : 5.5.5.1 ~ 5.5.5.5 Private Host A Host B 1.1.1.1 Public NAT Host C 5000 10.1.1.1 80 1.1.1.1 5000 5.5.5.1 80 1.1.1.1 5000 10.1.1.2 80 1.1.1.1 5000 5.5.5.2 80 1.1.1.1 5000 10.1.1.3 80 1.1.1.1 5000 5.5.5.3 80 1.1.1.1 5000 10.1.1.4 80 1.1.1.1 5000 5.5.5.4 80 1.1.1.1 5000 10.1.1.5 80 1.1.1.1 5000 5.5.5.5 80 1.1.1.1 Port Preservation: Internal Port (5000) = External Port (5000) 5000 10.1.1.6 80 1.1.1.1 5000 5.5.5.5 80 1.1.1.1 Port Overloading: Internal Port (5000) = External Port (5000) ■ No Port Overloading (in Port Preservation) In the event of port collisions, NATs do not use port preservation, and instead they allocate the External Port a value different from that of the Internal Port. Port Preservation & No Port Overloading 10.1.1.6 10.1.1.5 External Address Range : 5.5.5.1 ~ 5.5.5.5 Private Host A Host B 1.1.1.1 Public NAT Host C 5000 10.1.1.1 80 1.1.1.1 5000 5.5.5.1 80 1.1.1.1 5000 10.1.1.2 80 1.1.1.1 5000 5.5.5.2 80 1.1.1.1 5000 10.1.1.3 80 1.1.1.1 5000 5.5.5.3 80 1.1.1.1 5000 10.1.1.4 80 1.1.1.1 5000 5.5.5.4 80 1.1.1.1 5000 10.1.1.5 80 1.1.1.1 5000 5.5.5.5 80 1.1.1.1 Port Preservation: Internal Port (5000) = External Port (5000) 5000 10.1.1.6 80 1.1.1.1 6000 5.5.5.5 80 1.1.1.1 No Port Overloading: Internal Port (5000) != External Port (6000) RFC 4787 Recommendation (REQ-3): A NAT MUST NOT have a "Port assignment" behavior of "Port overloading" 8
  • 9. Netmanias Tech-Blog: NAT Behavioral Requirements (RFC 4787) - Part 1. Mapping Behavior 1.4 Port Assignment Rule The RFC also includes "Export Port Assignment Rules" for NATs supporting "No Port Preservation". The Internet Assigned Numbers Authority (IANA) defines port ranges as follows:  Well-Known: 0 ~ 1023 (as standardized by IANA. e.g. HTTP = 80)  Registered: 1024 ~ 49151 (not standardized by IANA, but widely used)  Dynamic/Private: 49192 ~ 65535 Depending on NAT implementation, the following External Port assignment rules can be applied:  If a NAT uses values from Dynamic/Private port range (49192 ~ 65535) for External Ports, the maximum number of NAT sessions supportable by one public IP address is limited to 16,000.  If a NAT uses values from the ranges excluding Well-Known range (1024 ~ 65535) for External Ports, the NAT uses values from Dynamic/Private port range first, and then ones from Registered range if needed. 1.5 Mapping Timer (Binding Refresh Timer) A binding entry generated in a NAT table by outbound traffic remains valid if there is traffic that is mapped using the same binding entry. However, if there is no traffic, the entry is deleted from the table when a mapping timer (also called binding refresh timer, or binding lifetime) expires. If a NAT has a short mapping timer, a device (NAT-friendly application) will have to send Keep Alive packets quite often to keep NAT sessions active. This will not be problematic for subscribers using wired or Wi-Fi networks. But, for 3G/LTE network subscribers who pay for what they use, this can be problematic. In the figure below, the NAT mapping timer is set two minutes. At t=0, Host A sends its first packet and generates a binding entry for the packet. Then one minute later, when Host A sends another packet, the binding entry is refreshed (reset) to two minutes again. 9
  • 10. Netmanias Tech-Blog: NAT Behavioral Requirements (RFC 4787) - Part 1. Mapping Behavior Mapping Refresh 10.1.1.1 5.5.5.1 1.1.1.1 Private Host A Public NAT 5000 10.1.1.1 80 1.1.1.1 Host B 1000 5.5.5.1 80 1.1.1.1 t=0 NAT Inside IP Port NAT Outside IP Port Binding Lifetime 10.1.1.1 5000 5.5.5.1 1000 120s Address Binding (Create Binding Entry) 5000 10.1.1.1 80 1.1.1.1 1000 5.5.5.1 80 1.1.1.1 t = 60 NAT Inside IP Port NAT Outside IP Port 10.1.1.1 5000 5.5.5.1 1000 Binding (Mapping) Refresh Binding Lifetime 120s As opposed to that, the NAT binding entry in the figure below is deleted after two minutes without traffic. Mapping Timeout 10.1.1.1 5.5.5.1 1.1.1.1 Private Host A Public NAT 5000 10.1.1.1 80 1.1.1.1 Host B 1000 5.5.5.1 80 1.1.1.1 t=0 NAT Inside IP Port NAT Outside IP Port Binding Lifetime 10.1.1.1 5000 5.5.5.1 1000 120s Address Binding (Create Binding Entry) t = 120 NAT Inside IP Port NAT Outside IP Port Binding Lifetime 0s Address Unbinding (Delete Binding Entry) RFC 4787 Recommendation (REQ-5): A NAT UDP mapping timer MUST NOT expire in less than two minutes, unless REQ-5a applies a) For specific destination ports in the well-known port range (ports 0-1023), a NAT MAY have shorter UDP mapping timers that are specific to the IANA-registered application running over that specific destination port b) The value of the NAT UDP mapping timer MAY be configurable c) A default value of five minutes or more for the NAT UDP mapping timer is RECOMMENDED 10
  • 11. Netmanias Tech-Blog: NAT Behavioral Requirements (RFC 4787) - Part 1. Mapping Behavior 1.6 Mapping Refresh Behavior ■ NAT Outbound refresh behavior of "True" When a mapping timer is refreshed by outbound traffic (a packet sent by an Internal Endpoint to an External Endpoint) ■ NAT Inbound refresh behavior of "True" When a mapping timer is refreshed by inbound traffic (a packet sent by an External Endpoint to an Internal Endpoint) RFC 4787 Recommendation (REQ-6): The NAT mapping Refresh Direction MUST have a "NAT Outbound refresh behavior" of "True" 11
  • 12. Netmanias Research and Consulting Scope 99 00 01 02 03 04 05 06 07 08 09 10 11 12 13 eMBMS/Mobile IPTV CDN/Mobile CDN Transparent Caching BSS/OSS Services Cable TPS Voice/Video Quality IMS Policy Control/PCRF IPTV/TPS LTE Mobile Network Mobile WiMAX Carrier WiFi LTE Backaul Data Center Migration Carrier Ethernet FTTH Wireline Network Data Center Metro Ethernet MPLS IP Routing CDN Transparent Caching Analysis Networks eMBMS LTE IMS Infrastructure Services Analyze trends, technologies and market Report Technical documents Blog One-Shot gallery Concept Design DRM POC Training Wi-Fi We design the future protocols IP/MPLS We design the future Carrier Ethernet We design the future Consulting Visit http://www.netmanias.com to view and download more technical documents. Future About NMC Consulting Group (www.netmanias.com) NMC Consulting Group is an advanced and professional network consulting company, specializing in IP network areas (e.g., FTTH, Metro Ethernet and IP/MPLS), service areas (e.g., IPTV, IMS and CDN), and wireless network areas (e.g., Mobile WiMAX, LTE and Wi-Fi) since 2002. Copyright © 2002-2013 NMC Consulting Group. All rights reserved. 12