Internet Engineering Task Force                                W. George
Internet-Draft                                                 L. Howard
Intended status: Best Current Practice                 Time Warner Cable
Expires: July 10, 2014                                   January 6, 2014

                     IPv6 Support Within IETF work


   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 further recommends that IETF revisit
   and update the previous attempts to review existing standards for
   IPv6 compliance.  It makes this recommendation in order 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

   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 July 10, 2014.

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
   ( 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 & Howard           Expires July 10, 2014                 [Page 1]

Internet-Draft                IPv6-support                  January 2014

   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

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 . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  IETF Actions  . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Requirements and Recommendations  . . . . . . . . . . . . . .   6
   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   7
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

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, and discusses the need for gap analyses on existing work.

   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.  Additionally, although
   reviews in RFC's 3789 [RFC3789] through RFC3796 ensured that IETF

George & Howard           Expires July 10, 2014                 [Page 2]

Internet-Draft                IPv6-support                  January 2014

   standards then in use could support IPv6, no IETF-wide effort has
   been undertaken to ensure that the issues identified in those drafts
   are all addressed, nor to ensure that standards written after RFC3100
   (where the previous review efforts stopped) function properly on
   IPv6-only networks.

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   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 make
   sure that its standards can be deployed by even the first operators
   to turn off IPv4.  Problems (and solutions) should 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 enabled 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.  The key at
   this point is to ensure that existing standards and protocols have
   been actively reviewed, and any parity gaps either identified so that
   they can be fixed, or documented as unnecessary to address because it
   is unused or superseded by other features.

George & Howard           Expires July 10, 2014                 [Page 3]

Internet-Draft                IPv6-support                  January 2014

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:

   "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.  IETF Actions

   In addition to a requirement for IPv6 support in the following
   section, this document recommends two major actions:

   First, the IETF must review RFCs 3789-3796 to ensure that any gaps in
   specifications identified in these documents and still in active use
   have been updated as necessary to enable operation in IPv6-only
   environments (or if no longer in use, are declared historic).  A
   document updating each of the below area-specific RFCs to identify
   which gaps have been addressed and which ones are either still
   outstanding or are now irrelevant may be an appropriate way to track
   this activity.

   o  Internet Area [RFC3790]

   o  Routing Area [RFC3791]

   o  Security Area [RFC3792]

   o  Sub-IP Area [RFC3793]

George & Howard           Expires July 10, 2014                 [Page 4]

Internet-Draft                IPv6-support                  January 2014

   o  Transport Area [RFC3794]

   o  Applications Area [RFC3795]

   o  Operations and Management Area [RFC3796]

   Second, the IETF must review documents written after the existing
   review stopped (according to RFC 3790, this review stopped with
   approximately RFC 3100) to identify specifications where IPv6-only
   operation is not possible, and update them as necessary and
   appropriate, or document why an identified gap is not an issue i.e.
   not necessary for functional parity with IPv4.

   This represents a significant amount of work in addition to IETF's
   existing workload, and there are basically two options for how to
   accomplish this significant document review.  If existing IETF
   resources are to take on this work, one method would be for Area
   Directors to charter their existing Working Groups to undertake this
   review for relevant work, and charter their Directorates or other
   volunteers to review work that is not within the charter of any
   active Working Group.  Another method would be to charter one (new or
   existing) Working Group or directorate to oversee this activity, with
   the assumption that the WG or directorate will pull in expertise from
   other areas and WGs as needed.  The alternative is to use a similar
   model to the previous analysis in RFCs 3789-3796, in which ISOC
   funded dedicated resources whose primary duty was to complete this
   document audit.

   RFC3789 [RFC3789] section 2 provides some guidance on methodology
   that can serve as a useful starting point for this effort.

      "To perform this study, each class of IETF standards are
      investigated in order of maturity: Full, Draft, and Proposed, as
      well as Experimental.  Informational and BCP RFCs are not
      addressed.  RFCs that have been obsoleted by either newer versions
      or because they have transitioned through the standards process
      are not covered.  RFCs which have been classified as Historic are
      also not included."

   This document does not recommend excluding Informational and BCP RFCs
   as the previous effort did, due to changes in the way that these
   documents are used and their relative importance in the RFC Series.
   Instead, any documents that are still active (i.e. not declared
   historic or obsolete) and the product of IETF consensus (i.e. not a
   product of the ISE Series) should be included.  In addition, the
   reviews undertaken by RFC 3789-96 were looking for "IPv4 dependency"
   or "usage of IPv4 addresses in standards".  This document recommends
   a slightly more specific set of criteria for review: review should

George & Howard           Expires July 10, 2014                 [Page 5]

Internet-Draft                IPv6-support                  January 2014

   include consideration of whether the specification can operate in an
   environment without IPv4.  Reviews should include guidance on the use
   of 32-bit identifiers that are commonly populated by IPv4 addresses.
   Reviews should include consideration of protocols on which
   specifications depend or interact, to identify indirect dependencies
   on IPv4.  Finally, reviews should consider how to migrate from an
   IPv4 environment to an IPv6 environment.

   By necessity, this sort of gap analysis work is already happening in
   several places, e.g. draft-ietf-sunset4-gapanalysis
   [I-D.ietf-sunset4-gapanalysis], draft-george-mpls-ipv6-only-gap
   [], and draft-klatsky-dispatch-ipv6
   -impact-ipv4 [I-D.klatsky-dispatch-ipv6-impact-ipv4].  These efforts
   are limited in scope, but may serve as a model for the larger effort

4.  Requirements and Recommendations

   While the primary goal of this effort is to ensure that existing IETF
   work has been properly evaluated and updated for IPv6-only support,
   ongoing focus is required for future work, whether via 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.

      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

George & Howard           Expires July 10, 2014                 [Page 6]

Internet-Draft                IPv6-support                  January 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.

5.  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.

6.  IANA Considerations

   This memo includes no request to IANA.

7.  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.

8.  References

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3789]  Nesser, P. and A. Bergstrom, "Introduction to the Survey
              of IPv4 Addresses in Currently Deployed IETF Standards
              Track and Experimental Documents", RFC 3789, June 2004.

   [RFC3790]  Mickles, C. and P. Nesser, "Survey of IPv4 Addresses in
              Currently Deployed IETF Internet Area Standards Track and
              Experimental Documents", RFC 3790, June 2004.

   [RFC3791]  Olvera, C. and P. Nesser, "Survey of IPv4 Addresses in
              Currently Deployed IETF Routing Area Standards Track and
              Experimental Documents", RFC 3791, June 2004.

George & Howard           Expires July 10, 2014                 [Page 7]

Internet-Draft                IPv6-support                  January 2014

   [RFC3792]  Nesser, P. and A. Bergstrom, "Survey of IPv4 Addresses in
              Currently Deployed IETF Security Area Standards Track and
              Experimental Documents", RFC 3792, June 2004.

   [RFC3793]  Nesser, P. and A. Bergstrom, "Survey of IPv4 Addresses in
              Currently Deployed IETF Sub-IP Area Standards Track and
              Experimental Documents", RFC 3793, June 2004.

   [RFC3794]  Nesser, P. and A. Bergstrom, "Survey of IPv4 Addresses in
              Currently Deployed IETF Transport Area Standards Track and
              Experimental Documents", RFC 3794, June 2004.

   [RFC3795]  Sofia, R. and P. Nesser, "Survey of IPv4 Addresses in
              Currently Deployed IETF Application Area Standards Track
              and Experimental Documents", RFC 3795, June 2004.

   [RFC3796]  Nesser, P. and A. Bergstrom, "Survey of IPv4 Addresses in
              Currently Deployed IETF Operations & Management Area
              Standards Track and Experimental Documents", RFC 3796,
              June 2004.

8.2.  Informative References

              George, W., Pignataro, C., Asati, R., Raza, K., Bonica,
              R., Papneja, R., Dhody, D., and V. Manral, "Gap Analysis
              for Operating IPv6-only MPLS Networks", draft-george-mpls-
              ipv6-only-gap-02 (work in progress), October 2013.

              Dionne, J., Perreault, S., Tsou, T., and C. Zhou, "Gap
              Analysis for IPv4 Sunset", draft-ietf-
              sunset4-gapanalysis-03 (work in progress), July 2013.

              Klatsky, C., Shekh-Yusef, R., Hutton, A., and G.
              Salgueiro, "Interoperability Impacts of IPv6 Interworking
              with Existing IPv4 SIP Implementations", draft-klatsky-
              dispatch-ipv6-impact-ipv4-02 (work in progress), October

   [RFC6540]  George, W., Donley, C., Liljenstolpe, C., and L. Howard,
              "IPv6 Support Required for All IP-Capable Nodes", BCP 177,
              RFC 6540, April 2012.

George & Howard           Expires July 10, 2014                 [Page 8]

Internet-Draft                IPv6-support                  January 2014

Authors' Addresses

   Wesley George
   Time Warner Cable
   13820 Sunrise Valley Drive
   Herndon, VA  20171

   Phone: +1 703-561-2540

   Lee Howard
   Time Warner Cable
   13820 Sunrise Valley Drive
   Herndon, VA  20171

   Phone: +1-703-345-3513

George & Howard           Expires July 10, 2014                 [Page 9]