Internet DRAFT - draft-andrews-6man-fragopt
draft-andrews-6man-fragopt
Network Working Group M. Andrews
Internet-Draft ISC
Expires: February 2, 2014 Aug 2013
IPv6 Stateless Fragmentation Identification Options
draft-andrews-6man-fragopt-01.txt
Abstract
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.
Status of this Memo
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."
This Internet-Draft will expire on February 2, 2014.
Copyright Notice
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.
Andrews Expires February 2, 2014 [Page 1]
Internet-Draft hop by hop frag opts Aug 2013
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. TCP and UDP Fragments . . . . . . . . . . . . . . . . . . . . . 3
3. ICMPv6 Fragments . . . . . . . . . . . . . . . . . . . . . . . 3
4. IPv4 in IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 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
Andrews Expires February 2, 2014 [Page 2]
Internet-Draft hop by hop frag opts Aug 2013
1. Introduction
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.
2. TCP and UDP Fragments
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 |
+-------------------------------+
3. ICMPv6 Fragments
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
Andrews Expires February 2, 2014 [Page 3]
Internet-Draft hop by hop frag opts Aug 2013
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 |
+---------------+---------------+
Andrews Expires February 2, 2014 [Page 4]
Internet-Draft hop by hop frag opts Aug 2013
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
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.
9. Normative References
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
Andrews Expires February 2, 2014 [Page 5]
Internet-Draft hop by hop frag opts Aug 2013
Author's Address
M. Andrews
Internet Systems Consortium
950 Charter Street
Redwood City, CA 94063
US
Email: marka@isc.org
Andrews Expires February 2, 2014 [Page 6]
