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

[Fernando Gont <[e-mail]>]

Hello, Bob,

Thanks for starting the WG call for adoption!

While I do expect participants to read through the document and make
their own judgement, some of the statements in your email below seem a 
bit inaccurate or misleading. So I felt like clarifying some of the 
points you have raised.

Please see in-line....


On 26/6/20 20:35, Bob Hinden wrote:
[....]
> 
> This document proposes significant changes to SLAAC to fix what could
> be seen as an implementation problem in some edge routers.

Firstly, this is not an implementation problem, but a protocol-based 
problem: SLAAC does not react gracefully to flash renumbering events.

The problem does not arise in one particular scenario, but it's actually 
a general issue with the protocol. Please see: 
https://tools.ietf.org/html/draft-ietf-v6ops-slaac-renum-01

Secondly, I don't think any of the four items you list below are 
significant changes to SLAAC. Namely:

* "Reducing the default Valid Lifetime and Preferred Lifetime of PIOs"

I would assume that the reason the protocol conveys time values in 
protocol fields is so that they can be changed. Otherwise they would be 
hardcoded in the protocol, and not communicated via PDUs/packets.


* "Cap the received lifetimes"

There is nothing in SLAAC that forces nodes to keep addresses for the 
PL/VL advertised in RAs. In fact, RFC4941 already leverages this fact 
(by configuring addresses that employ effective lifetimes that are 
shorter than the ones advertised in RAs). There are a couple of special 
cases that need to be taken care of, which the latest rev of this 
document already does.

* "Frequent retransmission of configuration information"

This is misleading. Firstly, Section 4.3 of the document recommends 
resending configuration information *upon interface initialization* -- 
i.e., this applies only when an interface is initialized, and not during 
regular operation, so to speak. Secondly, This behavior is allowed by 
RFC4861 already ("MAY transmit..")... so I'm not sure why you'd deem 
this as a significant change.

* "Routers send all options in RA messages"

This document recommends that routers send all *PIOs* in the same RA. As 
reported by Tim Winters, this essentially matches all running code.



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

I will note that this is not a corner case, but actually a general issue 
of SLAAC that has concrete operational implications. The problem (and 
some of the possible scenarios where it may arise) is discussed in 
detail in: https://tools.ietf.org/html/draft-ietf-v6ops-slaac-renum

There have been other previous efforts that have tried to deal with some 
of the possible scenarios where this may arise, which include:

* Protocol update proposals: Jen's "Default Address Selection and Subnet
   Renumbering", draft-linkova-6man-default-addr-selection-update-00
  (work in progress), March 2017.

* Router implementations such as Fritzbox: 
https://www.si6networks.com/2016/02/16/quiz-weird-ipv6-traffic-on-the-local-network-updated-with-solution/

* Operational mitigations: RIPE-690 document: 
https://www.ripe.net/publications/docs/ripe-690

Several operators have repeatedly noted on the v6ops list why these 
scenarios may occur. And, in fact, work on this document was started in 
response to an ISP asking for guidance on how to deal with this problem.

Last, but not least, the whole point of adopting a document (as in this 
case), is for the WG to work on it, and if there's any aspect of the 
current proposal that needs to be improved or changed, modify the 
document accordingly.



> The changes proposed will make SLAAC more active, the changes
> include:
> 
> o Reducing the default Valid Lifetime and Preferred Lifetime of PIOs 
> 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

Would you mind elaborating on what you mean by the changes "making SLAAC 
more active"?

Thanks!

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