--- 1/draft-ietf-6man-ext-transmit-03.txt 2013-09-25 22:14:24.473028674 -0700 +++ 2/draft-ietf-6man-ext-transmit-04.txt 2013-09-25 22:14:24.497029299 -0700 @@ -1,19 +1,19 @@ 6man B. Carpenter Internet-Draft Univ. of Auckland Updates: 2460, 2780 (if approved) S. Jiang Intended status: Standards Track Huawei Technologies Co., Ltd -Expires: February 23, 2014 August 22, 2013 +Expires: March 30, 2014 September 26, 2013 Transmission and Processing of IPv6 Extension Headers - draft-ietf-6man-ext-transmit-03 + draft-ietf-6man-ext-transmit-04 Abstract Various IPv6 extension headers have been standardised since the IPv6 standard was first published. This document updates RFC 2460 to clarify how intermediate nodes should deal with such extension headers and with any that are defined in future. It also specifies how extension headers should be registered by IANA, with a corresponding minor update to RFC 2780. @@ -25,52 +25,52 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on February 23, 2014. + This Internet-Draft will expire on March 30, 2014. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction and Problem Statement . . . . . . . . . . . . . 2 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 - 2. Requirement to Transmit Extension Headers . . . . . . . . . . 4 - 2.1. All Extension Headers . . . . . . . . . . . . . . . . . . 4 - 2.2. Hop-by-Hop Options . . . . . . . . . . . . . . . . . . . 5 + 2. Requirement to Transmit Extension Headers . . . . . . . . . . 5 + 2.1. All Extension Headers . . . . . . . . . . . . . . . . . . 5 + 2.2. Hop-by-Hop Options . . . . . . . . . . . . . . . . . . . 6 3. Security Considerations . . . . . . . . . . . . . . . . . . . 6 - 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 + 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 - 6. Change log [RFC Editor: Please remove] . . . . . . . . . . . 7 + 6. Change log [RFC Editor: Please remove] . . . . . . . . . . . 8 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 - 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 + 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 7.2. Informative References . . . . . . . . . . . . . . . . . 9 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction and Problem Statement In IPv6, an extension header is any header that follows the initial 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 Header"). An initial set of IPv6 extension headers was defined by [RFC2460], which also described how they should be handled by intermediate @@ -86,38 +86,38 @@ forwarding nodes to modify them, remove them, insert them, or use them to affect forwarding behaviour. Thus, new extension headers could be introduced progressively, used only by hosts that have been updated to create and interpret them [RFC6564]. The extension header mechanism 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 routers, but also by a variety of intermediate nodes, often referred to as middleboxes, such as firewalls, load balancers, or packet - classifiers. However, experience has showed that as a result, the + classifiers. However, experience has shown that as a result, the network is not transparent to IPv6 extension headers. Contrary to Section 4 of RFC 2460, middleboxes sometimes examine and process 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 header (or an encrypted payload). Unfortunately, because not all IPv6 extension headers follow a uniform TLV format, this 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 precluding its use in nodes attempting to process packets at line speed. The present document does not intend to solve this problem, which is caused by the fundamental architecture of IPv6 extension headers. This document focuses on clarifying how the header chain - should be traversed in the current IPv6 architecture. + should be handled in the current IPv6 architecture. If they encounter an unrecognised extension header type, some firewalls treat the packet as suspect and drop it. Unfortunately, it is an established fact that several widely used firewalls do not recognise some or all of the extension headers standardised since RFC 2460. It has also been observed that certain firewalls do not even handle all the extension headers standardised in RFC 2460, including the fragment header [I-D.taylor-v6ops-fragdrop], causing fundamental problems of end-to-end connectivity. This applies in particular to firewalls that attempt to inspect packets at very high speed, since @@ -147,21 +147,21 @@ The uniform TLV format now defined for extension headers [RFC6564] will improve the situation, but only for future extensions. Some tricky and potentially malicious cases will be avoided by forbidding very long chains of extension headers that need to be fragmented [I-D.ietf-6man-oversized-header-chain]. This will alleviate concerns that stateless firewalls cannot locate a complete header chain as required by the present document. However, these changes are insufficient to correct the underlying 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 nodes that forward IPv6 packets and to all extension headers standardised now and in the future. It also requests IANA to create a subsidiary registry that clearly identifies extension header types, and updates RFC 2780 accordingly. Fundamental changes to the IPv6 extension header architecture are out of scope for this document. 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 requirements for processing the Hop-by-Hop options header to make them more realistic. @@ -170,62 +170,71 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. In the remainder of this document, the term "forwarding node" refers to any router, firewall, load balancer, prefix translator, or any other device or middlebox that forwards IPv6 packets with or without examining the packet in any way. + In this document "standard" IPv6 extension headers are those + specified in detail by IETF standards actions. "Experimental" + extension headers are those defined by any Experimental RFC, and the + experimental extension header values 253 and 254 defined by [RFC3692] + and [RFC4727]. "Defined" extension headers are the "standard" + extension headers plus the "experimental" ones. + 2. Requirement to Transmit Extension Headers 2.1. All Extension Headers + As mentioned above, forwarding nodes that discard packets containing + extension headers are known to cause connectivity failures and + deployment problems. Therefore, it is important that forwarding + nodes that inspect IPv6 headers can parse all defined extension + headers and deal with them appropriately, as specified in this + section. + Any forwarding node along an IPv6 packet's path, which forwards the packet for any reason, SHOULD do so regardless of any extension headers that are present, as required by RFC 2460. Exceptionally, if - this node is designed to examine extension headers for any reason, - such as firewalling, it MUST recognise and deal appropriately with - all standardised IPv6 extension header types and SHOULD recognise - experimental IPv6 extension header types. The list of standardised - and experimental extension header types is maintained by IANA (see - Section 4) and implementors are advised to check this list regularly - for updates. + a forwarding node is designed to examine extension headers for any + reason, such as firewalling, it MUST recognise and deal appropriately + with all standard IPv6 extension header types and SHOULD recognise + and deal appropriately with experimental IPv6 extension header types. + The list of standard and experimental extension header types is + maintained by IANA (see Section 4) and implementors are advised to + check this list regularly for updates. RFC 2460 requires destination hosts to discard packets containing unrecognised extension headers. However, intermediate forwarding - nodes SHOULD NOT do this by default, 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 - header, not yet recognised by the intermediate node. The only - exceptions to this rule are discussed below. + header, not yet recognised by the intermediate node. The exceptions + to this rule are discussed next. - As mentioned above, forwarding nodes that discard packets containing - extension headers are known to cause connectivity failures and - deployment problems. Therefore, it is important that forwarding - nodes that inspect IPv6 extension headers can parse all standard - headers and are able to behave according to the above requirements. If a forwarding node discards a packet containing a standard IPv6 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 - means that the discard policy for each standardised type of extension + means that the discard policy for each standard type of extension header MUST be individually configurable. The default configuration - SHOULD allow all standardised extension headers. + SHOULD allow all standard extension headers. - Experimental IPv6 extension headers, including types 253 and 254 - defined by [RFC3692] and [RFC4727], SHOULD be treated in the same way - as standardised extension headers, but they MAY be dropped by - default. + Experimental IPv6 extension headers SHOULD be treated in the same way + as standard extension headers, including an individually configurable + discard policy. However, the default configuration MAY drop + experimental extension headers. Forwarding nodes MUST be configurable to allow packets containing - unrecognised extension headers, but such packets MAY be dropped by - default. + unrecognised extension headers, but the default configuration MAY + drop such packets. The IPv6 Routing Header Types 0 and 1 have been deprecated [RFC5095]. However, this does not mean that the IPv6 Routing Header can be unconditionally dropped by forwarding nodes. Packets containing standardised and undeprecated Routing Headers SHOULD be forwarded by default. At the time of writing, these include Type 2 [RFC6275], Type 3 [RFC6554], and the experimental Routing Header Types 253 and 254 [RFC4727]. Others may be defined in future. 2.2. Hop-by-Hop Options @@ -238,49 +247,60 @@ this likely behaviour. As a reminder, in RFC 2460, it is stated that the Hop-by-Hop Options header, if present, must be first. 3. Security Considerations Forwarding nodes that operate as firewalls MUST conform to the requirements in the previous section in order to respect the IPv6 extension header architecture. In particular, packets containing - standard extension headers are only to be discarded as a result of a - configurable policy. + standard extension headers are only to be discarded as a result of an + intentionally configured policy. + + These changes do not affect a firewall's ability to filter out + traffic containing unwanted or suspect extension headers, if + configured to do so. However, the changes do require firewalls to be + capable of permitting any or all extension headers, if configured to + do so. The default configurations are intended to allow normal use + of any standard extension header, avoiding the connectivity issues + described in Section 1 and Section 2.1. When new extension headers are standardised in the future, those implementing and configuring forwarding nodes, including firewalls, - will need to take account of them. 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 - may be required. It is therefore to be expected that the deployment - 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. + may be required. Additional security issues with experimental values + 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 + slow and will depend on satisfactory operational experience. Until + deployment 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 IANA is requested to clearly mark in the Assigned Internet Protocol Numbers registry those values which are also IPv6 Extension Header - types defined by an IETF action, for example by adding an extra - column to indicate this. This will also apply to any IPv6 Extension + types defined by an IETF Standards Action or IESG Approval (see list + below), for example by adding an extra column title "IPv6 Extension + Header" to indicate this. This will also apply to any IPv6 Extension Header types defined in the future. - Additionally, IANA is requested to replace the existing empty IPv6 - Next Header Types registry by an IPv6 Extension Header Types - registry. It will contain only those protocol numbers which are also - marked as IPv6 Extension Header types in the Assigned Internet - Protocol Numbers registry. Experimental values will be marked as - such. The initial list will be as follows: + Additionally, IANA is requested to make the existing empty IPv6 Next + Header Types registry redirect users to a new IPv6 Extension Header + Types registry. It will contain only those protocol numbers which + are also marked as IPv6 Extension Header types in the Assigned + Internet Protocol Numbers registry. Experimental values will be + marked as such. The initial list will be as follows: o 0, Hop-by-Hop Options, [RFC2460] o 43, Routing, [RFC2460], [RFC5095] o 44, Fragment, [RFC2460] o 50, Encapsulating Security Payload, [RFC4303] o 51, Authentication, [RFC4302] @@ -293,38 +314,42 @@ o 140, shim6, [RFC5533] o 253, experimental use, [RFC3692], [RFC4727] o 254, experimental use, [RFC3692], [RFC4727] This list excludes type 59, No Next Header, [RFC2460], which is not an extension header as such. 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 and + the IPv6 Extension Header Types registry will be managed accordingly. 5. Acknowledgements - This document was triggered by mailing list discussions including John Leslie, Stefan Marksteiner and others. Valuable comments and contributions were made by Dominique Barthel, Tim Chown, Lorenzo Colitti, Fernando Gont, C. M. Heard, Bob Hinden, Ray Hunter, Suresh - Krishnan, Marc Lampo, Michael Richardson, Dave Thaler, Joe Touch, - Bjoern Zeeb, and others. + Krishnan, Marc Lampo, Sandra Murphy, Michael Richardson, Dan + Romascanu, Dave Thaler, Joe Touch, Bjoern Zeeb, and others. Brian Carpenter was a visitor at the Computer Laboratory, Cambridge University during part of this work. This document was produced using the xml2rfc tool [RFC2629]. 6. Change log [RFC Editor: Please remove] + 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. @@ -351,64 +375,64 @@ [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers", BCP 37, RFC 2780, March 2000. [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, January 2004. - [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December - 2005. - - [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC - 4303, December 2005. - [RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006. - [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation - of Type 0 Routing Headers in IPv6", RFC 5095, December - 2007. - - [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, - "Host Identity Protocol", RFC 5201, April 2008. - - [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming - Shim Protocol for IPv6", RFC 5533, June 2009. - - [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support - in IPv6", RFC 6275, July 2011. - [RFC6564] Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and M. Bhatia, "A Uniform Format for IPv6 Extension Headers", RFC 6564, April 2012. 7.2. Informative References [Heller] Heller, J., "Catch-22", Simon and Schuster , 1961. [I-D.ietf-6man-oversized-header-chain] Gont, F., Manral, V., and R. Bonica, "Implications of Oversized IPv6 Header Chains", draft-ietf-6man-oversized- - header-chain-04 (work in progress), August 2013. + header-chain-07 (work in progress), September 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, June 1999. + [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December + 2005. + + [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC + 4303, December 2005. + + [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation + of Type 0 Routing Headers in IPv6", RFC 5095, December + 2007. + + [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, + "Host Identity Protocol", RFC 5201, April 2008. + + [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming + Shim Protocol for IPv6", RFC 5533, June 2009. + + [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support + in IPv6", RFC 6275, July 2011. + [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 Routing Header for Source Routes with the Routing Protocol for Low-Power and Lossy Networks (RPL)", RFC 6554, March 2012. Authors' Addresses Brian Carpenter Department of Computer Science University of Auckland