[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03

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


   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",
   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

   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

      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

              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.

              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

   Phone: +1 703-561-2540
   Email: wesley.george@twcable.com

   Chris Donley
   858 Coal Creek Circle
   Louisville, CO  80027

   Phone: +1-303-661-9100
   Email: C.Donley@cablelabs.com

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

   Phone: +1-703-345-3513
   Email: lee.howard@twcable.com

George, et al.           Expires August 24, 2012                [Page 8]

Html markup produced by rfcmarkup 1.121, available from https://tools.ietf.org/tools/rfcmarkup/