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

[Fernando Gont <[e-mail]>]

Hello, Pascal,

On 30/6/20 04:29, Pascal Thubert (pthubert) wrote:
> Hello Bob:
> 
> I see 2 distinct parts in the draft. On the one hand, the draft
> describes a problem and the state of the IPv6 signaling, can and
> cannot do with the lifetimes in RAs. I believe that this is really
> useful to the community and can be a strong base to frame the
> solution.
> 
> Then the draft jumps to a proposition to solve the issue. I see
> controversy on the solution part because indeed there can be several
> ways to either signal the host that it should renumber or leave it to
> the host to figure that out quickly.

FWIW, what this document is trying to do is to tweak the protocol, and 
implement mitigations, in a way that the problem in question can be 
mitigated without the need for both the local host and the local router 
to implement a new behavior.

In that light, any kind of signaling by the router would required 
changes to both the router (to send the signal) and the host (to process 
it), making it a no starter for what we are trying to achieve. We are 
trying to improve the situation for hosts where their local router will 
not be updated in any sensible time frame, as well as for hosts that 
will not be updated, but may attach to a network where the local router 
has been updated.



> I'll note that the host is impacted whatever; there are few major
> OSes but a great many brands of CPEs; that the host OS may be
> refreshed faster than CPEs, some of which are just plugged on the
> phone line till fiber shows up. This means a great many (failure)
> combinations and a very slow path to the problem globally solved if
> we need to change both sides. So a host-only change like Erik's
> variation of NUD makes a lot of sense to me. 

We are trying to do both.


> A policy recommendation
> to the ISPs to keep the prefix stable within the original advertised
> lifetime seems also like a good idea.

We are doing that in: draft-ietf-v6ops-slaac-renum. That said, that's 
just one of the possible scenarios.



> All in all, I believe that there should be several solution drafts
> proposed and then the group would decide what's the best approach.

This problem (along with this document) has been discussed for over a 
year now.

The only bit where there seems to be differing opinions is on Section 
4.5 (but not the rest of the document).

And regarding Section 4.5 itself, I believe our differences are rather 
minor. For example, it seems we all agree that an RA that has ceased to 
advertise a PIO send an implicit signal (which you might use to unprefer 
or invalidate prefixes, or trigger an active text of the information).

    We might have small variations in this area ranging from reacting
    to such RA at once (since all existing implementations don't split
    RAs), to "wait for a few seconds before reacting, just in case" (as
    in the current version of the document) to try to "measure if the
    router is splitting RAs, and then use that information when deciding
    to react to the RA).

Then small variations regarding whether to react passively (as in the 
current version of the document), or whether to do some sort of active 
testing (either against the local router, or against an off-link system).

These possible variations and details do indeed to need to be worked 
out. But I believe they reflect a lot of points of agreement, already.

Thanks!

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