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]