[arin-ppml] Opposed to 2010-9 and 2010-12
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?
> 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.
>> 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:
>> Please contact info at arin.net if you experience any issues.
More information about the ARIN-PPML