Home | Reports | Technical Documents | Tech-Blog | One-Shot Gallery | Korea ICT News | Korea Communication Market Data | List of Contributors | Become a Contributor |    
 
 
Section 5G 4G LTE C-RAN/Fronthaul Gigabit Internet IPTV/Video Streaming IoT SDN/NFV Wi-Fi KT SK Telecom LG U+ Network Protocol Samsung   Korean Vendors
 
Real World Private 5G Cases   4 Deployment Models On-Premise Cases 5G Core Control Plane Sharing Cases

5G Core Sharing Cases

   
 
Private 5G Deployment   • Private 5G Frequency Allocation Status in Korea  South Korean government's regulations on private 5G and KT's strategy for entering the market
Cases in Korea   Private 5G Operators |   SK Networks Service (SI) Sejong Telecom (Wire-line Carrier) KT MOS (Affiliate of KT) • Newgens (SI) • NAVER Cloud more >>  
    Enterprise DIY |   Korea Hydro & Nuclear Power (Power Plant) Korea Electric Power Corporation (Energy) • Republic of Korea Navy more >>
 
CHANNELS     HFR Private 5G Solution (my5G)       my5G Solution Components       my5G Key Features        my5G Resources        my5G News          
 
banner
banner
NAT Behavioral Requirements, as Defined by the IETF (RFC 4787) - Part 3. Deterministic Properties
October 10, 2013 | By Netmanias (tech@netmanias.com)
Online viewer:
Comments (1)
6

 NAT Behavioral Requirements, as Defined by the IETF (RFC 4787)

  Part 1. Mapping Behavior

 

This is the last post on RFC 4787. 

 
4. Application Level Gateway

 

For information about Application Level Gateways (ALGs), please click here.

 

RFC 4787 Recommendation (REQ-10): To eliminate interference with UNSAF NAT traversal mechanisms and allow integrity protection of UDP communications, NAT ALGs for UDP-based protocols SHOULD be turned off

 

What does this recommendation mean? ALGs, if not fully supported, may only interfere with NAT traversal. So turn it off!! 

 

 

5. Deterministic Properties

 

Non-Deterministic NAT
A NAT that changes its Mapping or Filtering Behavior in particular circumstances (see the example below) is called a "Non-Deterministic NAT". One example of these NATs presented in RFC 4787 is described below. 
 
NATs usually implement "Endpoint-Independent Mapping with Port Preservation". 
So, in the figure below, the NAT allocates the same External Port (5000) to both packets [1] and [2] that Host A is sending to Host X and Host Y (Endpoint-Independent Mapping). It also allocates 5000, the Internal Port number, to the External Port (Port Preservation).
Next, Host A and Host B send Host Y a packet ([3] and [4], respectively). At this time both packets use 6000 for their Internal Port number. Since the NAT has sufficient IP addresses available in its External Address Pool, it can stick with Port Preservation. 
 
Later when Host C sends Host Y a packet [5] which has 6000 as its Internal Port number as Host B did, the NAT realizes that i) the Internal Port of 6000 has already been allocated to the previous packet destined to the same External Endpoint, and ii) there is no more external address available, and thus it cannot stick with Port Preservation any more. So, it switches to "Address and Port-Dependent Mapping without Port Preservation".  
Then the packet that Host C sends to Host Y (i.e. packet [5]) will inevitably have an External Port (7000) that is different from its Internal Port (6000). Thus, No Port Preservation here! Furthermore, it also becomes inevitable for the packet [6] that Host C sends to Host X to have an External Port (7002) that is different from the External Port (7000) of the packet [5] that Host C sent to Host Y (Address and Port-Dependent Mapping). 

 

 

Deterministic NAT 
A NAT that never changes its Mapping or Filtering Behavior in any circumstances is called a "Deterministic NAT". 

 

RFC 4787 Recommendation (REQ-11): A NAT MUST have deterministic behavior, i.e., it MUST NOT change the NAT translation or the Filtering Behavior at any point in time, or under any particular conditions

 

 

6. Fragmentation of Outgoing Packets

 

The maximum transmission size of an outbound packet sent by a TCP/UDP application in a host is limited based on the size of  the specified IP Maximum Transmission Unit (MTU). In case the lower layer of IP (L2 layer) is Ethernet, the IP MTU is 1500 byte (except for Jumbo Frame). So, if, as in the figure below, a UDP application sends a 2,000 byte packet, the NAT fragments the packet into two smaller ones - the first one with both IP and UDP headers, and the second one with an IP header only. 
 
For this reason, it is important at this time for the NAT to be able to identify fragmented packets by referring to MF (More Fragment) and Fragmentation Offset fields in the IP header of the packets. For the second packet with no UDP header, the NAT should be able to identify sessions by referring the Identification field (0x1234) of the IP header, and replace the Internal Address (10.1.1.1) with the External Address (5.5.5.1) for the packet. If the NAT can't do these, no communication will be allowed (Obviously, these seem too basic. The IETF didn't even bother to include them in its RFC 4787). 

 

 
Packet fragmentation occurs not only in hosts (devices or servers), but also in generic routers and NATs (NATs can be considered as routers in that their packet delivery is also based on the destination IP address of packets).  
Today, almost all link layers are Ethernet, and besides the MTU size on a Wi-Fi network is 1,500 bytes (with Windows). Therefore, NATs rarely perform packet fragmentation in deed. However, RFC 4787 still recommends NATs send an ICMP message as follows in case needed:

 

RFC 4787 Recommendation (REQ-13): If the packet received on an internal IP address has DF=1, the NAT MUST send back an ICMP message "Fragmentation needed and DF set" to the host, as described in [RFC0792]

a) If the packet has DF=0, the NAT MUST fragment the packet and SHOULD send the fragments in order

 

 

7. Receiving Fragmented Packets

 

Packet fragmentation is triggered not only by an Internal Endpoint as described above, but also by an External Host (e.g. Host B in the figure below). In case of external host-triggered fragmentation, the same requirements in Section 6 must be met as well. For the fragmented packet with no UDP header, the NAT should be able to identify sessions by referring the Identification field of the IP header, and replace the received External Address with the Internal Address for the packet.
 

 

The following two types of NAT behavior are mentioned in RFC 4787 for such case: 

 

Received Fragments Ordered
A NAT can translate the address/port of fragmented packets and forward them to Internal Endpoints only when the packets are received in an order that they are fragmented.

 

Received Fragment Out of Order 
A NAT can translate the address/port of fragmented packets and forward them to Internal Endpoints even when the packets are not received in an order that they are fragmented (e.g. in case an External Endpoint sent packets in order of fragment packet 1, 2 and 3, but the NAT receives them in order of fragment packet 1, 3 and 2).

 

RFC 4787 Recommendation (REQ-14): A NAT MUST support receiving in-order and out-of-order fragments, so it MUST have "Received Fragment Out of Order" behavior

 

 

8. Closing

 

We have reviewed the "NAT Behavioral Requirements for Unicast UDP" as presented in RFC 4787 through three of our posts so far. After close examination of the document, you may agree with me in that:
 
i) it could have been much easier and simpler to establish standards for different types of NATs only if NAT behavior had been standardized by the IETF earlier, i.e. before NATs were actually introduced in the market.   
 
ii) it is unfortunate that APs provided by telecom operators or in open markets are not compliant with the foregoing standards because the standards are originally designed for NAT traversal (i.e. for P2P applications of which packets must pass through a NAT). According to our test on APs from Cisco-Linksys, ipTIME and a telecom operator, all APs used Endpoint-Independent Mapping + Address and Port-Dependent Filtering Behavior.  

Nancy 2015-01-10 19:19:43

Almost all link layers are Ethernet, and besides the MTU size on a Wi-Fi network. Some routers or DSL lines cannot handle such large packets which causes the call to fail. Depending on the MTU size your network components can process, in some cases large packets are required to be fragmented. Use either provisioning or HTTP GET requests in order to enable this setting. For the latter you would need to enter the following URL in a browser. This article is very much helpful and cooperative to comprehend.

Thank you for visiting Netmanias! Please leave your comment if you have a question or suggestion.
 
 
 
 

[HFR Private 5G: my5G]

 

Details >>

 

 

 

     
         
     

 

     
     

Subscribe FREE >>

Currently, 55,000+ subscribed to Netmanias.

  • You can get Netmanias Newsletter

  • You can view all netmanias' contents

  • You can download all netmanias'

    contents in pdf file

     
     

 

     
         
     

 

 

 

View All (179)
5G (8) 6G (1) Backbone (2) Backhaul (3) Blockchain (1) CDN (1) Carrier Ethernet (3) Charging (1) Cloud Native (1) Core (1) DHCP (4) ECM (2) EMM (16) EPS (2) Google (1) HLS (1) HTTP Adaptive Streaming (3) Handover (5) IPTV (4) Initial Attach (2) IoT (2) Korea (1) LTE (39) LTE Identification (2) LTE-A (1) MPLS (2) Mobility (2) NAT (7) Netflix (1) Network Architecture (3) Network Protocol (20) New Radio (1) OTT (1) PCRF (3) QoS (3) RCS (3) SDF (2) SDN/NFV (3) SK Telecom (2) Samsung (3) Security (5) Sk Telecom (1) Transparent Cache (1) Video Streaming (4) VoLTE (2) Wi-Fi (1) YouTube (2)
Password confirmation
Please enter your registered comment password.
Password