Re: [IPv6] ULA vs. 1918

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

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