On 22 Oct 2012, at 01:04, Mark Smith <[email protected]> wrote:
> 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. Part of the problem here is the whole long-running issue with the 'soft' nature of the M and O flags. Their semantics have been diluted in the update of the SLAAC RFC. Many people I think would be happy to see them gone completely. I think there's two questions here. One is what a host should do if it receives conflicting information from the same sender. The other is what to do if conflicting information comes from two senders. This issue has come up recently in 6renum discussions, actually from Karl as well :) http://www.ietf.org/mail-archive/web/ipv6/current/msg16179.html The discussion there was about the former case - successive RAs from a single sender changing. There may be valid reasons for the M/O bit values changing, e.g. to move from a DHCPv6 model to a SLAAC model for address management. In such a case you would probably expect the 'old' address to be deprecated, similar to the approach in RFC4192, such that it is still valid, but not preferred for new connections. Which is pretty much what Karl said in that thread. The example being considered here with two senders and inconsistent settings is a misconfiguration. The inconsistency should be logged and corrected, regardless of what the host behaviour is. If the second RA is a rogue, then methods for rogue RA suppression should be in place. A similar discussion could be had if each RA carried different DNS resolver addresses in the RFC6106 option. That RFC says "configurations where different information is provided by different sources may lead to problems. Therefore, the network administrator needs to configure DNS options in multiple sources in order to prevent such problems from happening." A similar argument. Tim
-------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
