Hi,
----- Original Message ----- > From: Karl Auer <ka...@biplane.com.au> > To: ipv6@ietf.org > Cc: > Sent: Tuesday, 23 October 2012 9:41 AM > Subject: Re: Win7 - no managed flag, DHCP address released?!? > > On Mon, 2012-10-22 at 13:53 +0100, Tim Chown wrote: >> 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 > > In that discussion I said that I thought a host MAY deconfigure an > address if it was configured due to an M flag, but I've changed my mind. > I now feel that a host MUST NOT deconfigure (or even deprecate) an > address solely because the state of the M or O flags changes, even if > from the same sender. Why? > Agree. > 22.6. IA Address Option > > [...]In a message sent by a server to a > client, the client MUST use the values in the preferred and valid > lifetime fields for the preferred and valid lifetimes. > <snip> > > However, there is also no statement, implied or otherwise, that a host > SHOULD NOT or MUST NOT deconfigure an address whenever it darn well > feels like it. I don't think you'd find that statement in the DHCPv6 RFC, instead, it'd be in the one that describes what preferred and valid lifetimes mean and how they're used i.e. address aging. DHCPv6 is only acting as an address configuration protocol in this case, not an address aging protocol too. Otherwise there'd be statements in the DHCPv6 RFC that the preferred and valid lifetimes for addresses must not be larger than the T1/T2 timer values in DHCPv6, to constrain the life of addresses to be within the life of a DHCPv6 session. The MUST in the text above is saying that what ever the IA Address Option ages are, they MUST be used for address aging. I consider Windows to be broken in this case, because it seems to fundamentally is assuming DHCPv6 session validity constrains the valid ages of any of the DHCPv6 options, when those options have their own specific age values. > The snippet of code above may suggest otherwise, but I > think it is clear that it is setting a maximum, not a minimum. So I have > to come to the reluctant conclusion that Windows is not doing anything > formally wrong in this regard, it is just doing something very > stupid[1]. > > And I stand by my opinion that these flags are unnecessary and should be > deprecated as soon as possible. > Assuming you're talking about the M & O bits, I think a drawback of that is that it then requires a DHCPv6 server, at the least a stateless one, to always be present. Otherwise all hosts would be periodically multicasting DHCPv6 solicit messages constantly, regardless of whether a DHCPv6 server is ever going to be present. This periodic sending of multicasts by all devices and possibly flooding of multicast to all devices (i.e. without MLD snooping at layer 2) could be quite detrimental to devices operating on batteries. OTOH, if that forced people to deploy stateless DHCPv6 for application/service configuration instead of thinking that DHCPv6 options should be in RAs, I'd personally be for it. >> 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. > > All true - but the host should also avoid a trivial DoS by not > "flapping" outside the lifetimes received with the address(es) it > configured. > >> 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. > > Similar, yes. But not the same, given the DHCPv6 contract. If a host was > fooled into entering the contract, that's too bad - but being able to > fool it out of the contract is equally bad. > > Regards, K. > > [1] If indeed it is doing it at all - I still haven't double checked > this. > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Karl Auer (ka...@biplane.com.au) > http://www.biplane.com.au/kauer > http://www.biplane.com.au/blog > > GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 > Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
