GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc7045

Internet Engineering Task Force (IETF) B. Carpenter Request for Comments: 7045 Univ. of Auckland Updates: 2460, 2780 S. Jiang Category: Standards Track Huawei Technologies Co., Ltd. ISSN: 2070-1721 December 2013

       Transmission and Processing of IPv6 Extension Headers

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 the future.  It also
 specifies how extension headers should be registered by IANA, with a
 corresponding minor update to RFC 2780.

Status of This Memo

 This is an Internet Standards Track document.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Further information on
 Internet Standards is available in Section 2 of RFC 5741.
 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 (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.

Carpenter & Jiang Standards Track [Page 1] RFC 7045 IPv6 Extension Header Transmission December 2013

Table of Contents

 1.  Introduction and Problem Statement  . . . . . . . . . . . . .   2
   1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4
 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 . . . . . . . . . . . . . . . . . . . . .   7
 5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   8
 6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
   6.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
   6.2.  Informative References  . . . . . . . . . . . . . . . . .   8

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
 nodes, with the exception of the Hop-by-Hop Options header:
    ...extension headers are not examined or processed 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) identified
    in the Destination Address field of the IPv6 header.
 This provision meant that forwarding nodes should be completely
 transparent to extension headers.  There was no provision for
 forwarding nodes to modify them, remove them, insert them, or use
 them to affect forwarding behaviour.  Thus, new extension headers
 could be introduced progressively and 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
 was published.
 Today, IPv6 packets are not always forwarded by straightforward IP
 routing based on their first 40 bytes.  Some routers, and a variety
 of intermediate nodes often referred to as middleboxes, such as
 firewalls, load balancers, or packet classifiers, might inspect other
 parts of each packet.  Indeed, such middlebox functions are often
 embedded in routers.  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

Carpenter & Jiang Standards Track [Page 2] RFC 7045 IPv6 Extension Header Transmission December 2013

 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
 [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 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 was published.  It has also been observed that certain firewalls
 do not even handle all the extension headers standardised in RFC
 2460, including the fragment header [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
 they cannot take the time to reassemble fragmented packets,
 especially when under a denial-of-service attack.
 Other types of middleboxes, such as load balancers or packet
 classifiers, might also fail in the presence of extension headers
 that they do not recognise.
 A contributory factor to this problem is that because extension
 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
 an implementor to quickly identify the full set of standard extension
 headers.  An implementor who consults only RFC 2460 will miss all
 extension headers defined subsequently.
 This combination of circumstances creates a "Catch-22" situation
 [Heller] for the deployment of any newly standardised extension
 header except for local use.  It cannot be widely deployed because
 existing middleboxes will drop it on many paths through the Internet.
 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
 Internet, which is impossible until the middleboxes have been
 updated.

Carpenter & Jiang Standards Track [Page 3] RFC 7045 IPv6 Extension Header Transmission December 2013

 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
 [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 nodes that forward IPv6 packets
 and to all extension headers standardised now and in the future.  It
 also requests that IANA 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.

1.1. Terminology

 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 [RFC5226].
 "Experimental" extension headers include those defined by any
 Experimental RFC and the header values 253 and 254 defined by
 [RFC3692] and [RFC4727] when used as experimental extension headers.
 "Defined" extension headers are the "standard" extension headers plus
 the "experimental" ones.

Carpenter & Jiang Standards Track [Page 4] RFC 7045 IPv6 Extension Header Transmission December 2013

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 be able to 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
 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, since that might cause them to
 inadvertently discard traffic using a recently standardised extension
 header not yet recognised by the intermediate node.  The exceptions
 to this rule are discussed next.
 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 standard type of extension
 header MUST be individually configurable.  The default configuration
 SHOULD allow all standard extension headers.
 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 the default configuration MAY
 drop such packets.
 The IPv6 Routing Header Types 0 and 1 have been deprecated.  Note
 that Type 0 was deprecated by [RFC5095].  However, this does not mean
 that the IPv6 Routing Header can be unconditionally dropped by

Carpenter & Jiang Standards Track [Page 5] RFC 7045 IPv6 Extension Header Transmission December 2013

 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 the future.

2.2. Hop-by-Hop Options

 The IPv6 Hop-by-Hop Options header SHOULD be processed by
 intermediate forwarding nodes as described in [RFC2460].  However, it
 is to be expected that high-performance routers will either ignore it
 or assign packets containing it to a slow processing path.  Designers
 planning to use a hop-by-hop option need to be aware of 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 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 Sections 1 and 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
 implementing and configuring forwarding nodes, including firewalls,
 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.  Additional security issues with experimental values

Carpenter & Jiang Standards Track [Page 6] RFC 7045 IPv6 Extension Header Transmission December 2013

 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 has added an extra column titled "IPv6 Extension Header" to the
 "Assigned Internet Protocol Numbers" registry to clearly mark those
 values that are also IPv6 extension header types defined by an IETF
 Standards Action or IESG Approval (see list below).  This also
 applies to IPv6 extension header types defined in the future.
 Additionally, IANA has closed the existing empty "Next Header Types"
 registry to new entries and is redirecting its users to a new "IPv6
 Extension Header Types" registry.  This registry contains only those
 protocol numbers that 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, IPv6 Hop-by-Hop Option, [RFC2460]
 o  43, Routing Header for IPv6, [RFC2460], [RFC5095]
 o  44, Fragment Header for IPv6, [RFC2460]
 o  50, Encapsulating Security Payload, [RFC4303]
 o  51, Authentication Header, [RFC4302]
 o  60, Destination Options for IPv6, [RFC2460]
 o  135, Mobility Header, [RFC6275]
 o  139, Experimental use, Host Identity Protocol [RFC5201]
 o  140, Shim6 Protocol, [RFC5533]
 o  253, Use for experimentation and testing, [RFC3692], [RFC4727]
 o  254, Use for experimentation and testing, [RFC3692], [RFC4727]
 This list excludes type 59, No Next Header, [RFC2460], which is not
 an extension header as such.

Carpenter & Jiang Standards Track [Page 7] RFC 7045 IPv6 Extension Header Transmission December 2013

 The references to the IPv6 Next Header field in [RFC2780] are to be
 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, Sandra Murphy, Michael Richardson, Dan
 Romascanu, Dave Thaler, Joe Touch, Bjoern Zeeb, and others.
 Brian Carpenter was a visitor at the Computer Laboratory at Cambridge
 University during part of this work.

6. References

6.1. Normative References

 [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119, March 1997.
 [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.
 [RFC4727]  Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4,
            ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006.
 [RFC6564]  Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and
            M. Bhatia, "A Uniform Format for IPv6 Extension Headers",
            RFC 6564, April 2012.

6.2. Informative References

 [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.

Carpenter & Jiang Standards Track [Page 8] RFC 7045 IPv6 Extension Header Transmission December 2013

 [HEADER-CHAIN]
            Gont, F., Manral, V., and R. Bonica, "Implications of
            Oversized IPv6 Header Chains", Work in Progress, October
            2013.
 [Heller]   Heller, J., "Catch-22", Simon and Schuster, November 1961.
 [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.
 [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
            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.

Carpenter & Jiang Standards Track [Page 9] RFC 7045 IPv6 Extension Header Transmission December 2013

Authors' Addresses

 Brian Carpenter
 Department of Computer Science
 University of Auckland
 PB 92019
 Auckland  1142
 New Zealand
 EMail: brian.e.carpenter@gmail.com
 Sheng Jiang
 Huawei Technologies Co., Ltd.
 Q14, Huawei Campus
 No. 156 Beiqing Road
 Hai-Dian District, Beijing  100095
 P.R. China
 EMail: jiangsheng@huawei.com

Carpenter & Jiang Standards Track [Page 10]

/data/webs/external/dokuwiki/data/pages/rfc/rfc7045.txt · Last modified: 2013/12/06 18:46 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki