draft-ietf-tsvwg-udp-options-31.txt   draft-ietf-tsvwg-udp-options-32.txt 
TSVWG J. Touch TSVWG J. Touch
Internet Draft Independent Consultant Internet Draft Independent Consultant
Intended status: Standards Track March 4, 2024 Intended status: Standards Track March 21, 2024
Intended updates: 768 Intended updates: 768
Expires: September 2024 Expires: September 2024
Transport Options for UDP Transport Options for UDP
draft-ietf-tsvwg-udp-options-31.txt draft-ietf-tsvwg-udp-options-32.txt
Abstract Abstract
Transport protocols are extended through the use of transport header Transport protocols are extended through the use of transport header
options. This document extends UDP by indicating the location, options. This document updates RFC 768 (UDP) by indicating the
syntax, and semantics for UDP transport layer options. location, syntax, and semantics for UDP transport layer options
within the surplus area after the end of the UDP user data but
before the end of the IP length.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 38 skipping to change at page 1, line 40
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
https://www.ietf.org/shadow.html https://www.ietf.org/shadow.html
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 4, 2024. This Internet-Draft will expire on September 21, 2024.
Copyright Notice Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 25 skipping to change at page 2, line 27
4. Background ....................................................4 4. Background ....................................................4
5. UDP Option Intended Uses ......................................5 5. UDP Option Intended Uses ......................................5
6. UDP Option Design Principles ..................................6 6. UDP Option Design Principles ..................................6
7. The UDP Option Area ...........................................7 7. The UDP Option Area ...........................................7
8. The UDP Surplus Area Structure ...............................10 8. The UDP Surplus Area Structure ...............................10
9. The Option Checksum (OCS) ....................................10 9. The Option Checksum (OCS) ....................................10
10. UDP Options .................................................12 10. UDP Options .................................................12
11. SAFE UDP Options ............................................16 11. SAFE UDP Options ............................................16
11.1. End of Options List (EOL) ..............................17 11.1. End of Options List (EOL) ..............................17
11.2. No Operation (NOP) .....................................17 11.2. No Operation (NOP) .....................................17
11.3. Alternate Payload Checksum (APC) .......................18 11.3. Additional Payload Checksum (APC) ......................18
11.4. Fragmentation (FRAG) ...................................19 11.4. Fragmentation (FRAG) ...................................19
11.5. Maximum Datagram Size (MDS) ............................27 11.5. Maximum Datagram Size (MDS) ............................26
11.6. Maximum Reassembled Datagram Size (MRDS) ...............28 11.6. Maximum Reassembled Datagram Size (MRDS) ...............27
11.7. Echo request (REQ) and echo response (RES) .............28 11.7. Echo request (REQ) and echo response (RES) .............27
11.8. Timestamps (TIME) ......................................29 11.8. Timestamps (TIME) ......................................28
11.9. Authentication (AUTH), RESERVED Only ...................31 11.9. Authentication (AUTH), RESERVED Only ...................30
11.10. Experimental (EXP) ....................................31 11.10. Experimental (EXP) ....................................30
12. UNSAFE Options ..............................................32 12. UNSAFE Options ..............................................31
12.1. UNSAFE Compression (UCMP) ..............................33 12.1. UNSAFE Compression (UCMP) ..............................32
12.2. UNSAFE Encryption (UENC) ...............................33 12.2. UNSAFE Encryption (UENC) ...............................32
12.3. UNSAFE Experimental (UEXP) .............................33 12.3. UNSAFE Experimental (UEXP) .............................32
13. Rules for designing new options .............................33 13. Rules for designing new options .............................32
14. Option inclusion and processing .............................34 14. Option inclusion and processing .............................33
15. UDP API Extensions ..........................................36 15. UDP API Extensions ..........................................35
16. UDP Options are for Transport, Not Transit ..................38 16. UDP Options are for Transport, Not Transit ..................37
17. UDP options vs. UDP-Lite ....................................38 17. UDP options vs. UDP-Lite ....................................37
18. Interactions with Legacy Devices ............................39 18. Interactions with Legacy Devices ............................38
19. Options in a Stateless, Unreliable Transport Protocol .......40 19. Options in a Stateless, Unreliable Transport Protocol .......39
20. UDP Option State Caching ....................................40 20. UDP Option State Caching ....................................39
21. Updates to RFC 768 ..........................................41 21. Updates to RFC 768 ..........................................40
22. Interactions with other RFCs (and drafts) ...................41 22. Interactions with other RFCs (and drafts) ...................40
23. Multicast Considerations ....................................42 23. Multicast Considerations ....................................41
24. Security Considerations .....................................43 24. Security Considerations .....................................42
25. IANA Considerations .........................................45 25. IANA Considerations .........................................44
26. References ..................................................46 26. References ..................................................45
26.1. Normative References ...................................46 26.1. Normative References ...................................45
26.2. Informative References .................................46 26.2. Informative References .................................46
27. Acknowledgments .............................................49 27. Acknowledgments .............................................49
Appendix A. Implementation Information ..........................51 Appendix A. Implementation Information ..........................50
1. Introduction 1. Introduction
Transport protocols use options as a way to extend their Transport protocols use options as a way to extend their
capabilities. TCP [RFC9293], SCTP [RFC9260], and DCCP [RFC4340] capabilities. TCP [RFC9293], SCTP [RFC9260], and DCCP [RFC4340]
include space for these options but UDP [RFC768] currently does not. include space for these options but UDP [RFC768] currently does not.
This document defines an extension to UDP that provides space for This document updates RFC 768 with an extension to UDP that provides
transport options including their generic syntax and semantics for space for transport options including their generic syntax and
their use in UDP's stateless, unreliable message protocol. semantics for their use in UDP's stateless, unreliable message
protocol. The details of the impact on RFC 768 are provided in
Section 21. This extension does not apply to UDP-Lite, as discussed
further in Section 17.
2. Conventions used in this document 2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
In this document, the characters ">>" preceding an indented line(s) In this document, the characters ">>" preceding an indented line(s)
skipping to change at page 5, line 37 skipping to change at page 5, line 45
5. UDP Option Intended Uses 5. UDP Option Intended Uses
UDP options provide a soft control plane to UDP. They enable UDP options provide a soft control plane to UDP. They enable
capabilities available in other transport protocols, such as capabilities available in other transport protocols, such as
fragmentation and reassembly, that enable UDP frames larger than the fragmentation and reassembly, that enable UDP frames larger than the
IP MTU to traverse devices that rely on transport ports, e.g., NATs. IP MTU to traverse devices that rely on transport ports, e.g., NATs.
It adds features that may, in the future, protect transport It adds features that may, in the future, protect transport
integrity and validate source identity (authentication), as well as integrity and validate source identity (authentication), as well as
those that may also encrypt the user payload, while still protecting those that may also encrypt the user payload, while still protecting
the UDP transport header - unlike DTLS. They also enable the UDP transport header - unlike DTLS. They also enable
packetization-layer path MTU discovery (PLPMTUD) over UDP, providing packetization-layer path MTU discovery (PLPMTUD) over UDP, known as
a means for probe packet validation without affecting the user data Datagram Packetization Layer Path Maximum Transmission Unit
plane, as well as providing explicit indication of the receiver Discovery DPLPMTUD [Fa24], providing a means for probe packet
transport reassembly size. validation without affecting the user data plane, as well as
providing explicit indication of the receiver transport reassembly
size.
UDP was originally intended to assume such capabilities could be UDP was originally intended to assume such capabilities could be
provided by the user or by a layer above UDP. However, enough provided by the user or by a layer above UDP. However, enough
protocols have evolved to use UDP directly, so such an intermediate protocols have evolved to use UDP directly, so such an intermediate
layer would be difficult to deploy for legacy applications. UDP layer would be difficult to deploy for legacy applications. UDP
options leverage the opportunity presented by the surplus area to options leverage the opportunity presented by the surplus area to
enable these extensions within the UDP transport layer itself. enable these extensions within the UDP transport layer itself.
6. UDP Option Design Principles 6. UDP Option Design Principles
skipping to change at page 6, line 50 skipping to change at page 7, line 12
either replace these other protocols nor to instrument UDP to either replace these other protocols nor to instrument UDP to
replace the need for network testing devices. replace the need for network testing devices.
5. UDP options are a framework, not a protocol. 5. UDP options are a framework, not a protocol.
Options can be defined in this initial document even when the Options can be defined in this initial document even when the
details are not sufficient to specify a complete protocol. Uses details are not sufficient to specify a complete protocol. Uses
of such options may then be described or supplemented in other of such options may then be described or supplemented in other
documents. Examples herein include REQ/RES and TIME; in both documents. Examples herein include REQ/RES and TIME; in both
cases, the option format is defined, but the protocol that uses cases, the option format is defined, but the protocol that uses
these is specified elsewhere (REQ/RES for DPLPMTUD [Fa23])or left these is specified elsewhere (REQ/RES for DPLPMTUD [Fa24]) or
undefined (TIME). left undefined (TIME).
6. The UDP option mechanism and UDP options themselves should 6. The UDP option mechanism and UDP options themselves should
default to the same behavior experienced by a legacy receiver. default to the same behavior experienced by a legacy receiver.
By default, even when option checksums (OCS, APC), By default, even when option checksums (OCS, APC),
authentication, or encryption fail, every received packet is authentication, or encryption fail, every received packet is
passed (possibly with an empty data payload) to the user passed (possibly with an empty data payload) to the user
application. Options that do not modify user data should (by application. Options that do not modify user data should (by
default) result in the user data also being passed, even if, default) result in the user data also being passed, even if,
e.g., option checksums or authentication fails. It is always the e.g., option checksums or authentication fails. It is always the
user's obligation to override this default behavior explicitly. user's obligation to override this default behavior explicitly.
These principles are intended to enable the design and use of UDP These principles are intended to enable the design and use of UDP
options with minimal impact to legacy UDP endpoints, preferably options with minimal impact to legacy UDP endpoints, preferably
none. UDP is - and remains - a minimal transport protocol. none. UDP is - and remains - a minimal transport protocol.
Additional capability is explicitly activated by user applications Additional capability is explicitly activated by user applications
or libraries acting on their behalf. or libraries acting on their behalf.
Finally, although not a strict principle, UDP options do not attempt Finally, UDP options do not attempt to match the number of zero-
to match the number of zero-length UDP datagrams received by legacy length UDP datagrams received by legacy and option-aware receivers
and option-aware receivers from a source using UDP options. Zero- from a source using UDP options. Legacy receivers interpret every
length UDP packets have been used as "liveness" indicators see UDP fragment as a zero-length packet (because they do not perform
Section 5 of [RFC8085]), but such use is dangerous because they lack reassembly), but option-aware receivers would reassemble the packet
unique identifiers (IPv6 has none, the IPv4 ID field is deprecated as a non-zero-length packet. Zero-length UDP packets have been used
for such use [RFC6994]). as "liveness" indicators see Section 5 of [RFC8085]), but such use
is dangerous because they lack unique identifiers (the IPv6 base
header has none, the IPv4 ID field is deprecated for such use
[RFC6994]).
7. The UDP Option Area 7. The UDP Option Area
The UDP transport header includes demultiplexing and service The UDP transport header includes demultiplexing and service
identification (port numbers), an error detection checksum, and a identification (port numbers), an error detection checksum, and a
field that indicates the UDP datagram length (including UDP header). field that indicates the UDP datagram length (including UDP header).
The UDP Length field is typically redundant with the size of the The UDP Length field is typically redundant with the size of the
maximum space available as a transport protocol payload, as maximum space available as a transport protocol payload, as
determined by the IP header (see detail in Section 18). The UDP determined by the IP header (see detail in Section 18). The UDP
Option area is created when the UDP Length indicates a smaller Option area is created when the UDP Length indicates a smaller
skipping to change at page 10, line 32 skipping to change at page 10, line 32
>> Option area bytes used for alignment before the OCS MUST be zero. >> Option area bytes used for alignment before the OCS MUST be zero.
The OCS contains an optional ones-complement sum that detects errors The OCS contains an optional ones-complement sum that detects errors
in the surplus area, which is not otherwise covered by the UDP in the surplus area, which is not otherwise covered by the UDP
checksum, as detailed in Section 9. checksum, as detailed in Section 9.
The remainder of the surplus area consists of options defined using The remainder of the surplus area consists of options defined using
a TLV (type, length, and optional value) syntax similar to that of a TLV (type, length, and optional value) syntax similar to that of
TCP [RFC9293], as detailed in Section 10. These options continue TCP [RFC9293], as detailed in Section 10. These options continue
until the end of the surplus area or can end earlier using the EOL until the end of the surplus area or can end earlier using the EOL
(end of list) option, followed by zeroes. (end of list) option, followed by zeroes (discussed further in
Section 10).
9. The Option Checksum (OCS) 9. The Option Checksum (OCS)
The Option Checksum (OCS) option is conventional Internet checksum The Option Checksum (OCS) option is a conventional Internet checksum
[RFC791] that detects errors in the surplus area. The OCS option [RFC791] that detects errors in the surplus area. The OCS option
contains a 16-bit checksum that is aligned to the first 2-byte contains a 16-bit checksum that is aligned to the first 2-byte
boundary, preceded by zeroes for padding (if needed), as shown in boundary, preceded by zeroes for padding (if needed), as shown in
Figure 4. Figure 4.
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| UDP data | 0 | | UDP data | 0 |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| OCS | UDP options... | | OCS | UDP options... |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
skipping to change at page 11, line 24 skipping to change at page 11, line 27
The design enables traversal of errant middleboxes that incorrectly The design enables traversal of errant middleboxes that incorrectly
compute the UDP checksum over the entire IP payload [Fa18][Zu20], compute the UDP checksum over the entire IP payload [Fa18][Zu20],
rather than only the UDP header and UDP payload (as indicated by the rather than only the UDP header and UDP payload (as indicated by the
UDP header length). Because the OCS is computed over the surplus UDP header length). Because the OCS is computed over the surplus
area and its length and then inverted, OCS effectively negates the area and its length and then inverted, OCS effectively negates the
effect that incorrectly including the surplus has on the UDP effect that incorrectly including the surplus has on the UDP
checksum. As a result, when OCS is non-zero, the UDP checksum is the checksum. As a result, when OCS is non-zero, the UDP checksum is the
same in either case. same in either case.
>> OCS MUST be non-zero when the UDP checksum is non-zero. >> The OCS MUST be non-zero when the UDP checksum is non-zero.
>> When the UDP checksum is zero, the OCS MAY be unused, and is then >> When the UDP checksum is zero, the OCS MAY be unused, and is then
indicated by a zero OCS value. indicated by a zero OCS value.
>> UDP option implementations MUST default to using OCS (i.e., as a >> UDP option implementations MUST default to using OCS (i.e., as a
non-zero value); users overriding that default take the risk of not non-zero value); users overriding that default take the risk of not
detecting nonstandard uses of the option area (of which there are detecting nonstandard uses of the option area (of which there are
none currently known). none currently known).
Like the UDP checksum, the OCS is optional under certain Like the UDP checksum, the OCS is optional under certain
skipping to change at page 11, line 46 skipping to change at page 11, line 49
zero for IPv4 [RFC791] and for IPv6 [RFC8200] when UDP payload zero for IPv4 [RFC791] and for IPv6 [RFC8200] when UDP payload
already covered by another checksum, as might occur for tunnels already covered by another checksum, as might occur for tunnels
[RFC6935]. The same exceptions apply to the OCS when used to detect [RFC6935]. The same exceptions apply to the OCS when used to detect
bit errors; an additional exception occurs for its use in the UDP bit errors; an additional exception occurs for its use in the UDP
datagram prior to fragmentation or after reassembly (see Section datagram prior to fragmentation or after reassembly (see Section
11.4). 11.4).
The benefits are similar to allowing UDP checksums to be zero, but The benefits are similar to allowing UDP checksums to be zero, but
the risks differ. OCS is additionally important to ensure packets the risks differ. OCS is additionally important to ensure packets
with UDP options can traverse errant middleboxes [Zu20]. When the with UDP options can traverse errant middleboxes [Zu20]. When the
cost of computing OCS is negligible, it is better to use OCS to cost of computing an OCS is negligible, it is better to use OCS to
ensure such traversal. In cases where such traversal risks can ensure such traversal. In cases where such traversal risks can
safely be ignored, such as controlled environments, over paths where safely be ignored, such as controlled environments, over paths where
traversal is validated, or where upper layer protocols traversal is validated, or where upper layer protocols
(applications, libraries, etc.) can adapt (by enabling OCS when (applications, libraries, etc.) can adapt (by enabling OCS when
packet exchange fails), and when bit errors at the UDP layer would packet exchange fails), and when bit errors at the UDP layer would
be detected by other layers (as with the UDP checksum) OCS can be be detected by other layers (as with the UDP checksum) OCS can be
disabled, e.g., to conserve energy or processing resources or when disabled, e.g., to conserve energy or processing resources or when
it can improve performance. This is why zeroing OCS is only safe it can improve performance. This is why zeroing OCS is only safe
when UDP checksum is also zero, but why OCS might still be used in when UDP checksum is also zero, but why OCS might still be used in
that case. that case.
The OCS covers the surplus area as formatted for transmission and is The OCS covers the surplus area as formatted for transmission and is
processed immediately upon reception. processed immediately upon reception.
>> If the OCS fails, all options MUST be ignored and the surplus >> If the receiver validation of the OCS fails, all options MUST be
area silently discarded. ignored and the surplus area silently discarded.
>> UDP user data that is validated by a correct UDP checksum MUST be >> UDP user data that is validated by a correct UDP checksum MUST be
delivered to the application layer, even if the OCS fails, unless delivered to the application layer, even if the OCS fails, unless
the endpoints have negotiated otherwise for this UDP packet's socket the endpoints have negotiated otherwise for this UDP packet's socket
pair. pair.
When not used (i.e., containing zero), the OCS is assumed to be When not used (i.e., containing zero), the OCS is assumed to be
"correct" for the purpose of accepting UDP datagrams at a receiver "correct" for the purpose of accepting UDP datagrams at a receiver
(see Section 14). (see Section 14).
skipping to change at page 14, line 9 skipping to change at page 14, line 9
>> UDP options MUST be interpreted in the order in which they occur >> UDP options MUST be interpreted in the order in which they occur
in the surplus area. in the surplus area.
The following UDP options are currently defined: The following UDP options are currently defined:
Kind Length Meaning Kind Length Meaning
---------------------------------------------- ----------------------------------------------
0* - End of Options List (EOL) 0* - End of Options List (EOL)
1* - No operation (NOP) 1* - No operation (NOP)
2* 6 Alternate payload checksum (APC) 2* 6 Additional payload checksum (APC)
3* 10/12 Fragmentation (FRAG) 3* 10/12 Fragmentation (FRAG)
4* 4 Maximum datagram size (MDS) 4* 4 Maximum datagram size (MDS)
5* 4 Maximum reassembled datagram size (MRDS) 5* 4 Maximum reassembled datagram size (MRDS)
6* 6 Request (REQ) 6* 6 Request (REQ)
7* 6 Response (RES) 7* 6 Response (RES)
8 10 Timestamps (TIME) 8 10 Timestamps (TIME)
9 (varies) RESERVED for Authentication (AUTH) 9 (varies) RESERVED for Authentication (AUTH)
10-126 (varies) UNASSIGNED (assignable by IANA) 10-126 (varies) UNASSIGNED (assignable by IANA)
127 (varies) RFC 3692-style experiments (EXP) 127 (varies) RFC 3692-style experiments (EXP)
128-191 RESERVED 128-191 RESERVED
192 (varies) RESERVED for Compression (UCMP) 192 (varies) RESERVED for Compression (UCMP)
193 (varies) RESERVED for Encryption (UENC) 193 (varies) RESERVED for Encryption (UENC)
194-253 UNASSIGNED-UNSAFE (assignable by IANA) 194-253 UNASSIGNED-UNSAFE (assignable by IANA)
254 (varies) RFC 3692-style experiments (UEXP) 254 (varies) RFC 3692-style experiments (UEXP)
255 RESERVED-UNSAFE 255 RESERVED-UNSAFE
Options indicated by Kind values in the range 0..191 are known as Options indicated by Kind values in the range 0..191 are known as
SAFE options because they do not alter the UDP data payload and thus SAFE options because they do not interfere with use of that data by
do not interfere with use of that data by legacy endpoints or when legacy endpoints or when the option is unsupported. Options
the option is unsupported. Options indicated by Kind values in the indicated by Kind values in the range 192..255 are known as UNSAFE
range 192..255 are known as UNSAFE options because they do alter the options because might interfere with use by legacy receiving
UDP data payload and thus would interfere with legacy endpoints. endpoints (e.g., an option that alters the UDP data payload).
UNSAFE option nicknames are expected to begin with capital "U", UNSAFE option nicknames are expected to begin with capital "U",
which should be avoided for SAFE option nicknames (see Section 25). which should be avoided for SAFE option nicknames (see Section 25).
RESERVED and RESERVED-UNSAFE are not assignable by IANA and not RESERVED and RESERVED-UNSAFE are not assignable by IANA and not
otherwise defined at this time. The AUTH, UCMP, and UENC otherwise defined at this time. The AUTH, UCMP, and UENC
reservations are intended for all future options supporting reservations are intended for all future options supporting
authentication, compression, and encryption, respectively, and authentication, compression, and encryption, respectively, and
remain reserved until assigned for those uses. remain reserved until assigned for those uses.
Although the FRAG option modifies the original UDP payload contents Although the FRAG option modifies the original UDP payload contents
(i.e., is UNSAFE with respect to the original UDP payload), it is (i.e., is UNSAFE with respect to the original UDP payload), it is
skipping to change at page 15, line 7 skipping to change at page 15, line 10
Section 11.4. Section 11.4.
These options are defined in the following subsections. Options 0 These options are defined in the following subsections. Options 0
and 1 use the same values as for TCP. and 1 use the same values as for TCP.
>> An endpoint supporting UDP options MUST support those marked with >> An endpoint supporting UDP options MUST support those marked with
a "*" above: EOL, NOP, APC, FRAG, MDS, MRDS, REQ, and RES. This a "*" above: EOL, NOP, APC, FRAG, MDS, MRDS, REQ, and RES. This
includes both recognizing and being able to generate these options includes both recognizing and being able to generate these options
if configured to do so. These are called "must-support" options. if configured to do so. These are called "must-support" options.
>> An endpoint supporting UDP options MUST treat unsupported options
in the UNSAFE range as terminating all option processing.
>> All other SAFE options (without a "*") MAY be implemented, and >> All other SAFE options (without a "*") MAY be implemented, and
their use SHOULD be determined either out-of-band or negotiated, their use SHOULD be determined either out-of-band or negotiated,
notably if needed to detect when options are silently ignored by notably if needed to detect when options are silently ignored by
legacy receivers. legacy receivers.
>> Receivers supporting UDP options MUST silently ignore unknown >> Receivers supporting UDP options MUST silently ignore unknown
SAFE options (i.e., in the same way a legacy receiver would ignore SAFE options (i.e., in the same way a legacy receiver would ignore
all UDP options). That includes options whose length does not all UDP options). That includes options whose length does not
indicate the specified value(s), as long as the length is not indicate the specified value(s), as long as the length is not
inherently invalid (i.e., smaller than 2 for the default and 4 for inherently invalid (i.e., smaller than 2 for the default and 4 for
the extended formats). the extended formats).
>> UNSAFE options MUST be used only with the FRAG option, in a >> UNSAFE options MUST be used only with the FRAG option, in a
manner that prevents them from being silently ignored while still manner that prevents them from being silently ignored while still
passing up potentially modified UDP payload. This ensures their safe passing up potentially modified UDP payload. This ensures their safe
use in environments that might include legacy receivers (See Section use in environments that might include legacy receivers (See Section
12), because the UDP payload occurs inside the FRAG option area and 12), because the UDP payload occurs inside the FRAG option area and
is silently discarded by legacy receivers. is silently discarded by legacy receivers.
>> Receivers supporting UDP options MUST silently drop all UDP >> Receivers supporting UDP options that receive unsupported options
options in a datagram containing an UNSAFE option when any UNSAFE in the UNSAFE range MUST terminate all option processing and MUST
option it contains is unknown. See Section 12 for further discussion silently drop all UDP options in that datagram. See Section 12 for
of UNSAFE options. further discussion of UNSAFE options.
>> Each option SHOULD NOT occur more than once in a single UDP >> Each option SHOULD NOT occur more than once in a single UDP
datagram, the only exceptions being NOP, EXP, and UEXP. If an option datagram, the only exceptions being NOP, EXP, and UEXP. If an option
other than these occurs more than once, a receiver MUST interpret other than these occurs more than once, a receiver MUST interpret
only the first instance of that option and MUST ignore all others. only the first instance of that option and MUST ignore all others.
Section 24 provides additional advice for DOS issues that involve Section 24 provides additional advice for DOS issues that involve
large numbers of options, whether valid, unknown, or repeating. large numbers of options, whether valid, unknown, or repeating.
>> EXP and UEXP MAY occur more than once, but SHOULD NOT occur more >> EXP and UEXP MAY occur more than once, but SHOULD NOT occur more
than once using the same ExID (see Sections 11.10 and 12.3). than once using the same ExID (see Sections 11.10 and 12.3).
skipping to change at page 16, line 17 skipping to change at page 16, line 16
unpredictable. This does not prohibit future uses of the entire unpredictable. This does not prohibit future uses of the entire
surplus area; space that would have occurred after the EOL can be surplus area; space that would have occurred after the EOL can be
used as a UDP option instead, i.e., rather than using the EOL option used as a UDP option instead, i.e., rather than using the EOL option
and trying to defining meaning beyond it, define a new option that and trying to defining meaning beyond it, define a new option that
uses the remaining surplus area as an option itself, in conjunction uses the remaining surplus area as an option itself, in conjunction
with an assigned UDP option codepoint and length to unambiguously with an assigned UDP option codepoint and length to unambiguously
indicate the meaning of that area. This also does not prohibit indicate the meaning of that area. This also does not prohibit
options that modify later options (in order of appearance within a options that modify later options (in order of appearance within a
packet), such as would typically be the case for compression (UCMP). packet), such as would typically be the case for compression (UCMP).
>> Impossible lengths SHOULD be treated as an indication of a
malformed surplus area and all options SHOULD silently be discarded.
This includes lengths that imply a physical impossibility, e.g.,
smaller than two for conventional options and four for extended
length options. Lengths other than those expected result in safe
options being ignored and skipped over, as with any other unknown
safe option.
Receivers cannot generally treat unexpected option lengths as Receivers cannot generally treat unexpected option lengths as
invalid, as this would unnecessarily limit future revision of invalid, as this would unnecessarily limit future revision of
options (e.g., defining a new APC that is defined by having a options (e.g., defining a new APC that is defined by having a
different length). The exception is only for lengths that imply a different length).
physical impossibility, e.g., smaller than two for conventional
options and four for extended length options.
>> Impossible lengths SHOULD be treated as an indication of a
malformed surplus area and all options SHOULD silently be discarded.
Lengths other than those expected MUST result in safe options being
ignored and skipped over, as with any other unknown safe option.
>> Option lengths MUST NOT exceed the IP length of the overall IP >> Option lengths MUST NOT exceed the IP length of the overall IP
datagram. If this occurs, the options MUST be treated as malformed datagram. A receiver MUST drop all options in such a malformed
and all options dropped, and the event MAY be logged for diagnostics packet and the event MAY be logged for diagnostics (logging SHOULD
(logging SHOULD be rate limited). be rate limited).
>> "Must-support" options other than NOP and EOL MUST come before >> "Must-support" options other than NOP and EOL MUST be placed by
other options. the transmitter before other UDP options and a receiver MUST drop
all UDP options in such malformed packet (i.e., in which this
ordering is not honored) and that event MAY be logged for
diagnostics (logging SHOULD be rate limited).
The requirement that must-support options come before others is The requirement that must-support options come before others is
intended to allow for endpoints to implement DOS protection, as intended to allow for endpoints to implement DOS protection, as
discussed further in Section 24. discussed further in Section 24.
11. SAFE UDP Options 11. SAFE UDP Options
SAFE UDP options can be silently ignored by legacy receivers without SAFE UDP options can be silently ignored by legacy receivers without
affecting the meaning of the UDP user data. They stand in contrast affecting the meaning of the UDP user data. They stand in contrast
to UNSAFE options, which modify UDP user data in ways that render it to UNSAFE options, which modify UDP user data in ways that render it
skipping to change at page 17, line 37 skipping to change at page 17, line 37
>> Bytes after EOL in the surplus area MAY be checked as being zero >> Bytes after EOL in the surplus area MAY be checked as being zero
on receipt, but MUST NOT be otherwise processed (except for OCS on receipt, but MUST NOT be otherwise processed (except for OCS
calculation, which zeros would not affect) and MUST NOT be passed to calculation, which zeros would not affect) and MUST NOT be passed to
the user (e.g., as part of the surplus area). the user (e.g., as part of the surplus area).
Requiring the post-option surplus area to be zero prevents side- Requiring the post-option surplus area to be zero prevents side-
channel uses of this area, requiring instead that all use of the channel uses of this area, requiring instead that all use of the
surplus area be UDP options supported by both endpoints. It is surplus area be UDP options supported by both endpoints. It is
useful to allow this area to be used for zero padding to increase useful to allow this area to be used for zero padding to increase
the UDP datagram length without affecting the UDP user data length, the UDP datagram length without affecting the UDP user data length,
e.g., for UDP DPLPMTUD (Section 4.1 of [Fa23]). e.g., for UDP DPLPMTUD (Section 4.1 of [Fa24]).
11.2. No Operation (NOP) 11.2. No Operation (NOP)
The No Operation (NOP, Kind=1) option is a one-byte placeholder, The No Operation (NOP, Kind=1) option is a one-byte placeholder,
intended to be used as padding, e.g., to align multi-byte options intended to be used as padding, e.g., to align multi-byte options
along 16-bit, 32-bit, or 64-bit boundaries. along 16-bit, 32-bit, or 64-bit boundaries.
+--------+ +--------+
| Kind=1 | | Kind=1 |
+--------+ +--------+
skipping to change at page 18, line 20 skipping to change at page 18, line 20
>> Receivers persistently experiencing packets with more than seven >> Receivers persistently experiencing packets with more than seven
consecutive NOPs SHOULD log such events, at least occasionally, as a consecutive NOPs SHOULD log such events, at least occasionally, as a
potential DOS indicator. potential DOS indicator.
NOPs are not reported to the user, whether used per-datagram or per- NOPs are not reported to the user, whether used per-datagram or per-
fragment (as defined in Section 11.4). fragment (as defined in Section 11.4).
This issue is discussed further in Section 24. This issue is discussed further in Section 24.
11.3. Alternate Payload Checksum (APC) 11.3. Additional Payload Checksum (APC)
The Alternate Payload Checksum (APC, Kind=2) option provides a The Additional Payload Checksum (APC, Kind=2) option provides a
stronger alternative to the checksum in the UDP header, using a 32- stronger supplement to the checksum in the UDP header, using a 32-
bit CRC of the conventional UDP user data payload only (excluding bit CRC of the conventional UDP user data payload only (excluding
the IP pseudoheader, UDP header, and surplus area). It is an the IP pseudoheader, UDP header, and surplus area). It is not an
"alternate" to the UDP checksum that covers the user data - not to alternative to the UDP checksum because it does not cover the IP
the OCS (the latter covers the surplus area only). Unlike the UDP pseudoheader or UDP header, and it is not a supplement to the OCS
checksum, APC does not include the IP pseudoheader or UDP header, because the latter covers the surplus area only. Its purpose is to
thus it does not need to be updated by NATs when IP addresses or UDP detect user data errors that the UDP checksum might not detect.
ports are rewritten. Its purpose is to detect user data errors that
the UDP checksum, when used, might not detect.
A CRC32c has been chosen because of its ubiquity and use in other A CRC32c has been chosen because of its ubiquity and use in other
Internet protocols, including iSCSI and SCTP. The option contains Internet protocols, including iSCSI and SCTP. The option contains
the CRC32c in network standard byte order, as described in the CRC32c in network standard byte order, as described in
[RFC3385]. [RFC3385].
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| Kind=2 | Len=6 | CRC32c... | | Kind=2 | Len=6 | CRC32c... |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| CRC32c (cont.) | | CRC32c (cont.) |
skipping to change at page 19, line 8 skipping to change at page 19, line 5
When present, the APC always contains a valid CRC checksum. There When present, the APC always contains a valid CRC checksum. There
are no reserved values, including the value of zero. If the CRC is are no reserved values, including the value of zero. If the CRC is
zero, this must indicate a valid checksum (i.e., it does not zero, this must indicate a valid checksum (i.e., it does not
indicate that the APC is not used; instead, the option would simply indicate that the APC is not used; instead, the option would simply
not be included if that were the desired effect). not be included if that were the desired effect).
APC does not protect the UDP pseudoheader; only the current UDP APC does not protect the UDP pseudoheader; only the current UDP
checksum provides that protection (when used). APC cannot provide checksum provides that protection (when used). APC cannot provide
that protection because it would need to be updated whenever the UDP that protection because it would need to be updated whenever the UDP
pseudoheader changed, e.g., during NAT address and port translation; pseudoheader changed, e.g., during NAT address and port translation.
because this is not the case, APC does not cover the pseudoheader.
>> UDP packets with incorrect APC checksums MUST be passed to the >> UDP packets with incorrect APC checksums SHOULD be passed to the
application by default, e.g., with a flag indicating APC failure. application, e.g., with a flag indicating APC failure. This is the
default behavior for APC.
Like all SAFE UDP options, APC needs to be silently ignored when Like all SAFE UDP options, APC needs to be silently ignored when
failing by default, unless the receiver has been configured to do failing by default, unless the receiver has been configured to do
otherwise. Although all UDP option-aware endpoints support APC otherwise. Although all UDP option-aware endpoints support APC
(being in the required set), this silently-ignored behavior ensures (being in the required set), this silently-ignored behavior ensures
that option-aware receivers operate the same as legacy receivers that option-aware receivers operate the same as legacy receivers
unless overridden. Another reason is because APC may fail even where unless overridden. Another reason is because APC may fail even where
the user data has not been corrupted, such as when its contents have the user data has not been corrupted, such as when its contents have
been overwritten. Such overwrites could be intentional and not been intentionally overwritten e.g. by a middlebox to update
widely known; defaulting to silent ignore ensures that option-aware embedded ports numbers or IP addresses. Such overwrites could be
endpoints do not change how users or applications operate unless intentional and not widely known; defaulting to silent ignore
explicitly directed to do otherwise. ensures that option-aware endpoints do not change how users or
applications operate unless explicitly directed to do otherwise.
>> UDP packets with unrecognized APC lengths MUST receive the same >> UDP packets with unrecognized APC lengths MUST receive the same
treatment as UDP packets with incorrect APC checksums. treatment as UDP packets with incorrect APC checksums.
Ensuring that unrecognized APC lengths are treated as incorrect Ensuring that unrecognized APC lengths are treated as incorrect
checksums enables future variants of APC to be treated as APC-like. checksums enables future variants of APC to be treated as APC-like.
APC is reported to the user, whether used per-datagram or per- APC is reported to the user and useful only per-datagram, because
fragment (as defined in Section 11.4). In the latter case, it is fragments have no UDP user data.
indicated as success only if reassembly is complete.
11.4. Fragmentation (FRAG) 11.4. Fragmentation (FRAG)
The Fragmentation (FRAG, Kind=3) option supports UDP fragmentation The Fragmentation (FRAG, Kind=3) option supports UDP fragmentation
and reassembly, which can be used to transfer UDP messages larger and reassembly, which can be used to transfer UDP messages larger
than allowed by the IP receive MTU (EMTU_R [RFC1122]). FRAG includes than allowed by the IP receive MTU (EMTU_R [RFC1122]). FRAG includes
a copy of the same UDP transport ports in each fragment, enabling a copy of the same UDP transport ports in each fragment, enabling
them to traverse Network Address (and port) Translation (NAT) them to traverse Network Address (and port) Translation (NAT)
devices, in contrast to the behavior of IP fragments. FRAG is devices, in contrast to the behavior of IP fragments. FRAG is
typically used with the UDP MDS and MRDS options to enable more typically used with the UDP MDS and MRDS options to enable more
skipping to change at page 25, line 26 skipping to change at page 24, line 26
Per-fragment UDP options, if used in addition to FRAG, occur before Per-fragment UDP options, if used in addition to FRAG, occur before
the fragment data. They typically occur after the FRAG option, the fragment data. They typically occur after the FRAG option,
except where they modify the FRAG option itself (e.g., UENC or except where they modify the FRAG option itself (e.g., UENC or
UCMP). Per-fragment options are processed before the fragment is UCMP). Per-fragment options are processed before the fragment is
included in the reassembled datagram. Such options can be useful to included in the reassembled datagram. Such options can be useful to
protect the reassembly process itself, e.g., to prevent the protect the reassembly process itself, e.g., to prevent the
reassembly cache from being polluted (using AUTH or UENC). reassembly cache from being polluted (using AUTH or UENC).
>> Fragments of a single datagram MAY use different sets of options. >> Fragments of a single datagram MAY use different sets of options.
It is expected to be prohibitive to validate uniformity across all It is expected to be computationally expensive to validate
fragments and there may be legitimate reasons for including options uniformity across all fragments and there may be legitimate reasons
in a fragment but not all fragments (e.g., MDS, MRDS). for including options in a fragment but not all fragments (e.g.,
MDS, MRDS).
If an option is used per-fragment but defined as not usable per- If an option is used per-fragment but defined as not usable per-
fragment, it is treated the same as any other unknown option. fragment, it is treated the same as any other unknown option.
Per-datagram UDP options, if used, reside in the surplus area of the Per-datagram UDP options, if used, reside in the surplus area of the
original UDP datagram. Processing of those options occurs after original UDP datagram. Processing of those options occurs after
reassembly is complete. This enables the safe use of UNSAFE options, reassembly is complete. This enables the safe use of UNSAFE options,
which are required to result in discarding the entire UDP datagram which are required to result in discarding the entire UDP datagram
if they are unknown to the receiver or otherwise fail (see Section if they are unknown to the receiver or otherwise fail (see Section
12). 12).
skipping to change at page 27, line 8 skipping to change at page 26, line 8
5. Complete the processing associated with creating these additional 5. Complete the processing associated with creating these additional
per-fragment UDP options for each fragment. per-fragment UDP options for each fragment.
Receivers reverse the above sequence. They process all received Receivers reverse the above sequence. They process all received
options in each fragment. When the FRAG option is encountered, the options in each fragment. When the FRAG option is encountered, the
FRAG data is used in reassembly. After all fragments are received, FRAG data is used in reassembly. After all fragments are received,
the entire UDP packet is processed with any trailing UDP options the entire UDP packet is processed with any trailing UDP options
applying to the reassembled user data. applying to the reassembled user data.
>> Reassembly failures at the receiver result in silent discard of >> Reassembly failures at the receiver result in silent discard of
any per-fragment options and fragment contents. Such failures SHOULD any per-fragment options and fragment contents and such failures
NOT generate zero-length frames to the user. SHOULD NOT generate zero-length frames to the user.
>> Finally, because fragmentation processing can be expensive, the >> Finally, because fragmentation processing can be expensive, the
FRAG option SHOULD be avoided unless the original datagram requires FRAG option SHOULD be avoided unless the original datagram requires
fragmentation or it is needed for "safe" use of UNSAFE options. fragmentation or it is needed for "safe" use of UNSAFE options.
>> Users MAY also select the FRAG option to provide limited support >> Users MAY also select the FRAG option to provide limited support
for UDP options in systems that have access to only the initial for UDP options in systems that have access to only the initial
portion of the data in incoming or outgoing packets, with the caveat portion of the data in incoming or outgoing packets, with the caveat
that such packets would be silently ignored by legacy receivers that such packets would be silently ignored by legacy receivers
(that do not support UDP options). (that do not support UDP options).
skipping to change at page 29, line 10 skipping to change at page 28, line 10
The echo request (REQ, Kind=6) and echo response (RES, Kind=7) The echo request (REQ, Kind=6) and echo response (RES, Kind=7)
options provides UDP packet-level acknowledgements as a capability options provides UDP packet-level acknowledgements as a capability
for use by upper layer protocols, e.g., user applications, for use by upper layer protocols, e.g., user applications,
libraries, operating systems, etc. Both the REQ and RES are under libraries, operating systems, etc. Both the REQ and RES are under
the control of these upper layers, i.e., UDP itself never the control of these upper layers, i.e., UDP itself never
automatically responds to a REQ with a RES. Instead, the REQ is automatically responds to a REQ with a RES. Instead, the REQ is
delivered to the upper layer, which decides whether and when to delivered to the upper layer, which decides whether and when to
issue a RES. issue a RES.
One such use is described as part of the UDP options variant of One such use is described as part of DPLPMTUD [Fa24]. The options
packetization layer path MTU discovery (PLPMTUD) [Fa23]. The options
both have the format indicated in Figure 15, in which the token has both have the format indicated in Figure 15, in which the token has
no internal structure or meaning. no internal structure or meaning.
+--------+--------+------------------+ +--------+--------+------------------+
| Kind | Len=6 | token | | Kind | Len=6 | token |
+--------+--------+------------------+ +--------+--------+------------------+
1 byte 1 byte 4 bytes 1 byte 1 byte 4 bytes
Figure 15 UDP REQ and RES options format Figure 15 UDP REQ and RES options format
skipping to change at page 29, line 33 skipping to change at page 28, line 32
supporting REQ/RES and responding with a RES, the upper layer SHOULD supporting REQ/RES and responding with a RES, the upper layer SHOULD
respond with the most recently received REQ token. respond with the most recently received REQ token.
>> REQ/RES MUST be disabled by default, i.e., arriving REQs are >> REQ/RES MUST be disabled by default, i.e., arriving REQs are
silently ignored and RES cannot be issued unless REQ/RES is actively silently ignored and RES cannot be issued unless REQ/RES is actively
enabled, e.g., for DPLPMTUD or other known use by an upper layer enabled, e.g., for DPLPMTUD or other known use by an upper layer
mechanism. mechanism.
For example, an application needs to explicitly enable the For example, an application needs to explicitly enable the
generation of a RES response by DPLPMTUD when using UDP Options generation of a RES response by DPLPMTUD when using UDP Options
[Fa23]. [Fa24].
>> The token used in a RES option MUST be a token received in a REQ >> The token transmitted in a RES option MUST be a token received in
option. This ensures that the response is to a received request. a REQ option by the transmitter. This ensures that the response is
to a received request.
REQ and RES option kinds appear at most once each in each UDP REQ and RES option kinds appear at most once each in each UDP
packet, as with most other options. Note also that the FRAG option packet, as with most other options. Note also that the FRAG option
is not used when sending DPLPMTUD probes to determine a PLPMTU is not used when sending DPLPMTUD probes to determine a PLPMTU
[Fa23]. [Fa24].
REQ and RES are reported to the user, whether used per-datagram or REQ and RES are reported to the user, whether used per-datagram or
per-fragment (as defined in Section 11.4). When used per-fragment, per-fragment (as defined in Section 11.4). When used per-fragment,
the report should indicate the most recently received token. the report should indicate the most recently received token.
11.8. Timestamps (TIME) 11.8. Timestamps (TIME)
The Timestamp (TIME, Kind=8) option exchanges two four-byte unsigned The Timestamp (TIME, Kind=8) option exchanges two four-byte unsigned
timestamp fields. It serves a similar purpose to TCP's TS option timestamp fields. It serves a similar purpose to TCP's TS option
skipping to change at page 31, line 36 skipping to change at page 30, line 36
Like APC, AUTH is a SAFE option because it would not modify the UDP Like APC, AUTH is a SAFE option because it would not modify the UDP
user data. AUTH may fail even where the user data has not been user data. AUTH may fail even where the user data has not been
corrupted, such as when its contents have been overwritten. Such corrupted, such as when its contents have been overwritten. Such
overwrites could be intentional and not widely known; defaulting to overwrites could be intentional and not widely known; defaulting to
silent ignore ensures that option-aware endpoints do not change how silent ignore ensures that option-aware endpoints do not change how
users or applications operate unless explicitly directed to do users or applications operate unless explicitly directed to do
otherwise. otherwise.
11.10. Experimental (EXP) 11.10. Experimental (EXP)
The Experimental option (EXP, Kind=127) is reserved for experiments The Experimental option (EXP, Kind=127) is allocated for experiments
[RFC3692]. Only one such value is reserved because experiments are [RFC3692]. Only one such value is allocated because experiments are
expected to use an Experimental ID (ExIDs) to differentiate expected to use an Experimental ID (ExIDs) to differentiate
concurrent use for different purposes, using UDP ExIDs registered concurrent use for different purposes, using UDP ExIDs registered
with IANA according to the approach developed for TCP experimental with IANA according to the approach developed for TCP experimental
options [RFC6994]. options [RFC6994].
+----------+----------+----------+----------+ +----------+----------+----------+----------+
| Kind=127 | Len | UDP ExID | | Kind=127 | Len | UDP ExID |
+----------+----------+----------+----------+ +----------+----------+----------+----------+
| (option contents, as defined)... | | (option contents, as defined)... |
+----------+----------+----------+----------+ +----------+----------+----------+----------+
Figure 17 UDP EXP option format Figure 17 UDP EXP option format
>> The length of the experimental option MUST be at least 4 to >> The length of the experimental option MUST be at least 4 to
account for the Kind, Length, and the minimum 16-bit UDP ExID account for the Kind, Length, and the 16-bit UDP ExID identifier
identifier (similar to TCP ExIDs [RFC6994]). (similar to TCP ExIDs [RFC6994]).
The UDP EXP option uses only 16-bit ExIDs, unlike TCP ExiDs. In TCP,
the first 16 bits of the ExID is unique; the additional 16 bits,
where present, iss used to decrease the chance of the entire ExID
occurring in legacy use of the TCP EXP option. This extended variant
provides no similar use for UDP EXP because ExIDs are required.
The UDP EXP option also includes an extended length format, where The UDP EXP option also includes an extended length format, where
the option LEN is 255 followed by two bytes of extended length. the option LEN is 255 followed by two bytes of extended length.
+----------+----------+----------+----------+ +----------+----------+----------+----------+
| Kind=127 | 255 | Extended Length | | Kind=127 | 255 | Extended Length |
+----------+----------+----------+----------+ +----------+----------+----------+----------+
| UDP ExID. |(option contents...) | | UDP ExID |(option contents...) |
+----------+----------+----------+----------+ +----------+----------+----------+----------+
Figure 18 UDP EXP extended option format Figure 18 UDP EXP extended option format
Assigned UDP experimental IDs (ExIDs) assigned from a single Assigned UDP experimental IDs (ExIDs) assigned from a single
registry managed by IANA (see Section 25). Assigned ExIDs can be registry managed by IANA (see Section 25). Assigned ExIDs can be
used in either the EXP or UEXP options (see Section 12.3 for the used in either the EXP or UEXP options (see Section 12.3 for the
latter). latter).
12. UNSAFE Options 12. UNSAFE Options
skipping to change at page 33, line 7 skipping to change at page 32, line 9
either per-fragment or after reassembly. either per-fragment or after reassembly.
>> Receivers supporting UDP options MUST silently drop the UDP user >> Receivers supporting UDP options MUST silently drop the UDP user
data of the reassembled datagram if any fragment or the entire data of the reassembled datagram if any fragment or the entire
datagram includes an UNSAFE option whose UKind is not supported or datagram includes an UNSAFE option whose UKind is not supported or
if an UNSAFE option appears outside the context of a fragment or if an UNSAFE option appears outside the context of a fragment or
reassembled fragments. reassembled fragments.
12.1. UNSAFE Compression (UCMP) 12.1. UNSAFE Compression (UCMP)
The UNSAFE Compression (UENC, Kind=192) option is reserved for all The UNSAFE Compression (UCMP, Kind=192) option is reserved for all
UDP compression mechanisms. UCMP is expected to cover the UDP user UDP compression mechanisms. UCMP is expected to cover the UDP user
data and some (e.g., later, in sequence) UDP options. data and some (e.g., later, in sequence) UDP options.
12.2. UNSAFE Encryption (UENC) 12.2. UNSAFE Encryption (UENC)
The UNSAFE Encryption (UENC, Kind=193) option is reserved for all The UNSAFE Encryption (UENC, Kind=193) option is reserved for all
UDP encryption mechanisms. UENC is expected to cover the UDP user UDP encryption mechanisms. UENC is expected to cover the UDP user
data and some (e.g., later, in sequence) UDP options, with possible data and some (e.g., later, in sequence) UDP options, with possible
additional protection of portions of the IP and UDP headers and additional protection of portions of the IP and UDP headers and
potentially also support for NAT traversal, in a similar manner as potentially also support for NAT traversal, in a similar manner as
skipping to change at page 37, line 14 skipping to change at page 36, line 14
o Extend the receive function to indicate the per-packet options o Extend the receive function to indicate the per-packet options
and their parameters as received with the corresponding received and their parameters as received with the corresponding received
datagram. Note that per-fragment options are handled within the datagram. Note that per-fragment options are handled within the
processing of each fragment. processing of each fragment.
>> Options and their processing status (success/fail) MUST be >> Options and their processing status (success/fail) MUST be
available to the user (i.e., application layer or upper layer available to the user (i.e., application layer or upper layer
protocol/service), both for the packet and for the fragment set, protocol/service), both for the packet and for the fragment set,
except for FRAG, NOP, and EOL; those three options are handled except for FRAG, NOP, and EOL; those three options are handled
within UDP option processing only. within UDP option processing only. As a reminder (from Section
14), all options except UNSAFE options MUST result in the UDP
user data being passed to the application layer, regardless of
whether all options are processed, supported, or succeed.
o For fragments, success for an option is reported only when all o For fragments, success for an option is reported only when all
fragments succeed for that option. fragments succeed for that option.
>> Per-fragment option status reporting SHOULD default as needed >> Per-fragment option status reporting SHOULD default as needed
(e.g., not computed and/or not passed up to the upper layers) to (e.g., not computed and/or not passed up to the upper layers) to
minimize overhead unless actively requested (e.g., by the minimize overhead unless actively requested (e.g., by the
user/application layer). user/application layer).
o >> SAFE options associated with fragments are accumulated when o >> SAFE options associated with fragments are accumulated when
skipping to change at page 37, line 38 skipping to change at page 36, line 41
fragment. fragment.
o Extend the send function to indicate the options to be added to o Extend the send function to indicate the options to be added to
the corresponding sent datagram. This includes indicating which the corresponding sent datagram. This includes indicating which
options apply to individual fragments vs. which apply to the UDP options apply to individual fragments vs. which apply to the UDP
packet prior to fragmentation, if fragmentation is enabled. This packet prior to fragmentation, if fragmentation is enabled. This
includes a minimum datagram length, such that the options list includes a minimum datagram length, such that the options list
ends in EOL and additional space is zero-filled as needed. It ends in EOL and additional space is zero-filled as needed. It
also includes a maximum fragment size, e.g., as discovered by also includes a maximum fragment size, e.g., as discovered by
DPLPMTUD, whether implemented at the application layer per DPLPMTUD, whether implemented at the application layer per
[RFC8899] or in conjunction with other UDP options [Fa23]. [RFC8899] or in conjunction with other UDP options [Fa24].
Examples of API instances for Linux and FreeBSD are provided in Examples of API instances for Linux and FreeBSD are provided in
Appendix A, to encourage uniform cross-platform implementations. Appendix A, to encourage uniform cross-platform implementations.
APIs are not intended to provide user control over option order, APIs are not intended to provide user control over option order,
especially on a per-packet basis, as this could create a covert especially on a per-packet basis, as this could create a covert
channel (see Section 24). Similarly, APIs are not intended to channel (see Section 24). Similarly, APIs are not intended to
provide user/application control over UDP fragment boundaries on a provide user/application control over UDP fragment boundaries on a
per-packet basis, although they are expected to allow control over per-packet basis, although they are expected to allow control over
which options, including fragmentation, are enabled (or disabled) on which options, including fragmentation, are enabled (or disabled) on
a per-packet basis. Such control over when fragmentation is used is a per-packet basis. Such control over fragmentation is critical to
critical to DPLPMTUD. DPLPMTUD.
16. UDP Options are for Transport, Not Transit 16. UDP Options are for Transport, Not Transit
UDP options are indicated in the surplus area of the IP payload that UDP options are indicated in the surplus area of the IP payload that
is not used by UDP. That area is really part of the IP payload, not is not used by UDP. That area is really part of the IP payload, not
the UDP payload, and as such, it might be tempting to consider the UDP payload, and as such, it might be tempting to consider
whether this is a generally useful approach to extending IP. whether this is a generally useful approach to extending IP.
Unfortunately, the surplus area exists only for transports that Unfortunately, the surplus area exists only for transports that
include their own transport layer payload length indicator. TCP and include their own transport layer payload length indicator. TCP and
SCTP include header length fields that already provide space for SCTP include header length fields that already provide space for
transport options by indicating the total length of the header area, transport options by indicating the total length of the header area,
such that the entire remaining area indicated in the network layer such that the entire remaining area indicated in the network layer
(IP) is transport payload. UDP-Lite already uses the UDP Length (IP) is transport payload. UDP-Lite already uses the UDP Length
field to indicate the boundary between data covered by the transport field to indicate the boundary between data covered by the transport
checksum and data not covered, and so there is no remaining area checksum and data not covered, and so there is no remaining area
where the length of the UDP-Lite payload as a whole can be indicated where the length of the UDP-Lite payload as a whole can be indicated
[RFC3828]. [RFC3828].
UDP options are intended for modification only by the transport UDP options are transport options. They are no more (or less)
endpoints. They are no more (or less) appropriate to be modified in- appropriate to be modified in-transit than any other portion of the
transit than any other portion of the transport datagram. transport datagram.
>> UDP options are transport options. Generally, transport headers, >> Generally, transport headers, options, and data are not intended
options, and data are not intended to be modified in-transit. UDP to be modified in-transit. UDP options are no exception and here are
options are no exception and here are specified as "MUST NOT" be specified as "MUST NOT" be altered in transit."
altered in transit.
However, note that the UDP option mechanism provides no specific However, note that the UDP option mechanism provides no specific
protection against in-transit modification of the UDP header, UDP protection against in-transit modification of the UDP header, UDP
payload, or surplus area, except as provided by the OCS or the payload, or surplus area, except as provided by the OCS or the
options selected (e.g., AUTH or UENC). options selected (e.g., AUTH or UENC).
Unless protected by encryption (e.g., UENC or via other layers, Unless protected by encryption (e.g., UENC or via other layers,
e.g., IPsec), UDP options remain visible to devices on the network e.g., IPsec), UDP options remain visible to devices on the network
path. path.
skipping to change at page 43, line 22 skipping to change at page 42, line 22
Note that any user application that considers UDP options to affect Note that any user application that considers UDP options to affect
security need not enable them. However, their use does not impact security need not enable them. However, their use does not impact
security in a way substantially different than TCP options; both security in a way substantially different than TCP options; both
enable the use of a control channel that has the potential for enable the use of a control channel that has the potential for
abuse. Similar to TCP, there are many options that, if unprotected, abuse. Similar to TCP, there are many options that, if unprotected,
could be used by an attacker to interfere with communication. could be used by an attacker to interfere with communication.
UDP options create new potential opportunities for DDOS attacks, UDP options create new potential opportunities for DDOS attacks,
notably through the use of fragmentation. When enabled, UDP options notably through the use of fragmentation. When enabled, UDP options
cause additional work at the receiver, however, of the "must- cause additional work at the receiver, however, of the "must-
support" options, only REQ (e.g., when used with DPLPMTUD [Fa23]) support" options, only REQ (e.g., when used with DPLPMTUD [Fa24])
will cause the upper layer to initiate a UDP response in the absence will cause the upper layer to initiate a UDP response in the absence
of user transmission. of user transmission.
The use of UDP packets with inconsistent IP and UDP Length fields The use of UDP packets with inconsistent IP and UDP Length fields
has the potential to trigger a buffer overflow error if not properly has the potential to trigger a buffer overflow error if not properly
handled, e.g., if space is allocated based on the smaller field and handled, e.g., if space is allocated based on the smaller field and
copying is based on the larger. However, there have been no reports copying is based on the larger. However, there have been no reports
of such vulnerability and it would rely on inconsistent use of the of such vulnerability and it would rely on inconsistent use of the
two fields for memory allocation and copying. two fields for memory allocation and copying.
UDP options are not covered by DTLS (datagram transport-layer UDP options are not covered by DTLS (datagram transport-layer
security). Despite the name, neither TLS [RFC8446] (transport layer security). Neither TLS [RFC8446] (transport layer
security, for TCP) nor DTLS [RFC9147] (TLS for UDP) protect the security, for TCP) nor DTLS [RFC9147] (TLS for UDP) protect the
transport layer. Both operate as a shim layer solely on the user transport layer; both operate as a shim layer solely on the user
data of transport packets, protecting only their contents. Just as data of transport packets, protecting only their contents.
TLS does not protect the TCP header or its options, DTLS does not
protect the UDP header or the new options introduced by this Just as TLS does not protect the TCP header or its options, DTLS
document. Transport security is provided in TCP by the TCP does not protect the UDP header or the new options introduced by
this document. Transport security is provided in TCP by the TCP
Authentication Option (TCP-AO [RFC5925]) and (when defined) in UDP Authentication Option (TCP-AO [RFC5925]) and (when defined) in UDP
by the Authentication (AUTH) option (Section 11.9) and (when by the Authentication (AUTH) option (Section 11.9) and (when
defined) the UNSAFE Encryption (UENC) option (Section 12). Transport defined) the UNSAFE Encryption (UENC) option (Section 12). Transport
headers are also protected as payload when using IP security (IPsec) headers are also protected as payload when using IP security (IPsec)
[RFC4301]. [RFC4301].
UDP options use the TLV syntax similar to that of TCP. This syntax UDP options use the TLV syntax similar to that of TCP. This syntax
is known to require serial processing and may pose a DOS risk, e.g., is known to require serial processing and may pose a DOS risk, e.g.,
if an attacker adds large numbers of unknown options that must be if an attacker adds large numbers of unknown options that must be
parsed in their entirety, as is the case for IPv6 [RFC8504]. parsed in their entirety, as is the case for IPv6 [RFC8504].
skipping to change at page 45, line 42 skipping to change at page 44, line 42
>> Implementations concerned with the potential use of UDP options >> Implementations concerned with the potential use of UDP options
as a covert channel MAY consider limiting use of some or all as a covert channel MAY consider limiting use of some or all
options. Such implementations SHOULD ensure FRAG, NOP, and EOL are options. Such implementations SHOULD ensure FRAG, NOP, and EOL are
not passed to the receiving user and SHOULD return options in an not passed to the receiving user and SHOULD return options in an
order not related to their sequence in the received packet. order not related to their sequence in the received packet.
25. IANA Considerations 25. IANA Considerations
Upon publication, IANA is hereby requested to create a new registry Upon publication, IANA is hereby requested to create a new registry
for UDP Option Kind numbers, similar to that for TCP Option Kinds; group for UDP Options, consisting of UDP Option Kind numbers and UDP
this assumes the creation of a new UDP registry group in which UDP Option Experimental IDs (ExIDs).
Option Kinds would be the only entry.
Initial values of the UDP Option Kind registry are as listed in Initial values of the UDP Option Kind registry are as listed in
Section 10, including those both assigned and reserved. Additional Section 10, including those both assigned and reserved. Additional
values in this registry are to be assigned from the UNASSIGNED values in this registry are to be assigned from the UNASSIGNED
values in Section 10 by IESG Approval or Standards Action [RFC8126]. values in Section 10 by IESG Approval or Standards Action [RFC8126].
Those assignments are subject to the conditions set forth in this Those assignments are subject to the conditions set forth in this
document, particularly (but not limited to) those in Section 13. The document, particularly (but not limited to) those in Section 13.
r
>> Although option nicknames are not used in-band, new UNSAFE option >> Although option nicknames are not used in-band, new UNSAFE option
names SHOULD commence with the capital letter "U" and avoid either names SHOULD commence with the capital letter "U" and avoid either
uppercase or lowercase "U" as commencing safe options. uppercase or lowercase "U" as commencing safe options.
Upon publication, IANA is hereby requested to create a new registry UDP Experimental Option Experiment Identifiers (UDP ExIDs) are
for UDP Experimental Option Experiment Identifiers (UDP ExIDs) for intended for use in a similar manner as TCP ExIDs [RFC6994]. UDP
use in a similar manner as TCP ExIDs [RFC6994]. UDP ExIDs can be ExIDs can be used in either (or both) the UDP EXP (Section 11.10) or
used in either (or both) the EXP or UEXP options. This registry is UEXP (Section 12.3) options. UDP ExID entries consist of a 16-bit
initially empty. Values in this registry are to be assigned by IANA ExID (in network-standard order), and (as with the TCP ExID) will
using first-come, first-served (FCFS) rules [RFC8126]. Options using preferentially also include a short description and acronym for use
these ExIDs are subject to the same conditions as new options, i.e., in documentation. UDP ExIDs are always 16 bits because their use in
they too are subject to the conditions set forth in this document, EXP and UEXP options is required and thus do not need a larger
particularly (but not limited to) those in Section 13. number space to decrease the probability of accidental occurrence
with non-ExID uses of the experimental options, as is the case with
TCP ExIDs.
Values in this registry are to be assigned by IANA using first-come,
first-served (FCFS) rules applied to both the ExID value and the
acronym [RFC8126]. Options using these ExIDs are subject to the same
conditions as new options, i.e., they too are subject to the
conditions set forth in this document, particularly (but not limited
to) those in Section 13.
The UDP ExID registry is intended to align with the TCP ExID
registry, where all UDP ExIDs are also TCP ExIDs, and the first 16
bits of all TCP ExIDs are also UDP ExIDs. Whether these are
represented as separate registries or as a single registry is at the
discretion of IANA. If as separate registries, this document
requests that each ExID request in either registry generates a
corresponding entry in the other registry. If as a single registry,
please include the direction that "16-bit ExIDs can be used with
either TCP or UDP; 32-bit ExIDs can be used with TCP or their first
16 bits can be used with UDP".
26. References 26. References
26.1. Normative References 26.1. Normative References
[Fa23] Fairhurst, G., T. Jones, "Datagram PLPMTUD for UDP [Fa24] Fairhurst, G., T. Jones, "Datagram PLPMTUD for UDP
Options," draft-ietf-tsvwg-udp-options-dplpmtud, Jun. Options," draft-ietf-tsvwg-udp-options-dplpmtud, Jan.
2023. 2024.
[RFC768] Postel, J., "User Datagram Protocol," RFC 768, August [RFC768] Postel, J., "User Datagram Protocol," RFC 768, August
1980. 1980.
[RFC791] Postel, J., "Internet Protocol," RFC 791, Sept. 1981. [RFC791] Postel, J., "Internet Protocol," RFC 791, Sept. 1981.
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -- [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts --
Communication Layers," RFC 1122, Oct. 1989. Communication Layers," RFC 1122, Oct. 1989.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
skipping to change at page 49, line 28 skipping to change at page 48, line 45
[CERT18] CERT Coordination Center, "TCP implementations vulnerable [CERT18] CERT Coordination Center, "TCP implementations vulnerable
to Denial of Service,", Vulnerability Note VU 962459, to Denial of Service,", Vulnerability Note VU 962459,
Software Engineering Institute, CMU, 2018, Software Engineering Institute, CMU, 2018,
https://www.kb.cert.org/vuls/id/962459. https://www.kb.cert.org/vuls/id/962459.
[To18] Touch, J., "A TCP Authentication Option Extension for [To18] Touch, J., "A TCP Authentication Option Extension for
Payload Encryption," draft-touch-tcp-ao-encrypt, Jul. Payload Encryption," draft-touch-tcp-ao-encrypt, Jul.
2018. 2018.
[To24] Touch, J., "The UDP Authentication Option," draft-touch- [To24] Touch, J., "The UDP Authentication Option," draft-touch-
udp-auth-option, Jul. 2018. tsvwg-udp-auth-opt, Mar. 2024.
[Zu20] Zullo, R., T. Jones, and G. Fairhurst, "Overcoming the [Zu20] Zullo, R., T. Jones, and G. Fairhurst, "Overcoming the
Sorrows of the Young UDP Options," 2020 Network Traffic Sorrows of the Young UDP Options," 2020 Network Traffic
Measurement and Analysis Conference (TMA), IEEE, 2020. Measurement and Analysis Conference (TMA), IEEE, 2020.
27. Acknowledgments 27. Acknowledgments
This work benefitted from feedback from Erik Auerswald, Bob Briscoe, This work benefitted from feedback from Erik Auerswald, Bob Briscoe,
Ken Calvert, Ted Faber, Gorry Fairhurst (including OCS for errant Ken Calvert, Ted Faber, Gorry Fairhurst (including OCS for errant
middlebox traversal), C. M. Heard (including combining previous FRAG middlebox traversal), C. M. Heard (including combining previous FRAG
 End of changes. 55 change blocks. 
155 lines changed or deleted 194 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/