Hi Christian, Thank you for your information. I also got the same results last week.
>In another message >http://lists.cluenet.de/pipermail/ipv6-ops/2009-December/002732.html >I corrected myself since I confused the values of PreferredLT and ValidLT >*only in the email* not in the tests. > >I can confirm the decribed behaviour of Win7 since I repeated the tests in >autumn 2010 with the same results. Sincerely, Masanobu >Hello Hemant, Masanobu, > >may I jump since the cited text was from a discussion I opened on >ipv6-ops@cluenet. >Please see my comments inline. > >>Masanobu, >> >>I have snipped the following text from your test details at >>http://lists.cluenet.de/pipermail/ipv6-ops/2009-December/002718 >>.html between squared brackets. >> >> >>[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.] >> >>There is one problem with your test and that is why I suspect >>you see the behavior. In the 2nd step your Preferred Lifetime >>value of 86400 is greater than Valid Lifetime of 43200 and >>thus a host can get confused. Note from the following text >>from section 4.6.2 of RFC 4861 that the Preferred Lifetime >>cannot exceed the Valid Lifetime. > >In another message >http://lists.cluenet.de/pipermail/ipv6-ops/2009-December/002732.html >I corrected myself since I confused the values of PreferredLT and ValidLT >*only in the email* not in the tests. > >I can confirm the decribed behaviour of Win7 since I repeated the tests in >autumn 2010 with the same results. > >cheers, >Christian > >> >>[Preferred Lifetime >> 32-bit unsigned integer. The length of >>time in seconds (relative to the time the packet is sent) that >>addresses generated from the prefix via stateless address >>autoconfiguration remain preferred [ADDRCONF]. A value of all >>one bits (0xffffffff) represents infinity. See [ADDRCONF]. >>Note that the value of this field MUST NOT exceed the Valid >>Lifetime field to avoid preferring addresses that are no longer valid.] >> >>Also, a host is totally legal to use just the Valid Lifetime >>and thus I'd repeat your test with changing of Valid Lifetime >>and see what you see for behavior by the host. >> >>Hemant >> >>-----Original Message----- >>From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On >>Behalf Of Masanobu Kawashima >>Sent: Monday, March 07, 2011 8:59 AM >>To: ipv6@ietf.org >>Subject: Question about IPv6 Address State >> >> >>Hi All, >> >>I'd like to ask simple question. :-) >>Can IPv6 address restore to Preferred State from Deprecated state? >>I think it's possible to do. However, there is no clear >>description in RFC4861/4862. Is it written in other RFCs? >> >>I know that one of the weird behavior. Please see the following links. >> >>issue with SLAAC and deprecated IPv6 addresses on recent >>windows versions >>http://lists.cluenet.de/pipermail/ipv6-ops/2009-December/002718.html >> >>Windows 7 does not restore autoconfigured IPv6 addresses to >>Preferred from Deprecated state (bug?) [originally from >>windows7 forum] >>http://social.technet.microsoft.com/Forums/en-US/ipv6/thread/2e >>97220e-af61-48da-b2d4-f1d4ba321b1a/ >> >>In addtion, a address can become valid address such as a >>preferred address even if its valid lifetime expires during >>above situation. >> >>If CPE implemented a requirement that is described L-13 in >>draft-ietf-v6ops-ipv6-cpe-router-09, it could happen. >>If the prefix is changed to such as "prefix A --> prefix B --> >>prefix A", CPE can't recognize as a same prefix. Therefore, >>IPv6 address should restore to Preferred State from Deprecated state. >> >>> L-13: If the delegated prefix changes, i.e. the current prefix is >>> replaced with a new prefix without any overlapping time >>> period, then the IPv6 CE router MUST immediately advertise the >>> old prefix with a preferred lifetime of 0 and a valid lifetime >>> of 2 hours (which must be decremented in real time) in a >>> Router Advertisement message. >> >>Sincerely, >>Masanobu >> >>¢(._.) >>======================================== >> NEC AccessTechnica, Ltd. >> Access Networks Engineering Department >> Masanobu Kawashima >>======================================== >> >>-------------------------------------------------------------------- >>IETF IPv6 working group mailing list >>ipv6@ietf.org >>Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>-------------------------------------------------------------------- >>-------------------------------------------------------------------- >>IETF IPv6 working group mailing list >>ipv6@ietf.org >>Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>-------------------------------------------------------------------- >> ¢(._.) ======================================== NEC AccessTechnica, Ltd. Access Networks Engineering Department Masanobu Kawashima ======================================== -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
