[要約] RFC 3768は、仮想ルータの冗長性プロトコル（VRRP）に関する規格です。VRRPは、ネットワークの冗長性を確保し、デフォルトゲートウェイの冗長化を実現するために使用されます。
Network Working Group R. Hinden, Ed.
Request for Comments: 3768 Nokia
Obsoletes: 2338 April 2004
Category: Standards Track
Virtual Router Redundancy Protocol (VRRP)
仮想ルーター冗長プロトコル（VRRP）
Status of this Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004). All Rights Reserved.
著作権（c）The Internet Society（2004）。無断転載を禁じます。
Abstract
概要
This memo defines the Virtual Router Redundancy Protocol (VRRP). VRRP specifies an election protocol that dynamically assigns responsibility for a virtual router to one of the VRRP routers on a LAN. The VRRP router controlling the IP address(es) associated with a virtual router is called the Master, and forwards packets sent to these IP addresses. The election process provides dynamic fail over in the forwarding responsibility should the Master become unavailable. This allows any of the virtual router IP addresses on the LAN to be used as the default first hop router by end-hosts. The advantage gained from using VRRP is a higher availability default path without requiring configuration of dynamic routing or router discovery protocols on every end-host.
このメモは、仮想ルーター冗長プロトコル（VRRP）を定義します。VRRPは、LAN上のVRRPルーターの1つに仮想ルーターの責任を動的に割り当てる選挙プロトコルを指定します。仮想ルーターに関連付けられたIPアドレスを制御するVRRPルーターはマスターと呼ばれ、これらのIPアドレスに送信されるパケットを転送します。選挙プロセスは、マスターが利用できなくなった場合に転送責任において動的な失敗を提供します。これにより、LAN上の仮想ルーターIPアドレスを、エンドホストでデフォルトのファーストホップルーターとして使用できます。VRRPを使用することで得られる利点は、すべてのエンドホストで動的ルーティングまたはルーター発見プロトコルの構成を必要とせずに、より高い可用性のデフォルトパスです。
Table of Contents
目次
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Contributors. . . . . . . . . . . . . . . . . . . . . . 3
1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Definitions . . . . . . . . . . . . . . . . . . . . . . 4
2. Required Features . . . . . . . . . . . . . . . . . . . . . . 5
2.1. IP Address Backup . . . . . . . . . . . . . . . . . . . 5
2.2. Preferred Path Indication . . . . . . . . . . . . . . . 5
2.3. Minimization of Unnecessary Service Disruptions . . . . 5
2.4. Efficient Operation over Extended LANs. . . . . . . . . 6
3. VRRP Overview . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Sample Configurations . . . . . . . . . . . . . . . . . . . . 7
4.1. Sample Configuration 1. . . . . . . . . . . . . . . . . 7
4.2. Sample Configuration 2. . . . . . . . . . . . . . . . . 9
5. Protocol. . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. VRRP Packet Format. . . . . . . . . . . . . . . . . . . 10
5.2. IP Field Descriptions . . . . . . . . . . . . . . . . . 10
5.3. VRRP Field Descriptions . . . . . . . . . . . . . . . . 11
6. Protocol State Machine. . . . . . . . . . . . . . . . . . . . 13
6.1. Parameters per Virtual Router . . . . . . . . . . . . . 13
6.2. Timers. . . . . . . . . . . . . . . . . . . . . . . . . 14
6.3. State Transition Diagram. . . . . . . . . . . . . . . . 15
6.4. State Descriptions. . . . . . . . . . . . . . . . . . . 15
7. Sending and Receiving VRRP Packets. . . . . . . . . . . . . . 18
7.1. Receiving VRRP Packets. . . . . . . . . . . . . . . . . 18
7.2. Transmitting Packets. . . . . . . . . . . . . . . . . . 19
7.3. Virtual MAC Address . . . . . . . . . . . . . . . . . . 19
8. Operational Issues. . . . . . . . . . . . . . . . . . . . . . 20
8.1. ICMP Redirects. . . . . . . . . . . . . . . . . . . . . 20
8.2. Host ARP Requests . . . . . . . . . . . . . . . . . . . 20
8.3. Proxy ARP . . . . . . . . . . . . . . . . . . . . . . . 20
8.4. Potential Forwarding Loop . . . . . . . . . . . . . . . 21
9. Operation over FDDI, Token Ring, and ATM LANE . . . . . . . . 21
9.1. Operation over FDDI . . . . . . . . . . . . . . . . . . 21
9.2. Operation over Token Ring . . . . . . . . . . . . . . . 21
9.3. Operation over ATM LANE . . . . . . . . . . . . . . . . 23
10. Security Considerations . . . . . . . . . . . . . . . . . . . 23
11. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 24
12. References. . . . . . . . . . . . . . . . . . . . . . . . . . 24
12.1. Normative References. . . . . . . . . . . . . . . . . . 24
12.2. Informative References. . . . . . . . . . . . . . . . . 25
13. Changes from RFC2338. . . . . . . . . . . . . . . . . . . . . 25
14. Editor's Address. . . . . . . . . . . . . . . . . . . . . . . 26
15. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 27
There are a number of methods that an end-host can use to determine its first hop router towards a particular IP destination. These include running (or snooping) a dynamic routing protocol such as Routing Information Protocol [RIP] or OSPF version 2 [OSPF], running an ICMP router discovery client [DISC] or using a statically configured default route.
エンドホストが特定のIP宛先に向けて最初のホップルーターを決定するために使用できる多くの方法があります。これらには、ルーティング情報プロトコル[RIP]やOSPFバージョン2 [OSPF]などの動的なルーティングプロトコル、ICMPルーターディスカバリークライアント[disc]の実行、または静的に構成されたデフォルトルートの使用などの動的なルーティングプロトコルの実行（またはスヌーピング）が含まれます。
Running a dynamic routing protocol on every end-host may be infeasible for a number of reasons, including administrative overhead, processing overhead, security issues, or lack of a protocol implementation for some platforms. Neighbor or router discovery protocols may require active participation by all hosts on a network, leading to large timer values to reduce protocol overhead in the face of large numbers of hosts. This can result in a significant delay in the detection of a lost (i.e., dead) neighbor, that may introduce unacceptably long "black hole" periods.
すべてのエンドホストで動的ルーティングプロトコルを実行することは、管理オーバーヘッド、オーバーヘッドの処理、セキュリティの問題、一部のプラットフォームのプロトコル実装の欠如など、さまざまな理由で実行不可能な場合があります。NeighborまたはRouterの発見プロトコルは、ネットワーク上のすべてのホストによる積極的な参加を必要とする場合があり、多数のホストに直面してプロトコルオーバーヘッドを減らすために大きなタイマー値につながる場合があります。これにより、失われた（つまり、死んだ）隣人の検出が大幅に遅れ、容認できないほど長い「ブラックホール」期間が導入される可能性があります。
The use of a statically configured default route is quite popular; it minimizes configuration and processing overhead on the end-host and is supported by virtually every IP implementation. This mode of operation is likely to persist as dynamic host configuration protocols [DHCP] are deployed, which typically provide configuration for an end-host IP address and default gateway. However, this creates a single point of failure. Loss of the default router results in a catastrophic event, isolating all end-hosts that are unable to detect any alternate path that may be available.
静的に構成されたデフォルトルートの使用は非常に人気があります。エンドホストの構成とオーバーヘッドの処理を最小限に抑え、ほぼすべてのIP実装によってサポートされています。この動作モードは、動的ホスト構成プロトコル[DHCP]が展開されているため持続する可能性があります。これは通常、エンドホストIPアドレスとデフォルトゲートウェイの構成を提供します。ただし、これにより障害の単一のポイントが作成されます。デフォルトのルーターを失うと、壊滅的なイベントが発生し、利用可能な代替パスを検出できないすべてのエンドホストを分離します。
The Virtual Router Redundancy Protocol (VRRP) is designed to eliminate the single point of failure inherent in the static default routed environment. VRRP specifies an election protocol that dynamically assigns responsibility for a virtual router to one of the VRRP routers on a LAN. The VRRP router controlling the IP address(es) associated with a virtual router is called the Master, and forwards packets sent to these IP addresses. The election process provides dynamic fail-over in the forwarding responsibility should the Master become unavailable. Any of the virtual router's IP addresses on a LAN can then be used as the default first hop router by end-hosts. The advantage gained from using VRRP is a higher availability default path without requiring configuration of dynamic routing or router discovery protocols on every end-host.
仮想ルーター冗長プロトコル（VRRP）は、静的デフォルトルーティング環境に固有の単一の障害点を排除するように設計されています。VRRPは、LAN上のVRRPルーターの1つに仮想ルーターの責任を動的に割り当てる選挙プロトコルを指定します。仮想ルーターに関連付けられたIPアドレスを制御するVRRPルーターはマスターと呼ばれ、これらのIPアドレスに送信されるパケットを転送します。選挙プロセスは、マスターが利用できなくなった場合に、転送責任の動的なフェイルオーバーを提供します。LAN上の仮想ルーターのIPアドレスは、エンドホストでデフォルトのファーストホップルーターとして使用できます。VRRPを使用することで得られる利点は、すべてのエンドホストで動的ルーティングまたはルーター発見プロトコルの構成を必要とせずに、より高い可用性のデフォルトパスです。
VRRP provides a function similar to the proprietary protocols "Hot Standby Router Protocol (HSRP)" [HSRP] and "IP Standby Protocol" [IPSTB].
VRRPは、独自のプロトコル「ホットスタンバイルータープロトコル（HSRP）」[HSRP]および「IPスタンバイプロトコル」[IPSTB]と同様の関数を提供します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、[RFC2119]に記載されているように解釈される。
The following people, who are the authors of the RFC 2338 that this document is based on and replaces, contributed to the text in this document. They are P. Higginson, R. Hinden, P. Hunt, S. Knight, A. Lindem, D. Mitzel, M. Shand, D. Weaver, and D. Whipple. They are not listed as authors of the document due to current RFC-Editor policies.
このドキュメントが基づいており、置き換えられているRFC 2338の著者である次の人々は、このドキュメントのテキストに貢献しました。彼らはP.ヒギンソン、R。ヒンデン、P。ハント、S。ナイト、A。リンデム、D。ミッツェル、M。シャンド、D。ウィーバー、およびD.ホイップルです。現在のRFC編集者ポリシーにより、文書の著者としてリストされていません。
The remainder of this document describes the features, design goals, and theory of operation of VRRP. The message formats, protocol processing rules and state machine that guarantee convergence to a single Virtual Router Master are presented. Finally, operational issues related to MAC address mapping, handling of ARP requests, generation of ICMP redirect messages, and security issues are addressed.
このドキュメントの残りの部分は、VRRPの機能、設計目標、および動作理論について説明しています。メッセージ形式、プロトコル処理ルール、および単一の仮想ルーターマスターへの収束を保証する状態マシンが表示されます。最後に、Macアドレスマッピング、ARP要求の処理、ICMPリダイレクトメッセージの生成、およびセキュリティの問題に関連する運用上の問題が対処されます。
This protocol is intended for use with IPv4 routers only. A separate specification will be produced if it is decided that similar functionality is desirable in an IPv6 environment.
このプロトコルは、IPv4ルーターのみで使用することを目的としています。IPv6環境で同様の機能が望ましいことが決定された場合、個別の仕様が生成されます。
VRRP Router A router running the Virtual Router Redundancy Protocol. It may participate in one or more virtual routers.
VRRPルーター仮想ルーター冗長プロトコルを実行するルーター。1つ以上の仮想ルーターに参加する場合があります。
Virtual Router An abstract object managed by VRRP that acts as a default router for hosts on a shared LAN. It consists of a Virtual Router Identifier and a set of associated IP address(es) across a common LAN. A VRRP Router may backup one or more virtual routers.
仮想ルーター共有LANのホストのデフォルトルーターとして機能するVRRPによって管理される抽象オブジェクト。これは、仮想ルーター識別子と、共通のLAN全体の関連するIPアドレスのセットで構成されています。VRRPルーターは、1つ以上の仮想ルーターをバックアップできます。
IP Address Owner The VRRP router that has the virtual router's IP address(es) as real interface address(es). This is the router that, when up, will respond to packets addressed to one of these IP addresses for ICMP pings, TCP connections, etc.
IPアドレスの所有者は、仮想ルーターのIPアドレス（ES）を実際のインターフェイスアドレス（ES）として持つVRRPルーター。これは、UPがICMP Ping、TCP接続などのこれらのIPアドレスのいずれかにアドレス指定されたパケットに応答するルーターです。
Primary IP Address An IP address selected from the set of real interface addresses. One possible selection algorithm is to always select the first address. VRRP advertisements are always sent using the primary IP address as the source of the IP packet.
プライマリIPアドレス実際のインターフェイスアドレスのセットから選択されたIPアドレス。可能な選択アルゴリズムの1つは、常に最初のアドレスを選択することです。VRRP広告は、IPパケットのソースとしてプライマリIPアドレスを使用して常に送信されます。
Virtual Router Master The VRRP router that is assuming the responsibility of forwarding packets sent to the IP address(es) associated with the virtual router, and answering ARP requests for these IP addresses. Note that if the IP address owner is available, then it will always become the Master.
仮想ルーターは、仮想ルーターに関連付けられたIPアドレスに送信されたパケットを転送する責任を想定しているVRRPルーターをマスターし、これらのIPアドレスのARP要求に応答します。IPアドレスの所有者が利用可能である場合、それは常にマスターになることに注意してください。
Virtual Router Backup The set of VRRP routers available to assume forwarding responsibility for a virtual router should the current Master fail.
仮想ルーターバックアップ現在のマスターが失敗した場合、仮想ルーターの責任を転送するために利用可能なVRRPルーターのセットをバックアップします。
This section outlines the set of features that were considered mandatory and that guided the design of VRRP.
このセクションでは、必須と見なされ、VRRPの設計をガイドした機能のセットの概要を説明します。
Backup of IP addresses is the primary function of the Virtual Router Redundancy Protocol. While providing election of a Virtual Router Master and the additional functionality described below, the protocol should strive to:
IPアドレスのバックアップは、仮想ルーター冗長プロトコルの主な機能です。仮想ルーターマスターの選挙と以下で説明する追加の機能を提供しながら、プロトコルは次のように努力する必要があります。
- Minimize the duration of black holes. - Minimize the steady state bandwidth overhead and processing complexity. - Function over a wide variety of multiaccess LAN technologies capable of supporting IP traffic. - Provide for election of multiple virtual routers on a network for load balancing. - Support of multiple logical IP subnets on a single LAN segment.
- ブラックホールの持続時間を最小限に抑えます。 - 定常状態の帯域幅のオーバーヘッドを最小限に抑え、複雑さを処理します。 - IPトラフィックをサポートできる多種多様なマルチケスLANテクノロジーで機能します。 - ロードバランスのためのネットワーク上の複数の仮想ルーターの選挙を提供します。 - 単一のLANセグメントでの複数の論理IPサブネットのサポート。
A simple model of Master election among a set of redundant routers is to treat each router with equal preference and claim victory after converging to any router as Master. However, there are likely to be many environments where there is a distinct preference (or range of preferences) among the set of redundant routers. For example, this preference may be based upon access link cost or speed, router performance or reliability, or other policy considerations. The protocol should allow the expression of this relative path preference in an intuitive manner, and guarantee Master convergence to the most preferential router currently available.
一連の冗長ルーターの間でのマスター選挙の単純なモデルは、各ルーターを平等に好みのあるもので処理し、マスターとしてルーターに収束した後、勝利を主張することです。ただし、一連の冗長ルーターの間に明確な好み（または好みの範囲）がある多くの環境がある可能性があります。たとえば、この好みは、アクセスリンクコストまたは速度、ルーターのパフォーマンスまたは信頼性、またはその他のポリシーに関する考慮事項に基づいている場合があります。このプロトコルは、この相対的なパス選好の表現を直感的に許可し、現在利用可能な最も優先的なルーターへのマスター収束を保証する必要があります。
Once Master election has been performed then any unnecessary transitions between Master and Backup routers can result in a disruption in service. The protocol should ensure after Master election that no state transition is triggered by any Backup router of equal or lower preference as long as the Master continues to function properly.
マスター選挙が行われると、マスターとバックアップルーターの間の不必要な移行は、サービスが中断される可能性があります。マスターが適切に機能し続ける限り、マスター選挙後に等しいまたは低い好みのバックアップルーターによって州の移行がトリガーされないことをマスター選挙後に保証する必要があります。
Some environments may find it beneficial to avoid the state transition triggered when a router becomes available that is preferred over the current Master. It may be useful to support an override of the immediate convergence to the preferred path.
一部の環境では、現在のマスターよりも優先されるルーターが利用可能になったときにトリガーされた状態遷移を避けることが有益であると思われる場合があります。優先パスへの即時収束のオーバーライドをサポートすることは有用かもしれません。
Sending IP packets on a multiaccess LAN requires mapping from an IP address to a MAC address. The use of the virtual router MAC address in an extended LAN employing learning bridges can have a significant effect on the bandwidth overhead of packets sent to the virtual router. If the virtual router MAC address is never used as the source address in a link level frame then the station location is never learned, resulting in flooding of all packets sent to the virtual router. To improve the efficiency in this environment the protocol should: 1) use the virtual router MAC as the source in a packet sent by the Master to trigger station learning; 2) trigger a message immediately after transitioning to Master to update the station learning; and 3) trigger periodic messages from the Master to maintain the station learning cache.
Multiaccess LANにIPパケットを送信するには、IPアドレスからMACアドレスへのマッピングが必要です。学習ブリッジを使用する拡張LANでの仮想ルーターMACアドレスの使用は、仮想ルーターに送信されるパケットの帯域幅のオーバーヘッドに大きな影響を与える可能性があります。仮想ルーターMACアドレスがリンクレベルフレームのソースアドレスとして使用されない場合、ステーションの位置が学習されることはなく、仮想ルーターに送信されるすべてのパケットの洪水が発生します。この環境の効率を改善するには、プロトコルは次のようにする必要があります。1）仮想ルーターMacを、マスターから送信されたパケットのソースとして、ステーションの学習をトリガーするために使用する。2）マスターに移行した直後にメッセージをトリガーして、ステーションの学習を更新します。3）ステーションの学習キャッシュを維持するために、マスターからの定期的なメッセージをトリガーします。
VRRP specifies an election protocol to provide the virtual router function described earlier. All protocol messaging is performed using IP multicast datagrams, thus the protocol can operate over a variety of multiaccess LAN technologies supporting IP multicast. Each VRRP virtual router has a single well-known MAC address allocated to it. This document currently only details the mapping to networks using the IEEE 802 48-bit MAC address. The virtual router MAC address is used as the source in all periodic VRRP messages sent by the Master router to enable bridge learning in an extended LAN.
VRRPは、前述の仮想ルーター機能を提供する選挙プロトコルを指定します。すべてのプロトコルメッセージは、IPマルチキャストデータグラムを使用して実行されるため、プロトコルはIPマルチキャストをサポートするさまざまなマルチケスLANテクノロジーで動作できます。各VRRP仮想ルーターには、それに割り当てられた1つの有名なMACアドレスがあります。現在、このドキュメントは、IEEE 802 48ビットMACアドレスを使用してネットワークへのマッピングのみを詳述しています。仮想ルーターMACアドレスは、マスタールーターによって送信されたすべての周期的なVRRPメッセージのソースとして使用され、拡張LANでブリッジ学習を可能にします。
A virtual router is defined by its virtual router identifier (VRID) and a set of IP addresses. A VRRP router may associate a virtual router with its real addresses on an interface, and may also be configured with additional virtual router mappings and priority for virtual routers it is willing to backup. The mapping between VRID and addresses must be coordinated among all VRRP routers on a LAN. However, there is no restriction against reusing a VRID with a different address mapping on different LANs. The scope of each virtual router is restricted to a single LAN.
仮想ルーターは、仮想ルーター識別子（VRID）と一連のIPアドレスによって定義されます。VRRPルーターは、仮想ルーターをインターフェイス上の実際のアドレスに関連付けることができ、バックアップすることをいとわない仮想ルーターの追加の仮想ルーターマッピングと優先度で構成することもできます。VRIDとアドレスの間のマッピングは、LAN上のすべてのVRRPルーター間で調整する必要があります。ただし、異なるLANに異なるアドレスマッピングでVRIDを再利用することに対する制限はありません。各仮想ルーターの範囲は、単一のLANに制限されています。
To minimize network traffic, only the Master for each virtual router sends periodic VRRP Advertisement messages. A Backup router will not attempt to preempt the Master unless it has higher priority. This eliminates service disruption unless a more preferred path becomes available. It's also possible to administratively prohibit all preemption attempts. The only exception is that a VRRP router will always become Master of any virtual router associated with addresses it owns. If the Master becomes unavailable then the highest priority Backup will transition to Master after a short delay, providing a controlled transition of the virtual router responsibility with minimal service interruption.
ネットワークトラフィックを最小限に抑えるために、各仮想ルーターのマスターのみが定期的なVRRP広告メッセージを送信します。バックアップルーターは、優先度が高い場合を除き、マスターを先取りしようとしません。これにより、より優先されたパスが利用可能にならない限り、サービスの中断がなくなります。すべての先制の試みを管理上禁止することも可能です。唯一の例外は、VRRPルーターが常に所有するアドレスに関連付けられた仮想ルーターのマスターになることです。マスターが利用できなくなった場合、最優先バックアップは短い遅延後にマスターに移行し、最小限のサービス中断で仮想ルーターの責任の制御された遷移を提供します。
The VRRP protocol design provides rapid transition from Backup to Master to minimize service interruption, and incorporates optimizations that reduce protocol complexity while guaranteeing controlled Master transition for typical operational scenarios. The optimizations result in an election protocol with minimal runtime state requirements, minimal active protocol states, and a single message type and sender. The typical operational scenarios are defined to be two redundant routers and/or distinct path preferences among each router. A side effect when these assumptions are violated (i.e., more than two redundant paths all with equal preference) is that duplicate packets may be forwarded for a brief period during Master election. However, the typical scenario assumptions are likely to cover the vast majority of deployments, loss of the Master router is infrequent, and the expected duration in Master election convergence is quite small ( << 1 second ). Thus the VRRP optimizations represent significant simplifications in the protocol design while incurring an insignificant probability of brief network degradation.
VRRPプロトコル設計は、サービスの中断を最小限に抑えるためにバックアップからマスターへの迅速な移行を提供し、典型的な運用シナリオの制御されたマスター遷移を保証しながら、プロトコルの複雑さを減らす最適化を組み込みます。最適化により、最小限のランタイム状態要件、最小限のアクティブプロトコル状態、単一のメッセージタイプと送信者を備えた選挙プロトコルが発生します。典型的な運用シナリオは、各ルーター間の2つの冗長ルーターおよび/または明確なパス設定であると定義されています。これらの仮定に違反した場合（つまり、すべてが同等の好みを持つすべての冗長なパス）、マスター選挙中の短い期間、重複したパケットが転送される可能性があるという副作用です。ただし、典型的なシナリオの仮定は展開の大部分をカバーする可能性が高いため、マスタールーターの損失はまれであり、マスター選挙の収束で予想される期間は非常に少ない（<< 1秒）。したがって、VRRPの最適化は、プロトコル設計の重要な単純化を表し、短時間のネットワーク劣化の重要ではない確率が発生します。
The following figure shows a simple network with two VRRP routers implementing one virtual router. Note that this example is provided to help understand the protocol, but is not expected to occur in actual practice.
次の図は、2つのVRRPルーターが1つの仮想ルーターを実装する単純なネットワークを示しています。この例は、プロトコルを理解するのに役立つが、実際の実践では発生するとは予想されていないことに注意してください。
+-----------+ +-----------+
| Rtr1 | | Rtr2 |
|(MR VRID=1)| |(BR VRID=1)|
| | | |
VRID=1 +-----------+ +-----------+
IP A ---------->* *<--------- IP B
| |
| |
------------------+------------+-----+--------+--------+--------+--
^ ^ ^ ^
| | | |
(IP A) (IP A) (IP A) (IP A)
| | | |
+--+--+ +--+--+ +--+--+ +--+--+
| H1 | | H2 | | H3 | | H4 |
+-----+ +-----+ +--+--+ +--+--+
Legend:
---+---+---+-- = Ethernet, Token Ring, or FDDI
H = Host computer
MR = Master Router
BR = Backup Router
* = IP Address
(IP) = default router for hosts
Eliminating all mention of VRRP (VRID=1) from the figure above leaves it as a typical IP deployment. Each router is permanently assigned an IP address on the LAN interface (Rtr1 is assigned IP A and Rtr2 is assigned IP B), and each host installs a static default route through one of the routers (in this example they all use Rtr1's IP A).
上の図からVRRP（VRID = 1）のすべての言及を排除すると、典型的なIP展開として残ります。各ルーターにはLANインターフェイス上のIPアドレスが永続的に割り当てられます（RTR1にはIP Aが割り当てられ、RTR2にはIP Bが割り当てられます）。各ホストは、Routerの1つを介して静的デフォルトルートをインストールします（この例では、すべてRTR1のIP Aを使用します）。
Moving to the VRRP environment, each router has the exact same permanently assigned IP address. Rtr1 is said to be the IP address owner of IP A, and Rtr2 is the IP address owner of IP B. A virtual router is then defined by associating a unique identifier (the virtual router ID) with the address owned by a router. Finally, the VRRP protocol manages virtual router fail over to a backup router.
VRRP環境に移動すると、各ルーターには、まったく同じ永久に割り当てられたIPアドレスがあります。RTR1はIP AのIPアドレス所有者であると言われ、RTR2はIP BのIPアドレス所有者です。仮想ルーターは、一意の識別子（仮想ルーターID）をルーターが所有するアドレスに関連付けることによって定義されます。最後に、VRRPプロトコルは仮想ルーターの失敗をバックアップルーターに管理します。
The example above shows a virtual router configured to cover the IP address owned by Rtr1 (VRID=1,IP_Address=A). When VRRP is enabled on Rtr1 for VRID=1 it will assert itself as Master, with priority=255, since it is the IP address owner for the virtual router IP address. When VRRP is enabled on Rtr2 for VRID=1 it will transition to Backup, with priority=100, since it is not the IP address owner. If Rtr1 should fail then the VRRP protocol will transition Rtr2 to Master, temporarily taking over forwarding responsibility for IP A to provide uninterrupted service to the hosts.
上記の例は、RTR1（VRID = 1、IP_Address = A）が所有するIPアドレスをカバーするように構成された仮想ルーターを示しています。VRID = 1のrtr1でVRRPが有効になると、仮想ルーターIPアドレスのIPアドレス所有者であるため、優先度= 255でマスターとして自分自身を主張します。VRID = 1のRTR2でVRRPが有効になると、IPアドレスの所有者ではないため、優先度= 100でバックアップに移行します。RTR1が失敗する場合、VRRPプロトコルはRTR2をマスターに移行し、一時的にIP Aの責任を引き継ぎ、ホストに中断のないサービスを提供します。
Note that in this example IP B is not backed up, it is only used by Rtr2 as its interface address. In order to backup IP B, a second virtual router must be configured. This is shown in the next section.
この例では、IP Bがバックアップされていないことに注意してください。RTR2によってのみインターフェイスアドレスとして使用されていることに注意してください。IP Bをバックアップするには、2番目の仮想ルーターを構成する必要があります。これは次のセクションに示されています。
The following figure shows a configuration with two virtual routers with the hosts spitting their traffic between them. This example is expected to be very common in actual practice.
次の図は、ホストがトラフィックを吐き出す2つの仮想ルーターを備えた構成を示しています。この例は、実際の実践では非常に一般的であると予想されます。
+-----------+ +-----------+
| Rtr1 | | Rtr2 |
|(MR VRID=1)| |(BR VRID=1)|
|(BR VRID=2)| |(MR VRID=2)|
VRID=1 +-----------+ +-----------+ VRID=2
IP A ---------->* *<---------- IP B
| |
| |
------------------+------------+-----+--------+--------+--------+--
^ ^ ^ ^
| | | |
(IP A) (IP A) (IP B) (IP B)
| | | |
+--+--+ +--+--+ +--+--+ +--+--+
| H1 | | H2 | | H3 | | H4 |
+-----+ +-----+ +--+--+ +--+--+
Legend:
---+---+---+-- = Ethernet, Token Ring, or FDDI
H = Host computer
MR = Master Router
BR = Backup Router
* = IP Address
(IP) = default router for hosts
In the example above, half of the hosts have configured a static route through Rtr1's IP A and half are using Rtr2's IP B. The configuration of virtual router VRID=1 is exactly the same as in the first example (see section 4.1), and a second virtual router has been added to cover the IP address owned by Rtr2 (VRID=2, IP_Address=B). In this case Rtr2 will assert itself as Master for VRID=2 while Rtr1 will act as a backup. This scenario demonstrates a deployment providing load splitting when both routers are available while providing full redundancy for robustness.
上記の例では、ホストの半分がRTR1のIP Aを介して静的ルートを構成し、半分はRTR2のIP Bを使用しています。仮想ルーターVRID = 1の構成は、最初の例（セクション4.1を参照）とまったく同じです。RTR2（VRID = 2、IP_ADDRESS = B）が所有するIPアドレスをカバーするために、2番目の仮想ルーターが追加されています。この場合、RTR2はVRID = 2のマスターとして自分自身を主張し、RTR1はバックアップとして機能します。このシナリオは、両方のルーターが利用可能な場合に負荷分割を提供する展開を示しています。
The purpose of the VRRP packet is to communicate to all VRRP routers the priority and the state of the Master router associated with the Virtual Router ID.
VRRPパケットの目的は、すべてのVRRPルーターに、仮想ルーターIDに関連付けられたマスタールーターの優先度と状態を通信することです。
VRRP packets are sent encapsulated in IP packets. They are sent to the IPv4 multicast address assigned to VRRP.
VRRPパケットは、IPパケットにカプセル化されて送信されます。それらは、VRRPに割り当てられたIPv4マルチキャストアドレスに送信されます。
This section defines the format of the VRRP packet and the relevant fields in the IP header.
このセクションでは、VRRPパケットの形式とIPヘッダーの関連フィールドを定義します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Type | Virtual Rtr ID| Priority | Count IP Addrs|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth Type | Adver Int | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
| . |
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address (n) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication Data (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication Data (2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The primary IP address of the interface the packet is being sent from.
パケットが送信されているインターフェイスの主要なIPアドレス。
The IP multicast address as assigned by the IANA for VRRP is:
VRRPにIANAによって割り当てられたIPマルチキャストアドレスは次のとおりです。
224.0.0.18
224.0.0.18
This is a link local scope multicast address. Routers MUST NOT forward a datagram with this destination address regardless of its TTL.
これは、ローカルスコープマルチキャストアドレスのリンクです。ルーターは、TTLに関係なく、この宛先アドレスでデータグラムを転送してはなりません。
The TTL MUST be set to 255. A VRRP router receiving a packet with the TTL not equal to 255 MUST discard the packet.
TTLは255に設定する必要があります。255に等しくないTTLでパケットを受信するVRRPルーターは、パケットを破棄する必要があります。
The IP protocol number assigned by the IANA for VRRP is 112 (decimal).
VRRPにIANAによって割り当てられたIPプロトコル番号は112（小数）です。
The version field specifies the VRRP protocol version of this packet. This document defines version 2.
バージョンフィールドは、このパケットのVRRPプロトコルバージョンを指定します。このドキュメントはバージョン2を定義します。
The type field specifies the type of this VRRP packet. The only packet type defined in this version of the protocol is:
タイプフィールドは、このVRRPパケットのタイプを指定します。このバージョンのプロトコルで定義されている唯一のパケットタイプは次のとおりです。
1 ADVERTISEMENT
1広告
A packet with unknown type MUST be discarded.
未知のタイプのパケットを破棄する必要があります。
The Virtual Router Identifier (VRID) field identifies the virtual router this packet is reporting status for. Configurable item in the range 1-255 (decimal). There is no default.
仮想ルーター識別子（VRID）フィールドは、このパケットがレポートされている仮想ルーターを識別します。範囲1-255（小数）の構成可能なアイテム。デフォルトはありません。
The priority field specifies the sending VRRP router's priority for the virtual router. Higher values equal higher priority. This field is an 8 bit unsigned integer field.
優先フィールドは、仮想ルーターの送信VRRPルーターの優先度を指定します。より高い値は優先度が高い。このフィールドは、8ビット署名されていない整数フィールドです。
The priority value for the VRRP router that owns the IP address(es) associated with the virtual router MUST be 255 (decimal).
仮想ルーターに関連付けられているIPアドレスを所有するVRRPルーターの優先値は255（小数）でなければなりません。
VRRP routers backing up a virtual router MUST use priority values between 1-254 (decimal). The default priority value for VRRP routers backing up a virtual router is 100 (decimal).
仮想ルーターをバックアップするVRRPルーターは、1〜254（小数）の間の優先値を使用する必要があります。仮想ルーターをバックアップするVRRPルーターのデフォルト優先度値は100（小数）です。
The priority value zero (0) has special meaning indicating that the current Master has stopped participating in VRRP. This is used to trigger Backup routers to quickly transition to Master without having to wait for the current Master to timeout.
優先順位ゼロ（0）には、現在のマスターがVRRPへの参加を停止したことを示す特別な意味があります。これは、バックアップルーターをトリガーするために使用され、現在のマスターがタイムアウトするのを待たずにマスターにすばやく移行します。
The number of IP addresses contained in this VRRP advertisement.
このVRRP広告に含まれるIPアドレスの数。
The authentication type field identifies the authentication method being utilized. Authentication type is unique on a Virtual Router basis. The authentication type field is an 8 bit unsigned integer. A packet with unknown authentication type or that does not match the locally configured authentication method MUST be discarded.
認証タイプフィールドは、使用されている認証方法を識別します。認証タイプは、仮想ルーターベースで一意です。認証タイプフィールドは、8ビット署名の整数です。未知の認証タイプを備えたパケットまたはローカルで構成された認証方法と一致しないパケットは破棄する必要があります。
Note: Earlier version of the VRRP specification had several defined authentication types [RFC2338]. These were removed in this specification because operational experience showed that they did not provide any real security and would only cause multiple masters to be created.
注：VRRP仕様の以前のバージョンには、いくつかの定義された認証タイプがありました[RFC2338]。これらは、この仕様で削除されました。これは、運用エクスペリエンスが実際のセキュリティを提供せず、複数のマスターを作成するだけであることを示したためです。
The authentication methods currently defined are:
現在定義されている認証方法は次のとおりです。
0 - No Authentication 1 - Reserved 2 - Reserved
0-認証なし1-予約2-予約済み
The use of this authentication type means that VRRP protocol exchanges are not authenticated. The contents of the Authentication Data field should be set to zero on transmission and ignored on reception.
この認証タイプの使用は、VRRPプロトコル交換が認証されていないことを意味します。認証データフィールドのコンテンツは、送信時にゼロに設定し、受信で無視する必要があります。
This authentication type is reserved to maintain backwards compatibility with RFC 2338.
この認証タイプは、RFC 2338との逆方向の互換性を維持するために予約されています。
This authentication type is reserved to maintain backwards compatibility with RFC 2338.
この認証タイプは、RFC 2338との逆方向の互換性を維持するために予約されています。
The Advertisement interval indicates the time interval (in seconds) between ADVERTISEMENTS. The default is 1 second. This field is used for troubleshooting misconfigured routers.
広告間隔は、広告間の時間間隔（秒単位）を示します。デフォルトは1秒です。このフィールドは、誤ったルーターのトラブルシューティングに使用されます。
The checksum field is used to detect data corruption in the VRRP message.
チェックサムフィールドは、VRRPメッセージのデータ腐敗を検出するために使用されます。
The checksum is the 16-bit one's complement of the one's complement sum of the entire VRRP message starting with the version field. For computing the checksum, the checksum field is set to zero. See RFC 1071 for more detail [CKSM].
チェックサムは、バージョンフィールドから始まるVRRPメッセージ全体の補完合計を16ビットの補完です。チェックサムを計算するために、チェックサムフィールドはゼロに設定されています。詳細[CKSM]については、RFC 1071を参照してください。
One or more IP addresses that are associated with the virtual router. The number of addresses included is specified in the "Count IP Addrs" field. These fields are used for troubleshooting misconfigured routers.
仮想ルーターに関連付けられている1つ以上のIPアドレス。含まれるアドレスの数は、「カウントIP ADDRS」フィールドで指定されています。これらのフィールドは、誤ったルーターのトラブルシューティングに使用されます。
The authentication string is currently only used to maintain backwards compatibility with RFC 2338. It SHOULD be set to zero on transmission and ignored on reception.
認証文字列は現在、RFC 2338との逆方向の互換性を維持するためにのみ使用されます。送信時にゼロに設定し、受信で無視する必要があります。
VRID Virtual Router Identifier. Configurable item in the range 1-255 (decimal). There is no default.
VRID仮想ルーター識別子。範囲1-255（小数）の構成可能なアイテム。デフォルトはありません。
Priority Priority value to be used by this VRRP router in Master election for this virtual router. The value of 255 (decimal) is reserved for the router that owns the IP addresses associated with the virtual router. The value of 0 (zero) is reserved for Master router to indicate it is releasing responsibility for the virtual router. The range 1-254 (decimal) is available for VRRP routers backing up the virtual router. The default value is 100 (decimal).
この仮想ルーターのマスター選挙でこのVRRPルーターが使用する優先優先値。255（小数）の値は、仮想ルーターに関連付けられたIPアドレスを所有するルーターに予約されています。0（ゼロ）の値は、仮想ルーターの責任を解放していることを示すマスタールーターのために予約されています。範囲1-254（小数）は、仮想ルーターをバックアップするVRRPルーターで使用できます。デフォルト値は100（小数）です。
IP_Addresses One or more IP addresses associated with this virtual router. Configured item. No default.
IP_ADDRESSESこの仮想ルーターに関連付けられた1つ以上のIPアドレス。構成されたアイテム。デフォルトはありません。
Advertisement_Interval Time interval between ADVERTISEMENTS (seconds). Default is 1 second.
Advertisement_interval広告間の時間間隔（秒）。デフォルトは1秒です。
Skew_Time Time to skew Master_Down_Interval in seconds. Calculated as:
skew_time time to skew master_down_interval秒で。計算：
( (256 - Priority) / 256 )
（（256-優先度） / 256）
Master_Down_Interval Time interval for Backup to declare Master down (seconds). Calculated as:
Master_down_intervalマスターダウンを宣言するバックアップの時間間隔（秒）。計算：
(3 * Advertisement_Interval) + Skew_time
（3 * Advertisement_interval）skew_time
Preempt_Mode Controls whether a higher priority Backup router preempts a lower priority Master. Values are True to allow preemption and False to prohibit preemption. Default is True.
preempt_modeは、優先度の高いバックアップルーターが優先度の低いマスターを先取りするかどうかを制御します。値は、先制が先制を禁止することを許可するために真実です。デフォルトはtrueです。
Note: Exception is that the router that owns the IP address(es) associated with the virtual router always preempts independent of the setting of this flag.
注：例外は、仮想ルーターに関連付けられているIPアドレスを所有するルーターが、常にこのフラグの設定とは無関係であることです。
Authentication_Type Type of authentication being used. Values are defined in section 5.3.6.
Authentication_Type使用中の認証のタイプ。値はセクション5.3.6で定義されています。
Authentication_Data Authentication data specific to the Authentication_Type being used.
Authentication_Data認証データは、使用されているAuthentication_Typeに固有のデータ。
Master_Down_Timer Timer that fires when ADVERTISEMENT has not been heard for Master_Down_Interval.
Master_down_timerタイマーは、master_down_intervalの広告が聞こえないときに発射されます。
Adver_Timer Timer that fires to trigger sending of ADVERTISEMENT based on Advertisement_Interval.
ADVER_TIMERタイマーは、Advertisement_intervalに基づいて広告の送信をトリガーするために発射します。
+---------------+
+--------->| |<-------------+
| | Initialize | |
| +------| |----------+ |
| | +---------------+ | |
| | | |
| V V |
+---------------+ +---------------+
| |---------------------->| |
| Master | | Backup |
| |<----------------------| |
+---------------+ +---------------+
In the state descriptions below, the state names are identified by {state-name}, and the packets are identified by all upper case characters.
以下の状態の説明では、状態名は{State-Name}で識別され、パケットはすべての大文字で識別されます。
A VRRP router implements an instance of the state machine for each virtual router election it is participating in.
VRRPルーターは、参加している各仮想ルーター選挙のために状態マシンのインスタンスを実装します。
The purpose of this state is to wait for a Startup event. If a Startup event is received, then:
この州の目的は、スタートアップイベントを待つことです。スタートアップイベントを受け取った場合、
- If the Priority = 255 (i.e., the router owns the IP address(es) associated with the virtual router)
- 優先度= 255の場合（つまり、ルーターが仮想ルーターに関連付けられているIPアドレスを所有しています）
o Send an ADVERTISEMENT o Broadcast a gratuitous ARP request containing the virtual router MAC address for each IP address associated with the virtual router. o Set the Adver_Timer to Advertisement_Interval o Transition to the {Master} state
o Advertisementを送信o Virtual Routerに関連付けられた各IPアドレスの仮想ルーターMACアドレスを含む無償のARPリクエストをブロードキャストします。o adver_timerをadvertisement_intervalに設定しますo {master}状態への移行
else
それ以外そのほこのさもないと
o Set the Master_Down_Timer to Master_Down_Interval o Transition to the {Backup} state
o master_down_timerをmaster_down_interval o {backup}状態に移行する
endif
endif
The purpose of the {Backup} state is to monitor the availability and state of the Master Router.
{バックアップ}状態の目的は、マスタールーターの可用性と状態を監視することです。
While in this state, a VRRP router MUST do the following:
この状態では、VRRPルーターは次のことを行う必要があります。
- MUST NOT respond to ARP requests for the IP address(s) associated with the virtual router.
- 仮想ルーターに関連付けられたIPアドレスのARP要求に応答しないでください。
- MUST discard packets with a destination link layer MAC address equal to the virtual router MAC address.
- 仮想ルーターMACアドレスに等しい宛先リンクレイヤーMACアドレスでパケットを破棄する必要があります。
- MUST NOT accept packets addressed to the IP address(es) associated with the virtual router.
- 仮想ルーターに関連付けられているIPアドレスにアドレス指定されたパケットを受け入れてはなりません。
- If a Shutdown event is received, then:
- シャットダウンイベントを受信した場合、
o Cancel the Master_Down_Timer o Transition to the {Initialize} state
o master_down_timer o {初期化}状態への移行をキャンセルする
endif
endif
- If the Master_Down_Timer fires, then:
- master_down_timerが発射する場合、
o Send an ADVERTISEMENT o Broadcast a gratuitous ARP request containing the virtual router MAC address for each IP address associated with the virtual router o Set the Adver_Timer to Advertisement_Interval o Transition to the {Master} state
o Advertisementを送信するo放送仮想ルーターに関連付けられた各IPアドレスの仮想ルーターMACアドレスを含む無償ARPリクエストo adver_timerをadvertisement_interval o {master} stateに移行するように設定します
endif
endif
- If an ADVERTISEMENT is received, then:
- 広告が受信された場合、次のとおりです。
If the Priority in the ADVERTISEMENT is Zero, then:
広告の優先順位がゼロの場合、次のとおりです。
o Set the Master_Down_Timer to Skew_Time
o master_down_timerをskew_timeに設定します
else:
それ以外：
If Preempt_Mode is False, or If the Priority in the ADVERTISEMENT is greater than or equal to the local Priority, then:
preempt_modeがfalseである場合、または広告の優先順位がローカル優先度以上の場合は、次のとおりです。
o Reset the Master_Down_Timer to Master_Down_Interval
o master_down_timerをmaster_down_intervalにリセットします
else:
それ以外：
o Discard the ADVERTISEMENT
o 広告を破棄します
endif endif endif
endif endif endif
While in the {Master} state the router functions as the forwarding router for the IP address(es) associated with the virtual router.
{Master}では、ルーターは仮想ルーターに関連付けられたIPアドレスの転送ルーターとして機能します。
While in this state, a VRRP router MUST do the following:
この状態では、VRRPルーターは次のことを行う必要があります。
- MUST respond to ARP requests for the IP address(es) associated with the virtual router.
- 仮想ルーターに関連付けられたIPアドレスのARP要求に応答する必要があります。
- MUST forward packets with a destination link layer MAC address equal to the virtual router MAC address.
- 仮想ルーターMACアドレスに等しい宛先リンクレイヤーMACアドレスでパケットを転送する必要があります。
- MUST NOT accept packets addressed to the IP address(es) associated with the virtual router if it is not the IP address owner.
- IPアドレスの所有者ではない場合、仮想ルーターに関連付けられたIPアドレスにアドレス指定されたパケットを受け入れないでください。
- MUST accept packets addressed to the IP address(es) associated with the virtual router if it is the IP address owner.
- IPアドレスの所有者である場合、仮想ルーターに関連付けられたIPアドレスにアドレス指定されたパケットを受け入れる必要があります。
- If a Shutdown event is received, then:
- シャットダウンイベントを受信した場合、
o Cancel the Adver_Timer o Send an ADVERTISEMENT with Priority = 0 o Transition to the {Initialize} state
o ADVER_TIMER Oをキャンセルして、優先度を持って広告を送信します= 0 o {初期化}状態に移行します
endif
endif
- If the Adver_Timer fires, then:
- adver_timerが発射する場合、
o Send an ADVERTISEMENT o Reset the Adver_Timer to Advertisement_Interval
o Adver_timerをAdvertisement_intervalにリセットする広告を送信します
endif
endif
- If an ADVERTISEMENT is received, then:
- 広告が受信された場合、次のとおりです。
If the Priority in the ADVERTISEMENT is Zero, then:
広告の優先順位がゼロの場合、次のとおりです。
o Send an ADVERTISEMENT o Reset the Adver_Timer to Advertisement_Interval
o Adver_timerをAdvertisement_intervalにリセットする広告を送信します
else:
それ以外：
If the Priority in the ADVERTISEMENT is greater than the local Priority, or If the Priority in the ADVERTISEMENT is equal to the local Priority and the primary IP Address of the sender is greater than the local primary IP Address, then:
広告の優先順位が現地の優先度よりも大きい場合、または広告の優先順位がローカルの優先事項と等しく、送信者の主要なIPアドレスがローカルプライマリIPアドレスよりも大きい場合、次のとおりです。
o Cancel Adver_Timer o Set Master_Down_Timer to Master_Down_Interval o Transition to the {Backup} state
o Adver_timer o cancel o master_down_timerをmaster_down_interval o {backup}状態に移行する
else:
それ以外：
o Discard ADVERTISEMENT
o 広告を破棄します
endif endif endif
endif endif endif
Performed the following functions when a VRRP packet is received:
VRRPパケットが受信されたときに次の機能を実行しました。
- MUST verify that the IP TTL is 255. - MUST verify the VRRP version is 2. - MUST verify that the received packet contains the complete VRRP packet (including fixed fields, IP Address(es), and Authentication Data). - MUST verify the VRRP checksum. - MUST verify that the VRID is configured on the receiving interface and the local router is not the IP Address owner (Priority equals 255 (decimal)). - MUST verify that the Auth Type matches the locally configured authentication method for the virtual router and perform that authentication method.
- IP TTLが255であることを確認する必要があります。-VRRPバージョンが2であることを確認する必要があります。-受信パケットに完全なVRRPパケット（固定フィールド、IPアドレス、および認証データを含む）が含まれていることを確認する必要があります。-VRRPチェックサムを確認する必要があります。-VRIDが受信インターフェイスで構成されており、ローカルルーターがIPアドレスの所有者ではないことを確認する必要があります（優先度255（小数））。-AUTHタイプが仮想ルーターのローカル構成認証方法と一致し、その認証方法を実行することを確認する必要があります。
If any one of the above checks fails, the receiver MUST discard the packet, SHOULD log the event and MAY indicate via network management that an error occurred.
上記のチェックのいずれかが失敗した場合、受信者はパケットを破棄し、イベントを記録する必要があり、ネットワーク管理を介してエラーが発生したことを示している可能性があります。
- MAY verify that "Count IP Addrs" and the list of IP Address matches the IP_Addresses configured for the VRID
- 「IP AddRをカウント」とIPアドレスのリストがVRID用に構成されたIP_ADDRESSESと一致することを確認できます
If the above check fails, the receiver SHOULD log the event and MAY indicate via network management that a misconfiguration was detected. If the packet was not generated by the address owner (Priority does not equal 255 (decimal)), the receiver MUST drop the packet, otherwise continue processing.
上記のチェックが失敗した場合、受信者はイベントを記録する必要があり、ネットワーク管理を通じて誤った構成が検出されたことを示している可能性があります。パケットがアドレス所有者によって生成されなかった場合（優先度が255（小数）等しくない）場合、受信者はパケットをドロップする必要があり、それ以外の場合は処理を継続する必要があります。
- MUST verify that the Adver Interval in the packet is the same as the locally configured for this virtual router
- パケット内のアドバー間隔がこの仮想ルーター用にローカルに構成されたものと同じであることを確認する必要があります
If the above check fails, the receiver MUST discard the packet, SHOULD log the event and MAY indicate via network management that a misconfiguration was detected.
上記のチェックが失敗した場合、受信者はパケットを破棄し、イベントをログに記録する必要があり、ネットワーク管理を介して誤った構成が検出されたことを示している可能性があります。
The following operations MUST be performed when transmitting a VRRP packet.
VRRPパケットを送信するときは、次の操作を実行する必要があります。
- Fill in the VRRP packet fields with the appropriate virtual router configuration state - Compute the VRRP checksum - Set the source MAC address to Virtual Router MAC Address - Set the source IP address to interface primary IP address - Set the IP protocol to VRRP - Send the VRRP packet to the VRRP IP multicast group
- 適切な仮想ルーター構成状態でVRRPパケットフィールドに入力します-VRRPチェックサムを計算 - ソースMACアドレスを仮想ルーターに設定 - ソースIPアドレスをプライマリIPアドレスのインターフェースに設定 - IPプロトコルをVRRPに設定 - VRRP IPマルチキャストグループへのVRRPパケット
Note: VRRP packets are transmitted with the virtual router MAC address as the source MAC address to ensure that learning bridges correctly determine the LAN segment the virtual router is attached to.
注：VRRPパケットは、ソースMACアドレスとして仮想ルーターMACアドレスで送信され、学習ブリッジが仮想ルーターが取り付けられているLANセグメントを正しく決定することを確認します。
The virtual router MAC address associated with a virtual router is an IEEE 802 MAC Address in the following format:
仮想ルーターに関連付けられた仮想ルーターMACアドレスは、次の形式のIEEE 802 Macアドレスです。
00-00-5E-00-01-{VRID} (in hex in internet standard bit-order)
00-00-5E-00-01- {vrid}（インターネット標準ビットオーダーの16進体）
The first three octets are derived from the IANA's OUI. The next two octets (00-01) indicate the address block assigned to the VRRP protocol. {VRID} is the VRRP Virtual Router Identifier. This mapping provides for up to 255 VRRP routers on a network.
最初の3つのオクテットは、IANAのOUIから派生しています。次の2つのオクテット（00-01）は、VRRPプロトコルに割り当てられたアドレスブロックを示しています。{vrid}はVRRP仮想ルーター識別子です。このマッピングは、ネットワーク上の最大255 VRRPルーターを提供します。
ICMP Redirects may be used normally when VRRP is running between a group of routers. This allows VRRP to be used in environments where the topology is not symmetric.
ICMPリダイレクトは、VRRPがルーターのグループ間で実行されているときに通常使用できます。これにより、トポロジーが対称ではない環境でVRRPを使用できます。
The IP source address of an ICMP redirect should be the address the end host used when making its next hop routing decision. If a VRRP router is acting as Master for virtual router(s) containing addresses it does not own, then it must determine which virtual router the packet was sent to when selecting the redirect source address. One method to deduce the virtual router used is to examine the destination MAC address in the packet that triggered the redirect.
ICMPリダイレクトのIPソースアドレスは、次のホップルーティング決定を行う際に使用されるエンドホストのアドレスである必要があります。VRRPルーターが所有していないアドレスを含む仮想ルーターのマスターとして機能している場合、リダイレクトソースアドレスを選択するときにパケットが送信された仮想ルーターを決定する必要があります。使用される仮想ルーターを推定する1つの方法は、リダイレクトをトリガーしたパケット内の宛先MACアドレスを調べることです。
It may be useful to disable Redirects for specific cases where VRRP is being used to load share traffic between a number of routers in a symmetric topology.
対称トポロジーの多くのルーター間で共有トラフィックをロードするためにVRRPが使用されている特定のケースに対してリダイレクトを無効にすると便利かもしれません。
When a host sends an ARP request for one of the virtual router IP addresses, the Master virtual router MUST respond to the ARP request with the virtual MAC address for the virtual router. The Master virtual router MUST NOT respond with its physical MAC address. This allows the client to always use the same MAC address regardless of the current Master router.
ホストが仮想ルーターIPアドレスの1つに対してARP要求を送信する場合、マスター仮想ルーターは、仮想ルーターの仮想MACアドレスを使用してARP要求に応答する必要があります。マスター仮想ルーターは、物理MACアドレスで応答してはなりません。これにより、クライアントは現在のマスタールーターに関係なく、常に同じMacアドレスを使用できます。
When a VRRP router restarts or boots, it SHOULD not send any ARP messages with its physical MAC address for the IP address it owns, it should only send ARP messages that include Virtual MAC addresses. This may entail:
VRRPルーターが再起動またはブーツを再起動したりする場合、所有するIPアドレスの物理MACアドレスを含むARPメッセージを送信しないでください。仮想MACアドレスを含むARPメッセージのみを送信する必要があります。これには次のことが伴う場合があります。
- When configuring an interface, VRRP routers should broadcast a gratuitous ARP request containing the virtual router MAC address for each IP address on that interface.
- インターフェイスを構成する場合、VRRPルーターは、そのインターフェイス上の各IPアドレスの仮想ルーターMACアドレスを含む無償のARPリクエストをブロードキャストする必要があります。
- At system boot, when initializing interfaces for VRRP operation; delay gratuitous ARP requests and ARP responses until both the IP address and the virtual router MAC address are configured.
- System Bootで、VRRP操作のインターフェイスを初期化するとき。IPアドレスと仮想ルーターMACアドレスの両方が構成されるまで、無償のARPリクエストとARP応答を遅らせます。
If Proxy ARP is to be used on a VRRP router, then the VRRP router must advertise the Virtual Router MAC address in the Proxy ARP message. Doing otherwise could cause hosts to learn the real MAC address of the VRRP router.
プロキシARPをVRRPルーターで使用する場合、VRRPルーターはプロキシARPメッセージで仮想ルーターMACアドレスを宣伝する必要があります。そうでなければ、ホストがVRRPルーターの実際のMACアドレスを学習する可能性があります。
A VRRP router SHOULD not forward packets addressed to the IP Address(es) it becomes Master for if it is not the owner. Forwarding these packets would result in unnecessary traffic. Also in the case of LANs that receive packets they transmit (e.g., token ring) this can result in a forwarding loop that is only terminated when the IP TTL expires.
VRRPルーターは、IPアドレスにアドレス指定されたパケットを転送してはなりません（ES）所有者でない場合にマスターになります。これらのパケットを転送すると、不必要なトラフィックが発生します。また、彼らが送信するパケットを受け取るLANの場合（例：トークンリング）、これにより、IP TTLの有効期限が切れたときにのみ終了する転送ループが得られます。
One such mechanism for VRRP routers is to add/delete a reject host route for each adopted IP address when transitioning to/from MASTER state.
VRRPルーターのそのようなメカニズムの1つは、マスター状態に遷移するときに、採用された各IPアドレスの拒否ホストルートを追加/削除することです。
FDDI interfaces remove from the FDDI ring frames that have a source MAC address matching the device's hardware address. Under some conditions, such as router isolations, ring failures, protocol transitions, etc., VRRP may cause there to be more than one Master router. If a Master router installs the virtual router MAC address as the hardware address on a FDDI device, then other Masters' ADVERTISEMENTS will be removed from the ring during the Master convergence, and convergence will fail.
FDDIインターフェイスは、デバイスのハードウェアアドレスに一致するソースMACアドレスを持つFDDIリングフレームから削除されます。ルーターの分離、リング障害、プロトコル遷移などのいくつかの条件下では、VRRPが複数のマスタールーターがある可能性があります。マスタールーターがFDDIデバイスのハードウェアアドレスとして仮想ルーターMACアドレスをインストールすると、マスターコンバージェンス中に他のマスターの広告がリングから削除され、収束が失敗します。
To avoid this an implementation SHOULD configure the virtual router MAC address by adding a unicast MAC filter in the FDDI device, rather than changing its hardware MAC address. This will prevent a Master router from removing any ADVERTISEMENTS it did not originate.
これを回避するには、実装では、ハードウェアMACアドレスを変更するのではなく、FDDIデバイスにユニキャストMACフィルターを追加して、仮想ルーターMACアドレスを構成する必要があります。これにより、マスタールーターが発生しなかった広告を削除することができなくなります。
Token ring has several characteristics that make running VRRP difficult. These include:
トークンリングには、実行のVRRPを難しくするいくつかの特性があります。これらには以下が含まれます：
- In order to switch to a new master located on a different bridge token ring segment from the previous master when using source route bridges, a mechanism is required to update cached source route information.
- ソースルートブリッジを使用するときに、前のマスターの別のブリッジトークンリングセグメントにある新しいマスターに切り替えるには、キャッシュされたソースルート情報を更新するためにメカニズムが必要です。
- No general multicast mechanism supported across old and new token ring adapter implementations. While many newer token ring adapters support group addresses, token ring functional address support is the only generally available multicast mechanism. Due to the limited number of token ring functional addresses these may collide with other usage of the same token ring functional addresses.
- 古いトークンリングアダプターの実装でサポートされている一般的なマルチキャストメカニズムはありません。多くの新しいトークンリングアダプターがグループアドレスをサポートしていますが、トークンリング機能アドレスサポートは、一般的に利用可能な唯一のマルチキャストメカニズムです。トークンリング機能アドレスの数が限られているため、これらは同じトークンリング機能アドレスの他の使用と衝突する可能性があります。
Due to these difficulties, the preferred mode of operation over token ring will be to use a token ring functional address for the VRID virtual MAC address. Token ring functional addresses have the two high order bits in the first MAC address octet set to B'1'. They range from 03-00-00-00-00-80 to 03-00-02-00-00-00 (canonical format). However, unlike multicast addresses, there is only one unique functional address per bit position. The functional addresses 03-00-00-10-00-00 through 03-00-02-00-00-00 are reserved by the Token Ring Architecture [TKARCH] for user-defined applications. However, since there are only 12 user-defined token ring functional addresses, there may be other non-IP protocols using the same functional address. Since the Novell IPX [IPX] protocol uses the 03-00-00-10-00-00 functional address, operation of VRRP over token ring will avoid use of this functional address. In general, token ring VRRP users will be responsible for resolution of other user-defined token ring functional address conflicts.
これらの困難により、トークンリングよりも優先される動作モードは、VRID仮想MACアドレスにトークンリング機能アドレスを使用することです。トークンリング機能アドレスには、最初のMacアドレスOctetにB'1 'に設定された2つの高次ビットがあります。03-00-00-00-00-80から03-00-02-00-00-00-00（標準形式）の範囲です。ただし、マルチキャストアドレスとは異なり、ビット位置ごとに一意の機能アドレスは1つだけです。関数アドレス03-00-10-00-00から03-00-02-00-00-00は、ユーザー定義のアプリケーションのトークンリングアーキテクチャ[Tkarch]によって予約されています。ただし、ユーザー定義のトークンリング機能アドレスは12個しかないため、同じ機能アドレスを使用して他の非IPプロトコルがある場合があります。Novell IPX [IPX]プロトコルは03-00-00-10-00-00の機能アドレスを使用しているため、トークンリングを介したVRRPの動作はこの機能アドレスの使用を回避します。一般に、トークンリングVRRPユーザーは、他のユーザー定義のトークンリング機能アドレスの競合の解決に責任を負います。
VRIDs are mapped directly to token ring functional addresses. In order to decrease the likelihood of functional address conflicts, allocation will begin with the largest functional address. Most non-IP protocols use the first or first couple user-defined functional addresses and it is expected that VRRP users will choose VRIDs sequentially starting with 1.
VRIDは、トークンリング機能アドレスに直接マッピングされます。機能アドレスの競合の可能性を減らすために、割り当ては最大の機能アドレスから始まります。ほとんどの非IPプロトコルは、最初のまたは最初のカップルまたは最初のカップルで定義された機能アドレスを使用し、VRRPユーザーが1から順次開始するVRIDを選択することが期待されます。
VRID Token Ring Functional Address
---- -----------------------------
1 03-00-02-00-00-00
2 03-00-04-00-00-00
3 03-00-08-00-00-00
4 03-00-10-00-00-00
5 03-00-20-00-00-00
6 03-00-40-00-00-00
7 03-00-80-00-00-00
8 03-00-00-01-00-00
9 03-00-00-02-00-00
10 03-00-00-04-00-00
11 03-00-00-08-00-00
Or more succinctly, octets 3 and 4 of the functional address are equal to (0x4000 >> (VRID - 1)) in non-canonical format.
より簡潔に、機能アドレスのオクテット3と4は、非標準形式で（0x4000 >>（vrid -1））に等しくなります。
Since a functional address cannot be used as a MAC level source address, the real MAC address is used as the MAC source address in VRRP advertisements. This is not a problem for bridges since packets addressed to functional addresses will be sent on the spanning-tree explorer path [802.1D].
機能アドレスはMacレベルのソースアドレスとして使用できないため、実際のMacアドレスはVRRP広告のMacソースアドレスとして使用されます。機能的なアドレスにアドレス指定されたパケットは、スパニングツリーエクスプローラーパス[802.1d]で送信されるため、これは橋にとっては問題ではありません。
The functional address mode of operation MUST be implemented by routers supporting VRRP on token ring.
操作の機能アドレスモードは、トークンリング上のVRRPをサポートするルーターによって実装する必要があります。
Additionally, routers MAY support unicast mode of operation to take advantage of newer token ring adapter implementations that support non-promiscuous reception for multiple unicast MAC addresses and to avoid both the multicast traffic and usage conflicts associated with the use of token ring functional addresses. Unicast mode uses the same mapping of VRIDs to virtual MAC addresses as Ethernet. However, one important difference exists. ARP request/reply packets contain the virtual MAC address as the source MAC address. The reason for this is that some token ring driver implementations keep a cache of MAC address/source routing information independent of the ARP cache. Hence, these implementations need to receive a packet with the virtual MAC address as the source address in order to transmit to that MAC address in a source-route bridged network.
さらに、ルーターはユニキャスト操作モードをサポートして、複数のユニキャストMACアドレスの非普及受信をサポートする新しいトークンリングアダプターの実装を活用し、トークンリング機能アドレスの使用に関連するマルチキャストトラフィックと使用競合の両方を回避する場合があります。ユニキャストモードは、VRIDと仮想Macアドレスと同じマッピングをイーサネットと使用します。ただし、1つの重要な違いが存在します。ARP要求/返信パケットには、ソースMACアドレスとして仮想MACアドレスが含まれています。この理由は、一部のトークンリングドライバーの実装が、ARPキャッシュとは無関係にMacアドレス/ソースルーティング情報のキャッシュを保持しているためです。したがって、これらの実装は、ソースルートのブリッジネットワークでそのMacアドレスに送信するために、Sourceアドレスとして仮想MACアドレスを含むパケットを受信する必要があります。
Unicast mode on token ring has one limitation that should be considered. If there are VRID routers on different source-route bridge segments and there are host implementations that keep their source-route information in the ARP cache and do not listen to gratuitous ARPs, these hosts will not update their ARP source-route information correctly when a switch-over occurs. The only possible solution is to put all routers with the same VRID on the same source-bridge segment and use techniques to prevent that bridge segment from being a single point of failure. These techniques are beyond the scope this document.
トークンリングのユニキャストモードには、考慮すべき1つの制限があります。さまざまなソースルートブリッジセグメントにVRIDルーターがあり、ソースルート情報をARPキャッシュに保持し、無償のARPを聴かないホストの実装がある場合、これらのホストはARPソースルート情報を正しく更新しません。スイッチオーバーが発生します。唯一の可能な解決策は、同じVRIDを持つすべてのルーターを同じソースブリッジセグメントに配置し、そのブリッジセグメントが単一の障害にならないようにテクニックを使用することです。これらの手法は、このドキュメントの範囲を超えています。
For both the multicast and unicast mode of operation, VRRP advertisements sent to 224.0.0.18 should be encapsulated as described in [RFC1469].
マルチキャストとユニキャストの両方の動作モードでは、[RFC1469]で説明されているように、224.0.0.18に送信されたVRRP広告をカプセル化する必要があります。
Operation of VRRP over ATM LANE on routers with ATM LANE interfaces and/or routers behind proxy LEC's are beyond the scope of this document.
プロキシLECの背後にあるATMレーンインターフェイスおよび/またはルーターを備えたルーター上のATMレーン上のVRRPの動作は、このドキュメントの範囲を超えています。
VRRP does not currently include any type of authentication. Earlier versions of the VRRP specification included several types of authentication ranging from none to strong. Operational experience and further analysis determined that these did not provide any real measure of security. Due to the nature of the VRRP protocol, even if VRRP messages are cryptographically protected, it does not prevent hostile routers from behaving as if they are a VRRP master, creating multiple masters. Authentication of VRRP messages could have prevented a hostile router from causing all properly functioning routers from going into backup state. However, having multiple masters can cause as much disruption as no routers, which authentication cannot prevent. Also, even if a hostile router could not disrupt VRRP, it can disrupt ARP and create the same effect as having all routers go into backup.
VRRPには現在、いかなるタイプの認証も含まれていません。VRRP仕様の以前のバージョンには、存在から強力なものまでのいくつかのタイプの認証が含まれていました。運用の経験とさらなる分析により、これらは実際のセキュリティの尺度を提供しないと判断しました。VRRPプロトコルの性質により、VRRPメッセージが暗号化されている場合でも、敵対的なルーターがVRRPマスターであるかのように動作することを妨げず、複数のマスターを作成します。VRRPメッセージの認証により、敵対的なルーターがすべての適切に機能するルーターがバックアップ状態になるのを防ぐことができた可能性があります。ただし、複数のマスターを持つことは、ルーターと同じくらい多くの混乱を引き起こす可能性があり、認証は防止できません。また、敵対的なルーターがVRRPを破壊できなかったとしても、ARPを破壊し、すべてのルーターをバックアップに入れるのと同じ効果を生み出すことができます。
It should be noted that these attacks are not worse and are a subset of the attacks that any node attached to a LAN can do independently of VRRP. The kind of attacks a malicious node on a LAN can do include promiscuously receiving packets for any routers MAC address, sending packets with the routers MAC address as the source MAC addresses in the L2 header to tell the L2 switches to send packets addressed to the router to the malicious node instead of the router, send redirects to tell the hosts to send their traffic somewhere else, send unsolicited ARP replies, answer ARP requests, etc., etc. All of this can be done independently of implementing VRRP. VRRP does not add to these vulnerabilities.
これらの攻撃は悪化しておらず、LANに接続されたノードがVRRPとは独立して行うことができる攻撃のサブセットであることに注意する必要があります。LAN上の悪意のあるノードが行うことができる攻撃の種類には、任意のルーターMACアドレスの無差別に受信されるパケットが含まれます。L2ヘッダーのソースMACアドレスとして、ルーターMACアドレスのパケットを送信して、L2スイッチを指示してルーターにアドレス指定されたパケットを送信するように指示します。ルーターの代わりに悪意のあるノードに、リダイレクトを送信して、ホストにトラフィックをどこか別の場所に送信するように指示し、未承諾ARP返信、ARPリクエストに応答するなどを送信します。これはすべてVRRPの実装とは無関係に行うことができます。VRRPはこれらの脆弱性を追加しません。
Independent of any authentication type VRRP includes a mechanism (setting TTL=255, checking on receipt) that protects against VRRP packets being injected from another remote network. This limits most vulnerabilities to local attacks.
認証タイプとは無関係に、VRRPには、別のリモートネットワークから注入されているVRRPパケットから保護するメカニズム（TTL = 255の設定、領収書を確認）が含まれています。これにより、ほとんどの脆弱性が地元の攻撃に対して制限されます。
VRRP does not provide any confidentiality. Confidentiality is not necessary for the correct operation of VRRP and there is no information in the VRRP messages that must be kept secret from other nodes on the LAN.
VRRPは機密性を提供しません。VRRPの正しい操作には機密性は必要ありません。VRRPメッセージには、LAN上の他のノードから秘密にしなければならない情報はありません。
The authors would like to thank Glen Zorn, and Michael Lane, Clark Bremer, Hal Peterson, Tony Li, Barbara Denny, Joel Halpern, Steve Bellovin, Thomas Narten, Rob Montgomery, Rob Coltun, Radia Perlman, Russ Housley, Harald Alvestrand, Steve Bellovin, Ned Freed, Ted Hardie, Russ Housley, Bert Wijnen, Bill Fenner, and Alex Zinin for their comments and suggestions.
著者は、グレン・ゾルン、マイケル・レーン、クラーク・ブレマー、ハル・ピーターソン、トニー・リー、バーバラ・デニー、ジョエル・ハルパーン、スティーブ・ベロヴィン、トーマス・ナルテン、ロブ・モンゴメリー、ロブ・コルトン、ラディア・ペルマン、ラス・ハウスリー、ハラルド・アルベストランド、スティーブに感謝したいと思います。ベロビン、ネッド・フリード、テッド・ハーディ、ラス・ヒューズリー、バート・ウィーネン、ビル・フェンナー、アレックス・ジニンのコメントと提案について。
[802.1D] International Standard ISO/IEC 10038: 1993, ANSI/IEEE Std 802.1D, 1993 edition.
[802.1d] International Standard ISO/IEC 10038：1993、ANSI/IEEE STD 802.1d、1993エディション。
[CKSM] Braden, R., Borman, D. and C. Partridge, "Computing the Internet checksum", RFC 1071, September 1988.
[CKSM] Braden、R.、Borman、D。and C. Partridge、「Internet Checksumのコンピューティング」、RFC 1071、1988年9月。
[HSRP] Li, T., Cole, B., Morton, P. and D. Li, "Cisco Hot Standby Router Protocol (HSRP)", RFC 2281, March 1998.
[HSRP] Li、T.、Cole、B.、Morton、P。and D. Li、「Cisco Hot Standby Router Protocol（HSRP）」、RFC 2281、1998年3月。
[IPSTB] Higginson, P. and M. Shand, "Development of Router Clusters to Provide Fast Failover in IP Networks", Digital Technical Journal, Volume 9 Number 3, Winter 1997.
[IPSTB] Higginson、P。およびM. Shand、「IPネットワークの高速フェールオーバーを提供するルータークラスターの開発」、デジタルテクニカルジャーナル、第9巻3、冬1997年。
[IPX] Novell Incorporated., "IPX Router Specification", Version 1.10, October 1992.
[IPX] Novell Incorporated。、「IPXルーター仕様」、バージョン1.10、1992年10月。
[RFC1469] Pusateri, T., "IP Multicast over Token Ring Local Area Networks", RFC 1469, June 1993.
[RFC1469] Pusateri、T。、「IPマルチキャストオーバートークンリングローカルエリアネットワーク」、RFC 1469、1993年6月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[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, April 1998.
[RFC2338] Knight、S.、Weaver、D.、Whipple、D.、Hinden、R.、Mitzel、D.、Hunt、P.、Higginson、P.、Shand、M. and A. Lindem、 "Virtual Router冗長プロトコル」、RFC 2338、1998年4月。
[TKARCH] IBM Token-Ring Network, Architecture Reference, Publication SC30-3374-02, Third Edition, (September, 1989).
[Tkarch] IBMトークンリングネットワーク、アーキテクチャリファレンス、出版SC30-3374-02、第3版（1989年9月）。
[DISC] Deering, S., Ed., "ICMP Router Discovery Messages", RFC 1256, September 1991.
[Disc] Deering、S.、ed。、「ICMPルーター発見メッセージ」、RFC 1256、1991年9月。
[DHCP] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[DHCP] Droms、R。、「動的ホスト構成プロトコル」、RFC 2131、1997年3月。
[OSPF] Moy, J., "OSPF version 2", STD 54, RFC 2328, April 1998.
[OSPF] Moy、J。、「OSPFバージョン2」、STD 54、RFC 2328、1998年4月。
[RIP] Malkin, G., "RIP Version 2", STD 56, RFC 2453, November 1998.
[RIP] Malkin、G。、「RIPバージョン2」、STD 56、RFC 2453、1998年11月。
- Moved authors of RFC 2338 to new Contributers section to comply with RFC editor policy and listed R. Hinden as Editor. - Removed authentication methods from VRRP. Changes included: o Removed the values for password and IPSEC based authentication. The fields and values are retained to keep backwards compatibility with RFC 2338. o Removed section on extensible security o Updated security consideration section to remove discussion of different authentication methods and added new text explaining motivation for change and describe vulnerabilities.
- RFC 2338の著者を新しい貢献者セクションに移動して、RFCエディターポリシーに準拠し、R。Hindenを編集者としてリストしました。-VRRPから認証方法を削除しました。変更：oパスワードとIPSECベースの認証の値を削除しました。フィールドと値は、RFC 2338との後方互換性を維持するために保持されます。O拡張可能なセキュリティに関するセクションを削除o更新されたセキュリティ検討セクションさまざまな認証方法の議論を削除し、変化の動機付けを説明し、脆弱性を説明する新しいテキストを追加しました。
- Revised the section 4 examples text with a clearer description of mapping of IP address owner, priorities, etc. - Clarify the section 7.1 text describing address list validation. - Corrected text in Preempt_Mode definition. - Changed authentication to be per Virtual Router instead of per Interface. - Added new subsection (9.3) stating that VRRP over ATM LANE is beyond the scope of this document. - Clarified text describing received packet length check. - Clarified text describing received authentication check. - Clarified text describing VRID verification check. - Added new subsection (8.4) describing need to not forward packets for adopted IP addresses. - Added clarification to the security considerations section. - Added reference for computing the internet checksum. - Updated references and author information. - Various small editorial changes.
- IPアドレス所有者のマッピング、優先順位などの明確な説明を含むセクション4の例を修正しました。-Preempt_mode定義でテキストを修正しました。 - インターフェイスごとではなく、仮想ルーターごとに認証を変更しました。-ATMレーン上のVRRPがこのドキュメントの範囲を超えていることを示す新しいサブセクション（9.3）を追加しました。 - 受信したパケット長チェックを説明する明確なテキスト。 - 受信した認証チェックを説明する明確なテキスト。-VRID検証チェックを説明する明確なテキスト。 - 採用されたIPアドレスのパケットを転送しない必要性を説明する新しいサブセクション（8.4）が追加されました。 - セキュリティに関する考慮事項セクションに説明を追加しました。 - インターネットチェックサムを計算するための参照を追加しました。 - 更新された参照と著者情報。 - さまざまな小さな編集上の変更。
Robert Hinden Nokia 313 Fairchild Drive Mountain View, CA 94043 US
ロバートヒンデンノキア313フェアチャイルドドライブマウンテンビュー、カリフォルニア94043米国
Phone: +1 650 625-2004
EMail: bob.hinden@nokia.com
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
著作権（c）The Internet Society（2004）。この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。