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

[Fernando Gont <[e-mail]>]

Hi, Jen,

Ping?


On 7/7/20 15:45, Fernando Gont wrote:
> 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