Path MTU Discovery for IP version 6
obsoleted by
- rfc-8201 — Path MTU Discovery for IP version 6
Extracted elements (24)
IPv6 has no Don't Fragment (DF) bit and no MTU plateau tables, unlike the IPv4 Path MTU Discovery mechanism in RFC 1191. All Packet Too Big messages in IPv6 report the actual MTU of the constricting link, eliminating the need for old-style messages or plateau tables.
It is suggested that the IP layer store PMTU information and that the ICMP layer process received Packet Too Big messages, rather than implementing Path MTU Discovery per packetization layer. This avoids duplicating the implementation for each transport and allows PMTU information to be shared across layers.
Path MTU Discovery must be performed even when a node believes a destination is on the same link, because a neighboring router acting as a Neighbor Discovery proxy can make a multi-hop destination appear directly connected.
PMTU aging is asymmetric: stale values that are too large are self-correcting (the next oversized packet elicits a Packet Too Big message), but stale values that are too small have no self-correction mechanism, so periodic reset to first-hop MTU is required.
A TCP retransmission triggered by a Packet Too Big message should not change the congestion window but should trigger the slow-start mechanism. The TCP layer must recognize when a Packet Too Big notification actually decreases the PMTU already used for the connection, and ignore duplicate notifications to avoid exponential growth in superfluous retransmissions.
If Path MTU Discovery changes the segment size during a TCP connection, the maximum transmission window should be adjusted to the greatest multiple of the new segment size that is less than or equal to the sender's buffer space, since window size may no longer be an exact multiple of segment size.
NFS over UDP should use Path MTU Discovery when routers are involved. Because a single NFS operation cannot be split across multiple UDP datagrams, certain operations require a minimum payload that may exceed the discovered PMTU; implementations should not reduce the payload below this threshold, accepting IP-layer fragmentation instead.
The TCP MSS option value sent to a peer is independent of the local PMTU. The TCP layer must also store the MSS received from its peer and must not send any segment larger than that peer MSS, regardless of the PMTU.
Transport protocols such as ISO TP4 that cannot repacketize during retransmission may fall back to IP-layer fragmentation for the retransmitted segment; subsequent first-time transmissions should be sized to the Path MTU.
A node MUST NOT increase its estimate of the Path MTU in response to the contents of a Packet Too Big message, because such a message may be stale, injected as part of a denial-of-service attack, or the result of multiple paths with different PMTUs.
A node MUST NOT reduce its estimate of the Path MTU below the IPv6 minimum link MTU. If a Packet Too Big message reports a next-hop MTU less than that minimum, the node must include a Fragment header in subsequent packets rather than shrinking below the minimum.
After receiving a Packet Too Big message, a node MUST attempt to avoid eliciting more such messages and MUST reduce the size of the packets it is sending along the path. The node MUST force the Path MTU Discovery process to end rather than continue sending oversized packets.
An upper layer MUST NOT retransmit data in response to an increase in the PMTU estimate, since increases never come in response to an indication of a dropped packet.
IPv6 nodes SHOULD implement Path MTU Discovery in order to discover and take advantage of paths with PMTU greater than the IPv6 minimum link MTU. A minimal implementation (e.g., in a boot ROM) may choose to omit it.
Nodes using Path MTU Discovery MUST detect decreases in PMTU as fast as possible. Nodes MAY detect increases in PMTU, but this MUST be done at infrequent intervals; an attempt to detect an increase MUST NOT be done less than 5 minutes after a Packet Too Big message has been received for the given path. The recommended timer is 10 minutes.
When a node receives a Packet Too Big message, it MUST reduce its estimate of the PMTU for the relevant path based on the MTU field in the message.
A management interface should allow operators to disable Path MTU Discovery on a given path (causing the IP layer to limit packets to the IPv6 minimum link MTU), change the cached PMTU value for a path, and adjust the stale-PMTU aging timeout.
For multicast destinations, copies of a packet may traverse many different paths, each with a different PMTU. Multiple Packet Too Big messages may be received; the minimum PMTU across all those paths determines the size of subsequent packets to the multicast destination.
Path MTU Discovery works by having a source node initially assume the PMTU equals the MTU of the first hop. When an intermediate node discards an oversized packet, it returns an ICMPv6 Packet Too Big message containing the constricting link's MTU, and the source reduces its PMTU estimate accordingly.
PMTU information may be stored per destination address (integrating with the Neighbor Discovery destination cache), per flow id for finer granularity when flows are in use, or per source route for source-routed packets. The initial PMTU value is assumed to be the MTU of the first-hop link.
Stale PMTU values are aged: when a PMTU value has not been decreased for approximately 10 minutes, the PMTU estimate is reset to the MTU of the first-hop link and packetization layers are notified, triggering a fresh Path MTU Discovery cycle. Implementations should allow configuring the timeout duration, including setting it to infinity.
The MMS_S (maximum send transport-message size) is the value packetization layers use to size messages; it is derived from the PMTU by subtracting the IPv6 header size plus any space reserved by the IP layer for additional headers.
When a Packet Too Big message is received containing a Routing header, the destination address is taken from the Routing header's last address (Address[n]) if Segments Left is greater than zero, or from the IPv6 Destination Address field if Segments Left equals zero.
A malicious party can send a false Packet Too Big message reporting a PMTU larger than reality. Because a node must never raise its PMTU estimate based on a Packet Too Big message (only lower it), this attack is largely mitigated by the requirement in Section 4.