[arin-ppml] Opposed to 2010-9 and 2010-12

Joe Maimon jmaimon at chl.com
Thu Oct 7 16:00:17 EDT 2010


In my most generous moods, to the point where in the existing /3, there 
would be enough allocations/assignments of that size/scale for every 
single ISP/end user that has ever existed or will ever exist in the next 
50 years that will meet their needs for at least a decade, without 
having to go brownfield.

I think thats a fairly low expectation from an address space large 
enough to number molecules.

I doubt these numbers cant be predicted with any degree of accuracy to 
any near degree of specificity. Thus, the only safe course is one that 
overestimates in the orders of magnitudes.

There is only 13 bits (8192) available for 6rd deployments storing their 
datasets into 32 bits of the space and planning on giving all their 
users /48 for 65K /64 subnets,  as per current guidance, with the 
default starting point of /32 ISP allocations.

All those deploying 6RD are not likely to be using the above math and I 
see no reason to open the door to it. Something has got to give.


Scott Leibrand wrote:
> Where would you put the concrete tent-flap camelwall? /24?
> Scott
> On Oct 7, 2010, at 3:05 PM, Joe Maimon<jmaimon at chl.com>  wrote:
>> I am opposed to both proposals because the camel creeping from right to left of the bitspace is really starting to concern me.
>> Transition space for 6rd can in theory justify a /16 allocation if you are doing /48 per customer.
>> Joe
>> _______________________________________________
>> 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.

More information about the ARIN-PPML mailing list