INTERNET-DRAFT M. Yevstifeyev Intended Status: Experimental January 25, 2011 Expires: July 29, 2011 Extendable User Datagram Protocol Abstract This document introduces the experimental extension to User Datagram Protocol (UDP) - Extendable User Datagram Protocol (EUDP) - that allows to extend its header (and, therefore, functionality) by options. Such solution lets the client to choose what features will be provided and what will not, and, therefore, is more liberal than, for instance, Transmission Control Protocol (TCP) or Datagram Congestion Control Protocol (DCCP), that make use of many functions mandatory, but may be more complicated than UDP, since may provide other needed functions, except only core transport features. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright and License Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. Yevstifeyev Expires July 29, 2011 [Page 1] INTERNET DRAFT EUDP January 25, 2011 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Model of Work . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Extension Specification . . . . . . . . . . . . . . . . . . . . 5 3.1. Sub-Header . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1.1. Sub-Header Format . . . . . . . . . . . . . . . . . . 5 3.1.2. Fields . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. EUDP Options . . . . . . . . . . . . . . . . . . . . . . . 6 3.2.1. Generic Description . . . . . . . . . . . . . . . . . 6 3.2.2. Pre-Defined Options . . . . . . . . . . . . . . . . . 7 3.2.2.1. 'No Operation' Option . . . . . . . . . . . . . . 7 3.2.2.2. 'End Of Options List' Option . . . . . . . . . . 7 3.2.2.3. 'Echo Request' Option . . . . . . . . . . . . . . 7 3.2.2.4. 'Echo Response' Option . . . . . . . . . . . . . 7 3.2.2.5. 'Packet Identifier' Option . . . . . . . . . . . 8 2.3.2.6. 'Packet Acknowledgment' Option . . . . . . . . . 8 2.3.2.7. 'Options Negotiation Request' Option . . . . . . 8 2.3.2.8. 'Options Negotiation Response' Option . . . . . . 9 3.3. Pseudo Header . . . . . . . . . . . . . . . . . . . . . . . 9 3.4. Packet Delivery Acknowledgment Mechanism . . . . . . . . . 9 3.5. Compatibility with UDP . . . . . . . . . . . . . . . . . 10 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 5.1. EUDP Options Numbers Registry . . . . . . . . . . . . . . 10 5.2. EUDP Service Codes . . . . . . . . . . . . . . . . . . . 11 5.3. UDP Port Number Assignment . . . . . . . . . . . . . . . 12 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.1. Normative References . . . . . . . . . . . . . . . . . . 12 6.2. Informative References . . . . . . . . . . . . . . . . . 12 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 12 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 Yevstifeyev Expires July 29, 2011 [Page 2] INTERNET DRAFT EUDP January 25, 2011 1. Introduction User Datagram Protocol (UDP) [RFC768] is one of the most widely-used transport-level protocol. One of the things which makes it so popular is its simplicity. However in some cases this causes lack of facilities, which can be provided by other protocols, such as Transmission Control Protocol (TCP) [RFC793] or Datagram Congestion Control Protocol [RFC4340]. During the history of UDP some attempts have been made to improve it by adding some features (for instance UDP-Lite [RFC3828]), but these proposals were too specific and did not gain popularity. EUDP, extension to UDP, proposed by this document, is intended to be a universal solution, which combines simplicity of UDP and extensibility of TCP by adding an options space to UDP header. This allows the client to choose what function except core transport ones will be provided and what will not. Unlike, for instance, TCP, that makes using, e.g., packet delivery acknowledgment system mandatory for all the packets in transaction, EUDP lets the client to choose what packets should be acknowledged by other side and what will not. Please note, that the extension, defined in this document is experimental and does not purport to be any kind of Standard. 1.1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. The term 'EUDP packet' means UDP packet with EUDP sub-header. Yevstifeyev Expires July 29, 2011 [Page 3] INTERNET DRAFT EUDP January 25, 2011 2. Model of Work EUDP works as follows. The EUDP sub-header is placed directly after the UDP header. The UDP header fields 'Source Port' and 'Destination Port' are set to TBD1 to identify the use of EUDP. The real values of these fields are put into corresponding fields into EUDP sub- header, called 'Source Service code' and 'Destination Service Code', respectively. It also contains information about the length of Options Area. The transferred data are put directly after the EUDP sub-headers. Then UDP packet with EUDP header is sent to the destination host via Internet Protocol (IP) or other protocol with the same functionality that is supported by the destination host. Once the destination host that supports EUDP received the UDP packet with the 'Source Port' and 'Destination Port' fields set to TBD1, it examines the EUDP sub- header and finds out the real source and destination port numbers, data offset and other information, processes options and sends the answering EUDP packet. EUDP provides stateless connection. It id a peer-to-peer protocol, i.e. not client-server one. Yevstifeyev Expires July 29, 2011 [Page 4] INTERNET DRAFT EUDP January 25, 2011 3. Extension Specification 3.1. Sub-Header 3.1.1. Sub-Header Format The EUDP sub-header is shown in the Figure 1. 0 15 16 31 +----------------+----------------+ | Source | Destination | | Service Code | Service Code | +----------------+----------------+ | Data Offset | | | | | +----------------+ + | Options | : : : +----------------+ | | Padding | +----------------+----------------+ Figure 1 The sub-haeder MUST be placed as shown in Figure 2. +----------------+----------------+ | | | UDP Header | | | +----------------+----------------+ | | | EUDP Sub-Header | | | +----------------+----------------+ | | : Data : | | +----------------+----------------+ Figure 2 3.1.2. Fields Source Service Code (16 bits) - REQUIRED field that contains the real value of 'Source Port' UDP header field (see Section 2 of this document), which is defined RFC 768 [RFC768]. Yevstifeyev Expires July 29, 2011 [Page 5] INTERNET DRAFT EUDP January 25, 2011 Destination Service Code (16 bits) - REQUIRED field that contains the real value of 'Destination Port' UDP header field (see Section 2 of this document), which is defined RFC 768 [RFC768]. Data Offset (16 bits) - REQUIRED field which is the number of 32 bit words in UDP header plus EUDP sub-header. The UDP header with EUDP sub-header (even one including options) MUST be an integral number of 32 bits long. Options (variable length) - OPIONAL field, that is used to carry EUDP options in. EUDP option are described in Section 3.2. Padding (variable length) - OPTIONAL field. The EUDP sub-header padding is used to ensure that the EUDP sub-header ends and data begins on a 32 bit boundary. The padding MUST be composed of zeros. 3.2. EUDP Options 3.2.1. Generic Description EUDP options are placed into the 'Options' sub-header field. Options may occupy space at the end of the EUDP sub-header and are a multiple of 8 bits in length. All options MUST be included in the UDP checksum. An option SHALL begin on any octet boundary. There are two cases for the format of an option: a) a single octet of option-kind. b) an octet of option-kind, an octet of option-length, and the actual option-data octets. The option-length counts the two octets of option-kind and option-length as well as the option-data octets. Note that the list of options may be shorter than the data offset field might imply. The content of the header beyond the 'End Of Options List' option MUST be header padding (i.e., zeros). All options can be _mandatory_ or _optional_ for support. EUDP nodes MUST support all _mandatory_ options. Support of _optional_ options is OPTIONAL. Pre-defined options are specified in Section 3.2.2. Yevstifeyev Expires July 29, 2011 [Page 6] INTERNET DRAFT EUDP January 25, 2011 3.2.2. Pre-Defined Options This section specifies pre-defined EUDP options. 3.2.2.1. 'No Operation' Option +--------+ | Kind=0 | +--------+ This option may be used between options, for example, to align the beginning of a subsequent option on a word boundary. The option is _mandatory_ for support. 3.2.2.2. 'End Of Options List' Option +--------+ | Kind=1 | +--------+ This option code indicates the end of the options list. This might not coincide with the end of the EUDP sub-header according to the 'Data Offset' field. This SHALL be used at the end of all options, not the end of each option, and need only be used if the end of the options would not otherwise coincide with the end of the EUDP header. The option is _mandatory_ for support. 3.2.2.3. 'Echo Request' Option +--------+--------+-------//-------+ | Kind=2 | Length | Data | +--------+--------+-------//-------+ The 'Echo Request' option is used to provide the possibility of echo debugging using the EUDP. The 'Data' part of option may consist of arbitrary octets. The receiver of the packet with this option SHALL send back the packet with 'Echo Response' option (see Section 3.2.2.4). The option is _mandatory_ for support. 3.2.2.4. 'Echo Response' Option +--------+--------+-------//-------+ | Kind=3 | Length | Data | +--------+--------+-------//-------+ Yevstifeyev Expires July 29, 2011 [Page 7] INTERNET DRAFT EUDP January 25, 2011 The 'Echo Response' option is used to answer the packets with 'Echo Request' option. The packet consisting 'Echo Response' option SHALL be send after receiving any EUDP packet with 'Echo Request' option. The 'Data' part of the option MUST be the same as in received 'Echo Request' option. The option is _mandatory_ for support. 3.2.2.5. 'Packet Identifier' Option +--------+--------+--------+-------+ | Kind=4 |Length=4| Packet ID | +--------+--------+--------+-------+ The 'Packet Identifier' option is asked to request the acknowledgment of the single packet. The 'Packet ID' field is filled by arbitrary bytes by the sender of the packet with this option. The receiver of the packet with 'Packet Identifier' option SHALL send back the packet with 'Packet Acknowledgment' option (see Section 3.2.2.6). See Section 3.4 for details. The option is _mandatory_ for support. 2.3.2.6. 'Packet Acknowledgment' Option +--------+--------+--------+-------+ | Kind=5 |Length=4| ACK Packet ID | +--------+--------+--------+-------+ The 'Packet Acknowledgment' option is used to answer the packets with 'Packet Identifier' option. The 'ACK Packet ID' field in the option in the packet sent to the originating host for packet with 'Packet Identifier' option MUST be the same as in received from this host packet. See Section 3.4 for details. The option is _mandatory_ for support. 2.3.2.7. 'Options Negotiation Request' Option +--------+--------+--------+-------//-------+ | Kind=6 | Length | Opt.#1 | Opt#2 .. Opt#N | +--------+--------+--------+-------//-------+ The 'Options Negotiation Request' option is used to initiate the negotiation of used _optional_ options. If the EUDP host wants to use one or more _optional_ options, it SHOULD firstly negotiate their use with the other host. The Data area of the option contains the numbers of options the host wants to negotiate. The EUDP host that Yevstifeyev Expires July 29, 2011 [Page 8] INTERNET DRAFT EUDP January 25, 2011 received the packet with this option SHALL answer with the packet with 'Options Negotiation Response' (see Section 2.3.2.8). The 'Options Negotiation Request' option MUST contain the numbers of _optional_ options only. The option is _mandatory_ for support. 2.3.2.8. 'Options Negotiation Response' Option +--------+--------+--------+-------//-------+ | Kind=7 | Length | Opt.#1 | Opt#2 .. Opt#N | +--------+--------+--------+-------//-------+ The 'Options Negotiation Response' option is used to complete the options negotiation. Once EUDP host receive the 'Options Negotiation Request' option (see Section 2.3.2.8), it SHALL check what option from the list mentioned in the negotiation request it supports and put appropriate values into the 'Options Negotiation Response' option, put it into the EUDP packet and send back. The option is _mandatory_ for support. 3.3. Pseudo Header EUDP does not use pseudo header. 3.4. Packet Delivery Acknowledgment Mechanism EUDP provides the possibility to request the acknowledgment of the single EUDP packet. This is provided by 'Packet Identifier' and 'Packet Acknowledgment' options. In the simplest form, the acknowledgment mechanism works as follows. Once EUDP host (let it be A) wants to request the acknowledgment of delivery of some packet, it puts the 'Packet Identifier' option in it and sends this packet to another EUDP host (let it be B). Once B received the A's packet, it checks the 'Packet Identifier' option to find out the packet identifier. After it finds it out, this number becomes the 'ACK Packet Identifier', that is put into 'Packet Acknowledgment' option and sent to A. The Packet identifiers MAY be reused once they are acknowledged, since EUDP provides stateless connection. Compared with acknowledgment mechanism of TCP [RFC793], EUDP provides simpler and more liberal system. While TCP makes using the packet sequence numbers and acknowledgement mandatory, EUDP allows the host to decide whether the packet needs to be acknowledged by the other side or not. Yevstifeyev Expires July 29, 2011 [Page 9] INTERNET DRAFT EUDP January 25, 2011 3.5. Compatibility with UDP The applications which use UDP can safely use EUDP with no options instead. 4. Security Considerations Generic security issues for UDP concern EUDP as well. Additional security can be provided by additional options. This document does not define such options. UDP itself does not provide any authentication features. Such features can be provided by additional options, which are not defined by this document. 5. IANA Considerations 5.1. EUDP Options Numbers Registry IANA is asked to create and maintain the registry named 'EUDP Options Numbers Registry', which consists of 4 values: Option Kind, Option Length, Support Criteria, Description and Reference. They are described below. 'Option Kind' value is integer; values from 0 to 255 are assigned. 'Option length' may be omitted (for one octet options), be stated as an integer or 'variable'. 'Support Criteria' can be assigned as 'Mandatory' and 'Optional'. 'Description' value contains the short description of the option. 'Reference' contains the reference to the document that specifies the option. The initial values are given below; assignments to this registry for _mandatory_ options are to be made following the 'IETF Consensus' policies; for _optional_ options - following the 'RFC required' policies. [RFC5226] The Option Kind 0 is assigned for 'No Operation' option. No Option Length value is assigned for it. The Support Criteria for this option is 'mandatory'. The Reference document is this RFC xxxx. Yevstifeyev Expires July 29, 2011 [Page 10] INTERNET DRAFT EUDP January 25, 2011 The Option Kind 1 is assigned for 'End Of Options List' option. No Option Length value is assigned for it. The Support Criteria for this option is 'mandatory'. The Reference document is this RFC xxxx. The Option Kind 2 is assigned for 'Echo Request' option. The Option Length value 'variable' is assigned for it. The Support Criteria for this option is 'mandatory'. The Reference document is this RFC xxxx. The Option Kind 3 is assigned for 'Echo Response' option. The Option Length value 'variable' is assigned for it. The Support Criteria for this option is 'mandatory'. The Reference document is this RFC xxxx. The Option Kind 4 is assigned for 'Packet Identifier' option. The Option Length value 4 is assigned for it. The Support Criteria for this option is 'mandatory'. The Reference document is this RFC xxxx. The Option Kind 5 is assigned for 'Packet Acknowledgement' option. The Option Length value 4 is assigned for it. The Support Criteria for this option is 'mandatory'. The Reference document is this RFC xxxx. The Option Kind 6 is assigned for 'Options Negotiation Request' option. The Option Length value 'variable' is assigned for it. The Support Criteria for this option is 'mandatory'. The Reference document is this RFC xxxx. The Option Kind 7 is assigned for 'Options Negotiation Response' option. The Option Length value 'variable' is assigned for it. The Support Criteria for this option is 'mandatory'. The Reference document is this RFC xxxx. The Option Kinds 8-253 are available for assignment. The Option Kind 254 is permanently reserved for experimentation purposes. The Option Kind 255 is permanently reserved for future use. [RFC Editor: Please replace xxxx with assigned RFC number] 5.2. EUDP Service Codes Since EUDP service codes are used in the meaning of port numbers and, therefore, numbers used as UDP port numbers are acceptable for use as EUDP service codes, IANA is asked to mark the UDP port numbers registry that the UDP port numbers are suitable for EUDP with the reference to this document. Yevstifeyev Expires July 29, 2011 [Page 11] INTERNET DRAFT EUDP January 25, 2011 5.3. UDP Port Number Assignment IANA has assigned the UDP port number TBD1 to be used for EUDP (see Section 2 of this document). 6. References 6.1. Normative References [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980. [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. 6.2. Informative References [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., Ed., and G. Fairhurst, Ed., "The Lightweight User Datagram Protocol (UDP-Lite)", RFC 3828, July 2004. [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006. Acknowledgments The idea of this document belongs to Magnus Westerlund. The portions of RFC 793, whose author - Jon Postel - is acknowledged, are reused in this document for describing options. Author's Addresses Mykyta Yevstifeyev Kotovsk, Ukraine EMail: evnikita2@gmail.com Yevstifeyev Expires July 29, 2011 [Page 12]