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