issue with SLAAC and deprecated IPv6 addresses on recent windows versions

[Christian Hahn]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> Hi list,
Sean Siler just pointed me to an error in mail initial email, so I want to
correct things. In the email I've mixed up the values I've used in my second
step (to bring the prefix back to life). The correct values and the one I used
during the tests, are _PreferredLifetime=43200_ and _ValidLifetime=86400_.
Sorry for the confusion.

cheers,
Christian
> 
> In a lab I did some testing with SLAAC and different OSs and recently stumbled
> upon an issue on recent windows versions. It is only present on Vista and 7, not
> on XP. But let me tell you the story ...
> 
> I deprecated an formerly (by RA) announced IPv6 prefix (let's say
> 2001:db8:1:2::/64) by  sending some RAs with PreferredLifetime=0 and
> ValidLifetime=7200 and thereafter stopped sending RAs.
> All windows machines behaved correctly and deprecated the addresses derived from
> that prefix. Outgoing connections no longer used it as source address, but
> incoming packets (like icmpv6 echo request) where answered due to the valid
> "ValidLifetime" value. ;)
> 
> Then in the second step (after some minutes of testing) I tried to re-activate
> the _same_ prefix (2001:db8:1:2::/64) by sending periodic RAs with
> PreferredLifetime=86400 and ValidLifetime=43200. And here the weird things
> began. On Vista and 7 the values for the "Lifetimes" where updated to the new
> ones derived from the RA, but the prefix status didn't change. It still was
> stuck in status "deprecated". Hence the still valid IPv6 addresses from that
> prefix (2001:db8:1:2::/64) wasn't used as source addresses for new connections,
> only old connections used it and incoming packets where answered.
> 
> On XP it was different. The prefix came back to life, changed to status
> "preferred" and the system again used it's 2001:db8:1:2::/64 IPv6 addresses as
> source address for new connections.
> 
> To proof it I replicated the test, and restarted all machines beforehand. But
> the result didn't change, hence it seems it is "stable" behavior.
> 
> I assume it's not the proper behavior, but found no clue in RFC4862 (SLAAC)
> where I was looking for allowed status changes or similar.
> Has anybody seen a similar behavior or made similar tests with different results?
> 
> BTW. I used radvd 1.1 on Ubuntu 9.04 on the router side.
> 
> cheers,
> Christian
> ------------------
> gpg fingerprint:
> 31E4 283B 5EFD 920C 3DD4  CC3E EA43 16EC 75BC EB6D
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/

iEYEARECAAYFAksYz2kACgkQ6kMW7HW8621CCQCdE/uSD+XOEuW5g3gfW19WRMRJ
htwAn1XLOQQOjVXOMK/7l4ItulOQePte
=mXWl
-----END PGP SIGNATURE-----