draft-ietf-6man-ext-transmit-05.txt   rfc7045.txt 
6man B. Carpenter Internet Engineering Task Force (IETF) B. Carpenter
Internet-Draft Univ. of Auckland Request for Comments: 7045 Univ. of Auckland
Updates: 2460, 2780 (if approved) S. Jiang Updates: 2460, 2780 S. Jiang
Intended status: Standards Track Huawei Technologies Co., Ltd Category: Standards Track Huawei Technologies Co., Ltd.
Expires: April 20, 2014 October 17, 2013 ISSN: 2070-1721 December 2013
Transmission and Processing of IPv6 Extension Headers Transmission and Processing of IPv6 Extension Headers
draft-ietf-6man-ext-transmit-05
Abstract Abstract
Various IPv6 extension headers have been standardised since the IPv6 Various IPv6 extension headers have been standardised since the IPv6
standard was first published. This document updates RFC 2460 to standard was first published. This document updates RFC 2460 to
clarify how intermediate nodes should deal with such extension clarify how intermediate nodes should deal with such extension
headers and with any that are defined in future. It also specifies headers and with any that are defined in the future. It also
how extension headers should be registered by IANA, with a specifies how extension headers should be registered by IANA, with a
corresponding minor update to RFC 2780. corresponding minor update to RFC 2780.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on April 20, 2014. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7045.
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
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 and Problem Statement . . . . . . . . . . . . . 2 1. Introduction and Problem Statement . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Requirement to Transmit Extension Headers . . . . . . . . . . 4 2. Requirement to Transmit Extension Headers . . . . . . . . . . 5
2.1. All Extension Headers . . . . . . . . . . . . . . . . . . 5 2.1. All Extension Headers . . . . . . . . . . . . . . . . . . 5
2.2. Hop-by-Hop Options . . . . . . . . . . . . . . . . . . . 6 2.2. Hop-by-Hop Options . . . . . . . . . . . . . . . . . . . 6
3. Security Considerations . . . . . . . . . . . . . . . . . . . 6 3. Security Considerations . . . . . . . . . . . . . . . . . . . 6
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
6. Change log [RFC Editor: Please remove] . . . . . . . . . . . 8 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 6.1. Normative References . . . . . . . . . . . . . . . . . . 8
7.1. Normative References . . . . . . . . . . . . . . . . . . 9 6.2. Informative References . . . . . . . . . . . . . . . . . 8
7.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction and Problem Statement 1. Introduction and Problem Statement
In IPv6, an extension header is any header that follows the initial In IPv6, an extension header is any header that follows the initial
40 bytes of the packet and precedes the upper layer header (which 40 bytes of the packet and precedes the upper-layer header (which
might be a transport header, an ICMPv6 header, or a notional "No Next might be a transport header, an ICMPv6 header, or a notional "No Next
Header"). Header").
An initial set of IPv6 extension headers was defined by [RFC2460], An initial set of IPv6 extension headers was defined by [RFC2460],
which also described how they should be handled by intermediate which also described how they should be handled by intermediate
nodes, with the exception of the hop-by-hop options header: nodes, with the exception of the Hop-by-Hop Options header:
"...extension headers are not examined or processed ...extension headers are not examined or processed by any node
by any node along a packet's delivery path, until the packet reaches along a packet's delivery path, until the packet reaches the node
the node (or each of the set of nodes, in the case of multicast) (or each of the set of nodes, in the case of multicast) identified
identified in the Destination Address field of the IPv6 header." in the Destination Address field of the IPv6 header.
This provision meant that forwarding nodes should be completely This provision meant that forwarding nodes should be completely
transparent to extension headers. There was no provision for transparent to extension headers. There was no provision for
forwarding nodes to modify them, remove them, insert them, or use forwarding nodes to modify them, remove them, insert them, or use
them to affect forwarding behaviour. Thus, new extension headers them to affect forwarding behaviour. Thus, new extension headers
could be introduced progressively, used only by hosts that have been could be introduced progressively and used only by hosts that have
updated to create and interpret them [RFC6564]. The extension header been updated to create and interpret them [RFC6564]. The extension
mechanism is an important part of the IPv6 architecture, and several header mechanism is an important part of the IPv6 architecture, and
new extension headers have been standardised since RFC 2460. several new extension headers have been standardised since RFC 2460
was published.
Today, IPv6 packets are often forwarded not only on the basis of Today, IPv6 packets are not always forwarded by straightforward IP
their first 40 bytes by straightforward IP routing. Some routers, routing based on their first 40 bytes. Some routers, and a variety
and a variety of intermediate nodes often referred to as middleboxes, of intermediate nodes often referred to as middleboxes, such as
such as firewalls, load balancers, or packet classifiers, might firewalls, load balancers, or packet classifiers, might inspect other
inspect other parts of each packet. Indeed, such middlebox functions parts of each packet. Indeed, such middlebox functions are often
are often embedded in routers. However, experience has shown that as embedded in routers. However, experience has shown that as a result,
a result, the network is not transparent to IPv6 extension headers. the network is not transparent to IPv6 extension headers. Contrary
Contrary to Section 4 of RFC 2460, middleboxes sometimes examine and to Section 4 of RFC 2460, middleboxes sometimes examine and process
process the entire IPv6 packet before making a decision to either the entire IPv6 packet before making a decision to either forward or
forward or discard the packet. This means that they need to traverse discard the packet. This means that they need to traverse the chain
the chain of extension headers, if present, until they find the of extension headers, if present, until they find the transport
transport header (or an encrypted payload). Unfortunately, because header (or an encrypted payload). Unfortunately, because not all
not all IPv6 extension headers follow a uniform TLV format, this IPv6 extension headers follow a uniform TLV format, this process is
process is clumsy and requires knowledge of each extension header's clumsy and requires knowledge of each extension header's format. A
format. A separate problem is that the header chain may even be separate problem is that the header chain may even be fragmented
fragmented [I-D.ietf-6man-oversized-header-chain]. [HEADER-CHAIN].
The process is potentially slow as well as clumsy, possibly The process is potentially slow as well as clumsy, possibly
precluding its use in nodes attempting to process packets at line precluding its use in nodes attempting to process packets at line
speed. The present document does not intend to solve this problem, speed. The present document does not intend to solve this problem,
which is caused by the fundamental architecture of IPv6 extension which is caused by the fundamental architecture of IPv6 extension
headers. This document focuses on clarifying how the header chain headers. This document focuses on clarifying how the header chain
should be handled in the current IPv6 architecture. should be handled in the current IPv6 architecture.
If they encounter an unrecognised extension header type, some If they encounter an unrecognised extension header type, some
firewalls treat the packet as suspect and drop it. Unfortunately, it firewalls treat the packet as suspect and drop it. Unfortunately, it
is an established fact that several widely used firewalls do not is an established fact that several widely used firewalls do not
recognise some or all of the extension headers standardised since RFC recognise some or all of the extension headers standardised since RFC
2460. It has also been observed that certain firewalls do not even 2460 was published. It has also been observed that certain firewalls
handle all the extension headers standardised in RFC 2460, including do not even handle all the extension headers standardised in RFC
the fragment header [I-D.taylor-v6ops-fragdrop], causing fundamental 2460, including the fragment header [FRAGDROP], causing fundamental
problems of end-to-end connectivity. This applies in particular to problems of end-to-end connectivity. This applies in particular to
firewalls that attempt to inspect packets at very high speed, since firewalls that attempt to inspect packets at very high speed, since
they cannot take the time to reassemble fragmented packets, they cannot take the time to reassemble fragmented packets,
especially when under a denial of service attack. especially when under a denial-of-service attack.
Other types of middlebox, such as load balancers or packet Other types of middleboxes, such as load balancers or packet
classifiers, might also fail in the presence of extension headers classifiers, might also fail in the presence of extension headers
that they do not recognise. that they do not recognise.
A contributory factor to this problem is that, because extension A contributory factor to this problem is that because extension
headers are numbered out of the existing IP Protocol Number space, headers are numbered out of the existing IP Protocol Number space,
there is no collected list of them. For this reason, it is hard for there is no collected list of them. For this reason, it is hard for
an implementor to quickly identify the full set of standard extension an implementor to quickly identify the full set of standard extension
headers. An implementor who consults only RFC 2460 will miss all headers. An implementor who consults only RFC 2460 will miss all
extension headers defined subsequently. extension headers defined subsequently.
This combination of circumstances creates a "Catch-22" situation This combination of circumstances creates a "Catch-22" situation
[Heller] for the deployment of any newly standardised extension [Heller] for the deployment of any newly standardised extension
header except for local use. It cannot be widely deployed, because header except for local use. It cannot be widely deployed because
existing middleboxes will drop it on many paths through the Internet. existing middleboxes will drop it on many paths through the Internet.
However, most middleboxes will not be updated to allow the new header However, most middleboxes will not be updated to allow the new header
to pass until it has been proved safe and useful on the open to pass until it has been proved safe and useful on the open
Internet, which is impossible until the middleboxes have been Internet, which is impossible until the middleboxes have been
updated. updated.
The uniform TLV format now defined for extension headers [RFC6564] The uniform TLV format now defined for extension headers [RFC6564]
will improve the situation, but only for future extensions. Some will improve the situation, but only for future extensions. Some
tricky and potentially malicious cases will be avoided by forbidding tricky and potentially malicious cases will be avoided by forbidding
very long chains of extension headers that need to be fragmented very long chains of extension headers that need to be fragmented
[I-D.ietf-6man-oversized-header-chain]. This will alleviate concerns [HEADER-CHAIN]. This will alleviate concerns that stateless
that stateless firewalls cannot locate a complete header chain as firewalls cannot locate a complete header chain as required by the
required by the present document. present document.
However, these changes are insufficient to correct the underlying However, these changes are insufficient to correct the underlying
problem. The present document clarifies that the above requirement problem. The present document clarifies that the above requirement
from RFC 2460 applies to all types of nodes that forward IPv6 packets from RFC 2460 applies to all types of nodes that forward IPv6 packets
and to all extension headers standardised now and in the future. It and to all extension headers standardised now and in the future. It
also requests IANA to create a subsidiary registry that clearly also requests that IANA create a subsidiary registry that clearly
identifies extension header types, and updates RFC 2780 accordingly. identifies extension header types and updates RFC 2780 accordingly.
Fundamental changes to the IPv6 extension header architecture are out Fundamental changes to the IPv6 extension header architecture are out
of scope for this document. of scope for this document.
Also, Hop-by-Hop options are not handled by many high speed routers, Also, hop-by-hop options are not handled by many high-speed routers
or are processed only on a slow path. This document also updates the or are processed only on a slow path. This document also updates the
requirements for processing the Hop-by-Hop options header to make requirements for processing the Hop-by-Hop Options header to make
them more realistic. them more realistic.
1.1. Terminology 1.1. Terminology
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 [RFC2119]. document are to be interpreted as described in [RFC2119].
In the remainder of this document, the term "forwarding node" refers In the remainder of this document, the term "forwarding node" refers
to any router, firewall, load balancer, prefix translator, or any to any router, firewall, load balancer, prefix translator, or any
other device or middlebox that forwards IPv6 packets with or without other device or middlebox that forwards IPv6 packets with or without
examining the packet in any way. examining the packet in any way.
In this document "standard" IPv6 extension headers are those In this document, "standard" IPv6 extension headers are those
specified in detail by IETF standards actions. "Experimental" specified in detail by IETF Standards Actions [RFC5226].
extension headers include those defined by any Experimental RFC, and "Experimental" extension headers include those defined by any
the header values 253 and 254 defined by [RFC3692] and [RFC4727] when Experimental RFC and the header values 253 and 254 defined by
used as experimental extension headers. "Defined" extension headers [RFC3692] and [RFC4727] when used as experimental extension headers.
are the "standard" extension headers plus the "experimental" ones. "Defined" extension headers are the "standard" extension headers plus
the "experimental" ones.
2. Requirement to Transmit Extension Headers 2. Requirement to Transmit Extension Headers
2.1. All Extension Headers 2.1. All Extension Headers
As mentioned above, forwarding nodes that discard packets containing As mentioned above, forwarding nodes that discard packets containing
extension headers are known to cause connectivity failures and extension headers are known to cause connectivity failures and
deployment problems. Therefore, it is important that forwarding deployment problems. Therefore, it is important that forwarding
nodes that inspect IPv6 headers can parse all defined extension nodes that inspect IPv6 headers be able to parse all defined
headers and deal with them appropriately, as specified in this extension headers and deal with them appropriately, as specified in
section. this section.
Any forwarding node along an IPv6 packet's path, which forwards the Any forwarding node along an IPv6 packet's path, which forwards the
packet for any reason, SHOULD do so regardless of any extension packet for any reason, SHOULD do so regardless of any extension
headers that are present, as required by RFC 2460. Exceptionally, if headers that are present, as required by RFC 2460. Exceptionally, if
a forwarding node is designed to examine extension headers for any a forwarding node is designed to examine extension headers for any
reason, such as firewalling, it MUST recognise and deal appropriately reason, such as firewalling, it MUST recognise and deal appropriately
with all standard IPv6 extension header types and SHOULD recognise with all standard IPv6 extension header types and SHOULD recognise
and deal appropriately with experimental IPv6 extension header types. and deal appropriately with experimental IPv6 extension header types.
The list of standard and experimental extension header types is The list of standard and experimental extension header types is
maintained by IANA (see Section 4) and implementors are advised to maintained by IANA (see Section 4), and implementors are advised to
check this list regularly for updates. check this list regularly for updates.
RFC 2460 requires destination hosts to discard packets containing RFC 2460 requires destination hosts to discard packets containing
unrecognised extension headers. However, intermediate forwarding unrecognised extension headers. However, intermediate forwarding
nodes SHOULD NOT do this, since that might cause them to nodes SHOULD NOT do this, since that might cause them to
inadvertently discard traffic using a recently standardised extension inadvertently discard traffic using a recently standardised extension
header, not yet recognised by the intermediate node. The exceptions header not yet recognised by the intermediate node. The exceptions
to this rule are discussed next. to this rule are discussed next.
If a forwarding node discards a packet containing a standard IPv6 If a forwarding node discards a packet containing a standard IPv6
extension header, it MUST be the result of a configurable policy, and extension header, it MUST be the result of a configurable policy and
not just the result of a failure to recognise such a header. This not just the result of a failure to recognise such a header. This
means that the discard policy for each standard type of extension means that the discard policy for each standard type of extension
header MUST be individually configurable. The default configuration header MUST be individually configurable. The default configuration
SHOULD allow all standard extension headers. SHOULD allow all standard extension headers.
Experimental IPv6 extension headers SHOULD be treated in the same way Experimental IPv6 extension headers SHOULD be treated in the same way
as standard extension headers, including an individually configurable as standard extension headers, including an individually configurable
discard policy. However, the default configuration MAY drop discard policy. However, the default configuration MAY drop
experimental extension headers. experimental extension headers.
Forwarding nodes MUST be configurable to allow packets containing Forwarding nodes MUST be configurable to allow packets containing
unrecognised extension headers, but the default configuration MAY unrecognised extension headers, but the default configuration MAY
drop such packets. drop such packets.
The IPv6 Routing Header Types 0 and 1 have been deprecated [RFC5095]. The IPv6 Routing Header Types 0 and 1 have been deprecated. Note
However, this does not mean that the IPv6 Routing Header can be that Type 0 was deprecated by [RFC5095]. However, this does not mean
unconditionally dropped by forwarding nodes. Packets containing that the IPv6 Routing Header can be unconditionally dropped by
standardised and undeprecated Routing Headers SHOULD be forwarded by forwarding nodes. Packets containing standardised and undeprecated
default. At the time of writing, these include Type 2 [RFC6275], Routing Headers SHOULD be forwarded by default. At the time of
Type 3 [RFC6554], and the experimental Routing Header Types 253 and writing, these include Type 2 [RFC6275], Type 3 [RFC6554], and the
254 [RFC4727]. Others may be defined in future. experimental Routing Header Types 253 and 254 [RFC4727]. Others may
be defined in the future.
2.2. Hop-by-Hop Options 2.2. Hop-by-Hop Options
The IPv6 Hop-by-Hop Options header SHOULD be processed by The IPv6 Hop-by-Hop Options header SHOULD be processed by
intermediate forwarding nodes as described in [RFC2460]. However, it intermediate forwarding nodes as described in [RFC2460]. However, it
is to be expected that high performance routers will either ignore is to be expected that high-performance routers will either ignore it
it, or assign packets containing it to a slow processing path. or assign packets containing it to a slow processing path. Designers
Designers planning to use a Hop-by-Hop option need to be aware of planning to use a hop-by-hop option need to be aware of this likely
this likely behaviour. behaviour.
As a reminder, in RFC 2460, it is stated that the Hop-by-Hop Options As a reminder, in RFC 2460, it is stated that the Hop-by-Hop Options
header, if present, must be first. header, if present, must be first.
3. Security Considerations 3. Security Considerations
Forwarding nodes that operate as firewalls MUST conform to the Forwarding nodes that operate as firewalls MUST conform to the
requirements in the previous section in order to respect the IPv6 requirements in the previous section in order to respect the IPv6
extension header architecture. In particular, packets containing extension header architecture. In particular, packets containing
standard extension headers are only to be discarded as a result of an standard extension headers are only to be discarded as a result of an
intentionally configured policy. intentionally configured policy.
These changes do not affect a firewall's ability to filter out These changes do not affect a firewall's ability to filter out
traffic containing unwanted or suspect extension headers, if traffic containing unwanted or suspect extension headers, if
configured to do so. However, the changes do require firewalls to be configured to do so. However, the changes do require firewalls to be
capable of permitting any or all extension headers, if configured to capable of permitting any or all extension headers, if configured to
do so. The default configurations are intended to allow normal use do so. The default configurations are intended to allow normal use
of any standard extension header, avoiding the connectivity issues of any standard extension header, avoiding the connectivity issues
described in Section 1 and Section 2.1. described in Sections 1 and 2.1.
As noted above, the default configuration might drop packets As noted above, the default configuration might drop packets
containing experimental extension headers. There is no header length containing experimental extension headers. There is no header length
field in an IPv6 header, and header types 253 and 254 might be used field in an IPv6 header, and header types 253 and 254 might be used
either for experimental extension headers or for experimental payload either for experimental extension headers or for experimental payload
types. Therefore, there is no generic algorithm by which a firewall types. Therefore, there is no generic algorithm by which a firewall
can distinguish these two cases and analyze the remainder of the can distinguish these two cases and analyze the remainder of the
packet. This should be considered when deciding on the appropriate packet. This should be considered when deciding on the appropriate
default action for header types 253 and 254. default action for header types 253 and 254.
skipping to change at page 7, line 12 skipping to change at page 7, line 15
As a result, it is to be expected that the deployment process will be As a result, it is to be expected that the deployment process will be
slow and will depend on satisfactory operational experience. Until slow and will depend on satisfactory operational experience. Until
deployment is complete, the new extension will fail in some parts of deployment is complete, the new extension will fail in some parts of
the Internet. This aspect needs to be considered when deciding to the Internet. This aspect needs to be considered when deciding to
standardise a new extension. Specific security considerations for standardise a new extension. Specific security considerations for
each new extension should be documented in the document that defines each new extension should be documented in the document that defines
it. it.
4. IANA Considerations 4. IANA Considerations
IANA is requested to clearly mark in the Assigned Internet Protocol IANA has added an extra column titled "IPv6 Extension Header" to the
Numbers registry those values which are also IPv6 Extension Header "Assigned Internet Protocol Numbers" registry to clearly mark those
types defined by an IETF Standards Action or IESG Approval (see list values that are also IPv6 extension header types defined by an IETF
below), for example by adding an extra column title "IPv6 Extension Standards Action or IESG Approval (see list below). This also
Header" to indicate this. This will also apply to any IPv6 Extension applies to IPv6 extension header types defined in the future.
Header types defined in the future.
Additionally, IANA is requested to close the existing empty IPv6 Next Additionally, IANA has closed the existing empty "Next Header Types"
Header Types registry to new entries, and redirect its users to a new registry to new entries and is redirecting its users to a new "IPv6
IPv6 Extension Header Types registry. This will contain only those Extension Header Types" registry. This registry contains only those
protocol numbers which are also marked as IPv6 Extension Header types protocol numbers that are also marked as IPv6 Extension Header types
in the Assigned Internet Protocol Numbers registry. Experimental in the "Assigned Internet Protocol Numbers" registry. Experimental
values will be marked as such. The initial list will be as follows: values will be marked as such. The initial list will be as follows:
o 0, Hop-by-Hop Options, [RFC2460] o 0, IPv6 Hop-by-Hop Option, [RFC2460]
o 43, Routing, [RFC2460], [RFC5095] o 43, Routing Header for IPv6, [RFC2460], [RFC5095]
o 44, Fragment, [RFC2460] o 44, Fragment Header for IPv6, [RFC2460]
o 50, Encapsulating Security Payload, [RFC4303] o 50, Encapsulating Security Payload, [RFC4303]
o 51, Authentication, [RFC4302] o 51, Authentication Header, [RFC4302]
o 60, Destination Options, [RFC2460] o 60, Destination Options for IPv6, [RFC2460]
o 135, MIPv6, [RFC6275] o 135, Mobility Header, [RFC6275]
o 139, experimental use, HIP, [RFC5201] o 139, Experimental use, Host Identity Protocol [RFC5201]
o 140, shim6, [RFC5533] o 140, Shim6 Protocol, [RFC5533]
o 253, experimental use, [RFC3692], [RFC4727] o 253, Use for experimentation and testing, [RFC3692], [RFC4727]
o 254, experimental use, [RFC3692], [RFC4727] o 254, Use for experimentation and testing, [RFC3692], [RFC4727]
This list excludes type 59, No Next Header, [RFC2460], which is not This list excludes type 59, No Next Header, [RFC2460], which is not
an extension header as such. an extension header as such.
The references to the IPv6 Next Header field in [RFC2780] are to be The references to the IPv6 Next Header field in [RFC2780] are to be
interpreted as also applying to the IPv6 Extension Header field and interpreted as also applying to the IPv6 Extension Header field, and
the IPv6 Extension Header Types registry will be managed accordingly. the "IPv6 Extension Header Types" registry will be managed
accordingly.
5. Acknowledgements 5. Acknowledgements
This document was triggered by mailing list discussions including This document was triggered by mailing list discussions including
John Leslie, Stefan Marksteiner and others. Valuable comments and John Leslie, Stefan Marksteiner, and others. Valuable comments and
contributions were made by Dominique Barthel, Tim Chown, Lorenzo contributions were made by Dominique Barthel, Tim Chown, Lorenzo
Colitti, Fernando Gont, C. M. Heard, Bob Hinden, Ray Hunter, Suresh Colitti, Fernando Gont, C. M. Heard, Bob Hinden, Ray Hunter, Suresh
Krishnan, Marc Lampo, Sandra Murphy, Michael Richardson, Dan Krishnan, Marc Lampo, Sandra Murphy, Michael Richardson, Dan
Romascanu, Dave Thaler, Joe Touch, Bjoern Zeeb, and others. Romascanu, Dave Thaler, Joe Touch, Bjoern Zeeb, and others.
Brian Carpenter was a visitor at the Computer Laboratory, Cambridge Brian Carpenter was a visitor at the Computer Laboratory at Cambridge
University during part of this work. University during part of this work.
This document was produced using the xml2rfc tool [RFC2629]. 6. References
6. Change log [RFC Editor: Please remove]
draft-ietf-6man-ext-transmit-05: updates following IESG comments,
2013-10-17.
draft-ietf-6man-ext-transmit-04: updates following IETF Last Call,
normative requirements clarified, IANA considerations clarified,
security consuderations expanded, 2013-09-26.
draft-ietf-6man-ext-transmit-03: added details for experimental
values, various clarifications and minor corrections, 2013-08-22.
draft-ietf-6man-ext-transmit-02: explicit mention of header types 253
and 254, editorial fixes, 2013-08-06.
draft-ietf-6man-ext-transmit-01: tuned use of normative language,
clarified that only standardised extensions are covered (hence
excluding HIP), 2013-05-29.
draft-ietf-6man-ext-transmit-00: first WG version, more
clarifications, 2013-03-26.
draft-carpenter-6man-ext-transmit-02: clarifications following WG
comments, recalibrated firewall requirements, 2013-02-22.
draft-carpenter-6man-ext-transmit-01: feedback at IETF85: clarify
scope and impact on firewalls, discuss line-speed processing and lack
of uniform TLV format, added references, restructured IANA
considerations, 2012-11-13.
draft-carpenter-6man-ext-transmit-00: original version, 2012-08-14.
7. References
7.1. Normative References 6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.
[RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For
Values In the Internet Protocol and Related Headers", BCP Values In the Internet Protocol and Related Headers", BCP
37, RFC 2780, March 2000. 37, RFC 2780, March 2000.
skipping to change at page 9, line 31 skipping to change at page 8, line 46
[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers
Considered Useful", BCP 82, RFC 3692, January 2004. Considered Useful", BCP 82, RFC 3692, January 2004.
[RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, [RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4,
ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006. ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006.
[RFC6564] Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and [RFC6564] Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and
M. Bhatia, "A Uniform Format for IPv6 Extension Headers", M. Bhatia, "A Uniform Format for IPv6 Extension Headers",
RFC 6564, April 2012. RFC 6564, April 2012.
7.2. Informative References 6.2. Informative References
[Heller] Heller, J., "Catch-22", Simon and Schuster , 1961. [FRAGDROP] Jaeggli, J., Colitti, L., Kumari, W., Vyncke, E., Kaeo,
M., and T. Taylor, "Why Operators Filter Fragments and
What It Implies", Work in Progress, June 2013.
[I-D.ietf-6man-oversized-header-chain] [HEADER-CHAIN]
Gont, F., Manral, V., and R. Bonica, "Implications of Gont, F., Manral, V., and R. Bonica, "Implications of
Oversized IPv6 Header Chains", draft-ietf-6man-oversized- Oversized IPv6 Header Chains", Work in Progress, October
header-chain-08 (work in progress), October 2013. 2013.
[I-D.taylor-v6ops-fragdrop]
Jaeggli, J., Colitti, L., Kumari, W., Vyncke, E., Kaeo,
M., and T. Taylor, "Why Operators Filter Fragments and
What It Implies", draft-taylor-v6ops-fragdrop-01 (work in
progress), June 2013.
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, [Heller] Heller, J., "Catch-22", Simon and Schuster, November 1961.
June 1999.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December
2005. 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
4303, December 2005. 4303, December 2005.
[RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation
of Type 0 Routing Headers in IPv6", RFC 5095, December of Type 0 Routing Headers in IPv6", RFC 5095, December
2007. 2007.
[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson,
"Host Identity Protocol", RFC 5201, April 2008. "Host Identity Protocol", RFC 5201, April 2008.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming
Shim Protocol for IPv6", RFC 5533, June 2009. Shim Protocol for IPv6", RFC 5533, June 2009.
[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
in IPv6", RFC 6275, July 2011. in IPv6", RFC 6275, July 2011.
[RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6
Routing Header for Source Routes with the Routing Protocol Routing Header for Source Routes with the Routing Protocol
for Low-Power and Lossy Networks (RPL)", RFC 6554, March for Low-Power and Lossy Networks (RPL)", RFC 6554, March
2012. 2012.
Authors' Addresses Authors' Addresses
Brian Carpenter Brian Carpenter
Department of Computer Science Department of Computer Science
University of Auckland University of Auckland
PB 92019 PB 92019
Auckland 1142 Auckland 1142
New Zealand New Zealand
Email: brian.e.carpenter@gmail.com EMail: brian.e.carpenter@gmail.com
Sheng Jiang Sheng Jiang
Huawei Technologies Co., Ltd Huawei Technologies Co., Ltd.
Q14, Huawei Campus Q14, Huawei Campus
No.156 Beiqing Road No. 156 Beiqing Road
Hai-Dian District, Beijing 100095 Hai-Dian District, Beijing 100095
P.R. China P.R. China
Email: jiangsheng@huawei.com EMail: jiangsheng@huawei.com
 End of changes. 59 change blocks. 
168 lines changed or deleted 130 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/