draft-ietf-6man-oversized-header-chain-03.txt   draft-ietf-6man-oversized-header-chain-04.txt 
IPv6 maintenance Working Group (6man) F. Gont IPv6 maintenance Working Group (6man) F. Gont
Internet-Draft SI6 Networks / UTN-FRH Internet-Draft SI6 Networks / UTN-FRH
Updates: 2460 (if approved) V. Manral Updates: 2460 (if approved) V. Manral
Intended status: Standards Track Hewlett-Packard Corp. Intended status: Standards Track Hewlett-Packard Corp.
Expires: January 16, 2014 R. Bonica Expires: February 14, 2014 R. Bonica
Juniper Networks Juniper Networks
July 15, 2013 August 13, 2013
Implications of Oversized IPv6 Header Chains Implications of Oversized IPv6 Header Chains
draft-ietf-6man-oversized-header-chain-03 draft-ietf-6man-oversized-header-chain-04
Abstract Abstract
The IPv6 specification allows IPv6 header chains of an arbitrary The IPv6 specification allows IPv6 header chains of an arbitrary
size. The specification also allows options which can in turn extend size. The specification also allows options which can in turn extend
each of the headers. In those scenarios in which the IPv6 header each of the headers. In those scenarios in which the IPv6 header
chain or options are unusually long and packets are fragmented, or chain or options are unusually long and packets are fragmented, or
scenarios in which the fragment size is very small, the first scenarios in which the fragment size is very small, the first
fragment of a packet may fail to include the entire IPv6 header fragment of a packet may fail to include the entire IPv6 header
chain. This document discusses the interoperability and security chain. This document discusses the interoperability and security
skipping to change at page 1, line 42 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 16, 2014. This Internet-Draft will expire on February 14, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 18 skipping to change at page 2, line 18
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. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Updates to RFC 2460 . . . . . . . . . . . . . . . . . . . . . 7 5. Updates to RFC 2460 . . . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 9.1. Normative References . . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . . 11 9.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
With IPv6, optional internet-layer information is carried in one or With IPv6, optional internet-layer information is carried in one or
more IPv6 Extension Headers [RFC2460]. Extension headers are placed more IPv6 Extension Headers [RFC2460]. Extension headers are placed
between the IPv6 header and the upper-layer header in a packet. The between the IPv6 header and the upper-layer header in a packet. The
term "header chain" refers collectively to the IPv6 header, extension term "header chain" refers collectively to the IPv6 header, extension
headers and upper-layer header occurring in a packet. In those headers and upper-layer header occurring in a packet. In those
scenarios in which the IPv6 header chain is unusually long and scenarios in which the IPv6 header chain is unusually long and
packets are fragmented, or scenarios in which the fragment size is packets are fragmented, or scenarios in which the fragment size is
skipping to change at page 5, line 7 skipping to change at page 5, line 7
fragment. fragment.
2. Requirements Language 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
3. Terminology 3. Terminology
For the purposes of this document, the terms Extension Header, Header
Chain, First Fragment, and Upper-layer Header are used as follows:
Extension Header: Extension Header:
Extension Headers are defined in Section 4 of [RFC2460]. Extension Headers are defined in Section 4 of [RFC2460].
Currently, six extension header types are defined. [RFC2460] Currently, six extension header types are defined. [RFC2460]
defines the hop-by-hop, routing, fragment and destination options defines the Hop-by-Hop, Routing, Fragment and Destination Options
extension header types. [RFC4302] defines the authentication extension header types. [RFC4302] defines the Authentication
header type and [RFC4303] defines the encapsulating security Header (AH) type and [RFC4303] defines the Encapsulating Security
payload (ESP) header type. Payload (ESP) header type.
First Fragment: First Fragment:
An IPv6 fragment with fragment offset equal to 0. An IPv6 fragment with fragment offset equal to 0.
IPv6 Header Chain: IPv6 Header Chain:
The initial portion of an IPv6 datagram containing headers, The header chain contains an initial IPv6 header, zero or more
starting from the fixed IPv6 header up to (and including) the IPv6 extension headers, and optionally, a single upper-layer
upper layer protocol header (TCP, UDP, etc. -- assuming there is header. If an upper-layer header is present, it terminates the
one of those), including any intermediate IPv6 extension headers. header chain.
For a header to qualify as a member of the header chain, it must
be referenced by the "Next Header" field of the previous member of
the header chain.
Upper-layer Header: The first member of the header chain is always an IPv6 header.
For a subsequent header to qualify as a member of the header
chain, it must be referenced by the "Next Header" field of the
previous member of the header chain. However, if a second IPv6
header appears in the header chain, as is the case when IPv6 is
tunneled over IPv6, the second IPv6 header is considered to be an
upper-layer header and terminates the header chain. Likewise, if
an ESP header appears in the header chain it is considered to be
an upper-layer header and it terminates the header chain.
The first member of the header chain that is neither an IPv6 Upper-layer Header:
header nor an IPv6 extension header. For the purposes of this
document, ICMPv6 is considered to be an upper-layer protocol, even
though ICMPv6 operates at the same layer as IPv6. Also for the
purposes of this document, the first 32 bits of the ICMPv6 message
(i.e., the type, code fields and checksum fields) are considered
to be the ICMPv6 header.
NOTES: In the general case, the upper-layer header is the first member of
The upper-layer payload is not part of the upper-layer header the header chain that is neither an IPv6 header nor an IPv6
and therefore, is not part of the IPv6 header chain. For extension header. However, if either an ESP header, or a second
example, if the upper-layer protocol is TCP, the TCP payload is IPv6 header occur in the header chain, they are considered to be
not part of the TCP header or the IPv6 header chain. upper layer headers and they terminate the header chain.
When a packet contains an ESP header [RFC4303], such header is Neither the upper-layer payload, nor any protocol data following
considered to be the last header in the IPv6 header chain. For the upper-layer payload, is considered to be part of the header
the sake of clarity, we note that only the Security Parameters chain. In a simple example, if the upper-layer header is a TCP
Index (SPI) and the Sequence Number fields (i.e., the first 64 header, the TCP payload is not part of the header chain. In a
bits of the ESP packet) are part of the ESP header (i.e., the more complex example, if the upper-layer header is an ESP header,
Payload Data and trailer are NOT part of the ESP header). neither the payload data, nor any of the fields that follow the
payload data in the ESP header are part of the header chain.
4. Motivation 4. Motivation
Many forwarding devices implement stateless firewalls. A stateless Many forwarding devices implement stateless firewalls. A stateless
firewall enforces a forwarding policy on packet-by-packet basis. In firewall enforces a forwarding policy on packet-by-packet basis. In
order to enforce its forwarding policy, the stateless firewall may order to enforce its forwarding policy, the stateless firewall may
need to glean information from both the IPv6 and upper-layer headers. need to glean information from both the IPv6 and upper-layer headers.
For example, assume that a stateless firewall discards all traffic For example, assume that a stateless firewall discards all traffic
received from an interface unless it destined for a particular TCP received from an interface unless it destined for a particular TCP
 End of changes. 12 change blocks. 
43 lines changed or deleted 46 lines changed or added

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