[ppml] Policy Proposal: IPv4 Transfer Policy Proposal

Scott Leibrand sleibrand at internap.com
Wed Feb 13 13:36:25 EST 2008


Thanks for that perspective, Kevin.

Do you see a transfer policy like this one as necessary to maintain IPv4 
connectivity during the transition?  If not, how do you think ISPs like 
you will deal with the continued need for IPv4 addressing after free 
pool exhaustion?  If so, do you think that this proposed transfer policy 
strikes a good balance between providing the conditions for a liquid 
market and preventing unnecessary routing table growth and speculative 
market behavior?

Thanks,
Scott

Kevin Kargel wrote:
> Just to give some feedback FROM one the ISP's you are talking about..
> Our plan is to go dual stack as soon as ANY of our upstream providers
> can feed us dual stack.  We are already working on the enterprise dual
> stack routing, and have actually established an IPv6 tunnel connection
> (that I don't want to route real traffic over and abuse the network that
> was so kind as to let us connect).  Luckily, we use exclusively Cisco
> routing hardware, which has dual stack funtionality built in.  
>
> There is no way we will be able to go IPv6 only until ALL of the major
> content providers are IPv6 functional, and ALL of the email providers
> are compliant.  Think of how you would complain if your ISP went IPv6
> and told you that you could now email to "some" places..  or even "most"
> places.  
>
> There are a lot of things that need to be functional before IPv6 is a
> reality for ISP's..  little stuff like IPv6 RBL's, bug free IPv6 VPN
> compatibility with ALL of the major VPN hardware and software vendors,
> IPv6 connectivity for entertainment networks like Xbox Live and PS3,
> gaming sites, IM protocols, and a host of other applications that
> consumers rightfully demand.  Any one of these "trivial" services not
> working is a deal killer for an ISP converting to IPv6 only.  
>
> So whether or not it is more expensive, more work, or otherwise more
> painful, ISP's will be forced to maintain IPv4 connectivity until
> content there is obsoleted.
>
> What tends to be forgotten, is that for the little guys IPv6 will not be
> a complete solution until EVERYTHING that is available on IPv4 is also
> available on IPv6 and the use is just as transparant to the end user.  
>
> Kevin
>
>
>   
>> -----Original Message-----
>> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On 
>> Behalf Of Scott Leibrand
>> Sent: Wednesday, February 13, 2008 9:33 AM
>> To: michael.dillon at bt.com
>> Cc: ppml at arin.net
>> Subject: Re: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal
>>
>> michael.dillon at bt.com wrote:
>>     
>>>> Yes.  There is a large installed base for whom migrating to
>>>> IPv6 may be painful (expensive).  Reducing the community's total 
>>>> expense for operating their IP networks is a benefit to 
>>>>         
>> the Internet 
>>     
>>>> community.
>>>>     
>>>>         
>>> RED HERRING!
>>>
>>> Given the fact that ISPs who implement IPv6 transit service 
>>>       
>> will also 
>>     
>>> have to implement transition mechanisms such as Teredo, 6to4, etc., 
>>> there is no imperative for any part of the installed base 
>>>       
>> to migrate 
>>     
>>> to IPv6 before they are ready.
>>>
>>> The imperative today is for those organizations with 
>>>       
>> steadily growing 
>>     
>>> networks at the heart of their business model (ISPs) to begin 
>>> transitioning. Whether it is painful or not, they must do it or die 
>>> because network growth is fundamental to their being.
>>>   
>>>       
>> I think you make an unjustified assumption that ISPs will be 
>> able to deploy IPv6-only service to new customers and operate 
>> transition mechanisms such as Teredo, 6to4, etc.
>>
>> An alternative, and IMO more likely, transition mechanism is 
>> to use two much more familiar technologies: dual stack and 
>> NAT.  Many consumer ISPs will be able to start providing IPv6 
>> support, provide the ability for their customers to 
>> dual-stack, and then start providing NAT'd RFC1918 addresses 
>> to their DHCP customers instead of public IPs.  This will be 
>> fairly easy for some ISPs, and more difficult for others 
>> (such as business ISPs, with more static-IP customers and 
>> smaller DHCP pools).  
>> In addition, there will be a great diversity of IPv6 support 
>> in middleboxes (home routers, enterprise firewalls, etc.)
>>
>> Given this diversity in cost of migrating to IPv6 
>> (dual-stack) and reducing IPv4 demand, there is an 
>> opportunity to allow organizations for whom the migration 
>> cost is higher to delay migration until IPv6 technology is 
>> better developed/deployed, and in the mean time get IPv4 
>> addresses from other organizations for whom the migration 
>> cost is lower.  Additionally, such a transfer policy would 
>> provide an incentive to encourage organizations to migrate 
>> their installed base to some form of IPv6 where it's easier 
>> to do so, rather than requiring growing networks to do so if 
>> it's more expensive for them.
>>
>>     
>>> If an ISP decided to try and avoid implementing IPv6 by getting
>>> IPv4 addresses from other sources, they are simply backing 
>>>       
>> themselves 
>>     
>>> into a corner and relying on their competitors to operate 
>>>       
>> transition 
>>     
>>> mechanisms for them. This is a risky strategy since the 
>>>       
>> market segment 
>>     
>>> who are willing to buy IPv4 network access will be steadily 
>>>       
>> shrinking. 
>>     
>>> In addition, their existing customers will begin to move 
>>>       
>> away because 
>>     
>>> the ISP is perceived as being incompetent and at risk of hitting a 
>>> brick wall.
>>>   
>>>       
>> I suspect that after ARIN free pool exhaustion, all ISPs will 
>> offer some form of IPv6 service.  To do so successfully, and 
>> support dual-stack, however, there will be a continued need 
>> for IPv4 addresses.  In some cases, a network may be able to 
>> free up enough IPv4 addresses to allow them to transfer them 
>> to other organizations.  In other cases, they'll be able to 
>> free up some, but not all, of their existing IPv4 addresses 
>> and use the remainder for growth.  In other cases, growth may 
>> overtake the ability of a network to cost-effectively reclaim 
>> IPv4 addresses (possibly due to a small install base), so 
>> continued availability of addresses from other organizations 
>> will be essential to avoiding much higher transition costs 
>> than are necessary.
>>
>>     
>>>   
>>>       
>>>>  This policy
>>>> proposal allows organizations to choose what's best for 
>>>>         
>> them, rather 
>>     
>>>> than forcing a one-size-fits-all solution.
>>>>     
>>>>         
>>> I disagree that this policy does what you say. In fact this 
>>>       
>> policy is 
>>     
>>> trying to set up a market for buying and selling IP addresses.
>>>   
>>>       
>> I don't think we're in disagreement here.  This policy 
>> proposal allows organizations to choose what's best for them 
>> by setting up a market for transferring IP addresses.  The 
>> addresses aren't property, so no one will be buying and 
>> selling the addresses themselves, but the underlying market 
>> economics will be similar.
>>     
>>> Under current policy, an ISP who migrates infrastructure to 
>>>       
>> IPv6 can 
>>     
>>> return their IPv4 addresses to ARIN. And an ISP who is not 
>>>       
>> migrating 
>>     
>>> can continue to apply to ARIN for more IPv4 addresses and 
>>>       
>> receive the 
>>     
>>> returned ones.
>>>
>>> This is clear and simple and easy to understand. It is the way that 
>>> IPv4 allocation has always been done and is fully understood by 
>>> everybody who deals with IP networking. Any new policy like the one 
>>> proposed, simply muddies the waters and creates confusion.
>>>   
>>>       
>> Yes, it is clear and simple, but it is not sufficient.  If a 
>> network has no incentive to go to the trouble of renumbering 
>> out of IPv4 addresses, they won't return them, and there 
>> won't be enough IPv4 addresses to meet the needs of those who 
>> need more addresses.  However, if the transfer process can 
>> cover the cost of renumbering, many more organizations will 
>> choose to do so.  To put it in basic economic terms, if we 
>> fix the price of scarce IPv4 addresses at zero (by leaving 
>> policy unchanged), supply will be insufficient to meet demand 
>> after the free pool is exhausted.  
>> If we allow price to be set by a market, the price will rise 
>> to the point where it increases supply and reduces demand 
>> enough to get them into balance.
>>
>> -Scott
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to 
>> the ARIN Public Policy Mailing List (PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/ppml
>> Please contact the ARIN Member Services Help Desk at 
>> info at arin.net if you experience any issues.
>>
>>     
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to the ARIN Public Policy
> Mailing List (PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml
> Please contact the ARIN Member Services Help Desk at info at arin.net if you experience any issues.
>   



More information about the ARIN-PPML mailing list