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]