Re: I-D Action: draft-gont-6man-slaac-renum-02.txt

[Philip Homburg <[e-mail]>]

In your letter dated Mon, 9 Mar 2020 13:48:34 -0300 you wrote:
>That is correct. I'd say, though, that the guess is based on empirical 
>evidence. I haven't seen any implementation that intentionally splis the 
>contents of RAs among multiple RAs.

I'm very much against a standard where one part of the standard imposes
no limits, and then another part implictly assumes that there is infact 
a limit.

If your code needs a limit on the number of RAs uses by a router to 
announces all prefixes, then this draft should explictly set such a limit.

>That is, from a theoretical point, correct. From an engineering point of 
>view, though, it's debatable (I don't think your e.g. house is prepared 
>to be hit by a meteor... but it could).

We are writing a single set of standards. This has nothing to do with 
behavior outside the standards we set.

>#1 is of utmost importance. But if the algorithm fails, you just 
>unpreferred the address. -- Yes, there might be undesirable oscillations 
>of the preferred address,but nothing has brokon down.

If the host knows a stale address then deprecating a good address may cause
the host to use the stale address which does break things.

>#2 is what might cause breakage. In such case you can increase 
>LTA_RAS_INVALID, at the expense of maintaining potentially-invalid 
>addresses for longer.

You cannot expect a random user of a phone to increase LTA_RAS_INVALID,
the draft doesn't even say that LTA_RAS_INVALID needs be configurable, so it
may be hardcoded in the OS.

>This is the first time I see you objecting to the algorithm, but my 
>memory might be failing. Could you provide a ref to any previous post, 
>such that if there were other things that you raised, we can try to 
>address them? (and also to figure out what happened with my mail system).

I found a message where you respond to me raising the issue:
https://mailarchive.ietf.org/arch/msg/ipv6/_oe8GMNO70uxaBYWcJQgtX869MY/