summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6564.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6564.txt')
-rw-r--r--doc/rfc/rfc6564.txt339
1 files changed, 339 insertions, 0 deletions
diff --git a/doc/rfc/rfc6564.txt b/doc/rfc/rfc6564.txt
new file mode 100644
index 0000000..7ebe87c
--- /dev/null
+++ b/doc/rfc/rfc6564.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) S. Krishnan
+Request for Comments: 6564 Ericsson
+Updates: 2460 J. Woodyatt
+Category: Standards Track Apple
+ISSN: 2070-1721 E. Kline
+ Google
+ J. Hoagland
+ Symantec
+ M. Bhatia
+ Alcatel-Lucent
+ April 2012
+
+
+ A Uniform Format for IPv6 Extension Headers
+
+Abstract
+
+ In IPv6, optional internet-layer information is encoded in separate
+ headers that may be placed between the IPv6 header and the transport-
+ layer header. There are a small number of such extension headers
+ currently defined. This document describes the issues that can arise
+ when defining new extension headers and discusses the alternate
+ extension mechanisms in IPv6. It also provides a common format for
+ defining any new IPv6 extension headers, if they are needed.
+
+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/rfc6564.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Krishnan, et al. Standards Track [Page 1]
+
+RFC 6564 Format for IPv6 Extension Headers April 2012
+
+
+Copyright Notice
+
+ Copyright (c) 2012 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 ....................................................2
+ 2. Conventions Used in This Document ...............................3
+ 3. Applicability ...................................................3
+ 4. Proposed IPv6 Extension Header Format ...........................4
+ 5. Backward Compatibility ..........................................4
+ 6. Future Work .....................................................5
+ 7. Security Considerations .........................................5
+ 8. Acknowledgements ................................................5
+ 9. Normative References ............................................5
+
+1. Introduction
+
+ The base IPv6 standard [RFC2460] defines extension headers as an
+ expansion mechanism to carry optional internet-layer information.
+ Extension headers, with the exception of the Hop-by-Hop Options
+ header, are not usually processed on intermediate nodes. However,
+ several existing deployed IPv6 routers and several existing deployed
+ IPv6 firewalls, in contradiction to [RFC2460], are capable of parsing
+ past or ignoring all currently defined IPv6 extension headers (e.g.,
+ to examine transport-layer header fields) at wire speed (e.g., by
+ using custom Application-specific Integrated Circuits (ASICs) for
+ packet processing). Hence, one must also consider that any new IPv6
+ extension header will break IPv6 deployments that use these existing
+ capabilities.
+
+ Any IPv6 header or option that has hop-by-hop behavior, and is
+ intended for general use in the public IPv6 Internet, could be
+ subverted to create an attack on IPv6 routers that process packets
+ containing such a header or option. Reports from the field indicate
+ that some IP routers deployed within the global Internet are
+ configured either to ignore the presence of headers with hop-by-hop
+
+
+
+Krishnan, et al. Standards Track [Page 2]
+
+RFC 6564 Format for IPv6 Extension Headers April 2012
+
+
+ behavior or to drop packets containing headers with hop-by-hop
+ behavior.
+
+2. Conventions Used in This Document
+
+ 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].
+
+3. Applicability
+
+ The base IPv6 standard [RFC2460] allows the use of both extension
+ headers and destination options in order to encode optional
+ destination information in an IPv6 packet. The use of destination
+ options to encode this information provides more flexible handling
+ characteristics and better backward compatibility than using
+ extension headers. Because of this, implementations SHOULD use
+ destination options as the preferred mechanism for encoding optional
+ destination information, and use a new extension header only if
+ destination options do not satisfy their needs. The request for
+ creation of a new IPv6 extension header MUST be accompanied by a
+ specific explanation of why destination options could not be used to
+ convey this information.
+
+ The base IPv6 standard [RFC2460] defines 3 extension headers (i.e.,
+ Routing header, Destination Options header, Hop-by-Hop Options
+ header) to be used for any new IPv6 options. The same standard only
+ allows the creation of new extension headers in limited circumstances
+ ([RFC2460], Section 4.6).
+
+ As noted above, the use of any option with hop-by-hop behavior can be
+ problematic in the global public Internet. New IPv6 extension
+ header(s) having hop-by-hop behavior MUST NOT be created or
+ specified. New options for the existing Hop-by-Hop Header SHOULD NOT
+ be created or specified unless no alternative solution is feasible.
+ Any proposal to create a new option for the existing Hop-by-Hop
+ Header MUST include a detailed explanation of why the hop-by-hop
+ behavior is absolutely essential in the document proposing the new
+ option with hop-by-hop behavior.
+
+ The use of IPv6 Destination Options to encode information provides
+ more flexible handling characteristics and better backward
+ compatibility than using a new extension header. Because of this,
+ new optional information to be sent SHOULD be encoded in a new option
+ for the existing IPv6 Destination Options header.
+
+
+
+
+
+
+Krishnan, et al. Standards Track [Page 3]
+
+RFC 6564 Format for IPv6 Extension Headers April 2012
+
+
+ Mindful of the need for compatibility with existing IPv6 deployments,
+ new IPv6 extension headers MUST NOT be created or specified, unless
+ no existing IPv6 extension header can be used by specifying a new
+ option for that existing IPv6 extension header. Any proposal to
+ create or specify a new IPv6 extension header MUST include a detailed
+ technical explanation of why no existing IPv6 extension header can be
+ used in the document proposing the new IPv6 extension header.
+
+4. Proposed IPv6 Extension Header Format
+
+ Any IPv6 extension headers defined in the future, keeping in mind the
+ restrictions specified in Section 3 and also the restrictions
+ specified in [RFC2460], MUST use the consistent format defined in
+ Figure 1. This minimizes breakage in intermediate nodes that examine
+ these extension headers.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Next Header | Hdr Ext Len | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
+ | |
+ . .
+ . Header Specific Data .
+ . .
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Next Header 8-bit selector. Identifies the type of header
+ immediately following the extension header.
+ Uses the same values as the IPv4 Protocol field
+ [IANA_IP_PARAM].
+
+ Hdr Ext Len 8-bit unsigned integer. Length of the extension
+ header in 8-octet units, not including the first
+ 8 octets.
+
+ Header Specific Variable length. Fields specific to the
+ Data extension header.
+
+ Figure 1: Extension Header Layout
+
+5. Backward Compatibility
+
+ The scheme proposed in this document is not intended to be backward
+ compatible with all the currently defined IPv6 extension headers. It
+ applies only to newly defined extension headers. Specifically, the
+
+
+
+
+Krishnan, et al. Standards Track [Page 4]
+
+RFC 6564 Format for IPv6 Extension Headers April 2012
+
+
+ fragment header predates this document and does not follow the format
+ proposed in this document.
+
+6. Future Work
+
+ This document proposes one step in easing the inspection of extension
+ headers by middleboxes. There is further work required in this area.
+ Some issues that are left unresolved beyond this document include:
+
+ o There can be an arbitrary number of extension headers.
+
+ o Extension headers must be processed in the order they appear.
+
+ o Extension headers may alter the processing of the payload itself,
+ and hence the packet may not be processed properly without
+ knowledge of said header.
+
+7. Security Considerations
+
+ This document proposes a standard format for the IPv6 extension
+ headers that minimizes breakage at intermediate nodes that inspect
+ but do not understand the contents of these headers. Intermediate
+ nodes, such as firewalls, that skip over unknown headers might end up
+ allowing the setup of a covert channel from the outside of the
+ firewall to the inside using the data field(s) of the unknown
+ extension headers.
+
+8. Acknowledgements
+
+ The authors would like to thank Albert Manfredi, Bob Hinden, Brian
+ Carpenter, Erik Nordmark, Hemant Singh, Lars Westberg, Markku Savela,
+ Tatuya Jinmei, Thomas Narten, Vishwas Manral, Alfred Hoenes, Joel
+ Halpern, Ran Atkinson, Steven Blake, Jari Arkko, Kathleen Moriarty,
+ Stephen Farrell, Ralph Droms, Sean Turner, and Adrian Farrel for
+ their reviews and suggestions that made this document better.
+
+9. Normative References
+
+ [IANA_IP_PARAM] IANA, "IP Parameters",
+ <http://www.iana.org/assignments/ip-parameters>.
+
+ [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.
+
+
+
+
+Krishnan, et al. Standards Track [Page 5]
+
+RFC 6564 Format for IPv6 Extension Headers April 2012
+
+
+Authors' Addresses
+
+ Suresh Krishnan
+ Ericsson
+ 8400 Decarie Blvd.
+ Town of Mount Royal, QC
+ Canada
+ Phone: +1 514 345 7900 x42871
+ EMail: suresh.krishnan@ericsson.com
+
+
+ James Woodyatt
+ Apple Inc.
+ 1 Infinite Loop
+ Cupertino, CA 95014
+ US
+ EMail: jhw@apple.com
+
+
+ Erik Kline
+ Google
+ Mori Tower 26F
+ Roppongi 6-10-1
+ Minato ku
+ Tokyo 106-6126
+ Japan
+ Phone: +81 3-6384-9635
+ EMail: ek@google.com
+
+
+ James Hoagland
+ Symantec Corporation
+ 350 Ellis St.
+ Mountain View, CA 94043
+ US
+ EMail: Jim_Hoagland@symantec.com
+ URI: http://symantec.com/
+
+
+ Manav Bhatia
+ Alcatel-Lucent
+ Bangalore
+ India
+ EMail: manav.bhatia@alcatel-lucent.com
+
+
+
+
+
+
+
+Krishnan, et al. Standards Track [Page 6]
+