INTERNET-DRAFT M. Yevstifeyev Intended Status: Experimental January 30, 2011 Expires: August 3, 2011 Extendable User Datagram Protocol (EUDP) Abstract This document is a specification of experimental Extendable User Datagram Protocol (EUDP), which is based on User Datagram Protocol (UDP), but allows to extend its header and, therefore, its functionality with options. 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. 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 Yevstifeyev Expires August 3, 2011 [Page 1] INTERNET DRAFT EUDP January 30, 2011 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. Protocol Description . . . . . . . . . . . . . . . . . . . . . 4 2.1. Lower Layer Protocols Considerations . . . . . . . . . . . 4 2.2. Packet Format . . . . . . . . . . . . . . . . . . . . . . . 4 2.2.1. Header . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2.2. Fields . . . . . . . . . . . . . . . . . . . . . . . . 4 2.3. EUDP Options . . . . . . . . . . . . . . . . . . . . . . . 5 2.3.1. Generic Description . . . . . . . . . . . . . . . . . 5 2.3.2. Pre-Defined Options . . . . . . . . . . . . . . . . . 5 2.3.2.1. 'No Operation' Option . . . . . . . . . . . . . . 5 2.3.2.2. 'End Of Options List' Option . . . . . . . . . . 6 2.3.2.3. 'Echo Request' Option . . . . . . . . . . . . . . 6 2.3.2.4. 'Echo Response' Option . . . . . . . . . . . . . 6 2.3.2.5. 'Packet Identifier' Option . . . . . . . . . . . 7 2.3.2.6. 'Packet Acknowledgment' Option . . . . . . . . . 7 2.4. Pseudo Header . . . . . . . . . . . . . . . . . . . . . . . 7 2.5. Packet Revival Acknowledgment Mechanism . . . . . . . . . . 7 2.6. Compatibility with UDP . . . . . . . . . . . . . . . . . . 8 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 9 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 4.1. EUDP Options Numbers Registry . . . . . . . . . . . . . . 10 4.2. EUDP Ports Registry . . . . . . . . . . . . . . . . . . . 11 4.3. IP Protocol Number Assignment . . . . . . . . . . . . . . 11 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.1. Normative References . . . . . . . . . . . . . . . . . . 11 5.2. Informative References . . . . . . . . . . . . . . . . . 11 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 11 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Yevstifeyev Expires August 3, 2011 [Page 2] INTERNET DRAFT EUDP January 30, 2011 1. Introduction This document is a specification of experimental Extendable User Datagram Protocol (EUDP), which is based on User Datagram Protocol (UDP), but allows to extend its header and, therefore, its functionality with options. Such solution may be useful in the situations when UDP provides lack of features while other transport-layer protocols, such as Transmission Control Protocol (TCP) [RFC793] or Datagram Congestion Control Protocol (DCCP) [RFC4340], have excessive facilities, which might not be needed in such particular case. Current transport-layer protocols are not able to cope with such situations. Unlike them, EUDP may provide theoretically unlimited number of features, that may be appended to core transport facilities, depending on what the client wants EUDP to provide. Therefore, EUDP is intended to be a universal solution, that may be used in almost any situation and may suit to almost any requirements. 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]. Yevstifeyev Expires August 3, 2011 [Page 3] INTERNET DRAFT EUDP January 30, 2011 2. Protocol Description 2.1. Lower Layer Protocols Considerations EUDP is a transport-layer protocol. It is implemented on the top of Internet Protocol (IP). EUDP supports as IPv4 [RFC791], as IPv6 [RFC2460] as lower-layer protocol. The IP Protocol number to be used with EUDP is TBD1. Moreover, EUDP SHOULD be able to operate on the any protocol that provides the same functionality as IP, such as EIP [RFC1385] or TP/IX [RFC1475]. 2.2. Packet Format 2.2.1. Header The EUDP header is shown in the figure 1. 0 15 16 31 +----------------+----------------+ | Source Port |Destination Port| +----------------+----------------+ | Data Offset | Reserved | +----------------+----------------+ | | : Options : : | | +----------------+ | | Padding | +----------------+----------------+ | | : Data : | | +----------------+----------------+ Figure 1 2.2.2. Fields Source Port (16 bits) - REQUIRED field which is defied and is to be used as described in UDP specification - RFC 768 [RFC768]. EUDP uses the same port set as UDP. Destination Port (16 bits) - REQUIRED field which is defied and is to be used as described in UDP specification - RFC 768 [RFC768]. EUDP uses the same port set as UDP. Data Offset (16 bits) - REQUIRED field which is the number of 32 bit words in the EUDP header. The EUDP header (even one including Yevstifeyev Expires August 3, 2011 [Page 4] INTERNET DRAFT EUDP January 30, 2011 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 2.3. Padding (variable length) - OPTIONAL field. The EUDP header padding is used to ensure that the EUDP header ends and data begins on a 32 bit boundary. The padding MUST be composed of zeros. NOTE: Bits 48-63 are reserved for future use and MUST be ignored by EUDP hosts until their use will be properly specified. 2.3. EUDP Options 2.3.1. Generic Description EUDP options are placed into the 'Options' header field. Options may occupy space at the end of the EUDP header and are a multiple of 8 bits in length. An option may 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., zero). All options can be _mandatory_ or _elective_ for support. EUDP nodes MUST support all _mandatory_ options. Support of _elective_ options is OPTIONAL. Pre-defined options are specified in Section 2.3.2. 2.3.2. Pre-Defined Options This section specifies pre-defined EUDP options. 2.3.2.1. 'No Operation' Option +--------+ | Kind=0 | +--------+ This option may be used between options, for example, to align the Yevstifeyev Expires August 3, 2011 [Page 5] INTERNET DRAFT EUDP January 30, 2011 beginning of a subsequent option on a word boundary. The option is _mandatory_ for support. 2.3.2.2. 'End Of Options List' Option +--------+ | Kind=1 | +--------+ This option code indicates the end of the option list. This might not coincide with the end of the EUDP header according to the 'Data Offset' header 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. 2.3.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 option-data octets of option MAY consist of arbitrary octets. The receiver of the packet with this option MUST answer with the packet with 'Echo Response' option (see Section 2.3.2.4). The option is _elective_ for support. 2.3.2.4. 'Echo Response' Option +--------+--------+-------//-------+ | Kind=3 | Length | Data | +--------+--------+-------//-------+ The 'Echo Response' option is used to answer the packets with 'Echo Request' option. The packet containing 'Echo Response' option MUST be send after receiving any EUDP packet with 'Echo Request' option. The option-data octets of the option MUST be the same as in 'Echo Request' option in the received packet. The option is _elective_ for support. Yevstifeyev Expires August 3, 2011 [Page 6] INTERNET DRAFT EUDP January 30, 2011 2.3.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 MUST answer with the packet with 'Packet Acknowledgment' option (see Section 2.3.2.6). See Section 2.5 for details. The option is _elective_ 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 2.5 for details. The option is _elective_ 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 use of _elective_ options (see Section 2.3.1). If the EUDP host wants to use one or more _elective_ options, it SHOULD firstly negotiate their use with the other host. The option-data octets of the option contain the numbers of options the host wants to negotiate. The EUDP host that receives 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 _elective_ options only. The option is _mandatory_ for support. 2.3.2.8. 'Options Negotiation Response' Option Yevstifeyev Expires August 3, 2011 [Page 7] INTERNET DRAFT EUDP January 30, 2011 +--------+--------+--------+-------//-------+ | Kind=7 | Length | Opt.#1 | Opt#2 .. Opt#N | +--------+--------+--------+-------//-------+ The 'Options Negotiation Response' option is used to complete the _elective_ options negotiation. Once EUDP host receives the 'Options Negotiation Request' option (see Section 2.3.2.7), 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. 2.3.2.9. 'Packet Checksum' Option +--------+--------+--------+-------+ | Kind=8 |Length=4| Checksum | +--------+--------+--------+-------+ The 'Packet Checksum' option is used to carry packet checksum, calculated using the method described in RFC 768 [RFC768]. Packets containing this option with bad checksum SHOULD be discarded. The option is _elective_ for support. 2.4. Pseudo Header EUDP does not use pseudo header. 2.5. 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 delivery acknowledgment mechanism works as below. If 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 receives 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, which is put into the EUDP packet, and sent to A. The packet identifiers MAY be reused once they are acknowledged, since EUDP does provides stateless connection. Compared with acknowledgment mechanism of TCP [RFC793], EUDP provides simpler and more liberal system. While TCP makes using the packet Yevstifeyev Expires August 3, 2011 [Page 8] INTERNET DRAFT EUDP January 30, 2011 sequence numbers and acknowledgement mandatory, EUDP allows the host to decide whether the packet needs to be acknowledged by the other side or not. 2.6. Compatibility with UDP The applications which use UDP can safely use EUDP with no options instead. 3. Security Considerations Generic security issues for UDP concern EUDP as well. Additional security can be provided by EUDP 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. 4. IANA Considerations 4.1. 'EUDP Options Numbers' Registry IANA is asked to create and maintain the registry named 'EUDP Options Numbers Registry' following the guidelines below. The regsitry consists of 5 values: Option Kind, Option Length, Support Criteria, Name and Reference. They are described below. Option Kind - an integer; refers to the value used in EUDP options. Values from 0 to 255 are assigned. Option Length - an integer, 'variable' (for multi-octet options) or 'N/A' (for one-octet options). Support Criteria - 'Mandatory' and 'Elective' (see Section 2.3.1). Name - contains the name of the option. Reference - the reference to the document, that defines 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 _elective_ options - following the 'RFC required' policies. [RFC5226] Yevstifeyev Expires August 3, 2011 [Page 9] INTERNET DRAFT EUDP January 30, 2011 +-------+-------+----------+------------------------------+-----------+ | # | Length| Support | Name | Reference | +-------+-------+----------+------------------------------+-----------+ | 0 | N/A | mandatory| No Operation | RFC xxxx | | 1 | N/A | mandatory| End Of Options List | RFC xxxx | | 2 | var. | elective | Echo Request | RFC xxxx | | 3 | var. | elective | Echo Response | RFC xxxx | | 4 | 4 | elective | Packet Identifier | RFC xxxx | | 5 | 4 | elective | Packet Acknowledgment | RFC xxxx | | 6 | var. | mandatory| Options Negotiation Request | RFC xxxx | | 7 | var. | mandatory| Options Negotiation Response | RFC xxxx | | 8 | 4 | elective | Packet Checksum | RFC xxxx | | 9-252 | -- | -- | Unassigned | RFC xxxx | | 253 | -- | -- | Used for Experimentation | RFC xxxx | | 254 | -- | -- | Used for Experimentation | RFC xxxx | | 255 | -- | -- | Reserved | RFC xxxx | +-------+-------+----------+------------------------------+-----------+ [RFC Editor: Please replace xxxx with assigned RFC number] 4.2. EUDP Port Numbers Assignment As EUDP uses the same port set as UDP, IANA is asked to mark the UDP port numbers registry values may be used with EUDP as well. 4.3. IP Protocol Number Assignment IANA has assigned the IP protocol number TBD1 to be used with EUDP. 5. References 5.1. Normative References [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980. [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. Yevstifeyev Expires August 3, 2011 [Page 10] INTERNET DRAFT EUDP January 30, 2011 5.2. Informative References [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [RFC1385] Wang, Z., "EIP: The Extended Internet Protocol", RFC 1385, November 1992. [RFC1475] Ullmann, R., "TP/IX: The Next Internet", RFC 1475, June 1993. [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006. Appendix A. Acknowledgments The portions of RFC 793 [RFC793], whose author - Jon Postel - is acknowledged, are adopted in this document for describing options. Author's Addresses Mykyta Yevstifeyev Kotovsk, Ukraine EMail: evnikita2@gmail.com Yevstifeyev Expires August 3, 2011 [Page 11]