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

[Jen Linkova <[e-mail]>]

On Sat, Jun 27, 2020 at 9:36 AM Bob Hinden <[e-mail]> wrote:
> This message starts a two week 6MAN call on adopting:
>
>  Title:          Improving the Robustness of Stateless Address Autoconfiguration (SLAAC) to Flash Renumbering Events
>  Authors:        F. Gont, J. Zorz, R. Patterson
>  File Name:      draft-gont-6man-slaac-renum-08
>  Document date:  2020-05-18>
>  https://tools.ietf.org/html/draft-gont-6man-slaac-renum
>
> as a working group item. Substantive comments and statements of support for adopting this document should be directed to the mailing list.  Editorial suggestions can be sent to the authors.  This adoption call will end on 10 July 2020.

First of all I agree that we do have a problem with flash renumbering
and it would be desirable to make the protocol more robust.
However I have some reservations about the changes proposed by the
draft and I do not support the adoption in its current form.
(I'd disagree with the argument that 'adopting does not mean the draft
will be published as it is so let's adopt it and figure out the
content later'. IMHO adopting the draft means that the WG agrees with
the proposed standard changes in principle and is willing to work on
polishing the details.

It's not the case for this draft for me.
In particular,
- the draft proposes some fundamental changes to the SLAAC. The full
impact of those changes, especially if the network can not guarantee
all ND packets to be delivered, is unclear.
- the draft drastically increases the complexity of the SLAAC state
machine. I'm not convinced the potential benefits are worth it.
Taking into account introduced complexity and not fully estimated
negative impact, it looks like the cure might be worse than the
disease. Introducing changes of that scale to *all* hosts to fix a
corner case of broken routers/software looks like a drunkard's search
principle...
- the draft assumes that RFC8028 is widely implemented while it does
not seem to be the case.
- I also agree with Lorenzo that the draft proposed a kind of
inconsistent behaviour by applying the heuristic to PIOs only. Shall
the same approach be taken for RIOs?
And any other RA option?

> There has been a lot of discussion on this draft, the chairs have some concerns with this document being adopted, but wanted the w.g. to express its opinion.  Our concerns include:
>
> This document proposes significant changes to SLAAC to fix what could be seen as an implementation problem in some edge routers.  This will affect all IPv6 nodes, not only the ones communicating with these edge routers.  This part of IPv6 is a mature standard.   It is not clear we should modify all IPv6 hosts to deal with one corner case that may break other things allowed by the standard.
>
> The changes proposed will make SLAAC more active, the changes include:
>
>  o Reducing the default Valid Lifetime and Preferred Lifetime of PIOs

I fully support this part of the proposal. Reducing the default values
for valid and preferred lifetimes so prefix and router lifetimes are
of the same magnitude does make sense. It's what I have deployed
anyway.

>  o Caps the received Valid Lifetime and Preferred Lifetime of PIOs.
>  o Frequent retransmission of configuration information
>  o Routers send all options in RA messages
>
> Some additional questions for the w.g. to consider:
>  o Are there better approaches to address the underlying issue?

Not sure if they are better or not, but off top of my head:
- I do not see the reason to force the invalidation of the prefix. If
the goal is to be able to communicate to 'new owners' of addresses in
that prefix, then
it would be enough to clear all on-link information when the prefix
gets deprecated.
- if we assume that hosts support RFC8028/Rule 5.5 then all the
routers need to do is to use the new Link-Local address every time the
PIOs set is changing (create a hash of PIOs or smth to generate the 64
bits of interfaceID). So as soon as the set of advertized PIOs has
changed, the router would send X new RAs from the new LLA. The hosts
would detect the old LLA being unreachable via NUD and switch to the
new prefix(es).
- we already have a mechanism for finding out what address works -
it's called Happy Eyeballs.
- I'm obviously biased here [1], but why can we not let the source
address selection to deal with it?
[1] https://tools.ietf.org/html/draft-linkova-6man-default-addr-selection-update-00

>  o Do the proposed changes work in all deployments?

That's my main concern. In multiple RA scenario the proposed mechanism
does not seem to be resilient to packet loss

>  o Are some proposed changes worth advancing even if the entirety may not be? If so, which ones?

I'd fully support reducing the default values for the lifetimes.

-- 
SY, Jen Linkova aka Furry