[arin-ppml] Draft Policy 2009-1: Transfer Policy -Revisedandforwarded to the Board

Ted Mittelstaedt tedm at ipinc.net
Fri May 8 14:11:16 EDT 2009


 

> -----Original Message-----
> From: George, Wes E [NTK] [mailto:Wesley.E.George at sprint.com] 
> Sent: Friday, May 08, 2009 6:57 AM
> To: Ted Mittelstaedt; 'William Herrin'; 'Martin Hannigan'
> Cc: 'arin ppml'
> Subject: RE: [arin-ppml] Draft Policy 2009-1: Transfer Policy 
> -Revisedandforwarded to the Board
> 
> 
> -----Original Message-----
> 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.
> 
> <snip>
> 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?
> 
> Ted
> 
> 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.

My Sprint Motorola Q that's a few years old is IPv6

> 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 believe that is how Sprint does it with my phone.

> 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.

On my phone I have a web browser, e-mail client, SSH client,
FTP client, RSS reader.  What else do I need?  My phone does
NOT have an IPv4 number on it, this I know from digging into it.

> 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.
> 

I'm not arguing that there won't be need for IPv4 in the future.  I
am just cautioning against making it seem like the transition is
more difficult than it is.

Ted




More information about the ARIN-PPML mailing list