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

From: Kim Kinnear <[email-masked]>
Date: Wed, 23 Jun 1999 15:18:34 -0400 (EDT)

At 02:18 PM 6/23/99 -0400, Ted Lemon wrote:
>
>> If the draft said that the hlen MUST be 1 and that chaddr[0] MUST be 0, then 
>> it would be a "legal" MAC address, and all 1394 devices would have the same 
>> legal MAC address with different client-identifiers, which would work with 
>> most if not all servers.
>
>Yow.   I have to disagree.   I would have to fix my server either way.
>To accept a zero-length link-layer address requires me to not make an
>entry in my link-layer address table for clients that send zero-length
>addresses.   To accept a link-layer address whose length is 1 and
>that's the same for every client requires me to add a special case for
>my server that treats such addresses as null.   It also requires me to
>assume that I will never receive a legitimate link-layer address with
>a length of 1, which is an assumption that, while likely to be true, I
>would rather not have to make.

	That's not what I meant, but it brings up an interesting
	question.

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

	Why do you need to add a special case for this?
	
	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.

	So, why do you have a problem with lots of clients that
	have the same (legal) MAC address?

	------------

	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.  

	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.

	?

	Cheers -- Kim

>
>I think that a lot of people will have to change their servers as a
>result of this RFC.   I'd rather make the change that is most correct,
>which I think is what the RFC currently does.
>
>			       _MelloN_
>