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

[Fernando Gont <[e-mail]>]

Hello, Jen,

I've asked/commented on meta issues in my previous response to this
email. Please find below more specific comments.

On 7/7/20 07:33, Jen Linkova wrote:
> 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.

Could you please spell which changes you are arguing against, which ones
you are in favor, and which ones you are, say, agnostic with?



> (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.

My understanding is that adoption means that there's agreement on the
problem to be solved, and that the document serves as a basis for the WG
to work on the issue. Clearly, a document that is still an individual
submission does not necessarily reflect WG consensus -- even when we
have worked with folks that have submitted feedback in that direction.

Maybe the AD can clarify?


> It's not the case for this draft for me. In particular, - the draft
> proposes some fundamental changes to the SLAAC.

Could you please spell what are the fundamental changes you are
referring to?



> The full impact of those changes, especially if the network can not
> guarantee all ND packets to be delivered, is unclear.

I'm not sure how to parse this statement. We did assess the changes. If
you find that the proposed changes may have some ill effect, maybe you
could suggest an scenario where that might be the case, and also
describe how the issue is so fundamental that it cannot be easily fixed
in the current document?



> - the draft drastically increases the complexity of the SLAAC state 
> machine.

Again: Which of the mitigations do you think that increases the state
machine? -- And, if you are referring to Section 4.5, is there a
substantial complexity increase with respect to RFC8028?   --- Note:
without RFC8028, IPv6 multiprefix support is essentially badly broken.



> 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...

Robustness essentially means ability to deal with scenarios where
network elements are not behaving as expected. So the inability of SLAAC
to deal with information that becomes stale seems to me like a problem
with SLAAC itself, as opposed to "a corner case".



> - the draft assumes that RFC8028 is widely implemented while it does 
> not seem to be the case.

I'll repeat again: you are problably referring to one section (SEction
4.5), out of *five* sections with mitigations. Could you please clarify
that?

That aside, Section 4.5 of this draft doens't assume that RFC8028 is
deployed. However, the engineered mitigation builds on top of RFC8028 --
which is a SHOULD as per Node Reqs -- since otherwise multiprefix
support is badly broken.



> - 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?

As noted to Lorenzo, we have focused on the problem of renumbering, for
options (PIOs) that are closely tied to the link -- unlike other
information such as RDNSS.

The WG might well consider and decide to apply similar thinking wehere
the wg thinks fit... but I'm not sure what's the relevance of that for
the decision of whether to adopt this document.


[....]
>> 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.

Given that there are multiple mitigations being proposed, maybe it would 
be useful to spell out which ones you support, and which ones you don't?
As noted to Lorenzo, if there's *one* out of many that you object to, 
that wouldn't seem to warrant shooting down the entire document....


> 
>> 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. 

The reason is getting rid of stale information. IN a first step, that's 
unpreferring the address. IN a second step, that's invalidating the address.



> 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).

If the host figures out that information is most likely stale, isn't it 
the obvious choice to unprefer the address and subsequently (whatever 
that means) eliminate it?

That said, the change you suggest seems indeed fundamental to me, and 
only works if the local router has been modified accordingly. -- whereas 
Section 4.5 of our document tries to deal with scenarios where that's 
not the case.



> 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.

HE is a totally different animal.

HE check whether addresses work end-to-end, including intermmediate 
systems and the destination system.

Using HE for this seems to be like blowing your head off because you 
have a headeach, instead of taking an aspirine.

And I also believe it's conceptually wrong.



> - 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

Answer: 
https://tools.ietf.org/html/draft-gont-6man-slaac-renum-08#appendix-A.2




>> 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

Could you point to the specific mitigation you're referring to, and also 
sketch an scenario where that might be the case?

Otherwise, a rather vague statement such as "does not seem to be 
resilient to packet loss" is hard to agree or disagree with, or 
acknowledge or reject.

Thanks!

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