Subject: [homenet] HNCP interaction with DHCP

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 06 Jul 2015 13:01:36 +0200

Markus, Steven,

When we assign a v4 prefix to a common link, we elect a designated DHCPv4 
server.  As Markus has explained to me, this is done to avoid sharing 
state between multiple DHCPv4 servers on a single link, which makes sense.

What default routes should be announced to v4 clients?  Just the one 
through the node serving as DHCPv4 server (and count on Redirects to 
optimise routing), snoop on the routing protocol and choose the best 
default router according to the routing protocol, or announce all the 
routers on the local link and trust the host to choose wisely?

(On a related note, do you think that it is wise to snoop on the routing 
protocol and build something similar to the example in RFC 4191 Section 3.6?)

What happens when a new router appears on the link, a new election is 
called, and the new router becomes the designated DHCPv4 server -- won't 
address collisions occur?  Perhaps DHCPv4 service should be "sticky", in 
the sense that a new election isn't called if the previously elected 
server is still alive.

(With stateful DHCPv6, we could perhaps do something with RECONFIGURE, 
although I'm not sure if RECONFIGURE is able to force the client to choose 
a different server.)

-- Juliusz

---

From: Steven Barth <[email-masked]>
Date: Mon, 06 Jul 2015 13:24:22 +0200

> What default routes should be announced to v4 clients?  Just the one through the node serving as DHCPv4 server (and count on Redirects to optimise routing), snoop on the routing protocol and choose the best default router according to the routing protocol, or announce all the routers on the local link and trust the host to choose wisely?
>
> (On a related note, do you think that it is wise to snoop on the routing protocol and build something similar to the example in RFC 4191 Section 3.6?)
>

This is what HNCP mandates: https://tools.ietf.org/html/draft-ietf-homenet-hncp-07#section-7.4
So most of what you mentioned was left out for the sake of simplicity.

Now that I think of it we should probably add a MUST for a classless route for the IPv4 "delegated" prefix,
at least in case there is no default route.

> What happens when a new router appears on the link, a new election is called, and the new router becomes the designated DHCPv4 server -- won't address collisions occur?  Perhaps DHCPv4 service should be "sticky", in the sense that a new election isn't called if the previously elected server is still alive.
We had this discussion already months ago I think. From what I remember "stickiness" would solve this particular use case,
but opens up others instead in case of e.g. merging or splitting links. I'm not sure if that discussion was on the list so you may find
it in the archives or not. IIRC it boiled down to making one case worse in favor of another with added complexity on top.

> (With stateful DHCPv6, we could perhaps do something with RECONFIGURE, although I'm not sure if RECONFIGURE is able to force the client to choose a different server.)
I only know of two implementations of dhcpv6 reconfigure on the client side so far, one is odhcp6c, the other is dhcpcd.
Maybe this has changed meanwhile but to my knowledge nobody really does it. Funny enough RFC 7084 mandates it for routers
on the client side, but I don't know how well that mandate is followed. Similarly I have yet to see a second (open source?)
implementation of reconfigure on the dhcpv6 server side.

Cheers,

Steven

---

From: Markus Stenberg <[email-masked]>
Date: Tue, 7 Jul 2015 08:01:27 +0200

> it in the archives or not. IIRC it boiled down to making one case worse in favor of another with added complexity on top.

I do not think the discussion was public, but yes, the gist is correct; 
there is a tradeoff between complexity and addressing one corner case 
while making some marginally worse. We assume relatively stable 
topology, and for that case at least, stickiness does not seem worth it.

(For the record, in internal discussions, I was originally 'for' 
stickiness but got convinced otherwise.)

Cheers,

-Markus