ＩＰｖ６ ｏｖｅｒ ＩＥＥＥ １３９４
ネットワーク・ワーキング・グループ k.Fujisawa
RFC：3146 A.Onoe
カテゴリ：トラック標準 ソニー株式会社
2001年10月
IEEE 1394ネットワーク上でのIPv6パケット転送
本ドキュメントの位置付け
本ドキュメントはインターネット・コミュニティのためのインターネット標準トラ
ック・プロトコルを指定するものであり、改善のための議論と提案を求めるものであ
る。本プロトコルの標準化の状況と位置付けには「インターネット・オフィシャル・
プロトコル・スタンダード」（STD 1）の最新版を参照されたい。本ドキュメントの
配布には如何なる制限もない。
コピーライト通知
Copyright(C) The Internet Society（2001). All Rights Reserved.
概要
本ドキュメントはIPv6パケット転送のためのフレームフォーマット及びIEEE1394
ネットワーク上のIPv6 リンク・ローカル・アドレスとステートレス自動設定
アドレスの生成方法について述べている。
１．はじめに
IEEE標準1394-1995（及びその改正版）はハイ・パフォーマンス・シリアル・バス
の標準である。IETF IP1394ワーキンググループはIEEE1394 サブネットネット
ワーク「IP1394」上のIPv4データグラム及びARPパケットの搬送方法を標準化した。
本ドキュメントは、IPv6(IPV6)パケット転送のためのフレームフォーマット及
びIEEE1394ネットワーク上のIPv6リンク・ローカル・アドレスとステートレス
自動設定アドレスの生成方法について述べている。また、メッセージがIEEE1394
ネットワークで転送されるときの、近隣探索「DISC]で使われるソース/ターゲットの
リンク・レイヤ・アドレス・オプションの内容についても述べている。
２.用語の定義
本ドキュメントでの「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、
「SHALL NOT」、「SHOULD」、「RECOMMENDED」、「MAY」、「OPTIONAL」
等のキーワードはRF2119で述べられたように解釈されるべきである。
３．IPv6対応ノード
IPv6対応ノードは以下の最低要件を満たしていなければならない[MUST」。
−ISO/IEC 13213:1994で指定する一般フォーマットにコンフィギュレーションROM
を実装しなければならず「MUST」、IEEE標準1394a-2000「1394a」で指定するバス
・インフォメーション･ブロックと本ドキュメントで指定するユニット・
ディレクトリを実装しなければならない「MUST」。
−そのバス･インフォーメション・ブロックのmax-recフィールドは少なくとも８
でなければならない「MUST]、これはブロック・ライト･リクエストと512オクテッ
ドのデータ･ペイロード付き非同期ストリーム・パケット受け入れの能力を示して
いる。同じ能力はリード・リクエストに対しても適用されねばならない「MUST」。
即ち、ノードは512オクテッドのデータ・ペイロード付きブロック･リスポンス・
パケットを転送できなければならない「MUST」。
−IEEE標準 1394a-2000で指定したように、等時性リソース・マネジャー対応でな
ければならない「MUST]。
−IEEE標準 1394a-2000で指定したように、非同期ストリームの受信と転送の双方を
サポートしなければならない「MUST]。
４．リンクのカプセル化とフラグメンテーション
カプセル化とフラグメンテ-ションのメカニズムは[IP1349]の「４．リンクのカプセル
化とフラグメンテーション」に同じでなければならない「MUST]。
注：プロトコルを識別するためのether_typeフィールドがあり、MCAP（マルチ
キャスト・チャネル・アロケーション・プロトコル）はIPv4とIPv6の双方に使わ
れるので、IPv6データグラムのGASP（グローバル非同期ストリーム・パケット）
ヘッダのVersionフィールドは「IP1394」と同じ値（１）である。
IPv6のether_type値は0x86ddである。
IEEE1394ネットワーク上のIPv6パケットのMTUサイズ・デフォルト値は1500オクテッド
である。このサイズはより小さなMTUを指定するMTUオプションを含んだルータ・アド
バタイズメント「DISC」、もしくは各ノードのマニュアル設定によって小さくされる
かもしれない。もしIEEE1394インタフェース上で受信したルータ・アドバタイズメント
が1500以上、或いはマニュアルで設定した値以上のMTUを指定するMTUオプションを持
っているなら、そのMTUオプションはシステム・マネージメントに記録されるであろ
うが、それ以外は無視されなければならない。特別な２つのノード間でMTUサイズを
拡張するメカニズムは今後の研究を待ちたい。
５．コンフィギュレーションROM
IPv6対応ノード用のコンフィギュレーションROMは、以下の場合を除いて、「IP1394」
で指定したフォーマットの中にユニット・ディレクトリを含んでいなければならな
い[MUST]。
−Unit_SW_Version用の値が0x000002である。
−Unit_SW_Version用のテキスト記述子は「IPv6」でなければならない「MUST」。
注：デュアル・スタック（IPv4とIPv6）ノードはIPv4とIPv6用の２つのユニット・
ディレクトリを持つであろう。
６．ステートレス自動設定
IEEE1394インタフェース用のインタフェース識別子「AARCH」は、EUI-64識別子の第１
オクテッドのnext-to-lowestオーダービットである、「ユニバーサル/ローカル」
(U/L)ビットを補足することでインタフェースのビルドインEUI-64識別子から生成さ
れる。このビットを補足することは、一般に０値を１に変えることである。なぜなら、
インタフェースのビルドイン EUI-64識別子はユニバーサルに管理されたアドレス
空間からであり、それゆえにグローバル ユニーク値を持つと予想されるからである。
ユニヴァーサルに管理されたEUI-64識別子は、U/Lビット・ポジションの中で０で示さ
れる。一方グローバルユニークIPv6インタフェース識別子はコレスポンディング・
ポジションで１で示される。この点についての更なる論議は「AARCH]を参照のこと。
IEEE1394インタフェースのステートレス自動設定「ACONF」に用いられるIPv6アドレス・
プレフィックスは64ビット長でなければならない「MUST」。
７．リンク･ローカル・アドレス
IEEE1394用のIPv6リンク・ローカル・アドレス「AARCH」は、上記で定義したように、
インタフェース識別子にFE80::/64のプレフィックスを付け加えることで形成される。
10 bits 54 bits 64 bits
+----------+-----------------------+----------------------------+
|1111111010| (ゼロ) | インターフェース識別子 |
+----------+-----------------------+----------------------------+
８．ユニキャスト用アドレス・マッピング
IEEE1394 リンク・レイヤ・アドレスに入るIPv6ユニキャスト・アドレスのマッピング
手順は、近隣探索「DISC」を使用する。1394リンク・レイヤ・アドレス（ノードID）
は1394ブリッジを常に通るわけではないので、われわれは、リンク・レイヤ・アドレス
・オプションの中にそれを置かないようにした。近隣探索の受信者はソースのリンク・
レイヤ・アドレスのコンテンツとの関連の中でソースID（非同期パケット・ヘッダ
或いはGASPヘッダから得られる）を使うべきである「SHOULD」。実装はノード・ユニー
クID（EUI-64識別子）とノードID間のマッピング・テーブルを使って送信者のノードID
を得るための何か他の方法を使ってもよい「MAY」。このようなマッピング・テーブル
を作成するメカニズムはこのドキュメントの目的ではない。
近隣探索パケットの受信者はソースIDの最上位の10ビットが0x3FFか、或いは受信者
のノードID・レジスタの最上位10ビットと同じでなければ、それを無視しなければなら
ない「MUST」。
ソース/ターゲットのリンク・レイヤ・アドレス・オプションは、リンク・レイヤが
IEEE1394であるとき、次の形式を持っている。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length = 3 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
| node_unique_ID (EUI-64識別子) |
+--- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | max_rec | spd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| unicast_FIFO |
+--- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 1 は、ソースのリンク・レイヤ・アドレス
2 は、ターゲットのリンク・レイヤ・アドレス
Length 3 ( 8 オクテット単位)
node_unique_ID このフィールドはノードのノード・ユニークIDを含んでおり、また
ノードのコンフィギュレーションROMで指定されたものと同じでなけ
ればならない「MUST」
max_rec このフィールドはノードのコンフィギュレーションROMのmax_rec
の値と等しくなければならない「MUST」。
spd このフィールドはノードのリンク・スピード及びPHYスピードのより
遅いものをセットしなければならない「MUST」。リンク・スピードと
はリンクがパケットを送信するか受信する最高スピードであり、
PHYスピードとは、PHYパケットを送信、受信、リピートする最高ス
ピードである。spdに用いられるエンコードは「IP1394」の表２で指
定する。
unicast_FIFO このフィールドはIPv6データグラムの受信に有効なノードFIFOの
48ビット・オフセットを指定しなければならない「MUST」。ノード
・ユニキャストFIFOのオフセットはパワー・リセットをした結果
以外に変化してはならない「MUST NOT」
reserved このフィールドは送信者がオールゼロにセットし、受信者は無視し
なければならない「MUST」。
ノードIDは1394バス・リセットが発生したとき、変化することに注意。ノードで所有
するマッピング・キャッシュは1394バス・リセットでクリアされるべきである「SHOULD」。
「1394」によれば、マキシマム・データ･ペイロードと転送スピードは送信者の能力、
受信者の能力、すべての中間ノードのPHYに基づいて決められるべきである「SHOULD」。
９．IPv6 マルチキャスト
デフォルトにより、すべてのベスト･エフォート型IPv6マルチキャストはそのチャネル
番号がブロードキャスト・チャネル・レジスタからのチャネル・フィールドに等しい
非同期ストリーム・パケットを使わねばならない「MUST」。特に、オール・ノード・
マルチキャスト・アドレス、オール・ルータ・マルチキャスト・アドレス及びソリシッ
ト・ノード・マルチキャスト・アドレス「AARCH」に宛てるデータグラムはブロードキャ
スト・チャネル・レジスタが指定するデフォルト･チャネルを使わねばならない「MUST」
他のマルチキャスト・グループ・アドレスのためのベスト・エフォート型IPv6マルチ
キャストは、それらのチャネル番号が「IP1394」で説明したように、マルチキャスト
・チャネル・アロケーション・プロトコル（MCAP）によって使用する前に配置およ
びアドバタイズされているなら、異なるチャネル番号を使ってもよい。
ノードがオール・ノード・マルチキャスト・アドレス、オール・ルータ・マルチキャ
スト・アドレス、ソリシット・ノード・マルチキャスト・アドレス以外に宛てたマルチ
キャスト・データを受信したいなら、マルチキャスト・グループ・アドレスとチャネル
番号の間のチャネル・マッピングが、「IP1394」の「9.3 マルチキャスト受信」で述べ
たように、MCAP使用中に存在するか確認しなければならない「MUST」。
MCAPの実装はセンド・オンリィ・ノードにとってはオプションである。ノードはチャネ
ルのアロケーションの存在を考慮せず、いずれかのマルチキャスト・アドレスに宛てた
マルチキャスト・データをデフォルトのブロードキャスト･チャネルに対し転送しても
よい「MAY」。 もしノードがデフォルト・チャネル以外にマルチキャスト・データを
転送したいなら、グループ・アドレス用のチャネル番号が既にアロケートされている
か、MCAPによって最初に確認されなければならない「MUST」。インプレメンタがハイ
・レート・マルチキャスト・ストリームを転送するとき、このプロトコルを使用する
ことを奨励する。
IPv6 グループ・アドレス記述子用のMCAPの「type」値は2である。
10．IANAに関する考察
IANAは5章で述べたように「CSRプロトコル識別子」の名前欄からの「IEEE1394上
のUnit_SW_Version」の値を0x000002と定めている。「CSR プロトコル識別子」の詳細
は「IP1394」の「10.IANAに関する考察」で述べられている。
「IP1394」の9.1章でMCAPグループ・アドレス記述子のフォーマットを定義している。
それは8ビットtypeの名前欄を含んでいる。本ドキュメントはIANAがMCAPグループ・
アドレス記述子を管理するため名前欄を維持するよう要求する。そのテーブルの初期設
定は以下のとおりである。
値 用途
０ リザーブ
１ IPv4マルチキャスト・アドレス
２ IPV6マルチキャスト・アドレス
255 リザーブ
追加的な値が3-254の範囲で「RFC 2434」の標準アクションを通して定義される。
11. セキュリティについての考察
IEEE1394上のIPv6は「IP1394」のセキュリティ考察に何も加えない。「IP1394」の
「11章 セキュリティ考察」でのべたセキュリティ関連がここでも同様に適用される。
12. 謝辞
著者は「IP1394」および「ETHER」の著者に謝意を表したい。このドキュメントの一部
はそれらから引き出されたものであるから。
13.参照
「1394」 IEEE標準 1394-1995、ハイ・パフォーマンス・シリアル・バス標準
「1394a」 IEEE標準 1394a-2000 ハイ・パフォーマンス・シリアル・バス−改正１
「IP1394」P.Johansson「IEEE1394でのIPv4」、RFC2734 1999年12月
「IPv6」 S.Deering、R.Hinden「インターネットプロトコル、バージョン６(IPv6)ｽ
ﾍﾟシフィケーション)、RFC2460 1998年12月
「AARCH」 R.Hinden、S.Deering「IP バージョン6 アドレス・アーキテクチャ」、
RFC2327 1998年12月
[ACONF] Thomson,S.andT.Narten,「IPv6 ステートレスアドレス自動設定」、
RFC2462,1998年12月
「DISC」 T.Narten、E.Nordmark、W.A.Simpson「IP バージョン６（IPv6）のため
の近隣検索」 RFC2461、1998年12月
「ETHER」 M.Crawford「イーサネット・ネットワーク上のIPv6パケットの転送」、
RFC2464 1998年12月
14. 著者住所
Kenji Fujisawa
Network & Software Technology Center
ソニー株式会社
〒141-0001 東京都品川区北品川 6-7-35
電話:03-5795-8507
ファクス:03-5796-8977
Email:fujisawa@sm.sony.co.jp
Atsushi Onoe
Internet Systems Laboratory，Internet Laboratories
ソニー株式会社
〒東京都品川区北品川 6-7-35
電話:03-5448-4620
ファクス:03-5448-4622
Email:onoe@sm.sony.co.jp
15．コピーライト全文
Copyright（ｃ）The Internet Society(2001)．All Rights Reserved.
本論文とその翻訳は、全体又は一部を、いかなる種類の制限も受けることなく、
コピーされ他者に提供されるかもしれない。そしてコメントしたり、別途説明したり、
実装を援助するという派生作業が、準備され、コピーされ、出版され、配布されるか
もしれない。もし、上記のコピーライト宣言と本パラグラフがそれらコピーや派生作業
に含まれているときには。しかし、この論文自体は、コピーライト通知を削除したり、
インターネット社会あるいは他のインターネット組織へ参照する等の、いかなる方法で
も修正してはならない。ただし、インターネット標準プロセスで定義されたコピーライ
ト手続きに従ってインターネット標準を発展させる目的で必要な場合、あるいは、
英語以外の言語に翻訳するために要求される場合を除く。
上記で認められた制限された許可は永久的であり、インターネット社会や継承者や
受託者によって無効にされることはないであろう。
本論文及びここに含まれる情報は、[AS IS（手を加えない）]ベースで提供され
る。Internet Society 及びInternet Engineering Task Force は、明確にも、暗黙
でもここでの情報を使うことが何らかの権利、あるいは商業的な暗黙の保証、あるい
は特殊な目的に対する適正を侵害することはないといういかなる保証を含めてしかし
制限なしに、すべての保証を拒否する。
謝辞
RFCの編集機能のための資金は現在インターネット・ソサイエティによって提供され
ている。
Copyright(C) 2002 by Etuko Ooishi
メールの宛先。
一 つ 上 へ
目 次 へ