idnits 2.17.1 draft-bhati-intarea-frag-label-reassembly-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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. 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 25, 2016) is 2702 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: '10' is mentioned on line 585, but not defined == Missing Reference: '11' is mentioned on line 586, but not defined == Missing Reference: '12' is mentioned on line 587, but not defined == Missing Reference: '13' is mentioned on line 588, but not defined == Missing Reference: '14' is mentioned on line 589, but not defined == Missing Reference: '15' is mentioned on line 590, but not defined == Missing Reference: '16' is mentioned on line 591, but not defined == Unused Reference: '1' is defined on line 506, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 509, but no explicit reference was found in the text == Unused Reference: 'RFC2234' is defined on line 516, but no explicit reference was found in the text == Unused Reference: 'RFC 791' is defined on line 522, but no explicit reference was found in the text == Unused Reference: 'RFC 815' is defined on line 525, but no explicit reference was found in the text == Unused Reference: 'RFC 1858' is defined on line 528, but no explicit reference was found in the text == Unused Reference: 'RFC 2460' is defined on line 531, but no explicit reference was found in the text == Unused Reference: 'RFC 3514' is defined on line 534, but no explicit reference was found in the text == Unused Reference: 'RFC 5722' is defined on line 537, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (ref. '2') (Obsoleted by RFC 4234) -- Duplicate reference: RFC2119, mentioned in 'RFC2119', was also mentioned in '1'. -- Duplicate reference: RFC2234, mentioned in 'RFC2234', was also mentioned in '2'. ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) Summary: 2 errors (**), 0 flaws (~~), 18 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Area Working Group A. Bhati 2 Internet Draft Samsung Electronics 3 Intended status: Standards Track October 25, 2016 4 Expires: April 2017 6 Label Based IP Reassembly 7 draft-bhati-intarea-frag-label-reassembly-00.txt 9 Status of this Memo 11 This Internet-Draft is submitted in full conformance with the 12 provisions of BCP 78 and BCP 79. 14 This document may contain material from IETF Documents or IETF 15 Contributions published or made publicly available before November 16 10, 2008. The person(s) controlling the copyright in some of this 17 material may not have granted the IETF Trust the right to allow 18 modifications of such material outside the IETF Standards Process. 19 Without obtaining an adequate license from the person(s) controlling 20 the copyright in such materials, this document may not be modified 21 outside the IETF Standards Process, and derivative works of it may 22 not be created outside the IETF Standards Process, except to format 23 it for publication as an RFC or to translate it into languages other 24 than English. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 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 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html 42 This Internet-Draft will expire on April 25, 2017. 44 Copyright Notice 46 Copyright (c) 2016 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Abstract 61 This document describes a faster mechanism to re-assemble IPv4 and 62 IPv6 fragments when fragment labels are used instead of fragment 63 offset to reassemble the packets. 65 Table of Contents 67 1. Introduction...................................................4 68 2. Conventions used in this document..............................4 69 3. Changes from RFC 791...........................................5 70 4. IPv4 Fragment field discussion.................................6 71 4.1. Current status as per RFC 791.............................6 72 4.2. Changes suggested by this document........................7 73 4.3. Illustration of fragment label on IPv4 packet.............8 74 5. IPv6 Fragment header discussion...............................12 75 5.1. Current status as per RFC 2460...........................12 76 5.2. Changes suggested by this document.......................13 77 6. Security Considerations.......................................14 78 7. IANA Considerations...........................................15 79 8. Conclusions...................................................16 80 9. References....................................................17 81 9.1. Normative References.....................................17 82 9.2. Informative References...................................17 83 10. Acknowledgments..............................................18 84 Appendix A. IP Packet Reassembly Processing......................19 86 1. Introduction 88 IPv4 as originally defined in RFC 791, has 3 bits of flags field and 89 13 bits of fragment offset field to perform IP fragmentation and IP 90 re-assembly operations inside network nodes. 92 Ipv6 as originally defined in RFC 2460, defines fragment header which 93 has 2 reserved bits just before M flag bit and 13 bits of fragment 94 offset bits before 2 reserved bits. 96 The mechanisms to re-assemble all the fragments of an IP packet are 97 mainly implementation dependent. 99 This draft suggests the use of reserved bit in IPv4 flag bits as L 100 bit (fragment label bit). Whenever value of L bit is 0, 13 bits after 101 the flags field MUST be interpreted as fragment offset as defined in 102 RFC 791. If value of L bit is 1, 13 bits after the flags field MUST 103 be interpreted as fragment label. 105 Similarly this draft suggests the use of reserved bit just before M 106 flag bit in IPv6 fragment header as L bit (bit number 30). Whenever 107 value of L bit is 0, bits 16-28 in fragment header MUST be 108 interpreted as fragment offset as defined in RFC 2460. If value of L 109 bit is 1, bits 16-28 in fragment header MUST be interpreted as 110 fragment label. 112 Fragment label is a simple incrementing integer counter value 113 starting from value 1 for first fragment and incrementing by value 1 114 for subsequent fragments of IP packet. 116 2. Conventions used in this document 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in RFC 2119 [RFC2119]. 122 3. Changes from RFC 791 124 Everything that is described in RFC 791 will remain intact except the 125 interpretation of reserved bit in 3 bit flags field as L bit 126 (fragment label bit). However, interpretation of reserved bit as L 127 bit as suggested in this document obsoletes RFC 3514. 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 - Don't 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 - 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 - Don't 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 Original IP length (5140 bytes, hexadecimal value is 0x1414) is 346 written after the packed bytes present in last fragment. This value 347 is used for comparison of reassembled packet length against the 348 original packet length. These two bytes should be removed from the 349 re-assembled packet after comparison is done and found to be 350 matching. If values do not match, reassembly context should be marked 351 as dirty and report should be sent to management plane of network 352 entity (reassemble). 354 When these fragments are processed by IP reassembly process inside a 355 network node, fragment label value can be used to directly index into 356 the actual fragment position without any further calculation. This 357 can greatly increase the re-assembly process performance inside 358 network nodes. A sample code to reassemble IP fragments in this 359 scenario is provided in Appendix A. 361 5. IPv6 Fragment header discussion 363 5.1. Current status as per RFC 2460 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 |Next header | Reserved | fragment offset |X|X|M| 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+ 368 X - Reserved Bit 369 M - More Fragments Bit 371 Possible first fragment with MF bit 1 and fragment offset zero 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 |Next header | Reserved | zero fragment offset |X|X|1| 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+ 376 Possible fragment with MF bit 1 and non-zero fragment offset 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 |Next header | Reserved | non-zero fragment offset|X|X|1| 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+ 381 Possible Last fragment with MF bit 0 and non-zero fragment offset 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 |Next header | Reserved | non-zero fragment offset|X|X|0| 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+ 386 Fragment offset value starts from 0 and always be an integer multiple 387 of 8 bytes. If second fragment has value 128, it means first fragment 388 contains 1024 bytes (byte 0 - byte 1023). Second fragment contains 389 byte which was originally present at offset 1024 in non-fragmented IP 390 packet. 392 Note that there is no D bit inside IPv6 fragment header as no 393 intermediate network node can do further fragmentation. Only source 394 node is permitted to do fragmentation of Ipv6 packet. 396 5.2. Changes suggested by this document 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 |Next header | Reserved | fragment offset |X|L|M| 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+ 401 L - Fragment Label Indicator Bit (new addition) 402 M - More Fragments Bit 404 Possible fragment with L bit 1, MF bit 1 and non-zero fragment label 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 |Next header | Reserved | non-zero fragment label |X|1|1| 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+ 409 Possible last fragment with L bit 1, MF bit 0 and non-zero fragment 410 label 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 |Next header | Reserved | non-zero fragment label |X|1|0| 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+ 415 Fragment label is always a non-zero value starting from integer 1. 417 If L bit is 0, bits 16-28 MUST be interpreted as fragment offset 418 field. 420 If L bit is 1, bits 16-28 MUST be interpreted as fragment label 421 field. 423 6. Security Considerations 425 Let's call the network entity which performs fragmentation of IP 426 packet as fragmentor and the network entity which performs reassembly 427 as reassembler. 429 This draft document suggests adding extra two bytes at the end in the 430 last fragment of IP packet produced by the fragmentor. 432 Fragmentor should write the value of original IP total length value 433 (IP length field in large un-fragmented packet) in these two bytes. 435 Reassemblor should match the value present in those 2 bytes against 436 the total length which is reassembled by the reassemblor. If the 437 values do not match, there is a possibility of malformed fragment 438 received by the reassembler. In this case, all the fragments for the 439 context should be discarded and the event should be reported to 440 management plane of reassembler. 442 This mechanism will ensure that no middle-man can possibly add or 443 truncate data bytes from the fragments. 445 The only possibility where a middle-man can add or truncate some 446 bytes in fragments is to have complete knowledge of last fragment and 447 the fragment which he wishes to change. 449 If reassembler receives any duplicate fragment label which was 450 already received earlier for a context, then all fragments for the 451 context shall be discarded and the event should be reported to 452 management plane of reassembler. 454 7. IANA Considerations 456 This draft document proposes the following registry to be maintained 457 by IANA. 459 Flags bits of IPv4 header. 461 ------------------------------------------------- 463 Bit 0: L bit [fragment label bit] 465 If value of this bit is 0, 13 bits after flags field MUST be 466 interpreted as fragment offset field as defined in RFC 791. 468 If value of this bit is 1, 13 bits after flags field MUST be 469 interpreted as fragment label field. 471 Assignment of Bit 0 as L bit obsoletes the evil bit of RFC 3514. 473 Fragment header of IPv6 header. 475 ------------------------------------------------- 477 Bit 30: L bit [fragment label bit] 479 If value of this bit is 0, bits 16-28 MUST be interpreted as fragment 480 offset field as defined in RFC 2460. 482 If value of this bit is 1, bits 16-28 MUST be interpreted as fragment 483 label field. 485 8. Conclusions 487 This draft document proposes the use of reserved bit in IPv4 header 488 flags field as L bit [offset versus label bit] to enable direct index 489 based IPv4 packet re-assembly. 491 Similarly, this draft document proposes the use of bit 30 in IPv6 492 fragment header as L bit [offset versus label bit] to enable direct 493 index based IPv6 packet re-assembly. 495 Network nodes MUST look at offset versus label bit before deciding 496 upon the algorithm to re-assemble IP fragments. If value of L bit is 497 1, the direct index based fragment re-assembly MUST be used for fast 498 re-assembly. This avoids any further calculations required to place a 499 fragment at its correct position inside the reassembly chain. These 500 calculations are explained in RFC 815. 502 9. References 504 9.1. Normative References 506 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 507 Levels", BCP 14, RFC 2119, March 1997. 509 [2] Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax 510 Specifications: ABNF", RFC 2234, Internet Mail Consortium and 511 Demon Internet Ltd., November 1997. 513 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 514 Requirement Levels", BCP 14, RFC 2119, March 1997. 516 [RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for 517 Syntax Specifications: ABNF", RFC 2234, Internet Mail 518 Consortium and Demon Internet Ltd., November 1997. 520 9.2. Informative References 522 [RFC 791] by Information Sciences Institute, University of Southern 523 California, "INTERNET PROTOCOL", RFC 791, September 1981 525 [RFC 815] by David D. Clark, "IP DATAGRAM REASSEMBLY ALGORITHMS", RFC 526 815, July 1982 528 [RFC 1858] by G. Ziemba, D. Reed, P. Traina, "Security Considerations 529 for IP fragment filtering", RFC 1858, October 1995 531 [RFC 2460] by S. Deering, R. Hinden, "Internet Protocol Version 6 532 (IPv6) Specification", RFC 2460, December 1998 534 [RFC 3514] by S. Bellovin, "The Security Flag in the IPv4 Header", 535 RFC 3514, April 2003 537 [RFC 5722] by S. Krishnan, "Handling of Overlapping IPv6 Fragments", 538 RFC 5722, December 2009 540 10. Acknowledgments 542 Big Thanks to J. Touch who has prepared the word template document to 543 edit/write new RFC documents. It is really difficult to write a new 544 RFC without this template. This document was prepared using 2-Word- 545 v2.0.template.dot. 547 Appendix A. IP Packet Reassembly Processing 549 |#define MAX_FRAGS 128 // A Value 65 is also good enough | 550 | | 551 |UINT32 g_max_label_sum[MAX_FRAGS + 1]; | 552 | | 553 |typedef struct { | 554 | UINT32 frag_rcvd_count; | 555 | UINT32 label_sum; | 556 | UINT32 max_possible_label_sum; | 557 | UINT32 context_created_timestamp; | 558 | UINT32 packet_ptr[MAX_FRAGS]; | 559 |} ip_reassembly_context_t; | 560 | | 561 |// This function initialize the sum of | 562 |// all possible labels for given fragment count | 563 |void init_label_sum_data() | 564 |{ | 565 | int i = 0; | 566 | for(i = 1; i <= MAX_FRAGS; i++) | 567 | { | 568 | if(1 == i) | 569 | g_max_label_sum[i] = 1; | 570 | else | 571 | g_max_label_sum[i] = g_max_label_sum[i-1] + i; | 572 | } | 573 |} | 574 | | 575 |// Example values: | 576 |g_max_label_sum[ 1] = 1 | 577 |g_max_label_sum[ 2] = 3 | 578 |g_max_label_sum[ 3] = 6 | 579 |g_max_label_sum[ 4] = 10 | 580 |g_max_label_sum[ 5] = 15 | 581 |g_max_label_sum[ 6] = 21 | 582 |g_max_label_sum[ 7] = 28 | 583 |g_max_label_sum[ 8] = 36 | 584 |g_max_label_sum[ 9] = 45 | 585 |g_max_label_sum[10] = 55 | 586 |g_max_label_sum[11] = 66 | 587 |g_max_label_sum[12] = 78 | 588 |g_max_label_sum[13] = 91 | 589 |g_max_label_sum[14] = 105 | 590 |g_max_label_sum[15] = 120 | 591 |g_max_label_sum[16] = 136 | 592 | | 593 |int fragment_reassembly_process() | 594 |{ | 595 | ip_reassembly_context_t *context = NULL; | 596 | uint16_t fragment_label = ip_hdr_ptr->fragment_label; | 597 | if(fragment_label > MAX_FRAGS) | 598 | { | 599 | // discard frame and report to management application | 600 | return -1; | 601 | } | 602 | | 603 | if(NULL == get_reassembly_context(ip_hdr_ptr->id, &context); | 604 | { | 605 | create_context(&context); | 606 | } | 607 | | 608 | if(NULL == context->packet_ptr[fragment_label]; | 609 | { | 610 | context->packet_ptr[fragment_label] = ip_hdr_ptr; | 611 | } | 612 | else // Duplicate fragment | 613 | { | 614 | // MUST discard frame. Set this context as dirty context. | 615 | // Report to management plane. | 616 | return -1; | 617 | } | 618 | | 619 | context->label_sum += fragment_label; | 620 | context->frag_rcvd_count += 1; | 621 | | 622 | if(0 == ip_hdr_ptr->flags.mf_bit) // last fragment | 623 | { | 624 | context->max_possible_label_sum = \ | 625 | g_max_label_sum[fragment_label]; | 626 | } | 627 | if(context->max_possible_label_sum == context->label_sum) | 628 | { | 629 | // re-assembly complete, stitch fragments. | 630 | // Match the length of reassembled packet with 2 byte | 631 | // length value present in last 2 bytes in last fragment. | 632 | // If values do not matching, set this context as dirty | 633 | // and report to management plane | 634 | return 1; // reassembly job done | 635 | } | 636 | | 637 | return 0; // re-assembly not yet over | 638 |} | 639 | | 640 Copyright (c) 2016 IETF Trust and the persons identified as authors 641 of the code. All rights reserved. 643 Redistribution and use in source and binary forms, with or without 644 modification, are permitted provided that the following conditions 645 are met: 647 o Redistributions of source code must retain the above copyright 648 notice, this list of conditions and the following disclaimer. 650 o Redistributions in binary form must reproduce the above copyright 651 notice, this list of conditions and the following disclaimer in 652 the documentation and/or other materials provided with the 653 distribution. 655 o Neither the name of Internet Society, IETF or IETF Trust, nor the 656 names of specific contributors, may be used to endorse or promote 657 products derived from this software without specific prior written 658 permission. 660 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 661 "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT 662 LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR 663 A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT 664 OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, 665 SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT 666 LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, 667 DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY 668 THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT 669 (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE 670 OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 672 Authors' Addresses 674 ABHISHEK BHATI 675 SAMSUNG ELECTRONICS 676 SAMSUNG R&D INSTITUTE, BENGALURU, INDIA 678 Phone: +91-9686500752 679 Email: ABH.BHATI@SAMSUNG.COM / AB.BHATI@GMAIL.COM