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

[Owen DeLong]

On Mar 18, 2010, at 4:44 PM, Matthew Petach wrote:

> 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?

I'm open to either mechanism of implementation.

My concern is that RFC-4193 (ULA-RANDOM) has drawbacks in that it
is merely statistically unique and not reliably unique. The process for
determining your proper RFC-4193 addresses is complex enough that
I suspect a high percentage of sites will approach it like RFC-1918 and
choose the first available, last available, or, some other convenient
to remember prefix. That sparse pseudo-random allocations will
be far less common than envisioned by the RFC.

Certainly, my opinion is that it makes more sense to supplant the
deprecated (but possibly getting resurrected again) ULA-Central
in favor of my proposal, but, I am not sure whether it should apply
to ULA-Random. I think ULA random should either be deprecated
entirely, or, left to rot as the morass that it may well be already.

My key point is that if we stop assuming that RIR-issuance = 
routing table slot and provide for corespondingly more liberal
policy at the RIR level, we can maintain good RIR stewardship
of the address space while serving a much broader user
community and removing the desire to create end-runs on
RIR justification policies.  The temptation to do an end-run
comes from policies that are perceived as unnecessarily
restrictive. To the extent possible, we should not be
restrictive in our policies. My proposal allows us to be quite
a bit less restrictive and support non-routed and routed
addresses with common allocation/assignment policy.

I'm not religious about what effect or relationship this action
has on or to ULA.

Owen