[arin-ppml] ARIN-2011-5: Shared Transition Space for IPv4 Address Extension - Last Call

[Joe Maimon]

Owen DeLong wrote:
>
> I'm telling you that they probably would not request additional justifiable resources from ARIN for
> the NAT444 purpose and that this policy will allow them to delay their need to deploy NAT444
> to their customers. I think both of those things are a good thing.
>
>    
How is the NAT444 purpose any different than the turning up new 
customers just like we have always done purpose?

In both cases the addresses are to be used to address customers. How 
would that not be justified?
>
> That's a complete fallacy of the situation.
>
> The question really is do operators need to submit additional requests specifically for pools to handle
> this purpose or not. Of course their normal needs for addresses for other purposes will remain whether
> or not this policy is adopted.
>    

Its the same purpose. Its the same DHCP pools.

>    
>> The /10 this proposal aims to remove from the community forever will only come to play when comparable resources are unavailable to anyone from anywhere else. And then it will serve only these large orgs interests and none other.
>>
>>      
> Actually, about 75% of the providers that have approached me saying they really need this are small
> to medium sized ISPs. True, they could get by with less than a /10, but, consider also this fact...
>    

The argument that rfc1918 has too high a cost of conflict resolution has 
even less weight to it when all an org needs to resolve this is less 
than /10 of non-conflicting space, considering the /8 /12 and /16 
already there for the purpose.

> The /10 issued as unique unicast could serve only 1,024 organizations that need a /20 (a fairly small ISP).
>    

A fairly small ISP can leverage a /20 for thousands of customers in a 
NAT444 environment. And letting them get started with ARIN resources 
prevents pay2play from. Instead, it is pay to expand, which is a 
different ball of wax. Plus, reclaimed resources being prioritized for 
that purpose could allow for minimal resources available to new entrants 
well past the point of peak Ipv4 demand.

> This would be additional need that they
>    

This is the crux of our disagreement. You call it additional need. I do 
not understand how it is any different then the need they have now, 
which allows them to continue justifying and obtaining more resources.

> would submit over and above their normal request rate which would accelerate runout for everyone else,
> including those small providers you claim you are attempting to save from this action.
>
>    
>> I suppose I would horse trade support for a proposal like this for a proposal that would take a /10 out for those who will truly get shafted after ARIN exhaustion.
>>
>>      
> If you can explain how that would help, I wouldn't necessarily be opposed, but, I think pretty much everyone
> gets shafted when ARIN runs out, so, I'm not sure how a /10 set aside for everyone changes anything.
>    

A /10 set aside for new organizations with no Direct Allocations. I 
proposed this earlier and got no support, nothing has caused me to 
believe anything is any different now. I will be Don Quixote standing by 
if anyone else wants to introduce it.

>    
>> It wont be those orgs who collectively received 80% of ARIN resources.
>>
>>      
> Let's be realistic here... Those orgs also collectively serve 80% of the customers in the region.
>    

And an increase of 50% efficiency with their existing resources will 
allow them to serve the remaining, with ease.

>    
>> Let us all sit by while the new G8 emerges to control address availability in the North America region.
>>
>>      
> I'll pass on the conspiracy theories. I think I have a pretty strong track record for defending the interests
> of the smaller providers in the region.
>    

Why is this a conspiracy? I believe this is the most likely outcome, 
probably no matter what we try and do here, but at least we should try.

>    
>> That will make the v6 root canal without novocain people happy.
>>
>>      
> Again, I'm not sure what you're attempting to say here. IPv6 is not that painful. IPv6 sooner is less
> painful than IPv6 later.
>
> Owen
>    

That was a dig at the folk (not necessarily you) who seem to think that 
the faster ipv4 unique integers are destroyed or become unavailable, the 
better for ipv6 which is good for everyone, no matter how painful the 
transition may or may not be.

Joe