idnits 2.17.1 draft-touch-tsvwg-udp-options-03.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 (June 28, 2016) is 2858 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) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 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 June 28, 2016 4 Expires: December 2016 6 Transport Options for UDP 7 draft-touch-tsvwg-udp-options-03.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 December 28, 2016. 34 Copyright Notice 36 Copyright (c) 2016 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. Whose options are these?.......................................8 59 6. UDP options vs. UDP-Lite.......................................8 60 7. Interactions with Legacy Devices...............................9 61 8. Options in a Stateless, Unreliable Transport Protocol.........10 62 9. Security Considerations.......................................10 63 10. IANA Considerations..........................................11 64 11. References...................................................11 65 11.1. Normative References....................................11 66 11.2. Informative References..................................11 67 12. Acknowledgments..............................................12 69 1. Introduction 71 Transport protocols use options as a way to extend their 72 capabilities. TCP [RFC793], SCTP [RFC4960], and DCCP [RFC4340] 73 include space for these options but UDP [RFC768] currently does not. 74 This document defines an experimental extension to UDP that provides 75 space for transport options including their generic syntax and 76 semantics for their use in UDP's stateless, unreliable message 77 protocol. 79 2. Conventions used in this document 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 83 document are to be interpreted as described in RFC 2119 [RFC2119]. 85 In this document, these words will appear with that interpretation 86 only when in ALL CAPS. Lowercase uses of these words are not to be 87 interpreted as carrying significance described in RFC 2119. 89 In this document, the characters ">>" preceding an indented line(s) 90 indicates a statement using the key words listed above. This 91 convention aids reviewers in quickly identifying or finding the 92 portions of this RFC covered by these key words. 94 3. Background 96 Many protocols include a default header and an area for header 97 options. These options enable the protocol to be extended for use in 98 particular environments or in ways unforeseen by the original 99 designers. Examples include TCP's Maximum Segment Size, Window 100 Scale, Timestamp, and Authentication Options 101 [RFC793][RFC5925][RFC7323]. 103 These options are used both in stateful (connection-oriented, e.g., 104 TCP [RFC793], SCTP [RFC4960], DCCP [RFC4340]) and stateless 105 (connectionless, e.g., IPv4 [RFC791], IPv6 [RFC2460] protocols. In 106 stateful protocols they can help extend the way in which state is 107 managed. In stateless protocols their effect is often limited to 108 individual packets, but they can have an aggregate effect on a 109 sequence as well. One example of such uses is Substrate Protocol for 110 User Datagrams (SPUD) [Tr15], and this document is intended to 111 provide an out-of-band option area as an alternative to the in-band 112 mechanism currently proposed [Hi15]. 114 UDP is one of the most popular protocols that lacks space for 115 options [RFC768]. The UDP header was intended to be a minimal 116 addition to IP, providing only ports and a data checksum for 117 protection. This document experimentally extends UDP to provide a 118 trailer area for options located after the UDP data payload. 120 4. The UDP Option Area 122 The UDP transport header includes demultiplexing and service 123 identification (port numbers), a checksum, and a field that 124 indicates the UDP datagram length (including UDP header). The UDP 125 Length length field is typically redundant with the size of the 126 maximum space available as a transport protocol payload (see also 127 discussion in Section 7). 129 For IPv4, IP Total Length field indicates the total IP datagram 130 length (including IP header), and the size of the IP options is 131 indicated in the IP header (in 4-byte words) as the "Internet Header 132 Length" (IHL), as shown in Figure 1 [RFC791]. As a result, the 133 typical (and largest valid) value for UDP Length is: 135 UDP_Length = IPv4_Total_Length - IPv4_IHL * 4 137 For IPv6, the IP Payload Length field indicates the datagram after 138 the base IPv6 header, which includes the IPv6 extension headers and 139 space available for the transport protocol, as shown in Figure 2 140 [RFC2460]. Note that the Next HDR field in IPv6 might not indicate 141 UDP (i.e., 17), e.g., when intervening IP extension headers are 142 present. For IPv6, the lengths of any additional IP extensions are 143 indicated within each extension [RFC2460], so the typical (and 144 largest valid) value for UDP Length is: 146 UDP_Length = IPv6_Payload_Length - sum(extension header lengths) 148 In both cases, the space available for the UDP transport protocol 149 data unit is indicated by IP, either completely in the base header 150 (for IPv4) or adding information in the extensions (for IPv6). In 151 either case, this document will refer to this available space as the 152 "IP transport payload". 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 |Version| IHL |Type of Service| Total Length | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | Identification |Flags| Fragment Offset | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 | Time to Live | Proto=17 (UDP)| Header Checksum | 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | Source Address | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | Destination Address | 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 ... zero or more IP Options (using space as indicated by IHL) ... 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 | UDP Source Port | UDP Destination Port | 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | UDP Length | UDP Checksum | 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 Figure 1 IPv4 datagram with UDP transport payload 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 |Version| Traffic Class | Flow Label | 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 | Payload Length | Next Hdr | Hop Limit | 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 ... 180 | Source Address (128 bits) | 181 ... 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 ... 184 | Destination Address (128 bits) | 185 ... 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 ... zero or more IP Extension headers (each indicating size) ... 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | UDP Source Port | UDP Destination Port | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | UDP Length | UDP Checksum | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 Figure 2 IPv6 datagram with UDP transport payload 196 As a result of this redundancy, there is an opportunity to use the 197 UDP Length field as a way to break up the IP transport payload into 198 two areas - that intended as UDP user data and an additional 199 "surplus area" (as shown in Figure 3). 201 IP transport payload 202 <-------------------------------------------------> 203 +--------+---------+----------------------+------------------+ 204 | IP Hdr | UDP Hdr | UDP user data | surplus area | 205 +--------+---------+----------------------+------------------+ 206 <------------------------------> 207 UDP Length 209 Figure 3 IP transport payload vs. UDP Length 211 In most cases, the IP transport payload and UDP Length point to the 212 same location, indicating that there is no surplus area. It is 213 important to note that this is not a requirement of UDP [RFC768] 214 (discussed further in Section 7). UDP-Lite used the difference in 215 these pointers to indicate the partial coverage of the UDP Checksum, 216 such that the UDP user data, UDP header, and UDP pseudoheader (a 217 subset of the IP header) are covered by the UDP checksum but 218 additional user data in the surplus area is not covered [RFC3828]. 219 This document uses the surplus area for UDP transport options. 221 The UDP option area is thus defined as the location between the end 222 of the UDP payload and the end of the IP datagram as a trailing 223 options area. This area can occur at any valid byte offset, i.e., it 224 need not be 16-bit or 32-bit aligned. In effect, this document 225 redefines the UDP "Length" field as a "trailer offset". 227 UDP options are defined using a syntax similar to that of TCP 228 [RFC793]. They are typically a minimum of two bytes in length as 229 shown in Figure 4, excepting only the one byte options "No 230 Operation" (NOP) and "End of Options List" (EOL) described below. 232 +--------+--------+ 233 | Kind | Length | 234 +--------+--------+ 236 Figure 4 UDP option default format 238 >> UDP options MAY occur at any UDP length offset. 240 >> The UDP length MUST be at least as large as the UDP header (8) 241 and no larger than the IP transport payload. Values outside this 242 range MUST be silently discarded as invalid and logged where rate- 243 limiting permits. 245 Others have considered using values of the UDP Length that is larger 246 than the IP transport payload as an additional type of signal. Using 247 a value smaller than the IP transport payload is expected to be 248 backward compatible with existing UDP implementations, i.e., to 249 deliver the UDP Length of user data to the application and silently 250 ignore the additional surplus area data. Using a value larger than 251 the IP transport payload would either be considered malformed (and 252 be silently dropped) or could cause buffer overruns, and so is not 253 considered silently and safely backward compatible. Its use is thus 254 out of scope for the extension described in this document. 256 >> UDP options MUST be interpreted in the order in which they occur 257 in the UDP option area. 259 The following UDP options are currently defined: 261 Kind Length Meaning 262 ---------------------------------------------- 263 0 - End of Options List (EOL) 264 1 - No operation (NOP) 265 2 2 Option checksum (OCS) 266 128-253 RESERVED 267 254 N(>=4) RFC 3692-style experiments 268 255 RESERVED 270 >> If options longer than one byte are used, NOP options SHOULD be 271 used at the beginning of the UDP options area to achieve alignment 272 as would be more efficient for active (i.e., non-NOP) options. 274 The option checksum (OCS, Kind = 2) is an 8-bit ones-complement sum 275 that covers only the options, from the first option as indicated by 276 the UDP Length to the last option as indicated by EOL (where 277 present) or the IP Payload Length. OCS can be calculated by 278 computing the 16-bit ones-complement sum and "folding over" the 279 result (using carry wraparound). Note that OCS is direct, i.e., it 280 is not negated or adjusted if zero (unlike the Internet checksum as 281 used in IPv4, TCP, and UDP headers). OCS protects the option area 282 from errors in a similar way that the UDP checksum protects the UDP 283 user data. 285 >> When present, the option checksum SHOULD occur as early as 286 possible, preferably preceded by only NOP options for alignment. 288 >> If the option checksum fails, all options MUST be ignored and any 289 trailing surplus data silently discarded. 291 >> UDP data that is validated by a correct UDP checksum MUST be 292 delivered to the application layer, even if the UDP option checksum 293 fails, unless the endpoints have negotiated otherwise for this 294 segment's socket pair. 296 >> When the UDP options do not consume the entire option area, the 297 last non-NOP option SHOULD be EOL (vs. filling the entire option 298 area with NOP values). 300 >> All bytes after EOL MUST be ignored by UDP option processing. 301 Those bytes MAY be passed to the application layer if negotiated 302 otherwise in advance; such negotiation can be used as a way to 303 include user data that is not protected by a checksum. If this 304 unprotected data is provided to the user, it MUST be provided 305 distinct from the UDP user data. 307 Kind=254 is reserved for experiments [RFC3692]. Only one such value 308 is reserved because experiments are expected to use an Experimental 309 ID (ExIDs) to differentiate concurrent use for different purposes, 310 using UDP ExIDs registered with IANA according to the approach 311 developed for TCP experimental options [RFC6994]. 313 >> The length of the experimental option MUST be at least 4 to 314 account for the Kind, Length, and the minimum 16-bit UDP ExID 315 identifier (similar to TCP ExIDs [RFC6994]). 317 5. Whose options are these? 319 UDP options are indicated in an area of the IP payload that is not 320 used by UDP. That area is really part of the IP payload, not the UDP 321 payload, and as such, it might be tempting to consider whether this 322 is a generally useful approach to extending IP. 324 Unfortunately, the surplus area exists only for transports that 325 include their own transport layer payload length indicator. TCP and 326 SCTP include header length fields that already provide space for 327 transport options by indicating the total length of the header area, 328 such that the entire remaining area indicated in the network layer 329 (IP) is transport payload. UDP-Lite already uses the UDP Length 330 field to indicate the boundary between data covered by the transport 331 checksum and data not covered, and so there is no remaining area 332 where the length of the UDP-Lite payload as a whole can be indicated 333 [RFC3828]. 335 >> UDP options are intended for use only by the transport endpoints. 336 They are no more (or less) appropriate to be modified in-transit 337 than any other portion of the transport datagram. 339 UDP options are are transport options. Generally, transport 340 datagrams are not intended to be modified in-transit. However, the 341 UDP option mechanism provides no specific protection against in- 342 transit modification of the UDP header, UDP payload, or UDP option 343 area. 345 6. UDP options vs. UDP-Lite 347 UDP-Lite provides partial checksum coverage, so that packets with 348 errors in some locations can be delivered to the user [RFC3828]. It 349 uses a different transport protocol number (136) than UDP (17) to 350 interpret the UDP Length field as the prefix covered by the UDP 351 checksum. 353 UDP (protocol 17) already defines the UDP Length field as the limit 354 of the UDP checksum, but by default also limits the data provided to 355 the application as that which precedes the UDP Length. A goal of 356 UDP-Lite is to deliver data beyond UDP Length as a default, which is 357 why a separate transport protocol number was required. 359 UDP options do not need a separate transport protocol number because 360 the data beyond the UDP Length offset (surplus data) is not provided 361 to the application by default. That data is interpreted exclusively 362 within the UDP transport layer. 364 UDP options support a similar service to UDP-Lite by terminating the 365 UDP options with an EOL option. The additional data not covered by 366 the UDP checksum follows that EOL option, and is passed to the user 367 separately. The difference is that UDP-Lite provides the un- 368 checksummed user data to the application by default, whereas UDP 369 options can provide the same capability only for endpoints that are 370 negotiated in advance (i.e., by default, UDP options would silently 371 discard this non-checksummed data). Additionally, in UDP-Lite the 372 checksummed and non-checksummed payload components are adjacent, 373 whereas in UDP options they are separated by the option area - 374 which, minimally, must consist of at least one EOL option. 376 UDP-Lite cannot support UDP options, either as proposed here or in 377 any other form, because the entire payload of the UDP packet is 378 already defined as user data and there is no additional field in 379 which to indicate a separate area for options. The UDP Length field 380 in UDP-Lite is already used to indicate the boundary between user 381 data covered by the checksum and user data not covered. 383 7. Interactions with Legacy Devices 385 It has always been permissible for the UDP Length to be inconsistent 386 with the IP transport payload length [RFC768]. Such inconsistency 387 has been utilized in UDP-Lite using a different transport number. 388 There are no known systems that use this inconsistency for UDP 389 [RFC3828]. It is possible that such use might interact with UDP 390 options, i.e., where legacy systems might generate UDP datagrams 391 that appear to have UDP options. The UDP OCS provides protection 392 against such events and is stronger than a static "magic number". 394 UDP options have been tested as interoperable with Linux, Max OS-X, 395 and Windows Cygwin, and worked through NAT devices. These systems 396 successfully delivered only the user data indicated by the UDP 397 Length field and silently discarded the surplus area. 399 There was one embedded device reported that passed the entire IP 400 transport payload to the user UDP socket. This is already 401 inconsistent with UDP and host requirements [RFC768] [RFC1122], as 402 it presents the entire IP transport payload to the user (including 403 the transport header) instead of presenting the transport payload to 404 the corresponding to the transport protocol, where the transport 405 header would have been removed. 407 It has been reported that Alcatel-Lucent's "Brick" Intrusion 408 Detection System has a default configuration that interprets 409 inconsistencies between UDP Length and IP Length as an attack to be 410 reported. Note that other firewall systems, e.g., CheckPoint, use a 411 default "relaxed UDP length verification" to avoid falsely 412 interpreting this inconsistency as an attack. 414 (TBD: test with UDP checksum offload and UDP fragmentation offload) 416 8. Options in a Stateless, Unreliable Transport Protocol 418 There are two ways to interpret options for a stateless, unreliable 419 protocol -- an option is either local to the message or intended to 420 affect a stream of messages in a soft-state manner. Either 421 interpretation is valid for defined UDP options. 423 It is impossible to know in advance whether an endpoint supports a 424 UDP option. 426 >> UDP options MUST allow for silent failure on first receipt. 428 >> UDP options that rely on soft-state exchange MUST allow for 429 message reordering and loss. 431 >> A UDP option MUST be silently optional until confirmed by 432 exchange with an endpoint. 434 It is useful that the above requirements prevent using UDP options 435 to implement transport-layer fragmentation and reassembly unless 436 that capability has been negotiated with an endpoint in advance for 437 a socket pair. Legacy systems would need to be able to interpret the 438 transport payload fragments as individual transport datagrams. 440 9. Security Considerations 442 The use of UDP packets with inconsistent IP and UDP Length fields 443 has the potential to trigger a buffer overflow error if not properly 444 handled, e.g., if space is allocated based on the smaller field and 445 copying is based on the larger. However, there have been no reports 446 of such a vulnerability and it would rely on inconsistent use of the 447 two fields for memory allocation and copying. 449 10. IANA Considerations 451 Upon publication, IANA is hereby requested to create a new registry 452 for UDP Option Kind numbers, similar to that for TCP Option Kinds. 453 Initial values of this registry are as indicated herein. Additional 454 values in this registry are to be assigned by IESG Approval or 455 Standards Action [RFC5226]. 457 Upon publication, IANA is hereby requested to create a new registry 458 for UDP Experimental Option Experiment Identifiers (UDP ExIDs) for 459 use in a similar manner as TCP ExIDs [RFC6994]. Values in this 460 registry are to be assigned by IANA using first-come, first-served 461 (FCFS) rules [RFC5226]. 463 11. References 465 11.1. Normative References 467 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 468 Requirement Levels", BCP 14, RFC 2119, March 1997. 470 11.2. Informative References 472 [Hi15] Hildebrand, J., B. Trammel, "Substrate Protocol for User 473 Datagrams (SPUD) Prototype," draft-hildebrand-spud- 474 prototype-03, Mar. 2015. 476 [RFC768] Postel, J., "User Datagram Protocol", RFC 768, August 477 1980. 479 [RFC791] Postel, J., "Internet Protocol," RFC 791, Sept. 1981. 481 [RFC793] Postel, J., "Transmission Control Protocol" RFC 793, 482 September 1981. 484 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -- 485 Communication Layers," RFC 1122, Oct. 1989. 487 [RFC2460] Deering, S., R. Hinden, "Internet Protocol Version 6 488 (IPv6) Specification," RFC 2460, Dec. 1998. 490 [RFC4340] Kohler, E., M. Handley, and S. Floyd, "Datagram Congestion 491 Control Protocol (DCCP)", RFC 4340, March 2006. 493 [RFC4960] Stewart, R. (Ed.), "Stream Control Transmission Protocol", 494 RFC 4960, September 2007. 496 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers 497 Considered Useful," RFC 3692, Jan. 2004. 499 [RFC3828] Larzon, L-A., M. Degermark, S. Pink, L-E. Jonsson (Ed.), 500 G. Fairhurst (Ed.), "The Lightweight User Datagram 501 Protocol (UDP-Lite)," RFC 3828, July 2004. 503 [RFC5226] Narten, T., H. Alvestrand, "Guidelines for Writing an IANA 504 Considerations Section in RFCs," RFC 5226, May 2008. 506 [RFC5925] Touch, J., A. Mankin, R. Bonica, "The TCP Authentication 507 Option," RFC 5925, June 2010. 509 [RFC6994] Touch, J., "Shared Use of Experimental TCP Options," RFC 510 6994, Aug. 2013. 512 [RFC7323] Borman, D., R. Braden, V. Jacobson, R. Scheffenegger 513 (Ed.), "TCP Extensions for High Performance," RFC 7323, 514 Sep. 2014. 516 [Tr15] Trammel, B. (Ed.), M. Kuelewind (Ed.), "Requirements for 517 the design of a Substrate Protocol for User Datagrams 518 (SPUD)," draft-trammell-spud-req-04, May 2016. 520 12. Acknowledgments 522 This work benefitted from feedback from Bob Briscoe, Ken Calvert, 523 Ted Faber, Gorry Fairhurst, C. M. Heard, Tom Herbert, as well as 524 discussions on the IETF SPUD email list. 526 This document was prepared using 2-Word-v2.0.template.dot. 528 Authors' Addresses 530 Joe Touch 531 USC/ISI 532 4676 Admiralty Way 533 Marina del Rey, CA 90292 USA 535 Phone: +1 (310) 448-9151 536 Email: touch@isi.edu