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

[Fernando Gont <[e-mail]>]

Hello, Jen,

Some meta comments/questions:

Could you please note, explicitly, which of the specific proposals you 
are arguing against, and which you are in favor?

It would seem to me that, if anything, you're only arguing against 
Section 4.5. That's *one* out of 5 sections with proposed mitigations. 
So I'm curious why, if that's the only part you are arguing against, the 
result of your assessment would be to not support adoption of this document.

IN your email, you also argue that you are not sure the proposed 
mitigation (I assume you're referring to Section 4.5? -- but please 
specify) is robust to packet loss. Could you please sketch a sample 
scenario, such that we can confirm what you're suggesting, or otherwise 
disagree with it?

Thanks,
Fernando




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


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