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? 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. The assignment of a address via DHCPv6 is a contract with the host - "you may have this address for this many seconds". The lifetimes sent by the server and their ability to be set by the administrator are the means of controlling the length of the contract. Once a DHCPv6 address is configured for a prefix, the M and O flags cease to be relevant unless or until that address has been deconfigured. Having read the RFC a few times now :-) I an convinced that there is no intention, implied or otherwise, that the absence (or disappearance) of the M or O flags should have any effect at all on a configured address. However much people may wish for that symmetry, it is not there and is not necessary. 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. 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. > 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 --------------------------------------------------------------------
