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

[Brian E Carpenter <[e-mail]>]

On 30/05/2013 20:11, Mark Smith 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, 

In traceroutes, link-locals sometimes leak too.

All these are confusing and make the traceroute hard to interpret,
but they don't actually *matter*. What matters is if they leak in
actual traffic such as attempted TCP connections. Does that happen?

   Brian

>  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
>  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.
> 
> 
> 
>> 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 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.
> 
>> Of course, in the case of ULAs, there's not much that can be done about the design at this point, but we should make an effort to make it clear that the potential for misconfiguration exists and provide clear guidance on how not to misconfigure them.
>>
>>
> 
>> Personally, I think that providing said guidance is much more useful and important than enumerating scenarios that aren't widely, if at all, implemented, and I hope that the authors of draft-ietf-v6ops-ula-usage-recommendations will agree.
>>
> 
> 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.
> 
> Regards,
> Mark.
> 
>> Cheers,
>> Lorenzo
>>
>>
>> ---------- Forwarded message ----------
>> From: Jeroen Massar <[e-mail]>
>> Date: Thu, May 30, 2013 at 4:59 AM
>> Subject: Usage of fd00::/8 on the Interwebz - something with filters and uRPF
>> To: [e-mail]
>>
>>
>> ...
>>  4  2001:7f8:1::a500:3303:1 (2001:7f8:1::a500:3303:1)  20.755 ms  20.763 ms  20.784 ms
>>  5  fd00:3303::1 (fd00:3303::1)  22.010 ms  21.984 ms  21.986 ms
>>  6  2a02:120c:1051:d010::1 (2a02:120c:1051:d010::1)  17.806 ms  17.889 ms  17.842 ms
>>  7  2a02:120c:1051:d010::1 (2a02:120c:1051:d010::1)  18.720 ms  18.593 ms  18.617 ms
>> ...
>>
>> Hmmmm fd00::/8, that really should never ever be visible on the Internet, being Unique *LOCAL* Addresses.
>> And it does not look like they applied the randomness bit for picking a prefix either.
>> You would also almost think that a /28 is more than enough address space to put a few router loopbacks in.
>>
>> It is apparently time for people to start checking their filters again because it seems that these packets leak into other ASNs too...
>>
>> More generally, do recheck your network for BCP38 compliance, please do apply it and require your peers to do the same!
>>
>> Greets,
>>  Jeroen
>>
>>
>> _______________________________________________
>> v6ops mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/v6ops
>>
>>
>>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>