Internet Protocol、バージョン 6 (IPv6) は、現在の IPv4 から正常進化をしながら、飛躍的な進歩を図った Internet Protocol (IP) の新バージョンです。定義されている移行機構を利用して IPv6 を導入しても今までの操作方法が混乱することはありません。IPv6 ではアドレス空間が増え、シンプルになったヘッダーフォーマット、認証とプライバシのサポート、アドレス割り当ての自動設定を採用し、サービス品質を一新してインターネット機能を強化しました。
IP4 から IP6 への変更内容は、次のように大きく分類できます。
拡張されたルーティングとアドレス指定機能 - IPv6 では IP アドレスサイズを 32 ビットから 128 ビットに拡大して、サポートするアドレス指定階層を広げるとともに、アドレス可能なノード数を増やし、アドレスの自動設定を容易にしました。
スコープフィールドの追加により、マルチキャストアドレスに対するマルチキャストルーティングのスケーラビリティを強化しました。
任意キャストアドレスという新しいタイプのアドレスを定義しました。これはノードセットを識別して、任意キャストアドレスに送信されたパケットを指定ノードに配信する機能です。IPv6 ソースルートでは任意キャストアドレスを使用して、ノードでトラフィックフローのパスを制御できます。
ヘッダーフォーマットの簡略化 - IPv4 ヘッダーフィールドが一部削除されたり、オプションになったりしました。この変更によってアドレスのサイズは増えましたが、パケットの共通処理や IPv6 ヘッダーの帯域幅は、可能な限り少なくなりました。IPv6 アドレスの長さは、IPv4 アドレスの 4 倍ですが、IPv6 ヘッダーのサイズは IPv4 の 2 倍に抑えられています。
オプションサポートの強化 - IP ヘッダーオプションのコード化の方法を変更したため、転送効率が改善され、オプションの長さに関する制限が緩和されて、将来、新しいオプションを導入する際の柔軟性が高くなりました。
サービス品質の機能 - 新しい機能が追加されて、送信側が特別な処理を必要とする特定のトラフィックフローに適したパケットのラベル指定が可能になりました。デフォルト以外の品質サービスやリアルタイムサービスなどです。
認証機能と機密機能 - IPv6 には認証、データの完全性、機密性をサポートする拡張機能の定義が組み込まれています。
IPv6 プロトコルは、基本 IPv6 ヘッダー、IPv6 拡張ヘッダーを含むヘッダーセットを定義します。
図 14-1 は、IPv6 ヘッダーに使用される要素とその順序を示します。
次に各ヘッダーフィールドの機能について説明します。
バージョン - 4 ビットインターネットプロトコルバージョン番号 = 6
トラフィッククラス - 8 ビットトラフィッククラスの値 (「トラフィッククラス」を参照)
フローラベル - 24 ビットフィールド (「IPv6 サービス品質 (QoS) 機能」を参照)
ペイロードの長さ - オクテットによる 16 ビット符号なし整数。IPv6 ヘッダーに続くパケットの残り
次のヘッダー - 8 ビットセレクタ。IPv6 ヘッダーのすぐ後ろのヘッダータイプを識別する。IPv4 プロトコルフィールドと同じ値を使用する (「拡張ヘッダー」を参照)
ホップ制限 - 8 ビット符号なし整数。パケットを送信するノードごとに値が 1 ずつ減る。ホップ制限がゼロになるとパケットが廃棄される
ソースアドレス - 128 ビット。パケットの初期送信側のアドレス (「IPv6 アドレス指定」を参照)
宛先アドレス - 128 ビット。パケットの予定受信側のアドレス (オプションのルーティングヘッダー (経路を発信元が指定するヘッダー) がある場合、必ずしも受信側とは限らない)
IPv6 には、IPv4 から強化されたオプション機能があります。IPv6 オプションは、IPv6 ヘッダーとトランスポート層の間の独立した拡張ヘッダーにあります。パケットのデリバリパスでは、どのルーターも、最終的な宛先に到着するまでほとんどの IPv6 拡張ヘッダーの確認や処理は行いません。そのため、オプションがあるパケットのルーター性能が大幅に改善されました。
IPv4 では、オプションがある場合、ルーターですべてのオプションを調べる必要がありました。IPv4 オプションと異なるその他の改良点として、IPv6 拡張ヘッダーは長さを任意に設定でき、またパケットに組み込むことのできるオプションの合計数が 40 バイト以内に限定されない点があります。この機能とその処理方法によって、IPv4 では非現実的であった機能を IPv6 オプションが使用できるようになりました。その良い例が IPv6 認証オプションとセキュリティカプセル化オプションです。
後続のオプションヘッダー (およびそのあとのトランスポートプロトコル) を処理する際の性能を強化するため、IPv6 オプションは常に 8 オクテットの整数の倍数の長さで、後続のヘッダーの配列が維持されています。
次の IPv6 拡張ヘッダーが現在、定義されています。
ルーティング - 拡張ルーティング (IPv4 ルーズソースルートにあたる)
断片化 - 断片化および再結合
認証 - 整合性および認証: セキュリティ
カプセル化 - 機密性
ホップバイホップオプション - 飛び飛びの処理が必要な特別なオプション
宛先オプション - 宛先ノードが判断するオプション情報
IPv6 アドレスは 128 ビット長の識別子であり、個々のインタフェースや、インタフェースセットを識別します。すべてのタイプの IPv6 アドレスは、インタフェースに割り当てられ、ノード (ホストやルーター) には割り当てられません。各インタフェースの所属先は 1 つのノードだけなので、ノードのインタフェースのユニキャストアドレスは、そのノードの識別子として使用できます。1 つのインタフェースには、任意のタイプの複数の IPv6 アドレスを割り当てることができます。
IPv6 アドレスには、ユニキャスト、任意キャスト、マルチキャストの 3 種類のタイプがあります。
ユニキャストアドレスは、1 つのインタフェースを識別する
任意キャストアドレスは、インタフェースのセットを識別する。その場合、任意キャストアドレスに送信されるパケットはそのセットのメンバーの 1 つに配信される
マルチキャストアドレスはインタフェースグループを識別する。その場合、マルチキャストアドレスに送信されるパケットは、そのグループのすべてのインタフェースに配信される
IPv6 にはブロードキャストアドレスはない。マルチキャストアドレスが代わりをする
IPv6 は IPv4 アドレスの 4 倍のビット数のアドレス (128 対 32) をサポートします。これは、IPv4 のアドレス領域の 40 億 x 40 億倍の大きさに相当します。実際にはアドレスの割り当てとルーティングでは階層を作成する必要があり、アドレス領域の利用効率が低下するため、利用できるアドレス数は減ります。ただし現状では、IPv6 で提供するアドレス領域で十分です。
アドレスの先頭ビットでは IPv6 アドレスのタイプを指定します。この先頭ビットがある可変長フィールドをフォーマットプレフィックス (FP) といいます。表 14-1 は、これらのプレフィックス (接頭辞) の初期割り当てです。
表 14-1 フォーマットプレフィックスの割り当て
割り当て |
プレフィックス (バイナリ) |
アドレス領域の端数 |
---|---|---|
予約 |
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 |
割り当てでは、集約グローバルユニキャストアドレス、ローカル用アドレス、マルチキャストアドレスの直接割り当てがサポートされています。NSAP (ネットワークサービスポイント) アドレス、IPX (相互ネットワークパケット交換プロトコル) アドレス、ニュートラル相互接続アドレスには領域が予約されています。残りのアドレス領域は将来用に割り当てなしになっています。この残ったアドレス領域は、既存の領域の拡張部分 (集約グローバルユニキャストアドレスへの追加など) または、新しい用途 (独立したロケータや識別子) に利用できます。なお、任意キャストアドレスはユニキャストアドレス領域の範囲外に割り当てられるため、ここには示していません。
初期設定で、アドレス領域の約 15 パーセントが割り当てられます。残りの 85 パーセントは将来用に予約されています。
IPv6 ユニキャストアドレスの割り当て形式は、次のとおりです。
集約グローバルユニキャストアドレス
ニュートラル相互接続ユニキャストアドレス
NSAP アドレス
IPX 階層アドレス
サイトローカル用アドレス
リンクローカル用アドレス
IPv4 対応ホストアドレス
その他のアドレスタイプは、あとから定義できます。
集約グローバルユニキャストアドレスは、グローバル通信に使用するアドレスで、CIDR (クラスレス相互ドメインルーティング) における IPv4 アドレスに機能的に似ています。表 14-2 に、そのフォーマットをまとめます。
表 14-2 集約グローバルユニキャストアドレスのフォーマット
3 ビット |
13 ビット |
8 ビット |
24 ビット |
16 ビット |
64 ビット |
FP |
TLA ID |
RES |
NLA ID |
SLA ID |
Interface ID |
各記号は次の内容を示します。
FP |
フォーマットプレフィックス (001) |
TLA ID |
最上位集約識別子 |
RES |
将来用に予約 |
NLA ID |
次レベル集約識別子 |
SLA ID |
サイトレベル集約識別子 |
INTERFACE ID |
インタフェース識別子 |
最初の 48 ビットはパブリックトポロジを表します。次の 16 ビットは各サイトのトポロジを表します。
最初の 3 ビットは集約グローバルユニキャストアドレスとしてアドレスを識別します。次のフィールドである TLA ID はルーティング階層の最上位レベルです。その次の 8 ビットは将来用に予約されています。NLA ID フィールドは TLA ID を割り当てた組織用であり、アドレス指定階層の作成と、サイトの識別に使用します。
SLA ID フィールドは、組織で各ローカルアドレス指定階層の作成とサブネットを識別するときに使用します。IPv4 のサブネットと似ていますが、組織別に割り当てることのできるサブネット数がはるかに多いところが異なります。16 ビット SLA ID フィールドがサポートするサブネットの数は 65,535 です。Interface ID では、リンク上のインタフェースを識別します。Interface ID は、リンク上で一意であるものとします。さらに広い範囲で一意であってもかまいません。通常、インタフェース識別子は識別子のリンク層のアドレスと同じか、そこから派生した値です。
ローカル用アドレスは、ローカルルート範囲だけのユニキャストアドレス (サブネットまたは加入者ネットワーク内) であり、ローカルまたはグローバルな一意の範囲が適用されます。このアドレスは、サイト内において、グローバルアドレスまでのプラグアンドプレイローカル通信とブートストラップに使用します。
ローカル用アドレスには、リンクローカルとサイトローカルの 2 種類が定義されています。リンクローカル用は 1 つのリンク用であり、サイトローカル用は 1 つのサイト用です。表 14-3 は、リンクローカル用アドレスフォーマットを示したものです。
表 14-3 リンクローカル用アドレスフォーマット
10 ビット |
n ビット |
118-n ビット |
1111111010 |
0 |
Interface ID |
リンクローカル用アドレスは自動アドレス設定などの目的で 1 つのリンク上のアドレス指定に使用します。
表 14-4 は、サイトローカル用アドレスフォーマットです。
表 14-4 サイトローカル用アドレス
10 ビット |
n ビット |
m ビット |
118-(n+ m) ビット |
1111111011 |
0 |
Subnet ID |
Interface ID |
どちらのローカル用アドレスタイプも、インタフェース ID はそれを使用するドメインで一意であるものとします。通常、ノードの IEEE-802 48 ビットアドレスを使用します。Subnet ID は、サイト内の特定のサブネットを識別します。Subnet ID と Interface ID を組み合わせてローカルアドレスにすると、他のアドレス指定をしなくても大規模なプライベートインターネットを構築できます。
ローカル用アドレスでは、グローバルインターネットに接続していない組織でも、グローバルインターネットアドレス領域のアドレスプレフィックスを要求せずに操作ができます。組織からグローバルインターネットにあとから接続する場合、Subnet ID と Interface ID をグローバルプレフィックスと組み合わせれば (たとえば Registry ID + Provider ID + Subscriber ID)、グローバルアドレスを作成できます。インターネットに接続するときにプライベート (非グローバル) IPv4 アドレスを使用して番号をマニュアルで指定し直さなければならない IPv4 に比べ、大幅に強化された点です。IPv6 の場合、番号は自動的に指定し直されます。
IPv6 移行機能では、ホストとルーター向けに、IPv4 ルーティングインフラストラクチャのもとで IPv6 パケットを動的にトンネル処理できる方式を採用しています。この方式を利用した IPv6 ノードには、下位 32 ビットの IPv4 アドレスを保存した特別な IPv6 ユニキャストアドレスが割り当てられます。このタイプのアドレスを IPv4 互換 IPv6 アドレスといいます。そのフォーマットを表 14-5 に示します。
表 14-5 IPv4-互換 IPv6 アドレスフォーマット
80 ビット |
16 ビット |
32 ビット |
0000.......................................0000 |
0000 |
IPv4 アドレス |
組み込み IPv4 アドレスを保存する第 2 のタイプの IPv6 アドレスも定義されています。このアドレスは IPv6 アドレス領域内の IPv4 アドレスを表すときに使用します。このアドレスはアプリケーション、API、とオペレーティングシステムの実装内で主に使用します。このタイプのアドレスを IPv4 マップ IPv6 アドレスと呼びます。そのフォーマットを表 14-6 に示します。
表 14-6 IPv4-マップ IPv6 アドレスフォーマット
80 ビット |
16 ビット |
32 ビット |
0000..............................0000 |
FFFF |
IPv4 アドレス |
IPv6 任意キャストアドレスは複数のインタフェース (通常は異なるノードに所属) に割り当てるアドレスであり、任意キャストアドレスに送信されたパケットは、ルーティングプロトコルの測定距離に基づいて同じアドレスで最も近くにあるインタフェースにルーティングされます。
任意キャストアドレスをルートシーケンスの一部に使用すると、トラフィックを搬送するインターネットサービスプロバイダをノードで選択できます。この機能をソース選択ポリシーと呼ぶこともあります。この機能を実装するには、任意キャストアドレスを設定して、インターネットサービスプロバイダに所属するルーターセットを識別します (たとえばインターネットサービスプロバイダごとに 1 つの任意キャスト)。このような任意キャストを、IPv6 ルーティングヘッダーの中間アドレスに使用すれば、特定のプロバイダやプロバイダシーケンスでパケットを配信できます。また、任意キャストアドレスは特定のサブネットに関連づけられたルーターセットや、特定のルーティングドメインのエントリを提供するルーターセットの識別にも使用できます。
定義済みのユニキャストアドレスフォーマットを利用すれば、ユニキャストアドレス領域から任意キャストを指定できます。そのため、任意キャストアドレスは、構文的にはユニキャストアドレスと区別がつきません。複数のインタフェースにユニキャストアドレスを割り当てるとき、つまり任意キャストに変換する場合、任意キャストアドレスであることを表すため、アドレスを割り当てるノードを明示的に設定する必要があります。
IPv6 マルチキャストアドレスは、インタフェースグループの識別子です。1 つのインタフェースが所属できるマルチキャストグループは複数設定できます。表 14-7 は、マルチキャストアドレスフォーマットを示します。
表 14-7 マルチキャストアドレスフォーマット
8 ビット |
4 ビット |
4 ビット |
112 ビット |
11111111 |
FLGS |
SCOP |
Group ID |
アドレスの先頭の 11111111 は、アドレスがマルチキャストアドレスであることを表します。FLGS は、4 つのフラグ (0、0、0、T) のセットです。
上位 3 つのフラグは、予約されており、0 に初期化されます。
T=0 - 固定的に割り当てられた (既知の) マルチキャストアドレスを識別する。グローバルインターネット番号指定機関が割り当てる
T=1 - 非固定的に割り当てられた (一時的な) マルチキャストアドレスを識別する
SCOP は、4 ビットのマルチキャストスコープの値であり、マルチキャストグループの有効範囲を表します。表 14-8 は、SCOP の値です。
表 14-8 SCOP の値
0 |
予約済み |
8 |
組織ローカルスコープ |
1 |
ノードローカルスコープ |
9 |
(割り当てなし) |
2 |
リンクローカルスコープ |
A |
(割り当てなし) |
3 |
(割り当てなし) |
B |
(割り当てなし) |
4 |
(割り当てなし) |
C |
(割り当てなし) |
5 |
サイトローカルスコープ |
D |
(割り当てなし) |
6 |
(割り当てなし) |
E |
グローバルスコープ |
7 |
(割り当てなし) |
F |
予約済み |
グループ ID は、指定グループ内で、固定または一時的のどちらかのマルチキャストグループを識別します。
IPv6 におけるルーティングは、CIDR における IPv4 の場合のルーティングとほぼ同じですが、IPv4 の 32 ビットアドレスに対し、IPv6 では 128 ビットアドレスを使用します。非常に簡単な拡張で、IPv4 のルーティングアルゴリズム (OSPF、RIP、IDRP、IS-IS など) をすべて IPv6 のルーティングに使用できます。
IPv6 には、新たに強力なルーティング機能をサポートした簡単なルーティング拡張機能も組み込まれました。次にそれを示します。
プロバイダ選択 (ポリシー、性能、コストなどを基準に)
ホストの移動性 (現在の場所までのルート)
アドレスの自動的な再指定 (新しいアドレスへのルート)
新しいルーティング機能を利用するには、IPv6 ルーティングオプションで IPv6 アドレスのシーケンスを作成します。IPv6 ソースでは、ルーティングオプションで複数の中間ノード (またはトポロジカルグループ) をリストします。この中間ノードは、パケットの宛先の途中に通過します。この機能は、IPv4 のルーズソースとルートオプションによく似た機能です。
アドレスシーケンスを一般的に使用する場合、通常は、(パケットが IPv6 認証ヘッダーで正しく認証された場合) アドレスシーケンスを保存した受信パケットのルートを IPv6 ホストで逆戻りして発信者にパケットを戻す必要があります。IPv6 ホストの実装では、この方式によりソースルートの処理と逆引きをサポートしています。これが、プロバイダ選択や拡張アドレスなどの新機能を実装するホストで IPv6 ホストの実装を使用するためのポイントです。
IPv6 では、同じリンクに接続されたノード間の対話に関連した問題をまとめて解決しました。そのため、次のような問題を個々に解決する仕組みを定義しています。
ルーター発見 - 接続されたリンクにあるルーターをホストが探索する
プレフィックス探索 - どの宛先がリンクに接続されているかを定義するアドレスプレフィックスのセットをホストが探索する (オンリンクということもある)。(リンクにある宛先と、ルーターからだけアクセスできる宛先を、ノードではプレフィックスで区別します)
パラメータ探索 - リンク MTU (最大伝送単位) などのリンクパラメータ、またはホップ制限値などのインターネットパラメータをノードが調べて出力パケットを転送する
アドレス自動設定 - インタフェースのアドレスをノードが自動的に設定する
アドレス解決 - 宛先の IP アドレス以外不明な場合に、ノードが近傍のリンク層を判定する
次のホップの決定 - 宛先のトラフィックを送信する宛先になる近傍の IP アドレスに到る IP 宛先アドレスの対応付けがアルゴリズムで決まる。次のホップはルーターか宛先になる
近傍不到達検出 - 近傍にアクセスできないことをノードが判定する。ルーターに使用される近傍の場合、代替デフォルトルーターを試行できる。ルーターとホストの場合、アドレス解決を再試行できる
重複アドレス検出 - あるノードがアドレスを要求したところ、別のノードが使用している場合にそれを判定する
リダイレクト - 特定の宛先へのアクセス手段として、最適な最初のホップノードをルーターからホストに知らせる
近傍探索では、ルーター要請メッセージとルーター通知メッセージのペア、近傍要請メッセージと近傍通知メッセージのペア、リダイレクトメッセージという 5 種類の ICMP (インターネット制御メッセージプロトコル) パケットタイプを定義します。これらのメッセージの目的は、次のとおりです。
ルーター要請 - インタフェースが使用可能になると、ホストはルーターに対して、次回に予定されているタイミングではなく、今すぐルーター通知を生成するように求めるルーター要請を送信できる
ルーター通知 - 定期的に、あるいはルーター要請メッセージに応じて、ルーターはさまざまなリンクパラメータやインターネットパラメータとともにその存在を通知する。ルーター通知には、オンリンク判定またはアドレス設定、あるいはホップ制限値の選択肢などに使用するプレフィックスが含まれる
近傍要請 - 近傍のリンク層アドレスを判定するため、あるいは近傍がキャッシュリンク層アドレスでアクセスできるかどうかを確認するための情報としてノードから送信される。近傍要請は重複アドレス検出にも使用する
近傍通知 - 近傍要請メッセージに対する応答として、ノードでは未要請の近傍通知も送信してリンク層アドレスの変更を伝える
リダイレクト - 宛先までの最適な最初のホップ、または宛先がオンリンクであることをルーターからホストに知らせる
マルチキャスト対応リンクとポイントツーポイントリンクでは、ルーターは定期的にルーター通知パケットをマルチキャストして利用できることを知らせます。ホストはすべてのルーターからルーター通知を受け取り、デフォルトルーターのリストを作成します。利用できるルーターをホストが短時間 (2、3 分以内) に知ることができるように、ルーターは頻繁にルーター通知を生成します。ただし、通知がないからといってルーターエラーであると判断できるほどの頻度ではありません。エラー検出には、分離近傍不到達検出アルゴリズムを利用します。
ルーター通知には、オンリンク判定や自動アドレス設定に使用するプレフィックスリストが含まれます。プレフィックスに付属するフラグは特定のプレフィックスの使用目的を表します。ホストでは、パケット宛先がいつオンリンクになっているか、あるいはルーターを離れているかを知るために、通知されたオンリンクプレフィックスからリストを作成し管理します。通知されたオンリンクプレフィックスになくても宛先がオンリンクの場合があります。その場合、ルーターからリダイレクトを送信して宛先が近傍であることを送信者に知らせることができます。
ルーター通知 (およびプレフィックス別のフラグ) では、ルーターからホストにアドレスの自動設定の方法を伝えることができます。たとえば、ステートフル (DHCPv6) か自動 (ステートレス) のどちらのアドレス設定を使用するかなどがあります。
ルーター通知メッセージには、ホストが出力パケットの使用することを指定するホップ制限などのインターネットパラメータや、オプションでリンク MTU などのリンクパラメータも組み込むことができます。これにより、ルーターに設定されて関連付けられたすべてのホストに伝達される重要なパラメータを簡単に集中管理できます。
ノードでは、宛先ノードに対してそのリンク層アドレスを戻すよう要求する近傍要請をマルチキャストしてアドレス解決を行います。近傍要請メッセージは、宛先アドレスの要請先のノードマルチキャストアドレスにマルチキャストされます。宛先は、そのリンク層アドレスをユニキャスト近傍通知メッセージで戻します。発信元と宛先の両方に対して 1 つの要求応答パケットペアで互いのリンク層アドレスを処理できます。発信元は、近傍要請に発信元のリンク層アドレスを組み込みます。
近傍要請メッセージでは、複数のノードに同じユニキャストアドレスが割り当てられていないかを確認することもできます。
近傍不到達検出では、近傍エラーや近傍への送信パスのエラーを検出します。そのためには、近傍に送信されるパケットがその近傍に実際にアクセスして、その IP 層で正しく処理されたかどうかを確認する肯定確認が必要です。近傍不到達検出では、2 つのソースの確認を使用します。可能な場合、上位層のプロトコルでは、接続が送信を処理中である、すなわち先に送信されたデータは正しく配信されたという肯定確認を戻します (たとえば、最も新しい TCP 肯定を受信したなど)。肯定応答が得られない場合、ノードは次のホップからのアクセス確認として、近傍通知を要請するユニキャスト近傍要請メッセージを送信します。不要なネットワークトラフィックを避けるため、検証メッセージはノードがアクティブでパケットを送信中の近傍にだけ送信されます。
上記の一般的な問題以外に、近傍探索では次のような状況にも対応します。
リンク層アドレスの変更 - リンク層アドレスの変更を認識したノードは、小数の (非要請) 近傍通知パケットをすべてのノードにマルチキャストして、無効になったキャッシュリンク層アドレスを更新できる。非要請通知の送信は、性能強化が目的。近傍不到達検出アルゴリズムにより、すべてのノードが確実に新しいアドレスを探索できるが、遅延が多少伸びる
入力負荷調整 - インタフェースを複写したノードでは、同じリンク上の複数のネットワークインタフェース間の入力パケットの複写の負荷調整ができる。このようなノード間では、同じインタフェースに複数のリンク層アドレスが割り当てられる。たとえば、1 つのネットワークドライバで、複数のネットワークインタフェースカードを、複数のリンク層アドレスを持つ 1 つの論理インタフェースとして表現できる
ルーターではソースリンク層アドレスをルーター通知パケットから省略させ、これによって近傍では近傍要請メッセージでルーターのリンク層アドレスを確認することで負荷を調整する。近傍通知メッセージの戻りには、要請元によって異なるリンク層アドレスが組み込まれる
任意キャストアドレス - 任意キャストアドレスでは、等価サービスを提供するノードセットの 1 つを識別し、同じリンクの複数のノードは同じ任意キャストを認識するように設定できる。近傍探索では、ノードが同じ宛先に対する複数の近傍通知を受け取るようノードを設定して任意キャストを処理する。任意キャストアドレスの通知には、すべて取り消しできない通知としてのタグが設定される。これで複数の通知のどれを使用するかを判定する特定の規則が呼び出される
プロキシ通知 - 近傍要請に応答できない宛先アドレスのかわりにパケットを受信するルーターは、取り消し無効の近傍通知を発行できる。現在は、プロキシの使用方法は指定されていないが、オフリンクになった移動ノードをプロキシ通知で処理できる可能性がある。ただし、たとえばこのプロトコルを実装していないノードを処理するといった一般的な機能ではない
IPv6 近傍探索プロトコルは、IPv4 プロトコル ARP (アドレス解決プロトコル)、ICMP ルーター発見、ICMP リダイレクトを組み合わせたようなものです。ホスト条件ではデッドゲートウェイ検出 (近傍不到達検出の課題) に対応できる可能性のあるアルゴリズムがいくつか指定されていますが、IPv4 には近傍不到達検出に全般的に対応できるプロトコルや機構はありませんでした。
近傍探索プロトコルでは、IPv4 プロトコルセットに対するさまざまな強化措置が施されています。
ルーター発見はベースプロトコルセットの一部であり、ホストがルーティングプロトコルをスヌープする必要はない
ルーター通知ではリンク層アドレスが伝達される。ルーターのリンク層アドレスの解決に、これ以外のパケット交換は不要
ルーター通知ではリンクのプレフィックスが伝達される。ネットマスクを設定する独立した機構は不要
ルーター通知では、アドレス自動設定が使用可能になる
ルーターでは、MTU が定義されていないすべてのノードで同じ MTU 値を使用するように、ホストがリンクで使用する MTU を通知する
アドレス解決マルチキャストは、40 億 (2^32) マルチキャストアドレスに展開され、宛先以外のノードに対するアドレス解決関係の割り込みを大幅に削減した。さらに、IPv6 以外のマシンの割り込みをなくした
リダイレクトには、新しい最初のホップのリンク層アドレスを保存する。独立したアドレス解決がなくてもリダイレクトを受信できる
同じリンクに複数のプレフィックスを関連付けられる。デフォルトで、ホストはルーター通知からすべてのオンリンクプレフィックスを受け取る。ただし、ルーター通知にあるプレフィックスをすべて、あるいは一部省略するようにルーターを設定できる。その場合、ホストは宛先がオフリンクであるとみなし、ルーターにトラフィックを送信する。ルーターは適宜リダイレクトを発行する
IPv4 と異なり、IPv6 リダイレクトの受信者は新しい次のホップがオンリンクであるとみなす。IPv4 では、ホストはリダイレクトを無視し、リンクのネットワークマスクに基づいて、リンクにない次のホップを指定する。IPv6 リダイレクト機構は XRedirect 機能に似ている。ノードがオンリンク宛先のすべてのプレフィックスを知ることが望ましくない場合、あるいは不可能な場合は、非ブロードキャストと共有媒体リンクで有効
近傍不到達検出は、障害ルーター、部分的に障害があるリンクやパーティション化されたリンク、リンク層アドレスが変更されたノードがあるときの、パケットの頑強性を大幅に強化した主要機能のひとつ。たとえば、移動ノードは、頻繁に更新される ARP キャッシュのおかげでオフリンクになっても接続が切れない
ARP と異なり、近傍探索では、ハーフリンクエラー (近傍不到達検出を利用) を検出し、双方向接続がない近傍にトラフィックが送信されるのを防ぐ
IPv4 ルーターと異なり、ルーター通知メッセージにはユーザー定義フィールドはない。安定性の異なるルーターの操作にユーザー定義フィールドは不要。近傍不到達検出で、デッドルーターを検出し、アクティブルーターに切り替えることができる
リンクローカルアドレスで (ルーター通知とリダイレクトメッセージ用に) ルーターを一意に識別しておけば、サイトの番号付けの変更で新しいグローバルプレフィックスが使用されても、ホストでルーター関連付けを維持できる
近傍探索メッセージのホップ制限は受信時に 255 なので、プロトコルがオフリンクノードによるスプーフエラーの被害を受けることがない。これに対し、IPv4 オフリンクノードでは ICMP (インターネット制御メッセージプロトコル) リダイレクトとルーター通知メッセージの両方を送信できる
ICMP 層にアドレス解決を配置すると、プロトコルが ARP よりも媒体に依存しなくなり、標準 IP 認証とセキュリティ機構を必要に応じて使用できるようになる
ホストでは、IPv6 のインタフェースの自動設定を数ステップかけて決定します。自動設定プロセスでは、リンクローカルアドレスの作成、リンク上の一意性の検査、どのような情報を自動設定するか (アドレス、その他情報、または両方)、そしてアドレスの場合、ステートレス機構で取得するか、ステートフル機能で取得するか、あるいはその両方で取得するかの決定が行われます。ここでは、リンクローカルアドレスの生成手順、ステートレスアドレス自動設定によるサイトローカルアドレスとグローバルアドレスの生成手順、そして重複アドレス検出手順について説明します。
IPv6 では、ステートフルとステートレスのアドレス自動設定機構を定義しています。ステートレス自動設定では、手動によるホストの設定は不要です。ルーターは最小限の設定 (あれば) ですみ、サーバーの追加も不要です。ステートレス機構では、ローカルに取得できる情報とルーターが通知する情報を利用してホストがそれぞれのアドレスを生成できます。ルーターはリンクに関連付けられたサブネットを識別するプレフィックスを通知します。ホストはサブネット上で一意にインタフェースを識別するインタフェース識別子を生成します。アドレスはこの 2 つを組み合わせて作ります。ルーターがない場合、ホストはリンクローカルアドレスだけを生成します。ただし、同じリンクに接続されたノード間の通信では、リンクローカルアドレスで十分です。
ステートフル自動設定モデルでは、ホストはインタフェースアドレスや設定情報とパラメータをサーバーから取り込みます。サーバーでは、どのホストにどのアドレスが割り当てられたかを保存したデータベースを管理します。ホストは、ステートフル自動設定プロトコルを利用してアドレスや設定情報、またはその両方をサーバーから取り込むことができます。ステートレス自動設定とステートフル自動設定は互いに補完し合います。たとえば、ホストでは、ステートレス自動設定でアドレスを設定し、ステートレス自動設定でその他の情報を取り込みます。
ホストが使用するアドレスが一意で正しくルートできればアドレスを厳密に知る必要はない場合に、ステートレス方式を使用します。正確なアドレス管理に対してサイトで厳しく管理する必要がある場合に、ステートフル方式を使用します。ステートフルとステートレスのどちらのアドレス自動設定も同時に使用できます。サイト管理者は、ルーター通知メッセージのフィールドの設定を通じて、どの方式の自動設定を使用するかを指定します。
IPv6 アドレスは、一定の時間 (場合によっては無限に) インタフェースにリースされます。各アドレスには、アドレスがどれだけの時間、インタフェースに結合されるかを示す寿命があります。寿命が尽きると、結合 (とアドレス) が無効になり、そのアドレスを別のインタフェースに割り当てることができます。アドレス結合の終了を効率的に行うため、アドレスはインタフェースに割り当てられた状態で 2 つの別々のフェーズを経ます。最初、アドレスには優先権が与えられ、任意に通信ができます。次に、アドレスの現在のインタフェース結合が無効になるという前提から、優先順位が下がります。優先順位が低い状態で、アドレスを使用するのは避けるべきですが、使用できないわけではありません。新しい通信 (たとえば、新しい TCP 接続の開始など) ではできるだけ優先順位の高いアドレスを使用します。優先順位の低いアドレスは、そのアドレスを使用中のアプリケーションにおいて、サービスを打ち切らないと別のアドレスに切り替えるのが困難なアプリケーションだけに使用します。
所定のリンクにおける設定済みアドレスをすべて一意にするため、インタフェースにアドレスを割り当てる前に、ノードは重複アドレス検出アルゴリズムを実行します。ステートレスとステートフルのどちらの自動設定で得られたアドレスにも重複アドレス検出アルゴリズムは実行されます。
このマニュアルで指定する自動設定プロセスは、ホストにだけ適用し、ルーターには適用しません。ホストの自動設定では、ルーターが通知した情報を使用するため、ルーターは別の手段で設定する必要があります。ただし、このマニュアルで説明した機能により、ルーターによってリンクローカルアドレスが生成される場合があります。また、インタフェースに割り当てられる前のすべてのアドレスにおいて、ルーターによる重複アドレス検出手順が済んでいる場合もあります。
ここでは、インタフェース自身の自動設定の概要について説明します。自動設定が行われるのはマルチキャスト対応リンクだけです。たとえばシステム起動時など、マルチキャスト対応インタフェースが使用可能な状態で開始します。ノード (ホストとルーターの両方) では、そのインタフェースのリンクローカルアドレスを生成して自動設定プロセスを開始します。リンクローカルアドレスは、インタフェースの識別子を既知のリンクローカルプレフィックスに追加して作成します。
ただし、リンクローカルアドレスをインタフェースに割り当てて使用する場合、この仮アドレスが別のノードやリンクで使用されていないことを確認する必要があります。特に、宛先が仮アドレスになっている近傍要請メッセージを送信するときは注意してください。別のノードが目的のアドレスを使用済みの場合、近傍要請でその旨を伝える内容が戻ります。近傍要請送信や再送の数と、連続した要請間の遅延はリンクによって異なり、システム管理で設定できます。
ノードにおいて、仮リンクローカルアドレスが一意でないことがわかると自動設定が打ち切られるため、手動でインタフェースを設定する必要があります。管理者が代替インタフェース識別子を提供してデフォルト識別子を無効にします。新しい (一意と思われる) インタフェース識別子を利用して自動設定機構を実行すると、簡単にこの状態から復帰できます。そうでなければ、リンクローカルアドレスとその他のアドレスは手動で設定します。
ノードにおいて仮リンクローカルアドレスが一意であると判定されると、インタフェースに割り当てられます。このとき、ノードは近傍ノードと IP レベルで接続されます。自動設定手順の残りは、ホストだけで実行されます。
自動設定の次の手順では、ルーター通知を受信するか、ルーターが存在しないことを確認します。ルーターがあれば、ホストが実行すべき自動設定の種類を指定したルーター通知が送信されます。ルーターがない場合、ステートフル自動設定が呼び出されます。
ルーターはルーター通知を定期的に送信しますが、連続した送信と送信の間の遅延は、自動設定を実行するホスト側の待機時間より通常は長くなります。通知を迅速に受信するため、すべてのルーターマルチキャストグループに 1 つまたは複数のルーター要請を送信します。ルーター通知には 2 つのフラグがあり、どのようなステートフル自動設定 (あれば) を実行すべきかを表します。管理アドレス設定フラグは、アドレスの取得時にホストがステートフル自動設定を使用するかどうかを表します。もう 1 つのステートフル設定フラグは、その他の情報 (アドレスを除く) の取得時にホストがステートフル自動設定を使用するかどうかを表します。
ルーター通知にプレフィックス情報オプションがある場合、これらのオプションにはステートレスアドレス自動設定におけるサイトローカルアドレスとグローバルアドレスの生成に必要な情報を保存します。ルーター通知のステートレスアドレス自動設定フィールドとステートフルアドレス自動設定フィールドは別々に処理され、ホストではステートフルアドレス自動設定とステートレスアドレス自動設定を同時に使用できます。プレフィックス情報オプションフィールドの 1 つである自動アドレス設定フラグは、オプションがステートレス自動設定にも適用されるかどうかを表します。適用される場合、補助オプションフィールドにサブネットプレフィックスと寿命値が保存され、プレフィックスから作成されたアドレスがどれだけの時間優先権を持ち有効であるかを表します。
ルーターではルーター通知が定期的に生成されるので、ホストでは常に新しい通知を受信します。ホストは各通知に組み込まれた情報を上記の手順で処理し、前の通知で受け取った情報を追加し更新します。
安全性確保のため、すべてのアドレスについて、インタフェースに対する割り当て前に一意かどうかが確認されます。ただし、ステートレス自動設定で作成したアドレスの場合、アドレスの一意性は、主にインタフェース識別子から生成されるアドレスの段階で決まります。そのため、ノードにおいてリンクローカルアドレスの一意性が確認されると、同じインタフェース識別子から生成される他のアドレスの個別の確認が不要になります。ただし、マニュアルやステートフルアドレス自動設定で得られたアドレスの場合は、個別に一意であることを確認する必要があります。重複アドレス検出を実行するのに手間がかかりすぎて意味がなくなるサイトの場合は、インタフェース別設定フラグの管理設定で重複アドレス検出の使用を無効にできます。
自動設定処理を短時間で終了するには、ルーター通知の待機とリンクローカルアドレスをホストで生成を並列に実行します (さらに一意性を確認)。これはルーターにおけるルーター要請に対する応答が遅れる場合があり、上記 2 つの手順を 1 つずつ実行すると、自動設定全体の時間が大幅に延長される場合があります。
ルーティングは、パケットの宛先 IP アドレスのサブネットプレフィックスで行われるので、移動ノード、ホストまたはルーターが宛先のパケットは、そのホームリンク (ホーム IPv6 サブネットが存在するリンク) に関連付けられていないとノードにアクセスできません。ノードの移動に関係なく通信を継続するには、新しいリンクに移動するたびに、移動ノードの IP アドレスを変更する必要があります。ただし、移動ノードの位置を変更すると、移動ノードではトランスポート接続と上位層接続が失われます。以上のことから、将来、インターネットの発展に移動コンピュータが依存することを考えると、IPv6 モビリティサポートが大きな意味を持つことになります。
上記の問題に IPv6 モビリティサポートが対応します。IPv6 サポートでは、移動ノードがリンク間を移動しても移動ノードの IP アドレスは変更されません。そのため、移動ノードに対する IP アドレスの割り当ては、ホームリンクのホームサブネットプレフィックスの範囲内で行われます。これをノードのホームアドレスといいます。
これにより、移動ノードのホームアドレスにルートされたパケットは、移動ノードが現在インターネットのどこに関連付けられていても宛先にアクセスできます。移動ノードが新しいリンクに移動しても他のノード (固定または移動) との通信は途切れません。
ただし、ホームを離れた移動ノードとの透過ルーティングパケットの問題は IPv6 移動サポートで解決できますが、移動コンピュータや無線ネットワークの使用に伴うすべての問題が片づくわけではありません。特に次の問題には対処できません。
通常の無線ネットワークのようにアクセスできるときできないときがあるリンクの処理 (ただし、移動検出手順でいくつかの問題は処理できる)
移動ノードが接続しているリンクのアクセス制御
ホストでは IPv6 ヘッダーでフローラベルフィールドとトラフィッククラスフィールドを使用して、デフォルト以外のサービス品質やリアルタイムサービスなど、IPv6 ルーターによる特別処理を必要とするパケットを識別します。この機能により、ある程度一貫したスループット、遅延、ジッターが必要なアプリケーションをサポートできます。この種のアプリケーションには、マルチメディアアプリケーションまたはリアルタイムアプリケーションがあります。
IPv6 ヘッダーで 24 ビットフローラベルフィールドをソースに使用して、デフォルト以外のサービス品質やリアルタイムサービスなど、IPv6 ルーターによる特別処理を必要とするパケットにラベルを設定できます。この IPv6 の機能はまだ実験段階であり、インターネットのフローサポートの条件が確定すると変更される可能性があります。フローラベルフィールドの機能をサポートしていないホストやルーターでは、パケットの生成時にフィールドをゼロに設定し、パケットの送信時にフィールドの値を前送りし、パケットの受信時にフィールドを無視する必要があります。
フローは特定のソースから、ソースがルーターの逆引きによる特別処理を必要とする特定の (ユニキャストまたはマルチキャスト) 宛先に送信されるパケットシーケンスです。特別な処理の特性は、リソース予約プロトコルなどの制御プロトコル、あるいはホップバイホップオプションなど、フローのパケットそのものに保存された情報によってルーターに伝達されます。
ソースから宛先までのアクティブフローは複数のフローであることもあれば、どのフローにも関連付けられていないトラフィックを含む場合もあります。フローの一意の識別はソースアドレスとゼロ以外のフローラベルの組み合わせによって行います。フローに所属しないパケットは、フローラベルゼロを運びます。
フローのソースノードでは、フローにフローラベルを割り当てます。新しいフローラベルは (疑似的な) ランダム選択で 1 から FFFFFF 16 進数の範囲から均等に選択します。このランダム割り当てにより、フローラベルフィールド内のビットセットは、フローの状態をルーターが調べるときのハッシュキーとして利用できるようになります。
同じフローに所属するパケットは、同じソースアドレス、同じ宛先アドレス、同じゼロ以外のフローラベルで送信します。これらのパケットのどれかにホップバイホップオプションヘッダーがあると、同じホップバイホップオプションヘッダーの内容で生成されます (ホップバイホップオプションヘッダーの次のヘッダーフィールドを除く)。これらのパケットのどれかにルーティングヘッダーがあると、ルーティングヘッダーまでは、すべての拡張ヘッダーが同じ内容で生成されます (ルーティングヘッダーの次のヘッダーフィールドを除く)。ルーターや宛先では、場合によってはこれらの条件が満たされているかを確認できます。条件違反がある場合、フローラベルフィールドの上位オクテットを表す ICMP パラメータ問題メッセージ、コード 0 でソースに報告します (すなわち、IPv6 パケットのオフセット 1)。
制御プロトコル、ホップバイホップオプション、その他の手段で明示的なフロー情報が与えられていなくても、ルーターでは、場合によっては、任意のフローのフロー処理状態をセットアップできます。たとえば、未知のゼロ以外のフローラベルで特定のソースからパケットを受信すると、フローラベルがゼロである場合と同様に、ルーターではその IPv6 ヘッダーと必要な拡張ヘッダーを処理できます。この処理には、次のホップインタフェースの判定と、場合によってはホップバイホップオプションの更新、ルートヘッダーのポインタとアドレスの加算、あるいはトラフィッククラスフィールドにもとづくパケットのキューイングの方法の決定など、その他の動作が含まれることがあります。ルーターでは、ソースアドレスとフローラベルをキャッシュキーとして、これらの処理手順の結果を記憶してその情報をキャッシュに保存できます。同じソースアドレスとフローラベルで後続のパケットについては、先のパラグラフの条件によれば、フローの最初のパケット以後、どのフィールドも変更されていないと考えられるため、調べなくてもキャッシュ情報を参照するだけで処理できます。
最初のノードや転送先のルーターは、IPv6 ヘッダーの 8 ビットトラフィッククラスフィールドを使用して、IPv6 パケットの異なるクラスまたは優先順位の特定と識別を行なうことができます。
トラフィッククラスフィールドには、以下の一般的な条件が適用されます。
1 つのノード内の IPv6 サービスへのサービスインタフェースは、上位プロトコルに対して、トラフィッククラスのビットの値を、上位プロトコルで生成されたパケットで供給する手段を提供する必要があります。すべての 8 ビットについて、デフォルトの値は必ず 0 になるようにします。
一部またはすべてのトラフィッククラスビットの固有の使用方法をサポートするノードは、それぞれの方法に従って生成、転送、または受信するパケット内のビットの値を変更することができます。ノードはトラフィッククラスフィールド内の、固有の使用方法をサポートしないすべてのビットを無視し、変更しないようにしなければなりません。
現在のインターネットには多くのセキュリティ問題があり、アプリケーション層の下層には有効な機密機構や認証機構がありません。この欠点に対し、IPv6 では、セキュリティサービスを提供する 2 つの統合オプションを設けて対応しています。この 2 つのオプションは、別々に、あるいはまとめて使用してさまざまなユーザーにさまざまなセキュリティレベルを提供できます。ユーザー通信が異なれば、セキュリティのニーズも異なります。
最初のオプションと、IPv6 認証ヘッダーという拡張ヘッダーは、IPv6 データグラムに機密機構なしの認証と一貫性を提供します。拡張機能はアルゴリズムに依存せず、さまざまな認証方式をサポートしますが、ワールドワイドインターネットで相互運用性を確保するにはキー付き MD5 を使用する必要があります。これでホストマスカレード侵害など、主なネットワーク侵害が避けられます。IPv6 でソースルーティングを使用する場合、IP ソースルーティングに明らかな危険性があるので IPv6 認証ヘッダーが重要になります。インターネット層に配置することで、現在は充分に保護されていない上位層プロトコルとサービスでホスト送信認証が可能になります。
2 番めのオプションである、IPv6 カプセル化セキュリティヘッダーと呼ばれる拡張ヘッダーは、IPv6 データグラムに一貫性と機密性を与えます。同種のセキュリティプロトコル (SP3D、ISO NLSP) に比べて単純ですが、柔軟性があり、アルゴリズムに依存しません。グローバルネットワークで相互運用性を活かすため、DES CBC は、IPv6 カプセル化セキュリティヘッダーの標準アルゴリズムとして使用されています。
IPv6 認証ヘッダーと IPv6 カプセル化セキュリティヘッダーは、新しいインターネットプロトコルセキュリティ (IPsec) の機能です。IPsecII の概要については、第 18 章「IPsec の概要」を参照してください。IPsec の実装方法については、第 19 章「IPsec の実装」を参照してください。