One document matched: draft-gont-6man-rfc6564bis-00.txt
IPv6 maintenance Working Group (6man) F. Gont
Internet-Draft SI6 Networks / UTN-FRH
Obsoletes: 6564 (if approved) W. Liu
Intended status: Standards Track Huawei Technologies
Expires: October 10, 2014 S. Krishnan
Ericsson
H. Pfeifer
Rohde & Schwarz
April 8, 2014
IPv6 Universal Extension Header
draft-gont-6man-rfc6564bis-00
Abstract
In IPv6, optional internet-layer information is encoded in separate
headers that may be placed between the IPv6 header and the transport-
layer header. There are a small number of such extension headers
currently defined. This document describes the issues that can arise
when defining new extension headers and specifies a new IPv6
Extension Header - the Universal Extension Header - that overcomes
the aforementioned problem, while enabling the extensibility of IPv6.
Finally, this document formally obsoletes RFC 6564.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on October 10, 2014.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
Gont, et al. Expires October 10, 2014 [Page 1]
Internet-Draft Universal Extension Header April 2014
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. A Problem with RFC 6564 . . . . . . . . . . . . . . . . . . . 3
4. Implications . . . . . . . . . . . . . . . . . . . . . . . . 3
5. UEH Specification . . . . . . . . . . . . . . . . . . . . . . 4
6. Operation of the UEH . . . . . . . . . . . . . . . . . . . . 5
7. Forbidding New IPv6 Extension Headers . . . . . . . . . . . . 5
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
9. Security Considerations . . . . . . . . . . . . . . . . . . . 6
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 6
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
12.1. Normative References . . . . . . . . . . . . . . . . . . 6
12.2. Informative References . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
There has recently been a lot of work in the area of IPv6 Extension
Headers. Firstly, there has been research about the extent to which
IPv6 Extension Headers are dropped in the public Internet
[GONT-IEPG-Nov13] [GONT-IEPG-Mar14], and debate about the motivation
behind such policy [I-D.taylor-v6ops-fragdrop]. Secondly, there has
been a fair share of work to improve some technicalities of IPv6
Extension Headers [RFC7112] [RFC7045], in the hopes that they can be
reliably used in the public Internet.
A key challenge for IPv6 Extension Headers to be "deployable" in the
public Internet is that they should not impair any nodes's ability to
process the entire IPv6 header chain. One of the steps meant in that
direction has been the specification of a Uniform Format for IPv6
Extension Headers [RFC6564], which was meant to be employed by any
IPv6 Extension Headers that might be defined in the future, such that
middle-boxes can still process the entire IPv6 header chain if the
new extension headers employ the Uniform Format. However, a problem
Gont, et al. Expires October 10, 2014 [Page 2]
Internet-Draft Universal Extension Header April 2014
in the aforementioned specification prevents such uniform format from
being of use in practice.
Section 3 discusses the aforementioned flaw in the Uniform Format for
Extension Headers specified in [RFC6564]. Section 4 explicitly
describes the implications of the aforementioned flaw. Section 5
formally updates [RFC6564], specifying the new Universal Extension
Header (UEH). Section 6 explains how new IPv6 would be developed
with the UEH. Section 7 formally forbids the specification of new
IPv6 Extension Headers (with new Next Header values), and mandates
that any new IPv6 Extensions be encoded with the UEH specified in
this document.
2. Terminology
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].
3. A Problem with RFC 6564
A key problem with the Uniform Format for IPv6 Extension Headers
[RFC6564] lies in that both IPv6 Extension Headers and Transport
Protocols share the same namespace ("Next Header" registry/
namespace). Thus, given an "unknown Next Header value", it is
impossible to tell whether the aforementioned value refers to an IPv6
Extension Header that employs the aforementioned uniform format, or
an "unknown" upper-layer protocol (e.g. an "unknown" transport
protocol). That is, while [RFC6564] specifies the syntax for the
Uniform Format for IPv6 Extension Headers, but it does not provide a
mechanism for a node to identify whether the aforementioned format is
being employed in the first place.
4. Implications
The current impossibility to parse an IPv6 header chain that includes
unknown Next Header values results in concrete implications for the
extensibility of the IPv6 protocol, and the deployability of IPv6
extension headers. Namely,
o New IPv6 extension headers cannot be incrementally deployed.
o New transport protocols cannot be deployed.
Since there is no way for a node to process IPv6 extension headers
that employ unknown next header values, an IPv6 host that receives a
packet that employs a new IPv6 extension header will not be able to
parse the IPv6 header chain past that unknown extension header, and
Gont, et al. Expires October 10, 2014 [Page 3]
Internet-Draft Universal Extension Header April 2014
hence it will drop the aforementioned packet. In a similar way, a
middlebox that needs to process the transport-protocol header will be
faced with the dilemma of what to do with packets that employ unknown
Next Header values. Since they will not be able to parse the IPv6
header chain past the unknown Next Header, it is very likely that
they will drop such packets.
Unfortunately, since transport protocols share the same namespace as
IPv6 Extension Headers, new transport protocols will pose the same
challenge to middle-boxes, and hence they will be likely dropped in
the network.
We believe that the current situation has implications that are
generally overlooked, and that, whatever the outcome, it should be
the result of an explicit decision by our community, rather than
simply "omission".
5. UEH Specification
The entire Section 4 of [RFC6564] is hereby replaced as follows:
New IPv6 Extension Headers MUST NOT be specified. Any IPv6
extensions that would require a new IPv6 Extension Header MUST be
implemented with the Universal Extension Header specified in this
document. This minimizes breakage in intermediate nodes that examine
these extension headers.
This document specifies a new IPv6 Extension Header: Universal
Extension Header. This Extension Header is identified by the value
[TBD] of [IANA-IP-PROTO]. The syntax of the Universal Extension
Header is:
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 | Hdr Ext Len | Subtype | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
. .
. Subtype Specific Data .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:
Next Header
Gont, et al. Expires October 10, 2014 [Page 4]
Internet-Draft Universal Extension Header April 2014
8-bit selector. Identifies the type of header immediately
following the extension header. Uses the same values as the IPv4
Protocol field [IANA-IP-PROTO].
Hdr Ext Len
8-bit unsigned integer. Length of the extension header in 8-octet
units, not including the first 8 octets.
Subtype
8-bit unsigned integer. Specifies the subtype for this extension
header. It uses a new namespace managed by IANA [IANA-UEH].
Subtype Specific Data
Variable length. Fields specific to this extension header/
Subtype.
The Universal Extension Header specified in this document MAY appear
multiple times in the same IPv6 packet.
6. Operation of the UEH
This section discusses de operation of the Universal Extension
Header.
The goal of the UEH is to provide for a common syntax for all future
IPv6 extensions. Any future extension headers will be encoded in a
UEH, and will be identified by a specific UEH Subtype assigned by
IANA at the time the corresponding specification is published. The
UEH thus provides for the "common syntax" required to process
"unrecognized extensions", and the Subtype field identifies the
specific extension being encoded in the UEH. Any "future extension
headers" would actually be new Subtypes (assigned by IANA) of the
UEH.
As a result, in the event an unrecognized Next Header value is
encountered by a node, the node will be able to assume that such Next
Header value identifies an upper-layer protocol, rather than an
extension header.
7. Forbidding New IPv6 Extension Headers
Since the specification of any new IPv6 Extension Headers (i.e., with
new Next Header values) would hamper (among other things) the
incremental deployment of extensions and enforcement of simple ACLs,
new IPv6 Extension Headers MUST NOT be specified in any future
specifications. Any new IPv6 extensions MUST be specified by means
of the UEH specified in this document.
Gont, et al. Expires October 10, 2014 [Page 5]
Internet-Draft Universal Extension Header April 2014
8. IANA Considerations
IANA is requested to create a new registry to maintain the Universal
Extension Header Subtypes [IANA-UEH].
9. Security Considerations
Enabling nodes to parse an entire IPv6 header chain even in the
presence of unrecognized extensions allows for security mechanisms to
be implemented and deployed.
10. Acknowledgements
The authors would like to thank [TBD] for providing valuable input on
earlier versions of this document.
11. Contributors
C.M. Heard identified the problems related with the Uniform Format
for IPv6 Extension Headers specified in [RFC6564], and participated
in the brainstorming that led to this document.
12. References
12.1. Normative References
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC6564] Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and
M. Bhatia, "A Uniform Format for IPv6 Extension Headers",
RFC 6564, April 2012.
[RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing
of IPv6 Extension Headers", RFC 7045, December 2013.
12.2. Informative References
[RFC7112] Gont, F., Manral, V., and R. Bonica, "Implications of
Oversized IPv6 Header Chains", RFC 7112, January 2014.
Gont, et al. Expires October 10, 2014 [Page 6]
Internet-Draft Universal Extension Header April 2014
[I-D.taylor-v6ops-fragdrop]
Jaeggli, J., Colitti, L., Kumari, W., Vyncke, E., Kaeo,
M., and T. Taylor, "Why Operators Filter Fragments and
What It Implies", draft-taylor-v6ops-fragdrop-02 (work in
progress), December 2013.
[GONT-IEPG-Nov13]
Gont, F., "Fragmentation and Extension Header Support in
the IPv6 Internet", IEPG 88, November 3, 2013. Vancouver,
BC, Canada, 2013, <http://www.iepg.org/2013-11-ietf88/
fgont-iepg-ietf88-ipv6-frag-and-eh.pdf>.
[GONT-IEPG-Mar14]
Gont, F. and T. Chown, "More results from measurements of
IPv6 Extension Header probing", IEPG 89, March 2, 2014.
London, U.K., 2014, <http://www.iepg.org/2014-03-02-ietf89
/fgont-iepg-ietf89-eh-update.pdf>.
[IANA-IP-PROTO]
Internet Assigned Numbers Authority, "Assigned Internet
Protocol Numbers", April 2011, <http://www.iana.org/
assignments/protocol-numbers/protocol-numbers.xhtml>.
[IANA-UEH]
Internet Assigned Numbers Authority, "Universal Extension
Header Subtypes", 2014.
Authors' Addresses
Fernando Gont
SI6 Networks / UTN-FRH
Evaristo Carriego 2644
Haedo, Provincia de Buenos Aires 1706
Argentina
Phone: +54 11 4650 8472
Email: fgont@si6networks.com
URI: http://www.si6networks.com
Will (Shucheng) Liu
Huawei Technologies
Bantian, Longgang District
Shenzhen 518129
P.R. China
Email: liushucheng@huawei.com
Gont, et al. Expires October 10, 2014 [Page 7]
Internet-Draft Universal Extension Header April 2014
Suresh Krishnan
Ericsson
8400 Decarie Blvd.
Town of Mount Royal, QC
Canada
Phone: +1 514 345 7900 x42871
Email: suresh.krishnan@ericsson.com
Hagen Paul Pfeifer
Rohde & Schwarz
Muehldorfstrasse 15
Munich 81671
Germany
Phone: +49 89 4129 15515
Email: hagen.pfeifer@rohde-schwarz.com
URI: http://www.rohde-schwarz.com/
Gont, et al. Expires October 10, 2014 [Page 8]
| PAFTECH AB 2003-2026 | 2026-04-23 11:09:31 |