[IPv6]Re: Should known-local be a generalized mechanism?

[Nick Buraglio <[e-mail]>]

On Thu, Aug 8, 2024 at 6:54 AM David Farmer
<farmer=[e-mail]> wrote:
>
>
>
> On Thu, Aug 8, 2024 at 05:48 Tim Chown <Tim.Chown=[e-mail]> wrote:
>>
>> From: David Farmer <farmer=[e-mail]>
>> Date: Tuesday, 6 August 2024 at 00:17
>> To: Brian E Carpenter <[e-mail]>
>> Cc: 6man WG <[e-mail]>
>> Subject: [IPv6]Re: Should known-local be a generalized mechanism?
>>
>> If we don't update it, we should still reference the current text; otherwise, some might get the idea that they can add as many as they want, which would be way worse than an update.
>>
>>
>>
>> We can refer to the RFC 4191 text.
>>
>>
>>
>> Someone could propose a 4191-update, but I don’t think the 6724-update document is the place to do that.
>>
>>
>>
>> Do we know who did the maths to get 17 and their workings?
>
>
> Well, RFC4191 is quite clear: 17 isn’t a technically derived limit, and it is much more philosophical; here is the whole paragraph;
>
>    Routers SHOULD NOT send more than 17 Route Information Options in
>    Router Advertisements per link.  This arbitrary bound is meant to
>    reinforce that relatively few and carefully selected routes should be
>    advertised to hosts.
>
>
> Since the known-local ULA use case might require more than 17 RIOs and justifies the switch to a technically derived limit, I believe this 6724-update might be the suitable location for the update.

I have been racking my brain trying to come up with a design where
this is a great idea. So far, I can't find one I love (or would ever
want to support), and that arbitrary limit is looking more and more
like a "let's put rails on this so it doesn't implode, but not require
it to not implode" (as seen by the SHOULD NOT and not MUST NOT).
Personally, I like to think of things like this in terms of
likelihood. What is the percentage likelihood that this design model
would be useful? We should consider that as we think about designing
for what are presumably edge cases.

Far be it from me to believe I know every good or bad design, but I
feel like we should tread very carefully in this space, and definitely
keep it out of the 6724-update. Another document could be an option,
but we should not gate on that.

>
> Thanks
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests:
> --------------------------------------------------------------------