idnits 2.17.1 draft-yevstifeyev-eudp-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 3 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 28, 2011) is 4739 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 1385 (Obsoleted by RFC 6814) -- Obsolete informational reference (is this intentional?): RFC 1475 (Obsoleted by RFC 6814) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT M. Yevstifeyev 3 Intended Status: Experimental April 28, 2011 4 Expires: October 30, 2011 6 Extendable User Datagram Protocol (EUDP) 7 draft-yevstifeyev-eudp-08 9 Abstract 11 This document is a specification of experimental Extendable User 12 Datagram Protocol (EUDP), which is based on User Datagram Protocol 13 (UDP), but allows to extend its header and, therefore, its 14 functionality with options. 16 Status of this Memo 18 This Internet-Draft is submitted to IETF in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as 24 Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/1id-abstracts.html 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html 37 Copyright and License Notice 39 Copyright (c) 2011 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Protocol Description . . . . . . . . . . . . . . . . . . . . . 3 59 2.1. Lower Layer Protocols Considerations . . . . . . . . . . . 3 60 2.2. Packet Format . . . . . . . . . . . . . . . . . . . . . . . 3 61 2.2.1. Header . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2.2.2. Fields . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2.3. EUDP Options . . . . . . . . . . . . . . . . . . . . . . . 4 64 2.3.1. Generic Description . . . . . . . . . . . . . . . . . 4 65 2.3.2. Pre-Defined Options . . . . . . . . . . . . . . . . . 5 66 2.3.2.1. 'No Operation' Option . . . . . . . . . . . . . . 5 67 2.3.2.2. 'End Of Options List' Option . . . . . . . . . . 6 68 2.3.2.3. 'Echo Request' Option . . . . . . . . . . . . . . 6 69 2.3.2.4. 'Echo Response' Option . . . . . . . . . . . . . 6 70 2.3.2.5. 'Packet Identifier' Option . . . . . . . . . . . 7 71 2.3.2.6. 'Packet Acknowledgment' Option . . . . . . . . . 7 72 2.3.2.7. 'Packet Checksum' Option . . . . . . . . . . . . 7 73 2.4. Pseudo Header . . . . . . . . . . . . . . . . . . . . . . . 8 74 2.5. Packet Delivery Acknowledgment Mechanism . . . . . . . . . 8 75 2.6. Compatibility with UDP . . . . . . . . . . . . . . . . . . 8 76 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 77 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9 78 4.1. 'EUDP Options Numbers' Registry . . . . . . . . . . . . . . 9 79 4.2. EUDP Port Numbers Assignment . . . . . . . . . . . . . . . 9 80 4.3. IP Protocol Number Assignment . . . . . . . . . . . . . . 10 81 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 82 5.1. Normative References . . . . . . . . . . . . . . . . . . 10 83 5.2. Informative References . . . . . . . . . . . . . . . . . 10 84 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 11 85 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 87 1. Introduction 89 This document is a specification of experimental Extendable User 90 Datagram Protocol (EUDP), which is based on User Datagram Protocol 91 (UDP) [RFC0768], but allows to extend its header and, therefore, its 92 functionality with options. 94 Such solution may be useful in the situations when UDP provides lack 95 of features while other transport-layer protocols, such as 96 Transmission Control Protocol (TCP) [RFC0793] or Datagram Congestion 97 Control Protocol (DCCP) [RFC4340], have excessive facilities, which 98 might not be needed in such particular case. Current transport-layer 99 protocols are not able to cope with such situations. 101 Unlike them, EUDP allows to choose what features it will provide to 102 the users via the options. Options allow to append different 103 capabilities to EUDP's core transport functionality. Therefore, it 104 may suit to almost any requirements. 106 Please note that EUDP is experimental protocol. Therefore any 107 suggestions for improvements and comments, directed to the author of 108 this document, are encouraged and welcome. 110 1.1. Terminology 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in RFC 2119 [RFC2119]. 116 2. Protocol Description 118 2.1. Lower Layer Protocols Considerations 120 EUDP is a transport-layer protocol, per RFC 1122 [RFC1122] (Layer 4 121 in Open Systems Interconnection Basic Reference Model [OSI]). It is 122 implemented on the top of Internet Protocol (IP). EUDP SHALL support 123 as IPv4 [RFC0791], as IPv6 [RFC2460] as lower-layer protocol. The IP 124 Protocol number to be used with EUDP is TBD1. 126 Moreover, EUDP SHALL be able to operate on the any protocol that 127 provides the same functionality as IP, such as EIP (Extended Internet 128 Protocol) [RFC1385] or IPv7 (also known as TP/IX) [RFC1475]. 130 2.2. Packet Format 132 2.2.1. Header 133 The EUDP header is shown below, in Figure 1. 135 0 15 16 31 136 +----------------+----------------+ 137 | Source Port |Destination Port| 138 +----------------+----------------+ 139 | Data Offset | Reserved | 140 +----------------+----------------+ 141 | | 142 : Options : 143 : | 144 | +----------------+ 145 | | Padding | 146 +=================================+ 147 | | 148 : Data : 149 | | 150 +----------------+----------------+ 152 Figure 1. EUDP Header 154 2.2.2. Fields 156 Source Port (16 bits) - REQUIRED field which is defined and is to be 157 used as described in UDP specification - RFC 768 [RFC0768]. EUDP 158 uses the same port set as UDP. 160 Destination Port (16 bits) - REQUIRED field which is defined and is 161 to be used as described in UDP specification - RFC 768 [RFC0768]. 162 EUDP uses the same port set as UDP. 164 Data Offset (16 bits) - REQUIRED field which is the number of 32 bit 165 words in the EUDP header. The EUDP header (even one including 166 options) SHALL be an integral number of 32 bits long. 168 Options (variable length) - OPIONAL field, that is used to carry EUDP 169 options in. EUDP option are described in Section 2.3. 171 Padding (variable length) - OPTIONAL field. The EUDP header padding 172 is used to ensure that the EUDP header ends and data begins on a 32 173 bit boundary. The padding MUST be composed of zeros. 175 NOTE: Bits 48-63 are reserved for future use and MUST be ignored by 176 EUDP hosts until their use will be properly specified. 178 2.3. EUDP Options 180 2.3.1. Generic Description 181 EUDP options are placed into the 'Options' header field. Options may 182 occupy space at the end of the EUDP header and are a multiple of 8 183 bits in length. An option may begin on any octet boundary. There 184 are two cases for the format of an option: 186 a) a single octet of option-kind. 188 b) an octet of option-kind, an octet of option-length, and the 189 actual option-data octets. The option-length counts the two octets 190 of option-kind and option-length as well as the option-data octets. 192 Note that the list of options MAY be shorter than the data offset 193 field might imply. The content of the header beyond the 'End Of 194 Options List' option MUST be header padding (i.e., zero). 196 All options fall into two categories: _critical_ and _elective_ . 197 These categories prescribe the host's behavior in the case when it 198 receives an unsupported option, as described below. The even numbers 199 of option-kind, including zero, (i. e. 0, 2, 4, 6...) are used to 200 identify _critical_ options whereas odd numbers of option-kind 201 identify _elective_ options. 203 If EUDP host receives the packet with unsupported _critical_ option, 204 this packet SHALL be discarded. If the unknown option is _elective_, 205 the receiver of the packet with it MAY continue its processing. 207 NOTE: While _critical_ and _elective_ categories are used to ensure 208 how the options are processed, they do not describe the support 209 criteria for them. The support of all options is OPTIONAL for EUDP 210 hosts. 212 Pre-defined options are specified in Section 2.3.2. 214 2.3.2. Pre-Defined Options 216 This section specifies pre-defined EUDP options. 218 2.3.2.1. 'No Operation' Option 220 +--------+ 221 | Kind=0 | 222 +--------+ 224 Figure 2. 'No Operation' Option 226 This option may be used between options, for example, to align the 227 beginning of a subsequent option on a word boundary. 229 The option is _critical_, per Section 2.3.1. 231 2.3.2.2. 'End Of Options List' Option 233 +--------+ 234 | Kind=2 | 235 +--------+ 237 Figure 3. 'End Of Options List' Option 239 This option code indicates the end of the options list. This might 240 not coincide with the end of the EUDP header according to the 'Data 241 Offset' header field. This option SHALL be used at the end of all 242 options, not the end of each option, and need only to be used if the 243 end of the options would not otherwise coincide with the end of the 244 EUDP header. 246 The option is _critical_, per Section 2.3.1. 248 2.3.2.3. 'Echo Request' Option 250 +--------+--------+-------//-------+ 251 | Kind=1 | Length | Data | 252 +--------+--------+-------//-------+ 254 Figure 4. 'Echo Request' Option 256 The 'Echo Request' option is used to provide the possibility of echo 257 debugging using the EUDP. The option-data octets of option MAY 258 consist of arbitrary octets. The receiver of the packet with this 259 option SHALL answer with the packet with 'Echo Response' option (see 260 Section 2.3.2.4), if it supports echo debugging via EUDP. 262 The option is _elective_, per Section 2.3.1. 264 2.3.2.4. 'Echo Response' Option 266 +--------+--------+-------//-------+ 267 | Kind=3 | Length | Data | 268 +--------+--------+-------//-------+ 270 Figure 5. 'Echo Response' Option 272 The 'Echo Response' option is put in the packets that are sent in 273 response to packets with 'Echo Request' option (see Section 2.3.2.3). 274 The packet containing 'Echo Response' option SHALL be send by the 275 EUDP host after receiving any EUDP packet with 'Echo Request' option, 276 if echo debugging via EUDP is supported by it. The option-data 277 octets of the option MUST be the same as in 'Echo Request' option in 278 the received packet. 280 The option is _elective_, per Section 2.3.1. 282 2.3.2.5. 'Packet Identifier' Option 284 +--------+--------+--------+-------+ 285 | Kind=4 |Length=4| Packet ID | 286 +--------+--------+--------+-------+ 288 Figure 6. 'Packet Identifier' Option 290 The 'Packet Identifier' option is to request the acknowledgment of 291 the single separate packet. The 'Packet ID' field is filled by 292 arbitrary bytes by the sender of the packet with this option. The 293 receiver of the packet with 'Packet Identifier' option MUST answer 294 with the packet with 'Packet Acknowledgment' option (see Section 295 2.3.2.6). See Section 2.5 for details. 297 The option is _critical_, per Section 2.3.1. 299 2.3.2.6. 'Packet Acknowledgment' Option 301 +--------+--------+--------+-------+ 302 | Kind=6 |Length=4| ACK Packet ID | 303 +--------+--------+--------+-------+ 305 Figure 7. 'Packet Acknowledgment' Option 307 The 'Packet Acknowledgment' option is used in the packets that are 308 sent in response to the packets with 'Packet Identifier' option. The 309 'ACK Packet ID' field in the option in the packet sent to the 310 originating host for packet with 'Packet Identifier' option MUST be 311 the same as in the 'Packet Identifier' option-data octets in received 312 from this host packet. See Section 2.5 for details. 314 The option is _critical_, per Section 2.3.1. 316 2.3.2.7. 'Packet Checksum' Option 318 +--------+--------+--------+-------+ 319 | Kind=5 |Length=4| Checksum | 320 +--------+--------+--------+-------+ 322 Figure 8. 'Packet Checksum' Option 324 The 'Packet Checksum' option is used to carry packet checksum, 325 calculated using the method described in RFC 768 [RFC0768]. Packets 326 containing this option with bad checksum SHOULD be discarded by EUDP 327 host, if this option is supported by it. 329 The option is _elective_, per Section 2.3.1. 331 2.4. Pseudo Header 333 EUDP does not use pseudo header. 335 2.5. Packet Delivery Acknowledgment Mechanism 337 EUDP provides the possibility to request the acknowledgment of the 338 single EUDP packet. This is provided by 'Packet Identifier' and 339 'Packet Acknowledgment' options (see Section 2.3.2.5 and Section 340 2.3.2.6, respectively). In the simplest form, the delivery 341 acknowledgment mechanism works as below. 343 If EUDP host (let it be A) wants to request the acknowledgment of 344 delivery of some packet, it puts the 'Packet Identifier' option in it 345 and sends this packet to another EUDP host (let it be B). Once B 346 receives the A's packet, it checks the 'Packet Identifier' option to 347 find out the packet identifier. After it finds it out, this number 348 becomes the 'ACK Packet Identifier', that is put into 'Packet 349 Acknowledgment' option, which is put into the EUDP packet, and sent 350 to A. The packet identifiers MAY be reused once they are 351 acknowledged, since EUDP does provides stateless connection. 353 Compared with acknowledgment mechanism of TCP [RFC0793], EUDP 354 provides simpler and more liberal system. While TCP makes using the 355 packet sequence numbers and acknowledgement mandatory, EUDP allows 356 the host to decide whether the packet needs to be acknowledged by the 357 other side or not. 359 2.6. Compatibility with UDP 361 The applications which use UDP can safely use EUDP with no options 362 instead. 364 3. Security Considerations 366 UDP is inheritedly insecure. It provides neither reliable packet 367 delivery nor authentication features. EUDP without any options does 368 not cover these issues as well. However, the 'Packet Identifier' and 369 'Packet Acknowledgment' options (see Section 2.3.2.5 and Section 370 2.3.2.6, respectively) introduce the packet delivery acknowledgment 371 mechanism, defined in Section 2.5. Further options may add more 372 security features, such as e. g. congestion control, to EUDP. These 373 options are not defined in this document. 375 4. IANA Considerations 377 4.1. 'EUDP Options Numbers' Registry 379 IANA is asked to create and maintain the registry named 'EUDP Options 380 Numbers Registry' following the guidelines below. 382 The registry consists of 4 values: Option Kind, Option Length, Name 383 and Reference. They are described below. 385 Option Kind - an integer; refers to the value used in EUDP options. 386 Values from 0 to 255 are assigned. 388 Option Length - an integer, 'variable' (for multi-octet options) or 389 'N/A' (for one-octet options). 391 Name - contains the name of the option. 393 Reference - the reference to the document, that defines the option. 395 The initial values are given in Table 1; new assignments are to be 396 made following the 'RFC Required' policies. [RFC5226] 398 +-------+-------+------------------------------+-----------+ 399 | Kind | Length| Name | Reference | 400 +-------+-------+------------------------------+-----------+ 401 | 0 | N/A | No Operation | RFC xxxx | 402 | 1 | var. | Echo Request | RFC xxxx | 403 | 2 | N/A | End Of Options List | RFC xxxx | 404 | 3 | var. | Echo Response | RFC xxxx | 405 | 4 | 4 | Packet Identifier | RFC xxxx | 406 | 5 | 4 | Packet Checksum | RFC xxxx | 407 | 6 | 4 | Packet Acknowledgment | RFC xxxx | 408 | 7-252 | -- | Unassigned | RFC xxxx | 409 | 253 | -- | Used for Experimentation | RFC xxxx | 410 | 254 | -- | Used for Experimentation | RFC xxxx | 411 | 255 | -- | Reserved | RFC xxxx | 412 +-------+-------+------------------------------+-----------+ 413 [RFC Editor: Please replace xxxx with assigned RFC number] 415 Table 1. Initial contents of the registry 417 4.2. EUDP Port Numbers Assignment 418 As EUDP uses the same port set as UDP, IANA is asked to mark the UDP 419 port numbers registry values may be used with EUDP as well. 421 4.3. IP Protocol Number Assignment 423 IANA has assigned the IP protocol number TBD1 to be used with EUDP. 425 5. References 427 5.1. Normative References 429 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 430 August 1980. 432 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 433 September 1981. 435 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 436 Requirement Levels", BCP 14, RFC 2119, March 1997. 438 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 439 (IPv6) Specification", RFC 2460, December 1998. 441 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 442 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 443 May 2008. 445 5.2. Informative References 447 [OSI] International Organization for Standardization (ISO), 448 "Information technology - Open Systems Interconnection - 449 Basic Reference Model: The Basic Model," ISO/IEC Standard 450 7498-1:1994, November 1994. 452 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 453 RFC 793, September 1981. 455 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 456 Communication Layers", STD 3, RFC 1122, October 1989. 458 [RFC1385] Wang, Z., "EIP: The Extended Internet Protocol", 459 RFC 1385, November 1992. 461 [RFC1475] Ullmann, R., "TP/IX: The Next Internet", RFC 1475, June 462 1993. 464 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 465 Congestion Control Protocol (DCCP)", RFC 4340, March 466 2006. 468 Appendix A. Acknowledgments 470 The portions of RFC 793 [RFC0793], whose author - Jon Postel - is 471 acknowledged, are adopted in this document for describing options. 473 Author's Addresses 475 Mykyta Yevstifeyev 476 8 Kuzovkov St., flat 25 477 Kotovsk 478 Ukraine 480 EMail: evnikita2@gmail.com