728x90
오늘은 RFC 3489와 RFC 5780에서 정의하고 있는 NAT 타입에 대해서 설명을 드리도록 하겠습니다.
지난 시간을 통해 NAT의 Mapping BehaviorFiltering Behavior에 대해 설명을 드렸는데, 그 내용을 숙지하셔야만 오늘 내용을 이해하실 수 있을 것입니다.


STUN이란?
STUN은 P2P 통신을 위해 두 단말 사이에 NAT의 존재 유무 및 NAT 타입을 식별(discover)하고 또한 NAT에 의해 변경되는 External IP 주소 및 External Port 값을 P2P 단말이 알 수 있도록 해 주는 프로토콜입니다.

본 프로토콜은 2003년도 RFC 3489(Standards)를 통해 먼저 표준화 되었고, 이후 2008년도 RFC 5389(Standard)와 2010년도 RFC 5780(Experimental)을 통해 개정되었습니다.
RFC 5389의 설명에 따르면, "Classic STUN 즉, RFC 3489에 기술된 NAT 타입 식별 알고리즘에는 오류가 있으며, 현재 시중에 나와 있는 NAT 장비를 RFC 3489에 정의된 4가지 타입으로 분류하는데 한계가 있다."라고 되어 있습니다.
이에 RFC 5389를 통해 기존 STUN 프로토콜이 수정(Binding Message의 Attribute 추가) 되었고, 또한 RFC 5780을 통해 NAT 타입 분류 재정의 및 NAT 타입 식별 알고리즘(방식)을 수정하게 되었습니다.

RFC 3489와 RFC 5389 표준에서는 STUN이란 동일 제목을 사용하고 있지만 아래와 같이 그 풀이를 다르게 하고 있습니다.
  • RFC 3489: STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)
  • RFC 5389: Session Traversal Utilities for NAT (STUN)


RFC 3489의 NAT 타입 및 RFC 5780과의 관계

■ 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)



Full Cone 타입은 RFC 5780에 Endpoint-Independent Mapping(이하 EIM)과 Endpoint-Independent Filtering(이하 EIF)으로 동작하는 방식을 말합니다.
  • Mapping Behavior: Outbound 패킷의 (1) Source IP, (2) Source Port만 동일하다면 Destination IP, Destination Port에 상관없이 같은 Port Mapping 값(Translated Port = 1000)을 사용
  • Filtering Behavior: Inbound 패킷에 대해 (1) Destination IP, (2) Destination Port만 검사하여 패킷의 허용 여부를 판단하고, External Endpoint의 소스 정보 즉, Source IP와 Source Port 값은 상관하지 않음




■ 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)



Restricted Cone 타입은 RFC 5780에 EIM과 Address-Dependent Filtering(이하 ADF)으로 동작하는 방식을 말합니다.
  • Mapping Behavior: Full Con과 동일
  • Filtering Behavior: Inbound 패킷에 대해 (1) Destination IP, (2) Destination Port 그리고 (3) Source IP를 검사하여 패킷의 허용 여부를 판단하고, External Endpoint의 Source Port 값은 상관하지 않음




■ 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)



Port Restricted Cone 타입은 RFC 5780에 EIM과 Address and Port-Dependent Filtering(이하 APDF)으로 동작하는 방식을 말합니다.
  • Mapping Behavior: Full Con과 동일
  • Filtering Behavior: Inbound 패킷에 대해 (1) Destination IP, (2) Destination Port 그리고 (3) Source IP, (4) Source Port를 검사하여 패킷의 허용 여부를 판단함




■ 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)



Symmetric 타입은 RFC 5780에 Address and Port-Dependent Mapping(이하 APDM)과 APDF로 동작하는 방식을 말합니다.
  • Mapping Behavior: Outbound 패킷의 (1) Source IP, (2) Source Port 그리고 (3) Destination IP, (4) Destination Port가 모두 동일해야 같은 Port Mapping 값을 사용
  • Filtering Behavior: Port Restricted Con과 동일




요약
아래 그림은 RFC 5780에서 정의하고 있는 9개의 NAT 타입과 RFC 3489에서 정의하고 있는 4개의 NAT 타입 간의 관계를 보이고 있습니다.




728x90

'Network' 카테고리의 다른 글

TCP Tahoe  (0) 2014.10.27
IGP 프로토콜  (0) 2014.10.19
IPV4 헤더 TTL 필드  (0) 2014.10.17
데이터통신  (0) 2014.05.01
dhcp  (0) 2014.03.20

+ Recent posts