[arin-ppml] Large hole in IPv6 assignment logic
stephen at sprunk.org
Mon Jun 8 19:51:39 EDT 2009
Dave Temkin wrote:
> I'm going to attempt to keep this brief, but here goes:
> Recently, I received a /48. After beginning our rollout, I quickly
> discovered that we'd need a /44 at the very least. See, I have
> multiple networks that are not interconnected by a common backbone,
> and so a single /48 would leave me with a useless routing domain given
> that most people prefix filter at le /48.
That's an understandable and very specific problem. Thanks!
> Currently, each OrgID is entitled to only one /48.
An org is entitled to one /48 _without justification_, and there is a
specific rule on what constitutes justification for more. According to
ARIN's stats, several blocks from /47 to /40 have been assigned, so it
is indeed possible:
> Under IPv4, if you operate separate, disparate networks you're allowed
> to request multiple blocks under the Multiple Discrete Networks
> policy. No such policy exists for IPv6, however it's been proposed
> here: https://www.arin.net/policy/nrpm.html#six583
I think you mean:
> I'd love to hear suggestions on workarounds until such the proposed
> policy would be voted on and implemented. PA addressing is not a
> viable option.
I can't think of any workarounds if you do not meet the existing policy
requirements in 22.214.171.124.
> If we expect IPv6 adoption to have a significant uptick we need to
> take away silly barriers to addressing such as this and make address
> assignments accessible for the common ASP or Enterprise - and right
> now it's definitely not.
Many of us are working towards exactly that goal, but we need to know
what the barriers are to legitimate assignments/allocations and how we
can address them without simply opening the floodgates to _everyone_
getting a block -- and a routing slot in the DFZ.
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3241 bytes
Desc: S/MIME Cryptographic Signature
More information about the ARIN-PPML