Network Working Group K. Fujisawa
Request for Comments: 2855 Sony Corporation
Category: Standards Track June 2000
Network Working Group K. Fujisawa
Request for Comments: 2855 Sony Corporation
Category: Standards Track June 2000
DHCP for IEEE 1394
ieee1394的DHCP协议
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
Abstract
摘要
IEEE Std 1394-1995 is a standard for a High Performance Serial Bus. Since 1394 uses a 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.
IEEE标准1394-1995是高性能串行总线的标准。由于1394使用了与传统IEEE802/以太网不同的链路层寻址方法，因此必须澄清某些字段的用法，以实现互操作性。本备忘录描述了DHCP消息某些字段的1394特定用法。
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 1394 ARP packets over an IEEE1394 network [RFC2734].
IEEE标准1394-1995是高性能串行总线的标准。IETF IP1394工作组规定了通过IEEE1394网络传输IPv4数据报和1394 ARP数据包的方法[RFC2734]。
The Dynamic Host Configuration Protocol (DHCP) [RFC2131] provides a framework for passing configuration information to hosts on a TCP/IP network.
动态主机配置协议（DHCP）[RFC2131]提供了一个框架，用于将配置信息传递给TCP/IP网络上的主机。
Since 1394 uses a 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 field.
由于1394使用了与传统IEEE802/以太网不同的链路层寻址方法，因此必须澄清某些字段的用法，以实现互操作性。本备忘录描述了DHCP某些字段的1394特定用法。有关DHCP的机制和每个字段的说明，请参见[RFC2131]。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
With 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 a 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 that the server sends a broadcast reply by setting the BROADCAST flag when 1394 ARP is not possible yet.
对于传统的链路层协议，例如以太网，“chaddr”（客户端硬件地址）字段可用于将应答消息从DHCP服务器（或中继代理）返回到客户端。由于1394链路地址（node_ID）是暂时的，在1394网桥上不一致，因此我们选择不将其放在“chaddr”字段中。当1394 ARP还不可能时，DHCP客户端应通过设置广播标志请求服务器发送广播应答。
Note: In general, the use of a broadcast reply is discouraged, but we consider the impact in a 1394 network as a non issue.
注意：一般来说，使用广播答复是不鼓励的，但是我们认为在1394网络中的影响是非问题。
Following rules should be used when a DHCP client is connected to an IEEE1394 network.
当DHCP客户端连接到IEEE1394网络时，应使用以下规则。
'htype' (hardware address type) MUST be 24 [ARPPARAM].
“htype”（硬件地址类型）必须为24[arParam]。
'hlen' (hardware address length) MUST be 0.
“hlen”（硬件地址长度）必须为0。
The 'chaddr' (client hardware address) field is reserved. The sender MUST set this field to zero, and the recipient and the relay agent MUST ignore its value on receipt.
保留“chaddr”（客户端硬件地址）字段。发件人必须将此字段设置为零，收件人和中继代理必须在收到时忽略其值。
A DHCP client on 1394 SHOULD set a BROADCAST flag in DHCPDISCOVER and DHCPREQUEST messages (and set 'ciaddr' to zero) to ensure that the server (or the relay agent) broadcasts its reply to the client.
1394上的DHCP客户端应在DHCPDISCOVER和DHCPREQUEST消息中设置广播标志（并将“ciaddr”设置为零），以确保服务器（或中继代理）向客户端广播其应答。
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 1394 ARP.
注：如[RFC2131]所述，在绑定、续订或重新绑定状态下，“ciaddr”必须填写客户端的IP地址，因此，不能设置广播标志。在这些情况下，DHCP服务器将DHCPACK消息单播到“ciaddr”中的地址。链接地址将由1394 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. Because every IP over 1394 node has an EUI-64 (node unique ID), the EUI-64 makes an obvious 'client identifier'. 1394 clients SHOULD include an EUI-64 identifier in the 'client identifier' option. The type value for the EUI-64 is 27 [ARPPARAM], and the format is illustrated as follows.
由于缺少“chaddr”，从客户端到服务器的DHCP消息中必须使用“客户端标识符”选项“客户端标识符”选项可以由任何数据组成。因为每个IP over 1394节点都有一个EUI-64（节点唯一ID），所以EUI-64会产生一个明显的“客户端标识符”。1394客户端应在“客户端标识符”选项中包含EUI-64标识符。EUI-64的类型值为27[ARPPARAM]，格式如下所示。
Code Len Type Client-Identifier
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| 61 | 9 | 27 | EUI-64 (node unique ID) |
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
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.
请注意，本备忘录不排除使用其他“客户端标识符”类型，如完全限定域名（FQDN）。
For more details, see "9.14. Client-identifier" in [RFC2132].
有关更多详细信息，请参阅[RFC2132]中的“9.14.客户端标识符”。
DHCP currently provides no authentication or security mechanisms. Potential exposures to attack are discussed in section 7 of the DHCP protocol specification [RFC2131].
DHCP目前不提供身份验证或安全机制。DHCP协议规范[RFC2131]第7节讨论了潜在的攻击风险。
A malicious client can falsify its EUI-64 identifier, thus masquerading as another client.
恶意客户端可以伪造其EUI-64标识符，从而伪装成另一个客户端。
Acknowledgments
致谢
The author appreciates the members of the Dynamic Host Configuration Working Group for their review and valuable comments.
作者感谢动态主机配置工作组的成员所作的审查和提出的宝贵意见。
References
工具书类
[RFC2734] Johansson, P., "IPv4 over IEEE 1394", RFC 2734, December 1999.
[RFC2734]Johansson，P.，“IEEE 1394上的IPv4”，RFC 27341999年12月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，RFC 211997年3月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131]Droms，R.，“动态主机配置协议”，RFC21311997年3月。
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997.
[RFC2132]Alexander，S.和R.Droms，“DHCP选项和BOOTP供应商扩展”，RFC 21321997年3月。
[ARPPARAM] http://www.iana.org/numbers.html
[ARPPARAM] http://www.iana.org/numbers.html
Author's Address
作者地址
Kenji Fujisawa Sony Corporation 6-7-35, Kitashinagawa, Shinagawa-ku, Tokyo, 141-0001 Japan
藤泽健二索尼公司6-7-35，日本东京新川区北川，141-0001
Phone: +81-3-5448-8507
EMail: fujisawa@sm.sony.co.jp
Phone: +81-3-5448-8507
EMail: fujisawa@sm.sony.co.jp
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。