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

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Fri, 27 May 2005 08:56:27 -0400

We don't but it avoids issues with backwards compatibility (though I
don't believe that is a big issue yet).

I think if we come to agreement on having no distinction between the
bits, we should deprecate one of the bits (O-bit?); though for backwards
compatibility, we can't remove/reassign it until many years from now (if
ever).

- Bernie

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of [email-masked]
> Sent: Friday, May 27, 2005 8:42 AM
> To: Ralph Droms (rdroms); [email-masked]; [email-masked]
> Subject: [dhcwg] RE: purpose of m/o bit
> 
> Ralph Droms <[email-masked]> 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
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dhcwg
> 

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

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 27 May 2005 15:07:20 +0200

> compatibility, we can't remove/reassign it until many years from  

I think having M = 0, O = 1 would be useful as an indication that  
clients should use the simplified stateless DHCPv6 rather than the  
full DHCPv6.

And I would object to any deprecation on the basis that there isn't  
enough operational experience to be able to make a good decision.