Internet Area Working Group A. Bhati Internet Draft Samsung Electronics Intended status: Standards Track October 25, 2016 Expires: April 2017 Label Based IP Reassembly draft-bhati-intarea-frag-label-reassembly-00.txt Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. 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/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on April 25, 2017. Bhati Expires April 25, 2017 [Page 1] Internet-Draft Label Based IP Reassembly October 2016 Copyright Notice Copyright (c) 2016 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 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Bhati Expires April 25, 2017 [Page 2] Internet-Draft Label Based IP Reassembly October 2016 Abstract This document describes a faster mechanism to re-assemble IPv4 and IPv6 fragments when fragment labels are used instead of fragment offset to reassemble the packets. Table of Contents 1. Introduction...................................................4 2. Conventions used in this document..............................4 3. Changes from RFC 791...........................................5 4. IPv4 Fragment field discussion.................................6 4.1. Current status as per RFC 791.............................6 4.2. Changes suggested by this document........................7 4.3. Illustration of fragment label on IPv4 packet.............8 5. IPv6 Fragment header discussion...............................12 5.1. Current status as per RFC 2460...........................12 5.2. Changes suggested by this document.......................13 6. Security Considerations.......................................14 7. IANA Considerations...........................................15 8. Conclusions...................................................16 9. References....................................................17 9.1. Normative References.....................................17 9.2. Informative References...................................17 10. Acknowledgments..............................................18 Appendix A. IP Packet Reassembly Processing......................19 Bhati Expires April 25, 2017 [Page 3] Internet-Draft Label Based IP Reassembly October 2016 1. Introduction IPv4 as originally defined in RFC 791, has 3 bits of flags field and 13 bits of fragment offset field to perform IP fragmentation and IP re-assembly operations inside network nodes. Ipv6 as originally defined in RFC 2460, defines fragment header which has 2 reserved bits just before M flag bit and 13 bits of fragment offset bits before 2 reserved bits. The mechanisms to re-assemble all the fragments of an IP packet are mainly implementation dependent. This draft suggests the use of reserved bit in IPv4 flag bits as L bit (fragment label bit). Whenever value of L bit is 0, 13 bits after the flags field MUST be interpreted as fragment offset as defined in RFC 791. If value of L bit is 1, 13 bits after the flags field MUST be interpreted as fragment label. Similarly this draft suggests the use of reserved bit just before M flag bit in IPv6 fragment header as L bit (bit number 30). Whenever value of L bit is 0, bits 16-28 in fragment header MUST be interpreted as fragment offset as defined in RFC 2460. If value of L bit is 1, bits 16-28 in fragment header MUST be interpreted as fragment label. Fragment label is a simple incrementing integer counter value starting from value 1 for first fragment and incrementing by value 1 for subsequent fragments of IP packet. 2. Conventions used in this document 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]. Bhati Expires April 25, 2017 [Page 4] Internet-Draft Label Based IP Reassembly October 2016 3. Changes from RFC 791 Everything that is described in RFC 791 will remain intact except the interpretation of reserved bit in 3 bit flags field as L bit (fragment label bit). However, interpretation of reserved bit as L bit as suggested in this document obsoletes RFC 3514. Everything that is described for fragment header in RFC 2460 will remain intact except the interpretation of bit number 30 as L bit (fragment label bit). Bhati Expires April 25, 2017 [Page 5] Internet-Draft Label Based IP Reassembly October 2016 4. IPv4 Fragment field discussion 4.1. Current status as per RFC 791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |X|D|M| fragment offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ X - Reserved Bit D - Don't Fragment Bit M - More Fragments Bit Possible fragment with MF bit 1 and zero fragment offset +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|1| zero fragment offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Possible fragment with MF bit 1 and non-zero fragment offset +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|1| non-zero fragment offset| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Possible Last fragment with MF bit 0 and non-zero fragment offset +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|0|non-zero fragment offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fragment offset value starts from 0 and always be an integer multiple of 8 bytes. If second fragment has value 128, it means first fragment contains 1024 bytes (byte 0 - byte 1023). Second fragment contains byte which was originally present at offset 1024 in non-fragmented IP packet. Bhati Expires April 25, 2017 [Page 6] Internet-Draft Label Based IP Reassembly October 2016 4.2. Changes suggested by this document +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L|D|M| fragment offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ L - Fragment Label Indicator Bit D - Don't Fragment Bit M - More Fragments Bit Possible fragment with L bit 1, MF bit 1, and non-zero label +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|1|non-zero fragment label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Possible last fragment with L bit 1, MF bit 0, and non-zero label +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0|non-zero fragment label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fragment label is always a non-zero value starting from integer 1. Note that while using mechanism of putting fragment labels instead of fragments offset, there is no restriction to put fragment data which is multiple of 8 bytes in each but last fragment. It is up to fragmentation implementation to decide how many bytes to be kept in any fragment as per the convenience. It is RECOMMENDED to put at least 1024 bytes in each but last fragment so that receiver can re-assemble those fragments using only 64 fragment labels. Another guideline is to keep number of bytes in a fragment equal to integer multiple of machine word size on which implementation is executing. This will avoid data access across word size boundaries and improves performance. Sample re-assembly pseudo code of approximate 30 lines is provided in Appendix A. Bhati Expires April 25, 2017 [Page 7] Internet-Draft Label Based IP Reassembly October 2016 4.3. Illustration of fragment label on IPv4 packet The following example illustrates the fragmentation operation on an example IPv4 packet which has 5120 bytes of payload. IP header length is 20 bytes and total length field is thus equal to 5140 bytes. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Header | | Version = 4 | | Header Length = 5 (20 bytes) | | TOS = 0 | | Total Length = 5140 bytes (includes 20 bytes of IP header) | | ID = 1234 | | Flags [L_bit = 0, D_bit = 0, M_bit = 0] | | Fragment offset / Fragment_label = 0x0 | | TTL = 64 | | Protocol = xyz | | Checksum = valid checksum value | | Source IP = 0x01010101 | | Destination IP = 0x02020202 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |abcdabcdabcdabcdabcdabcd(1024 bytes)abcdabcdabcdabcdabcdabcdabc| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |abcdabcdabcdabcdabcdabcd(1024 bytes)abcdabcdabcdabcdabcdabcdabc| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |abcdabcdabcdabcdabcdabcd(1024 bytes)abcdabcdabcdabcdabcdabcdabc| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |abcdabcdabcdabcdabcdabcd(1024 bytes)abcdabcdabcdabcdabcdabcdabc| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |abcdabcdabcdabcdabcdabcd(1024 bytes)abcdabcdabcdabcdabcdabcdabc| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Bhati Expires April 25, 2017 [Page 8] Internet-Draft Label Based IP Reassembly October 2016 The above packet is fragmented into 5 fragments as follows: First fragment: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Header | | Version = 4 | | Header Length = 5 (20 bytes) | | TOS = 0 | | Total Length = 1044 bytes (includes 20 bytes of IP header) | | ID = 1234 | | Flags [L_bit = 1, D_bit = 0, M_bit = 1] | | Fragment offset / Fragment Label = 1 | | TTL = 64 | | Protocol = xyz | | Checksum = valid checksum value | | Source IP = 0x01010101 | | Destination IP = 0x02020202 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |abcdabcdabcdabcdabcdabcd(1024 bytes)abcdabcdabcdabcdabcdabcdabc| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Second fragment: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Header | | Version = 4 | | Header Length = 5 (20 bytes) | | TOS = 0 | | Total Length = 1044 bytes (includes 20 bytes of IP header) | | ID = 1234 | | Flags [L_bit = 1, D_bit = 0, M_bit = 1] | | Fragment offset / Fragment label = 2 | | TTL = 64 | | Protocol = xyz | | Checksum = valid checksum value | | Source IP = 0x01010101 | | Destination IP = 0x02020202 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |abcdabcdabcdabcdabcdabcd(1024 bytes)abcdabcdabcdabcdabcdabcdabc| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Bhati Expires April 25, 2017 [Page 9] Internet-Draft Label Based IP Reassembly October 2016 Third fragment: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Header | | Version = 4 | | Header Length = 5 (20 bytes) | | TOS = 0 | | Total Length = 1044 bytes (includes 20 bytes of IP header) | | ID = 1234 | | Flags [L_bit = 1, D_bit = 0, M_bit = 1] | | Fragment offset / Fragment label = 3 | | TTL = 64 | | Protocol = xyz | | Checksum = valid checksum value | | Source IP = 0x01010101 | | Destination IP = 0x02020202 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |abcdabcdabcdabcdabcdabcd(1024 bytes)abcdabcdabcdabcdabcdabcdabc| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fourth fragment: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Header | | Version = 4 | | Header Length = 5 (20 bytes) | | TOS = 0 | | Total Length = 1044 bytes (includes 20 bytes of IP header) | | ID = 1234 | | Flags [L_bit = 1, D_bit = 0, M_bit = 1] | | Fragment offset / Fragment label = 4 | | TTL = 64 | | Protocol = xyz | | Checksum = valid checksum value | | Source IP = 0x01010101 | | Destination IP = 0x02020202 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |abcdabcdabcdabcdabcdabcd(1024 bytes)abcdabcdabcdabcdabcdabcdabc| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Bhati Expires April 25, 2017 [Page 10] Internet-Draft Label Based IP Reassembly October 2016 Fifth and Final fragment: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Header | | Version = 4 | | Header Length = 5 (20 bytes) | | TOS = 0 | | Total Length = 1046 bytes (includes 20 bytes of IP header) | | ID = 1234 | | Flags [L_bit = 1, D_bit = 0, M_bit = 0] | | Fragment offset / Fragment label = 5 | | TTL = 64 | | Protocol = xyz | | Checksum = valid checksum value | | Source IP = 0x01010101 | | Destination IP = 0x02020202 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |abcdabcdabcdabcdabcdabcd(1024 + 2 bytes)abcdabcdabcdabcdabcdabc| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| |1414 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Note that if value of L bit is 1, 13 bits after flags field is interpreted as fragment label instead of fragment offset. Note that implementation is free to pack more than 1024 bytes in each fragment as per link MTU size. This example is packing only 1024 bytes per fragment for easy understanding of the concept. Original IP length (5140 bytes, hexadecimal value is 0x1414) is written after the packed bytes present in last fragment. This value is used for comparison of reassembled packet length against the original packet length. These two bytes should be removed from the re-assembled packet after comparison is done and found to be matching. If values do not match, reassembly context should be marked as dirty and report should be sent to management plane of network entity (reassemble). When these fragments are processed by IP reassembly process inside a network node, fragment label value can be used to directly index into the actual fragment position without any further calculation. This can greatly increase the re-assembly process performance inside network nodes. A sample code to reassemble IP fragments in this scenario is provided in Appendix A. Bhati Expires April 25, 2017 [Page 11] Internet-Draft Label Based IP Reassembly October 2016 5. IPv6 Fragment header discussion 5.1. Current status as per RFC 2460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Next header | Reserved | fragment offset |X|X|M| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+ X - Reserved Bit M - More Fragments Bit Possible first fragment with MF bit 1 and fragment offset zero +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Next header | Reserved | zero fragment offset |X|X|1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+ Possible fragment with MF bit 1 and non-zero fragment offset +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Next header | Reserved | non-zero fragment offset|X|X|1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+ Possible Last fragment with MF bit 0 and non-zero fragment offset +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Next header | Reserved | non-zero fragment offset|X|X|0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+ Fragment offset value starts from 0 and always be an integer multiple of 8 bytes. If second fragment has value 128, it means first fragment contains 1024 bytes (byte 0 - byte 1023). Second fragment contains byte which was originally present at offset 1024 in non-fragmented IP packet. Note that there is no D bit inside IPv6 fragment header as no intermediate network node can do further fragmentation. Only source node is permitted to do fragmentation of Ipv6 packet. Bhati Expires April 25, 2017 [Page 12] Internet-Draft Label Based IP Reassembly October 2016 5.2. Changes suggested by this document +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Next header | Reserved | fragment offset |X|L|M| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+ L - Fragment Label Indicator Bit (new addition) M - More Fragments Bit Possible fragment with L bit 1, MF bit 1 and non-zero fragment label +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Next header | Reserved | non-zero fragment label |X|1|1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+ Possible last fragment with L bit 1, MF bit 0 and non-zero fragment label +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Next header | Reserved | non-zero fragment label |X|1|0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+ Fragment label is always a non-zero value starting from integer 1. If L bit is 0, bits 16-28 MUST be interpreted as fragment offset field. If L bit is 1, bits 16-28 MUST be interpreted as fragment label field. Bhati Expires April 25, 2017 [Page 13] Internet-Draft Label Based IP Reassembly October 2016 6. Security Considerations Let's call the network entity which performs fragmentation of IP packet as fragmentor and the network entity which performs reassembly as reassembler. This draft document suggests adding extra two bytes at the end in the last fragment of IP packet produced by the fragmentor. Fragmentor should write the value of original IP total length value (IP length field in large un-fragmented packet) in these two bytes. Reassemblor should match the value present in those 2 bytes against the total length which is reassembled by the reassemblor. If the values do not match, there is a possibility of malformed fragment received by the reassembler. In this case, all the fragments for the context should be discarded and the event should be reported to management plane of reassembler. This mechanism will ensure that no middle-man can possibly add or truncate data bytes from the fragments. The only possibility where a middle-man can add or truncate some bytes in fragments is to have complete knowledge of last fragment and the fragment which he wishes to change. If reassembler receives any duplicate fragment label which was already received earlier for a context, then all fragments for the context shall be discarded and the event should be reported to management plane of reassembler. Bhati Expires April 25, 2017 [Page 14] Internet-Draft Label Based IP Reassembly October 2016 7. IANA Considerations This draft document proposes the following registry to be maintained by IANA. Flags bits of IPv4 header. ------------------------------------------------- Bit 0: L bit [fragment label bit] If value of this bit is 0, 13 bits after flags field MUST be interpreted as fragment offset field as defined in RFC 791. If value of this bit is 1, 13 bits after flags field MUST be interpreted as fragment label field. Assignment of Bit 0 as L bit obsoletes the evil bit of RFC 3514. Fragment header of IPv6 header. ------------------------------------------------- Bit 30: L bit [fragment label bit] If value of this bit is 0, bits 16-28 MUST be interpreted as fragment offset field as defined in RFC 2460. If value of this bit is 1, bits 16-28 MUST be interpreted as fragment label field. Bhati Expires April 25, 2017 [Page 15] Internet-Draft Label Based IP Reassembly October 2016 8. Conclusions This draft document proposes the use of reserved bit in IPv4 header flags field as L bit [offset versus label bit] to enable direct index based IPv4 packet re-assembly. Similarly, this draft document proposes the use of bit 30 in IPv6 fragment header as L bit [offset versus label bit] to enable direct index based IPv6 packet re-assembly. Network nodes MUST look at offset versus label bit before deciding upon the algorithm to re-assemble IP fragments. If value of L bit is 1, the direct index based fragment re-assembly MUST be used for fast re-assembly. This avoids any further calculations required to place a fragment at its correct position inside the reassembly chain. These calculations are explained in RFC 815. Bhati Expires April 25, 2017 [Page 16] Internet-Draft Label Based IP Reassembly October 2016 9. References 9.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, Internet Mail Consortium and Demon Internet Ltd., November 1997. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, Internet Mail Consortium and Demon Internet Ltd., November 1997. 9.2. Informative References [RFC 791] by Information Sciences Institute, University of Southern California, "INTERNET PROTOCOL", RFC 791, September 1981 [RFC 815] by David D. Clark, "IP DATAGRAM REASSEMBLY ALGORITHMS", RFC 815, July 1982 [RFC 1858] by G. Ziemba, D. Reed, P. Traina, "Security Considerations for IP fragment filtering", RFC 1858, October 1995 [RFC 2460] by S. Deering, R. Hinden, "Internet Protocol Version 6 (IPv6) Specification", RFC 2460, December 1998 [RFC 3514] by S. Bellovin, "The Security Flag in the IPv4 Header", RFC 3514, April 2003 [RFC 5722] by S. Krishnan, "Handling of Overlapping IPv6 Fragments", RFC 5722, December 2009 Bhati Expires April 25, 2017 [Page 17] Internet-Draft Label Based IP Reassembly October 2016 10. Acknowledgments Big Thanks to J. Touch who has prepared the word template document to edit/write new RFC documents. It is really difficult to write a new RFC without this template. This document was prepared using 2-Word- v2.0.template.dot. Bhati Expires April 25, 2017 [Page 18] Internet-Draft Label Based IP Reassembly October 2016 Appendix A. IP Packet Reassembly Processing |#define MAX_FRAGS 128 // A Value 65 is also good enough | | | |UINT32 g_max_label_sum[MAX_FRAGS + 1]; | | | |typedef struct { | | UINT32 frag_rcvd_count; | | UINT32 label_sum; | | UINT32 max_possible_label_sum; | | UINT32 context_created_timestamp; | | UINT32 packet_ptr[MAX_FRAGS]; | |} ip_reassembly_context_t; | | | |// This function initialize the sum of | |// all possible labels for given fragment count | |void init_label_sum_data() | |{ | | int i = 0; | | for(i = 1; i <= MAX_FRAGS; i++) | | { | | if(1 == i) | | g_max_label_sum[i] = 1; | | else | | g_max_label_sum[i] = g_max_label_sum[i-1] + i; | | } | |} | | | |// Example values: | |g_max_label_sum[ 1] = 1 | |g_max_label_sum[ 2] = 3 | |g_max_label_sum[ 3] = 6 | |g_max_label_sum[ 4] = 10 | |g_max_label_sum[ 5] = 15 | |g_max_label_sum[ 6] = 21 | |g_max_label_sum[ 7] = 28 | |g_max_label_sum[ 8] = 36 | |g_max_label_sum[ 9] = 45 | |g_max_label_sum[10] = 55 | |g_max_label_sum[11] = 66 | |g_max_label_sum[12] = 78 | |g_max_label_sum[13] = 91 | |g_max_label_sum[14] = 105 | |g_max_label_sum[15] = 120 | |g_max_label_sum[16] = 136 | | | Bhati Expires April 25, 2017 [Page 19] Internet-Draft Label Based IP Reassembly October 2016 |int fragment_reassembly_process() | |{ | | ip_reassembly_context_t *context = NULL; | | uint16_t fragment_label = ip_hdr_ptr->fragment_label; | | if(fragment_label > MAX_FRAGS) | | { | | // discard frame and report to management application | | return -1; | | } | | | | if(NULL == get_reassembly_context(ip_hdr_ptr->id, &context); | | { | | create_context(&context); | | } | | | | if(NULL == context->packet_ptr[fragment_label]; | | { | | context->packet_ptr[fragment_label] = ip_hdr_ptr; | | } | | else // Duplicate fragment | | { | | // MUST discard frame. Set this context as dirty context. | | // Report to management plane. | | return -1; | | } | | | | context->label_sum += fragment_label; | | context->frag_rcvd_count += 1; | | | | if(0 == ip_hdr_ptr->flags.mf_bit) // last fragment | | { | | context->max_possible_label_sum = \ | | g_max_label_sum[fragment_label]; | | } | | if(context->max_possible_label_sum == context->label_sum) | | { | | // re-assembly complete, stitch fragments. | | // Match the length of reassembled packet with 2 byte | | // length value present in last 2 bytes in last fragment. | | // If values do not matching, set this context as dirty | | // and report to management plane | | return 1; // reassembly job done | | } | | | | return 0; // re-assembly not yet over | |} | | | Bhati Expires April 25, 2017 [Page 20] Internet-Draft Label Based IP Reassembly October 2016 Copyright (c) 2016 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: o Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. o Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. o Neither the name of Internet Society, IETF or IETF Trust, nor the names of specific contributors, may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. Bhati Expires April 25, 2017 [Page 21] Internet-Draft Label Based IP Reassembly October 2016 Authors' Addresses ABHISHEK BHATI SAMSUNG ELECTRONICS SAMSUNG R&D INSTITUTE, BENGALURU, INDIA Phone: +91-9686500752 Email: ABH.BHATI@SAMSUNG.COM / AB.BHATI@GMAIL.COM Bhati Expires April 25, 2017 [Page 22]