Network Working Group R. Hinden, Ed.
Request for Comments: 3768 Nokia
Obsoletes: 2338 April 2004
Category: Standards Track
Virtual Router Redundancy Protocol (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）インターネット協会（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.
すべてのエンドホスト上で動的ルーティングプロトコルを実行すると、管理オーバーヘッド、処理オーバーヘッド、セキュリティの問題、またはいくつかのプラットフォームのためのプロトコルの実装の欠如を含むいくつかの理由のために実行不可能であってもよいです。隣接またはルータ発見プロトコルは、ホストの多数の面で、プロトコルオーバーヘッドを減らすために大きなタイマ値をもたらす、ネットワーク上のすべてのホストによる積極的な参加を必要とするかもしれません。これは、許容できないほど長い「ブラックホール」の期間を導入することができる失われた（すなわち、死んだ）ネイバーの検出において有意な遅延をもたらし得ます。
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実装によってサポートされています。この動作モードは、典型的には、エンドホストのIPアドレスとデフォルトゲートウェイの構成を提供し、動的ホスト構成プロトコル[DHCP]展開されているが、持続する可能性があります。しかし、これは、単一障害点を作成します。利用可能である任意の代替パスを検出することができないすべてのエンドホストを単離する大惨事にデフォルトルータ結果の損失。
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は、独自のプロトコル "のHot Standby Router Protocol（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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "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. HindenとP.ハント、S.ナイト、A. Lindem、D. Mitzel、M.シャンド、D.ウィーバー、およびD.ウィップルあります。これらは、現在のRFC-Editorの政策による文書の作成者としてリストされていません。
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アドレスを持っているVRRPルータ。これは、ICMPピング、TCP接続などのためにこれらのIPアドレスの1つに宛て、アップ、パケットに応答しますルータです
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アドレス。一つの可能な選択アルゴリズムは常に最初のアドレスを選択することです。 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アドレス（複数可）に送信されたパケット転送の責任を想定し、これらのIPアドレスのARP要求に答えている仮想ルータマスターザ・VRRPルータ。 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.
マルチアクセスLAN上のIPパケットを送信すると、MACアドレスとIPアドレスのマッピングが必要です。拡張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仮想ルータは、それに割り当てられた単一のよく知られたMACアドレスを持っています。この文書では、現在、IEEE 802の48ビットMACアドレスを使用してネットワークへのマッピングを説明します。仮想ルータMACアドレスは、拡張LANでの学習ブリッジを有効にするには、マスタルータによって送信されたすべての定期的なVRRPメッセージの送信元として使用されています。
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.
次の図は、1台の仮想ルータを実装する2つのVRRPルータと簡単なネットワークを示しています。この例では、プロトコルを理解するために提供されていますが、実際に発生すると予想されていないことに注意してください。
+-----------+ +-----------+
| 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の展開としてそれを残します。各ルータは永久に（RTR1がIP AとRTR2が割り当てられているIP Bに割り当てられている）LANインターフェイス上でIPアドレスが割り当てられ、各ホストは、（この例では、それらのすべてがRTR1のIP Aを使用）ルーターの1つを介してスタティックデフォルトルートをインストールします。
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は、ルータが所有するアドレスを一意の識別子（仮想ルータID）を関連付けることによって定義されるIP B. Aの仮想ルータのIPアドレスの所有者です。最後に、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アドレスをカバーするように構成された仮想ルータを示しています。 VRRPがVRID = 1のためRTR1で有効になっているとき、それは仮想ルータのIPアドレスのIPアドレスの所有者であるので、それは、優先順位= 255で、マスターとしての地位を主張します。 VRRPがVRID = 1のためRTR2上で有効になっている場合、それはIPアドレスの所有者ではないので、それは、優先順位= 100で、バックアップに移行します。 RTR1が故障した場合、VRRPプロトコルは、一時的にIP Aがホストに中断のないサービスを提供するための責任を転送引き継ぐ、マスターにRTR2を移行します。
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のために、第二の仮想ルータを設定する必要があります。これは、次のセクションに示されています。
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.
上記の例では、ホストの半分は（セクション4.1を参照）仮想ルータVRID = 1の構成は実施例1と全く同じであるRTR2のIP B.を使用して、そしてれるRTR1のIP Aと半を通じて静的ルートを設定しています第二の仮想ルータはRTR2（VRID = 2、IP_Addressは= B）が所有しているIPアドレスをカバーするために追加されています。 RTR1がバックアップとして機能する一方、この場合にRTR2はVRID = 2のためのマスターとして自分自身をアサートします。このシナリオでは、堅牢性のための完全な冗長性を提供しながら、両方のルータが使用可能な場合、負荷分割を提供する展開を示しています。
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マルチキャストアドレスは次のとおりです。
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に等しくないTTLでパケットを受信したA VRRPルータがパケットを捨てなければなりません255に設定しなければなりません。
The IP protocol number assigned by the IANA for VRRP is 112 (decimal).
VRRPのためにIANAによって割り当てられたIPプロトコル番号は、112（10進数）です。
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 ADVERTISEMENT
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（10進数）に設定項目。デフォルトはありません。
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（10進数）でなければなりません。
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（10進数）の間の優先順位の値を使用しなければなりません。 VRRPルータが仮想ルータをバックアップするためのデフォルトのプライオリティ値は100（10進数）です。
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メッセージの1の補数和の16ビットの1の補数です。チェックサムを計算するために、チェックサムフィールドはゼロに設定されています。 [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（10進数）に設定項目。デフォルトはありません。
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（10進数）の値は、仮想ルータに関連付けられたIPアドレスを所有しているルータのために予約されています。 0（ゼロ）の値は、それが仮想ルータの責任をリリースしていることを示すためにマスタルータ用に予約されています。範囲1-254（10進数）仮想ルータをバックアップするVRRPルータのために利用可能です。デフォルト値は100（10進数）です。
IP_Addresses One or more IP addresses associated with this virtual router. Configured item. No default.
この仮想ルータに関連付けられた1つの以上のIPアドレスをIP_Addresses。構成されたアイテム。デフォルトなし。
Advertisement_Interval Time interval between ADVERTISEMENTS (seconds). Default is 1 second.
ADVERTISEMENTS（秒）の間のAdvertisement_Interval時間間隔。デフォルトは1秒です。
Skew_Time Time to skew Master_Down_Interval in seconds. Calculated as:
Skew_Time時間は秒単位で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とFalseです。デフォルトは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.
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_TYPEに特定AUTHENTICATION_DATA認証データが使用されています。
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タイマーは広告インターバルに基づいて広告の送信をトリガーするために発生させています。
+---------------+
+--------->| |<-------------+
| | 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.
以下の状態の説明では、状態名は{状態名}によって識別され、パケットは、すべての大文字によって識別されます。
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:
この状態の目的は、Startupイベントを待つことです。スタートアップイベントを受信した場合は、次のようになります。
- 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ブロードキャストoを仮想ルータに関連付けられたIPアドレスごとに仮想ルータのMACアドレスを含む無料のARP要求をADVERTISEMENTを送信します。 O {マスター}状態にAdver_TimerのAdvertisement_IntervalにO遷移を設定
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遷移を設定
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 0遷移をキャンセル
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 oをブロードキャスト{マスター}状態へのAdvertisement_Interval 0遷移にセットAdver_Timer O仮想ルータに関連付けられた各IPアドレスのための仮想ルータMACアドレスを含む無償ARP要求をADVERTISEMENTを送ります
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 Skew_TimeにMaster_Down_Timerを設定します。
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の場合、またはADVERTISEMENTにおける優先順位は、ローカル優先、以上の場合：
o Reset the Master_Down_Timer to Master_Down_Interval
O Master_Down_IntervalにMaster_Down_Timerをリセット
else:
他：
o Discard the ADVERTISEMENT
O ADVERTISEMENTを破棄
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.
{マスター}状態のルータ機能に仮想ルータに関連付けられた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優先的にADVERTISEMENTを送る= 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をリセットに広告を送ります
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をリセットに広告を送ります
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:
ADVERTISEMENTでの優先順位は、ローカルの優先度よりも高い場合、またはADVERTISEMENTでの優先順位は、ローカル優先順位に等しく、送信元のプライマリIPアドレスは、その後、ローカルのプライマリIPアドレスよりも大きい場合：
o Cancel Adver_Timer o Set Master_Down_Timer to Master_Down_Interval o Transition to the {Backup} state
O {バックアップ}状態に遷移oをMaster_Down_Intervalに設定Master_Down_Timer O Adver_Timerキャンセル
else:
他：
o Discard ADVERTISEMENT
O破棄ADVERTISEMENT
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 - で受信したパケットが（固定フィールド、IPアドレス（ES）、及び認証データを含む）完全なVRRPパケットが含まれていることを確認しなければなりません。 - VRRPチェックサムを確かめなければなりません。 - VRIDが受信インタフェースに設定され、ローカルルータは、IPアドレスの所有者（優先度は255（10進数）に等しい）ではないことを確かめなければなりません。 - 認証タイプは、仮想ルータのローカルに設定された認証方法と一致していることを確認し、その認証方法を実行しなければなりません。
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アドレスカウント」ことを確認し、IPアドレスのリストは、VRIDのために設定されたIPアドレスと一致してもよい（MAY）
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（10進数）と等しくない）によって生成されなかった場合、受信機は、そうでなければ処理を継続し、パケットを廃棄しなければなりません。
- MUST verify that the Adver Interval in the packet is the same as the locally configured for this virtual router
- パケット内Adver間隔が局所的にこの仮想ルータの構成と同じであることを確かめなければなりません
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アドレスを送信元MACアドレスを設定 - プライマリIPアドレスをインタフェースする送信元IPアドレスを設定します - VRRPにIPプロトコルを設定する - 送信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パケットは学習ブリッジが正しく仮想ルータが接続されたLANセグメントを決定することを保証するために送信元MACアドレスとして仮想ルータのMACアドレスを使用して送信されます。
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.
VRRPは、ルータのグループ間で実行されている場合、ICMPリダイレクトは、通常使用されてもよいです。これは、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.
- システム起動時に、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.
これを回避するために、実装は、FDDI装置にユニキャストMACフィルタを追加することはなく、そのハードウェア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アドレスのトークンリング機能アドレスを使用するようになります。トークンリング機能アドレスはB'1' に設定された第1のMACアドレスオクテット内の2つの上位ビットを有します。彼らは、03-00-00-00-00-80から03-00-02-00-00-00（標準形式）の範囲です。しかし、マルチキャストアドレスとは異なり、ビット位置ごとに1つだけのユニークな機能アドレスがあります。 03-00-00-10-00-00 03-00-02-00-00-00スルー機能アドレスは、ユーザー定義のアプリケーションのためにトークンリングアーキテクチャ[TKARCH]によって予約されています。わずか12ユーザ定義トークンリング機能アドレスがあるので、同じ機能アドレスを使用して他の非IPプロトコルが存在してもよいです。ノベル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（1）0x4000の>>（VRID）に等しいです。
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アドレスについて非無差別受信をサポートし、トークンリング機能アドレスの使用に関連するマルチキャストトラフィック及び使用の競合の両方を回避するために新しいトークンリングアダプターの実装を利用する動作のユニキャストモードをサポートするかもしれません。ユニキャストモードでは、イーサネットなどの仮想MACアドレスへのVRIDの同じマッピングを使用しています。しかし、一つの重要な違いが存在します。 ARP要求は/パケットが送信元MACアドレスとして仮想MACアドレスが含まれて返信。この理由は、いくつかのトークンリングドライバの実装は、ARPキャッシュの独立したルーティング情報をMACアドレス/ソースのキャッシュを保持していることです。したがって、これらの実装は、ネットワークブリッジソースルート内のそのMACアドレスに送信するために送信元アドレスとして仮想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.
ATM LANEインタフェースおよび/またはプロキシLECの背後にあるルータとルータのATM LANE以上の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仕様の以前のバージョンでは、noneからの強いまでの認証のいくつかのタイプが含まれています。運用経験とさらなる分析は、これらのセキュリティの任意の実際の測定値を提供していないと判断しました。 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上の悪意のあるノードは、パケットを送信するためにL2スイッチを伝えるためにL2ヘッダ内の送信元MACアドレスはルータ宛として、ルータMACアドレスを持つパケットを送信する、任意のルータMACアドレスのパケットを受信無差別に含まれないことができます代わりに、ルータの悪意があるノードに、どこか自分のトラフィックを送信するホストを伝えるためにリダイレクトを送信、送信、迷惑ARPは、このすべてが独立してVRRPを実装するのに行うことができるなど、など、ARP要求に応答、応答します。 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が正しく動作するために必要ではなく、LAN上の他のノードから秘密にしなければならないVRRPメッセージには情報はありません。
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.
著者はグレンソーン、そしてマイケル・レーン、クラークブレマー、ハル・ピーターソン、トニー・リー、バーバラ・デニー、ジョエル・ハルパーン、スティーブBellovin氏、トーマスNarten氏、ロブ・モンゴメリー、ロブColtun、ラディア・パールマン、ラスHousley、ハラルドAlvestrand、スティーブに感謝したいと思います彼らのコメントや提案のためBellovin氏、ネッドフリード、テッドハーディー、ラスHousley、バートWijnen、ビルフェナー、およびアレックスジニン。
[802.1D] International Standard ISO/IEC 10038: 1993, ANSI/IEEE Std 802.1D, 1993 edition.
[802.1D]国際規格ISO / IEC 10038：1993、ANSI / IEEE規格802.1D、1993年版。
[CKSM] Braden, R., Borman, D. and C. Partridge, "Computing the Internet checksum", RFC 1071, September 1988.
[CKSM]ブレーデン、R.、ボーマン、D.およびC.ヤマウズラ、 "インターネットチェックサムの計算"、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]李、T.、コール、B.、モートン、P。およびD.リー、 "シスコホットスタンバイルータプロトコル（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]ヒギンソン、P.とM.シャンド、デジタルテクニカル・ジャーナル、第9巻3号、冬1997「IPネットワークにおける高速フェイルオーバーを提供するために、ルータクラスタの開発」。
[IPX] Novell Incorporated., "IPX Router Specification", Version 1.10, October 1992.
[IPX]ノベル株式会社。、 "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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]ナイト、S.、ウィーバー、D.、ウィップル、D.、HindenとR.、Mitzel、D.、ハント、P.、ヒギンソン、P.、シャンド、M.及びA. Lindem、「仮想ルータ冗長プロトコル」、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版、（9月、1989）。
[DISC] Deering, S., Ed., "ICMP Router Discovery Messages", RFC 1256, September 1991.
[DISC]デアリング、S.、エド。、 "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]モイ、J.、 "OSPFバージョン2"、STD 54、RFC 2328、1998年4月。
[RIP] Malkin, G., "RIP Version 2", STD 56, RFC 2453, November 1998.
[RIP]マルキン、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ベースの認証のための値を削除しました。フィールドと値が異なる認証方法の議論を削除し、変更のための新しいテキスト説明モチベーションを追加し、脆弱性を説明するために更新、セキュリティの考慮セクションO拡張可能なセキュリティで除去セクションO RFC 2338との下位互換性を保つために保持されています。
- 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の例のテキストを改訂 - セクション7.1テキスト記述アドレスリストの検証を明確にします。 - Preempt_Mode定義で修正されたテキスト。 - 仮想ルータごとの代わりに、インターフェイスごとに変更の認証。 - ATM LANE以上のVRRPは、このドキュメントの範囲外であることを示す新しいサブセクション（9.3）を追加しました。 - 受信したパケット長チェックを説明明確化したテキスト。 - 受信した認証チェックを説明明確化したテキスト。 - VRIDの検証チェックを説明明確化したテキスト。 - 採用したIPアドレスのパケットを転送しないようにする必要性を説明新しいサブセクション（8.4）を追加しました。 - セキュリティの考慮事項のセクションに説明を追加しました。 - インターネットチェックサムを計算するための参照を追加。 - 参照と著者情報を更新しました。 - 様々な小さな編集上の変更。
Robert Hinden Nokia 313 Fairchild Drive Mountain View, CA 94043 US
ロバートHindenとノキア313フェアチャイルドドライブマウンテンビュー、カリフォルニア州94043米国
Phone: +1 650 625-2004 EMail: bob.hinden@nokia.com
電話：+1 650 625-2004 Eメール：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）インターネット協会（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 Editor機能のための基金は現在、インターネット協会によって提供されます。