Bernie, I think your honing down to valid points. I view m bit set implying o bit use too. but that is not stated. /jim
> -----Original Message----- > From: Bernie Volz (volz) [mailto:[EMAIL PROTECTED] > Sent: Tuesday, May 24, 2005 11:36 AM > To: Bound, Jim; Thomas Narten; ipv6@ietf.org; dhcwg@ietf.org > Subject: RE: purpose of m/o bit > > 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 PROTECTED] [mailto:[EMAIL PROTECTED] On > > Behalf Of Bound, Jim > > Sent: Tuesday, May 24, 2005 11:13 AM > > To: Thomas Narten; ipv6@ietf.org > > 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 > > > ipv6@ietf.org > > > Administrative Requests: > https://www1.ietf.org/mailman/listinfo/ipv6 > > > > -------------------------------------------------------------------- > > > > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
