[Search] [pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02                                                      
Internet Engineering Task Force                                W. George
Internet-Draft                                                    Sprint
Updates: 1812, 1122, 4084                                      C. Donley
(if approved)                                                  Cablelabs
Intended status: Standards Track                         C. Liljenstolpe
Expires: September 5, 2011                                       Telstra
                                                               L. Howard
                                                       Time Warner Cable
                                                           March 4, 2011

             IPv6 Support Required for all IP-capable nodes


   Given the global lack of available IPv4 space, and limitations in
   IPv4 extension and transition technologies, this document deprecates
   the concept that an IP-capable node MAY support IPv4 _only_, and
   redefines an IP-capable node as one which supports either IPv6 _only_
   or IPv4/IPv6 dual-stack.  This document updates RFC1812, 1122 and
   4084 to reflect the change in requirements.

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 September 5, 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

George, et al.          Expires September 5, 2011               [Page 1]

Internet-Draft                IPv6-required                   March 2011

   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . . . 4
   2.  Requirements and Recommendation . . . . . . . . . . . . . . . . 4
   3.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 5
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 5
     6.1.  Normative References  . . . . . . . . . . . . . . . . . . . 5
     6.2.  Informative References  . . . . . . . . . . . . . . . . . . 6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 7

George, et al.          Expires September 5, 2011               [Page 2]

Internet-Draft                IPv6-required                   March 2011

1.  Introduction

   IP version 4 (IPv4) has served to connect public and private hosts
   all over the world for over 30 years.  However, due to the success of
   the Internet in finding new and innovative uses for IP networking,
   billions of hosts are now connected via the Internet and requiring
   unique addressing.  This demand has led to the exhaustion of the IANA
   [IANA-exhaust] global pool of unique IPv4 addresses.  While
   transition technologies and other means to extend the lifespan of
   IPv4 do exist, nearly all of them come with tradeoffs that prevent
   them from being optimal long-term solutions when compared with
   deployment of IP version 6 (IPv6) as a means to allow continued
   growth on the Internet.  See
   [I-D.ietf-intarea-shared-addressing-issues] and
   [I-D.donley-nat444-impacts] for some discussion on this topic.

   IPv6 was proposed in 1995 [RFC1883] as, among other things, a
   solution to the limitations on globally unique addressing that IPv4's
   32-bit addressing space represented, and has been under continuous
   refinement and deployment ever since.  [RFC2460].  The exhaustion of
   IPv4 and the continued growth of the internet worldwide has created
   the driver for widespread IPv6 deployment.

   However, the IPv6 deployment necessary to reduce reliance on IPv4 has
   been hampered by a lack of ubiquitous hardware and software support
   throughout the industry.  Many vendors, especially in the consumer
   space have continued to view IPv6 support as optional.  Even today
   they are still selling "IP capable" or "Internet Capable" devices
   which are not IPv6-capable, which has continued to push out the point
   at which the natural hardware refresh cycle will significantly
   increase IPv6 support.  They are also choosing not to update existing
   software to enable IPv6 support on software-updatable devices, which
   is a problem because it is not realistic to expect that the hardware
   refresh cycle will single-handedly purge IPv4-only devices from the
   active network in a reasonable amount of time.  This is a significant
   problem, especially in the consumer space, where the network operator
   often has no control over the hardware the consumer chooses to use.
   For the same reason that the average consumer is not making a
   purchasing decision based on the presence of IPv6 support in their
   Internet-capable devices and services, consumers are unlikely to
   replace their still-functional Internet-capable devices simply to add
   IPv6 support - they don't know or don't care about IPv6, they simply
   want their devices to work as advertised.

   This lack of support is making the eventual IPv6 transition
   considerably more difficult, and drives the need for expensive and
   complicated transition technologies to extend the life of IPv4-only
   devices as well as eventually to interwork IPv4-only and IPv6-only

George, et al.          Expires September 5, 2011               [Page 3]

Internet-Draft                IPv6-required                   March 2011

   hosts.  While IPv4 is expected to coexist on the Internet with IPv6
   for many years, a transition from IPv4 as the dominant Internet
   Protocol towards IPv6 as the dominant Internet Protocol will need to
   occur.  The sooner the majority of devices support IPv6, the less
   protracted this transition period will be.

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

   This draft updates the following documents:

   Updates [RFC1812] to note that IP nodes SHOULD no longer support IPv4
   only.  This is to ensure that those using it as a guideline for IP
   implementations use the other informative references in this document
   as a guideline for proper IPv6 implementations.

   Updates [RFC1122] to redefine generic "IP" support to include and
   require IPv6 for IP-capable nodes and routers.

   Updates [RFC4084] to move "Version Support" from Section 4,
   "Additional Terminology" to Section 2, "General Terminology."  This
   is to reflect the idea that version support is now critical to
   defining the types of IP service, especially with respect to Full
   Internet Connectivity.

   From a practical perspective, the requirements proposed by this draft
   mean that:

      New IP implementations MUST support IPv6.

      Current IP implementations SHOULD support IPv6.

      IPv6 support MUST be equivalent in quality and functionality to
      IPv4 support.

      Helpful informative references can be found in [RFC4294], soon to
      be updated by [I-D.ietf-6man-node-req-bis] and

      Current and new IP Networking implementations SHOULD support IPv4
      and IPv6 coexistence (dual-stack), but MUST NOT require IPv4 for
      proper and complete function.

George, et al.          Expires September 5, 2011               [Page 4]

Internet-Draft                IPv6-required                   March 2011

      It is expected that many existing devices and implementations will
      not be able to support IPv6 for one or more valid technical
      reasons, but for maximum flexibility and compatibility, a best
      effort SHOULD be made to update existing hardware and software to
      enable IPv6 support.

   Within the IETF, further development on protocols and applications
   _exclusive_ to IPv4 SHOULD cease, except for vital operational or
   security issues.  This will enable IETF WGs to concentrate on
   additional refinements and enhancements to IP version 6, with the
   goal of bringing IPv6 to parity with IPv4 in function, support, and
   deployment.  This does not mean that future work SHOULD NOT have
   support for IPv4, merely that it MUST happen as a part of an IP
   version-agnostic implementation, or as an implementation that
   explicitly supports both IPv4 and IPv6.  New features and protocols
   SHOULD NOT be introduced for use as IPv4-only unless they are
   specifically in support of IPv6 transition or IPv4-IPv6 interworking.
   A comprehensive list of these parity items and enhancements 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 goal of
   full parity for IPv6.

3.  Acknowledgements

   Thanks to the following people for their reviews and comments: Marla
   Azinger, Brian Carpenter, Victor Kuarsingh.

4.  IANA Considerations

   This memo includes no request to IANA.

5.  Security Considerations

   There are no direct security considerations generated by this
   document, but existing documented security considerations for
   implementing IPv6 will apply.

6.  References

6.1.  Normative References

   [RFC1122]  Braden, R., "Requirements for Internet Hosts -
              Communication Layers", STD 3, RFC 1122, October 1989.

George, et al.          Expires September 5, 2011               [Page 5]

Internet-Draft                IPv6-required                   March 2011

   [RFC1812]  Baker, F., "Requirements for IP Version 4 Routers",
              RFC 1812, June 1995.

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

   [RFC4084]  Klensin, J., "Terminology for Describing Internet
              Connectivity", BCP 104, RFC 4084, May 2005.

6.2.  Informative References

              Donley, C., Howard, L., Kuarsingh, V., Chandrasekaran, A.,
              and V. Ganti, "Assessing the Impact of NAT444 on Network
              Applications", draft-donley-nat444-impacts-01 (work in
              progress), October 2010.

              Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node
              Requirements RFC 4294-bis",
              draft-ietf-6man-node-req-bis-07 (work in progress),
              December 2010.

              Ford, M., Boucadair, M., Durand, A., Levis, P., and P.
              Roberts, "Issues with IP Address Sharing",
              draft-ietf-intarea-shared-addressing-issues-05 (work in
              progress), March 2011.

              Singh, H., Beebee, W., Donley, C., Stark, B., and O.
              Troan, "Basic Requirements for IPv6 Customer Edge
              Routers", draft-ietf-v6ops-ipv6-cpe-router-09 (work in
              progress), December 2010.

              IANA, "IANA address allocation", 2011, <http://

   [RFC1883]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 1883, December 1995.

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, December 1998.

   [RFC4294]  Loughney, J., "IPv6 Node Requirements", RFC 4294,
              April 2006.

George, et al.          Expires September 5, 2011               [Page 6]

Internet-Draft                IPv6-required                   March 2011

Authors' Addresses

   Wesley George
   12000 Sunrise Valley Drive
   Reston, VA  20196

   Phone: +1 703-592-4847
   Email: wesley.e.george@sprint.com

   Chris Donley
   858 Coal Creek Circle
   Louisville, CO  80027

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

   Christopher Liljenstolpe
   Level 32/242 Exhibition Street
   Melbourne, VIC  3000

   Phone: +61-3-8647-6389
   Email: cdl@asgaard.org

   Lee Howard
   Time Warner Cable
   13241 Woodland Park Road
   Herndon, VA  20171

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

George, et al.          Expires September 5, 2011               [Page 7]