dhcpd sending on the same IP it receives on

[Phil Mayers]

sthaug at nethelp.no wrote:
>> If host A sends a packet to host B, it will expect to receive the
>> response from host B's IP address (the IP it sent the packet to).
> 
> No, it's not that simple. In the case of TCP you have a *connection*,
>  and you would expect to receive the response from the IP address you
>  have *connected* to in the first place.
> 
> In the case of UDP, you would normally expect to receive the response
>  from the "closest" interface, *unless the application has taken care

What is "normally"? As you point out, DNS (by far the most commonly used 
UDP application) doesn't do that, for various reasons. I think replying 
from the IP (socket) you got the request on is best for reasons of 
"least surprise", not to mention things like RPF filtering and stateful 
firewalls.

Another example: >1 IP on a single interface (e.g. using a "service" IP, 
and failover such as VRRP to a standby server). You don't want the DHCP 
reply coming from the servers "real" IP; you want it from the floating 
virtual IP. That is more easily worked around (on Linux at least) by 
setting the source IP on the 0/0 route, but still...

>  to bind a separate file descriptor for each interface* (BIND for 
> instance does this).

I think it's pretty clear ISC DHCP has sub-optimal behaviour, because it 
CANNOT be made to work in these scenarios. The solution is simple 
(though implementation may not be):

  1. An application should reply down the same file descriptor it 
received the packet on

  2. Applications MAY default to opening a single socket bound to 
INADDR_ANY, but SHOULD have the option of binding to one or more 
specific IPs, one socket per IP