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 PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of [EMAIL PROTECTED] > Sent: Friday, May 27, 2005 8:42 AM > To: Ralph Droms (rdroms); dhcwg@ietf.org; ipv6@ietf.org > Subject: [dhcwg] RE: purpose of m/o bit > > Ralph Droms <[EMAIL PROTECTED]> 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@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
