This is interesting. Thanks for doing these tests and submitting the results.
When testing the switching behavior, I'm curious for the " SLAAC-only host receiving A=0&M=1 " case as to what you set the Preferred Lifetime to, when you set A=0. I'm guessing Preferred Lifetime > 0? Since RFC 4862 states "A preferred address becomes deprecated when its preferred lifetime expires", I would only have expected a host to deprecate a SLAAC-obtained address if the RA message set Preferred Lifetime to zero. It sounds like the case where the RA is changed from A=1 and Preferred Lifetime > 0 to A=0 and Preferred Lifetime > 0 is ambiguous. I'm not quite sure what the use case is for separating the A flag and Preferred Lifetime settings. Did you also run the test by changing to A=0 and Preferred Lifetime = 0? I would hope that there would be consistent behavior in that case. For the "DHCPv6-only host receiving A=1&M=0" case, I'm curious as to whether you also tried sending a DHCPv6 Reconfigure message and forcing the host to release the DHCPv6-assigned address; and send A=1&M=0 in an RA directly after sending the Reconfigure. I'm not sure what the use case is for trying to force the release or deprecation of a DHCPv6 address via flags in an RA message. Once a host has a DHCPv6 address, I would have expected its subsequent behavior relating to that address and that DHCPv6 server to be governed by RFC 3315. The Linux/MAC behavior appears consistent with what I would have expected. The Windows 7 does not. I'm unaware of even a "hint" that suggests RA flags have a role in governing DHCPv6 behavior once RFC 3315 is in play. Barbara > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Liubing (Leo) > Sent: Tuesday, February 26, 2013 2:14 AM > To: [email protected]; [email protected] > Cc: [email protected] > Subject: SLAAC/DHCPv6 addr-conf operational gaps > > Hi, 6man & v6ops > > We submitted a new draft to discuss the SLAAC/DHCPv6 interaction gaps. > > As we know there are several flags in RA messages regarding with the host > configuration behavior, which are A (Autonomous) flag, M (Managed) flag, > and O (Otherconfig) flag. > For some reason, the host behavior of interpreting the flags is ambiguous in > the standard (mainly RFC4862). I presented a draft discussing M flag behavior > in 6man @ietf84, and there were some feedbacks arguing the same issue. > This draft analyzed all the three flags, and provided test result of current > implementations, it showed the behavior of different mainstream desktop > OSes have varied. The ambiguous and variation might cause operational > problems, such as renumbering (used to discuss in 6renum WG and been > documented in the WG drafts), cold start problem, and management gaps > .etc. > > Your review and comments would be appreciated very much. > > All the best, > Bing > > > -----Original Message----- > > From: [email protected] [mailto:[email protected]] > > Sent: Monday, February 25, 2013 5:52 PM > > To: Liubing (Leo) > > Cc: [email protected] > > Subject: New Version Notification for > > draft-liu-bonica-dhcpv6-slaac-problem-01.txt > > > > > > A new version of I-D, draft-liu-bonica-dhcpv6-slaac-problem-01.txt > > has been successfully submitted by Bing Liu and posted to the IETF > > repository. > > > > Filename: draft-liu-bonica-dhcpv6-slaac-problem > > Revision: 01 > > Title: DHCPv6/SLAAC Address Configuration Interaction Problem > > Statement > > Creation date: 2013-02-25 > > Group: Individual Submission > > Number of pages: 12 > > URL: > > http://www.ietf.org/internet-drafts/draft-liu-bonica-dhcpv6-slaac-prob > > lem- > > 01.txt > > Status: > > http://datatracker.ietf.org/doc/draft-liu-bonica-dhcpv6-slaac-problem > > Htmlized: > > http://tools.ietf.org/html/draft-liu-bonica-dhcpv6-slaac-problem-01 > > Diff: > > http://www.ietf.org/rfcdiff?url2=draft-liu-bonica-dhcpv6-slaac-problem > > -01 > > > > Abstract: > > This document analyzes the host behavior of DHCPv6/SLAAC interaction > > issue. It reviews the standard definition of the host behaviors and > > provides the test results of current mainstream implementations. Some > > potential operational gaps of the interaction are also described. > > > > > > > > > > The IETF Secretariat > > -------------------------------------------------------------------- > 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 --------------------------------------------------------------------
