Hi Hemant, Thank you for your comment. I agree with you.
But I should have added following link. http://lists.cluenet.de/pipermail/ipv6-ops/2009-December/002732.html I am sorry for the confusion. Sincerely, Masanobu >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. > >[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/2e97220e-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 >-------------------------------------------------------------------- ¢(._.) ======================================== 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 --------------------------------------------------------------------
