Network Working Group R. Hinden Request for Comments: 2373 Nokia Obsoletes: 1884 S. Deering Category: Standards Track Cisco Systems July 1998 IP Version 6 Addressing Architecture Status of this Memo このドキュメントは、インターネット社会の為のインターネット標準トラッ クプロトコルを規定しており、改善の為の議論と提案を求めている。この プロトコルの標準化の状態と状況については、"Internet Official Protocol Standards" (STD 1) の現在の版を参照されたい。このメモの配 布は制限されない。 Copyright Notice Copyright (C) The Internet Society (1998). All Rights Reserved. Abstract この規約は、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 からの変更点 参照 作者のアドレス 完全なコピーライト宣言 1.0 導入 この規約は、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」で説明されているものと同等に解釈する。 2.0 IPv6 アドレッシング IPv6 アドレスは、インタフェースやインタフェースの集合のための 128 ビット識別子である。三つのタイプのアドレスが存在する。 ユニキャスト: 単一のインタフェースの識別子。ユニキュストアドレ スに送信されるパケットは、そのアドレスによって識 別されるインタフェースに配送される。 エニイキャスト: 一組のインタフェースの識別子 (通常、異なるノード に属する)。エニイキャストアドレスに送信されるパ ケットは、そのアドレスによって識別されるインタフェ ースの一つ (ルーティングプロトコルの距離計測に従っ て "最も近い" もの) に配送される。 マルチキャスト: 一組のインタフェースの識別子 (通常、異なるノード に属する)。マルチキャストアドレスに送信されるパ ケットは、そのアドレスによって識別されるインタフェ ースの全てに配送される。 IPv6 ではブロードキャストアドレスは存在せず、その機能はマルチキャス トアドレスによって代替される。 このドキュメントでは、アドレス中のフィールドは例えば "subscriber" といった特定の名前が付与される。この名前が、名前の後ろに識別子とし て "ID" という用語が付いて使用される場合 (例えば "subscriber ID")、 その名前のフィールドの内容を指し示す。"prefix" という用語が付いて使 用される場合 (例えば "subscriber prefix")、左からこのフィールドを含 むこのフィールドまでのアドレス全てを指し示す。 IPv6 では、全て 1 と全て 0 は、特に禁止していなければどのフィールド においても正しい値である。特に、プレフィクスは 0 値のフィールドを含 んでもよいし、0 で終わってもよい。 2.1 アドレッシングモデル 全てのタイプの IPv6 アドレスは、ノードではなくインタフェースに割り 当てられる。IPv6 ユニキャストアドレスは、単一のインタフェースを示す。 各々のインタフェースは単一のノードに属すので、ノードのインタフェー スのユニキャストアドレスはいずれも、ノードの識別子として使用してよ い。 全てのインタフェースは、少なくとも一つのリンクローカルユニキャスト アドレスを持つ必要がある (追加の必須アドレスについてはセクション 2.8 参照)。単一インタフェースは、如何なるタイプ (ユニキャスト、エニ イキャスト、マルチキャスト)、あるいはスコープの IPv6 アドレスに割り 当ててもよい。リンクスコープより大きいスコープを持つユニキャストア ドレスは、非隣接者宛て/からの IPv6 パケットの送信元か宛先として使用 されないインタフェースには必要ではない。これは、時にはポイントツー ポイントインタフェースで都合がよい。このアドレッシングモデルには、 一つの例外がある。 もし実装体が、複数の物理インタフェースをインターネット層に見せる 時に一つのインタフェースとして扱うのであれば、一つのユニキャスト アドレス、あるいは一組のユニキャストアドレスを複数の物理インタフェ ースに割り当ててもよい。これは、複数の物理インタフェース上で負荷 分散する際に都合がよい。 現在 IPv6 は、サブネットプレフィクスが一つのリンクに割り当てられる という IPv4 モデルを引き継いでいる。複数のサブネットプレフィクスを 同じリンクに割り当ててもよい。 2.2 アドレスのテキスト表現 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 2.3 アドレスプレフィクスのテキスト表現 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 のように省略して記述でき る。 2.4 アドレスタイプ表現 IPv6 アドレスの特殊なタイプは、アドレス中の頭のビットによって示され る。これらの頭のビットを構成する可変長のフィールドは、形式プレフィ クス (FP: Format Prefix) と呼ばれる。これらのプレフィクスの初期割当 ては、下記の通りである。 割当て プレフィクス アドレス (2 進) 空間の部分 --------------------------------------- -------- ---------- 予約 0000 0000 1/256 未割当て 0000 0001 1/256 NSAP 割当てのために予約 0000 001 1/128 IPX 割当てのために予約 0000 010 1/128 未割当て 0000 011 1/128 未割当て 0000 1 1/32 未割当て 0001 1/16 集約可能なグローバルユニキャストアドレス 001 1/8 未割当て 010 1/8 未割当て 011 1/8 未割当て 100 1/8 未割当て 101 1/8 未割当て 110 1/8 未割当て 1110 1/16 未割当て 1111 0 1/32 未割当て 1111 10 1/64 未割当て 1111 110 1/128 未割当て 1111 1110 0 1/512 リンクローカルユニキャストアドレス 1111 1110 10 1/1024 サイトローカルユニキャストアドレス 1111 1110 11 1/1024 マルチキャストアドレス 1111 1111 1/256 注記: (1) "未指定アドレス" (セクション 2.5.2 参照)、ループバックアドレ ス (セクション 2.5.3 参照)、埋め込み IPv4 アドレスを持つ IPv6 アドレス (セクション 2.5.4 参照) は、0000 0000 形式のプ レフィクス空間から割り当てられる。 (2) マルチキャストアドレス (1111 1111) を除くプレフィクス 001 か ら 111 までの形式は、全て EUI-64 形式の 64 ビットインタフェ ース識別子を持つ必要がある。定義については、セクション 2.5.1 を参照されたい。 この割当ては、集約アドレス、ローカル使用アドレス、マルチキャストア ドレスの直接割当てをサポートする。空間は、NSAP アドレスと IPX アド レスのために予約される。残りのアドレス空間は、将来の使用のために割 り当てられない。これは既存の使用の拡張 (例えば追加の集約アドレス) や、新しい使用 (例えば別々の位置子と識別子) で使用できる。アドレス 空間の 15% が初期に割り当てられる。残りの 85% は将来の使用のために 予約される。 ユニキャストアドレスは、アドレスの高次オクテットの値によってマルチ キャストアドレスと区別される。FF (11111111) の値はアドレスをマルチ キャストアドレスとして識別し、他の値はアドレスをユニキャストアドレ スとして識別する。エニイキャストアドレスは、ユニキャストアドレス空 間から割り当てられ、シンタックス上はユニキャストアドレスと区別でき ない。 2.5 ユニキャストアドレス IPv6 ユニキャストアドレスは、クラスレスドメイン間ルーティング [CIDR] に基づく IPv4 アドレスと同様に、連続したビットマスクで集約できる。 IPv6 では、幾つかの形式のユニキャストアドレス割当てが存在し、グロー バルな集約可能グローバルユニキャストアドレス、NSAP アドレス、IPX 階 層アドレス、サイトローカルアドレス、リンクローカルアドレス、IPv4 機 能を持つホストアドレスを含む。追加のアドレスタイプを、将来定義する ことは可能である。 IPv6 ノードは、IPv6 アドレスの内部構造についてかなりの、あるいはわ ずかの知識を持ってもよく、それはノードの果たす役割 (例えばホスト対 ルータ) に依存する。最小限では、ノードは (自分自身を含む) ユニキャ ストアドレスは内部構造を持たないと考えてもよい。 | 128 bits | +-----------------------------------------------------------------+ | node address | +-----------------------------------------------------------------+ 若干洗練されたホスト (しかしまだ単純) は、付加的に自分が接続されて いるリンクのサブネットプレフィクスを知ってもよい。その場合、異なる アドレスが異なる n の値を持ってもよい。 | n bits | 128-n bits | +------------------------------------------------+----------------+ | subnet prefix | interface ID | +------------------------------------------------+----------------+ より洗練されたホストは、ユニキャストアドレスで他の階層的な境界を知っ てもよい。非常に単純なルータは IPv6 ユニキャストアドレスの内部構造 の知識を持たないが、ルータは、ルーティングプロトコルの処理のために 一つ以上の階層的な境界の知識を、より一般的に持つだろう。既知の境界 は、ルーティング階層でルータが維持する位置によって、ルータ毎に異なっ てもよい。 2.5.1 インタフェース識別子 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 " 規約 で定義される。 2.5.2 未指定アドレス 0:0:0:0:0:0:0:0 は、未指定アドレスと呼ばれる。それは、如何なるノー ドにも割り当ててはならない。それは、アドレスが無いことを示す。それ を使用する一つの例は、自分自身のアドレスを知る前に初期化中のホスト が送信した IPv6 パケットの送信元アドレスフィールドである。 未指定アドレスは、IPv6 パケットや IPv6 ルーティングヘッダで宛先アド レスとして使用してはならない。 2.5.3 ループバックアドレス ユニキャストアドレス 0:0:0:0:0:0:0:1 は、ループバックアドレスと呼ば れる。それは、ノードが自分自身に IPv6 パケットを送信するために使用 してよい。それは、如何なる物理インタフェースにも割り当てられない。 それは、仮想インタフェース (例えばループバックインタフェース) に割 り当てられているように考えてもよい。 ループバックアドレスは、単一ノードの外側に送信する IPv6 パケットの 送信元アドレスとして使用してはならない。ループバックの宛先アドレス を持つ IPv6 パケットは、単一ノードの外側に送信してはならず、IPv6 ル ータは転送してはならない。 2.5.4 埋め込み IPv4 アドレスを持つ 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 | +--------------------------------------+----+---------------------+ 2.5.5 NSAP アドレス NSAP アドレスの IPv6 アドレスへのマッピンクは、[NSAP] で定義される。 このドキュメントは、OSI NSAP アドレス付け計画を予定している、あるい は開発しているネットワーク実装者や、IPv6 を配置し、変換したいと考え ているネットワーク実装者に、自分たちの要件に適合させるために IPv6 だけのアドレス付けを再設計することを推奨する。しかし、IPv6 ネットワ ークで OSI NSAP アドレス付けをサポートするための一連のメカニズムも 定義する。これらのメカニズムは、もしそうしたサポートが必要ならば使 用しなければならないものである。このドキュメントは、OSI アドレス形 式の範囲内での IPv6 アドレスのマッピングが必要である場合に行うべき メカニズムも定義する。 2.5.6 IPX アドレス IPX アドレスの IPv6 アドレスへのマッピングは、以下の通りである。 | 7 | 121 bits | +-------+---------------------------------------------------------+ |0000010| to be defined | +-------+---------------------------------------------------------+ ドラフト定義、動機、使用方法については、研究中である。 2.5.7 集約可能なグローバルユニキャストアドレス グローバルな集約可能グローバルユニキャストアドレスは、[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] で定義される。 2.5.8 ローカル使用 IPv6 ユニキャストアドレス 定義されたローカル使用ユニキャストアドレスには、二つのタイプが存在 する。これらは、リンクローカルとサイトローカルである。リンクローカ ルは単一のリンクで使用するためのもので、サイトローカルは単一のサイ トで使用するためのものである。リンクローカルアドレスは、以下の形式 を持つ。 | 10 | | bits | 54 bits | 64 bits | +----------+-------------------------+----------------------------+ |1111111010| 0 | interface ID | +----------+-------------------------+----------------------------+ リンクローカルアドレスは、例えば自動アドレス設定、隣接者検出、ルー タが存在しない時などの目的で、単一のリンク上のアドレッシングで使用 するために設計されている。 ルータは、リンクローカルな送信元あるいは宛先アドレスを持つパケット を他のリンクに転送してはならない。 サイトローカルアドレスは、以下の形式を持つ。 | 10 | | bits | 38 bits | 16 bits | 64 bits | +----------+-------------+-----------+----------------------------+ |1111111011| 0 | subnet ID | interface ID | +----------+-------------+-----------+----------------------------+ サイトローカルアドレスは、グローバルなプレフィクスを持つ必要の無い サイトの代わりのアドレッシングで使用するために設計されている。 ルータは、サイトローカルな送信元あるいは宛先アドレスを持つパケット を他のサイトに転送してはならない。 2.6 エニイキャストアドレス IPv6 エニイキャストアドレスは、 (通常異なるノードに属する) 一つ以上 のインタフェースに割り当てられるアドレスであり、エニイキャストアド レスに送信されたパケットは、ルーティングプロトコルの距離計測に従っ て、そのアドレスを持つ "最も近い" インタフェースに振り分けられると いう特性を持つ。 エニイキャストアドレスは、定義されたユニキャストアドレス形式のいず れかを使用して、ユニキャストアドレス空間から割り当てられる。従って、 エニイキャストアドレスは文法的にユニキャストアドレスと区別できない。 ユニキャストアドレスが一つ以上のインタフェースに割り当てられ、その ためにエニイキャストアドレスに変わる時、そのアドレスが割り当てられ たノードは、それがエニイキャストアドレスであることを認識できるよう 明示的に設定しなければならない。 割り当てられたエニイキャストアドレスには全て、そのエニイキャストア ドレスに属する全てのインタフェースが存在するトポロジーの範囲を識別 する、最長のアドレスプレフィクス P が存在する。P によって識別される 範囲内では、エニイキャストの組みの各々のメンバは (通常 "ホスト経路" と呼ばれる) ルーティングシステム中の別々のエントリとして通知しなけ ればならない。P によって識別される範囲外では、エニイキャストアドレ スはプレフィクス P のルーティング通知に集約させてもよい 最悪のケースでは、エニイキャストセットのプレフィクス P はヌルプレフィ クスかもしれないことに注意されたい。すなわち、そのセットのメンバが トポロジー上の場を持たないかもしれない。その場合、そのエニイキャス トアドレスはインターネット全体に渡って別々のルーティングエントリと して通知しなければならず、そうした "グローバルな" エニイキャストセッ トを幾つサポートするかについて、厳しい規模制限が存在する。従って、 グローバルエニイキャストセットのサポートは利用できない、あるいは非 常に制限されると予想される。 エニイキャストアドレスの期待された一つの使用方法は、インターネット サービスを提供している組織に属するルータの組みを識別することである。 そのようなアドレスは、IPv6 ルーティングヘッダの中間アドレスとして使 用でき、特定の集団あるいは一連の集団を経由してパケットを配送させる ことができる。他の有り得る使用方法は、特定のサブネットに接続された ルータの組みや、特定のルーティングドメインへのエントリを提供してい るルータの組みを識別することである。 広範囲に、任意にインターネットエニイキャストアドレスを使用する経験 はほとんど無く、完全に一般的にそれらを使用する場合、既知の複雑な問 題や障害が存在する [ANYCAST]。より多くの経験を積み、それらの問題に 対して合意された解決法が得られるまでは、以下の制限が IPv6 エニイキャ ストアドレスに課せられる。 o エニイキャストアドレスは、IPv6 パケットの送信元アドレスとして 使用してはならない。 o エニイキャストアドレスは IPv6 ホストに割り当ててはならない。す なわち、IPv6 ルータにのみ割り当ててよい。 2.6.1 エニイキャストアドレス要件 サブネットルータエニイキャストアドレスは、あらかじめ定義されている。 その形式は下記の通り。 | n bits | 128-n bits | +------------------------------------------------+----------------+ | subnet prefix | 00000000000000 | +------------------------------------------------+----------------+ エニイキャストアドレス中の "subnet prefix" は、特定のリンクを識別す るプレフィクスである。このエニイキャストアドレスは、文法的にインタ フェース識別子を 0 に設定したリンク上のインタフェースのためのユニキャ ストアドレスと同じである。 サブネットルータエニイキャストアドレスに送信されるパケットは、その サブネット上の一つのルータに配送されるだろう。全てのルータは、イン タフェースを持つサブネットのサブネットルータエニイキャストアドレス をサポートする必要がある。 サブネットルータエニイキャストアドレスは、ノードがリモートのサブネッ ト上にあるルータの組み一つと通信する必要のあるアプリケーションで使 用されることを意図している。例えば、モバイルホストが、その "ホーム" サブネット上のモバイルエージェントの一つと通信する必要がある場合で ある。 2.7 マルチキャストアドレス 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 パケットの送信元アドレスで使用しては ならず、如何なるルーティングヘッダにも現れてはならない。 2.7.1 あらかじめ定義されたマルチキャストアドレス 以下の良く知られたマルチキャストアドレスが、あらかじめ定義されてい る。 予約マルチキャストアドレス: 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 アドレスは、同じ要請ノードアドレスにマッビングされ、それ によってノードが参加しなければならないマルチキャストアドレスの数を 減らしている、 ノードは、割り当てられた全てのユニキャストとエニイキャストアドレス のための、関連する要請ノードマルチキャストアドレスを算出し、参加す る必要がある。 2.7.2 新しい 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] によって定義され、 登録される。 2.8 ノードに要求されるアドレス ホストは、以下のアドレスを自分自身を識別するアドレスとして認識する 必要がある。 o 各インタフェースのリンクローカルアドレス o 割り当てられたユニキャストアドレス o ループバックアドレス o 全ノードマルチキャストアドレス o 割り当てられたユニキャストとエニイキャストの各々の要請ノードマ ルチキャストアドレス o ホストが属する他の全てのグループのマルチキャストアドレス ルータはホストが認識する必要のあるアドレス全てに加え、以下のアドレ スを自分自身を識別するアドレスとして認識する必要がある。 o ルータとして動作するよう設定されたインタフェースのサブネットル ータエニイキャストアドレス o ルータに設定された他の全てのエニイキャストアドレス o 全ルータマルチキャストアドレス o ルータが属する他の全てのグループのマルチキャストアドレス 実装体で前もって定義すべき唯一のアドレスプレフィクスは、 o 未指定アドレス o ループバックアドレス o マルチキャストプレフィクス (FF) o ローカル使用プレフィクス (リンクローカルとサイトローカル) o あらかじめ定義されたマルチキャストアドレス o IPv4 互換プレフィクス 実装体は、特殊な設定がなされていなければ (例えばエニイキャストアド レス)、他の全てのアドレスはユニキャストであると仮定すべきである。 3. セキュリティの考慮 IPv6 アドレッシングドキュメントは、インターネット基盤セキュリティに は直接影響しない。IPv6 パケットの認証は [AUTH] で定義されている。 付録 A: EUI-64 ベースのインタフェース識別子の生成 ------------------------------------------------- 特定のリンクやノードの特性により、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" 規約で定義される。 自動アルゴリズムの一部として、衝突検出アルゴリズムを実装することが 強く推奨される。 付録 B: テキスト表現の ABNF 記述 -------------------------------- この付録は、参照目的で拡張 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 付録 C: RFC-1884 からの変更点 ----------------------------- 以下の変更点は、RFC-1884 "IP バージョン 6 アドレス体系" からの変更 点である。 - テキスト表現の ABNF 記述を提供する付録を追加 - リンクユニーク識別子は、再起動や他のインタフェース再設定後に変 更されないことを明確化 - コメントに基づくアドレスモデルの明確化 - 集約形式用語を集約ドラフトと一貫させるための変更 - インタフェース識別子は同一ノードで一つ以上のインタフェースで使 用できるというテキスト追加 - 新しいマルチキャストアドレスの定義のための規則追加 - EUI-64 ベースのインタフェース ID を生成手続きを説明する付録追 加 - IPv6 プレフィクスを定義するための記法追加 - より長いプレフィクスを使用するための、要請ノードマルチキャスト アドレス定義の変更 - サイトスコープの全ルータマルチキャストアドレスの追加 - "001" 形式プレフィクスを使用するための集約可能グローバルユニ キャストアドレスの定義 - "010" (プロバイダベースのユニキャスト) と "100" (地理のために 予約) プレフィクス形式を未割当てに変更 ・ユニキャストアドレスのためのインタフェース ID 定義のセクション 追加。プレフィクス形式の範囲における EUI-64 の使用と、EUI-64 でグローバル/ローカルスコープビットの設定規則を必要とする。 ・RFC1888 の作業を反映して NSAP テキストを更新 ・プロトコル特定 IPv6 マルチキャストアドレス (例えば DHCP) とそ の IANA 定義への参照を削除 ・"ユニキャストアドレスの例" を削除。OBE を持つようになった。 ・新しい参照の追加と更新 ・テキストのマイナーな明確化と改善 参照 [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.