Network Working Group K. Fujisawa
Request for Comments: 2855 Sony Corporation
Category: Standards Track June 2000
DHCP for IEEE 1394
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 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がまだできない場合BROADCASTフラグを設定することにより、ブロードキャスト応答を送信することを要求する必要があります。
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メッセージでBROADCASTフラグを設定（ゼロに「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」はBOUND、RENEWINGまたはREBINDING状態の時に、クライアントのIPアドレスで埋めなければならない、それゆえ、BROADCASTフラグを設定してはいけません。これらの例では、DHCPサーバは「ciaddr」のアドレスにDHCPACKメッセージをユニキャストします。リンクアドレスは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。クライアント識別子」を参照してください。
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]ヨハンソン、P.、 "IEEE 1394経由のIPv4"、RFC 2734、1999年12月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]アレクサンダー、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
けんじ ふじさわ そｎｙ こｒぽらちおん ６ー７ー３５、 きたしながわ、 しながわーく、 ときょ、 １４１ー０００１ じゃぱん
Phone: +81-3-5448-8507 EMail: fujisawa@sm.sony.co.jp
電話：+ 81-3-5448-8507 Eメール：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 Editor機能のための基金は現在、インターネット協会によって提供されます。