DHCP unicast

[Alexander Mukhin]

On Mon, Apr 30, 2018 at 05:32:30PM +0200, Denys Vlasenko wrote:
> On Sat, Apr 28, 2018 at 11:12 AM, Alexander Mukhin
> <alexander.i.mukhin at gmail.com> wrote:
> > Dear Denys,
> >
> > I have a doubt on your commit a6a3ad327360669e0c12552f680382e3b9713489,
> > when you introduced a requirement that the DHCP Server ID must be
> > directly reachable.
> >
> > Please consider a very common case when a DHCP relay is used. Here, the
> > Server ID will never be a direcly connected address. Your commit
> > effectively breaks any possibility of unicast communications with such a
> > server.
> 
> Well, I see that serverid of 1.1.1.1 is handed out to my machine right now.
> It is clearly bogus. So this does happen in real world.

But because of your bogus serverid you broke a lot of legitimate cases.

DHCP RFC says clearly that

   DHCP clients MUST use the IP address
   provided in the 'server identifier' option
   for any unicast requests to the DHCP server.

but nowhere says that the serverid must be directly reachable.

Routed serverids also happen in real world, and probably much often than
bogus serverids. As I've said, this will be so if a DHCP relay is used,
which is a common case for large networks.

I'm also a victim of such a case. After your commit, any kind of unicast
communications with the DHCP server stopped. The DHCP client tries
several times to send a unicast renew, then gives up and sends a
broadcast. So, it basically works, although via broadcasts only. But the
feature of sending a DHCP release on exit is broken completely, because
a release must be sent in unicast. So, I had to patch dhcpc and remove
MSG_DONTROUTE flag.

The problem of bogus serverids could be solved in a number of ways. For
example, if you worry that packets to a bogus serverid are routed via
another interface, this can be fixed in the DHCPC hook script by adding
a static route to the serverid:

    ip route add $serverid via $router

So, I ask you to change your mind and revert that commit. There
definitely exist more complete and correct solutions for the problem.

-- 
Kind regards,
Alexander.