One document matched: draft-ietf-intarea-ipv6-required-02.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 RFC1122 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1122.xml">
<!ENTITY RFC1812 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1812.xml">
<!ENTITY RFC1883 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1883.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 RFC6269 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6269.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="bcp" docName="draft-ietf-intarea-ipv6-required-02"
ipr="trust200902" updates="">
<!-- 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="8" month="December" 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 advises that
IPv6 support 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 the term "IP"
becomes a generic which can mean IPv4 + IPv6, IPv6-only, or IPv4-only,
depending on context and application.</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="RFC6269"></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 (e.g., <xref target="RFC2460"></xref>) and
deployment ever since. 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>
<section anchor="simple_list" title="Clarifications and Recommendation">
<t>To ensure interoperability and proper function after IPv4 exhaustion,
support for IPv6 is virtually a requirement. 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, implementers are cautioned that a distinction must be
made between IPv4 and IPv6 in some IETF documents 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>Many of IETF's early documents use the generic term "IP" synonymously
with the more specific "IPv4." Some examples of this potential confusion
can be found in <xref target="RFC1812"></xref>, especially sections 1,
2, and 4. Since RFC1812 is an IPv4 router specification, the generic use
of IP in this standard may cause confusion as the term "IP" can now be
interpreted to mean: IPv4 + IPv6, IPv6-only, or IPv4-only. Additionally,
<xref target="RFC1122"></xref>, is no longer a complete definition of
"IP" or the Internet Protocol suite by 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, 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. Additional instances of
this type of problem exist that are not discussed here. Since existing
RFCs say "IP" in places where they may mean IPv4, implementers are
cautioned to ensure that they know whether a given standard is inclusive
or exclusive of IPv6. To ensure interoperability, implementers building
IP nodes will need to support both IPv4 and IPv6. If the standard does
not include an integral definition of both IPv4 and IPv6, implementers
need to use the other informative references in this document as a
companion guideline for proper IPv6 implementations.</t>
<t>To ensure interoperability and flexibility, the best practice is:</t>
<t><list style="empty">
<t>New IP implementations must support IPv6.</t>
<t>Updates to 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 a new or updated IP
implementation.</t>
<t>New and updated IP Networking implementations should support IPv4
and IPv6 coexistence (dual-stack), but must not require IPv4 for
proper and complete function.</t>
<t>Implementers are encouraged to update existing hardware and
software to enable IPv6 wherever technically feasible.</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, Eric
Rosen, David Harrington, Wesley Eddy.</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="Informative References">
<!-- Here we use entities that we defined at the beginning. -->
&RFC1122;
&RFC1812;
&RFC1883;
&RFC2460;
&RFC4294;
&RFC6269;
&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 03:16:15 |