Path MTU Discovery: Difference between revisions
No edit summary |
|||
| Line 10: | Line 10: | ||
Some implementations of PMTUD attempt to avoid this problem by inferring that large payload packets have been dropped due to MTU rather than because of link congestion. However, in order for [[Transmission Control Protocol]] (TCP) to operate most efficiently, ICMP unreachables (type 3) should be permitted. A robust method for PMTUD that relies on TCP or some other packetization layer to probe the path with progressively larger packets has been standardized in RFC 4821 (Packetization Layer Path MTU Discovery). |
Some implementations of PMTUD attempt to avoid this problem by inferring that large payload packets have been dropped due to MTU rather than because of link congestion. However, in order for [[Transmission Control Protocol]] (TCP) to operate most efficiently, ICMP unreachables (type 3) should be permitted. A robust method for PMTUD that relies on TCP or some other packetization layer to probe the path with progressively larger packets has been standardized in RFC 4821 (Packetization Layer Path MTU Discovery). |
||
A workaround used by some routers is to change the [[maximum segment size]] (MSS) of all connections passing through links with MTU lower than the [[Ethernet]] default of 1500. This is known as ''MSS clamping''. |
A workaround used by some routers is to change the [[maximum segment size]] (MSS) of all connections passing through links with MTU lower than the [[Ethernet]] default of 1500. This is known as ''MSS clamping''.{{citation needed}} |
||
==External links== |
==External links== |
||
Revision as of 16:49, 7 July 2010
Path MTU discovery (PMTUD) is a 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.
Path MTU discovery works by setting the DF (Don't Fragment) option 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 ICMP "Fragmentation Needed" (Type 3, Code 4) message containing its MTU, allowing the source host to reduce its path MTU appropriately. The process repeats until the MTU is small enough to traverse the entire path without fragmentation.
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 what is possible on the lower link, the OS will periodically reprobe to see if the path has changed and now allows larger packets. On Linux this timer is set by default to ten minutes.[citation needed]
Problems with PMTUD
Many network security devices block all ICMP messages for security reasons[1], including the errors that are necessary for PMTUD to work. This can result in connections that complete the TCP three-way handshake correctly, but then hang when data is transferred. This state is referred to as a "black hole connection".
Some implementations of PMTUD attempt to avoid this problem by inferring that large payload packets have been dropped due to MTU rather than because of link congestion. However, in order for Transmission Control Protocol (TCP) to operate most efficiently, ICMP unreachables (type 3) should be permitted. A robust method for PMTUD that relies on TCP or some other packetization layer to probe the path with progressively larger packets has been standardized in RFC 4821 (Packetization Layer Path MTU Discovery).
A workaround used by some routers is to change the maximum segment size (MSS) of all connections passing through links with MTU lower than the Ethernet default of 1500. This is known as MSS clamping.[citation needed]
External links
- Internet Engineering Task Force Path MTU Discovery (pmtud) Working Group
- RFC 1191 - Path MTU Discovery
- RFC 1981 - Path MTU Discovery for IP version 6
- RFC 2923 - TCP Problems with Path MTU Discovery
- RFC 4821 - Packetization Layer Path MTU Discovery