draft-ietf-ip1394-dhcp-01.txt   draft-ietf-ip1394-dhcp-02.txt 
Internet-Draft K. Fujisawa Internet-Draft K. Fujisawa
<draft-ietf-ip1394-dhcp-01.txt> Sony Corporation <draft-ietf-ip1394-dhcp-02.txt> Sony Corporation
Expires: July, 1999 January 1999 Expires: February, 2000 August 1999
DHCP for IEEE 1394 DHCP for IEEE 1394
Status of this memo Status of this memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft and is in full conformance
documents of the Internet Engineering Task Force (IETF), its with all provisions of Section 10 of RFC2026.
areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts. 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 Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet- documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as 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 list of current Internet-Drafts can be accessed at
the "1id-abstracts.txt" listing contained in the Internet-Drafts http://www.ietf.org/ietf/1id-abstracts.txt
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
(Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au The list of Internet-Draft Shadow Directories can be accessed at
(Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu http://www.ietf.org/shadow.html.
(US West Coast).
Abstract Abstract
IEEE Std 1394-1995 is a standard for a High Performance Serial Bus. IEEE Std 1394-1995 is a standard for a High Performance Serial Bus.
Since 1394 uses different link-layer addressing method than Since 1394 uses different link-layer addressing method than
conventional IEEE802/Ethernet, the usage of some fields must be conventional IEEE802/Ethernet, the usage of some fields must be
clarified to achieve interoperability. clarified to achieve interoperability.
This memo describes the 1394 specific usage of some fields of DHCP This memo describes the 1394 specific usage of some fields of DHCP
messages. messages.
skipping to change at page 2, line 37 skipping to change at page 2, line 37
2. Issues related to 1394 link address 2. Issues related to 1394 link address
By the conventional link-layer protocols, such as an Ethernet, the By the conventional link-layer protocols, such as an Ethernet, the
'chaddr' (client hardware address) field may be used to return a 'chaddr' (client hardware address) field may be used to return a
reply message from a DHCP server (or relay-agent) to a client. Since 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 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' 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 field. A DHCP client should request the server to send a broadcast
reply by setting the BROADCAST flag when ARP is not possible yet. 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 3. 1394 specific usage of DHCP message fields
Following rules should be used when a DHCP client is connected to Following rules should be used when a DHCP client is connected to
an IEEE1394 network. an IEEE1394 network.
'htype' (hardware address type) MUST be 24 [ARPPARAM]. 'htype' (hardware address type) MUST be 24 [ARPPARAM].
'hlen' (hardware address length) MUST be 0. 'hlen' (hardware address length) MUST be 0.
The 'chaddr' (client hardware address) field is reserved. The The 'chaddr' (client hardware address) field is reserved. The
recipient shall not check the value of this field. recipient shall not check the value of this field.
A DHCP client on 1394 SHOULD set a BROADCAST flag in DHCPDISCOVER and A DHCP client on 1394 SHOULD set a BROADCAST flag in DHCPDISCOVER and
DHCPREQUEST messages to request the server (or the relay agent) to DHCPREQUEST messages to request the server (or the relay agent) to
send a broadcast reply if its 'ciaddr' (client IP address) is zero. 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 identifier' option MUST be used in DHCP messages from the
client to the server due to the lack of the 'chaddr'. 'client client to the server due to the lack of the 'chaddr'. 'client
identifier' option may consist of any data. When an EUI-64 (node identifier' option may consist of any data. Every IP over 1394 node
unique ID) [EUI64] is used as a 'client identifier', the type value has an EUI-64 (node unique ID) [EUI64], it is useful for a 'client
for the EUI-64 is 27 [ARPPARAM], and the format is illustrated as identifier'. When an EUI-64 is used as a 'client identifier', the
follows. type value for the EUI-64 is 27 [ARPPARAM], and the format is
illustrated as follows.
Code Len Type Client-Identifier Code Len Type Client-Identifier
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| 61 | 9 | 27 | EUI-64 (node unique ID) | | 61 | 9 | 27 | EUI-64 (node unique ID) |
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
Note that the use of other 'client identifier' type, such as a fully Note that the use of other 'client identifier' type, such as a fully
qualified domain name (FQDN), is not precluded by this memo. qualified domain name (FQDN), is not precluded by this memo.
For more details, see "9.14. Client-identifier" in [RFC2132]. For more details, see "9.14. Client-identifier" in [RFC2132].
Security Considerations Security Considerations
Security issues are not discussed in this document. 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 References
[IP1394] P. Johansson, "IPv4 over IEEE 1394", [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, [RFC2131] R. Droms, "Dynamic Host Configuration Protocol", RFC2131,
March 1997. March 1997.
[RFC2132] S. Alexander, R. Droms, "DHCP Options and BOOTP Vendor [RFC2132] S. Alexander, R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC2132, March 1997. Extensions", RFC2132, March 1997.
[EUI64] http://standards.ieee.org/regauth/oui/tutorials/EUI64.html [EUI64] http://standards.ieee.org/regauth/oui/tutorials/EUI64.html
[ARPPARAM] http://www.isi.edu/in-notes/iana/assignments/arp-parameters [ARPPARAM] http://www.isi.edu/in-notes/iana/assignments/arp-parameters
Author's address Author's address
Kenji Fujisawa Kenji Fujisawa
Sony Corporation Sony Corporation
IT Laboratories, Computer Systems Laboratory
6-7-35, Kitashinagawa, 6-7-35, Kitashinagawa,
Shinagawa-ku, Tokyo, 141-0001 Japan Shinagawa-ku, Tokyo, 141-0001 Japan
Phone: +81-3-5448-4602 Phone: +81-3-5448-8507
E-mail: fujisawa@sm.sony.co.jp E-mail: fujisawa@sm.sony.co.jp
 End of changes. 14 change blocks. 
22 lines changed or deleted 37 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/