Internet Engineering Task Force W. George
Internet-Draft Time Warner Cable
Intended status: BCP C. Donley
Expires: August 24, 2012 Cablelabs
L. Howard
Time Warner Cable
February 21, 2012
IPv6 Support Within IETF work
draft-george-ipv6-support-01
Abstract
This document recommends that IETF formally require its standards
work to be IP version agnostic or to explicitly include support for
IPv6, with some exceptions. It recommends that future IPv4 work be
limited to solving documented operational problems identified through
deployment experience.
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 August 24, 2012.
Copyright Notice
Copyright (c) 2012 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
George, et al. Expires August 24, 2012 [Page 1]
Internet-Draft IPv6-support February 2012
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3
2. Requirements and Recommendation . . . . . . . . . . . . . . . . 3
3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Normative References . . . . . . . . . . . . . . . . . . . 7
6.2. Informative References . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
George, et al. Expires August 24, 2012 [Page 2]
Internet-Draft IPv6-support February 2012
1. Introduction
[I-D.ietf-intarea-ipv6-required] gives guidance to implementers that
in order to ensure interoperability and proper function after IPv4
exhaustion, 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
results of IETF efforts enable implementers to follow that
recommendation. This document provides explicit recommendations and
guidance as to how IETF itself should handle future work as it
relates to Internet Protocol versions.
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].
2. Requirements and Recommendation
When considering support for IPv4 vs IPv6 within IETF work, the
general goal is to provide tools that enable networks and
applications to operate seamlessly in any combination of IPv4-only,
dual-stack, or IPv6-only as their needs dictate.
As IPv6 deployment grows, IETF will naturally focus on features and
protocols that enhance and extend IPv6, along with continuing work on
items that are IP version agnostic. New features and protocols will
not typically be introduced for use as IPv4-only. However, as of
this document's writing, there is no documented requirement for all
IETF work to support IPv6, either implicitly by being network-layer
agnostic or explicitly by having an IPv6-specific implementation.
Due to the existing operational base of IPv4, it is not realistic to
completely bar further work on IPv4 within the IETF at this time, nor
to formally declare it historic. This draft is viewed as a first
step in IPv4's eventual phase-out, in that it limits IPv4-specific
activities within the IETF to a few key areas. Until the time when
IPv4 is no longer in wide use and/or declared historic, the IETF
needs to continue to update IPv4-only protocols and features for
vital operational or security issues. Similarly, IETF needs to
continue the work related to IPv4-to-IPv6 transition tools for
migrating more traffic to IPv6. As the transition to IPv6-capable
networks accelerates, it is also likely that some changes may be
George, et al. Expires August 24, 2012 [Page 3]
Internet-Draft IPv6-support February 2012
necessary in IPv4 protocols to facilitate decommissioning IPv4 in a
way that does not create unacceptable impact to applications or
users. These sorts of IPv4-focused activities should be allowed to
continue, especially if they are accompanied by real operational
experience documenting the problem to be solved.
Generally, the IETF should be focused on two goals as it relates to
IP version support:
1. Transition technologies that enable IPv6
2. Complete support for IPv6-only operation
It is helpful to clarify what the above statements mean. "Transition
technologies" is a fairly broad term that can be interpreted in a lot
of different ways. At its broadest, it includes providing IPv6
support over an IPv4 network and vice versa, methods to interwork
IPv4-only devices and IPv6-only devices, as well as technologies to
extend IPv4's life despite the lack of additional globally unique
addresses to provide to hosts and networks. This document makes the
distinction between those technologies which provide a path for an
IPv4-only network to become dual-stack or otherwise use native IPv6,
and those which primarily serve to extend the life of IPv4 while not
providing a path to native IPv6 support on the network in question.
The IETF needs to be focusing their work on transition mechanisms
that provide progress toward native IPv6, are simple, stateless, and
use mechanisms which preserve end-to-end connectivity as much as
possible.
While the eventual end state may be networks and end points that are
IPv6-only, the timeframe for that to become a reality is likely to be
different within each network. This means that there are multiple
legitimate use cases for continued support for IPv4, including
methods to translate between IPv4-only hosts and IPv6-only hosts, as
well as methods for IPv4 address sharing in order to reduce the
impact of IPv4 exhaustion on implementations that still use IPv4.
The IETF has provided several soutions that have implementations to
address the need to keep business running and users happy during this
transition, including Dual Stack Lite RFC 6333 [RFC6333], NAT64 RFC
6146 [RFC6146], as well as Carrier Grade NAT
([I-D.ietf-behave-lsn-requirements] and RFC 6264 [RFC6264]). As the
above documents complete the IETF document lifecycle and become RFCs,
and the BEHAVE WG closes after completion of its charter, this should
comprise a body of solutions to meet the needs of the majority of
IPv4's continued use cases such that work on additional protocols to
extend the life of IPv4 no longer needs to be an area of focus for
the IETF.
George, et al. Expires August 24, 2012 [Page 4]
Internet-Draft IPv6-support February 2012
[**authors' note, remove before publication**]
This document is not intended to be yet another survey of available
transition mechanisms, so the list above does not have to be
exhaustive. The intent was to cite the most likely candidates for
wide deployment as evidence that there exists a consensus solution
for each major case. There are a number of other drafts that could
be included in the above list of solutions, but as draft documents,
they have not yet found consensus. For example, A+P is an
Experimental RFC (6346), and its derivative works such as MAP
(draft-mdt-softwire-mapping-address-and-port) and potentially 4rd-
{E,T,U}, dIVI-PD, stateless 4over6, etc. are current internet-draft
documents. Under the structure proposed in this document, a working
group would need to find consensus on a problem statement, defining a
real operational problem that the proposed solution would solve,
before any proposed solution could be adopted as a WG item.
[end author's note]
It is not possible to document completely which technologies and
drafts are and are not acceptable, so this document is intended to be
a guideline for working groups and IESG members when evaluating new
and existing work, rather than being an exhaustive list. There are
corner cases and use cases for which the existing solutions may not
be a perfect fit, as well as unsolved theoretical problems, but
standardizing solutions for every possible permutation moves into the
realm of diminishing returns, and solutions applicable only to one or
two networks are best pursued between the operator and their vendors.
Thus, further work on IPv4-extension protocols such as those
mentioned MUST be triggered by a draft documenting actual operational
experiences, focusing on problems encountered in deployment that the
IETF needs to solve through protocol changes. This will ensure that
IETF is focusing its energies on solving real operational problems
that exist in IPv4 and transition technologies, rather than
interesting theoretical problems, corner cases or new features.
To put this set of guidelines succinctly:
IETF SHOULD continue to update IPv4-only protocols and features to
address vital operational or security issues.
IETF work SHOULD update existing IPv4 to IPv6 transition and
interworking technologies as necessary to address operational
problems encountered during the implementation phase.
IETF work SHOULD continue to make updates to IPv4 protocols and
features to facilitate IPv4 decommissioning
George, et al. Expires August 24, 2012 [Page 5]
Internet-Draft IPv6-support February 2012
IETF work that is not related to the above exceptions MUST be IP
version agnostic (because it is implemented above the network
layer) or MUST explicitly support IPv6.
IETF SHOULD NOT initiate new IPv4 extension technology
development.
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.
IETF work SHOULD continue to update IPv4-only protocols and
applications to support IPv6 as necessary and appropriate.
This last item raises a question about where feature parity between
IPv4 and IPv6 fits into the discussion. In this context, feature
parity ensures that there are no 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 legacy 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 certain features
and protocols will not have specific support for IPv4. 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 a goal
to eliminate of any remaining places in IETF standards and protocols
where IPv4 is required for complete and proper function, and that
they do not focus on IPv4 extension technologies. This document does
not suggest a timeline where this must be completed, as it will
likely happen organically over a long period of time.
3. Acknowledgements
Thanks to the following people for their comments: Jari Arkko, Ralph
Droms, Scott Brim, Margaret Wasserman. Thanks also to Randy Bush,
Mark Townsley, and Dan Wing for their discussion in IntArea WG at
IETF 81 in Taipei, TW regarding transition technologies, IPv4 life
extension, and IPv6 support.
George, et al. Expires August 24, 2012 [Page 6]
Internet-Draft IPv6-support February 2012
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.
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.ietf-behave-lsn-requirements]
Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A.,
and H. Ashida, "Common requirements for Carrier Grade NATs
(CGNs)", draft-ietf-behave-lsn-requirements-05 (work in
progress), November 2011.
[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-02 (work in progress),
December 2011.
[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.
[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
Stack Lite Broadband Deployments Following IPv4
Exhaustion", RFC 6333, August 2011.
George, et al. Expires August 24, 2012 [Page 7]
Internet-Draft IPv6-support February 2012
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 August 24, 2012 [Page 8]