DHCP Relay serving clients on the same network as a DHCP server?

[David W. Hankins]

On Sun, Feb 14, 2010 at 05:59:08PM +0000, Simon Hobson wrote:
> Thinking about it, IIRC the client uses a different socket to the server - 
> so is it possible to just filter inbound packets from a client on the DHCP 
> Server facing interface so it can receive the traffic from the server but 
> ignores clients ?

Yes, for example the DHCPv6 relay agent already has an "upstream" and
"downstream" segregation; it understands to listen for client packets
on the downstream side, and only insists on necessary socket
information to pass packets "upstream" and receive the replies.  This
is partly because of how DHCPv6 is different in its use of link local
addresses and link-local multicasts.  We hope to leverage the same
command line interface in addressing this suite of issues with the
DHCPv4 relay.

Unfortunately our underlying DHCPv4/IPv4 socket code, which is used by
the client, relay, and server commonly, has some limitations I've been
wanting to correct (so that in some circumstances we don't have to
keep a raw socket open), and this is one of them.

In theory the right thing would be for the relay agent to open a raw
socket on all client-facing interfaces, and open a plain old BSD UDP
socket both to transmit forwarded packets to the server, and to
receive all replies.

That said, right now (and certainly as far back as 3.0pl2, sheesh!),
we do not do that...so the duplicate packets are an unfortunate
requirement.  They really should not be /damaging/ however since DHCP
packet load is quite small, and clients should deal well with
duplicate answers.

The only tricky situation you get into is if DHCP client renewals are
transiting (routed through) the same system as the relay agent.  In
this case, the relay can get confused and forward three copies of the
client's packet (the client's unicast packet, a forwarded copy the
relay receives on the ingress interface, a forwarded copy of the
client's unicast packet that is received by the relay as it is sent
to the egress interface...).  A temporary workaround until we can
address the socket interface issues is to play games with the
'server-identifier' option - set it to the relay agent's client-facing
interface, in a scope limited to the subnet (or shared network).

-- 
David W. Hankins	BIND 10 needs more DHCP voices.
Software Engineer		There just aren't enough in our heads.
Internet Systems Consortium, Inc.		http://bind10.isc.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20100218/f818e00b/attachment.bin>