[arin-ppml] Set aside round deux

[Owen DeLong]

OK... A little less fuzzy analysis of the policy and it's mathematical
implications...


The acceptable use list is (desirably in my opinion) pretty limited.
I can't imagine expanding any combination of the following:

	Router Loopbacks
	NAT Gateways
	Qualifying TE entries
	Point to Point links

Adding up to a /20 or even 80% of a /20 for any established network
even over 3 years unless they are VERY large and growing rather
quickly.

As to making IPv4 addresses available for business as usual assignments
to web, NTP, DNS, and other servers that happen to be dual-stacked, I think
this is a very bad idea and provides a huge loophole in the policy. It basically
allows hosting providers and certain others to get unlimited IPv4 as usual
from this pool. Admittedly, this makes it pretty easy for smaller organizations
to get IPv4 from this pool, but, it also makes it pretty unlikely that the pool
will last much longer than any other /8 which I think is counterproductive
to the stated intent of the policy.

However, if we reserve the pool to purposes of actual transition, for example,
eliminate the business-as-usual assignments for public facing servers and
restrict it to NAT-PT-style gateways, B4/AFTR implementations, DNS64
servers and other things actually designed to provide transitional interoperation
between IPv6-only and IPv4-only systems, then, I think you'll be hard
pressed to consume that much address space unless you are a very large
provider.

Owen

On Jul 26, 2010, at 2:30 PM, Hannigan, Martin wrote:

> 
> 
> 
> On 7/26/10 5:00 PM, "Owen DeLong" <owen at delong.com> wrote:
> 
>> I did read it... A little math...
> 
> 
>> 
>> Let's assume you're trying to use this for NAT64 boxes... At an estimated
>> 5,000 customers per NAT64
>> box (most people I've talked to are talking between 8,000 and 80,000 per box),
>> to qualify for a /20
>> using a single /32 per NAT box, you need 4,096 NAT boxes or at least 80% of
>> 20,480,000
>> which works out to 16,384,000 customers in order to justify a minimum
>> allocation under this policy.
>> 
>> If you think that small providers have 16,000,000+ customers, we have
>> radically different ideas
>> of what constitutes small.
>> 
> 
> 
> That would be some very fuzzy math from my perspective. If the same network
> that only needs a /32 for a NAT device also needs a /20 to use for purposes
> defined on the acceptable use list then I think that they're in good shape.
> If a network is so small and not expecting to grow at all in $time, I'm not
> so sure why it wouldn't make sense for them to scrounge up an address or ask
> their upstream for "one" (both of which are much more likely to be routable
> at least in the early stages of transition).
> 
> Alas, I'm not really in a position to argue the min/max until I receive some
> constructive feedback, which was the main purpose of the post.
> 
> 
> Best,
> 
> -M<
>