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
STUN (RFC 3489) vs. STUN (RFC 5389/5780)
October 21, 2013 | By Netmanias (tech@netmanias.com)
Online viewer:
Comments (4)
20

What are the differences between NAT types defined in RFC 3489 and RFC 5780?
To understand the differences to be explained below, you must be familiar with the Mapping Behavior and Filtering Behavior of a NAT that we covered last time.

 

What is STUN?
 

STUN is a protocol that allows two devices (P2P devices) to discover the presence and types of a NAT between them, and to find out what External IP address and Port are to be replaced by the NAT, for P2P communication between the two devices.
 
STUN was first defined in RFC 3489 (standards) back in 2003, and then revised two times once in RFC 5389 (standards) in 2008 and again in RFC 5780 (experimental) in 2010.  
According to RFC 5389, "classic STUN's  algorithm for classification of NAT types (defined in RFC 3489) was found to be faulty, as many NATs (available in the market) did not fit cleanly into the (four) types defined there."
To resolve this problem, classic STUN was modified in RFC 5389 (i.e. to add attributes to Binding messages). And in RFC 5780, NAT types were re-defined and the algorithm (method) for classification of NAT types was modified. 
 
Both RFC 3489 and 5389 use the same term "STUN", but in two different meanings as follows:

  • RFC 3489: STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)
  • RFC 5389: Session Traversal Utilities for NAT (STUN) 

 

 

NAT Types Defined in RFC 3489 and 5780

 

1. Full Cone

 

[Mapping Behavior] A full cone NAT is one where all requests from the same internal IP address and port are mapped to the same external IP address and port.  [Filtering Behavior] Furthermore, any external host can send a packet to the internal host, by sending a packet to the mapped external address. (RFC 3489)

 

A full cone NAT in RFC 3489 corresponds to a NAT that uses Endpoint-Independent Mapping ("EIM") and Endpoint-Independent Filtering ("EIF") in RFC 5780. 

  • Mapping Behavior: The NAT translates any outbound packets with the same (1) source IP and (2) source port into the same Port Mapping value (e.g. translated Port = 1000 in the figure below), regardless of the destination IP or destination port of the packet.
  • Filtering Behavior: The NAT checks only the (1) destination IP and (2) destination port of an inbound packet to decide whether to pass the packet or not. Thus, it doesn't care about the source IP or source port values of the External Endpoint.  

 

2. Restricted Cone

 

[Mapping Behavior] A restricted cone NAT is one where all requests from the same internal IP address and port are mapped to the same external IP address and port.  [Filtering Behavior] Unlike a full cone NAT, an external host (with IP address X) can send a packet to the internal host only if the internal host had previously sent a packet to IP address X. (RFC 3489)

 

A restricted cone NAT corresponds to a NAT that uses EIM and Address-Dependent Filtering ("ADF") in RFC 5780.

  • Mapping Behavior: Same as in a full cone type 
  • Filtering Behavior: This NAT checks only the (1) destination IP, (2) destination port and (3) source IP of an inbound packet to decide whether to pass the packet or not. It doesn't care about the source port value of the External Endpoint. 

 

3. Port Restricted Cone

 

[Mapping Behavior] A port restricted cone NAT is like a restricted cone NAT, [Filtering Behavior] but the restriction includes port numbers. Specifically, an external host can send a packet, with source IP address X and source port P, to the internal host only if the internal host had previously sent a packet to IP address X and port P. (RFC 3489)

 

A port restricted cone NAT corresponds to a NAT that uses EIM and Address and Port-Dependent Filtering ("APDF") in RFC 5780.

  • Mapping Behavior: Same as in a full cone type 
  • Filtering Behavior: This NAT checks the (1) destination IP, (2) destination port, (3) source IP AND (4) source port of an inbound packet to decide whether to pass the packet or not. 

 

4. Symmetric

 

[Mapping Behavior] A symmetric NAT is one where all requests from the same internal IP address and port, to a specific destination IP address and port, are mapped to the same external IP address and port.  If the same host sends a packet with the same source address and port, but to a different destination, a different mapping is used.  [Filtering Behavior] Furthermore, only the external host that receives a packet can send a UDP packet back to the internal host. (RFC 3489)

 

A symmetric NAT corresponds to a NAT that uses Address and Port-Dependent Mapping ("APDM") and APDF in RFC 5780.

  • Mapping Behavior: This NAT uses the same Port Mapping value for only the packets that have the same (1) source IP, (2) source port, (3) destination IP AND (4) destination port. 
  • Filtering Behavior: Same as in a port restricted cone type

 

 

Summary 

 

The figure below shows the nine NAT types defined in RFC 5780 and the four NAT types defined in RFC 3489, and how the NAT types in RFC 3489 match their counterparts in RFC 5780.

 

 

 

sivakumar 2014-07-27 02:32:39

nice expained.

S. M. Iftekharul Amin 2017-04-06 15:05:24

what are the terminologies used for NAT Type 4~8 in RFC-3489 definition ?

yintiliang 2018-11-13 10:28:11

Mapping Address(yes or no) Maping Port(yes or no)

Filtering Address(yes or no) Filtering Port(yes or no)

2^4=16

So, there are 16 NAT types defined in RFC 5780~

 

unknown 2022-01-13 15:06:59

>>マッピングアドレス(はいまたはいいえ)マッピングポート(はいまたはいいえ)

>>フィルタリングアドレス(はいまたはいいえ)フィルタリングポート(はいまたはいいえ)

>>2 ^ 4 = 16

>>したがって、RFC 5780〜で定義されている16のNATタイプがあります。

 

全て「いいえ」のものがある時点でNATとは言わない。これについて考えるだけ時間の無駄だった。

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 (181)
5G (9) 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) Private 5G (1) 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