Internet Engineering Task Force W. George
Internet-Draft L. Howard
Intended status: Best Current Practice Time Warner Cable
Expires: April 3, 2015 September 30, 2014
IPv6 Support Within IETF work
draft-george-ipv6-support-03
Abstract
This document recommends that the IETF formally require its standards
work to be IP version agnostic or to explicitly include support for
IPv6, with some exceptions, to ensure that it is possible to operate
without dependencies on IPv4.
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 April 3, 2015.
Copyright Notice
Copyright (c) 2014 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
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
George & Howard Expires April 3, 2015 [Page 1]
Internet-Draft IPv6-support September 2014
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. IPv6-only operation . . . . . . . . . . . . . . . . . . . . . 3
2.1. Functional Parity with IPv4 . . . . . . . . . . . . . . . 3
2.2. IPv4 Sunset . . . . . . . . . . . . . . . . . . . . . . . 3
3. Requirements and Recommendations . . . . . . . . . . . . . . 4
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 5
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
7.1. Normative References . . . . . . . . . . . . . . . . . . 5
7.2. Informative References . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5
1. Introduction
[RFC6540] gives guidance to implementers that in order to ensure
interoperability and proper function after IPv4 exhaustion, IP-
capable devices need to support IPv6, and cannot be reliant on IPv4,
because global IPv4 exhaustion creates many circumstances where the
use of IPv6 will no longer be optional. Since this is an IETF Best
Current Practice recommendation, it is imperative that the results of
IETF efforts enable implementers to follow that recommendation. This
document provides recommendations and guidance as to how IETF itself
should handle future work as it relates to Internet Protocol
versions.
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. However, as the
IPv4 to IPv6 transition continues, it will become increasingly
difficult to ensure interoperability and backward compatibility with
IPv4-only networks and applications. 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 formal requirement for all IETF work to support
IPv6, either implicitly by being network-layer agnostic or explicitly
by having an IPv6-specific implementation.
George & Howard Expires April 3, 2015 [Page 2]
Internet-Draft IPv6-support September 2014
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. IPv6-only operation
At this document's writing, IPv6 has seen significant deployment.
Most of these deployments are dual-stack, with IPv4 and IPv6
coexisting on the same networks. However, dual-stack is a waypoint
in the transition from IPv4 to IPv6. The eventual end state is
networks and end points that are IPv6-only. Some operators may take
a long time to turn off IPv4, if they ever do, but the IETF MUST
ensure that its standards can be deployed by even the first operators
to turn off IPv4. Problems (and solutions) need to be identified
before they are encountered by the earliest adopters.
2.1. Functional Parity with IPv4
In order for IPv6-only operation to be realistic, IPv6 MUST have at
least functional parity with IPv4. "Functional parity" means that
any function that IPv4 enables MUST also be enabled by IPv6. This
does not mean that every feature that exists in IPv4 will exist in
IPv6; different features may enable the same function. For instance,
IPv4 supports some features that are no longer in use. In some cases
it has not been practical to remove them in IPv4, or even to declare
them historic, but it is unnecessary to carry them forward into IPv6.
IPv6 also eliminates the need for some features that exist in IPv4;
no effort to create unneeded features is required. Functional parity
does not mean that all functions in IPv6 must also be possible in
IPv4. Indeed, with IPv6 becoming the predominant protocol, new
functionality should be developed in IPv6, and IETF effort SHOULD NOT
be spent retrofitting features into the legacy protocol.
2.2. IPv4 Sunset
Somewhat distinct from identifying the needed features for IPv6-only
functional parity is the effort to identify what is necessary to
disable or sunset IPv4 in a given network. Since many of the
protocols in use today were designed to be fault-tolerant and very
robust, actually removing them from a network once they are no longer
needed is sometimes complex. Many implementations may not even have
"off switches" because the assumption was that they would never be
switched off in a normal network implementation. The Sunset4 Working
Group was chartered to address these issues:
George & Howard Expires April 3, 2015 [Page 3]
Internet-Draft IPv6-support September 2014
"The Working Group will point out specific areas of concern, provide
recommendations, and standardize protocols that facilitate the
graceful "sunsetting" of the IPv4 Internet in areas where IPv6 has
been deployed. This includes the act of shutting down IPv4 itself,
as well as the ability of IPv6-only portions of the Internet to
continue to connect with portions of the Internet that remain
IPv4-only. ... Disabling IPv4 in applications, hosts, and networks
is new territory for much of the Internet today, and it is expected
that problems will be uncovered including those related to basic IPv4
functionality, interoperability, as well as potential security
concerns. The working group will report on common issues, provide
recommendations, and, when necessary, protocol extensions in order to
facilitate disabling IPv4 in networks where IPv6 has been deployed."
3. Requirements and Recommendations
Ongoing focus is required to ensure that future IETF work is capable
of IPv6-only operation. This attention may take the form of IESG
evaluation, individual document reviews, or future WG charters. 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. 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, the IETF needs to
complete 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
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, in support of
security, transition, and decommissioning, should continue,
accompanied by problem statements based on operational experience.
Generally the focus should move away from IPv4-only work.
The IESG SHOULD review working group charters to ensure that work
will be capable of operating without IPv4, except in cases of IPv4
security, transition, and decommissioning work.
IETF SHOULD make updates to IPv4 protocols and features to
facilitate IPv4 decommissioning
IETF work SHOULD explicitly support IPv6 or SHOULD be IP version
agnostic (because it is implemented above the network layer),
except IPv4-specific transition or address-sharing technologies.
IETF SHOULD NOT initiate new IPv4 extension technology
development.
George & Howard Expires April 3, 2015 [Page 4]
Internet-Draft IPv6-support September 2014
IETF work SHOULD function completely on IPv6-only nodes and
networks, unless consensus exists that it is unnecessary to use a
given feature or protocol on IPv6-only networks.
IETF SHOULD identify and update IPv4-only protocols and
applications to support IPv6 unless consensus exists that it is
unnecessary for a given feature or protocol.
4. Acknowledgements
Thanks to the following people for their comments: Jari Arkko, Ralph
Droms, Scott Brim, Margaret Wasserman, Brian Haberman. 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.
5. IANA Considerations
This memo includes no request to IANA.
6. Security Considerations
This document generates no new security considerations because it is
not defining a new protocol. As existing work is analyzed for its
ability to operate properly on IPv6-only networks, new security
issues may be identified.
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
7.2. Informative References
[RFC6540] George, W., Donley, C., Liljenstolpe, C., and L. Howard,
"IPv6 Support Required for All IP-Capable Nodes", BCP 177,
RFC 6540, April 2012.
Authors' Addresses
George & Howard Expires April 3, 2015 [Page 5]
Internet-Draft IPv6-support September 2014
Wesley George
Time Warner Cable
13820 Sunrise Valley Drive
Herndon, VA 20171
US
Phone: +1 703-561-2540
Email: wesley.george@twcable.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 & Howard Expires April 3, 2015 [Page 6]