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 [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
