6. Specification of Protocol-Specific Methods
DPLPMTUD requires protocol-specific details to be specified for each PL that uses it.
The first subsection provides guidance on how to implement the DPLPMTUD method as a part of an application using UDP or UDP-Lite. This guidance is also applicable to other datagram services that do not include a specific transport protocol (such as tunnel encapsulation). The following subsections describe how to implement DPLPMTUD as a part of a transport service, allowing applications that use this service to benefit from discovery of the PLPMTU without needing to implement this method themselves when using SCTP and QUIC.
6.1. Application Support for DPLPMTUD with UDP or UDP-Lite
The current specifications of UDP [RFC0768] and UDP-Lite [RFC3828] do not define a method in the RFC series that supports PLPMTUD. In particular, the UDP transport does not provide the transport features required to implement datagram PLPMTUD.
The DPLPMTUD method can be implemented as part of an application directly or indirectly built upon UDP or UDP-Lite but relies on higher-layer protocol features to implement the method [BCP145].
Some primitives used by DPLPMTUD might not be available via the datagram API (e.g., the ability to access the PLPMTU from the IP-layer cache or the ability to interpret received PTB messages).
In addition, it is RECOMMENDED that PMTU discovery is not performed by multiple protocol layers. When the underlying transport system provides this function, an application SHOULD avoid using DPLPMTUD. There are benefits in a generic method to manage the PLPMTU, both in sharing state between processes and in coordinating probing for different PL instances.
6.1.1. Application Request
An application needs an application-layer protocol mechanism (such as a message acknowledgment method) to request a response from the destination endpoint. The method SHOULD allow the sender to check values returned in the response to provide additional protection against injection of data from off the path [BCP145]. Suitable methods include parameters known only to the two endpoints, such as a session ID or an initialized sequence number.
6.1.2. Application Response
An application needs an application-layer protocol mechanism to communicate a response from the destination endpoint. This response can indicate that a probe has successfully traversed the path but can also indicate that some (or all) packets have failed to reach the destination.
6.1.3. Sending Application Probe Packets
Probe packets can carry an application data block but there is a risk that successful transmission of this data is at risk when used for probing. Some applications might prefer to use probe packets that do not carry an application data block to avoid disruption in data transmission.
6.1.4. Initial Connectivity
An application that has no other higher-layer information confirming connectivity with the remote peer SHOULD implement a mechanism for connection using acknowledged probe packets before entering the BASE state.
6.1.5. Validating the Path
An application that has no other higher-layer information confirming that datagrams are correctly delivered SHOULD implement the CONFIRMATION_TIMER to periodically send probe packets when in the SEARCH_COMPLETE state.
6.1.6. Handling of PTB Messages
Applications that are able to and wish to receive PTB messages MUST perform ICMP validation specified in Section 5.2 of [BCP145]. This requires the application to check each received PTB message to validate it was received in response to transmitted traffic and that the reported PL_PTB_SIZE is less than the size currently probed (see Section 4.6.2). A validated PTB message MAY be utilized as an input to the DPLPMTUD algorithm but MUST NOT be used directly to set the PLPMTU.
6.2. DPLPMTUD for SCTP
Section 10.2 of [RFC4821] specifies a recommended PLPMTUD probing method for SCTP, and Section 7.3 of [RFC4960] recommends that an endpoint apply the techniques in RFC 4821 on a per-destination-address basis. The DPLPMTUD specification continues the practice of the PL discovering the PMTU but updates RFC4960 to RECOMMEND use of the method specified in this document: The RECOMMENDED method to generate probes is to add a chunk consisting only of padding to an SCTP message. The PAD chunk defined in [RFC4820] SHOULD be attached to a minimum-length HEARTBEAT (HB) chunk to build a probe packet. This makes the probing independent of the transfer of user messages and independent of congestion control or flow control. This is preferred to using DATA chunks (bundled, if needed, with other control chunks) as path probes.
Section 6.9 of [RFC4960] describes the PL sender segmenting user messages into DATA chunks when using SCTP. This notes that once an SCTP message is sent, it cannot be resegmented. [RFC4960] describes a method of retransmitting DATA chunks when the MPS is reduced, and Section 6.9 of [RFC4960] describes using IP fragmentation in this case. This document does not make changes to this.
6.2.1. SCTP/IPv4 and SCTP/IPv6
6.2.1.1. Initial Connectivity
The base protocol is specified in [RFC4960]. This provides an Acknowledged PL. Therefore, a sender can enter the BASE state once the association has been confirmed.
6.2.1.2. Sending SCTP Probe Packets
The probe packet consists of an SCTP common header, a HEARTBEAT chunk, and a PAD chunk. The PAD chunk is used to control the length of the probe packet. The HEARTBEAT chunk is used to trigger the sending of a HEARTBEAT ACK chunk. Reception of a HEARTBEAT ACK chunk acknowledges the reception of a successful probe. Successful probes update the association and path counters, but unsuccessful probes are disregarded (assumed to be the result of choosing too large a PLPMTU).
The SCTP sender needs to be able to determine the total size of a probe packet. The HEARTBEAT chunk can carry a Heartbeat Information parameter that, in addition to the information suggested in [RFC4960], also includes the size of the probe to help implementations associate a HEARTBEAT ACK with the size of probe sent. Other methods are possible, such as sending a random number and verifying that the returned information also contains the corresponding random number.
The length of the PAD chunk is computed by reducing the size of the SCTP common header and the HEARTBEAT chunk. The payload of the PAD chunk contains arbitrary data. When transmitted over IP, the PMTU size also includes the IPv4 or IPv6 header.
Probing can start directly after the PL handshake; this can be done before data is sent. Assuming this behavior (i.e., PMTU is less than or equal to the interface MTU), this process will require several round-trip time periods, depending on the number of DPLPMTUD probes sent. The Heartbeat timer can be used to implement the PROBE_TIMER.
6.2.1.3. Validating the Path with SCTP
Since SCTP provides an Acknowledged PL, a sender MUST NOT implement the CONFIRMATION_TIMER when in the SEARCH_COMPLETE state.
6.2.1.4. PTB Message Handling by SCTP
Normal ICMP validation MUST be performed as specified in Appendix C of [RFC4960]. This requires the first 8 bytes of the SCTP common header to be quoted in the payload of the PTB message, which can be the case for ICMPv4 and is usually the case for ICMPv6.
When a PTB message has been validated, the PL_PTB_SIZE calculated from the PTB_SIZE reported in the PTB message SHOULD be used with the DPLPMTUD algorithm, providing the reported PL_PTB_SIZE is less than the current probe size (see Section 4.6).
6.2.2. DPLPMTUD for SCTP/UDP
UDP encapsulation of SCTP is specified in [RFC6951].
This specification updates the reference to RFC 4821 in Section 5.6 of RFC 6951 to refer to this document (RFC 8899). RFC 6951 is updated by adding the following sentence at the end of Section 5.6 of RFC 6951:
The RECOMMENDED method to determine the Path MTU is specified in RFC 8899.
6.2.2.1. Initial Connectivity
A sender can enter the BASE state once the SCTP association has been confirmed.
6.2.2.2. Sending SCTP/UDP Probe Packets
Datagram probing can be performed as specified in Section 6.2.1.2. The size of probe packets includes the 8-byte UDP header. This has to be taken into account when a probe packet is padded using a PAD chunk.
6.2.2.3. Validating the Path with SCTP/UDP
SCTP provides an Acknowledged PL; therefore, a sender does not implement the CONFIRMATION_TIMER when in the SEARCH_COMPLETE state.
6.2.2.4. Handling of PTB Messages by SCTP/UDP
ICMP validation of PTB messages MUST be performed as specified in Appendix C of [RFC4960]. This requires the first 8 bytes of the SCTP common header to be present in the PTB message, which could be the case for ICMPv4 (but note the UDP header consumes a part of the quoted packet header) and is usually the case for ICMPv6. When validation is completed, the PL_PTB_SIZE calculated from the PTB_SIZE in the PTB message SHOULD be used with DPLPMTUD, providing the reported PL_PTB_SIZE is less than the current probe size.
6.2.3. DPLPMTUD for SCTP/DTLS
Datagram Transport Layer Security (DTLS) encapsulation of SCTP is specified in [RFC8261]. This is used in data channels for WebRTC implementations. This specification updates the reference to RFC 4821 in Section 5 of RFC 8261 to refer to this document (RFC 8899).
6.2.3.1. Initial Connectivity
A sender can enter the BASE state once the SCTP association has been confirmed.
6.2.3.2. Sending SCTP/DTLS Probe Packets
Datagram probing can be performed as specified in Section 6.2.1.2. The maximum payload is reduced by the size of the DTLS headers, which has to be taken into account when padding using a PAD chunk. The size of probe packets includes the DTLS PL header. This has to be taken into account when a probe packet is padded using a PAD chunk.
6.2.3.3. Validating the Path with SCTP/DTLS
Since SCTP provides an Acknowledged PL, a sender MUST NOT implement the CONFIRMATION_TIMER when in the SEARCH_COMPLETE state.
6.2.3.4. Handling of PTB Messages by SCTP/DTLS
[RFC4960] does not specify a method for validation of SCTP/DTLS ICMP message payloads, and neither does this document. This prevents processing of PTB messages at the PL.
6.3. DPLPMTUD for QUIC
QUIC [QUIC] is a UDP-based PL that provides reception feedback. The UDP payload includes a QUIC packet header, a protected payload, and any authentication fields. It supports padding and packet coalescing that can be used to construct probe packets. From the perspective of DPLPMTUD, QUIC can function as an Acknowledged PL. [QUIC] describes a method for using DPLPMTUD with QUIC packets.
Implementation Considerations
When implementing DPLPMTUD for a specific protocol:
- Choose Appropriate Probe Method - Select the most efficient probe packet type based on protocol characteristics
- Utilize Existing Mechanisms - Use built-in acknowledgment and heartbeat mechanisms where possible
- Consider Encapsulation Overhead - Correctly calculate the size of headers at each layer
- Coordinate State Management - Ensure PLPMTU state synchronizes with protocol connection state
- Handle Protocol-Specific Limitations - Consider the unique constraints and requirements of each protocol
These protocol-specific implementation guidelines ensure DPLPMTUD can effectively integrate with various transport protocols.