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 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
