Subject: Re: [dhcwg] [homenet] What to do when we lose DHCPv4 election?

From: Michael Richardson <[email-masked]>
Date: Sun, 16 Aug 2015 21:05:03 -0400

Juliusz Chroboczek <[email-masked]> wrote:
    > 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, but I have two questions.

1) do Homenet-aware DHCPv4 servers pick the same rfc1918 address spaces to
   give out?

2) if a DHCPv4 server previously had given out leases, and the lease is still
   valid, then I think that it ought to ACK a DHCP renew.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 17 Aug 2015 12:23:25 +0200

>> When a Homenet router was previously acting as DHCPv4 server for
>> a link, and subsequently loses an election, should it:

> 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.

> 1) do Homenet-aware DHCPv4 servers pick the same rfc1918 address spaces to

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.

>    valid, then I think that it ought to ACK a DHCP renew.

What if the prefix got renumbered, and the address is no longer being routed?

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 17 Aug 2015 12:25:50 +0200

> I think that #2 is probably correct, but I have two questions.

By the way, if some Wise Person were kind enough to check my DHCPv4
server for compliance, I'd be very grateful.  The code is here:

    https://github.com/jech/shncpd/blob/master/dhcpv4.c#L663

---

From: Steven Barth <[email-masked]>
Date: Mon, 17 Aug 2015 13:46:34 +0200

> requests are no longer onlink?  I'd like a precise reference, if that's
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.

> 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.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 17 Aug 2015 13:54:00 +0200 (CEST)

> as a generic recommendation.

Yes, I think this makes the most sense as well.  The only other way of 
solving this would be for all routers capable of becoming HNCP Designated 
Router for the Common Link would keep all kinds of state between them (for 
instance DHCP leases), and while this would be nice, I see this as a huge 
complication that is probably not worth doing?

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Mon, 17 Aug 2015 11:50:16 -0400

> server for each link works around the issue.

Yes... but...  don't kill connections that don't need to be killed.

    > What if the prefix got renumbered, and the address is no longer being

Those are really three questions.

1) if the v4 prefix on the link is renumbered because a different router
   won the election, then the existing router may still have connectivity,
   and may still be willing to route packets.
   (b) - there may be static IPs assigned, and there may even be port
         forwards which are linked to that first router.

2) if the v4 prefix on the link is renumbered for a different reason, but
   the router still can route/NAT packets, then it should NAK the renew.
   (b) if the v4 prefix on the outside (WAN) is not the same, then the NAT
       sessions are dead anyway, so might as well NAK the packet and push
       the host over to the winning router.

3) if the address can no longer be routed at all (no WAN link...) then
   I think it should NAK.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 17 Aug 2015 11:50:52 -0400

> thinking of adding "Routers which seize to be elected DHCP

s/seize/cease/
??

---

From: Steven Barth <[email-masked]>
Date: Mon, 17 Aug 2015 17:53:50 +0200

>     > thinking of adding "Routers which seize to be elected DHCP

Of course. Looks like my English is still in vacation mode ;)

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 17 Aug 2015 17:57:29 +0200

>    and may still be willing to route packets.

The old prefix is no longer announced over the routing protocol, so the
old addresses are unreachable now.  (Or are you suggesting that we announce
host routes for unexpired IPv4 leases?  I'm not sure I like redistributing
DHCPv4 into Babel.)

-- Juliusz

---

From: Michael Richardson <[email-masked]>
Date: Mon, 17 Aug 2015 13:43:28 -0400

> forwards which are linked to that first router.

To clarify, there may be static leases, where DHCP has been told to give
out the same IPv4 to the same host consistently.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 17 Aug 2015 13:45:44 -0400

> old addresses are unreachable now.  (Or are you suggesting that we

That's not entirely true.  Nodes on the same link (such as 99% of current
home setups) don't need the routing protocol to reach things.

My point here is not to break how IPv4 works in a typical setup.
(You may argue the word "works" above...)

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 17 Aug 2015 20:09:21 +0200

> home setups) don't need the routing protocol to reach things.

It doesn't matter -- the old prefix is no longer applied to the link, so
in order to route to the hosts with the old addresses, I'll need to
install host routes.  And if I install them, I might as well announce them
over the routing protocol -- it's actually less code than filtering them
out.

I guess it could be done, but I'm not sure what consequences it would
have, especially if the old prefix is reused by a different link.

-- Juliusz

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 21 Aug 2015 16:55:39 +0000

Typically a server would grant the requested address in the DHCPREQUEST unless there was a reason it could not, for example:
- Address is no longer valid for the network segment
- Address is in use by another device

It is probably best NOT to NAK something unless there is a good reason to.

Note: The DHCPREQUEST here would most likely end up being a INIT-REBOOT or a REBIND -- RENEWs are unicast to the server so those might not be seen (unless the DHCP server has been replaced with a device at the same address - in which case, the above policy works nicely).

- Bernie

-----Original Message-----
From: dhcwg [mailto:[email-masked]] On Behalf Of Juliusz Chroboczek
Sent: Monday, August 17, 2015 6:26 AM
To: Michael Richardson
Cc: dhcwg; Homenet
Subject: Re: [dhcwg] [homenet] What to do when we lose DHCPv4 election?

> I think that #2 is probably correct, but I have two questions.

By the way, if some Wise Person were kind enough to check my DHCPv4 server for compliance, I'd be very grateful.  The code is here:

_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg