INTERNET-DRAFT Mykyta Yevstifeyev Intended Status: Experimental December 8, 2010 Expires: June 11, 2011 Extendable User Datagram Protocol (EUDP) Abstract This document is a specification of Extendable User Datagram Protocol (EUDP), which is based on User Datagram Protocol (UDP), but allows to extend the header using 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) 2010 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 to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of M. Yevstifeyev Expires June 11, 2011 [Page 1] INTERNET DRAFT EUDP Specification December 8, 2010 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. Pre-Defined Options . . . . . . . . . . . . . . . . . . . . 5 2.3.1. 'No Operation' Option . . . . . . . . . . . . . . . . 5 2.3.2. 'End Of Options List' Option . . . . . . . . . . . . . 5 2.4. Pseudo Header . . . . . . . . . . . . . . . . . . . . . . . 6 2.5. Compatibility with UDP . . . . . . . . . . . . . . . . . . 6 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 4.1. EUDP Options Registry . . . . . . . . . . . . . . . . . . . 8 4.2. EUDP Ports Registry . . . . . . . . . . . . . . . . . . . . 8 4.3. IP Protocol Number Assignment . . . . . . . . . . . . . . . 8 4.4. EUDP Pseudo-Header Flags Registry . . . . . . . . . . . . . 8 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.1. Normative References . . . . . . . . . . . . . . . . . . . 9 5.2. Informative References . . . . . . . . . . . . . . . . . . 9 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 M. Yevstifeyev Expires June 11, 2011 [Page 2] INTERNET DRAFT EUDP Specification December 8, 2010 1. Introduction UDP 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 TCP (see RFC 793 [RFC793]) or DCCP (see RFC 4340 [RFC4340]). During the history of UDP some attempts have been made to improve it by adding some features (for instance UDP-Lite (see RFC 3828 [RFC3828]), but these proposals were too specific and did not gain popularity. EUDP, protocol, proposed by this document, is intended to be a universal solution, which combines simplicity of UDP and extensibility of TCP. 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]. M. Yevstifeyev Expires June 11, 2011 [Page 3] INTERNET DRAFT EUDP Specification December 8, 2010 2. Protocol Description 2.1. Lower Layer Protocols Considerations EUDP is a transport-layer protocol, and the protocol directly under it is IP. EUDP supports as IPv4, as IPv6 as lower-layer protocol. The IP Protocol number to be used with EUDP is TBD1. 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 | Checksum | +----------------+----------------+ | | : 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. This indicates where the data begins. The EUDP header (even one including options) is an integral number of 32 bits long. M. Yevstifeyev Expires June 11, 2011 [Page 4] INTERNET DRAFT EUDP Specification December 8, 2010 Checksum (16 bits) - REQUIRED field which is defied and is to be used as described in UDP specification - RFC 768 [RFC768]. Options (variable length) - OPIONAL field. Options may occupy space at the end of the EUDP header and are a multiple of 8 bits in length. All options are included in the checksum. An option may begin on any octet boundary. There are two cases for the format of an option: Case 1: A single octet of option-kind. Case 2: 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-Option option must be header padding (i.e., zero). EUDP MUST support all options. Pre-defied options are specified in Section 2.3. Padding (variable length) - OPTIONAL field. The EUDP header padding is used to ensure that the TCP header ends and data begins on a 32 bit boundary. The padding is composed of zeros. 2.3. Pre-Defined Options This section specifies pre-defined EUDP options. Currently following options are pre-defined - see Section 2.3.1 and Section 2.3.2. 2.3.1. 'No Operation' Option The 'No Operation' option has the following parameters: Kind - 0; Length - none (one-octet option); This option may be used between options, for example, to align the beginning of a subsequent option on a word boundary. 2.3.2. 'End Of Options List' Option The 'End of Options List' option has the following parameters: Kind - 1; Length - none (one-octet option); This option code indicates the end of the option list. This might not coincide with the end of the TCP header according to the Data Offset M. Yevstifeyev Expires June 11, 2011 [Page 5] INTERNET DRAFT EUDP Specification December 8, 2010 field. This is 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. 2.4. Pseudo Header The EUDP does not use the same pseudo header as UDP. The EUDP pseudo- header is shown in the figure 2. 0 7 8 15 +--------+---------+ |Protocol| Flags | +--------+---------+ Figure 2 The Protocol field is defined and is to be used as described in UDP specification - RFC 768 [RFC768]. The Flags field is currently not defined. This field SHOULD be ignored until at least one flag is defined. For numbering purposes this field is being numbered as defined below: 01234567 +--------+ | Flags | +--------+ 2.5. Compatibility with UDP The applications which use UDP can safely use EUDP with no options instead. M. Yevstifeyev Expires June 11, 2011 [Page 6] INTERNET DRAFT EUDP Specification December 8, 2010 3. 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. M. Yevstifeyev Expires June 11, 2011 [Page 7] INTERNET DRAFT EUDP Specification December 8, 2010 4. IANA Considerations 4.1. EUDP Options Registry IANA is asked to create and maintain the registry named 'EUDP Options Registry', which consists of 4 values: Option Kind, Option Length, Description and Reference. The initial values are given below; assignments to this registry are to be made through RFC Required policies. Option kind Option length Description Reference ------------+--------------+-----------------------+--------------- 0 - No Operation This document 1 - End of Options List This document 2-253 - Unassigned This document 254 variable Private Experimentation This document 255 - Reserved This document 4.2. EUDP Ports Registry As EUDP uses the same port set as UDP, IANA is asked to mark that all assigned UDP ports can 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. 4.4. EUDP Pseudo-Header Flags Registry IANA is asked to create and maintain the registry named 'EUDP Pseudo- Header Flags Registry', which consists of 3 values: Bit Number, Description and Reference. The initial values are given below; assignments to this registry are to be made through RFC Required policies. Bit number Description Reference ------------+-------------------------------------+--------------- 0-7 Unassigned This document M. Yevstifeyev Expires June 11, 2011 [Page 8] INTERNET DRAFT EUDP Specification December 8, 2010 5. References 5.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. 5.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. Author's Addresses Mykyta Yevstifeyev 8 Kuzovkov St., flat 25, Kotovsk, Ukraine EMail: evnikita2@gmail.com M. Yevstifeyev Expires June 11, 2011 [Page 9]