Am 17.08.2015 um 12:23 schrieb Juliusz Chroboczek:
>>> When a Homenet router was previously acting as DHCPv4 server for
>>> a link, and subsequently loses an election, should it:
>
>>> 1. remain silent;
>>> 2. remain silent in response to DHCPDISCOVER, but NAK any DHCPREQUEST; or
>>> 3. NAK both DHCPDISCOVER and DHCPREQUEST?
>
>> I think that #2 is probably correct
>
> Thanks. What after a renumbering event and the addresses that the client
> requests are no longer onlink? I'd like a precise reference, if that's
> okay.
At first glance all 3 behaviors seem sensible, while 2 and 3 look more
preferable.
However I do not particularly remember all the implications. In any case I'm
thinking of adding "Routers which seize to be elected DHCP
servers SHOULD - when applicable - invalidate remaining existing
bindings in order to trigger client reconfiguration."
as a generic recommendation.
>
>> 1) do Homenet-aware DHCPv4 servers pick the same rfc1918 address spaces to
>> give out?
>
> Not necessarily -- if there are multiple prefixes assigned to the link,
> the spec doesn't say which prefix is used by each server. (Shncpd uses
> them all, which I'm not sure is a good idea.) Electing a single DHCPv4
> server for each link works around the issue.
There is only one IPv4 "delegated" prefix at a time in an HNCP network.
"In case multiple IPv4
prefixes are announced, only the one published by the node with
the highest node identifier is kept among those with a Prefix
Policy of type 0 - if there is any."
So as long as the Assigned Prefix for a link does not change the DHCPv4
pools stays the same. Individual DHCPv4 servers might use different
algorithms to assign addresses from within the pool.
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet