6man Working Group Manav Bhatia Internet Draft Alcatel-Lucent Intended status: Standards Track Expires: March, 2011 September 2010 Standardizing IPv6 Extension Header Definition draft-bhatia-6man-update-ipv6-ext-hdr-00.txt 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on March 2011. Copyright Notice Copyright (c) 2010 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. Bhatia, Manav Standards Track [Page 1] Internet-Draft September 2010 Abstract In IPv6, optional internet-layer information is encoded in separate headers that may be placed between the IPv6 header and the upper-layer header in a packet. There are a small number of such extension headers, each identified by a distinct Next Header value. However, it presents no backward compatible way for incrementally introducing new IPv6 extension headers inside the network. Additionally since there is no standard format for extension headers, it becomes impossible for intermediaries that want to deep inspect the packet to parse an incoming packet which carries an extension header that it does not recognize. This document attempts to standardize the IPv6 extension header format to fix these issues. 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 RFC 2119. [RFC2119] Table of Contents 1. Problem Definition............................................2 2. Standard IPv6 Extension Header Format.........................3 3. Incremental Deployments.......................................5 4. Intermediary Nodes............................................5 5. Security Considerations.......................................5 6. IANA Considerations...........................................5 7. References....................................................5 7.1. Normative References.....................................5 7.2. Informative References...................................5 1. Problem Definition The IPv6 standard [RFC2460] defines extension headers that can be used to encode optional internet layer information and are placed between the IPv6 main header and the upper-layer header of the packet. This helps in improving forwarding performance as the intermediate routers only look at the IPv6 main header and dont process the extension headers treating them as part of the packet payload. Bhatia, Manav Expires March 2011 [Page 2] Internet-Draft September 2010 The architecture is very flexible for developing new extension headers for future uses as needed. New extension headers [RFC3775] can be defined and used without changing the IPv6 main header. [RFC2460] allows us to chain multiple extension headers by using the Next Header field. The Next Header field indicates to the router which extension header to expect next. If there are no more extension headers, the next header field indicates the upper layer header (TCP, UDP, etc). [RFC2460] further states that an end node that comes across an unrecognized Next Header should discard that packet and send an ICMP Parameter Problem message to the source of the packet, with an ICMP code value of 1 ("unrecognized Next Header type encountered") and the ICMP Pointer field containing the offset of the unrecognized value within the original packet. This creates a problem in incrementally introducing new IPv6 extension headers inside the network as all routers need to get upgraded at the same time so that they don't discard packets. This is cumbersome and is not always possible. Another problem that exists is that if new extension headers are defined, and if an intermediate device that wants to deep inspect the packets is not aware of these extension headers, then it may not be able to process the packet as it will not know where the new unknown extension header ends and the next one begins. This document proposes to standardize the IPv6 extension header format for fixing the above mentioned issues. 2. Standard IPv6 Extension Header Format All IPv6 Extension Headers should have the format as described in the following figure: Bhatia, Manav Expires March 2011 [Page 3] Internet-Draft September 2010 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 | Header Len | Hdr Options | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | ~ Extension Header Specific Data ~ | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1 Next Header 8 bit selector that identifies the type of header immediately following the Extension Header. Uses the same values as the IPv6 Next Header field [RFC2460]. Header Len 8-bit selector that indicates the length in 8 octet units of the extension header, not including the first 8 octets. Hdr Options 8-bit selector where the highest two bits specify the action that must be taken if the processing IPv6 node does not recognize the extension header: 00 skip over this option and continue processing the header. 01 discard the packet. 10 discard the packet and, regardless of whether or not the packet's Destination Address was a multicast address, send an ICMP Parameter Problem, Code 1, message to the packet's Source Address, pointing to the unrecognized value within the original packet. 11 discard the packet and, only if the packet's Destination Address was not a multicast address, send an ICMP parameter Problem, Code 1, message to the packet's Source Address, pointing to the unrecognized value within the original packet. Bhatia, Manav Expires March 2011 [Page 4] Internet-Draft September 2010 3. Incremental Deployments New extension headers can set the highest order bits in the Header Options of the extension header to 00 so that the end node can still process the original packet. This will obviously only help if the end node can still function without being able to understand the new extension header. An example of this is [karp-non-ipsec-ospfv3-auth]. 4. Intermediary Nodes Intermediaries that cannot recognize the new extension header can look at the length of the extension header and skip as many bytes and continue with the remaining packet if it so desires. Additionally it MAY look at the Header Options and decide if it wants to pass/drop the packet. 5. Security Considerations This document introduces no new security threat that already exists. 6. IANA Considerations This document requires no action from IANA. 7. References 7.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., et. al, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. 7.2. Informative References [RFC3775] Johnson, D., "Mobility Support in IPv6", RFC 3775, June 2004. [karp-non-ipsec-ospfv3-auth] Bhatia, M.," Non IPSec Authentication mechanism for OSPFv3", Work in Progress Author's Addresses Bhatia, Manav Expires March 2011 [Page 5] Internet-Draft September 2010 Manav Bhatia Alcatel-Lucent Bangalore India Phone: Email: manav.bhatia@alcatel-lucent.com Bhatia, Manav Expires March 2011 [Page 6]