SLAAC in renumbering events

Sun Mar 10 20:53:57 UTC 2019

Hi, Bill,

Thanks for the feedback! In-line....

On 10/3/19 13:54, William Herrin wrote:
> 
> 
> On Fri, Mar 8, 2019 at 3:32 AM Fernando Gont <fgont at si6networks.com
> <mailto:fgont at si6networks.com>> wrote:
> 
>     If you follow the 6man working group of the IETF you may have seen a
>     bunch of emails on this topic, on a thread resulting from an IETF
>     Internet-Draft we published with Jan Žorž about "Reaction of Stateless
>     Address Autoconfiguration (SLAAC) to Renumbering Events" (Available at:
>     https://github.com/fgont/draft-slaac-renum/raw/master/draft-gont-6man-slaac-renum-02.txt
>      )
> 
> 
> Hi Fernando,
> 
> I'm a little confused here. I can certainly see why the default timeout
> of 30 days is a problem, but doesn't the host lose the route from the RA
> sooner? 

Which route?

Configuration of addresses is mostly a different business than acquiring
routes. SO, in the typical scenario where the CPE crashes and reboots,
hosts will even have a default route -- advertised by the router that
crashed and rebooted.

If you are referring to the "on-link" route -- i.e., the route
introduced because the Prefix Information Option had the "L" bit set --
then I don't think there's anything in the standard to actually
grabage-collect such routes.

> Why would an IPv6 host originate connections from an address for
> which it has no corresponding route? Isn't that broken source address
> selection?

Please see above.

The mechanism we specified in Section 5.1.3 of our draft tries to do
exactly that: Try to detect when a previously-advertised prefix has
become stale... and when it's inferred to be stale, just remove all the
corresponding information.

Regarding fixing this issue with source address selection: some have
suggested that his should be addressed in source address selection.
However, there are a number of problems with this.

If you prioritize addresses from the prefix that was last advertised,
then source addresses are guaranteed to flap -- and in the cause of
multi-prefix networks, this would become a troubleshooting nightmare.
Secondly,  if you don't remove the on-link route for the stale-prefix,
then packets meant to the new "owners" of that prefix will be assumed to
be on-link, and hence communication will fail. This should probably be
an indication that the solution is not to avoid using the stale
information, but rather discarding it in a timelier manner.

Please do let me know if I've missed anything.

Thanks!

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont at si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492