Re: [v6ops] A good example of why we need to careful about ULAs

[Owen DeLong <[e-mail]>]

Sent from my iPad

On May 30, 2013, at 4:11 AM, Mark Smith <[e-mail]> wrote:

>> ________________________________
>> From: Lorenzo Colitti <[e-mail]>
>> To: "[e-mail] WG" <[e-mail]> 
>> Cc: "[e-mail]" <[e-mail]> 
>> Sent: Thursday, 30 May 2013 4:41 PM
>> Subject: [v6ops] A good example of why we need to careful about ULAs
>> 
>> 
>> 
>> News at 11:
>> 
>> 
>> 1. ULAs leak.
>> 
>> 2. People assign ULAs by hand.
>> 
> 
> In the early news, not really a new problem.
> 
> RFC1918 and 100.64/10 leak too, and what is worse, I've seen people intentionally expose RFC1918s to other networks - the largest carrier here in .au uses RFC1918 addresses for their wholesale ADSL L2TP LACs (from memory, at least 20 to 30, spread across multiple /16s within 172.16/12) and then expect their many wholesale ADSL customers' to just accept those addresses and make them work within their own networks, despite their own, quite legitimate internal use of 172.16/12 (fortunately VRFs/VPNs can be used to isolate that address space from your own). So we can't pretend that RFC1918s have been perfectly used, and therefore ULAs being less private than intended is going to be new problem and experience. At least properly formed ULAs are unlikely to conflict with other network's ones, even if the other network has used fd00::/8, and if the two interconnecting parties have both been lazy and used fd00::/8, they'll both be victims of theirs and the other

Actually, as I understand it, part of the reason for making ULA different from RFC-1918 and wasting such a large amount of address space on said boondoggle was to address exactly the situation you describe and allow said telecom to have IPv6 addresses that didn't conflict with their wholesale customers. Thus, while the above scenario is problematic in RFC-1918 IPv4 land, it's supposed to be one of the intended uses of ULA as I understand it.

Of course, GUA avoids these issues altogether, but apparently that's not good enough for reasons passing understanding.

> party's laziness (which they'll be used to, since they've probably experienced it with RFC1918). They'll probably resort to NPTv6 to fix it, because that is what they're used to, rather than using IPv6's address aging mechanisms to renumber to a properly formed ULA. Good luck to them, as long as it doesn't effect the rest of us.

Ah, but eventually, it will.

Owen

> 
> 
>> 
> 
>> Yes, both of these a violation of IETF guidance. I don't think that matters much, though - while we can always claim that the implementer/operator is "holding it wrong", we should be careful that what we design/standardize is hard to misconfigure and possibly robust in the face of misconfiguration. Subtle nuances like "these addresses are global scope, but not globally routable" tend to get lost very easily.
>> 
> 
> I think recommending against ULAs is just going to result in people stealing other address spaces for devices that don't need global reachability - like 2001:db8::/32, or unused global address space (as we saw with 1/8, 5/8 and other IPv4 prefixes).

I don't think it was recommending against the use of RFC-1918 that led to the above hijackings.

> I think global address space comes with and implies a default assumption of global reachability, and you'll therefore have to actively take measures to ensure they don't provide global reachability if you don't want it. Link-locals don't cut it because they're not routable. The need ULAs fulfils is the gap in between global space and link-locals, and the one which RFC1918 generally fulfils in IPv4, except that the likelyhood of address space collision is reduced.

99.99+% of RFC-1918 is to provide for GUA conservation through overloaded NAT.

That being not only unnecessary, but very undesirable in IPv6...

As to a "default assumption of global reachability", this is a very harmful and very incorrect assumption. IPv6 GUA provides for global uniqueness. It may or may not be globally routable and even if routed may or may not be reachable.

> So is this draft aiming for BCP status and therefore should only reflect best common practice? If not, I think it is reasonable to present scenarios where ULAs could be useful. We've got a lot of experience with private address spaces from IPv4 (the Deprecating Site Local Addresses RFC3879 is also a pretty complete list of the problems with RFC1918 addresses), so the only real difference is scenarios where concurrent global and private address spaces could be useful. In some cases, they'll just be more capable versions of what we've already doing in IPv4 e.g. private addressed loopbacks on routers, global addresses on the links, in a ULA environment you would add ULAs to the links too, which could make troubleshooting and other OAM less dependent on the global address space.

You say that as if dependency on the global address space is a bad thing.

IMNSHO, dependency on non-global addresses is where things get unnecessarily complicated.

Owen