Internet DRAFT - draft-bhati-intarea-ip-reassembly-using-labels
draft-bhati-intarea-ip-reassembly-using-labels
Internet Area Working Group A. Bhati
Internet Draft Samsung Electronics
Intended status: Informational October 4, 2018
Expires: April 2019
IP Reassembly Using Labels
draft-bhati-intarea-ip-reassembly-using-labels-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 4, 2017.
Bhati Expires April 4, 2019 [Page 1]
Internet-Draft IP Reassembly Using Labels October 2018
Copyright Notice
Copyright (c) 2018 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 4, 2019 [Page 2]
Internet-Draft IP Reassembly Using Labels October 2018
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 4, 2019 [Page 3]
Internet-Draft IP Reassembly Using Labels October 2018
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 4, 2019 [Page 4]
Internet-Draft IP Reassembly Using Labels October 2018
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).
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 4, 2019 [Page 5]
Internet-Draft IP Reassembly Using Labels October 2018
4. IPv4 Fragment field discussion
4.1. Current status as per RFC 791
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|X|D|M| fragment offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
X Reserved Bit
D Do not 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 to byte 1023). Second fragment contains
byte which was originally present at offset 1024 in non-fragmented IP
packet.
Bhati Expires April 4, 2019 [Page 6]
Internet-Draft IP Reassembly Using Labels October 2018
4.2. Changes suggested by this document
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L|D|M| fragment offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L Fragment Label Indicator Bit
D Do not 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 4, 2019 [Page 7]
Internet-Draft IP Reassembly Using Labels October 2018
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 4, 2019 [Page 8]
Internet-Draft IP Reassembly Using Labels October 2018
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 4, 2019 [Page 9]
Internet-Draft IP Reassembly Using Labels October 2018
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 4, 2019 [Page 10]
Internet-Draft IP Reassembly Using Labels October 2018
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.
For last fragment, original IP length (5140 bytes) is written in last
fragment, which is used for comparison of reassembled bytes against
the original length. These two bytes should be removed from the re-
assembled packet after comparison is done and found to be matching.
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 4, 2019 [Page 11]
Internet-Draft IP Reassembly Using Labels October 2018
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 to 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 4, 2019 [Page 12]
Internet-Draft IP Reassembly Using Labels October 2018
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 ne interpreted as fragment label
field.
Bhati Expires April 4, 2019 [Page 13]
Internet-Draft IP Reassembly Using Labels October 2018
6. Security Considerations
Let us 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 4, 2019 [Page 14]
Internet-Draft IP Reassembly Using Labels October 2018
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.
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 4, 2019 [Page 15]
Internet-Draft IP Reassembly Using Labels October 2018
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 4, 2019 [Page 16]
Internet-Draft IP Reassembly Using Labels October 2018
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.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 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 4, 2019 [Page 17]
Internet-Draft IP Reassembly Using Labels October 2018
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 4, 2019 [Page 18]
Internet-Draft IP Reassembly Using Labels October 2018
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 4, 2019 [Page 19]
Internet-Draft IP Reassembly Using Labels October 2018
|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, &context); |
| { |
| create_context(ip_hdr_ptr, &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 4, 2019 [Page 20]
Internet-Draft IP Reassembly Using Labels October 2018
Copyright (c) 2018 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 4, 2019 [Page 21]
Internet-Draft IP Reassembly Using Labels October 2018
Author's 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 4, 2019 [Page 22]
