|
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" は company_id のビットである。付録 A: "EUI-64 ベースのインタフェース識別子の生成" は、異なる EUI-64 ベースのインタフェース識別子の生成の例を提供している。
インタフェース識別子を構成する時に "u" ビットを反転する動機は、ハードウェアトークンが利用できない時に、システム管理者がローカルスコープの識別子を手動で設定することを容易にすることである。これはシリアル回線やトンネルの終点等の場合に期待される。さもなくば、ずっと簡単な ::1, ::2 等の代わりに、0200:0:0:1, 0200:0:0:2 等の形式とすることになっただろう。
IEEE EUI-64 識別子の汎用/ローカルビットを使用することにより、グローバルスコープを持つインタフェース識別子を利用できる将来の技術の開発を可能にする。
インタフェース識別子の形式の詳細は、例えば "IPv6 over Ethernet" [ETHER], "IPv6 over FDDI" [FDDI] 等の適切な "IPv6 over <link>" 規約で定義される。
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 | +------------------------------------------------+----------------+
エニイキャストアドレス中の "subnet prefix" は、特定のリンクを識別するプレフィクスである。このエニイキャストアドレスは、文法的にインタフェース識別子を 0 に設定したリンク上のインタフェースのためのユニキャストアドレスと同じである。
サブネットルータエニイキャストアドレスに送信されるパケットは、そのサブネット上の一つのルータに配送されるだろう。全てのルータは、インタフェースを持つサブネットのサブネットルータエニイキャストアドレスをサポートする必要がある。
サブネットルータエニイキャストアドレスは、ノードがリモートのサブネット上にあるルータの組み一つと通信する必要のあるアプリケーションで使用されることを意図している。例えば、モバイルホストが、その "ホーム" サブネット上のモバイルエージェントの一つと通信する必要がある場合である。
IPv6 マルチキャストアドレスは、ノードのグループのための識別子である。ノードは、如何なる数のマルチキャストグループに属してもよい。マルチキャストアドレスは、以下の形式を持つ。
| 8 | 4 | 4 | 112 bits | +------ -+----+----+---------------------------------------------+ |11111111|flgs|scop| group ID | +--------+----+----+---------------------------------------------+
アドレスの開始部分の 11111111 は、そのアドレスがマルチキャストアドレスであることを示す。
flgs は 4 つのフラグの組みである
+-+-+-+-+ |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] は、EUI-64 識別子を IEEE 48 ビット MAC 識別子から生成するための方法を定義する。これは、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.