idnits 2.17.1 draft-eromenko-ipff-fdp-00.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 234 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. ** There are 3 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 55 has weird spacing: '...DP) is defin...' == Line 56 has weird spacing: '...atagram mode...' == Line 109 has weird spacing: '... padded with ...' == Line 110 has weird spacing: '... to make a...' == Line 113 has weird spacing: '...omputed check...' == (7 more instances...) -- The document date (2017-03-29) is 2557 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? 'IPFF' on line 151 looks like a reference -- Missing reference section? 'RFC-2460' on line 212 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT 2 "Internet Protocol Five Fields - Fragmented 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 Fragmented Datagram Protocol 12 -------------------------------- 13 for Internet Protocol "Five Fields" (IP-FF) 14 Specification draft 16 Abstract 18 A heavy-weight version of the UDP protocol, intended to provide simple 19 fragmentation mechanism with Internet Protocol "Five Fields", along 20 with a stronger checksum at a cost of somewhat higher overhead. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 Copyright Notice 39 Copyright (c) 2015 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 Introduction 53 ------------ 55 This Fragmented Datagram Protocol (FDP) is defined to make 56 datagram mode communication possible in the computing environment, 57 where fragmented transmission and reception are needed. 58 FDP conceptually is a heavy-weight UDP if you will. 60 Format 61 ------ 62 Fragmented Datagram Header Format 64 0 1 2 3 65 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 66 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 67 4| | 68 + CRC64c Checksum + 69 8| | 70 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 71 12|M| Fragment Offset | | 72 |F| | | 73 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 74 16| Fragment Identifier | 75 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 76 | | 77 + data octets ... . 78 | . 79 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 80 (bytes) 82 Fields 83 ------ 85 CRC64c Checksum (64-bit) -- 64-bit checksum. See CRC64 Checksum. 87 M flag 1 = more fragments; 0 = last fragment. 89 Fragment Offset 15-bit unsigned integer. The offset, in 8-byte 90 units, of the data following this header, 91 relative to the start of the datagram. 93 Fragment Identifier 48-bit identifier is needed to distinguish 94 fragments from different datagrams. 96 FDP segment must only be assembled when the six-tuple matches: 97 1. Source and Destination IP address 98 2. Source and Destination ports / Flow 99 3. Protocol 100 4. Same Fragment Identifier 102 *NOTE: Fragmentation is incompatible with very big Jumbograms. 103 (IP packets sized > 256 KiB) 105 CRC64 Checksum 106 -------------- 108 Consists of parts of the IP header, the FDP header, 109 and the data, padded with zero bytes at the end (if necessary) 110 to make a multiple of two bytes. 111 This checksum procedure is similar to what is used in TCP.64. 113 If the computed checksum is zero, it is transmitted as all ones. 114 An all zero transmitted checksum value means that the transmitter 115 generated no checksum (for debugging or for higher level protocols 116 that don't care or for ILNP purposes). 118 Design note: 120 Checksum in FDP covers *only* one-single fragment, not the entire 121 packet. This is done to simplify processing by middleboxes, so for 122 them it will look like a Checksum covers a packet, they don't need 123 to re-assemble the fragments into a packet to change or validate 124 checksum anymore. 125 This is done particularly for load-balancers and NAT Routers. 127 Additionally, because in IP-FF ports are at layer 3, are visible, 128 which further simplifies middlebox design and implementation. 130 Implied Items 131 ------------- 133 Ports, while logically belong to Transport Layer, have moved to the 134 IP layer in IP-FF, and this is to speed-up certain decisions. 136 Source Port is an optional field, when meaningful, it indicates the 137 port of the sending process, and may be assumed to be the port 138 to which a reply should be addressed in the absence of any other 139 information. If not used, a value of zero is inserted. 141 Destination Port has a meaning within the context of a 142 particular internet destination address. 144 Length of the data is taken from upper level IPFF protocol. 146 The pseudo header conceptually prefixed to the FDP header contains 147 the source address, the destination address, the protocol, and 148 the FDP length. This information gives protection against 149 misrouted datagrams. 151 The header structure must be taken from [IPFF] document RFC. 153 Protocol Application 154 -------------------- 156 Existing UDP applications may be migrated over to FDP. 158 Protocol Number 159 --------------- 161 This is protocol number (to be assigned by IANA), 162 when used in the Internet Protocol, Five Fields. 164 Explaining Fragmentation 165 ------------------------ 167 Fragmented Datagram Protocol works in a similar way to IPv6 fragmentation, 168 with the added bonus that all the IP-FF extensions, checksums and ports 169 are part of each fragment, which adds simplicity. (at a cost of some 170 overhead) 172 In order to send a packet that is too large to fit in the MTU of the 173 path to its destination, a source node may divide the packet into 174 fragments and send each fragment as a separate packet, to be 175 reassembled at the receiver. 177 For every packet that is to be fragmented, the source node generates 178 an Identification value. The Identification must be different than 179 that of any other fragmented packet sent recently* with the same 180 Source Address, Destination Address, Source Port and Destination Port. 182 * "recently" means within the maximum likely lifetime of a packet, 183 including transit time from source to destination and time spent 184 awaiting reassembly with other fragments of the same packet. 185 However, it is not required that a source node know the maximum 186 packet lifetime. Rather, it is assumed that the requirement can 187 be met by maintaining the Identification value as a simple, 48- 188 bit, "wrap-around" counter, incremented each time a packet must 189 be fragmented. It is an implementation choice whether to 190 maintain a single counter for the node or multiple counters, 191 e.g., one for each of the node's possible source addresses, or 192 one for each active (source address, destination address, 193 and ports) combination. 195 The following rules govern reassembly: 197 An original packet is reassembled only from fragment packets that 198 have the same Source Address, Destination Address, Source Port, 199 Destination Port, and Fragment Identification. 201 If all the fragments arrived, with correct checksums, application 202 should receive a complete packet. 203 Else packet must be dropped. 205 Acknowledgement 206 --------------- 208 Originally UDP was written by J.Postel as RFC-768, modified by Alexey 209 Eromenko for the purposes of Internet Protocol "Five Fields". 211 FDP borrows heavily from IPv6-style-fragmentation by end nodes 212 [RFC-2460]. 214 Author Contacts 216 Alexey Eromenko 217 Israel 219 Skype: Fenix_NBK_ 220 EMail: al4321@gmail.com 221 Facebook: https://www.facebook.com/technologov 223 INTERNET-DRAFT 224 Alexey 226 expiration date: 2017-03-29