RFC2855 日本語訳
2855 DHCP for IEEE 1394. K. Fujisawa. June 2000. (Format: TXT=8070 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group K. Fujisawa Request for Comments: 2855 Sony Corporation Category: Standards Track June 2000
コメントを求めるワーキンググループK.藤沢の要求をネットワークでつないでください: 2855年のソニーカテゴリ: 標準化過程2000年6月
DHCP for IEEE 1394
IEEE1394のためのDHCP
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
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 Std1394-1995はHighパフォーマンスSerial Busの規格です。 1394が従来のIEEE802/イーサネットと異なったリンクレイヤアドレス指定法を使用するので、相互運用性を達成するためにいくつかの分野の用法をはっきりさせなければなりません。 このメモは1394年のDHCPメッセージのいくつかの分野の特定の用法を説明します。
1. Introduction
1. 序論
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 Std1394-1995はHighパフォーマンスSerial Busの規格です。 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.
Dynamic Host Configuration Protocol(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/イーサネットと異なったリンクレイヤアドレス指定法を使用するので、相互運用性を達成するためにいくつかの分野の用法をはっきりさせなければなりません。 このメモは1394年のDHCPのいくつかの分野の特定の用法を説明します。 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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[RFC2119]で説明されるように本書では解釈されることであるべきですか?
Fujisawa Standards Track [Page 1] RFC 2855 DHCP for IEEE 1394 June 2000
藤沢Standardsは2000年6月にIEEE1394のためにRFC2855DHCPを追跡します[1ページ]。
2. Issues related to 1394 link address
2. 1394年のリンクアドレスに関連する問題
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年のリンクアドレス(ノード_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年のネットワークにおける影響が非問題であるとみなします。
3. 1394 specific usage of DHCP message fields
3. 1394年のDHCPメッセージ分野の特定の用法
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.
1394SHOULDの上のDHCPクライアントは、DHCPDISCOVERとDHCPREQUESTメッセージ('ciaddr'をゼロに設定する)のBROADCAST旗にサーバ(または、中継エージェント)が回答をクライアントに放送するのを保証するように設定します。
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]で説明されるように、したがって、RENEWINGかREBINDINGが、BOUNDの間、クライアントのIPアドレスで'ciaddr'に記入しなければならないと述べて、BROADCAST旗は設定されてはいけません。 これらのケース、'ciaddr'のアドレスへのDHCPサーバユニキャストDHCPACKメッセージで。 リンクアドレスは1394ARPによって決議されるでしょう。
'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クライアントSHOULDは'クライアント識別子'オプションにEUI-64識別子を含んでいます。 EUI-64のためのタイプ値は27[ARPPARAM]です、そして、形式は以下の通り例証されます。
Fujisawa Standards Track [Page 2] RFC 2855 DHCP for IEEE 1394 June 2000
藤沢Standardsは2000年6月にIEEE1394のためにRFC2855DHCPを追跡します[2ページ]。
Code Len Type Client-Identifier
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| 61 | 9 | 27 | EUI-64 (node unique ID) |
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
コードレンタイプクライアント識別子+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ | 61 | 9 | 27 | EUI-64(ノードのユニークな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].
その他の詳細に関しては、「9.14」を見てください。 [RFC2132]の「クライアント識別子。」
4. Security Considerations
4. セキュリティ問題
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.
作者は彼らのレビューと貴重なコメントのためにDynamic Host Configuration作業部会のメンバーに感謝します。
References
参照
[RFC2734] Johansson, P., "IPv4 over IEEE 1394", RFC 2734, December
1999.
[RFC2734]ヨハンソン、1999年12月のP.、「IEEE1394の上のIPv4」RFC2734。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、RFC2119、1997年3月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
2131, March 1997.
[RFC2131] Droms、R.、「ダイナミックなホスト構成プロトコル」、RFC2131、1997年3月。
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997.
[RFC2132] アレクサンダーとS.とR.Droms、「DHCPオプションとBOOTPベンダー拡大」、RFC2132、1997年3月。
[ARPPARAM] http://www.iana.org/numbers.html
[ARPPARAM] http://www.iana.org/numbers.html
Fujisawa Standards Track [Page 3] RFC 2855 DHCP for IEEE 1394 June 2000
藤沢Standardsは2000年6月にIEEE1394のためにRFC2855DHCPを追跡します[3ページ]。
Author's Address
作者のアドレス
Kenji Fujisawa Sony Corporation 6-7-35, Kitashinagawa, Shinagawa-ku, Tokyo, 141-0001 Japan
Kenji藤沢ソニー6-7-35、Kitashinagawa、品川区、日本東京141-0001
Phone: +81-3-5448-8507 EMail: fujisawa@sm.sony.co.jp
以下に電話をしてください。 +81-3-5448-8507 メールしてください: fujisawa@sm.sony.co.jp
Fujisawa Standards Track [Page 4] RFC 2855 DHCP for IEEE 1394 June 2000
藤沢Standardsは2000年6月にIEEE1394のためにRFC2855DHCPを追跡します[4ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Fujisawa Standards Track [Page 5]
藤沢標準化過程[5ページ]
一覧
スポンサーリンク
