dhcpd sending on the same IP it receives on
p.mayers at imperial.ac.uk
Tue Feb 5 22:45:32 UTC 2008
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
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
More information about the dhcp-users