draft-ietf-6man-ext-transmit-01.txt   draft-ietf-6man-ext-transmit-02.txt 
6man B. E. Carpenter 6man B. Carpenter
Internet-Draft Univ. of Auckland Internet-Draft Univ. of Auckland
Updates: 2460, 2780 (if approved) S. Jiang Updates: 2460, 2780 (if approved) S. Jiang
Intended status: Standards Track Huawei Technologies Co., Ltd Intended status: Standards Track Huawei Technologies Co., Ltd
Expires: November 30, 2013 May 29, 2013 Expires: February 07, 2014 August 06, 2013
Transmission of IPv6 Extension Headers Transmission of IPv6 Extension Headers
draft-ietf-6man-ext-transmit-01 draft-ietf-6man-ext-transmit-02
Abstract Abstract
Various IPv6 extension headers have been standardised since the IPv6 Various IPv6 extension headers have been standardised since the IPv6
standard was first published. This document updates RFC 2460 to standard was first published. This document updates RFC 2460 to
clarify how intermediate nodes should deal with such extension clarify how intermediate nodes should deal with such extension
headers and with any that are defined in future. It also specifies headers and with any that are defined in future. It also specifies
how extension headers should be registered by IANA, with a how extension headers should be registered by IANA, with a
corresponding minor update to RFC 2780. corresponding minor update to RFC 2780.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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 November 30, 2013. This Internet-Draft will expire on February 07, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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 19 skipping to change at page 2, line 19
1. Introduction and Problem Statement . . . . . . . . . . . . . 2 1. Introduction and Problem Statement . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Requirement to Transmit Extension Headers . . . . . . . . . . 4 2. Requirement to Transmit Extension Headers . . . . . . . . . . 4
2.1. All Extension Headers . . . . . . . . . . . . . . . . . . 4 2.1. All Extension Headers . . . . . . . . . . . . . . . . . . 4
2.2. Hop-by-Hop Options . . . . . . . . . . . . . . . . . . . 5 2.2. Hop-by-Hop Options . . . . . . . . . . . . . . . . . . . 5
3. Security Considerations . . . . . . . . . . . . . . . . . . . 5 3. Security Considerations . . . . . . . . . . . . . . . . . . . 5
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
6. Change log [RFC Editor: Please remove] . . . . . . . . . . . 7 6. Change log [RFC Editor: Please remove] . . . . . . . . . . . 7
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Normative References . . . . . . . . . . . . . . . . . . 7 7.1. Normative References . . . . . . . . . . . . . . . . . . 8
7.2. Informative References . . . . . . . . . . . . . . . . . 8 7.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction and Problem Statement 1. Introduction and Problem Statement
In IPv6, an extension header is any header that follows the initial In IPv6, an extension header is any header that follows the initial
40 bytes of the packet and precedes the upper layer header (which 40 bytes of the packet and precedes the upper layer header (which
might be a transport header, an ICMPv6 header, or a notional "No Next might be a transport header, an ICMPv6 header, or a notional "No Next
Header"). Header").
skipping to change at page 4, line 42 skipping to change at page 4, line 42
In the remainder of this document, the term "forwarding node" refers In the remainder of this document, the term "forwarding node" refers
to any router, firewall, load balancer, prefix translator, or any to any router, firewall, load balancer, prefix translator, or any
other device or middlebox that forwards IPv6 packets with or without other device or middlebox that forwards IPv6 packets with or without
examining the packet in any way. examining the packet in any way.
2. Requirement to Transmit Extension Headers 2. Requirement to Transmit Extension Headers
2.1. All Extension Headers 2.1. All Extension Headers
Any forwarding node along an IPv6 packet's path, which forwards it Any forwarding node along an IPv6 packet's path, which forwards the
for any reason, SHOULD do so regardless of any extension headers that packet for any reason, SHOULD do so regardless of any extension
are present, as required by RFC 2460. Exceptionally, if this node is headers that are present, as required by RFC 2460. Exceptionally, if
designed to examine extension headers for any reason, such as this node is designed to examine extension headers for any reason,
firewalling, it MUST recognise and deal appropriately with all such as firewalling, it MUST recognise and deal appropriately with
standard IPv6 extension header types. The list of standard extension all standardised IPv6 extension header types. The list of
header types is maintained by IANA (see Section 4) and implementors standardised extension header types is maintained by IANA (see
are advised to check this list regularly for updates. Section 4) and implementors are advised to check this list regularly
for updates.
RFC 2460 requires destination hosts to discard packets containing RFC 2460 requires destination hosts to discard packets containing
unrecognised extension headers. However, intermediate forwarding unrecognised extension headers. However, intermediate forwarding
nodes SHOULD NOT do this by default, since that might cause them to nodes SHOULD NOT do this by default, since that might cause them to
inadvertently discard traffic using a recently standardised extension inadvertently discard traffic using a recently standardised extension
header, not yet recognised by the intermediate node. The only header, not yet recognised by the intermediate node. The only
exceptions to this rule are discussed below. exceptions to this rule are discussed below.
As mentioned above, forwarding nodes that discard packets containing As mentioned above, forwarding nodes that discard packets containing
extension headers are known to cause connectivity failures and extension headers are known to cause connectivity failures and
deployment problems. Therefore, it is important that forwarding deployment problems. Therefore, it is important that forwarding
nodes that inspect IPv6 extension headers can parse all standard nodes that inspect IPv6 extension headers can parse all standard
headers and are able to behave according to the above requirements. headers and are able to behave according to the above requirements.
If a forwarding node discards a packet containing a standard IPv6 If a forwarding node discards a packet containing a standard IPv6
extension header, it MUST be the result of a configurable policy, and extension header, it MUST be the result of a configurable policy, and
not just the result of a failure to recognise such a header. This not just the result of a failure to recognise such a header. This
means that the discard policy for each standard type of extension means that the discard policy for each standardised type of extension
header MUST be individually configurable. The default configuration header MUST be individually configurable. The default configuration
SHOULD allow all standard extension headers. Forwarding nodes MUST SHOULD allow all standardised extension headers except the
be configurable to allow packets containing unrecognised extension experimental values 253 and 254 standardised by [RFC3692] and
headers, and such packets MAY be dropped by default. [RFC4727]. Forwarding nodes MUST be configurable to allow packets
containing unrecognised extension headers, but such packets MAY be
dropped by default.
The IPv6 Routing Header Types 0 and 1 have been deprecated and SHOULD The IPv6 Routing Header Types 0 and 1 have been deprecated and SHOULD
NOT be used. However, as specified in [RFC5095], this does not mean NOT be used. However, as specified in [RFC5095], this does not mean
that the IPv6 Routing Header can be unconditionally dropped by that the IPv6 Routing Header can be unconditionally dropped by
forwarding nodes. Packets containing undeprecated Routing Headers forwarding nodes. Packets containing standardised and undeprecated
SHOULD be forwarded by default. At the time of writing, these Routing Headers SHOULD be forwarded by default. At the time of
include Type 2 [RFC6275], Type 3 [RFC6554], and Types 253 and 254 writing, these include Type 2 [RFC6275], Type 3 [RFC6554], and the
[RFC4727]. Others may be defined in future. experimental Routing Header Types 253 and 254 [RFC4727]. Others may
be defined in future.
2.2. Hop-by-Hop Options 2.2. Hop-by-Hop Options
The IPv6 Hop-by-Hop Options header SHOULD be processed by The IPv6 Hop-by-Hop Options header SHOULD be processed by
intermediate forwarding nodes as described in [RFC2460]. However, it intermediate forwarding nodes as described in [RFC2460]. However, it
is to be expected that high performance routers will either ignore is to be expected that high performance routers will either ignore
it, or assign packets containing it to a slow processing path. it, or assign packets containing it to a slow processing path.
Designers planning to use a Hop-by-Hop option need to be aware of Designers planning to use a Hop-by-Hop option need to be aware of
this likely behaviour. this likely behaviour.
skipping to change at page 6, line 48 skipping to change at page 6, line 51
o 50, Encapsulating Security Payload, [RFC4303] o 50, Encapsulating Security Payload, [RFC4303]
o 51, Authentication, [RFC4302] o 51, Authentication, [RFC4302]
o 60, Destination Options, [RFC2460] o 60, Destination Options, [RFC2460]
o 135, MIPv6, [RFC6275] o 135, MIPv6, [RFC6275]
o 140, shim6, [RFC5533] o 140, shim6, [RFC5533]
o 253, experimental use, [RFC3692], [RFC4727]
o 254, experimental use, [RFC3692], [RFC4727]
This list excludes both type 59, No Next Header, [RFC2460], which is This list excludes both type 59, No Next Header, [RFC2460], which is
not an extension header as such, and type 139, HIP, [RFC5201], which not an extension header as such, and type 139, HIP, [RFC5201], which
is experimental. is experimental.
The references to the IPv6 Next Header field in [RFC2780] are to be The references to the IPv6 Next Header field in [RFC2780] are to be
interpreted as also applying to the IPv6 Extension Header field. interpreted as also applying to the IPv6 Extension Header field.
5. Acknowledgements 5. Acknowledgements
This document was triggered by mailing list discussions including This document was triggered by mailing list discussions including
John Leslie, Stefan Marksteiner and others. Valuable comments and John Leslie, Stefan Marksteiner and others. Valuable comments and
contributions were made by Dominique Barthel, Tim Chown, Lorenzo contributions were made by Dominique Barthel, Tim Chown, Lorenzo
Colitti, Fernando Gont, C. M. Heard, Bob Hinden, Ray Hunter, Suresh Colitti, Fernando Gont, C. M. Heard, Bob Hinden, Ray Hunter, Suresh
Krishnan, Marc Lampo, Michael Richardson, Dave Thaler, Joe Touch, and Krishnan, Marc Lampo, Michael Richardson, Dave Thaler, Joe Touch,
others. Bjoern Zeeb, and others.
Brian Carpenter was a visitor at the Computer Laboratory, Cambridge Brian Carpenter was a visitor at the Computer Laboratory, Cambridge
University during part of this work. University during part of this work.
This document was produced using the xml2rfc tool [RFC2629]. This document was produced using the xml2rfc tool [RFC2629].
6. Change log [RFC Editor: Please remove] 6. Change log [RFC Editor: Please remove]
draft-ietf-6man-ext-transmit-02: explicit mention of header types 253
and 254, editorial fixes, 2013-08-06.
draft-ietf-6man-ext-transmit-01: tuned use of normative language, draft-ietf-6man-ext-transmit-01: tuned use of normative language,
clarified that only standardised extensions are covered (hence clarified that only standardised extensions are covered (hence
excluding HIP), 2013-05-29. excluding HIP), 2013-05-29.
draft-ietf-6man-ext-transmit-00: first WG version, more draft-ietf-6man-ext-transmit-00: first WG version, more
clarifications, 2013-03-26. clarifications, 2013-03-26.
draft-carpenter-6man-ext-transmit-02: clarifications following WG draft-carpenter-6man-ext-transmit-02: clarifications following WG
comments, recalibrated firewall requirements, 2013-02-22. comments, recalibrated firewall requirements, 2013-02-22.
skipping to change at page 7, line 42 skipping to change at page 8, line 4
comments, recalibrated firewall requirements, 2013-02-22. comments, recalibrated firewall requirements, 2013-02-22.
draft-carpenter-6man-ext-transmit-01: feedback at IETF85: clarify draft-carpenter-6man-ext-transmit-01: feedback at IETF85: clarify
scope and impact on firewalls, discuss line-speed processing and lack scope and impact on firewalls, discuss line-speed processing and lack
of uniform TLV format, added references, restructured IANA of uniform TLV format, added references, restructured IANA
considerations, 2012-11-13. considerations, 2012-11-13.
draft-carpenter-6man-ext-transmit-00: original version, 2012-08-14. draft-carpenter-6man-ext-transmit-00: original version, 2012-08-14.
7. References 7. References
7.1. Normative References 7.1. 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.E. and R.M. Hinden, "Internet Protocol, Version [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
6 (IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998.
[RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For
Values In the Internet Protocol and Related Headers", BCP Values In the Internet Protocol and Related Headers", BCP
37, RFC 2780, March 2000. 37, RFC 2780, March 2000.
[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers
Considered Useful", BCP 82, RFC 3692, January 2004.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December
2005. 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
4303, December 2005. 4303, December 2005.
[RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, [RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4,
ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006. ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006.
[RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation
skipping to change at page 8, line 40 skipping to change at page 9, line 4
[RFC6564] Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and [RFC6564] Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and
M. Bhatia, "A Uniform Format for IPv6 Extension Headers", M. Bhatia, "A Uniform Format for IPv6 Extension Headers",
RFC 6564, April 2012. RFC 6564, April 2012.
7.2. Informative References 7.2. Informative References
[Heller] Heller, J., "Catch-22", Simon and Schuster , 1961. [Heller] Heller, J., "Catch-22", Simon and Schuster , 1961.
[I-D.ietf-6man-oversized-header-chain] [I-D.ietf-6man-oversized-header-chain]
Gont, F. and V. Manral, "Security and Interoperability Gont, F., Manral, V., and R. Bonica, "Implications of
Implications of Oversized IPv6 Header Chains", draft-ietf- Oversized IPv6 Header Chains", draft-ietf-6man-oversized-
6man-oversized-header-chain-02 (work in progress), header-chain-03 (work in progress), July 2013.
November 2012.
[I-D.taylor-v6ops-fragdrop] [I-D.taylor-v6ops-fragdrop]
Jaeggli, J., Colitti, L., Kumari, W., Vyncke, E., Kaeo, Jaeggli, J., Colitti, L., Kumari, W., Vyncke, E., Kaeo,
M., and T. Taylor, "Why Operators Filter Fragments and M., and T. Taylor, "Why Operators Filter Fragments and
What It Implies", draft-taylor-v6ops-fragdrop-00 (work in What It Implies", draft-taylor-v6ops-fragdrop-01 (work in
progress), October 2012. progress), June 2013.
[RFC2629] Rose, M.T., "Writing I-Ds and RFCs using XML", RFC 2629, [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999. June 1999.
[RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6
Routing Header for Source Routes with the Routing Protocol Routing Header for Source Routes with the Routing Protocol
for Low-Power and Lossy Networks (RPL)", RFC 6554, March for Low-Power and Lossy Networks (RPL)", RFC 6554, March
2012. 2012.
Authors' Addresses Authors' Addresses
Brian Carpenter Brian Carpenter
 End of changes. 18 change blocks. 
34 lines changed or deleted 45 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/