Internet DRAFT - draft-eddy-ipv6-maturity
draft-eddy-ipv6-maturity
Network Working Group W. Eddy
Internet-Draft Verizon Federal Network Systems
Expires: November 9, 2006 W. Ivancic
NASA Glenn Research Center
May 8, 2006
Assessment of IPv6 Maturity
draft-eddy-ipv6-maturity-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 9, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document collects and comments on several indicators of IPv6's
maturity level as a technology. This data can be used in decision-
making processes where many myths regarding IPv6 completeness and
deployability persist.
Eddy & Ivancic Expires November 9, 2006 [Page 1]
Internet-Draft IPv6 Maturity May 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Protocol Documentation . . . . . . . . . . . . . . . . . . . 4
3. Running Code . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Real-World Deployment . . . . . . . . . . . . . . . . . . . 7
5. Policy Directives . . . . . . . . . . . . . . . . . . . . . 9
6. Summary of Findings . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . 11
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
9. Informative References . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . 14
Eddy & Ivancic Expires November 9, 2006 [Page 2]
Internet-Draft IPv6 Maturity May 2006
1. Introduction
While IPv4 has achieved widespread use and acclaim, its intended
successor, IPv6, is still facing some hurdles in large-scale
deployment. In both aeronautical networking and space networks a
move towards network-centric operations and away from application-
specific point-to-point links is occuring. In multiple groups that
are attempting to define aeronautical or space networking
architectures, the use of Internet protocols is well-accepted, but
there is considerable uncertainty on whether to use IPv4, IPv6, or a
dual-stack.
It is the technical opinion of many that IPv6 is favorable, due to
some of its features (mobility and security are particularly
important for network-centric operations). Vague notions persist
that IPv6 is still ephemeral work-in-progress and not yet ready for
widespread use, or that IPv6 has no market support. In this
document, we attempt to largely dispel these notions as myths by
presenting several sets of hard data that argue to the contrary.
Companion documents debunk arguments where IPv4 is brought forward as
a favored choice based on the logic that it has lower "overhead" than
IPv6 [Eddy06], and provide a comparison of the relative features of
IPv6 and IPv4 [EI06].
This document is broken down as follows. Section 2 contains
discussion of the available specifications, their status as
standards, and other informational materials regarding IPv6.
Section 3 describes the availability of IPv6 support in common
products, operating systems, and commercial routers. Section 4
contains some information on real-world usage of IPv6 which is
currently happening, and Section 5 considers various policy
directives and guidance on deploying IPv6. Finally, Section 6 then
summarizes the results of this study.
Eddy & Ivancic Expires November 9, 2006 [Page 3]
Internet-Draft IPv6 Maturity May 2006
2. Protocol Documentation
The IPv6 standard was the output of the IPng course of action to find
a replacement for IPv4, given all of the lessons learned from IPv4
use over the years. While many people have the notion that the
significance of IPv6 lies in a larger address space, an examination
of the literature shows that this is only the tip of the iceberg, and
the IPv4 address size was only one of around a dozen IPv4 aspects
that it was seen necessary to change. The search tool on the rfc-
editor.org website can be used to find many RFCs that document the
history of the IPng process, and archived copies of expired internet-
drafts with further details can also be found on the Internet. In
April of 2006, a simple search on rfc-editor.org for "IPng" yielded
41 RFC documents, most of which are Informational and contain inputs
to the IPng from representatives of various industry segments or
researchers.
In December of 1995, RFC 1883 was published as a Proposed Standard
for IPv6 [RFC1883]. Three years later, in December of 1998, RFC 2460
was published as a Draft Standard [RFC2460]. This basic
specification that covers the IPv6 header format, required extension
headers, fragmentation behavior, flow labels, traffic classes, and
upper-layer protocol issues has remained unchanged since its
publication. Accompanying documents that can be considered the core
of IPv6 include the specifications for ICMPv6 [RFC2463], Neighbor
Discovery [RFC2461], and Address Autoconfiguration [RFC2462], all of
which have reached the Draft Standard level as well. Many protocols
that are well-accepted by industry and in widespread use are only
Proposed Standards, and not even formally at this level of maturity
in the IETF process. All of this demonstrates that the core IPv6
specification is agreed upon and stable and has been for some time
now.
Additionally, a very rough search on the rfc-editor.org website for
"IPv6", turns up 166 documents. For the most part, these document
IPv6 usage and interactions in conjunction with other protocols, or
extensions to IPv6. This search is fairly conservative in that a
much larger number of documents deal with IPv6 in at least some way,
but are not indexed under the term "IPv6", and so do not turn up. We
simply use the large number of results that do show up as evidence
that integration of IPv6 with numerous link layers and extension of
IPv6 has been actively pursued in industry, and a large number of
supplementary standards have been produced. Among IETF working
groups, the "Mobility for IPv4" group seems to be the only one
specifically chartered to provide an IPv4-only protocol, whereas at
least 8 others are chartered specifically to provide IPv6-based
solutions, including:
Eddy & Ivancic Expires November 9, 2006 [Page 4]
Internet-Draft IPv6 Maturity May 2006
o IPv6 over Low-Power WPAN (6lowpan)
o IPv6 Working Group (ipv6)
o Mobility for IPv6 (mip6)
o Mobile IPv6 Signalling and Handoff Optimization (mipshop)
o Mobile Nodes and Multiple Interfaces in IPv6 (monami6)
o Site Multihoming by IPv6 Intermediation (shim6)
o Site Multihoming in IPv6 (multi6)
o IPv6 Operations (v6ops)
Among other working groups, for example those focusing on security,
application, or transport protocols, it seems that the vast majority
are constructing protocols that will work with either IPv6 or both
IPv6 and IPv4 (e.g. Host Identity Protocol). There is a clear sense
of support for IPv6 in the standards community based on this survey
of current IETF activities. From mailing list archives it can be
seen that representatives from several large vendors and operators
are active participants in the IPv6 groups, not merely academics.
In addition to the IETF, other bodies exist, such as the IPv6 Forum,
to further the use and adoption of IPv6, and produce documentation
and reccommendations on the topic. There are widely available
training courses and materials, textbooks, and support services for
IPv6 deployment, transition, and troubleshooting. A search on
amazon.com for IPv6 books turned up 60 results. The next section of
this document examines actual IPv6 implementations that are readily
available.
Eddy & Ivancic Expires November 9, 2006 [Page 5]
Internet-Draft IPv6 Maturity May 2006
3. Running Code
A large number of IPv6 implementations are available from both
commercial vendors and the open-source community. The IPv6 Forum has
created the "IPv6 Ready" Logo Program which consists of sets of
criteria that can be used to assess the features and interoperability
of IPv6 products. Phase-1 of this program judges implementations of
basic or core IPv6 functions. Over 200 products have been certified
to use the Phase-1 IPv6 Ready Logo. The Phase-2 Logo builds upon
Phase-1 by adding tests for IPsec and mobility features. Several
dozen products are on the approved list for Phase-2.
Major router vendors are serious about IPv6 and provide products that
implement many advanced features in addition to the IPv6 base.
Cisco, for instance, has a webpage that lists dozens of specific IPv6
services and details which versions of their IOS software implement
the features and where documentation on configuring them can be found
(http://www.cisco.com/en/US/products/sw/iosswrel/ps5187/
products_configuration_guide_chapter09186a00801d65ed.html).
Similarly, Juniper has supported IPv6 basic functions since 2001 in
JUNOS 5.1 [Shimizu01], and supports IPv6 across their product line
[Uze02].
IPv6 support is built into many off-the-shelf end-host operating
systems as well. Microsoft's Windows Server 2003, Windows XP
(Service Pack 1 or 2), and Windows CE .NET all support IPv6. Apple's
MacOS 10.3 and Sun's Solaris 8 similarly have built-in support for
IPv6. The Japanese KAME project developed IPv6 support for the open-
source BSD-based operating systems, and Linux has had IPv6 support
since the 2.2 kernel.
Additionally, many common consumer devices come with IPv6. For
instance, the 3GPP and 3GPP2 cellular telephony groups have made IPv6
a part of the IP Multimedia System (IMS). IPv6 capable, or dual-
stack cellular handsets have been available for some time (the Nokia
7700 is an example), and a dual-stack takes up only about 15% more
space on the device than an IPv4-only stack [Loughney04]. Sony's
Playstation 2 and Microsoft's X-Box video game consoles are both
IPv6-enabled and widely deployed.
Eddy & Ivancic Expires November 9, 2006 [Page 6]
Internet-Draft IPv6 Maturity May 2006
4. Real-World Deployment
In this section, we examine evidence that the IPv6 Internet is
currently operational. This evidence comes from four main sources
(1) known IPv6 exchanges and peering services, (2) reports from the
RIRs on IPv6 allocations, (3) BGP announcements, and (4) measurements
of 6-to-4 gateways. All of this evidence suggests that IPv6 is
nearing a critical mass of operational use.
The www.v6nap.net web site lists 18 exchanges that support IPv6
throughout the United States, South Korea, the Netherlands, Finland,
France, Germany, Japan and the UK. As an example, the MAE exchange
(operated by Verizon Business) is really a number of facilities
consisting of four main locations in the United States, one in Paris,
France, and one in Frankfurt, Germany. Each of these facilities may
actually extend to a number of physical sites throughout a number of
nearby cities. A customer's routers connect to switches at a MAE
site over which they can interface with other customer's routers to
exchange traffic. Currently, all of the MAE facilities are capable
of exchanging IPv6 traffic. The same switches are used to support
both IPv4 and IPv6, accros a number of access types (ATM, Frame
Relay, or Gigabit Ethernet). Native IPv6, dual-stack, and tunneled
connections are supported at the customer's discretion. New IPv6
native exchange point addresses are available upon request from MAE,
and IPv6 addresses are automatically provided to customers with
current IPv4 addresses at an exchange. More information can be found
at www.mae.net.
IPv6 address blocks are assigned by IANA to the five Regional
Internet Registries (RIRs). The RIRs then further distribute smaller
blocks of addresses to IPv6 ISPs and other Local Internet Registries
(LIRs). Each of the five RIRs publishes some statistics on the
prefixes that they have delegated. Examination of some recent
reports of these statistics allows us to count the number of IPv6
prefixes delegated, as well as the Autonomous System Numbers (ASNs)
assigned (note that the percentage presented that compares the number
of IPv6 prefixes to the number of ASNs is not a completely valid way
to measure IPv6 adoption for a number of reasons):
AfriNIC (April 24, 2006): 11 IPv6 prefixes (220 ASNs - 5%)
APNIC (April 24, 2006): 436 IPv6 prefixes (2162 ASNs - 20.2%)
ARIN (April 24, 2006): 247 IPv6 prefixes (16729 ASNs - 1.5%)
LACNIC (April 21, 2006): 54 IPv6 prefixes (1060 ASNs - 5.1%)
Eddy & Ivancic Expires November 9, 2006 [Page 7]
Internet-Draft IPv6 Maturity May 2006
RIPE NCC (April 21, 2006): 761 IPv6 prefixes (11437 ASNs - 6.7%)
This data indicates that IPv6 addresses have been assigned to a fair
number of LIRs, especially in the Asia-Pacific region. The current
policies for IPv6 allocation from the RIRs do not allow address
blocks to be assigned to end-sites (although this may be changed
soon), whereas this is not the case in IPv4, so the number of ASNs
reflects a number of IPv4 end-sites that are not eligible for IPv6
address blocks from an RIR, and thus the number of locations where
IPv6 is usable is actually much greater than the percentages of
prefixes over ASNs reported here. If Provider Independent addressing
for IPv6 became popular with the RIRs, then we would expect these
percentages to more accurately reflect the penetration of IPv6.
Since ASNs may correspond to multiple prefixes, at full adoption,
these would go somewhere above 100%.
In April of 2006, Geoff Huston's BGP analysis tool (bgp.potaroo.net/
v6/as6447) sshows between 721 active IPv6 BGP entries. Among these,
589 unique AS numbers appear, with 419 origin-only ASes, 12 transit-
only ASes, and the remainder mixed. These BGP observations show that
there is a global IPv6 routing table with a reasonable number of
sites contained in it.
6-to-4 [RFC3056] is a transition mechanism that tunnels IPv6 over
IPv4 packets for transit across the network. Pekka Savola has
studied the traffic at a public 6-to-4 gateway [Savola04]. This was
only considered to be a relatively small, or lightly-used, 6-to-4
gateway, it still was probed by 2 million Windows hosts, and actively
used by over 1000 nodes per month in 2004. DNS traffic, as well as
SSH, HTTP, SMTP, and BitTorrent file sharing were all observed over
the 6-to-4 gateway, indicating that typical Internet applications are
functioning over it.
Eddy & Ivancic Expires November 9, 2006 [Page 8]
Internet-Draft IPv6 Maturity May 2006
5. Policy Directives
Among US government agencies, the Department of Defense (DoD) was an
early recognizer of the benefits of IPv6 and began the deployment and
transition process before most other federal agencies even considered
IPv6. the DoD has a number of useful resources for IPv6, including a
set of feature profiles for judging aquisitions against [Green05].
The DoD has announced plans to fully transition to IPv6 by fiscal
year 2008.
In 2005, the Government Accountability Office (GAO) recomended to the
Office of Management and Budget (OMB) that other federal agencies
should follow DoD's lead and begin planning for a move to IPv6
[GAO05]. Following this, it was announced that June 2008 was the
deadline for all agencies to support IPv6 in their operational
networks [Evans05].
Plans for the 2008 Olympics in China involve IPv6 as a prominent
means of connecting millions of users to various types of multimedia
content [Chi-Loong05]. In general, the growth in the "online
population" in Asian countries is causing IPv6 to be eager to deploy
IPv6.
Since IPv6 several of the features of IPv6 can be back-ported or
hacked into an IPv4 architecute through various means, IPv6 has been
portrayed as unecessary or lacking a killer-application by many
pundits. That these opinions are not very well informed from a
standpoint of network architecture, where attempting to make IPv4 do
things that it was not designed for make the network more fragile.
For instance, the use of NAT to get around addressing limitations in
IPv4 is well-known to have poor architectural implications [RFC2993].
Unfortunately, US businesses still seem to be stalling on IPv6
deployment, however, the recent government action in this area may
serve to motivate the private sector to some extent.
Eddy & Ivancic Expires November 9, 2006 [Page 9]
Internet-Draft IPv6 Maturity May 2006
6. Summary of Findings
The general result of this study is that IPv6 can be used at the
present time, and is being deployed in diverse settings (from mobile
phones and video games to government systems).
The technical advantages, ease of availability, and policy directives
regarding IPv6 combine to make it the strongly favored option for use
in present network design efforts.
Eddy & Ivancic Expires November 9, 2006 [Page 10]
Internet-Draft IPv6 Maturity May 2006
7. Security Considerations
This informational document only contains data about IPv6 maturity.
There are no new security considerations raised by this material.
Eddy & Ivancic Expires November 9, 2006 [Page 11]
Internet-Draft IPv6 Maturity May 2006
8. Acknowledgements
Work on this document was performed at NASA's Glenn Research Center,
in support of the NASA Space Communications Architecture Working
Group (SCAWG), and the FAA/Eurocontrol Future Communications Study
(FCS). Joe Ishac of NASA contributed useful comments on this
document.
9. Informative References
[Chi-Loong05]
Chi-Loong, C., "China's IT Gold", CMPnetAsia Newsletter ,
December 2005.
[EI06] Eddy, W. and J. Ishac, "IPv6-IPv4 Feature Comparison",
draft-eddy-ipv6-ipv4-comparison-00 Internet-Draft (work in
progress), May 2006.
[Eddy06] Eddy, W., "Comparison of IPv4 and IPv6 Header Overhead",
draft-eddy-ipv6-overhead-00 Internet-Draft (work in
progress), May 2006.
[Evans05] Evans, K., "Transition Planning for Internet Protocol
Version 6", Office of Management and Budget, Memorandum
for the Chief Information Officers M-05-22, August 2005.
[GAO05] GAO, "Federal Agencies Need to Plan for Transition and
Manage Security Risks", GAO report to congressional
requesters GAO-05-471, May 2005.
[Green05] Green, D., "DoD IPv6 Standard Profiles for IPv6 Capable
Products", DISA draft for coordination, Draft v.06,
December 2005.
[Loughney04]
Loughney, J., "IPv6 in 2G and 3G Networks", North American
IPv6 Summit 2004, June 2004.
[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.
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461,
December 1998.
Eddy & Ivancic Expires November 9, 2006 [Page 12]
Internet-Draft IPv6 Maturity May 2006
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[RFC2463] Conta, A. and S. Deering, "Internet Control Message
Protocol (ICMPv6) for the Internet Protocol Version 6
(IPv6) Specification", RFC 2463, December 1998.
[RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993,
November 2000.
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
via IPv4 Clouds", RFC 3056, February 2001.
[Savola04]
Savola, P., "Observations of IPv6 Traffic on a 6to4
Relay", ACM Computer Communication Review, Volume 35,
Number 1, January 2005.
[Shimizu01]
Shimizu, T., "Juniper Networks IPv6 Implementation",
Global IPv6 Summit, Yokohama, Japan, December 2001.
[Uze02] Uze, J., "Juniper IPv6 Solution", RIPE 42, IPv6 WG,
May 2002.
Authors' Addresses
Wesley M. Eddy
Verizon Federal Network Systems
21000 Brookpark Rd, MS 54-5
Cleveland, OH 44135
Phone: 216-433-6682
Email: weddy@grc.nasa.gov
William D. Ivancic
NASA Glenn Research Center
21000 Brookpark Rd, MS 54-5
Cleveland, OH 44135
Phone: 216-433-3494
Email: wivancic@grc.nasa.gov
Eddy & Ivancic Expires November 9, 2006 [Page 13]
Internet-Draft IPv6 Maturity May 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Eddy & Ivancic Expires November 9, 2006 [Page 14]
