Re: [IPv6] ULA vs. 1918

[Ted Lemon <[e-mail]>]

What do you mean by “secure” here!

Op vr 16 jun 2023 om 03:02 schreef Pascal Thubert (pthubert) <pthubert=
[e-mail]>

> Hello Brian
>
> If I have a ULA and my destination has a ULA and routing enables
> connectivity between the 2, 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/. 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
>
> --------------------------------------------------------------------
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>