draft-ietf-ip1394-dhcp-00.txt   draft-ietf-ip1394-dhcp-01.txt 
Internet-Draft K. Fujisawa Internet-Draft K. Fujisawa
<draft-ietf-ip1394-dhcp-00.txt> Sony Corporation <draft-ietf-ip1394-dhcp-01.txt> Sony Corporation
Expires: May, 1999 November 1998 Expires: July, 1999 January 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. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts. distribute working documents as Internet-Drafts.
skipping to change at page 2, line 27 skipping to change at page 2, line 27
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.
See [RFC2131] for the mechanism of DHCP and the explanations of each See [RFC2131] for the mechanism of DHCP and the explanations of each
fields. fields.
This document is a product of the IP1394 working group within the This document is a product of the IP1394 working group within the
Internet Engineering Task Force. Comments are solicited and should Internet Engineering Task Force. Comments are solicited and should
be addressed to the working group's mailing list at be addressed to the working group's mailing list at
ip1394@mailbag.intel.com and/or the author. 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 By the conventional link-layer protocols, such as an Ethernet, the
an IEEE1394 network. '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 'htype' (hardware address type) MUST be 24 [ARPPARAM].
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The values of 'node_ID', 'unicast_FIFO', 'max_rec' and 'spd' sub- 'hlen' (hardware address length) MUST be 0.
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.
NOTE: The usage of the 'node_ID' field is still under discussion The 'chaddr' (client hardware address) field is reserved. The
within the working group. According to the discussion for the recipient shall not check the value of this field.
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.
'client identifier' option MUST be used in DHCP messages from the A DHCP client on 1394 SHOULD set a BROADCAST flag in DHCPDISCOVER and
client to the server due to the transient nature of the 'node_ID' DHCPREQUEST messages to request the server (or the relay agent) to
field in 'chaddr'. 'chaddr' will be used only to return a message send a broadcast reply if its 'ciaddr' (client IP address) is zero.
from the server (or DHCP relay-agent) to the client.
'client identifier' option may consist of any data. When an EUI-64 'client identifier' option MUST be used in DHCP messages from the
(node unique ID) [EUI64] is used as a 'client identifier', the type client to the server due to the lack of the 'chaddr'. 'client
value for the EUI-64 is 27 [ARPPARAM], and the format is illustrated identifier' option may consist of any data. When an EUI-64 (node
as follows. 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 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.
References References
[IP1394] P. Johansson, "IPv4 over IEEE 1394", [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, [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
 End of changes. 11 change blocks. 
39 lines changed or deleted 27 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/