Path MTU Discovery
Path MTU Discovery (PMTUD) is a standardized technique in computer networking for determining the maximum transmission unit (MTU) size on the network path between two Internet Protocol (IP) hosts, usually with the goal of avoiding IP fragmentation. PMTUD was originally intended for routers in Internet Protocol Version 4 (IPv4).[1] However, all modern operating systems use it on endpoints. In IPv6, this function has been explicitly delegated to the end points of a communications session.[2] As an extension to the standard path MTU discovery, a technique called Packetization Layer Path MTU Discovery works without support from ICMP.[3]
Implementation
[edit]For IPv4 packets, Path MTU Discovery works by setting the Don't Fragment (DF) flag bit in the IP headers of outgoing packets. Then, any device along the path whose MTU is smaller than the packet will drop it, and send back an Internet Control Message Protocol (ICMP) Fragmentation Needed (Type 3, Code 4) message containing its MTU, allowing the source host to reduce its path MTU appropriately. The process is repeated until the MTU is small enough to traverse the entire path without fragmentation.
As IPv6 routers do not fragment packets, there is no Don't Fragment option in the IPv6 header. For IPv6, Path MTU Discovery works by initially assuming the path MTU is the same as the MTU on the link layer interface where the traffic originates. Then, similar to IPv4, any device along the path whose MTU is smaller than the packet will drop the packet and send back an ICMPv6 Packet Too Big (Type 2) message containing its MTU, allowing the source host to reduce its path MTU appropriately. The process is repeated until the MTU is small enough to traverse the entire path without fragmentation.[4]
If the path MTU changes after the connection is set up and becomes lower than the previously determined path MTU, the first large packet will cause an ICMP error and the new, lower path MTU will be found. If the path changes and the new path MTU is larger, the source will not learn about the increase, because all routers along the new path will be capable of relaying all packets that the source sends using the originally determined, lower path MTU.[5][6][4]
Problems
[edit]Many network security devices block all ICMP messages for perceived security benefits, including the errors that are necessary for the proper operation of PMTUD. This can result in connections that complete the TCP three-way handshake correctly but then hang when attempting to transfer data. This state is referred to as a black hole connection.[7]
Some implementations of PMTUD attempt to circumvent this problem by inferring that large payload packets have been dropped due to MTU rather than link congestion. One such scheme is standardized under RFC 8899, Datagram Packetization Layer Path MTU Discovery (DPLPMTUD).[3] Upon loss of connectivity, DPLPMTUD utilizes probe packets of controlled sizes to probe the MTU of the path. Acknowledgement of a probe packet indicates that the path MTU is at least the size of that packet. Usage of DPLPMTUD is standardized in QUIC.[8] However, in order for transport layer protocols to operate most efficiently, ICMP Unreachable messages (type 3) should still be permitted.
Some routers, including the Linux kernel[9] and Cisco,[10] provide an option to reduce the maximum segment size (MSS) advertised in the TCP handshake as a workaround. This is known as MSS clamping.
Another problem is when networks administrators don't properly update the MTU between 2 adjacent layer 3 hops if the link between these hops is composed of multiple layer 2 segments with switches between them. Usually the MTU on the outgoing L3 interface is taken from the first L2 segment. But if the second or further segment has a lower MTU the switch that is between will just silently drop the packet without reporting back any ICMP (because only layer 3 hops can generate ICMP "packet too big"). So, in this case admins should update the MTU for each outgoing L3 interface to the minimum MTU of the layer 2 segments used until the next L3 hop.
References
[edit]- ^ J. Mogul; S. Deering (November 1990). Path MTU Discovery. Network Working Group. doi:10.17487/RFC1191. RFC 1191. Draft Standard. 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. Internet Standard 87. Obsoletes RFC 1981.
- ^ a b G. Fairhurst; T. Jones; M. Tüxen; I. Rüngeler; T. Völker (September 2020). Packetization Layer Path MTU Discovery for Datagram Transports. Internet Engineering Task Force (IETF). doi:10.17487/RFC8899. ISSN 2070-1721. RFC 8899. Proposed Standard. Updates RFC 4821, 4960, 6951, 8085 and 8261.
- ^ a b Davies, Joseph (2012). Understanding IPv6 (3rd ed.). Redmond: Microsoft Press. pp. 146–147. ISBN 978-0735659148. OCLC 810455372.
- ^ E. Comer, Douglas (2014). Internetworking with TCP/IP Volume 1 (6th ed.). Pearson. pp. 133–134. ISBN 0-13-608530-X.
- ^ linux source code (ipv4) and linux source code (ipv6) see line with "mtu_expires" 10 * 60 seconds
- ^ K. Lahey (September 2000). TCP Problems with Path MTU Discovery. Network Working Group. doi:10.17487/RFC2923. RFC 2923. Informational.
- ^ J. Iyengar; M. Thomson, eds. (May 2021). QUIC: A UDP-Based Multiplexed and Secure Transport. Internet Engineering Task Force. doi:10.17487/RFC9000. ISSN 2070-1721. RFC 9000. Proposed Standard.
- ^ "Mangling packet headers - nftables wiki". wiki.nftables.org. Retrieved 2024-07-03.
- ^ "Ethernet MTU and TCP MSS Adjustment Concept for PPPoE Connections". Cisco. Retrieved 2024-07-03.