[arin-ppml] Draft Policy 2009-1: Transfer Policy -Revisedandforwarded to the Board
George, Wes E [NTK]
Wesley.E.George at sprint.com
Fri May 8 09:57:03 EDT 2009
From: Ted Mittelstaedt [mailto:tedm at ipinc.net]
Sent: Thursday, May 07, 2009 6:16 PM
To: George, Wes E [NTK]; 'William Herrin'; 'Martin Hannigan'
Cc: 'arin ppml'
Subject: RE: [arin-ppml] Draft Policy 2009-1: Transfer Policy -Revisedandforwarded to the Board
I probably did a bit too much snipping, since you had gone on
to say that retrofitting existing devices for IPv6 wasn't
easy, I was more responding to that.
> Therefore the
> means to keep the network functional in the intervening time
> will be important.
But it will be, because all of those existing IPv4 devices aren't
going to lose their IPv4 numbering as a result of runout. It is
the NEW devices that will need to be IPv6 compliant.
Since that date is in the future, effectively what your saying
is that it's really NOT the EXISTING devices that need retrofitting
to IPv6. It is the devices you are going to assign IP to at
some date in the future - it's future, new, devices. Unless, that
is, your recycling old IPv4-only devices. And if your recycling,
what about the IPv4 numbers that used to be assigned to them,
where are they going?
yes, this probably sounds simplistic. But, that is because it
IS rather simple. We have IPv4 still available now. We know at
some date in the future it will be gone. We can simply start buying
palletloads of devices now, that are IPv6 compliant, and the
warehouse is going to empty out of the IPv4-only wigits before we
run out of IPv4.
What other way would it work?
I think the fundamental (flawed) assumption you are applying is that we already have enough space for all of the existing IPv4-only devices and therefore I'm making a problem where none exists. We do not have addresses for every single device in the network simultaneously, or even a fraction of that. We are banking on the fact that some percentage of our userbase (Grandma) is going to need an IP address either infrequently or never, and that the vast majority of active devices will be periodic users (hit google for 5 minutes then shut down), meaning that we have the ability to share IPv4 addresses among a large number of devices. However, more and more wireless use is becoming data use, and it's becoming less periodic, and that means that we keep needing more IPv4 addresses despite the fact that the installed base isn't necessarily changing much.
To your second point, this isn't really about widgets sitting in a warehouse. It's the phone already in your hand. I heard word that we had been asking vendors for IPv6 at least as a roadmap item in in mobile devices for probably 2 years, but not every vendor was able to necessarily deliver, and the ones that did may have had varying degrees of success in a complete and functional IPv6 implementation. The expectation is that attrition of old devices will partially solve this problem by creating an installed base that does support IPv6 and (hopefully) needs an IPv4 address less often if at all. But, depending on how often devices roll over, that may not reduce the IPv4-using population enough either. Even then, that only puts this particular application on a par with the rest of the PC-using population: IPv6 is supported, but is only useful if we ensure that either a) every possible destination our users might go to is IPv6-capable or b) that there is some sort of intermediate device that allows an IPv6-only device to reach IPv4-only websites.
I fully expect that there will be classes of devices that can be IPv6-only either because they only need to reach IPv6 content or because the content that they reach can be proxied through an IPv6-to-IPv4 NAT/ALG, but not all devices will fall into that category.
We're working to ensure that our internal content is v6-enabled, but the idea behind a proper IPv6 transition is that it has to be seamless to the users. If I have to explain to the average user what IPv6 is in order to explain why they can't reach a given website then I have failed.
I would absolutely rather that we have IPv6 enabled and ready to roll and IPv4 runout becomes a complete non-issue. I also know the speed at which companies the size of mine move despite my best efforts, and it would be very irresponsible of me as a representative of my company to this organization to simply assume that no contingency planning should be necessary because IPv6 is the answer. Hence my support for means to ensure that IPv4 keeps being available as long as possible - IN CASE my company (or any other company) needs it for a real and justifiable reason based on the rules at the time.
This e-mail may contain Sprint Nextel Company proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.
More information about the ARIN-PPML