Internet Area Working Group                                    W. George
Internet-Draft                                         Time Warner Cable
Updates: 1812, 1122, 4084                                      C. Donley
(if approved)                                                  Cablelabs
Intended status: Standards Track BCP                                           C. Liljenstolpe Donley
Expires: January 12, June 10, 2012                                         Cablelabs
                                                         C. Liljenstolpe
                                                                 Telstra
                                                               L. Howard
                                                       Time Warner Cable
                                                           July 11,
                                                        December 8, 2011

             IPv6 Support Required for all IP-capable nodes
                  draft-ietf-intarea-ipv6-required-01 Nodes
                  draft-ietf-intarea-ipv6-required-02

Abstract

   Given the global lack of available IPv4 space, and limitations in
   IPv4 extension and transition technologies, this document deprecates
   the concept advises
   that an IP-capable node MAY IPv6 support IPv4 _only_, and
   redefines an IP-capable node is no longer considered optional.  It also cautions
   that there are places in existing IETF documents where the term "IP"
   is used in a way that could be misunderstood by implementers as one the
   term "IP" becomes a generic which supports either IPv6 _only_ can mean IPv4 + IPv6, IPv6-only, or IPv4/IPv6 dual-stack.  This document updates RFC1812, RFC1122
   IPv4-only, depending on context and
   RFC4084 to reflect the change in requirements. application.

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 January 12, June 10, 2012.

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
   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  Clarifications and Recommendation . . . . . . . . . . . . . . . . 4
   3.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 5
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6 5
   6.  Informative References  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
     6.1.  Normative References  . . . . . . . . . . . . . . . . . . . 6
     6.2.  Informative References  . . . . . . . . . . . . . . . . . . 6 5
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 7 6

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
   global pool of unique IPv4 addresses [IANA-exhaust], and will be
   followed by the exhaustion of the free pools for each Regional
   Internet Registry (RIR), the first of which is APNIC [APNIC-exhaust].
   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] [RFC6269] and
   [I-D.donley-nat444-impacts] for some discussion on this topic.

   IPv6 [RFC1883] was proposed in 1995 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 (e.g., [RFC2460]) 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 in the average home or enterprise network.
   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
   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",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

2.  Requirements  Clarifications and Recommendation

   This draft updates the following documents:

   Updates [RFC1812], especially sections 1, 2,

   To ensure interoperability and 4 which use the
   generic "IP" synonymously with the more specific "IPv4."  Since
   RFC1812 is an proper function after IPv4 router specification, the generic use of IP in
   this standard may cause confusion as IP exhaustion,
   support for IPv6 is redefined to mean IPv4 +
   IPv6.  This proposed virtually a requirement.  Rather than update is not intended to change the
   existing
   technical interpretation of RFC1812 IPv4 protocol specification standards to include IPv6, IETF
   has defined a completely separate set of standalone documents which
   cover IPv6.  Therefore, implementers are cautioned that a distinction
   must be made between IPv4 and IPv6 in its
   implementation details.  Rather, it some IETF documents where IP is intended to ensure that those
   using RFC1812 as a guideline
   used generically.  Current requirements for IP implementations understand that
   IP nodes SHOULD NOT IPv6 support IPv4 only, can be found
   in [RFC4294], soon to be updated by [I-D.ietf-6man-node-req-bis] and that they should use the
   other informative references
   in this document as a companion
   guideline for proper IPv6 implementations.

   Updates [RFC1122] [RFC6204].  Each of these documents contains specific information,
   requirements, and references to clarify that other draft and proposed standards
   governing many aspects of IPv6 implementation.

   Many of IETF's early documents use the generic term "IP" synonymously
   with the more specific "IPv4."  Some examples of this document, especially potential
   confusion can be found in
   section 3, primarily discusses [RFC1812], especially sections 1, 2, and 4.
   Since RFC1812 is an IPv4 where it uses router specification, the more generic use of IP
   in this standard may cause confusion as the term "IP" and can now be
   interpreted to mean: IPv4 + IPv6, IPv6-only, or IPv4-only.
   Additionally, [RFC1122], is no longer a complete definition of "IP"
   or the Internet Protocol suite by itself. itself, because it does not include
   IPv6.  For example, section 3.1 does not contain references to the
   IPv6 equivalent standards for the Internet layer, section 3.2 is a
   protocol walk-through for IPv4 only; only, and section 3.2.1.1 explicitly
   requires an IP datagram whose version number is not 4 to be
   discarded, which would be detrimental to IPv6 forwarding.
   However, portions  Additional
   instances of RFC1122 refer to the Internet Layer and IP more
   in terms this type of its function and problem exist that are less version-specific, such as
   Section 1.1.3.  In these cases, it is possible to redefine generic not discussed here.
   Since existing RFCs say "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 in places where they may mean IPv4,
   implementers are cautioned to reflect the idea ensure that version support they know whether a given
   standard is now critical to
   defining the types inclusive or exclusive of IPv6.  To ensure
   interoperability, implementers building IP service, especially with respect nodes will need to Full
   Internet Connectivity.

   Rather than update the existing support
   both IPv4 protocol specification standards
   to include IPv6, IETF has defined a completely separate set of
   standalone documents which cover and IPv6.  Therefore,  If the above-listed
   standards are standard does not being updated to include the complete technical
   details an integral
   definition of IPv6, but to identify that a distinction must be made
   between both IPv4 and IPv6 IPv6, implementers need to use the other
   informative references in some places where IP is used generically.
   Current requirements this document as a companion guideline for
   proper IPv6 support can be found in [RFC4294], soon
   to be updated by [I-D.ietf-6man-node-req-bis] and in [RFC6204].  Each
   of these documents contains specific information, requirements, and
   references to other draft implementations.

   To ensure interoperability and proposed standards governing many
   aspects of IPv6 implementation.

   From a practical perspective, flexibility, the requirements proposed by this draft
   mean that: best practice is:

      New IP implementations MUST must support IPv6.

      Current

      Updates to current IP implementations SHOULD should support IPv6.

      IPv6 support MUST must be equivalent or better in quality and
      functionality when compared to IPv4 support in an a new or updated IP
      implementation.

      Current

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

      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

      Implementers are encouraged to update existing hardware and
      software to enable IPv6 support. wherever technically feasible.

3.  Acknowledgements

   Thanks to the following people for their reviews and comments: Marla
   Azinger, Brian Carpenter, Victor Kuarsingh, Jari Arkko, Scott Brim,
   Margaret Wasserman, Joe Touch, Fred Baker, Benson Schliesser Schliesser, Eric
   Rosen, David Harrington, Wesley Eddy.

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.

   [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

   [APNIC-exhaust]
              APNIC, "APNIC Press Release", 2011, <http://www.apnic.net/
              __data/assets/pdf_file/0018/33246/
              Key-Turning-Point-in-Asia-Pacific-IPv4-
              Exhaustion_English.pdf >.

   [I-D.donley-nat444-impacts]
              Donley, C., Howard, L., Kuarsingh, V., Chandrasekaran, A., Berg, J., and V. Ganti, U.
              Colorado, "Assessing the Impact of NAT444 Carrier-Grade NAT on
              Network Applications", draft-donley-nat444-impacts-01 draft-donley-nat444-impacts-03
              (work in progress), October 2010. November 2011.

   [I-D.ietf-6man-node-req-bis]
              Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node
              Requirements", draft-ietf-6man-node-req-bis-11 (work in
              progress), May 2011.

   [I-D.ietf-intarea-shared-addressing-issues]
              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.

   [IANA-exhaust]
              IANA, "IANA address allocation", 2011, <http://
              www.iana.org/assignments/ipv4-address-space/
              ipv4-address-space.xml>.

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

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

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

   [RFC6204]  Singh, H., Beebee, W., Donley, C., Stark, B., and O.
              Troan, "Basic Requirements for IPv6 Customer Edge
              Routers", RFC 6204, April 2011.

   [RFC6269]  Ford, M., Boucadair, M., Durand, A., Levis, P., and P.
              Roberts, "Issues with IP Address Sharing", RFC 6269,
              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

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

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

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

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