[arin-ppml] ULA-C

[Owen DeLong]

On Apr 13, 2010, at 6:26 AM, William Herrin wrote:

> On Tue, Apr 13, 2010 at 1:14 AM, Owen DeLong <owen at delong.com> wrote:
>> This is where we differ most strongly.  I'm really tired of the <pick your
>> noun> that GUA == Route Announcement or that route announcements are
>> somehow evil or should be avoided by the RIR.
>> 
>> 1.      Not all uses for GUA will end up in the DFZ.
>> 2.      It's not ARIN's place to judge who is worthy or set the criteria by
>>        which others decide who is worthy of entries in the DFZ. That is
>>        best left for people who run actual routers.
> 
> Owen,
> 
> If you can get the netops to sign off on eliminating things like the
> multihomed criteria and the the minimum host count criteria which for
> IPv6 /48's serve solely to  suppress the public route count, I'll
> stand in support. I think that's a fantasy but more power to you.
> 
I think we'll eventually get [back] there. It's definitely worth the effort.

> 
>> So, having said that, I think that ULA should have a little bit stronger
>> criteria than grab-and-go without planning anything. I think that GUA
>> should also have a little bit stronger criteria than that.
> 
> This is where your position is unreasonable and self-serving. ULA is
> private IP addresses, the successor in spirit to the no-rules RFC1918.
> Of course it has to be grab and go. Self-serving because the real
> reason you don't want it to be grab and go is that would mess with
> your idea of unifying it with the GUA policy which would be difficult
> to responsibly architect as grab and go.
> 
I'm not sure how you see this as self-serving. The reason I think it must
be unified is because if it is not unified, ULA-C will NOT be a successor
to RFC-1918, it will become de facto GUA without the community's
GUA policies. This isn't because it's what is best for me, it's because I
believe it is necessary for the benefit of the community as a whole.

ULA-R is the successor to RFC-1918, and, even it does not have as
much protection from "GUA-Creep" for lack of a better term as RFC-1918
did. This is the advantage and the curse of the much larger address
space. Collisions are so much less likely that there is enough uniqueness
to represent a risk that these addresses may be used as a substitute for
GUA. That would negatively impact the community in two ways:

1.	It would make ULA meaningless to those that want it as an
	address space regarded by the community as un-routable on
	the "global internet".

2.	It would make GUA policies far less effective or meaningful
	as ULA becomes an end-run for those policies.

> Make your case for making RFC1918 more difficult to get than it is if
> you want, but please get on the same page as the rest of us in
> understanding that ULA is IPv6's RFC1918 with a nearly identical use
> profile regardless of whether a registry is involved.
> 
I agree with you about the community's intended use of RFC-1918 and
ULA. If I did not, I would probably be opposed to ULA in general rather
than specifically opposed to a ULA policy that invites abuse.

However, intended use and unintended consequences both need to
be evaluated. A non-unified policy for ULA/GUA will lead to abuse of
ULA as an end-run for GUA which is, in my opinion, an unacceptable
risk.

> 
> 
>>> Of course if you'd rather, we can simply build up the ULA registry at
>>> http://www.sixxs.net/tools/grh/ula/list/
>>> 
>> Have fun with that.  Personally, I think that project is short-sighted and
>> harmful, but, as I've said, there's nothing ARIN can do about people who
>> want to run competing registries.
> 
> It has 25% as many ULA registrations as IPv6 GUA announcements on the
> public Internet and is growing as fast or faster than IPv6 is. Barring
> someone else stepping forward to do a proper job (i.e. the RIRs) it's
> on track to hit critical mass around the same time as IPv6 over all.
> 
Your statement here is mathematically inconsistent with itself.

Be that as it may, even if this registry hits critical mass, it's much less likely
that ISPs might consider advertising routes based on this registry than based
on data in an RIR. In any case, there's not much ARIN can do about it.
Would I rather the SIXXS registry didn't exist? Probably.  Do I think that it has
the potential to become a disservice to the community for the exact
reasons I have mentioned above? Yes.

Nonetheless, I agree that it is out of scope for ARIN policy and I do believe
that anyone has the right to build any list of integers they want.  Integers
are not property, you can't own numbers.

> It doesn't do a great job meeting the need we're discussing, but it
> does meet that need, something at which the notions you've suggested
> still fall short.
> 
As I said, enjoy. I have no problem with you registering whatever you want
in other registries. I do not want to see ARIN create opportunities to
evade ARIN policies inside other ARIN policies. ULA as you want to see ARIN
register it would do exactly that.

Owen