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

From: Ted Lemon <[email-masked]>
Date: Wed, 23 Jun 1999 16:32:55 -0400 (EDT)

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