경로 MTU 검색
Path MTU DiscoveryPMTUD(Path MTUD Discovery)는 두 IP(Internet Protocol) 호스트 사이의 네트워크 경로에서 최대 전송 단위(MTU) 크기를 결정하기 위한 컴퓨터 네트워킹의 표준화된 기법이며, 대개 IP 단편화를 피한다는 목표를 가지고 있다. PMTUD는 원래 IPv4(Internet Protocol Version 4)에서 라우터를 위한 것이었다.[1] 그러나 모든 최신 운영 체제는 엔드포인트에서 그것을 사용한다. IPv6에서 이 기능은 통신 세션의 끝점에 명시적으로 위임되었다.[2] 표준 경로 MTU 검색의 확장자로서, 패킷화 계층 경로 MTU 검색이라는 기술은 ICMP의 지원 없이 작동한다.[3]
실행
IPv4 패킷의 경우 경로 MTU 검색은 송신 패킷의 IP 헤더에서 DF 플래그 비트를 설정하여 작동한다. 그런 다음 MTU가 패킷보다 작은 경로에 있는 모든 디바이스가 이를 삭제하고 MTU가 포함된 ICMP(Internet Control Message Protocol) 조각화 필요(Type 3, Code 4) 메시지를 다시 전송하여 소스 호스트가 경로 MTU를 적절하게 줄일 수 있도록 한다. 이 프로세스는 MTU가 조각화 없이 전체 경로를 통과할 수 있을 정도로 작을 때까지 반복된다.
IPv6 라우터는 단편화를 지원하지 않으므로 Don't Fragment 옵션을 지원하지 않는다. IPv6의 경우 경로 MTU 검색은 처음에 트래픽이 발생하는 링크 계층 인터페이스의 MTU와 경로 MTU가 동일하다고 가정하여 작동한다. 그런 다음 IPv4와 마찬가지로 MTU가 패킷보다 작은 경로에 있는 모든 디바이스가 패킷을 삭제하고 해당 MTU가 포함된 ICMPv6 Packet Too Big(Type 2) 메시지를 다시 전송하여 소스 호스트가 경로 MTU를 적절하게 줄일 수 있게 한다. 이 프로세스는 MTU가 조각화 없이 전체 경로를 통과할 수 있을 정도로 작을 때까지 반복된다.[4]
연결이 설정된 후 경로 MTU가 변경되고 이전에 결정된 경로 MTU보다 낮으면 첫 번째 대형 패킷이 ICMP 오류를 발생시키고 새 경로 MTU가 발견된다. 반대로 PMTUD가 경로가 하위 링크에서 가능한 큰 MTU를 허용한다는 것을 발견하면 OS는 경로가 변경되었는지 여부를 정기적으로 재프로그래밍하여 이제 더 큰 패킷을 허용한다. Linux와 Windows 모두에서 이 타이머는 기본적으로 10분으로 설정된다.[5][6]
문제
많은 네트워크 보안 장치는 PMTUD의 적절한 작동에 필요한 오류를 포함하여 인식된 보안상의 이점을 위해 모든 ICMP 메시지를 차단한다. 이로 인해 TCP 3방향 핸드셰이크가 올바르게 완료되지만 데이터가 전송될 때 연결이 중단될 수 있다. 이 상태를 블랙홀 연결이라고 한다.[7]
PMTUD의 일부 구현에서는 링크 혼잡 때문이 아니라 MTU로 인해 대형 페이로드 패킷이 삭제되었음을 유추하여 이 문제를 방지하려고 한다. 단, TCP(Transmission Control Protocol)가 가장 효율적으로 작동하기 위해서는 ICMP 불가 메시지(타입 3)가 허용되어야 한다. 점차적으로 더 큰 패킷으로 경로를 탐색하기 위해 TCP 또는 다른 프로토콜에 의존하는 PMTUD를 위한 강력한 방법이 RFC 4821에서 표준화되었다.
일부 라우터에 의해 사용되는 해결책은 이더넷 기본값인 1500보다 낮은 MTU로 링크를 통과하는 모든 TCP 연결의 최대 세그먼트 크기(MSS)를 변경하는 것이다. 이것은 MSS 클램핑이라고 알려져 있다.[8]
참조
- ^ J. Mogul; S. Deering (November 1990). Path MTU Discovery. Network Working Group. doi:10.17487/RFC1191. RFC 1191. Obsoletes RFC 1063.
- ^ J. McCann; S. Deering; J. Mogul (July 2017). R. Hinden (ed.). Path MTU Discovery for IP version 6. IETF. doi:10.17487/RFC8201. STD 87. RFC 8201. Obsoletes RFC 1981.
- ^ G. Fairhurst; T. Jones; M. Tüxen; I. Rüngeler; T. Völker (September 2020). Packetization Layer Path MTU Discovery for Datagram Transports. IETF. doi:10.17487/RFC8899. ISSN 2070-1721. RFC 8899. RFC 4821, 4960, 6951, 8085 및 8261 업데이트.
- ^ Davies, Joseph (2012). Understanding IPv6 (3rd ed.). Microsoft Press. pp. 146–147. ISBN 9780735659148.
- ^ Linux 소스 코드(source code) 및 Linux 소스 코드(source code)(source code)는 "inflines_inflines" 10 * 60초 참조
- ^ Davies, Joseph (2012). Understanding IPv6 (3rd ed.). Redmond: Microsoft Press. p. 147. ISBN 978-0735659148. OCLC 810455372.
- ^ K. Lahey (September 2000). TCP Problems with Path MTU Discovery. Network Working Group. doi:10.17487/RFC2923. RFC 2923.
- ^ "Circumventing Path MTU Discovery issues with MSS Clamping (for ADSL, cable, PPPoE & PPtP users)". lartc.org. Retrieved 2019-04-15.