--- 1/draft-ietf-ip1394-dhcp-00.txt 2007-12-18 18:48:42.000000000 +0100 +++ 2/draft-ietf-ip1394-dhcp-01.txt 2007-12-18 18:48:42.000000000 +0100 @@ -1,14 +1,14 @@ Internet-Draft K. Fujisawa - Sony Corporation -Expires: May, 1999 November 1998 + Sony Corporation +Expires: July, 1999 January 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. @@ -49,82 +49,70 @@ 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 ip1394@mailbag.intel.com and/or the author. -2. 1394 specific usage of DHCP message fields +2. Issues related to 1394 link address - Following rules should be used when the DHCP client is connected to - an IEEE1394 network. + 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. - 'htype' (hardware address type) should be 24 [ARPPARAM]. +3. 1394 specific usage of DHCP message fields - 'hlen' (hardware address length) should be 16. + Following rules should be used when a DHCP client is connected to + an IEEE1394 network. - The format of the 'chaddr' (client hardware address) is specified as - follows, - 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | node_ID | unicast_FIFO_hi | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | unicast_FIFO_lo | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | max_rec | spd | reserved | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | reserved | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 'htype' (hardware address type) MUST be 24 [ARPPARAM]. - The values of 'node_ID', 'unicast_FIFO', 'max_rec' and 'spd' sub- - fields should be the same values used by ARP specified in [IP1394]. - A reserved field shall be zeroed. The recipient shall not check the - value of a reserved field. + 'hlen' (hardware address length) MUST be 0. - NOTE: The usage of the 'node_ID' field is still under discussion - within the working group. According to the discussion for the - virtual node ids in the IEEE P1394.1 Bridges Working Group, a node - in the bridged IEEE1394 buses may have two node_IDs, one physical - node_ID for local bus nodes and one virtual node_ID for remote bus - nodes. + The 'chaddr' (client hardware address) field is reserved. The + recipient shall not check the value of this field. - 'client identifier' option MUST be used in DHCP messages from the - client to the server due to the transient nature of the 'node_ID' - field in 'chaddr'. 'chaddr' will be used only to return a message - from the server (or DHCP relay-agent) to the client. + 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. - '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. + '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-11.txt, work in progress. + 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