| Network Working Group | M. Andrews |
| Internet-Draft | ISC |
| Aug 2013 |
IPv6 Stateless Fragmentation Identification Options
draft-andrews-6man-fragopt-01.txt
Fragmented IPv6 packets are often dropped because there is no way to identify whether a fragment matches a otherwise permitted packet as the L4 header information is not available on all the fragments.
The document defines hop-by-hop options that can be used to supply the missing information in non initial fragments.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
Copyright (c) 2013 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.
Fragmented IPv6 packets are often dropped because there is no way to identify whether a fragment matches a otherwise permitted packet as the L4 header information is not available on all the fragments.
The document defines hop-by-hop options that can be used to supply the missing information in non initial fragments.
The information required differs depending upon the L4 packet. For TCP and UDP the source and destination ports are needed. For ICMP the type of ICMP packet is needed.
These options are expected to be used by middle boxes (firewalls and load balancers) and end nodes.
For TCP and UDP a skippable hop-by-hop option [RFC2460] (for backwards compatibility) containing the source and destination ports from the TCP and UDP headers is needed. To permit the use of NATs, however undesired, the option contents are marked changeable enroute. The option code has mnemonic PORTS and value (TBD) and is added to all fragments of UDP and TCP packets when they are fragmented. By adding the option to all fragments you reduce the amount of fragmentation reassembly failures that would result if you only added the option to non-initial fragments and were dropping non-initial fragments without this option.
NAT should update the port fields to match those in the TCP and UDP headers if it updates those fields as part of the NAT processing.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0|1| (TBD) | 4 | source port |
+---------------+---------------+---------------+---------------+
| destination port |
+-------------------------------+
To identify the type of ICMPv6 packet a fragment is part of the type and code values need to be copied from the ICMPv6 header. As with the TCP and UDP case, a skippable hop-by-hop option is required. ICMPv6 type and code points are not changed by NAT so a immutable hop-by-hop option could be used.
In most cases a ICMPv6 error message won't need to be fragmented as the maximum size of a ICMPv6
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0|0| (TBD) | 2 | type | code |
+---------------+---------------+---------------+---------------+
For IPv4 in IPv6 the IPv4 source and destination addresses are needed.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0|0| (TBD) | 8 | IPv4 source address ~
+---------------+---------------+---------------+---------------+
~ IPv4 source address | IPv4 destination address ~
+---------------+---------------+---------------+---------------+
~ IPv4 destination address |
+---------------+---------------+
For IPv6 in IPv6 the IPv6 source and destination addresses are needed.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0|0| (TBD) | 32 | IPv6 source address ~
+---------------+---------------+---------------+---------------+
~ IPv6 source address ~
+---------------+---------------+---------------+---------------+
~ IPv6 source address | IPv6 destination address ~
+---------------+---------------+---------------+---------------+
~ IPv6 destination address ~
+---------------+---------------+---------------+---------------+
~ IPv6 destination address |
+---------------+---------------+
Should this be a single hop-by-hop option or multiple hop-by-hop options?
If a single hop-by-hop option, should it include the next header field of the fragment header or should this be implicit?
To be completed.
The use of these options will expose nodes to more fragmentation based attacks and potentially more traffic which will ultimately be dropped if a attacker can guess which option values will be permitted.
With the exception of the fragmentation based attacks, permitting fragments with these options is no worse that permitting multiple un-fragmented packets based in the same parameters.
When reassembling a packet all fragments of a packet should have a identical fragment identification option and it should be on all fragment or on none of the fragments.
For TCP and UDP the ports values may or may not match up with those of the un-fragmented packet when the packet has been through a NAT. When a packet has passed through multiple NAT boxes that are unaware of this option both the source and destination ports may have been changed so the ports may appear to be completely unrelated. The source port is changed by a client NAT and the destination port is changed by a NAT acting a load balancer.
| [RFC2460] | Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. |