5. Layering

Packetization Layer Path MTU Discovery is most easily implemented by splitting its functions between layers. The IP layer is the best place to keep shared state, collect the ICMP messages, track IP header sizes, and manage MTU information provided by the link layer interfaces. However, the procedures that PLPMTUD uses for probing and verification of the Path MTU are very tightly coupled to features of the Packetization Layers, such as data recovery and congestion control state machines.

5.1. Accounting for Header Sizes

The way in which PLPMTUD operates across multiple layers requires a mechanism for accounting header sizes at all layers between IP and the Packetization Layer (inclusive). When transmitting non-probe packets, it is sufficient for the Packetization Layer to ensure an upper bound on final IP packet size, so as not to exceed the current effective Path MTU.

5.2. Storing PMTU Information

This memo uses the concept of a "flow" to define the scope of the Path MTU Discovery algorithms. For many implementations, a flow would naturally correspond to an instance of each protocol (i.e., each connection or session). The observed PMTU (eff_pmtu in Section 7.1) MAY be shared between different flows with a common path representation.

The IP layer SHOULD be used to store the cached PMTU value and other shared state such as MTU values reported by ICMP PTB messages.

An implementation MAY use the destination address as the local representation of a path. Network or subnet numbers MUST NOT be used as representations of a path.

5.3. Accounting for IPsec

This document does not take a stance on the placement of IP Security (IPsec) [RFC2401], which logically sits between IP and the Packetization Layer.

5.4. Multicast

In the case of a multicast destination address, copies of a packet may traverse many different paths to reach many different nodes.

Minimally, an implementation MAY maintain a single MTU value to be used for all multicast packets originated from the node.