Subject: Question about IPv6 Address State

From: Masanobu Kawashima <[email-masked]>
Date: Mon, 7 Mar 2011 22:59:20 +0900

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                     
========================================

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 7 Mar 2011 13:58:13 -0600

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: [email-masked] [mailto:[email-masked]] On Behalf Of Masanobu Kawashima
Sent: Monday, March 07, 2011 8:59 AM
To: [email-masked]
Subject: Question about IPv6 Address State

Hi All,

Sincerely,
Masanobu

¢(._.)

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Suresh Krishnan <[email-masked]>
Date: Mon, 7 Mar 2011 15:02:26 -0500

Hi Kawashima-san,

>  in RFC4861/4862. Is it written in other RFCs?

Yes. It is possible. Please refer to bullet e) in Section 5.5.3 of
RFC4862 on RA processing which states

"If the advertised prefix is equal to the prefix of an address
 configured by stateless autoconfiguration in the list, the
 preferred lifetime of the address is reset to the Preferred
 Lifetime in the received advertisement."

This should give you the effect you are looking for.

Thanks
Suresh

---

From: Masanobu Kawashima <[email-masked]>
Date: Tue, 8 Mar 2011 09:56:42 +0900

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

¢(._.)

---

From: Masanobu Kawashima <[email-masked]>
Date: Tue, 8 Mar 2011 09:58:02 +0900

Hi Suresh,

Thank you for your comment.

But Windows Vista and 7 are correctly updating preferred lifetime. :-)
(i.e. It conforms to Section 5.5.3 of RFC4862.)

The problem is that Windows Vista and 7 don't restore to "Preferred"
 from "Deprecated".

Please see my question.

> in RFC4861/4862. Is it written in other RFCs?

We have to define clearly in RFC?

Sincerely,
Masanobu

¢(._.)

---

From: <[email-masked]>
Date: Tue, 8 Mar 2011 09:29:54 +0100

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.
>
>
>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 
>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
>
>I think it's possible to do. However, there is no clear 
>description  in RFC4861/4862. Is it written in other RFCs?
>
>Windows 7 does not restore autoconfigured IPv6 addresses to 
>Preferred  from Deprecated state (bug?) [originally from 
>windows7 forum] 
>In addtion, a address can become valid address such as a 
>preferred address  even if its valid lifetime expires during 
>above situation.
>
>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.
>

---

From: Masanobu Kawashima <[email-masked]>
Date: Tue, 8 Mar 2011 19:27:33 +0900

Hi Christian,

Thank you for your information.
I also got the same results last week.

Sincerely,
Masanobu

¢(._.)