Re: Win7 - no managed flag, DHCP address released?!?

[Karl Auer <[e-mail]>]

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 ([e-mail])
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