Subject: RE: purpose of m/o bit

From: "Bound, Jim" <[email-masked]>
Date: Tue, 24 May 2005 12:10:56 -0400

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-masked]] 
> Sent: Tuesday, May 24, 2005 11:36 AM
> To: Bound, Jim; Thomas Narten; [email-masked]; [email-masked]
> 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-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
> > --------------------------------------------------------------------
> > 
> 

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

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 25 May 2005 11:45:44 +0200

> implying o bit use too.  but that is not stated.

RFC 2462:

                        In addition, when the value of the  
ManagedFlag is
                        TRUE, the value of OtherConfigFlag is  
implicitely
                        TRUE as well. It is not a valid configuration  
for
                        a host to use stateful address autoconfiguration
                        to request addresses only, without also  
accepting
                        other configuration
                        information.