RFC 8899
Packetization Layer Path MTU Discovery for Datagram Transports
Packetization Layer Path MTU Discovery for Datagram Transports 🦋
Okay bestie, let's get into RFC 8899, the one about Datagram PLPMTUD ✨. It's a Standards Track document, and it's giving serious networking energy 💅.
Title block, the tea 🍓
- Who wrote it: G. Fairhurst, T. Jones, M. Tüxen, I. Rüngeler, and T. Völker, all from the University of Aberdeen and Münster University of Applied Sciences 🎀
- Date: September 2020 🌸
- Category: Standards Track, so it's an official Internet standard, not just a suggestion 👑
- Updates: RFC 4821, RFC 4960, RFC 6951, RFC 8085, and RFC 8261 🔥
- Obsoletes: nothing is listed as obsoleted here 🙈
Also, the ISSN is 2070-1721, and the RFC number is 8899 💜
Abstract
Okay so this doc specifies Datagram Packetization Layer Path MTU Discovery (DPLPMTUD) 🧚. It's a robust method for Path MTU Discovery (PMTUD) for datagram Packetization Layers (PLs). Basically, it lets a PL, or a datagram application that uses a PL, figure out whether a network path can handle the current size of datagram 💖. This can be used to detect and reduce the message size when a sender runs into a packet black hole 💀. It can also probe the path to see whether the maximum packet size can go up 📈.
This is giving equivalent energy to the PLPMTUD spec for TCP (RFC 4821), which this document updates 🦋. It also updates the UDP Usage Guidelines so they point to this method for UDP datagrams, and it updates SCTP too ✨.
The document also has implementation notes for putting Datagram PMTUD into IETF datagram transports, or into applications that use datagram transports 🫶.
Lastly, this spec updates RFC 4960, RFC 4821, RFC 6951, RFC 8085, and RFC 8261 💅.
Status of This Memo
This is an Internet Standards Track document 👑.
It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG) 🌈. For more on Internet Standards, check Section 2 of RFC 7841 🎀.
For the current status, errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc8899 💜.
Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved 🔒.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication. Please read these carefully, because they spell out your rights and restrictions for this document 📜. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they're provided without warranty as described in the Simplified BSD License 🫶.
Table of Contents
1. Introduction
1.1. Classical Path MTU Discovery
1.2. Packetization Layer Path MTU Discovery
1.3. Path MTU Discovery for Datagram Services
2. Terminology
3. Features Required to Provide Datagram PLPMTUD
4. DPLPMTUD Mechanisms
4.1. PLPMTU Probe Packets
4.2. Confirmation of Probed Packet Size
4.3. Black Hole Detection and Reducing the PLPMTU
4.4. The Maximum Packet Size (MPS)
4.5. Disabling the Effect of PMTUD
4.6. Response to PTB Messages
4.6.1. Validation of PTB Messages
4.6.2. Use of PTB Messages
5. Datagram Packetization Layer PMTUD
5.1. DPLPMTUD Components
5.1.1. Timers
5.1.2. Constants
5.1.3. Variables
5.1.4. Overview of DPLPMTUD Phases
5.2. State Machine
5.3. Search to Increase the PLPMTU
5.3.1. Probing for a Larger PLPMTU
5.3.2. Selection of Probe Sizes
5.3.3. Resilience to Inconsistent Path Information
5.4. Robustness to Inconsistent Paths
6. Specification of Protocol-Specific Methods
6.1. Application Support for DPLPMTUD with UDP or UDP-Lite
6.1.1. Application Request
6.1.2. Application Response
6.1.3. Sending Application Probe Packets
6.1.4. Initial Connectivity
6.1.5. Validating the Path
6.1.6. Handling of PTB Messages
6.2. DPLPMTUD for SCTP
6.2.1. SCTP/IPv4 and SCTP/IPv6
6.2.1.1. Initial Connectivity
6.2.1.2. Sending SCTP Probe Packets
6.2.1.3. Validating the Path with SCTP
6.2.1.4. PTB Message Handling by SCTP
6.2.2. DPLPMTUD for SCTP/UDP
6.2.2.1. Initial Connectivity
6.2.2.2. Sending SCTP/UDP Probe Packets
6.2.2.3. Validating the Path with SCTP/UDP
6.2.2.4. Handling of PTB Messages by SCTP/UDP
6.2.3. DPLPMTUD for SCTP/DTLS
6.2.3.1. Initial Connectivity
6.2.3.2. Sending SCTP/DTLS Probe Packets
6.2.3.3. Validating the Path with SCTP/DTLS
6.2.3.4. Handling of PTB Messages by SCTP/DTLS
6.3. DPLPMTUD for QUIC
7. IANA Considerations
8. Security Considerations
9. References
9.1. Normative References
9.2. Informative References
Acknowledgments
Authors' Addresses1. Introduction 🌸
1.1. Classical Path MTU Discovery
(Part 1 of 10: the table of contents above and the intro below are as far as we get this time, so more sections are coming in the next parts 💜.)
The IETF has specified datagram transport using UDP, Stream Control Transmission Protocol (SCTP), and Datagram Congestion Control Protocol (DCCP) 🎀. It has also specified protocols layered on top of these transports (for example, SCTP/UDP, DCCP/UDP, and QUIC/UDP), plus direct datagram transport over the IP network layer ✨. This document describes a robust method for Path MTU Discovery (PMTUD) that can be used with these transport protocols, or with the applications that use their transport service, to discover an appropriate packet size to use across an Internet path 🦋.
1.1. Classical Path MTU Discovery 📡
okay so Classical Path Maximum Transmission Unit Discovery (PMTUD) can be used with any transport that is able to process ICMP Packet Too Big (PTB) messages, like [RFC1191] and [RFC8201]. 💖 In this doc, "PTB message" covers two things: IPv4 ICMP Unreachable messages (Type 3) that carry the Fragmentation Needed error (Type 3, Code 4) [RFC0792], and ICMPv6 Packet Too Big messages (Type 2) [RFC4443]. 🦋 When a sender gets a PTB message, it lowers its effective MTU to the value reported as the link MTU in that message. 📉
Classical PMTUD also periodically tries sending bigger packets to see if the supported PMTU has gone up. ✨ Those bigger-than-current-effective-PMTU packets are called probe packets. 🔍 Packets that aren't probes get either fragmented down to the current effective PMTU, or the send just fails with an error code. 💅 Apps can ask for the Maximum Packet Size (MPS), which is derived from the current effective PMTU, so they know their limit. 🎀
Classical PMTUD has protocol failures, bestie. 😭 One is black-holing: traffic bigger than the actual PMTU gets silently dropped (every datagram larger than the actual PMTU is discarded). 🕳️ This can happen when the PTB messages never make it back to the sender for some reason (see [RFC2923], for example).
Here are some examples of where PTB messages don't get delivered:
- The generation of ICMP messages is usually rate limited. 🐢 That could mean no PTB messages get generated back to the sender (see Section 2.4 of [RFC4443]).
- ICMP messages can be filtered by middleboxes, including firewalls [RFC4890]. 🧱 A firewall set up to block incoming ICMP messages would stop a sending endpoint behind it from receiving PTB messages. 🙈
- When the router sending the ICMP message drops a tunneled packet, the ICMP message goes to the tunnel ingress. 🚇 That tunnel endpoint is responsible for forwarding the ICMP message, processing the quoted packet in the payload field to remove the effect of the tunnel, and returning a correctly formatted ICMP message to the sender [TUNNELS]. 🫶 If it doesn't do this, the PTB message never reaches the original sender. 💀
- Asymmetry in forwarding can mean there's no return route to the original sender, so the ICMP message can't be delivered. 🔀 This can also happen with policy-based routing, Equal-Cost Multipath (ECMP) routing, or when a middlebox acts as an application load balancer. 🎢 For example, an ECMP router might pick a path toward the server based on the bytes in the IP payload. 🧭 In that case, if a packet sent by the server runs into a problem after the ECMP router, the ECMP router needs to direct any resulting ICMP message toward the original sender. 💜
- Sometimes the next-hop destination fails to receive a packet because of its size. 📦 This could be due to misconfiguration of the layer 2 path between nodes, like the MTU configured in a layer 2 switch, or a misconfigured Maximum Receive Unit (MRU). 😬 If the link drops the packet, no PTB message gets sent to the original sender. 👻
Another failure could happen if a node that isn't on the network path sends a PTB message that tries to force a sender to change its effective PMTU [RFC8201]. 🚨 A sender can protect itself from reacting to these by using the quoted packet inside the PTB message payload to check that the PTB message was actually generated in response to a packet that came from the sender. 🛡️ But sometimes a sender just can't do that validation. 😤 Here are examples where validation isn't possible:
- When a router sending the ICMP message follows RFC 792 [RFC0792], it only needs to include the first 64 bits of the IP payload of the packet in the quoted payload. 🥲 There might not be enough bytes left for the sender to make sense of the quoted transport information.
Note: The recommendation in RFC 1812 [RFC1812] is that IPv4 routers return a quoted packet with as much of the original datagram as possible, without the length of the ICMP datagram exceeding 576 bytes. 📏 IPv6 routers include as much of the invoking packet as possible without the ICMPv6 packet exceeding 1280 bytes [RFC4443]. 🌈
- Using tunnels and/or encryption can shrink the quoted packet returned to the original source address. 🤏 That raises the risk that there aren't enough bytes left for the sender to interpret the quoted transport information. 😵
- Even when the PTB message has enough bytes of the quoted packet, the network layer might not have enough context to validate it. 🧩 Validation depends on information about the active transport flows at an endpoint node, like the socket/address pairs in use and other protocol header information. 🗂️
- When a packet is encapsulated/tunneled over an encrypted transport, the tunnel/encapsulation ingress might not have enough context, or computational power, to rebuild the transport header that validation would need. 🔐
- When an ICMP message is generated by a router in a network segment that inserted a header into a packet, the quoted packet could contain extra protocol header information that wasn't in the original sent packet. ➕ The PL sender doesn't process that extra info, or might not know how to, which could mess up the sender's ability to validate the PTB message. 🙃
- A Network Address Translation (NAT) device that translates a packet header ought to also translate ICMP messages and update the ICMP-quoted packet [RFC5508] in that message. 🔁 If that isn't translated correctly, the sender can't match the message to the PL that originated the packet, so the ICMP message can't be validated. 🥀
1.2. Packetization Layer Path MTU Discovery 🧁
The term Packetization Layer (PL) was introduced to describe the layer that's responsible for placing data blocks into the payload of IP packets and selecting an appropriate MPS. 🎀 This job is often done by a transport protocol (like DCCP, RTP, SCTP, or QUIC), but other encapsulation methods working above the transport layer can do it too. 🌸
Packetization Layer Path MTU Discovery (PLPMTUD) [RFC4821] is different from Classical PMTUD because it doesn't rely on receiving and validating PTB messages. 🙌 That makes it more robust than Classical PMTUD. 💪 It's now the recommended approach for discovering the PMTU [BCP145]. 👑
This document updates [RFC4821] to specify the PLPMTUD method for datagram PLs. ✨ It also updates [BCP145] to point to the method specified here for use with UDP datagrams, instead of the method in [RFC4821]. 🔄
The general strategy is that the PL sends probe packets to search for the largest size of unfragmented datagram that can be sent over a network path. 🔎 Probes explore using a larger packet size. 🚀 If a probe is successfully delivered (as decided by the PL), the PLPMTU goes up to the size of that successful probe. 📈 If a black hole is detected (say, packets of size PLPMTU are consistently not received), the method brings the PLPMTU down. 📉
Datagram PLPMTUD is super flexible to implement. 🧸 At one extreme, it can be configured to only do black hole detection and recovery, which is more robust than Classical PMTUD. 🛟 At the other extreme, all PTB processing can be turned off, and PLPMTUD replaces Classical PMTUD entirely. 🔁
PLPMTUD can also add consistency checks without increasing the risk of data loss when probing for the Path MTU. 🧐 For example, info available at the PL (or higher layers) lets received PTB messages get validated before they're used. ✅
1.3. Path MTU Discovery for Datagram Services 📨
Section 5 of this document presents a set of algorithms that datagram protocols can use to discover the largest size of unfragmented datagram that can be sent over a network path. 🗺️ The method relies on features of the PL described in Section 3, and it applies to transport protocols running over IPv4 and IPv6. 🌐 It doesn't need cooperation from the lower layers, though it can use PTB messages when they're made available to the PL. 🎁
The message size guidelines in Section 3.2 of the UDP Usage Guidelines [BCP145] say that "an application SHOULD either use the Path MTU information provided by the IP layer or implement Path MTU Discovery (PMTUD)". 🤔 But they don't give a mechanism for finding the largest size of unfragmented datagram that can be used on a network path. 🫠 This document updates RFC 8085 to specify that method in place of PLPMTUD [RFC4821], and it provides a mechanism for sharing the discovered largest size as the MPS (see Section 4.4). 🎁
Section 10.2 of [RFC4821] recommended a PLPMTUD probing method for the Stream Control Transport Protocol (SCTP). 🌊 SCTP uses probe packets made of a minimal-sized HEARTBEAT chunk bundled with a PAD chunk, as defined in [RFC4820]. 🧩 However, RFC 4821 didn't give a complete specification. 🙁 This document replaces that description with a complete specification. ✨
The Datagram Congestion Control Protocol (DCCP) [RFC4340] requires implementations to support Classical PMTUD, and says that a DCCP sender "MUST maintain the MPS allowed for each active DCCP session". 📜 It also defines the current congestion control MPS (CCMPS) supported by a network path. 🛣️ DCCP recommends using PMTUD, and suggests using control packets (DCCP-Sync) as path probe packets, because they don't risk application data loss. 🫧 The method defined in this specification can be used with DCCP. 💖
Section 4 and Section 5 define the protocol mechanisms and specification for Datagram Packetization Layer Path MTU Discovery (DPLPMTUD). 🧠 Section 6 specifies the method for datagram transports, and gives info to help implement PLPMTUD with other datagram transports and with applications that use datagram transports. 🎀 Section 6 also has recommendations for SCTP endpoints, updating [RFC4960], [RFC6951], and [RFC8261] to use the method specified in this document instead of the method in [RFC4821]. 🦋
2. Terminology ✨
okay bestie, time to get our vocab straight 💅 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" get read the BCP 14 [RFC2119] [RFC8174] way, but only when they show up in ALL CAPS like this 🎀
The following terms are defined 🌸 The relevant ones are copied straight from [RFC4821], and the definitions in [RFC1122] also apply 🫶
Acknowledged PL: A PL with a mechanism that can confirm successful delivery of datagrams to the remote PL endpoint (e.g., SCTP). Usually the PL receiver sends back acknowledgments for the datagrams it got, and those can be used to detect black-holing of packets (c.f., Unacknowledged PL) 🦋
Actual PMTU: The actual PMTU is the PMTU of a network path between a sender PL and a destination PL, which the DPLPMTUD algorithm is trying to figure out 🔍
Black Hole: You get a black hole when a sender doesn't realise packets aren't reaching the destination endpoint 🕳️ Two types matter for DPLPMTUD:
- Packet black hole: Packets don't get delivered to the destination endpoint (e.g., when the sender transmits packets of a particular size with a previously known effective PMTU, and the network discards them).
- ICMP black hole: The sender doesn't realise packets aren't being delivered because the originating PL sender never receives PTB messages.
Classical Path MTU Discovery: Classical PMTUD is the process described in [RFC1191] and [RFC8201], where nodes rely on PTB messages to learn the largest unfragmented packet size that can be used across a network path 🧚
Datagram: A datagram is a transport-layer protocol data unit, carried in the payload of an IP packet 💜
DPLPMTUD: Datagram Packetization Layer Path MTU Discovery (DPLPMTUD), which is PLPMTUD performed using a datagram transport protocol ✨
Effective PMTU: The effective PMTU is the current estimated value for PMTU that a PMTUD uses. This is the same as the PLPMTU derived by PLPMTUD plus the size of any headers added below the PL, including the IP layer headers 📦
EMTU_S: The effective MTU for sending (EMTU_S) is defined in [RFC1122] as "the maximum IP datagram size that may be sent, for a particular combination of IP source and destination addresses...". 📤
EMTU_R: The effective MTU for receiving (EMTU_R) is designated in [RFC1122] as "the largest datagram size that can be reassembled". 📥
Link: A link is a communication facility or medium over which nodes can communicate at the link layer, which is a layer below the IP layer. Examples are Ethernet LANs and Internet (or higher) layer tunnels 🌈
Link MTU: The link Maximum Transmission Unit (MTU) is the size in bytes of the largest IP packet, including the IP header and payload, that can be transmitted over a link. Note that this could more properly be called the IP MTU, to be consistent with how other standards organizations use the acronym 👑 It includes the IP header but leaves out link layer headers and other framing that isn't part of IP or the IP payload. Other standards organizations usually define the link MTU to include the link layer headers. This specification carries on the requirement in [RFC4821] that says, "All links MUST enforce their MTU: links that might non-deterministically deliver packets that are larger than their rated MTU MUST consistently discard such packets." 🚨
MAX_PLPMTU: The MAX_PLPMTU is the largest size of PLPMTU that DPLPMTUD will attempt to use (see the constants defined in Section 5.1.2) 🔝
MIN_PLPMTU: The MIN_PLPMTU is the smallest size of PLPMTU that DPLPMTUD will attempt to use (see the constants defined in Section 5.1.2) 🔽
MPS: The Maximum Packet Size (MPS) is the largest size of application data block that a PL can send across a network path using a single datagram (see Section 4.4) 🍓
MSL: The Maximum Segment Lifetime (MSL) is the maximum delay a packet is expected to experience across a path, taken as 2 minutes [BCP145] ⏳
Packet: A packet is the IP header(s) and any extension headers/options, plus the IP payload 🎁
Packetization Layer (PL): The PL is a layer of the network stack that places data into packets and performs transport protocol functions. Examples of a PL include TCP, SCTP, SCTP over UDP, SCTP over DTLS, or QUIC 🫧
Path: The path is the set of links and routers that a packet goes through, between a source node and a destination node, for a particular flow 🛣️
Path MTU (PMTU): The Path MTU (PMTU) is the minimum of the link MTU of all the links forming a network path between a source node and a destination node, as used by PMTUD 🌸
PTB: In this document, "PTB message" covers both IPv4 ICMP Unreachable messages (Type 3) that carry the error Fragmentation Needed (Type 3, Code 4) [RFC0792], and ICMPv6 Packet Too Big messages (Type 2) [RFC4443] 📨
PTB_SIZE: The PTB_SIZE is a value reported in a validated PTB message that indicates the next-hop link MTU of a router along the path 🪧
PL_PTB_SIZE: The size reported in a validated PTB message, reduced by the size of all headers added by layers below the PL 🧮
PLPMTU: The Packetization Layer PMTU is an estimate of the largest size of PL datagram that a path can carry, controlled by PLPMTUD 🎯
PLPMTUD: Packetization Layer Path MTU Discovery (PLPMTUD) is the method described in this document for datagram PLs, and it's an extension to Classical PMTU Discovery 🧩
Probe packet: A probe packet is a datagram sent with a purposely chosen size (typically the current PLPMTU or larger) to detect whether packets of that size can be successfully sent end-to-end across the network path 🔎
Unacknowledged PL: A PL that doesn't itself provide a mechanism to confirm delivery of datagrams to the remote PL endpoint (e.g., UDP), so DPLPMTUD has to provide a mechanism to detect black-holing of packets (c.f., Acknowledged PL) 🙈
3. Features Required to Provide Datagram PLPMTUD ✨
okay bestie, the principles in [RFC4821] apply to this technique with any PL 💅. TCP PLPMTUD got defined using standard TCP protocol mechanisms, but datagram PLs need extra mechanisms and considerations to implement PLPMTUD 🎀. Here's the checklist:
- Managing the PLPMTU: For datagram PLs, the PLPMTU is managed by DPLPMTUD. A PL MUST NOT send a datagram (other than a probe packet) with a size at the PL that is larger than the current PLPMTU. 🦋
- Probe packets: The network interface below the PL is REQUIRED to provide a way to transmit a probe packet that is larger than the PLPMTU. In IPv4, a probe packet MUST be sent with the Don't Fragment (DF) bit set in the IP header and without network layer endpoint fragmentation. In IPv6, a probe packet is always sent without source fragmentation (as specified in Section 5.4 of [RFC8201]). 🌸
- Reception feedback: The destination PL endpoint is REQUIRED to provide a feedback method that indicates to the DPLPMTUD sender when a probe packet has been received by the destination PL endpoint. Section 6 provides examples of how a PL can provide this acknowledgment of received probe packets. 🫶
- Probe loss recovery: It is RECOMMENDED to use probe packets that do not carry any user data that would require retransmission if lost. Most datagram transports permit this. If a probe packet contains user data requiring retransmission in case of loss, the PL (or layers above) is REQUIRED to arrange any retransmission and/or repair of any resulting loss. The PL is REQUIRED to be robust in the case where probe packets are lost due to other reasons (including link transmission error, congestion). 😭
- PMTU parameters: A DPLPMTUD sender is RECOMMENDED to utilize information about the maximum size of packet that can be transmitted by the sender on the local link (e.g., the local link MTU). A PL sender MAY utilize similar information about the maximum size of network-layer packet that a receiver can accept when this is supplied (note this could be less than EMTU_R). This avoids implementations trying to send probe packets that cannot be transferred by the local link. Too high of a value could reduce the efficiency of the search algorithm. Some applications also have a maximum transport protocol data unit (PDU) size, in which case there is no benefit from probing for a size larger than this (unless a transport allows multiplexing multiple applications' PDUs into the same datagram). 🧚
- Processing PTB messages: A DPLPMTUD sender MAY optionally utilize PTB messages received from the network layer to help identify when a network path does not support the current size of probe packet. Any received PTB message MUST be validated before it is used to update the PLPMTU discovery information [RFC8201]. This validation confirms that the PTB message was sent in response to a packet originated by the sender and needs to be performed before the PLPMTU discovery method reacts to the PTB message. A PTB message MUST NOT be used to increase the PLPMTU [RFC8201] but could trigger a probe to test for a larger PLPMTU. A valid
PTB_SIZEis converted to aPL_PTB_SIZEbefore it is to be used in the DPLPMTUD state machine. APL_PTB_SIZEthat is greater than that currently probed SHOULD be ignored. (This PTB message ought to be discarded without further processing but could be utilized as an input that enables a resilience mode). 👑 - Probing and congestion control: A PL MAY use a congestion controller to decide when to send a probe packet. If transmission of probe packets is limited by the congestion controller, this could result in transmission of probe packets being delayed or suspended during congestion. When the transmission of probe packets is not controlled by the congestion controller, the interval between probe packets MUST be at least one RTT. Loss of a probe packet SHOULD NOT be treated as an indication of congestion and SHOULD NOT trigger a congestion control reaction [RFC4821] because this could result in unnecessary reduction of the sending rate. An update to the PLPMTU (or MPS) MUST NOT increase the congestion window measured in bytes [RFC4821]. Therefore, an increase in the packet size does not cause an increase in the data rate in bytes per second. A PL that maintains the congestion window in terms of a limit to the number of outstanding fixed-size packets SHOULD adapt this limit to compensate for the size of the actual packets. The transmission of probe packets can interact with the operation of a PL that performs burst mitigation or pacing, and the PL could need transmission of probe packets to be regulated by these methods. 💅
- Probing and flow control: Flow control at the PL concerns the end-to-end flow of data using the PL service. Flow control SHOULD NOT apply to DPLPMTU when probe packets use a design that does not carry user data to the remote application. 🍓
- Shared PLPMTU state: The PMTU value calculated from the PLPMTU MAY also be stored with the corresponding entry associated with the destination in the IP layer cache and used by other PL instances. The specification of PLPMTUD [RFC4821] states, "If PLPMTUD updates the MTU for a particular path, all Packetization Layer sessions that share the path representation (as described in Section 5.2) SHOULD be notified to make use of the new MTU". Such methods MUST be robust to the wide variety of underlying network forwarding behaviors. Section 5.2 of [RFC8201] provides guidance on the caching of PMTU information and also the relation to IPv6 flow labels. 🌈
In addition, the following principles are stated for design of a DPLPMTUD method:
- A PL MAY be designed to segment data blocks larger than the MPS into multiple datagrams. However, not all datagram PLs support segmentation of data blocks. It is RECOMMENDED that methods avoid forcing an application to use an arbitrary small MPS for transmission while the method is searching for the currently supported PLPMTU. A reduced MPS can adversely impact the performance of an application. 🎀
- To assist applications in choosing a suitable data block size, the PL is RECOMMENDED to provide a primitive that returns the MPS derived from the PLPMTU to the higher layer using the PL. The value of the MPS can change following a change in the path or loss of probe packets. ✨
- Path validation: It is RECOMMENDED that methods are robust to path changes that could have occurred since the path characteristics were last confirmed and to the possibility of inconsistent path information being received. 🦋
- Datagram reordering: A method is REQUIRED to be robust to the possibility that a flow encounters reordering or that the traffic (including probe packets) is divided over more than one network path. 🫶
- Datagram delay and duplication: The feedback mechanism is REQUIRED to be robust to the possibility that packets could be significantly delayed or duplicated along a network path. 💀
- When to probe: It is RECOMMENDED that methods determine whether the path has changed since it last measured the path. This can help determine when to probe the path again. 🧚
4. DPLPMTUD Mechanisms ✨
This section lists the protocol mechanisms used in this specification.
4.1. PLPMTU Probe Packets
okay so the DPLPMTUD method relies on the PL sender being able to generate probe packets with a specific size 🔥. TCP can make these probe packets by choosing to segment the data being sent appropriately [RFC4821]. A datagram PL building a probe packet is different, though. It has to either ask an application to send a data block that is larger than what the application generated, or use padding functions to stretch a datagram beyond the size of the application data block 🙈. Protocols that allow control messages to be exchanged (without an application data block) can make a probe packet by extending a control message with padding data 🌸. The total size of a probe packet includes all headers and padding added to the payload data being sent (e.g., including protocol option fields, security-related fields such as an Authenticated Encryption with Associated Data (AEAD) tag, and TLS record layer padding) 💖.
A receiver is REQUIRED to be able to distinguish an in-band data block from any added padding. This is needed to ensure that any added padding is not passed on to an application at the receiver. 🫶
This results in three possible ways that a sender can create a probe packet:
- Probing using padding data: A probe packet that contains only control information together with any padding, which is needed to inflate to the size of the probe packet. Since these probe packets do not carry an application-supplied data block, they do not typically require retransmission, although they do still consume network capacity and incur endpoint processing. 🧚
- Probing using application data and padding data: A probe packet that contains a data block supplied by an application that is combined with padding to inflate the length of the datagram to the size of the probe packet. 🎀
- Probing using application data: A probe packet that contains a data block supplied by an application that matches the size of the probe packet. This method requests the application to issue a data block of the desired probe size. 👑
A PL that uses a probe packet carrying application data and that needs protection from the loss of this probe packet could perform transport-layer retransmission/repair of the data block (e.g., by retransmitting after loss is detected or by duplicating the data block in a datagram without the padding data). This retransmitted data block might possibly need to be sent using a smaller PLPMTU, which could force the PL to use a smaller packet size to traverse the end-to-end path. (This could utilize endpoint network-layer fragmentation or a PL that can resegment the data block into multiple datagrams.) 😅
DPLPMTUD MAY choose to use only one of these methods to simplify the implementation. 🦋
Probe messages sent by a PL MUST contain enough information to uniquely identify the probe within the Maximum Segment Lifetime (e.g., including a unique identifier from the PL or the DPLPMTUD implementation), while being robust to reordering and replay of probe response and PTB messages. no cap, this one matters a lot 🔥
4.2. Confirmation of Probed Packet Size ✨
okay so the PL needs a way to confirm when its probe packets have actually made it end-to-end across a network path 🦋 sending them is not the same as them arriving, bestie 💅
Transport protocols can have end-to-end methods that detect and report when specific datagrams they sent were received. DCCP, SCTP, and QUIC all have keep-alive/heartbeat features 💖 When that's supported, this mechanism MAY also be used by DPLPMTUD to acknowledge reception of a probe packet 🫶
A PL that doesn't acknowledge data reception (like UDP and UDP-Lite) is literally unable to tell on its own when its packets get discarded because they're bigger than the actual PMTU 😭 These PLs need to rely on an application protocol to detect that loss 🙈
Section 6 spells out this function for a set of IETF-specified protocols 🎀
4.3. Black Hole Detection and Reducing the PLPMTU 🕳️
The description that follows uses the set of constants defined in Section 5.1.2 and the variables defined in Section 5.1.3 🧮
Black hole detection is triggered by an indication that the network path could be unable to support the current PLPMTU size 🚨
There are three indicators that can be used to detect black holes:
- A validated PTB message can be received that indicates a
PL_PTB_SIZEless than the currentPLPMTU. A DPLPMTUD method MUST NOT rely solely on this method. - A PL can use the DPLPMTUD probing mechanism to periodically generate probe packets of the size of the current
PLPMTU(e.g., using theCONFIRMATION_TIMER, Section 5.1.1). A timer tracks whether acknowledgments are received. Successive loss of probes is an indication that the current path no longer supports thePLPMTU(e.g., when the number of probe packets sent without receiving an acknowledgment,PROBE_COUNT, becomes greater thanMAX_PROBES). - A PL can utilize an event that indicates the network path no longer sustains the sender's
PLPMTUsize. This could use a mechanism implemented within the PL to detect excessive loss of data sent with a specific packet size and then conclude that this excessive loss could be a result of an invalidPLPMTU(as in PLPMTUD for TCP [RFC4821]).
⚠️ bestie, the first indicator is NOT enough on its own. A DPLPMTUD method MUST NOT rely solely on a PTB message to detect a black hole 🙅♀️
The three methods can result in different transmission patterns for packet probes and are expected to result in different responsiveness following a change in the actual PMTU 📈
A PL MAY inhibit sending probe packets when no application data has been sent since the previous probe packet. A PL that resumes sending user data MAY continue PLPMTU discovery for each path 🔁 This allows it to use an up-to-date PLPMTU. However, this could result in additional packets being sent 📦
When the method detects that the current PLPMTU is not supported, DPLPMTUD sets a lower PLPMTU and a lower MPS 📉 The PL then confirms that the new PLPMTU can be successfully used across the path ✅ A probe packet could need to be smaller than the size of the data block generated by the application 🧸
4.4. The Maximum Packet Size (MPS) 📏
The result of probing determines a usable PLPMTU, which is used to set the MPS used by the application 🎯 The MPS is smaller than the PLPMTU because it is reduced by the size of PL headers (including the overhead of security-related fields such as an AEAD tag and TLS record layer padding) 🔐 The relationship between the MPS and the PLPMTUD is illustrated in Figure 1 🖼️
Any additional
headers .--- MPS -----.
| | |
v v v
+------------------------------+
| IP | ** | PL | protocol data |
+------------------------------+
<----- PLPMTU ----->
<---------- PMTU -------------->
Figure 1: Relationship between MPS and PLPMTUA PL is unable to send a packet (other than a probe packet) with a size larger than the current PLPMTU at the network layer 🚫 To avoid this, a PL MAY be designed to segment data blocks larger than the MPS into multiple datagrams 🧩
DPLPMTUD seeks to avoid IP fragmentation 🙅 An attempt to send a data block larger than the MPS will therefore fail if a PL is unable to segment data 💀 To determine the largest data block that can be sent, a PL SHOULD provide applications with a primitive that returns the MPS, derived from the current PLPMTU 🔍
If DPLPMTUD results in a change to the MPS, the application needs to adapt to the new MPS 🔄 A particular case can arise when packets have been sent with a size less than the MPS and the PLPMTU was subsequently reduced. If these packets are lost, the PL MAY segment the data using the new MPS. If a PL is unable to resegment a previously sent datagram (e.g., [RFC4960]), then the sender either discards the datagram or could perform retransmission using network-layer fragmentation to form multiple IP packets not larger than the PLPMTU 🧷 For IPv4, the use of endpoint fragmentation by the sender is preferred over clearing the DF bit in the IPv4 header 🎀 Operational experience reveals that IP fragmentation can reduce the reliability of Internet communication [RFC8900], which may reduce the probability of successful retransmission 📉
4.5. Disabling the Effect of PMTUD 🙅♀️
A PL implementing this specification MUST suspend network layer processing of outgoing packets that enforces a PMTU [RFC1191][RFC8201] for each flow utilizing DPLPMTUD, and instead use DPLPMTUD to control the size of packets that are sent by a flow 🛑 This removes the need for the network layer to drop or to fragment sent packets that have a size greater than the PMTU 🫧
4.6. Response to PTB Messages 📬
This method requires the DPLPMTUD sender to validate any received PTB message before using the PTB information 🔎 The response to a PTB message depends on the PL_PTB_SIZE calculated from the PTB_SIZE in the PTB message, the state of the PLPMTUD state machine, and the IP protocol being used 🧠
Section 4.6.1 describes validation for both IPv4 ICMP Unreachable messages (Type 3) and ICMPv6 Packet Too Big messages, both of which are referred to as PTB messages in this document 🧾
4.6.1. Validation of PTB Messages 🛡️
This section specifies utilization and validation of PTB messages 💅
- A simple implementation MAY ignore received PTB messages, and in this case, the PLPMTU is not updated when a PTB message is received 🙈
- A PL that supports PTB messages MUST validate these messages before they are further processed ✅
A PL that receives a PTB message from a router or middlebox performs ICMP validation (see Section 4 of [RFC8201] and Section 5.2 of [BCP145]) 🕵️♀️ Because DPLPMTUD operates at the PL, the PL needs to check that each received PTB message is received in response to a packet transmitted by the endpoint PL performing DPLPMTUD 🎯
The PL MUST check the protocol information in the quoted packet carried in an ICMP PTB message payload to validate the message originated from the sending node 🔍 This validation includes determining that the combination of the IP addresses, the protocol, the source port, and destination port match those returned in the quoted packet. This is also necessary for the PTB message to be passed to the corresponding PL 🧵
The validation SHOULD utilize information that is not simple for an off-path attacker to determine [BCP145] 👀 For example, it could check the value of a protocol header field known only to the two PL endpoints 🔐 A datagram application that uses well-known source and destination ports ought to also rely on other information to complete this validation 🫶
These checks are intended to provide protection from packets that originate from a node that is not on the network path 🚧 A PTB message that does not complete the validation MUST NOT be further utilized by the DPLPMTUD method, as discussed in the Security Considerations section (Section 8) 💀 This one is serious, bestie! 😤
Section 4.6.2 describes this processing of PTB messages 📖
4.6.2. Use of PTB Messages 🦋
PTB messages that have been validated MAY be utilized by the DPLPMTUD algorithm, but MUST NOT be used directly to set the PLPMTU 🙅♀️
Before using the size reported in the PTB message, it must first be converted to a PL_PTB_SIZE. The PL_PTB_SIZE is smaller than the PTB_SIZE because it is reduced by headers below the PL, including any IP options or extensions added to the PL packet 📐
A method that utilizes these PTB messages can improve the speed at which the algorithm detects an appropriate PLPMTU by triggering an immediate probe for the PL_PTB_SIZE (resulting in a network-layer packet of size PTB_SIZE), compared to one that relies solely on probing using a timer-based search algorithm ⚡
A set of checks are intended to provide protection from a router that reports an unexpected PTB_SIZE. The PL also needs to check that the indicated PL_PTB_SIZE is less than the size used by probe packets and at least the minimum size accepted 🧐
This section provides a summary of how PTB messages can be utilized, using the set of constants defined in Section 5.1.2. This processing depends on the PL_PTB_SIZE and the current value of a set of variables 📋
PL_PTB_SIZE < MIN_PLPMTU- Invalid
PL_PTB_SIZE, see Section 4.6.1. - PTB message ought to be discarded without further processing (i.e., PLPMTU is not modified) 🗑️
- The information could be utilized as an input that triggers the enabling of a resilience mode (see Section 5.3.3) 🚨
- Invalid
MIN_PLPMTU < PL_PTB_SIZE < BASE_PLPMTU- A robust PL MAY enter an error state (see Section 5.2) for an IPv4 path when the
PL_PTB_SIZEreported in the PTB message is larger than or equal to 68 bytes [RFC0791] and when this is less than theBASE_PLPMTU🫤 - A robust PL MAY enter an error state (see Section 5.2) for an IPv6 path when the
PL_PTB_SIZEreported in the PTB message is larger than or equal to 1280 bytes [RFC8200] and when this is less than theBASE_PLPMTU🫤
- A robust PL MAY enter an error state (see Section 5.2) for an IPv4 path when the
BASE_PLPMTU <= PL_PTB_SIZE < PLPMTU- This could be an indication of a black hole. The PLPMTU SHOULD be set to
BASE_PLPMTU(the PLPMTU is reduced to theBASE_PLPMTUto avoid unnecessary packet loss when a black hole is encountered) 🕳️ - The PL ought to start a search to quickly discover the new PLPMTU. The
PL_PTB_SIZEreported in the PTB message can be used to initialize a search algorithm 🔍
- This could be an indication of a black hole. The PLPMTU SHOULD be set to
PLPMTU < PL_PTB_SIZE < PROBED_SIZE- The PLPMTU continues to be valid, but the size of a packet used to search (
PROBED_SIZE) was larger than the actual PMTU 🧩 - The PLPMTU is not updated 🙌
- The PL can use the reported
PL_PTB_SIZEfrom the PTB message as the next search point when it resumes the search algorithm 🔁
- The PLPMTU continues to be valid, but the size of a packet used to search (
PL_PTB_SIZE >= PROBED_SIZE- Inconsistent network signal 🤨
- PTB message ought to be discarded without further processing (i.e., PLPMTU is not modified) 🗑️
- The information could be utilized as an input to trigger the enabling of a resilience mode 🚨
5. Datagram Packetization Layer PMTUD ✨
Okay bestie, this is the section where DPLPMTUD finally shows up and starts doing its thing 💅 It's the method that probes for the biggest packet your path can actually handle, so your app can pick a size that fits the route it's on. Here's the layout:
DPLPMTUD SHOULD only be performed at one layer between a pair of endpoints 🫶 So an upper PL or application should avoid using DPLPMTUD if a lower layer already has it switched on. Also, a PL MUST adjust the MPS that DPLPMTUD gives back so it accounts for any extra overhead the PL adds. Not optional, not a suggestion, just the rule 😭
Figure 2 shows where it can slot into the stack (the * marks the spots):
+----------------------+
| Application* |
+-----+------------+---+
| |
+---+--+ +--+--+
| QUIC*| |SCTP*|
+---+--+ +-+-+-+
| | |
+---+ +----+ |
| | |
+-+--+-+ |
| UDP | |
+---+--+ |
| |
+-----------+-------+--+
| Network Interface |
+----------------------+Figure 2: Examples Where DPLPMTUD Can Be Implemented
The big idea is probing from the sender's side 🦋 The sender sends probe packets to find the largest user message that can get all the way across the network path to the destination in one piece. Iconic behaviour, honestly.
The next sections cover what you need to build it, give an overview of the phases, and spell out the state machine and search algorithm. Let's go ✨
5.1. DPLPMTUD Components
Here we meet the timers, constants, and variables that DPLPMTUD runs on 🎀 It's like the cast list before the show starts.
5.1.1. Timers
The method uses up to three timers 🧚
PROBE_TIMER: This one is set to expire after a period longer than the maximum time it takes to get an acknowledgment for a probe packet. The value MUST NOT be smaller than 1 second and SHOULD be larger than 15 seconds. For guidance on picking the value, see Section 3.1.1 of the UDP Usage Guidelines [BCP145] 📖
PMTU_RAISE_TIMER: This one is set to the period a sender keeps using the current PLPMTU, and once it runs out, the sender goes back into the Search Phase 🔄 It's set to 600 seconds, as recommended by PLPMTUD [RFC4821]. Main character timer, no notes.
DPLPMTUD MAY inhibit sending probe packets when no application data has been sent since the previous probe packet. A PL that wants an up-to-date PMTU once user data is sent again can choose to keep doing PMTU discovery for each path. Heads up though: this will mean sending extra packets 📦
CONFIRMATION_TIMER: When an acknowledged PL is used, this timer MUST NOT be used 🙈 For other PLs, it's the period a PL sender waits before confirming the current PLPMTU is still supported. It's shorter than the PMTU_RAISE_TIMER, and it's used to bring the PLPMTU down (for example, when a black hole shows up). Confirmation has to happen often enough while data is flowing that the sending PL doesn't black hole a huge pile of traffic 💀 For guidance on picking this value, see Section 3.1.1 of the UDP Usage Guidelines [BCP145].
DPLPMTUD MAY inhibit sending probe packets when no application data has been sent since the previous probe packet. A PL that wants an up-to-date PMTU once user data is sent again can choose to keep doing PMTU discovery for each path. However, this could mean sending extra packets 🌸
DPLPMTUD specifies various timers, but an implementation could choose to run all of these timer functions off a single timer. Efficient and iconic 💜
5.1.2. Constants
These are the fixed values DPLPMTUD is defined with ✨
MAX_PROBES: This is the maximum value of the PROBE_COUNT counter (see Section 5.1.3). It's the limit on how many consecutive probe attempts of any size you get. Search algorithms benefit from a MAX_PROBES value greater than 1, because that gives you some robustness against isolated packet loss 🛡️ The default value of MAX_PROBES is 3.
MIN_PLPMTU: This is the smallest PLPMTU that DPLPMTUD will try to use 🍓 An endpoint might need to configure MIN_PLPMTU to leave room for extension headers and other encapsulations below the PL. This value can depend on the interface and the path. For IPv6, this size is greater than or equal to the size at the PL that results in an 1280-byte IPv6 packet, as specified in [RFC8200]. For IPv4, this size is greater than or equal to the size at the PL that results in an 68-byte IPv4 packet. Note: An IPv4 router is required to be able to forward a datagram of 68 bytes without further fragmentation. That's the combined size of an IPv4 header and the minimum fragment size of 8 bytes. Also, receivers are required to be able to reassemble fragmented datagrams at least up to 576 bytes, as stated in Section 3.3.3 of [RFC1122] 🧠
MAX_PLPMTU: This is the largest PLPMTU size. It has to be less than or equal to the maximum size of the PL packet that can be sent on the outgoing interface (which is constrained by the local interface MTU). When it's known, it also ought to be less than the maximum size of PL packet the remote endpoint can receive (which is constrained by EMTU_R). It can be limited by the design or configuration of the PL being used. An application, or PL, MAY choose a smaller MAX_PLPMTU when there's no need to send packets larger than a specific size 🎯
BASE_PLPMTU: This is a configured size that's expected to work for most paths 💖 It's equal to or larger than MIN_PLPMTU and smaller than MAX_PLPMTU. For most PLs, a suitable BASE_PLPMTU will be larger than 1200 bytes. When using IPv4, there's no currently equivalent size specified, so a default BASE_PLPMTU of 1200 bytes is RECOMMENDED 🌈
5.1.3. Variables
This method uses a set of variables 🦋
PROBED_SIZE: This is the size of the current probe packet as determined at the PL. It's a tentative value for the PLPMTU, and it's waiting for confirmation by an acknowledgment 🤞
PROBE_COUNT: This is a count of the number of successive unsuccessful probe packets that have been sent. Each time a probe packet is acknowledged, the value is reset to zero. (Some probe loss is expected while searching, so losing a single probe is not an indication of a PMTU problem. Don't panic, bestie 🫶)
Figure 3 shows how the packet size constants and variables relate at one moment in time, when DPLPMTUD is probing to raise the PLPMTU. A probe packet of size PROBED_SIZE has been sent. Once it's acknowledged, the PLPMTU goes up to PROBED_SIZE, and then DPLPMTUD can keep raising PROBED_SIZE toward a probe the size of the actual PMTU 👑
MIN_PLPMTU MAX_PLPMTU
<------------------------------------------->
| | |
v | |
BASE_PLPMTU | v
| PROBED_SIZE
v
PLPMTUFigure 3: Relationships between Packet Size Constants and Variables
5.1.4. Overview of DPLPMTUD Phases ✨
okay bestie, this section is a high-level tour 🗺️ of how DPLPMTUD moves through its phases. It's purely informative, so if you want every detail, the state machine in Section 5.2 has you covered 💅
+------+
+------->| Base |-----------------+ Connectivity
| +------+ | or BASE_PLPMTU
| | | confirmation failed
| | v
| | Connectivity +-------+
| | and BASE_PLPMTU | Error |
| | confirmed +-------+
| | | Consistent
| v | connectivity
Black Hole | +--------+ | and BASE_PLPMTU
detected | | Search |<---------------+ confirmed
| +--------+
| ^ |
| | |
| Raise | | Search
| timer | | algorithm
| expired | | completed
| | |
| | v
| +-----------------+
+---| Search Complete |
+-----------------+
Figure 4: DPLPMTUD PhasesBase 🌸 The Base Phase is where DPLPMTUD makes sure it can actually reach the remote peer, using packets of BASE_PLPMTU size. For a connection-oriented PL, connectivity is implicit and can be checked during the PL connection handshake. A connectionless PL sends a probe packet and waits for it to be acknowledged, and that ack is how it knows the peer is reachable.
The sender also needs to check that BASE_PLPMTU actually works across the network path. It can do that with a PL mechanism (e.g., a handshake packet of size BASE_PLPMTU), or by sending a probe of size BASE_PLPMTU and confirming it gets received.
A probe of size BASE_PLPMTU can go out right away on first entry to the Base Phase (following a connectivity check). If a PL doesn't want to support a path with a PLPMTU below BASE_PLPMTU, it can squash this phase into one step by doing its connectivity checks with a probe of the BASE_PLPMTU size. Smart and efficient 🧚
Once confirmed, DPLPMTUD moves on to the Search Phase. If the Base Phase can't confirm BASE_PLPMTU, it heads to the Error Phase.
Search 🔍 The Search Phase runs a search algorithm that sends probe packets to try to raise the PLPMTU. The algorithm wraps up once it finds a suitable PLPMTU, and then it enters the Search Complete Phase.
A PL can also respond to PTB messages, using them to either move the search forward or end it. See Section 4.6 for the details.
Search Complete 🦋 This phase is entered once the PLPMTU is confirmed to be supported across the network path. A PL can use a CONFIRMATION_TIMER to periodically repeat a probe packet at the current PLPMTU size. If the sender can't confirm reachability (for example, if the CONFIRMATION_TIMER expires), or the PL signals that reachability is lost, that means a black hole has been detected, and DPLPMTUD drops back into the Base Phase.
The PMTU_RAISE_TIMER is what periodically resumes the Search Phase so DPLPMTUD can check whether the PLPMTU can be raised. Black hole detection sends the sender back to the Base Phase.
Error 🚨 The Error Phase kicks in when there's conflicting or invalid PLPMTU information for the path (for example, a failure to support the BASE_PLPMTU). That mess stops DPLPMTUD from making progress, so the PLPMTU gets lowered.
DPLPMTUD stays in the Error Phase until it can see a consistent view of the path and has confirmed that the path supports the BASE_PLPMTU (or until DPLPMTUD is suspended). Patience is a virtue, bestie 💅
A method that only lowers the PLPMTU to a suitable size would be enough to keep things reliable, but it can be super inefficient when the actual PMTU changes, or when the method makes a suboptimal choice for the PLPMTU for whatever reason. Nobody wants that. 😭
A full implementation of DPLPMTUD gives the sender an algorithm to increase the PLPMTU after the characteristics of the path change. That could happen when a link gets reconfigured with a larger MTU, or when the set of links an end-to-end flow traverses changes (for example, after a routing or path failover decision). Main character energy 👑
5.2. State Machine
A state machine for DPLPMTUD is shown in Figure 5. If multipath or multihoming is supported, each path needs its own state machine 🛣️
Note: Not all changes are shown, to keep the diagram simple.
| |
| Start | PL indicates loss
| | of connectivity
v v
+---------------+ +---------------+
| DISABLED | | ERROR |
+---------------+ PROBE_TIMER expiry: +---------------+
| PL indicates PROBE_COUNT = MAX_PROBES or ^ |
| connectivity PTB: PL_PTB_SIZE < BASE_PLPMTU | |
+--------------------+ +------------------+ |
| | |
v | BASE_PLPMTU Probe |
+---------------+ acked |
| BASE |--------------------->+
+---------------+ |
^ | ^ ^ |
Black hole detected | | | | Black hole detected |
+--------------------+ | | +--------------------+ |
| +----+ | |
| PROBE_TIMER expiry: | |
| PROBE_COUNT < MAX_PROBES | |
| | |
| PMTU_RAISE_TIMER expiry | |
| +-----------------------------------------+ | |
| | | | |
| | v | v
+---------------+ +---------------+
|SEARCH_COMPLETE| | SEARCHING |
+---------------+ +---------------+
| ^ ^ | | ^
| | | | | |
| | +-----------------------------------------+ | |
| | MAX_PLPMTU Probe acked or | |
| | PROBE_TIMER expiry: PROBE_COUNT = MAX_PROBES or | |
+----+ PTB: PL_PTB_SIZE = PLPMTU +----+
CONFIRMATION_TIMER expiry: PROBE_TIMER expiry:
PROBE_COUNT < MAX_PROBES or PROBE_COUNT < MAX_PROBES or
PLPMTU Probe acked Probe acked or PTB:
PLPMTU < PL_PTB_SIZE < PROBED_SIZE
Figure 5: State Machine for Datagram PLPMTUDHere's the crew of states 🎀
DISABLED 💤 This is the initial state, before any probing has started. It's also entered from any other state when the PL indicates loss of connectivity. The state is left once the PL indicates connectivity to the remote PL. When transitioning to the BASE state, a probe packet of size BASE_PLPMTU can be sent immediately.
BASE 🌱 The BASE state confirms that the BASE_PLPMTU size is supported by the network path. It's designed to let an application keep working through transient reductions in the actual PMTU. It also tries to avoid long stretches where a sender searching for a larger PLPMTU has no idea that packets aren't being delivered because of a packet or ICMP black hole.
On entry, PROBED_SIZE is set to the BASE_PLPMTU size, and PROBE_COUNT is set to zero.
Each time a probe packet is sent, the PROBE_TIMER starts. The state is exited when the probe packet is acknowledged, and the PL sender then enters the SEARCHING state.
The state is also left when PROBE_COUNT reaches MAX_PROBES or a received PTB message is validated. When that happens, the PL sender enters the ERROR state.
SEARCHING 🔎 SEARCHING is the main probing state. It's entered when probing for the BASE_PLPMTU completes.
Each time a probe packet is acknowledged, PROBE_COUNT is set to zero, PLPMTU is set to PROBED_SIZE, and then PROBED_SIZE is increased using the search algorithm (as described in Section 5.3).
When a probe packet is sent and isn't acknowledged within the period of the PROBE_TIMER, PROBE_COUNT is incremented and a new probe packet is transmitted.
The state is exited to enter SEARCH_COMPLETE when PROBE_COUNT reaches MAX_PROBES, when a validated PTB arrives that corresponds to the last successfully probed size (PL_PTB_SIZE = PLPMTU), or when a probe of size MAX_PLPMTU is acknowledged (PLPMTU = MAX_PLPMTU).
When a black hole is detected in the SEARCHING state, the PL sender enters the BASE state.
SEARCH_COMPLETE 🏁 SEARCH_COMPLETE means a search has finished. This is the normal maintenance state, where the PL isn't probing to update the PLPMTU. DPLPMTUD stays here until either the PMTU_RAISE_TIMER expires or a black hole is detected.
When DPLPMTUD uses an unacknowledged PL and is in SEARCH_COMPLETE, a CONFIRMATION_TIMER periodically resets PROBE_COUNT and schedules a probe packet with the size of the PLPMTU. If MAX_PROBES successive PLPMTUD-sized probes fail to be acknowledged, the method enters the BASE state. When it's used with an acknowledged PL (e.g., SCTP), DPLPMTUD SHOULD NOT continue to generate PLPMTU probes in this state. 🙈
ERROR 🧯 ERROR covers the case where either the network path isn't known to support a PLPMTU of at least the BASE_PLPMTU size, or there's contradictory information about the network path that would otherwise cause excessive variation in the MPS signaled to the higher layer. The state includes a method to mitigate oscillation in the state-event engine. It signals a conservative value of the MPS to the higher layer by the PL. The state is exited when packet probes no longer detect the error, and then the PL sender enters the SEARCHING state.
Implementations are permitted to enable endpoint fragmentation if DPLPMTUD can't validate MIN_PLPMTU within PROBE_COUNT probes. If DPLPMTUD can't validate MIN_PLPMTU, the implementation will transition to the DISABLED state.
Note: MIN_PLPMTU could be identical to BASE_PLPMTU, which simplifies the actions in this state.
5.3. Search to Increase the PLPMTU
Now we're getting to the search itself 🦋 This section describes the algorithms DPLPMTUD uses to search for a larger PLPMTU. Let's gooo 🚀
5.3.1. Probing for a Larger PLPMTU
Okay so this is where the search actually happens 🦋 Implementations run a search algorithm across the search range to figure out whether a bigger PLPMTU can survive the trip across a network path. Bestie, it's giving detective energy 🔍✨
The method finds the search range by confirming the minimum PLPMTU first, then uses the probe method to pick a PROBED_SIZE that is less than or equal to MAX_PLPMTU. MAX_PLPMTU is the minimum of the local MTU and EMTU_R (when that is learned from the remote endpoint) 💅. The MAX_PLPMTU MAY be reduced by an application that sets a maximum on the size of datagrams it will send 🌸.
The PROBE_COUNT is initialized to zero when the first probe with a size greater than or equal to PLPMTU is sent 🎀. Each probe packet that is successfully sent to the remote peer is confirmed by acknowledgment at the PL (see Section 4.1) 💜.
Each time a probe packet is sent to the destination, the PROBE_TIMER is started ⏱️. The timer gets canceled when the PL receives acknowledgment that the probe packet was successfully sent across the path (Section 4.1). This confirms that the PROBED_SIZE is supported, and then the PROBED_SIZE value gets assigned to the PLPMTU 🙌. The search algorithm can keep sending subsequent probe packets of an increasing size, so it's literally climbing the ladder 🪜🧚.
If the timer expires before a probe packet is acknowledged, the probe has failed to confirm the PROBED_SIZE 😭. Each time the PROBE_TIMER expires, the PROBE_COUNT is incremented, the PROBE_TIMER is reinitialized, and a new probe of the same size or any other size (chosen by the search algorithm) can be sent 🦋. The maximum number of consecutive failed probes is configured (MAX_PROBES) 🔢. If the value of the PROBE_COUNT reaches MAX_PROBES, probing stops and the PL sender enters the SEARCH_COMPLETE state 🏁✨.
5.3.2. Selection of Probe Sizes
The search algorithm figures out a minimum useful gain in PLPMTU 📏. Trying to probe for every single size would not be constructive for a PL sender, because it would just dump unnecessary load on the path 🙅♀️. Implementations SHOULD select the set of probe packet sizes that maximizes the gain in PLPMTU from each search step 💖.
Implementations could optimize the search by picking step sizes from a table of common PMTU sizes 🍓. When choosing the next size to search, an implementer ought to also consider that applications may seek to use common sizes of MPS, and there could be common sizes of MTU used within the network 🌈.
5.3.3. Resilience to Inconsistent Path Information
A decision to increase the PLPMTU needs to be resilient to the possibility that information learned about the network path is inconsistent 🥺. A path counts as inconsistent when, for example, probe packets get lost for other reasons (i.e., not packet size) or because of frequent path changes. Those path changes could happen through unexpected "flapping", where some packets from a flow take one path while other packets follow a different path with different properties 🌀.
A PL sender can detect inconsistency either from the sequence of PLPMTU probes that get acknowledged or from the sequence of PTB messages it receives 👀. When inconsistent path information is detected, a PL sender could switch to an alternate search mode that clamps the offered MPS to a smaller value for a period of time. This avoids unnecessary loss of packets 🫶.
5.4. Robustness to Inconsistent Paths
Some paths might not be able to sustain packets of the BASE_PLPMTU size 😬. The Error State could be implemented to provide robustness for such paths. This allows fallback to a smaller than desired PLPMTU instead of suffering a connectivity failure 💪. It could use methods such as endpoint IP fragmentation so the PL sender can communicate with packets smaller than the BASE_PLPMTU 🧩.
- Specification of Protocol-Specific Methods ✨
DPLPMTUD requires protocol-specific details to be specified for each PL that gets used 📝.
The first subsection gives guidance on implementing the DPLPMTUD method as part of an application using UDP or UDP-Lite 🎀. The guidance also applies to other datagram services that don't include a specific transport protocol (such as a tunnel encapsulation). The following subsections describe how DPLPMTUD can be implemented as part of the transport service, so applications using the service get to benefit from PLPMTU discovery without implementing 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. Like, at all 🙈. In particular, the UDP transport does not provide the transport features needed to implement datagram PLPMTUD 💀.
The DPLPMTUD method can be implemented as part of an application built directly or indirectly on UDP or UDP-Lite, but it 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 to interpret received PTB messages) 🥲.
Also, it is recommended that PMTU discovery is not performed by multiple protocol layers. An application SHOULD avoid using DPLPMTUD when the underlying transport system provides this capability 🙅♀️. A common method for managing the PLPMTU has benefits, both in sharing state between different processes and in opportunities to coordinate probing for different PL instances 🤝💜.
6.1.1. Application Request
An application needs an application-layer protocol mechanism (such as a message acknowledgment method) that solicits a response from a destination endpoint. The method SHOULD let the sender check the value returned in the response, which gives additional protection from off-path insertion of data [BCP145] 🛡️. Suitable methods include a parameter known only to the two endpoints, such as a session ID or initialized sequence number 🔐.
6.1.2. Application Response
An application needs an application-layer protocol mechanism to communicate the response from the destination endpoint 📬. This response could indicate successful reception of the probe across the path, but it could also indicate that some (or all) packets failed to reach the destination 😵.
6.1.3. Sending Application Probe Packets
A probe packet can carry an application data block, but the successful transmission of that data is at risk when it's used for probing 😬. Some applications might prefer a probe packet that does not carry an application data block, so they don't disrupt the data transfer 🌷.
6.1.4. Initial Connectivity
An application that doesn't have other higher-layer information confirming connectivity with the remote peer SHOULD implement a connectivity mechanism using acknowledged probe packets before entering the BASE state 🚦.
6.1.5. Validating the Path
An application that doesn't have other higher-layer information confirming correct delivery of datagrams SHOULD implement the CONFIRMATION_TIMER to periodically send probe packets while in the SEARCH_COMPLETE state 🔁.
6.1.6. Handling of PTB Messages
An application that is able and wishes to receive PTB messages MUST perform ICMP validation as specified in Section 5.2 of [BCP145] 🧐. This requires that the application checks each received PTB message to validate that it was received in response to transmitted traffic and that the reported PL_PTB_SIZE is less than the current probed size (see Section 4.6.2) 🔍. A validated PTB message MAY be used as input to the DPLPMTUD algorithm, but it 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 🌐. DPLPMTUD keeps the practice of using the PL to discover the PMTU, but it updates RFC4960 with a recommendation to use the method specified in this document 💅. The RECOMMENDED method for generating 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 enables probing without affecting the transfer of user messages and without being limited by congestion control or flow control 🙌. This is preferred over using DATA chunks (with padding as required) as path probes 💖.
Section 6.9 of [RFC4960] describes dividing user messages into DATA chunks sent by the PL when using SCTP 📦. It notes that once an SCTP message has been sent, it cannot be resegmented 🙅♀️. [RFC4960] describes the method for retransmitting DATA chunks when the MPS has been reduced, and Section 6.9 of [RFC4960] describes the use of IP fragmentation for this case 🧩. This is unchanged by this document 🫶.
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 💜. A sender can therefore enter the BASE state as soon as connectivity has been confirmed ✨.
6.2.1.2. Sending SCTP Probe Packets
Probe packets consist of an SCTP common header followed by a HEARTBEAT chunk and a PAD chunk 🎁. The PAD chunk controls the length of the probe packet, and the HEARTBEAT chunk triggers the sending of a HEARTBEAT ACK chunk 🦋. Receiving the HEARTBEAT ACK chunk acknowledges reception of a successful probe 🥳. A successful probe updates the association and path counters, but an unsuccessful probe is discounted (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 could carry a Heartbeat Information parameter that includes, besides the information suggested in [RFC4960], the probe size, to help an implementation associate a HEARTBEAT ACK with the size of the probe that was sent 🧠. The sender could also use other methods, such as sending a nonce and verifying that the returned information contains the corresponding nonce 🔑. The length of the PAD chunk is computed by reducing the probing size by the size of the SCTP common header and the HEARTBEAT chunk 🧮. The payload of the PAD chunk contains arbitrary data 🌸. When transmitted at the IP layer, the PMTU size also includes the IPv4 or IPv6 header(s) 🌐.
Probing can start directly after the PL handshake, and this can be done before data is sent 🚀. Assuming this behavior (i.e., the PMTU is smaller than or equal to the interface MTU), this process takes 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 while in the SEARCH_COMPLETE state 🚫. Not needed, bestie, SCTP already has you covered 💅✨.
6.2.1.4. PTB Message Handling by SCTP
Normal ICMP validation MUST be performed as specified in Appendix C of [RFC4960] 🔍. This requires that the first 8 bytes of the SCTP common header are quoted in the payload of the PTB message, which can be the case for ICMPv4 and is normally 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, provided that the reported PL_PTB_SIZE is less than the current probe size (see Section 4.6) 🎯💖.
6.2.2. DPLPMTUD for SCTP/UDP 🦋
okay so the UDP encapsulation of SCTP is defined in [RFC6951] 💖 and this doc updates the reference to RFC 4821 in Section 5.6 of RFC 6951 so it points here (RFC 8899) ✨ RFC 6951 gets one new sentence tacked on at the end of Section 5.6, and it's giving very "this is the new official way" energy 👑
The RECOMMENDED method for determining the MTU of the path is specified in RFC 8899.
6.2.2.1. Initial Connectivity 🌸
a sender can enter the BASE state as soon as SCTP connectivity has been confirmed 🫶
6.2.2.2. Sending SCTP/UDP Probe Packets 🎀
packet probing works the same as in Section 6.2.1.2 🍓 BUT the probe packet size includes the 8 bytes of the UDP header, so you have to count those when you stuff the probe with the PAD chunk 😭 (not me forgetting the UDP header lol)
6.2.2.3. Validating the Path with SCTP/UDP 💅
SCTP gives you an acknowledged PL, so a sender does not implement the CONFIRMATION_TIMER while it's in the SEARCH_COMPLETE state. literally no need, it's already confirmed 🧚
6.2.2.4. Handling of PTB Messages by SCTP/UDP 🔥
ICMP validation MUST be performed for PTB messages as specified in Appendix C of [RFC4960] 🙈 this means the first 8 bytes of the SCTP common header have to be inside the PTB message. that's possible with ICMPv4 (but the UDP header eats part of the quoted packet header too, so be careful 👀) and it's totally normal with ICMPv6 💜 once validation is done, the PL_PTB_SIZE (calculated from the PTB_SIZE in the PTB message) SHOULD be used with the DPLPMTUD, as long as the reported PL_PTB_SIZE is smaller than the current probe size ✨
6.2.3. DPLPMTUD for SCTP/DTLS 🌈
the Datagram Transport Layer Security (DTLS) encapsulation of SCTP is specified in [RFC8261], and it's the one used for data channels in WebRTC implementations 🎀 this spec also updates the reference to RFC 4821 in Section 5 of RFC 8261 so it points to this document (RFC 8899) 🫶
6.2.3.1. Initial Connectivity 🌸
same vibe as before: a sender can enter the BASE state as soon as SCTP connectivity has been confirmed 💖
6.2.3.2. Sending SCTP/DTLS Probe Packets 🍓
packet probing can be done as in Section 6.2.1.2 ✨ the maximum payload shrinks by the size of the DTLS headers, so that has to be accounted for when you fill the PAD chunk 💅 the probe packet size also includes the DTLS PL headers, which means you gotta consider those too when filling the probe with the PAD chunk 😭
6.2.3.3. Validating the Path with SCTP/DTLS 👑
since SCTP gives you an acknowledged PL, a sender MUST NOT implement the CONFIRMATION_TIMER while in the SEARCH_COMPLETE state. this one's a hard no, bestie 🚫💀
6.2.3.4. Handling of PTB Messages by SCTP/DTLS 🙈
ngl this one's kinda messy 🥺 [RFC4960] doesn't say how to validate the SCTP/DTLS ICMP message payload, and this document doesn't either. so yeah, that can stop PTB messages from being processed at the PL 💔
6.3. DPLPMTUD for QUIC 🦋
okay QUIC [QUIC] is a UDP-based PL that gives you reception feedback ✨ the UDP payload holds a QUIC packet header, a protected payload, and any authentication fields 🧚 it also supports padding and packet coalescence, so you can build probe packets with it 🎀 from DPLPMTUD's point of view, QUIC can act as an acknowledged PL, and [QUIC] itself describes how to use DPLPMTUD with QUIC packets 💜
7. IANA Considerations 🎀
this document has no IANA actions 🫶
8. Security Considerations 🔥
okay this section is the serious one, so pay attention bestie 👀 the security considerations for using UDP and SCTP live in the referenced RFCs 📚
to avoid excessive load, the interval between individual probe packets MUST be at least one RTT, and the interval between rounds of probing is determined by the PMTU_RAISE_TIMER 🚦
a PL sender needs to make sure the method it uses to confirm reception of probe packets protects against off-path attackers injecting packets into the path 🛡️ IETF protocols like TCP and SCTP handle this with a randomly initialized sequence number 🎲 one way to do this when using UDP is described in Section 5.1 of [BCP145]).
there are cases where ICMP Packet Too Big (PTB) messages don't get delivered because of policy, configuration, or equipment design (see Section 1.1) 😤 so this method doesn't rely on PTB messages being received, but it can use them when the sender does get them 🧚 PTB messages could potentially be abused to make a node inappropriately reduce the PLPMTU 💀 that's why a node supporting DPLPMTUD MUST appropriately validate the payload of PTB messages, to make sure they were received in response to traffic it actually sent (i.e., a reported error condition that corresponds to a datagram actually sent by the path layer, see Section 4.6.1) 🔒
an on-path attacker that can create a PTB message could forge PTB messages that include a valid quoted IP packet 👀 that could be used to drive the PLPMTU down ⬇️ an on-path device could also force a reduction of the PLPMTU by enforcing a policy that drops packets larger than a configured size 😬 there are two ways this method can be mitigated against such attacks 🛡️ first, a PL sender never reduces the PLPMTU below the base size solely in response to receiving a PTB message, which is achieved by first entering the BASE state when such a message is received ✨ second, the design does not require processing PTB messages, so a PL sender could suspend processing of PTB messages (e.g., in a robustness mode after detecting that subsequent probes actually confirm that a size larger than the PTB_SIZE is supported by a path) 🫶
parsing the quoted packet inside a PTB message can add extra per-packet processing at the PL sender 🥵 this processing SHOULD be limited to avoid a denial-of-service attack when arbitrary headers are included 🚫 rate-limiting the processing could mean PTB messages don't get received by a PL, but the DPLPMTUD method is robust to that loss 💪
the successful processing of an ICMP message can trigger a probe when the reported PTB size is valid, but it doesn't directly update the PLPMTU for the path 🧠 this stops a message from trying to black hole data by indicating a size bigger than the path supports 🕳️
it's possible that the information about a path isn't stable 🌀 this could happen when forwarding goes across more than one path with a different actual PMTU, or when a single path presents a varying PMTU 🎢 the design of a PLPMTUD implementation SHOULD consider how to mitigate the effects of varying path information 🧩 one possible mitigation is to provide robustness (see Section 5.4) in the method, so the MPS doesn't oscillate 🦋
DPLPMTUD methods can add padding data to inflate the length of the datagram to the total size needed for a probe packet 🎀 the total size of a probe packet includes all headers and padding added to the payload data being sent (e.g., including security-related fields such as an AEAD tag and TLS record layer padding) 🔐 the value of the padding data does not influence the DPLPMTUD search algorithm, so it needs to be set consistent with the policy of the PL 🧾
if a PL can use cryptographic confidentiality or data-integrity mechanisms, then the design ought to avoid adding anything (e.g., padding) to DPLPMTUD probe packets that isn't also protected by those cryptographic mechanisms 🔏💜
9. References 📚
9.1. Normative References 🌷
[BCP145] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
Guidelines", BCP 145, RFC 8085, March 2017,
<https://www.rfc-editor.org/info/bcp145>.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
DOI 10.17487/RFC0768, August 1980,
<https://www.rfc-editor.org/info/rfc768>.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981,
<https://www.rfc-editor.org/info/rfc791>.
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
DOI 10.17487/RFC1191, November 1990,
<https://www.rfc-editor.org/info/rfc1191>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., Ed.,
and G. Fairhurst, Ed., "The Lightweight User Datagram
Protocol (UDP-Lite)", RFC 3828, DOI 10.17487/RFC3828, July
2004, <https://www.rfc-editor.org/info/rfc3828>.
[RFC4820] Tuexen, M., Stewart, R., and P. Lei, "Padding Chunk and
Parameter for the Stream Control Transmission Protocol
(SCTP)", RFC 4820, DOI 10.17487/RFC4820, March 2007,
<https://www.rfc-editor.org/info/rfc4820>.
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol",
RFC 4960, DOI 10.17487/RFC4960, September 2007,
<https://www.rfc-editor.org/info/rfc4960>.
[RFC6951] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream
Control Transmission Protocol (SCTP) Packets for End-Host
to End-Host Communication", RFC 6951,
DOI 10.17487/RFC6951, May 2013,
<https://www.rfc-editor.org/info/rfc6951>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
[RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed.,
"Path MTU Discovery for IP version 6", STD 87, RFC 8201,
DOI 10.17487/RFC8201, July 2017,
<https://www.rfc-editor.org/info/rfc8201>.
[RFC8261] Tuexen, M., Stewart, R., Jesup, R., and S. Loreto,
"Datagram Transport Layer Security (DTLS) Encapsulation of
SCTP Packets", RFC 8261, DOI 10.17487/RFC8261, November
2017, <https://www.rfc-editor.org/info/rfc8261>.9.2. Informative References 📚
okay bestie, these are the informative refs, the extra reading that backs up the spec 💜🤓
[QUIC] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", Work in Progress, Internet-Draft, draft-ietf-quic-transport-29, 10 June 2020, <https://tools.ietf.org/html/draft-ietf-quic-transport-29>.
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, DOI 10.17487/RFC0792, September 1981, <https://www.rfc-editor.org/info/rfc792>.
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989, <https://www.rfc-editor.org/info/rfc1122>.
[RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", RFC 1812, DOI 10.17487/RFC1812, June 1995, <https://www.rfc-editor.org/info/rfc1812>.
[RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 2923, DOI 10.17487/RFC2923, September 2000, <https://www.rfc-editor.org/info/rfc2923>.
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, DOI 10.17487/RFC4340, March 2006, <https://www.rfc-editor.org/info/rfc4340>.
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", STD 89, RFC 4443, DOI 10.17487/RFC4443, March 2006, <https://www.rfc-editor.org/info/rfc4443>.
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, <https://www.rfc-editor.org/info/rfc4821>.
[RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering ICMPv6 Messages in Firewalls", RFC 4890, DOI 10.17487/RFC4890, May 2007, <https://www.rfc-editor.org/info/rfc4890>.
[RFC5508] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT Behavioral Requirements for ICMP", BCP 148, RFC 5508, DOI 10.17487/RFC5508, April 2009, <https://www.rfc-editor.org/info/rfc5508>.
[RFC8900] Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, O., and F. Gont, "IP Fragmentation Considered Fragile", RFC 8900, BCP 230, September 2020, <https://www.rfc-editor.org/info/rfc8900>.
[TUNNELS] Touch, J. and M. Townsley, "IP Tunnels in the Internet Architecture", Work in Progress, Internet-Draft, draft-ietf-intarea-tunnels-10, 12 September 2019, <https://tools.ietf.org/html/draft-ietf-intarea-tunnels-10>.
Acknowledgments 🫶
this work got partially funded by the European Union Horizon 2020 Research and Innovation Programme under grant agreement No. 644334, "A New, Evolutive API and Transport-Layer Architecture for the Internet" (NEAT) ✨. the views expressed are solely those of the author(s) 💅
huge thanks to everyone who commented or contributed 💖, the TSVWG and QUIC working groups 🌈, and Mathew Calder and Julius Flohr for providing early implementations 🔥
Authors' Addresses 🦋
Godred Fairhurst
University of Aberdeen
School of Engineering
Fraser Noble Building
Aberdeen
AB24 3UE
United Kingdom
Email: gorry@erg.abdn.ac.uk
Tom Jones
University of Aberdeen
School of Engineering
Fraser Noble Building
Aberdeen
AB24 3UE
United Kingdom
Email: tom@erg.abdn.ac.uk
Michael Tüxen
Münster University of Applied Sciences
Stegerwaldstrasse 39
48565 Steinfurt
Germany
Email: tuexen@fh-muenster.de
Irene Rüngeler
Münster University of Applied Sciences
Stegerwaldstrasse 39
48565 Steinfurt
Germany
Email: i.ruengeler@fh-muenster.de
Timo Völker
Münster University of Applied Sciences
Stegerwaldstrasse 39
48565 Steinfurt
Germany
Email: timo.voelker@fh-muenster.de📦 where this page comes from
- ietf: rfc8899 2020-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms