idnits 2.17.1 draft-ietf-tsvwg-udp-options-01.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 1117 has weird spacing: '...default mean...' == Line 1149 has weird spacing: '...enabled net.i...' == Line 1150 has weird spacing: '...enabled net....' == Line 1160 has weird spacing: '...default mean...' == Line 1166 has weird spacing: '... params mean...' == (1 more instance...) -- The document date (June 27, 2017) is 2494 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 1981 (Obsoleted by RFC 8201) -- Obsolete informational reference (is this intentional?): RFC 2140 (Obsoleted by RFC 9040) -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) -- 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 (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TSVWG J. Touch 2 Internet Draft USC/ISI 3 Intended status: Standards Track June 27, 2017 4 Intended updates: 768 5 Expires: December 2017 7 Transport Options for UDP 8 draft-ietf-tsvwg-udp-options-01.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 December 27, 2017. 36 Copyright Notice 38 Copyright (c) 2017 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)..............................................10 69 5.6. Maximum Segment Size (MSS)...............................12 70 5.7. Timestamps (TIME)........................................13 71 5.8. Fragmentation (FRAG).....................................13 72 5.8.1. Coupling FRAG with LITE.............................16 73 5.9. Authentication and Encryption (AE).......................16 74 5.10. Experimental (EXP)......................................17 75 6. UDP API Extensions............................................17 76 7. Whose options are these?......................................18 77 8. UDP options vs. UDP-Lite......................................19 78 9. Interactions with Legacy Devices..............................19 79 10. Options in a Stateless, Unreliable Transport Protocol........20 80 11. UDP Option State Caching.....................................21 81 12. Multicast Considerations.....................................21 82 13. Security Considerations......................................21 83 14. IANA Considerations..........................................22 84 15. References...................................................22 85 15.1. Normative References....................................22 86 15.2. Informative References..................................23 87 16. Acknowledgments..............................................24 88 Appendix A. Implementation Information...........................26 90 1. Introduction 92 Transport protocols use options as a way to extend their 93 capabilities. TCP [RFC793], SCTP [RFC4960], and DCCP [RFC4340] 94 include space for these options but UDP [RFC768] currently does not. 95 This document defines an experimental extension to UDP that provides 96 space for transport options including their generic syntax and 97 semantics for their use in UDP's stateless, unreliable message 98 protocol. 100 2. Conventions used in this document 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 104 document are to be interpreted as described in RFC 2119 [RFC2119]. 106 In this document, these words will appear with that interpretation 107 only when in ALL CAPS. Lowercase uses of these words are not to be 108 interpreted as carrying significance described in RFC 2119. 110 In this document, the characters ">>" preceding an indented line(s) 111 indicates a statement using the key words listed above. This 112 convention aids reviewers in quickly identifying or finding the 113 portions of this RFC covered by these key words. 115 3. Background 117 Many protocols include a default header and an area for header 118 options. These options enable the protocol to be extended for use in 119 particular environments or in ways unforeseen by the original 120 designers. Examples include TCP's Maximum Segment Size, Window 121 Scale, Timestamp, and Authentication Options 122 [RFC793][RFC5925][RFC7323]. 124 These options are used both in stateful (connection-oriented, e.g., 125 TCP [RFC793], SCTP [RFC4960], DCCP [RFC4340]) and stateless 126 (connectionless, e.g., IPv4 [RFC791], IPv6 [RFC2460] protocols. In 127 stateful protocols they can help extend the way in which state is 128 managed. In stateless protocols their effect is often limited to 129 individual packets, but they can have an aggregate effect on a 130 sequence as well. One example of such uses is Substrate Protocol for 131 User Datagrams (SPUD) [Tr15], and this document is intended to 132 provide an out-of-band option area as an alternative to the in-band 133 mechanism currently proposed [Hi15]. 135 UDP is one of the most popular protocols that lacks space for 136 options [RFC768]. The UDP header was intended to be a minimal 137 addition to IP, providing only ports and a data checksum for 138 protection. This document experimentally extends UDP to provide a 139 trailer area for options located after the UDP data payload. 141 4. The UDP Option Area 143 The UDP transport header includes demultiplexing and service 144 identification (port numbers), a checksum, and a field that 145 indicates the UDP datagram length (including UDP header). The UDP 146 Length length field is typically redundant with the size of the 147 maximum space available as a transport protocol payload (see also 148 discussion in Section 9). 150 For IPv4, IP Total Length field indicates the total IP datagram 151 length (including IP header), and the size of the IP options is 152 indicated in the IP header (in 4-byte words) as the "Internet Header 153 Length" (IHL), as shown in Figure 1 [RFC791]. As a result, the 154 typical (and largest valid) value for UDP Length is: 156 UDP_Length = IPv4_Total_Length - IPv4_IHL * 4 158 For IPv6, the IP Payload Length field indicates the datagram after 159 the base IPv6 header, which includes the IPv6 extension headers and 160 space available for the transport protocol, as shown in Figure 2 161 [RFC2460]. Note that the Next HDR field in IPv6 might not indicate 162 UDP (i.e., 17), e.g., when intervening IP extension headers are 163 present. For IPv6, the lengths of any additional IP extensions are 164 indicated within each extension [RFC2460], so the typical (and 165 largest valid) value for UDP Length is: 167 UDP_Length = IPv6_Payload_Length - sum(extension header lengths) 169 In both cases, the space available for the UDP transport protocol 170 data unit is indicated by IP, either completely in the base header 171 (for IPv4) or adding information in the extensions (for IPv6). In 172 either case, this document will refer to this available space as the 173 "IP transport payload". 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 |Version| IHL |Type of Service| Total Length | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | Identification |Flags| Fragment Offset | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | Time to Live | Proto=17 (UDP)| Header Checksum | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 | Source Address | 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 | Destination Address | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 ... zero or more IP Options (using space as indicated by IHL) ... 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | UDP Source Port | UDP Destination Port | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | UDP Length | UDP Checksum | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 Figure 1 IPv4 datagram with UDP transport payload 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 |Version| Traffic Class | Flow Label | 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 | Payload Length | Next Hdr | Hop Limit | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 ... 201 | Source Address (128 bits) | 202 ... 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 ... 205 | Destination Address (128 bits) | 206 ... 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 ... zero or more IP Extension headers (each indicating size) ... 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 | UDP Source Port | UDP Destination Port | 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 | UDP Length | UDP Checksum | 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 Figure 2 IPv6 datagram with UDP transport payload 217 As a result of this redundancy, there is an opportunity to use the 218 UDP Length field as a way to break up the IP transport payload into 219 two areas - that intended as UDP user data and an additional 220 "surplus area" (as shown in Figure 3). 222 IP transport payload 223 <-------------------------------------------------> 224 +--------+---------+----------------------+------------------+ 225 | IP Hdr | UDP Hdr | UDP user data | surplus area | 226 +--------+---------+----------------------+------------------+ 227 <------------------------------> 228 UDP Length 230 Figure 3 IP transport payload vs. UDP Length 232 In most cases, the IP transport payload and UDP Length point to the 233 same location, indicating that there is no surplus area. It is 234 important to note that this is not a requirement of UDP [RFC768] 235 (discussed further in Section 9). UDP-Lite used the difference in 236 these pointers to indicate the partial coverage of the UDP Checksum, 237 such that the UDP user data, UDP header, and UDP pseudoheader (a 238 subset of the IP header) are covered by the UDP checksum but 239 additional user data in the surplus area is not covered [RFC3828]. 240 This document uses the surplus area for UDP transport options. 242 The UDP option area is thus defined as the location between the end 243 of the UDP payload and the end of the IP datagram as a trailing 244 options area. This area can occur at any valid byte offset, i.e., it 245 need not be 16-bit or 32-bit aligned. In effect, this document 246 redefines the UDP "Length" field as a "trailer offset". 248 UDP options are defined using a TLV (type, length, and optional 249 value) syntax similar to that of TCP [RFC793]. They are typically a 250 minimum of two bytes in length as shown in Figure 4, excepting only 251 the one byte options "No Operation" (NOP) and "End of Options List" 252 (EOL) described below. 254 +--------+--------+ 255 | Kind | Length | 256 +--------+--------+ 258 Figure 4 UDP option default format 260 >> UDP options MAY occur at any UDP length offset. 262 >> The UDP length MUST be at least as large as the UDP header (8) 263 and no larger than the IP transport payload. Values outside this 264 range MUST be silently discarded as invalid and logged where rate- 265 limiting permits. 267 Others have considered using values of the UDP Length that is larger 268 than the IP transport payload as an additional type of signal. Using 269 a value smaller than the IP transport payload is expected to be 270 backward compatible with existing UDP implementations, i.e., to 271 deliver the UDP Length of user data to the application and silently 272 ignore the additional surplus area data. Using a value larger than 273 the IP transport payload would either be considered malformed (and 274 be silently dropped) or could cause buffer overruns, and so is not 275 considered silently and safely backward compatible. Its use is thus 276 out of scope for the extension described in this document. 278 >> UDP options MUST be interpreted in the order in which they occur 279 in the UDP option area. 281 5. UDP Options 283 The following UDP options are currently defined: 285 Kind Length Meaning 286 ---------------------------------------------- 287 0* - End of Options List (EOL) 288 1* - No operation (NOP) 289 2* 2 Option checksum (OCS) 290 3 4 Alternate checksum (ACS) 291 4 4 Lite (LITE) 292 5 4 Maximum segment size (MSS) 293 6 10 Timestamps (TIME) 294 7 12 Fragmentation (FRAG) 295 8 (varies) Authentication and Encryption (AE) 296 9-126 (varies) UNASSIGNED (assignable by IANA) 297 127-253 RESERVED 298 254 N(>=4) RFC 3692-style experiments (EXP) 299 255 RESERVED 301 These options are defined in the following subsections. 303 >> An endpoint supporting UDP options MUST support those marked with 304 a "*" above: EOL, NOP, and OCS. 306 [QUESTION: Should we extend these, e.g., through #7?] 308 >> All other options (without a "*") MAY be implemented, and their 309 use SHOULD be determined either out-of-band or negotiated. 311 >> Receivers MUST silently ignore unknown options. That includes 312 options whose length does not indicate the specified value. 314 >> Only ACS and AE options depend on the contents of the option 315 area. AE is always computed as if both the AE hash and ACS checksum 316 are zero; ACS is computed as if the ACS checksum is zero. Future 317 options MUST NOT be defined as having a value independent of the 318 contents of the option area. Otherwise, interactions between those 319 values, ACS, and UDP-AE could be unpredictable. 321 Receivers cannot treat unexpected option lengths as invalid, as this 322 would unnecessarily limit future revision of options (e.g., defining 323 a new ACS that is defined by having a different length). 325 >> Option lengths MUST NOT exceed the IP length of the packet. If 326 this occurs, the packet MUST be treated as malformed and dropped, 327 and the event MAY be logged for diagnostics (logging SHOULD be rate 328 limited). 330 >> Required options MUST come before other options. Each required 331 option MUST NOT occur more than once (if they are repeated in a 332 received segment, all except the first MUST be silently ignored). 334 The requirement that required options come before others is intended 335 to allow for endpoints to implement DOS protection, as discussed 336 further in Section 13. 338 5.1. End of Options List (EOL) 340 The End of Options List (EOL) option indicates that there are no 341 more options. It is used to indicate the end of the list of options 342 without needing to pad the options to fill all available option 343 space. 345 +--------+ 346 | Kind=0 | 347 +--------+ 349 Figure 5 UDP EOL option format 351 >> When the UDP options do not consume the entire option area, the 352 last non-NOP option SHOULD be EOL (vs. filling the entire option 353 area with NOP values). 355 >> All bytes after EOL MUST be ignored by UDP option processing. As 356 a result, there can only ever be one EOL option (even if other bytes 357 were zero, they are ignored). 359 5.2. No Operation (NOP) 361 The No Operation (NOP) option is a one byte placeholder, intended to 362 be used as padding, e.g., to align multi-byte options along 16-bit 363 or 32-bit boundaries. 365 +--------+ 366 | Kind=1 | 367 +--------+ 369 Figure 6 UDP NOP option format 371 >> If options longer than one byte are used, NOP options SHOULD be 372 used at the beginning of the UDP options area to achieve alignment 373 as would be more efficient for active (i.e., non-NOP) options. 375 >> Segments SHOULD NOT use more than three consecutive NOPs. NOPs 376 are intended to assist with alignment, not other padding or fill. 378 [NOTE: Tom Herbert suggested we declare "more than 3 consecutive 379 NOPs" a fatal error to reduce the potential of using NOPs as a DOS 380 attack, but IMO there are other equivalent ways (e.g., using 381 RESERVED or other UNASSIGNED values) and the "no more than 3" 382 creates its own DOS vulnerability) 384 5.3. Option Checksum (OCS) 386 The Option Checksum (OCS) is an 8-bit ones-complement sum (Ones8) 387 that covers all of the UDP options. OCS is 8-bits to allow the 388 entire option to occupy a total of 16 bits. 390 OCS can be calculated by computing the 16-bit ones-complement sum 391 and "folding over" the result (using carry wraparound). Note that 392 OCS is direct, i.e., it is not negated or adjusted if zero (unlike 393 the Internet checksum as used in IPv4, TCP, and UDP headers). OCS 394 protects the option area from errors in a similar way that the UDP 395 checksum protects the UDP user data. 397 +--------+--------+ 398 | Kind=2 | Ones8 | 399 +--------+--------+ 401 Figure 7 UDP OCS option format 403 >> When present, the option checksum SHOULD occur as early as 404 possible, preferably preceded by only NOP options for alignment and 405 the LITE option if present. 407 OCS covers the entire UDP option, including the Lite option as 408 formatted before swapping for transmission (or, equivalently, after 409 the swap after reception). 411 >> If the option checksum fails, all options MUST be ignored and any 412 trailing surplus data (and Lite data, if used) silently discarded. 414 >> UDP data that is validated by a correct UDP checksum MUST be 415 delivered to the application layer, even if the UDP option checksum 416 fails, unless the endpoints have negotiated otherwise for this 417 segment's socket pair. 419 5.4. Alternate Checksum (ACS) 421 The Alternate Checksum (ACS) is a 16-bit CRC of the UDP payload only 422 (excluding the IP pseudoheader, UDP header, and UDP options). It 423 does not include the IP pseudoheader or UDP header, and so need not 424 be updated by NATs when IP addresses or UDP ports are rewritten. Its 425 purpose is to detect errors that the UDP checksum might not detect. 426 CRC-CCITT (polynomial x^16 + x^12 + x^5 + x or polynomial 0x1021) 427 has been chosen because of its ubiquity and use in other packet 428 protocols, such as X.25, HDLC, and Bluetooth. 430 +--------+--------+--------+--------+ 431 | Kind=3 | Len=4 | CRC16sum | 432 +--------+--------+--------+--------+ 434 Figure 8 UDP ACS option format 436 When ACS is computed, its checksum (CRC) area is zeroed. No other 437 options are zeroed before computing ACS. 439 5.5. Lite (LITE) 441 The Lite option (LITE) is intended to provide equivalent capability 442 to the UDP Lite transport protocol [RFC3828]. UDP Lite allows the 443 UDP checksum to cover only a prefix of the UDP data payload, to 444 protect critical information (e.g., application headers) but allow 445 potentially erroneous data to be passed to the user. This feature 446 helps protect application headers but allows for application data 447 errors. Some applications are impacted more by a lack of data than 448 errors in data, e.g., voice and video. 450 >> When LITE is active, it MUST come first in the UDP options list. 452 LITE is intended to support the same API as for UDP Lite to allow 453 applications to send and receive data that has a marker indicating 454 the portion protected by the UDP checksum and the portion not 455 protected by the UDP checksum. 457 LITE includes a 2-byte offset that indicates the length of the 458 portion of the UDP data that is not covered by the UDP checksum. 460 +--------+--------+--------+--------+ 461 | Kind=5 | Len=4 | Offset | 462 +--------+--------+--------+--------+ 464 Figure 9 UDP LITE option format 466 At the sender, the option is formed using the following steps: 468 1. Create a LITE option, ordered as the first UDP option (Figure 469 10). 471 2. Calculate the location of the start of the options as an absolute 472 offset from the start of the UDP header and place that length in 473 the last two bytes of the LITE option. 475 3. Swap all four bytes of the LITE option with the first 4 bytes of 476 the LITE data area (Figure 11). 478 +---------+--------------+--------------+------------------+ 479 | UDP Hdr | user data | LITE data |LITE| other opts | 480 +---------+--------------+--------------+------------------+ 481 <----------------------> 482 UDP Length 484 Figure 10 LITE option formation - LITE goes first 486 +---------+--------------+--------------+------------------+ 487 | UDP Hdr | user data | LITE data |LITE| other opts | 488 +---------+--------------+--------------+------------------+ 489 ^^^^ ^^^^ 490 | | 491 +--------------+ 493 Figure 11 Before sending swap LITE option and front of LITE data 495 The resulting packet has the format shown in Figure 12. Note that 496 the UDP length now points to the LITE option, and the LITE option 497 points to the start of the option area. 499 +---------+--------------+----------------+------------------+ 500 | UDP Hdr | user data |LITE| LITE data |Ldat| other opts | 501 +---------+--------------+----------------+------------------+ 502 <----------------------> | ^ 503 UDP Length +-------------+ 505 Figure 12 Lite option as sent 507 A legacy endpoint receiving this packet will discard the LITE option 508 and everything that follows, including the lite data and remainder 509 of the UDP options. The UDP checksum will protect only the user 510 data, not the LITE option or lite data. 512 Receiving endpoints capable of processing UDP options will do the 513 following: 515 1. Process options as usual. This will start at the LITE option. 517 2. When the LITE option is encountered, record its location as the 518 start of the LITE data area and swap the four bytes there with 519 the four bytes at the location indicated inside the LITE option, 520 which indicates the start of all of the options, including the 521 LITE one (one past the end of the lite data area). This restores 522 the format of the option as per Figure 10. 524 3. Continue processing the remainder of the options, which are now 525 in the format shown in Figure 11. 527 The purpose of this swap is to support the equivalent of UDP Lite 528 operation together with other UDP options without requiring the 529 entire LITE data area to be moved after the UDP option area. 531 5.6. Maximum Segment Size (MSS) 533 The Maximum Segment Size (MSS, Kind = 3) is a 16-bit indicator of 534 the largest UDP segment that can be received. As with the TCP MSS 535 option [RFC793], the size indicated is the IP layer MTU decreased by 536 the fixed IP and UDP headers only [RFC6691]. The space needed for IP 537 and UDP options need to be adjusted by the sender when using the 538 value indicated. The value transmitted is based on EMTU_R, the 539 largest IP datagram that can be received (i.e., reassembled at the 540 receiver) [RFC1122]. 542 +--------+--------+--------+--------+ 543 | Kind=5 | Len=4 | MSS size | 544 +--------+--------+--------+--------+ 546 Figure 13 UDP MSS option format 548 The UDP MSS option MAY be used for path MTU discovery 549 [RFC1191][RFC1981], but this may be difficult because of known 550 issues with ICMP blocking [RFC2923] as well as UDP lacking automatic 551 retransmission. It is more likely to be useful when coupled with IP 552 source fragmentation to limit the largest reassembled UDP message, 553 e.g., when EMTU_R is larger than the required minimums (576 for IPv4 554 [RFC791] and 1500 for IPv6 [RFC2460]). 556 5.7. Timestamps (TIME) 558 The UDP Timestamp option (TIME) exchanges two four-byte timestamp 559 fields. It serves a similar purpose to TCP's TS option [RFC7323], 560 enabling UDP to estimate the round trip time (RTT) between hosts. 561 For UDP, this RTT can be useful for establishing UDP fragment 562 reassembly timeouts or transport-layer rate-limiting [RFC8085]. 564 +--------+--------+------------------+------------------+ 565 | Kind=6 | Len=10 | TS Value | TS Echo Reply | 566 +--------+--------+------------------+------------------+ 567 1 byte 1 byte 4 bytes 4 bytes 569 Figure 14 UDP TIME option format 571 TS Value (TSval) and TS Echo (TSecr) are used in a similar manner to 572 the TCP TS option [RFC7323]. A host using the Timestamp option sets 573 TS Value on all UDP segments issued. Received TSval values are 574 provided to the application, which passes this value as TSecr on UDP 575 messages sent in response to such a message. 577 >> UDP MAY use an RTT estimate based on nonzero Timestamp values as 578 a hint for fragmentation reassembly, rate limiting, or other 579 mechanisms that benefit from such an estimate. 581 >> UDP SHOULD make this RTT estimate available to the user 582 application. 584 5.8. Fragmentation (FRAG) 586 The Fragmentation option (FRAG) supports UDP fragmentation and 587 reassembly, which can be used to transfer UDP messages larger than 588 limited by the IP receive MTU (EMTU_R [RFC1122]). It is typically 589 used with the UDP MSS option to enable more efficient use of large 590 messages, both at the UDP and IP layers. FRAG is designed similar to 591 the IPv6 Fragmentation Header [RFC2460], except that the UDP variant 592 uses a 16-bit Offset measured in bytes, rather than IPv6's 13-bit 593 Fragment Offset measured in 8-byte units. This UDP variant avoids 594 creating reserved fields. 596 +--------+--------+--------+--------+ 597 | Kind=8 | Len=8 | Frag. Offset | 598 +--------+--------+--------+--------+ 599 | Identification | 600 +--------+--------+--------+--------+ 602 Figure 15 UDP non-terminal FRAG option format 604 The FRAG option also lacks a "more" bit, zeroed for the terminal 605 fragment of a set. This is possible because the terminal FRAG option 606 is indicated as a longer, 12-byte variant, which includes an 607 Internet checksum over the reassembled payload (omitting the IP 608 pseudoheader and UDP header, as well as UDP options), as shown in 609 Figure 16. 611 >> The reassembly checksum SHOULD be used, but MAY be unused in the 612 same situations when the UDP checksum is unused (e.g., for transit 613 tunnels or applications that have their own integrity checks 614 [RFC2460]), and by the same mechanism (set the field to 0x0000). 616 +--------+--------+--------+--------+ 617 | Kind=8 | Len=12 | Frag. Offset | 618 +--------+--------+--------+--------+ 619 | Identification | 620 +--------+--------+--------+--------+ 621 | Checksum | 622 +--------+--------+ 624 Figure 16 UDP terminal FRAG option format 626 The Fragment Offset is 16 bits and indicates the location of the UDP 627 payload fragment in bytes from the beginning of the original 628 unfragmented payload. The Len field indicates whether there are more 629 fragments (Len=8) or no more fragments (Len=12). 631 >> The Identification field is a 32-bit value that MUST be unique 632 over the expected fragment reassembly timeout. 634 >> The Identification field SHOULD be generated in a manner similar 635 to that of the IPv6 Fragment ID [RFC2460]. 637 >> UDP fragments MUST NOT overlap. 639 FRAG needs to be used with extreme care because it will present 640 incorrect datagram boundaries to a legacy receiver, unless encoded 641 as LITE data (see Section 5.8.1). 643 >> A host SHOULD indicate FRAG support by transmitting an 644 unfragmented datagram using the Fragmentation option (e.g., with 645 Offset zero and length 12, i.e., including the checksum area), 646 except when encoded as LITE. 648 >> A host MUST NOT transmit a UDP fragment before receiving recent 649 confirmation from the remote host, except when FRAG is encoded as 650 LITE. 652 UDP fragmentation relies on a fragment expiration timer, which can 653 be preset or could use a value computed using the UDP Timestamp 654 option. 656 >> The default UDP reassembly SHOULD be no more than 2 minutes. 658 Implementers are advised to limit the space available for UDP 659 reassembly. 661 >> UDP reassembly space SHOULD be limited to reduce the impact of 662 DOS attacks on resource use. 664 >> UDP reassembly space limits SHOULD NOT be implemented as an 665 aggregate, to avoid cross-socketpair DOS attacks. 667 >> Individual UDP fragments MUST NOT be forwarded to the user. The 668 reassembled datagram is received only after complete reassembly, 669 checksum validation, and continued processing of the remaining 670 options. 672 Any additional UDP options would follow the FRAG option in the final 673 fragment, and would be included in the reassembled packet. 674 Processing of those options would commence after reassembly. 676 >> UDP options MUST NOT follow the FRAG header in non-terminal 677 fragments. Any data following the FRAG header in non-terminal 678 fragments MUST be silently dropped. All other options that apply to 679 a reassembled packet MUST follow the FRAG header in the terminal 680 fragment. 682 5.8.1. Coupling FRAG with LITE 684 FRAG can be coupled with LITE to avoid impacting legacy receivers. 685 Each fragment is sent as LITE un-checksummed data, where each UDP 686 packet contains no legacy-compatible data. Legacy receivers 687 interpret these as zero-payload packets, which would not affect the 688 receiver unless the presence of the packet itself were a signal. The 689 header of such a packet would appear as shown in Figure 17 and 690 Figure 18. 692 +---------+--------------+---------+ 693 | UDP Hdr | LiteFrag |LITE|FRAG| 694 +---------+--------------+----+----+ 695 <-------> ^^^^ ^^^^ 696 Zero UDP Length | | 697 +--------------+ 699 Figure 17 Preparing FRAG as Lite data 701 +---------+--------------+----+ 702 | UDP Hdr |LITE|LiteFrag |FRAG| 703 +---------+--------------+----+ 704 <-------> | ^ 705 Zero UDP Length | | 706 +-------------+ 708 Figure 18 Lite option before transmission 710 When a packet is reassembled, it appears as a complete LITE data 711 region. The UDP header of the reassembled packet is adjusted 712 accordingly, so that the reassembled region now appears as 713 conventional UDP user data, and processing of the UDP options 714 continues, as with the non-LITE FRAG variant. 716 5.9. Authentication and Encryption (AE) 718 The Authentication and Encryption option (AE) is intended to allow 719 UDP to provide a similar type of authentication as the TCP 720 Authentication Option (TCP-AO) [RFC5925]. It uses the same format as 721 specified for TCP-AO, except that it uses a Kind of 8. UDP-AO 722 supports NAT traversal in a similar manner as TCP-AO [RFC6978]. UDP- 723 AO can also be extended to provide a similar encryption capability 724 as TCP-AO-ENC, in a similar manner [To17ao]. For these reasons, the 725 option is known as UDP-AE. 727 Like TCP-AO, UDP-AE is not negotiated in-band. Its use assumes both 728 endpoints have populated Master Key Tuples (MKTs), used to exclude 729 non-protected traffic. 731 TCP-AO generates unique traffic keys from a hash of TCP connection 732 parameters. UDP lacks a three-way handshake to coordinate 733 connection-specific values, such as TCP's Initial Sequence Numbers 734 (ISNs) [RFC793], thus UDP-AE's Key Derivation Function (KDF) uses 735 zeroes as the value for both ISNs. This means that the UDP-AE reuses 736 keys when socket pairs are reused, unlike TCP-AO. 738 UDP-AE can be configured to either include or exclude TCP options, 739 the same way as can TCP-AO. When UDP options are covered, the ACS 740 option area checksum and UDP-AE hash areas are zeroed before 741 computing the AE hash. It is important to consider that options not 742 yet defined might yield unpredictable results if not confirmed as 743 supported, e.g., if they contain other hashes or checksums that 744 depend on the option area contents. 746 Similar to TCP-AO-NAT, UDP-AE can be configured to support NAT 747 traversal, excluding one or both of the UDP ports [RFC6978]. 749 5.10. Experimental (EXP) 751 The Experimental option (EXP) is reserved for experiments [RFC3692]. 752 Only one such value is reserved because experiments are expected to 753 use an Experimental ID (ExIDs) to differentiate concurrent use for 754 different purposes, using UDP ExIDs registered with IANA according 755 to the approach developed for TCP experimental options [RFC6994]. 757 >> The length of the experimental option MUST be at least 4 to 758 account for the Kind, Length, and the minimum 16-bit UDP ExID 759 identifier (similar to TCP ExIDs [RFC6994]). 761 6. UDP API Extensions 763 UDP currently specifies an application programmer interface (API), 764 summarized as follows (with Unix-style command as an example) 765 [RFC768]: 767 o Method to create new receive ports 769 o E.g., bind(handle, recvaddr(optional), recvport) 771 o Receive, which returns data octets, source port, and source 772 address 773 o E.g., recvfrom(handle, srcaddr, srcport, data) 775 o Send, which specifies data, source and destination addresses, and 776 source and destination ports 778 o E.g., sendto(handle, destaddr, destport, data) 780 This API is extended to support options as follows: 782 o Extend the method to create receive ports to include receive 783 options that are required. Datagrams not containing these 784 required options MUST be silently dropped and MAY be logged. 786 o Extend the receive function to indicate the options and their 787 parameters as received with the corresponding received datagram. 789 o Extend the send function to indicate the options to be added to 790 the corresponding sent datagram. 792 Examples of API instances for Linux and FreeBSD are provided in 793 Appendix A, to encourage uniform cross-platform implementations. 795 7. Whose options are these? 797 UDP options are indicated in an area of the IP payload that is not 798 used by UDP. That area is really part of the IP payload, not the UDP 799 payload, and as such, it might be tempting to consider whether this 800 is a generally useful approach to extending IP. 802 Unfortunately, the surplus area exists only for transports that 803 include their own transport layer payload length indicator. TCP and 804 SCTP include header length fields that already provide space for 805 transport options by indicating the total length of the header area, 806 such that the entire remaining area indicated in the network layer 807 (IP) is transport payload. UDP-Lite already uses the UDP Length 808 field to indicate the boundary between data covered by the transport 809 checksum and data not covered, and so there is no remaining area 810 where the length of the UDP-Lite payload as a whole can be indicated 811 [RFC3828]. 813 UDP options are intended for use only by the transport endpoints. 814 They are no more (or less) appropriate to be modified in-transit 815 than any other portion of the transport datagram. 817 UDP options are transport options. Generally, transport datagrams 818 are not intended to be modified in-transit. However, the UDP option 819 mechanism provides no specific protection against in-transit 820 modification of the UDP header, UDP payload, or UDP option area, 821 except as provided by the options selected (e.g., OCS, ACS, or AE). 823 8. UDP options vs. UDP-Lite 825 UDP-Lite provides partial checksum coverage, so that packets with 826 errors in some locations can be delivered to the user [RFC3828]. It 827 uses a different transport protocol number (136) than UDP (17) to 828 interpret the UDP Length field as the prefix covered by the UDP 829 checksum. 831 UDP (protocol 17) already defines the UDP Length field as the limit 832 of the UDP checksum, but by default also limits the data provided to 833 the application as that which precedes the UDP Length. A goal of 834 UDP-Lite is to deliver data beyond UDP Length as a default, which is 835 why a separate transport protocol number was required. 837 UDP options do not need a separate transport protocol number because 838 the data beyond the UDP Length offset (surplus data) is not provided 839 to the application by default. That data is interpreted exclusively 840 within the UDP transport layer. 842 UDP options support a similar service to UDP-Lite by terminating the 843 UDP options with an EOL option. The additional data not covered by 844 the UDP checksum follows that EOL option, and is passed to the user 845 separately. The difference is that UDP-Lite provides the un- 846 checksummed user data to the application by default, whereas UDP 847 options can provide the same capability only for endpoints that are 848 negotiated in advance (i.e., by default, UDP options would silently 849 discard this non-checksummed data). Additionally, in UDP-Lite the 850 checksummed and non-checksummed payload components are adjacent, 851 whereas in UDP options they are separated by the option area - 852 which, minimally, must consist of at least one EOL option. 854 UDP-Lite cannot support UDP options, either as proposed here or in 855 any other form, because the entire payload of the UDP packet is 856 already defined as user data and there is no additional field in 857 which to indicate a separate area for options. The UDP Length field 858 in UDP-Lite is already used to indicate the boundary between user 859 data covered by the checksum and user data not covered. 861 9. Interactions with Legacy Devices 863 It has always been permissible for the UDP Length to be inconsistent 864 with the IP transport payload length [RFC768]. Such inconsistency 865 has been utilized in UDP-Lite using a different transport number. 866 There are no known systems that use this inconsistency for UDP 868 [RFC3828]. It is possible that such use might interact with UDP 869 options, i.e., where legacy systems might generate UDP datagrams 870 that appear to have UDP options. The UDP OCS provides protection 871 against such events and is stronger than a static "magic number". 873 UDP options have been tested as interoperable with Linux, Max OS-X, 874 and Windows Cygwin, and worked through NAT devices. These systems 875 successfully delivered only the user data indicated by the UDP 876 Length field and silently discarded the surplus area. 878 One reported embedded device passes the entire IP datagram to the 879 UDP application layer. Although this feature could enable 880 application-layer UDP option processing, it would require that 881 conventional UDP user applications examine only the UDP payload. 882 This feature is also inconsistent with the UDP application interface 883 [RFC768] [RFC1122]. 885 It has been reported that Alcatel-Lucent's "Brick" Intrusion 886 Detection System has a default configuration that interprets 887 inconsistencies between UDP Length and IP Length as an attack to be 888 reported. Note that other firewall systems, e.g., CheckPoint, use a 889 default "relaxed UDP length verification" to avoid falsely 890 interpreting this inconsistency as an attack. 892 (TBD: test with UDP checksum offload and UDP fragmentation offload) 894 10. Options in a Stateless, Unreliable Transport Protocol 896 There are two ways to interpret options for a stateless, unreliable 897 protocol -- an option is either local to the message or intended to 898 affect a stream of messages in a soft-state manner. Either 899 interpretation is valid for defined UDP options. 901 It is impossible to know in advance whether an endpoint supports a 902 UDP option. 904 >> UDP options MUST allow for silent failure on first receipt. 906 >> UDP options that rely on soft-state exchange MUST allow for 907 message reordering and loss. 909 >> A UDP option MUST be silently optional until confirmed by 910 exchange with an endpoint. 912 The above requirements prevent using any option that cannot be 913 safely ignored unless that capability has been negotiated with an 914 endpoint in advance for a socket pair. Legacy systems would need to 915 be able to interpret the transport payload fragments as individual 916 transport datagrams. 918 11. UDP Option State Caching 920 Some TCP connection parameters, stored in the TCP Control Block, can 921 be usefully shared either among concurrent connections or between 922 connections in sequence, known as TCP Sharing [RFC2140][To17cb]. 923 Although UDP is stateless, some of the options proposed herein may 924 have similar benefit in being shared or cached. We call this UCB 925 Sharing, or UDP Control Block Sharing, by analogy. 927 [TBD: extend this section to indicate which options MAY vs. MUST NOT 928 be shared and how, e.g., along the lines of To17cb] 930 Updates to RFC 768 932 This document updates RFC 768 as follows: 934 o This document defines the meaning of the IP payload area beyond 935 the UDP length but within the IP length. 937 o This document extends the UDP API to support the use of options. 939 12. Multicast Considerations 941 UDP options are primarily intended for unicast use. Using these 942 options over multicast IP requires careful consideration, e.g., to 943 ensure that the options used are safe for different endpoints to 944 interpret differently (e.g., either to support or silently ignore) 945 or to ensure that all receivers of a multicast group confirm support 946 for the options in use. 948 13. Security Considerations 950 The use of UDP packets with inconsistent IP and UDP Length fields 951 has the potential to trigger a buffer overflow error if not properly 952 handled, e.g., if space is allocated based on the smaller field and 953 copying is based on the larger. However, there have been no reports 954 of such vulnerability and it would rely on inconsistent use of the 955 two fields for memory allocation and copying. 957 UDP options are not covered by DTLS (datagram transport-layer 958 security). Despite the name, neither TLS [RFC5246] (transport layer 959 security, for TCP) nor DTLS [RFC6347] (TLS for UDP) protect the 960 transport layer. Both operate as a shim layer solely on the payload 961 of transport packets, protecting only their contents. Just as TLS 962 does not protect the TCP header or its options, DTLS does not 963 protect the UDP header or the new options introduced by this 964 document. Transport security is provided in TCP by the TCP 965 Authentication Option (TCP-AO [RFC5925]) or in UDP by the 966 Authentication Extension option (Section 5.9). Transport headers are 967 also protected as payload when using IP security (IPsec) [RFC4301]. 969 UDP options use the TLV syntax similar to that of TCP. This syntax 970 is known to require serial processing and may pose a DOS risk, e.g., 971 if an attacker adds large numbers of unknown options that must be 972 parsed in their entirety. Implementations concerned with the 973 potential for this vulnerability MAY implement only the required 974 options and MAY also limit NOPs (e.g., no more than three 975 consecutive NOPs or some total number that might occur between the 976 required options, if all are present). Because the required options 977 come first and at most once each (and all later duplicates silently 978 ignored), this limits the DOS impact. 980 14. IANA Considerations 982 Upon publication, IANA is hereby requested to create a new registry 983 for UDP Option Kind numbers, similar to that for TCP Option Kinds. 984 Initial values of this registry are as listed in Section 5. 985 Additional values in this registry are to be assigned by IESG 986 Approval or Standards Action [RFC8126]. 988 Upon publication, IANA is hereby requested to create a new registry 989 for UDP Experimental Option Experiment Identifiers (UDP ExIDs) for 990 use in a similar manner as TCP ExIDs [RFC6994]. This registry is 991 initially empty. Values in this registry are to be assigned by IANA 992 using first-come, first-served (FCFS) rules [RFC8126]. 994 15. References 996 15.1. Normative References 998 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 999 Requirement Levels", BCP 14, RFC 2119, March 1997. 1001 [RFC768] Postel, J., "User Datagram Protocol", RFC 768, August 1002 1980. 1004 [RFC791] Postel, J., "Internet Protocol," RFC 791, Sept. 1981. 1006 15.2. Informative References 1008 [Hi15] Hildebrand, J., B. Trammel, "Substrate Protocol for User 1009 Datagrams (SPUD) Prototype," draft-hildebrand-spud- 1010 prototype-03, Mar. 2015. 1012 [RFC793] Postel, J., "Transmission Control Protocol" RFC 793, 1013 September 1981. 1015 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -- 1016 Communication Layers," RFC 1122, Oct. 1989. 1018 [RFC1191] Mogul, J., S. Deering, "Path MTU discovery," RFC 1191, 1019 November 1990. 1021 [RFC1981] McCann, J., S. Deering, J. Mogul, "Path MTU Discovery for 1022 IP version 6," RFC 1981, Aug. 1996. 1024 [RFC2140] Touch, J., "TCP Control Block Interdependence," RFC 2140, 1025 Apr. 1997. 1027 [RFC2460] Deering, S., R. Hinden, "Internet Protocol Version 6 1028 (IPv6) Specification," RFC 2460, Dec. 1998. 1030 [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery," RFC 1031 2923, September 2000. 1033 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1034 Internet Protocol", RFC 4301, Dec. 2005. 1036 [RFC4340] Kohler, E., M. Handley, and S. Floyd, "Datagram Congestion 1037 Control Protocol (DCCP)", RFC 4340, March 2006. 1039 [RFC4960] Stewart, R. (Ed.), "Stream Control Transmission Protocol", 1040 RFC 4960, September 2007. 1042 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers 1043 Considered Useful," RFC 3692, Jan. 2004. 1045 [RFC3828] Larzon, L-A., M. Degermark, S. Pink, L-E. Jonsson (Ed.), 1046 G. Fairhurst (Ed.), "The Lightweight User Datagram 1047 Protocol (UDP-Lite)," RFC 3828, July 2004. 1049 [RFC5246] Dierks, T., E. Rescorla, "The Transport Layer Security 1050 (TLS) Protocol Version 1.2," RFC 5246, Aug. 2008. 1052 [RFC5925] Touch, J., A. Mankin, R. Bonica, "The TCP Authentication 1053 Option," RFC 5925, June 2010. 1055 [RFC6347] Rescorla, E., N. Modadugu, "Datagram Transport Layer 1056 Security Version 1.2," RFC 6347, Jan. 2012. 1058 [RFC6691] Borman, D., "TCP Options and Maximum Segment Size (MSS)," 1059 RFC 6691, July 2012. 1061 [RFC6978] Touch, J., "A TCP Authentication Option Extension for NAT 1062 Traversal", RFC 6978, July 2013. 1064 [RFC6994] Touch, J., "Shared Use of Experimental TCP Options," RFC 1065 6994, Aug. 2013. 1067 [RFC7323] Borman, D., R. Braden, V. Jacobson, R. Scheffenegger 1068 (Ed.), "TCP Extensions for High Performance," RFC 7323, 1069 Sep. 2014. 1071 [RFC8085] Eggert, L., G. Fairhurst, G. Shepherd, "UDP Usage 1072 Guidelines," RFC 8085, Feb. 2017. 1074 [RFC8126] Cotton, M., B. Leiba, T. Narten, "Guidelines for Writing 1075 an IANA Considerations Section in RFCs," RFC 8126, June 1076 2017. 1078 [To17ao] Touch, J., "A TCP Authentication Option Extension for 1079 Payload Encryption", draft-touch-tcp-ao-encrypt, Apr. 1080 2017. 1082 [To17cb] Touch, J., M. Welzl, S. Islam, J. You, "TCP Control Block 1083 Interdependence," draft-touch-tcpm-2140bis, Jan. 2017. 1085 [Tr15] Trammel, B. (Ed.), M. Kuelewind (Ed.), "Requirements for 1086 the design of a Substrate Protocol for User Datagrams 1087 (SPUD)," draft-trammell-spud-req-04, May 2016. 1089 16. Acknowledgments 1091 This work benefitted from feedback from Bob Briscoe, Ken Calvert, 1092 Ted Faber, Gorry Fairhurst, C. M. Heard (including the FRAG/LITE 1093 combination), Tom Herbert, and Mark Smith, as well as discussions on 1094 the IETF TSVWG and SPUD email lists. 1096 This work is partly supported by USC/ISI's Postel Center. 1098 This document was prepared using 2-Word-v2.0.template.dot. 1100 Authors' Addresses 1102 Joe Touch 1103 USC/ISI 1104 4676 Admiralty Way 1105 Marina del Rey, CA 90292 USA 1107 Phone: +1 (310) 448-9151 1108 Email: touch@isi.edu 1110 Appendix A. Implementation Information 1112 The following information is provided to encourage interoperable API 1113 implementations. 1115 System-level variables (sysctl): 1117 Name default meaning 1118 ---------------------------------------------------- 1119 net.ipv4.udp_opt 0 UDP options available 1120 net.ipv4.udp_opt_ocs 1 Default include OCS 1121 net.ipv4.udp_opt_acs 0 Default include ACS 1122 net.ipv4.udp_opt_lite 0 Default include LITE 1123 net.ipv4.udp_opt_mss 0 Default include MSS 1124 net.ipv4.udp_opt_time 0 Default include TIME 1125 net.ipv4.udp_opt_frag 0 Default include FRAG 1126 net.ipv4.udp_opt_ae 0 Default include AE 1128 Socket options (sockopt), cached for outgoing datagrams: 1130 Name meaning 1131 ---------------------------------------------------- 1132 UDP_OPT Enable UDP options (at all) 1133 UDP_OPT_OCS Enable UDP OCS option 1134 UDP_OPT_ACS Enable UDP ACS option 1135 UDP_OPT_LITE Enable UDP LITE option 1136 UDP_OPT_MSS Enable UDP MSS option 1137 UDP_OPT_TIME Enable UDP TIME option 1138 UDP_OPT_FRAG Enable UDP FRAG option 1139 UDP_OPT_AE Enable UDP AE option 1141 Send/sendto parameters: 1143 (TBD - currently using cached parameters) 1145 Connection parameters (per-socketpair cached state, part UCB): 1147 Name Initial value 1148 ---------------------------------------------------- 1149 opts_enabled net.ipv4.udp_opt 1150 ocs_enabled net.ipv4.udp_opt_ocs 1152 The following option is included for debugging purposes, and MUST 1153 NOT be enabled otherwise. 1155 System variables 1156 net.ipv4.udp_opt_junk 0 1158 System-level variables (sysctl): 1160 Name default meaning 1161 ---------------------------------------------------- 1162 net.ipv4.udp_opt_junk 0 Default use of junk 1164 Socket options (sockopt): 1166 Name params meaning 1167 ------------------------------------------------------ 1168 UDP_JUNK - Enable UDP junk option 1169 UDP_JUNK_VAL fillval Value to use as junk fill 1170 UDP_JUNK_LEN length Length of junk payload in bytes 1172 Connection parameters (per-socketpair cached state, part UCB): 1174 Name Initial value 1175 ---------------------------------------------------- 1176 junk_enabled net.ipv4.udp_opt_junk 1177 junk_value 0xABCD 1178 junk_len 4