idnits 2.17.1 draft-ietf-tsvwg-udp-options-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- == The document has an IETF Trust Provisions of 28 Dec 2009, Section 6.c(i) Publication Limitation clause. 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 1166 has weird spacing: '...default mean...' == Line 1198 has weird spacing: '...enabled net.i...' == Line 1199 has weird spacing: '...enabled net....' == Line 1209 has weird spacing: '...default mean...' == Line 1215 has weird spacing: '... params mean...' == (1 more instance...) -- The document date (July 1, 2018) is 2125 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) -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 2140 (Obsoleted by RFC 9040) -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- 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: 0 errors (**), 0 flaws (~~), 8 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TSVWG J. Touch 2 Internet Draft 3 Intended status: Standards Track July 1, 2018 4 Intended updates: 768 5 Expires: January 2019 7 Transport Options for UDP 8 draft-ietf-tsvwg-udp-options-04.txt 10 Status of this Memo 12 This Internet-Draft is submitted in full conformance with the 13 provisions of BCP 78 and BCP 79. This document may not be modified, 14 and derivative works of it may not be created, except to format it 15 for publication as an RFC or to translate it into languages other 16 than English. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other documents 25 at any time. It is inappropriate to use Internet-Drafts as 26 reference material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 This Internet-Draft will expire on January 1, 2019. 36 Copyright Notice 38 Copyright (c) 2018 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with 46 respect to this document. Code Components extracted from this 47 document must include Simplified BSD License text as described in 48 Section 4.e of the Trust Legal Provisions and are provided without 49 warranty as described in the Simplified BSD License. 51 Abstract 53 Transport protocols are extended through the use of transport header 54 options. This document experimentally extends UDP by indicating the 55 location, syntax, and semantics for UDP transport layer options. 57 Table of Contents 59 1. Introduction...................................................3 60 2. Conventions used in this document..............................3 61 3. Background.....................................................3 62 4. The UDP Option Area............................................4 63 5. UDP Options....................................................7 64 5.1. End of Options List (EOL).................................8 65 5.2. No Operation (NOP)........................................9 66 5.3. Option Checksum (OCS).....................................9 67 5.4. Alternate Checksum (ACS).................................10 68 5.5. Lite (LITE)..............................................11 69 5.6. Maximum Segment Size (MSS)...............................13 70 5.7. Fragmentation (FRAG).....................................14 71 5.7.1. Coupling FRAG with LITE.............................16 72 5.8. Timestamps (TIME)........................................17 73 5.9. Authentication and Encryption (AE).......................17 74 5.10. Experimental (EXP)......................................18 75 6. UDP API Extensions............................................19 76 7. Whose options are these?......................................19 77 8. UDP options LITE option vs. UDP-Lite..........................20 78 9. Interactions with Legacy Devices..............................21 79 10. Options in a Stateless, Unreliable Transport Protocol........21 80 11. UDP Option State Caching.....................................22 81 12. Updates to RFC 768...........................................22 82 13. Multicast Considerations.....................................22 83 14. Security Considerations......................................22 84 15. IANA Considerations..........................................23 85 16. References...................................................24 86 16.1. Normative References....................................24 87 16.2. Informative References..................................24 88 17. Acknowledgments..............................................26 89 Appendix A. Implementation Information...........................28 91 1. Introduction 93 Transport protocols use options as a way to extend their 94 capabilities. TCP [RFC793], SCTP [RFC4960], and DCCP [RFC4340] 95 include space for these options but UDP [RFC768] currently does not. 96 This document defines an experimental extension to UDP that provides 97 space for transport options including their generic syntax and 98 semantics for their use in UDP's stateless, unreliable message 99 protocol. 101 2. Conventions used in this document 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 105 document are to be interpreted as described in RFC 2119 [RFC2119]. 107 In this document, these words will appear with that interpretation 108 only when in ALL CAPS. Lowercase uses of these words are not to be 109 interpreted as carrying significance described in RFC 2119. 111 In this document, the characters ">>" preceding an indented line(s) 112 indicates a statement using the key words listed above. This 113 convention aids reviewers in quickly identifying or finding the 114 portions of this RFC covered by these key words. 116 3. Background 118 Many protocols include a default header and an area for header 119 options. These options enable the protocol to be extended for use in 120 particular environments or in ways unforeseen by the original 121 designers. Examples include TCP's Maximum Segment Size, Window 122 Scale, Timestamp, and Authentication Options 123 [RFC793][RFC5925][RFC7323]. 125 These options are used both in stateful (connection-oriented, e.g., 126 TCP [RFC793], SCTP [RFC4960], DCCP [RFC4340]) and stateless 127 (connectionless, e.g., IPv4 [RFC791], IPv6 [RFC8200] protocols. In 128 stateful protocols they can help extend the way in which state is 129 managed. In stateless protocols their effect is often limited to 130 individual packets, but they can have an aggregate effect on a 131 sequence as well. One example of such uses is Substrate Protocol for 132 User Datagrams (SPUD) [Tr16], and this document is intended to 133 provide an out-of-band option area as an alternative to the in-band 134 mechanism currently proposed [Hi15]. 136 UDP is one of the most popular protocols that lacks space for 137 options [RFC768]. The UDP header was intended to be a minimal 138 addition to IP, providing only ports and a data checksum for 139 protection. This document experimentally extends UDP to provide a 140 trailer area for options located after the UDP data payload. 142 4. The UDP Option Area 144 The UDP transport header includes demultiplexing and service 145 identification (port numbers), a checksum, and a field that 146 indicates the UDP datagram length (including UDP header). The UDP 147 Length length field is typically redundant with the size of the 148 maximum space available as a transport protocol payload (see also 149 discussion in Section 9). 151 For IPv4, IP Total Length field indicates the total IP datagram 152 length (including IP header), and the size of the IP options is 153 indicated in the IP header (in 4-byte words) as the "Internet Header 154 Length" (IHL), as shown in Figure 1 [RFC791]. As a result, the 155 typical (and largest valid) value for UDP Length is: 157 UDP_Length = IPv4_Total_Length - IPv4_IHL * 4 159 For IPv6, the IP Payload Length field indicates the datagram after 160 the base IPv6 header, which includes the IPv6 extension headers and 161 space available for the transport protocol, as shown in Figure 2 162 [RFC8200]. Note that the Next HDR field in IPv6 might not indicate 163 UDP (i.e., 17), e.g., when intervening IP extension headers are 164 present. For IPv6, the lengths of any additional IP extensions are 165 indicated within each extension [RFC8200], so the typical (and 166 largest valid) value for UDP Length is: 168 UDP_Length = IPv6_Payload_Length - sum(extension header lengths) 170 In both cases, the space available for the UDP transport protocol 171 data unit is indicated by IP, either completely in the base header 172 (for IPv4) or adding information in the extensions (for IPv6). In 173 either case, this document will refer to this available space as the 174 "IP transport payload". 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 |Version| IHL |Type of Service| Total Length | 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 | Identification |Flags| Fragment Offset | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 | Time to Live | Proto=17 (UDP)| Header Checksum | 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 | Source Address | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | Destination Address | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 ... zero or more IP Options (using space as indicated by IHL) ... 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | UDP Source Port | UDP Destination Port | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | UDP Length | UDP Checksum | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 Figure 1 IPv4 datagram with UDP transport payload 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 |Version| Traffic Class | Flow Label | 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 | Payload Length | Next Hdr | Hop Limit | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 ... 202 | Source Address (128 bits) | 203 ... 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 ... 206 | Destination Address (128 bits) | 207 ... 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 ... zero or more IP Extension headers (each indicating size) ... 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | UDP Source Port | UDP Destination Port | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | UDP Length | UDP Checksum | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 Figure 2 IPv6 datagram with UDP transport payload 218 As a result of this redundancy, there is an opportunity to use the 219 UDP Length field as a way to break up the IP transport payload into 220 two areas - that intended as UDP user data and an additional 221 "surplus area" (as shown in Figure 3). 223 IP transport payload 224 <-------------------------------------------------> 225 +--------+---------+----------------------+------------------+ 226 | IP Hdr | UDP Hdr | UDP user data | surplus area | 227 +--------+---------+----------------------+------------------+ 228 <------------------------------> 229 UDP Length 231 Figure 3 IP transport payload vs. UDP Length 233 In most cases, the IP transport payload and UDP Length point to the 234 same location, indicating that there is no surplus area. It is 235 important to note that this is not a requirement of UDP [RFC768] 236 (discussed further in Section 9). UDP-Lite used the difference in 237 these pointers to indicate the partial coverage of the UDP Checksum, 238 such that the UDP user data, UDP header, and UDP pseudoheader (a 239 subset of the IP header) are covered by the UDP checksum but 240 additional user data in the surplus area is not covered [RFC3828]. 241 This document uses the surplus area for UDP transport options. 243 The UDP option area is thus defined as the location between the end 244 of the UDP payload and the end of the IP datagram as a trailing 245 options area. This area can occur at any valid byte offset, i.e., it 246 need not be 16-bit or 32-bit aligned. In effect, this document 247 redefines the UDP "Length" field as a "trailer offset". 249 UDP options are defined using a TLV (type, length, and optional 250 value) syntax similar to that of TCP [RFC793]. They are typically a 251 minimum of two bytes in length as shown in Figure 4, excepting only 252 the one byte options "No Operation" (NOP) and "End of Options List" 253 (EOL) described below. 255 +--------+--------+ 256 | Kind | Length | 257 +--------+--------+ 259 Figure 4 UDP option default format 261 >> UDP options MAY occur at any UDP length offset. 263 >> The UDP length MUST be at least as large as the UDP header (8) 264 and no larger than the IP transport payload. Values outside this 265 range MUST be silently discarded as invalid and logged where rate- 266 limiting permits. 268 Others have considered using values of the UDP Length that is larger 269 than the IP transport payload as an additional type of signal. Using 270 a value smaller than the IP transport payload is expected to be 271 backward compatible with existing UDP implementations, i.e., to 272 deliver the UDP Length of user data to the application and silently 273 ignore the additional surplus area data. Using a value larger than 274 the IP transport payload would either be considered malformed (and 275 be silently dropped) or could cause buffer overruns, and so is not 276 considered silently and safely backward compatible. Its use is thus 277 out of scope for the extension described in this document. 279 >> UDP options MUST be interpreted in the order in which they occur 280 in the UDP option area. 282 5. UDP Options 284 The following UDP options are currently defined: 286 Kind Length Meaning 287 ---------------------------------------------- 288 0* - End of Options List (EOL) 289 1* - No operation (NOP) 290 2* 2 Option checksum (OCS) 291 3* 4 Alternate checksum (ACS) 292 4* 4 Lite (LITE) 293 5* 4 Maximum segment size (MSS) 294 6* 8/10 Fragmentation (FRAG) 295 7 10 Timestamps (TIME) 296 8 (varies) Authentication and Encryption (AE) 297 9-126 (varies) UNASSIGNED (assignable by IANA) 298 127-253 RESERVED 299 254 N(>=4) RFC 3692-style experiments (EXP) 300 255 RESERVED 302 These options are defined in the following subsections. 304 >> An endpoint supporting UDP options MUST support those marked with 305 a "*" above: EOL, NOP, OCS, ACS, LITE, FRAG, and MSS. This includes 306 both recognizing and being able to generate these options if 307 configured to do so. 309 >> All other options (without a "*") MAY be implemented, and their 310 use SHOULD be determined either out-of-band or negotiated. 312 >> Receivers MUST silently ignore unknown options. That includes 313 options whose length does not indicate the specified value. 315 >> Except for NOP, each option SHOULD NOT occur more than once in a 316 single UDP datagram. If a non-NOP option occurs more than once, a 317 receiver MUST interpret only the first instance of that option and 318 MUST ignore all others. 320 >> Only the OCS and AE options depend on the contents of the option 321 area. AE is always computed as if the AE hash and OCS checksum are 322 zero; OCS is always computed as if the OCS checksum is zero and 323 after the AE hash has been computed. Future options MUST NOT be 324 defined as having a value dependent on the contents of the option 325 area. Otherwise, interactions between those values, OCS, and AE 326 could be unpredictable. 328 Receivers cannot treat unexpected option lengths as invalid, as this 329 would unnecessarily limit future revision of options (e.g., defining 330 a new ACS that is defined by having a different length). 332 >> Option lengths MUST NOT exceed the IP length of the packet. If 333 this occurs, the packet MUST be treated as malformed and dropped, 334 and the event MAY be logged for diagnostics (logging SHOULD be rate 335 limited). 337 >> Required options MUST come before other options. Each required 338 option MUST NOT occur more than once (if they are repeated in a 339 received segment, all except the first MUST be silently ignored). 341 The requirement that required options come before others is intended 342 to allow for endpoints to implement DOS protection, as discussed 343 further in Section 14. 345 5.1. End of Options List (EOL) 347 The End of Options List (EOL) option indicates that there are no 348 more options. It is used to indicate the end of the list of options 349 without needing to pad the options to fill all available option 350 space. 352 +--------+ 353 | Kind=0 | 354 +--------+ 356 Figure 5 UDP EOL option format 358 >> When the UDP options do not consume the entire option area, the 359 last non-NOP option SHOULD be EOL (vs. filling the entire option 360 area with NOP values). 362 >> All bytes after EOL MUST be ignored by UDP option processing. As 363 a result, there can only ever be one EOL option (even if other bytes 364 were zero, they are ignored). 366 5.2. No Operation (NOP) 368 The No Operation (NOP) option is a one byte placeholder, intended to 369 be used as padding, e.g., to align multi-byte options along 16-bit 370 or 32-bit boundaries. 372 +--------+ 373 | Kind=1 | 374 +--------+ 376 Figure 6 UDP NOP option format 378 >> If options longer than one byte are used, NOP options SHOULD be 379 used at the beginning of the UDP options area to achieve alignment 380 as would be more efficient for active (i.e., non-NOP) options. 382 >> Segments SHOULD NOT use more than three consecutive NOPs. NOPs 383 are intended to assist with alignment, not other padding or fill. 385 [NOTE: Tom Herbert suggested we declare "more than 3 consecutive 386 NOPs" a fatal error to reduce the potential of using NOPs as a DOS 387 attack, but IMO there are other equivalent ways (e.g., using 388 RESERVED or other UNASSIGNED values) and the "no more than 3" 389 creates its own DOS vulnerability) 391 5.3. Option Checksum (OCS) 393 The Option Checksum (OCS) is an 8-bit ones-complement sum (Ones8) 394 that covers all of the UDP options. OCS is 8-bits to allow the 395 entire option to occupy a total of 16 bits. 397 OCS can be calculated by computing the 16-bit ones-complement sum 398 and "folding over" the result (using carry wraparound). Note that 399 OCS is direct, i.e., it is not negated or adjusted if zero (unlike 400 the Internet checksum as used in IPv4, TCP, and UDP headers). OCS 401 protects the option area from errors in a similar way that the UDP 402 checksum protects the UDP user data. 404 +--------+--------+ 405 | Kind=2 | Ones8 | 406 +--------+--------+ 408 Figure 7 UDP OCS option format 410 >> When present, the option checksum SHOULD occur as early as 411 possible, preferably preceded by only NOP options for alignment and 412 the LITE option if present. 414 OCS covers the entire UDP option area, including the Lite option as 415 formatted before swapping for transmission (or, equivalently, after 416 the swap after reception). 418 >> If the option checksum fails, all options MUST be ignored and any 419 trailing surplus data (and Lite data, if used) silently discarded. 421 >> UDP data that is validated by a correct UDP checksum MUST be 422 delivered to the application layer, even if the UDP option checksum 423 fails, unless the endpoints have negotiated otherwise for this 424 segment's socket pair. 426 5.4. Alternate Checksum (ACS) 428 The Alternate Checksum (ACS) provides a stronger alternative to the 429 UDP header checksum, using a 16-bit CRC of the conventional UDP 430 payload only (excluding the IP pseudoheader, UDP header, and UDP 431 options, and not include the LITE area). It does not include the IP 432 pseudoheader or UDP header, and so need not be updated by NATs when 433 IP addresses or UDP ports are rewritten. Its purpose is to detect 434 errors that the UDP checksum might not detect. CRC-CCITT (polynomial 435 x^16 + x^12 + x^5 + x) has been chosen because of its ubiquity and 436 use in other packet protocols, such as X.25, HDLC, and Bluetooth. 437 The option contains the remainder of the calculation of the 438 polynomial over the UDP payload data (i.e., not inverted). 440 +--------+--------+--------+--------+ 441 | Kind=3 | Len=4 | CRC16sum | 442 +--------+--------+--------+--------+ 444 Figure 8 UDP ACS option format 446 When present, the ACS always contains a valid CRC checksum. There 447 are no reserved values, including the value of zero. If the CRC is 448 zero, this must indicate a valid checksum (i.e., it does not 449 indicate that the ACS is not used; instead, the option would simply 450 not be included if that were the desired effect). 452 ACS does not protect the UDP pseudoheader; only the current UDP 453 checksum provides that protection. ACS cannot provide that 454 protection because it would need to be updated whenever the UDP 455 pseudoheader changed, e.g., during NAT address and port translation; 456 because this is not the case, ACS does not cover the pseudoheader. 458 5.5. Lite (LITE) 460 The Lite option (LITE) is intended to provide equivalent capability 461 to the UDP Lite transport protocol [RFC3828]. UDP Lite allows the 462 UDP checksum to cover only a prefix of the UDP data payload, to 463 protect critical information (e.g., application headers) but allow 464 potentially erroneous data to be passed to the user. This feature 465 helps protect application headers but allows for application data 466 errors. Some applications are impacted more by a lack of data than 467 errors in data, e.g., voice and video. 469 >> When LITE is active, it MUST come first in the UDP options list. 471 LITE is intended to support the same API as for UDP Lite to allow 472 applications to send and receive data that has a marker indicating 473 the portion protected by the UDP checksum and the portion not 474 protected by the UDP checksum. 476 LITE includes a 2-byte offset that indicates the length of the 477 portion of the UDP data that is not covered by the UDP checksum. 479 +--------+--------+--------+--------+ 480 | Kind=4 | Len=4 | Offset | 481 +--------+--------+--------+--------+ 483 Figure 9 UDP LITE option format 485 At the sender, the option is formed using the following steps: 487 1. Create a LITE option, ordered as the first UDP option (Figure 488 10). 490 2. Calculate the location of the start of the options as an absolute 491 offset from the start of the UDP header and place that length in 492 the last two bytes of the LITE option. 494 3. If the LITE data area is 4 bytes or longer, swap all four bytes 495 of the LITE option with the first 4 bytes of the LITE data area 496 (Figure 11). If the LITE data area is 0-3 bytes long, slide the 497 LITE option to the front of the LITE data area (i.e., placing the 498 0-3 bytes of LITE data after the LITE option). 500 +---------+--------------+--------------+------------------+ 501 | UDP Hdr | user data | LITE data |LITE| other opts | 502 +---------+--------------+--------------+------------------+ 503 <----------------------> 504 UDP Length 506 Figure 10 LITE option formation - LITE goes first 508 +---------+--------------+--------------+------------------+ 509 | UDP Hdr | user data | LITE data |LITE| other opts | 510 +---------+--------------+--------------+------------------+ 511 ^^^^ ^^^^ 512 | | 513 +--------------+ 515 Figure 11 Before sending swap LITE option and front of LITE data 517 The resulting packet has the format shown in Figure 12. Note that 518 the UDP length now points to the LITE option, and the LITE option 519 points to the start of the option area. 521 +---------+--------------+----------------+------------------+ 522 | UDP Hdr | user data |LITE| LITE data |Ldat| other opts | 523 +---------+--------------+----------------+------------------+ 524 <----------------------> | ^ 525 UDP Length +-------------+ 527 Figure 12 Lite option as sent 529 A legacy endpoint receiving this packet will discard the LITE option 530 and everything that follows, including the lite data and remainder 531 of the UDP options. The UDP checksum will protect only the user 532 data, not the LITE option or lite data. 534 Receiving endpoints capable of processing UDP options will do the 535 following: 537 1. Process options as usual. This will start at the LITE option. 539 2. When the LITE option is encountered, record its location as the 540 start of the LITE data area and (if the LITE offset indicates a 541 LITE data length of at least 4 bytes) swap the four bytes there 542 with the four bytes at the location indicated inside the LITE 543 option, which indicates the start of all of the options, 544 including the LITE one (one past the end of the lite data area). 545 If the LITE offset indicates a LITE data area of 0-3 bytes, then 546 slide the LITE option forward that amount and slide the 547 corresponding bytes after the LITE option to where the LITE 548 option originally began. In either case, this restores the format 549 of the option as it was prior to being sent, as per Figure 10. 551 3. Continue processing the remainder of the options, which are now 552 in the format shown in Figure 11. 554 The purpose of this swap (or slide) is to support the equivalent of 555 UDP Lite operation together with other UDP options without requiring 556 the entire LITE data area to be moved after the UDP option area. 558 5.6. Maximum Segment Size (MSS) 560 The Maximum Segment Size (MSS, Kind = 3) is a 16-bit indicator of 561 the largest UDP segment that can be received. As with the TCP MSS 562 option [RFC793], the size indicated is the IP layer MTU decreased by 563 the fixed IP and UDP headers only [RFC6691]. The space needed for IP 564 and UDP options need to be adjusted by the sender when using the 565 value indicated. The value transmitted is based on EMTU_R, the 566 largest IP datagram that can be received (i.e., reassembled at the 567 receiver) [RFC1122]. 569 +--------+--------+--------+--------+ 570 | Kind=5 | Len=4 | MSS size | 571 +--------+--------+--------+--------+ 573 Figure 13 UDP MSS option format 575 The UDP MSS option MAY be used for path MTU discovery 576 [RFC1191][RFC8201], but this may be difficult because of known 577 issues with ICMP blocking [RFC2923] as well as UDP lacking automatic 578 retransmission. It is more likely to be useful when coupled with IP 579 source fragmentation to limit the largest reassembled UDP message, 580 e.g., when EMTU_R is larger than the required minimums (576 for IPv4 581 [RFC791] and 1500 for IPv6 [RFC8200]). 583 5.7. Fragmentation (FRAG) 585 The Fragmentation option (FRAG) supports UDP fragmentation and 586 reassembly, which can be used to transfer UDP messages larger than 587 limited by the IP receive MTU (EMTU_R [RFC1122]). It is typically 588 used with the UDP MSS option to enable more efficient use of large 589 messages, both at the UDP and IP layers. FRAG is designed similar to 590 the IPv6 Fragmentation Header [RFC8200], except that the UDP variant 591 uses a 16-bit Offset measured in bytes, rather than IPv6's 13-bit 592 Fragment Offset measured in 8-byte units. This UDP variant avoids 593 creating reserved fields. 595 +--------+--------+--------+--------+ 596 | Kind=6 | Len=8 | Frag. Offset | 597 +--------+--------+--------+--------+ 598 | Identification | 599 +--------+--------+--------+--------+ 601 Figure 14 UDP non-terminal FRAG option format 603 The FRAG option also lacks a "more" bit, zeroed for the terminal 604 fragment of a set. This is possible because the terminal FRAG option 605 is indicated as a longer, 10-byte variant, which includes an 606 Internet checksum over the entire reassembled UDP payload (omitting 607 the IP pseudoheader and UDP header, as well as UDP options), as 608 shown in Figure 15. 610 >> The reassembly checksum SHOULD be used, but MAY be unused in the 611 same situations when the UDP checksum is unused (e.g., for transit 612 tunnels or applications that have their own integrity checks 613 [RFC8200]), and by the same mechanism (set the field to 0x0000). 615 +--------+--------+--------+--------+ 616 | Kind=6 | Len=10 | Frag. Offset | 617 +--------+--------+--------+--------+ 618 | Identification | 619 +--------+--------+--------+--------+ 620 | Checksum | 621 +--------+--------+ 623 Figure 15 UDP terminal FRAG option format 625 >> During fragmentation, the UDP header checksum of each fragment 626 needs to be recomputed based on each datagram's pseudoheader. 628 >> After reassembly is complete and validated using the checksum of 629 the terminal FRAG option, the UDP header checksum of the resulting 630 datagram needs to be recomputed based on the datagram's 631 pseudoheader. 633 The Fragment Offset is 16 bits and indicates the location of the UDP 634 payload fragment in bytes from the beginning of the original 635 unfragmented payload. The Len field indicates whether there are more 636 fragments (Len=8) or no more fragments (Len=12). 638 >> The Identification field is a 32-bit value that MUST be unique 639 over the expected fragment reassembly timeout. 641 >> The Identification field SHOULD be generated in a manner similar 642 to that of the IPv6 Fragment ID [RFC8200]. 644 >> UDP fragments MUST NOT overlap. 646 FRAG needs to be used with extreme care because it will present 647 incorrect datagram boundaries to a legacy receiver, unless encoded 648 as LITE data (see Section 5.7.1). 650 >> A host SHOULD indicate FRAG support by transmitting an 651 unfragmented datagram using the Fragmentation option (e.g., with 652 Offset zero and length 12, i.e., including the checksum area), 653 except when encoded as LITE. 655 >> A host MUST NOT transmit a UDP fragment before receiving recent 656 confirmation from the remote host, except when FRAG is encoded as 657 LITE. 659 UDP fragmentation relies on a fragment expiration timer, which can 660 be preset or could use a value computed using the UDP Timestamp 661 option. 663 >> The default UDP reassembly SHOULD be no more than 2 minutes. 665 Implementers are advised to limit the space available for UDP 666 reassembly. 668 >> UDP reassembly space SHOULD be limited to reduce the impact of 669 DOS attacks on resource use. 671 >> UDP reassembly space limits SHOULD NOT be implemented as an 672 aggregate, to avoid cross-socketpair DOS attacks. 674 >> Individual UDP fragments MUST NOT be forwarded to the user. The 675 reassembled datagram is received only after complete reassembly, 676 checksum validation, and continued processing of the remaining 677 options. 679 Any additional UDP options would follow the FRAG option in the final 680 fragment, and would be included in the reassembled packet. 681 Processing of those options would commence after reassembly. 683 >> UDP options MUST NOT follow the FRAG header in non-terminal 684 fragments. Any data following the FRAG header in non-terminal 685 fragments MUST be silently dropped. All other options that apply to 686 a reassembled packet MUST follow the FRAG header in the terminal 687 fragment. 689 5.7.1. Coupling FRAG with LITE 691 FRAG can be coupled with LITE to avoid impacting legacy receivers. 692 Each fragment is sent as LITE un-checksummed data, where each UDP 693 packet contains no legacy-compatible data. Legacy receivers 694 interpret these as zero-payload packets, which would not affect the 695 receiver unless the presence of the packet itself were a signal. The 696 header of such a packet would appear as shown in Figure 16 and 697 Figure 17. 699 +---------+--------------+---------+ 700 | UDP Hdr | LiteFrag |LITE|FRAG| 701 +---------+--------------+----+----+ 702 <-------> ^^^^ ^^^^ 703 Zero UDP Length | | 704 +--------------+ 706 Figure 16 Preparing FRAG as Lite data 708 +---------+--------------+----+ 709 | UDP Hdr |LITE|LiteFrag |FRAG| 710 +---------+--------------+----+ 711 <-------> | ^ 712 Zero UDP Length | | 713 +-------------+ 715 Figure 17 Lite option before transmission 717 When a packet is reassembled, it appears as a complete LITE data 718 region. The UDP header of the reassembled packet is adjusted 719 accordingly, so that the reassembled region now appears as 720 conventional UDP user data, and processing of the UDP options 721 continues, as with the non-LITE FRAG variant. 723 5.8. Timestamps (TIME) 725 The UDP Timestamp option (TIME) exchanges two four-byte timestamp 726 fields. It serves a similar purpose to TCP's TS option [RFC7323], 727 enabling UDP to estimate the round trip time (RTT) between hosts. 728 For UDP, this RTT can be useful for establishing UDP fragment 729 reassembly timeouts or transport-layer rate-limiting [RFC8085]. 731 +--------+--------+------------------+------------------+ 732 | Kind=7 | Len=10 | TS Value | TS Echo Reply | 733 +--------+--------+------------------+------------------+ 734 1 byte 1 byte 4 bytes 4 bytes 736 Figure 18 UDP TIME option format 738 TS Value (TSval) and TS Echo (TSecr) are used in a similar manner to 739 the TCP TS option [RFC7323]. A host using the Timestamp option sets 740 TS Value on all UDP segments issued. Received TSval values are 741 provided to the application, which passes this value as TSecr on UDP 742 messages sent in response to such a message. 744 >> UDP MAY use an RTT estimate based on nonzero Timestamp values as 745 a hint for fragmentation reassembly, rate limiting, or other 746 mechanisms that benefit from such an estimate. 748 >> UDP SHOULD make this RTT estimate available to the user 749 application. 751 5.9. Authentication and Encryption (AE) 753 The Authentication and Encryption option (AE) is intended to allow 754 UDP to provide a similar type of authentication as the TCP 755 Authentication Option (TCP-AO) [RFC5925]. It uses the same format as 756 specified for TCP-AO, except that it uses a Kind of 8. UDP-AO 757 supports NAT traversal in a similar manner as TCP-AO [RFC6978]. UDP- 758 AO can also be extended to provide a similar encryption capability 759 as TCP-AO-ENC, in a similar manner [To18ao]. For these reasons, the 760 option is known as UDP-AE. 762 +--------+--------+--------+--------+ 763 | Kind=8 | Len | Digest... | 764 +--------+--------+--------+--------+ 765 | Digest (con't)... | 766 +--------+--------+--------+--------+ 768 Figure 19 UDP non-terminal FRAG option format 770 Like TCP-AO, UDP-AE is not negotiated in-band. Its use assumes both 771 endpoints have populated Master Key Tuples (MKTs), used to exclude 772 non-protected traffic. 774 TCP-AO generates unique traffic keys from a hash of TCP connection 775 parameters. UDP lacks a three-way handshake to coordinate 776 connection-specific values, such as TCP's Initial Sequence Numbers 777 (ISNs) [RFC793], thus UDP-AE's Key Derivation Function (KDF) uses 778 zeroes as the value for both ISNs. This means that the UDP-AE reuses 779 keys when socket pairs are reused, unlike TCP-AO. 781 UDP-AE can be configured to either include or exclude UDP options, 782 the same way as can TCP-AO. When UDP options are covered, the OCS 783 option area checksum and UDP-AE hash areas are zeroed before 784 computing the UDP-AE hash. It is important to consider that options 785 not yet defined might yield unpredictable results if not confirmed 786 as supported, e.g., if they were to contain other hashes or 787 checksums that depend on the option area contents. This is why such 788 dependencies are not permitted except as defined for OCS and UDP-AE. 790 Similar to TCP-AO-NAT, UDP-AE can be configured to support NAT 791 traversal, excluding one or both of the UDP ports [RFC6978]. 793 5.10. Experimental (EXP) 795 The Experimental option (EXP) is reserved for experiments [RFC3692]. 796 It uses a Kind value of 254. Only one such value is reserved because 797 experiments are expected to use an Experimental ID (ExIDs) to 798 differentiate concurrent use for different purposes, using UDP ExIDs 799 registered with IANA according to the approach developed for TCP 800 experimental options [RFC6994]. 802 +----------+----------+----------+----------+ 803 | Kind=254 | Len | UDP ExID | 804 +----------+----------+----------+----------+ 805 | (option contents, as defined)... | 806 +----------+----------+----------+----------+ 808 Figure 20 UDP EXP option format 810 >> The length of the experimental option MUST be at least 4 to 811 account for the Kind, Length, and the minimum 16-bit UDP ExID 812 identifier (similar to TCP ExIDs [RFC6994]). 814 6. UDP API Extensions 816 UDP currently specifies an application programmer interface (API), 817 summarized as follows (with Unix-style command as an example) 818 [RFC768]: 820 o Method to create new receive ports 822 o E.g., bind(handle, recvaddr(optional), recvport) 824 o Receive, which returns data octets, source port, and source 825 address 827 o E.g., recvfrom(handle, srcaddr, srcport, data) 829 o Send, which specifies data, source and destination addresses, and 830 source and destination ports 832 o E.g., sendto(handle, destaddr, destport, data) 834 This API is extended to support options as follows: 836 o Extend the method to create receive ports to include receive 837 options that are required. Datagrams not containing these 838 required options MUST be silently dropped and MAY be logged. 840 o Extend the receive function to indicate the options and their 841 parameters as received with the corresponding received datagram. 843 o Extend the send function to indicate the options to be added to 844 the corresponding sent datagram. 846 Examples of API instances for Linux and FreeBSD are provided in 847 Appendix A, to encourage uniform cross-platform implementations. 849 7. Whose options are these? 851 UDP options are indicated in an area of the IP payload that is not 852 used by UDP. That area is really part of the IP payload, not the UDP 853 payload, and as such, it might be tempting to consider whether this 854 is a generally useful approach to extending IP. 856 Unfortunately, the surplus area exists only for transports that 857 include their own transport layer payload length indicator. TCP and 858 SCTP include header length fields that already provide space for 859 transport options by indicating the total length of the header area, 860 such that the entire remaining area indicated in the network layer 861 (IP) is transport payload. UDP-Lite already uses the UDP Length 862 field to indicate the boundary between data covered by the transport 863 checksum and data not covered, and so there is no remaining area 864 where the length of the UDP-Lite payload as a whole can be indicated 865 [RFC3828]. 867 UDP options are intended for use only by the transport endpoints. 868 They are no more (or less) appropriate to be modified in-transit 869 than any other portion of the transport datagram. 871 UDP options are transport options. Generally, transport datagrams 872 are not intended to be modified in-transit. However, the UDP option 873 mechanism provides no specific protection against in-transit 874 modification of the UDP header, UDP payload, or UDP option area, 875 except as provided by the options selected (e.g., OCS, ACS, or AE). 877 8. UDP options LITE option vs. UDP-Lite 879 UDP-Lite provides partial checksum coverage, so that packets with 880 errors in some locations can be delivered to the user [RFC3828]. It 881 uses a different transport protocol number (136) than UDP (17) to 882 interpret the UDP Length field as the prefix covered by the UDP 883 checksum. 885 UDP (protocol 17) already defines the UDP Length field as the limit 886 of the UDP checksum, but by default also limits the data provided to 887 the application as that which precedes the UDP Length. A goal of 888 UDP-Lite is to deliver data beyond UDP Length as a default, which is 889 why a separate transport protocol number was required. 891 UDP options do not use or need a separate transport protocol number 892 because the data beyond the UDP Length offset (surplus data) is not 893 provided to the application by default. That data is interpreted 894 exclusively within the UDP transport layer. 896 The LITE UDP options option supports a similar service to UDP-Lite. 897 The main difference is that UDP-Lite provides the un-checksummed 898 user data to the application by default, whereas the LITE UDP option 899 can safely provide that service only between endpoints that 900 negotiate that capability in advance. An endpoint that does not 901 implement UDP options would silently discard this non-checksummed 902 user data, along with the UDP options as well. 904 UDP-Lite cannot support UDP options, either as proposed here or in 905 any other form, because the entire payload of the UDP packet is 906 already defined as user data and there is no additional field in 907 which to indicate a separate area for options. The UDP Length field 908 in UDP-Lite is already used to indicate the boundary between user 909 data covered by the checksum and user data not covered. 911 9. Interactions with Legacy Devices 913 It has always been permissible for the UDP Length to be inconsistent 914 with the IP transport payload length [RFC768]. Such inconsistency 915 has been utilized in UDP-Lite using a different transport number. 916 There are no known systems that use this inconsistency for UDP 917 [RFC3828]. It is possible that such use might interact with UDP 918 options, i.e., where legacy systems might generate UDP datagrams 919 that appear to have UDP options. The UDP OCS provides protection 920 against such events and is stronger than a static "magic number". 922 UDP options have been tested as interoperable with Linux, macOS, and 923 Windows Cygwin, and worked through NAT devices. These systems 924 successfully delivered only the user data indicated by the UDP 925 Length field and silently discarded the surplus area. 927 One reported embedded device passes the entire IP datagram to the 928 UDP application layer. Although this feature could enable 929 application-layer UDP option processing, it would require that 930 conventional UDP user applications examine only the UDP payload. 931 This feature is also inconsistent with the UDP application interface 932 [RFC768] [RFC1122]. 934 It has been reported that Alcatel-Lucent's "Brick" Intrusion 935 Detection System has a default configuration that interprets 936 inconsistencies between UDP Length and IP Length as an attack to be 937 reported. Note that other firewall systems, e.g., CheckPoint, use a 938 default "relaxed UDP length verification" to avoid falsely 939 interpreting this inconsistency as an attack. 941 (TBD: test with UDP checksum offload and UDP fragmentation offload) 943 10. Options in a Stateless, Unreliable Transport Protocol 945 There are two ways to interpret options for a stateless, unreliable 946 protocol -- an option is either local to the message or intended to 947 affect a stream of messages in a soft-state manner. Either 948 interpretation is valid for defined UDP options. 950 It is impossible to know in advance whether an endpoint supports a 951 UDP option. 953 >> UDP options MUST allow for silent failure on first receipt. 955 >> UDP options that rely on soft-state exchange MUST allow for 956 message reordering and loss. 958 >> A UDP option MUST be silently optional until confirmed by 959 exchange with an endpoint. 961 The above requirements prevent using any option that cannot be 962 safely ignored unless that capability has been negotiated with an 963 endpoint in advance for a socket pair. Legacy systems would need to 964 be able to interpret the transport payload fragments as individual 965 transport datagrams. 967 11. UDP Option State Caching 969 Some TCP connection parameters, stored in the TCP Control Block, can 970 be usefully shared either among concurrent connections or between 971 connections in sequence, known as TCP Sharing [RFC2140][To18cb]. 972 Although UDP is stateless, some of the options proposed herein may 973 have similar benefit in being shared or cached. We call this UCB 974 Sharing, or UDP Control Block Sharing, by analogy. 976 [TBD: extend this section to indicate which options MAY vs. MUST NOT 977 be shared and how, e.g., along the lines of To18cb] 979 12. Updates to RFC 768 981 This document updates RFC 768 as follows: 983 o This document defines the meaning of the IP payload area beyond 984 the UDP length but within the IP length. 986 o This document extends the UDP API to support the use of options. 988 13. Multicast Considerations 990 UDP options are primarily intended for unicast use. Using these 991 options over multicast IP requires careful consideration, e.g., to 992 ensure that the options used are safe for different endpoints to 993 interpret differently (e.g., either to support or silently ignore) 994 or to ensure that all receivers of a multicast group confirm support 995 for the options in use. 997 14. Security Considerations 999 The use of UDP packets with inconsistent IP and UDP Length fields 1000 has the potential to trigger a buffer overflow error if not properly 1001 handled, e.g., if space is allocated based on the smaller field and 1002 copying is based on the larger. However, there have been no reports 1003 of such vulnerability and it would rely on inconsistent use of the 1004 two fields for memory allocation and copying. 1006 UDP options are not covered by DTLS (datagram transport-layer 1007 security). Despite the name, neither TLS [RFC5246] (transport layer 1008 security, for TCP) nor DTLS [RFC6347] (TLS for UDP) protect the 1009 transport layer. Both operate as a shim layer solely on the payload 1010 of transport packets, protecting only their contents. Just as TLS 1011 does not protect the TCP header or its options, DTLS does not 1012 protect the UDP header or the new options introduced by this 1013 document. Transport security is provided in TCP by the TCP 1014 Authentication Option (TCP-AO [RFC5925]) or in UDP by the 1015 Authentication Extension option (Section 5.9). Transport headers are 1016 also protected as payload when using IP security (IPsec) [RFC4301]. 1018 UDP options use the TLV syntax similar to that of TCP. This syntax 1019 is known to require serial processing and may pose a DOS risk, e.g., 1020 if an attacker adds large numbers of unknown options that must be 1021 parsed in their entirety. Implementations concerned with the 1022 potential for this vulnerability MAY implement only the required 1023 options and MAY also limit processing of TLVs. Because required 1024 options come first and at most once each (with the exception of 1025 NOPs, which should never need to come in sequences of more than 1026 three in a row), this limits their DOS impact. Note that when a 1027 packet's options cannot be processed, it MUST be discarded; the 1028 packet and its options should always share the same fate. 1030 15. IANA Considerations 1032 Upon publication, IANA is hereby requested to create a new registry 1033 for UDP Option Kind numbers, similar to that for TCP Option Kinds. 1034 Initial values of this registry are as listed in Section 5. 1035 Additional values in this registry are to be assigned by IESG 1036 Approval or Standards Action [RFC8126]. 1038 Upon publication, IANA is hereby requested to create a new registry 1039 for UDP Experimental Option Experiment Identifiers (UDP ExIDs) for 1040 use in a similar manner as TCP ExIDs [RFC6994]. This registry is 1041 initially empty. Values in this registry are to be assigned by IANA 1042 using first-come, first-served (FCFS) rules [RFC8126]. 1044 16. References 1046 16.1. Normative References 1048 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1049 Requirement Levels", BCP 14, RFC 2119, March 1997. 1051 [RFC768] Postel, J., "User Datagram Protocol", RFC 768, August 1052 1980. 1054 [RFC791] Postel, J., "Internet Protocol," RFC 791, Sept. 1981. 1056 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -- 1057 Communication Layers," RFC 1122, Oct. 1989. 1059 16.2. Informative References 1061 [Hi15] Hildebrand, J., B. Trammel, "Substrate Protocol for User 1062 Datagrams (SPUD) Prototype," draft-hildebrand-spud- 1063 prototype-03, Mar. 2015. 1065 [RFC793] Postel, J., "Transmission Control Protocol" RFC 793, 1066 September 1981. 1068 [RFC1191] Mogul, J., S. Deering, "Path MTU discovery," RFC 1191, 1069 November 1990. 1071 [RFC2140] Touch, J., "TCP Control Block Interdependence," RFC 2140, 1072 Apr. 1997. 1074 [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery," RFC 1075 2923, September 2000. 1077 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1078 Internet Protocol", RFC 4301, Dec. 2005. 1080 [RFC4340] Kohler, E., M. Handley, and S. Floyd, "Datagram Congestion 1081 Control Protocol (DCCP)", RFC 4340, March 2006. 1083 [RFC4960] Stewart, R. (Ed.), "Stream Control Transmission Protocol", 1084 RFC 4960, September 2007. 1086 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers 1087 Considered Useful," RFC 3692, Jan. 2004. 1089 [RFC3828] Larzon, L-A., M. Degermark, S. Pink, L-E. Jonsson (Ed.), 1090 G. Fairhurst (Ed.), "The Lightweight User Datagram 1091 Protocol (UDP-Lite)," RFC 3828, July 2004. 1093 [RFC5246] Dierks, T., E. Rescorla, "The Transport Layer Security 1094 (TLS) Protocol Version 1.2," RFC 5246, Aug. 2008. 1096 [RFC5925] Touch, J., A. Mankin, R. Bonica, "The TCP Authentication 1097 Option," RFC 5925, June 2010. 1099 [RFC6347] Rescorla, E., N. Modadugu, "Datagram Transport Layer 1100 Security Version 1.2," RFC 6347, Jan. 2012. 1102 [RFC6691] Borman, D., "TCP Options and Maximum Segment Size (MSS)," 1103 RFC 6691, July 2012. 1105 [RFC6978] Touch, J., "A TCP Authentication Option Extension for NAT 1106 Traversal", RFC 6978, July 2013. 1108 [RFC6994] Touch, J., "Shared Use of Experimental TCP Options," RFC 1109 6994, Aug. 2013. 1111 [RFC7323] Borman, D., R. Braden, V. Jacobson, R. Scheffenegger 1112 (Ed.), "TCP Extensions for High Performance," RFC 7323, 1113 Sep. 2014. 1115 [RFC8085] Eggert, L., G. Fairhurst, G. Shepherd, "UDP Usage 1116 Guidelines," RFC 8085, Feb. 2017. 1118 [RFC8126] Cotton, M., B. Leiba, T. Narten, "Guidelines for Writing 1119 an IANA Considerations Section in RFCs," RFC 8126, June 1120 2017. 1122 [RFC8200] Deering, S., R. Hinden, "Internet Protocol Version 6 1123 (IPv6) Specification," RFC 8200, Jul. 2017. 1125 [RFC8201] McCann, J., S. Deering, J. Mogul, R. Hinden (Ed.), "Path 1126 MTU Discovery for IP version 6," RFC 8201, Jul. 2017. 1128 [To18ao] Touch, J., "A TCP Authentication Option Extension for 1129 Payload Encryption", draft-touch-tcp-ao-encrypt, Jan. 1130 2018. 1132 [To18cb] Touch, J., M. Welzl, S. Islam, J. You, "TCP Control Block 1133 Interdependence," draft-touch-tcpm-2140bis, Jan. 2018. 1135 [Tr16] Trammel, B. (Ed.), M. Kuelewind (Ed.), "Requirements for 1136 the design of a Substrate Protocol for User Datagrams 1137 (SPUD)," draft-trammell-spud-req-04, May 2016. 1139 17. Acknowledgments 1141 This work benefitted from feedback from Bob Briscoe, Ken Calvert, 1142 Ted Faber, Gorry Fairhurst, C. M. Heard (including the FRAG/LITE 1143 combination), Tom Herbert, and Mark Smith, as well as discussions on 1144 the IETF TSVWG and SPUD email lists. 1146 This work is partly supported by USC/ISI's Postel Center. 1148 This document was prepared using 2-Word-v2.0.template.dot. 1150 Authors' Addresses 1152 Joe Touch 1154 Manhattan Beach, CA 90266 USA 1156 Phone: +1 (310) 560-0334 1157 Email: touch@strayalpha.com 1159 Appendix A. Implementation Information 1161 The following information is provided to encourage interoperable API 1162 implementations. 1164 System-level variables (sysctl): 1166 Name default meaning 1167 ---------------------------------------------------- 1168 net.ipv4.udp_opt 0 UDP options available 1169 net.ipv4.udp_opt_ocs 1 Default include OCS 1170 net.ipv4.udp_opt_acs 0 Default include ACS 1171 net.ipv4.udp_opt_lite 0 Default include LITE 1172 net.ipv4.udp_opt_mss 0 Default include MSS 1173 net.ipv4.udp_opt_time 0 Default include TIME 1174 net.ipv4.udp_opt_frag 0 Default include FRAG 1175 net.ipv4.udp_opt_ae 0 Default include AE 1177 Socket options (sockopt), cached for outgoing datagrams: 1179 Name meaning 1180 ---------------------------------------------------- 1181 UDP_OPT Enable UDP options (at all) 1182 UDP_OPT_OCS Enable UDP OCS option 1183 UDP_OPT_ACS Enable UDP ACS option 1184 UDP_OPT_LITE Enable UDP LITE option 1185 UDP_OPT_MSS Enable UDP MSS option 1186 UDP_OPT_TIME Enable UDP TIME option 1187 UDP_OPT_FRAG Enable UDP FRAG option 1188 UDP_OPT_AE Enable UDP AE option 1190 Send/sendto parameters: 1192 (TBD - currently using cached parameters) 1194 Connection parameters (per-socketpair cached state, part UCB): 1196 Name Initial value 1197 ---------------------------------------------------- 1198 opts_enabled net.ipv4.udp_opt 1199 ocs_enabled net.ipv4.udp_opt_ocs 1201 The following option is included for debugging purposes, and MUST 1202 NOT be enabled otherwise. 1204 System variables 1205 net.ipv4.udp_opt_junk 0 1207 System-level variables (sysctl): 1209 Name default meaning 1210 ---------------------------------------------------- 1211 net.ipv4.udp_opt_junk 0 Default use of junk 1213 Socket options (sockopt): 1215 Name params meaning 1216 ------------------------------------------------------ 1217 UDP_JUNK - Enable UDP junk option 1218 UDP_JUNK_VAL fillval Value to use as junk fill 1219 UDP_JUNK_LEN length Length of junk payload in bytes 1221 Connection parameters (per-socketpair cached state, part UCB): 1223 Name Initial value 1224 ---------------------------------------------------- 1225 junk_enabled net.ipv4.udp_opt_junk 1226 junk_value 0xABCD 1227 junk_len 4