draft-ietf-6man-ext-transmit-04.txt   draft-ietf-6man-ext-transmit-05.txt 
6man B. Carpenter 6man B. Carpenter
Internet-Draft Univ. of Auckland Internet-Draft Univ. of Auckland
Updates: 2460, 2780 (if approved) S. Jiang Updates: 2460, 2780 (if approved) S. Jiang
Intended status: Standards Track Huawei Technologies Co., Ltd Intended status: Standards Track Huawei Technologies Co., Ltd
Expires: March 30, 2014 September 26, 2013 Expires: April 20, 2014 October 17, 2013
Transmission and Processing of IPv6 Extension Headers Transmission and Processing of IPv6 Extension Headers
draft-ietf-6man-ext-transmit-04 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 future. It also specifies
how extension headers should be registered by IANA, with a how extension headers should be registered by IANA, with a
corresponding minor update to RFC 2780. corresponding minor update to RFC 2780.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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 March 30, 2014. This Internet-Draft will expire on April 20, 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
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 . . . . . . . . . . 5 2. Requirement to Transmit Extension Headers . . . . . . . . . . 4
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 . . . . . . . . . . . . . . . . . . . . . . 7 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
6. Change log [RFC Editor: Please remove] . . . . . . . . . . . 8 6. Change log [RFC Editor: Please remove] . . . . . . . . . . . 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Normative References . . . . . . . . . . . . . . . . . . 9 7.1. Normative References . . . . . . . . . . . . . . . . . . 9
7.2. Informative References . . . . . . . . . . . . . . . . . 9 7.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 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").
skipping to change at page 2, line 48 skipping to change at page 2, line 48
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, used only by hosts that have been
updated to create and interpret them [RFC6564]. The extension header updated to create and interpret them [RFC6564]. The extension header
mechanism is an important part of the IPv6 architecture, and several mechanism is an important part of the IPv6 architecture, and several
new extension headers have been standardised since RFC 2460. new extension headers have been standardised since RFC 2460.
Today, packets are often forwarded not only by straightforward IP Today, IPv6 packets are often forwarded not only on the basis of
routers, but also by a variety of intermediate nodes, often referred their first 40 bytes by straightforward IP routing. Some routers,
to as middleboxes, such as firewalls, load balancers, or packet and a variety of intermediate nodes often referred to as middleboxes,
classifiers. However, experience has shown that as a result, the such as firewalls, load balancers, or packet classifiers, might
network is not transparent to IPv6 extension headers. Contrary to inspect other parts of each packet. Indeed, such middlebox functions
Section 4 of RFC 2460, middleboxes sometimes examine and process the are often embedded in routers. However, experience has shown that as
entire IPv6 packet before making a decision to either forward or a result, the network is not transparent to IPv6 extension headers.
discard the packet. This means that they need to traverse the chain Contrary to Section 4 of RFC 2460, middleboxes sometimes examine and
of extension headers, if present, until they find the transport process the entire IPv6 packet before making a decision to either
header (or an encrypted payload). Unfortunately, because not all forward or discard the packet. This means that they need to traverse
IPv6 extension headers follow a uniform TLV format, this process is the chain of extension headers, if present, until they find the
clumsy and requires knowledge of each extension header's format. A transport header (or an encrypted payload). Unfortunately, because
separate problem is that the header chain may even be fragmented not all IPv6 extension headers follow a uniform TLV format, this
[I-D.ietf-6man-oversized-header-chain]. process is clumsy and requires knowledge of each extension header's
format. A separate problem is that the header chain may even be
fragmented [I-D.ietf-6man-oversized-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
skipping to change at page 4, line 42 skipping to change at page 4, line 45
"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. "Experimental"
extension headers are those defined by any Experimental RFC, and the extension headers include those defined by any Experimental RFC, and
experimental extension header values 253 and 254 defined by [RFC3692] the header values 253 and 254 defined by [RFC3692] and [RFC4727] when
and [RFC4727]. "Defined" extension headers are the "standard" used as experimental extension headers. "Defined" extension headers
extension headers plus the "experimental" ones. 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 can parse all defined extension
headers and deal with them appropriately, as specified in this headers and deal with them appropriately, as specified in this
section. 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
skipping to change at page 6, line 37 skipping to change at page 6, line 35
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 Section 1 and Section 2.1.
As noted above, the default configuration might drop packets
containing experimental extension headers. There is no header length
field in an IPv6 header, and header types 253 and 254 might be used
either for experimental extension headers or for experimental payload
types. Therefore, there is no generic algorithm by which a firewall
can distinguish these two cases and analyze the remainder of the
packet. This should be considered when deciding on the appropriate
default action for header types 253 and 254.
When new extension headers are standardised in the future, those When new extension headers are standardised in the future, those
implementing and configuring forwarding nodes, including firewalls, implementing and configuring forwarding nodes, including firewalls,
will need to take them into account. A newly defined header will will need to take them into account. A newly defined header will
exercise new code paths in a host that does recognise it, so caution exercise new code paths in a host that does recognise it, so caution
may be required. Additional security issues with experimental values may be required. Additional security issues with experimental values
or new extension headers are to be found in [RFC4727] and [RFC6564]. or new extension headers are to be found in [RFC4727] and [RFC6564].
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
skipping to change at page 7, line 14 skipping to change at page 7, line 19
4. IANA Considerations 4. IANA Considerations
IANA is requested to clearly mark in the Assigned Internet Protocol IANA is requested to clearly mark in the Assigned Internet Protocol
Numbers registry those values which are also IPv6 Extension Header Numbers registry those values which are also IPv6 Extension Header
types defined by an IETF Standards Action or IESG Approval (see list types defined by an IETF Standards Action or IESG Approval (see list
below), for example by adding an extra column title "IPv6 Extension below), for example by adding an extra column title "IPv6 Extension
Header" to indicate this. This will also apply to any IPv6 Extension Header" to indicate this. This will also apply to any IPv6 Extension
Header types defined in the future. Header types defined in the future.
Additionally, IANA is requested to make the existing empty IPv6 Next Additionally, IANA is requested to close the existing empty IPv6 Next
Header Types registry redirect users to a new IPv6 Extension Header Header Types registry to new entries, and redirect its users to a new
Types registry. It will contain only those protocol numbers which IPv6 Extension Header Types registry. This will contain only those
are also marked as IPv6 Extension Header types in the Assigned protocol numbers which are also marked as IPv6 Extension Header types
Internet Protocol Numbers registry. Experimental values will be in the Assigned Internet Protocol Numbers registry. Experimental
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, Hop-by-Hop Options, [RFC2460]
o 43, Routing, [RFC2460], [RFC5095] o 43, Routing, [RFC2460], [RFC5095]
o 44, Fragment, [RFC2460] o 44, Fragment, [RFC2460]
o 50, Encapsulating Security Payload, [RFC4303] o 50, Encapsulating Security Payload, [RFC4303]
o 51, Authentication, [RFC4302] o 51, Authentication, [RFC4302]
skipping to change at page 8, line 18 skipping to change at page 8, line 25
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, Cambridge
University during part of this work. University during part of this work.
This document was produced using the xml2rfc tool [RFC2629]. This document was produced using the xml2rfc tool [RFC2629].
6. Change log [RFC Editor: Please remove] 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, draft-ietf-6man-ext-transmit-04: updates following IETF Last Call,
normative requirements clarified, IANA considerations clarified, normative requirements clarified, IANA considerations clarified,
security consuderations expanded, 2013-09-26. security consuderations expanded, 2013-09-26.
draft-ietf-6man-ext-transmit-03: added details for experimental draft-ietf-6man-ext-transmit-03: added details for experimental
values, various clarifications and minor corrections, 2013-08-22. values, various clarifications and minor corrections, 2013-08-22.
draft-ietf-6man-ext-transmit-02: explicit mention of header types 253 draft-ietf-6man-ext-transmit-02: explicit mention of header types 253
and 254, editorial fixes, 2013-08-06. and 254, editorial fixes, 2013-08-06.
skipping to change at page 9, line 33 skipping to change at page 9, line 38
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 7.2. Informative References
[Heller] Heller, J., "Catch-22", Simon and Schuster , 1961. [Heller] Heller, J., "Catch-22", Simon and Schuster , 1961.
[I-D.ietf-6man-oversized-header-chain] [I-D.ietf-6man-oversized-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", draft-ietf-6man-oversized-
header-chain-07 (work in progress), September 2013. header-chain-08 (work in progress), October 2013.
[I-D.taylor-v6ops-fragdrop] [I-D.taylor-v6ops-fragdrop]
Jaeggli, J., Colitti, L., Kumari, W., Vyncke, E., Kaeo, Jaeggli, J., Colitti, L., Kumari, W., Vyncke, E., Kaeo,
M., and T. Taylor, "Why Operators Filter Fragments and M., and T. Taylor, "Why Operators Filter Fragments and
What It Implies", draft-taylor-v6ops-fragdrop-01 (work in What It Implies", draft-taylor-v6ops-fragdrop-01 (work in
progress), June 2013. progress), June 2013.
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999. June 1999.
 End of changes. 13 change blocks. 
32 lines changed or deleted 45 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/