Re: [dhcwg] dhc WG last callon draft-ietf-dhc-relay-id-suboption-00.txt

["Bernie Volz (volz)" <volz at cisco.com>]

Wow. I don't really understand how you read that, but if you did, then
yes, this draft certainly needs some work!

I don't understand where the manufacturing the client's identifier
entered into the picture.

The point of that introduction was to say that a UNIQUE identifier for a
client might be formed using <relay-id><relay-port-id> -- such as for a
factory floor where a robot plugged into port 6 of switch xyz would
always be welding the door to the car regardless of what the
client-identifier or mac address is. Thus, you'd want to assign it the
"weld door to car" robot IP address.

There are already relay agent suboptions to identify the port
(remote-id, circuit-id). There isn't anything to unique identify the
relay (giaddr *might* be usable, but it has other purposes too and so is
dangerous and it is related to the network topology - for the relay
address on the server side, not the client side of the network).

Once generated, the relay-id would be stable. The remote-id/circuit-id
for a particular port would also. And, the server is expected to use the
relay-id/<remote-id or circuit-id> to identify the client in the server
-- not the client-id or mac-address.

---

There are other uses of this relay-agent id suboption -- such as the
DHCPv4 bulk leasequery work.

- Bernie

-----Original Message-----
From: dhcwg-bounces at ietf.org [mailto:dhcwg-bounces at ietf.org] On Behalf
Of David W. Hankins
Sent: Monday, September 08, 2008 5:19 PM
To: DHC WG
Subject: Re: [dhcwg] dhc WG last callon
draft-ietf-dhc-relay-id-suboption-00.txt

On Mon, Sep 08, 2008 at 03:47:44PM -0400, Ralph Droms wrote:
>
http://www.ietf.org/internet-drafts/draft-ietf-dhc-relay-id-suboption-00
.txt

The draft mentions in Introduction the use of the field in identifying
the client instead of the client-identifier or the chaddr field.

It doesn't seem to address or suggest server behaviour when a client
is RENEWING.  All the server would have at this stage is any identity
the client offers, which is sure to mismatch any relay-agent supplied
value, which is what the lease binding is suggested to be identified
against.

I think in particular the advice to generate a DUID for the client to
put in this field is a potentially misleading default, as for example
it would be fairly bad for a relay to manufacture a new DUID-LLT every
time it sees a given client.  I know of no reason why this would be
considered beneficial; presuming the client supplies a DUID, it would
always be preferrable.  If there is some beneficial reason for A
DUID-like identifier to be manufactured by a relay, perhaps it could
be described.

I think this draft could use some more work before going to IESG.

-- 
Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
Why settle for the lesser evil?	 https://secure.isc.org/store/t-shirt/
-- 
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
dhcwg at ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg