[要約] RFC 2855は、IEEE 1394ネットワーク上でのDHCP（Dynamic Host Configuration Protocol）の仕様を定義しています。このRFCの目的は、IEEE 1394ネットワーク上のデバイスに自動的にIPアドレスを割り当てるための標準化を提供することです。
Network Working Group K. Fujisawa
Request for Comments: 2855 Sony Corporation
Category: Standards Track June 2000
DHCP for IEEE 1394
IEEE 1394の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.
Copyright（c）The Internet Society（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 STD 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 STD 1394-1995は、高性能シリアルバスの標準です。IETF IP1394ワーキンググループは、IEEE1394ネットワーク[RFC2734]でIPv4データグラムと1394 ARPパケットを運ぶ方法を指定しました。
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].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" は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」フィールドに入れないことを選択しました。DHCPクライアントは、1394 ARPがまだ不可能な場合、ブロードキャストフラグを設定することにより、サーバーがブロードキャスト返信を送信するように要求する必要があります。
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 [arpparam]でなければなりません。
'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メッセージで使用する必要があります。「クライアント識別子」オプションは、任意のデータで構成されている場合があります。1394を超えるすべてのIPには、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) |
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
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。Client-Identifier」を参照してください。
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。、「IPv4 Over IEEE 1394」、RFC 2734、1999年12月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、RFC 2119、1997年3月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131] DROMS、R。、「動的ホスト構成プロトコル」、RFC 2131、1997年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 2132、1997年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
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。