Path MTU Discovery for IP version 6
Extracted elements (24)
For multicast destinations, the minimum PMTU across all paths to all receivers determines the packet size sent, since a single packet may traverse many different paths and generate multiple Packet Too Big messages each reporting a different next-hop MTU.
IPv6 has no Don't Fragment (DF) bit (unlike IPv4/RFC 1191) and all Packet Too Big messages report the MTU of the constricting link, eliminating the need for MTU plateau tables used in IPv4 PMTUD.
Packetization layers are encouraged to avoid sending messages requiring source fragmentation because fragmentation degrades performance and reliability. When source fragmentation is not desired, EMTU_S is set to PMTU and the upper layer must limit its message sizes accordingly.
PMTU information is suggested to be stored at the IP layer (not the packetization layer) so it can be shared across different transport connections and protocols, avoiding duplicated implementation effort and allowing long-term caching independent of connection state.
PMTU values should be aged (invalidated after roughly 10 minutes without a decrease) so that increases in the actual path MTU can be discovered. Stale values that are too small have no self-correcting mechanism unlike stale values that are too large.
For transport protocols that cannot repacketize on retransmission, the IP layer may fragment the original segment during retransmission. Subsequent new segments should be no larger than allowed by the Path MTU.
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 proxy may make a multi-hop destination appear directly connected, and the actual PMTU may be lower than the link MTU.
The TCP MSS option value sent by a node reflects EMTU_R (the receiver's reassembly limit) and is independent of the sender's PMTU. The peer uses the received MSS as an upper bound on segment size regardless of its own PMTU value.
When ICMPv6 filtering prevents reception of PTB messages, PMTUD fails silently and can cause black-hole connections. Packetization Layer Path MTU Discovery (RFC 4821) does not rely on ICMPv6 and is more robust in filtered environments.
A loss caused by a PMTU probe indicated by reception of a Packet Too Big message must not be considered a congestion notification, and hence the congestion window may not change.
A node must not increase its estimate of the Path MTU in response to the contents of a Packet Too Big message, as such a message might be stale, forged, or reflect multipath conditions.
A node must not reduce its estimate of the Path MTU below the IPv6 minimum link MTU on receipt of a Packet Too Big message. If a Packet Too Big message reports a next-hop MTU less than the IPv6 minimum link MTU, the node must discard it.
A packetization layer must use the PMTU for the path(s) in use by a connection and should not send segments that would result in packets larger than the PMTU, except for PMTU probes (which must not be fragmented to the PMTU).
A TCP implementation must store the Maximum Segment Size (MSS) received from its peer (representing EMTU_R) and must not send any segment larger than this MSS, regardless of the PMTU.
After receiving a Packet Too Big message, a node must attempt to avoid eliciting more such messages and must reduce the size of packets it is sending along the path.
An attempt to detect a PMTU increase by sending a packet larger than the current estimate must not be done less than 5 minutes after a Packet Too Big message has been received for the given path. The recommended timer setting is 10 minutes.
Nodes not implementing Path MTU Discovery must use the IPv6 minimum link MTU as the maximum packet size.
Nodes should appropriately validate the payload of ICMPv6 PTB messages to ensure they were received in response to traffic actually transmitted by the node, per RFC 4443.
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 value in the message.
EMTU_S (Effective MTU for sending) is the largest IP packet that can be sent; MMS_S (maximum send transport-message size) is EMTU_S minus the IPv6 header size. When source fragmentation is not desired, EMTU_S is set to PMTU.
Path MTU Discovery uses ICMPv6 Packet Too Big (PTB) messages to determine the MTU of a path. When a router cannot forward a packet due to its size, it discards the packet and returns a PTB message containing the MTU of the constricting link.
PMTU information may be keyed by destination address, flow id (source address plus non-zero flow label), or source route. Storing per-destination or per-flow allows optimally sized packets; a single global PMTU is the minimal implementation.
A malicious party can send false Packet Too Big messages claiming a PMTU larger than reality, causing temporary packet drops and black-hole connections. The defense is that a node must never raise its PMTU estimate based on a PTB message.
PMTU discovery iterates through states: (1) assume PMTU equals first-hop link MTU; (2) send packets; (3) on receiving PTB, reduce PMTU estimate and reduce packet size; (4) periodically probe for PMTU increase (no sooner than 5 minutes after last PTB). The process ends when the estimate is at or below the actual PMTU.