Re: [IPv6] ULA vs. 1918

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

On 19-Jun-23 19:11, Pascal Thubert (pthubert) wrote:
> Hello Brian:
> 
> I see that's one way of dealing with it. I'm concerned that limiting the applicability of ULA also limits its value.
> 
> We have a long history of defining something with one goal in mind (e.g., tag switching and the MPLS were meant to boost forwarding), dropping it, and then finding value in the technology somewhere else (here, VPN / SD-WAN / pseudowires). Same goes for RH0 finding value with SRH.
> 
> So, I was wondering what the nature of ULAs is -> what's their potential / value. I'm still not sure we have the full story there, but I believe we need it to move on. Certainly, having defined something that is least preferred than staying with v4 and RFC 1918 is not a total success for a v6 tech.
> 
> The most salient traits of ULAs seem to be (please add what I missed there we want the complete list):
> 
>  1. prefix autoconfiguration

Yes. This is, for example, what we exploit in RFC 8994 (the Autonomic Control Plane).

>  2. manageable reachability / diameter

Yes. In other words, ensure that local traffic stays local.

>  3. ?

I would add: easier to merge two networks that use "private" (i.e. local) addresses.
  
> Where do those properties have unique value that that ULA becomes something really useful?

Again, I cite RFC 8994. I think Nick Buraglio has institutional use cases.

> Note that my security properties discussion with Ted are the exact same exercise.

OK, but I hesitate to equate "local use" with "security".

    Brian

> 
> 
> regards,
> 
> Pascal
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> *De :* Brian E Carpenter <[e-mail]>
> *Envoyé :* samedi 17 juin 2023 00:03
> *À :* Pascal Thubert (pthubert) <[e-mail]>
> *Cc :* David Farmer <[e-mail]>; [e-mail] <[e-mail]>
> *Objet :* Re: [IPv6] ULA vs. 1918
> On 16-Jun-23 19:02, Pascal Thubert (pthubert) wrote:
>> Hello Brian
>> 
>> If I have a ULA and my destination has a ULA and routing enables connectivity between the 2,
> 
> I'll stop you right there. That is not a recommended scenario; it's not what ULAs were designed for; it is not a case that a default address selection mechanism can ever deal with. Use GUAs.
> 
>      Brian
> 
> 
>> ULA to ULA seems to be the most secured choice (because there’s some control on the diameter where an attacker can operate).
>> 
>> But then how does my stack know? Sure, routing does to a point (default routes obfuscate). So I could leave it to trial and error / eyeballs. But isn’t that a demonstration that the information available at the stack is lacking?
>> 
>> What we want is the stack to know which prefixes a ULA can reach from the routing standpoint, and if an ULA can reach a prefix, allow to prefer a ULA.
>> 
>> The ULA to ULA routability could be expected / inferred within a 48, but my point above is that it’s doubly a mistake to resort on that.
>> 
>> I’ll add that outside the 48 boundary, ULA longest match is not your friend. If you have 2 ULAs a and b and a destination c outside a’s and b’s 48s, but a longer bitwise match with b, does that mean anything about which of a or b can be routed to c? Ne.
>> 
>> This is why for each PIO of an ULA there should be a train of prefixes that an address formed from the address in that PIO can reach, with a preference (vs other PiOs) That’s the only way to unleash the power of ULAs.
>> 
>> Note along that vein: there’s no point making GUA prefixes special in that logic. If the ULA can reach a GUA, then the ULA is still a more secure source address. Placing a GUA in the train with a preference should be acceptable. For the return path, the GUA  should assume symmetrical routability: if the ULA packet reaches me I can reach it back (because it is hopefully filtered at the site boundary).
>> IOW we could consider RIO as the router-level “the originating router can reach this destination prefix with this preference “ and a RIO-prime attached to a PIO would be the source address-level “a source address formed from the prefix in the PIO above can  reach this destination prefix with this preference “. This destination prefix being a global address, ULA or GUA.
>> 
>> Note that RPL use that sort of semantics very successfully. More so with upcoming signaling in  https://datatracker.ietf.org/doc/draft-ietf-roll-dao-projection/ <https://datatracker.ietf.org/doc/draft-ietf-roll-dao-projection/> <https://datatracker.ietf.org/doc/draft-ietf-roll-dao-projection/ <https://datatracker.ietf.org/doc/draft-ietf-roll-dao-projection/>>. I’m not asking you to read the draft but it’s a good hint at how powerful the concept of AGP can become.
>> 
>> Take care,
>> 
>> Pascal
>> 
>>> Le 15 juin 2023 à 22:40, Brian E Carpenter <[e-mail]> a écrit :
>>>
>>> On 15-Jun-23 19:38, Pascal Thubert (pthubert) wrote:
>>>> Hello Brian
>>>> Today the only reachability that is assumed seems to be the /64. Based on the current standards one could assume that /48 is reachable as well but I’d not like to case that in stone in the stacks. The /64 experience with SLAAC should have taught us a thing  or 2.
>>>
>>> Routing will determine whether the whole /48 is reachable. There's not too much we can do about that at the address selection stage. This is more a matter of scope; and as things have evolved, the nearest thing we still have to site-local scope is a ULA  /48. I completely agree that this is classful addressing (even link-local is classful). However, it would not be cast in stone in the code, since it would be in a configuration table. Do we have a better solution for the *default* behaviour?
>>>
>>> (There is an argument for the default table being defined by v6ops, not by 6man.)
>>>
>>>    Brian
>>>
>>>> This is why I jumped in the thread. The ULA may reach a shorter aggregation (even if to Lorenzo’s point that is not fully legal with the current text), and it may reach other ULA prefixes. So hardcoding the /48 is not only repeating an error of the past  but also not sufficient to avoid the need of DHCP, as soon as the network gets fancier.
>>>> And it will. SNAC is just one example.
>>>> I’m looking forward to seeing what the new draft proposes. I hope for a per PIO option inspired by RIO. Basically for ULA all the access le prefixes would be listed with a preference.
>>>> Along the same vein I hope for another per PIO option, also inspired by RIO, that indicates the router preference for a source address derived from that prefix.
>>>> Regards,
>>>> Pascal
>>>>> Le 15 juin 2023 à 00:52, Brian E Carpenter <[e-mail]> a écrit :
>>>>>
>>>>> On 15-Jun-23 10:33, David Farmer wrote:
>>>>>> On Wed, Jun 14, 2023 at 17:01 Brian E Carpenter <[e-mail] <mailto:[e-mail] <mailto:[e-mail]>>> wrote:
>>>>>>    On 15-Jun-23 04:56, David Farmer wrote:
>>>>>>     > I've been thinking we should extend RFC 8028's use of a PIO with A=0 and L=0 for choosing the first-hop router. By adding to that, if the prefix is from the ULA range, then the host should also treat the prefix as a Local ULA prefix from an RFC  6472 section 10.3 perspective and add it to the table as a local ULA prefix.
>>>>>>    What is specific about A=L=0 in this case? Why wouldn't this apply to any PIO in the ULA range?
>>>>>> If A=1 and the prefix length isn’t 64, some people are going to have words with you, I’m fine with it, but I’m not really looking to pick a fight today, and those seem to be fighting words.
>>>>>
>>>>> I was assuming the PIO would be for a prefix of whatever length happens to be in use on the subnet in question (which would be indeed be 64 today). But one can legitimately assume that if fdxx:xxxx:xxxx:yyyy::/64 is announced, the applicable ULA prefix  is fdxx:xxxx:xxxx::/48.
>>>>>
>>>>>   Brian
>>>>>
>>>>>> Also, L=1 is making a different statement about the prefix. A=L=0 isn’t making any other statement about the prefix than it might be a ULA that the host should treat as local and the router announcing the RA knows how to route for.
>>>>>> But it doesn’t specifically have to be A=L=0, but that is probably the safest statement to make.
>>>>>> Thanks
>>>>>> -- 
>>>>>> ===============================================
>>>>>> David Farmer Email:[e-mail] <mailto:[e-mail] <mailto:[e-mail]>>
>>>>>> Networking & Telecommunication Services
>>>>>> Office of Information Technology
>>>>>> University of Minnesota
>>>>>> 2218 University Ave SE        Phone: [phone]
>>>>>> Minneapolis, MN 55414-3029   Cell: 612-812-9952
>>>>>> ===============================================
>>>>> --------------------------------------------------------------------
>>>>> IETF IPv6 working group mailing list
>>>>> [e-mail]
>>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6>
>>>>> --------------------------------------------------------------------