Hi, I've had a quick read though, I'll try to do a thorough one in the next week or so.
Thanks for writing this, I've been thinking about doing something similar over the last few months since, IIRC, I heard about Windows 7 invalidating IPv6 addresses learned via DHCPv6 when SLAAC was enabled and DHCPv6 was disabled on a link. A few thoughts I've had which may be useful - Firstly, I came to realise that the mistake being made by Windows 7 was the assumption that the aging of the assigned IPv6 addresses was tightly coupled to the DHCPv6 session state, meaning that if DHCPv6 went away, so would the assigned addresses. This is generally the way DHCPv4 has worked. However, in IPv6/DHCPv6, it seems the address lifetime values in the IA_NA are not coupled to the T1 and T2 times, so if DHCPv6 goes away (perhaps because the M bit was switched off in a latter RA), the configured IPv6 addresses should be left to age out as per their preferred and valid lifetimes. The other thing I noticed was that the M RA flag and the PIO A flags aren't mutually exclusive - I couldn't find any text in RFC4861 that says if the M bit is switched on, the PIO A flags must be switched off and vice-versa. So that suggests that the DHCPv6 and SLAAC can co-exist, and I think that is quite reasonable if you're transitioning a link from DHCPv6 to SLAAC address configuration or vice-versa. Thinking about it more, I came realise that DHCPv6 and SLAAC are _address configuration_ methods, but are not address aging methods - IPv6 takes care of address aging via it's preferred and valid aging mechanisms, regardless of the address configuration method. Static assignment is also just an address configuration method, although typically the addresses don't age out, but only because they're normally set to infinity. Perhaps in the future there might be other address configuration methods. I didn't seem to be able to find an RFC that made it clear that address configuration and address aging are quite separate, so perhaps this ID could be the one. Regarding this text: 'For the host behavior, there is an explicit rule in the SLAAC specification [RFC4862]: "If the Autonomous flag is not set, silently ignore the Prefix Information option."' I think RFC5942, "IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes." updates that advice, as the PIO option is used to indicates which prefix/range of addresses are on-link, via the PIO O bit, even if the PIO A bit is switched off. Best regards, Mark. >________________________________ > From: Liubing (Leo) <[email protected]> >To: "[email protected]" <[email protected]>; "[email protected]" <[email protected]> >Cc: "[email protected]" <[email protected]> >Sent: Tuesday, 26 February 2013 6:14 PM >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-problem- >> 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 --------------------------------------------------------------------
