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]