idnits 2.17.1 draft-eromenko-ipff-udp-03.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 169 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 54 has weird spacing: '...DP) is defin...' == Line 55 has weird spacing: '...atagram mode...' == Line 56 has weird spacing: '...ronment of a...' == Line 57 has weird spacing: '...rotocol assum...' == Line 60 has weird spacing: '...rotocol provi...' == (18 more instances...) -- The document date (2017-03-29) is 2575 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 57 looks like a reference -- Missing reference section? '2' on line 64 looks like a reference -- Missing reference section? 'IPFF' on line 104 looks like a reference Summary: 3 errors (**), 0 flaws (~~), 8 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT 2 "Internet Protocol Five Fields - User Datagram Protocol", 3 Alexey Eromenko, 2016-09-29, 4 5 expiration date: 2017-03-29 7 Intended status: Standards Track 8 A.Eromenko 9 September 2016 11 User Datagram Protocol 12 ---------------------- 13 for Internet Protocol "Five Fields" (IP-FF) 14 Specification draft 16 Abstract 18 Minor modification of the UDP protocol to reduce overhead by 2 bytes. 19 Intended to be used with Internet Protocol "Five Fields". 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 Copyright Notice 38 Copyright (c) 2015 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Introduction 52 ------------ 54 This User Datagram Protocol (UDP) is defined to make available a 55 datagram mode of packet-switched computer communication in the 56 environment of an interconnected set of computer networks. This 57 protocol assumes that the Internet Protocol (IP) [1] is used as the 58 underlying protocol. 60 This protocol provides a procedure for application programs to send 61 messages to other programs with a minimum of protocol mechanism. The 62 protocol is transaction oriented, and delivery and duplicate protection 63 are not guaranteed. Applications requiring ordered reliable delivery of 64 streams of data should use the Transmission Control Protocol (TCP) [2]. 66 Format 67 ------ 68 User Datagram Header Format 70 0 7 8 15 16 23 24 31 71 +--------+--------+--------+--------+ 72 | | 73 | CRC32c Checksum | 74 +--------+--------+--------+--------+ 75 | . 76 | data octets ... . 77 +---------------- ... 79 Fields 80 ------ 82 Ports, while logically belong to Transport Layer, have moved to the IP 83 layer in IP-FF, and this is to speed-up certain routing decisions. 85 Source Port is an optional field, when meaningful, it indicates the port 86 of the sending process, and may be assumed to be the port to which a 87 reply should be addressed in the absence of any other information. If 88 not used, a value of zero is inserted. 90 Destination Port has a meaning within the context of a particular 91 internet destination address. 93 Length of the data is taken from upper level IPFF protocol. 95 CRC32c Checksum consists of parts of the IP header, the UDP header, 96 and the data, padded with zero bytes at the end (if necessary) 97 to make a multiple of two bytes. 98 This checksum procedure is similar to what is used in TCP.64. 100 The pseudo header conceptually prefixed to the UDP header contains the 101 source address, the destination address, the protocol, and the UDP 102 length. This information gives protection against misrouted datagrams. 104 The header structure must be taken from [IPFF] document RFC. 106 If the computed checksum is zero, it is transmitted as all ones. 107 An all zero transmitted 108 checksum value means that the transmitter generated no checksum (for 109 debugging or for higher level protocols that don't care). 111 User Interface 112 -------------- 114 A user interface should allow the creation of new receive ports, 115 receive operations on the receive ports that return the data bytes 116 and an indication of source port and source address, 117 and an operation that allows a datagram to be sent, specifying the 118 data, source and destination ports and addresses to be sent. 120 IP Interface 121 ------------- 123 The UDP module must be able to determine the source and destination 124 internet addresses and the protocol field from the internet header. One 125 possible UDP/IP interface would return the whole internet datagram 126 including all of the internet header in response to a receive operation. 127 Such an interface would also allow the UDP to pass a full internet 128 datagram complete with header to the IP to send. 130 Protocol Application 131 -------------------- 133 The major uses of this protocol is the Internet Domain Name Server 134 (DNS), the Trivial File Transfer Protocol (TFTP) and the Dynamic Host 135 Configuration Protocol (DHCP). 137 Protocol Number 138 --------------- 140 This is protocol 17 when used in the Internet Protocol. 142 Acknowledgement 143 --------------- 145 Originally written by J.Postel as RFC-768, modified by Alexey Eromenko 146 for the purposes of Internet Protocol "Five Fields". 148 Author Contacts 150 Alexey Eromenko 151 Israel 153 Skype: Fenix_NBK_ 154 EMail: al4321@gmail.com 155 Facebook: https://www.facebook.com/technologov 157 INTERNET-DRAFT 158 Alexey 160 expiration date: 2017-03-29