Hi Karl,
----- Original Message ----- > From: Karl Auer <[email protected]> > To: IETF IPv6 <[email protected]> > Cc: > Sent: Thursday, 18 October 2012 11:30 PM > Subject: Win7 - no managed flag, DHCP address released?!? > > My apologies if this is not the right list for this comment/question; > suggestions for alternatives are welcome. > > I have just seen the following demonstrated. > > Two routers, short RA interval, both sending RAs for the same prefix, > both with the autoconf flag set, one with the managed flag set and one > without. > So to be clear, RA1 - M=1, O=1, PIO: pfx=2001:db8:0:1::/64, L=1, A=1 RA2 - M=0, O=1, PIO: pfx=2001:db8:0:1::/64, L=1, A=1 6.2.7, "Router Advertisement Consistency" in RFC4861 does say routers should check the RAs from other routers, and log inconsistencies, as it indicates that a misconfiguration has occurred. The M and O bits are specifically mentioned. Although the M bit is a whole of link flag as it is global in the RA, rather than being a prefix specific flag, the definition of the M bit in RFC4861 seems to only indicate to attempt stateful DHCPv6, rather than also override the A bit in any received PIOs: M 1-bit "Managed address configuration" flag. When set, it indicates that addresses are available via Dynamic Host Configuration Protocol [DHCPv6]. If the M flag is set, the O flag is redundant and can be ignored because DHCPv6 will return all available configuration information. Looking a bit further, RFC4861 says that (6.3.4) When multiple routers are present, the information advertised collectively by all routers may be a superset of the information contained in a single Router Advertisement. Moreover, information may also be obtained through other dynamic means like DHCPv6. Hosts accept the union of all received information; the receipt of a Router Advertisement MUST NOT invalidate all information received in a previous advertisement or from another source. However, when received information for a specific parameter (e.g., Link MTU) or option (e.g., Lifetime on a specific Prefix) differs from information received earlier, and the parameter/option can only have one value, the most recently received information is considered authoritative. So I'd say Windows 7 is doing the wrong thing if the M bit changes from 1 to 0. It should stop using DHCPv6 from that point onwards to acquire or refresh addresses, but still should respect the preferred and valid lifetimes of the addresses it previously acquired using DHCPv6. It should also perform SLAAC using the RA PIOs with the A bits, independently of the value of the M bit. It seems that an exclusively stateful DHCPv6 or SLAAC model has been adopted by Windows 7, rather than a stateful DHCPv6 and/or SLAAC model, which is what RFC4861 provides. RFC4861's model would allow the addition of a stateful DHCPv6 server to a formerly SLAAC only link, or vice versa, and facilitate a phased rather than disruptive move to a SLAAC only or stateful DHCPv6 only operation if that is the goal. > A Windows 7 host gets an address via DHCPv6 when the RA with the managed > flag comes around - and DROPS IT when an RA without the managed flag > comes past. > > This is not the valid lifetime expiring normally. I was not able to > determine whether the Windows host is actually sending a DHCPv6 release > as well, but it is most certainly dropping the address from the > interface. > > I will be trying to do my own tests to confirm (or not) this behaviour, > but has anyone else seen it? Or seen it with other operating systems? > > If it is indeed happening, this behaviour seems very badly broken to me. > I don't feel the relevant RFCs can reasonably be interpreted as > supporting this behaviour. > > Regards, K. > Regards, Mark. -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
