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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of Bound, Jim > Sent: Friday, May 27, 2005 12:32 PM > To: Ralph Droms; [EMAIL PROTECTED] > Cc: dhcwg@ietf.org; ipv6@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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > On Behalf Of Ralph Droms > > Sent: Friday, May 27, 2005 8:59 AM > > To: [EMAIL PROTECTED] > > Cc: dhcwg@ietf.org; ipv6@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, [EMAIL PROTECTED] wrote: > > > 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 > > > > _______________________________________________ > 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 --------------------------------------------------------------------
