< draft-andrews-6man-fragopt-00.txt   draft-andrews-6man-fragopt-01.txt >
Network Working Group M. Andrews Network Working Group M. Andrews
Internet-Draft ISC Internet-Draft ISC
Expires: February 2, 2014 Aug 2013 Expires: February 2, 2014 Aug 2013
IPv6 Stateless Fragmentation Identification Options IPv6 Stateless Fragmentation Identification Options
draft-andrews-6man-fragopt-00.txt draft-andrews-6man-fragopt-01.txt
Abstract Abstract
Fragmented IPv6 packets are often dropped because there is no way to Fragmented IPv6 packets are often dropped because there is no way to
identify whether a fragment matches a otherwise permitted packet as identify whether a fragment matches a otherwise permitted packet as
the L4 header information is not available on all the fragments. 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 document defines hop-by-hop options that can be used to supply
the missing information in non initial fragments. the missing information in non initial fragments.
skipping to change at page 2, line 8 skipping to change at page 2, line 8
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. TCP and UDP Fragements . . . . . . . . . . . . . . . . . . . . 3 2. TCP and UDP Fragments . . . . . . . . . . . . . . . . . . . . . 3
3. Security Considerations . . . . . . . . . . . . . . . . . . . . 3 3. ICMPv6 Fragments . . . . . . . . . . . . . . . . . . . . . . . 3
4. Normative References . . . . . . . . . . . . . . . . . . . . . 4 4. IPv4 in IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 4
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. IPv6 in IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 4
6. Open Questions . . . . . . . . . . . . . . . . . . . . . . . . 5
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
8. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
9. Normative References . . . . . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5
1. Introduction 1. Introduction
Fragmented IPv6 packets are often dropped because there is no way to Fragmented IPv6 packets are often dropped because there is no way to
identify whether a fragment matches a otherwise permitted packet as identify whether a fragment matches a otherwise permitted packet as
the L4 header information is not available on all the fragments. 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 document defines hop-by-hop options that can be used to supply
the missing information in non initial fragments. the missing information in non initial fragments.
The informtion required differs depending upon the L4 packet. For The information required differs depending upon the L4 packet. For
TCP and UDP the source and destination ports are needed. For ICMP TCP and UDP the source and destination ports are needed. For ICMP
the type of ICMP packet is needed. the type of ICMP packet is needed.
These options are expected to be used by middle boxes (firewalls and These options are expected to be used by middle boxes (firewalls and
loadbalancers) and end nodes. load balancers) and end nodes.
2. TCP and UDP Fragements 2. TCP and UDP Fragments
For TCP and UDP a skippable hop-by-hop option [RFC2460] (for For TCP and UDP a skippable hop-by-hop option [RFC2460] (for
backwards compatibilty) containing the source and destination ports backwards compatibility) containing the source and destination ports
from the TCP and UDP headers is needed. To permit the use of NATs, from the TCP and UDP headers is needed. To permit the use of NATs,
however undesired, the option contents are marked changable enroute. however undesired, the option contents are marked changeable enroute.
The option code has nmemonic PORTS and value (TBD) and is added to 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 all fragments of UDP and TCP packets when they are fragmented. By
adding the option to all fragments you reduce the amount of adding the option to all fragments you reduce the amount of
fragmentation reassembly failures that would result if you only added fragmentation reassembly failures that would result if you only added
the option to non-initial fragments and were dropping non-initial the option to non-initial fragments and were dropping non-initial
fragments without this option. 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
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 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 | |0|0|1| (TBD) | 4 | source port |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| destination port | | destination port |
+-------------------------------+ +-------------------------------+
3. Security Considerations 3. ICMPv6 Fragments
The use of these options will expose nodes to more fragmention based To identify the type of ICMPv6 packet a fragment is part of the type
attacks and potentually more traffic which will ultimately be dropped and code values need to be copied from the ICMPv6 header. As with
if a attacker can guess which option values will be permitted. 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 |
+---------------+---------------+---------------+---------------+
4. IPv4 in IPv6
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 |
+---------------+---------------+
5. IPv6 in IPv6
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 |
+---------------+---------------+
6. Open Questions
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?
7. IANA Considerations
To be completed.
8. Security Considerations
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 With the exception of the fragmentation based attacks, permitting
fragments with these options is no worse that permitting multiple fragments with these options is no worse that permitting multiple un-
unfragmented packets based in the same parameters. fragmented packets based in the same parameters.
4. Normative References 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.
9. Normative References
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998.
Author's Address Author's Address
M. Andrews M. Andrews
Internet Systems Consortium Internet Systems Consortium
950 Charter Street 950 Charter Street
Redwood City, CA 94063 Redwood City, CA 94063
 End of changes. 12 change blocks. 
18 lines changed or deleted 102 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/