idnits 2.17.1 draft-ietf-tsvwg-udp-options-18.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1743 has weird spacing: '...default mean...' == Line 1783 has weird spacing: '...enabled net.i...' == Line 1784 has weird spacing: '...enabled net....' == Line 1794 has weird spacing: '...default mean...' == Line 1800 has weird spacing: '... params mean...' == (1 more instance...) -- The document date (March 26, 2022) is 733 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2460' is mentioned on line 1443, but not defined ** Obsolete undefined reference: RFC 2460 (Obsoleted by RFC 8200) -- Duplicate reference: RFC2119, mentioned in 'RFC8174', was also mentioned in 'RFC2119'. -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) -- Obsolete informational reference (is this intentional?): RFC 6691 (Obsoleted by RFC 9293) Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TSVWG J. Touch 2 Internet Draft Independent Consultant 3 Intended status: Standards Track March 26, 2022 4 Intended updates: 768 5 Expires: September 2022 7 Transport Options for UDP 8 draft-ietf-tsvwg-udp-options-18.txt 10 Abstract 12 Transport protocols are extended through the use of transport header 13 options. This document extends UDP by indicating the location, 14 syntax, and semantics for UDP transport layer options. 16 Status of this Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 https://www.ietf.org/shadow.html 32 Internet-Drafts are draft documents valid for a maximum of six 33 months and may be updated, replaced, or obsoleted by other documents 34 at any time. It is inappropriate to use Internet-Drafts as 35 reference material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on September 26, 2022. 39 Copyright Notice 41 Copyright (c) 2022 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with 49 respect to this document. Code Components extracted from this 50 document must include Revised BSD License text as described in 51 Section 4.e of the Trust Legal Provisions and are provided without 52 warranty as described in the Revised BSD License. 54 Table of Contents 56 1. Introduction...................................................3 57 2. Conventions used in this document..............................3 58 3. Terminology....................................................3 59 4. Background.....................................................4 60 5. The UDP Option Area............................................5 61 6. The UDP Surplus Area Structure.................................8 62 7. The Option Checksum (OCS)......................................8 63 8. UDP Options...................................................10 64 9. Safe UDP Options..............................................13 65 9.1. End of Options List (EOL)................................13 66 9.2. No Operation (NOP).......................................14 67 9.3. Alternate Payload Checksum (APC).........................14 68 9.4. Fragmentation (FRAG).....................................16 69 9.5. Maximum Datagram Size (MDS)..............................19 70 9.6. Maximum Reassembled Datagram Size (MRDS).................20 71 9.7. Echo request (REQ) and echo response (RES)...............21 72 9.8. Timestamps (TIME)........................................21 73 9.9. Authentication (AUTH)....................................22 74 9.10. Experimental (EXP)......................................23 75 10. UNSAFE Options...............................................24 76 10.1. UNSAFE Encryption (UENC)................................25 77 10.2. UNSAFE Experimental (UEXP)..............................25 78 11. Rules for designing new options..............................25 79 12. Option inclusion and processing..............................26 80 13. UDP API Extensions...........................................28 81 14. UDP Options are for Transport, Not Transit...................29 82 15. UDP options vs. UDP-Lite.....................................29 83 16. Interactions with Legacy Devices.............................30 84 17. Options in a Stateless, Unreliable Transport Protocol........30 85 18. UDP Option State Caching.....................................31 86 19. Updates to RFC 768...........................................31 87 20. Interactions with other RFCs (and drafts)....................32 88 21. Multicast Considerations.....................................33 89 22. Security Considerations......................................33 90 23. IANA Considerations..........................................34 91 24. References...................................................35 92 24.1. Normative References....................................35 93 24.2. Informative References..................................35 94 25. Acknowledgments..............................................38 95 Appendix A. Implementation Information...........................39 97 1. Introduction 99 Transport protocols use options as a way to extend their 100 capabilities. TCP [RFC793], SCTP [RFC4960], and DCCP [RFC4340] 101 include space for these options but UDP [RFC768] currently does not. 102 This document defines an extension to UDP that provides space for 103 transport options including their generic syntax and semantics for 104 their use in UDP's stateless, unreliable message protocol. 106 2. Conventions used in this document 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 110 "OPTIONAL" in this document are to be interpreted as described in 111 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 112 capitals, as shown here. 114 In this document, the characters ">>" preceding an indented line(s) 115 indicates a statement using the key words listed above. This 116 convention aids reviewers in quickly identifying or finding the 117 portions of this RFC covered by these key words. 119 3. Terminology 121 The following terminology is used in this document: 123 o IP datagram [RFC791][RFC8200] - an IP packet, composed of the IP 124 header and an IP payload area 126 o User datagram - a UDP packet, composed of a UDP header and UDP 127 payload; as discussed herein, that payload need not extend to the 128 end of the IP datagram 130 o UDP packet - the more contemporary term used herein to refer to a 131 user datagram [RFC768] 133 o Surplus area - the area of an IP payload that follows a UDP 134 packet; this area is used for UDP options in this document 136 o UDP fragment - one or more components of a UDP packet and its UDP 137 options that enables transmission as IP payloads larger than 138 permitted by IP datagram maximum sizes; note that each UDP 139 fragment is itself transmitted as a UDP packet with its own 140 options 142 o (UDP) User data - the user data field of a UDP packet [RFC768] 144 o UDP Length - the length field of a UDP header [RFC768] 146 o Must-support options - UDP options that all implementations are 147 required to support. Their use in individual UDP packets is 148 optional. 150 4. Background 152 Many protocols include a default, invariant header and an area for 153 header options that varies from packet to packet. These options 154 enable the protocol to be extended for use in particular 155 environments or in ways unforeseen by the original designers. 156 Examples include TCP's Maximum Segment Size, Window Scale, 157 Timestamp, and Authentication Options [RFC793][RFC5925][RFC7323]. 159 Header options are used both in stateful (connection-oriented, e.g., 160 TCP [RFC793], SCTP [RFC4960], DCCP [RFC4340]) and stateless 161 (connectionless, e.g., IPv4 [RFC791], IPv6 [RFC8200]) protocols. In 162 stateful protocols they can help extend the way in which state is 163 managed. In stateless protocols their effect is often limited to 164 individual packets, but they can have an aggregate effect on a 165 sequence of packets as well. 167 UDP is one of the most popular protocols that lacks space for header 168 options [RFC768]. The UDP header was intended to be a minimal 169 addition to IP, providing only ports and a checksum for error 170 detection. This document extends UDP to provide a trailer area for 171 such options, located after the UDP user data. 173 UDP options are possible because UDP includes its own length field, 174 separate from that of the IP header. Other transport protocols infer 175 transport payload length from the IP datagram length (TCP, DCCP, 176 SCTP). There are a number of reasons why Internet historians suggest 177 that UDP includes this field, e.g., to support multiple UDP packets 178 within the same IP datagram or to indicate the length of the UDP 179 user data as distinct from zero padding required for systems that 180 require writes that are not byte-aligned. These suggestions are not 181 consistent with earlier versions of UDP or with concurrent design of 182 multi-segment multiplexing protocols, however, so the real reason 183 remains unknown. Regardless, this field presents an opportunity to 184 differentiate the UDP user data from the implied transport payload 185 length, which this document leverages to support a trailer options 186 field. 188 There are other ways to include additional header fields or options 189 in protocols that otherwise are not extensible. In particular, in- 190 band encoding can be used to differentiate transport payload from 191 additional fields, such as was proposed in [Hi15]. This approach can 192 cause complications for interactions with legacy devices, and is 193 thus not considered further in this document. 195 IPv6 Teredo [RFC6081] uses values of the UDP Length that are larger 196 than the IP payload as an additional type of signal, as noted in 197 Section 20. UDP options uses a value smaller than the IP payload to 198 enable backwards compatibility with existing UDP implementations, 199 i.e., to deliver the UDP Length of UDP user data to the application 200 and silently ignore the additional surplus area data. Using a value 201 larger than the IP payload could either be considered malformed (and 202 ought to be silently dropped by UDP processing) or could cause 203 buffer overruns, and so is not considered silently and safely 204 backward compatible. 206 5. The UDP Option Area 208 The UDP transport header includes demultiplexing and service 209 identification (port numbers), an error detection checksum, and a 210 field that indicates the UDP datagram length (including UDP header). 211 The UDP Length field is typically redundant with the size of the 212 maximum space available as a transport protocol payload, as 213 determined by the IP header (see detail in Section 16). The UDP 214 Option area is created when the UDP Length indicates a smaller 215 transport payload than implied by the IP header. 217 For IPv4, IP Total Length field indicates the total IP datagram 218 length (including IP header) and the size of the IP options is 219 indicated in the IP header (in 4-byte words) as the "Internet Header 220 Length" (IHL), as shown in Figure 1 [RFC791]. As a result, the 221 typical (and largest valid) value for UDP Length is: 223 UDP_Length = IPv4_Total_Length - IPv4_IHL * 4 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 |Version| IHL |Type of Service| Total Length | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | Identification |Flags| Fragment Offset | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | Time to Live | Proto=17 (UDP)| Header Checksum | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | Source Address | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | Destination Address | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 ... zero or more IP Options (using space as indicated by IHL) ... 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | UDP Source Port | UDP Destination Port | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | UDP Length | UDP Checksum | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 Figure 1 IPv4 datagram with UDP header 244 For IPv6, the IP Payload Length field indicates the transport 245 payload after the base IPv6 header, which includes the IPv6 246 extension headers and space available for the transport protocol, as 247 shown in Figure 2 [RFC8200]. Note that the Next HDR field in IPv6 248 might not indicate UDP (i.e., 17), e.g., when intervening IP 249 extension headers are present. For IPv6, the lengths of any 250 additional IP extensions are indicated within each extension 251 [RFC8200], so the typical (and largest valid) value for UDP Length 252 is: 254 UDP_Length = IPv6_Payload_Length - sum(extension header lengths) 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 |Version| Traffic Class | Flow Label | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | Payload Length | Next Hdr | Hop Limit | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 ... 262 | Source Address (128 bits) | 263 ... 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 ... 266 | Destination Address (128 bits) | 267 ... 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 ... zero or more IP Extension headers (each indicating size) ... 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | UDP Source Port | UDP Destination Port | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | UDP Length | UDP Checksum | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 Figure 2 IPv6 datagram with UDP header 278 In both cases, the space available for the UDP packet is indicated 279 by IP, either directly in the base header (for IPv4) or by adding 280 information in the extensions (for IPv6). In either case, this 281 document will refer to this available space as the "IP transport 282 payload". 284 As a result of this redundancy, there is an opportunity to use the 285 UDP Length field as a way to break up the IP transport payload into 286 two areas - that intended as UDP user data and an additional 287 "surplus area" (as shown in Figure 3). 289 IP transport payload 290 <-------------------------------------------------> 291 +--------+---------+----------------------+------------------+ 292 | IP Hdr | UDP Hdr | UDP user data | surplus area | 293 +--------+---------+----------------------+------------------+ 294 <------------------------------> 295 UDP Length 297 Figure 3 IP transport payload vs. UDP Length 299 In most cases, the IP transport payload and UDP Length point to the 300 same location, indicating that there is no surplus area. This is not 301 a requirement of UDP [RFC768] (discussed further in Section 16). 302 This document uses the surplus area for UDP options. 304 The surplus area can commence at any valid byte offset, i.e., it 305 need not be 16-bit or 32-bit aligned. In effect, this document 306 redefines the UDP "Length" field as a "trailer options offset". 308 6. The UDP Surplus Area Structure 310 UDP options use the entire surplus area, i.e., the contents of the 311 IP payload after the last byte of the UDP payload. They commence 312 with a 2-byte Option Checksum (OCS) field aligned to the first 2- 313 byte boundary (relative to the start of the IP datagram) of that 314 area, using zeroes for alignment. The UDP option area can be used 315 with any UDP payload length (including zero), as long as there 316 remains enough space for the aligned OCS and the options used. 318 >> UDP options MAY begin at any UDP length offset. 320 >> Option area bytes used for alignment before the OCS MUST be zero. 322 The OCS contains an optional ones-complement sum that detects errors 323 in the surplus area, which is not otherwise covered by the UDP 324 checksum, as detailed in Section 7. 326 The remainder of the surplus area consists of options defined using 327 a TLV (type, length, and optional value) syntax similar to that of 328 TCP [RFC793], as detailed in Section 8. These options continue until 329 the end of the surplus area or can end earlier using the EOL (end of 330 list) option, followed by zeroes. 332 7. The Option Checksum (OCS) 334 The Option Checksum (OCS) option is conventional Internet checksum 335 [RFC791] that detects errors in the surplus area. The OCS option 336 contains a 16-bit checksum that is aligned to the first 2-byte 337 boundary, preceded by zeroes for padding (if needed), as shown in 338 Figure 4. 340 +--------+--------+--------+--------+ 341 | UDP data | 0 | 342 +--------+--------+--------+--------+ 343 | OCS | UDP options... | 344 +--------+--------+--------+--------+ 346 Figure 4 UDP OCS format, here using one zero for alignment 348 The OCS consists of a 16-bit Internet checksum [RFC1071], computed 349 over the surplus area and including the length of the surplus area 350 as an unsigned 16-bit value. The OCS protects the surplus area from 351 errors in a similar way that the UDP checksum protects the UDP user 352 data (when not zero). 354 The primary purpose of the OCS is to detect non-standard (i.e., non- 355 option) uses of that area and accidental errors. It is not intended 356 to detect attacks, as discussed further in Section 22. 358 The design enables traversal of errant middleboxes that incorrectly 359 compute the UDP checksum over the entire IP payload [Fa18], rather 360 than only the UDP header and UDP payload (as indicated by the UDP 361 header length). Because the OCS is computed over the surplus area 362 and its length and then inverted, OCS effectively negates the effect 363 that incorrectly including the surplus has on the UDP checksum. As a 364 result, when OCS is non-zero, the UDP checksum is the same in either 365 case. 367 >> OCS MUST be non-zero when the UDP checksum is non-zero. 369 >> When the UDP checksum is zero, the OCS MAY be unused, and is then 370 indicated by a zero OCS value. 372 Like the UDP checksum, the OCS is optional under certain 373 circumstances and contains zero when not used. UDP checksums can be 374 zero for IPv4 [RFC791] and for IPv6 [RFC8200] when UDP payload 375 already covered by another checksum, as might occur for tunnels 376 [RFC6935]. The same exceptions apply to the OCS when used to detect 377 bit errors; an additional exception occurs for its use in the UDP 378 datagram prior to fragmentation or after reassembly (see Section 379 9.4). 381 The OCS covers the surplus area as formatted for transmission and is 382 processed immediately upon reception. 384 >> If the OCS fails, all options MUST be ignored and the surplus 385 area silently discarded. 387 >> UDP user data that is validated by a correct UDP checksum MUST be 388 delivered to the application layer, even if the OCS fails, unless 389 the endpoints have negotiated otherwise for this UDP packet's socket 390 pair. 392 When not used (i.e., containing zero), the OCS is assumed to be 393 "correct" for the purpose of accepting UDP datagrams at a receiver 394 (see Section 12). 396 8. UDP Options 398 UDP options are typically a minimum of two bytes in length as shown 399 in Figure 5, excepting only the one byte options "No Operation" 400 (NOP) and "End of Options List" (EOL) described below. 402 +--------+--------+------- 403 | Kind | Length | (remainder of option...) 404 +--------+--------+------- 406 Figure 5 UDP option default format 408 The Kind field is always one byte. The Length field is one byte for 409 all lengths below 255 (including the Kind and Length bytes). A 410 Length of 255 indicates use of the UDP option extended format shown 411 in Figure 6. The Extended Length field is a 16-bit field in network 412 standard byte order. 414 +--------+--------+--------+--------+ 415 | Kind | 255 | Extended Length | 416 +--------+--------+--------+--------+ 417 | (remainder of option...) 418 +--------+--------+--------+--------+ 420 Figure 6 UDP option extended format 422 >> The UDP length MUST be at least as large as the UDP header (8) 423 and no larger than the IP transport payload. Datagrams with length 424 values outside this range MUST be silently dropped as invalid and 425 logged where rate-limiting permits. 427 >> Option Lengths (or Extended Lengths, where applicable) smaller 428 than the minimum for the corresponding Kind MUST be treated as an 429 error. Such errors call into question the remainder of the surplus 430 area and thus MUST result in all UDP options being silently 431 discarded. 433 >> Any UDP option other than EOL and NOP MAY use either the default 434 or extended option formats. 436 >> Any UDP option whose length is larger than 254 MUST use the UDP 437 option extended format shown in Figure 6. 439 >> For compactness, UDP options SHOULD use the smallest option 440 format possible. 442 >> UDP options MUST be interpreted in the order in which they occur 443 in the surplus area. 445 The following UDP options are currently defined: 447 Kind Length Meaning 448 ---------------------------------------------- 449 0* - End of Options List (EOL) 450 1* - No operation (NOP) 451 2* 6 Alternate payload checksum (APC) 452 3* 10/12 Fragmentation (FRAG) 453 4* 4 Maximum datagram size (MDS) 454 5* 4 Maximum reassembled datagram size (MRDS) 455 6* 6 Request (REQ) 456 7* 6 Response (RES) 457 8 10 Timestamps (TIME) 458 9 (varies) Authentication (AUTH) 459 10-126 (varies) UNASSIGNED (assignable by IANA) 460 127 (varies) RFC 3692-style experiments (EXP) 461 128-191 RESERVED 463 192 (varies) Encryption (UENC) 464 193-253 UNASSIGNED-UNSAFE (assignable by IANA) 465 254 (varies) RFC 3692-style experiments (UEXP) 466 255 RESERVED 468 Options indicated by Kind values in the range 0..127 are known as 469 SAFE options because they do not alter the UDP data payload and thus 470 do not interfere with use of that data by legacy endpoints. Options 471 indicated by Kind values in the range 192..254 are known as UNSAFE 472 options because they do alter the UDP data payload and thus would 473 interfere with legacy endpoints. UNSAFE option nicknames are 474 expected to begin with "U", which should be avoided for safe option 475 nicknames (see Section 23). Kind values 128-191 and 255 are RESERVED 476 and not otherwise defined at this time. 478 >> RESERVED Kind values MUST NOT be assumed to be either SAFE nor 479 UNSAFE until defined. 481 Although the FRAG option modifies the original UDP payload contents 482 (i.e., is UNSAFE with respect to the original UDP payload), it is 483 used only in subsequent fragments with zero UDP payloads, thus is 484 SAFE in actual use, as discussed further in Section 9.4. 486 These options are defined in the following subsections. Options 0 487 and 1 use the same values as for TCP. 489 >> An endpoint supporting UDP options MUST support those marked with 490 a "*" above: EOL, NOP, APC, FRAG, MDS, MRDS, REQ, and RES. This 491 includes both recognizing and being able to generate these options 492 if configured to do so. These are called "must-support" options. 494 >> An endpoint supporting UDP options MUST treat unsupported options 495 in the UNSAFE range as terminating all option processing. 497 >> All other SAFE options (without a "*") MAY be implemented, and 498 their use SHOULD be determined either out-of-band or negotiated, 499 notably if needed to detect when options are silently ignored by 500 legacy receivers. 502 >> Receivers supporting UDP options MUST silently ignore unknown 503 SAFE options (i.e., in the same way a legacy receiver would). That 504 includes options whose length does not indicate the specified 505 value(s), as long as the length is not inherently invalid (i.e., 506 smaller than 2 for the default and 4 for the extended formats). 508 >> UNSAFE options are used only in with the FRAG option, in a manner 509 that prevents them from being silently ignored but passing the UDP 510 payload to the user when not supported. This ensures their safe use 511 in environments that might include legacy receivers (See Section 512 10). 514 >> Receivers supporting UDP options MUST silently drop all UDP 515 options in a datagram containing an UNSAFE option when any UNSAFE 516 option it contains is unknown. See Section 10 for further discussion 517 of UNSAFE options. 519 >> Except for NOP, EXP, and UEXP, each option SHOULD NOT occur more 520 than once in a single UDP datagram. If an option other than these 521 occurs more than once, a receiver MUST interpret only the first 522 instance of that option and MUST ignore all others. 524 >> EXP and UEXP MAY occur more than once, but SHOULD NOT occur more 525 than once using the same ExID (see Sections 9.10 and 10.2). 527 >> Only the OCS and the AUTH and UENC options depend on the contents 528 of the surplus area. AUTH and UENC are never used together, as UENC 529 would serve both purposes. AUTH and UENC are always computed as if 530 their hash and the OCS are zero; the OCS is always computed as if 531 its contents are zero and after the AUTH or UENC hash has been 532 computed. Future options MUST NOT be defined as having a value 533 dependent on the contents of the surplus area. Otherwise, 534 interactions between those values, the OCS, and the AUTH and UENC 535 options could be unpredictable. 537 Receivers cannot generally treat unexpected option lengths as 538 invalid, as this would unnecessarily limit future revision of 539 options (e.g., defining a new APC that is defined by having a 540 different length). The exception is only for lengths that imply a 541 physical impossibility, e.g., smaller than two for conventional 542 options and four for extended length options. Impossible lengths 543 should indicate a malformed surplus area and all options silently 544 discarded. Lengths other than those expected should result in safe 545 options being ignored and skipped over, as with any other unknown 546 safe option. 548 >> Option lengths MUST NOT exceed the IP length of the overall IP 549 datagram. If this occurs, the options MUST be treated as malformed 550 and all options dropped, and the event MAY be logged for diagnostics 551 (logging SHOULD be rate limited). 553 >> "Must-support" options other than NOP and EOL MUST come before 554 other options. 556 The requirement that must-support options come before others is 557 intended to allow for endpoints to implement DOS protection, as 558 discussed further in Section 22. 560 9. Safe UDP Options 562 Safe UDP options can be silently ignored by legacy receivers without 563 affecting the meaning of the UDP user data. They stand in contrast 564 to Unsafe options, which modify UDP user data in ways that render it 565 unusable by legacy receivers (Section 10). The following subsections 566 describe safe options defined in this document. 568 9.1. End of Options List (EOL) 570 The End of Options List (EOL, Kind=0) option indicates that there 571 are no more options. It is used to indicate the end of the list of 572 options without needing to use NOP options (see the following 573 section) as padding to fill all available option space. 575 +--------+ 576 | Kind=0 | 577 +--------+ 579 Figure 7 UDP EOL option format 581 >> When the UDP options do not consume the entire surplus area, the 582 last non-NOP option MUST be EOL. 584 >> NOPs SHOULD NOT be used as padding before the EOL option. As a 585 one byte option, it need not be otherwise aligned. 587 >> All bytes in the surplus area after EOL MUST be set to zero on 588 transmit. 590 >> Bytes after EOL in the surplus area MAY be checked as being zero 591 on receipt but MUST be treated as zero regardless of their content 592 and are not passed to the user (e.g., as part of the surplus area). 594 Requiring the post-option surplus area to be zero prevents side- 595 channel uses of this area, requiring instead that all use of the 596 surplus area be UDP options supported by both endpoints. It is 597 useful to allow this area to be used for zero padding to increase 598 the UDP datagram length without affecting the UDP user data length, 599 e.g., for UDP DPLPMTUD (Section 4.1 of [Fa22]). 601 9.2. No Operation (NOP) 603 The No Operation (NOP, Kind=1) option is a one-byte placeholder, 604 intended to be used as padding, e.g., to align multi-byte options 605 along 16-bit, 32-bit, or 64-bit boundaries. 607 +--------+ 608 | Kind=1 | 609 +--------+ 611 Figure 8 UDP NOP option format 613 >> UDP packets SHOULD NOT use more than seven consecutive NOPs, 614 i.e., to support alignment up to 8-byte boundaries. UDP packets 615 SHOULD NOT use NOPs at the end of the options area as a substitute 616 for EOL followed by zero-fill. NOPs are intended to assist with 617 alignment, not as other padding or fill. 619 This issue is discussed further in Section 22. 621 9.3. Alternate Payload Checksum (APC) 623 The Alternate Payload Checksum (APC, Kind=2) option provides a 624 stronger alternative to the checksum in the UDP header, using a 32- 625 bit CRC of the conventional UDP user data payload only (excluding 626 the IP pseudoheader, UDP header, and surplus area). It is an 627 "alternate" to the UDP checksum that covers the user data - not to 628 the OCS (the latter covers the surplus area only). Unlike the UDP 629 checksum, APC does not include the IP pseudoheader or UDP header, 630 thus it does not need to be updated by NATs when IP addresses or UDP 631 ports are rewritten. Its purpose is to detect user data errors that 632 the UDP checksum, when used, might not detect. 634 A CRC32c has been chosen because of its ubiquity and use in other 635 Internet protocols, including iSCSI and SCTP. The option contains 636 the CRC32c in network standard byte order, as described in 637 [RFC3385]. 639 +--------+--------+--------+--------+ 640 | Kind=2 | Len=6 | CRC32c... | 641 +--------+--------+--------+--------+ 642 | CRC32c (cont.) | 643 +--------+--------+ 645 Figure 9 UDP APC option format 647 When present, the APC always contains a valid CRC checksum. There 648 are no reserved values, including the value of zero. If the CRC is 649 zero, this must indicate a valid checksum (i.e., it does not 650 indicate that the APC is not used; instead, the option would simply 651 not be included if that were the desired effect). 653 APC does not protect the UDP pseudoheader; only the current UDP 654 checksum provides that protection (when used). APC cannot provide 655 that protection because it would need to be updated whenever the UDP 656 pseudoheader changed, e.g., during NAT address and port translation; 657 because this is not the case, APC does not cover the pseudoheader. 659 >> UDP packets with incorrect APC checksums MUST be passed to the 660 application by default, e.g., with a flag indicating APC failure. 662 Like all safe UDP options, APC needs to be silently ignored when 663 failing by default, unless the receiver has been configured to do 664 otherwise. Although all UDP option-aware endpoints support APC 665 (being in the required set), this silently-ignored behavior ensures 666 that option-aware receivers operate the same as legacy receivers 667 unless overridden. 669 >> UDP packets with unrecognized APC lengths MUST be receive the 670 same treatment as UDP packets with incorrect APC checksums. 672 Ensuring that unrecognized APC lengths are treated as incorrect 673 checksums enables future variants of APC to be treated as APC-like. 675 9.4. Fragmentation (FRAG) 677 The Fragmentation (FRAG, Kind=3) option supports UDP fragmentation 678 and reassembly, which can be used to transfer UDP messages larger 679 than limited by the IP receive MTU (EMTU_R [RFC1122]). FRAG includes 680 a copy of the same UDP transport ports in each fragment, enabling 681 them to traverse Network Address (and port) Translation (NAT) 682 devices, in contrast to the behavior of IP fragments. FRAG is 683 typically used with the UDP MDS and MRDS options to enable more 684 efficient use of large messages, both at the UDP and IP layers. FRAG 685 is designed similar to the IPv6 Fragmentation Header [RFC8200], 686 except that the UDP variant uses a 16-bit Offset measured in bytes, 687 rather than IPv6's 13-bit Fragment Offset measured in 8-byte units. 688 This UDP variant avoids creating reserved fields. 690 >> When FRAG is present, it SHOULD come as early as possible in the 691 UDP options list. 693 >> When FRAG is present, the UDP user data MUST be empty. If the 694 user data is not empty, all UDP options MUST be silently ignored and 695 the user data received sent to the user. 697 Legacy receivers interpret FRAG messages as zero-length user data 698 UDP packets (i.e., UDP Length field is 8, the length of just the UDP 699 header), which would not affect the receiver unless the presence of 700 the UDP packet itself were a signal (see Section 5 of [RFC8085]). 701 In this manner, the FRAG option also helps hide UNSAFE options so 702 they can be used more safely in the presence of legacy receivers. 704 The FRAG option has two formats; non-terminal fragments use the 705 shorter variant (Figure 10) and terminal fragments use the longer 706 (Figure 11). The latter includes stand-alone fragments, i.e., when 707 data is contained in the FRAG option but reassembly is not required. 709 +--------+--------+--------+--------+ 710 | Kind=3 | Len=10 | Frag. Start | 711 +--------+--------+--------+--------+ 712 | Identification | 713 +--------+--------+--------+--------+ 714 | Frag. Offset | 715 +--------+--------+ 717 Figure 10 UDP non-terminal FRAG option format 719 In the non-terminal FRAG option format, Frag. Start indicates the 720 location of the beginning of the fragment data, measured from the 721 beginning of the UDP header of the fragment. The fragment data 722 follows the remainder of the UDP options and continues to the end of 723 the IP datagram (i.e., the end of the surplus area). Those options 724 are applied to this UDP fragment. Non-terminal fragments never have 725 options after the fragment. 727 The Frag. Offset field indicates the location of this fragment 728 relative to the original UDP datagram (prior to fragmentation), 729 measured from the start of the original UDP datagram's UDP header. 731 The FRAG option does not need a "more fragments" bit because it 732 provides the same indication by using the longer, 12-byte variant, 733 as shown in Figure 11. 735 >> The FRAG option MAY be used on a single fragment, in which case 736 the Frag. Offset would be zero and the option would have the 12-byte 737 format. 739 >> Endpoints supporting UDP options MUST be capable of fragmenting 740 and reassembling at least 2 fragments, for a total of at least 3,000 741 bytes (see MRDS in Section 9.6). 743 Use of the single fragment variant can be helpful in supporting use 744 of UNSAFE options without undesirable impact to receivers that do 745 not support either UDP options or the specific UNSAFE options. 747 +--------+--------+--------+--------+ 748 | Kind=3 | Len=12 | Frag. Start | 749 +--------+--------+--------+--------+ 750 | Identification | 751 +--------+--------+--------+--------+ 752 | Frag. Offset | Dgram Opt Start | 753 +--------+--------+--------+--------+ 755 Figure 11 UDP terminal FRAG option format 757 The terminal FRAG option format adds a Datagram Option Start 758 pointer, measured from the start of the original UDP datagram 759 header, indicating the end of the reassembled data and the start of 760 the surplus area after the original UDP datagram. In this variant, 761 UDP options that apply to the reassembled datagram may occur after 762 the terminal fragment data. UDP options that occur before the FRAG 763 data are processed on the fragment; UDP options after the FRAG data 764 are processed after reassembly, such that the reassembled data 765 represents the original UDP user data. This allows either pre- 766 reassembly or post-reassembly UDP option effects, such as using UENC 767 on each fragment while also using TIME on the reassembled datagram 768 for round-trip latency measurements. 770 >> During fragmentation, the UDP header checksum of each fragment 771 remains constant and does not depend on the fragment data (which 772 appears in the surplus area), because all fragments have a zero- 773 length user data field. 775 The Fragment Offset is 16 bits and indicates the location of the UDP 776 payload fragment in bytes from the beginning of the original 777 unfragmented payload. The option Len field indicates whether there 778 are more fragments (Len=10) or no more fragments (Len=12). 780 >> The Identification field is a 32-bit value that MUST be unique 781 over the expected fragment reassembly timeout. 783 >> The Identification field SHOULD be generated in a manner similar 784 to that of the IPv6 Fragment ID [RFC8200]. 786 >> UDP fragments MUST NOT overlap. 788 Similar to IPv6 reassembly [RFC8200], if any of the fragments being 789 reassembled overlap with any other fragments being reassembled for 790 the same UDP packet, reassembly of that UDP packet must be abandoned 791 and all the fragments that have been received for that UDP packet 792 must be discarded, and no ICMP error messages should be sent. 794 It should be noted that fragments may be duplicated in the network. 795 Instead of treating these exact duplicate fragments as overlapping 796 fragments, an implementation may choose to detect this case and drop 797 exact duplicate fragments while keeping the other fragments 798 belonging to the same UDP packet. 800 UDP fragmentation relies on a fragment expiration timer, which can 801 be preset or could use a value computed using the UDP Timestamp 802 option. 804 >> The default UDP reassembly SHOULD be no more than 2 minutes. 806 >> UDP reassembly space SHOULD be limited to reduce the impact of 807 DOS attacks on resource use. 809 >> UDP reassembly space limits SHOULD NOT be computed as a shared 810 resource across multiple sockets, to avoid cross-socketpair DOS 811 attacks. 813 >> Individual UDP fragments MUST NOT be forwarded to the user. The 814 reassembled datagram is received only after complete reassembly, 815 checksum validation, and continued processing of the remaining UDP 816 options. 818 Any per-datagram UDP options, if used, follow the FRAG option in the 819 final fragment and would be included in the reassembled UDP packet. 820 Processing of those options would commence after reassembly. This is 821 especially important for UNSAFE options, which are interpreted only 822 after FRAG. 824 In general, UDP packets are fragmented as follows: 826 1. Create a UDP packet with data and UDP options, which we will call 827 "D". Note that the UDP options treat the data area as UDP user 828 data and thus must follow that data. 830 Process these UDP options before the rest of the fragmentation 831 steps below. Note that the OCS value of the original packet 832 SHOULD be zero if each fragment will have a non-zero OCS value 833 (as will be the case if the UDP checksum is non-zero). 835 2. Identify the desired fragment size, which we will call "S". This 836 value should take into account the path MTU (if known) and allow 837 space for per-fragment options. 839 3. Fragment "D" into chunks of size no larger than "S"-10 each, with 840 one final chunk no larger than "S"-12. Note that all the non-FRAG 841 options in step #1 need not be limited to the terminal fragment, 842 i.e., the Dgram Opt. Start pointer can indicate the start of the 843 original surplus area anywhere in the reassembled data. 845 4. For each chunk of "D" in step #3, create a zero-data UDP packet 846 followed by the word-aligned OCS, the FRAG option, and any 847 additional UDP options, followed by the FRAG data chunk. 849 The last chunk includes the non-FRAG options noted in step #1 850 after the end of the FRAG data. These UDP options apply to the 851 reassembled user data as a whole when received. 853 5. Process the pre-reassembly UDP options of each fragment. 855 Receivers reverse the above sequence. They process all received 856 options in each fragment. When the FRAG option is encountered, the 857 FRAG data is used in reassembly. After all fragments are received, 858 the entire UDP packet is processed with any trailing UDP options 859 applying to the reassembled user data. 861 9.5. Maximum Datagram Size (MDS) 863 The Maximum Datagram Size (MDS, Kind=4) option is a 16-bit hint of 864 the largest unfragmented UDP packet that an endpoint believes can be 865 received. As with the TCP Maximum Segment Size (MSS) option 866 [RFC793], the size indicated is the IP layer MTU decreased by the 867 fixed IP and UDP headers only [RFC6691]. The space needed for IP and 868 UDP options need to be adjusted by the sender when using the value 869 indicated. The value transmitted is based on EMTU_R, the largest IP 870 datagram that can be received (i.e., reassembled at the receiver) 871 [RFC1122]. However, as with TCP, this value is only a hint at what 872 the receiver believes; it does not indicate a known path MTU and 873 thus MUST NOT be used to limit transmissions. 875 +--------+--------+--------+--------+ 876 | Kind=4 | Len=4 | MDS size | 877 +--------+--------+--------+--------+ 879 Figure 12 UDP MDS option format 881 The UDP MDS option MAY be used as a hint for path MTU discovery 882 [RFC1191][RFC8201], but this may be difficult because of known 883 issues with ICMP blocking [RFC2923] as well as UDP lacking automatic 884 retransmission. It is more likely to be useful when coupled with IP 885 source fragmentation or UDP fragmentation to limit the largest 886 reassembled UDP message as indicated by MRDS (see Section 9.6), 887 e.g., when EMTU_R is larger than the required minimums (576 for IPv4 888 [RFC791] and 1500 for IPv6 [RFC8200]). It can also be used with 889 DPLPMTUD [RFC8899] to provide a hint to maximum DPLPMTU, though it 890 MUST NOT prohibit transmission of larger UDP packets (or fragments) 891 used as DPLPMTU probes. 893 9.6. Maximum Reassembled Datagram Size (MRDS) 895 The Maximum Reassembled Segment Size (MRDS, Kind=5) option is a 16- 896 bit indicator of the largest reassembled UDP segment that can be 897 received. MRDS is the UDP equivalent of IP's EMTU_R but the two are 898 not related [RFC1122]. Using the FRAG option (Section 9.4), UDP 899 packets can be transmitted as transport fragments, each in their own 900 (presumably not fragmented) IP datagram and be reassembled at the 901 UDP layer. 903 +--------+--------+--------+--------+ 904 | Kind=5 | Len=4 | MRDS size | 905 +--------+--------+--------+--------+ 907 Figure 13 UDP MRDS option format 909 >> Endpoints supporting UDP options MUST support a local MRDS of at 910 least 3,000 bytes. 912 9.7. Echo request (REQ) and echo response (RES) 914 The echo request (REQ, Kind=6) and echo response (RES, Kind=7) 915 options provide a means for UDP options to be used to provide UDP 916 packet-level acknowledgements. One such use is described as part of 917 the UDP options variant of packetization layer path MTU discovery 918 (PLPMTUD) [Fa22]. The options both have the format indicated in 919 Figure 14, in which the token has no internal structure or meaning. 921 +--------+--------+------------------+ 922 | Kind | Len=6 | token | 923 +--------+--------+------------------+ 924 1 byte 1 byte 4 bytes 926 Figure 14 UDP REQ and RES options format 928 Each of these option kinds appears at most once in each UDP packet, 929 as with other options. Note also that the FRAG option is not used 930 when sending DPLPMTUD probes to determine a PLPMTU [Fa22]. 932 9.8. Timestamps (TIME) 934 The Timestamp (TIME, Kind=8) option exchanges two four-byte unsigned 935 timestamp fields. It serves a similar purpose to TCP's TS option 936 [RFC7323], enabling UDP to estimate the round trip time (RTT) 937 between hosts. For UDP, this RTT can be useful for establishing UDP 938 fragment reassembly timeouts or transport-layer rate-limiting 939 [RFC8085]. 941 +--------+--------+------------------+------------------+ 942 | Kind=8 | Len=10 | TSval | TSecr | 943 +--------+--------+------------------+------------------+ 944 1 byte 1 byte 4 bytes 4 bytes 946 Figure 15 UDP TIME option format 948 TS Value (TSval) and TS Echo Reply (TSecr) are used in a similar 949 manner to the TCP TS option [RFC7323]. On transmitted UDP packets 950 using the option, TS Value is always set based on the local "time" 951 value. Received TSval and TSecr values are provided to the 952 application, which can pass the TSval value to be used as TSecr on 953 UDP messages sent in response (i.e., to echo the received TSval). A 954 received TSecr of zero indicates that the TSval was not echoed by 955 the transmitter, i.e., from a previously received UDP packet. 957 >> TIME MAY use an RTT estimate based on nonzero Timestamp values as 958 a hint for fragmentation reassembly, rate limiting, or other 959 mechanisms that benefit from such an estimate. 961 >> an application MAY use TIME to compute this RTT estimate for 962 further use by the user. 964 UDP timestamps are modeled after TCP timestamps and have similar 965 expectations. In particular, they are expected to be: 967 o Values are monotonic and non-decreasing except for anticipated 968 number-space rollover events 970 o Values should "increase" (allowing for rollover) according to a 971 typical 'tick' time 973 o A request is defined as TSval being non-zero and a reply is 974 defined as TSecr being non-zero. 976 o A receiver should always respond to a request with the highest 977 TSval received (allowing for rollover), which is not necessarily 978 the most recently received. 980 Rollover can be handled as a special case or more completely using 981 sequence number extension [RFC9187], however zero values need to be 982 avoided explicitly. 984 >> TIME values MUST NOT use zeros as valid time values, because they 985 are used as indicators of requests and responses. 987 9.9. Authentication (AUTH) 989 The Authentication (AUTH, Kind=9) option is intended to allow UDP to 990 provide a similar type of authentication as the TCP Authentication 991 Option (TCP-AO) [RFC5925]. AUTH covers the UDP user data. AUTH 992 supports NAT traversal in a similar manner as TCP-AO [RFC6978]. 993 Figure 16 shows the UDP AUTH format, whose contents are identical to 994 that of the TCP-AO option. 996 +--------+--------+--------+--------+ 997 | Kind=9 | Len | TCP-AO fields...| 998 +--------+--------+--------+--------+ 999 | TCP-AO fields (con't)... | 1000 +--------+--------+--------+--------+ 1002 Figure 16 UDP AUTH option format 1004 Like TCP-AO, AUTH is not negotiated in-band. Its use assumes both 1005 endpoints have populated Master Key Tuples (MKTs), used to exclude 1006 non-protected traffic. 1008 TCP-AO generates unique traffic keys from a hash of TCP connection 1009 parameters. UDP lacks a three-way handshake to coordinate 1010 connection-specific values, such as TCP's Initial Sequence Numbers 1011 (ISNs) [RFC793], thus AUTH's Key Derivation Function (KDF) uses 1012 zeroes as the value for both ISNs. This means that the AUTH reuses 1013 keys when socket pairs are reused, unlike TCP-AO. 1015 >> UDP packets with incorrect AUTH HMACs MUST be passed to the 1016 application by default, e.g., with a flag indicating AUTH failure. 1018 Like all non-UNSAFE UDP options, AUTH needs to be silently ignored 1019 when failing. This silently-ignored behavior ensures that option- 1020 aware receivers operate the same as legacy receivers unless 1021 overridden. 1023 In addition to the UDP user data (which is always included), AUTH 1024 can be configured to either include or exclude the surplus area, in 1025 a similar way as can TCP-AO can optionally exclude TCP options. When 1026 UDP options are covered, the OCS value and AUTH (and later, UENC) 1027 hash areas are zeroed before computing the AUTH hash. It is 1028 important to consider that options not yet defined might yield 1029 unpredictable results if not confirmed as supported, e.g., if they 1030 were to contain other hashes or checksums that depend on the surplus 1031 area contents. This is why such dependencies are not permitted 1032 except as defined for the OCS and the AUTH (and later, UENC) option. 1034 Similar to TCP-AO-NAT, AUTH (and later, UENC) can be configured to 1035 support NAT traversal, excluding (by zeroing out) one or both of the 1036 UDP ports and corresponding IP addresses [RFC6978]. 1038 9.10. Experimental (EXP) 1040 The Experimental option (EXP, Kind=127) is reserved for experiments 1041 [RFC3692]. Only one such value is reserved because experiments are 1042 expected to use an Experimental ID (ExIDs) to differentiate 1043 concurrent use for different purposes, using UDP ExIDs registered 1044 with IANA according to the approach developed for TCP experimental 1045 options [RFC6994]. 1047 +----------+----------+----------+----------+ 1048 | Kind=127 | Len | UDP ExID | 1049 +----------+----------+----------+----------+ 1050 | (option contents, as defined)... | 1051 +----------+----------+----------+----------+ 1053 Figure 17 UDP EXP option format 1055 >> The length of the experimental option MUST be at least 4 to 1056 account for the Kind, Length, and the minimum 16-bit UDP ExID 1057 identifier (similar to TCP ExIDs [RFC6994]). 1059 The UDP EXP option also includes an extended length format, where 1060 the option LEN is 255 followed by two bytes of extended length. 1062 +----------+----------+----------+----------+ 1063 | Kind=127 | 255 | Extended Length | 1064 +----------+----------+----------+----------+ 1065 | UDP ExID. |(option contents...) | 1066 +----------+----------+----------+----------+ 1068 Figure 18 UDP EXP option format 1070 Assigned UDP experimental IDs (ExIDs) assigned from a single 1071 registry managed by IANA (see Section 23). Assigned ExIDs can be 1072 used in either the EXP or UEXP options (see Section 10.2 for the 1073 latter). 1075 10. UNSAFE Options 1077 UNSAFE options are not safe to ignore and can be used 1078 unidirectionally or without soft-state confirmation of UDP option 1079 capability. They are always used only when the user data occurs 1080 inside a reassembled set of one or more UDP fragments, such that if 1081 UDP fragmentation is not supported, the enclosed UDP user data would 1082 be silently dropped anyway. 1084 >> Applications using UNSAFE options SHOULD NOT also use zero-length 1085 UDP packets as signals, because they will arrive when UNSAFE options 1086 fail. Those that choose to allow such packets MUST account for such 1087 events. 1089 >> UNSAFE options MUST be used only as part of UDP fragments, used 1090 either per-fragment or after reassembly. 1092 >> Receivers supporting UDP options MUST silently drop the UDP user 1093 data of the reassembled datagram if any fragment or the entire 1094 datagram includes an UNSAFE option whose UKind is not supported. 1095 Note that this still results in the receipt of a zero-length UDP 1096 datagram. 1098 10.1. UNSAFE Encryption (UENC) 1100 UNSAFE encryption (UENC, Kind=192) has the same format as AUTH 1101 (Section 9.9), except that it encrypts (modifies) the user data. It 1102 provides a similar encryption capability as TCP-AO-ENC, in a similar 1103 manner [To18]. Its fields, coverage, and processing are the same as 1104 for AUTH, except that UENC encrypts only the user data, although it 1105 can (optionally) depend on the surplus area (with certain fields 1106 zeroed, as per AUTH, e.g., providing authentication over the surplus 1107 area). Like AUTH, UENC can be configured to be compatible with NAT 1108 traversal. 1110 10.2. UNSAFE Experimental (UEXP) 1112 The UNSAFE Experimental option (UEXP, Kind=254) is reserved for 1113 experiments [RFC3692]. As with EXP, only one such UEXP value is 1114 reserved because experiments are expected to use an Experimental ID 1115 (ExIDs) to differentiate concurrent use for different purposes, 1116 using UDP ExIDs registered with IANA according to the approach 1117 developed for TCP experimental options [RFC6994]. 1119 Assigned ExIDs can be used with either the UEXP or EXP options. 1121 11. Rules for designing new options 1123 The UDP option Kind space allows for the definition of new options, 1124 however the currently defined options do not allow for arbitrary new 1125 options. The following is a summary of rules for new options and 1126 their rationales: 1128 >> New options MUST NOT modify other option content. 1130 >> New options MUST NOT depend on the content of other options. 1132 >> UNSAFE options can both depend on and vary user data content 1133 because they are contained only inside UDP fragments and thus are 1134 processed only by UDP option capable receivers. 1136 >> New options MUST NOT declare their order relative to other 1137 options, whether new or old. 1139 >> At the sender, new options MUST NOT modify UDP packet content 1140 anywhere except within their option field, excepting only those 1141 contained within the UNSAFE option; areas that need to remain 1142 unmodified include the IP header, IP options, the UDP user data, and 1143 the surplus area (i.e., other options). 1145 >> Options MUST NOT be modified in transit. This includes those 1146 already defined as well as new options. 1148 >> New options MUST NOT require or intend optionally for 1149 modification of any UDP options, including their new areas, in 1150 transit. 1152 Note that only certain of the initially defined options violate 1153 these rules: 1155 o >> Only FRAG and UNSAFE options are permitted to modify the UDP 1156 body. 1158 The following recommendation helps enable efficient zero-copy 1159 processing: 1161 o >> FRAG SHOULD be the first option, when present. 1163 12. Option inclusion and processing 1165 The following rules apply to option inclusion by senders and 1166 processing by receivers. 1168 >> Senders MAY add any option, as configured by the API. 1170 >> All "must-support" options MUST be processed by receivers, if 1171 present (presuming UDP options are supported at that receiver). 1173 >> Non-"must-support" options MAY be ignored by receivers, if 1174 present, e.g., based on API settings. 1176 >> All options MUST be processed by receivers in the order 1177 encountered in the options area. 1179 >> All options except UNSAFE options MUST result in the UDP user 1180 data being passed to the application layer, regardless of whether 1181 all options are processed, supported, or succeed. 1183 The basic premise is that, for options-aware endpoints, the sender 1184 decides what options to add and the receiver decides what options to 1185 handle. Simply adding an option does not force work upon a receiver, 1186 with the exception of the "must-support" options. 1188 Upon receipt, the receiver checks various properties of the UDP 1189 packet and its options to decide whether to accept or drop the UDP 1190 packet and whether to accept or ignore some its options as follows 1191 (in order): 1193 if the UDP checksum fails then 1194 silently drop the entire UDP packet (per RFC1122) 1195 if the UDP checksum passes then 1196 if OCS != 0 and fails or is zero when UDP CS != 0 then 1197 deliver the UDP user data but ignore other options 1198 (this is required to emulate legacy behavior) 1199 if OCS is nonzero and passes or is zero then 1200 deliver the UDP user data after parsing 1201 and processing the rest of the options, 1202 regardless of whether each is supported or succeeds 1203 (again, this is required to emulate legacy behavior) 1205 The design of the UNSAFE options as used only inside the FRAG area 1206 ensures that the resulting UDP data will be silently dropped in both 1207 legacy and options-aware receivers. Again, note that this still 1208 results in the delivery of a zero-length UDP packet. 1210 Options-aware receivers can drop UDP packets with option processing 1211 errors via either an override of the default UDP processing or at 1212 the application layer. 1214 I.e., all options are treated the same, in that the transmitter can 1215 add it as desired and the receiver has the option to require it or 1216 not. Only if it is required (e.g., by API configuration) should the 1217 receiver require it being present and correct. 1219 I.e., for all options: 1221 o if the option is not required by the receiver, then UDP packets 1222 missing the option are accepted. 1224 o if the option is required (e.g., by override of the default 1225 behavior at the receiver) and missing or incorrectly formed, 1226 silently drop the UDP packet. 1228 o if the UDP packet is accepted (either because the option is not 1229 required or because it was required and correct), then pass the 1230 option with the UDP packet via the API. 1232 Any options whose length exceeds that of the UDP packet (i.e., 1233 intending to use data that would have been beyond the surplus area) 1234 should be silently ignored (again to model legacy behavior). 1236 13. UDP API Extensions 1238 UDP currently specifies an application programmer interface (API), 1239 summarized as follows (with Unix-style command as an example) 1240 [RFC768]: 1242 o Method to create new receive ports 1244 o E.g., bind(handle, recvaddr(optional), recvport) 1246 o Receive, which returns data octets, source port, and source 1247 address 1249 o E.g., recvfrom(handle, srcaddr, srcport, data) 1251 o Send, which specifies data, source and destination addresses, and 1252 source and destination ports 1254 o E.g., sendto(handle, destaddr, destport, data) 1256 This API is extended to support options as follows: 1258 o Extend the method to create receive ports to include per-packet 1259 and per-fragment receive options that are required as indicated 1260 by the application. Datagrams not containing these required 1261 options MUST be silently dropped and MAY be logged. This includes 1262 a minimum datagram length, such that the options list ends in EOL 1263 and additional space is zero-filled as needed. 1265 o WG QUESTION: DO WE ALSO WANT A MIN FRAG SIZE? OR MAX? 1267 o Extend the receive function to indicate the per-packet options 1268 and their parameters as received with the corresponding received 1269 datagram. Note that per-fragment options are handled within the 1270 processing of each fragment. 1272 o WG QUESTION: SHOULD WE ACCUMULATE THOSE OPTIONS? OR DISCARD THEM? 1274 o Extend the send function to indicate the options to be added to 1275 the corresponding sent datagram. This includes indicating which 1276 options apply to individual fragments vs. which apply to the UDP 1277 packet prior to fragmentation, if fragmentation is enabled. 1279 Examples of API instances for Linux and FreeBSD are provided in 1280 Appendix A, to encourage uniform cross-platform implementations. 1282 14. UDP Options are for Transport, Not Transit 1284 UDP options are indicated in the surplus area of the IP payload that 1285 is not used by UDP. That area is really part of the IP payload, not 1286 the UDP payload, and as such, it might be tempting to consider 1287 whether this is a generally useful approach to extending IP. 1289 Unfortunately, the surplus area exists only for transports that 1290 include their own transport layer payload length indicator. TCP and 1291 SCTP include header length fields that already provide space for 1292 transport options by indicating the total length of the header area, 1293 such that the entire remaining area indicated in the network layer 1294 (IP) is transport payload. UDP-Lite already uses the UDP Length 1295 field to indicate the boundary between data covered by the transport 1296 checksum and data not covered, and so there is no remaining area 1297 where the length of the UDP-Lite payload as a whole can be indicated 1298 [RFC3828]. 1300 UDP options are intended for use only by the transport endpoints. 1301 They are no more (or less) appropriate to be modified in-transit 1302 than any other portion of the transport datagram. 1304 UDP options are transport options. Generally, transport headers, 1305 options, and data re not intended to be modified in-transit. UDP 1306 options are no exception and here are specified as "MUST NOT" be 1307 altered in transit. However, the UDP option mechanism provides no 1308 specific protection against in-transit modification of the UDP 1309 header, UDP payload, or surplus area, except as provided by the OCS 1310 or the options selected (e.g., AUTH, or UENC). 1312 15. UDP options vs. UDP-Lite 1314 UDP-Lite provides partial checksum coverage, so that UDP packets 1315 with errors in some locations can be delivered to the user 1316 [RFC3828]. It uses a different transport protocol number (136) than 1317 UDP (17) to interpret the UDP Length field as the prefix covered by 1318 the UDP checksum. 1320 UDP (protocol 17) already defines the UDP Length field as the limit 1321 of the UDP checksum, but by default also limits the data provided to 1322 the application as that which precedes the UDP Length. A goal of 1323 UDP-Lite is to deliver data beyond UDP Length as a default, which is 1324 why a separate transport protocol number was required. 1326 UDP options do not use or need a separate transport protocol number 1327 because the data beyond the UDP Length offset (surplus data) is not 1328 provided to the application by default. That data is interpreted 1329 exclusively within the UDP transport layer. 1331 UDP-Lite cannot support UDP options, either as proposed here or in 1332 any other form, because the entire payload of the UDP packet is 1333 already defined as user data and there is no additional field in 1334 which to indicate a surplus area for options. The UDP Length field 1335 in UDP-Lite is already used to indicate the boundary between user 1336 data covered by the checksum and user data not covered. 1338 16. Interactions with Legacy Devices 1340 It has always been permissible for the UDP Length to be inconsistent 1341 with the IP transport payload length [RFC768]. Such inconsistency 1342 has been utilized in UDP-Lite using a different transport number. 1343 There are no known systems that use this inconsistency for UDP 1344 [RFC3828]. It is possible that such use might interact with UDP 1345 options, i.e., where legacy systems might generate UDP datagrams 1346 that appear to have UDP options. The OCS provides protection against 1347 such events and is stronger than a static "magic number". 1349 UDP options have been tested as interoperable with Linux, macOS, and 1350 Windows Cygwin, and worked through NAT devices. These systems 1351 successfully delivered only the user data indicated by the UDP 1352 Length field and silently discarded the surplus area. 1354 One reported embedded device passes the entire IP datagram to the 1355 UDP application layer. Although this feature could enable 1356 application-layer UDP option processing, it would require that 1357 conventional UDP user applications examine only the UDP user data. 1358 This feature is also inconsistent with the UDP application interface 1359 [RFC768] [RFC1122]. 1361 It has been reported that Alcatel-Lucent's "Brick" Intrusion 1362 Detection System has a default configuration that interprets 1363 inconsistencies between UDP Length and IP Length as an attack to be 1364 reported. Note that other firewall systems, e.g., CheckPoint, use a 1365 default "relaxed UDP length verification" to avoid falsely 1366 interpreting this inconsistency as an attack. 1368 17. Options in a Stateless, Unreliable Transport Protocol 1370 There are two ways to interpret options for a stateless, unreliable 1371 protocol -- an option is either local to the message or intended to 1372 affect a stream of messages in a soft-state manner. Either 1373 interpretation is valid for defined UDP options. 1375 It is impossible to know in advance whether an endpoint supports a 1376 UDP option. 1378 >> All UDP options other than UNSAFE ones MUST be ignored if not 1379 supported or upon failure (e.g., APC). 1381 >> All UDP options that fail MUST result in the UDP data still being 1382 sent to the application layer by default, to ensure equivalence with 1383 legacy devices. 1385 >> UDP options that rely on soft-state exchange MUST allow for 1386 message reordering and loss. 1388 The above requirements prevent using any option that cannot be 1389 safely ignored unless it is hidden inside the FRAG area (i.e., 1390 UNSAFE options). Legacy systems also always need to be able to 1391 interpret the transport fragments as individual UDP packets. 1393 18. UDP Option State Caching 1395 Some TCP connection parameters, stored in the TCP Control Block, can 1396 be usefully shared either among concurrent connections or between 1397 connections in sequence, known as TCP Sharing [RFC9040]. Although 1398 UDP is stateless, some of the options proposed herein may have 1399 similar benefit in being shared or cached. We call this UCB Sharing, 1400 or UDP Control Block Sharing, by analogy. Just as TCB sharing is not 1401 a standard because it is consistent with existing TCP 1402 specifications, UCB sharing would be consistent with existing UDP 1403 specifications, including this one. Both are implementation issues 1404 that are outside the scope of their respective specifications, and 1405 so UCB sharing is outside the scope of this document. 1407 19. Updates to RFC 768 1409 This document updates RFC 768 as follows: 1411 o This document defines the meaning of the IP payload area beyond 1412 the UDP length but within the IP length as the surplus area used 1413 herein for UDP options. 1415 o This document extends the UDP API to support the use of UDP 1416 options. 1418 20. Interactions with other RFCs (and drafts) 1420 This document clarifies the interaction between UDP Length and IP 1421 length that is not explicitly constrained in either UDP or the host 1422 requirements [RFC768] [RFC1122]. 1424 Teredo extensions (TE) define use of a similar difference between 1425 these lengths for trailers [RFC6081]. TE defines the UDP length 1426 pointing beyond (larger) than the location indicated by the IP 1427 length rather than shorter (as used herein): 1429 "..the IPv6 packet length (i.e., the Payload Length value in 1430 the IPv6 header plus the IPv6 header size) is less than or 1431 equal to the UDP payload length (i.e., the Length value in 1432 the UDP header minus the UDP header size)" 1434 As a result, UDP options are not compatible with TE, but that is 1435 also why this document does not update TE. Additionally, it is not 1436 at all clear how TE operates, as it requires network processing of 1437 the UDP length field to understand the total message including TE 1438 trailers. 1440 TE updates Teredo NAT traversal [RFC4380]. The NAT traversal 1441 document defined "consistency" of UDP length and IP length as: 1443 "An IPv6 packet is deemed valid if it conforms to [RFC2460]: 1444 the protocol identifier should indicate an IPv6 packet and 1445 the payload length should be consistent with the length of 1446 the UDP datagram in which the packet is encapsulated." 1448 IPv6 is clear on the meaning of this consistency, in which the 1449 pseudoheader used for UDP checksums is based on the UDP length, not 1450 inferred from the IP length, using the same text in the current 1451 specification [RFC8200]: 1453 "The Upper-Layer Packet Length in the pseudo-header is the 1454 length of the upper-layer header and data (e.g., TCP header 1455 plus TCP data). Some upper-layer protocols carry their own 1456 length information (e.g., the Length field in the UDP header); 1457 for such protocols, that is the length used in the pseudo- 1458 header." 1460 This document is consistent the UDP profile for Robust Header 1461 Compression (ROHC)[RFC3095], noted here: 1463 "The Length field of the UDP header MUST match the Length 1464 field(s) of the preceding subheaders, i.e., there must not 1465 be any padding after the UDP payload that is covered by the 1466 IP Length." 1468 ROHC compresses UDP headers only when this match succeeds. It does 1469 not prohibit UDP headers where the match fails; in those cases, ROHC 1470 default rules (Section 5.10) would cause the UDP header to remain 1471 uncompressed. Upon receipt of a compressed UDP header, Section A.1.3 1472 of that document indicates that the UDP length is "INFERRED"; in 1473 uncompressed packets, it would simply be explicitly provided. 1475 This issue of handling UDP header compression is more explicitly 1476 described in more recent specifications, e.g., Sec. 10.10 of Static 1477 Context Header Compression [RFC8724]. 1479 21. Multicast Considerations 1481 UDP options are primarily intended for unicast use. Using these 1482 options over multicast IP requires careful consideration, e.g., to 1483 ensure that the options used are safe for different endpoints to 1484 interpret differently (e.g., either to support or silently ignore) 1485 or to ensure that all receivers of a multicast group confirm support 1486 for the options in use. 1488 22. Security Considerations 1490 There are a number of security issues raised by the introduction of 1491 options to UDP. Some are specific to this variant, but others are 1492 associated with any packet processing mechanism; all are discussed 1493 in this section further. 1495 The use of UDP packets with inconsistent IP and UDP Length fields 1496 has the potential to trigger a buffer overflow error if not properly 1497 handled, e.g., if space is allocated based on the smaller field and 1498 copying is based on the larger. However, there have been no reports 1499 of such vulnerability and it would rely on inconsistent use of the 1500 two fields for memory allocation and copying. 1502 UDP options are not covered by DTLS (datagram transport-layer 1503 security). Despite the name, neither TLS [RFC8446] (transport layer 1504 security, for TCP) nor DTLS [RFC6347] (TLS for UDP) protect the 1505 transport layer. Both operate as a shim layer solely on the user 1506 data of transport packets, protecting only their contents. Just as 1507 TLS does not protect the TCP header or its options, DTLS does not 1508 protect the UDP header or the new options introduced by this 1509 document. Transport security is provided in TCP by the TCP 1510 Authentication Option (TCP-AO [RFC5925]) or in UDP by the 1511 Authentication (AUTH) option (Section 9.9) and UNSAFE Encryption 1512 (UENC) option (Section 10). Transport headers are also protected as 1513 payload when using IP security (IPsec) [RFC4301]. 1515 UDP options use the TLV syntax similar to that of TCP. This syntax 1516 is known to require serial processing and may pose a DOS risk, e.g., 1517 if an attacker adds large numbers of unknown options that must be 1518 parsed in their entirety, as is the case for IPv6 [RFC8504]. 1520 >> Implementations concerned with the potential for this 1521 vulnerability MAY implement only the required UDP options and MAY 1522 also limit processing of TLVs, either in number of non-padding 1523 options or total length, or both. The number of non-zero TLVs 1524 allowed in such cases MUST be at least 8. 1526 Because required options come first and at most once each (with the 1527 exception of NOPs, which should never need to come in sequences of 1528 more than seven in a row), this limits their DOS impact. Note that 1529 TLV formats for options does require serial processing, but any 1530 format that allows future options, whether ignored or not, could 1531 introduce a similar DOS vulnerability. 1533 UDP security should never rely solely on transport layer processing 1534 of options. UNSAFE options are the only type that share fate with 1535 the UDP data, because of the way that data is hidden in the surplus 1536 area until after those options are processed. All other options 1537 default to being silently ignored at the transport layer but may be 1538 dropped either if that default is overridden (e.g., by 1539 configuration) or discarded at the application layer (e.g., using 1540 information about the options processed that are passed along with 1541 the UDP packet). 1543 UDP fragmentation introduces its own set of security concerns, which 1544 can be handled in a manner similar to IP reassembly or TCP segment 1545 reordering [CERT18]. In particular, the number of UDP packets 1546 pending reassembly and effort used for reassembly is typically 1547 limited. In addition, it may be useful to assume a reasonable 1548 minimum fragment size, e.g., that non-terminal fragments should 1549 never be smaller than 500 bytes. 1551 23. IANA Considerations 1553 Upon publication, IANA is hereby requested to create a new registry 1554 for UDP Option Kind numbers, similar to that for TCP Option Kinds. 1555 Initial values of this registry are as listed in Section 8. 1556 Additional values in this registry are to be assigned from the 1557 UNASSIGNED values in Section 8 by IESG Approval or Standards Action 1559 [RFC8126]. Those assignments are subject to the conditions set forth 1560 in this document, particularly (but not limited to) those in Section 1561 11. 1563 Although option nicknames are not used in-band, IANA should require 1564 UNSAFE safe option values to commence with the letter "U" and avoid 1565 that letter as commencing safe options. 1567 Upon publication, IANA is hereby requested to create a new registry 1568 for UDP Experimental Option Experiment Identifiers (UDP ExIDs) for 1569 use in a similar manner as TCP ExIDs [RFC6994]. UDP ExIDs can be 1570 used in either (or both) the EXP or UEXP options. This registry is 1571 initially empty. Values in this registry are to be assigned by IANA 1572 using first-come, first-served (FCFS) rules [RFC8126]. Options using 1573 these ExIDs are subject to the same conditions as new options, i.e., 1574 they too are subject to the conditions set forth in this document, 1575 particularly (but not limited to) those in Section 11. 1577 24. References 1579 24.1. Normative References 1581 [Fa22] Fairhurst, G., T. Jones, "Datagram PLPMTUD for UDP 1582 Options," draft-ietf-tsvwg-udp-options-dplpmtud, Feb. 1583 2022. 1585 [RFC768] Postel, J., "User Datagram Protocol," RFC 768, August 1586 1980. 1588 [RFC791] Postel, J., "Internet Protocol," RFC 791, Sept. 1981. 1590 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -- 1591 Communication Layers," RFC 1122, Oct. 1989. 1593 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1594 Requirement Levels," BCP 14, RFC 2119, March 1997. 1596 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1597 2119 Key Words," RFC 2119, May 2017. 1599 24.2. Informative References 1601 [Fa18] Fairhurst, G., T. Jones, R. Zullo, "Checksum Compensation 1602 Options for UDP Options", draft-fairhurst-udp-options-cco, 1603 Oct. 2018. 1605 [Hi15] Hildebrand, J., B. Trammel, "Substrate Protocol for User 1606 Datagrams (SPUD) Prototype," draft-hildebrand-spud- 1607 prototype-03, Mar. 2015. 1609 [RFC793] Postel, J., "Transmission Control Protocol" RFC 793, 1610 September 1981. 1612 [RFC1071] Braden, R., D. Borman, C. Partridge, "Computing the 1613 Internet Checksum," RFC 1071, Sept. 1988. 1615 [RFC1191] Mogul, J., S. Deering, "Path MTU discovery," RFC 1191, 1616 November 1990. 1618 [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery," RFC 1619 2923, September 2000. 1621 [RFC3095] Bormann, C. (Ed), et al., "RObust Header Compression 1622 (ROHC): Framework and four profiles: RTP, UDP, ESP, and 1623 uncompressed," RFC 3095, July 2001. 1625 [RFC3385] Sheinwald, D., J. Satran, P. Thaler, V. Cavanna, "Internet 1626 Protocol Small Computer System Interface (iSCSI) Cyclic 1627 Redundancy Check (CRC)/Checksum Considerations," RFC 3385, 1628 Sep. 2002. 1630 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers 1631 Considered Useful," RFC 3692, Jan. 2004. 1633 [RFC3828] Larzon, L-A., M. Degermark, S. Pink, L-E. Jonsson (Ed.), 1634 G. Fairhurst (Ed.), "The Lightweight User Datagram 1635 Protocol (UDP-Lite)," RFC 3828, July 2004. 1637 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1638 Internet Protocol", RFC 4301, Dec. 2005. 1640 [RFC4340] Kohler, E., M. Handley, and S. Floyd, "Datagram Congestion 1641 Control Protocol (DCCP)", RFC 4340, March 2006. 1643 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 1644 Network Address Translations (NATs)," RFC 4380, Feb. 2006. 1646 [RFC4960] Stewart, R. (Ed.), "Stream Control Transmission Protocol", 1647 RFC 4960, September 2007. 1649 [RFC5925] Touch, J., A. Mankin, R. Bonica, "The TCP Authentication 1650 Option," RFC 5925, June 2010. 1652 [RFC6081] Thaler, D., "Teredo Extensions," RFC 6081, Jan 2011. 1654 [RFC6347] Rescorla, E., N. Modadugu, "Datagram Transport Layer 1655 Security Version 1.2," RFC 6347, Jan. 2012. 1657 [RFC6691] Borman, D., "TCP Options and Maximum Segment Size (MSS)," 1658 RFC 6691, July 2012. 1660 [RFC6935] Eubanks, M., P. Chimento, M. Westerlund, "IPv6 and UDP 1661 Checksums for Tunneled Packets," RFC 6935, April 2013. 1663 [RFC6978] Touch, J., "A TCP Authentication Option Extension for NAT 1664 Traversal", RFC 6978, July 2013. 1666 [RFC6994] Touch, J., "Shared Use of Experimental TCP Options," RFC 1667 6994, Aug. 2013. 1669 [RFC7323] Borman, D., R. Braden, V. Jacobson, R. Scheffenegger 1670 (Ed.), "TCP Extensions for High Performance," RFC 7323, 1671 Sep. 2014. 1673 [RFC8085] Eggert, L., G. Fairhurst, G. Shepherd, "UDP Usage 1674 Guidelines," RFC 8085, Feb. 2017. 1676 [RFC8126] Cotton, M., B. Leiba, T. Narten, "Guidelines for Writing 1677 an IANA Considerations Section in RFCs," RFC 8126, June 1678 2017. 1680 [RFC8200] Deering, S., R. Hinden, "Internet Protocol Version 6 1681 (IPv6) Specification," RFC 8200, Jul. 2017. 1683 [RFC8201] McCann, J., S. Deering, J. Mogul, R. Hinden (Ed.), "Path 1684 MTU Discovery for IP version 6," RFC 8201, Jul. 2017. 1686 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1687 Version 1.3," RFC 8446, Aug. 2018. 1689 [RFC8504] Chown, T., J. Loughney, T. Winters, "IPv6 Node 1690 Requirements," RFC 8504, Jan. 2019. 1692 [RFC8724] Minaburo, A., L. Toutain, C. Gomez, D. Barthel, JC., 1693 "SCHC: Generic Framework for Static Context Header 1694 Compression and Fragmentation," RFC 8724, Apr. 2020. 1696 [RFC8899] Fairhurst, G., T. Jones, M. Tuxen, I. Rungeler, T. Volker, 1697 "Packetization Layer Path MTU Discovery for Datagram 1698 Transports," RFC 8899, Sep. 2020. 1700 [RFC9040] Touch, J., M. Welzl, S. Islam, "TCP Control Block 1701 Interdependence," RFC 9040, Jul. 2021. 1703 [RFC9187] Touch, J., "Sequence Number Extension for Windowed 1704 Protocols," RFC 9187, Jan. 2022. 1706 [CERT18] CERT Coordination Center, "TCP implementations vulnerable 1707 to Denial of Service,", Vulnerability Note VU 962459, 1708 Software Engineering Institute, CMU, 2018, 1709 https://www.kb.cert.org/vuls/id/962459. 1711 [To18] Touch, J., "A TCP Authentication Option Extension for 1712 Payload Encryption," draft-touch-tcp-ao-encrypt, Jul. 1713 2018. 1715 25. Acknowledgments 1717 This work benefitted from feedback from Erik Auerswald, Bob Briscoe, 1718 Ken Calvert, Ted Faber, Gorry Fairhurst (including OCS for 1719 misbehaving middlebox traversal), C. M. Heard (including combining 1720 previous FRAG and LITE options into the new FRAG), Tom Herbert, Mark 1721 Smith, and Raffaele Zullo, as well as discussions on the IETF TSVWG 1722 and SPUD email lists. 1724 This work was partly supported by USC/ISI's Postel Center. 1726 This document was prepared using 2-Word-v2.0.template.dot. 1728 Authors' Addresses 1730 Joe Touch 1731 Manhattan Beach, CA 90266 USA 1733 Phone: +1 (310) 560-0334 1734 Email: touch@strayalpha.com 1736 Appendix A. Implementation Information 1738 The following information is provided to encourage interoperable API 1739 implementations. 1741 System-level variables (sysctl): 1743 Name default meaning 1744 ---------------------------------------------------- 1745 net.ipv4.udp_opt 0 UDP options available 1746 net.ipv4.udp_opt_ocs 1 Default use OCS 1747 net.ipv4.udp_opt_apc 0 Default include APC 1748 net.ipv4.udp_opt_frag 0 Default fragment 1749 net.ipv4.udp_opt_mds 0 Default include MDS 1750 net.ipv4.udp_opt_mrds 0 Default include MRDS 1751 net.ipv4.udp_opt_req 0 Default include REQ 1752 net.ipv4.udp_opt_resp 0 Default include RES 1753 net.ipv4.udp_opt_time 0 Default include TIME 1754 net.ipv4.udp_opt_auth 0 Default include AUTH 1755 net.ipv4.udp_opt_exp 0 Default include EXP 1756 net.ipv4.udp_opt_uenc 0 Default include UENC 1757 net.ipv4.udp_opt_uexp 0 Default include UEXP 1759 Socket options (sockopt), cached for outgoing datagrams: 1761 Name meaning 1762 ---------------------------------------------------- 1763 UDP_OPT Enable UDP options (at all) 1764 UDP_OPT_OCS Use UDP OCS 1765 UDP_OPT_APC Enable UDP APC option 1766 UDP_OPT_FRAG Enable UDP fragmentation 1767 UDP OPT MDS Enable UDP MDS option 1768 UDP OPT MRDS Enable UDP MRDS option 1769 UDP OPT REQ Enable UDP REQ option 1770 UDP OPT RES Enable UDP RES option 1771 UDP_OPT_TIME Enable UDP TIME option 1772 UDP OPT AUTH Enable UDP AUTH option 1773 UDP OPT EXP Enable UDP EXP option 1774 UDP_OPT_UENC Enable UDP UENC option 1775 UDP OPT UEXP Enable UDP UEXP option 1777 Send/sendto parameters: 1779 Connection parameters (per-socketpair cached state, part UCB): 1781 Name Initial value 1782 ---------------------------------------------------- 1783 opts_enabled net.ipv4.udp_opt 1784 ocs_enabled net.ipv4.udp_opt_ocs 1786 The following option is included for debugging purposes, and MUST 1787 NOT be enabled otherwise. 1789 System variables 1791 net.ipv4.udp_opt_junk 0 1792 System-level variables (sysctl): 1794 Name default meaning 1795 ---------------------------------------------------- 1796 net.ipv4.udp_opt_junk 0 Default use of junk 1798 Socket options (sockopt): 1800 Name params meaning 1801 ------------------------------------------------------ 1802 UDP_JUNK - Enable UDP junk option 1803 UDP_JUNK_VAL fillval Value to use as junk fill 1804 UDP_JUNK_LEN length Length of junk payload in bytes 1806 Connection parameters (per-socketpair cached state, part UCB): 1808 Name Initial value 1809 ---------------------------------------------------- 1810 junk_enabled net.ipv4.udp_opt_junk 1811 junk_value 0xABCD 1812 junk_len 4