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

Versions: 00 01 02 03

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]


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