Subject: [dhcwg] RE: purpose of m/o bit

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Tue, 24 May 2005 11:35:41 -0400

Thomas/Jim:

I believe that most of us are in agreement on the main points -- the
bit(s) are useful and SHOULD be acted on by clients accordingly.

I believe were there are issues are in the details about what each bit
means and how they interact and what happens if they're not set
correctly.

Personally I think the last issue should be a non-issue since there are
plenty of other parameters that need to be set correctly for networks to
run. At worst, this causes clients not to get addresses (which will
likely generate complaints to the network administrators fairly quickly)
or wastes bandwidth.

If we assume that current bits are retained, there is a problem if both
the M and O bits are set with what a client should do if it supports
both stateful and stateless DHCPv6 but fails to receive responses to
Solicit requests.

If the client only supports stateless DHCPv6, there is no issue since it
just sends Information-Request messages.

But if the client supports both (really this means it is a "full" 3315
client), does it do both in parallel, initiate stateful (Solicits) and
failover to stateless at some point (and does it continue to do stateful
in the background), or? These areas that are not well documented in the
DHCPv6 specifications (3315 + 3736) and we need to clarify. We've
discussed several proposals but I don't think we've closed that
discussion.

Having one bit instead of two doesn't really solve this problem since
there is still the question of what a "full" 3315 client does when it
fails to receive a response to Solicits or receives advertises that no
addresses are available. 

Though having one bit (saying run DHCPv6) does help as it simplifies the
problem about what M=1 and O=0 means.

Thus, I would suggest we:
- Have one bit that says "run DHCPv6". If the client is stateful, it
does "full" 3315". If the client is stateless (3736), it does stateless
only.
- Have the DHC WG publish a draft to properly define the behavior of
clients (and servers) when stateful service is not available and only
stateless is available. IE, when should a client switch to using
Information-Request or should all servers support Solicit and should an
Advertise be able to carry "other configuration" options when addresses
are not available. (Or perhaps there are other options to be
considered.)

- Bernie

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Bound, Jim
> Sent: Tuesday, May 24, 2005 11:13 AM
> To: Thomas Narten; [email-masked]
> Subject: RE: purpose of m/o bit
> 
>  
> > Does the community feel that operators need RA bits that
> > control/indicate whether a client is to invoke DHC? That 
> is, is there
> > a need for the sys admin to signal to client whether DHC is to be
> > invoked?
> 
> yes.
> 
> > 
> > Second, is it important that such a signal be honored by clients?
> > (That is, if clients end up mostly ignoring the flags, does their
> > presence become useless?)
> 
> That is not our business but yes I believe the market and clients will
> honor them as requirement from the organizations policy using stateful
> or other config info.
> 
> > 
> > For example, should the sys admin be able to say "do not run DHC,
> > doing so wastes local resources and won't get you any config info"?
> > (And should that be honored by clients?)
> 
> Sure just don't set the current bits in RAs.
> 
> > 
> > Fundamentally, it is only the access network that has knowledge of
> > whether running DHC is useful. Thus, by default, clients (arguably)
> > can't know whether running DHC is useful, so by default they shold
> > invoke DHC (unless the sys admin signals "don't invoke DHC").
> 
> I think the m or o bit will be the decision policy point. 
> 
> > 
> > Or (switching the argument), by default, client should not 
> invoke DHC,
> > unless the local sys admin indicates doing so is appropriate.
> 
> Corrrect same as question above.
> 
> > 
> > If we can't agree that the above is necessary (i.e., is a "problem
> > statement" of sorts), I really have to wonder what purpose the R/A
> > bits can serve or whether we will ever have a shared 
> understanding of
> > what they are supposed to do. Having them be a hint (that clients in
> > practice ignore half the time) would seem to solve no useful purpose
> > (IMO) and would provide the sys admin with useless tools (since
> > clients wouldn't respond to the usage of the tool in predicatable
> > ways). The result would simply be more confusion. (Oh, that 
> is already
> > the state we are in!!! :-))
> 
> We agreed on this years ago.
> 
> /jim
> > 
> > So, what is it? 
> > 
> > Thomas
> > 
> > 
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [email-masked]
> > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> > 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 

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

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 25 May 2005 11:09:34 +0900

>>>>> On Tue, 24 May 2005 11:35:41 -0400, 
>>>>> "Bernie Volz (volz)" <[email-masked]> said:

> likely generate complaints to the network administrators fairly quickly)

I agree.  While I have repeatedly mentioned the latter case, I
actually don't care about the case where a client cannot get addresses
via DHCP due to incorrect M/O flags and/or misconfigured DHCPv6
servers.  In this case, the user can do nothing but complain to the
administrator.

I'm more concerned about the case you mentioned in the succeeding
lines (below), and it looks we are in some level of agreement.

> discussed several proposals but I don't think we've closed that

Exactly.  This is one of my major concerns, which I've been trying
to address through the mo-flags draft with my co-authors (although we
may not have been convincing enough in that work so far).

> are not available. (Or perhaps there are other options to be

If we can get the DHC draft soon (it's okay even if it's just an I-D),
I think this is a reasonable approach.  But since this (the first
bullet more specifically) clearly results in a "backward-incompatible"
change, we'll need a meta-level agreement for this approach.  (In
particular, we should consider how this affects the rfc2461bis work as
an urgent issue)

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

---

From: "Soohong Daniel [email-masked]" <[email-masked]>
Date: Wed, 25 May 2005 12:15:10 +0900

> failover to stateless at some point (and does it continue to 
> do stateful in the background), or? These areas that are not well 
> documented in the DHCPv6 specifications (3315 + 3736) and we 
> need to clarify. We've discussed several proposals but I don't think 
> we've closed that discussion.

Exactly,

> Information-Request or should all servers support Solicit and 
> should an Advertise be able to carry "other configuration" options 
> when addresses are not available. (Or perhaps there are other options 
> to be considered.)

As Jinmei pointed out, we should consider *backward-incompatibility*
proir to saying any alternatives. We should make sure that is not a trivial 
consideration. 

---------------------------------------------
Daniel (Soohong Daniel Park)
Mobile Platform Laboratory, SAMSUNG Electronics.