Re: Adoption Call for "Improving the Robustness of Stateless Address Autoconfiguration (SLAAC) to Flash Renumbering Events"

[Fernando Gont <[e-mail]>]

On 30/6/20 01:16, Erik Kline wrote:
> On Mon, Jun 29, 2020 at 1:50 AM Tim Chown <[e-mail]> wrote:
>>
>> On 29 Jun 2020, at 08:49, Lorenzo Colitti <lorenzo=[e-mail]> wrote:
>>>
>>> <snip>
>>>
>>> Yup. Like I said, most of the document consists of simple tweaks that in many cases are already allowed by existing standards. That definitely seems publishable.
>>
>> I don’t think adoption means we would include everything in the document in the final version that is published.  If “most of the document” contains advice you think is publishable, then should we not adopt and work on consensus on what is in the final version?
>>
>> I do agree that data on evidence of the problem would be welcomed.  The user experience may be protected by other mechanisms such as happy eyeballs.
>>
>>> Another much simpler approach that could be taken to solve this problem is to recommend that if a host receives an RA where previous prefix(es) - or more in general, previous options - have disappeared, then it should attempt to re-check that information's validity in some way (e.g., by attempting off-link connectivity).
>>
>> That would seem to be one good bit of advice to include.
> 
> <no hats>
> 
> I'll repeat my previous recommendation that a host can unicast an NS
> from any of its GUAs in a suspected lost PIO for the router's
> link-local address to the link-local address of the router.  Treat it
> like NUD -- RRUD, return routing unreachability detection.

That's indeed possible. In fact, we did consider this, but were so far 
relying on subsequent unsolicited RAs (for actually invalidating an 
address).

One can certainly augment the current algorithm, and recommend that 
e.g., such an NS is sent at the very same time a missing option is 
detected, and one might even also recommend that another one be sent 
upon LTA_INVALID/2 seconds (i.e., before an address is actually eliminated).




> And an alternative to timer manipulation might be 6724 policy table
> manipulation (e.g. something like add an entry for the PIO with
> precedence "precedenceOf(::/0) - 1" and/or a new label, given the
> table in 6724#2.1)?  I have not spent enough time thinking through the
> implications of this, though.

I'd need to give this more proper thought, but, of the top of my head:

* In the context of RFC8028, you need still need to dis-associate the 
prefix with the router that has ceased to advertise it. i.e., if you 
have multiple routers advertising the prefix, if one of them ceases to 
advertise it you don't need to stop using it for new connections, but 
just e.g. stop sending such packets to the router that has ceased to 
advertise the prefix (send them to any other router that has advertised it).

* I believe that the "preferred/unpreferred" status already provide what 
we need. The underlying issue is that, in practice, the 
"preferred/unpreferred" status is meaningless, because it's associated 
with timers that are set to such long values that they will never go off 
in any meaningful timeframe.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492