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

[Mark Smith <[e-mail]>]

On 14 Nov 2015 14:19, "Owen DeLong" <[e-mail]> wrote:
>
> >>
> >> 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.
>

It's $25 p.a. that can't be spent on something else.

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

Why not?

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

I agree, which is why I think ULAs are much better than site-locals.

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

Can you enumerate them for me please?


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

*You* can put two addresses on a interface. DHCPv4 can't, and the
protocol stack treats the addresses/subnets as though they were
assigned to different interfaces/links.


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

See above.

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

"Implicit" is a form of the word "implied". Implied doesn't guarantee
they will be accepted by all networks carrying DFZs. It means of all
of the IPv6 address space, PI is most likely to be accepted by
networks carrying DFZ, because most people who carry DFZ routes have a
default accept policy, and only drop a small subset of routes (their
own PI/PA etc.)


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

And it would be a terrible way to spend your "wombats".


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

Right. That creates a massive incentive to use the much cheaper RIR PI
space to more easily and quickly achieve the same goal.

> 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 never claimed it was.

It is operational experience with ULAs in one type of environment, and
it is a piece of empirical evidence that seems to disprove your
assertions that ULAs will only cause trouble.


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

"your home does not constitute a comprehensive study of all possible
or even all likely environments."



> Owen
>