DHCP relay IP and gateway IP, possible bad logic?

[Phil Mayers]

On 03/04/2013 08:59 PM, Alan DeKok wrote:
> Phil Mayers wrote:
>> Second, "reply to giaddr" is mandated in the DHCP spec; are you *sure*
>> you have "other DHCP servers" which "reply to source ip"? Which servers?
>
>    The issue is that giaddr serves two purposes.  In the request, it
> indicates that the server MUST send the reply to that IP.
>
>    In the reply, it means that the client sends the NEXT request to the
> giaddr.
>
>    ASCII art helps:
>
>
> 	client --> 1  NAS  2 ---> server
>
>
>    The client sends broadcast packets to the NAS, using a private network
>   The NAS unicasts them FROM NAS address "2" to the server, using giaddr
> = 2.  NAS address "2" and the server are on a public network.
>
>    The server knows that the NAS has a private address.  So it sends the
> unicast answer back to NAS address 2", with giaddr = NAS address "1".
>
>    The NAS broadcasts (or unicasts) this response back to the client.
>
>    On a renew, the client unicasts the packet to NAS address "1", which
> forwards it to the server using address "2", and giaddr ==2.

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

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

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.

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.