[ppml] Research on transfer markets, was: RFC 1744 and its discontents

[Ted Mittelstaedt]

> -----Original Message-----
> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On 
> Behalf Of Matthew Pounsett
> Sent: Tuesday, April 22, 2008 2:18 PM
> To: arin ppml
> Subject: Re: [ppml] Research on transfer markets,was: RFC 
> 1744 and its discontents
> 
> 
> 
> Personally, the problem with depletion that I think needs fixing is  
> the problem of the new company that comes to ARIN the day after  
> depletion looking for addresses for their new network.  Yes, 
> they are  
> in an excellent position to fire up v6 and never have to 
> worry about a  
> transition, but most of their customers will not be able to 
> reach them  
> on v6, and so they will need some way to acquire at least a small  
> number of v4 addresses to make their web site, mail servers, and  
> various other public-facing services work.
> 

So if they are multihomed they go to one of their feeds and request
a /24, then advertise it via BGP in the normal fashion.  Companies have
been doing this for years, so what?

Are you unaware that you can obtain an AS number and advertise
IP addressing that was allocated to you by your feed?  As long as
your feed SWIPS it, and as long as it is a minimum of a /24,
your fine.

I think there's some confusion by use of the term "depletion"

We are talking "RIR-depletion" we are NOT talking "IPv4-depletion"
like the entire Internet will come to a grinding halt.  There will
still be plenty of IPv4 around post RIR-depletion.  It is just not
going to be available from the RIR's.  But it will certainly be
available from many networks for many years afterwards.

The only downside is that getting it from an existng network means
if at some point in the future you decide to cancel service from
that network, you will have to give it up and renumber.

Anyone needing more IPv4 is going to only need it if they are
connected to the Internet.  Thus, the end of RIR-IPv4 availability
simply means that people now will have to get IPv4 from whomever
they are connected to.

if that ISP has no more IPv4 then they merely find another ISP.
It's not like there's any shortage of them.

> v4 will be around in some form or another for a long time.  I don't  
> think it's going to "go away" in any significant way until it's  
> cheaper to run single-stack v6 (both in terms of straight-up  
> operational costs and the ability to do whatever business 
> people need  
> to do on v6 only).  As long as v4 is around, any new player on the  
> 'net will require some v4 addresses... not necessarily a lot, 
> but some.
> 
> In order to allow new players to get the addresses they require post- 
> RIR-depletion, we need some sort of incentive for those already  
> migrating to v6 to actually free up v4 addresses where possible.   

We already have this - those existing players will have incentive to
renumber to free up IPv4 so they can sell IPv4 Internet connectivity
to these "new players"

> There will be places where networks don't need to run dual 
> stack, but  
> it will cost money to remove the need for the v4 stacks, and to  
> renumber into smaller blocks of a company's current v4 addresses.
> 
> I'm not entirely convinced that a paid transfer policy is the best  
> incentive; it seems to carry a lot of  negative baggage with it, and  
> require a lot of complex restrictions in order to maintain the fair  
> balance that (I hope) we all want.  However, so far it's the only  
> remotely viable suggestion I've seen.
> 
> > How is any new entrant ever going to be able to bypass the need to 
> > reach the universe of IPv4-addressed resources?
> 
> The context of your question suggests you think this is a reason not  
> to have this sort of transfer policy.  Let me ask you the same thing  
> though; in the absence of a policy along these lines, how will a new  
> entrant ever do business with other 
> companies/individuals/whomever in  
> the universe of IPv4-addressed resources?
> 
> I would very much like to see alternative ideas explored that would  
> address this issue.
> 

http://tools.ietf.org/wg/softwire/
http://www.join.uni-muenster.de/Dokumente/Howtos/Howto_TRT.php?lang=en

http://www.cs.washington.edu/research/networking/napt/
http://www.cs.princeton.edu/~mef/research/napt/reports/usenix98/

http://www.datatekcorp.com/literature/pdf/IEEE_IPV6_IPV4.pdf
http://www.fujitsu.com/downloads/MAG/vol40-1/paper21.pdf

Ted