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
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
