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

From: Karl Auer <[email-masked]>
Date: Thu, 18 Oct 2012 23:30:48 +1100

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.

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.

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer ([email-masked])
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

---

From: Oliver <[email-masked]>
Date: Thu, 18 Oct 2012 13:48:45 +0200

> suggestions for alternatives are welcome.

I'd recommend the ipv6-ops mailing list on cluenet.de and possibly NANOG

Regards,
Oliver

---

From: Mark Smith <[email-masked]>
Date: Sun, 21 Oct 2012 17:04:19 -0700 (PDT)

Hi Karl,

----- Original Message -----
> From: Karl Auer <[email-masked]>
> To: IETF IPv6 <[email-masked]>
> Cc: 
> Sent: Thursday, 18 October 2012 11:30 PM
> Subject: Win7 - no managed flag, DHCP address released?!?
> 

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.
> supporting this behaviour.

Regards,
Mark.

---

From: Tim Chown <[email-masked]>
Date: Mon, 22 Oct 2012 13:53:49 +0100

>> 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

---

From: Karl Auer <[email-masked]>
Date: Tue, 23 Oct 2012 09:41:55 +1100

> 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.

---

From: Mark Smith <[email-masked]>
Date: Mon, 22 Oct 2012 21:37:54 -0700 (PDT)

Hi,

----- Original Message -----
> To: [email-masked]
> Sent: Tuesday, 23 October 2012 9:41 AM
> Subject: Re: Win7 - no managed flag, DHCP address released?!?
> 

Agree. 

>    lifetime fields for the preferred and valid lifetimes.
<snip>
> 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

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.

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>