Datagram Packetization Layer Path MTU Discovery (DPLPMTUD) for UDP Options University of Aberdeen
School of Engineering Fraser Noble Building Aberdeen AB24 3UE United Kingdom gorry@erg.abdn.ac.uk
University of Aberdeen
School of Engineering Fraser Noble Building Aberdeen AB24 3UE United Kingdom tom@erg.abdn.ac.uk
WIT tsvwg UDP UDP-Options PMTUD PLPMTUD DPLPMTUD Datagram This document specifies how a UDP Options sender implements Datagram Packetization Layer Path MTU Discovery (DPLPMTUD) as a robust method for Path MTU Discovery (PMTUD). This method uses the UDP Options packetization layer. It allows an application to discover the largest size of datagram that can be sent across a network path. It also provides a way to allow the application to periodically verify the current Maximum Packet Size (MPS) supported by a path and to update this when required.
Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at .
Copyright Notice Copyright (c) 2025 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 () in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
Table of Contents
  • .  Introduction
  • .  Terminology
  • .  DPLPMTUD for UDP Options
    • .  Packet Formats
    • .  Sending Probe Packets with the Request Option
    • .  Receiving UDP Options Probe Packets and Sending the RES Option
  • .  DPLPMTUD Sender Procedures for UDP Options
    • .  Confirmation of Connectivity Across a Path
    • .  Sending Probe Packets to Increase the PLPMTU
    • .  Validating the Path with UDP Options
    • .  Probe Packets That Do Not Include Application Data
    • .  Probe Packets That Include Application Data
  • .  Receiving Events from the Network
    • .  Changes in the Path
    • .  Validation of PTB Messages
  • .  Examples with Different Receiver Behaviors
  • .  IANA Considerations
  • .  Security Considerations
  • .  References
    • .  Normative References
    • .  Informative References
  • Acknowledgements
  • Authors' Addresses
Introduction The User Datagram Protocol (UDP) offers a minimal transport service on top of IP and is frequently used as a substrate for other protocols. Section of UDP Guidelines recommends that applications implement some form of Path MTU Discovery (PMTUD) to avoid the generation of IP fragments:
Consequently, an application SHOULD either use the path MTU information provided by the IP layer or implement Path MTU Discovery (PMTUD) itself [RFC1191] [RFC1981] [RFC4821] to determine whether the path to a destination will support its desired message size without fragmentation.
The UDP API offers calls for applications to receive ICMP Packet Too Big (PTB) messages and to control the maximum size of datagrams that are sent, but it does not offer any automated mechanisms for an application to discover the MPS supported by a path. Upper Layer protocols, which include applications, can implement mechanisms for PMTUD above the UDP API. Packetization Layer Path MTU Discovery (PLPMTUD) describes a method for a bidirectional Packetization Layer (PL) to search for the largest Packetization Layer PMTU (PLPMTU) supported on a path. DPLPMTUD specifies this support for datagram transports. PLPMTUD and DPLPMTUD gain robustness by using a probing mechanism that does not solely rely on ICMP PTB messages and works on paths that drop ICMP PTB messages. UDP Options supplies functionality that can be used to implement DPLPMTUD within the transport service or in an Upper Layer protocol (including an application) that uses UDP Options. This document specifies how DPLPMTUD using UDP Options is implemented () and requires support to be enabled at both the sender and receiver. Implementing DPLPMTUD within the transport service above UDP Options avoids the need for each Upper Layer protocol to implement the DPLPMTUD method. It provides a standard method for applications to discover the current MPS for a path and to detect when this changes. It can be used with Equal-Cost Multipath (ECMP) routing and/or multihoming. If multipath or multihoming is supported, a state machine is needed for each path. DPLPMTUD is not specified for multicast. The method requires explicit acknowledgement of probe packets provided by UDP Options, which is primarily intended for unicast use (see ).
Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. This document uses the terms defined for DPLPMTUD (Sections and of ).
DPLPMTUD for UDP Options A UDP Options sender implementing DPLPMTUD uses the method specified in . In this specification, DPLPMTUD is realized using a pair of UDP Options: the Request (REQ) Option and the Response (RES) Option (). The method also uses the End of Options List (EOL) Option () to introduce padding to set the size of a probe packet. Use of DPLPMTUD MUST be explicitly enabled by the application, for instance, once an application has established connectivity and is ready to exchange data with the remote Upper Layer protocol. Similarly, a DPLPMTUD receiver MUST NOT respond to a UDP REQ Option until DPLPMTUD has been enabled. This is to help protect from misuse of the mechanism for other forms of probing. Probe packets consume network capacity and incur endpoint processing (). Implementations ought to send a probe packet with a UDP REQ Option only when required by their local DPLPMTUD state machine, i.e., when confirming the base PMTU for the path, probing to increase the PLPMTU, or confirming the current PLPMTU. DPLPMTUD can be implemented over UDP Options in two ways:
  • Implementation within the UDP transport service.
  • Implementation in an Upper Layer protocol (or application) that uses UDP Options.
When DPLPMTUD is implemented within the UDP transport service, the DPLPMTUD state machine is responsible for sending probe packets to determine a PLPMTU, as described in this document. This determines an MPS, the largest size of application data block that can be sent across a network path using a single datagram. The Upper Layer protocol is responsible for deciding when a session enables DPLPMTUD. The discovered PLPMTU can be used to either:
  • set the maximum datagram size for the current path or
  • set the maximum fragment size when a sender uses the UDP Fragmentation Option to divide a datagram into multiple UDP fragments for transmission. The size of each UDP fragment is then less than or equal to the size of the discovered largest IP packet that can be received across the current path.
The figure below shows an implementation of DPLPMTUD within the UDP transport service. It illustrates key interactions between the layers. This design requires an API primitive to allow the application to control whether the DPLPMTUD state machine is enabled for a specific UDP port. By default, this API MUST disable DPLPMTUD processing. Upper Layer Protocol or Application Messages (with UDP Options) receive send Primitives for MPS, Min_PMTU, etc. DPLPMTUD State Machine Maximum Packet Size (MPS) PLPMTU, Probed-Size, Min_PMTU Token Values & Probes, etc. Messages (with UDP Options) Send/Receive: Probes with Options receive send Events: ICMP, Interface MTU, etc. UDP Options Transport Datagrams (with UDP Options) Fragmented Datagrams with UDP Options receive send Events: ICMP, Interface MTU, etc. +--------------------------------+ | Upper Layer Protocol | | or Application | +---------------------------+----+ ^ | Messages (with UDP Options) | receive send v Primitives for MPS, Min_PMTU, etc. +---+----------------------------+ | DPLPMTUD State Machine | | Maximum Packet Size (MPS) | | PLPMTU, Probed-Size, Min_PMTU| | Token Values & Probes, etc. | +---------------------------+----+ ^ | Messages (with UDP Options) | | Send/Receive: Probes with Options | receive send v Events: ICMP, Interface MTU, etc. +---+----------------------------+ | UDP Options Transport | +---------------------------+----+ ^ | Datagrams (with UDP Options) | | Fragmented Datagrams with UDP Options | receive send v Events: ICMP, Interface MTU, etc. When DPLPMTUD is instead implemented by an Upper Layer protocol, the format and content of probe packets are determined by the Upper Layer protocol. This design is also permitted to use the REQ and RES Options provided by UDP Options. If DPLPMTUD is active at more than one layer, then the values of the tokens used in REQ Options need to be coordinated with any values used for other DPLPMTUD probe packets to ensure that each probe packet can be identified by a unique token. When configurable, a configuration ought to avoid performing such discovery both within UDP Options and also by an Upper Layer protocol that sends and receives probe packets via UDP Options. recommends that: "An application SHOULD avoid using DPLPMTUD when the underlying transport system provides this capability."
Packet Formats The UDP Options used in this document are described in and are used in the following ways:
  • The REQ Option is set by a sending PL to solicit a response from a remote receiver. A four-byte (four-octet) token identifies each request.
  • A sending PL can use the EOL Option together with a minimum datagram length to pad probe packets.
  • The RES Option is sent by a UDP Options receiver in response to a previously received REQ Option. Each RES Option echoes the last received four-byte token.
  • If a UDP Options endpoint creates and sends a datagram with a RES Option solely as response to a received REQ Option, the responder MUST limit the rate of these responses (e.g., limiting each pair of ports to send 1 per measured RTT or 1 per second). This rate limit is to mitigate the DoS vector without significantly impacting the operation of DPLPMTUD. An example in describes a case where this might be used.
  • Reception of a RES Option by the REQ sender confirms that a specific probe packet has been received by the remote UDP Options receiver.
The token allows a UDP Options sender to distinguish between acknowledgements for initial probe packets and acknowledgements confirming receipt of subsequent probe packets (e.g., travelling along alternate paths with a larger RTT). Each probe packet MUST be uniquely identifiable by the UDP Options sender within the Maximum Segment Lifetime (MSL) . The UDP Options sender MUST NOT reuse a token value within the MSL. A four-byte value for the token field provides sufficient space for multiple unique probe packets to be made within the MSL. Since UDP Options operates over UDP, the token values only need to be unique for the specific 5-tuple over which it is operating. The value of the four-byte token field SHOULD be initialized to a randomized value to enhance protection from off-path attacks, as described in .
Sending Probe Packets with the Request Option DPLPMTUD relies upon sending a probe packet with a specific size. Each probe packet includes the UDP Options area containing a REQ Option and any other required options concluded with an EOL Option (), followed by any padding needed to inflate to the required probe size. A probe packet can therefore be up to the maximum size supported by the local interface (i.e., the Interface MTU). Item 2 in requires the network interface below DPLPMTUD to provide a way to transmit a probe packet that is larger than the current PLPMTU. The size of this probe packet MUST NOT be constrained by the maximum PMTU set by network layer mechanisms (such as discovered by PMTUD or the PMTU size held in the IP-layer cache), as noted in item 2 in ). UDP datagrams used as DPLPMTUD probe packets, as described in this document, MUST NOT be fragmented at the UDP or IP layer. Therefore, requires: "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."
Receiving UDP Options Probe Packets and Sending the RES Option When DPLPMTUD is enabled, a UDP Options receiver responds by sending a UDP datagram with the RES Option when it receives a UDP Options datagram with the REQ Option. The operation of DPLPMTUD can depend on the support at the remote UDP Options endpoint, the way in which DPLPMTUD is implemented, and in some cases, the application data that is exchanged over the UDP transport service. When UDP Options is not supported by the remote receiver, DPLPMTUD will be unable to confirm the path or to discover the PLPMTU. This will result in the minimum configured PLPMTU (MIN_PLPMTU). More explanation of usage is provided in .
DPLPMTUD Sender Procedures for UDP Options DPLPMTUD utilizes three types of probe. These are described in the following sections:
  • Probes to confirm the path can support the BASE_PLPMTU ().
  • Probes to detect whether the path can support a larger PLPMTU.
  • Probes to validate that the path supports the current PLPMTU.
Confirmation of Connectivity Across a Path The DPLPMTUD method requires a PL to confirm connectivity over the path (), but UDP itself does not offer a mechanism for this. UDP Options can provide this required functionality. A UDP Options sender implementing this specification MUST elicit a positive confirmation of connectivity for the path by sending a probe packet padded to size BASE_PLPMTU. This confirmation probe MUST include the REQ UDP Option to elicit a response from the remote DPLPMTUD. Reception of a datagram with the corresponding RES Option confirms the reception of a packet of the probed size that has successfully traversed the path to the receiver. This also confirms that the remote endpoint supports the RES Option.
Sending Probe Packets to Increase the PLPMTU From time to time, DPLPMTUD enters the SEARCHING state, described in , (e.g., after expiry of the PMTU_RAISE_TIMER) to detect whether the current path can support a larger PLPMTU. When the remote endpoint advertises a UDP Maximum Datagram Size (MDS) Option (see ), this value MAY be used as a hint to initialize this search to increase the PLPMTU. Probe packets seeking to increase the PLPMTU SHOULD NOT carry application data (see "Probing using padding data" in ), since they will be lost whenever their size exceeds the actual PMTU. requires a probe packet to elicit a positive acknowledgement that the path has delivered a datagram of the specific probed size; therefore, a probe packet MUST include the REQ Option when using transport options for UDP . At the receiver, a received probe packet that does not carry application data does not form a part of the end-to-end transport data and is not delivered to the Upper Layer protocol (i.e., application or protocol layered above UDP). A zero-length payload notification could still be delivered to the application (see ), although discusses the implications when using UDP Options.
Validating the Path with UDP Options A PL using DPLPMTUD MUST validate that a path continues to support the PLPMTU discovered in a previous search for a suitable PLPMTU value, as defined in . This validation sends probe packets in the DPLPMTUD SEARCH_COMPLETE state () to detect black-holing of data ( defines a DPLPMTUD black hole). Path validation can be implemented within UDP Options by generating a probe packet of size PLPMTU, which MUST include a REQ Option to elicit a positive confirmation that the path has delivered this probe packet. A probe packet used to validate the path MAY use either "Probing using padding data" to construct a probe packet that does not carry any application data or "Probing using application data and padding data"; see . When using "Probing using padding data", the UDP Options API does not indicate receipt of the zero-length probe packet (see ).
Probe Packets That Do Not Include Application Data A simple implementation of the method might be designed to only use probe packets in a UDP datagram that includes no application data. The size of each probe packet is padded to the required probe size including the REQ Option. This implements "Probing using padding data" () and avoids having to retransmit application data when a probe fails. This could be achieved by setting a minimum datagram length, such that the options list ends in EOL () with any additional space zero-filled as needed (see ). In this use, the probe packets do not form a part of the end-to-end transport data and a receiver does not deliver them to the Upper Layer protocol.
Probe Packets That Include Application Data An implementation always uses the format in when DPLPMTUD searches to increase the PLPMTU. An alternative format is permitted for a probe packet that is used to confirm the connectivity or to validate the path. These probe packets MAY carry application data. (UDP payload data is permitted because these probe packets perform black-hole detection and will therefore usually have a higher probability of successful transmission, similar to other packets sent by the Upper Layer protocol.) provides a discussion of the merits and demerits of including application data. For example, this reduces the need to send additional datagrams. This type of probe packet MAY use a control message format defined by the Upper Layer protocol, provided that the message does not need to be delivered reliably. The REQ Option MUST be included when the sending Upper Layer protocol performs DPLPMTUD. The DPLPMTUD method tracks the transmission of probe packets (using the REQ Option token). A receiver that responds to DPLPMTUD MUST process the REQ Option and include the corresponding RES Option with an Upper Layer protocol message that it returns to the requester (examples of receiver processing are provided in ). Probe packets that use this format form a part of the end-to-end transport data and can be used to manage the PLPMTU in just one direction or can be used for both directions.
Receiving Events from the Network This specification does not rely upon reception of events from the network, but an implementation can utilize these events when they are provided.
Changes in the Path A change in the path or the loss of a probe packet can result in DPLPMTUD updating the PLPMTU. DPLPMTUD recommends 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. For example, a notification that a path has changed could trigger path validation to provide black-hole protection (). An Upper Layer protocol could trigger DPLPMTUD to validate the path when it observes a high packet loss rate (or a repeated protocol timeout) . requires any methods designed to share the PLPMTU between PLs (such as updating the IP cache PMTU for an interface/destination) to be robust to the wide variety of underlying network forwarding behaviors. For example, an implementation could avoid sharing PMTU information that could potentially relate to packets sent with the same address over a different interface.
Validation of PTB Messages Support for receiving ICMP PTB messages is OPTIONAL for DPLPMTUD. A UDP Options sender can therefore ignore received ICMP PTB messages. Before processing an ICMP PTB message, the DPLPMTUD method needs to perform two checks to ensure that the message was received in response to a sent probe packet:
  • DPLPMTUD first utilizes the quoted information in each PTB message. The receiver MUST validate the protocol information in the quoted packet carried in an ICMP PTB message payload to validate the message originated from the sending node (see ).
  • The receiver SHOULD utilize information that is not simple for an off-path attacker to determine (see ). Specifically, a UDP Options receiver SHOULD confirm that the token contained in the UDP REQ Option of the quoted packet has a value that corresponds to a probe packet that was recently sent by the current endpoint.
An implementation unable to support this validation MUST ignore received ICMP PTB messages.
Examples with Different Receiver Behaviors When enabled, a DPLPMTUD endpoint that implements UDP Options normally responds with a UDP datagram with a RES Option when requested by a sender. The following examples describe various possible receiver behaviors:
  • No DPLPMTUD receiver support: One case is when a sender supports this specification, but no RES Option is received from the remote endpoint. In this example, the method is unable to discover the PLPMTU. This will result in using the MIN_PLPMTU. Such a remote endpoint might be not configured to process UDP Options or might not return a datagram with a RES Option for some other reason (e.g., packet loss, insufficient space to include the option, filtering on the path, etc.).
  • DPLPMTUD receiver uses application datagrams: In a second case, both the sender and receiver support DPLPMTUD using the specification, and the receiver only returns a RES Option with the next UDP datagram that is sent to the requester. Therefore, reception of a REQ Option does not systematically trigger a response. This allows DPLPMTUD to operate when there is a flow of datagrams in both directions, provided there is periodic feedback (e.g., one acknowledgement packet per RTT). It requires the PLPMTU at the receiver to be sufficiently large enough that the RES Option can be included in the feedback packets that are sent in the return direction. This method avoids opportunities to misuse the method as a DoS attack. However, when there is a low rate of transmission (or no datagrams are sent) in the return direction, this will prevent prompt delivery of the RES Option. At the DPLPMTUD sender, this results in probe packets failing to be acknowledged in time and could result in a smaller PLPMTU than is actually supported by the path or in using the MIN_PLPMTU.
  • Unidirectional transfer: Another case is where an application only transfers data in one direction (or predominantly in one direction). In this case, the wait at the receiver for a datagram to be queued before returning a RES Option could easily result in a probe timeout at the DPLPMTUD sender. In this case, DPLPMTUD could allow exchanging datagrams without a payload (as discussed in earlier sections) to return the RES Option.
  • DPLPMTUD receiver permitted to send responses in UDP datagrams with no payload: A DPLPMTUD receiver can generate a datagram (e.g., with zero payload data) solely to return a RES Option (e.g., sent when no other datagrams are queued for transmission). This would allow an endpoint to probe the set of UDP ports that have been configured with support for this specification using a DPLPMTUD probe packet. Although this results in some additional traffic overhead, it has the advantage that it can ensure timely progress of DPLPMTUD. specifies: "If a UDP Options endpoint creates and sends a datagram with a RES Option solely as response to a received REQ Option, the responder MUST limit the rate of these responses (e.g., limiting each pair of ports to send 1 per measured RTT or 1 per second)". This rate limit is to mitigate the DoS vector, without significantly impacting the operation of DPLPMTUD.
IANA Considerations This document has no IANA actions.
Security Considerations The security considerations for using UDP Options are described in . The method does not change the integrity protection offered by the UDP Options method. The security considerations for using DPLPMTUD are described in . On-path attackers could maliciously drop or modify probe packets to seek to decrease the PMTU or to maliciously modify probe packets in an attempt to black-hole traffic. The specification recommends that the token value in the REQ Option is initialized to a randomized value. This is to enhance protection from off-path attacks. If a subsequent probe packet uses a token value that is easily derived from the initial value (e.g., incrementing the value), a misbehaving on-path observer could then determine the token values used for subsequent probe packets from that sender, even if these probe packets are not transiting via the observer. This would allow probe packets to be forged, with an impact similar to other on-path attacks against probe packets. This attack could be mitigated by using an unpredictable token value for each probe packet. The method does not change the ICMP PTB message validation method described by DPLPMTUD: A UDP Options sender that utilizes ICMP PTB messages received to a probe packet MUST use the quoted packet to validate the UDP port information in combination with the token contained in the UDP Option before processing the packet using the DPLPMTUD method. Upper Layer protocols or applications that employ encryption ought to perform DPLPMTUD at a layer above UDP Options and not enable UDP Options support for DPLPMTUD. This allows the application to control when DPLPMTUD is used to control the additional traffic that this generates. This also ensures that DPLPMTUD probe packets are encrypted.
References Normative References User Datagram Protocol Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Packetization Layer Path MTU Discovery for Datagram Transports This document specifies Datagram Packetization Layer Path MTU Discovery (DPLPMTUD). This is a robust method for Path MTU Discovery (PMTUD) for datagram Packetization Layers (PLs). It allows a PL, or a datagram application that uses a PL, to discover whether a network path can support the current size of datagram. This can be used to detect and reduce the message size when a sender encounters a packet black hole. It can also probe a network path to discover whether the maximum packet size can be increased. This provides functionality for datagram transports that is equivalent to the PLPMTUD specification for TCP, specified in RFC 4821, which it updates. It also updates the UDP Usage Guidelines to refer to this method for use with UDP datagrams and updates SCTP. The document provides implementation notes for incorporating Datagram PMTUD into IETF datagram transports or applications that use datagram transports. This specification updates RFC 4960, RFC 4821, RFC 6951, RFC 8085, and RFC 8261. Transport Options for UDP Independent Consultant Unaffiliated Informative References Path MTU discovery This memo describes a technique for dynamically discovering the maximum transmission unit (MTU) of an arbitrary internet path. It specifies a small change to the way routers generate one type of ICMP message. For a path that passes through a router that has not been so changed, this technique might not discover the correct Path MTU, but it will always choose a Path MTU as accurate as, and in many cases more accurate than, the Path MTU that would be chosen by current practice. [STANDARDS-TRACK] Packetization Layer Path MTU Discovery This document describes a robust method for Path MTU Discovery (PMTUD) that relies on TCP or some other Packetization Layer to probe an Internet path with progressively larger packets. This method is described as an extension to RFC 1191 and RFC 1981, which specify ICMP-based Path MTU Discovery for IP versions 4 and 6, respectively. [STANDARDS-TRACK] UDP Usage Guidelines The User Datagram Protocol (UDP) provides a minimal message-passing transport that has no inherent congestion control mechanisms. This document provides guidelines on the use of UDP for the designers of applications, tunnels, and other protocols that use UDP. Congestion control guidelines are a primary focus, but the document also provides guidance on other topics, including message sizes, reliability, checksums, middlebox traversal, the use of Explicit Congestion Notification (ECN), Differentiated Services Code Points (DSCPs), and ports. Because congestion control is critical to the stable operation of the Internet, applications and other protocols that choose to use UDP as an Internet transport must employ mechanisms to prevent congestion collapse and to establish some degree of fairness with concurrent traffic. They may also need to implement additional mechanisms, depending on how they use UDP. Some guidance is also applicable to the design of other protocols (e.g., protocols layered directly on IP or via IP-based tunnels), especially when these protocols do not themselves provide congestion control. This document obsoletes RFC 5405 and adds guidelines for multicast UDP usage. Path MTU Discovery for IP version 6 This document describes Path MTU Discovery (PMTUD) for IP version 6. It is largely derived from RFC 1191, which describes Path MTU Discovery for IP version 4. It obsoletes RFC 1981. Transport Features of the User Datagram Protocol (UDP) and Lightweight UDP (UDP-Lite) This is an informational document that describes the transport protocol interface primitives provided by the User Datagram Protocol (UDP) and the Lightweight User Datagram Protocol (UDP-Lite) transport protocols. It identifies the datagram services exposed to applications and how an application can configure and use the features offered by the Internet datagram transport service. RFC 8303 documents the usage of transport features provided by IETF transport protocols, describing the way UDP, UDP-Lite, and other transport protocols expose their services to applications and how an application can configure and use the features that make up these services. This document provides input to and context for that document, as well as offers a road map to documentation that may help users of the UDP and UDP-Lite protocols.
Acknowledgements and are supported by funding provided by the University of Aberdeen. The authors would like to thank and for their detailed comments and also other people who contributed to completing this document.
Authors' Addresses University of Aberdeen
School of Engineering Fraser Noble Building Aberdeen AB24 3UE United Kingdom gorry@erg.abdn.ac.uk
University of Aberdeen
School of Engineering Fraser Noble Building Aberdeen AB24 3UE United Kingdom tom@erg.abdn.ac.uk