idnits 2.17.1 draft-bhati-intarea-ip-reassembly-using-labels-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 22 longer pages, the longest (page 19) being 67 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 22 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 362 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 == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 4, 2018) is 2032 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: '10' is mentioned on line 572, but not defined == Missing Reference: '11' is mentioned on line 573, but not defined == Missing Reference: '12' is mentioned on line 574, but not defined == Missing Reference: '13' is mentioned on line 575, but not defined == Missing Reference: '14' is mentioned on line 576, but not defined == Missing Reference: '15' is mentioned on line 577, but not defined == Missing Reference: '16' is mentioned on line 578, but not defined == Unused Reference: '1' is defined on line 500, but no explicit reference was found in the text == Unused Reference: 'RFC 791' is defined on line 508, but no explicit reference was found in the text == Unused Reference: 'RFC 815' is defined on line 511, but no explicit reference was found in the text == Unused Reference: 'RFC 1858' is defined on line 514, but no explicit reference was found in the text == Unused Reference: 'RFC 2460' is defined on line 517, but no explicit reference was found in the text == Unused Reference: 'RFC 3514' is defined on line 520, but no explicit reference was found in the text == Unused Reference: 'RFC 5722' is defined on line 523, but no explicit reference was found in the text -- Duplicate reference: RFC2119, mentioned in 'RFC2119', was also mentioned in '1'. -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) Summary: 1 error (**), 0 flaws (~~), 18 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Area Working Group A. Bhati 3 Internet Draft Samsung Electronics 4 Intended status: Informational October 4, 2018 5 Expires: April 2019 7 IP Reassembly Using Labels 8 draft-bhati-intarea-ip-reassembly-using-labels-00.txt 10 Status of this Memo 12 This Internet-Draft is submitted in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 This document may contain material from IETF Documents or IETF 16 Contributions published or made publicly available before November 17 10, 2008. The person(s) controlling the copyright in some of this 18 material may not have granted the IETF Trust the right to allow 19 modifications of such material outside the IETF Standards Process. 20 Without obtaining an adequate license from the person(s) controlling 21 the copyright in such materials, this document may not be modified 22 outside the IETF Standards Process, and derivative works of it may 23 not be created outside the IETF Standards Process, except to format 24 it for publication as an RFC or to translate it into languages other 25 than English. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 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 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html 43 This Internet-Draft will expire on April 4, 2017. 45 Copyright Notice 47 Copyright (c) 2018 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Abstract 62 This document describes a faster mechanism to re-assemble IPv4 and 63 IPv6 fragments when fragment labels are used instead of fragment 64 offset to reassemble the packets. 66 Table of Contents 68 1. Introduction...................................................4 69 2. Conventions used in this document..............................4 70 3. Changes from RFC 791...........................................5 71 4. IPv4 Fragment field discussion.................................6 72 4.1. Current status as per RFC 791.............................6 73 4.2. Changes suggested by this document........................7 74 4.3. Illustration of fragment label on IPv4 packet.............8 75 5. IPv6 Fragment header discussion...............................12 76 5.1. Current status as per RFC 2460...........................12 77 5.2. Changes suggested by this document.......................13 78 6. Security Considerations.......................................14 79 7. IANA Considerations...........................................15 80 8. Conclusions...................................................16 81 9. References....................................................17 82 9.1. Normative References.....................................17 83 9.2. Informative References...................................17 84 10. Acknowledgments..............................................18 85 Appendix A. IP Packet Reassembly Processing......................19 87 1. Introduction 89 IPv4 as originally defined in RFC 791, has 3 bits of flags field and 90 13 bits of fragment offset field to perform IP fragmentation and IP 91 re-assembly operations inside network nodes. 93 Ipv6 as originally defined in RFC 2460, defines fragment header which 94 has 2 reserved bits just before M flag bit and 13 bits of fragment 95 offset bits before 2 reserved bits. 97 The mechanisms to re-assemble all the fragments of an IP packet are 98 mainly implementation dependent. 100 This draft suggests the use of reserved bit in IPv4 flag bits as L 101 bit (fragment label bit). Whenever value of L bit is 0, 13 bits after 102 the flags field MUST be interpreted as fragment offset as defined in 103 RFC 791. If value of L bit is 1, 13 bits after the flags field MUST 104 be interpreted as fragment label. 106 Similarly this draft suggests the use of reserved bit just before M 107 flag bit in IPv6 fragment header as L bit (bit number 30). Whenever 108 value of L bit is 0, bits 16-28 in fragment header MUST be 109 interpreted as fragment offset as defined in RFC 2460. If value of L 110 bit is 1, bits 16-28 in fragment header MUST be interpreted as 111 fragment label. 113 Fragment label is a simple incrementing integer counter value 114 starting from value 1 for first fragment and incrementing by value 1 115 for subsequent fragments of IP packet. 117 2. Conventions used in this document 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in RFC 2119 [RFC2119]. 123 3. Changes from RFC 791 125 Everything that is described in RFC 791 will remain intact except the 126 interpretation of reserved bit in 3 bit flags field as L bit 127 (fragment label bit). 129 Everything that is described for fragment header in RFC 2460 will 130 remain intact except the interpretation of bit number 30 as L bit 131 (fragment label bit). 133 4. IPv4 Fragment field discussion 135 4.1. Current status as per RFC 791 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 |X|D|M| fragment offset | 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 X Reserved Bit 141 D Do not Fragment Bit 142 M More Fragments Bit 144 Possible fragment with MF bit 1 and zero fragment offset 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 |0|0|1| zero fragment offset | 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 Possible fragment with MF bit 1 and non-zero fragment offset 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 |0|0|1| non-zero fragment offset| 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 Possible Last fragment with MF bit 0 and non-zero fragment offset 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 |0|0|0|non-zero fragment offset | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 Fragment offset value starts from 0 and always be an integer multiple 160 of 8 bytes. If second fragment has value 128, it means first fragment 161 contains 1024 bytes (byte 0 to byte 1023). Second fragment contains 162 byte which was originally present at offset 1024 in non-fragmented IP 163 packet. 165 4.2. Changes suggested by this document 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 |L|D|M| fragment offset | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 L Fragment Label Indicator Bit 171 D Do not Fragment Bit 172 M More Fragments Bit 174 Possible fragment with L bit 1, MF bit 1, and non-zero label 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 |1|0|1|non-zero fragment label | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 Possible last fragment with L bit 1, MF bit 0, and non-zero label 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 |1|0|0|non-zero fragment label | 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 Fragment label is always a non-zero value starting from integer 1. 186 Note that while using mechanism of putting fragment labels instead of 187 fragments offset, there is no restriction to put fragment data which 188 is multiple of 8 bytes in each but last fragment. 190 It is up to fragmentation implementation to decide how many bytes to 191 be kept in any fragment as per the convenience. 193 It is RECOMMENDED to put at least 1024 bytes in each but last 194 fragment so that receiver can re-assemble those fragments using only 195 64 fragment labels. 197 Another guideline is to keep number of bytes in a fragment equal to 198 integer multiple of machine word size on which implementation is 199 executing. This will avoid data access across word size boundaries 200 and improves performance. 202 Sample re-assembly pseudo code of approximate 30 lines is provided in 203 Appendix A. 205 4.3. Illustration of fragment label on IPv4 packet 207 The following example illustrates the fragmentation operation on an 208 example IPv4 packet which has 5120 bytes of payload. IP header length 209 is 20 bytes and total length field is thus equal to 5140 bytes. 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 | IPv4 Header | 213 | Version = 4 | 214 | Header Length = 5 (20 bytes) | 215 | TOS = 0 | 216 | Total Length = 5140 bytes (includes 20 bytes of IP header) | 217 | ID = 1234 | 218 | Flags [L_bit = 0, D_bit = 0, M_bit = 0] | 219 | Fragment offset / Fragment_label = 0x0 | 220 | TTL = 64 | 221 | Protocol = xyz | 222 | Checksum = valid checksum value | 223 | Source IP = 0x01010101 | 224 | Destination IP = 0x02020202 | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 |abcdabcdabcdabcdabcdabcd(1024 bytes)abcdabcdabcdabcdabcdabcdabc| 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 |abcdabcdabcdabcdabcdabcd(1024 bytes)abcdabcdabcdabcdabcdabcdabc| 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 |abcdabcdabcdabcdabcdabcd(1024 bytes)abcdabcdabcdabcdabcdabcdabc| 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 |abcdabcdabcdabcdabcdabcd(1024 bytes)abcdabcdabcdabcdabcdabcdabc| 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 |abcdabcdabcdabcdabcdabcd(1024 bytes)abcdabcdabcdabcdabcdabcdabc| 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 The above packet is fragmented into 5 fragments as follows: 238 First fragment: 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | IPv4 Header | 242 | Version = 4 | 243 | Header Length = 5 (20 bytes) | 244 | TOS = 0 | 245 | Total Length = 1044 bytes (includes 20 bytes of IP header) | 246 | ID = 1234 | 247 | Flags [L_bit = 1, D_bit = 0, M_bit = 1] | 248 | Fragment offset / Fragment Label = 1 | 249 | TTL = 64 | 250 | Protocol = xyz | 251 | Checksum = valid checksum value | 252 | Source IP = 0x01010101 | 253 | Destination IP = 0x02020202 | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 |abcdabcdabcdabcdabcdabcd(1024 bytes)abcdabcdabcdabcdabcdabcdabc| 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 Second fragment: 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | IPv4 Header | 262 | Version = 4 | 263 | Header Length = 5 (20 bytes) | 264 | TOS = 0 | 265 | Total Length = 1044 bytes (includes 20 bytes of IP header) | 266 | ID = 1234 | 267 | Flags [L_bit = 1, D_bit = 0, M_bit = 1] | 268 | Fragment offset / Fragment label = 2 | 269 | TTL = 64 | 270 | Protocol = xyz | 271 | Checksum = valid checksum value | 272 | Source IP = 0x01010101 | 273 | Destination IP = 0x02020202 | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 |abcdabcdabcdabcdabcdabcd(1024 bytes)abcdabcdabcdabcdabcdabcdabc| 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 Third fragment: 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | IPv4 Header | 281 | Version = 4 | 282 | Header Length = 5 (20 bytes) | 283 | TOS = 0 | 284 | Total Length = 1044 bytes (includes 20 bytes of IP header) | 285 | ID = 1234 | 286 | Flags [L_bit = 1, D_bit = 0, M_bit = 1] | 287 | Fragment offset / Fragment label = 3 | 288 | TTL = 64 | 289 | Protocol = xyz | 290 | Checksum = valid checksum value | 291 | Source IP = 0x01010101 | 292 | Destination IP = 0x02020202 | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 |abcdabcdabcdabcdabcdabcd(1024 bytes)abcdabcdabcdabcdabcdabcdabc| 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 Fourth fragment: 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | IPv4 Header | 301 | Version = 4 | 302 | Header Length = 5 (20 bytes) | 303 | TOS = 0 | 304 | Total Length = 1044 bytes (includes 20 bytes of IP header) | 305 | ID = 1234 | 306 | Flags [L_bit = 1, D_bit = 0, M_bit = 1] | 307 | Fragment offset / Fragment label = 4 | 308 | TTL = 64 | 309 | Protocol = xyz | 310 | Checksum = valid checksum value | 311 | Source IP = 0x01010101 | 312 | Destination IP = 0x02020202 | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 |abcdabcdabcdabcdabcdabcd(1024 bytes)abcdabcdabcdabcdabcdabcdabc| 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 Fifth and Final fragment: 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | IPv4 Header | 320 | Version = 4 | 321 | Header Length = 5 (20 bytes) | 322 | TOS = 0 | 323 | Total Length = 1046 bytes (includes 20 bytes of IP header) | 324 | ID = 1234 | 325 | Flags [L_bit = 1, D_bit = 0, M_bit = 0] | 326 | Fragment offset / Fragment label = 5 | 327 | TTL = 64 | 328 | Protocol = xyz | 329 | Checksum = valid checksum value | 330 | Source IP = 0x01010101 | 331 | Destination IP = 0x02020202 | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 |abcdabcdabcdabcdabcdabcd(1024 + 2 bytes)abcdabcdabcdabcdabcdabc| 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 335 |1414 | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 Note that if value of L bit is 1, 13 bits after flags field is 339 interpreted as fragment label instead of fragment offset. 341 Note that implementation is free to pack more than 1024 bytes in each 342 fragment as per link MTU size. This example is packing only 1024 343 bytes per fragment for easy understanding of the concept. 345 For last fragment, original IP length (5140 bytes) is written in last 346 fragment, which is used for comparison of reassembled bytes against 347 the original length. These two bytes should be removed from the re- 348 assembled packet after comparison is done and found to be matching. 350 When these fragments are processed by IP reassembly process inside a 351 network node, fragment label value can be used to directly index into 352 the actual fragment position without any further calculation. This 353 can greatly increase the re-assembly process performance inside 354 network nodes. A sample code to reassemble IP fragments in this 355 scenario is provided in Appendix A. 357 5. IPv6 Fragment header discussion 359 5.1. Current status as per RFC 2460 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 |Next header | Reserved | fragment offset |X|X|M| 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+ 364 X Reserved Bit 365 M More Fragments Bit 367 Possible first fragment with MF bit 1 and fragment offset zero 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 |Next header | Reserved | zero fragment offset |X|X|1| 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+ 372 Possible fragment with MF bit 1 and non-zero fragment offset 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 |Next header | Reserved | non-zero fragment offset|X|X|1| 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+ 377 Possible Last fragment with MF bit 0 and non-zero fragment offset 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 |Next header | Reserved | non-zero fragment offset|X|X|0| 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+ 382 Fragment offset value starts from 0 and always be an integer multiple 383 of 8 bytes. If second fragment has value 128, it means first fragment 384 contains 1024 bytes (byte 0 to byte 1023). Second fragment contains 385 byte which was originally present at offset 1024 in non-fragmented IP 386 packet. 388 Note that there is no D bit inside IPv6 fragment header as no 389 intermediate network node can do further fragmentation. Only source 390 node is permitted to do fragmentation of Ipv6 packet. 392 5.2. Changes suggested by this document 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 |Next header | Reserved | fragment offset |X|L|M| 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+ 397 L Fragment Label Indicator Bit (new addition) 398 M More Fragments Bit 400 Possible fragment with L bit 1, MF bit 1 and non-zero fragment label 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 |Next header | Reserved | non-zero fragment label |X|1|1| 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+ 405 Possible last fragment with L bit 1, MF bit 0 and non-zero fragment 406 label 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 |Next header | Reserved | non-zero fragment label |X|1|0| 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+ 411 Fragment label is always a non-zero value starting from integer 1. 413 If L bit is 0, bits 16-28 MUST be interpreted as fragment offset 414 field. 416 If L bit is 1, bits 16-28 MUST ne interpreted as fragment label 417 field. 419 6. Security Considerations 421 Let us call the network entity which performs fragmentation of IP 422 packet as fragmentor and the network entity which performs reassembly 423 as reassembler. 425 This draft document suggests adding extra two bytes at the end in the 426 last fragment of IP packet produced by the fragmentor. 428 Fragmentor should write the value of original IP total length value 429 (IP length field in large un-fragmented packet) in these two bytes. 431 Reassemblor should match the value present in those 2 bytes against 432 the total length which is reassembled by the reassemblor. If the 433 values do not match, there is a possibility of malformed fragment 434 received by the reassembler. In this case, all the fragments for the 435 context should be discarded and the event should be reported to 436 management plane of reassembler. 438 This mechanism will ensure that no middle-man can possibly add or 439 truncate data bytes from the fragments. 441 The only possibility where a middle-man can add or truncate some 442 bytes in fragments is to have complete knowledge of last fragment and 443 the fragment which he wishes to change. 445 If reassembler receives any duplicate fragment label which was 446 already received earlier for a context, then all fragments for the 447 context shall be discarded and the event should be reported to 448 management plane of reassembler. 450 7. IANA Considerations 452 This draft document proposes the following registry to be maintained 453 by IANA. 455 Flags bits of IPv4 header. 457 ------------------------------------------------- 459 Bit 0: L bit [fragment label bit] 461 If value of this bit is 0, 13 bits after flags field MUST be 462 interpreted as fragment offset field as defined in RFC 791. 464 If value of this bit is 1, 13 bits after flags field MUST be 465 interpreted as fragment label field. 467 Fragment header of IPv6 header. 469 ------------------------------------------------- 471 Bit 30: L bit [fragment label bit] 473 If value of this bit is 0, bits 16-28 MUST be interpreted as fragment 474 offset field as defined in RFC 2460. 476 If value of this bit is 1, bits 16-28 MUST be interpreted as fragment 477 label field. 479 8. Conclusions 481 This draft document proposes the use of reserved bit in IPv4 header 482 flags field as L bit [offset versus label bit] to enable direct index 483 based IPv4 packet re-assembly. 485 Similarly, this draft document proposes the use of bit 30 in IPv6 486 fragment header as L bit [offset versus label bit] to enable direct 487 index based IPv6 packet re-assembly. 489 Network nodes MUST look at offset versus label bit before deciding 490 upon the algorithm to re-assemble IP fragments. If value of L bit is 491 1, the direct index based fragment re-assembly MUST be used for fast 492 re-assembly. This avoids any further calculations required to place a 493 fragment at its correct position inside the reassembly chain. These 494 calculations are explained in RFC 815. 496 9. References 498 9.1. Normative References 500 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 501 Levels", BCP 14, RFC 2119, March 1997. 503 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 504 Requirement Levels", BCP 14, RFC 2119, March 1997. 506 9.2. Informative References 508 [RFC 791] by Information Sciences Institute, University of Southern 509 California, INTERNET PROTOCOL, RFC 791, September 1981 511 [RFC 815] by David D. Clark, IP DATAGRAM REASSEMBLY ALGORITHMS, RFC 512 815, July 1982 514 [RFC 1858] by G. Ziemba, D. Reed, P. Traina, Security Considerations 515 for IP fragment filtering, RFC 1858, October 1995 517 [RFC 2460] by S. Deering, R. Hinden, Internet Protocol Version 6 518 (IPv6) Specification, RFC 2460, December 1998 520 [RFC 3514] by S. Bellovin, The Security Flag in the IPv4 Header, 521 RFC 3514, April 2003 523 [RFC 5722] by S. Krishnan, Handling of Overlapping IPv6 Fragments, 524 RFC 5722, December 2009 526 10. Acknowledgments 528 Big Thanks to J. Touch who has prepared the word template document to 529 edit/write new RFC documents. It is really difficult to write a new 530 RFC without this template. This document was prepared using 2-Word- 531 v2.0.template.dot. 533 Appendix A. 534 IP Packet Reassembly Processing 536 |#define MAX_FRAGS 128 // A Value 65 is also good enough | 537 | | 538 |UINT32 g_max_label_sum[MAX_FRAGS + 1]; | 539 | | 540 |typedef struct { | 541 | UINT32 frag_rcvd_count; | 542 | UINT32 label_sum; | 543 | UINT32 max_possible_label_sum; | 544 | UINT32 context_created_timestamp; | 545 | UINT32 packet_ptr[MAX_FRAGS]; | 546 |} ip_reassembly_context_t; | 547 | | 548 |// This function initialize the sum of | 549 |// all possible labels for given fragment count | 550 |void init_label_sum_data() | 551 |{ | 552 | int i = 0; | 553 | for(i = 1; i <= MAX_FRAGS; i++) | 554 | { | 555 | if(1 == i) | 556 | g_max_label_sum[i] = 1; | 557 | else | 558 | g_max_label_sum[i] = g_max_label_sum[i-1] + i; | 559 | } | 560 |} | 561 | | 562 |// Example values: | 563 |g_max_label_sum[ 1] = 1 | 564 |g_max_label_sum[ 2] = 3 | 565 |g_max_label_sum[ 3] = 6 | 566 |g_max_label_sum[ 4] = 10 | 567 |g_max_label_sum[ 5] = 15 | 568 |g_max_label_sum[ 6] = 21 | 569 |g_max_label_sum[ 7] = 28 | 570 |g_max_label_sum[ 8] = 36 | 571 |g_max_label_sum[ 9] = 45 | 572 |g_max_label_sum[10] = 55 | 573 |g_max_label_sum[11] = 66 | 574 |g_max_label_sum[12] = 78 | 575 |g_max_label_sum[13] = 91 | 576 |g_max_label_sum[14] = 105 | 577 |g_max_label_sum[15] = 120 | 578 |g_max_label_sum[16] = 136 | 579 | | 580 |int fragment_reassembly_process() | 581 |{ | 582 | ip_reassembly_context_t *context = NULL; | 583 | uint16_t fragment_label = ip_hdr_ptr->fragment_label; | 584 | if(fragment_label > MAX_FRAGS) | 585 | { | 586 | // discard frame and report to management application | 587 | return -1; | 588 | } | 589 | | 590 | if(NULL == get_reassembly_context(ip_hdr_ptr, &context); | 591 | { | 592 | create_context(ip_hdr_ptr, &context); | 593 | } | 594 | | 595 | if(NULL == context->packet_ptr[fragment_label]; | 596 | { | 597 | context->packet_ptr[fragment_label] = ip_hdr_ptr; | 598 | } | 599 | else // Duplicate fragment | 600 | { | 601 | // MUST discard frame. Set this context as dirty context. | 602 | // Report to management plane. | 603 | return -1; | 604 | } | 605 | | 606 | context->label_sum += fragment_label; | 607 | context->frag_rcvd_count += 1; | 608 | | 609 | if(0 == ip_hdr_ptr->flags.mf_bit) // last fragment | 610 | { | 611 | context->max_possible_label_sum = \ | 612 | g_max_label_sum[fragment_label]; | 613 | } | 614 | if(context->max_possible_label_sum == context->label_sum) | 615 | { | 616 | // re-assembly complete, stitch fragments. | 617 | // Match the length of reassembled packet with 2 byte | 618 | // length value present in last 2 bytes in last fragment. | 619 | // If values do not matching, set this context as dirty | 620 | // and report to management plane | 621 | return 1; // reassembly job done | 622 | } | 623 | | 624 | return 0; // re-assembly not yet over | 625 |} | 626 | | 627 Copyright (c) 2018 IETF Trust and the persons identified as authors 628 of the code. All rights reserved. 630 Redistribution and use in source and binary forms, with or without 631 modification, are permitted provided that the following conditions 632 are met: 634 o Redistributions of source code must retain the above copyright 635 notice, this list of conditions and the following disclaimer. 637 o Redistributions in binary form must reproduce the above copyright 638 notice, this list of conditions and the following disclaimer in 639 the documentation and/or other materials provided with the 640 distribution. 642 o Neither the name of Internet Society, IETF or IETF Trust, nor the 643 names of specific contributors, may be used to endorse or promote 644 products derived from this software without specific prior written 645 permission. 647 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 648 "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT 649 LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR 650 A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT 651 OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, 652 SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT 653 LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, 654 DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY 655 THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT 656 (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE 657 OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 659 Author's Addresses 661 ABHISHEK BHATI 662 SAMSUNG ELECTRONICS 663 SAMSUNG R&D INSTITUTE, BENGALURU, INDIA 665 Phone: +91-9686500752 666 Email: ABH.BHATI@SAMSUNG.COM / AB.BHATI@GMAIL.COM