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: [email protected] [mailto:[email protected]] On >Behalf Of Masanobu Kawashima >Sent: Monday, March 07, 2011 8:59 AM >To: [email protected] >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 >[email protected] >Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- >-------------------------------------------------------------------- >IETF IPv6 working group mailing list >[email protected] >Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
