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 <fg...@si6networks.com > <mailto:fg...@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: fg...@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492