idnits 2.17.1 draft-touch-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 (28 Dec 2009) Section 6.c(ii) Publication Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. 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 -- The document date (July 21, 2015) is 3200 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- 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 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-04) exists of draft-trammell-spud-req-00 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TSGWG J. Touch 2 Internet Draft USC/ISI 3 Intended status: Experimental July 21, 2015 4 Expires: January 2016 6 Transport Options for UDP 7 draft-touch-tsvwg-udp-options-01.txt 9 Status of this Memo 11 This Internet-Draft is submitted in full conformance with the 12 provisions of BCP 78 and BCP 79. This document may not be modified, 13 and derivative works of it may not be created, and it may not be 14 published except as an Internet-Draft. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any time. It is inappropriate to use Internet-Drafts as 24 reference material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 This Internet-Draft will expire on January 21, 2016. 34 Copyright Notice 36 Copyright (c) 2015 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with 44 respect to this document. 46 Abstract 48 Transport protocols are extended through the use of transport header 49 options. This document experimentally extends UDP to provide a 50 location, syntax, and semantics for transport layer options. 52 Table of Contents 54 1. Introduction...................................................2 55 2. Conventions used in this document..............................2 56 3. Background.....................................................3 57 4. The UDP Option Area............................................3 58 5. UDP options vs. UDP-Lite.......................................5 59 6. Options in a Stateless, Unreliable Transport Protocol..........5 60 7. Security Considerations........................................6 61 8. IANA Considerations............................................6 62 9. References.....................................................6 63 9.1. Normative References......................................6 64 9.2. Informative References....................................6 65 10. Acknowledgments...............................................7 67 1. Introduction 69 Transport protocols use options as a way to extend their 70 capabilities. TCP [RFC793], SCTP [RFC4960], and DCCP [RFC4340] 71 include space for these options but UDP [RFC768] currently does not. 72 This document defines an experimental extension to UDP that provides 73 space for transport options including their generic syntax and 74 semantics for their use in UDP's stateless, unreliable message 75 protocol. 77 2. Conventions used in this document 79 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 80 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 81 document are to be interpreted as described in RFC 2119 [RFC2119]. 83 In this document, these words will appear with that interpretation 84 only when in ALL CAPS. Lowercase uses of these words are not to be 85 interpreted as carrying significance described in RFC 2119. 87 In this document, the characters ">>" preceding an indented line(s) 88 indicates a statement using the key words listed above. This 89 convention aids reviewers in quickly identifying or finding the 90 portions of this RFC covered by these key words. 92 3. Background 94 Many protocols include a default header and an area for header 95 options. These options enable the protocol to be extended for use in 96 particular environments or in ways unforeseen by the original 97 designers. Examples include TCP's Maximum Segment Size, Window 98 Scale, Timestamp, and Authentication Options 99 [RFC793][RFC5925][RFC7323]. 101 These options are used both in stateful (connection-oriented, e.g., 102 TCP [RFC793], SCTP [RFC4960], DCCP [RFC4340]) and stateless 103 (connectionless, e.g., IPv4 [RFC791], IPv6 [RFC2460] protocols. In 104 stateful protocols they can help extend the way in which state is 105 managed. In stateless protocols their effect is often limited to 106 individual packets, but they can have an aggregate effect on a 107 sequence as well. One example of such uses is Substrate Protocol for 108 User Datagrams (SPUD) [Tr15], and this document is intended to 109 provide an out-of-band option area as an alternative to the in-band 110 mechanism currently proposed [Hi15]. 112 UDP is one of the most popular protocols that lacks space for 113 options [RFC768]. The UDP header was intended to be a minimal 114 addition to IP, providing only ports and a data checksum for 115 protection. This document experimentally extends UDP to provide a 116 trailer area for options located after the UDP data payload. 118 4. The UDP Option Area 120 The UDP transport header includes demultiplexing and service 121 identification (port numbers), a checksum, and a field that 122 indicates the payload length. This length field is typically 123 redundant with total IP datagram length and header length. 125 For IPv4, the total datagram length (including IP header) is the 126 "Total Length" field and the header and its options are 4*IHL 127 ("Internet Header Length") [RFC791]. For IPv6, the last IP option 128 with "Next Header" = UDP (i.e., 17) indicates the size of the 129 transport payload as its "Payload Length" directly [RFC2460]. In 130 both cases, the space available for the UDP transport protocol data 131 unit is indicated by IP 133 As a result of this redundancy, the UDP length field can be used in 134 other ways. UDP-Lite uses this field to indicate UDP checksum 135 coverage. This document uses this field to create a place for UDP 136 transport options. 138 The UDP option area is defined as the location between the end of 139 the UDP payload (as indicated by UDP length) and the end of the IP 140 datagram (as indicated by the IP length and IP header length), i.e., 141 as a trailing options area. This area can occur at any valid byte 142 offset, i.e., it need not be 16-bit or 32-bit aligned. In effect, 143 this document redefines the UDP "Length" field as a "trailer 144 offset". 146 UDP options are defined using a syntax similar to that of TCP 147 [RFC793]. They are typically a minimum of two bytes in length as 148 shown in Figure 1, excepting only the one byte options "No 149 Operation" (NOP) and "End of Options List" (EOL) described below. 151 +--------+--------+ 152 | Kind | Length | 153 +--------+--------+ 155 Figure 1 UDP option default format 157 >> UDP options MAY occur at any UDP length offset. 159 >> The UDP length MUST be at least as large as the UDP header (8) 160 and no larger than the payload of the IP datagram (IPlen - 161 IPhdrlen). Values outside this range MUST be silently discarded as 162 invalid and logged where rate-limiting permits. 164 >> UDP options MUST be interpreted in the order in which they occur 165 in the UDP option area. 167 The following UDP options are currently defined: 169 Kind Length Meaning 170 ---------------------------------------------- 171 0 - End of Options List 172 1 - No operation 173 128-253 RESERVED 174 254 N(>=4) RFC 3692-style experiments 175 255 RESERVED 177 >> NOP options SHOULD be used at the beginning of the UDP options 178 area to achieve 32-bit alignment for active (i.e., non-NOP) options. 180 >> When the UDP options do not consume the entire option area, the 181 last non-NOP option SHOULD be EOL. 183 >> All bytes after EOL MUST be ignored by UDP option processing. 185 Note that Kind=254 is reserved for experiments [RFC3692]. Only one 186 such value is reserved because it experiments are expected to 187 already apply the shared use approach developed for TCP experimental 188 options [RFC6994]. 190 >> The length of the experimental option MUST be at least 4 to 191 account for the Kind, Length, and the minimum 16-bit UDP ExID 192 identifier (similar to TCP ExIDs [RFC6994]). 194 5. UDP options vs. UDP-Lite 196 UDP Lite provides partial checksum coverage, so that packets with 197 errors in some locations can be delivered to the user [RFC3828]. It 198 uses a different transport protocol number (136) than UDP (17) to 199 interpret the UDP length field as the prefix covered by the UDP 200 checksum. 202 UDP already defines the UDP length field as the limit of the UDP 203 checksum but that would also limit the data provided to the user 204 (application). A goal of UDP-Lite is to deliver data beyond that 205 length offset, which is why a separate transport protocol number was 206 required. 208 UDP options do not need a separate transport protocol number because 209 the data beyond the UDP length offset is never provided to the user. 210 It is interpreted exclusively within the UDP transport layer. 212 6. Options in a Stateless, Unreliable Transport Protocol 214 There are two ways to interpret options for a stateless, unreliable 215 protocol -- an option is either local to the message or intended to 216 affect a stream of messages in a soft-state manner. Either 217 interpretation is valid for defined UDP options. 219 It is impossible to know in advance whether an endpoint supports a 220 UDP option. 222 >> Options MUST allow for silent failure on first receipt. 224 >> Options that rely on soft-state exchange MUST allow for message 225 reordering and loss. 227 >> A UDP option MUST be silently optional until confirmed by 228 exchange with an endpoint. 230 (I'm sure there will be more here) 232 7. Security Considerations 234 (to be addressed) 236 8. IANA Considerations 238 Upon publication, IANA is hereby requested to create a new registry 239 for UDP Option Kind numbers, similar to that for TCP Option Kinds. 240 Values in this registry are to be assigned by IESG Approval or 241 Standards Action [RFC5226]. 243 Upon publication, IANA is hereby requested to create a new registry 244 for UDP Experimental Option Experiment Identifiers (UDP ExIDs) for 245 use in the same manner as [RFC6994]. Values in this registry are to 246 be assigned using first-come, first-served (FCFS) rules [RFC5226]. 248 9. References 250 9.1. Normative References 252 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 253 Requirement Levels", BCP 14, RFC 2119, March 1997. 255 9.2. Informative References 257 [Hi15] Hildebrand, J., B. Trammel, "Substrate Protocol for User 258 Datagrams (SPUD) Prototype," draft-hildebrand-spud- 259 prototype-03, Mar. 2015. 261 [RFC768] Postel, J., "User Datagram Protocol", RFC 768, August 262 1980. 264 [RFC791] Postel, J., "Internet Protocol," RFC 791, Sept. 1981. 266 [RFC793] Postel, J., "Transmission Control Protocol" RFC 793, 267 September 1981 269 [RFC2460] Deering, S., R. Hinden, "Internet Protocol Version 6 270 (IPv6) Specification," RFC 2460, Dec. 1998. 272 [RFC4340] Kohler, E., M. Handley, and S. Floyd, "Datagram Congestion 273 Control Protocol (DCCP)", RFC 4340, March 2006. 275 [RFC4960] Stewart, R. (Ed.), "Stream Control Transmission Protocol", 276 RFC 4960, September 2007. 278 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers 279 Considered Useful," RFC 3692, Jan. 2004. 281 [RFC3828] Larzon, L-A., M. Degermark, S. Pink, L-E. Jonsson (Ed.), 282 G. Fairhurst (Ed.), "The Lightweight User Datagram 283 Protocol (UDP-Lite)," RFC 3828, July 2004. 285 [RFC5226] Narten, T., H. Alvestrand, "Guidelines for Writing an IANA 286 Considerations Section in RFCs," RFC 5226, May 2008. 288 [RFC5925] Touch, J., A. Mankin, R. Bonica, "The TCP Authentication 289 Option," RFC 5925, June 2010. 291 [RFC6994] Touch, J., "Shared Use of Experimental TCP Options," RFC 292 6994, Aug. 2013. 294 [RFC7323] Borman, D., R. Braden, V. Jacobson, R. Scheffenegger 295 (Ed.), "TCP Extensions for High Performance," RFC 7323, 296 Sep. 2014. 298 [Tr15] Trammel, B. (Ed.), M. Kuelewind (Ed.), "Requirements for 299 the design of a Substrate Protocol for User Datagrams 300 (SPUD)," draft-trammell-spud-req-00, July 2015. 302 10. Acknowledgments 304 This work benefitted from feedback from Ken Calvert, Ted Faber, and 305 Gorry Fairhurst, as well as discussions on the IETF SPUD email list. 307 This document was prepared using 2-Word-v2.0.template.dot. 309 Authors' Addresses 311 Joe Touch 312 USC/ISI 313 4676 Admiralty Way 314 Marina del Rey, CA 90292 USA 316 Phone: +1 (310) 448-9151 317 Email: touch@isi.edu