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

From: [email-masked]
Date: Wed, 7 Jul 1999 22:32:03 -0400 (EDT)

Hi,

Thanks for comment.

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

Although I don't know the detail of UUID and DHCP-Authentication,
I don't see any problem here since DHCP/1394 does NOT restrict to use
only EUI-64 client ID.  One MAY use a UUID Client ID for 1394 device.

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

I think this is a point of discussion.
What is a meaning of 'chaddr'? 
My understanding is it is a client link address to return a response
message, since we have a Client ID to identify a client.

In the case of IEEE1394, we don't have a constant link address of a node. 
This is the reason to set 'hlen' = 0.

What do you/others think?

Best Regards,

Kenji Fujisawa