Subject: Re: [dhcwg] Brokenness of specs w.r.t. client behavior with M&O bits

From: Joseph Hyunwook Cha <[email-masked]>
Date: Tue, 14 Oct 2008 06:47:26 +0000 (GMT)

Hello, Thomas.

Thank you for your analysis and suggestions.

IMO, as long as M&O flags are configured correctly, there is no reason to ignore the bits. So, I do not think that one of two options should be selected and specified exclusively. What I am saying is that it will be ok if there is an option (configurable policy) in client side for user to run DHCPv6 client irrespecive of the flags because user can swith its policy to ignorance of flags in case that running client fails by misconfigured flags.  (You can refer to the draft-ietf-ipv6-ra-mo-flags-01.txt )

As I discussed 71st and 72nd meetings, I do not think that RFC 2461/2462 are clear enough for implementors to be guieded. ; Specifically speaking, there are no considerations regarding how to revoke clients and handle with conflict flags from different routers.
So, I think that we should discuss these issues as well as when to invoke clients.

> Our options are:
>
> 1) We could ignore/deprecate the M&O bits and simply have any
>   client that implements DHCP invoke DHCP without even bothering to
>   see what the M&O flags say. I.e, the way DHCPv4 works today.
>
>   IMO, this approach would work fine. Indeed, it has the advantage
>   that the client won't do the wrong thing due to misconfigured
>   routers sending out M&O bits with the wrong setting. The main
>   downside is that operators would have no way of signalling to
>   clients that DHCP isn't available and they shouldn't waste
>   resources trying to invoke it. In the past, there has been
>   endless(?) debate about how significant the "waste" would be.
>
> 2) We could restore the M&O bits, and tie DHCP invocation to the
>   settings of those bits. This is what 2461/2462 did, and was the
>   original model. But, there is still a number of choices to be made
>   here:
>
>   a) Treat the M&O bits as SHOULDs, meaning exactly that. If the bits
>      are set, one SHOULD invoke DHCP, but it is NOT a MUST
>      requirement. If one choses (for whatever reason) not to honor
>      the bits, so be it, but it is not a protocol violation per se.
>
>      This is the approach 2462 took, though it used lower case
>      shoulds.
>
>   b) Treat the M&O bits as MUST. You MUST invoke DHC if they are set,
>      and it is a protocol violation to not do so (if you have
>      implemented DHC, i.e., you have a non-complient DHCP
>      implementation).
>
>   c) One could also say one MUST NOT invoke DHCP *unless* the M&O
>      bits are set.
>
>      Some people/operators wanted such behavior because they wanted a
>      way of indicating that no DHCP servers are present, and that
>      clients shouldn't waste network resources invoking DHCP (this
>      was asserted to be a potential issue on some types of wireless
>      WANs).
>
>      Others argued that a robust client would be foolish to rely on
>      the proper settings of those M&O bits, as it could lead to
>      (unncessary) failures if routers were misconfigured, but DHCP
>      servers were available. [this leads back to the call for option
>      1) above]
>
> In summary, the current specs are not clear on when a client should
> invoke DHCPv6 and when not. That is broken and should be fixed. I also
> suspect that it it less important *which* approach we adopt, than that
> we do actually choose one and document it.

Joseph

_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Thomas Narten <[email-masked]>
Date: Wed, 15 Oct 2008 08:46:49 -0400

> IMO, as long as M&O flags are configured correctly, there is no
>  reason to ignore the bits. So, I do not think that one of two
>  options should be selected and specified exclusively. What I am
>  saying is that it will be ok if there is an option (configurable
>  policy) in client side for user to run DHCPv6 client irrespecive of
>  the flags because user can swith its policy to ignorance of flags
>  in case that running client fails by misconfigured flags.  (You can
>  refer to the draft-ietf-ipv6-ra-mo-flags-01.txt )

One thing I think we need to keep in mind is that we are long past the
time where it makes sense (generally) to "make something configurable
by the end user" as a way to try to have it both ways. We are past (or
rapidly getting past) the day where the standard Internet device is a
PC that has a nice GUI that users can configure things with. Think
cell phones, iPhones, SlimServers, etc. Also, think typical end users
(grandma) who doesn't have a clue about what DHCP is and what it would
mean to enable or disable it.

We really need to make things work out of the box, by default, for
everyone with no configuration. That sort of simplicity is far more
important than saving a few multicast messages in certain
environments.

> As I discussed 71st and 72nd meetings, I do not think that RFC
>  2461/2462 are clear enough for implementors to be guieded. ;
>  Specifically speaking, there are no considerations regarding how to
>  revoke clients and handle with conflict flags from different
>  routers.

In my note, I specifically did not address this issue. This is
completely separate from the basic question of when to invoke DHCP in
the first place. I agree we need to have a clear answer on this one
too, but my take is that we have consensus that the current text (that
does not define a way to "revoke" invocation of DHCP service) is
adequate and the current wording in the RFCs is clear about that. (But
I'm open to other views on this.)

Thomas

---

From: "hyunwook cha" <[email-masked]>
Date: Thu, 16 Oct 2008 11:26:11 +0900

Hello, Thomas.

Inline comments are continued below.

> important than saving a few multicast messages in certain

To fix problem caused by misconfigured flags, there are two options.
i) to fix misconfiguration of routers and ii) to change running policy
of DHPCv6 client in user node.
I think that in most cases, the first way is feasible. I agree that
grandma can not configure a CPE router box in her home. Then, where is
DHCPv6 server for the client in her node and who is responsible for
the configuration of it? If the server is provisioned by service
provider, it is very likely that CPE router box has DHCPv6 relay
installed and configured to be enabled. Then, I think that your
concern is not big because box can be implemented for M&O bits to be
TRUE automatically if DHCPv6 server or relay agent is turned on. Even
if relay/server is not collocated with the CPE router, it is not such
a big task to change M&O bits in RA for whoever is responsible for the
configration of server/relay.
 I also believe that the second option might be necessay with whatever
reasons. This might not be feasible for grandma. However, it depends
on UI in implementations and users.
In short, I am ok if failure is easily detactable and there are
obvious ways to solve the failure.

> I'm open to other views on this.)
I am not sure that there is consensus that it is ok not to define a
way to "revoke" invocation of DHCPv6 client and the current wording in
the RFCs is clear on that issue. I believe that unless M&O bits are
deprecated, a way to "revoke" invocation of DHCPv6 client is required.

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