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

From: "Henry, Mike" <[email-masked]>
Date: Wed, 7 Jul 1999 19:30:31 -0400 (EDT)

I'm not quite sure where to jump in here as there are a couple of
interesting entry points, but, here goes....

First, it seems like the requirement for the 1394 device to use EUI-64 as
the Client ID would be a problem if the 1394 device was ever expected to use
authenticated DHCP messages, as it would then also need to use a UUID Client
ID instead of it EUI-64 ID for those transactions. The authors of
Authentication for DHCP Messages <draft-ietf-dhc-authentication-10.txt>
(sect. 5.5.1) propose using a UUID type of client ID
<draft-henry-DHCP-opt61-UUID-type-00.txt> as a means for the client to ID
itself to the DHCP service . 

One suggestion would be for 1394 to use a UUID Client ID rather than a
EUI-64 Client ID.

Besides solving this particular problem, we think it would be very useful in
general to establish a truly universal identifier that could be universally
used as a convenient index for devices independent of the device's network
protocol, media type, presence of a network, etc.
 
Also, wouldn't the suggestion that the 1394 device place it's Client ID in
chadder to facilitate keying by the DHCP service theoretically be a problem
if a different device using a different protocol had a matching 64bit MAC
address (72bit if 1394 also included Client ID type number)? This is very
unlikely, but it *is* the problem with identifiers that are expected to be
unique outside of their scope.  Would it be reasonable to reserve 128 bit
MAC address format to be identically the UUID?

 - Mike H.  7/7
-----------------
Michael D. Henry
PXE Engineering Manager
Intel - IAL/MPL
[email-masked]
(503) 264-9689
(503) 804-8011 (cell)

> -----Original Message-----
> From: Ted Lemon [mailto:[email-masked]]
> Sent: Wednesday, June 23, 1999 1:33 PM
> To: Multiple recipients of list
> Subject: Re: draft-ietf-ip1394-dhcp-01.txt 
> 
> 
> 
> > 	I wasn't proposing any special processing for the MAC address
> > 	that would come in from the 1394 clients (if they made the
> > 	change that I proposed, so that it was a "legal" MAC address).
> 
> Does the RFC say that a zero-length MAC address isn't legal?   I can't
> find any such statement.
> 
> > 	Why do you need to add a special case for this?
> 
> Because the ISC DHCP server records every link-layer address in a hash
> table.   If a bunch of clients all have the same link-layer address,
> they're all going to wind up in the same hash bucket, which isn't
> going to make any difference to them, but will make things really slow
> for any other client that winds up in the same hash bucket.
> 
> > 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,
> 
> True.
> 
> > and it is perfectly reasonable for them to be all the same, since it
> > will not be used as the identity of the client.
> 
> Depends on how you implemented your server, doesn't it?   It sounds
> like you don't hash the hardware address if you get a client
> identifier, but the ISC server does, so for us it's a problem.   :'(
> 
> > 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.
> 
> I think you'd have to squint real hard to get anything out of the
> current draft other than that the client has to send its link-layer
> address regardless of whether or not it sends a client identifier.
> 
> > Thus, I think with the change that I proposed, the 1394
> > approach will work with most if not all existing servers, some of
> > which might well have a problem with *no* MAC address at all.
> 
> I understand, but I think this is an extrapolation from your
> understanding of your own server that isn't actually valid for all
> servers.  I've no idea how many servers would have problems with
> either solution, though.  My server will probably operate correctly as
> it is with either solution, but it'll be slow if there are a lot of
> clients like this, and I'd prefer to avoid that.
> 
> Where I think you and I are really differing is as to whether or not
> this standard requires that people install a new DHCP server.   My
> take on it is that it's okay if it requires that.   It sounds like
> you'd prefer not to require that.   I don't know what to suggest -
> it's obviously easier on me if 1394 requires a server upgrade than it
> is for you, but I still think I'm right!   :')
> 
> BTW, is 1394 == firewire?
> 
> 			       _MelloN_
>