RFC 9568: IPv4及びIPv6用仮想ルータ冗長プロトコル(VRRP)バージョン3

要旨

本文書は、IPv4及びIPv6における仮想ルータ冗長プロトコル(VRRP)のバージョン3を定義する。この文書は、前のVRRP(バージョン3)を規定していたRFC 5798を廃止する。RFC 5798は、IPv4のVRRP(バージョン2)を規定したRFC 3768を廃止した。VRRPは、LAN上のVRRPルータの1つに仮想ルータの責務を動的に割り当てる選出プロトコルを規定する。仮想ルータで使用するIPv4またはIPv6アドレスを制御するVRRPルータはアクティブ・ルータと呼ばれ、このIPv4またはIPv6アドレスにルーティングされたパケットを転送する。アクティブ・ルータは仮想IPv4またはIPv6アドレスが設定され、バックアップ・ルータはIPプロトコル・バージョンに基づいて広告される仮想アドレスのアドレスファミリーを推測する。VRRPルータ内では、IPv4及びIPv6の各アドレスファミリーの仮想ルータは互いに独立しており、常に別々の仮想ルータ・インスタンスとして扱われる。アクティブ・ルータが使用できなくなると、選出プロセスによって転送責務の動的フェイルオーバーを提供する。IPv4の場合、VRRPを使用することで得られるメリットは、すべてのエンドホストで動的ルーティングやルータ検出プロトコルを設定することなく、より可用性の高いデフォルト・パスを実現できることである。IPv6の場合、IPv6用のVRRPを使用することで得られるメリットは、標準のIPv6近隣探索メカニズムよりもバックアップ・ルータへの切り替えが速いことである。

本文書の位置付け

本文書は、インターネット標準化過程の文書である。

この文書はInternet Engineering Task Force (IETF)の成果物である。IETFコミュニティのコンセンサスを表すものである。公開レビューを受けており、Internet Engineering Steering Group (IESG)によって公開が承認されている。インターネット標準の詳細については、RFC 7841のセクション 2を参照のこと。

本文書の現在のステータス、正誤表、および文書に対するフィードバックの提供方法に関する情報は、<https://www.rfc-editor.org/info/rfc9568>で入手できる。

著作権表示

Copyright (c) 2024 IETFトラストおよび文書の著者として特定された人物。無断転載を禁じる。

本文書は、BCP 78および文書の発行日において有効なIETF文書に関するIETFトラストの法的規定(<https://trustee.ietf.org/license-info>)に従うものとする。これらの文書には、本文書に関するあなたの権利と制限が記載されているため、注意深く確認して欲しい。文書から抽出されたコード・コンポーネントには、トラスト法的条項のセクション4.eに記載されている改訂BSDライセンスのテキストを含まなければならず、改訂BSDライセンスに記載されているように保証なしで提供する。

1. はじめに

本文書は、IPv4及びIPv6における仮想ルータ冗長プロトコル(VRRP)のバージョン3を定義する。本文書は、前にVRRP(バージョン3)を規定していた[RFC5798]を廃止するものである。[RFC5798]は、IPv4用のVRRP(バージョン2)を指定した[RFC3768]を廃止したものである。VRRPは、仮想ルータ(セクション1.7を参照)の責務をLAN上のVRRPルータのいずれかに動的に割り当てる選出プロトコルを規定する。仮想ルータで使用するIPv4またはIPv6アドレスを制御するVRRPルータをアクティブ・ルータと呼び、これらのIPv4またはIPv6アドレス宛にルーティングされたパケットを転送する(セクション8.3.1で説明するこれらのアドレス宛のパケットを除く)。VRRPアクティブ・ルータには仮想IPv4またはIPv6アドレスを設定し、バックアップ・ルータはIPプロトコルのバージョンに基づいて広告される仮想アドレスのアドレスファミリーを推測する。VRRPルータ内では、IPv4とIPv6アドレスファミリーのそれぞれの仮想ルータは互いに独立しており、常に別個の仮想ルータ・インスタンスとして扱われる。アクティブ・ルータが使用できなくなった場合、選出プロセスによって転送責務の動的フェイルオーバーを提供する。

VRRPは、プロプライエタリ・プロトコルのホット・スタンバイ・ルータ・プロトコル(HSRP) [RFC2281]やIPスタンバイ・プロトコル [IPSTB]と同様の機能を提供する。

1.1. RFC 5798との差異

[RFC5798]から次の変更が加えられています。

1. VRRPの用語は、IETF技術の包括的言語ガイドラインに準拠するよう更新した。IETFは、国立標準技術研究所(NIST)の文書「Guidance for NIST Staff on Using Inclusive Language in Documentary Standards」(ドキュメント標準における包括的言語の使用に関するNISTスタッフ向けのガイダンス)[NISTIR8366]を包括的言語ガイドラインに指定している。

2. IETFの包括的用語と整合させるため、転送責務を負うVRRPルータの用語を、「アクティブ・ルータ」に変更した。さらに、[RFC5798]の「アクティブ・ルータ」と「バックアップ・ルータ」という用語の不整合を修正した。さらに、到達不能なパケットを引き付け(attracting)、破棄するという好ましくない用語を変更した。

3. セクション6のステートマシンに関する正誤表を修正した。

4. セクション5.2.8のチェックサム計算は、何が含まれるかを正確に規定し、IPv4の疑似ヘッダを含まないことを明確にした。

5. 優先度の低いVRRPルータからVRRP広告を受信した場合、アクティブVRRPルータは直ちにVRRP広告を送信し、学習ブリッジがパケットを正しいイーサネット・セグメントにブリッジすることを保証する(セクション6.4.3を参照)。

6. レガシー技術(FDDI、トークンリング、ATM LANエミュレーションなど)上の動作について説明した付録を削除した。

7. IPv6の自発的近隣広告(Unsolicited Neighbor Advertisements)はアクティブ・ルータとバックアップ・ルータが受け入れる必要がある(SHOULD)という推奨事項を追加した(セクション8.2.4 )。

   Unsolicited Neighbor Advertisementsの訳は、自発的近隣広告でいいのか?

8. 最大広告間隔が一致していることを確認することが推奨されるが、これによってVRRPパケットが破棄されることはない(セクション7.1)。

9. 読みやすくするため、編集上のさまざまな変更が加えた。

10. IPv4/IPv6マルチキャスト・アドレスの割り当てとイーサネットのメディア・アクセス・コントロール (MAC)アドレスの割り当てをすべて含めるために、IANAの考慮事項セクションを拡張した。

1.2. 用語についての注意

本文書では、IPv4とIPv6の運用について説明するが、VRRPプロトコルに関しては多くの説明と手順が共通している。本文書では、「IP」を「IPv4またはIPv6」のいずれかを意味するように記述した方が冗長な表現にはならない。しかし、歴史的には、「IP」という用語はIPv4を指すことが多い。そのため、本仕様では、「IPv4」または「IPv6」のいずれかを意味する「IPvX」(Xは4または6)という用語を導入する。本文書では、IPバージョンが重要な場合は適切な用語が使用し、「IP」という用語の使用を避ける。

1.3. IPv4

IPv4エンドホストが特定のIPv4宛先のファースト・ホップ・ルータを決定するために使用できる方法はいくつかある。これには、ルーティング・インフォメーション・プロトコル(RIP) [RFC2453]やOSPFバージョン2 [RFC2328]などの動的ルーティング・プロトコルを実行する(またはスヌーピング)、ICMPルータ検出クライアント[RFC1256]を実行する、DHCPv4 [RFC2131]を実行する、または静的に設定されたデフォルト経路を使用する、などがある。

すべてのエンドホスト上で動的ルーティング・プロトコルを実行することは、管理上のオーバーヘッド、処理上のオーバーヘッド、セキュリティ上の問題、特定のプラットフォーム用の実装がないなど、さまざまな理由から実現不可能かも知れない。近隣またはルータ検出プロトコルは、ネットワーク上のすべてのホストの積極的な参加を必要とし、各ホストのプロトコル・パケット処理に関連するプロトコル・オーバーヘッドを削減するために、大きなタイマー値を必要とする。その結果、到達不能なルータを検出するのに大幅な遅延が生じる可能性があり、そのような遅延は、デフォルト経路に対して許容できないほど長い到達不能期間をもたらすかも知れない。

手動で設定されたデフォルト経路(スタティック経路またはDHCPv4経由)の使用は、エンドホストでの設定と処理のオーバーヘッドを最小限に抑えることができ、事実上すべてのIPv4実装でサポートしているため、非常に一般的である。しかし、これにより単一障害点が発生する。デフォルト経路が失われると、利用可能な代替パスを検出できないすべてのエンドホストが孤立し、壊滅的な事態が起こる。

仮想ルータ冗長プロトコル (VRRP)は、デフォルト・ルーティングを使用するネットワークに固有の単一障害点を排除するよう設計されている。VRRPは、LAN上のVRRPルータの1つに仮想ルータの責務を動的に割り当てる選出プロトコルを規定する。仮想ルータで使用するIPv4アドレスを制御するVRRPルータはアクティブ・ルータと呼び、これらのIPv4アドレスに送信されたパケットを転送する。選出プロセスは、アクティブ・ルータが使用できなくなった場合の転送責務の動的なフェイルオーバーを提供する。LAN上の仮想ルータのIPv4アドレスはどれも、エンドホストがデフォルトのファースト・ホップ・ルータとして使用できる。VRRPを使用するメリットは、すべてのエンドホストで動的ルーティングやルータ検出プロトコルの設定を必要とせず、可用性の高いデフォルト・パスが得られることである。

1.4. IPv6

LAN上のIPv6ホストは通常、IPv6近隣探索(ND)プロトコル[RFC4861]を使用して送信されるルータ広告を受信することで、1つ以上のデフォルト・ルータを学習する。ルータ広告は、ホストがLAN上のデフォルト・ルータを学習するのに10秒以上かかるようなレートで定期的にマルチキャストされる。ルータ広告は、ルータの障害を検出するために、ルータ広告がないことに依存できるほどには頻繁に送信されない。

NDプロトコルには、近隣ノード(ルータまたはホスト)または近隣ノードへの転送パスの障害を検出するための、近隣到達不能検出と呼ばれるメカニズムが含まれている。これは、ユニキャストND近隣要請メッセージを近隣ノードに送信することで行われる。近隣要請を送信するオーバーヘッドを軽減するため、近隣要請はノードがアクティブにトラフィックを送信している近隣ノードにのみ送信され、ルータが一定期間稼働しているという明確な兆候がなくなった後にのみ送信される。NDのデフォルト・パラメータを使用すると、ホストがルータに到達できないことを認識し、別のデフォルト・ルータに切り替わるまでに10秒以上かかることがある。この遅延はユーザにとって非常に重大で、トランスポート・プロトコルの実装によってはタイムアウトの原因となる。

近隣到達不能検出は、タイマー間隔をよりアグレッシブに設定することでより速く行うことができるが(現在の下限は5秒であることに留意する)、これは特に、多くのホストが1つ以上のルータの到達可能性を判断しようとしている場合、NDトラフィックのオーバーヘッドが大幅に増加するという欠点がある。

IPv6の仮想ルータ冗長プロトコルは、標準的なND手順を使用するよりもはるかに高速な代替デフォルト・ルータへの切り替えを提供する。VRRPを使用すると、障害が発生したデフォルト・ルータをバックアップ・ルータが約3秒以内に引き継ぐことができる(VRRPのデフォルト・パラメータを使用)。これは、ホストとのやり取りなく、最小限のVRRPトラフィックで実行できる。

1.5. 要件言語

この文書のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すように、すべて大文字で表示される場合に限り、 BCP 14 [RFC2119] [RFC8174]の記述に従って解釈される。

1.6. 範囲

本文書の残りの部分では、VRRPの機能、設計目標、動作理論について説明する。単一のアクティブ・ルータへの収束を保証するメッセージ・フォーマット、プロトコル処理ルール、ステートマシンについて説明する。最後に、MACアドレス・マッピング、ARPメッセージの処理、ICMPリダイレクト・メッセージの生成、セキュリティに関する運用上の問題を取り上げる。

1.7. 定義

VRRPルータ
仮想ルータ冗長プロトコルを実行しているルータ。1つ以上の仮想ルータとして参加することができる。

仮想ルータ
VRRPが管理する抽象オブジェクト。共有LAN上のホストのデフォルト・ルータとして機能する。これは、仮想ルータ識別子と、共通LAN上の関連するIPv4アドレス・セットまたはIPv6アドレス・セットで構成される。VRRPルータは、1つ以上の仮想ルータのバックアップ・ルータとして機能する。

仮想ルータ識別子
LAN上の仮想ルータのインスタンスを識別する整数値(1～255)。その頭字語とってVRIDと呼ばれる。

仮想ルータのMACアドレス
VRIDのVRRP広告に使用するマルチキャストのイーサネットMACアドレス。セクション7.3を参照。

IPアドレス保有者
仮想ルータのIPvXアドレスを実インタフェース・アドレスとして持つVRRPルータ。このルータが稼働時、ICMP pingやTCPコネクション要求など、これらのIPvXアドレス宛てのパケットに応答する。

プライマリIPアドレス
IPv4における、実インタフェース・アドレス・セットから選出されるIPv4アドレス。考えられる選出アルゴリズムの1つは、常に先頭のアドレスを選択する。IPv4では、常にプライマリIPv4アドレスをIPv4パケットの送信元としてVRRP広告は使用する。IPv6では、パケットが送信されるインタフェースのリンクローカル・アドレスを使用する。

転送責務
仮想ルータで使用するIPvXアドレスに送られたパケットを転送する責務。これには、仮想ルータのMACアドレスに送られたパケットの受信、ローカルのルーティング情報ベース (RIB)/転送情報ベース (FIB)に基づいたパケットの転送、IPv4アドレスに対するARP要求への応答、IPv6アドレスに対するND要求への応答が含まれる。

アクティブ・ルータ
仮想ルータで使用するIPvXアドレスに送られたパケットの転送、IPv4アドレスに対するARP要求への応答、IPv6アドレスに対するND要求に応答する役割を担うVRRPルータ。IPvXアドレスの所有者が利用可能な場合、そのIPvXアドレスの所有者が常にアクティブ・ルータになることに留意する。

バックアップ・ルータ
現在のアクティブ・ルータに障害が発生した場合に、仮想ルータの転送責務を引き受けるために利用できるVRRPルータ・セット。

ドロップ経路
ルーティング情報ベース(RIB)にインストールされた経路で、その経路に一致する送信先アドレスを持つトラフィックがドロップされることになる。

2. 必須機能

このセクションでは、必須と考えられ、VRRPの設計の指針となった機能について説明する。

2.1. IPvXアドレスのバックアップ

IPvXアドレスのバックアップはVRRPの主要機能である。アクティブ・ルータの選出と後に説明する追加機能を提供する場合、プロトコルは以下を行う必要がある:

• 到達不能時間を最小限に抑える
• 定常状態の帯域幅のオーバーヘッドと処理の複雑さを最小限に抑える
• IPvXトラフィックをサポートできるさまざまなマルチアクセスLANテクノロジー上で機能する
• 負荷分散のためにネットワーク上で複数の仮想ルータを使用できる
• 単一のLANセグメント上で複数の論理IPvXサブネットをサポートする

2.2. 優先パスの表示

冗長ルータ間のアクティブ・ルータ選択の単純なモデルは、各ルータを等しく優先的に扱い、任意のルータをアクティブ・ルータとして収束した後に勝利を主張することである。しかし、冗長ルータ間で明確な優先順位(または優先順位の範囲)が存在する環境も多く存在する。例えば、この優先順位は、アクセスリンクのコストや速度、ルータのパフォーマンスや信頼性、または他のポリシーの考慮事項に基づく場合がある。このプロトコルは、この相対パスの優先順位を直感的な方法で表現できるようにし、アクティブ・ルータが現在利用可能な最も優先度の高い仮想ルータに収束することを保証する必要がある。

2.3. 不必要なサービスの中断を最小限に抑える

アクティブルータの選出が実行されると、アクティブ・ルータとバックアップ・ルータの間で不必要な遷移が発生し、サービスの中断につながる可能性がある。プロトコルは、アクティブ・ルータの選出後、アクティブ・ルータが適切に機能し続ける限り、同等またはそれ以下の優先順位を持つバックアップ・ルータによって遷移がトリガーされないことを保証する必要がある。

環境によっては、現在のアクティブ・ルータよりも優先されるルータが使用可能になったときにトリガーされる遷移を回避することが有益な場合もある。優先パスへの即時復元のオーバーライドをサポートすると役立つかも知れない。

2.4. 拡張LANでの効率的な運用

マルチアクセスLANでIPvXパケットを送信するには、つまりIPv4またはIPv6をいずれかを送信するには、IPvXアドレスからMACアドレスへのマッピングが必要である。学習ブリッジを使用する拡張LANで仮想ルータのMACアドレスを使用すると、仮想ルータに送信されるパケットの帯域幅オーバーヘッドに大きな影響を与える可能性がある。仮想ルータのMACアドレスがリンクレベルのフレームの送信元アドレスとして使用されることがない場合、MACアドレスの位置が学習されることはないため、仮想ルータに送信されるすべてのパケットがフラッディングが発生する。この環境での効率を改善するために、プロトコルは以下のことを行う必要がある:

1. MAC学習をトリガーするために、アクティブ・ルータから送信されるパケットの送信元として仮想ルータのMACアドレスを使用する。
2. MAC学習を更新するために、アクティブ・ルータに移行した直後にメッセージをトリガーする。
3. MACアドレス・キャッシュを維持するために、アクティブ・ルータから定期的なメッセージをトリガーする。

2.5. IPv4とIPv6の1秒未満の動作

IPv4とIPv6の両方の環境で、アクティブ・ルータの障害を1秒以内に検出する必要がある。以前の研究では、1秒未満の動作はIPv6向けで提案されており、この仕様は、IPv4とIPv6の両方について、前のアプローチを活用している。

短い広告間隔(セクション6.1を参照)を使用した場合に起こりうる問題のシナリオの1つは、VRRPルータが送信できるパケット数以上のパケットを発出し、VRRPルータにキューが溜まってしまうことが考えられる。これが発生すると、VRRPの対象となるLAN(VRRP-protected LAN)に送信されるパケットで、最小の広告間隔よりも大きなキュー遅延が発生する可能性がある。この場合、アクティブ・ダウン間隔(セクション6.1を参照)は通常のキュー遅延によってバックアップ・ルータがアクティブ・ルータがダウンしていると判断し、自身をアクティブ・ルータに昇格させるのに十分なほど短くなる可能性がある。その直後、元のアクティブ・ルータからのVRRPパケットの遅延により、VRRPルータはバックアップ・ルータに切り替わる。さらに、このプロセスは1秒間に何度も繰り返されるため、トラフィックに重大な中断を引き起こす可能性がある。この問題を軽減するためには、VRRPパケットをエグレス・インタフェースのキューに優先順位を考慮する必要がある。もし、アクティブ・ルータがこの現象が発生していることを確認した場合、その問題をログに記録すべきである(レート制限の対象となる)。

3. VRRPの概要

VRRPは、前述した仮想ルータ機能を提供するための選出プロトコルを規定する。プロトコルのメッセージングはすべて、IPv4またはIPv6のマルチキャスト・データグラムを使用して行われる。したがって、このプロトコルは、IPvXマルチキャストをサポートするさまざまなマルチアクセスLANテクノロジー上で動作できる。VRRP仮想ルータの各リンクには、単一の既知のMACアドレスが割り当てられている。本文書では現在、IEEE 802の48ビットMACアドレスを使用するネットワークへのマッピングついてのみを詳細に説明している。仮想ルータのMACアドレスは、拡張LAN上のレイヤ2(L2)ブリッジによるMAC学習を有効にするために、アクティブ・ルータから送信されるすべての定期的なVRRPメッセージの送信元として使用される。

仮想ルータは、仮想ルータ識別子(VRID)とIPv4またはIPv6アドレスのセットによって定義される。VRRPルータは、インタフェースの実アドレスと仮想ルータを関連付けることができる。各仮想ルータの範囲は、単一のLANに限定される。VRRPルータは、追加の仮想ルータ・マッピングとバックアップする仮想ルータの優先順位を設定できる。VRIDとそのIPvXアドレスのマッピングは、LAN上のすべてのVRRPルータ間で調整する必要がある。

異なるLANで異なるアドレス・マッピングのVRIDを再利用することに制限はない。また、IPv4アドレスとIPv6アドレスに同じVRID番号を使用することに対する制限もない。ただし、これらは2つの異なる仮想ルータである。

ネットワーク・トラフィックを最小限に抑えるために、各仮想ルータのアクティブ・ルータのみが定期的にVRRP広告メッセージを送信する。バックアップ・ルータは優先度が高くない限り、アクティブ・ルータをプリエンプトしようとしない。このため、より優先度の高いパスが利用可能にならない限り、サービスの中断は発生しない。アクティブ・ルータのプリエンプション試行を管理者によって禁止することもできる。唯一の例外は、VRRPルータが所有するアドレスに関連付けられた仮想ルータの常にアクティブ・ルータになることである。アクティブ・ルータが使用できなくなった場合、最も優先度の高いバックアップ・ルータが短い遅延の後にアクティブ・ルータに移行し、サービスの中断を最小限に抑えながら仮想ルータの責務を制御された状態で移行する。

VRRPプロトコルの設計は、バックアップ・ルータからアクティブ・ルータへの迅速な移行を実現し、サービスの中断を最小限に抑えると共に、一般的な運用シナリオで制御されたアクティブ・ルータへの移行を保証しながらプロトコルの複雑さを軽減する最適化を組み込んでいる。これらの最適化により、最小限のランタイム状態要件、最小限のアクティブなプロトコル状態、単一のメッセージ・タイプと送信者を持つ選出プロトコルが実現されている。典型的な運用シナリオは、2つの冗長ルータおよび/または各ルータの明確なパス優先を定義している。これらの前提に反した場合、つまり、同じ優先順位を持つ2つ以上の冗長パスが存在する場合の副次的影響は、アクティブ・ルータの選出中に短期間、重複パケットが転送される可能性があることである。しかし、一般的なシナリオを想定すると、導入の大部分をカバーする可能性が高く、アクティブ・ルータの損失はほとんどなく、アクティブ・ルータの選択の収束にかかる予想時間は非常に短い(デフォルトの広告間隔を使用した場合は4秒未満、設定では1/25秒未満)。このように、VRRPの最適化は、プロトコル設計の大幅な簡素化を意味するが、短時間のネットワーク中断の可能性はごくわずかである。

4. サンプルVRRPネットワーク

4.1. サンプルVRRPネットワーク1

VRRPルータ2台で1台の仮想ルータを実装したシンプルなネットワークを以下の図に示す。

図1: VRRPネットワークのサンプル1

IPv4の場合、つまり、図ではIPvXがすべてIPv4の場合、各ルータにはLANインタフェース上のIPv4アドレスが恒久的に割り当てられ(Router-1にはIPv4 Aが、ルータ2にはIPv4 Bが割り当てられる)、各ホストはいずれかのルータを経由するデフォルト経路(DHCPv4で学習した経路、または設定された静的経路)をインストールする(この例では、すべてホストがRouter-1のIPv4 Aを使用する)。

IPv6の場合、つまり、図ではIPvXがすべてIPv6の場合、各ルータはLANインタフェースに独自のリンクローカルIPv6アドレスを持ち、VRIDごとにリンクローカルIPv6アドレスを持ち、同じVRIDを提供する他のルータと共有する。各ホストは、ルータ広告からいずれかのルータを経由してデフォルト経路を学習する(この例では、すべてRouter-1のIPv6 Link-Local Aを使用する)。

IPv4 VRRP環境では、各ルータはまったく同じIPv4アドレスの受信と送信をサポートする。Router-1はIPv4 AのIPv4アドレス保有者であり、Router-2はIPv4 BのIPv4アドレスの保有者である。そして、Router-1が所有するアドレスに一意の識別子(VRID)を関連付けることで、仮想ルータが定義される。

IPv6 VRRP環境では、各ルータはVRIDに関連付けられたIPv6アドレスの送受信をサポートする。Router-1はIPv6 AのIPv6アドレス保有者、Router-2がIPv6 BのIPv6アドレス保有者である。そしてRouter-1 が所有するアドレスに一意の識別子(VRID)を関連付けることによって、仮想ルータを定義する。

最後に、IPv4とIPv6の両方のケースで、VRRPプロトコルはバックアップ・ルータへの仮想ルータのフェイルオーバーを管理する。

上のIPvXの例では、Router-1が所有するIPvXアドレス(VRID=1、IPvX_Address=A)をカバーするように仮想ルータを設定している。VRID=1のRouter-1でVRRPを有効にすると、Router-1が仮想ルータのIPvXアドレスの保有者であるため、優先度=255のアクティブ・ルータとしてアサートされる。VRID=1のRouter-2でVRRPを有効にすると、IPvXアドレスの保有者ではないため、優先度=100(デフォルトの優先度は100)のバックアップ・ルータに移行する。Router-1に障害が発生した場合、VRRPプロトコルはRouter-2をアクティブ・ルータに移行し、IPvX Aの転送責務を一時的に引き継いで、ホストに中断のないサービスを提供する。

この例では、どちらの場合も、IPvX Bはバックアップされず、Router-2がそのインタフェース・アドレスとして使用しているだけであることに留意する。IPvX Bをバックアップするには、2番目の仮想ルータを設定する必要がある。これについては次のセクションで説明する。

4.2.サンプルVRRPネットワーク2

以下の図は、2台の仮想ルータでホストがトラフィックを分割する構成を示す。

図2: サンプルVRRP ネットワーク2

上記のIPv4の例では、図中のIPvXがすべてIPv4の場合、ホストの半分がRouter-1のIPv4 Aを経由して静的デフォルト経路を設定し、残りの半分はRouter-2のIPv4 Bを使用している。仮想ルータVRID=1の設定は最初の例とまったく同じであり(セクション4.1を参照)、Router-2が持つIPv4アドレス (VRID=2、IPv4_Address=B)をカバーするために2番目の仮想ルータを追加している。この場合、Router-2はVRID=2のアクティブ・ルータとして動作し、Router-1はバックアップ・ルータとして動作する。このシナリオは、両方のルータが利用可能な場合に負荷分割を提供する展開を示すと同時に、堅牢性のために完全な冗長性を提供する。

上記のIPv6の例では、図中のIPvXがすべてIPv6の場合、ホストの半分はRouter-1の IPv6 Aを経由するデフォルト経路を使用し、残りのホストはRouter-2のIPv6 Bを使用している。仮想ルータVRID=1の設定は最初の例とまったく同じであり(セクション4.1を参照)、Router-2が所有するIPv6アドレス(VRID=2、IPv6_Address=B)をカバーするために2番目の仮想ルータを追加している。この場合、Router-2はVRID=2のアクティブ・ルータとして動作し、Router-1はバックアップ・ルータとして動作する。このシナリオは、両方のルータが利用可能な場合に負荷分割を提供する展開を示すと同時に、堅牢性のための完全な冗長性を提供する。

負荷分散の詳細は本文書の範囲外であることに留意する。しかし、サーバが異なる重み付けを必要とする場合、ルータ間のホスト・トラフィックのバランスを取るためにルータ広告だけに頼るのは意味がない[RFC4311]。

5. プロトコル

VRRP広告の目的は、VRIDに関連付けられたアクティブ・ルータの優先度、最大広告間隔、IPvXアドレスをすべてのVRRPルータに伝達することにある。

VRRPはIPv4アドレスが対象の場合、VRRPパケットはIPv4パケットにカプセル化して送信する。VRRPに割り当てられたIPv4マルチキャスト・アドレスに送信される。

VRRPはIPv6アドレスが対象の場合、VRRPパケットはIPv6パケットにカプセル化して送信する。VRRPに割り当てられたIPv6マルチキャスト・アドレスに送信する。

5.1. VRRPパケット・フォーマット

このセクションでは、VRRPパケットのフォーマットと、IPvXヘッダの関連フィールド (アドレスファミリーと関連)を定義する。

図3: IPv4/IPv6 VRRP広告パケットのフォーマット

5.1.1. IPv4フィールドの説明

5.1.1.1.送信元アドレス

パケットの送信元インタフェースのプライマリIPv4アドレス。

5.1.1.2.送信先アドレス

IANAがVRRPに割り当てられたIPv4マルチキャスト・アドレスはは以下のとおり:

224.0.0.18

これは、リンクローカル・スコープのマルチキャスト・アドレスである。ルータは、TTLに関係なく、この送信先アドレスのデータグラムを転送してはならない(MUST NOT)。

5.1.1.3. TTL

TTLは255に設定しなければならない(MUST)。TTLが255以外のパケットを受信したVRRPルータは、そのパケットを破棄しなければならない(MUST)[RFC5082]。

5.1.1.4.プロトコル

IANAがVRRPに割り当てたIPv4プロトコル番号は112 (10進数)である。

5.1.2. IPv6フィールドの説明

5.1.2.1.送信元アドレス

パケットの送信元インタフェースのIPv6リンクローカル・アドレスである。

5.1.2.2. 送信先アドレス

IANAがVRRPに割り当てたIPv6マルチキャスト・アドレスは以下のとおり:

ff02:0:0:0:0:0:0:12

これは、リンクローカル・スコープのマルチキャスト・アドレスである。ルータは、ホップ制限に関係なく、この送信先アドレスを持つデータグラムを転送してはならない(MUST NOT) 。

5.1.2.3.ホップ制限

ホップ制限は255に設定しなければならない(MUST)。ホップ制限が255ではないパケットを受信したVRRPルータは、そのパケットを破棄しなければならない(MUST)[RFC5082]。

5.1.2.4.次のヘッダー

IANAがVRRPに割り当てたIPv6 Next Headerプロトコルは112(10進数)である。

5.2. VRRPフィールドの説明

5.2.1.バージョン

バージョン・フィールドは、このパケットのVRRPプロトコルのバージョンを示す。本文書はバージョン3を定義する。

5.2.2.タイプ

タイプ・フィールドは、VRRPパケットのタイプを指定する。このバージョンのプロトコルで定義する唯一のパケット・タイプは以下のとおり:

1 - ADVERTISEMENT(広告)

タイプが不明なパケットは破棄しなければならない(MUST)。

5.2.3.仮想ルータID (VRID)

仮想ルータIDフィールドは、このパケットがステータスを報告している仮想ルータを識別する。

5.2.4. 優先度

優先度フィールドは、VRRPルータの仮想ルータに対する優先度を送信することを指定する。値が大きいほど優先度が高いことを示す。このフィールドは8ビットの符号なし整数フィールドである。

仮想ルータで使用するIPvXアドレスを所有するVRRPルータの優先度の値は255(10進数)でなければならない(MUST)。

仮想ルータをバックアップするVRRPルータは、1～254(10進数)の優先度値を使用しなければならない(MUST)。仮想ルータをバックアップするVRRPルータのデフォルトの優先度値は100(10進数)である。優先度の設定に関する推奨事項については、セクション8.3.2を参照のこと。

優先度値ゼロ(0)には特別な意味があり、現在のアクティブ・ルータがVRRPへの参加を停止したことを示す。これは、現在のアクティブ・ダウン間隔(セクション6.1を参照) を待たずに、バックアップ・ルータがアクティブ・ルータに素早く移行するためのトリガーとして使用する。

5.2.5. IPvXアドレス数

IPvXアドレス数フィールドは、このVRRP広告に含まれるIPv4アドレスまたはIPv6アドレスの数である。最小値は1である。受信カウントが0の場合、VRRP広告は無視しなければならない(MUST)。

5.2.6. 予約

予約フィールドは送信時にゼロに設定し、受信時には無視しなければならない(MUST)。

5.2.7. 最大広告間隔

最大広告間隔は12ビットのフィールドで、広告の時間間隔(センチ秒単位)を示す。デフォルトは100センチ秒(1秒)である。

優先度の高いアクティブ・ルータが、そのバックアップ・ルータよりも遅い伝送レートを持つ場合、不安定になることに留意する。これは、より速いレートに設定された優先度の低いバックアップ・ルータが、より遅いレートを持つ優先度の高いアクティブ・ルータから何も聞かないうちにLANに参加し、アクティブ・ルータになるべきだと判断してしまう可能性があるためである。これは一時的なものである。つまり、優先度の低いノードが優先度の高いアクティブ・ルータからのメッセージを受信すると、アクティブ・ルータの地位を放棄する。

5.2.8.チェックサム

チェックサム・フィールドは、VRRPメッセージのデータ破損を検出するために使用する。

IPv4とIPv6の両アドレスファミリーにおいて、チェックサムはVRRPメッセージの1の補数和の16ビットの1の補数である。チェックサムを計算するために、チェックサム ・フィールドはゼロに設定する。詳細は、[RFC1071]を参照のこと。

💡 チェックサム計算アルゴリズム (RFC 1071)

送信側:

1. チェックサム格納領域をゼロ埋め
2. チェックサム計算対象領域で16ビットごとに1の補数和を行う
3. 計算結果の1の補数をチェックサム格納領域に入れる

受信側:

1. チェックサム計算対象領域で16ビットごとに1の補数和を行う
2. 計算結果が0(全ビットが1)となることを確認する

16ビットの数値Aの1の補数は、0xffff-A、すなわちビット反転でもある。1の補数和とは、足し算の結果のMSB側の繰り上がりをLSBに加算することで計算できる。この方法は、バイトオーダー(エンディアン)が異なっても、桁溢れた巡回するためどちらも同じ値になる。

計算の説明のために、以下のIPパケットでチェックサムの計算をしてみる。

45 00 00 34 00 00 40 00
40 06 d7 43 c0 a8 00 0b
11 39 91 94

まず2バイトずつ計算する

0x4500 + 0x0034 = 0x4534

0x4534 + 0x0000 = 0x4534

0x4534 + 0x4000 = 0x8534

0x8534 + 0x4006 = 0xc53a

0xd743はIPチェックサムなので飛ばす。

0xc53a + 0xc0a8 = 0x185e2 → 0x85e3 (桁が上がったら上がった分を1の位に加算して16ビット化)

0x85e3 + 0x000b = 0x85ee

0x85ee + 0x1139 = 0x9727

0x9727 + 0x9194 = 0x128bb → 0x28bc

0x28bcを反転(1の補数)させると、0xd743になる。

IPv4アドレスファミリーの場合、チェックサム計算には、バージョン・フィールドで始まり最後のIPv4アドレスで終わるVRRPメッセージのみを含む(セクション5.2を参照)。

IPv6アドレスファミリーの場合、 [RFC8200]のセクション8.1で定義しているように、チェックサム計算には先頭に追加された「疑似ヘッダ」も含まれる。「疑似ヘッダ」の次のヘッダ・フィールドは、VRRPの場合は112(10進数)に設定する必要がある。

5.2.9. IPvXアドレス

これは、仮想ルータで使用する1つ以上のIPvXアドレスを指す。含まれるアドレスの数は、IPvXアドレス数フィールドで指定する。このフィールドは、設定が間違っているルータのトラブルシューティングに使用する。複数のアドレスが送信する場合、比較を簡素化するために、すべてのルータが同じ順序でこれらのアドレスを送信するよう設定することを推奨する。

IPv4アドレスの場合、これは仮想ルータによってバックアップされる1つ以上のIPv4アドレスを指す。

IPv6の場合、最初のアドレスは仮想ルータで使用するIPv6リンクローカル・アドレスでなければならない(MUST)。

このフィールドには、1つ以上のIPv4アドレスまたは1つ以上のIPv6アドレスが含まれる。アドレスのアドレスファミリー(IPv4またはIPv6のどちらかで、両方は不可)は、VRRPパケットのIPvXヘッダのアドレスファミリーと同じでなければならない(MUST)。

6. プロトコル・ステート・マシン

6.1. 仮想ルータごとのパラメータ

VRID
仮想ルータ識別子。1～255(10進数)の範囲で設定可能な値。デフォルト値はない。

Priority (優先度)
このVRRPルータがこの仮想ルータのアクティブ・ルータ選出時に使用する優先度の値。値255(10進数)は仮想ルータで使用するIPvXアドレスを所有するルータのために予約されている。値0(ゼロ)は、アクティブ・ルータが仮想ルータに対する責務を放棄することを示すために予約されている。1～254(10進数)の範囲は仮想ルータをバックアップするVRRPルータに使用できる。値は大きいほど優先度が高いことを示す。デフォルト値は100(10進数)である。

IPv4_Addresses (IPv4アドレス)
この仮想ルータで使用する1つ以上のIPv4アドレス。デフォルト値なしの設定されたアドレス・リスト。

IPv6_Addresses (IPv6アドレス)
この仮想ルータで使用する1つ以上のIPv6アドレス。デフォルト値なしの設定されたアドレス・リスト。最初のアドレスは、仮想ルータで使用するリンクローカル・アドレスでなければならない(MUST)。

IPvX_Addresses (IPvXアドレス)
この仮想ルータで使用するIPv4アドレスまたはIPv6アドレスのいずれかを指す(上記のIPv4_AddressesとIPv6_Addressesを参照)。

Advertisement_Interval (広告間隔)
この仮想ルータが送信するVRRP広告の時間間隔(センチ秒)。デフォルトは100センチ秒(1秒)である。

Active_Adver_Interval (アクティブ広告間隔)
アクティブ・ルータから受信したVRRP広告に含まれる広告間隔(センチ秒単位)。この値はバックアップ状態の仮想ルータに保存され、Skew_Time (セクション8.3.2で規定)とActive_Down_Intervalの計算に使用される。初期値はAdvertising_Intervalと同じである。

Skew_Time (スキュー時間)
Active_Down_Intervalをスキューさせる時間(センチ秒)。以下のように計算する:

(((256 - Priority) * Active_Adver_Interval) / 256)

Active_Down_Interval (アクティブ・ダウン間隔)
バックアップ・ルータがアクティブ・ルータのダウンを宣言するまでの時間間隔 (センチ秒)。以下のように計算する:

(3 * Active_Adver_Interval) + Skew_Time

Preempt_Mode (プリエンプト・モード)
優先度の高いバックアップ・ルータ (開始または再起動)が優先度の低いアクティブ・ルータをプリエンプトするかどうかを制御する。値は、プリエンプションを許可する場合はTrue、禁止する場合はFalseである。デフォルトはTrue。

注記: 例外は、仮想ルータで使用するIPvXアドレスを保有するルータが、このフラグの設定に関係なく、常にプリエンプトする。

Accept_Mode (受諾モード)
アクティブ状態の仮想ルータが、IPvXアドレス保有者でない場合でも、アドレス保有者のIPvXアドレス宛のパケットを自身のIPvXアドレスとして受け入れるかどうかを制御する。デフォルトはFalse。例えば、アドレス保有者のIPvXアドレスにpingを送信することに依存する展開では、Accept_ModeをTrueに設定する必要な場合がある。

注記: Accept_ModeがFalseの場合、IPv6近隣要請と近隣通知を破棄してはならない(MUST NOT) 。

Virtual_Router_MAC_Address (仮想ルータMACアドレス)
IPvX_Addressesに使用するMACアドレスとして、VRRP広告の送信元MACアドレスに使用され、ARP/NDメッセージで広告されるMACアドレス。

6.2. タイマー

Active_Down_Timer (アクティブ・ダウン・タイマー)
Active_Down_Interval間にVRRP広告を受信しなかった場合に起動するタイマー (バックアップ・ルータのみ)。

Adver_Timer (広告タイマー)
Advertising_Intervalに基づいてVRRP広告の送信をトリガーに起動するタイマー (アクティブ・ルータのみ)。

6.3. 状態遷移図

図4: 状態遷移図

6.4. 状態の説明

以下の状態の説明では、状態名はstate-nameで識別し、パケットはすべて大文字で識別する。

VRRPルータは、参加している仮想ルータごとにステート・マシンのインスタンスを実装する。

6.4.1. 初期化

この状態の目的は、始動イベント、つまり、プロトコルが構成された後にそれを始動する実装定義メカニズムを待機することである。構成メカニズムはこの仕様の範囲外である。

(If)始動イベントを受信した場合:

• 優先度(Priority) = 255、つまりルータが仮想ルータで使用するIPvXアドレスを保有している場合:

  • ADVERTISEMENTを送信する

  • (If)対象となるIPvXアドレスがIPv4アドレスの場合:

    • 仮想ルータで使用するIPv4アドレスごとに、仮想ルータのMACアドレスを含み、ターゲットのリンク層アドレスが仮想ルータのMAC アドレスに設定されているGratuitous ARPメッセージをブロードキャストする。

  • else // IPv6

    • 仮想ルータで使用する各IPv6アドレスに対して、ルータ・フラグ(R)を設定、要請フラグ(S)をクリア、オーバーライド・フラグ(O)を設定、ターゲット・アドレスを仮想ルータ及び仮想ルータのMACアドレスに設定されたターゲットのリンク層アドレスに設定し、自発的ND近隣広告を送信する。

  • endif // 対象となるアドレスはIPv4か?

  • 広告タイマー(Adver_Timer)を広告間隔(Advertising_Interval)に設定する

  • Active状態へ遷移する

• else // ルータはアドレス保有者ではない

  • アクティブ広告間隔(Active_Adver_Interval)を広告間隔(Advertising_Interval)に設定する
  • アクティブ・ダウン・タイマー(Active_Down_Timer)をアクティブ・ダウン間隔(Active_Down_Intervalに設定する
  • バックアップ状態へ遷移する

• endif // 優先度(Priority)は255か?

endif // 始動イベントを受信

Errata (Reported)

次のように記述する必要がある:

• 仮想ルータで使用するIPv4アドレスごとに、仮想ルータのIPv4アドレスを含み、ターゲットのリンク層アドレスが仮想ルータのMAC アドレスに設定されているGratuitous ARPメッセージをブロードキャストする。

注記:

IPv4アドレスの代わりにMACアドレスを指定する。

💡 初期化のフローチャート

6.4.2. バックアップ

Backup状態の目的は、アクティブ・ルータの可用性と状態を監視することである。要請ノード・マルチキャスト・アドレス[RFC4291]は、以下の疑似コードの中で参照される。

(While)バックアップ状態にある間、VRRPルータは以下のことを実行しなければならない(MUST):

• (If)対象となるIPvXアドレスがIPv4アドレスの場合:

  • 仮想ルータで使用するIPv4アドレスに対するARP要求に応答してはならない(MUST NOT)。

• else // 対象となるアドレスはIPv6の場合:

  • 仮想ルータで使用するIPv6アドレスに対するND近隣要請メッセージに応答してはならない(MUST NOT)。
  • 仮想ルータに対してNDルータ広告メッセージを送信してはならない(MUST NOT)。

• endif // 対象となるアドレスはIPv4か?

• 仮想ルータのMACアドレスと等しい宛先リンク層MACアドレスを持つパケットを破棄しなければならない(MUST)。

• 仮想ルータで使用するIPvXアドレス宛てのパケットを受け入れてはならない(MUST NOT)。

• (If)シャットダウン・イベントを受信した場合:

  • アクティブ・ダウン・タイマー(Active_Down_Timer)をキャンセルする
  • 初期化状態へ遷移

• endif // シャットダウン・イベントを受信した

• (If)アクティブ・ダウン・タイマー(Active_Down_Timer)が起動したら、以下の処理を行う:

  • ADVERTISEMENTを送信する

  • 対象となるIPvXアドレスがIPv4アドレスの場合、以下の処理を行う:

    • 仮想ルータで使用する各IPv4アドレスに対して、仮想ルータのMACアドレスを含み、ターゲットのリンク層アドレスが仮想ルータのMACアドレスに設定されたGratuitous ARPメッセージをブロードキャストする。

  • else // IPv6

    • 仮想ルータで使用するIPv6アドレスの要請ノード・マルチキャスト・アドレス[RFC4291]を計算し、参加する。
    • 仮想ルータで使用する各IPv6アドレスに対して、ルータ・フラグ(R)セット、要請フラグ(S)クリア、オーバーライド・フラグ(O)セット、ターゲット・アドレスを、仮想ルータ及び仮想ルータのMACアドレスに設定されたターゲットのリンク層アドレスに設定し、自発的ND近隣広告を送信する。

  • endif // 対象となるアドレスはIPv4か?

  • 広告タイマー(Adver_Timer)を広告間隔(Advertising_Interval)に設定する

  • Active状態へ遷移

• endif // アクティブ・ダウン・タイマー(Active_Down_Timer)が起動する

• (If)ADVERTISEMENTを受信した場合:

  • (If)ADVERTISEMENTの優先度が0の場合:

    • アクティブ・ダウン・タイマー(Active_Down_Timer)をスキュー時間(Skew_Time)に設定する

  • else // 優先度がゼロ以外の場合

    • (If)Preempt_ModeがFalseの場合、またはADVERTISEMENTのPriorityがローカルのPriority以上の場合:

      • アクティブ広告間隔(Active_Adver_Interval)をADVERTISEMENTに含まれる最大広告間隔に設定する
      • スキュー時間(Skew_Time)を再計算する
      • アクティブ・ダウン間隔(Active_Down_Interval)を再計算する
      • アクティブ・ダウン・タイマー(Active_Down_Timer)をアクティブ・ダウン間隔(Active_Down_Interval)に設定する

    • else // プリエンプトがtrueで、優先度がローカル優先度よりも低い

      • ADVERTISEMENTを破棄する

    • endif // プリエンプト・テスト

  • endif // 優先度は0か?

• endif // 広告は受信したか?

endwhile // バックアップ状態

Errata (Reported)

次のように記述する必要がある:

• 仮想ルータで使用する各IPv4アドレスに対して、仮想ルータのIPv4アドレスを含み、ターゲットのリンク層アドレスが仮想ルータのMACアドレスに設定されたGratuitous ARPメッセージをブロードキャストする。

注記:

IPv4アドレスの代わりにMACアドレスを指定する。

💡 バックアップのフローチャート

6.4.3. アクティブ

アクティブ状態にある間、ルータは仮想ルータで使用するIPvXアドレスの転送ルータとして機能する。

Active状態では、Preempt_Modeフラグは考慮されないことに留意する。

(While)Active状態にある間、VRRPルータは以下のことを実行しなければならない:

• (If)対象となるIPvXアドレスがIPv4アドレスの場合:
  • 仮想ルータで使われるIPv4アドレスに対するARP要求に応答しなければならない(MUST)
• else // IPv6
  • 仮想ルータで使われるIPv6アドレスの要請ノード・マルチキャスト・アドレスのメンバーでなければならない(MUST)
  • 仮想ルータで使われるIPv6アドレスのND近隣要請メッセージ(ルータ・フラグ(R)が設定されたもの)に応答しなければならない(MUST)。
  • 仮想ルータのNDルータ広告を送信しなければならない。
  • (If)Accept_ModeがFalseの場合:
    • IPv6近隣要請と近隣通知を破棄してはならない(MUST NOT)。
• endif // IPv4?
• 仮想ルータのMACアドレスと等しい宛先リンク層MACアドレスを持つパケットを転送しなければならない(MUST)。
• 仮想ルータがIPvXアドレスの保有者であるか、Accept_ModeがTrueの場合、仮想ルータで使われるIPvXアドレス宛てのパケットを受け入れなければならない(MUST)。それ以外の場合、これらのパケットを受け入れてはならない(MUST NOT)。
• (If)シャットダウン・イベントを受信した場合:
  • 広告タイマー(Adver_Timer)をキャンセルする
  • 優先度(Priority) = 0で広告を送信する
  • 初期化状態へ遷移
• endif // シャットダウンを受信
• (If)Adver_Timerが起動したら、以下の処理を行う:
  • ADVERTISEMENTを送信する
  • 広告タイマー(Adver_Timer)を広告間隔(Advertising_Interval)にリセットする
• endif // 広告タイマーが起動
• (If)ADVERTISEMENTを受信した場合:
  • (If)ADVERTISEMENTのPriorityが0の場合:
    • ADVERTISEMENTを送信する
    • 広告タイマー(Adver_Timer)を広告間隔(Advertising_Interval)にリセットする
  • else // 優先度(Priority)がゼロ以外だった
    • (If)ADVERTISEMENTの優先度(Priority)がローカルの優先度(Priority)より大きいか、ADVERTISEMENTの優先度(Priority)がローカルの優先度(Priority)に等しく、送信者のプライマリIPvXアドレスがローカルのプライマリIPvXアドレス(IPvXの符号なし整数比較に基づくネットワーク・バイトオーダーのアドレス)より大きい場合、以下の処理を行う:
      • 広告タイマー(Adver_Timer)をキャンセルする
      • アクティブ広告間隔(Active_Adver_Interval)をADVERTISEMENTに含まれる最大広告間隔に設定する
      • スキュー時間(Skew_Time)を再計算する
      • アクティブ・ダウン間隔(Active_Down_Interval)を再計算する
      • アクティブ・ダウン・タイマー(Active_Down_Timer)をアクティブ・ダウン間隔(Active_Down_Interval)に設定する
      • Backup状態へ遷移
    • else // 新しいアクティブ・ルータのロジック
      • ADVERTISEMENTを破棄する
      • すぐにADVERTISEMENTを送信して、送信側VRRPルータに Active状態をアサートし、ラーニング・ブリッジを正しいアクティブVRRPルータのパスで更新する。
      • endif // 新しいアクティブ・ルータを検出
    • endif // 優先度(Priority)は0か?
  • endif // 広告を受信

endwhile // Active状態

注: VRRPパケットは、仮想ルータが接続されているLANセグメントを学習ブリッジが正しく判断できるように、仮想ルータのMACアドレスを送信元MACアドレスとして送信する。

💡 アクティブのフローチャート

7. VRRPパケットの送受信

7.1. VRRPパケットの受信

VRRPパケットを受信した場合、以下の機能を実行する必要がある:

• (If)受信したパケットがIPv4パケットの場合:
  • IPv4 TTLが255であることを確認しなければならない(MUST)。
• else // IPv6 VRRPパケットを受信
  • IPv6ホップ制限が255であることを確認しなければならない(MUST)。
• endif
• VRRPバージョンが3であることを確認しなければならない。
• VRRPのパケット・タイプが1(ADVERTISEMENT)であることを確認する。
• 受信したパケットに完全なVRRPパケット(固定フィールドとIPvXアドレスを含む)が含まれていることを確認しなければならない(MUST)。
• VRRPチェックサムを検証しなければならない。
• VRIDが受信側インタフェースに設定されており、ローカル・ルータがIPvXアドレス保有者ではないことを確認しなければならない(優先度 = 255 (10進数))。

上記のチェックのいずれかが失敗した場合、受信者はパケットを破棄しなければならず(MUST)、そのイベントを(レート制限に従って)ログに記録する必要があり(SHOULD)、ネットワーク管理を通じてエラーが発生したことを示してもよい(MAY)。

受信者は、受信したVRRPパケットの最大広告間隔がVRIDに設定された広告間隔と一致していることも確認する必要がある(SHOULD)。間隔が異なると不安定になることがある(セクション5.2.7を参照)。このチェックに失敗した場合、受信者はイベント(レート制限の対象)をログに記録すべきであり(SHOULD)、ネットワーク管理を通して設定ミスが検出されたことを示してもよい(MAY)。

受信者はまた、「IPvXアドレス数」とIPvXアドレスのリストがVRIDに設定されたIPvXアドレスと一致することを検証してもよい(MAY)。この確認に失敗した場合、受信者はイベントをログに記録する必要があり(SHOULD)、ネットワーク管理を通じて設定ミスが検出されたことを示してもよい(MAY)。

7.2. VRRPパケットの送出

VRRPパケットを送出するときは、以下の操作を実行しなければならない:

• VRRPパケット・フィールドに適切な仮想ルータの構成状態を入力する
• VRRPチェックサムを計算する
• 送信元MACアドレスを仮想ルータのMACアドレスに設定する
• (If)対象となるアドレスがIPv4アドレスの場合:
  • 送信元IPv4アドレスをインタフェースのプライマリIPv4アドレスに設定する
• else // IPv6
  • 送信元IPv6アドレスをインタフェースのリンクローカルIPv6アドレスに設定する
• endif
• IPvXプロトコルをVRRPに設定する
• VRRPパケットをVRRP IPvXマルチキャスト・グループに送信する

注記: VRRPパケットは、仮想ルータが接続されているLANセグメントを学習ブリッジが正しく判断できるように、仮想ルータのMACアドレスを送信元MACアドレスとしてを使用して送信される。

7.3. 仮想ルータのMACアドレス

仮想ルータで使用する仮想ルータのMACアドレスは、以下の形式のIEEE 802 MACアドレス[RFC9542]である:

IPv4の場合: 00-00-5E-00-01-VRID (16進数、ネットワーク・バイトオーダー)

最初の3オクテットは、IANAの組織固有識別子(OUI)に由来する。その次の2オクテット(00～01)は、IPv4プロトコルのVRRPプロトコルに割り当てられたアドレス・ブロックを示す。VRIDは仮想ルータ識別子である。このマッピングにより、LAN上に最大255台のIPv4 VRRPルータを提供できる。

IPv6の場合: 00-00-5E-00-02-VRID (16進数、ネットワーク・バイトオーダー)

最初の3オクテットは、IANAのOUIに由来する。その次の2オクテット(00～02)は、IPv6プロトコルのVRRPプロトコルに割り当てられたアドレス・ブロックを示す。VRIDは仮想ルータ識別子である。このマッピングは、LAN上に最大255台のIPv6 VRRPルータを提供できる。

7.4. IPv6インタフェース識別子

[RFC8064]は、IPv6ステートレス・アドレス自動構成(SLAAC)[RFC4862]で安定したアドレスを生成するためのデフォルト・スキームとして[RFC7217]を使用することを規定している。[RFC7217]及び[RFC8981]のインタフェース識別子(IID)導出アルゴリズムで使用するNet_Ifaceパラメータに仮想ルータMACを使用してはならない(MUST NOT)。

このVRRP仕様では、VRRPルータのIPv6リンクローカル・アドレス及びその他の関連するIPv6アドレスを、仮想ルータのMACアドレスに広告し、解決する方法について説明する。

8. 運用上の問題

8.1. IPv4

8.1.1. ICMPリダイレクト

ルータ・グループ間でVRRPが動作している場合、ICMPリダイレクトは通常通り使用できる。これにより、トポロジが対称でない環境でもVRRPを使用できる。

ICMPリダイレクトのIPv4送信元アドレスは、エンドホストがネクストホップのルーティングを決定するときに使用したアドレスでなければならない。VRRPルータが、自分が所有していないアドレスを含む仮想ルータのアクティブ・ルータとして動作している場合、リダイレクト元アドレスを選択するときに、パケットがどの仮想ルータに送信されたかを判断しなければならない。使用中の仮想ルータを推測する1つの方法は、リダイレクトをトリガーしたパケットの宛先MACアドレスを調べることである。

VRRPが対称トポロジの複数のルータ間でトラフィックを負荷分散するために使用されている特定のケースでは、リダイレクトを無効にすることが有用な場合がある。

8.1.2. ホストARPリクエスト

ホストが仮想ルータのIPv4アドレスの1つに対してARPリクエストを送信すると、アクティブ・ルータは、仮想ルータの仮想ルータMACアドレスを示すARP応答でARP要求に応答しなければならない(MUST)。なお、このARP応答のイーサネット・フレームの送信元アドレスは、物理ルータの物理MACアドレスであることに留意する。アクティブ・ルータは、ARP応答でその物理MACアドレスを応答してはならない(MUST NOT)。これにより、ホストは現在のアクティブ・ルータに関係なく、常に同じMACアドレスを使用することができる。

VRRPルータが再起動または起動する場合、(セクション1.7で定義されているように)IPv4アドレスの保有者であるIPv4アドレスに対して、その物理的なMACアドレスを使用してARPメッセージを送信すべきではない(SHOULD NOT)。仮想ルータのMACアドレスを含むARPメッセージのみを送信すべきである。

これには以下のことが伴う:

• インタフェースを設定するとき、アクティブ・ルータはそのインタフェース上の各IPv4アドレスの仮想ルータMACアドレスを含むGratuitous ARPメッセージをブロードキャストする必要がある(SHOULD)。
• システム起動時、VRRP動作のためにインタフェースを初期化する場合、IPv4アドレスと仮想ルータのMACアドレスの両方が設定されるまで、Gratuitous ARPメッセージを遅らせなければならない(MUST)。
• 例えば、特定のVRRPルータへのセキュアシェル(SSH)アクセスが必要な場合、そのルータに属するIPv4アドレスを使用する必要がある(SHOULD)。

8.1.3. プロキシARP

VRRPルータでプロキシARPを使用する場合、VRRPルータはプロキシARPメッセージで仮想ルータのMACアドレスを広告しなければならない。そうしなければ、ホストがVRRPルータの実際のMACアドレスを学習する可能性がある。

8.2. IPv6

8.2.1. ICMPv6リダイレクト

ルータ・グループ間でVRRPが実行されている場合、ICMPv6リダイレクトは通常通り使用できる[RFC4443]。これにより、VRRPルータが同じ宛先に接続しないなど、トポロジが対称でない環境でもVRRPを使用できる。

ICMPv6リダイレクトのIPv6送信元アドレスは、エンドホストがネクストホップのルーティングを決定する際に使用したアドレスである必要がある(SHOULD)。VRRPルータが、自身が所有しないアドレスを含む仮想ルータのアクティブ・ルータとして動作している場合、リダイレクト元アドレスを選択する際に、パケットがどの仮想ルータに送信されたかを判断しなければならない。使用中の仮想ルータを推定する方法は、リダイレクトがトリガーとなったパケットの宛先MACアドレスを調べることである。

8.2.2. ND近隣要請

ホストが仮想ルータのIPv6アドレスに対してND近隣要請メッセージを送信する場合、アクティブ・ルータはND近隣要請メッセージに仮想ルータのMACアドレスで応答しなければならない(MUST)。アクティブ・ルータはその物理MACアドレスで応答してはならない(MUST NOT)。これにより、ホストは現在のアクティブ・ルータに関係なく、常に同じMACアドレスを使用できる。

アクティブ・ルータがホストのIPv6アドレスのND近隣要請メッセージを送信するとき、近隣要請メッセージでソース・リンク層アドレス・オプションを送信する場合、アクティブ・ルータは仮想ルータの仮想ルータMACアドレスを含めなければならない(MUST)。送信元リンク層アドレス・オプションに物理MACアドレスを使用してはならない(MUST NOT)。

VRRPルータが再起動または起動した場合、そのルータが保有するIPv6アドレスの物理MACアドレスを含むNDメッセージを送信すべきではなく(SHOULD NOT)、仮想ルータのMACアドレスを含むNDメッセージのみを送信すべきである。

これには次のことが伴います:

• インタフェースを設定するとき、アクティブ・ルータはそのインタフェース上のIPv6アドレスの仮想ルータMACアドレスを含む、自発的ND近隣広告メッセージを送信する必要がある(SHOULD)。
• システム起動時、VRRP動作のためにインタフェースを初期化する場合、IPv6アドレスと仮想ルータのMACアドレスの両方が設定されるまで、すべてのNDルータ広告、ND近隣広告、ND近隣要請メッセージを遅らせなければならない(MUST)。

再起動中のアクティブ・ルータでVRRPの対象アドレスがインタフェース・アドレス、つまりアドレスの保有者である場合、バックアップ・ルータがそのアドレスを保有していると応答する可能性があるため、重複アドレス検出に失敗する可能性があることに留意する。この場合、重複アドレス検出を実行しないことが、1つの解決策となる。

8.2.3. ルータ広告

バックアップVRRPルータが仮想ルータのアクティブ・ルータになった場合、セクション6.4.3で規定するとおり、仮想ルータのルータ広告を送信する責務を負う。バックアップ・ルータは、アドレス保有者と同じルータ広告オプションを送信するように設定しなければならない(MUST)。

アドレス保有者に存在する特別なサービス(ホーム・エージェント情報オプションなど)を広告するルータ広告オプションは、バックアップ・ルータがこれらのサービスを完全に引き受ける準備ができており、このサービスのために完全かつ同期されたデータベースを持たない限り、アドレス保有者から送信すべきではない(SHOULD NOT)。

8.2.4. 自発的近隣広告

IPv6アクティブ・ルータまたはバックアップ・ルータとして動作するVRRPルータは、自発的近隣広告を受け入れ、対応する近隣キャッシュ[RFC4861]を更新する必要がある(SHOULD)。これらはIPv6全ノード・マルチキャスト・アドレス(ff021) [RFC4861]またはIPv6全ルータ・マルチキャスト・アドレス(ff022)に送信されるため、受信される。自発的近隣広告は、リンクレベルのアドレスが変更された場合[RFC4861]、及びファースト・ホップ・ルータによるGratuitous近隣発見の場合[RFC9131]の両方で送信される。自発的近隣広告が対応する近隣キャッシュを更新するには、追加の設定が必要になる場合がある。

8.3. IPvX

8.3.1. 潜在的な転送ループ

VRRPルータは、アドレス保有者ではない場合、自身がアクティブ・ルータとなるIPvXアドレス宛のパケットを転送すべきではない(SHOULD NOT)。これらのパケットを転送すると、不要なトラフィックが発生する。また、自分が送信したパケットを受信するLANの場合、IPvXのTTLの有効期限が切れた場合に終了する転送ループが発生する可能性がある。

このような転送ループを回避するVRRPルータのメカニズムとして、アクティブ状態から移行する際に、保有していないIPvXアドレスごとにホストのドロップ経路を追加/削除する方法がある。

8.3.2. 優先度の値設定に関する推奨事項

優先度の値255は、特定のルータをVRIDの「IPvXアドレス保有者」に指定する。優先度255のVRRPルータは、起動と同時に優先度の低いすべてのルータをプリエンプトする。VRIDにとって、リンク上の1つのVRRPルータだけに優先度255を設定する必要がある(SHOULD)。優先度255を広告する複数のVRRPルータが検出された場合、その状態は記録する必要がある(レート制限の影響を受ける)(SHOULD)。この優先度を持つVRRPルータがなく、かつプリエンプションが無効になっている場合、プリエンプションは発生しない。

前のアクティブ・ルータに障害が発生するかシャットダウンした後、2台以上のバックアップ・ルータが同時にアクティブ・ルータになることを避けるため、すべての仮想ルータは異なる優先度を設定し、優先度の低いバックアップ・ルーターがアクティブ・ルータに移行する際に、優先度の高いバックアップ・ルータから広告を受信する前にアクティブ状態に移行しないよう、優先度に十分な差を付けて設定する必要がある(SHOULD)。同じ優先度を広告する複数のVRRPルータが検出された場合、この状態は警告として記録してもよい(レート制限の対象)。

スキュー時間は優先度が高くなるほど短くなるため、優先するバックアップ・ルータに高い優先度を使用することで、より速いコンバージェンスを得ることができる。ただし、複数のバックアップ・ルータを使用する場合、前述の推奨通り、優先度に十分な差を付けて設定する必要がある。

8.4. VRRPv3とVRRPv2の相互運用

8.4.1. 前提

1. VRRPv2とVRRPv3の相互運用はオプションである。
2. VRRPv2とVRRPv3の混在は、VRRPv2からVRRPv3への移行時にのみ行うこと。2つのバージョンを混在させることは、恒久的なソリューションとは考えないこと。

8.4.2. VRRPv3 VRRPv2相互運用のサポート

前述のとおり、このサポートはアップグレード・シナリオを意図したものであり、恒久的な展開には推奨しない(NOT RECOMMENDED)。

実装は、VRRPv2とVRRPv3の両方の広告をリッスンして指示する設定フラグを実装してもよい(MAY)。

仮想ルータがこの方法で設定され、アクティブ・ルータである場合、たとえ1秒未満であっても、設定されたレートで両タイプを送信しなければならない(MUST)。

この方法で設定された仮想ルータがバックアップ・ルーターである場合、アクティブ・ルータから広告されたレートに基づいてタイムアウトしなければならない(MUST)。VRRPv2アクティブ・ルータの場合、受信したタイムアウト値(秒単位)をセンチ秒に変換しなければならない。また、バックアップ・ルータは、現在のアクティブ・ルータからVRRPv3パケットも受信している場合、そのルータのVRRPv2広告を無視する必要がある(SHOULD)。VRRPv3アクティブ・ルータがVRRPv2パケットを送信していない場合、VRRPv2相互運用をサポートしているかどうかが一致していないことを示唆するため報告してもよい(MAY)。

8.4.2.1. 相互運用に関する考慮事項

8.4.2.1.1. 低速で優先度の高いアクティブ・ルータ

「最大広告間隔(Max Advertise Interval)」も参照のこと。

1秒未満のVRRPv3バックアップ・ルータと対話するVRRPv2アクティブ・ルータは、この最も重要な例である。

VRRPv2またはVRRPv3ルータの広告レートが1秒未満の場合、VRRPv2実装は相互運用しているVRRPv2またはVRRPv3実装よりも高い優先度を与えるべきではない(SHOULD NOT)。

8.4.2.1.2. VRRPv2バックアップを圧倒する

VRRPv3アクティブ・ルータがセンチ秒のレートで送信すると、潜在的に非決定論的な結果で、VRRPv2バックアップ・ルータを圧倒する可能性があるようだ。

このようなアップグレードの場合、導入では、VRRPv2ルータがアップグレードされるまでの間、最初はVRRPv3アクティブ・ルータをより低い頻度(例えば、100センチ秒)で動作させる必要がある。その後、導入によりVRRPv3が適切に動作していることを確認したら、VRRPv2のサポートを無効にし、希望する1秒未満のレートを設定する。

9. セキュリティに関する考慮事項

IPvXのVRRPには現在、いかなるタイプの認証も含まれていない。前のバージョンのVRRP仕様には、認証なしから強力な認証まで、いくつかのタイプの認証が含まれていた。しかし、運用経験とさらなる分析により、これらの認証方式ではシークレットを誤って設定し、複数のアクティブ・ルータを選択してしまうという脆弱性を克服するのに十分なセキュリティが得られないことが判明した。VRRPプロトコルの性質上、VRRPメッセージを暗号的に保護しても、敵対ノードがアクティブ・ルータであるかのように振る舞い、複数のアクティブ・ルータを作成することを防ぐことはできない。VRRPメッセージの認証により、敵対ノードが正常に動作しているすべてのルータがバックアップ状態になるのを防ぐことができた可能性はある。しかし、複数のアクティブ・ルータが存在すると、ルータが存在しない場合と同程度の中断を引き起こす可能性があり、認証ではこれを防ぐことはできない。また、敵対ノードがVRRPを中断できなくても、ARP/NDを邪魔し、すべてのルータがバックアップ状態になるのと同じ効果を引き起こす可能性がある。

L2スイッチの中には、例えば、エンドホストからのARPメッセージやNDメッセージをスイッチ ポート単位でフィルタリングして除外する機能を提供しているものがある。このメカニズムは、エンドホストで使われたスイッチ・ポートからのVRRPメッセージをフィルタリングすることもできるため、信頼できないホストを使用する導入を考慮することができる。

これらの攻撃は決して一番ひどいものではなく、LANに接続されたノードがVRRPとは無関係に行える攻撃のサブセットであることに留意する必要がある。LAN上の悪意のあるノードが実行できる攻撃には以下のようなものがある:

• 任意のルータのMACアドレスのパケットを無差別に受信する。
• L2ヘッダの送信元MACアドレスとしてルータのMACアドレスを持つパケットを送信し、ルータ宛てのパケットをルータではなく悪意のあるノードに送信するようにL2スイッチに指示する。
• ホストにトラフィックを別の場所に送るように指示するリダイレクトを送信する。
• 自発的ND応答を送信する。
• ND要求に応答する、など。

これらはすべて、VRRPの実装とは無関係に実行できる。VRRPはこれらの脆弱性を助長するものではなく、これらの脆弱性のほとんどは、例えばセキュア近隣探索(SEND) [RFC3971]などで独立して対処されている。

VRRPには、他のリモート・ネットワークから注入されるVRRPパケットを保護するメカニズム(IPv4 TTLまたはIPv6ホップリミットを255に設定し、受信時に値をチェックする)が含まれている[RFC5082]。これにより、ほとんどの脆弱性はローカル・ネットワークの攻撃に限定される。

VRRPは機密性を提供しない。VRRPの正しい動作には機密性は必要なく、VRRPメッセージには、LAN上の他のノードに対して秘密にしなければならない情報はない。

IPv6の運用において、SENDが導入されている場合、VRRPはSEND[RFC3971]の「トラストアンカー」及び「トラストアンカーまたはCGA」モードと互換性がある。SENDの構成では、アクティブ・ルータとバックアップ・ルータが同じサブネット・プレフィックスを広告できるよう、証明書でアクティブ・ルータとバックアップ・ルータに同じプレフィックス委任を与える必要がある。ただし、秘密鍵の共有を避けるため、アクティブ・ルータとバックアップ・ルータは、独自の鍵ペアを持つべきである。

また、IPv6の運用においては、[RFC9099]のセクション2.3のリンクレベルのセキュリティ・ガイドラインに従うことを推奨する(RECOMMENDED)。

10. IANAに関する考慮事項

IANAは、 [RFC5798]へのすべてのIANAレジストリ参照を、RFC 9568、つまり本文書への参照に更新した。個々のIANA参照を以下に示す。

「Assigned Internet Protocol Numbers」レジストリのVRRPには「112」が割り当てた。

「IPv4 Multicast Address Space Registry」 [RFC5771]の「Local Network Control Block (224.0.0.0 - 224.0.0.255 (224.0.0/24))」レジストリでは、IANAはVRRPに IPv4マルチキャスト・アドレス「224.0.0.18」を割り当てた。

「IPv6 Multicast Address Space Registry」[RFC3307]の「Link-Local Scope Multicast Addresses」レジストリでは、IANAは「VRRP for IPv6」にIPv6リンクローカル・スコープ・マルチキャスト・アドレス「ff02:0:0:0:0:0:0:12」を割り当てた。

「IANA MAC ADDRESS BLOCK」レジストリ[RFC9542]で、IANAはイーサネット・ユニキャスト・アドレスのブロックを以下のように割り当てた(16進数):

アドレス	使用法	参照
00-01-00 から 00-01-FF	VRRP(仮想ルータ冗長プロトコル)	RFC 9568
00-02-00 から 00-02-FF	VRRP IPv6 (仮想ルーター冗長プロトコルIPv6)	RFC 9568

表1

11. 参考文献

11.1. 引用規格

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast Addresses", RFC 3307, DOI 10.17487/RFC3307, August 2002, <https://www.rfc-editor.org/info/rfc3307>.

[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, <https://www.rfc-editor.org/info/rfc4291>.

[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", STD 89, RFC 4443, DOI 10.17487/RFC4443, March 2006, <https://www.rfc-editor.org/info/rfc4443>.

[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, <https://www.rfc-editor.org/info/rfc4861>.

[RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. Pignataro, "The Generalized TTL Security Mechanism (GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007, https://www.rfc-editor.org/info/rfc5082.

[RFC5771] Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for IPv4 Multicast Address Assignments", BCP 51, RFC 5771, DOI 10.17487/RFC5771, March 2010, <https://www.rfc-editor.org/info/rfc5771>.

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, <https://www.rfc-editor.org/info/rfc8200>.

[RFC9542] Eastlake 3rd, D., Abley, J., and Y. Li, "IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters", BCP 141, RFC 9542, DOI 10.17487/RFC9542, April 2024, <https://www.rfc-editor.org/info/rfc9542>.

11.2. 参考規格

[IPSTB] Higginson, P. and M. Shand, "Development of Router Clusters to Provide Fast Failover in IP Networks", Digital Technical Journal, Volume 9, Number 3, 1997.

[NISTIR8366] National Institute of Standards and Technology (NIST), "Guidance for NIST Staff on Using Inclusive Language in Documentary Standards,", NISTIR 8366, DOI 10.6028/NIST.IR.8366, April 2021, <https://doi.org/10.6028/NIST.IR.8366>.

[RFC1071] Braden, R., Borman, D., and C. Partridge, "Computing the Internet checksum", RFC 1071, DOI 10.17487/RFC1071, September 1988, <https://www.rfc-editor.org/info/rfc1071>.

[RFC1256] Deering, S., Ed., "ICMP Router Discovery Messages", RFC 1256, DOI 10.17487/RFC1256, September 1991, <https://www.rfc-editor.org/info/rfc1256>.

[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, DOI 10.17487/RFC2131, March 1997, <https://www.rfc-editor.org/info/rfc2131>.

[RFC2281] Li, T., Cole, B., Morton, P., and D. Li, "Cisco Hot Standby Router Protocol (HSRP)", RFC 2281, DOI 10.17487/RFC2281, March 1998, <https://www.rfc-editor.org/info/rfc2281>.

[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, DOI 10.17487/RFC2328, April 1998, <https://www.rfc-editor.org/info/rfc2328>.

[RFC2338] Knight, S., Weaver, D., Whipple, D., Hinden, R., Mitzel, D., Hunt, P., Higginson, P., Shand, M., and A. Lindem, "Virtual Router Redundancy Protocol", RFC 2338, DOI 10.17487/RFC2338, April 1998, <https://www.rfc-editor.org/info/rfc2338>.

[RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, DOI 10.17487/RFC2453, November 1998, <https://www.rfc-editor.org/info/rfc2453>.

[RFC3768] Hinden, R., Ed., "Virtual Router Redundancy Protocol (VRRP)", RFC 3768, DOI 10.17487/RFC3768, April 2004, <https://www.rfc-editor.org/info/rfc3768>.

[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, DOI 10.17487/RFC3971, March 2005, <https://www.rfc-editor.org/info/rfc3971>.

[RFC4311] Hinden, R. and D. Thaler, "IPv6 Host-to-Router Load Sharing", RFC 4311, DOI 10.17487/RFC4311, November 2005, <https://www.rfc-editor.org/info/rfc4311>.

[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007, <https://www.rfc-editor.org/info/rfc4862>.

[RFC5798] Nadas, S., Ed., "Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6", RFC 5798, DOI 10.17487/RFC5798, March 2010, <https://www.rfc-editor.org/info/rfc5798>.

[RFC7217] Gont, F., "A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)", RFC 7217, DOI 10.17487/RFC7217, April 2014, <https://www.rfc-editor.org/info/rfc7217>.

[RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu, "Recommendation on Stable IPv6 Interface Identifiers", RFC 8064, DOI 10.17487/RFC8064, February 2017, <https://www.rfc-editor.org/info/rfc8064>.

[RFC8981] Gont, F., Krishnan, S., Narten, T., and R. Draves, "Temporary Address Extensions for Stateless Address Autoconfiguration in IPv6", RFC 8981, DOI 10.17487/RFC8981, February 2021, <https://www.rfc-editor.org/info/rfc8981>.

[RFC9099] Vyncke, É., Chittimaneni, K., Kaeo, M., and E. Rey, "Operational Security Considerations for IPv6 Networks", RFC 9099, DOI 10.17487/RFC9099, August 2021, <https://www.rfc-editor.org/info/rfc9099>.

[RFC9131] Linkova, J., "Gratuitous Neighbor Discovery: Creating Neighbor Cache Entries on First-Hop Routers", RFC 9131, DOI 10.17487/RFC9131, October 2021, <https://www.rfc-editor.org/info/rfc9131>.

[VRRP-IPv6] Hinden, R. and J. Cruz, "Virtual Router Redundancy Protocol for IPv6", Work in Progress, Internet-Draft, draft-ietf-vrrp-ipv6-spec-08, 5 March 2007, <https://datatracker.ietf.org/doc/html/draft-ietf-vrrp-ipv6-spec-08>.

謝辞

この仕様のIPv6の文章は[RFC2338]に基づいている。[RFC2338]の著者は、 S・ナイト、D・ウィーバー、D・ウィップル、R・ヒンデン、D・ミッツェル、P・ハント、P・ヒギンソン、M・シャンド、A・リンデムである。

[VRRP-IPv6]の著者であるリック・ノルトマーク、トーマス・ナルテン、スティーブ・ディーリング、ラディア・パールマン、ダニー・ミッツェル、ムケシュ・グプタ、ドン・プロヴァン、マーク・ホリンジャー、ジョン・クルーズ、メリッサ・ジョンソンの有益な提案に感謝する。

本仕様のIPv4の文章は[RFC3768]に基づいています。この仕様の著者である、グレン・ゾーン、マイケル・レーン、クラーク・ブレーマー、ハル・ピーターソン、トニー・リー、バーバラ・デニー、ジョエル・ハルパーン、スティーブ・M・ベロビン、トーマス・ナルテン、ロブ・モンゴメリー、ロブ・コルトン、ラディア・パールマン、ラス・ハウズリーに感謝する。ハラルド・アルヴェストランド、ネッド・フリード、テッド・ハーディー、バート・ワイネン、ビル・フェナー、アレックス・ジニンのコメントと提案に感謝する。

[RFC3768]と[VRRP-IPv6]を文書にマージ/編集し、最終的に[RFC5798]となる作業を行ったスティーブ・ナダスに感謝する。

現在の文書(RFC 9568)に関するコメントについては、スチュワート・ブライアント、サーシャ・ヴァインシュテイン、パスカル・チュベール、アレクサンダー・オコニコフ、ベン・ニーヴン＝ジェンキンス、ティム・カウン、マリシャ・ヴチニッチ、ラス・ホワイト、ドナルド・イーストレイク、デーブ・ターラー、エリック・クライン、ヴィジャイ・グルバニに感謝する。レガシー・テクノロジの付録の削除に関する議論については、ギャン・ミシュラ、ポール・コングドン、ジョン・ローゼンに感謝する。IANAセクションを改善するためのコメントと提案をくれたドゥルヴ・ドーディとドナルド・イーストレイクに感謝する。 「最大広告間隔」の検証を推奨してくれたサーシャ・ヴァインシュテインに感謝する。IPv6 SLAAC に関するディスカッションと最新情報について、ティム・カウンとフェルナンド・ゴントに感謝する。

現在の文書(RFC 9568)に関する詳細なレビューと広範なコメントを提供してくれたクエンティン・アーミテージに特に感謝する。

著者のアドレス

エース・リンデム
LabN Consulting, L.L.C.
301 Midenhall Way
Cary, NC 27513
アメリカ合衆国
メール: [e-mail]

アディティア・ドグラ
Cisco Systems
Sarjapur Outer Ring Road
Bangalore 560103
カルナータカ
インド
メール: [e-mail]

更新履歴

• 2024.6.14