DHCP relay IP and gateway IP, possible bad logic?

[Alan DeKok]

Phil Mayers wrote:
> Perhaps I've misunderstood, but this doesn't reflect the DHCP behaviour
> I've seen on "normal" clients.

  It's possible.

> As far as I know, it goes (starting from INIT, as opposed to INIT-REBOOT
> which effectively starts from step 4):
> 
>  1. Client sends DISCOVER to broadcast
>  2. NAS forwards to server; giaddr==1, srcip==2
>  3. Server sends DHCPOFFER; dstip==giaddr, server_id=$SERVER
>  4. Repeat 1-3 with DHCPREQUEST/ACK
>  5. Client comes to t1 - unicast DHCPREQUEST dstip=$SERVER
>  6. If no reply, at t2 - broadcast DHCPREQUEST

  Yes.

> i.e. AFAIK, the client *always* sends packets to broadcast or to the
> server ident (DHCP option 54). Note the latter is mandatory in all DHCP
> replies.

  That's the usual practice... but some clients may be weird.

> There are a bunch of subtleties in this whole area - some devices offer
> knobs to control giaddr in the case of multinettings, and some devices
> offer knobs to control srcip - but, in my experience, you are asking for
> trouble if giaddr is not valid for accepting relayed replies. We've had
> significant problems with setups where this is difficult or impossible
> to achieve as a result. Multinetting a private and public range onto the
> same interface falls into exactly that category.

  Yes.

  Maybe I got parts of the explanation wrong, but the DHCP handling of
giaddr is just weird.

  Alan DeKok.