draft-ietf-intarea-ipv6-required-00.txt   draft-ietf-intarea-ipv6-required-01.txt 
Internet Area Working Group W. George Internet Area Working Group W. George
Internet-Draft Time Warner Cable Internet-Draft Time Warner Cable
Updates: 1812, 1122, 4084 C. Donley Updates: 1812, 1122, 4084 C. Donley
(if approved) Cablelabs (if approved) Cablelabs
Intended status: Standards Track C. Liljenstolpe Intended status: Standards Track C. Liljenstolpe
Expires: December 18, 2011 Telstra Expires: January 12, 2012 Telstra
L. Howard L. Howard
Time Warner Cable Time Warner Cable
June 16, 2011 July 11, 2011
IPv6 Support Required for all IP-capable nodes IPv6 Support Required for all IP-capable nodes
draft-ietf-intarea-ipv6-required-00 draft-ietf-intarea-ipv6-required-01
Abstract Abstract
Given the global lack of available IPv4 space, and limitations in Given the global lack of available IPv4 space, and limitations in
IPv4 extension and transition technologies, this document deprecates IPv4 extension and transition technologies, this document deprecates
the concept that an IP-capable node MAY support IPv4 _only_, and the concept that an IP-capable node MAY support IPv4 _only_, and
redefines an IP-capable node as one which supports either IPv6 _only_ redefines an IP-capable node as one which supports either IPv6 _only_
or IPv4/IPv6 dual-stack. This document updates RFC1812, RFC1122 and or IPv4/IPv6 dual-stack. This document updates RFC1812, RFC1122 and
RFC4084 to reflect the change in requirements. RFC4084 to reflect the change in requirements.
skipping to change at page 1, line 40 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 18, 2011. This Internet-Draft will expire on January 12, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 18 skipping to change at page 2, line 18
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 4
2. Requirements and Recommendation . . . . . . . . . . . . . . . . 4 2. Requirements and Recommendation . . . . . . . . . . . . . . . . 4
3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6.1. Normative References . . . . . . . . . . . . . . . . . . . 5 6.1. Normative References . . . . . . . . . . . . . . . . . . . 6
6.2. Informative References . . . . . . . . . . . . . . . . . . 6 6.2. Informative References . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction 1. Introduction
IP version 4 (IPv4) has served to connect public and private hosts 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 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, the Internet in finding new and innovative uses for IP networking,
billions of hosts are now connected via the Internet and requiring billions of hosts are now connected via the Internet and requiring
unique addressing. This demand has led to the exhaustion of the IANA unique addressing. This demand has led to the exhaustion of the IANA
global pool of unique IPv4 addresses [IANA-exhaust], and will be global pool of unique IPv4 addresses [IANA-exhaust], and will be
followed by the exhaustion of the free pools for each Regional followed by the exhaustion of the free pools for each Regional
skipping to change at page 4, line 23 skipping to change at page 4, line 23
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2. Requirements and Recommendation 2. Requirements and Recommendation
This draft updates the following documents: This draft updates the following documents:
Updates [RFC1812] to note that IP nodes SHOULD no longer support IPv4 Updates [RFC1812], especially sections 1, 2, and 4 which use the
only. This is to ensure that those using it as a guideline for IP generic "IP" synonymously with the more specific "IPv4." Since
implementations use the other informative references in this document RFC1812 is an IPv4 router specification, the generic use of IP in
as a guideline for proper IPv6 implementations. this standard may cause confusion as IP is redefined to mean IPv4 +
IPv6. This proposed update is not intended to change the existing
technical interpretation of RFC1812 to include IPv6 in its
implementation details. Rather, it is intended to ensure that those
using RFC1812 as a guideline for IP implementations understand that
IP nodes SHOULD NOT support IPv4 only, and that they should use the
other informative references in this document as a companion
guideline for proper IPv6 implementations.
Updates [RFC1122] to redefine generic "IP" support to include and Updates [RFC1122] to clarify that this document, especially in
require IPv6 for IP-capable nodes and routers. section 3, primarily discusses IPv4 where it uses the more generic
term "IP" and is no longer a complete definition of "IP" or the
Internet Protocol suite by itself. 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; 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 of RFC1122 refer to the Internet Layer and IP more
in terms of its function and are less version-specific, such as
Section 1.1.3. In these cases, it is possible 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, Updates [RFC4084] to move "Version Support" from Section 4,
"Additional Terminology" to Section 2, "General Terminology." This "Additional Terminology" to Section 2, "General Terminology." This
is to reflect the idea that version support is now critical to is to reflect the idea that version support is now critical to
defining the types of IP service, especially with respect to Full defining the types of IP service, especially with respect to Full
Internet Connectivity. Internet Connectivity.
Rather than update the existing IPv4 protocol specification standards
to include IPv6, IETF has defined a completely separate set of
standalone documents which cover IPv6. Therefore, the above-listed
standards are not being updated to include the complete technical
details of IPv6, but to identify that a distinction must be made
between IPv4 and IPv6 in some places where IP is used generically.
Current requirements for 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 and proposed standards governing many
aspects of IPv6 implementation.
From a practical perspective, the requirements proposed by this draft From a practical perspective, the requirements proposed by this draft
mean that: mean that:
New IP implementations MUST support IPv6. New IP implementations MUST support IPv6.
Current IP implementations SHOULD support IPv6. Current IP implementations SHOULD support IPv6.
IPv6 support MUST be equivalent or better in quality and IPv6 support MUST be equivalent or better in quality and
functionality when compared to IPv4 support in an IP functionality when compared to IPv4 support in an IP
implementation. implementation.
Helpful informative references can be found in [RFC4294], soon to
be updated by [I-D.ietf-6man-node-req-bis] and in [RFC6204]
Current and new IP Networking implementations SHOULD support IPv4 Current and new IP Networking implementations SHOULD support IPv4
and IPv6 coexistence (dual-stack), but MUST NOT require IPv4 for and IPv6 coexistence (dual-stack), but MUST NOT require IPv4 for
proper and complete function. proper and complete function.
It is expected that many existing devices and implementations will It is expected that many existing devices and implementations will
not be able to support IPv6 for one or more valid technical not be able to support IPv6 for one or more valid technical
reasons, but for maximum flexibility and compatibility, a best reasons, but for maximum flexibility and compatibility, a best
effort SHOULD be made to update existing hardware and software to effort SHOULD be made to update existing hardware and software to
enable IPv6 support. enable IPv6 support.
3. Acknowledgements 3. Acknowledgements
Thanks to the following people for their reviews and comments: Marla Thanks to the following people for their reviews and comments: Marla
Azinger, Brian Carpenter, Victor Kuarsingh, Jari Arkko, Scott Brim, Azinger, Brian Carpenter, Victor Kuarsingh, Jari Arkko, Scott Brim,
Margaret Wasserman, Joe Touch Margaret Wasserman, Joe Touch, Fred Baker, Benson Schliesser
4. IANA Considerations 4. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
5. Security Considerations 5. Security Considerations
There are no direct security considerations generated by this There are no direct security considerations generated by this
document, but existing documented security considerations for document, but existing documented security considerations for
implementing IPv6 will apply. implementing IPv6 will apply.
 End of changes. 11 change blocks. 
17 lines changed or deleted 45 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/