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

[Owen DeLong <[e-mail]>]

> On Nov 12, 2015, at 14:53 , Mark Andrews <[e-mail]> wrote:
> 
> 
> In message <[e-mail] <mailto:[e-mail]>>, Owen DeLong write
> s:
>> 
>>> On Nov 12, 2015, at 12:08 , Mark Smith <[e-mail]> wrote:
>>> 
>>> On 13 November 2015 at 05:32, Owen DeLong <[e-mail]> wrote:
>>>> 
>>>>> On Nov 5, 2015, at 23:14 , [e-mail] wrote:
>>>>> 
>>> <snip.
>>>> 
>>>> Please explain exactly what circumstances make it too difficult for
>> any company
>>>> to acquire a /48 PI as I would consider this a brokenness in the
>> relevant RIRs
>>>> policy and would happily work to resolve the issue.
>>>> 
>>> 
>>> This was was in part what I was getting getting at when I said that
>>> abandoning ULAs would discourage adoption of IPv6.
>>> 
>>> If you're building a small network that either currently isn't and may
>>> never be attached to the Internet, you have 3 choices:
>>> 
>>> (a) apply for RIR membership and incur annual RIR costs to get a PI
>>> /48 and after some time delay, be able to build your IPv6 network
>>> 
>>> (b) use $free ULA space, and be able to build your IPv6 network right
>> now
>>> 
>>> (c) use $free RFC1918 IPv4 space, and build an IPv4 network right now
>>> 
>>> 
>>> Option (a) has financial costs and time delays that option (b)
>>> doesn't, and if option (b) doesn't exist, then option (c) is the most
>>> convenient and timely choice, unless it is essential that IPv6 is
>>> used. Option (c) being the most convenient, cost effective and timely
>>> option for if (b) isn't available will actually discourage support for
>>> IPv6.
>> 
>> (d) use whatever string of {32,48,64} bits you want and pretend its
>> an IPv6 prefix.
>> 
>> Please explain what benefit (b) offers over (d) in such a case. Youre
>> going to end up renumbering when you attach to the internet either way.
> 
> Renumbering in IPv6 is not the same as renumbering in IPv4.  In
> this case you are just adding a prefix.  You don't stop using the
> ULA addresses in (b).  For (d) you need to remove the addresses
> because you don't know what you are colliding with.

I’m well aware of this. Nonetheless, your statement is not true.

(d) if I use something like f3fe::, I can be quite certain for some time to come that
I’m not colliding with anything other than someone else who randomly chose f3fe::.

This is actually a lower likelihood of collision than I get with ULA.

True, if I chose something within 2000::/3, I know I’m likely to collide with some
unknown thing that expects their addresses to be globally unique.

Also true that at some future date, my f3fe:: address may come to collide with
some future IETF decision at which point I _MAY_ have to remove the prefix.

> Additionally we have deployed technology for nodes to update their
> addresses in the DNS which deals with most of the renumber problem.

Not sure how this is relevant, but whatever.

> A 1 page BCP which says to do what Apple and various router vendors
> have been doing for years updating the DNS should be enough to get
> the rest to do this.

Again, not sure how this is relevant to the utility (or lack thereof) for ULA.

>>> I think that if (a) was the only choice, it is in effect creating an
>>> annual tax or license fee on the use of IPv6 technology, because (in
>>> theory) you wouldn't be able to use IPv6 unless you paid an RIR and
>>> waited for them to give you your space. Of course, the other choice
>>> would be that some people would steal space to use instead to build an
>>> IPv6 network, like the documentation prefix. Absence of a local use
>>> address space encourages stealing of other address spaces if you don't
>>> have time to get a proper one or don't have the financial means or
>>> financial incentive to get some.
>> 
>> Im all for providing a lower cost alternative to having a legitimate
>> registry for addresses for smaller users.
>> 
>>> 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
>>> space.
>> 
>> Except that ULA isnt globally unique, its just probably unique for various
>> relatively high values of probably depending on how you go about choosing
>> your ULA prefix. Were ULA globally unique, youd have the double edge sword
>> of:
>> 
>> 	1.	Its good because its free PI address space.
>> 	2.	Its bad because its a free end-run around the RIR policy
>> processes.
> 
> And that matters how?  If you happen to learn a remote ULA address
> and actually use it the border router should block the packet and
> send back a ICMP administrively prohibited unreachable.  If there
> is a ULA prefix collision you still have to match the rest of the
> address which is highly unlikely.  Subnet collisions in this case
> are likely but not the full address.

Why? There are circumstances where the border router may actually intend
to exchange packets with some other person using that same ULA prefix.

ULA is just like RFC-1918 except it provides a greater illusion of utility. It still
offers all the same problems, just in a less constrained and (potentially) harder
to identify way. It does offer a greater timeline and potential for the creation
of time-bomb configurations that work at the time of installation and then break
spectacularly at some future date due to the collision of earlier decisions on two
networks that later find themselves connected in places far removed from where
those decisions were made.

>>> 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.
> 
> Which in practice does not exist.  I've run networks with ULA + PA
> locally and *never* seen a issue due to address selection.  Longest
> match takes care of that for the older machines (0010 vs 1111).
> Newer machines know about ULA so have different address match rules
> which deal with ULA address leaks.  Properly configuring the border
> routers to return ICMPv6 administrively prohibited for attempts to
> send a packet outside the site using a address from the ULA prefix
> deals with the rest.

I hate to break it to you Mark, but your relatively narrow experience does not
constitute the entire world. I have seen these problems, even in as simple a
case as GUA/SLAAC + GUA/Privacy Address.

I have seen problems getting outbound connections to select the correct source
address in a variety of scenarios and I have seen things break in significant and
interesting ways as a result.

I assure you that these problems most definitely do exist in practice in some
environments, even if yours doesn’t happen to be one of them.

Owen