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

From: [email-masked] (by way of Ralph Droms <[email-masked]>)
Date: Wed, 23 Jun 1999 16:31:58 -0400 (EDT)

message sent to [email-masked] by [email-masked] follows.
----------------------------------------------------------------------

Kim Kinnear wrote on Wed, 23 Jun 1999 11:02:27 GMT:

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

If a legal-looking address needs to be there, then why can't the 8-byte
EUI-64 node unique ID be used there as well as in the client ID field,
with the same hardware type value used in both places?

Since client ID always overrides the MAC address, and the BROADCAST bit
is always set, the contents of chaddr mostly exists to fool overly
paranoid packet verification checks.  The closer it is to the client ID,
the easier it will be to fool such servers.  chaddr is 16 bytes long, so
it is big enough to hold the EUI-64.

Putting the EUI-64 into the header would also make the DHCP packet a
valid BOOTP packet, so there is at least some chance that BOOTP servers
can be used as well for 1394 hosts (yes, BOOTP is obsolete, but some
people still use it worse luck).

Maybe a bit more information about 1394 might be useful.  Are hosts
expected to keep some kind of dynamic table that maps EUI-64 values
into the transient link addresses?  If so, then some kernels might
already have the information to do a direct link send.  Then again,
maybe not.  I don't know anything about 1394, so I'm probably wrong. :)

Other than that, the spec looks reasonable to me.

Cheers,

Rhys.