[arin-ppml] early experimenter /32 catch-22
On Thu, Oct 7, 2010 at 3:51 PM, Gary Giesen <ggiesen at akn.ca> wrote:
> I'm hoping that with sparse allocation ARIN would just be able to grow
> their existing block.
oh look, I started my v6 rollout on my wired network, I have 20
customers deployed, uptake is kinda slow. oh well, still good though!
'exec' - "Hey chris, build me a wireless network eh? you know, like
one that enables rural folk access to this interwebs and the dancing
baby videos? Yea, I get that you may need to buy transit for this
network, that you may need to have wireless backhaul links, etc...
just get it done we have customers to service!"
me - "ok, well... I don't want the new wireless network with lower
speed core interfaces and less transit to provide transit to my
existing v6 customers on this here fancy 1gbps customer-link
deployment. I'll have to get a new netblock and not re-use the
existing /32... oh, but I can't."
replace 'wireless network' with '6rd' or 'network with a
new/different/other routing domain/requirements'
(you can't guarantee longer prefixes than a /32 get global
reachability... so subnetting the current allocation isn't feasible)
> On 10-10-07 3:47 PM, "Christopher Morrow" <christopher.morrow at gmail.com>
>>On Thu, Oct 7, 2010 at 3:27 PM, Andrew Dul - andrew.dul
>><andrew.dul at quark.net> wrote:
>>> We told people to go out and get a /32 to get some experience with IPv6,
>>> so a lot of people went out and were allocated /32s. Now that we are
>>> actually getting ready to deploy production networks a number of the
>>> providers need to get larger blocks to address their networks even
>>> they haven't used up their current /32.
>>or another allocation for a distinct routing domain
>>or another allocation for a new technology deployment
>>> Seems like we need a simple policy that will either allow an ISP to
>>> the /32 in exchange for a larger block or get an additional larger block
>>> that they can renumber into.
>>yes, to the second part. (I think)
>>> This "production" block should be justified based upon current customer
>>> count, an expected growth rate over the next 5-10 years, and the
>>> network topology assuming some regional aggregation for large networks.
>>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.