Hi, Pamela, On 27/8/19 15:31, Pamela Mosiejczuk wrote: > Hi all, > > When slaacd(8) detects a link-state change, it sets the preferred > lifetime (pltime) of all configured addresses to zero and tries to > obtain a new router advertisement. > > If none is received after some time, slaacd will give up, but existing > configured IPv6 addresses remain. This leads applications to believe > that IPv6 connectivity is available when it is not, leading to > potentially long timeouts. RFC 6059 suggests removing these addresses. > > Please test this with IPv6-enabled -> IPv6-enabled transitions (there > should be no regression) and IPv6-enabled -> legacy-only transitions > (things should be improved). > > RFC 6059 has additional suggestions about what to do when moving among > various IPv6-enabled networks.
Just happened to see this (sorry for the bad timing!). Note: It may be appropriate to remove existing addresses as soon as you realize you've connected to a different link (e.g., different SSID for wifi, or if you somehow detect a different net as per RFC6059). However, a link-state shouldn't, per-se, lead to addresses being removed. Otherwise, you might break e.g. existing TCP connections upon transient network problems. Since we are at it: heads-up: https://www.ietf.org/internet-drafts/draft-ietf-6man-rfc4941bis-05.txt Thanks! Cheers, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
