Internet Engineering Task Force W. George
Internet-Draft Time Warner Cable
Intended status: BCP C. Donley
Expires: December 31, 2011 Cablelabs
L. Howard
Time Warner Cable
June 29, 2011
IPv6 Support Within IETF protocol work
draft-george-ipv6-support-00
Abstract
Given the global lack of available IPv4 space, and limitations in
IPv4 extension and transition technologies, this document recommends
that IETF formally require protocol work to be IP version agnostic or
to explicitly include support for IPv6, with some exceptions.
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 December 31, 2011.
Copyright Notice
Copyright (c) 2011 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
George, et al. Expires December 31, 2011 [Page 1]
Internet-Draft IPv6-support June 2011
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements and Recommendation . . . . . . . . . . . . . . . . 4
3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6.1. Normative References . . . . . . . . . . . . . . . . . . . 6
6.2. Informative References . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
George, et al. Expires December 31, 2011 [Page 2]
Internet-Draft IPv6-support June 2011
1. Introduction
[I-D.ietf-intarea-ipv6-required] gives guidance to implementers that
IP-capable devices need to support IPv6, because global IPv4
exhaustion creates many circumstances where the use of IPv6 will no
longer be optional.
In the above draft, IETF is making the recommendation that IP-capable
devices need to support IPv6. Therefore, it is imperative that the
protocols that result from IETF work enable implementers to follow
that recommendation. This document provides explicit recommendations
and guidance as to how IETF itself should handle future work to
ensure that it can meet the requirements of
[I-D.ietf-intarea-ipv6-required], especially "SHOULD NOT require IPv4
for proper and complete operation."
1.1. Requirements Language
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].
1.2. Terminology
There are several terms used by this document and other standards
work which have commonly-accepted meanings, but are not necessarily
defined within IETF's current body of documents. Because this draft
is recommending that exceptions are made for certain areas of IETF
work, the authors felt it necessary to formally define these terms
for improved clarity.
o IPv4-IPv6 Transition - network technologies that offer IPv6
support over an IPv4 network (e.g. 6in4 [RFC4213], ISATAP
[RFC5214], 6RD [RFC5969], etc.)
o IPv4-IPv6 Coexistence - network technologies (e.g. DSLite
[I-D.ietf-softwire-dual-stack-lite], CGN [RFC6264], etc.) that
maintain support for legacy IPv4 devices and applications after
IPv4 exhaustion.
o IPv4-IPv6 Interworking - network technologies (e.g. NAT64
[RFC6146]) that allow IPv6-only devices to communicate with IPv4-
only devices
o IP version agnostic - the idea that the implementation is at a
higher layer than IP (layer 3) and therefore the use of IPv4 or
IPv6 at the Network Layer should be transparent to the upper-layer
implementation or protocol.
George, et al. Expires December 31, 2011 [Page 3]
Internet-Draft IPv6-support June 2011
o IPv4-IPv6 Feature parity - the absence of gaps where functionality
exists in IPv4 but has no equivalent in IPv6. Note that this does
not mean a direct 1:1 relationship where every feature that exists
in IPv4 will exist in IPv6. This is because IPv6 eliminates the
need for some features that exist in IPv4, IPv4 supports some
features that are no longer in use, and some existing IPv4
features are integrated into other parts of IPv6. In addition, as
new features and implementations take advantage of the differences
between IPv6 and IPv4, it is expected that IPv6 will surpass IPv4
and feature parity will begin to swing in the other direction as
the decision is made not to implement certain features and
protocols in IPv4.
Additional terminology can be found in
[I-D.arkko-ipv6-transition-guidelines]
[Authors' note: These are strawman definitions, probably need to be
wordsmithed further. Also, we were unable to find an existing draft
or RFC which defines these terms. If one exists, we are happy to
reference that instead.]
It is important to note that the protocols listed in this section are
merely examples, and this is not intended to be an exhaustive list of
the applications of each term. Ultimately the decision as to whether
an IETF WG, protocol, or draft should remain focused primarily or
exclusively on IPv4 remains with the appropriate ADs.
2. Requirements and Recommendation
Within the IETF, further development on protocols and applications
that are IPv4 only SHOULD cease, except to address vital
operational or security issues, to maintain support for existing
IPv4-only applications during the transition to IPv6, or to update
the protocol or application to support IPv6.
This will enable IETF WGs to concentrate on work that is either IP
version agnostic, explicitly supports both IPv4 and IPv6, or in
some cases, targets only IPv6. The goal is to ensure IPv4-IPv6
feature parity in most cases, and enable networks to operate
seamlessly in any combination of IPv4-only, dual-stack, or IPv6-
only as their needs dictate.
New features and protocols SHOULD NOT be introduced for use as
IPv4-only unless they are specifically in support of IPv4-IPv6
transition, IPv4-IPv6 coexistence or IPv4-IPv6 interworking.
George, et al. Expires December 31, 2011 [Page 4]
Internet-Draft IPv6-support June 2011
A comprehensive list of needed parity items and enhancements for
IPv6 is outside the scope of this document, but this document
recommends that the charters and work items of currently active
IETF Working Groups (WGs) be evaluated to ensure that they are
supporting the goals of IPv4-IPv6 feature parity and elimination
of any remaining places in IETF standards and protocols where IPv4
is required for complete and proper function.
Put another way:
IETF SHOULD continue to update IPv4-only protocols and features
for vital operational or security issues.
IETF work SHOULD continue on IPv4-IPv6 transition and IPv4-IPv6
coexistence technologies as necessary.
IETF work that is not related to the above exceptions MUST be IP
version agnostic or MUST explicitly support IPv6.
IETF work SHOULD continue to update IPv4-only protocols and
applications to support IPv6 as necessary and appropriate.
IETF work MAY support IPv6-only applications and protocols,
especially in cases where supporting the protocol or feature in
IPv4 would be difficult or impossible.
3. Acknowledgements
Thanks to the following people for their comments: Jari Arkko, Scott
Brim, Margaret Wasserman
4. IANA Considerations
This memo includes no request to IANA.
5. Security Considerations
This document generates no new security considerations because it is
not defining a new protocol. However, it is important to note that
the recommendations above to stop work on IPv4-only protocols and
applications include an exception for fixes to critical security
issues. The definition of critical in this context will be left to
the appropriate ADs, but while IPv4 is still in wide use, it is
expected that these exceptions will occur from time to time.
George, et al. Expires December 31, 2011 [Page 5]
Internet-Draft IPv6-support June 2011
6. References
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
6.2. Informative References
[I-D.arkko-ipv6-transition-guidelines]
Arkko, J. and F. Baker, "Guidelines for Using IPv6
Transition Mechanisms during IPv6 Deployment",
draft-arkko-ipv6-transition-guidelines-14 (work in
progress), December 2010.
[I-D.ietf-intarea-ipv6-required]
George, W., Donley, C., Liljenstolpe, C., and L. Howard,
"IPv6 Support Required for all IP-capable nodes",
draft-ietf-intarea-ipv6-required-00 (work in progress),
June 2011.
[I-D.ietf-softwire-dual-stack-lite]
Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
Stack Lite Broadband Deployments Following IPv4
Exhaustion", draft-ietf-softwire-dual-stack-lite-11 (work
in progress), May 2011.
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site
Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214,
March 2008.
[RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4
Infrastructures (6rd) -- Protocol Specification",
RFC 5969, August 2010.
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers", RFC 6146, April 2011.
[RFC6264] Jiang, S., Guo, D., and B. Carpenter, "An Incremental
Carrier-Grade NAT (CGN) for IPv6 Transition", RFC 6264,
June 2011.
George, et al. Expires December 31, 2011 [Page 6]
Internet-Draft IPv6-support June 2011
Authors' Addresses
Wesley George
Time Warner Cable
13820 Sunrise Valley Drive
Herndon, VA 20171
US
Phone: +1 703-561-2540
Email: wesley.george@twcable.com
Chris Donley
Cablelabs
858 Coal Creek Circle
Louisville, CO 80027
US
Phone: +1-303-661-9100
Email: C.Donley@cablelabs.com
Lee Howard
Time Warner Cable
13820 Sunrise Valley Drive
Herndon, VA 20171
US
Phone: +1-703-345-3513
Email: lee.howard@twcable.com
George, et al. Expires December 31, 2011 [Page 7]