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