[ppml] Policy Proposal: IPv4 Transfer Policy Proposal

[Kevin Kargel]

 Scott,
	The best plan I see now for residential ISP's is to start
putting new customers on IPv6 for local connectivity, using dual stack
translation for global connectivity. This will work for almost
everything except VPN's and residential servers (xBox, remote desktop
et.al.) ..  
	With that phase working when IPv6 DHCP is debugged we can start
migrating existing end users via Radius and PPPoE.  This should actually
be rather transparant to the customer.  
	As customer connections are the primary consumer of IP's for an
ISP, utilizing IPv6 for this will allow IP's to be reclaimed for use for
global connections.  This will greatly extend the time that an ISP can
remain IPv4 functional after exhaustion. 
	My plan at this point is to try to arrange things so I can
function no matter what changes in policy arise.   

> -----Original Message-----
> From: Scott Leibrand [mailto:sleibrand at internap.com] 
> Sent: Wednesday, February 13, 2008 12:36 PM
> To: Kevin Kargel
> Cc: ppml at arin.net
> Subject: Re: [ppml] Policy Proposal: IPv4 Transfer Policy Proposal
> 
> 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.
> >   
>