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

["Bound, Jim" <jim.bound at hp.com>]

hmmm I wonder if part of the confusion is for prefix delegation to
happen maybe that should be signaled by the m bit.  The o bit or its
function should be pristine to mean only use dhc for configuration data
like dns, link information, services information etc.

when m bit set it is client/server implementation defined by admins for
dhc whether stateless dhc is used or full dhc?

/jim 

> -----Original Message-----
> From: dhcwg-bounces at ietf.org [mailto:dhcwg-bounces at ietf.org] 
> On Behalf Of Bound, Jim
> Sent: Friday, May 27, 2005 12:32 PM
> To: Ralph Droms; matthew.ford at bt.com
> Cc: dhcwg at ietf.org; ipv6 at ietf.org
> Subject: RE: [dhcwg] RE: purpose of m/o bit
> 
> m == use dhc for addresses, o == use dhc for just configuration bow do
> you do this with one bit? neither m or o not set says don't use dhc.
> thus my reason for ternary.
> 
> thx
> /jim 
> 
> > -----Original Message-----
> > From: dhcwg-bounces at ietf.org [mailto:dhcwg-bounces at ietf.org] 
> > On Behalf Of Ralph Droms
> > Sent: Friday, May 27, 2005 8:59 AM
> > To: matthew.ford at bt.com
> > Cc: dhcwg at ietf.org; ipv6 at ietf.org
> > Subject: [dhcwg] RE: purpose of m/o bit
> > 
> > Mat - thanks for your review and input.  I specified the 
> two bits only
> > for backward compatibility with existing implementations.
> > 
> > I imagine we could design a specification that retains one bit and
> > deprecates the other, with rules about the appearance of the depre
> > backward compatibility.  At least, this spec would need a note
> > explaining why there are two bits in the spec and 
> > recommending that new
> > implementations use, for example, just the M bit.
> > 
> > - Ralph
> > 
> > On Fri, 2005-05-27 at 13:41 +0100, matthew.ford at bt.com wrote:
> > > Ralph Droms <rdroms at cisco.com> wrote:
> > > 
> > > > Seems to me I'm hearing two requirements out of this thread:
> > > > 
> > > > 1) Ability to indicate to a host "DHCP is not available 
> > on this link",
> > > >    with the expectation that the host won't send any 
> DHCP messages
> > > > 
> > > > 2) Ability for a host to get all desired and available DHCP
> > > >    configuration with a single DHCP message exchange
> > > >    - if a host wants HCB, it sends an HCB request (Solicit)
> > > > and receives
> > > >      HCB and/or ICB replies
> > > >    - if a host wants ICB, it sends an ICB request
> > > > (Information-request)
> > > >      and receives ICB replies
> > > > 
> > > > 1 is a requirement in scenarios with limited resources (e.g.,
> > > > wireless), where polling for DHCP is unacceptable.  2 is a
> > > > requirement to avoid timeout delays or other complexity 
> in getting
> > > > ICB reply when 
> > > > host would
> > > > prefer HCB reply.
> > > > 
> > > > If I've got that right, we can meet the two requirements 
> > with a couple
> > > > of small updates to existing specs:
> > > > 
> > > > 1) If an RA is received with the M and/or the O bit is set, DHCP
> > > >    service is available over the link through which the RA
> > > > was received
> > > >    (no differentiation between HCB and ICB DHCP)
> > > > 
> > > > 2) If a DHCP server receives an HCB request (Solicit) 
> but can only
> > > >    supply an ICB, the server can respond with the ICB 
> > reply (note that
> > > >    according RFC 3115, the server would respond with an 
> "HCB-nak"
> > > >    [Advertise containing only an error code])
> > > > 
> > > > In addition to meeting the requirements, these updates 
> > are mostly (if
> > > > not entirely) operationally compatible with existing clients and
> > > > servers. 
> > > 
> > > I completely agree with this analysis and support 
> proceeding on this
> > > basis. But it does beg the question, why do we need two 
> > bits to signal a
> > > binary condition?
> > > 
> > >  -- Mat
> > 
> > _______________________________________________
> > dhcwg mailing list
> > dhcwg at ietf.org
> > https://www1.ietf.org/mailman/listinfo/dhcwg
> > 
> 
> _______________________________________________
> dhcwg mailing list
> dhcwg at ietf.org
> https://www1.ietf.org/mailman/listinfo/dhcwg
> 

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 at ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------