| 리포트 | 기술문서 | 테크-블로그 | 글로벌 블로그 | 원샷 갤러리 | 통신 방송 통계  | 한국 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) - 1편: Mapping Behavior
NAT Behavior Requirements for Unicast UDP (RFC 4787) - Part 1: Mapping Behavior
September 12, 2013 | By 유창모 (cmyoo@netmanias.com)
banner
코멘트 (9)
16

 NAT 문서 모두 보기 

 

Skype, 카톡 보이스, 온라인 게임 등은 모두 UDP 기반의 P2P(Peer-to-Peer) 응용으로써, 서버를 거치지 않고 두 단말간에 바로 통신을 합니다. 지난 시간에 국내 통신 사업자의 경우 유선을 제외한 모든 액세스망(Wi-Fi, 3G, LTE)에 NAT 장비가 도입되어 있다고 설명을 드렸는데요. 

 

이 P2P 응용 프로그램과 NAT는 서로 상극입니다.  (NAT가 가해자, P2P가 피해자~ ^^*)

서로 다른 지역에 위치한 사설 IP 단말 2대가 NAT를 통해 서로 직접 통신은 불가능합니다. 왜냐면 외부에서 NAT 내부로 먼저 연결하는 것, 즉 패킷을 먼저 전송하는 것이 기본적으로 불가능하기 때문입니다. (단말1에서 단말2로 패킷을 보내면 단말2 앞에 있는 NAT가 버리고, 단말2에서 단말1로 패킷을 보내면 이번에는 단말1 앞에 있는 NAT가 버림)

 

이를 해결하고자 STUN(Session Traversal Utilities for NAT, RFC 5389/RFC5780), TURN(Traversal Using Relays around NAT, RFC 5766), ICE(Interactive Connectivity Establishment, RFC 5245)등의 NAT Traversal(NAT 통과 기법)이 표준화되었으며 이를 간단히 요약하면 다음과 같습니다.

  • STUN: 단말(STUN 클라이언트)이 STUN 서버(공인 IP 주소를 가진 서버)와 통신을 통해 (1) 현재 내가 사설망에 있는지(NAT가 있는지), (2) NAT의 동작 특성(NAT Behavior)은 어떻게 되는지, (3) NAT에 의해 변경되는 공인 IP 주소와 Source Port는 어떤 값인지 등을 알아내는 방법을 기술함
  • TURN: 공인 IP 주소를 가진 Relay 서버(TURN 서버)를 통해 두 단말 간에 통신하는 방법을 기술함 (Relay 서버를 거치므로 응답 속도가 느리겠죠)
  • ICE: STUN이나 TURN을 이용하여 단말간 세션을 설정할 때 최적의 방법을 찾아주는 방법을 기술함

이와 같은 NAT Traversal 기법은 NAT 장비의 동작 특성에 의존하게 되는데, 그래서 2007년도에 RFC 4787을 통해 "효과적인 NAT Traversal을 위한 NAT Behavior Requirement"가 표준화 되었습니다. 

앞으로 총 3회에 걸쳐 RFC 4787에서 얘기하는 "P2P 응용을 위해 NAT는 이렇게 동작하면 좋겠다!"에 대해 설명 드리도록 하겠습니다. 

 

설명을 시작하기에 앞서 용어 정의부터 하겠습니다. (아래 그림 참조)

  • Internal Endpoint: NAT 내부에 있는 사설 IP 주소를 가지는 단말 (Host A)
  • External Endpoint: NAT 외부에 있는 공인 IP 주소를 가지는 단말 (Host B)
  • Outbound Packet (Traffic): Internal Endpoint에서 NAT를 거쳐 External Endpoint로 전송되는 패킷(트래픽)
  • Inbound Packet (Traffic): External Endpoint에서 NAT를 거쳐 Internal Endpoint로 전송되는 패킷(트래픽)
  • Internal Address와 Internal Port: Internal Endpoint(Host A)가 보내는 패킷의 Source IP(10.1.1.1)와 Source Port(5000)
  • External Address와 External Port: NAT에 의해 변환되어 External Endpoint(Host B)로 전송되는 패킷의 Source IP(5.5.5.1)와 Source Port(1000)
  • 일반적으로 Internal Endpoint(Host A)가 보내는 패킷의 목적지 정보 즉, Destination IP(1.1.1.1), Destination Port(80)는 NAT에 의해 변환되지 않고 transparent하게 External Endpoint(Host B)로 전달됨
  • 패킷을 수신한 External Endpoint(Host B)는 그 응답으로 다음과 같이 패킷을 구성하여 Internal Endpoint로 패킷 전송
    • Destination IP = 수신된 패킷의 Source IP 즉, External Address(5.5.5.1)
    • Destination Port = 수신된 패킷의 Source Port 즉, External Port(1000)
    • Source IP = 수신된 패킷의 Destination IP(1.1.1.1) 즉, External Endpoint(Host B)의 IP 주소
    • Source Port = 수신된 패킷의 Destination Port(80)

 

 

 

1. Network Address and Port Translation Behavior

 

1.1 Address and Port Mapping

 

■ Endpoint-Independent Mapping

여기서 Endpoint란 External Endpoint를 의미합니다. 

"목적지 독립적 매핑(Endpoint-Independent Mapping)"은 Internal Endpoint(Host A)가 송신하는 패킷의 (1) Source IP Address(10.1.1.1)와 (2) Source Port(5000)만 동일 하다면 Destination IP Address(1.1.1.1 or 2.2.2.2) 및 Destination Port(80 or 8080) 값에 상관없이 동일한 External Port Mapping 값(Translated Port = 1000)을 사용합니다.

 

 

■ Address-Dependent Mapping

여기서 Address란 Internal Endpoint가 송신하는 패킷의 목적지 주소(Destination IP Address)를 의미합니다. 

"목적지 주소 의존적 매핑(Address-Dependent Mapping)"은 Internal Endpoint(Host A)가 송신하는 패킷의 (1) Source IP Address(10.1.1.1)와 (2) Source Port(5000) 그리고 (3) Destination IP Address(1.1.1.1)가 동일하면 Destination Port(80 or 8080) 값에 상관없이 동일한 External Port Mapping 값(Translated Port = 1000)을 사용합니다.

 

 

만약 Source IP Address(10.1.1.1)와 Source Port(5000)는 동일하지만 Destination IP Address가 다르면(1.1.1.1 and 2.2.2.2) 서로 다른 External Port Mapping 값(Translated Port = 1000 and 1002)을 사용합니다.

 

 

■ Address and Port-Dependent Mapping

여기서 Address와 Port란 Internal Endpoint가 송신하는 패킷의 목적지 주소(Destination IP Address)와 목적지 포트(Destination Port)를 의미합니다. 

"목적지 주소 및 포트 의존적 매핑(Address and Port-Dependent Mapping)"은 Internal Endpoint(Host A)가 송신하는 패킷의 (1) Source IP Address, (2) Source Port 그리고 (3) Destination IP Address, (4) Destination Port가 모두 동일해야 동일 External Port Mapping 값을 사용합니다.

아래 그림에서는 Destination IP Address(1.1.1.1 and 2.2.2.2)가 달라서 다른 External Port Mapping 값(Translated Port = 1000 and 1002)을 사용하였고,

 

 

이 그림에서는 Destination Port(80 and 8080)가 달라서 다른 External Port Mapping 값(Translated Port = 1000 and 1004)을 사용하였습니다.

 

 

RFC 4787 권고 (REQ-1): A NAT MUST have an "Endpoint-Independent Mapping" behavior

RFC 4787에 따르면 "본 권고를 지키지 않는 경우 P2P 통신은 Relay 서버(TURN 서버)를 거칠 수 밖에 없게 되어 매우 비효율적이다"라고 얘기하고 있습니다.

 

 

1.2 IP Address Pooling

 

유무선 공유기나 Wi-Fi Hotspot AP의 경우 하나의 Public IP 주소를 이용하여 NAPT(Network Address Port Translation)를 수행하는 반면, 3G/LTE 망에 적용된 LSN(Large Scale NAT, 혹은 CGN: Carrier Glade NAT라 부름)의 경우 여러개의 Public IP 주소(Pool of IP addresses on the external side of the NAT)를 가지게 됩니다.

 

 Arbitrary

하나의 Internal Endpoint가 보내는 패킷이지만(동일 Source IP Address를 가진 패킷), Session(tuple of {Source IP, Source Port, Destination IP, Destination Port})이 다르면 다른 External IP 주소를 사용합니다.

아래 그림과 같이 Internal Endpoint 10.1.1.1(Host A)이 External Endpoint 1.1.1.1(Host B)로 2개의 Session을 생성하면 NAT는 각 Session에 대해 서로 다른 External IP 주소(5.5.5.1 and 5.5.5.2)를 할당합니다.

  • 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}
 

 

 Paired

하나의 Internal Endpoint가 보내는 패킷(동일 Source IP Address)에 대해서는 Session(tuple of {Source IP, Source Port, Destination IP, Destination Port})이 달라도 동일 External IP 주소를 사용합니다.

아래 그림과 같이 Internal Endpoint 10.1.1.1(Host A)이 External Endpoint 1.1.1.1(Host B)로 2개의 서로 다른 Session을 생성하였지만 NAT는 각 Session에 대해 동일 External IP 주소(5.5.5.1)를 할당합니다.

 

 

RFC 4787 권고 (REQ-2): It is RECOMMENDED that a NAT have an "IP address pooling" behavior of "Paired"

 

 

1.3 Port Assignment

 

 Port Preservation

Internal Endpoint가 보낸 Source Port(Internal/Local Port) 값이 NAT 변환 후에도 그 값을 유지(Preservation)합니다(External Port = Internal Port). 

 

 

■ No Port Preservation

Internal Endpoint가 보낸 Source Port(Internal Port) 값을 유지하지 않고 따라서 NAT 장비가 임의의 Source Port(External Port) 값으로 변경합니다(External Port != Internal Port).

 

 

■ Port Overloading (in Port Preservation)

Port Preservation을 지원하는 NAT 장비가 더 이상 사용 가능한 External IP Address(Public IP Address)가 없는 상황에서 동일 Source Port를 가진 Outbound 패킷이 들어오면 어떻게 해야 할까요?

 

Port Overloading은 아주 무식한 방식입니다. Port Collision이 발생하면 기존 Binding Entry를 새것으로 덮어 써 버립니다. 즉, Port Preservation 룰을 계속 유지하겠다는 건데, 이렇게 되면 아래 그림과 같이 Host B를 위해 생성된 Binding Entry가 Host A에 의해 덮어 써 지게 됩니다.

Host A와 Host B가 NAT를 통해 Host C로 송신한 패킷이 동일한 External Address(5.5.5.5) 및 External Port(5000)를 가지게 되고, Host C가 송신하는 Inbound 패킷에 대해 NAT는 Host A로 패킷을 전달하게 되어 결국 Host B는 Host C와 통신이 불가능한 상태가 되어 버립니다. 요즘 이렇게 만든 장비는 없겠죠?

 

 

 No Port Overloading (in Port Preservation)

Port Collision 발생 시 더 이상 Port Preservation 룰을 유지 하지 않고, Internal Port와 다른 값의 External Port를 할당합니다.

 

 

RFC 4787 권고 (REQ-3): A NAT MUST NOT have a "Port assignment" behavior of "Port overloading"

 

 

1.4 Port Assignment Rule

 

본 RFC에서는 No Port Preservation을 지원하는  NAT에 대해서 "Internal Port에 대한 External Port 할당 규칙"에 대해서도 언급을 하고 있습니다. IANA(Internet Assigned Numbers Authority)에서는 다음과 같이 Port Range를 정의하고 있으며,

  • Well-Known: 0 ~ 1023 (IANA에서 표준화한 값, 예. HTTP = 80)
  • Registered: 1024 ~ 49151 (IANA에서 표준화하지 않았으나 널리 사용되고 있는 값)
  • Dynamic/Private: 49192 ~ 65535

NAT의 구현에 따라 다음과 같이 External Port 할당 규칙을 적용할 수 있다고 합니다.

  • Dynamic/Private 범위(49192 ~ 65535)의 값을 External Port로 사용하는 경우 (이 경우 하나의 공인 IP 주소로 지원할 수 있는 NAT 세션 수는 16K개로 제한)
  • Well-Known을 제외한 범위(1024 ~ 65535)의 값을 External Port로 사용하는 경우 (먼저 Dynamic/Port의 값을 사용 후 부족하면 Registered의 값 사용)

 

1.5 Mapping Timer (Binding Refresh Timer)

 

Outbound 트래픽에 의해서 생성된 NAT의 Binding Entry는 해당 엔트리를 거치는 트래픽이 있는 경우 계속 유지되지만, 만약 트래픽이 없다면 Mapping Timer(혹은 Binding Refresh Timer, Binding Lifetime이라 부름) 시간 후에 해당 엔트리는 삭제됩니다.

이 시간이 짧으면 단말(NAT friendly application)에서 NAT session 유지를 위해 Keep Alive 패킷을 자주 보내야 하고 유선, Wi-Fi 망의 경우 별 문제가 없겠으나 3G/LTE 망의 종량제 사용자 입장에서는 별로 바람직하지 않겠죠.

 

아래 그림은 NAT Mapping Timer가 2분으로 설정된 상황에서, t=0에 단말이 첫 패킷을 보내 Binding Entry 생성 후 1분 후에 다시 패킷을 보내어 Binding Entry가 2분으로 다시 refresh(reset) 됨을 보이고 있고,

 

 

이 그림은 2분이 지나도록 트래픽이 없어 NAT에 Binding Entry가 삭제됨을 보이고 있습니다.


 

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

 

 

1.6 Mapping Refresh Behavior

 

■ NAT Outbound refresh behavior of "True"

Outbound Traffic(Internal Endpoint에서 External Endpoint로의 패킷)에 의해 Mapping Timer가 refresh되는 경우

 

■ NAT Inbound refresh behavior of "True"

Inbound Traffic(External Endpoint에서 Internal Endpoint로의 패킷)에 의해 Mapping Timer가 refresh되는 경우

 

RFC 4787 권고 (REQ-6):  The NAT mapping Refresh Direction MUST have a "NAT Outbound refresh behavior" of "True"

 

황두건 2013-09-14 14:57:17
RFC 4787 권고 (REQ-1): A NAT MUST have an "Endpoint-Independent Mapping" behavior
라고 하는데요...위에서 설명하신 "Address Dependent Mapping"과 "Address and Port Dependent Mapping" 기능이
필요한 경우가 있는지요? "Endpoing" 방식 하나면 문제 없을 것 같아서 문의 드립니다.
추가로 두 단말이 모두 NAT에 속해 있는 경우 P2P 세션이 맺을 수 있게하는 기술이 있으시면 소개 부탁 드려요
^^; 추석 잘 보내세요
넷매니아즈 2013-09-16 14:07:40
기능적으로는 EIM(Endpoint-Independent Mapping)으로도 NAT 기능은 충분히 지원될 듯 합니다.
Linux 기반의 와이파이 AP들은 대부분 EIM으로 동작하고 있습니다.
다만 EIM 방식은 NAT 하단에 수많은 Internal Endpoint 단말들이 위치하게 되면 Port Collision이 발생할 수도 있겠네요.

UDP hole punching이란 단어로 구글링해보시면 NAT를 뚫고 P2P 세션을 맺는 방법에 대한 자료들을 찾을 수 있습니다.
본 NAT 연재에 마지막 글이 UDP hole punching에 대한 건데 이건 한달 정도 후 포스팅 될 듯 합니다.

황두건 님도 추석 잘 보내세요~.
전 지금 인도 출장 중이라 추석을 지내지는 못합니다만.... -.-;;
황두건 2013-09-17 13:37:25
답변 감사드립니다. ^^ 인도 출장 중이시라...타지에서 고생 많으시네요 건강 조심하세요~~
넷매니아즈 2013-09-17 14:10:09
황두건님, 따뜻한 말씀 감사드립니다.
추석 당일 동쪽 하늘 바라보고 절이라도 해야 겠습니다. ^^*
황두건 2013-10-11 16:34:06
제가 아둔해서 다시 한번더 질문 드리겠습니다. ^^;
새로이 STUN 문서 읽다가 다시 생각 나서 질문드립니다.
위에 처음 답변 주신 "EIM 방식은 NAT 하단에 수많은 Internal Endpoint 단말들이 위치하게 되면 Port Collision이 발생할 수도 있겠네요" 이 답변은 EIM 방식 보다 APDM 같은 방식을 사용할때 더 빨리 발생하지 않을까요? 따라서 NAT 기준으로는 EIM 방식이 최적의 방법 같습니다. 다만 EIM방식은 외부에 있는 방화벽같은 장비에서 동일 Source IP와 Port로 많은 트래픽이 와서 문제 될 수 있기 때문일까? 라고 생각 해봅니다.
ssamoo 2014-03-18 11:33:13
오우~! 완전 도움이 되는 자료입니다~! 정리를 너무 잘 해놓으셨네요~~!
감사히 잘 보고 갑니다~~! ^^
이영호 2015-02-10 06:56:24

NAT에 대한 멋진 글 감사합니다.

call518 2016-02-07 18:59:16

먼저, 쌈박한 설명 자료 너무 좋습니다.

NAT Traversal과 관련하여 슬라이드 자료로 나름대로 정리 및 공유도 해볼까 합니다. 이 시리즈 자료를 참고자료로 사용해도 괜찮을까요?

넷매니아즈 2016-02-11 12:28:06

작성 자료에 출처(www.netmanais.com)를 명시하시면 사용하셔도 됩니다. 감사합니다.

Thank you for visiting Netmanias! Please leave your comment if you have a question or suggestion.
View All (973)
5G (68) 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 (11) 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 (45) 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 (11) 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 파일로 다운로드

   받으실 수 있습니다. 

     
     

 

     
         
     

 

 

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