draft-ietf-6man-exthdr-03.txt   draft-ietf-6man-exthdr-04.txt 
6man Working Group S. Krishnan 6man Working Group S. Krishnan
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Standards Track j h. woodyatt Intended status: Standards Track j h. woodyatt
Expires: December 29, 2011 Apple Expires: January 12, 2012 Apple
E. Kline E. Kline
Google Google
J. Hoagland J. Hoagland
Symantec Symantec
M. Bhatia M. Bhatia
Alcatel-Lucent Alcatel-Lucent
June 27, 2011 July 11, 2011
An uniform format for IPv6 extension headers An uniform format for IPv6 extension headers
draft-ietf-6man-exthdr-03 draft-ietf-6man-exthdr-04
Abstract Abstract
In IPv6, optional internet-layer information is encoded in separate In IPv6, optional internet-layer information is encoded in separate
headers that may be placed between the IPv6 header and the transport headers that may be placed between the IPv6 header and the transport
layer header. There are a small number of such extension headers layer header. There are a small number of such extension headers
currently defined. This document defines a format for defining new currently defined. This document describes the issues that can arise
IPv6 extension headers. when defining new extension headers and discusses the alternative
extension mechanisms in IPv6. It also provides a format for defining
new IPv6 extension headers that would allow implementations to
process past unknown extension headers.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 29, 2011. This Internet-Draft will expire on January 12, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 18 skipping to change at page 2, line 21
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . . 3
3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Proposed IPv6 Extension Header format . . . . . . . . . . . . . 5 4. Proposed IPv6 Extension Header format . . . . . . . . . . . . . 5
5. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 6 5. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 5
6. Future work . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Future work . . . . . . . . . . . . . . . . . . . . . . . . . . 5
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
8. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
10. Normative References . . . . . . . . . . . . . . . . . . . . . 7 10. Normative References . . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction 1. Introduction
The base IPv6 standard [RFC2460] defines extension headers as an The base IPv6 standard [RFC2460] defines extension headers as an
expansion mechanism to carry optional internet layer information. expansion mechanism to carry optional internet layer information.
Extension headers, with the exception of the hop-by-hop options Extension headers, with the exception of the hop-by-hop options
header, are not usually processed on intermediate nodes. However, header, are not usually processed on intermediate nodes. However,
some intermediate nodes such as firewalls, may need to look at the some intermediate nodes such as firewalls, may need to look at the
transport layer header fields in order to make a decision to allow or transport layer header fields in order to make a decision to allow or
deny the packet. If new extension headers are defined and the deny the packet. If new extension headers are defined and the
skipping to change at page 5, line 37 skipping to change at page 5, line 7
Mindful of the need for compatibility with existing IPv6 deployments, Mindful of the need for compatibility with existing IPv6 deployments,
new IPv6 extension headers MUST NOT be created or specified, unless new IPv6 extension headers MUST NOT be created or specified, unless
no existing IPv6 Extension Header can be used by specifying a new no existing IPv6 Extension Header can be used by specifying a new
option for that existing IPv6 Extension Header. Any proposal to option for that existing IPv6 Extension Header. Any proposal to
create or specify a new IPv6 Extension Header MUST include a detailed create or specify a new IPv6 Extension Header MUST include a detailed
technical explanation of why no existing IPv6 Extension Header can be technical explanation of why no existing IPv6 Extension Header can be
used in the Internet-Draft proposing the new IPv6 Extension Header. used in the Internet-Draft proposing the new IPv6 Extension Header.
4. Proposed IPv6 Extension Header format 4. Proposed IPv6 Extension Header format
This document proposes that all IPv6 extension headers be encoded in If any IPv6 Extension Headers are defined in future, keeping in mind
a consistent format so that it is possible for nodes to skip over the restrictions specified in Section 3 and also the restrictions
unknown extension headers and continue to further process the header specified in [RFC2460], they MUST use the consistent format defined
chain. in Figure 1. This enables future IPv6 implementations to skip over
unknown IPv6 Extension Headers and continue to further process the
IPv6 header chain.
0 1 2 3 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 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 | | | Next Header | Hdr Ext Len | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| | | |
. . . .
. Header Specific Data . . Header Specific Data .
. . . .
skipping to change at page 7, line 24 skipping to change at page 6, line 29
such as firewalls, skipping over unknown headers might end up such as firewalls, skipping over unknown headers might end up
allowing the setup of a covert channel from the outside of the allowing the setup of a covert channel from the outside of the
firewall to the inside using the data field(s) of the unknown firewall to the inside using the data field(s) of the unknown
extension headers. extension headers.
9. Acknowledgements 9. Acknowledgements
The authors would like to thank Albert Manfredi, Bob Hinden, Brian The authors would like to thank Albert Manfredi, Bob Hinden, Brian
Carpenter, Erik Nordmark, Hemant Singh, Lars Westberg, Markku Savela, Carpenter, Erik Nordmark, Hemant Singh, Lars Westberg, Markku Savela,
Tatuya Jinmei, Thomas Narten, Vishwas Manral, Alfred Hoenes, Joel Tatuya Jinmei, Thomas Narten, Vishwas Manral, Alfred Hoenes, Joel
Halpern and Ran Atkinson for their reviews and suggestions that made Halpern, Ran Atkinson and Steven Blake for their reviews and
this document better. suggestions that made this document better.
10. Normative References 10. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998.
Authors' Addresses Authors' Addresses
 End of changes. 8 change blocks. 
19 lines changed or deleted 24 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/