One document matched: draft-ietf-intarea-ipv6-required-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC1883 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1883.xml">
<!ENTITY RFC1812 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1812.xml">
<!ENTITY RFC1122 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1122.xml">
<!ENTITY RFC2460 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2460.xml">
<!ENTITY RFC4294 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4294.xml">
<!ENTITY RFC4084 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4084.xml">
<!ENTITY I-D.ietf-intarea-shared-addressing-issues SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-intarea-shared-addressing-issues.xml">
<!ENTITY I-D.donley-nat444-impacts SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.donley-nat444-impacts.xml">
<!ENTITY RFC6204 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6204.xml">
<!ENTITY I-D.ietf-6man-node-req-bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-6man-node-req-bis.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-ietf-intarea-ipv6-required-01"
ipr="trust200902" updates="1812, 1122, 4084">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="IPv6-required">IPv6 Support Required for all IP-capable
nodes</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Wesley George" initials="W" surname="George">
<organization>Time Warner Cable</organization>
<address>
<postal>
<street>13820 Sunrise Valley Drive</street>
<!-- Reorder these if your country does things differently -->
<city>Herndon</city>
<region>VA</region>
<code>20171</code>
<country>US</country>
</postal>
<phone>+1 703-561-2540</phone>
<email>wesley.george@twcable.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Chris Donley" initials="C" surname="Donley">
<organization>Cablelabs</organization>
<address>
<postal>
<street>858 Coal Creek Circle</street>
<!-- Reorder these if your country does things differently -->
<city>Louisville</city>
<region>CO</region>
<code>80027</code>
<country>US</country>
</postal>
<phone>+1-303-661-9100</phone>
<email>C.Donley@cablelabs.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Christopher Liljenstolpe" initials="C"
surname="Liljenstolpe">
<organization>Telstra</organization>
<address>
<postal>
<street>Level 32/242 Exhibition Street</street>
<!-- Reorder these if your country does things differently -->
<city>Melbourne</city>
<region>VIC</region>
<code>3000</code>
<country>AU</country>
</postal>
<phone>+61-3-8647-6389</phone>
<email>cdl@asgaard.org</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Lee Howard" initials="L" surname="Howard">
<organization>Time Warner Cable</organization>
<address>
<postal>
<street>13820 Sunrise Valley Drive</street>
<!-- Reorder these if your country does things differently -->
<city>Herndon</city>
<region>VA</region>
<code>20171</code>
<country>US</country>
</postal>
<phone>+1-703-345-3513</phone>
<email>lee.howard@twcable.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<date day="11" month="July" year="2011" />
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>General</area>
<workgroup>Internet Area Working Group</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>IPv6 IPv4 node requirement</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>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, RFC1122 and RFC4084 to
reflect the change in requirements.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>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 <xref target="IANA-exhaust"></xref>, and
will be followed by the exhaustion of the free pools for each Regional
Internet Registry (RIR), the first of which is APNIC <xref
target="APNIC-exhaust"></xref>. 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 <xref
target="I-D.ietf-intarea-shared-addressing-issues"></xref> and <xref
target="I-D.donley-nat444-impacts"></xref> for some discussion on this
topic.</t>
<t>IPv6 <xref target="RFC1883"></xref> 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 and deployment ever since. <xref
target="RFC2460"></xref>. The exhaustion of IPv4 and the continued
growth of the internet worldwide has created the driver for widespread
IPv6 deployment.</t>
<t>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.</t>
<t>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.</t>
<section title="Requirements Language">
<t>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 <xref
target="RFC2119">RFC 2119</xref>.</t>
</section>
</section>
<section anchor="simple_list" title="Requirements and Recommendation">
<t>This draft updates the following documents:</t>
<t>Updates <xref target="RFC1812"></xref>, especially sections 1, 2, and
4 which use the generic "IP" synonymously with the more specific "IPv4."
Since RFC1812 is an IPv4 router specification, the generic use of IP in
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. </t>
<t>Updates <xref target="RFC1122"></xref> to clarify that this document,
especially in 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. </t>
<t>Updates <xref target="RFC4084"></xref> 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.</t>
<t>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 <xref
target="RFC4294"></xref>, soon to be updated by <xref
target="I-D.ietf-6man-node-req-bis"></xref> and in <xref
target="RFC6204"></xref>. Each of these documents contains specific
information, requirements, and references to other draft and proposed
standards governing many aspects of IPv6 implementation.</t>
<t>From a practical perspective, the requirements proposed by this draft
mean that:</t>
<t><list style="empty">
<t>New IP implementations MUST support IPv6.</t>
<t>Current IP implementations SHOULD support IPv6.</t>
<t>IPv6 support MUST be equivalent or better in quality and
functionality when compared to IPv4 support in an IP
implementation.</t>
<t>Current and new IP Networking implementations SHOULD support IPv4
and IPv6 coexistence (dual-stack), but MUST NOT require IPv4 for
proper and complete function.</t>
<t>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.</t>
</list></t>
</section>
<!-- This PI places the pagebreak correctly (before the section title) in the text output. -->
<?rfc needLines="8" ?>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>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</t>
</section>
<!-- Possibly a 'Contributors' section ... -->
<section anchor="IANA" title="IANA Considerations">
<t>This memo includes no request to IANA.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>There are no direct security considerations generated by this
document, but existing documented security considerations for
implementing IPv6 will apply.</t>
</section>
</middle>
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
&RFC2119;
&RFC1812;
&RFC1122;
&RFC4084;
</references>
<references title="Informative References">
<!-- Here we use entities that we defined at the beginning. -->
&RFC1883;
&RFC2460;
&RFC4294;
&I-D.ietf-intarea-shared-addressing-issues;
&I-D.donley-nat444-impacts;
&RFC6204;
&I-D.ietf-6man-node-req-bis;
<!-- A reference written by by an organization not a person. -->
<reference anchor="IANA-exhaust"
target="http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml">
<front>
<title>IANA address allocation</title>
<author>
<organization>IANA</organization>
</author>
<date year="2011" />
</front>
</reference>
<reference anchor="APNIC-exhaust"
target="http://www.apnic.net/__data/assets/pdf_file/0018/33246/Key-Turning-Point-in-Asia-Pacific-IPv4-Exhaustion_English.pdf ">
<front>
<title>APNIC Press Release</title>
<author>
<organization>APNIC</organization>
</author>
<date year="2011" />
</front>
</reference>
</references>
<!-- Change Log
v00 2006-03-15 EBD Initial version
v01 2006-04-03 EBD Moved PI location back to position 1 -
v3.1 of XMLmind is better with them at this location.
v02 2007-03-07 AH removed extraneous nested_list attribute,
other minor corrections
v03 2007-03-09 EBD Added comments on null IANA sections and fixed heading capitalization.
Modified comments around figure to reflect non-implementation of
figure indent control. Put in reference using anchor="DOMINATION".
Fixed up the date specification comments to reflect current truth.
v04 2007-03-09 AH Major changes: shortened discussion of PIs,
added discussion of rfc include.
v05 2007-03-10 EBD Added preamble to C program example to tell about ABNF and alternative
images. Removed meta-characters from comments (causes problems). -->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:58:15 |