| 리포트 | 기술문서 | 테크-블로그 | 글로벌 블로그 | 원샷 갤러리 | 통신 방송 통계  | 한국 ICT 기업 총람 |

제품 검색

| 네트워크/통신 뉴스 | 기술자료실 | 자유게시판 |  
 
 
섹션 5G 4G LTE C-RAN/Fronthaul Gigabit Internet IPTV/UHD IoT SDN/NFV Wi-Fi Video Streaming KT SK Telecom LG U+ OTT Network Protocol CDN YouTube Data Center
 
스폰서채널 |

 

  스폰서채널 서비스란?
NAT 장비는 이렇게 만들어야 하는데... (RFC 4787) - 3편: Deterministic Properties
NAT Behavior Requirements for Unicast UDP (RFC 4787) - Part 3: Deterministic Properties
September 23, 2013 | By 유창모 (cmyoo@netmanias.com)
banner
코멘트 (3)
7
RFC 4787 마지막 편입니다.
 

4. Application Level Gateway

 

Application Level Gateway(ALG)에 대한 설명은 여기를 클릭하시기 바랍니다.

 

RFC 4787 권고 (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

어정쩡한 ALG 지원은 오히려 NAT Traversal에 방해가 될 수 있으므로 그 기능을 꺼버리라는 것이죠.

 

 

5. Deterministic Properties

 

■ Non-Deterministic NAT

NAT가 어떤 특정 상황(아래 사례 참조)에서 Mapping 혹은 Filtering Behavior를 자동으로 변경하는 경우입니다.

RFC 4787에서 언급하고 있는 사례는 다음과 같습니다. 

 

평소 NAT는 "Endpoint-Independent Mapping with Port Preservation"으로 동작을 합니다. 

따라서 Host A가 Host X와 Host Y로 보내는 패킷[1][2]에 대해 둘 모두 동일한 External Port = 5000을 할당하고(Endpoint-Independent Mapping), Internal Port와 동일한 값 5000을 External Port로 사용합니다(Port Preservation).
그리고 Host A와 Host B는 각각 Internal Port = 6000으로 하여 Host Y로 패킷[3][4]를 보냅니다. NAT는 External Address Pool에 할당 가능한 IP 주소 여유가 있으므로 여전히 Port Preservation이 가능합니다.

 

이후 Host C가 Host B와 동일한 Internal Port = 6000으로 Host Y로 패킷[5]를 송신하게 되면, NAT는 동일 목적지(External Endpoint)에 대해 Internal Port = 6000이 이미 사용 중에 있고, External 주소 여유분도 없어(Session Conflict) 더 이상 Port Preservation을 할 수 없음을 인지 한 후 NAT Behavior를 "Address and Port-Dependent Mapping without Port Preservation"으로 변경합니다.

따라서 Host C가 Host Y로 보내는 패킷[5]에 대해서는 Internal Port(6000)와 External Port(7000)가 같지 않게 되며(No Port Preservation), 또한 Host C가 Host Y로 보낸 패킷[5]의 External Port(7000)와 Host X로 보낸 패킷[6]의 External Port(7002) 역시 같지 않게 됩니다(Address and Port-Dependent Mapping).

 

 

■ Deterministic NAT 

어떤 상황에서도 NAT가 동일한 Mapping & Filtering Behavior를 유지하는 경우입니다.

 

RFC 4787 권고 (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

 

Host의 TCP/UDP 응용이 보낸 패킷은 IP MTU(Maximum Transmission Unit) 크기에 의해 최대 전송 크기가 제한됩니다. IP 하부 계층(L2 layer)이 Ethernet인 경우 IP MTU는 1500 byte이며(Jumbo Frame 경우 제외), 아래 그림과 같이 UDP 응용에서 2000 byte 패킷을 전송하면 이 패킷은 2개의 패킷으로 Fragmentation 됩니다. 이 때 첫번째 패킷에는 IP 및 UDP 헤더가 모두 붙지만, 두번째 패킷에는 IP 헤더만 붙게 됩니다. 

 

따라서 이 경우 NAT는 IP 헤더의 MF(More Fragment) 및 Fragmentation Offset 필드를 참조하여 Fragmentation 된 패킷인지 구별 할 수 있어야 하고, UDP 헤더가 붙지 않은 두번재 패킷에 대해서 IP 헤더의 Identification 필드(0x1234)를 참조하여 Session을 구분하고 해당 패킷의 Internal Address(10.1.1.1)을 External Address(5.5.5.1)로 변경 할 수 있어야 합니다. 만약 이 기능을 지원하지 않으면 통신이 불가능하게 됩니다. (이건 너무 기본적인 기능인지 RFC 4787 권고 사항으로 얘기하고 있지도 않네요)

 

 

또한 이와 같은 Packet Fragmentation은 Host(단말/서버) 뿐만 아니라 일반 라우터와 NAT(NAT 장비도 Destination IP 주소 기반으로 패킷을 전달하므로 라우터라고 볼 수 있음)에서도 수행합니다.

현재는 Link Layer를 Ethernet이 평정하였고, Wi-Fi 또한 IP MTU가 1500 byte라서(Windows 경우) NAT 장비가 Packet Fragmentation 할 경우는 별로 없지만, RFC 4787에서는 다음과 같은 시나리오에 대해 얘기하고 있습니다.

만약 IP 헤더에 DF(Don't Fragment) bit가 1로 설정("이 패킷은 Fragmentation 하지 마세요~"의 의미)된 패킷을 Host로 부터 수신한 NAT가 이 패킷을 업링크(인터넷 방향)로 전달 시 MTU 크기 제약으로 인해 Packet Fragmentation을 해야만 한다면 Host로 "Fragmentation이 필요합니다"라는 ICMP 메시지를 전달하라고 되어 있습니다.

 

RFC 4787 권고 (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

 

위와 같이 Internal Endpoint에 의해서 Packet Fragmentation이 발생할 수도 있지만 반대로 External Host(Host B)에 의해서 Fragmentation이 발생할 수도 있습니다. 이 경우도 위와 동일하게 UDP 헤더가 없는 Fragmented Packet에 대해서 IP 헤더의 Identification 필드를 참조하여 Session을 구분하고 해당 패킷의 Destination IP를 변경 할 수 있어야 합니다. 

 

 

또한 이 경우 다음 2가지 NAT Behavior를 얘기하고 있습니다.

 

■ Received Fragments Ordered

Fragmented된 패킷이 순서데로 수신되어야만 주소/포트 변환 후 Internal Endpoint로 전송하는 경우

 

■ Received Fragment Out of Order 

Fragment된 패킷의 순서가 바뀌어 수신되어도(예. External Endpoint가 Fragment Packet 1, 2, 3을 전송했는데 IP 망에 의해서 그 순서가 뒤바뀌어 NAT로 1, 3, 2 순으로 수신) 주소/포트 변환을 잘하여 Internal Endpoint로 전송하는 경우

 

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

 

 

이상으로 총 3편에 걸쳐 RFC 4787 "NAT Behavior Requirements for Unicast UDP"의 설명을 마치도록 하겠습니다.

 

참 오랜만에 RFC 문서를 정독하였습니다. 표준을 읽고 그 의미를 분석하면서 느낀 점은, 

(1) 만약 NAT 장비가 시장에 나오기 전에 IETF에서 NAT Behavior를 표준화 하였다면 이처럼 복잡한 상황에 대한 설명이 불필요했을텐데라는 아쉬움과,

 

(2) 또한 이 표준은 어디까지나 NAT Traversal 즉, "NAT를 통과해야 하는 P2P 응용"의 필요성으로 만들어진 것이라서 현재 통신 사업자 혹은 Open Market의 유무선 공유기가 이 규격의 권고를 준수하고 있지 않고 있다는 안타까움입니다. 

(Cisco-Linksys, ipTIME, 통신사업자 유무선 공유기 하나를 시험해 본 결과 모두 Endpoint-Independent Mapping + Address and Port-Dependent Filtering의 Behavior를 보임)

 

 

조형래 2015-09-14 00:43:10

ㅎㅎ.. 첫번째 설명중(Non-Deterministic NAT)에서 hostC가 6000포트 보내는 패킷은 5.5.5.2:6000에 아직 할당 할수있는거 아닌가요?? ^_^;;??

유주안 2017-07-16 15:16:02

글 정말 잘 읽었습니다.

 

혹시 ISP업체에서 NAT전용 장비로 추천할 장비가 있나요??

 

Chris Yoo 2017-07-16 16:31:06

2013년 조사 결과에 따르면 국내 통신 사업자에 도입된 CGNAT 벤더/장비는 Juniper SRX, Cisco ASA, Fortinet, A10 Networks 등입니다.

Thank you for visiting Netmanias! Please leave your comment if you have a question or suggestion.
View All (969)
5G (67) AI (5) ALTO (1) AR (2) ARP (6) AT&T (1) Akamai (5) Authentication (5) BT (1) Backhaul (2) Big Data (2) Bridging (5) C-RAN/Fronthaul (17) CDN (20) CIoT (2) CPRI (6) Carrier Aggregation (5) Charging (2) China Mobile (2) Cisco (6) CoMP (3) Comcast (1) DHCP (6) DNS (15) Data Center (15) EDGE (10) EMM (1) EPS Bearer (7) Ethernet (3) FTTH (8) GSLB (5) Gigabit Internet (17) Google (17) Google Global Cache (8) Google TV (1) HLS (5) HTTP (5) HTTP Adaptive Streaming (7) HTTP Progressive Download (2) Handover (5) Huawei (1) IGMP (3) IP (6) IP Allocation (8) IP Routing (20) IPSec (4) IPTV (25) IoST (2) IoT (44) KT (45) Korea (8) Korea ICT Vendor (1) L3 Switch (5) LG U+ (24) LTE (99) LTE-A (10) LTE-A Pro (1) LTE-M (1) LTE-U (3) LoRa (5) MEC (10) MPLS (3) MWC 2013 (1) MWC 2015 (3) MWC 2016 (2) MWC 2017 (1) Mobile IPTV (1) Multi-Screen (1) Multicast (2) NAT (9) NB-IoT (6) NTT Docomo (1) Netflix (5) Network Protocol (49) Network Slicing (3) OSPF (3) OTT (20) Operator CDN (1) P2P (3) PS-LTE (3) Pooq (2) QoS (5) RCS (1) RRH (1) Request Routing (3) SD-WAN (8) SDN/NFV (34) SK Broadband (1) SK Telecom (38) Samsung (2) Security (8) Self-Driving (3) Shortest Path Tree (2) Small Cell (3) Spectrum Sharing (1) TAU (2) Transparent Caching (9) UHD (7) VLAN (2) VPN (3) VR (3) Video Streaming (22) VoLTE (1) VoWiFi (1) WAN Optimization (1) Wi-Fi (30) WiBro(WiMAX) (2) YouTube (16) eICIC (1) eMBMS (1) ePDG (6) u+ tv G (4) 로컬 5G (1)

 

 

     
         
     

 

     
     

넷매니아즈 회원 가입 하기

2019년 1월 현재 넷매니아즈 회원은 49,000+분입니다.

 

넷매니아즈 회원 가입을 하시면,

► 넷매니아즈 신규 컨텐츠 발행 소식 등의 정보를

   이메일 뉴스레터로 발송해드립니다.

► 넷매니아즈의 모든 컨텐츠를 pdf 파일로 다운로드

   받으실 수 있습니다. 

     
     

 

     
         
     

 

 

비밀번호 확인
코멘트 작성시 등록하신 비밀번호를 입력하여주세요.
비밀번호