Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon?

[Owen DeLong <[e-mail]>]

>> 
>> I’m all for providing a lower cost alternative to having a legitimate registry
>> for addresses for smaller users.
>> 
> 
> Zero cost is what is needed.

I think a nominal fee (say US$25/year) wouldn’t represent a significant barrier.

> 
> You can only charge money for magic numbers because of the magic, not
> the numbers. The numbers themselves are free, because anybody can make
> them up.
> 
> The magic you're buying or renting when you get RIR space is:
> 
> - actively managed global uniqueness (although not absolutely
> guaranteed, because of the human error factor)

To the best of my knowledge there are all of 3 instances of non-uniqueness
temporarily resulting from such errors in all of internet history and all in IPv4
or ASNs.

> - implicit acceptance of routes for that space by networks that carry
> the DFZ route table

Really? I don’t think so.

> The first property is really a requirement and necessity demanded by
> the second one.

Certainly the second cannot function with the first, yes, but the first
property is oh so desirable for so many other reasons.

> If people don't need the magic of implicit acceptance in the DFZ, why
> should they have to pay for it? That is the unnecessary tax or cost on
> enabling IPv6 that you're creating by saying people should be required
> to use RIR space, even if they have no intention of having the
> corresponding local address space routes in the DFZ.

If it isn’t connecting to the global internet than it doesn’t matter what numbers
you make up or whether they are unique or how you go about making them
up. It’s not stealing space, it’s just using random numbers that aren’t actually
internet addresses because you happen to be running the same protocol on
your disconnected network as most networks run on the internet.

> If people later need the magic of implicit acceptance in the DFZ, they
> can get PA or PI, and most importantly add it to their existing ULA
> addressed network.

With all the attendant problems that have been repeatedly discussed.

> Renumbering is not required to add PA/PI, and that is where IPv6
> provides a much better alternative than IPv4 - IPv4 demanded an
> exclusive or between PA/PI address space and RFC1918s, and RFC1918s
> were perceived to be cheaper and easier for a variety of reasons,
> including because a 'magic translation box' could be used between
> RFC1918s and PA/PI needed to reach the Internet.

I can put an RFC1918 address and a GUA IPv4 address on the same
interface on any modern host as well. This is no different from IPv6.

There is no meaningful difference in this regard. ULA is just RFC1918
with more addresses available for stupid host tricks.

> In other words, in IPv4 we're forced into serial address spaces, where
> as in IPv6 we have the opportunity for multiple parallel ones.

This statement is not reality on any modern system.

>>> Humans don't incur costs on themselves unless they see or perceive
>>> some equivalent benefit. Making something available for "free", in
>>> this case a local yet globally unique network address space,
>>> significantly lowers the barrier to IPv6 adoption. If you've bought
>>> the equipment to build your network, and it comes IPv6 enabled for
>>> "free", you can then immediately build an IPv6 network using ULA
>>> spa
> 
>> Except that ULA isn’t globally unique, it’s just “probably unique” for various
>> relatively high values of “probably” depending on how you go about choosing
>> your ULA prefix. Were ULA globally unique, you’d have the double edge sword
>> of:
>> 
>>        1.      It’s good because it’s free PI address space.
> 
> It isn't "free PI address space", because it doesn't have the magic
> that real PI address space has - implicit acceptance by all carriers
> of the DFZ route table.

Neither does real PI space. This is a figment of your imagination.

> The only similar properties between PI and ULAs are the
> (statistical/managed) global uniqueness.

Not at all true…

In fact, those are arguably the only differences.

They are both prefixes of 128 bit numbers, usually in /48 chunks.
They are both intended for numbering interfaces on devices running the IPv6 protocol.
They are both capable of being forward by routers.
Both can be described and routes distributed via OSPFv3, ISIS, and BGPv4.

The only real difference between ULA and PI is the convention of not routing
ULA across borders where administrators choose to enforce and/or abide by
said convention and the fact that anyone can make up whatever ULA address
they want, where there is an expectation that PI is coordinated through an RIR,
though there is enough history of hijacking in IPv4 prefixes that I see no reason
to believe this will not occur with IPv6.

>>        2.      It’s bad because it’s a free end-run around the RIR policy processes.
> 
> Not if you can't successfully get it globally routed.

I assert that this is simply a matter of the right number of “wombats” placed
in the right pockets. (To use a term coined by Jan Zorz).

> Here's the challenge for you. Show us how easy it is for you to get a
> ULA of your choosing permanently accepted in all ASes who accept the
> DFZ route table, at a cost and effort that is lower than using RIR PI
> space instead.

The cost for the first people to do it will be extraordinarily high. As it becomes
more common practice, the price will drop.

>>> If at a later date a ULA addressed network connects to the Internet
>>> they would add PA or PI space to be able to access external
>>> destinations, because IPv6 is designed to fully support parallel
>>> address spaces (i.e., so having ULAs on your network doesn't
>>> automatically imply using NAT66).
>> 
>> Except for all the problems previously noted in such installations with various
>> issues around source address selection, etc.
>> 
> 
> I've been running ULAs here at home more than 4 years, both with 6to4
> IPv6 connectivity, and for the last 4 years native connectivity. I
> haven't seen any issues, or if there have been any, they've been
> overcome transparently via such things as Happy Eyeballs. (with the
> caveat that all my hosts are fundamentally Linux, although various
> distros - Fedora, Android, Chromecast and Chrome OS.)

As has been repeatedly pointed out to you, the use in your home does not
constitute a comprehensive study of all possible or even all likely environments.
I have had multiple issues with source address selection in IPv6 in my environment,
especially on Apple equipment, even without using ULA. ULA would only make
the problem 10x worse.

> More recently, anybody who has been running IPv6 on OpenWRT since
> BarrierBreaker 14.07, released on 30th of September 2014, has had an
> ULA prefix automatically generated and announced to hosts on the LAN
> interfaces. Via a few Internet searches, I can't find any reports of
> issues relating to OpenWRT and automatic ULAs in the last 2 years.

I briefly had a router that did that to my network. That option was quickly turned
off to resolve the myriad problems it created. Subsequently, that router was
abandoned in favor of a router I didn’t have to keep beating about the head
and shoulders to prevent it from damaging the network in unexpected ways.

Owen