[arin-ppml] Draft Policy 2011-5: Shared Transition Space for IPv4 Address Extension - IAB comment

[Owen DeLong]

> 
>> RFC-1918 is also a non-starter for most of the large providers. They'll get GUA allocations before they'll use 1918 in most cases.
>>   
> That is assuming it is available. And if it is available, why wouldnt they get it? False dichotomy. They will get gua until they cant get no more and then they will use 1918 or whatever else is available.
> 

Yes, they will get GUA until they can't get more. The question is whether we make it possible to make more of that GUA available for traditional usage (better for the providers and the internet in general) or whether we force providers to each reserve some portion of the GUA they can get near runout for an intermediate NAT444 pool. In the latter case, we consume multiple different address spaces out of the global free pool for this purpose removing it from other uses. In the case of the /10 granted under this policy, we allow all ISPs to draw that space from a common pool, leaving the space outside of this single /10 available for other uses.

>>> Even if they do not find those options as attractive as this /10.
>>> 
>>>     
>> If I were to rank the options in order of attractiveness (from an ISP perspective), they would be:
>> 
>> 	2011-5
>>   
> Benefits only a specific segment of the community, ignores the needs of the rest.

That segment of the community happens to provide services to something on the order of 75% of the users of the internet, so, I wouldn't exactly say we're looking to benefit a handful of corner cases here.

>> 	Consortium-based assignment
>>   
> Has its own advantages.

And many disadvantages, not the least of which is it is unclear whether ARIN would approve such an assignment.

>> 	Community pool of GUA addresses
>>   
> Just a variation of above

Yep.

>> 	New GUA allocations or assignments from RIR (individually to various ISPs)
>>   
> Going to happen anyway

Not really.

If we do this, they may get other allocations/assignments, but, they'll get them for other purposes. If we don't do this, then, much more than a /10 may well get collectively reserved by various ISPs for this purpose and not shared. You cannot ignore the fact that this will take address space away from other usage.

>> 	Use of existing GUA space (forcing some fraction of existing customers into NAT-444 degraded services)
>>   
> Going to happen anyway

I am not convinced of this. I know of several providers that if they have this space available do not plan to take addresses away from existing customers to support their NAT444 deployment and do not plan to degrade their existing customers, instead, inflicting NAT444 only on new customers and volunteers.

Were I running an ISP where I actually wanted to keep my customers, that's certainly the approach I would take. (I work for an ISP, but, I don't run one).

>> 	Use of RFC-1918 space
>>   
> Which will work well enough with some intelligence applied.

Only if you're running a much smaller network with much larger margins than is the case for the large residential ISPs that I have discussed the matter with.

>> 	Use of 240/4
>>   
> Continuously torpedoed by self fulfilling prophets.

Studied multiple times and rejected on the basis that the amount of software that would have to be modified is roughly equivalent effort to the software modifications required to switch to IPv6 without the dividends provided by IPv6. Seems like a poor investment of time and effort to me.

Owen

>> I'm pretty sure that they'll find a way to make one of the top 4 work. Since the first 3 basically boil down to the same effect as 2011-5, I would say that it's a relatively safe bet that the dichotomy between 1-3 and 4 is a valid and accurate one.
>> 
>> Owen
>> 
>> 
>>   
> 
> Joe
> 
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.