JavaScript is required to for searching.
ナビゲーションリンクをスキップ
印刷ビューの終了
Solaris のシステム管理 (IP サービス)     Oracle Solaris 10 8/11 Information Library (日本語)
search filter icon
search icon

ドキュメントの情報

はじめに

パート I システム管理の概要: IP サービス

1.  Oracle Solaris TCP/IP プロトコル群 (概要)

パート II TCP/IP の管理

2.  TCP/IP ネットワークの計画 (手順)

3.  IPv6 の紹介(概要)

4.  IPv6 ネットワークの計画 (手順)

5.  TCP/IP ネットワークサービスと IPv4 アドレス指定の構成 (作業)

6.  ネットワークインタフェースの管理 (作業)

7.  IPv6 ネットワークの構成 (手順)

8.  TCP/IP ネットワークの管理 (手順)

9.  ネットワークの問題の障害追跡 (手順)

10.  TCP/IP と IPv4 の詳細 (リファレンス)

11.  IPv6 の詳細 (リファレンス)

IPv6 の新機能の詳細

IPv6 アドレス指定書式の詳細

6to4 派生のアドレス指定

ホストにおける 6to4 派生のアドレス指定

IPv6 マルチキャストアドレスの詳細

IPv6 パケットヘッダーの書式

IPv6 拡張ヘッダー

デュアルスタックプロトコル

Oracle Solaris の IPv6 の実装

IPv6 設定ファイル

ndpd.conf 設定ファイル

IPv6 インタフェース設定ファイル

/etc/inet/ipaddrsel.conf 設定ファイル

IPv6 関連のコマンド

ipaddrsel コマンド

6to4relay コマンド

IPv6 をサポートするための ifconfig コマンドの拡張

IPv6 をサポートするための netstat コマンドの変更

IPv6 をサポートするための snoop コマンドの変更

IPv6 をサポートするための route コマンドの変更

IPv6 をサポートするための ping コマンドの変更

IPv6 をサポートするための traceroute コマンドの変更

IPv6 関連のデーモン

in.ndpd デーモン、近傍検索用

in.ripngd デーモン、IPv6 経路制御用

inetd デーモンと IPv6 サービス

IPv6 近傍検索プロトコル

近傍検索からの ICMP メッセージ

自動設定プロセス

ルーター広告の受信

接頭辞設定変数

アドレスの一意性

近傍要請と不到達

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

プロキシ通知

入力負荷分散

リンクローカルアドレスの変更

近傍検索と ARP および関連する IPv4 プロトコルとの比較

IPv6 の経路制御

ルーター広告

ルーター広告接頭辞

ルーター広告メッセージ

IPv6 トンネル

トンネルの設定

6to4 自動トンネル

6to4 トンネルのトポロジ

6to4 トンネルを介したパケットフロー

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

Oracle Solaris ネームサービスに対する IPv6 拡張機能

IPv6 の DNS 拡張機能

nsswitch.conf ファイルへの変更

ネームサービスコマンドの変更

NFS と RPC による IPv6 のサポート

IPv6 over ATM のサポート

パート III DHCP

12.  DHCP について (概要)

13.  DHCP サービスの使用計画 (手順)

14.  DHCP サービスの構成 (手順)

15.  DHCP の管理 (手順)

16.  DHCP クライアントの構成と管理

17.  DHCP の障害追跡 (リファレンス)

18.  DHCP コマンドと DHCP ファイル (リファレンス)

パート IV IP セキュリティー

19.  IP セキュリティーアーキテクチャー (概要)

20.  IPsec の構成 (手順)

21.  IP セキュリティーアーキテクチャー (リファレンス)

22.  インターネットキー交換 (概要)

23.  IKE の設定 (手順)

24.  インターネットキー交換 (リファレンス)

25.  Oracle Solaris の IP フィルタ (概要)

26.  IP フィルタ (手順)

パート V モバイル IP

27.  モバイル IP (概要)

28.  モバイル IP の管理 (手順)

29.  モバイル IP のファイルおよびコマンド (リファレンス)

パート VI IPMP

30.  IPMP の紹介 (概要)

31.  IPMP の管理 (手順)

パート VII IP サービス品質 (IPQoS)

32.  IPQoS の紹介 (概要)

33.  IPQoS 対応ネットワークの計画 (手順)

34.  IPQoS 構成ファイルの作成 (手順)

35.  IPQoS の起動と保守(手順)

36.  フローアカウンティングの使用と統計情報の収集 (手順)

37.  IPQoS の詳細 (リファレンス)

用語集

索引

IPv6 近傍検索プロトコル

IPv6 は近傍検索プロトコルを導入します (RFC 2461, Neighbor Discovery for IP Version 6 (IPv6) を参照)。近傍検索の主な機能の概要については、「IPv6 近傍検索プロトコルの概要」を参照してください。

この節では、近傍検索プロトコルの次の機能について説明します。

近傍検索からの ICMP メッセージ

近傍検索では、次の 5 種類の新しい ICMP (インターネット制御メッセージプロトコル) メッセージを定義します。これらのメッセージの目的は、次のとおりです。

自動設定プロセス

この節では、自動設定中にインタフェースが実行する一般的な手順の概要について説明します。自動設定が行われるのはマルチキャスト対応リンクだけです。

  1. たとえば、ノードの起動中、マルチキャスト対応インタフェースが有効になります。

  2. このノードは、そのインタフェースのリンクローカルアドレスを生成することによって、自動設定プロセスを開始します。

    リンクローカルアドレスは、インタフェースの MAC (Media Access Control) アドレスから形成されます。

  3. このノードは、仮リンクローカルアドレスをターゲットとする近傍要請メッセージを送信します。

    このメッセージの目的は、仮リンクローカルアドレスが、すでにそのリンク上の別のノードによって使用されているかどうかを確認することです。この確認が終わったら、リンクローカルアドレスをインタフェースに割り当てることができます。

    1. 別のノードがすでにそのアドレスを使用していた場合、その別のノードは近傍通知メッセージを戻して、そのアドレスが使用中であることを伝えます。

    2. 別のノードがそのアドレスを使用しようと試みている場合、そのノードもその宛先に近傍要請を送信します。

      近傍要請送信や再送の数と、連続した要請間の遅延 はリンクによって異なります。これらのパラメータは、必要であれば設定できます。

  4. 仮リンクローカルアドレスが一意でないとノードが判断した場合、自動設定は停止します。その時点で、インタフェースのリンクローカルアドレスは手動で設定する必要があります。

    しかし、ここで、デフォルト以外の代替のインタフェース ID を指定することも可能です。これにより、一意であると考えられる新しいインタフェース ID を使用して、自動設定機構を再開できます。

  5. この仮リンクローカルアドレスが一意であると判断されると、ノードはインタフェースにそのアドレスを割り当てます。

    このとき、ノードは近傍ノードと IP レベルで接続されます。自動設定手順の残りは、ホストだけで実行されます。

ルーター広告の受信

自動設定の次の段階は、ルーター広告を受信するか、ルーターが存在しないことを判断することです。ルーターがあれば、ホストが実行すべき自動設定の種類を指定したルーター広告が送信されます。

ルーターはルーター広告を定期的に送信します。ただし、連続した送信と送信の間の遅延は、自動設定を実行するホスト側の待機時間より通常は長くなります。通知を迅速に受信するため、すべてのルーターマルチキャストグループに 1 つまたは複数のルーター要請を送信します。

接頭辞設定変数

ルーター広告には、ステートレスアドレス自動設定が接頭辞を生成するときに使用する接頭辞変数とその情報が含まれます。ルーター広告の Stateless Address Autoconfiguration フィールドは個別に処理されます。接頭辞情報オプションフィールドの1 つである Address Autoconfiguration フラグは、オプションがステートレス自動設定にも適用されるかどうかを表します。適用される場合、補助オプションフィールドにサブネット接頭辞と寿命値が含まれます。これらの値は、接頭辞から作成されたアドレスがどれだけの時間優先権を持ち有効であるかを表します。

ルーターは定期的にルーター広告を生成するため、ホストは新しい通知を受信し続けます。IPv6 が有効なホストは、各通知に含まれる情報を処理します。情報を追加します。また、ホストは前の通知で受け取った情報を更新します。

アドレスの一意性

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

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

近傍要請と不到達

近傍検索は、「近傍要請」メッセージを使用して、複数のノードに同じユニキャストアドレスが割り当てられているかどうかを判断します。「近傍不到達検出」では、近傍エラーや近傍への送信パスのエラーを検出します。近傍不到達検出では、近傍に送信されるパケットがその近傍に実際にアクセスして、パケットがノードの IP 層によって適切に処理されているかどうかを判断します。

近傍不到達検出では、2 つのソースの確認を使用します。 つまり、上位層プロトコルと近傍要請メッセージです。可能な場合、上位層のプロトコルでは、接続が送信を処理中であるという肯定確認を戻します。たとえば、新しい TCP 確認を受信した場合、以前送信されたデータが正しく送信されたことが確認されます。

あるノードが上位層プロトコルから肯定的な確認を受信しない場合、このノードはユニキャスト近傍要請メッセージを送信します。このメッセージは、次のホップからの到達可能確認として近傍通知を要請します。不要なネットワークトラフィックを避けるため、ノードからアクティブにパケットが送信されている近傍にだけ探査メッセージが送信されます。

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

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

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

プロキシ通知

ターゲットアドレスの代わりにパケットを受信するルーターは、取り消しできない近傍通知を発行できる。ルーターは、近傍要請に応答できない宛先アドレスのかわりにパケットを受信する。現在はプロキシの使用方法は指定されていないが、オフリンクになった移動ノードをプロキシ通知で処理できる可能性がある。ただし、プロキシは、このプロトコルを実装していないノードを処理する一般的な機構として使用されることはない

入力負荷分散

インタフェースを複製したノードでは、同じリンク上の複数のネットワークインタフェース間の入力パケットの受信の負荷分散ができる。このようなノードには、同じインタフェースに複数のリンクローカルアドレスが割り当てられる。たとえば、1 つのネットワークドライバで、複数のネットワークインタフェースカードを、複数のリンクローカルアドレスを持つ 1 つの論理インタフェースとして表現できる。

負荷分散は、ルーターがソースリンクローカルアドレスをルーター広告パケットから省略することを可能にすることで処理する。結果として、近傍は近傍要請メッセージを使用して、ルーターのリンクローカルアドレスを確認する。返される近傍通知メッセージには、要請元によって異なるリンクローカルアドレスが含まれ る

リンクローカルアドレスの変更

リンクローカルアドレスの変更を認識したノードは、非要請近傍通知パケットをマルチキャストできる。ノードは、すべてのノードにパケットをマルチキャストして、無効になったキャッシュに入っているリンクローカルアドレスを更新できる。非要請通知の送信は、パフォーマンス強化が目的。近傍不到達検出アルゴリズムにより、すべてのノードが確実に新しいアドレスを探索できるが、遅延が多少伸びる可能性がある

近傍検索と ARP および関連する IPv4 プロトコルとの比較

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

次のリストは、近傍検索プロトコルと関連する IPv4 プロトコルセットを比較します。