Solaris のシステム管理 (第 3 巻)

第 14 章 IPv6 の概要

Internet Protocol、バージョン 6 (IPv6) は、現在の IPv4 から正常進化をしながら、飛躍的な進歩を図った Internet Protocol (IP) の新バージョンです。定義されている移行機構を利用して IPv6 を導入しても今までの操作方法が混乱することはありません。IPv6 ではアドレス空間が増え、シンプルになったヘッダーフォーマット、認証とプライバシのサポート、アドレス割り当ての自動設定を採用し、サービス品質を一新してインターネット機能を強化しました。

IPv6 の機能

IP4 から IP6 への変更内容は、次のように大きく分類できます。

IPv6 のヘッダーと拡張機能

IPv6 プロトコルは、基本 IPv6 ヘッダー、IPv6 拡張ヘッダーを含むヘッダーセットを定義します。

ヘッダーフォーマット

図 14-1 は、IPv6 ヘッダーに使用される要素とその順序を示します。

図 14-1 IPv6 ヘッダーフォーマット

Graphic

次に各ヘッダーフィールドの機能について説明します。

拡張ヘッダー

IPv6 には、IPv4 から強化されたオプション機能があります。IPv6 オプションは、IPv6 ヘッダーとトランスポート層の間の独立した拡張ヘッダーにあります。パケットのデリバリパスでは、どのルーターも、最終的な宛先に到着するまでほとんどの IPv6 拡張ヘッダーの確認や処理は行いません。そのため、オプションがあるパケットのルーター性能が大幅に改善されました。

IPv4 では、オプションがある場合、ルーターですべてのオプションを調べる必要がありました。IPv4 オプションと異なるその他の改良点として、IPv6 拡張ヘッダーは長さを任意に設定でき、またパケットに組み込むことのできるオプションの合計数が 40 バイト以内に限定されない点があります。この機能とその処理方法によって、IPv4 では非現実的であった機能を IPv6 オプションが使用できるようになりました。その良い例が IPv6 認証オプションとセキュリティカプセル化オプションです。

後続のオプションヘッダー (およびそのあとのトランスポートプロトコル) を処理する際の性能を強化するため、IPv6 オプションは常に 8 オクテットの整数の倍数の長さで、後続のヘッダーの配列が維持されています。

次の IPv6 拡張ヘッダーが現在、定義されています。

IPv6 アドレス指定

IPv6 アドレスは 128 ビット長の識別子であり、個々のインタフェースや、インタフェースセットを識別します。すべてのタイプの IPv6 アドレスは、インタフェースに割り当てられ、ノード (ホストやルーター) には割り当てられません。各インタフェースの所属先は 1 つのノードだけなので、ノードのインタフェースのユニキャストアドレスは、そのノードの識別子として使用できます。1 つのインタフェースには、任意のタイプの複数の IPv6 アドレスを割り当てることができます。

IPv6 アドレスには、ユニキャスト、任意キャスト、マルチキャストの 3 種類のタイプがあります。

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 ユニキャストアドレスの割り当て形式は、次のとおりです。

その他のアドレスタイプは、あとから定義できます。

集約グローバルユニキャストアドレス

集約グローバルユニキャストアドレスは、グローバル通信に使用するアドレスで、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 

Interface ID 

リンクローカル用アドレスは自動アドレス設定などの目的で 1 つのリンク上のアドレス指定に使用します。

表 14-4 は、サイトローカル用アドレスフォーマットです。

表 14-4 サイトローカル用アドレス

10 ビット 

n ビット

m ビット

118-(n+ m) ビット

1111111011 

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 の場合、番号は自動的に指定し直されます。

組み込み 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 に初期化されます。

SCOP は、4 ビットのマルチキャストスコープの値であり、マルチキャストグループの有効範囲を表します。表 14-8 は、SCOP の値です。

表 14-8 SCOP の値

予約済み 

組織ローカルスコープ 

ノードローカルスコープ 

(割り当てなし) 

リンクローカルスコープ 

(割り当てなし) 

(割り当てなし) 

(割り当てなし) 

(割り当てなし) 

(割り当てなし) 

サイトローカルスコープ 

(割り当てなし) 

(割り当てなし) 

グローバルスコープ 

(割り当てなし) 

予約済み 

グループ ID は、指定グループ内で、固定または一時的のどちらかのマルチキャストグループを識別します。

IPv6 のルーティング

IPv6 におけるルーティングは、CIDR における IPv4 の場合のルーティングとほぼ同じですが、IPv4 の 32 ビットアドレスに対し、IPv6 では 128 ビットアドレスを使用します。非常に簡単な拡張で、IPv4 のルーティングアルゴリズム (OSPF、RIP、IDRP、IS-IS など) をすべて IPv6 のルーティングに使用できます。

IPv6 には、新たに強力なルーティング機能をサポートした簡単なルーティング拡張機能も組み込まれました。次にそれを示します。

新しいルーティング機能を利用するには、IPv6 ルーティングオプションで IPv6 アドレスのシーケンスを作成します。IPv6 ソースでは、ルーティングオプションで複数の中間ノード (またはトポロジカルグループ) をリストします。この中間ノードは、パケットの宛先の途中に通過します。この機能は、IPv4 のルーズソースとルートオプションによく似た機能です。

アドレスシーケンスを一般的に使用する場合、通常は、(パケットが IPv6 認証ヘッダーで正しく認証された場合) アドレスシーケンスを保存した受信パケットのルートを IPv6 ホストで逆戻りして発信者にパケットを戻す必要があります。IPv6 ホストの実装では、この方式によりソースルートの処理と逆引きをサポートしています。これが、プロバイダ選択や拡張アドレスなどの新機能を実装するホストで IPv6 ホストの実装を使用するためのポイントです。

IPv6 の近傍探索

IPv6 では、同じリンクに接続されたノード間の対話に関連した問題をまとめて解決しました。そのため、次のような問題を個々に解決する仕組みを定義しています。

近傍探索では、ルーター要請メッセージとルーター通知メッセージのペア、近傍要請メッセージと近傍通知メッセージのペア、リダイレクトメッセージという 5 種類の ICMP (インターネット制御メッセージプロトコル) パケットタイプを定義します。これらのメッセージの目的は、次のとおりです。

ルーター通知

マルチキャスト対応リンクとポイントツーポイントリンクでは、ルーターは定期的にルーター通知パケットをマルチキャストして利用できることを知らせます。ホストはすべてのルーターからルーター通知を受け取り、デフォルトルーターのリストを作成します。利用できるルーターをホストが短時間 (2、3 分以内) に知ることができるように、ルーターは頻繁にルーター通知を生成します。ただし、通知がないからといってルーターエラーであると判断できるほどの頻度ではありません。エラー検出には、分離近傍不到達検出アルゴリズムを利用します。

ルーター通知プレフィックス

ルーター通知には、オンリンク判定や自動アドレス設定に使用するプレフィックスリストが含まれます。プレフィックスに付属するフラグは特定のプレフィックスの使用目的を表します。ホストでは、パケット宛先がいつオンリンクになっているか、あるいはルーターを離れているかを知るために、通知されたオンリンクプレフィックスからリストを作成し管理します。通知されたオンリンクプレフィックスになくても宛先がオンリンクの場合があります。その場合、ルーターからリダイレクトを送信して宛先が近傍であることを送信者に知らせることができます。

ルーター通知 (およびプレフィックス別のフラグ) では、ルーターからホストにアドレスの自動設定の方法を伝えることができます。たとえば、ステートフル (DHCPv6) か自動 (ステートレス) のどちらのアドレス設定を使用するかなどがあります。

ルーター通知メッセージ

ルーター通知メッセージには、ホストが出力パケットの使用することを指定するホップ制限などのインターネットパラメータや、オプションでリンク MTU などのリンクパラメータも組み込むことができます。これにより、ルーターに設定されて関連付けられたすべてのホストに伝達される重要なパラメータを簡単に集中管理できます。

ノードでは、宛先ノードに対してそのリンク層アドレスを戻すよう要求する近傍要請をマルチキャストしてアドレス解決を行います。近傍要請メッセージは、宛先アドレスの要請先のノードマルチキャストアドレスにマルチキャストされます。宛先は、そのリンク層アドレスをユニキャスト近傍通知メッセージで戻します。発信元と宛先の両方に対して 1 つの要求応答パケットペアで互いのリンク層アドレスを処理できます。発信元は、近傍要請に発信元のリンク層アドレスを組み込みます。

近傍要請と不到達

近傍要請メッセージでは、複数のノードに同じユニキャストアドレスが割り当てられていないかを確認することもできます。

近傍不到達検出では、近傍エラーや近傍への送信パスのエラーを検出します。そのためには、近傍に送信されるパケットがその近傍に実際にアクセスして、その IP 層で正しく処理されたかどうかを確認する肯定確認が必要です。近傍不到達検出では、2 つのソースの確認を使用します。可能な場合、上位層のプロトコルでは、接続が送信を処理中である、すなわち先に送信されたデータは正しく配信されたという肯定確認を戻します (たとえば、最も新しい TCP 肯定を受信したなど)。肯定応答が得られない場合、ノードは次のホップからのアクセス確認として、近傍通知を要請するユニキャスト近傍要請メッセージを送信します。不要なネットワークトラフィックを避けるため、検証メッセージはノードがアクティブでパケットを送信中の近傍にだけ送信されます。

上記の一般的な問題以外に、近傍探索では次のような状況にも対応します。

IPv4 との比較

IPv6 近傍探索プロトコルは、IPv4 プロトコル ARP (アドレス解決プロトコル)、ICMP ルーター発見、ICMP リダイレクトを組み合わせたようなものです。ホスト条件ではデッドゲートウェイ検出 (近傍不到達検出の課題) に対応できる可能性のあるアルゴリズムがいくつか指定されていますが、IPv4 には近傍不到達検出に全般的に対応できるプロトコルや機構はありませんでした。

近傍探索プロトコルでは、IPv4 プロトコルセットに対するさまざまな強化措置が施されています。

IPv6 ステートレスアドレス自動設定

ホストでは、IPv6 のインタフェースの自動設定を数ステップかけて決定します。自動設定プロセスでは、リンクローカルアドレスの作成、リンク上の一意性の検査、どのような情報を自動設定するか (アドレス、その他情報、または両方)、そしてアドレスの場合、ステートレス機構で取得するか、ステートフル機能で取得するか、あるいはその両方で取得するかの決定が行われます。ここでは、リンクローカルアドレスの生成手順、ステートレスアドレス自動設定によるサイトローカルアドレスとグローバルアドレスの生成手順、そして重複アドレス検出手順について説明します。

ステートレス自動設定の条件

IPv6 では、ステートフルとステートレスのアドレス自動設定機構を定義しています。ステートレス自動設定では、手動によるホストの設定は不要です。ルーターは最小限の設定 (あれば) ですみ、サーバーの追加も不要です。ステートレス機構では、ローカルに取得できる情報とルーターが通知する情報を利用してホストがそれぞれのアドレスを生成できます。ルーターはリンクに関連付けられたサブネットを識別するプレフィックスを通知します。ホストはサブネット上で一意にインタフェースを識別するインタフェース識別子を生成します。アドレスはこの 2 つを組み合わせて作ります。ルーターがない場合、ホストはリンクローカルアドレスだけを生成します。ただし、同じリンクに接続されたノード間の通信では、リンクローカルアドレスで十分です。

ステートフル自動設定モデル

ステートフル自動設定モデルでは、ホストはインタフェースアドレスや設定情報とパラメータをサーバーから取り込みます。サーバーでは、どのホストにどのアドレスが割り当てられたかを保存したデータベースを管理します。ホストは、ステートフル自動設定プロトコルを利用してアドレスや設定情報、またはその両方をサーバーから取り込むことができます。ステートレス自動設定とステートフル自動設定は互いに補完し合います。たとえば、ホストでは、ステートレス自動設定でアドレスを設定し、ステートレス自動設定でその他の情報を取り込みます。

ステートレス方式とステートフル方式をいつ使用するか

ホストが使用するアドレスが一意で正しくルートできればアドレスを厳密に知る必要はない場合に、ステートレス方式を使用します。正確なアドレス管理に対してサイトで厳しく管理する必要がある場合に、ステートフル方式を使用します。ステートフルとステートレスのどちらのアドレス自動設定も同時に使用できます。サイト管理者は、ルーター通知メッセージのフィールドの設定を通じて、どの方式の自動設定を使用するかを指定します。

IPv6 アドレスは、一定の時間 (場合によっては無限に) インタフェースにリースされます。各アドレスには、アドレスがどれだけの時間、インタフェースに結合されるかを示す寿命があります。寿命が尽きると、結合 (とアドレス) が無効になり、そのアドレスを別のインタフェースに割り当てることができます。アドレス結合の終了を効率的に行うため、アドレスはインタフェースに割り当てられた状態で 2 つの別々のフェーズを経ます。最初、アドレスには優先権が与えられ、任意に通信ができます。次に、アドレスの現在のインタフェース結合が無効になるという前提から、優先順位が下がります。優先順位が低い状態で、アドレスを使用するのは避けるべきですが、使用できないわけではありません。新しい通信 (たとえば、新しい TCP 接続の開始など) ではできるだけ優先順位の高いアドレスを使用します。優先順位の低いアドレスは、そのアドレスを使用中のアプリケーションにおいて、サービスを打ち切らないと別のアドレスに切り替えるのが困難なアプリケーションだけに使用します。

重複アドレスの検出アルゴリズム

所定のリンクにおける設定済みアドレスをすべて一意にするため、インタフェースにアドレスを割り当てる前に、ノードは重複アドレス検出アルゴリズムを実行します。ステートレスとステートフルのどちらの自動設定で得られたアドレスにも重複アドレス検出アルゴリズムは実行されます。

このマニュアルで指定する自動設定プロセスは、ホストにだけ適用し、ルーターには適用しません。ホストの自動設定では、ルーターが通知した情報を使用するため、ルーターは別の手段で設定する必要があります。ただし、このマニュアルで説明した機能により、ルーターによってリンクローカルアドレスが生成される場合があります。また、インタフェースに割り当てられる前のすべてのアドレスにおいて、ルーターによる重複アドレス検出手順が済んでいる場合もあります。

IPv6 プロトコルの概要

ここでは、インタフェース自身の自動設定の概要について説明します。自動設定が行われるのはマルチキャスト対応リンクだけです。たとえばシステム起動時など、マルチキャスト対応インタフェースが使用可能な状態で開始します。ノード (ホストとルーターの両方) では、そのインタフェースのリンクローカルアドレスを生成して自動設定プロセスを開始します。リンクローカルアドレスは、インタフェースの識別子を既知のリンクローカルプレフィックスに追加して作成します。

ただし、リンクローカルアドレスをインタフェースに割り当てて使用する場合、この仮アドレスが別のノードやリンクで使用されていないことを確認する必要があります。特に、宛先が仮アドレスになっている近傍要請メッセージを送信するときは注意してください。別のノードが目的のアドレスを使用済みの場合、近傍要請でその旨を伝える内容が戻ります。近傍要請送信や再送の数と、連続した要請間の遅延はリンクによって異なり、システム管理で設定できます。

ノードにおいて、仮リンクローカルアドレスが一意でないことがわかると自動設定が打ち切られるため、手動でインタフェースを設定する必要があります。管理者が代替インタフェース識別子を提供してデフォルト識別子を無効にします。新しい (一意と思われる) インタフェース識別子を利用して自動設定機構を実行すると、簡単にこの状態から復帰できます。そうでなければ、リンクローカルアドレスとその他のアドレスは手動で設定します。

ノードにおいて仮リンクローカルアドレスが一意であると判定されると、インタフェースに割り当てられます。このとき、ノードは近傍ノードと IP レベルで接続されます。自動設定手順の残りは、ホストだけで実行されます。

ルーター通知の受信

自動設定の次の手順では、ルーター通知を受信するか、ルーターが存在しないことを確認します。ルーターがあれば、ホストが実行すべき自動設定の種類を指定したルーター通知が送信されます。ルーターがない場合、ステートフル自動設定が呼び出されます。

ルーターはルーター通知を定期的に送信しますが、連続した送信と送信の間の遅延は、自動設定を実行するホスト側の待機時間より通常は長くなります。通知を迅速に受信するため、すべてのルーターマルチキャストグループに 1 つまたは複数のルーター要請を送信します。ルーター通知には 2 つのフラグがあり、どのようなステートフル自動設定 (あれば) を実行すべきかを表します。管理アドレス設定フラグは、アドレスの取得時にホストがステートフル自動設定を使用するかどうかを表します。もう 1 つのステートフル設定フラグは、その他の情報 (アドレスを除く) の取得時にホストがステートフル自動設定を使用するかどうかを表します。

プレフィックス情報

ルーター通知にプレフィックス情報オプションがある場合、これらのオプションにはステートレスアドレス自動設定におけるサイトローカルアドレスとグローバルアドレスの生成に必要な情報を保存します。ルーター通知のステートレスアドレス自動設定フィールドとステートフルアドレス自動設定フィールドは別々に処理され、ホストではステートフルアドレス自動設定とステートレスアドレス自動設定を同時に使用できます。プレフィックス情報オプションフィールドの 1 つである自動アドレス設定フラグは、オプションがステートレス自動設定にも適用されるかどうかを表します。適用される場合、補助オプションフィールドにサブネットプレフィックスと寿命値が保存され、プレフィックスから作成されたアドレスがどれだけの時間優先権を持ち有効であるかを表します。

ルーターではルーター通知が定期的に生成されるので、ホストでは常に新しい通知を受信します。ホストは各通知に組み込まれた情報を上記の手順で処理し、前の通知で受け取った情報を追加し更新します。

アドレスの一意性

安全性確保のため、すべてのアドレスについて、インタフェースに対する割り当て前に一意かどうかが確認されます。ただし、ステートレス自動設定で作成したアドレスの場合、アドレスの一意性は、主にインタフェース識別子から生成されるアドレスの段階で決まります。そのため、ノードにおいてリンクローカルアドレスの一意性が確認されると、同じインタフェース識別子から生成される他のアドレスの個別の確認が不要になります。ただし、マニュアルやステートフルアドレス自動設定で得られたアドレスの場合は、個別に一意であることを確認する必要があります。重複アドレス検出を実行するのに手間がかかりすぎて意味がなくなるサイトの場合は、インタフェース別設定フラグの管理設定で重複アドレス検出の使用を無効にできます。

自動設定処理を短時間で終了するには、ルーター通知の待機とリンクローカルアドレスをホストで生成を並列に実行します (さらに一意性を確認)。これはルーターにおけるルーター要請に対する応答が遅れる場合があり、上記 2 つの手順を 1 つずつ実行すると、自動設定全体の時間が大幅に延長される場合があります。

IPv6 モビリティ (移動性) サポート

ルーティングは、パケットの宛先 IP アドレスのサブネットプレフィックスで行われるので、移動ノード、ホストまたはルーターが宛先のパケットは、そのホームリンク (ホーム IPv6 サブネットが存在するリンク) に関連付けられていないとノードにアクセスできません。ノードの移動に関係なく通信を継続するには、新しいリンクに移動するたびに、移動ノードの IP アドレスを変更する必要があります。ただし、移動ノードの位置を変更すると、移動ノードではトランスポート接続と上位層接続が失われます。以上のことから、将来、インターネットの発展に移動コンピュータが依存することを考えると、IPv6 モビリティサポートが大きな意味を持つことになります。

上記の問題に IPv6 モビリティサポートが対応します。IPv6 サポートでは、移動ノードがリンク間を移動しても移動ノードの IP アドレスは変更されません。そのため、移動ノードに対する IP アドレスの割り当ては、ホームリンクのホームサブネットプレフィックスの範囲内で行われます。これをノードのホームアドレスといいます。

これにより、移動ノードのホームアドレスにルートされたパケットは、移動ノードが現在インターネットのどこに関連付けられていても宛先にアクセスできます。移動ノードが新しいリンクに移動しても他のノード (固定または移動) との通信は途切れません。

ただし、ホームを離れた移動ノードとの透過ルーティングパケットの問題は IPv6 移動サポートで解決できますが、移動コンピュータや無線ネットワークの使用に伴うすべての問題が片づくわけではありません。特に次の問題には対処できません。

IPv6 サービス品質 (QoS) 機能

ホストでは IPv6 ヘッダーでフローラベルフィールドとトラフィッククラスフィールドを使用して、デフォルト以外のサービス品質やリアルタイムサービスなど、IPv6 ルーターによる特別処理を必要とするパケットを識別します。この機能により、ある程度一貫したスループット、遅延、ジッターが必要なアプリケーションをサポートできます。この種のアプリケーションには、マルチメディアアプリケーションまたはリアルタイムアプリケーションがあります。

フローラベル

IPv6 ヘッダーで 24 ビットフローラベルフィールドをソースに使用して、デフォルト以外のサービス品質やリアルタイムサービスなど、IPv6 ルーターによる特別処理を必要とするパケットにラベルを設定できます。この IPv6 の機能はまだ実験段階であり、インターネットのフローサポートの条件が確定すると変更される可能性があります。フローラベルフィールドの機能をサポートしていないホストやルーターでは、パケットの生成時にフィールドをゼロに設定し、パケットの送信時にフィールドの値を前送りし、パケットの受信時にフィールドを無視する必要があります。

フローとは

フローは特定のソースから、ソースがルーターの逆引きによる特別処理を必要とする特定の (ユニキャストまたはマルチキャスト) 宛先に送信されるパケットシーケンスです。特別な処理の特性は、リソース予約プロトコルなどの制御プロトコル、あるいはホップバイホップオプションなど、フローのパケットそのものに保存された情報によってルーターに伝達されます。

ソースから宛先までのアクティブフローは複数のフローであることもあれば、どのフローにも関連付けられていないトラフィックを含む場合もあります。フローの一意の識別はソースアドレスとゼロ以外のフローラベルの組み合わせによって行います。フローに所属しないパケットは、フローラベルゼロを運びます。

フローのソースノードでは、フローにフローラベルを割り当てます。新しいフローラベルは (疑似的な) ランダム選択で 1 から FFFFFF 16 進数の範囲から均等に選択します。このランダム割り当てにより、フローラベルフィールド内のビットセットは、フローの状態をルーターが調べるときのハッシュキーとして利用できるようになります。

同じフローに所属するパケット

同じフローに所属するパケットは、同じソースアドレス、同じ宛先アドレス、同じゼロ以外のフローラベルで送信します。これらのパケットのどれかにホップバイホップオプションヘッダーがあると、同じホップバイホップオプションヘッダーの内容で生成されます (ホップバイホップオプションヘッダーの次のヘッダーフィールドを除く)。これらのパケットのどれかにルーティングヘッダーがあると、ルーティングヘッダーまでは、すべての拡張ヘッダーが同じ内容で生成されます (ルーティングヘッダーの次のヘッダーフィールドを除く)。ルーターや宛先では、場合によってはこれらの条件が満たされているかを確認できます。条件違反がある場合、フローラベルフィールドの上位オクテットを表す ICMP パラメータ問題メッセージ、コード 0 でソースに報告します (すなわち、IPv6 パケットのオフセット 1)。

制御プロトコル、ホップバイホップオプション、その他の手段で明示的なフロー情報が与えられていなくても、ルーターでは、場合によっては、任意のフローのフロー処理状態をセットアップできます。たとえば、未知のゼロ以外のフローラベルで特定のソースからパケットを受信すると、フローラベルがゼロである場合と同様に、ルーターではその IPv6 ヘッダーと必要な拡張ヘッダーを処理できます。この処理には、次のホップインタフェースの判定と、場合によってはホップバイホップオプションの更新、ルートヘッダーのポインタとアドレスの加算、あるいはトラフィッククラスフィールドにもとづくパケットのキューイングの方法の決定など、その他の動作が含まれることがあります。ルーターでは、ソースアドレスとフローラベルをキャッシュキーとして、これらの処理手順の結果を記憶してその情報をキャッシュに保存できます。同じソースアドレスとフローラベルで後続のパケットについては、先のパラグラフの条件によれば、フローの最初のパケット以後、どのフィールドも変更されていないと考えられるため、調べなくてもキャッシュ情報を参照するだけで処理できます。

トラフィッククラス

最初のノードや転送先のルーターは、IPv6 ヘッダーの 8 ビットトラフィッククラスフィールドを使用して、IPv6 パケットの異なるクラスまたは優先順位の特定と識別を行なうことができます。

トラフィッククラスフィールドには、以下の一般的な条件が適用されます。

IPv6 セキュリティの強化

現在のインターネットには多くのセキュリティ問題があり、アプリケーション層の下層には有効な機密機構や認証機構がありません。この欠点に対し、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 の実装」を参照してください。