この章では、次の Oracle Solaris の IPv6 実装の参照情報について説明します。
IPv6 の概念については、第 3 章IPv6 の紹介(概要)を参照してください。IPv6 が有効なネットワークを設定する作業については、第 7 章IPv6 ネットワークの構成 (手順)を参照してください。
Solaris 10 7/07 では、/etc/inet/ipnodes ファイルは廃止されました。個々の手順で説明されているとおり、/etc/inet/ipnodes は以前の Oracle Solaris 10 リリースにのみ使用してください。
第 3 章IPv6 の紹介(概要)では、IPv6 アドレス指定のもっとも一般的な書式について紹介しました。 つまり、ユニキャストサイトアドレスとリンクローカルアドレスです。この節では、第 3 章IPv6 の紹介(概要)で説明しなかった IPv6 アドレス指定の詳細な書式について説明します。
ルーターまたはホストエンドポイントから 6to4 トンネルを設定する計画がある場合は、エンドポイントシステム上の /etc/inet/ndpd.conf ファイルにある 6to4 サイト接頭辞を通知する必要があります。6to4 トンネルの設定に関する概要と作業については、「6to4 トンネルを設定する方法」を参照してください。
次の図に、6to4 サイト接頭辞の構成を示します。
次の図は、ndpd.conf ファイルに指定する 6to4 サイトのサブネット接頭辞の構成を示しています。
この表では、6to4 サブネット接頭辞を構成する要素と、各要素の長さおよび定義について説明しています。
構成要素 |
長さ |
定義 |
---|---|---|
接頭辞 |
16 ビット |
6to4 接頭辞ラベル 2002 (0x2002)。 |
IPv4 アドレス |
32 ビット |
6to4 インタフェースですでに設定されている一意の IPv4 アドレス。通知のために、ドット付きの 10 進表記ではなく 16 進表記の IPv4 アドレスを指定します。 |
サブネット ID |
16 ビット |
サブネット ID。これは、6to4 サイトにおけるリンクで一意となる値でなければなりません。 |
ルーター広告によって 6to4 派生の接頭辞を受信する際、IPv6 ホストはインタフェース上の 6to4 派生アドレスを自動的に設定し直します。アドレスの書式は次のとおりです。
prefix:IPv4-address:subnet-ID:interface-ID/64 |
6to4 インタフェースを持つホスト上で ifconfig -a コマンドを実行すると、次のような出力が返されます。
qfe1:3: flags=2180841<UP,RUNNING,MULTICAST,ADDRCONF,ROUTER,IPv6> mtu 1500 index 7 inet6 2002:8192:56bb:9258:a00:20ff:fea9:4521/64 |
この出力では、inet6 に続く文字列が 6to4 派生アドレスです。
この表では、6to4 派生アドレスの構成要素、各要素の長さ、および各要素が提供する情報について説明しています。
アドレスの構成要素 |
長さ |
定義 |
---|---|---|
prefix |
16 ビット |
2002。これは 6to4 接頭辞です。 |
IPv4-address |
32 ビット |
8192:56bb。これは、6to4 ルーターで設定されている 6to4 擬似インタフェースに対する 16 進表記による IPv4 アドレスです。 |
subnet-ID |
16 ビット |
9258。これは、このホストの所属先であるサブネットのアドレスです。 |
interface-ID |
64 ビット |
a00:20ff:fea9:4521。これは、6to4 に設定されているホストインタフェースのインタフェース ID です。 |
IPv6 マルチキャストアドレスは、同じ情報またはサービスを「マルチキャストグループ」という定義済みのインタフェースのグループに分配する方法を提供します。 通常、マルチキャストグループのインタフェースは異なるノード上にあります。1 つのインタフェースが所属できるマルチキャストグループは複数設定できます。マルチキャストアドレスに送信されたパケットは、このマルチキャストグループのすべてのメンバーに送信されます。マルチキャストアドレスの使用法の例としては、情報のブロードキャストがあります。これは、IPv4 ブロードキャストアドレスに似た機能です。
次の表に、マルチキャストアドレスの書式を示します。
表 11–1 IPv6 マルチキャストアドレス書式
8 ビット |
4 ビット |
4 ビット |
8 ビット |
8 ビット |
64 ビット |
32 ビット |
11111111 |
FLGS |
SCOP |
Reserved |
Plen |
Network prefix |
Group ID |
次に、各フィールドの内容を要約します。
11111111 – アドレスをマルチキャストアドレスとして識別します。
FLGS – 4 つのフラグ「0,0,P,T」のセットです。最初の 2 つのフラグはゼロである必要があります。P フィールドは、次の値のうちの 1 つとなります。
0 = ネットワーク接頭辞に基づいて割り当てられていないマルチキャストアドレス
1 = ネットワーク接頭辞に基づいて割り当てられているマルチキャストアドレス
P を 1 に設定した場合、T も 1 に設定する必要があります。
Reserved - ゼロの予約値。
Plen - サブネットを識別するサイト接頭辞内のビット数。サイト接頭辞に基づいて割り当てられているマルチキャストアドレス用。
Group ID - 恒久的または動的に割り当てられたマルチキャストグループの識別子。
マルチキャストアドレスの書式の詳細については、RFC 3306, "Unicast-Prefix-based IPv6 Multicast Addresses を参照してください。
いくつかの IPv6 マルチキャストアドレスは、Internet Assigned Numbers Authority (IANA) によって恒久的に割り当てられます。これらの例としては、IPv6 ノードと IPv6 ルーターに必要な All Nodes Multicast Addresses と All Routers Multicast Addresses などがあります。IPv6 マルチキャストアドレスは動的に割り当てることもできます。マルチキャストアドレスとマルチキャストグループの適切な使用方法の詳細については、RFC 3307, "Allocation Guidelines for IPv6 Multicast Addresses" を参照してください。
IPv6 プロトコルは、基本 IPv6 ヘッダー、IPv6 拡張ヘッダーを含むヘッダーセットを定義します。次の図は、IPv6 ヘッダーに使用されるフィールドとその順序を示します。
次のリストは、各ヘッダーフィールドの機能について説明します。
バージョン – 4 ビットインターネットプロトコルバージョン番号。IPv6 では 6 です。
トラフィッククラス – 8 ビットトラフィッククラスフィールド。
フローラベル – 20 ビットフィールド。
ペイロードの長さ – オクテット単位で表す 16 ビット符号なし整数。IPv6 ヘッダーに続くパケットの残りです。
次のヘッダー – 8 ビットセレクタ。IPv6 ヘッダーのすぐ後ろに続くヘッダーのタイプを識別します。IPv4 プロトコルフィールドと同じ値を使用します。
ホップ制限 – 8 ビット符号なし整数。パケットを送信するノードごとに値が 1 ずつ減ります。ホップ制限がゼロになるとパケットが廃棄されます。
ソースアドレス – 128 ビット。パケットの初期送信側のアドレス。
宛先アドレス – 128 ビット。パケットの予定受信側のアドレス。オプションの経路制御ヘッダーがある場合、必ずしも受信側とは限りません。
IPv6 オプションは、IPv6 ヘッダーとトランスポート層の間の独立した拡張ヘッダーにあります。パケットが最終的な宛先に到着するまで、その配送パスに存在するルーターは、ほとんどの場合 IPv6 拡張ヘッダーを確認または処理しません。そのため、オプションを含むパケットを処理するルーターの性能が大幅に改善されました。IPv4 では、オプションがある場合、ルーターですべてのオプションを調べる必要がありました。
IPv4 オプションとは異なり、IPv6 拡張ヘッダーの長さは任意です。またパケットに組み込むことのできるオプションの合計数が 40 バイト以内に限定されない点があります。この機能とその処理方法によって、IPv4 では非現実的であった機能を IPv6 オプションが使用できるようになりました。
後続のオプションヘッダー (およびそのあとのトランスポートプロトコル) を処理する際の性能を強化するため、IPv6 オプションは常に 8 オクテットの整数倍の長さです。この 8 オクテットの整数倍という長さにより、後続ヘッダーのバイト境界が維持されます。
次の IPv6 拡張ヘッダーが現在、定義されています。
経路制御 – 拡張経路制御 (IPv4 ルーズソースルートにあたる)
断片化 – 断片化および再結合
認証 – 整合性および認証、セキュリティー
セキュリティーペイロードのカプセル化 – 機密性
ホップバイホップオプション – ホップごとの処理が必要な特別なオプション
宛先オプション – 宛先ノードが判断するオプション情報
「デュアルスタック」とは、アプリケーションからネットワーク層に至るプロトコルスタックのすべてのレベルの完全な複製をいいます。完全な複製の例として、OSI プロトコルとTCP/IP プロトコルを両方とも実行するシステムがあります。
Oracle Solaris は「デュアルスタック」です。これは、Oracle Solaris で IPv4 プロトコルと IPv6 プロトコルの両方が実装されていることを意味します。オペレーティングシステムをインストールするとき、IPv6 プロトコルを IP 層で有効にするか、デフォルトの IPv4 プロトコルだけを使用するかを選択できます。TCP/IP スタックの残りは同じです。結果として、同じ転送プロトコル、TCP、UDP、および SCTP を IPv4 と IPv6 の両方で実行できます。また、同じアプリケーションを IPv4 と IPv6 の両方で実行できます。図 11–4 は、インターネットプロトコル群のさまざまな層において、IPv4 プロトコルと IPv6 プロトコルがデュアルスタックとしてどのように機能するかを示しています。
デュアルスタックシナリオでは、ホストとルーターの両方のサブネットは、IPv4 に加えて、IPv6 をサポートするようにアップグレードされます。デュアルスタックアプローチによって、アップグレードしたノードは、IPv4 を使用して IPv4 専用ノードと常に相互運用できます。
この節では、Oracle Solaris で IPv6 が有効なファイル、コマンド、およびデーモンについて説明します。
この節では、IPv6 実装の一部である設定ファイルについて説明します。
/etc/inet/ndpd.conf ファイルは、 近傍検索デーモン in.ndpd が使用するオプションを設定するために使用されます。ルーターの場合、ndpd.conf は、主にサイト接頭辞をリンクに通知されるように設定するときに使用します。ホストの場合、ndpd.conf は、アドレスの自動設定を無効にしたり、一時アドレスを設定したりするときに使用します。
次の表に、ndpd.conf ファイルで使用されるキーワードを示します。
表 11–2 /etc/inet/ndpd.conf キーワード
変数 |
説明 |
---|---|
ifdefault |
すべてのインタフェースのルーターの動作を指定します。次の構文を使用してルーターパラメータと対応する値を設定します。 ifdefault [variable-value] |
prefixdefault |
接頭辞通知のデフォルトの動作を指定します。次の構文を使用してルーターパラメータと対応する値を設定します。 prefixdefault [variable-value] |
if |
インタフェース別パラメータを設定します。構文は次のとおりです。 if interface [variable-value ] |
prefix |
インタフェース別接頭辞情報を通知します。構文は次のとおりです。 prefix prefix/length interface [variable-value] |
ndpd.conf ファイルでは、この表にあるキーワードといっしょに、いくつかのルーター設定変数を使用します。これらの変数の詳細については、RFC 2461, Neighbor Discovery for IP Version 6 (IPv6) を参照してください。
次の表に、インタフェースを設定するための変数と、その簡単な説明を示します。
表 11–3 /etc/inet/ndpd.conf インタフェース設定変数
変数 |
デフォルト |
定義 |
---|---|---|
AdvRetransTimer |
0 |
ルーターが送信する通知メッセージにおいて、Retrans Timer フィールドの値を指定します。 |
AdvCurHopLimit |
インターネットの現在の直径 |
ルーターが送信する通知メッセージにおいて、現在のホップ制限に設定する値を指定します。 |
AdvDefaultLifetime |
3 + MaxRtrAdvInterval |
ルーター広告のデフォルトの寿命を指定します。 |
AdvLinkMTU |
0 |
ルーターが送信する最大転送単位 (MTU) の値を指定します。ゼロは、ルーターが MTU オプションを指定しないことを意味します。 |
AdvManaged Flag |
False |
ルーター広告において、Manage Address Configuration フラグに設定する値を指定します。 |
AdvOtherConfigFlag |
False |
ルーター広告において、Other Stateful Configuration フラグに設定する値を指定します。 |
AdvReachableTime |
0 |
ルーターが送信する通知メッセージにおいて、Reachable Time フィールドの値を指定します。 |
AdvSendAdvertisements |
False |
ノードが通知を送信し、ルーター要請に応答するかどうかを指定します。ルーター広告機能を有効にするには、 ndpd.conf ファイルにおいて、この変数を明示的に「TRUE」に設定する必要があります。詳細については、「IPv6 対応のルーターを構成する方法」を参照してください。 |
DupAddrDetect Transmits |
1 |
近傍検索プロトコルがローカルノードのアドレスの複製アドレス検出中に送信する、連続近傍要請メッセージの数を定義します。 |
MaxRtrAdvInterval |
600 秒 |
非要請マルチキャスト通知を送信する間隔の最大時間を指定します。 |
MinRtrAdvInterval |
200 秒 |
非要請マルチキャスト通知を送信する間隔の最小時間を指定します。 |
StatelessAddrConf |
True |
ノードがその IPv6 アドレスを設定するときに、ステートレスアドレス自動設定を使用するかどうかを制御します。 ndpd.conf で False が宣言されている場合、そのアドレスは手動で設定する必要があります。詳細については、「ユーザー指定の IPv6 トークンを構成する方法」を参照してください。 |
TmpAddrsEnabled |
False |
あるノードのすべてのインタフェースまたは特定のインタフェースに対して、一時アドレスを作成するかどうかを指定します。 詳細については、「一時アドレスを構成する方法」を参照してください。 |
TmpMaxDesyncFactor |
600 秒 |
in.ndpd を起動するときに、優先寿命変数 TmpPreferredLifetime から引くランダム数を指定します。TmpMaxDesyncFactor 変数の目的は、ネットワーク上のすべてのシステムが同時に一時アドレスを再生成することを防ぐことです。TmpMaxDesyncFactor を使用すると、このランダム数の上限値を変更できます。 |
TmpPreferredLifetime |
False |
一時アドレスの優先寿命を設定します。詳細については、「一時アドレスを構成する方法」を参照してください。 |
TmpRegenAdvance |
False |
一時アドレスのアドレス劣化までの先行時間を指定します。詳細については、「一時アドレスを構成する方法」を参照してください。 |
TmpValidLifetime |
False |
一時アドレスの有効寿命を設定します。詳細については、「一時アドレスを構成する方法」を参照してください。 |
次の表に、IPv6 接頭辞を設定するときに使用する変数を示します。
表 11–4 /etc/inet/ndpd.conf 接頭辞設定変数
変数 |
デフォルト |
定義 |
---|---|---|
AdvAutonomousFlag |
True |
Prefix Information オプションの Autonomous Flag フィールドに格納される値を指定します。 |
AdvOnLinkFlag |
True
|
Prefix Information オプションのオンリンクフラグ (“L-bit”) に格納される値を指定します。 |
AdvPreferredExpiration |
「設定なし」 |
接頭辞の優先満了日を指定します。 |
AdvPreferredLifetime |
604800 秒 |
Prefix Information オプションの優先寿命に格納される値を指定します。 |
AdvValidExpiration |
「設定なし」 |
接頭辞の有効満了日を指定します。 |
AdvValidLifetime |
2592000 秒 |
設定している接頭辞の有効寿命を指定します。 |
次に、ndpd.conf ファイルでキーワードや設定変数を使用する例を示します。変数を有効にするには、コメント (#) を削除します。
# ifdefault [variable-value ]* # prefixdefault [variable-value ]* # if ifname [variable-value ]* # prefix prefix/length ifname # # Per interface configuration variables # #DupAddrDetectTransmits #AdvSendAdvertisements #MaxRtrAdvInterval #MinRtrAdvInterval #AdvManagedFlag #AdvOtherConfigFlag #AdvLinkMTU #AdvReachableTime #AdvRetransTimer #AdvCurHopLimit #AdvDefaultLifetime # # Per Prefix: AdvPrefixList configuration variables # # #AdvValidLifetime #AdvOnLinkFlag #AdvPreferredLifetime #AdvAutonomousFlag #AdvValidExpiration #AdvPreferredExpiration ifdefault AdvReachableTime 30000 AdvRetransTimer 2000 prefixdefault AdvValidLifetime 240m AdvPreferredLifetime 120m if qe0 AdvSendAdvertisements 1 prefix 2:0:0:56::/64 qe0 prefix fec0:0:0:56::/64 qe0 if qe1 AdvSendAdvertisements 1 prefix 2:0:0:55::/64 qe1 prefix fec0:0:0:56::/64 qe1 if hme1 AdvSendAdvertisements 1 prefix 2002:8192:56bb:1::/64 qfe0 if hme1 AdvSendAdvertisements 1 prefix 2002:8192:56bb:2::/64 hme1 |
起動時、IPv6 は /etc/hostname6.interface ファイルを使用して、IPv6 論理インタフェースを自動的に定義します。Oracle Solaris のインストール中に IPv6 Enabled オプションを選択した場合、インストールプログラムは、/etc/hostname.interface ファイルに加えて、一次ネットワークインタフェース用の /etc/hostname6.interface ファイルを作成します。
インストール中に複数の物理インタフェースが検出された場合、このようなインタフェースを設定するかどうかをたずねられます。インストールプログラムは、指定された追加のインタフェースごとに、IPv4 物理インタフェース設定ファイルと IPv6 論理インタフェース設定ファイルを作成します。
IPv4 インタフェースと同様に、IPv6 インタフェースも Oracle Solaris インストール後に手動で設定できます。新しいインタフェースには /etc/hostname6.interface ファイルを作成します。インタフェースを手動で構成する方法については、「Solaris 10 3/05 の管理インタフェース」または第 6 章ネットワークインタフェースの管理 (作業)を参照してください。
ネットワークインタフェース設定ファイル名の構文は次のとおりです。
hostname.interface hostname6.interface |
interface 変数の構文は次のとおりです。
dev[.module[.module ...]]PPA |
ネットワークインタフェースデバイスを示します。デバイスは eri や qfe などの物理ネットワークインタフェースか、トンネルなどの論理インタフェースです。詳細については、「IPv6 インタフェース設定ファイル」を参照してください。
plumb される際にデバイスにプッシュされる 1 つまたは複数の STREAMS モジュールのリスト。
物理的な接続ポイントを示します。
構文 [.[.]] も可能です。
次に、有効な IPv6 設定ファイル名の例を示します。
hostname6.qfe0 hostname.ip.tun0 hostname.ip6.tun0 hostname6.ip6to4tun0 hostname6.ip.tun0 hostname6.ip6.tun0 |
/etc/inet/ipaddrsel.conf ファイルには、IPv6 デフォルトアドレス選択ポリシーテーブルが含まれます。Oracle Solaris をインストールしたときに IPv6 を有効にした場合、このファイルには、表 11–5 に示す内容が含まれます。
/etc/inet/ipaddrsel.conf ファイルの内容は編集できます。しかし、このファイルを変更することは極力避けるべきです。どうしても変更が必要な場合、手順については、「IPv6 アドレス選択ポリシーテーブルを管理する方法」を参照してください。ippaddrsel.conf の詳細については、「IPv6 アドレス選択ポリシーテーブルを変更する理由」と ipaddrsel.conf(4) のマニュアルページを参照してください。
この節では、Oracle Solaris IPv6 実装で追加されたコマンドについて説明します。また、IPv6 をサポートするために行われた既存のコマンドへの変更についても説明します。
ipaddrsel コマンドを使用すると、IPv6 デフォルトアドレス選択ポリシーテーブルを変更できます。
Oracle Solaris カーネルは IPv6 デフォルトアドレス選択ポリシーテーブルを使用して、IPv6 パケットヘッダーに対して、宛先アドレス順序付けやソースアドレス選択を実行します。/etc/inet/ipaddrsel.conf ファイルには、このポリシーテーブルが含まれます。
次の表に、このポリシーテーブルのデフォルトアドレス書式とその優先度のリストを示します。IPv6 アドレス選択に関する技術的な詳細については、inet6(7P) のマニュアルページを参照してください。
表 11–5 IPv6 アドレス選択ポリシーテーブル
接頭辞 |
優先度 |
定義 |
---|---|---|
::1/128 |
50 |
ループバック |
::/0 |
40 |
デフォルト |
2002::/16 |
30 |
6to4 |
::/96 |
20 |
IPv4 互換 |
::ffff:0:0/96 |
10 |
IPv4 |
この表では、IPv6 接頭辞 (::1/128 と ::/0) は 6to4 アドレス (2002::/16) と IPv4 アドレス (::/96 と ::ffff:0:0/96) よりも優先されます。したがって、カーネルは、別の IPv6 宛先に向かうパケットに対して、インタフェースのグローバル IPv6 アドレスをデフォルトで選択します。インタフェースの IPv4 アドレスの優先度は、特に IPv6 宛先に向かうパケットに対しては低くなります。選択した IPv6 ソースアドレスを考えて、カーネルは宛先アドレスにも IPv6 書式を使用します。
ほとんどの場合、IPv6 デフォルトアドレス選択ポリシーテーブルを変更する必要はありません。どうしてもポリシーテーブルを管理する必要がある場合は、 ipaddrsel コマンドを使用します。
次のような場合、ポリシーテーブルの変更をお勧めします。
システムが 6to4 トンネル用のインタフェースを持っている場合、6to4 アドレスにより高いアドレスに変更できます。
特定の宛先アドレスと通信するときだけ特定のソースアドレスを使用したい場合、これらのアドレスをポリシーテーブルに追加します。そのあと、ifconfig コマンドを使用して、これらのアドレスが優先されるようにフラグを立てます。
IPv4 アドレスを IPv6 アドレスよりも優先させたい場合、::ffff:0:0/96 の優先度をより大きな値に変更します。
旧式のアドレスにより高い優先度を割り当てる必要がある場合は、旧式のアドレスをポリシーテーブルに追加します。たとえば、IPv6 内でサイトのローカルアドレスが旧式であると仮定します。これらのアドレスには、fec0::/10 という接頭辞があります。この場合、ポリシーテーブルを変更すると、サイトのローカルアドレスにより高いポリシーを与えることができます。
ipaddrsel コマンドの詳細については、ipaddrsel(1M) のマニュアルページを参照してください。
「6to4 トンネリング」を使用すると、孤立した 6to4 サイト間で通信できます。しかし、6to4 以外のネイティブ IPv6 サイトにパケットを転送する場合は、6to4 ルーターは 6to4 リレールーターとのトンネルを確立する必要があります。このトンネルが確立されると、「6to4 リレールーター」によって 6to4 パケットが IPv6 ネットワークに転送され、最終的にネイティブ IPv6 サイトに送信されます。6to4 有効化サイトがネイティブな IPv6 サイトとデータを交換する必要がある場合、6to4relay コマンドを使用して、適切なトンネルを有効にします。
リレールーターの使用は安全とは言えないため、Oracle Solaris のデフォルト設定ではリレールーターとの間のトンネリングは無効になっています。このシナリオを実践に移す場合は、6to4 リレールーターとの間のトンネル構築に伴って発生する問題点をあらかじめ慎重に検討してください。6to4 リレールーターの詳細については、「6to4 リレールーターとの間のトンネルについての考慮事項」を参照してください。6to4 リレールーターのサポートを有効にする場合、その関連手順については、「6to4 トンネルを設定する方法」を参照してください。
6to4relay -e [-a IPv4-address] -d -h |
6to4 ルーターとエニーキャスト 6to4 リレールーター間のトンネルサポートを有効にします。このオプションを指定すると、トンネルのエンドポイントアドレスが 192.88.99.1 (6to4 リレールーターのエニーキャストグループのデフォルトアドレス) に設定されます。
6to4 ルーターと指定された IPv4-address の 6to4 リレールーター間にトンネルを確立します。
6to4 リレールーターとの間のトンネリングのサポートを無効にします。これは、Oracle Solaris のデフォルトの設定です。
6to4relay のヘルプを表示します。
詳細は、6to4relay(1M) のマニュアルページを参照してください。
引数を指定せずに 6to4relay コマンドを実行すると、6to4 リレールーターサポートの現在の状態が表示されます。次の例に、Oracle Solaris における IPv6 実装のデフォルトを示します。
# /usr/sbin/6to4relay 6to4relay:6to4 Relay Router communication support is disabled |
リレールーターサポートが有効に設定されている場合には、6to4relay を実行すると次のように表示されます。
# /usr/sbin/6to4relay 6to4relay:6to4 Relay Router communication support is enabled IPv4 destination address of Relay Router=192.88.99.1 |
6to4relay コマンドに -a オプションと IPv4 アドレスを指定した場合、192.88.99.1 ではなく、- a オプションに指定した IPv4 アドレスが表示されます。
6to4relay は、-d、 -e、および -a IPv4 address オプションが成功したかどうかを報告しません。しかし、これらのオプションの実行時に発生した可能性のあるエラーは表示します。
ifconfig コマンドにより、IPv6 インタフェースとトンネリングモジュールを plumb できるようになりました。ifconfig は、ioctl の拡張セットを使用して、IPv4 と IPv6 の両方のネットワークインタフェースを設定します。次に、IPv6 操作をサポートする ifconfig オプションについて説明します。ifconfig に関連する IPv4 と IPv6 の両方の作業については、「ifconfig コマンドによるインタフェース構成の監視」を参照してください。
インタフェースインデックスを設定します。
トンネルソース / 宛先を設定します。
論理インタフェースの次の候補を作成します。
指定された IP アドレスの論理インタフェースを削除します。
インタフェースにポイントツーポイント宛先アドレスを設定します。
インタフェースにアドレスとネットマスクのどちらか、または両方を設定します。
インタフェースのサブネットアドレスを設定します。
インタフェースにおけるパケット伝送を使用可能または使用不能にします。
IPv6 を設定する手順については、第 7 章IPv6 ネットワークの構成 (手順)を参照してください。
次の形式の ifconfig コマンドは、 hme0:3 論理インタフェースを作成します。
# ifconfig hme0 inet6 addif up Created new logical interface hme0:3 |
次の形式の ifconfig は、新しいインタフェースの作成を確認します。
# ifconfig hme0:3 inet6 hme0:3: flags=2000841<UP,RUNNING,MULTICAST,IPv6> mtu 1500 index 2 inet6 inet6 fe80::203:baff:fe11:b321/10 |
次の形式の ifconfig コマンドは、 hme0:3 論理インタフェースを削除します。
# ifconfig hme0:3 inet6 down # ifconfig hme0 inet6 removeif 1234::5678 |
# ifconfig ip.tun0 inet6 plumb index 13 |
物理インタフェース名に関連するトンネルを開きます。
# ifconfig ip.tun0 inet6 ip.tun0: flags=2200850<POINTOPOINT,RUNNING,MULTICAST,NONUD, #IPv6> mtu 1480 index 13 inet tunnel src 0.0.0.0 inet6 fe80::/10 --> :: |
トンネルデバイスを使用して、そのデバイスの状態を報告するように、TCP/IP に必要なストリームを設定します。
# ifconfig ip.tun0 inet6 tsrc 120.46.86.158 tdst 120.46.86.122 |
トンネルのソースアドレスと宛先アドレスを設定します。
# ifconfig ip.tun0 inet6 ip.tun0: flags=2200850<POINTOPOINT,RUNNING,MULTICAST,NONUD, IPv6> mtu 1480 index 13 inet tunnel src 120.46.86.158 tunnel dst 120.46.86.122 inet6 fe80::8192:569e/10 --> fe80::8192:567a |
設定後のデバイスの新しい状態を報告します。
この 6to4 擬似インタフェース設定例は、サブネット ID として 1 を使用し、ホスト ID を 16 進形式で指定しています。
# ifconfig ip.6to4tun0 inet6 plumb # ifconfig ip.6to4tun0 inet tsrc 129.146.86.187 \ 2002:8192:56bb:1::8192:56bb/64 up |
# ifconfig ip.6to4tun0 inet6 ip.6to4tun0: flags=2200041<UP,RUNNING,NONUD,IPv6>mtu 1480 index 11 inet tunnel src 129.146.86.187 tunnel hop limit 60 inet6 2002:8192:56bb:1::8192:56bb/64 |
この例では、6to4 トンネルを設定するための短い形式を示します。
# ifconfig ip.6to4tun0 inet6 plumb # ifconfig ip.6to4tun0 inet tsrc 129.146.86.187 up |
# ifconfig ip.6to4tun0 inet6 ip.6to4tun0: flags=2200041<UP,RUNNING,NONUD,IPv6>mtu 1480 index 11 inet tunnel src 129.146.86.187 tunnel hop limit 60 inet6 2002:8192:56bb::1/64 |
netstat コマンドは、IPv4 ネットワークと IPv6 ネットワークの両方の状態を表示します。 表示するプロトコル情報を選択するには、/etc/default/inet_type ファイルに DEFAULT_IP 値を設定するか、-f コマンド行オプションを使用します。DEFAULT_IP のパラメータ設定では、netstat に IPv4 情報だけが表示されていることを確認できます。この設定は、-f オプションで無効にできます。inet_type ファイルの詳細については、inet_type(4) のマニュアルページを参照してください。
netstat コマンドの -p オプションは、net-to-media テーブルを表示します。これは、 IPv4 の場合は ARP テーブルであり、IPv6 の場合は近傍キャッシュです。詳細は、netstat(1M) のマニュアルページを参照してください。このコマンドを使用する手順については、「ソケットの状態を表示する方法」を参照してください。
snoop コマンドは、IPv4 パケットと IPv6 パケットの両方を取り込むことができます。IPv6 ヘッダー、IPv6 拡張ヘッダー、ICMPv6 ヘッダー、近傍検索プロトコルデータを表示できます。デフォルトで、snoop コマンドは、IPv4 パケットと IPv6 パケットの両方を表示します。ip または ip6 のプロトコルキーワードを指定した場合、snoop コマンドは IPv4 パケットまたは IPv6 パケットだけを表示します。IPv6 フィルタオプションでは、すべてのパケットをフィルタの対象にでき (IPv4 と IPv6 の両方)、IPv6 パケットだけが表示されます。詳細は、snoop(1m) のマニュアルページを参照してください。snoop コマンドを使用する手順については、「IPv6 ネットワークトラフィックを監視する方法」を参照してください。
route コマンドは IPv4 ルートと IPv6 ルートの両方で動作します。デフォルトでは、IPv4 ルートで動作します。route コマンドのすぐあとに -inet6 コマンド行オプションを指定した場合、route コマンドは IPv6 ルート上で動作します。詳細は、route(1M) のマニュアルページを参照してください。
ping コマンドは、ターゲットホストを検証するのに、IPv4 プロトコルと IPv6 プロトコルの両方で使用できます。プロトコル選択は、指定のターゲットホストのネームサーバーが戻すアドレスに依存します。デフォルトでネームサーバーによってターゲットホストの IPv6 アドレスが返されると、ping コマンドは IPv6 プロトコルを使用します。サーバーが IPv4 アドレスだけを戻すと、ping コマンドは IPv4 プロトコルを使用します。-A コマンド行オプションで使用するプロトコルを指定すれば、この動作を無効にできます。
詳細については、ping(1M) のマニュアルページを参照してください。ping を使用する手順については、「ping コマンドによるリモートホストの検証」を参照してください。
traceroute コマンドは、指定したホストへの IPv4 ルートと IPv6 ルートの両方で使用できます。使用するプロトコルの選択について、traceroute では、ping と同じアルゴリズムを使用します。選択を無効にするには、-A コマンド行オプションを使用します。マルチホームホストのすべてのアドレスまでの各ルートは -a コマンド行オプションでトレースできます。
詳細については、traceroute(1M) のマニュアルページを参照してください。traceroute を使用する手順については、「traceroute コマンドによる経路制御情報の表示」を参照してください。
この節では、IPv6 関連のデーモンについて説明します。
in.ndpd デーモンは、IPv6 近傍検索プロトコルとルーター発見を実装します。このデーモンは、IPv6 のアドレス自動設定も実装します。次に、in.ndpd でサポートされるオプションを示します。
デバッグを有効にします。
特定のイベントのデバッグを有効にします。
デフォルトの /etc/inet/ndpd.conf ファイル以外で、設定データを読み取るファイルを指定します。
インタフェースごとに関連情報を印刷します。
ルーター広告をループバックしません。
受信パケットを無視します。
冗長モードを指定します (さまざまな種類の診断メッセージを報告する)。
パケット追跡をオンに設定します。
in.ndpd デーモンは、/etc/inet/ndpd.conf 設定ファイルに設定されたパラメータと、/var/inet/ndpd_state.interface 起動ファイルの任意の適用可能なパラメータによって制御されます。
/etc/inet/ndpd.conf が存在すると構文解析され、ノードをルーターとして使用するための設定が行われます。表 11–2 に、このファイルに現れる可能性がある有効なキーワードのリストを示します。ホストを起動しても、ルーターがすぐには使用できない場合があります。ルーターによって通知されたパケットがドロップしたり、また、通知されたパケットがホストに届かない場合もあります。
/var/inet/ndpd_state.interface ファイルは状態ファイルです。このファイルはノードごとに定期的に更新されます。ノードに障害が発生し再起動した場合、ルーターがなくてもノードはインタフェースを設定できます。このファイルにはインタフェースアドレス、最終更新時間、有効期間などの情報が含まれています。また、先のルーター広告で得られた情報も含まれています。
状態ファイルの内容を変更する必要はありません。このファイルは、in.ndpd デーモンが自動的に管理します。
設定変数とそれに指定できる値のリストについては、in.ndpd(1M) のマニュアルページと ndpd.conf(4) のマニュアルページを参照してください。
in.ripngd デーモンは、RIPng (Routing Information Protocol next-generation for IPv6 routers) を実装します。RIPng は IPv6 における RIP 相当機能を定義します。routeadm コマンドで IPv6 ルーターを設定し、IPv6 経路制御を有効にした場合、in.ripngd デーモンはそのルーターに RIPng を実装します。
次に、RIPng のサポートされるオプションを示します。
n は RIPNG パケットの送受信に使用する代替ポート番号を指定します。
経路制御情報を打ち切ります。
デーモンがルーターとして動作しているかどうかの経路制御情報の提供を強制します。
ポイズンリバースを打ち切ります。
in.ripngd がルーターとして機能しない場合、各ルーターにはデフォルトのルートだけが指定されます。
IPv6 が有効なサーバーアプリケーションは、IPv4 要求と IPv6 要求の両方、あるいは、IPv6 要求だけを処理できます。IPv6 が有効なサーバーは常に、IPv6 ソケット経由の要求を処理します。さらに、IPv6 が有効なサーバーは、対応するクライアントで使用しているプロトコルと同じプロトコルを使用します。IPv6 用にサービスを追加または変更するには、Service Management Facility (SMF) から入手できるコマンドを使用します。
SMF コマンドについては、『Solaris のシステム管理 (基本編)』の「SMF コマンド行管理ユーティリティー」を参照してください。
SMF を使用して、SCTP 経由で動作する IPv4 サービスマニフェストを設定する作業の例については、 「SCTP プロトコルを使用するサービスを追加する方法」を参照してください。
IPv6 サービスを設定するには、そのサービスの inetadm プロファイルにある proto フィールド値に、適切な値のリストが含まれていることを確認する必要があります。
IPv4 要求と IPv6 要求の両方を処理するサービスの場合、proto 値として、tcp6、udp6、または sctp を選択します。proto 値として、tcp6、udp6、または sctp6 のいずれかを選択した場合、inetd は IPv6 が有効なサーバーに IPv6 ソケットを渡します。IPv4 クライアントが要求を持っている場合に備えて、IPv6 が有効なサーバーは IPv4 マップ済みアドレスを含んでいます。
IPv6 要求だけを処理するサービスの場合、proto 値として、tcp6only または tcp6only を選択します。これらの値を proto に選択した場合、 inetd は IPv6 が有効なサーバーに IPv6 ソケットを渡します。
Oracle Solaris コマンドを別の実装で置き換えた場合、そのサービスの実装が IPv6 をサポートすることを確認する必要があります。その実装が IPv6 をサポートしない場合、proto 値と して、tcp、udp、または sctp のいずれかを指定する必要があります。
次に、IPv4 とIPv6 の両方をサポートし、SCTP で動作する echo サービスマニフェストに inetadm を実行した結果のプロファイルを示します。
# inetadm -l svc:/network/echo:sctp_stream SCOPE NAME=VALUE name="echo" endpoint_type="stream" proto="sctp6" isrpc=FALSE wait=FALSE exec="/usr/lib/inet/in.echod -s" user="root" default bind_addr="" default bind_fail_max=-1 default bind_fail_interval=-1 default max_con_rate=-1 default max_copies=-1 default con_rate_offline=-1 default failrate_cnt=40 default failrate_interval=60 default inherit_env=TRUE default tcp_trace=FALSE default tcp_wrappers=FALSE |
proto フィールドの値を変更するには、次の構文を使用します。
# inetadm -m FMRI proto="transport-protocols" |
Oracle Solaris ソフトウェアが提供されるサーバーはすべて、proto 値として、tcp6、udp6、または sctp6 のいずれかを指定するプロファイルエントリを 1 つだけ必要とします。しかし、リモートシェルサーバー (shell) とリモート実行サーバー (exec) は、現在、単一のサービスインスタンスで設定されており、proto 値として、tcp と tcp6only の両方を含める必要があります。たとえば、shell の proto 値を設定するには、次のコマンドを発行します。
# inetadm -m network/shell:default proto="tcp,tcp6only" |
ソケットを使用する IPv6 対応サーバーの作成方法の詳細については、『プログラミングインタフェース』のソケット API の IPv6 拡張機能を参照してください。
サービスを IPv6 用に追加または変更するときには、次のことに注意しておく必要があります。
IPv4 接続と IPv6 接続の両方を有効にするには、proto 値として、 tcp6、sctp6、または udp6のいずれかを指定する必要があります。proto 値として、 tcp、 sctp、または udp を指定した場合、そのサービスは IPv4 だけを使用します。
inetd に対して、一対多スタイルの SCTP ソケットを使用するサービスインスタンスも追加できますが、推奨しません。inetd は、一対多スタイルの SCTP ソケットでは機能しません。
wait-status プロパティーまたは exec プロパティーが異なるため、サービスが 2 つのエントリを必要とする場合、オリジナルのサービスから 2 つのインスタンスまたはサービスを作成する必要があります。
IPv6 は近傍検索プロトコルを導入します (RFC 2461, Neighbor Discovery for IP Version 6 (IPv6) を参照)。近傍検索の主な機能の概要については、「IPv6 近傍検索プロトコルの概要」を参照してください。
この節では、近傍検索プロトコルの次の機能について説明します。
近傍検索では、次の 5 種類の新しい ICMP (インターネット制御メッセージプロトコル) メッセージを定義します。これらのメッセージの目的は、次のとおりです。
ルーター要請 – インタフェースが有効になると、ホストはルーター要請メッセージを送信できます。この要請は、次に予定されている時刻ではなく、ただちにルーター広告メッセージを送信するようにルーターに要求します。
ルーター広告 – ルーターは自分の存在、さまざまなリンクパラメータ、およびさまざまなインターネットパラメータを通知します。ルーターは定期的に、あるいはルーター要請メッセージに応じて通知します。ルーター広告には、オンリンク判別またはアドレス設定、あるいはホップ限界数の選択肢などに使用する接頭辞が含まれます。
近傍要請 – ノードは近傍要請メッセージを送信して、近傍のリンク層アドレスを判別します。近傍要請メッセージはまた、キャッシュされたリンク層アドレスによって近傍が到達可能であるかを確認するために送信されます。近傍要請は重複アドレス検出にも使用します。
近傍通知 – ノードは、近傍要請メッセージへの応答として、近傍通知メッセージを送信します。ノードはまた、非要請近傍通知を送信して、リンク層アドレスの変更を通知できます。
リダイレクト – ルーターはリダイレクトメッセージを使用して、宛先までのより高速なホップをホストに通知したり、宛先が同じリンク上にあることを通知します。
この節では、自動設定中にインタフェースが実行する一般的な手順の概要について説明します。自動設定が行われるのはマルチキャスト対応リンクだけです。
たとえば、ノードの起動中、マルチキャスト対応インタフェースが有効になります。
このノードは、そのインタフェースのリンクローカルアドレスを生成することによって、自動設定プロセスを開始します。
リンクローカルアドレスは、インタフェースの MAC (Media Access Control) アドレスから形成されます。
このノードは、仮リンクローカルアドレスをターゲットとする近傍要請メッセージを送信します。
このメッセージの目的は、仮リンクローカルアドレスが、すでにそのリンク上の別のノードによって使用されているかどうかを確認することです。この確認が終わったら、リンクローカルアドレスをインタフェースに割り当てることができます。
別のノードがすでにそのアドレスを使用していた場合、その別のノードは近傍通知メッセージを戻して、そのアドレスが使用中であることを伝えます。
別のノードがそのアドレスを使用しようと試みている場合、そのノードもその宛先に近傍要請を送信します。
近傍要請送信や再送の数と、連続した要請間の遅延 はリンクによって異なります。これらのパラメータは、必要であれば設定できます。
仮リンクローカルアドレスが一意でないとノードが判断した場合、自動設定は停止します。その時点で、インタフェースのリンクローカルアドレスは手動で設定する必要があります。
しかし、ここで、デフォルト以外の代替のインタフェース ID を指定することも可能です。これにより、一意であると考えられる新しいインタフェース ID を使用して、自動設定機構を再開できます。
この仮リンクローカルアドレスが一意であると判断されると、ノードはインタフェースにそのアドレスを割り当てます。
このとき、ノードは近傍ノードと IP レベルで接続されます。自動設定手順の残りは、ホストだけで実行されます。
自動設定の次の段階は、ルーター広告を受信するか、ルーターが存在しないことを判断することです。ルーターがあれば、ホストが実行すべき自動設定の種類を指定したルーター広告が送信されます。
ルーターはルーター広告を定期的に送信します。ただし、連続した送信と送信の間の遅延は、自動設定を実行するホスト側の待機時間より通常は長くなります。通知を迅速に受信するため、すべてのルーターマルチキャストグループに 1 つまたは複数のルーター要請を送信します。
ルーター広告には、ステートレスアドレス自動設定が接頭辞を生成するときに使用する接頭辞変数とその情報が含まれます。ルーター広告の Stateless Address Autoconfiguration フィールドは個別に処理されます。接頭辞情報オプションフィールドの1 つである Address Autoconfiguration フラグは、オプションがステートレス自動設定にも適用されるかどうかを表します。適用される場合、補助オプションフィールドにサブネット接頭辞と寿命値が含まれます。これらの値は、接頭辞から作成されたアドレスがどれだけの時間優先権を持ち有効であるかを表します。
ルーターは定期的にルーター広告を生成するため、ホストは新しい通知を受信し続けます。IPv6 が有効なホストは、各通知に含まれる情報を処理します。情報を追加します。また、ホストは前の通知で受け取った情報を更新します。
セキュリティーのため、すべてのアドレスは、インタフェースに割り当てられる前に、その一意性をテストする必要があります。ただし、ステートレス自動設定で作成したアドレスの場合は状況が異なります。アドレスの一意性は、インタフェース ID から生成されるアドレスの一部で主に決まります。したがって、ノードにおいてリンクローカルアドレスの一意性が確認されると、ほかのアドレスの個別の確認は不要になります。これらのアドレスが、同じインタフェース ID から生成されているためです。ただし、手動で得られるアドレスはすべて、個別に一意であることを確認する必要があります。一部のサイトのシステム管理者は、重複アドレスの検出を実行するためのオーバーヘッドが大きく、それを実行することで得られる利益が帳消しになると信じています。そのようなサイトでは、インタフェース別設定フラグの設定で重複アドレスの検出の使用を無効にできます。
自動設定処理を短時間で終了するために、ルーター広告の待機、リンクローカルアドレスの生成、およびその一意性の確認を、ホストで並列して実行できます。ルーターでは、ルーター要請に対する応答が数秒遅れる可能性があります。そのため、上記 2 つの手順を 1 つずつ実行すると、自動設定を完了するために必要な合計時間が大幅に長くなる可能性があります。
近傍検索は、「近傍要請」メッセージを使用して、複数のノードに同じユニキャストアドレスが割り当てられているかどうかを判断します。「近傍不到達検出」では、近傍エラーや近傍への送信パスのエラーを検出します。近傍不到達検出では、近傍に送信されるパケットがその近傍に実際にアクセスして、パケットがノードの IP 層によって適切に処理されているかどうかを判断します。
近傍不到達検出では、2 つのソースの確認を使用します。 つまり、上位層プロトコルと近傍要請メッセージです。可能な場合、上位層のプロトコルでは、接続が送信を処理中であるという肯定確認を戻します。たとえば、新しい TCP 確認を受信した場合、以前送信されたデータが正しく送信されたことが確認されます。
あるノードが上位層プロトコルから肯定的な確認を受信しない場合、このノードはユニキャスト近傍要請メッセージを送信します。このメッセージは、次のホップからの到達可能確認として近傍通知を要請します。不要なネットワークトラフィックを避けるため、ノードからアクティブにパケットが送信されている近傍にだけ探査メッセージが送信されます。
すべての設定されたアドレスが特定のリンク上で一意であるかどうかを確認するために、ノードは「重複アドレス検出」アルゴリズムをアドレスに対して実行します。この実行は、インタフェースにアドレスを割り当てる前に行われる必要があります。重複アドレスの検出アルゴリズムは、すべてのアドレスを対象として実行されます。
この節で指定する自動設定プロセスは、ホストにだけ適用し、ルーターには適用しません。ホストの自動設定では、ルーターが通知した情報を使用するため、ルーターは別の手段で設定する必要があります。ただし、この章で説明した機構を使用して、ルーターによってリンクローカルアドレスが生成される場合があります。また、インタフェースに割り当てられる前に、すべてのアドレスにおいてルーターによる重複アドレスの検出アルゴリズムが正常終了していることが望まれます。
ターゲットアドレスの代わりにパケットを受信するルーターは、取り消しできない近傍通知を発行できる。ルーターは、近傍要請に応答できない宛先アドレスのかわりにパケットを受信する。現在はプロキシの使用方法は指定されていないが、オフリンクになった移動ノードをプロキシ通知で処理できる可能性がある。ただし、プロキシは、このプロトコルを実装していないノードを処理する一般的な機構として使用されることはない
インタフェースを複製したノードでは、同じリンク上の複数のネットワークインタフェース間の入力パケットの受信の負荷分散ができる。このようなノードには、同じインタフェースに複数のリンクローカルアドレスが割り当てられる。たとえば、1 つのネットワークドライバで、複数のネットワークインタフェースカードを、複数のリンクローカルアドレスを持つ 1 つの論理インタフェースとして表現できる。
負荷分散は、ルーターがソースリンクローカルアドレスをルーター広告パケットから省略することを可能にすることで処理する。結果として、近傍は近傍要請メッセージを使用して、ルーターのリンクローカルアドレスを確認する。返される近傍通知メッセージには、要請元によって異なるリンクローカルアドレスが含まれ る
リンクローカルアドレスの変更を認識したノードは、非要請近傍通知パケットをマルチキャストできる。ノードは、すべてのノードにパケットをマルチキャストして、無効になったキャッシュに入っているリンクローカルアドレスを更新できる。非要請通知の送信は、性能強化が目的。近傍不到達検出アルゴリズムにより、すべてのノードが確実に新しいアドレスを探索できるが、遅延が多少伸びる可能性がある
IPv6 近傍検索プロトコルの機能は、次のような IPv4 プロトコルの組み合わせのようなものです。 つまり、アドレス解決プロトコル (ARP)、Internet Control Message Protocol (ICMP)、ルーター発見、および ICMP リダイレクトです。IPv4 には近傍不到達検出に全般的に対応できるプロトコルや機構はありませんでした。ただし、ホスト条件ではデッドゲートウェイ検出に対応できるアルゴリズムがいくつか指定されています。デッドゲートウェイ検出は、近傍不到達検出の一部です。
次のリストは、近傍検索プロトコルと関連する IPv4 プロトコルセットを比較します。
ルーター発見は IPv6 ベースプロトコルセットの一部です。IPv6 ホストは、ルーターを検索するために、経路制御プロトコルを snoop する必要はありません。IPv4 は、ルーターを検索するために、ARP、ICMP ルーター発見、および ICMP リダイレクトを使用します。
IPv6 ルーター広告はリンクローカルアドレスを伝達します。ルーターのリンクローカルアドレスを解決するために、これ以外のパケットを交換する必要はありません。
ルーター広告はリンクのサイト接頭辞を伝達します。IPv4 の場合と同様に、ネットマスクを設定するのに別の機構は必要ありません。
ルーター広告では、アドレス自動設定が使用可能になります。自動設定は IPv4 には実装されません。
近傍検索により、IPv6 ルーターはホストの MTU を通知して、リンクで使用できるようにします。したがって、MTU が定義されていないすべてのノードはリンク上の同じ MTU 値を使用します。IPv4 の場合、同じネットワーク上のホストが異なる MTU を持つ場合もあります。
IPv4 ブロードキャストアドレスとは異なり、IPv6 アドレス解決マルチキャストは 40 億個を超える (2^32) マルチキャストアドレスを持つため、ターゲット以外のノードに対するアドレス解決関係の割り込みを大幅に減らしました。さらに、IPv6 以外のマシンの割り込みをなくしました。
IPv6 リダイレクトには、新しい最初のホップのリンクローカルアドレスが含まれます。独立したアドレス解決がなくてもリダイレクトを受信できます。
同じ IPv6 ネットワークに複数のサイト接頭辞を関連付けられます。デフォルトでは、ホストはローカルサイトのすべての接頭辞をルーター広告を通じて知ります。ただし、ルーター広告にある接頭辞をすべて、あるいは一部省略するようにルーターを設定できます。その場合、ホストは宛先がリモートネットワーク上にあるとみなします。その結果、ホストはルーターにトラフィックを送信します。ルーターは適宜リダイレクトを発行します。
IPv4 とは異なり、IPv6 リダイレクトの受信者は新しい次のホップがローカルネットワーク上にあるとみなします。IPv4 では、リダイレクトメッセージに指定されている次のホップが (ネットワークマスクによると) ローカルネットワーク上にない場合、ホストはそのリダイレクトメッセージを無視します。IPv6 リダイレクト機構は、IPv4 の XRedirect 機能に似ています。このリダイレクト機構は、非ブロードキャストおよび共有メディアリンク上で便利です。このようなネットワークでは、ノードはローカルリンク宛先のすべての接頭辞を確認できません。
IPv6 近傍不到達検出は、障害ルーターが存在する場合のパケット伝送能力を改善します。この機能は、部分的に障害があるリンクやパーティション化されたリンクを経由するパケット伝送を改善します。この機能はまた、自分のリンクローカルアドレスを変更するノードを経由するパケット伝送も改善します。たとえば、頻繁に更新される ARP キャッシュのおかげで、移動ノードはローカルネットワークから離れても切断されません。IPv4 には、近傍不到達検出に相当する機能がありません。
ARPとは異なり、近傍検索では、近傍不到達検出により、ハーフリンクエラーを検出します。近傍検索は、双方向接続がない近傍にトラフィックが送信されるのを防ぎます。
リンクローカルアドレスでルーターを一意に識別しておけば、ホストでルーター関連付けを維持できます。ルーターを識別する機能は、ルーター広告とリダイレクトメッセージで必要とされます。サイトが新しいグローバル接頭辞を使用しても、ホストはルーター関連付けを維持する必要があります。IPv4 には、ルーター識別に相当する機能がありません。
近傍検索メッセージのホップ制限は受信時に 255 なので、プロトコルがオフリンクノードによるスプーフエラーの被害を受けることがありません。逆に、IPv4 オフリンクノードは ICMP リダイレクトメッセージを送信できます。IPv4 オフリンクノードはルーター通知メッセージを送ることもできます。
ICMP 層にアドレス解決を配置すると、近傍検索が ARP よりもメディアに依存しなくなります。その結果、標準 IP 認証とセキュリティー機構が使用できるようになります。
IPv6 における経路制御は、Classless Inter-Domain Routing (CIDR) 下における IPv4 の経路制御とほとんど同じです。唯一の違いは、IPv4 では 32 ビットアドレスを使用しますが、IPv6 では 128 ビットアドレスを使用することです。非常に簡単な拡張で、IPv4 の経路制御アルゴリズム (OSPF、RIP、IDRP、IS-IS など) をすべて IPv6 の経路制御に使用できます。
IPv6 には、新たに強力な経路制御機能をサポートした簡単な経路制御拡張機能も組み込まれました。次のリストに、新しい経路制御機能を示します。
プロバイダ選択 (ポリシー、性能、コストなどを基準に)
ホストの移動性 (現在の場所までのルート)
アドレスの自動的な再指定 (新しいアドレスへのルート)
新しい経路制御機能を利用するには、IPv6 経路制御オプションを使用する IPv6 アドレスのシーケンスを作成します。IPv6 の送信元は、経路制御オプションでを使用して、パケットが宛先に至るまでに経由する複数の中間ノード (またはトポロジカルグループ) をリストします。この中間ノードは、パケットの宛先の途中に通過します。この機能は、IPv4 での緩やかな経路制御と記録オプションによく似ています。
アドレスシーケンスを一般的に使用する場合、通常は、ホストが受信したパケットのルートを逆戻りする必要があります。このパケットは、IPv6 認証ヘッダーを使用して正常に認証される必要があります。パケットを発信者に戻すには、アドレスシーケンスがパケット内に含まれている必要があります。IPv6 ホストの実装では、この方式により始点ルートの処理と逆引きをサポートしています。始点ルートの処理と逆引きは、IPv6 の新機能 (プロバイダの選択や拡張アドレスなど) を実装するホストをプロバイダが使用するためのポイントです。
マルチキャスト対応リンクとポイントツーポイントリンクでは、各ルーターは定期的にルーター広告パケットをマルチキャストグループに送信して、ルーターが利用できることを知らせます。ホストはすべてのルーターからルーター広告を受け取り、デフォルトルーターのリストを作成します。ルーターは頻繁にルーター広告を生成するので、ホストは数分でルーターが利用できることを知ることができます。ただし、通知がないからといってルーターエラーであると判断できるほどの頻度ではありません。エラー検出には、近傍到達不能性を判別する別の検出アルゴリズムを利用します。
ルーター広告には、ホストがルーターと同じリンク上にいる (つまり、オンリンクである) かどうかを判断するときに使用するサブネット接頭辞のリストが含まれます。この接頭辞リストは、自動アドレス設定にも使用されます。接頭辞に付属するフラグは特定の接頭辞の使用目的を表します。ホストは通知されたオンリンク接頭辞を使用して、パケットの宛先がオンリンクであるか、あるいはルーターを越えているかを判断するためのリストを作成および管理します。通知されたオンリンク接頭辞になくても宛先がオンリンクの場合があります。この場合、ルーターはリダイレクトを送ることができます。リダイレクトは送信側に、宛先が近傍であることを知らせます。
ルーター広告と接頭辞別のフラグを使用すると、ルーターはステートレスアドレス自動設定を実行する方法をホストに伝えることができます。
ルーター広告メッセージには、ホストが発信するパケットに使用するインターネットパラメータ (ホップの制限など) も含めることができます。また、オプションでリンク MTU などのリンクパラメータも含めることができます。この機能により、重要なパラメータを集中管理できます。パラメータは、ルーターに設定され、関連付けられたすべてのホストに自動的に伝達されます。
アドレス解決を行うために、ノードは、宛先ノードがリンク層アドレスを戻すように要求する近傍要請をマルチキャストグループに送信します。マルチキャストされた近傍要請メッセージは、宛先アドレスの要請先ノードのマルチキャストアドレスに送信されます。宛先は、そのリンク層アドレスをユニキャスト近傍通知メッセージで戻します。発信元と宛先の両方に対して 1 つの要求応答パケットペアで互いのリンク層アドレスを処理できます。発信元は、近傍要請に発信元のリンク層アドレスを組み込みます。
デュアルスタック (IPv4 と IPv6 の両用サイト) における依存を最小限に抑えるため、2 つの IPv6 ノード間のパス中にあるすべてのルーターが IPv6 をサポートする必要はありません。このようなネットワーク構成をサポートする機構のことを「トンネル」と呼びます。基本的に IPv6 パケットは IPv4 パケット内部に組み込まれ、IPv4 ルーター間を転送されます。次の図に、IPv6 ルーター (図中の “R”) を通るトンネル機構を示します。
Oracle Solaris IPv6 実装には、2 つの種類のトンネル機構があります。
2 つのルーター間に構成されたトンネル (図 11–5 を参照)
エンドポイントホストで終了する自動トンネル
作成されたトンネルは現在、インターネット上の、たとえば、MBONE (IPv4 マルチキャストバックボーン ) で、ほかの目的に使用されています。設定トンネルの作成手順からいうと、2 つのルー ターを設定して、その間に IPv4 ネットワーク経由の仮想ポイントツーポイントリンクを作成します。近い将来、インターネットのさまざまな局面に、この種のトンネルが利用されるでしょう。
自動トンネルには、IPv4 互換アドレスを必要とします。自動トンネルは、IPv6 ルーターが使用できない場合に IPv6 ノードを接続するために使用できます。このようなトンネルは、自動トンネルネットワークインタフェースを設定することによって、デュアルスタックホストまたはデュアルスタックルーターから作成できます。トンネルは常に、デュアルスタックホストで終了します。トンネルのはたらきにより、宛先 IPv4 アドレス (トンネルの終点) が IPv4 互換宛先アドレスから抽出されて動的に指定されます。
トンネルインタフェースのフォーマットは次のとおりです。
ip.tun ppa |
システムの起動時、トンネルモジュール (tun) は ifconfig コマンドによって IP の一番上にプッシュされ、仮想インタフェースが作成されます。このプッシュは、hostname6.* ファイルを作成することによって行われます。
たとえば、IPv4 ネットワーク経由で IPv6 パケットをカプセル化するためのトンネルを作成するには、次のファイルを作成します。
/etc/hostname6.ip.tun0 |
このファイルの内容は、インタフェースが plumb されたあとで、ifconfig に渡されます。ポイントツーポイントトンネルの設定に必要なパラメータになります。
次に、hostname6.ip.tun0 ファイルのエントリの例を示します。
tsrc 10.10.10.23 tdst 172.16.7.19 up addif 2001:db8:3b4c:1:5678:5678::2 up |
この例では、IPv4 ソースアドレスと宛先アドレスは、IPv6 リンクローカルアドレスを自動設定するためのトークンとして使用されます。これらのアドレスは、ip.tun0 インタフェースのソースと宛先です。次の 2 つのインタフェース ip.tun0 インタフェースと、論理インタフェース ip.tun0:1 が設定されます。論理インタフェースには、addif コマンドによって指定されたソースと宛先 IPv6 アドレスがあります。
システムをマルチユーザーモードで起動すると、これらの設定ファイルの内容は変更されずに ifconfig に渡されます。例 11–11 内のエントリは、次と同等です。
# ifconfig ip.tun0 inet6 plumb # ifconfig ip.tun0 inet6 tsrc 10.0.0.23 tdst 172.16.7.19 up # ifconfig ip.tun0 inet6 addif 2001:db8:3b4c:1:5678:5678::2 up |
次に、このトンネルにおける ifconfig -a の出力を示します。
ip.tun0: flags=2200850<UP,POINTOPOINT,RUNNING,MULTICAST, NONUD,IPv6> mtu 1480 index 6 inet tunnel src 10.0.0.23 tunnel dst 172.16.7.19 inet6 fe80::c0a8:6417/10 --> fe80::c0a8:713 ip.tun0:1: flags=2200850<UP,POINTOPOINT,RUNNING,MULTICAST,NONUD,IPv6> mtu 1480 index 5 inet6 2001:db8:3b4c:1:5678:5678::2 |
次の構文で設定ファイルに行を追加すれば、さらに論理インタフェースを設定できます。
addif IPv6-source IPv6-destination up |
トンネルのどちらかの端がトンネル経由で 1 つ以上の接頭辞を通知する IPv6 ルーターである場合、トンネル設定ファイルには addif コマンドは必要ありません。ほかのアドレスは自動設定されるため、必要とされる可能性があるのは tsrc と tdst だけです。
場合によっては、特定のトンネルについて、固有のソースリンクローカルアドレスと宛先リンクローカルアドレスを手動で設定する必要があることもあります。その場合、設定ファイルの最初の行を変更して、これらのリンクローカルアドレスを組み込みます。次に例を示します。
tsrc 10.0.0.23 tdst 172.16.7.19 fe80::1/10 fe80::2 up |
ソースのリンクローカルアドレスの接頭辞の長さが 10 であることに注目してください。この例では、ip.tun0 インタフェースは次のようになります。
ip.tun0: flags=2200850<UP,POINTOPOINT,RUNNING,MULTICAST,NONUD,IPv6> mtu 1480 index 6 inet tunnel src 10.0.0.23 tunnel dst 172.16.7.19 inet6 fe80::1/10 --> fe80::2 |
IPv6 ネットワーク経由で IPv6 パケットをカプセル化するためのトンネル (IPv6 over IPv6 トンネル) を作成するには、次のファイル名を作成します。
/etc/hostname6.ip6.tun0 |
次に、IPv6 ネットワーク経由の IPv6 カプセル化における hostname6.ip6.tun0 ファイルのエントリの例を示します。
tsrc 2001:db8:3b4c:114:a00:20ff:fe72:668c tdst 2001:db8:15fa:25:a00:20ff:fe9b:a1c3 fe80::4 fe80::61 up |
IPv6 ネットワーク経由で IPv4 パケットをカプセル化するためのトンネル (IPv4 over IPv6 トンネル) を作成するには、次のファイル名を作成します。
/etc/hostname.ip6.tun0 |
次に、IPv6 ネットワーク経由の IPv4 カプセル化における hostname.ip6.tun0 ファイルのエントリの例を示します。
tsrc 2001:db8:3b4c:114:a00:20ff:fe72:668c tdst 2001:db8:15fa:25:a00:20ff:fe9b:a1c3 10.0.0.4 10.0.0.61 up |
IPv4 ネットワーク経由で IPv4 パケットをカプセル化するためのトンネル (IPv4 over IPv4 トンネル) を作成するには、次のファイル名を作成します。
/etc/hostname.ip.tun0 |
次に、IPv4 ネットワーク経由の IPv4 カプセル化における hostname.ip.tun0 ファイルのエントリの例を示します。
tsrc 172.16.86.158 tdst 192.168.86.122 10.0.0.4 10.0.0.61 up |
tun の固有の情報については、tun(7M) のマニュアルページを参照してください。IPv6 への移行期間におけるトンネルの一般的な概念については、「IPv6 トンネルの概要」を参照してください。トンネルを設定する手順については、「IPv6 サポート用にトンネルを構成するための作業 (作業マップ)」を参照してください。
Oracle Solaris には、IPv4 から IPv 6 アドレス指定への移行期間における暫定的な優先方法として、6to4 トンネルがあります。6to4 トンネルを使用すると、孤立した IPv6 サイトが、IPv6 をサポートしていない IPv4 ネットワーク上の自動トンネルを通じて通信できるようになります。6to4 トンネルを使用するには、6to4 自動トンネルの片方のエンドポイントとして、境界ルーターを IPv6 ネットワークに設定する必要があります。そのあと、この 6to4 ルーターをほかの 6to4 サイトとの間のトンネルの構成要素として使用することも、あるいは必要に応じて 6to4 以外のネイティブ IPv6 サイトとの間のトンネルで使用することもできます。
この節では、6to4 に関連した次の参考情報を示します。
6to4 トンネルのトポロジ
6to4 アドレス指定 (通知の書式など)
6to4 トンネルを介したパケットフローの説明
6to4 ルーターと 6to4 リレールーター間のトンネルのトポロジ
6to4 リレールーターサポートを設定する前の考慮事項
次の表では、6to4 トンネルを構成するための追加作業について説明し、有用な追加情報の入手先を示しています。
作業または技術情報 |
参照先 |
---|---|
6to4 トンネルの設定作業 | |
6to4 関連の RFC | |
6to4 リレールーターとの間のトンネルのサポートを有効にする 6to4relay コマンドの詳細 | |
6to4 のセキュリティー |
6to4 トンネルは、あらゆる場所にあるすべての 6to4 サイトに IPv6 接続を提供します。同様に、リレールーターに転送するようにトンネルが構成されている場合、トンネルはネイティブ IPv6 インターネットも含むすべての IPv6 サイトへのリンクとしても機能します。次の図は、6to4 トンネルが 6to4 サイト間にこの接続を提供する仕組みを示しています。
この図は、独立した 2 つの 6to4 ネットワーク、サイト A とサイト B を示しています。各サイトは、IPv4 ネットワークに外部接続するようにルーターを設定してあります。IPv4 ネットワークを越える 6to4 トンネルによって、6to4 サイトをリンクする接続が提供されています。
IPv6 サイトを 6to4 サイトにするには、6to4 をサポートできるように 1 つ以上のルーターインタフェースを設定する必要があります。このインタフェースは、IPv4 ネットワークに対する外部接続を提供する必要があります。qfe0 で設定するアドレスは、一意 (世界で唯一) のものでなければなりません。次の図では、境界ルーター A のインタフェース qfe0 がサイト A を IPv4 ネットワークに接続しています。qfe0 を 6to4 擬似インタフェースとして設定するには、IPv4 アドレスを使用してあらかじめインタフェース qfe0 を設定しておきます。
上記の図では、6to4 サイト A はルーター A 上のインタフェース hme0 と hme1 に接続した 2 つのサブネットから構成されています。サイト A の両サブネットのすべての IPv6 ホストは、ルーター A からの通知を受け取ると 6to4 派生アドレスを使用して自動的に再設定を行います。
サイト B は、もう 1 つの独立した 6to4 サイトです。サイト A からトラフィックを正しく受け取るには、サイト B 側の境界ルーターを 6to4 をサポートするように設定する必要があります。この設定を行わないと、ルーターがサイト A から受け取るパケットが認識されずに削除されてしまいます。
この節では、ある 6to4 サイトにあるホストから、リモートの 6to4 サイトにあるホストまでのパケットのフローについて説明します。このシナリオでは、図 11–6 で使用したトポロジを使用します。このシナリオは、6to4 ルーターと 6to4 ホストがすでに設定済みであることを想定しています。
6to4 サイト A のサブネット 1 に存在するホストが伝送を行い、6to4 サイト B 上のホストが宛先として機能します。各パケットヘッダーには、送信元の 6to4 派生アドレスと宛先の 6to4 派生アドレスが含まれます。
サイト A のルーターは、IPv4 ヘッダー内で各 6to4 パケットをカプセル化します。このプロセスでルーターは、カプセル化ヘッダーの IPv4 宛先アドレスを、サイト B のルーターアドレスに設定します。トンネルインタフェースを通過する各 IPv6 パケットの IPv6 宛先アドレスには、この IPv4 宛先アドレスも含まれています。したがって、ルーターはカプセル化ヘッダーに設定されている IPv4 宛先アドレスを特定することができます。続いてサイト A のルーターは、標準の IPv4 経路制御手続きを使用し IPv4 ネットワークを介してこのパケットを転送します。
パケットが遭遇する IPv4 ルーターが、パケットの IPv4 宛先アドレスを使用して転送を行います。このアドレスはルーター B のインタフェースに使用される一意の (世界に 1 つしかない) IPv4 アドレスであり、6to4 擬似インタフェースとしても機能します。
サイト A から送付されたパケットがルーター B に到着します。ルーター B は、IPv4 ヘッダーを削除して IPv6 パケットのカプセル化を解除します。
続いてルーター B は、IPv6 パケット内の宛先アドレスを使用してサイト B の受信ホストにパケットを転送します。
6to4 リレールーターは、6to4 ではない ネイティブ IPv6 ネットワークと通信を行う必要がある 6to4 ルーターからのトンネルのエンドポイントとして機能します。本来、リレールーターは 6to4 サイトとネイティブ IPv6 サイトとの間のブリッジとして使用されます。この手法は安全ではない場合があるため、Oracle Solaris のデフォルト設定では 6to4 リレールーターのサポートは無効になっています。しかし、サイトでこのようなトンネルが必要な場合には 6to4relay コマンドを使用して次に示すようなトンネリングを有効にできます。
図 11–7 において、6to4 Site A はネイティブな IPv6 Site B にあるノードと通信する必要があります。次の図に、Site A から IPv4 ネットワークを越える 6to4 トンネルに通じるトラフィックパスを示します。このトンネルは、6to4 ルーター A と 6to4 リレールーターをエンドポイントとして使用しています。6to4 リレールーターより先は IPv6 ネットワークであり、IPv6 サイト B はこのネットワークに接続されています。
この節では、6to4 サイトからネイティブな IPv6 サイトまでのパケットフローについて説明します。このシナリオでは、図 11–7 で使用したトポロジを使用します。
6to4 サイト A 上のホストから、ネイティブ IPv6 サイト B 上のホストに向けて伝送を行います。各パケットヘッダーには、その発信元アドレスとして 6to4 派生アドレスが指定されています。宛先アドレスは標準の IPv6 アドレスです。
サイト A の 6to4 ルーターは、各パケットを宛先である 6to4 ルーターの Ipv4 アドレスを持つ IPv4 ヘッダー内でカプセル化します。この 6to4 ルーターは、標準の IPv4 経路制御手続きを使用し IPv4 ネットワークを介してこのパケットを転送します。パケットが遭遇する IPv4 ルーターが、6to4 リレールーターにパケットを転送します。
サイト A に物理的にもっとも近いエニーキャスト 6to4 リレールーターが、192.88.99.1 エニーキャストグループ宛てのパケットを検出します。
6to4 リレールーターエニーキャストグループの一部である 6to4 リレールーターには、192.88.99.1 という IP アドレスが割り当てられます。このエニーキャストアドレスは、6to4 リレールーターのデフォルトアドレスです。特定の 6to4 リレールーターを使用する必要がある場合は、デフォルトを上書きしてそのルーターの IPv4 アドレスを指定できます。
このリレールーターは、IPv4 ヘッダーを取り除いて 6to4 パケットのカプセル化を解除し、ネイティブ IPv6 宛先アドレスを明らかにします。
続いてこのリレールーターは、IPv6 のみとなったパケットを IPv6 ネットワークに送信します。IPv6 ネットワークにおいて、パケットは最終的に Site B のルーターによって検出されます。続いてこのルーターが、宛先である IPv6 ノードにパケットを転送します。
この節では、IPv6 の実装によって導入されたネームサービスの変更について説明します。IPv6 アドレスは、どの Oracle Solaris ネームサービス(NIS、LDAP、DNS、およびファイル) にも格納できます。また、NIS over IPv6 RPC トランスポートを使用すると、NIS データを検出できます。
IPv6 固有なリソースレコードである AAAA リソースレコードについては、RFC 1886、DNS Extensions to Support IP Version 6を参照してください。この AAAA レコードは、ホスト名を 128 ビット IPv6 アドレスにマップします。PTR レコードは IPv6 でも、IP アドレスをホスト名にマップするときに使用されています。128 ビットアドレスの 32 の 4 ビットニブルは、IPv6 アドレス用に反転されています。各ニブルは対応する 16 進 ASCII 値に変換されます。変換後、ip6.int が追加されます。
Solaris 10 11/06 以前のリリースでは、/etc/inet/ipnodes で IPv6 アドレスを調べる機能に加え、NIS、LDAP、DNS の各ネームサービスにも IPv6 サポートが追加されています。結果として、nsswitch.conf ファイルは、IPv6 検索をサポートするように変更されました。
hosts: files dns nisplus [NOTFOUND=return] ipnodes: files dns nisplus [NOTFOUND=return] |
IPv4 アドレスと IPv6 アドレスでこれらの ipnodes データベースを生成してから、複数のネームサービスで ipnodes を探すように /etc/nsswitch.conf ファイルを変更してください。ホストアドレスの解決時に不要な遅延が発生してしまうからです (起動タイミングの遅れが発生することもあります)。
次の図に、nsswitch.conf ファイルと、gethostbyname コマンドと getipnodebyname コマンドを使用するアプリケーション用の新しいネームサービスデータベースの間の新しい関係を示します。斜体の項目は新規です。gethostbyname コマンドは、/etc/inet/hosts に保存されている IPv4 アドレスだけを調べます。Solaris 10 11/06 以前のリリースでは、getipnodebyname コマンドは、nsswitch.conf ファイルの ipnodes エントリで指定したデータベースを調べます。検索に失敗すると、nsswitch.conf ファイルの hosts エントリで指定したデータベースを調べます。
ネームサービスの詳細は、『Solaris のシステム管理 (ネーミングとディレクトリサービス : DNS、NIS、LDAP 編)』を参照してください。
IPv6 をサポートするため、IPv6 アドレスは既存のネームサービスコマンドを使用して検索できます。たとえば、ypmatch コマンドは、新しい NIS マップに使用できます。nslookup コマンドでは、DNS の新しい AAAA レコードを調べることができます。
NFS ソフトウェアと遠隔手続き呼出し (RPC) ソフトウェアは、同じような方法で IPv6 をサポートします。NFS サービスに関連のある既存のコマンドは変更されていません。ほとんどの RPC アプリケーションが、変更なしで IPv6 で実行できます。トランスポート機能のある一部の高度 RPC アプリケーションに更新が必要な場合があります。
Oracle Solaris は、IPv6 経由の ATM、固定仮想回路 (PVC)、静的な交換仮想回路 (SVC) をサポートするようになりました。