[arin-ppml] Large hole in IPv6 assignment logic

[Dave Temkin]

Stephen Sprunk wrote:
> 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:
> https://www.arin.net/knowledge/statistics/statistics.pdf
>   


Correct, and I'm not sure where the blocker is.  I highly doubt that 
anyone's fully utilized a /48 yet.

>   
>> 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:
> http://lists.arin.net/pipermail/arin-ppml/2009-March/013129.html
>   


Yes, sorry, my bad.

>   
>> 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 6.5.8.3.
>
>   
>> 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.
>   


Understood, but we need a better exception policy in place other than 
"We'll get to it at the next meeting" if we're going to foster 
development in such an evolving space.

-Dave
> S
>
>