[arin-ppml] ULA, GUA, NCN and the potential for abuse

[Matthew Petach]

On Thu, Mar 18, 2010 at 4:34 PM, Leo Vegoda <leo.vegoda at icann.org> wrote:
> On 18 Mar 2010, at 4:13, Matthew Petach wrote:
>
> [...]
>
>>> 3. Maintain the same qualification and assignment criteria for both
>>> groups of IPv6 unicast addresses. Do not differentiate them at
>>> the fee structure, either.
>>
>> I think this is going to be the biggest stumbling point.
>>
>> Today, there's no fee for a private organization to use
>> RFC1918 addresses internally.  If they're building
>> a massive internal test network, and use most of 10/8
>> to do it, but only need a /29 from their upstream ISP
>> for minimal external connectivity, they don't pay ARIN
>> for the ability to use 10/8 internally.
>>
>> In your model, the network would now have to pay
>> annual ARIN fees to use IPv6 addresses internally,
>> *even* if they are never using them on the global
>> internet.
>
> Assuming this proposal is accepted, they would only have to do this if they were unwilling to use a /48 from the unique local space already set aside in RFC 4193. If RFC 1918 address space is good enough in IPv4 I find it hard to understand why RFC 4193 space would not be good enough in IPv6. RFC 4193 is far, far less likely to suffer from any address clash problems and is very unlikely to ever be routed across the Internet.
>

Unless I misunderstood Owen's opening paragraphs, it sounded
to me as though he's putting this grand unified address allocation
idea forth in order to incorporate all v6 allocations, including the
ULA addresses mentioned in RFC4193.

> I can't help but think that the number of people who use RFC 1918 space now instead of requesting unique addresses but would not be happy with RFC 4193 for a similar private network is going to be quite small. While such cases might exist, people with special needs generally understand that their needs are special and understand what that means. If it means paying a registration fee of some kind then presumably that would be acceptable to most people if it gave them the guarantee they were after.
>

If this is *not* subsuming RFC4193, but would be a parallel
track as an alternative to RFC4193 addresses, then yes, I
quite agree.

Owen, can you clarify whether you intended this to be an
umbrella which also applied to unique local addresses
as defined in RFC 4193, or as a a parallel source of
addresses separate from RFC4193?

> Regards,
> Leo Vegoda

Thanks!

Matt