メインコンテンツまでスキップ

5. Protocol Specification (プロトコル仕様)

自動設定は、マルチキャストをサポートするインターフェース上でインターフェースごとに実行されます。マルチホーム機では、自動設定は各インターフェース上で独立して実行されます。自動設定は主にホストを対象としていますが、2つの例外があります。ルーターは以下に概説される手順を使用してリンクローカルアドレスを生成することが期待されます。さらに、ルーターはインターフェースにすべてのアドレスを割り当てる前に、すべてのアドレスに対して重複アドレス検出を実行します。

5.1. Node Configuration Variables (ノード設定変数)​

ノードは、マルチキャストをサポートする各インターフェースに対して、システム管理により以下の自動設定関連変数を設定できるようにする必要があります (MUST):

DupAddrDetectTransmits - 暫定アドレスに対して重複アドレス検出を実行する際に送信される連続的な近隣要請メッセージの数。値がゼロの場合、暫定アドレスに対して重複アドレス検出を実行しないことを示します。値が1の場合、1回の送信を示し、後続の再送信はありません。

デフォルト値: 1。ただし、特定のリンクタイプ上でのIP伝送に関する問題をカバーするリンクタイプ固有のドキュメント内のリンクタイプ固有の値によって上書きされる可能性があります (例: [RFC2464])。

自動設定はまた、[RFC4861]で定義されている変数RetransTimerの存在を前提としています。自動設定の目的では、RetransTimerは重複アドレス検出中に実行される連続的な近隣要請送信間の遅延 (DupAddrDetectTransmitsが1より大きい場合)、およびノードが最後の近隣要請を送信した後、重複アドレス検出プロセスを終了するまでに待機する時間を指定します。

リンクローカルアドレスの形成と重複アドレス検出の使用以外に、ルーターがそのインターフェースを (自動的に) 設定する方法は、本ドキュメントの範囲外です。

ホストはアドレスのリストとそれに対応する有効期間を維持します。アドレスリストには、自動設定されたアドレスと手動で設定されたアドレスが含まれます。

ノードは、インターフェースが有効になるたびにリンクローカルアドレスを形成します。インターフェースは、以下のいずれかのイベントの後に有効になることがあります:

  • システム起動時にインターフェースが初期化される。
  • 一時的なインターフェース障害の後、またはシステム管理により一時的に無効にされた後、インターフェースが再初期化される。
  • インターフェースが最初にリンクに接続される。これには、無線ネットワークアクセスポイントの変更によって接続リンクが動的に変更される場合が含まれます。
  • 管理上無効にされた後、システム管理によってインターフェースが有効になる。

リンクローカルアドレスは、よく知られたリンクローカルプレフィックスFE80::0 [RFC4291] (適切な長さ) とインターフェース識別子を組み合わせることによって形成されます。以下のようになります:

  1. アドレスの最も左側の「プレフィックス長」ビットは、リンクローカルプレフィックスのビットです。
  2. リンクローカルプレフィックスの右側のアドレスのビットはすべてゼロに設定されます。
  3. インターフェース識別子の長さがNビットの場合、アドレスの最も右側のNビットがインターフェース識別子に置き換えられます。

リンクローカルプレフィックス長とNの合計が128より大きい場合、自動設定は失敗し、手動設定が必要です。インターフェース識別子の長さは、アドレスアーキテクチャ[RFC4291]とも一致する必要がある別個のリンクタイプ固有のドキュメントで定義されています (セクション2を参照)。これらのドキュメントでは、リンク上でリンクローカルアドレスを自動設定できるように長さを注意深く定義します。

リンクローカルアドレスは無限の優先および有効有効期間を持ちます。タイムアウトすることはありません。

5.4. Duplicate Address Detection (重複アドレス検出)​

すべてのユニキャストアドレスに対して、インターフェースに割り当てる前に重複アドレス検出を実行する必要があります (MUST)。これは、ステートレス自動設定、DHCPv6、または手動設定のいずれによって取得されたかにかかわらず適用されますが、以下の例外があります:

  • DupAddrDetectTransmits変数がゼロに設定されているインターフェースは、重複アドレス検出を実行しません。

  • 一意であることがわかっているユニキャストアドレス (例: ステートフル手動設定またはDHCPv6によって取得されたアドレスなど、重複を防ぐのに十分なメカニズムを使用して取得されたアドレス) は、重複アドレス検出を実行することができます (MAY) (ただし、必須ではありません (MUST NOT))。

  • インターフェースで最初の重複アドレス検出を実行する前に、インターフェースはマルチキャストメンバーシップ処理を実行してそのインターフェース上で近隣探索メッセージを受信し、All-Nodes multicast address および、検証中の各暫定アドレスに対するsolicited-node multicast addressに参加する必要があります (MUST)。

重複アドレス検出は、アドレスがインターフェースに割り当てられる前に実行されます。アドレスが重複していることが判明した場合、インターフェースに割り当てられません。したがって、実装は一意であることが検証されるまでアドレスを外部的に使用可能として扱うことを避ける必要があります。特に、ノードは暫定アドレスを使用して通常のトラフィックを送信してはなりません (MUST NOT)。アドレスがまだ暫定状態である間に送信される唯一の許可されるユニキャスト通信は、アドレスの一意性を検証するために重複アドレス検出自体が実行する近隣探索パケットです。

重複アドレス検出は実際には各アドレスごとに個別に実行されますが、複数のアドレスに対して同時に実行することができます (MAY)。アドレスが一意であることが判定されるまで、それは「暫定」状態にあると言われます。

5.4.1. Message Validation (メッセージ検証)​

重複アドレス検出の文脈では、ノードは以下の検証チェックを満たす近隣要請および近隣広告メッセージに興味を持ちます (詳細は [RFC4861] で指定されています):

  • [RFC4861] で指定されているすべての検証チェックを満たしていること。受信インターフェースでDupAddrDetectTransmits変数が実装されている場合は、その値がゼロでないこと。

  • ICMPチェックサム ([RFC4443]を参照) が有効であること。

  • IPホップ制限フィールドが値255 (つまり、パケットがパスに沿ってルーターによって転送されていないこと) を持つこと。

  • IPソースがリンクローカルアドレスであること。(リンクローカルソースアドレスは [RFC4861] によって検証されます。) さらに、IPソースは指定されていないアドレス (0:0:0:0:0:0:0:0) である場合があります (重複アドレス検出の文脈で議論されます)。

  • ターゲットアドレスが暫定アドレスであること。(暫定アドレスへの近隣要請 (NS) は重複アドレス検出が進行中であることを示し、暫定アドレスからのNSは別のノードも同じアドレスを暫定として使用していることを示します。)

  • すべての含まれるオプション (ソースリンク層アドレスオプションを含む) が [RFC4861] のオプション検証チェックを満たしていること。

ノードはルーターまたはホストのいずれかであり、異なる条件でリンクローカルアドレスを作成するため、それぞれについて重複アドレス検出手順が異なります。以下のセクションでは、各タイプのノードについて手順を説明します。

5.4.2. Sending Neighbor Solicitation Messages (近隣要請メッセージの送信)​

重複アドレス検出を実行する前に、インターフェースはAll-Nodes multicast address および、検証中の各暫定アドレスに対するsolicited-node multicast addressに結合する必要があります (MUST)。特定の暫定アドレスに対する重複アドレス検出を停止または中止する場合、そのアドレスに対するsolicited-node multicast addressからは離脱すべきです (SHOULD) (近隣探索、マルチキャストリスナー探索、またはその他の理由によって以前にそれに参加していない限り)。

暫定アドレスに対して重複アドレス検出を実行するには、ノードは一連のDupAddrDetectTransmits 近隣要請を送信します。前後の送信間の時間間隔はRetransTimerミリ秒です。

5.4.3. Receiving Neighbor Solicitation Messages (近隣要請メッセージの受信)​

受信時に、ノードは近隣要請のターゲットアドレスとソースアドレスが暫定アドレスと一致するかどうかを確認する必要があります (MUST)。一致する場合、近隣要請は重複アドレス検出が進行中のアドレスのためのものです。処理は、ターゲットアドレスまたはソースアドレスのいずれかが一致するかによって異なります。

ターゲットアドレスが暫定アドレスと一致する場合:

近隣要請のソースアドレスは、送信者のIPソースアドレスを指します。近隣要請のIPソースアドレスが指定されていないアドレス (0:0:0:0:0:0:0:0) の場合、ソースはそのアドレスに対して重複アドレス検出を実行しているため、近隣要請は重複アドレス検出によって送信されたものです。そうでない場合、ソースはそのアドレスをユニキャストアドレスとして使用しています。いずれの場合も、近隣要請は、ノードの暫定アドレスが重複していないことを検証しようとする近隣要請の送信者に示します。近隣要請はそのアドレスが重複していることを示しています。

そのような近隣要請を受信したノードは、近隣広告を送信してはなりません (MUST NOT) (そうしないと、そのアドレスは暫定であり、まだ使用すべきではないため (SHOULD NOT))。代わりに、そのような近隣要請の受信は、検証中の暫定アドレスが重複していることを示すため、近隣要請を送信するプロセスを直ちに停止する必要があります (MUST)。

ソースアドレスが暫定アドレスと一致する場合:

これは、別のノードも同じアドレスを暫定として使用しており、同時に重複アドレス検出を実行していることを示します。これは、複数のインターフェースが同時に初期化される場合 (例: システムブート時) に予想される現象です。ただし、この近隣要請の受信はアドレスが重複していることを示すため、ノードは近隣要請の送信を直ちに停止する必要があります (MUST)。

ノードは近隣探索が進行中である間に近隣要請を受信する可能性がありますが、重複が検出される前に送信をすでに停止している場合があります。この場合、近隣要請は無視されるべきです (SHOULD) (ただし、セクション5.4.4の場合を除く)。

5.4.4. Receiving Neighbor Advertisement Messages (近隣広告メッセージの受信)​

重複アドレス検出 (DAD) では、近隣要請のターゲットアドレスが暫定アドレスと一致するかどうか、および近隣広告のターゲットアドレスが暫定アドレスと一致するかどうかを確認する必要があります (MUST)。一致する場合、近隣広告はアドレスが重複していることを示します。一致しない場合、広告は無関係です。

暫定アドレスと一致するターゲットアドレスを持つ近隣広告の受信時に、ノードは近隣要請の送信を停止し (MUST)、そのアドレスがリンク上で使用されていることを検出します。

5.4.5. When Duplicate Address Detection Fails (重複アドレス検出が失敗した場合)​

上記のように重複していると判定された暫定アドレスは、インターフェースに割り当ててはなりません (MUST NOT)。ノードはシステム管理エラーをログに記録すべきです (SHOULD)。

アドレスが、一意に割り当てられるべきハードウェアアドレス (例: イーサネットインターフェースのEUI-64) に基づくインターフェース識別子から形成されたリンクローカルアドレスである場合、インターフェース上のIP操作を無効にすべきです (SHOULD)。IP操作を無効にすることで、ノードは:

  • インターフェースからIPパケットを送信しない、
  • インターフェースで受信したIPパケットをサイレントにドロップする、および
  • (ルーターとして動作する場合、またはルーティングヘッダーを持つパケットを処理する場合) インターフェースへIPパケットを転送しない。

この場合、IPアドレスの重複は重複したハードウェアアドレスが使用されていることを意味する可能性があり、別のIPアドレスを設定して回復を試みても、使用可能なネットワークにはなりません。実際には、インターフェース上のネットワーク操作を単に無効にするよりも診断が困難な問題を作成することで、状況を悪化させる可能性があります。ユーザーは、一部のことは機能するが他のことは機能しない部分的に機能するネットワークを見ることになります。

一方、重複したリンクローカルアドレスが、一意に割り当てられるべきハードウェアアドレスに基づくインターフェース識別子から形成されていない場合、インターフェース上のIP操作を継続することができます (MAY)。

注: セクション2で述べたように、上記の説明における「IP」は「IPv6」を意味します。ハードウェアアドレスに関する背景的な理論的根拠は特定のネットワークプロトコルに依存しませんが、他のプロトコルへの影響は本ドキュメントの範囲外です。

5.5. Creation of Global Addresses (グローバルアドレスの生成)​

グローバルアドレスは、適切な長さのプレフィックスにインターフェース識別子を付加することによって形成されます。プレフィックスは、ルーター広告に含まれるプレフィックス情報オプションから取得されます。このセクションで説明されているグローバルアドレスの生成は、ローカルで設定可能であるべきです (SHOULD)。ただし、以下で説明する処理はデフォルトで有効にする必要があります (MUST)。

5.5.1. Soliciting Router Advertisements (ルーター広告の要請)​

ルーター広告は、All-Nodesマルチキャストアドレスに定期的に送信されます。広告を迅速に取得するために、ホストは [RFC4861] で説明されているようにルーター要請を送信します。

5.5.2. Absence of Router Advertisements (ルーター広告の不在)​

リンク上にルーターがない場合でも、アドレスを取得するDHCPv6サービスが利用可能である可能性があり、ホストはそのサービスを使用したい場合があります。自動設定の観点から、少数のルーター要請を送信した後にルーター広告が受信されない場合 ([RFC4861] で説明されているように)、リンク上にルーターは存在しません。

この意味では、リンク上にルーターが存在しない可能性がありますが、パケットを転送する能力を持つノードが存在する場合があることに注意してください。この場合、リンク外パケットを送信するためには、転送ノードのアドレスをホストで手動で設定する必要があります。デフォルトルーターアドレスを自動設定する唯一のメカニズムはルーター広告のメカニズムであるためです。

5.5.3. Router Advertisement Processing (ルーター広告処理)​

ルーター広告内の各プレフィックス情報オプションに対して:

a) 自律フラグが設定されていない場合、プレフィックス情報オプションをサイレントに無視します。

b) プレフィックスがリンクローカルプレフィックスの場合、プレフィックス情報オプションをサイレントに無視します。

c) 優先有効期間が有効有効期間より大きい場合、プレフィックス情報オプションをサイレントに無視します。この場合、ノードはシステム管理エラーをログに記録したい場合があります (MAY)。

d) 広告されたプレフィックスが、インターフェースに関連付けられたアドレスリストにすでに存在するステートレス自動設定アドレスのプレフィックスと等しくなく (「等しい」とは、両方のプレフィックス長が同じで、プレフィックスのプレフィックス長ビットが同じであることを意味します)、有効有効期間がゼロでない場合、広告されたプレフィックスとリンクのインターフェース識別子を組み合わせることによってアドレスを形成し (リストに追加します)、以下のようになります:

|            128 - N bits               |       N bits           |
+---------------------------------------+------------------------+
|            link prefix                |  interface identifier  |
+----------------------------------------------------------------+

プレフィックス長とインターフェース識別子長の合計が128ビットに等しくない場合、プレフィックス情報オプションを無視する必要があります (MUST)。この場合、実装はシステム管理エラーをログに記録したい場合があります (MAY)。インターフェース識別子の長さは、アドレスアーキテクチャ[RFC4291]とも一致する必要がある別個のリンクタイプ固有のドキュメントで定義されています (セクション2を参照)。

ルーター広告に含まれるプレフィックスの長さが、そのリンクタイプのインターフェース識別子の長さと一致することを確認するのはシステム管理者の責任です。ただし、これは広告されたプレフィックス長が無意味であることを意味するものではないことに注意する必要があります。実際、広告された長さは [RFC4861] のリンク上決定に対して自明ではない意味を持ちます。プレフィックス長とインターフェース識別子長の合計は128に等しくない可能性があります。したがって、ここで広告されたプレフィックス長を検証して、アドレス自動設定のコンテキストで無効なプレフィックス長を指定する設定エラーを検出して回避することは安全であるべきです。

アドレスアーキテクチャ[RFC4291]の将来のバージョンと将来のリンクタイプ固有のドキュメント (それでもまだ互いに一致する) は、現在のドキュメントで定義されている値以外の長さのインターフェース識別子を許可する可能性があることに注意してください。したがって、実装は特定の定数を想定すべきではありません (SHOULD NOT)。代わりに、任意の長さのインターフェース識別子を期待すべきです。

アドレスが正常に形成され、まだリストにない場合、ホストはそれをインターフェースに割り当てられたアドレスのリストに追加し、プレフィックス情報オプションから優先および有効有効期間の値を初期化します。この手順の開始時にプレフィックスに対して実行される確認は、リスト内のアドレスの衝突を常に検出するわけではないことに注意してください。リストにすでに存在するアドレス (手動設定またはDHCPv6設定による) が新しく作成されたアドレスと偶然同じである可能性があります。これは非典型的な状況であるべきです。

e) 広告されたプレフィックスが、ステートレス自動設定によって設定されたリスト内のアドレスのプレフィックスと等しい場合、アドレスの優先有効期間は、受信した広告内の優先有効期間にリセットされます。アドレスの有効有効期間に対して実行される特定の操作は、受信した広告内の有効有効期間と、以前に自動設定されたアドレスの有効有効期間が切れるまでの残り時間に依存します。以下の議論では、残り時間を「RemainingLifetime」と呼びます:

  1. 受信した有効有効期間が2時間より大きい場合、またはRemainingLifetimeより大きい場合、対応するアドレスの有効有効期間を広告された有効有効期間に設定します。
  2. RemainingLifetimeが2時間以下の場合、有効有効期間に関するプレフィックス情報オプションを無視します。ただし、このオプションが取得されたルーター広告が認証されている場合 (例: Secure Neighbor Discovery [RFC3971]による) を除きます。ルーター広告が認証されている場合、対応するアドレスの有効有効期間を受信したオプション内の有効有効期間に設定すべきです (SHOULD)。
  3. それ以外の場合、対応するアドレスの有効有効期間を2時間にリセットします。

上記のルールは、偽造された広告が非常に短い有効有効期間を持つプレフィックスを含む可能性がある特定のサービス拒否攻撃に対処します。上記のルールがない場合、短い有効有効期間を持つ偽造されたプレフィックス情報オプションを含む単一の認証されていない広告によって、ノードのすべてのアドレスが早期に期限切れになる可能性があります。上記のルールは、正当な広告 (定期的に送信される) が短い有効有効期間が実際に有効になる前に「取り消す」ことを保証します。

対応するアドレスの優先有効期間は、有効有効期間がリセットされるか無視されるかにかかわらず、受信したプレフィックス情報オプション内の優先有効期間に常にリセットされることに注意してください。この違いは、優先有効期間に対する可能な攻撃が比較的些細なものであるという事実に由来します。さらに、有効な管理者が短い優先有効期間を送信して特定のアドレスを非推奨にしたい場合 (有効有効期間が誤って無視された場合)、優先有効期間を無視することさえ望ましくありません。

5.5.4. Address Lifetime Expiry (アドレス有効期間の満了)​

優先アドレスの優先有効期間が期限切れになると、優先アドレスは非推奨になります。非推奨アドレスは、既存の通信におけるソースアドレスとして使用し続けるべきです (SHOULD) が、十分なスコープの代替 (非推奨でない) アドレスが容易に使用できる場合、新しい通信を開始するために使用すべきではありません (SHOULD NOT)。

非推奨でないアドレスを使用して新しい通信を開始することの実現可能性は、アプリケーション固有の決定である可能性があることに注意してください。(現在) 非推奨のアドレスが (または依然として) アプリケーションによって使用されているかどうかを知ることができるのはアプリケーションのみである可能性があるためです。たとえば、アプリケーションが明示的にプロトコルスタックに非推奨アドレスをソースアドレスとして使用するように指定した場合、プロトコルスタックはそれを受け入れる必要があります。アプリケーションがそれを要求する可能性があるのは、そのIPアドレスが上位レベルの通信で使用されており、そのようなパケット内の複数の接続が同じIPアドレスペアを使用することが要求される可能性があるためです。

IPおよび上位層 (例: TCP、UDP) は、非推奨アドレスに送信されたデータグラムを引き続き受け入れて処理する必要があります (MUST)。非推奨アドレスはインターフェースの有効なアドレスであるためです。TCPの場合、これは、非推奨アドレスに送信されたTCP SYNセグメントに対して、対応するSYN-ACK内のソースアドレスとして非推奨アドレスを使用して応答することを意味します (その接続が許可される場合)。

実装は、新しい通信が非推奨アドレスを使用することを禁止することができます (MAY) が、システム管理はそのような機能を無効にする能力を持つ必要があり (MUST)、その機能はデフォルトで無効にする必要があります (MUST)。

ソースアドレス選択の他の微妙なケースにも注意する必要があります。たとえば、上記の説明では、非推奨のより小さいスコープのアドレスと非推奨でない十分なスコープのアドレスの間でどちらのアドレスを使用すべきかを明確にしていません。このケースを含むアドレス選択の詳細は [RFC3484] で説明されており、本ドキュメントの範囲外です。

アドレス (およびインターフェースとの関連付け) の有効有効期間が期限切れになると、アドレスは無効になります。無効アドレスは、アウトバウンド通信におけるソースアドレスとして使用してはならず (MUST NOT)、受信インターフェース上で宛先として認識されてはなりません (MUST NOT)。

5.6. Configuration Consistency (設定の一貫性)​

ホストは、ステートレス自動設定とDHCPv6の両方を同時に使用してアドレス情報を取得することができます。両方とも同時に有効にできるためです。他の設定パラメータ (MTUサイズやホップ制限など) の値も、ルーター広告とDHCPv6から学習される可能性があります。同じ設定情報が複数のソースから提供される場合、この情報の値は一貫しているべきです。ただし、複数のソースから受信した情報に一貫性がない場合、致命的なエラーとは見なされません。ホストは、近隣探索とDHCPv6を通じて受信したすべての情報の和集合を受け入れます。

異なるソースから一貫性のない情報が学習された場合、実装は、保護なしで学習された情報よりも安全に学習された情報を優先したい場合があります。たとえば、[RFC3971] のセクション8では、Secure Neighbor Discoveryを通じて学習された情報と通常の近隣探索を通じて学習された情報が競合する場合の処理方法について説明しています。同じ議論は、通常の近隣探索を通じて学習された情報とセキュアDHCPv6を通じて学習された情報の間の優先順位などにも適用できます。

いずれの場合も、セキュリティの違いがない場合、最近取得された値は、以前に学習された情報よりも優先されるべきです (SHOULD)。

5.7. Retaining Configured Addresses for Stability (安定性のために設定されたアドレスを保持する)​

安定したストレージを持つ実装は、ステートレスアドレス自動設定を使用してアドレスを取得する際に、ストレージ内にアドレスを保持したい場合があります。使用される有効期間が合理的であると仮定すると、この手法は、ルーターの一時的な中断 (有効有効期間未満) がノードのグローバルアドレスの喪失を決して引き起こさないことを意味します。ノードが再起動する場合でもです。この手法を使用する場合、優先および有効有効期間の有効期限も保持する必要があることにも注意する必要があります。これにより、アドレスが非推奨または無効になった後にアドレスが使用されることを防ぎます。

この拡張に関する詳細は、本ドキュメントの範囲外です。

に最終更新