Steve, I have no issue with your list of steps, other than it leaves out significant cost factors related to the exhaustion of the IPv4 Free Pool, and implies that each requires completion of the previous before it can start. A) has been true for what people call 'computers' for a long time now (~5-6 years). The place that is lacking and being corrected during the 4G rollouts is in the mobile handset space. B) is not strictly required, because most of them already tunnel IPv4 over foo, so tunneling IPv6 over foo works fine and still means that the transport network has no clue about what the clients are really doing. C) is the real problem child in the story here. Until someone in the LTE space stands up and publicly says that the mobile eyeballs are going to be connected IPv6-only, they have no motivation because they refuse to see the costs of IPv4 rising. This is also where your list falls flat. As the pool of freely available space is exhausted, the source of IPv4 addresses will be eBay. The open market will decide what block sizes get traded, and all historical controls over routing table size will vaporize. While the engineering side of the house will whine about table growth and try to maintain filters on prefix lengths, we saw in the CIDR deployment that the business side of the house will win every time and engineering will be told to "make it work". As the routing table grows at an unconstrained rate, every major content provider will also have to deal with the costs to upgrade their public facing routers. At the same time, to avoid paying market price for IPv4 addresses, every ISP will be deploying multiple layers of nat, increasing their cost and complexity, while breaking what few apps their customers have that are able to work today by signaling the local cpe based nat. This rising cost of maintaining IPv4 will be passed on to all existing customers because doing otherwise would distort the pricing models and drive potential customers away. D-F) are irrelevant, because it doesn't matter if a device/protocol/... can speak IPv4 if it is not being provisioned that way due to cost constraints. The LTE community as a whole has collectively decided that the economics of provisioning IPv4 makes no sense, even though the handsets and infrastructure could do it. While I agree there will be IPv4-only device around in 20 years (embedded controllers die slowly), the majority of the world won't care because they will live at the edge where local economics make different decisions. In the public space, pricing will drive out IPv4 fairly quickly, and that only accelerates as the end systems prefer IPv6 whenever it works. We have already seen several instances of 5% traffic shift between the versions overnight as AAAA records are added to DNS, and that is while it is still fairly difficult to get ISPs to get out of the way and just let IPv6 work even when they aren't actively supporting it. As the costs issues for maintaining IPv4 become widely understood, the demand for fully functional IPv6 products will pick up, and the parity issues you refer to will be resolved. It is unfortunate that most of the world has chosen to be 'next-quarter' focused, so they won't see the problem until it is acute, and then will be reacting in a panic. There was no need for interworking gateways if the world has deployed dual-stack in parallel, and moved the apps gracefully long before the ability to maintain IPv4 became costly. Unfortunately that didn't happen, so now the world is looking for IPv6-only to IPv4-only solutions to deal with the results of their shortsightedness, and it will be the most costly confusing mess of a deployment one could possibly imagine. Either way, it is appropriate for the IETF to declare IPv4 to be historic, and given how long it will take to decide what that means, we should start now. I seriously doubt we could get consensus on that before 2015, but waiting until then to start means it will be 2021 before we get past IPv4, and the world will have long forgotten what the debate was about. IPv4 was a fine experiment that escaped the lab, and now it is time to stand up and tell the world that we need to move to a production version. Tony From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On Behalf Of Steve Crocker Sent: Thursday, September 17, 2009 6:30 AM To: Olivier MJ Crepin-Leblond Cc: IETF Discussion Subject: Re: IPv6 standard? There are hundreds of millions of IPv4 computers and perhaps millions of individual IPv4 transport networks, large and small. Here are some useful points along the way from pure IPv4 to pure IPv6. A. Every new computer is able to talk IPv6 B. Every transport is able to talk IPv6, i.e. every network from tier 1 ISPs down through wifi hot spots and every internal corporate network C. Every major service, e.g. Google, CNN, Amazon, is reachable via IPv6 D. Every new computer is not able to talk IPv4 E. A substantial number of transports are unable to talk IPv4 F. A substantial number of major services are not directly accessible via IPv4 (but, of course, will be accessible via gateways) I haven't included supporting details like DNS and gateways between IPv4 and IPv6. We're basically at A. Give some thought to the dates you'd assign to B through F. Feel free to disagree that these are significant steps along the path, but if you do disagree, please propose other reasonable and measurable mark points. I didn't include the bitter end of this process, i.e. the complete disappearances of IPv4. If we get through steps A through F, the rest won't matter much. I have trouble believing this will all happen in less than 20 years. I do not have trouble imagining it might take much longer. I don't have any stake in the outcome. It's fine with me if it happens faster. However, the mechanisms for interoperability between IPv4 and IPv6 are still being worked out and the products to do the work, i.e. application gateways, are not yet plentiful. Moreover, even when the first products appear, there's a long maturation cycle. As one example, two years ago the ICANN Security and Stability Advisory Committee (SSAC) looked at the products in the security area -- firewalls, etc. -- to see whether the feature sets for IPv6 were the same as for IPv4. The good news was the products did actually support IPv6. The bad news was the feature sets were noticeably poorer. Our report, SAC 021, http://www.icann.org/committees/security/sac021.pdf , concluded with: IP version 6 (IPv6) transport is not broadly supported by commercial firewalls. On average, less than one in three products support IPv6 transport and security features. Support among the firewall market share leaders improves this figure somewhat. Support for IPv6 transport and security services is available from commercial firewalls for all market segments, however, availability of advanced security features is lagging in SOHO and SMB segments and strongest in the LE/SP segment. Overall, relatively little support for IPv6 transport and security features exists. However, some form of traffic inspection, event logging, and IP Security (IPsecv6) are commonly available among products that support IPv6 transport and security services. Internet firewalls are the most widely employed infrastructure security technology today. With nearly two decades of deployment and evolution, firewalls are also the most mature security technology used in the Internet. They are, however, one of many security technologies commonly used by Internet-enabled and security-aware organizations to mitigate Internet attacks and threats. This survey cannot definitively answer the question, "Can an organization that uses IPv6 transport enforce a security policy at a firewall that is commensurate to a policy currently supported when IPv4 transport is used?" The survey results do suggest that an organization that adopts IPv6 today may not be able duplicate IPv4 security feature and policy support. The observations and conclusions in this report are based on collected survey results. Future studies should consider additional and deeper analyses of security technology availability for IPv6. Such analyses are best performed by certification laboratories and security assessment teams. Before attempting further testing and analysis, the community must alter the perception among technology vendors in general (and security vendors specifically) that the market is too small to justify IPv6 product development. The situation is probably better now, but I would guess there's still some distance to go. Imagine the decision process for the CIO or network architect of a medium or large company. A security policy exists and it's implemented with a collection of commercial products -- firewalls, routers, intrusion detection systems, etc. -- all configured and managed to support the company's security policy. Further imagine the both the transport and the individual devices are all capable of supporting and using IPv6. How quickly will the CIO or network architect decide that it's time to switch everyone over to IPv6? Among other things, he will likely want to make sure he can continue to implement the company's security policy. As of two years ago, he couldn't buy products that would function at the same level. IPv6 is definitely necessary and we should all do everything we can to move in that direction. I'm just noting that even when IPv6 is widely available and in broad use, there will be a long tail before IPv4 fades from the scene. Steve On Sep 17, 2009, at 2:36 AM, Olivier MJ Crepin-Leblond wrote: "Steve Crocker" <steve@xxxxxxxxxxxx> wrote: We're some distance away from deprecating IPv4. Maybe 20 years, maybe 50 years. For a very long time, IPv6 and IPv4 will co-exist. I know you wrote those figures to be provocative, Steve. :-) I mean, 50 years? That's like saying "computers will still run on valves in 50 years' time" in 1950. Of course this is a matter of appreciation, and frankly, does it really matter how long IPv4 will be around? Let's worry at the future, not the past. Kindest regards, Olivier -- Olivier MJ Crépin-Leblond, PhD http://www.gih.com/ocl.html _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf