4. Application Level Gateway

 

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

 

 

 

5. Deterministic Properties

 

■ Non-Deterministic NAT

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

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

 

평소 NAT는 "Endpoint-Independent Mapping with 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 메시지를 전달하라고 되어 있습니다.

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로 전송하는 경우

 

이상으로 총 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를 보임)