--- 1/draft-ietf-ip1394-dhcp-01.txt 2007-12-18 18:48:42.000000000 +0100 +++ 2/draft-ietf-ip1394-dhcp-02.txt 2007-12-18 18:48:42.000000000 +0100 @@ -1,36 +1,37 @@ - Internet-Draft K. Fujisawa - Sony Corporation -Expires: July, 1999 January 1999 + Sony Corporation +Expires: February, 2000 August 1999 DHCP for IEEE 1394 Status of this memo - This document is an Internet-Draft. Internet-Drafts are working - documents of the Internet Engineering Task Force (IETF), its - areas, and its working groups. Note that other groups may also - distribute working documents as Internet-Drafts. + This document is an Internet-Draft and is in full conformance + with all provisions of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as + Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as - ``work in progress.'' + "work in progress." - To view the entire list of current Internet-Drafts, please check - the "1id-abstracts.txt" listing contained in the Internet-Drafts - Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net - (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au - (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu - (US West Coast). + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. Abstract IEEE Std 1394-1995 is a standard for a High Performance Serial Bus. 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 messages. @@ -59,70 +60,84 @@ 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. + Note: In general, the use of a broadcast reply is discouraged, + but we consider the impact in a 1394 network is not an issue. + 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. + Note: As described in [RFC2131], 'ciaddr' MUST be filled in with + client's IP address during BOUND, RENEWING or REBINDING state, + therefore, the BROADCAST flag MUST NOT be set. In these cases, + the DHCP server unicasts DHCPACK message to the address in + 'ciaddr'. The link address will be resolved by ARP. + '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. + identifier' option may consist of any data. Every IP over 1394 node + has an EUI-64 (node unique ID) [EUI64], it is useful for a 'client + identifier'. When an EUI-64 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. +Acknowledgments + + The author appreciates the members of the Dynamic Host Configuration + working group for their review and valuable comments. + References [IP1394] P. Johansson, "IPv4 over IEEE 1394", - draft-ietf-ip1394-ipv4-12.txt, work in progress. + draft-ietf-ip1394-ipv4-15.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 + Phone: +81-3-5448-8507 E-mail: fujisawa@sm.sony.co.jp