draft-ietf-6man-ext-transmit-00.txt   draft-ietf-6man-ext-transmit-01.txt 
6man B. E. Carpenter 6man B. E. 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: September 28, 2013 March 28, 2013 Expires: November 30, 2013 May 29, 2013
Transmission of IPv6 Extension Headers Transmission of IPv6 Extension Headers
draft-ietf-6man-ext-transmit-00 draft-ietf-6man-ext-transmit-01
Abstract Abstract
Various IPv6 extension headers have been defined 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.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 September 28, 2013. This Internet-Draft will expire on November 30, 2013.
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 16 skipping to change at page 2, line 16
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 . . . . . . . . . . 4
2.1. All Extension Headers . . . . . . . . . . . . . . . . . . 4 2.1. All Extension Headers . . . . . . . . . . . . . . . . . . 4
2.2. Hop-by-Hop Options . . . . . . . . . . . . . . . . . . . 5 2.2. Hop-by-Hop Options . . . . . . . . . . . . . . . . . . . 5
3. Security Considerations . . . . . . . . . . . . . . . . . . . 5 3. Security Considerations . . . . . . . . . . . . . . . . . . . 5
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
6. Change log [RFC Editor: Please remove] . . . . . . . . . . . 7 6. Change log [RFC Editor: Please remove] . . . . . . . . . . . 7
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Normative References . . . . . . . . . . . . . . . . . . 7 7.1. Normative References . . . . . . . . . . . . . . . . . . 7
7.2. Informative References . . . . . . . . . . . . . . . . . 8 7.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
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 along a packet's delivery path, until the packet reaches by any node along a packet's delivery path, until the packet reaches
the node (or each of the set of nodes, in the case of multicast) the node (or each of the set of nodes, in the case of multicast)
identified in the Destination Address field of the IPv6 header." identified in the Destination Address field of the IPv6 header."
This provision allowed for the addition of new extension headers, This provision meant that forwarding nodes should be completely
since it means that forwarding nodes should be completely transparent transparent to extension headers. There was no provision for
to them. Thus, new extension headers could be introduced forwarding nodes to modify them, remove them, insert them, or use
progressively, used only by hosts that have been updated to create them to affect forwarding behaviour. Thus, new extension headers
and interpret them. The extension header mechanism is an important could be introduced progressively, used only by hosts that have been
part of the IPv6 architecture, and several new extension headers have updated to create and interpret them. The extension header mechanism
been defined since RFC 2460. is an important part of the IPv6 architecture, and several new
extension headers have been standardised since RFC 2460.
Today, packets are often forwarded not only by straightforward IP Today, packets are often forwarded not only by straightforward IP
routers, but also by a variety of intermediate nodes, often referred routers, but also by a variety of intermediate nodes, often referred
to as middleboxes, such as firewalls and load balancers. to as middleboxes, such as firewalls, load balancers, or packet
Unfortunately, experience has showed that as a result, the network is classifiers. Unfortunately, experience has showed that as a result,
not transparent to IPv6 extension headers. The main reason for this the network is not transparent to IPv6 extension headers. Contrary
is that by design, some middleboxes attempt to inspect the transport to Section 4 of RFC 2460, middleboxes sometimes examine and process
header or payload. This means that they need to traverse the chain the entire IPv6 packet before making a decision to either forward or
discard the packet. This means that they need to traverse the chain
of extension headers, if present, until they find the transport of extension headers, if present, until they find the transport
header (or an encrypted payload). Unfortunately, because not all header (or an encrypted payload). Unfortunately, because not all
IPv6 extension headers follow a uniform TLV format, this process is IPv6 extension headers follow a uniform TLV format, this process is
clumsy and requires knowledge of each extension header's format. clumsy and requires knowledge of each extension header's format.
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 traversed in the current IPv6 architecture. should be traversed 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 defined 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. It has also been observed that certain firewalls do not even
handle all the extension headers in RFC 2460, including the fragment handle all the extension headers standardised in RFC 2460, including
header [I-D.taylor-v6ops-fragdrop], causing fundamental problems of the fragment header [I-D.taylor-v6ops-fragdrop], causing fundamental
connectivity. This applies in particular to firewalls that attempt problems of connectivity. This applies in particular to firewalls
to inspect packets statelessly at very high speed, since they cannot that attempt to inspect packets statelessly at very high speed, since
take the time to reassemble fragmented packets, especially when under they cannot take the time to reassemble fragmented packets,
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 middlebox, 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 defined 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 designed extension header [Heller] for the deployment of any newly standardised extension
except for local use. It cannot be widely deployed, because existing header except for local use. It cannot be widely deployed, because
middleboxes will render large parts of the Internet opaque to it. existing middleboxes will render large parts of the Internet opaque
However, most middleboxes will not be updated to allow the new header to it. However, most middleboxes will not be updated to allow the
to pass until it has been proved safe and useful on the open new header to pass until it has been proved safe and useful on the
Internet, which is impossible until the middleboxes have been open 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 [I-D.ietf-6man-oversized-header-chain]. This will alleviate concerns
that stateless firewalls cannot handle a complete header chain as that stateless firewalls cannot handle a complete header chain as
required by the present document. required by the 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 node that forward IPv6 packets from RFC 2460 applies to all types of node that forward IPv6 packets
and to all extension headers defined now and in the future. It also and to all extension headers standardised now and in the future. It
requests IANA to create a subsidiary registry that clearly identifies also requests IANA to create a subsidiary registry that clearly
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
skipping to change at page 4, line 44 skipping to change at page 4, line 44
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.
2. Requirement to Transmit Extension Headers 2. Requirement to Transmit Extension Headers
2.1. All Extension Headers 2.1. All Extension Headers
Any forwarding node along an IPv6 packet's path, which forwards it Any forwarding node along an IPv6 packet's path, which forwards it
for any reason, SHOULD do so regardless of any extension headers that for any reason, SHOULD do so regardless of any extension headers that
are present, as described in RFC 2460. Exceptionally, if this node are present, as required by RFC 2460. Exceptionally, if this node is
is designed to examine extension headers for any reason, such as designed to examine extension headers for any reason, such as
firewalling, it MUST recognise and deal appropriately with all firewalling, it MUST recognise and deal appropriately with all
defined IPv6 extension header types. The list of currently defined standard IPv6 extension header types. The list of standard extension
extension header types is maintained by IANA (see Section 4) and header types is maintained by IANA (see Section 4) and implementors
implementors are advised to check this list regularly for updates. are advised to 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 MUST NOT do this by default, since that might cause them to nodes SHOULD NOT do this by default, since that might cause them to
inadvertently discard traffic using a recently defined extension inadvertently discard traffic using a recently standardised extension
header, not yet recognised by the intermediate node. header, not yet recognised by the intermediate node. The only
exceptions to this rule are discussed below.
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 extension headers can parse all defined nodes that inspect IPv6 extension headers can parse all standard
headers and are able to behave according to the above requirements. headers and are able to behave according to the above requirements.
If a forwarding node discards a packet containing a defined 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 defined 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 defined extension headers. Forwarding nodes MUST be SHOULD allow all standard extension headers. Forwarding nodes MUST
configurable to allow packets containing unrecognised extension be configurable to allow packets containing unrecognised extension
headers, and such packets MAY be dropped by default. headers, and such packets MAY be dropped by default.
The IPv6 Routing Header Types 0 and 1 have been deprecated and SHOULD The IPv6 Routing Header Types 0 and 1 have been deprecated and SHOULD
NOT be used. However, as specified in [RFC5095], this does not mean NOT be used. However, as specified in [RFC5095], this does not mean
that the IPv6 Routing Header can be unconditionally dropped by that the IPv6 Routing Header can be unconditionally dropped by
forwarding nodes. Packets containing undeprecated Routing Headers forwarding nodes. Packets containing undeprecated Routing Headers
SHOULD be forwarded by default. At the time of writing, these SHOULD be forwarded by default. At the time of writing, these
include Type 2 [RFC6275], Type 3 [RFC6554], and Types 253 and 254 include Type 2 [RFC6275], Type 3 [RFC6554], and Types 253 and 254
[RFC4727]. Others may be defined in future. [RFC4727]. Others may be defined in future.
skipping to change at page 5, line 47 skipping to change at page 5, line 48
this likely behaviour. this likely 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
specific extension headers are only to be discarded as a result of a standard extension headers are only to be discarded as a result of a
configurable policy. configurable policy.
When new extension headers are defined 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 account of them. It is to be expected that this will need to take account of them. A newly defined header will
process will be slow. Until it is complete, the new extension will exercise new code paths in a host that does recognise it, so caution
fail in some parts of the Internet. This aspect needs to be may be required. It is therefore to be expected that the deployment
considered when deciding to standardise a new extension. process will be slow and will depend on satisfactory operational
experience. Until it is complete, the new extension will fail in
some parts of the Internet. This aspect needs to be considered when
deciding to standardise a new extension. Specific security
considerations for each new extension should be documented in the
document that defines it.
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, for example by adding an extra column to indicate this. This types defined by an IETF standards action, for example by adding an
will also apply to any IPv6 Extension Header types defined in the extra column to indicate this. This will also apply to any IPv6
future. Extension Header types standardised in the future.
Additionally, IANA is requested to replace the existing empty IPv6 Additionally, IANA is requested to replace the existing empty IPv6
Next Header Types registry by an IPv6 Extension Header Types Next Header Types registry by an IPv6 Extension Header Types
registry. It will contain only those protocol numbers which are also registry. It will contain only those protocol numbers which are also
marked as IPv6 Extension Header types in the Assigned Internet marked as IPv6 Extension Header types in the Assigned Internet
Protocol Numbers registry. The initial list will be as follows: Protocol Numbers registry and were defined by an IETF standards
action. 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]
o 60, Destination Options, [RFC2460] o 60, Destination Options, [RFC2460]
o 135, MIPv6, [RFC6275] o 135, MIPv6, [RFC6275]
o 139, HIP, [RFC5201]
o 140, shim6, [RFC5533] o 140, shim6, [RFC5533]
This list excludes both type 59, No Next Header, [RFC2460], which is
not an extension header as such, and type 139, HIP, [RFC5201], which
is experimental.
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. interpreted as also applying to the IPv6 Extension Header field.
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, Lorenzo Colitti, contributions were made by Dominique Barthel, Tim Chown, Lorenzo
Fernando Gont, Bob Hinden, Ray Hunter, Suresh Krishnan, Marc Lampo, Colitti, Fernando Gont, C. M. Heard, Bob Hinden, Ray Hunter, Suresh
Michael Richardson, Dave Thaler, Joe Touch, and others. Krishnan, Marc Lampo, Michael Richardson, Dave Thaler, Joe Touch, 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-transmission-00: first WG version, more 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. clarifications, 2013-03-26.
draft-carpenter-6man-ext-transmission-02: clarifications following WG draft-carpenter-6man-ext-transmit-02: clarifications following WG
comments, recalibrated firewall requirements, 2013-02-22. comments, recalibrated firewall requirements, 2013-02-22.
draft-carpenter-6man-ext-transmission-01: feedback at IETF85: clarify draft-carpenter-6man-ext-transmit-01: feedback at IETF85: clarify
scope and impact on firewalls, discuss line-speed processing and lack scope and impact on firewalls, discuss line-speed processing and lack
of uniform TLV format, added references, restructured IANA of uniform TLV format, added references, restructured IANA
considerations, 2012-11-13. considerations, 2012-11-13.
draft-carpenter-6man-ext-transmission-00: original version, draft-carpenter-6man-ext-transmit-00: original version, 2012-08-14.
2012-08-14.
7. References 7. References
7.1. Normative References 7.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.E. and R.M. Hinden, "Internet Protocol, Version [RFC2460] Deering, S.E. and R.M. Hinden, "Internet Protocol, Version
6 (IPv6) Specification", RFC 2460, December 1998. 6 (IPv6) Specification", RFC 2460, December 1998.
 End of changes. 32 change blocks. 
68 lines changed or deleted 83 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/