|
Network Working Group Request for Comments: 2373 Obsoletes: 1884 Category: Standards Track |
R. Hinden Nokia S. Deering Cisco Systems |
このドキュメントは、インターネット社会の為のインターネット標準トラックプロトコルを規定しており、改善の為の議論と提案を求めている。このプロトコルの標準化の状態と状況については、"Internet Official Protocol Standards" (STD 1) の現在の版を参照されたい。このメモの配布は制限されない。
Copyright (C) The Internet Society (1998). All Rights Reserved.
この規約は、IP バージョン 6 プロトコル [IPV6] のアドレス体系を定義する。このドキュメントは、IPv6 アドレス付けモデル、IPv6 アドレスのテキスト表現、IPv6 ユニキャストアドレスの定義、エニイキャストアドレス、マルチキャストアドレス、IPv6 ノードの必要なアドレスを含む。
Table of Contents
1. 導入
2. IPv6 アドレス付け
2.1 アドレス付けモデル
2.2 アドレスのテキスト表現
2.3 アドレスプレフィクスのテキスト表現
2.4 アドレスタイプ表現
2.5 ユニキャストアドレス
2.5.1 インタフェース識別子
2.5.2 未指定アドレス
2.5.3 ループバックアドレス
2.5.4 埋め込まれた IPv4 アドレスを持つ IPv6 アドレス
2.5.5 NSAP アドレス
2.5.6 IPX アドレス
2.5.7 集約可能なグローバルユニキャストアドレス
2.5.8 IPv6 ユニキャストアドレスのローカル使用
2.6 エニイキャストアドレス
2.6.1 エニイキャストアドレス要件
2.7 マルチキャストアドレス
2.7.1 前もって定義されたマルチキャストアドレス
2.7.2 新しい IPv6 マルチキャストアドレスの割当て
2.8 ノードに要求されるアドレス
3. セキュリティの考慮
付録 A: EUI-64 ベースのインタフェース識別子の生成
付録 B: テキスト表現の ABNF 記述
付録 C: RFC-1884 からの変更点
参照
作者のアドレス
完全なコピーライト宣言
この規約は、IP バージョン 6 プロトコルのアドレス体系を定義する。それは、現在定義されている IPv6 [IPV6] のアドレス形式の詳細な説明を含む。
作者は、Paul Francis, Scott Bradner, Jim Bound, Brian Carpenter, Matt Crawford, Deborah Estrin, Roger Fajman, Bob Fink, Peter Ford, Bob Gilligan, Dimitry Haskin, Tom Harsch, Christian Huitema, Tony Li, Greg Minshall, Thomas Narten, Erik Nordmark, Yakov Rekhter, Bill Simpson, Sue Thomson の寄書に感謝したい。
このドキュメント中のキーワード「MUST」「MUST NOT」「REQUIRED」「SHALL」「SHALL NOT」「SHOULD」「SHOULD NOT」「RECOMMENDED」「MAY」「OPTIONAL」は、[RFC2119] で説明されているものと同等に解釈する。
IPv6 アドレスは、インタフェースやインタフェースの集合のための 128 ビット識別子である。三つのタイプのアドレスが存在する。
ユニキャスト: 単一インタフェースの識別子。ユニキュストアドレスに送信されるパケットは、そのアドレスによって識別されるインタフェースに配送される。
エニイキャスト: インタフェースの集合のための識別子 (通常、異なるノードに属する)。エニイキャストアドレスに送信されるパケットは、そのアドレスによって識別されるインタフェースの一つ (ルーティングプロトコルの距離計測に従って「最も近い」ところ) に配送される。
マルチキャスト: インタフェースの集合のための識別子 (通常、異なるノードに属する)。マルチキャストアドレスに送信されるパケットは、そのアドレスによって識別されるインタフェースの全てに配送される。
IPv6 ではブロードキャストアドレスは存在せず、その機能はマルチキャストアドレスに取って代わる。
このドキュメントでは、アドレス中のフィールドは例えば「subscriber」といった特定の名前が付与される。この名前が、名前の後ろの識別子のために「ID」という用語と共に使用される時 (例えば「subscriber ID」)、それは名前フィールドの内容を参照する。この名前が、「prefix」という用語と共に使用される時 (例えば「subscriber prefix」)、それはこのフィールドを含み、このフィールドまでのアドレス全てを参照する。
IPv6 では、全て 1 と全て 0 は特に除外していなければ、どのフィールドにおいても正しい値である。特に、プレフィクスは 0 値のフィールドを含んでもよいし、0 で終わってもよい。
全てのタイプの IPv6 アドレスは、ノードではなくインタフェースに割り当てられる。IPv6 ユニキャストアドレスは、単一のインタフェースを識別する。各々のインタフェースは単一のノードに属すので、ノードのインタフェースのユニキャストアドレスのいずれかは、ノードの識別子として使用してもよい。
全てのインタフェースは、少なくとも一つのリンクローカルユニキャストアドレスを持つ必要がある (追加必要アドレスについてはセクション 2.8 参照)。単一インタフェースは、複数の如何なるタイプ (ユニキャスト、エニイキャスト、マルチキャスト)、あるいは如何なる範囲の IPv6 アドレスに割り当ててもよい。リンク範囲より大きい範囲を持つユニキャストは、非接続者向け/からの IPv6 パケットの起動元か宛先で使用されるインタフェースには必要ではない。これは、ポイントツーポイントインタフェースで時々便利である。このアドレス付けモデルには、一つの例外がある。
もし実装体が、複数の物理インタフェースをインターネット層向けに提供する時に一つのインタフェースとして扱うのであれば、一つのユニキャストアドレス、あるいはユニキャストアドレスの集合を複数の物理インタフェースに割り当ててもよい。これは、複数の物理インタフェース上で負荷分散するのに有効である。
現在 IPv6 は、サブネットプレフィクスが一つのリンクに割り当てられるという IPv4 モデルを引き継いでいる。複数のサブネットプレフィクスを同じリンクに割り当ててもよい。
IPv6 アドレスをテキスト文字列で表現するのに、三つの通常形式が存在する。
1. 好ましい形式は x:x:x:x:x:x:x:x
で、「x」はアドレスの 8 個の 16 ビット断片の 16進値である。例えば、
FEDC:BA98:7654:3210:FEDC:BA98:7654:3210
1080:0:0:0:8:800:200C:417A
個々のフィールドで先行する 0 は書く必要が無いが、全てのフィールドには少なくとも一つの数字が存在しなければならない (2 で説明されている場合を除く)。
2. IPv6 アドレスのあるスタイルを割り当てる幾つかの方法のために、アドレスが
0 ビットの長い文字列を含むことは共通的だろう。0 ビットを含むアドレスの記述を容易にするために、0
を圧縮する特殊な記法を利用することができる。「::」の使用は、0
の 16 ビットアドレスの複数のグループを示す。「::」はアドレス中に一回だけ現れることができる。「::」はアドレス中で先行する、あるいは後続の
0 を圧縮するために使用できる。
例えば、以下のアドレスは、
1080:0:0:0:8:800:200C:417A ユニキャストアドレス FF01:0:0:0:0:0:0:101 マルチキャストアドレス 0:0:0:0:0:0:0:1 ループバックアドレス 0:0:0:0:0:0:0:0 未指定アドレス
は、下記のように表現してもよい。
1080::8:800:200C:417A ユニキャストアドレス FF01::101 マルチキャストアドレス ::1 ループバックアドレス :: 未指定アドレス
3. IPv4 と IPv6 ノードの混在環境を扱う時に便利な代替形式は x:x:x:x:x:x:d.d.d.d で、「x」はアドレスの 6 個の高次 16 ビット断片の 16進値であり、「d」はアドレスの 4 個の低次 8 ビット断片の 10進値 (標準的な IPv4 表現) である。例えば、
0:0:0:0:0:0:13.1.68.3
0:0:0:0:0:FFFF:129.144.52.38
あるいは圧縮形式で、
::13.1.68.3
::FFFF:129.144.52.38
IPv6 アドレスプレフィクスのテキスト表現は、IPv4
のアドレスプレフィクスが CIDR 記法で記述される方法と同様である。IPv6
アドレスプレフィクスは、以下の記法で表現される。
ipv6-address/prefix-length
ipv6-address は、セクション 2.2
でリスト化されている記法のいずれかの IPv6 アドレスである。
prefix-length は、アドレスの連続した最左ビットの幾つがプレフィクスを構成するかを示す 10進値である。
例えば、以下は 60 ビットプレフィクス
12AB00000000CD3 (16進) の正しい表現である。
12AB:0000:0000:CD30:0000:0000:0000:0000/60
12AB::CD30:0:0:0:0/60
12AB:0:0:CD30::/60
以下は、上記プレフィクスの不正な表現である。
12AB:0:0:CD3/60 は、アドレスの 16
ビットの固まりの中で先行する 0 は落としてもよいが、後続の 0 は落としてはならない。
12AB::CD30/60 アドレスの 「/」の左側は、12AB:0000:0000:0000:0000:000:0000:CD30 に拡張される。
12AB::CD3/60 アドレスの 「/」の左側は、12AB:0000:0000:0000:0000:000:0000:0CD3 に拡張される。
ノードアドレスとそのノードアドレスのプレフィクスの両方を記述する時 (例えばノードのサブネットプレフィクス)、その二つは以下のように結合される。
ノードアドレス 12AB:0:0:CD30:123:4567:89AB:CDEF
サブネット番号 12AB:0:0:CD30::/60
は、12AB:0:0:CD30:123:4567:89AB:CDEF/60
のように短縮できる。
IPv6 アドレスの特殊なタイプは、アドレス中の先行ビットによって示される。これらの先行ビットを構成する可変長のフィールドは、形式プレフィクス (FP: Format Prefix) と呼ばれる。これらのプレフィクスの初期割当ては、下記の通りである。
| 割当て | プレフィクス
(2進) | アドレス空間の 分数 |
| 予約 未割当て | 0000 0000 0000 0001 | 1/256 1/256 |
| NSAP 割当てのために予約 IPX 割当てのために予約 | 0000 001 0000 010 | 1/128 1/128 |
| 未割当て 未割当て 未割当て | 0000 011 0000 1 0001 | 1/128 1/32 1/16 |
| 集約可能なグローバルユニキャストアドレス 未割当て 未割当て 未割当て 未割当て 未割当て | 001 010 011 100 101 110 | 1/8 1/8 1/8 1/8 1/8 1/8 |
| 未割当て 未割当て 未割当て 未割当て 未割当て | 1110 1111 1111 10 1111 110 1111 1110 | 1/16 1/32 1/64 1/128 1/512 |
| リンクローカルユニキャストアドレス サイトローカルユニキャストアドレス | 1111 1110 10 1111 1110 11 | 1/1024 1/1024 |
| マルチキャストアドレス | 1111 1111 | 1/256 |
注記:
この割当ては、集約アドレス、ローカル使用アドレス、マルチキャストアドレスの直接割当てをサポートする。空間は、NSAP アドレスと IPX アドレスのために予約される。残りのアドレス空間は、将来の使用のために割り当てられない。これは既存の使用の拡張 (例えば追加の集約アドレス) や、新しい使用 (例えば別々の位置子と識別子) で使用できる。アドレス空間の 15% が初期に割り当てられる。残りの 85% は将来の使用のために予約される。
ユニキャストアドレスは、アドレスの高次オクテットの値によってマルチキャストアドレスと区別される。FF (11111111) の値はアドレスをマルチキャストアドレスとして識別し、他の値はアドレスをユニキャストアドレスとして識別する。エニイキャストアドレスは、ユニキャストアドレス空間から割り当てられ、シンタクス上はユニキャストアドレスと区別できない。
IPv6 ユニキャストアドレスは、クラスレス内部ドメインルーティング [CIDR] 下の IPv4 アドレスと同様に、連続したビットマスクで集約できる
IPv6 では、幾つかの形式のユニキャストアドレス割当てが存在し、グローバルな集約可能グローバルユニキャストアドレス、NSAP アドレス、IPX 階層アドレス、サイトローカルアドレス、リンクローカルアドレス、IPv4 能力を持つホストアドレスを含む。追加のアドレスタイプを、将来定義することは可能である。
IPv6 ノードは、IPv6 アドレスの内部構造のかなり、あるいはわずかの知識を持ってもよく、それはノードの果たす役割 (例えばホスト対ルータ) に依存する。最小限では、ノードは (自分自身を含む) ユニキャストアドレスは内部構造を持たないと考えてもよい。
| 128 bits | +-----------------------------------------------------------------+ | node address | +-----------------------------------------------------------------+
若干精巧なホスト (しかしまだ単純) は、付加的に自分が接続されているリンクのサブネットプレフィクスを知ってもよい。その場合、異なるアドレスが異なる n の値を持ってもよい。
| n bits | 128-n bits | +------------------------------------------------+----------------+ | subnet prefix | interface ID | +------------------------------------------------+----------------+
より精巧なホストは、ユニキャストアドレスで他の階層的な境界を知ってもよい。非常に単純なルータは IPv6 ユニキャストアドレスの内部構造の知識を持たないが、ルータは、ルーティングプロトコルの処理のために一つ以上の階層的な境界の知識を、より一般的に持つだろう。既知の境界は、ルーティング階層でルータが維持する位置によって、ルータ毎に異なってもよい。
IPv6 ユニキャストアドレスのインタフェース識別子は、リンク上のインタフェースを識別するために使用される。それらは、そのリンク上でユニークである必要がある。より広い範囲でユニークであってもよい。多くの場合、インタフェースの識別子はインタフェースのリンク層アドレスと同じである。同じインタフェース識別子は、単一のノード上で複数のインタフェースで使用されてもよい。
単一ノードの複数のインタフェース上で同じインタフェース識別子を使用することは、そのインタフェース識別子を使用して作成されるインタフェース識別子のグローバルなユニークさ、あるいは IPv6 アドレスのグローバルなユニークさに影響を与えないことに注意されたい。
形式プレフィクスの数 (セクション 2.4 参照) において、インタフェース ID は 64 ビット長で、IEEE EUI-64 形式 [EUI64] で形成される必要がある。EUI-64 ベースのインタフェース識別子は、グローバルトークンが利用可能な場合 (例えば IEEE 48 ビット MAC) は、グローバルな適用範囲を持ってもよく、グローバルトークンが利用不可能な場合 (例えばシリアル回線や終点トンネル等) は、ローカルな適用範囲を持ってもよい。EUI-64 からインタフェース識別子を形成する場合は、「u」ビット (IEEE EUI-64 の用語で汎用/ローカルビット) を裏返す必要がある。「u」ビットは、グローバルな適用範囲を示すために 1 に設定され、ローカルな適用範囲を示すために 0 に設定される。EUI-64 識別子の 2進の最初の 3 オクテットは、以下の様に、
|0 0 0 1 1 2| |0 7 8 5 6 3| +----+----+----+----+----+----+ |cccc|ccug|cccc|cccc|cccc|cccc| +----+----+----+----+----+----+
インターネット標準のビット順序で記述され、「u」は汎用/ローカルビットであり、「g」は個別/グループビットであり、「c」は企業 id のビットである。付録 A: 「EUI-64 ベースのインタフェース識別子の生成」は、異なる EUI-64 ベースのインタフェース識別子の生成の例を提供する。
インタフェース識別子を形成する時に「u」ビットを裏返す動機は、ハードウゥアトークンを利用できない時に、システム管理者がローカルスコープの識別子を手動で設定することを容易にすることである。これはシリアル回線、終点トンネル等の場合に期待される。その代替は、これらが ::1, ::2 にかなり似た形式の代わりに、0200:0:0:1, 0200:0:0:2 の形式とすることになっただろう。
IEEE EUI-64 識別子の汎用/ローカルビットを使用することにより、グローバルスコープを持つインタフェース識別子を利用できる将来の技術の開発を可能にする。
インタフェース識別子を形成する詳細は、例えば「イーサネット上の IPv6」[ETHER]、「FDDI 上の IPv6」[FDDI] 等、適切な「<リンク>上の IPv6」規約で定義される。
0:0:0:0:0:0:0:0 は、未指定アドレスと呼ばれる。それは、如何なるノードにも割り当ててはならない。それは、アドレスの欠如を示す。それを使用する一つの例は、自分自身のアドレスを知る前の初期化中のホストが送信した IPv6 パケットの送信元アドレスである。
未指定アドレスは、IPv6 パケットや IPv6 ルーティングヘッダで宛先アドレスとして使用してはならない。
ユニキャストアドレス 0:0:0:0:0:0:0:1 は、ループバックアドレスと呼ばれる。それは、ノードが自分自身に IPv6 パケットを送信するために使用してよい。それは、如何なる物理インタフェースにも割り当てられない。それは、仮想インタフェース (例えばループバックインタフェース) に割り当てられているように考えてもよい。
ループバックアドレスは、単一ノードの外側に送信する IPv6 パケットの送信元アドレスとして使用してはならない。ループバックの宛先アドレスを持つ IPv6 パケットは、単一ノードの外側には決して送信しはならず、IPv6 ルータは決して転送してはならない。
IPv6 変換メカニズム [TRAN] は、ホストとルータが動的に IPv6 パケットを IPv4 ルーティング基盤上にトンネル化する技術を含む。この技術を利用する IPv6 ノードは、低次 32 ビットで IPv4 アドレスを運ぶ特殊な IPv6 ユニキャストアドレスを割り当てられる。このアドレスのタイプは、「IPv4-互換 IPv6 アドレス」と呼ばれ、以下の形式を持つ。
| 80 bits | 16 | 32 bits | +--------------------------------------+--------------------------+ |0000..............................0000|0000| IPv4 address | +--------------------------------------+----+---------------------+
埋め込まれた IPv4 アドレスを保持する IPv6 アドレスの二番目のタイプもまた定義される。このアドレスは、IPv4 のみの (IPv6 をサポートしていない) ノードのアドレスを、IPv6 アドレスとして表現するために使用される。このアドレスのタイプは、「IPv4-マッピング IPv6 アドレス」と呼ばれ、以下の形式を持つ。
| 80 bits | 16 | 32 bits | +--------------------------------------+--------------------------+ |0000..............................0000|FFFF| IPv4 address | +--------------------------------------+----+---------------------+
NSAP アドレスの IPv6 アドレスへのマッピンクは、[NSAP] で定義される。このドキュメントは、OSI NSAP アドレス付け計画を予定している、あるいは開発しているネットワーク実装者や、IPv6 を配置し、変換したいと考えているネットワーク実装者に、自分たちの要件に適合させるために IPv6 だけのアドレス付けを再設計することを推奨する。しかし、IPv6 ネットワークで OSI NSAP アドレス付けをサポートするための一連のメカニズムも定義する。これらのメカニズムは、もしそうしたサポートが必要ならば使用しなければならないものである。このドキュメントは、OSI アドレス形式の範囲内での IPv6 アドレスのマッピングが必要である場合に行うべきメカニズムも定義する。
IPX アドレスの IPv6 アドレスへのマッピングは、以下の通りである。
| 7 | 121 bits | +-------+---------------------------------------------------------+ |0000010| to be defined | +-------+---------------------------------------------------------+
ドラフト定義、動機、使用方法については、研究中である。
グローバルな集約可能グローバルユニキャストアドレスは、[AGGR] で定義される。このアドレス形式は、集約ベースの現在のプロバイダとエクスチェンジと呼ばれる新しいタイプの集約の両方をサポートするために設計される。その組み合わせは、プロバイダに直接接続するサイトと、エクスチェンジに接続するサイトの両方にとって、効率的なルーティング集約を可能にする。サイトは、集約点のどちらのタイプに接続するかの選択肢を持つ。
IPv6 集約可能グローバルユニキャストアドレス形式は、以下の通りである。
| 3| 13 | 8 | 24 | 16 | 64 bits | +--+-----+---+--------+--------+--------------------------------+ |FP| TLA |RES| NLA | SLA | Interface ID | | | ID | | ID | ID | | +--+-----+---+--------+--------+--------------------------------+
001 : 集約可能グローバルユニキャストアドレス形式のプレフィクス
(3 ビット)
TLA ID : 集約識別子の最上位レベル
RES : 将来の使用のために予約
NLA ID : 集約識別子の次レベル
SLA ID : 集約識別子のサイトレベル
INTERFACE ID : インタフェース識別子
内容、フィールドサイズ、割当て規則は、[AGGR] で定義される。
定義されたローカル使用ユニキャストアドレスには、二つのタイプが存在する。これらは、リンクローカルとサイトローカルである。リンクローカルは単一のリンクで使用するためのもので、サイトローカルは単一のサイトで使用するためのものである。リンクローカルアドレスは、下記の形式を持つ。
| 10 | | | bits | 54 bits | 64 bits | +----------+-------------------------+----------------------------+ |1111111010| 0 | interface ID | +----------+-------------------------+----------------------------+
リンクローカルアドレスは、例えば自動アドレス設定、隣接者検出、ルータが存在しない時などの目的で、単一のリンク上でアドレス付けするのに使用するために設計される。
ルータは、リンクローカルの送信元、宛先アドレスを持つパケットを他のリンクに転送してはならない。
サイトローカルアドレスは、下記の形式を持つ。
| 10 | | | bits | 38 bits | 16 bits | 64 bits | +----------+-------------+-----------+----------------------------+ |1111111011| 0 | subnet ID | interface ID | +----------+-------------+-----------+----------------------------+
サイトローカルアドレスは、グローバルなプレフィクスを持つ必要の無いサイトの代わりにアドレス付けするのに使用するために設計される。
ルータは、サイトローカルの送信元、宛先アドレスを持つパケットを他のサイトに転送してはならない。
IPv6 エニイキャストアドレスは、一つ以上のインタフェース (通常異なるノードに属する) に割り当てられるアドレスであり、エニイキャストアドレスに送信されたパケットは、ルーティングプロトコルの距離計測に従って、そのアドレスを持つ「最も近い」インタフェースに振り分けられるという特性を持つ。
エニイキャストアドレスは、定義されたユニキャストアドレス形式のどれかを使用して、ユニキャストアドレス空間から割り当てられる。従って、エニイキャストアドレスは文法的にユニキャストアドレスと識別できない。ユニキャストアドレスが一つ以上のインタフェースに割り当てられるためにエニイキャストアドレスに変わる時、そのアドレスが割り当てられたノードは、それがエニイキャストアドレスであることを認識できるよう明示的に設定しなければならない。
割り当てられたエニイキャストアドレスには全て、そのエニイキャストアドレスに属する全てのインタフェースが存在するトポロジー区域を識別する、最長のアドレスプレフィクス P が存在する。P によって識別される区域内では、エニイキャスト集合の各々のメンバは、ルーティングシステム中の (通常「ホスト経路」と呼ばれる) 別々のエントリとして通知されなければならない。P によって識別される区域外では、エニイキャストアドレスはプレフィクス P のルーティング通知に集約させてもよい。
注記: 最悪の場合、エニイキャスト集合のプレフィクス P はヌルプレフィクスかもしれない。すなわち、その集合のメンバがトポロジー上の場を持たないかもしれない。その場合、そのエニイキャストアドレスはインターネット全体にわたって別個のルーティングエントリとして通知しなければならず、そのような「グローバルな」エニイキャスト集合を幾つサポートするかについて、厳しい規模制限が存在する。従って、グローバルなエニイキャスト集合のサポートは利用できない、あるいは非常に制限されることが期待される。
エニイキャストアドレスの期待された一つの使用方法は、インターネットサービスを提供している組織に属するルータの集合を識別することである。そのようなアドレスは、IPv6 ルーティングヘッダの中間アドレスで使用でき、特定の集約、あるいは一連の集約を経由してパケットを配送できる。他の有り得る使用方法は、特定のサブネットに接続されたルータの集合や、特定のルーティングドメインへのエントリを提供しているルータの集合を識別することである。
広範囲に、任意にインターネットエニイキャストアドレスを使用する経験はほとんど無く、完全に一般的にそれらを使用する時、既知の複雑な問題や危険が存在する [ANYCAST]。より多くの経験を積み、それらの問題に対して合意された解決法が得られるまでは、IPv6 エニイキャストアドレスに以下の制限が課せられる。
サブネットルータエニイキャストアドレスは、前もって定義される。その形式は下記の通り。
| n bits | 128-n bits | +------------------------------------------------+----------------+ | subnet prefix | 00000000000000 | +------------------------------------------------+----------------+
エニイキャストアドレス中の「サブネットプレフィクス」は、特定のリンクを識別するプレフィクスである。このエニイキャストアドレスは、文法的にインタフェース識別子を 0 に設定したリンク上のインタフェースのためのユニキャストアドレスと同一である。
サブネットルータエニイキャストアドレスに送信されるパケットは、そのサブネット上の一つのルータに配送されるだろう。全てのルータは、インタフェースを持つサブネットのサブネットルータエニイキャストアドレスをサポートする必要がある。
サブネットルータエニイキャストアドレスは、ノードがリモートのサブネット上にある複数ルータの一つと通信する必要のあるアプリケーションで使用されることを意図している。例えば、移動体ホストが、その「ホーム」サブネット上の移動体エージェントの一つと通信する必要がある場合である。
IPv6 マルチキャストアドレスは、ノードのグループのための識別子である。ノードは、如何なる数のマルチキャストグループに属してもよい。マルチキャストアドレスは、以下の形式を持つ。
| 8 | 4 | 4 | 112 bits | +------ -+----+----+---------------------------------------------+ |11111111|flgs|scop| group ID | +--------+----+----+---------------------------------------------+
アドレスの開始部分の 11111111 は、そのアドレスがマルチキャストアドレスであるとこを識別する。
flags は、四つのフラグを持つ。
+-+-+-+-+ |0|0|0|T| +-+-+-+-+
高次 3 フラグは予約されており、0 で初期化しなければならない。
T = 0 は、グローバルなインターネット番号割当てによって永久に割り当てられる (「よく知られた」) マルチキャストアドレスを示す。
T = 1 は、永久に割り当てられたものではない(「一時的な」) マルチキャストアドレスを示す。
scop は、マルチキャストグループの適用範囲を限定するのに使用される 4 ビットのマルチキャストスコープ値である。その値は、
0 予約
1 ノードローカルスコープ
2 リンクローカルスコープ
3 (未割当て)
4 (未割当て)
5 サイトローカルスコープ
6 (未割当て)
7 (未割当て)
8 組織ローカルスコープ
9 (未割当て)
A (未割当て)
B (未割当て)
C (未割当て)
D (未割当て)
E グローバルスコープ
F 予約
group ID は、提供された適用範囲内で、永久的か一時的のいずれかのマルチキャストグループを識別する。
永久的に割り当てられたマルチキャストアドレスの「意味」は、スコープ値に依存しない。例えば、もし「NTP サーバグループ」が 101 (16進)の group ID を持つ永久的なマルチキャストアドレスを割り当てられたら:
FF01:0:0:0:0:0:0:101 は、送信側と同一ノード上の全ての NTP サーバを意味する。
FF02:0:0:0:0:0:0:101 は、送信側と同一リンク上の全ての NTP サーバを意味する。
FF05:0:0:0:0:0:0:101 は、送信側と同一サイト上の全ての NTP サーバを意味する。
FF0E:0:0:0:0:0:0:101 は、インターネット内の全ての NTP サーバを意味する。
永久に割り当てられたものではないマルチキャストアドレスは、与えられた適用範囲内でのみ意味を持つ。例えば、あるサイトにおける、非永久的によって識別されるグループのサイトローカルマルチキャストアドレス FF15:0:0:0:0:0:0:101 は、異なるサイトで同じアドレスを使用するグループとも、異なる適用範囲で同じ group ID を使用する非永久的グループとも、同じ group ID を持つ永久的グループとも関係を持たない。
マルチキャストアドレスは IPv6 パケットの送信元アドレスで使用されてはならず、如何なるルーティングヘッダにも現れてはならない。
以下の良く知られたマルチキャストアドレスが、前もって定義される。
予約マルチキャストアドレス:
FF00:0:0:0:0:0:0:0
FF01:0:0:0:0:0:0:0
FF02:0:0:0:0:0:0:0
FF03:0:0:0:0:0:0:0
FF04:0:0:0:0:0:0:0
FF05:0:0:0:0:0:0:0
FF06:0:0:0:0:0:0:0
FF07:0:0:0:0:0:0:0
FF08:0:0:0:0:0:0:0
FF09:0:0:0:0:0:0:0
FF0A:0:0:0:0:0:0:0
FF0B:0:0:0:0:0:0:0
FF0C:0:0:0:0:0:0:0
FF0D:0:0:0:0:0:0:0
FF0E:0:0:0:0:0:0:0
FF0F:0:0:0:0:0:0:0
上記のマルチキャストアドレスは予約されており、如何なるマルチキャストグループにも割り当ててはならない。
全ノードアドレス:
FF01:0:0:0:0:0:0:1
FF02:0:0:0:0:0:0:1
上記のマルチキャストアドレスは、スコープ 1 (ノードローカル) か 2 (リンクローカル) の範囲内で、全ての IPv6 ノードのグループを識別する。
全ルータアドレス:
FF01:0:0:0:0:0:0:2
FF02:0:0:0:0:0:0:2
FF05:0:0:0:0:0:0:2
上記のマルチキャストアドレスは、スコープ 1 (ノードローカル) か 2 (リンクローカル) か 3 (サイトローカル) の範囲内で、全ての IPv6 ルータのグループを識別する。
要請ノードアドレス:
FF02:0:0:0:0:1:FFXX:XXXX
上記のマルチキャストアドレスは、ノードのユニキャストとエニイキャストアドレスの機能として算出される。要請ノードマルチキャストアドレスは、(ユニキャストかエニイキャスト) アドレスの低次 24 ビットを取り、それらのビットをプレフィクス FF02:0:0:0:0:1:FF00::/104 に付加することによって形成され、結果 FF02:0:0:0:0:1:FF00:0000 から FF02:0:0:0:0:1:FFFF:FFFF までの範囲のアドレスとなる。
例えば、IPv6 アドレス 4037::01:800:200E:8C6C に対応する要請ノードマルチキャストアドレスは、FF02::1:FF0E:8C6C である。例えば異なる集約に割り当てられた複数の高次プレフィクスのために、高次ビットのみが異なる IPv6 アドレスは、それによってノードが参加しなければならないマルチキャストアドレスの数を減らしている、同じ要請ノードアドレスにマッビングするだろう
ノードは、割り当てられた全てのユニキャストとエニイキャストアドレスに結びついた要請ノードマルチキャストアドレスを算出し、参加する必要がある。
IPv6 マルチキャストアドレスを IEEE 802 MAC アドレスにマッビングするための現在のアプローチ [ETHER] は、IPv6 マルチキャストアドレスの低次 32 ビットを取り、それを MAC アドレスを生成するために使用する。トークンリングネットワークは、別個に扱われることに注意されたい。これは [TOKEN] で定義される。32 ビット以下のグループ ID は、ユニークな MAC アドレスを生成するだろう。このため、新しい IPv6 マルチキャストアドレスは、グループ識別子が以下に示されるように低次 32 ビット中に常にあるように割り当てなければならない。
| 8 | 4 | 4 | 80 bits | 32 bits | +------ -+----+----+---------------------------+-----------------+ |11111111|flgs|scop| reserved must be zero | group ID | +--------+----+----+---------------------------+-----------------+
これは永久的 IPv6 マルチキャストグループの数を 2^32 に制限するが、将来の制限にはならないであろう。もし、将来この制限を超えることが必要になるなら、マルチキャストは依然として作用するが、処理は若干遅くなるだろう。
追加の IPv6 マルチキャストアドレスは、IANA [MASGN] によって定義され、登録される。
ホストは、以下のアドレスを自分自身を識別するアドレスとして認識する必要がある。
ルータは、ホストが認識する必要のあるアドレス全てに加え、以下のアドレスを自分自身を識別するアドレスとして認識する必要がある。
実装体で前もって定義すべき唯一のアドレスプレフィクスは、
実装体は、特殊な設定がなされていなければ (例えばエニイキャストアドレス)、他の全てのアドレスはユニキャストであると仮定すべきである。
IPv6 アドレス付けドキュメントは、インターネット基盤セキュリティに直接影響しない。IPv6 パケットの認証は [AUTH] で定義される。
特定のリンクやノードの特性に依存して、EUI ベースのインタフェース識別子を生成するためのアプローチは数多く存在する。この付録では、これらのアプローチの幾つかについて説明する。
EUI-64 識別子を持つリンクやノード
EUI-64 識別子をインタフェース識別子に変換するのに必要な唯一の変更点は、「u」(汎用/ローカル)ビットを挿入することである。例えば、以下の形式のグローバルにユニークな
EUI-64 識別子では、
|0 1|1 3|3 4|4 6| |0 5|6 1|2 7|8 3| +----------------+----------------+----------------+----------------+ |cccccc0gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm| +----------------+----------------+----------------+----------------+
「c」は company_id を割り当てられたビットであり、「0」はグローバルスコープを示す汎用/ローカルビットの値であり、「g」は個別/グループビットであり、「m」は製造者選択の拡張識別子のビットである。以下の形式の IPv6 インタフェース識別子では、
|0 1|1 3|3 4|4 6| |0 5|6 1|2 7|8 3| +----------------+----------------+----------------+----------------+ |cccccc1gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm| +----------------+----------------+----------------+----------------+
唯一の変更は、汎用/ローカルビットの値を挿入することである。
IEEE 802 48 ビット MAC を持つリンクやノード
[EUI64]
は、IEEE 48 ビット MAC 識別子から EUI-64 識別子を生成するための方法を定義する。これは、0xFF
と 0xFE の 16進値を持つ二オクテットを、48 ビット MAC の中間 (company_id
とベンタ供給 id との間) に挿入するためのものである。例えば、以下のグローバルスコープを持つ
48 ビット MAC では:
|0 1|1 3|3 4| |0 5|6 1|2 7| +----------------+----------------+----------------+ |cccccc0gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm| +----------------+----------------+----------------+
「c」は company_id を割り当てられたビットであり、「0」はグローバルスコープを示す汎用/ローカルビットの値であり、「g」は個別/グループビットであり、「m」は製造者選択の拡張識別子のビットである。以下の形式のインタフェース識別子では、
|0 1|1 3|3 4|4 6| |0 5|6 1|2 7|8 3| +----------------+----------------+----------------+----------------+ |cccccc1gcccccccc|cccccccc11111111|11111110mmmmmmmm|mmmmmmmmmmmmmmmm| +----------------+----------------+----------------+----------------+
IEEE 802 48ビット MAC アドレスが (インタフェースかノード上で) 利用可能である場合、実装体はそれを利用できることとユニークさの特性のために、インタフェース識別子を生成するのにそれらを使用すべきである。
非グローバル識別子を持つリンク
複数アクセスである一方、グローバルにユニークなリンク識別子を持たない数多くのタイプのリンクが存在する。例は、LocalTalk
と Arcnet を含む。EUI-64 形式化された識別子を生成する方法は、リンク識別子
(例えば LocalTalk 8 ビットノード識別子) を取り、左側に 0 を埋めることである。例えば、16進値
0x4F の LocalTalk 8 ビットノード識別子は、結果として以下のインタフェース識別子になる。
|0 1|1 3|3 4|4 6| |0 5|6 1|2 7|8 3| +----------------+----------------+----------------+----------------+ |0000000000000000|0000000000000000|0000000000000000|0000000001001111| +----------------+----------------+----------------+----------------+
これは、ローカルスコープを示すために汎用/ローカルビットを「0」に設定した結果であることに注意されたい。
識別子の無いリンク
組み込み識別子のタイプを持たない数多くのリンクが存在する。これらの最も共通な点は、シリアル回線でトンネル化設定である。インタフェース識別子は、リンクに対してユニークであるよう選択しなければならない。
組み込み識別子がリンク上で利用できない時、好ましいアプローチは、別のインタフェースかノード自身に割り当てられたインタフェースからグローバルなインタフェース識別子を使用することである。このアプローチを使用するために、同じインタフェースを使用してもよい、同一ノードを同一リンクに接続する他のインタフェースは無い。
もしリンク上で使用できるグローバルなインタフェース識別子が存在しないならば、実装体はローカルスコープのインタフェース識別子を生成する必要がある。唯一の要件は、そのリンク上でユニークであることである。リンクユニークなインタフェース識別子を選択するための可能なアプローチは数多く存在する。それらは以下を含む。
手動設定
ランダムな数の生成
ノードシリアル番号 (他のノード特定トークン)
リンクユニークインタフェースは、ノードの再起動や、ノードにインタフェースを追加したり削除した場合に変更されない方法で生成すべきである。
適切なアルゴリズムの選択は、リンクや実装に依存する。インタフェース識別子を形成する詳細は、適切な「<リンク>上の IPv6」規約で定義される。自動アルゴリズムの一部として、衝突検出アルゴリズムを実装することが強く推奨される。
この付録は、参照目的で拡張 BNF [ABNF] による IPv6 アドレスとプレフィクスのテキスト表現を定義する。
IPv6address = hexpart [ ":" IPv4address ] IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT IPv6prefix = hexpart "/" 1*2DIGIT hexpart = hexseq | hexseq "::" [ hexseq ] | "::" [ hexseq ] hexseq = hex4 *( ":" hex4) hex4 = 1*4HEXDIG
以下の変更点は、RFC-1884 「IP バージョン 6 アドレス体系」からの変更点である。
[ABNF] Crocker, D., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[AGGR] Hinden, R., O'Dell, M., and S. Deering, "An Aggregatable Global Unicast Address Format", RFC 2374, July 1998.
[AUTH] Atkinson, R., "IP Authentication Header", RFC 1826, August 1995.
[ANYCST] Partridge, C., Mendez, T., and W. Milliken, "Host Anycasting Service", RFC 1546, November 1993.
[CIDR] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless Inter-Domain Routing (CIDR): An Address Assignment and Aggregation Strategy", RFC 1519, September 1993.
[ETHER] Crawford, M., "Transmission of IPv6 Pacekts over Ethernet Networks", Work in Progress.
[EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) Registration Authority", http://standards.ieee.org/db/oui/tutorials/EUI64.html, March 1997.
[FDDI] Crawford, M., "Transmission of IPv6 Packets over FDDI Networks", Work in Progress.
[IPV6] Deering, S., and R. Hinden, Editors, "Internet Protocol, Version 6 (IPv6) Specification", RFC 1883, December 1995.
[MASGN] Hinden, R., and S. Deering, "IPv6 Multicast Address Assignments", RFC 2375, July 1998.
[NSAP] Bound, J., Carpenter, B., Harrington, D., Houldsworth, J., and A. Lloyd, "OSI NSAPs and IPv6", RFC 1888, August 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[TOKEN] Thomas, S., "Transmission of IPv6 Packets over Token Ring Networks", Work in Progress.
[TRAN] Gilligan, R., and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", RFC 1993, April 1996.
Robert M. Hinden Nokia 232 Java Drive Sunnyvale, CA 94089 USA Phone: +1 408 990-2004 Fax: +1 408 743-5677 EMail: hinden@iprg.nokia.com Stephen E. Deering Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA Phone: +1 408 527-8213 Fax: +1 408 527-8254 EMail: deering@cisco.com
Copyright (C) The Internet Society (1998). 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.
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.