Steve Crocker wrote: > Tony, > > Thanks for your comments. I guess I don't understand the nominal > criteria for declaring something to be historic. I assumed it was > when it was no longer in common use, but I gather from your comments > and others that it's sometimes used as a leading edge, i.e. to lead > people toward tapering off the usage. I have no expectation that anything the IETF says will in any way impact usage. What I would hope is that we can stop wasting IESG time on new warts to keep IPv4 running, when it should be clear that just creates a bigger mess to clean up, besides being more expensive than just moving on. > > Re the metrics and milestones I listed, even though I used a lettered > sequence, I did not mean to imply they had to happen in that order. > Each could have its own date, and the dates might not be strictly > increasing. > > Nor would I insist on those specific metrics, even though they seem > good to me. They are certainly the metrics I frequently get asked about, along with 'how much IPv6 traffic is there?', but people are fundamentally resistant to change, and readily take the position of 'I will wait until metric X has been passed before starting'. We have been stuck in that mode for 10 years, and the only way to get out is for people to recognize that the change is imminent and inevitable so they will stop waiting for others to go first. > > The main point I wanted to make is that bringing IPv6 into full use > and advancing the associated specifications along the standards track > did not, at least for me, imply deprecating IPv4 standards. I agree those are separable events, and the only reason they have come together in time is that the IPv6 to full standard event has been delayed to the end of useful IPv4. > In > practice, the two technologies are going to co-exist for quite a > while. At the edge absolutely... In the core, economics would argue otherwise. > Today, one can pretty much count on IPv4 connectivity around > the world, and one can also count on being to reach almost any service > (Google, Amazon, CNN, etc.) via IPv4. What's the estimated date when > those two statements stop being true? Well depending on how you define 'reach a service', it stopped being true when 1918 was published, and has only gotten worse over time. As a simple example, at a hotel in Sydney I was unable to get to the IPv4 address for the IPv6-over-IPv4 tunnel service because the hotel was blocking UDP for one mode, and I was only being offered a private IPv4 address which prevented the other mode. Yes I could get to cnn.com over IPv4, but as I told the help desk when they said I didn't need IPv6; "I get my email via IPv6, and preventing access to specific IPv4 services while actively avoiding IPv6 deployment is a denial of service attack by the ISP". When will the major content providers stop offering IPv4 access? As soon as the traffic level drops below the nominal value relative to the cost of continuing to support it. As ISPs offer native IPv6 to their customers, OS-X, W7, current *nix will just use it and stop using IPv4 for sites that offer both. This will result in a substantial and rapid shift, so economics would argue for a relatively short timeframe where both are offered. This is not an issue of how long it will take for users to choose to move, because they should never know it happened. As soon as a AAAA shows up, the IPv4 traffic should stop from every IPv6 capable client. Native connectivity makes that service better, but should not be required as long as the ISP is not getting in the way of the tunneling functionality. > Even if you tighten the > criterion to using native IPv4 transport, i.e. not tunneled via IPv6, > I believe it will be many, many years before the general IPv4 fabric > starts showing any significant rips and tears. We can agree to disagree over this point, as it has been steadily chipped away at by nat at the edge, and will be seriously shattered as the currently-in-high-demand CarrierGradeNat devices get rolled out over the coming 12 months. Yes the core of BGP will still exist for many years to come, and I believe we will see a working routing system at > 1M entries in the DFZ, so you could declare the 'IPv4 fabric' intact, but from a 'service viability' perspective we are long past the point of no return. Tony > > Steve > > > > On Sep 17, 2009, at 6:37 PM, Tony Hain wrote: > > > 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