[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Will IPv4 be formally deprecated when IPv6 is good enough ?

Hi,

A recent discussion came up on the ipv6 mailing list regarding why the market picked up IPv4 NAT, initially asked by Geoff Huston, and posted to the list by Pekka Savola.

Archives of the discussion are available at 

http://marc.theaimsgroup.com/?l=ipng&m=106389565013129&w=2

and

http://marc.theaimsgroup.com/?l=ipng&m=106442112224359&w=2


A little later, it occured to me that maybe what the market might be missing is a statement from the IETF, IESG and/or IAB, that IPv6 is now *ready*, and can be deployed in production via the available transition mechanisms, slowly replacing IPv4 (+ NAT). Maybe the market is really just waiting for the engineers behind IPv6 to say "it's basically finished, its now ready for you to use, pending your applications being ported".

Having a brief look at the list of IPng requirements in rfc1752, it would appear to me, with my limited knowledge of all the IPv6 development that has occured, that most of the goals have been met :

"6.1 The IPng Technical Criteria document

   The criteria described in this document include: (from Kasten94)

   * complete specification - The proposal must completely describe the
     proposed protocol.  We must select an IPng by referencing specific
     documents, not to future work.
   * architectural simplicity - The IP-layer protocol should be as
     simple as possible with functions located elsewhere that are more
     appropriately performed at protocol layers other than the IP layer.
   * scale - The IPng Protocol must allow identifying and addressing at
     least 10**9 leaf-networks (and preferably much more)
   * topological flexibility - The routing architecture and protocols
     ofIPng must allow for many different network topologies.  They must
     not assume that the network's physical structure is a tree.
   * performance - A state of the art, commercial grade router must be
     able to process and forward IPng traffic at speeds capable of fully
     utilizing common, commercially available, high-speed media at the
     time.
   * robust service - The network service and its associated routing and
     control protocols must be robust.
   * transition -  The protocol must have a straightforward transition
     plan from IPv4.
   * media independence -  The protocol must work across an internetwork
     of many different LAN, MAN, and WAN media, with individual link
     speeds ranging from a ones-of-bits per second to hundreds of
     gigabits per second.
   * datagram service - The protocol must support an unreliable datagram
     delivery service.
   * configuration ease -  The protocol must permit easy and largely
     distributed configuration and operation. Automatic configuration of
     hosts and routers is required.
   * security - IPng must provide a secure network layer.
   * unique names - IPng must assign unique names to all IP-Layer
     objects in the global, ubiquitous, Internet.  These names may or
     may not have any location, topology, or routing significance.
   * access to standards -  The protocols that define IPng and its
     associated protocols should be as freely available and
     redistributable as the IPv4 and related RFCs.  There must be no
     specification-related licensing fees for implementing or selling
     IPng software.
   * multicast support - The protocol must support both unicast and
     multicast packet transmission.   Dynamic and automatic routing of
     multicasts is also required.
   * extensibility -  The protocol must be extensible; it must be able
     to evolve to meet the future service needs of the Internet. This
     evolution must be achievable without requiring network-wide
     software upgrades.
   * service classes - The protocol must allow network devices to
     associate packets with particular service classes and provide them
     with the  services specified by those classes.
   * mobility - The protocol must support mobile hosts, networks and
     internetworks.
   * control protocol - The protocol must include elementary support for
     testing and debugging networks. (e.g., ping and traceroute)
   * tunneling support -  IPng must allow users to build private
     internetworks on top of the basic Internet Infrastructure.  Both
     private IP-based internetworks and private non-IP-based (e.g., CLNP
     or AppleTalk) internetworks must be supported."

That brings to my mind two questions

a) Is IPv4 going to be formally deprecated when IPv6 is good enough? If so, are the related IPv4 NAT RFCs also going to be deprecated at that time ?

b) Is IPv6 good enough yet ?


Thanks,
Mark.

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------