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/