RFC2855
Network Working K.Fujisawa
Request for Comments: 2855 Sony Corporation
Categori:Standard Track June 2000
DHCP for IEEE 1394
本論文のステータス
本ドキュメントはインターネット社会のためにインターネット標準トラックプロトコル
を規定したものであり、改善のための議論と提案を求めている。
本プロトコルの標準化状態とステータスについては「Internet Official Protocol
Standards」(STD1)の最新版を参照のこと。本論文の配布は制限を受けない。
コピーライト通知
Copyright (C) The Internet Society (2000). All Rights Reserved.
概要
IEEE Std 1394-1995は、ハイパフォーマンス・シリアルバスの標準である。
1394が従来のIEEE802/Ethernetとは異なったリンクレイヤアドレッシング法を使用して
いるので、いくつかのフィールドの使用法を明確にし、相互運用性(interoperabirity)
を実現しなければならない。
本論文はDHCPメッセージのいくつかのフィールドの具体的な使用法を説明したものである。
1.導入
IEEE Std 1394-1995は、ハイパフォーマンスシリアルバスの標準である。
IEEE IP 1394 Working Group は、IEEE1394 ネットワーク上でのIPv4データグラム及び
1394 ARPパケットを搬送する方法を指定した。[RFC2734].
DHCP(Dynamic Host Configuration Protocol)[RFC 2131]は、TCP/IPネットワーク上の
ホストに通過する構成情報(configuration information)のフレームワークを提供する。
1394が従来のIEEE802/Ethernetとは異なるリンクレイヤアドレッシング方法を用いて
いるため、いくつかのフィールドの使用法が、相互運用性を実現するため明確に
されねばならない。
本論文はDHCPのいくつかのフィールドについての1394の特別な使用について述べている。
DHCPのメカニズムおよび各フィールドの説明については[RFC 2131]を参照されたい。
本論文中のキーワード「必須(MUST、REQUIRED、SALL)」,
「禁止(MUST NOT、SHALL NOT)」,「推奨(SHOULD,RECOMMENDED)」,
「非推奨(SHOULD NOT)」,「オプション(MAY,OPTIONAL)」は、[RFC 2119]に記されている
通り解釈される。
2.1394リンクアドレスの関する問題
Ethernetのような、従来のリンクレイヤプロトコルでは、「chaddr(クライアント
ハードウエアアドレス)」フィールドは、DHCPサーバ(あるいはリレイエージェント)
からクライアントへの応答メッセージを返すために使われる。
1394リンクアドレス(ノードID)は一時的で、1394ブリッジを越える不変的なもの
ではないので、われわれは、それを「chaddr」フィールドに置かないことに決めた。
DHCPクライアントは1394 ARPがまだ不可能であるうちに、サーバがBROADCASTフラグを
セットすることでブロードキャスト応答を送ることを要求することが必須である。
注:一般に、ブロードキャスト応答の使用は思いとどまらせられる。
しかし、われわれは問題無いとして1394ネットワークでのインパクトを考える。
3.DHCPメッセージフィールドの1394の特殊な用法
DHCPクライアントがIEEE1394ネットワークに接続したとき、次のルールが適用される。
「htye」(hardware addrese type)は、24[ARPPARAM]であることが必須である。
「hlen」(hardware address length)は、0であることが必須である。
「chaddr」(client hardware adderess)フィールドは予約されている。
送信側はこのフィールドに0を設定るすことが必須で、受信側およびリレイ
エージェントは受信の際にその値を無視することが必須である。
1394のDHCPクライアントはDHCPDISCOVERおよびDHCPREQUIESTメッセージにBROADCAST
フラグをセットし(そして「ciaddr」に0をセットする)、サーバ(あるいはリレイ
エージェント)がクライアントにその応答をブロードキャストするのを保証することが
必須である。
注:[RFC 2131]で述べられたように、「ciaddr」はBOUND,RENEWING,REBINDING状態の
うちに、クライアントのIPアドレスで満たされることが必須である。
それゆえ、BROADCASTフラグの設定は禁止される。これらの場合、DHCPサーバは
「ciaddr」のアドレスにDHCPACKメッセージをユニキャストする。
リンクアドレスは1394 ARPによって解決されるであろう。
「client identifier」オプションは「ciaddr」が欠けたことにより、クライアント
からサーバへのDHCPメッセージの中で用いられることが必須である。
「client identifier」オプションはいかなるデータからでも成り立つ。
1394ノード上のすべてのIPはEUI-64(ノードユニークID)を持っており、EUI-64は
明白な「client identifier」を作るからである。
1394クライアントは,「client indetifier」オプションにEUI-64識別子を含んでいる。
EUI-64のタイプ値は27[ARPPARAM]であり、フォーマットは以下の通りである。
Code Len Type Client-Identifier
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| 61 | 9 | 27 | EUI-64 (node unique ID) |
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
注:他の「client identifier」タイプ、たとえばFQDN(fully qualifed domain name)の
ようなタイプの使用を、本論文では排除しない。
更なる詳細は、[RFC2132]の「9.14 Client-identifier」を参照されたい。
4.セキュリティ考察
DHCP は現在、何の認証あるいはセキュリティメカニズムも備えていない。
可能性のある攻撃については、DHCPプロトコル仕様書 [RFC2131] の第7章で議論され
ている。
悪意のあるクライアントはそのEUI-64識別子を偽造でき、他のクライアントのふりを
することが可能である。
謝辞
著者は動的ホスト構成ワーキンググループのメンバーの批評と貴重なコメントに謝意を
表する。
参照
[RFC2734] Johansson, P., "IPv4 over IEEE 1394", RFC 2734, December
1999.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
2131, March 1997.
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997.
[ARPPARAM] http://www.iana.org/numbers.html
著者住所
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
コピーライト全文
上記のコピーライト通知と本パラグラフが以下のようなコピーや派生作業すべてに
含まれるという条件なら、この論文とその翻訳は、全体又は一部をいかなる種類の制限
も受けずに、コピーされ、他人に与えられるかもしれず、またコメントしたり、
別途説明したり、実装を援助するという派生作業が、準備、コピー、出版、配布される
かもしれない。
しかし、この論文自体は、コピーライト通知を削除したり、インターネット社会ある
いは他のインターネット組織へ参照する等の、いかなる方法でも修正してはならない。
ただし、インターネット標準を発展させる目的で必要な場合、インターネット標準プロ
セスで定義されたコピーライト手続きに従わねばならなかったり、英語以外の言語に
翻訳するために要求される場合を除く。
上記で認められた制限された許可は永久的であり、インターネット社会や継承者や
受託人によって無効にされることはないであろう。
本論文及びここに含まれる情報は、[AS IS(手を加えない)]ベースで提供される。
Internet Society 及びInternet Engineering Task Force は、明確にも、暗黙でも
ここでの情報を使うことが何らかの権利、あるいは商業的な暗黙の保証、あるいは
特殊な目的に対する適正を侵害することはないといういかなる保証を含めてしかし
制限なしに、すべての保証を拒否する。
謝辞
RFCエディタ機能に対する資金は現在インターネット社会によって提供されている。
Copyright(C) 2001 by Etuko Ooishi
メールの宛先。
一 つ 上 へ
目 次 へ