IPv6 の管理

第 1 章 IPv6 (概要)

インターネットプロトコル バージョン 6 (IPv6 : Internet Protocol version 6) はインターネットプロトコル (IP) の新しいバージョンです。 IPv6 は、現在の IPv4 から飛躍的に進歩しています。IPv4 から IPv6 には無理なく移行することができます。規定されている移行メカニズムを使用することにより、現在の運用に混乱を生じることなく IPv6 ネットワークを展開できます。IPv6 ではアドレス領域が増加しています。また、シンプルになったヘッダーフォーマット、認証とプライバシのサポート、アドレス割り当ての自動設定を採用し、サービス品質を一新してインターネット機能を強化しました。

この章では、以下の内容について説明します。

IPv6 の機能

IPv4 から IPv6 への変更内容は、次のように分類できます。

IPv6 のヘッダーと拡張機能

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

ヘッダーフォーマット

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

図 1–1 IPv6 ヘッダーフォーマット

ダイアグラムは、ソースと宛先アドレスを含む 8 つのフィールドを構成する 128 ビットの IPv6 ヘッダーを示しています。

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

拡張ヘッダー

IPv6 には、IPv4 から強化されたオプション機能があります。IPv6 オプションは、IPv6 ヘッダーとトランスポート層の間の独立した拡張ヘッダーにあります。パケットが最終的な宛先に到着するまで、その配送パスに存在するルーターは、ほとんどの場合 IPv6 拡張ヘッダを確認または処理しません。そのため、オプションがあるパケットを処理するルーターの性能が大幅に改善されました。IPv4 では、オプションがある場合、ルーターですべてのオプションを調べる必要がありました。

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

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

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

IPv6 アドレス指定

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

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

IPv6 では、ブロードキャストアドレスの代わりにマルチキャストアドレスが使われます。

IPv4 が 32 ビットであるのに対し、IPv6 は 128 ビットと 4 倍のビット数のアドレスをサポートします。したがって、計算上はそのアドレス領域は IPv4 のアドレス領域の 40 億倍の大きさになります。実際にはアドレスの割り当てとルーティングでは階層を作成する必要があり、アドレス領域の利用効率が減少するため、結果として、利用できるアドレス数は減少します。ただし当面は、IPv6 で提供するアドレス領域で十分です。

アドレスの先頭ビットでは IPv6 アドレスのタイプを指定します。この先頭ビットがある可変長フィールドをフォーマットプレフィックス (FP) といいます。 次の表は、これらのプレフィックス (接頭辞) の初期割り当てです。

表 1–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 

6to4 ルーターアドレスに予約 

1000 0000 0000 10 

 

割り当てには、集約グローバルユニキャストアドレス、ローカル用アドレス、マルチキャストアドレスの直接割り当てがサポートされています。NSAP (ネットワークサービスアクセスポイント) アドレス、IPX (相互ネットワークパケット交換プロトコル) アドレス、ニュートラル相互接続アドレスには空間が予約されています。残りのアドレス領域は将来用に割り当てなしになっています。残りのアドレス領域は、既存の領域の拡張部分に利用できます。たとえば、集約グローバルユニキャストアドレスへの追加として使用されます。残りの領域は、新規用としても使用されます。たとえば、個別のロケータと個別の識別子として使用されます。なお、エニーキャストアドレスはユニキャストアドレス空間の範囲外に割り当てられるため、ここには示していません。

初期設定で、アドレス領域の約 15 パーセントが割り当てられます。残りの 85 パーセントは将来用に予約されています。

ユニキャストアドレス

IPv6 ユニキャストアドレスの割り当て形式は、次のとおりです。

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

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

集約グローバルユニキャストアドレスは、グローバル通信に使用するアドレスです。CIDR (クラスレス相互ドメインルーティング) における IPv4 アドレスに機能的に似ています。表 1–2 に、そのフォーマットをまとめます。

表 1–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 フィールドは、組織で各ローカルアドレス指定階層の作成とサブネットを識別するときに使用します。SLA ID フィールドの使い方は IPv4 のサブネットと似ていますが、組織別に割り当てることのできるサブネット数がはるかに多いところが異なります。16 ビット SLA ID フィールドがサポートするサブネットの数は 65,535 です。Interface ID は、リンク上のインタフェースを識別するために使用します。Interface ID はそのリンク上で一意である必要があります。また、より広い範囲で一意とすることができます。通常、インタフェース識別子はインタフェースのリンクのアドレスと同じです。または、インタフェースのリンク層のアドレスに基づいた値です。

ローカル用アドレス

ローカル用アドレスは、ローカルにルーティング可能な範囲のみを対象とするユニキャストアドレスです。使用できるのは、サブネット内または加入者ネットワーク内に限定されます。ローカル用アドレスは、プラグアンドプレイのローカル通信を行うために、サイト内で使用します。また、グローバルアドレスを使用するためのブートストラップ操作を行うために使用されます。

ローカル用のユニキャストアドレスには、リンクローカルとサイトローカルの 2 種類があります。リンクローカル使用アドレスは、Ethernet や フレームリレーリンクのような単一のデータリンク層方式で使用します。サイトローカル用は単一サイトで使用します。次の表は、リンクローカル用アドレスフォーマットを示したものです。

表 1–3 リンクローカル用アドレスフォーマット

10 ビット 

54 ビット 

64 ビット 

1111111010 

Interface ID 

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

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

表 1–4 サイトローカル用アドレス

10 ビット 

38 ビット 

16 ビット 

64 ビット 

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 では、プライベート (非グローバル) な IPv4 アドレスを使うサイトは、インターネットに接続する場合に手動で番号を指定し直す必要があります。IPv6 の場合、番号は自動的に指定し直されます。

組み込み IPv4 アドレスを伴った IPv6 アドレス

IPv6 移行機能では、ホストとルーターが IPv4 ルーティングインフラストラクチャのもとで IPv6 パケットを動的にトンネル処理できる方式を採用しています。この方式を利用した IPv6 ノードには、下位 32 ビットに IPv4 アドレスを保存した特別な IPv6 ユニキャストアドレスが割り当てられます。このタイプのアドレスを IPv4 互換 IPv6 アドレスといいます。 次の表にそのフォーマットを示します。

表 1–5 IPv4 互換 IPv6 アドレスフォーマット

80 ビット 

16 ビット 

32 ビット 

0000.......................................0000  

0000 

IPv4 アドレス 

組み込み IPv4 アドレスを保存する第 2 のタイプの IPv6 アドレスも定義されています。このアドレスは IPv6 アドレス領域内の IPv4 アドレスを表すときに使用します。このアドレスは主に、アプリケーション、API、オペレーティングシステムの実装内で使用します。このタイプのアドレスを IPv4 マップ IPv6 アドレスといいます。 次の表にそのフォーマットを示します。

表 1–6 IPv4 マップ IPv6 アドレスフォーマット

80 ビット 

16 ビット 

32 ビット 

0000..............................0000  

FFFF 

IPv4 アドレス 

エニーキャストアドレス

IPv6 エニーキャストアドレスは複数のインタフェースに割り当てるアドレスです。通常は、エニーキャストアドレスは異なるノードに所属しています。エニーキャストアドレスに送られたパケットは、そのアドレスを持つ最も近いインタフェースにルーティングされます。

エニーキャストアドレスはルートシーケンスの一部に使用できます。 したがって、ノードはトラフィックを搬送するインターネットサービスプロバイダを選択できます。この機能をソース選択ポリシーと呼ぶこともあります。この機能を実装するには、インターネットサービスプロバイダに所属するルーターセットを識別するようにエニーキャストアドレスを構成します。たとえば、インターネットサービスプロバイダごとに 1 つのエニーキャストを構成します。エニーキャストを、IPv6 ルーティングヘッダーで中間アドレスとして使用できます。これにより、特定のプロバイダによってパケットが配信されます。または、一連のプロバイダによって配信されます。また、エニーキャストアドレスは、特定のサブネットに接続されたルーターセットや、特定のルーティングドメインへのエントリを提供するルーターセットの識別にも使用できます。

定義済みのユニキャストアドレスフォーマットを利用すれば、ユニキャストアドレス領域からエニーキャストを指定できます。そのため、エニーキャストアドレスは、構文的にはユニキャストアドレスと区別がつきません。複数のインタフェースにユニキャストアドレスを割り当てる場合は、ユニキャストアドレスをエニーキャストアドレスに変換します。ただし、そのアドレスがエニーキャストアドレスであることがわかるように、アドレスを割り当てるノードを明示的に構成する必要があります。

マルチキャストアドレス

IPv6 マルチキャストアドレスは、インタフェースグループの識別子です。1 つのインタフェースが所属できるマルチキャストグループは複数設定できます。表 1–7 は、マルチキャストアドレスフォーマットを示します。

表 1–7 マルチキャストアドレスフォーマット

8 ビット 

4 ビット 

4 ビット 

112 ビット 

11111111 

FLGS 

SCOP 

グループ ID 

アドレスの先頭の 11111111 は、アドレスがマルチキャストアドレスであることを表します。FLGS は、4 つのフラグ (0、0、0、T) のセットです。

上位 3 つのフラグは、予約されていて、これらのフラグは 0 に初期設定される必要があります。

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

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

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

ルーター通知

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

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

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

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

ルーター通知メッセージ

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

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

近傍要請と不到達

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

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

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

IPv4 との比較

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

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

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

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

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

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

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

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

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

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

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

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

特定のリンク上ですべての設定済みアドレスが一意であることを保証するため、ノードは重複アドレスの検出アルゴリズムを実行します。この実行は、インタフェースにアドレスを割り当てる前に行われる必要があります。重複アドレスの検出アルゴリズムはすべてのアドレスを対象として実行されます。

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

自動設定プロセス

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

ノードは、この仮リンクローカルアドレスがリンク上の別のノードで使用されていないことを確認する必要があります。この確認が終わったら、リンクローカルアドレスをインタフェースに割り当てることができます。特に、ノードは宛先が仮アドレスになっている近傍要請メッセージを送信します。別のノードがそのアドレスを使用中の場合、そのノードはそのことを伝える内容を含む近傍要請を返信します。別のノードがそのアドレスを使用しようと試みている場合、そのノードもその宛先に近傍要請を送信します。近傍要請送信や再送の数と、連続した要請間の遅延 はリンクによって異なります。これらのパラメータは、システム管理で設定できます。

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

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

ルーター通知の受信

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

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

プレフィックス情報

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

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

アドレスの一意性

安全性確保のため、すべてのアドレスについて、インタフェースに対する割り当て前に一意かどうかが確認されます。ただし、ステートレス自動設定で作成したアドレスの場合は状況が異なります。アドレスの一意性は、インタフェース識別子から生成されるアドレスの一部で主に決まります。したがって、ノードにおいてリンクローカルアドレスの一意性が確認されると、他のアドレスの個別の確認は不要になります。これらのアドレスが、同じインタフェース識別子から生成されているためです。ただし、手動で得られるアドレスはすべて、個別に一意であることを確認する必要があります。ステートフルアドレスの自動設定で得られるアドレスについても同じです。一部のサイトでは、重複アドレスの検出を実行するためのオーバーヘッドが大きく、それを実行することで得られる利益が帳消しになる場合があります。そのようなサイトでは、インタフェース別設定フラグの設定で重複アドレスの検出の使用を無効にできます。

自動設定処理を短時間で終了するために、ルーター通知の待機とリンクローカルアドレスの生成 (およびその一意性の確認) をホストで並列して実行できます。ルーターでは、ルーター要請に対する応答が数秒遅れる可能性があります。そのため、上記 2 つの手順を 1 つずつ実行すると、自動設定を完了するために必要な合計時間が大幅に長くなる可能性があります。

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

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

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

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

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

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

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

フローラベル

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

フローとは

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

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

フローのソースノードでは、フローにフローラベルを割り当てます。新しいフローラベルは、擬似的な方法で、ランダムに選択します。16 進数で、1 から FFFFF の範囲から均等に選択します。ランダムに割り当てることにより、ルーターはフローラベルフィールド内の任意のビットセットをハッシュキーとして利用できます。ルーターは、ハッシュキーを使ってフローに関連付けられた状態を調べることができます。

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

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

ルーターは、任意のフローのフロー処理状態を自由にセットアップできます。この場合ルーターは、制御プロトコル、ホップバイホップオプション、その他の手段による、明示的なフロー確立情報を必要としません。たとえば、未知のゼロ以外に設定されたフローラベルを持つパケットを特定のソースから受信した場合、ルーターではその IPv6 ヘッダーを処理できます。ルーターは、フローラベルがゼロに設定されている拡張ヘッダーを処理する場合と同じ方法で、必要な拡張ヘッダーを処理できます。ルーターは、次中継点のインタフェースの判別を行います。場合によってはホップバイホップオプションの更新、ルーティングヘッダーのポインタとアドレスの加算、あるいはパケットのキューイングの方法の決定なども行います。パケットのキューイングの方法の決定は、パケットのトラフィッククラスフィールドに基づいて行われます。ルーターは、この処理手順の結果を記憶することを選択できます。そして、記憶した後でその情報をキャッシュに保存できます。始点アドレスとフローラベルがキャッシュキーとして使用されます。同じ始点アドレスとフローラベルを持つ後続のパケット については、キャッシュされた情報を参照することにより処理できます。これらのパケットの始点アドレスとフローラベルをすべて調べる必要はありません。ルーターは、フローの最初のパケットは確認しますが、その後はフィールドの内容は変更されないと仮定することができます。

トラフィッククラス

パケットを生成したノードは、IPv6 パケットの異なるクラスまたは優先順位を識別する必要があります。その場合、IPv6 ヘッダーのトラフィッククラスフィールドが使用されます。パケットを転送するルーターも同じ目的でトラフィッククラスフィールドを使用します。

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

IPv6 セキュリティの強化

現在のインターネットには多くのセキュリティ問題があります。インターネットでは、アプリケーション層より下の層には有効な機密機構や認証機構がありません。この欠点に対し、IPv6 では、セキュリティサービスを提供する 2 つの統合オプションを設けて対応しています。この 2 つのオプションは、別々に、あるいはまとめて使用してさまざまなユーザーにさまざまなセキュリティレベルを提供できます。ユーザー通信が異なれば、セキュリティのニーズも異なります。

最初のオプションは IPv6 認証ヘッダー (AH) と呼ばれる拡張ヘッダーです。この拡張ヘッダーは、IPv6 データグラムに機密性を持たない認証と完全性を提供します。この拡張機能はアルゴリズムに依存せず、さまざまな認証方式をサポートします。認証ヘッダーは、ワールドワイドなインターネット内の相互運用性の保証を支援するために、それを使用することが提案されています。認証ヘッダーを使用することにより、ホストなりすまし攻撃など、主なネットワーク侵害を回避できます。IPv6 でソースルーティングを使用する場合、IP ソースルーティングに明らかな危険性があるので IPv6 認証ヘッダーが重要になります。上位層プロトコルおよび上位層サービスには、現在有効な保護策はありません。しかし、インターネット層に認証ヘッダーを使用することで、ホスト発信元認証を提供できます。

2 番めのオプションである、IPv6 カプセル化セキュリティペイロード (ESP) と呼ばれる拡張ヘッダーは、IPv6 データグラムに完全性と機密性を提供します。いくつかの同じようなセキュリティプロトコル よりも単純ですが、ESP はフレキシブルなままで、独立したアルゴリズムです。同様のセキュリティプロトコルには、SP3D とISO NLSP が含まれます。

IPv6 認証ヘッダーと IPv6 カプセル化セキュリティヘッダーは、新しいインターネットプロトコルセキュリティ (IPsec) の機能です。IPsec の概要については、『Solaris のシステム管理 (IP サービス)』の「IPsec (概要)」を参照してください。IP sec の実装の方法については、『Solaris のシステム管理 (IP サービス)』の「IPsec 実装の作業マップ」を参照してください。

IPv4 ネットワーク経由の 6to4 トンネル

IPv4 から IPv6 へのスムーズな移行のため、Solaris オペレーティングシステムでは 6to4 移行機構をサポートしています。この機構は、IPv4 ネットワークを介し、独立した IPv6 サイトから独立した別の IPv6 サイトへパケットのトンネリングを可能にするものです。6to4 機構を使用することで管理者は、1 つのグローバル IPv4 アドレスを使用し、完全な 48 ビット IPv6 グローバルプレフィックスを生成できます。6to4 ルーティングの技術情報が必要な場合は、RFC 3056 の『Connection of IPv6 Domains via IPv4 Clouds』を参照してください。

ご使用の IPv6 サイトが以下のどちらか一方あるいは両方の条件にあう場合は、6to4 の実装を検討してください。

かつては、独立した IPv6 サイトは、ほかの IPv6 サイトと通信を行えませんでした。6to4 ルーティングを使用すると、独立したサイトから IPv4 ネットワーク経由でトンネルを介してパケットを転送できます。この場合に必要となる条件は、IPv4 ネットワークに接続するインタフェースに一意の (世界に 1 つしかない) IPv4 アドレスを持たせて境界ルーターを使用することだけです。

インタフェースがこの要件を満たす場合には、6to4 サポート用のルーターに複数のインタフェースを設定できます。6to4 サポートのためにホストを手動で設定する必要はありません。6to4 ルーターからプレフィックス通知を受け取ると、IPv6 ホストは 6to4 アドレスを使用して自動的に IPv6 インタフェースを再設定します。

ルーターは、出力用の IPv6 パケットを IPv4 ヘッダーを使用してカプセル化します。続いて、IPv4 ネットワーク経由で 6to4 ルーターと宛先の 6to4 サイト間で自動トンネルが構築されます。リモート側の 6to4 ルーターは、パケットを受けとった時点でそのカプセル化を解除し、標準の IPv6 形式となったこのパケットを適切な IPv6 ノードへ配布します。

6to4 ルーターは、6to4 サイトではないネイティブ IPv6 サイトにパケットをトンネリングすることもできます。この場合、6to4 ルーターは IPv4 ネットワークを介して 6to4 リレールーターとの間のトンネルを構築します。リレールーターは、パケットを IPv6 ネットワークに転送します。

6to4 ルーティングの詳細

6to4 ルーティングの設定はいたって容易です。次に、6to4 設定の作業と技術情報の参照先を示します。

作業または技術情報 

参照先 

6to4 ルーターの設定 

6to4 ルーターの設定方法

6to4 リレールーターの設定 

6to4 リレールーターとの間の 6to4 トンネルの設定方法

ifconfig に対する 6to4 変更

ifconfig ユーティリティに対する IPv6 拡張機能

6to4relay コマンドの詳細

6to4relay コマンド

6to4 サイトトポロジの詳細 

6to4 トンネルの構成

6to4 アドレス指定の詳細 

6to4 派生のアドレス指定

6to4 リレールーターの詳細 

6to4 リレールーターとの間のトンネルについての考慮事項