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]

PMTUD is standardized for IPv4 in RFC 1191 and for IPv6 in RFC 8201 (which obsoleted RFC 1981, the previous IPv6 PMTUD standard).[3] RFC 4821[4] describes an extension to the techniques that works without support from Internet Control Message Protocol. RFC 8899[5] updates RFC 4821 by introducing guidelines for using Packetization Layer PMTUD with UDP and SCTP.

Implementation

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.

IPv6 routers do not support fragmentation and consequently don't support the Don't Fragment option. 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.[6]

If the Path MTU changes after the connection is set up and is 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. Conversely, if PMTUD finds that the path allows a larger MTU than is possible on the lower link, the OS will periodically reprobe to see if the path has changed and now allows larger packets. On both Linux and Windows this timer is set by default to ten minutes.[7][8]

Problems

Many so-called network security devices block all ICMP messages for perceived security benefits,[9] including the errors that are necessary for the proper operation of PMTUD; note this is despite the referenced article specifically describing good ICMP like that required for PMTUD to operate correctly. This can result in connections that complete the TCP three-way handshake correctly, but then hang when data are transferred. This state is referred to as a black hole connection.[10]

Some implementations of PMTUD attempt to prevent this problem by inferring that large payload packets have been dropped due to MTU rather than because of link congestion. However, in order for the Transmission Control Protocol (TCP) to operate most efficiently, ICMP Unreachable messages (type 3) should be permitted. A robust method for PMTUD that relies on TCP or another protocol to probe the path with progressively larger packets has been standardized in RFC 4821.

A workaround used by some routers is to change the maximum segment size (MSS) of all TCP connections passing through links with MTU lower than the Ethernet default of 1500. This is known as MSS clamping.[11]

References
  1. RFC 1191, Path MTU Discovery, J. Mogul, S. Deering (November 1990)
  2. RFC 1981, Path MTU Discovery for IP version 6, J. McCann, S. Deering, J. Mogul (August 1996)
  3. Mogul, Jeffrey; Hinden, Robert (July 2017). "Path MTU Discovery for IP version 6". tools.ietf.org. ISSN 2070-1721. Retrieved April 15, 2019.
  4. RFC 4821, Packetization Layer Path MTU Discovery, M. Mathis, J. Heffner (March 2007)
  5. RFC 8899, Packetization Layer Path MTU Discovery for Datagram Transports, G. Fairhurst, T. Jones, M. Tüxen, I. Rüngeler, T. Völker (September 2020)
  6. Davies, Joseph (2012). Understanding IPv6 (3rd ed.). Microsoft Press. pp. 146–147. ISBN 9780735659148.
  7. linux source code (ipv4) and linux source code (ipv6) see line with "mtu_expires" 10 * 60 seconds
  8. Davies, Joseph (2012). Understanding IPv6 (3rd ed.). Redmond: Microsoft Press. p. 147. ISBN 978-0735659148. OCLC 810455372.
  9. Michael Mullins (2003-10-21). "Prevent hacker probing by blocking ICMP traffic". Retrieved 2013-07-12.
  10. RFC 2923, TCP Problems with Path MTU Discovery, K. Lahey (September 2000)
  11. "Circumventing Path MTU Discovery issues with MSS Clamping (for ADSL, cable, PPPoE & PPtP users)". lartc.org. Retrieved 2019-04-15.
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.