doc: Add RFC documents

1 files changed, 563 insertions, 0 deletions

diff --git a/doc/rfc/rfc7045.txt b/doc/rfc/rfc7045.txt
new file mode 100644
index 0000000..d69701d
--- /dev/null
+++ b/doc/rfc/rfc7045.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+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]
+