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

From: Kim Kinnear <[email-masked]>
Date: Wed, 23 Jun 1999 14:02:11 -0400 (EDT)

My first take on this is that the general idea seems ok, to wit:  On 1394 
you have to use a client-identifier. Period.

That said, I think the form of MAC address used will break a lot of servers 
(ours, for instance, :-(  ).  We get upset with a zero length 
MAC address, and I suspect we're not alone.

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.

Cheers -- Kim

At 12:41 PM 6/23/99 -0400, Thomas Narten wrote:
>DHCP WG:
>
>The following document is a product of the ip1394 WG, but the document
>arguably should be a joint DHCP/1394 effort. It describes how DHCP
>should work over 1394 networks. 1394 is different from common
>link-layers in that it can't just use a link-layer address for the
>'chaddr' field.
>
>I've appended the entire draft in this note (it's less than three
>pages of meat), on the hope that some of you need a quick diversion
>and might be able to return some quick comments.
>
>I also think it might be good to discuss this in Oslo.
>
>Thanks!!!
>Thomas
>
>
>1. Introduction
>
>   IEEE Std 1394-1995 is a standard for a High Performance Serial Bus.
>   IETF IP1394 Working Group specified the method to carry IPv4
>   datagrams and ARP packets over an IEEE1394 network [IP1394].
>
>   The Dynamic Host Configuration Protocol (DHCP) [RFC2131] provides a
>   framework for passing configuration information to hosts on a TCP/IP
>   network.
>
>   Since 1394 uses different link-layer addressing method than
>   conventional IEEE802/Ethernet, the usage of some fields must be
>   clarified to achieve interoperability.
>   This memo describes the 1394 specific usage of some fields of DHCP.
>   See [RFC2131] for the mechanism of DHCP and the explanations of each
>   fields.
>
>   This document is a product of the IP1394 working group within the
>   Internet Engineering Task Force.  Comments are solicited and should
>   be addressed to the working group's mailing list at
>   [email-masked] and/or the author.
>
>2. Issues related to 1394 link address
>
>   By the conventional link-layer protocols, such as an Ethernet, the
>   'chaddr' (client hardware address) field may be used to return a
>   reply message from a DHCP server (or relay-agent) to a client.  Since
>   1394 link address (node_ID) is transient and will not be consistent
>   across the 1394 bridge, we have chosen not to put it in the 'chaddr'
>   field.  A DHCP client should request the server to send a broadcast
>   reply by setting the BROADCAST flag when ARP is not possible yet.
>
>3. 1394 specific usage of DHCP message fields
>
>   Following rules should be used when a DHCP client is connected to
>   an IEEE1394 network.
>
>   'htype' (hardware address type) MUST be 24 [ARPPARAM].
>
>   'hlen' (hardware address length) MUST be 0.
>
>   The 'chaddr' (client hardware address) field is reserved.  The
>   recipient shall not check the value of this field.
>
>   A DHCP client on 1394 SHOULD set a BROADCAST flag in DHCPDISCOVER and
>   DHCPREQUEST messages to request the server (or the relay agent) to
>   send a broadcast reply if its 'ciaddr' (client IP address) is zero.
>
>
>
>
>K. Fujisawa                Expires July 1999                    [Page 2]
>
>Internet Draft       draft-ietf-ip1394-dhcp-01.txt          January 1999
>
>
>   'client identifier' option MUST be used in DHCP messages from the
>   client to the server due to the lack of the 'chaddr'.  'client
>   identifier' option may consist of any data.  When an EUI-64 (node
>   unique ID) [EUI64] is used as a 'client identifier', the type value
>   for the EUI-64 is 27 [ARPPARAM], and the format is illustrated as
>   follows.
>
>       Code  Len   Type  Client-Identifier
>      +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
>      |  61 |  9  | 27  |           EUI-64 (node unique ID)             |
>      +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
>
>   Note that the use of other 'client identifier' type, such as a fully
>   qualified domain name (FQDN), is not precluded by this memo.
>   For more details, see "9.14. Client-identifier" in [RFC2132].
>
>Security Considerations
>
>   Security issues are not discussed in this document.
>
>References
>
> [IP1394]   P. Johansson, "IPv4 over IEEE 1394",
>            draft-ietf-ip1394-ipv4-12.txt,  work in progress.
>
> [RFC2131]  R. Droms, "Dynamic Host Configuration Protocol", RFC2131,
>            March 1997.
>
> [RFC2132]  S. Alexander, R. Droms, "DHCP Options and BOOTP Vendor
>            Extensions", RFC2132, March 1997.
>
> [EUI64]    http://standards.ieee.org/regauth/oui/tutorials/EUI64.html
>
> [ARPPARAM] http://www.isi.edu/in-notes/iana/assignments/arp-parameters
>
>Author's address
>
>   Kenji Fujisawa
>   Sony Corporation
>   IT Laboratories, Computer Systems Laboratory
>   6-7-35, Kitashinagawa,
>   Shinagawa-ku, Tokyo, 141-0001 Japan
>   Phone:  +81-3-5448-4602
>   E-mail: [email-masked]
>
>
>
>
>
>
>
>K. Fujisawa                Expires July 1999                    [Page 3]
>
>