Subject: Re: [dhcwg] I-D ACTION:draft-ietf-dhc-server-override-03.txt

From: "David W. Hankins" <[email-masked]>
Date: Wed, 9 Nov 2005 00:22:31 +0000

Since this isn't on the agenda this week, I wanted to comment on this
again before I forget.

Sadly I must tell a war story first.

Recently I had the misfortune to have to consider deeply how some aspects
of our implementation work, specifically in regards to sensing which
network the client is attached to.

The reference case that's causing me sleepless nights is a DHCP server
with a large number of 802.1q vlans all on a single physical interface.
The DHCP server has the same MAC address on all these broadcast domains.
A client can move between these vlans and, either at renewal or early
broadcasted renewals due to sensing the link status change, can
successfully unicast its DHCPREQUEST to the server.  Something we
assume fails if you change networks.

Our implementation waffles on wether or not a DHCPREQUEST was unicast
or broadcast...not all of the IO subsystems that can deliver packets
to our server for processing have the power to tell us which it was,
so we punt on the issue and assume all DHCPREQUESTS were unicast, and
therefore we must answer all DHCPREQUESTs be it ACK or NAK.

The one thing our server /can/ agree on:  If giaddr was set, it was
broadcast.

Unicast/broadcast becomes important more in just knowing wether or not a
failover peer, for example, also received the message and can respond, it
tells us wether or not we can believe the client is attached to the right
network.  A DHCPREQUEST that was unicast to us may very well come in the
wrong interface, and the client may very well be attached to the right
network still.  A DHCPREQUEST that was broadcast, and is on the wrong
physical interface, should probably get a NAK.

But currently, our implementation will only supply a NAK if the giaddr
was set and is not appropriate for the address the client is requesting.
The giaddr is taken as gospel that the client broadcast its request.

Now switch that reference case from a server to a relay.  Who is
responsible to detect client attachment, and how is that processing
acheived?

So this draft is partially changing the interpretation of giaddr...now it
is set not only when the client broadcasts, but also when it unicasts.  The
server has no way of distinguishing between the two.

I think for this draft to address this client attachment problem, it would
have to mandate that relays emit DHCPNAKs.

I'm not sure I like going there.

-- 
David W. Hankins		"If you don't do it right the first time,
Software Engineer			you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg