Subject: [dhcwg] Last Call: 'DHCP Server Identifier Override Suboption' to Proposed Standard

From: The IESG <[email-masked]>
Date: Wed, 01 Feb 2006 14:30:10 -0500

The IESG has received a request from the Dynamic Host Configuration WG to 
consider the following document:

- 'DHCP Server Identifier Override Suboption '
   <draft-ietf-dhc-server-override-03.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[email-masked] or [email-masked] mailing lists by 2006-02-15.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-dhc-server-override-03.txt

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

---

From: "David W. Hankins" <[email-masked]>
Date: Tue, 7 Feb 2006 14:24:29 -0800

I'm still at odds with this draft.

It muddies the meaning of the giaddr without offering a replacement.

Currently, giaddr is an easy way to say 'hey, this client broadcast
this request!'  That's important in understanding wether or not the
client is renewing or rebinding, and wether it is appropriate (from
how I read RFC2131) for the response to be a NAK or ignorance.

Literally, the logic in all currently released forms of ISC DHCP
uses the logic:

	(ciaddr && giaddr) || (!ciaddr && client_requested_address)

To determine wether the client is suitable to be NAKed or should be
left alone (to NAK upon REBIND rather than RENEW).

There is no guidance in the draft how a server implementation should
now reform this logic to detect the remote-client state as RENEW or
REBIND (even "probably").

The original author of this logic (Ted Lemon) has written a four page
comment in our sources on the topic, which my brief summary here barely
does justice.

To not muddy the meaning of the giaddr, the relay must supply a
new field to identify wether the client packet is broadcast or
unicast.

It puts renewal overhead into replication, the way I read it.

A relay implementing this draft that forwards to more than one dhcp
server will produce duplicate renewal requests and forward them to each
server.  Today only one server gets the renewal request.

Not only is this an increase in overhead, but it obviates LBA.

Essentially, in LBA, all REQUESTs must be answered if the server is
capable of doing so.  At least, that is my estimation of the facts,
having software that implements it.

If a client is RENEWING, one of the two failover servers is expected
to be the only one to hear it, so whichever server heard it has to
answer (or relegate the client to REBIND later).

If a client is REBINDING, it might be out of communication with the
other server (LBA's "max 'secs'" has kicked in), so there's no
point in waiting to serve it.

Fundamentally, the only thing that decides load balancing when using
LBA on a failover pair is what state the lease is in.

If it is FREE or BACKUP, only the primary/secondary respectively must
answer.  If it is ACTIVE, both will answer.

This is the present state of things, and is the best way I can see
around problems we've had using any other mechanism.

You really need to instruct relays to participate in the state engine
and remember the server identifier somehow (if not by the client) so
only one server is queried.

And I'm really not comfortable with that idea.

I think implementations of this draft as it stands is going to create
new forms of pain in general.

I would like to see some discussion to the contrary on these issues.

I don't remember there being a WG last call on this.  I guess I missed
it.

Sorry.

-- 
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