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

Owen DeLong owen at delong.com
Tue Apr 22 17:28:23 EDT 2008


On Apr 22, 2008, at 2:17 PM, Matthew Pounsett wrote:

>
> On 20-Apr-2008, at 17:33 , Tom Vest wrote:
>
>>> I don't think there has been a land grab: hence my use of "if".  I
>>> think that IP addresses have, for the most part, been assigned
>>> fairly and equitably based on the conditions and understanding at
>>> the time they were given out.
>>
>> I agree entirely. However, I also believe that resource transfer
>> proposals as currently defined would represent a fundamental and
>> irreversible break from this policy/practice/outcome.
>
> Considering that "fair and equitable distribution" is what we think  
> we have now with justification requirements, and considering that  
> these requirements for justification are maintained in 2008-2, I'm  
> not sure I understand how it is a fundamental break from fair and  
> equitable distribution.  Could you expand on that?
>
Well, at least to one extent, instead of being the combination of  
justification
and first-come first-serve, it now becomes highest-bidding justified  
user,
which, could place organizations with fewer financial resources at a  
clear
disadvantage vs. organizations with greater financial resources.

>> Whose demands for redistribution rise to the level of "requirements"
>> -- aspiring sellers or would-be buyers? Incumbent buyers or new  
>> entrant buyers -- i.e., the current and future "customers" that don't
>> participate in ARIN deliberations (yet)?
>
> 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.
>
This could argue for the possibility of reserving the last /8 or two  
for "transitional
addressing" allocations/assignments rather than handing them out as  
business
as usual. (A /8 makes quite a few /28 or /29 assignments for this  
purpose vs.
a few months of business as usual).

> 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.
>
The solutions for reaching the v4 internet from v6 only clients are  
starting
to mature fairly rapidly.  The bigger issue, certainly, is how to make  
it possible
to build a v6-only site that is reachable from v4-only clients.  I  
think there is
room for community effort and out reach as I think that eyeball  
providers are
going to need to address this with something akin to NAT-PT Proxies with
DNS voodoo.  If the majority of ISPs with v4 clients can provide this  
service
transparently to their users, I think that goes a long way towards  
solving this.

> 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.   
> 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.
>
This assumes that the migration will begin sooner and/or move faster  
than I think
the facts at hand suggest is likely.  As such, I think we might need a  
solution
other than incentives and some form of reservation for this purpose  
might be
necessary.

Owen




More information about the ARIN-PPML mailing list