Subject: RE: draft-ietf-ip1394-dhcp-01.txt

From: "HIBBS, BARR (PB)" <[email-masked]>
Date: Wed, 23 Jun 1999 16:33:40 -0400 (EDT)

Kim, Ted, et al.--

I expect that many servers would require modification for this case, and I
wonder if it might be better to specify that instead of a null chaddr, some
unique octet string be used, much like Microsoft inserts a string in packets
for RAS requests?

Of course, I don't know if the EUI-64 identifier suggested by the draft is
sufficiently unique for this purpose, but if it is it would seem a likely
candidate.

> 	My understanding is that if there is no client-identifier
> 	in a packet, then the chaddr/hlen/htype -> MAC address is
> 	used as the "identity" of the client for the purposes of
> 	giving out an IP addresss lease.  However, if there *is*
> 	a client-identifier, then it MUST be used as the "identity"
> 	of the client.  In this second case, the actual value
> 	of the MAC address doesn't matter, and it is perfectly
> 	reasonable for them to be all the same, since it will
> 	not be used as the identity of the client.
> 
> 	I was proposing the change I suggested because I believe
> 	that there are no clients today that do not give a valid
> 	MAC address even *if* they use a client-identifier, and
> 	that the RFC isn't too clear on whether they need to specify
> 	a chaddr or not if they use a client-identifier.  
> 
My understanding is a bit different from yours, Kim...  I believe that the
client identifier is preferred over any other means of identifying a lease
(such as MAC address, IP address, or hostname--which my support people
insist on using!), but is not exclusively used instead of, say, chaddr.

But as for the impact on various server implementations, in my case if
chaddr were "missing" I simply wouldn't try to index the lease using it,
just as I don't index the lease on client identifier or hostname if they are
missing.  I would have to add another rule that requires a client identifier
if chaddr is null, but that is not really any different than requiring
certain other fields to be present or absent based on received options and
message type.

Maybe we do need some editorial changes in the RFCs as well.

--Barr