Subject: Re: dhcpd(8) _cannot_ be completely disabled on an interface
To: Steven M. Bellovin <firstname.lastname@example.org>
From: Bill Squier <email@example.com>
Date: 01/09/2002 14:30:28
On Mon, Jan 07, 2002 at 07:27:47PM -0500, Steven M. Bellovin wrote:
> In message <20020107191756.A492@noc.untraceable.net>, Andrew Brown writes:
> >>> >It doesn't matter. The client is required to put its MAC address in
> >>> >the dhcp packet payload so it is always available there.
> >>> certainly, but i've often found it more informative to look at the
> >>> ethernet header itself to find out exactly where packets are coming
> >>> from.
> >>Since an dhcp can come from a relay agent, the mac address itself
> >>isn't interesting.
> >i was considering that, and thinking that the response from the server
> >should be sent back to the relay instead of to the hardware address as
> >specified in the dhcp message itself...
> Not just "should" -- must. If there's a relay agent, the server and
> client are probably on different networks; sending to the hardware
> address of the client won't work. This is discussed in 2131.
It's just slightly nasty in one particular case with which I am all too
familiar. The server is required to send to the 'giaddr', which is an IP
address of the interface on which the relay received the packet. There are
several situations in which that address is not routeable from the server,
but the interface from which the server received the relay packet is.
We use a special purpose hack in this case, and if I'm not mistaken, I was
able to prod Ted into prodding Ralph to make DHCPv6 return the reply to the
source address of the relayed request instead of the 'giaddr'.
I admit to being remiss in reading the latest v6 draft.
Bill Squier (firstname.lastname@example.org) http://www.netbsd.org
I know I don't deserve another chance, but this _is_ America,
and as an American, aren't I entitled to one? --Sideshow Bob.