Internet Engineering Task Force H. Pfeifer, Ed. Internet-Draft Protocol Labs Intended status: Standards Track September 11, 2011 Expires: March 14, 2012 IPv6 Extension Headers Reserved Space draft-pfeifer-6man-exthdr-res-01.txt Abstract This document specify a mechanism to allow IPv6 stack implementation to parse upcoming IPv6 extension header by reserving a small range of protocol numbers for well defined IPv6 extension headers. IPv6 stack implementors can code these range into their network stack a priori. These reserved range provide an guarantee that a given next header is a well formed extension header and not a next layer protocol. Operators, companies, vendors et cetera are in the ability to deploy and test not standardized extension headers without modifying every middle box parsing the complete extension header chain in between. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on March 14, 2012. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. Pfeifer Expires March 14, 2012 [Page 1] Internet-Draft Abbreviated Title September 2011 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 BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Extension Header Encoding . . . . . . . . . . . . . . . . . . . 4 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 7. Normative References . . . . . . . . . . . . . . . . . . . . . 6 Appendix A. Implementation Example . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 Pfeifer Expires March 14, 2012 [Page 2] Internet-Draft Abbreviated Title September 2011 1. Introduction Optional IPv6 protocol information are encoded in extension header between the basic IPv6 header and the next layer protocol. Next layer protocols such as TCP or UDP are encoded in a non uniform manner. Network stacks that process the extension header chain are required to know the exact encoding of all stagged headers until the required next layer protocol is detected. If a unknown protocol or extension header lies between the processing must be stopped. Extension header are normally not processed on intermediate nodes [RFC2460]. Intermediate nodes are urged to not examine or process any extension header. One exception is is the hop-by-hop options header which must be processed. Sometimes nodes along a packet's delivery path are required to parse the complete extension header chain to analyze the transport layer protocol. Middleboxes which analyze the transport protocol header are the most prominent example. Firewalls or network proxies are the most prominent examples. Middle boxes have no possibility to resolve this circumstance cleanly. Firewalls are likely to drop the packet. End-boxed following [RFC2460] generate a ICMP Parameter Problem message if an unknown extension header is detected. Providing the sender enough information to resend the packet without the extension header. [I-D.ietf-6man-exthdr] defines a standard format to unify the layout of IPv6 extension header and advised to use the IPv6 Destination Options Header. Thus providing a way that future extensions are encoded in a consistent manner. This is the first part to address this unlucky fact. The second half of the problem lies in the fact that the next header space is shared with the protocol number. Network stack cannot differentiate if an unknown code-point declaring an extension header or an protocol. 1.1. Requirements Language 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 RFC 2119 [RFC2119]. 2. Overview This mechanism provide middle boxes the chance to process up to now new extension header and simultaneous do not constrain the possibility to introduce new extension header in future by reserving a small fraction of protocol number space. Pfeifer Expires March 14, 2012 [Page 3] Internet-Draft Abbreviated Title September 2011 Future IPv6 extensions which cannot encoded in one of the existing extension header MUST follow the encoding specification in [I-D.ietf-6man-exthdr]. Upcoming standardized extension header following the proposal MUST be reserved from this space. Network stacks are provided with a guarantee that these extension headers follow the specification. Currently 60% of the space is already allocated. Thus to be conservative a good compromise is to reserve the range between 245 and 252 (7). This leave space for 98 new next layer protocols, 98 extension header not following the proposal or any combination of both. Upcoming standardized extension header following the proposal MUST be reserved from this space. Providing an guarantee of the encoding makes it possible that vendors and other parties implement proprietary extension header without standardization and wait years of enrollment of new middle-boxes supporting the new extension header. 3. Extension Header Encoding The following figure illustrate the format of the unified extension header format. It will be removed if [I-D.ietf-6man-exthdr] is approved. Pfeifer Expires March 14, 2012 [Page 4] Internet-Draft Abbreviated Title September 2011 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. 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 Uniform IPv6 Extension Header Figure 1 4. Acknowledgements The author thank Suresh Krishnan, James Woodyatt, Erik Kline, James Hoagland, Manav Bhatia and all other people involved in [I-D.ietf-6man-exthdr]. 5. IANA Considerations This document includes a request to IANA. The editors of this draft request the protocol number 245 till 252 be reserved for uniform formated IPv6 extension header 6. Security Considerations Filled later Pfeifer Expires March 14, 2012 [Page 5] Internet-Draft Abbreviated Title September 2011 7. Normative References [I-D.ietf-6man-exthdr] Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and M. Bhatia, "An uniform format for IPv6 extension headers", draft-ietf-6man-exthdr-04 (work in progress), July 2011. [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. Appendix A. Implementation Example The following patch applied on net-next-2.6 add support for the code- point reservation. diff --git a/net/ipv6/exthdrs_core.c b/net/ipv6/exthdrs_core.c index 14ed0a9..d7f2e97 100644 --- a/net/ipv6/exthdrs_core.c +++ b/net/ipv6/exthdrs_core.c @@ -4,6 +4,9 @@ */ #include +#define IP6_EXTHDR_RESERVED_MIN 245 +#define IP6_EXTHDR_RESERVED_MAX 252 + /* * find out if nxthdr is a well-known extension header or a protocol */ @@ -18,7 +21,8 @@ int ipv6_ext_hdr(u8 nexthdr) (nexthdr == NEXTHDR_FRAGMENT) || (nexthdr == NEXTHDR_AUTH) || (nexthdr == NEXTHDR_NONE) || - (nexthdr == NEXTHDR_DEST); + (nexthdr == NEXTHDR_DEST) || + (nexthdr >= IP6_EXTHDR_RESERVED_MIN && + nexthdr <= IP6_EXTHDR_RESERVED_MAX); } Figure 2 Pfeifer Expires March 14, 2012 [Page 6] Internet-Draft Abbreviated Title September 2011 Author's Address Hagen Paul Pfeifer (editor) Protocol Labs Hofmannstr. 19 81379, Munich Germany Phone: +49 174 5455 209 Email: hagen.pfeifer@protocollabs.com URI: http://www.protocollabs.com Pfeifer Expires March 14, 2012 [Page 7]