[要約] RFC 2338は、仮想ルータの冗長性プロトコル（VRRP）に関するものであり、冗長なルータの構成とフェイルオーバーを提供するための仕様を定義しています。VRRPは、ネットワークの可用性と信頼性を向上させることを目的としています。
Network Working Group S. Knight
Request for Comments: 2338 D. Weaver
Category: Standards Track Ascend Communications, Inc.
D. Whipple
Microsoft, Inc.
R. Hinden
D. Mitzel
P. Hunt
Nokia
P. Higginson
M. Shand
Digital Equipment Corp.
A. Lindem
IBM Corporation
April 1998
Virtual Router Redundancy Protocol
仮想ルーター冗長プロトコル
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 (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
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
2. Required Features..........................................5
3. VRRP Overview..............................................6
4. Sample Configurations......................................8
5. Protocol...................................................9
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............................................13
6.2 Timers................................................15
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
9. Operation over FDDI and Token Ring........................21
9.1 Operation over FDDI...................................21
9.2 Operation over Token Ring.............................21
10. Security Considerations...................................23
10.1 No Authentication....................................23
10.2 Simple Text Password.................................23
10.3 IP Authentication Header.............................24
11. Acknowledgments...........................................24
12. References................................................24
13. Authors' Addresses........................................25
14. 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, which 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 a Cisco Systems, Inc. proprietary protocol named Hot Standby Router Protocol (HSRP) [HSRP] and to a Digital Equipment Corporation, Inc. proprietary protocol named IP Standby Protocol [IPSTB].
VRRPは、ホットスタンバイルータプロトコル（HSRP）[HSRP]という名前のCisco Systems、Inc.独自のプロトコルと、IPスタンバイプロトコル[IPSTB]という名前のDigital Equipment Corporation、Inc.独自のプロトコルに似た機能を提供します。
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 [RFC 2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC 2119]で説明されているように解釈されます。
The IESG/IETF take no position regarding the validity or scope of any intellectual property right or other rights that might be claimed to pertain to the implementation or use of the technology, or the extent to which any license under such rights might or might not be available. See the IETF IPR web page at http://www.ietf.org/ipr.html for additional information.
IESG / IETFは、技術の実装または使用に関連すると主張される可能性がある知的財産権またはその他の権利の有効性または範囲、またはそのような権利に基づくライセンスが適用されるかどうかに関係なく、いかなる立場も取らない利用可能です。詳細については、http：//www.ietf.org/ipr.htmlのIETF IPR Webページを参照してください。
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.
仮想ルーターVRRPによって管理される抽象オブジェクトで、共有LAN上のホストのデフォルトルーターとして機能します。これは、仮想ルーターIDと、共通の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 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アドレスに送信されたパケットを転送し、これらの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 more preferential than the current Master. It may be useful to support an override of the immediate convergence to the preferred path.
一部の環境では、現在のマスターよりも優先されるルーターが使用可能になったときにトリガーされる状態遷移を回避することが有益である場合があります。優先パスへの即時収束のオーバーライドをサポートすると役立つ場合があります。
The virtual router functionality is applicable to a wide range of internetworking environments that may employ different security policies. The protocol should require minimal configuration and overhead in the insecure operation, provide for strong authentication when increased security is required, and allow integration of new security mechanisms without breaking backwards compatible operation.
仮想ルーター機能は、さまざまなセキュリティポリシーを採用している可能性のある幅広いインターネットワーキング環境に適用できます。プロトコルは、安全でない操作で最小限の設定とオーバーヘッドを必要とし、セキュリティの強化が必要なときに強力な認証を提供し、下位互換性のある操作を壊すことなく新しいセキュリティメカニズムの統合を可能にする必要があります。
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パケットを送信するには、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.
仮想ルーターは、その仮想ルーター識別子（VRID）とIPアドレスのセットによって定義されます。 VRRPルーターは、仮想ルーターをインターフェイス上の実際のアドレスに関連付けることができます。また、追加の仮想ルーターマッピングと、バックアップを希望する仮想ルーターの優先度を設定することもできます。 VRIDとアドレス間のマッピングは、LAN上のすべてのVRRPルーター間で調整する必要があります。
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.
ただし、異なる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 pre-empt 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 pre-emption 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ルーターは常に、自身が所有するアドレスに関連付けられた仮想ルーターのマスターになることです。マスターが使用できなくなると、優先度の最も高いバックアップが少し遅れてマスターに移行し、サービスの中断を最小限に抑えて仮想ルーターの責任を制御して移行します。
VRRP defines three types of authentication providing simple deployment in insecure environments, added protection against misconfiguration, and strong sender authentication in security conscious environments. Analysis of the protection provided and vulnerability of each mechanism is deferred to Section 10.0 Security Considerations. In addition new authentication types and data can be defined in the future without affecting the format of the fixed portion of the protocol packet, thus preserving backward compatible operation.
VRRPは3種類の認証を定義し、安全でない環境での簡単な導入、設定ミスに対する保護の追加、セキュリティを重視する環境での強力な送信者認証を提供します。提供される保護と各メカニズムの脆弱性の分析は、セクション10.0のセキュリティに関する考慮事項に委ねられます。さらに、プロトコルパケットの固定部分のフォーマットに影響を与えることなく、将来的に新しい認証タイプとデータを定義できるため、下位互換性のある動作を維持できます。
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つの冗長ルーターおよび/または各ルーター間での異なるパス設定として定義されています。これらの仮定に違反した場合の副次的な影響（つまり、優先度がすべて等しい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ルーターを持つ単純なネットワークを示しています。この例はプロトコルの理解を助けるために提供されていますが、実際には実際に発生することは想定されていないことに注意してください。
+-----+ +-----+
| MR1 | | BR1 |
| | | |
| | | |
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
The above configuration shows a very simple VRRP scenario. In this configuration, the end-hosts install a default route to the IP address of virtual router #1 (IP A) and both routers run VRRP. The router on the left becomes the Master for virtual router #1 (VRID=1) and the router on the right is the Backup for virtual router #1. If the router on the left should fail, the other router will take over virtual router #1 and its IP addresses, and provide uninterrupted service for the hosts.
上記の設定は、非常に単純なVRRPシナリオを示しています。この構成では、エンドホストが仮想ルーター＃1（IP A）のIPアドレスへのデフォルトルートをインストールし、両方のルーターがVRRPを実行します。左側のルーターが仮想ルーター＃1（VRID = 1）のマスターになり、右側のルーターが仮想ルーター＃1のバックアップになります。左側のルーターに障害が発生した場合、他のルーターが仮想ルーター＃1とそのIPアドレスを引き継ぎ、ホストに中断のないサービスを提供します。
Note that in this example, IP B is not backed up by the router on the left. IP B is only used by the router on the right as its interface address. In order to backup IP B, a second virtual router would have to be configured. This is shown in the next section.
この例では、IP Bは左側のルーターによってバックアップされないことに注意してください。 IP Bは、右側のルーターのインターフェースアドレスとしてのみ使用されます。 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つの仮想ルーターが構成され、ホスト間でトラフィックが分割されている構成を示しています。この例は、実際には非常に一般的であると予想されます。
+-----+ +-----+
| MR1 | | MR2 |
| & | | & |
| BR2 | | BR1 |
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 above configuration, half of the hosts install a default route to virtual router #1's IP address (IP A), and the other half of the hosts install a default route to virtual router #2's IP address (IP B). This has the effect of load balancing the outgoing traffic, while also providing full redundancy.
上記の構成では、ホストの半分が仮想ルーター＃1のIPアドレス（IP A）へのデフォルトルートをインストールし、ホストの残りの半分が仮想ルーター＃2のIPアドレス（IP B）へのデフォルトルートをインストールします。これは、完全な冗長性を提供しながら、発信トラフィックの負荷を分散する効果があります。
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パケットの目的は、仮想ルーターIDに関連付けられたマスタールーターの優先度と状態をすべてのVRRPルーターと通信することです。
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:
IRPがVRRPに割り当てるIPマルチキャストアドレスは次のとおりです。
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に関係なく、この宛先アドレスでデータグラムを転送してはなりません（MUST NOT）。
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).
IRPがVRRPに割り当てるIPプロトコル番号は112（10進数）です。
The version field specifies the VRRP protocol version of this packet. This document defines version 2.
versionフィールドは、このパケットの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.
不明なタイプのパケットは破棄しなければなりません（MUST）。
The Virtual Router Identifier (VRID) field identifies the virtual router this packet is reporting status for.
仮想ルーター識別子（VRID）フィールドは、このパケットがステータスを報告している仮想ルーターを識別します。
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 per interface 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ビットの符号なし整数です。不明な認証タイプのパケット、またはローカルで設定された認証方法と一致しないパケットは破棄されなければなりません（MUST）。
The authentication methods currently defined are:
現在定義されている認証方法は次のとおりです。
0 - No Authentication 1 - Simple Text Password 2 - IP Authentication Header
0-認証なし1-単純なテキストパスワード2-IP認証ヘッダー
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プロトコル交換は認証されません。認証データフィールドの内容は、送信時にはゼロに設定され、受信時には無視されます。
The use of this authentication type means that VRRP protocol exchanges are authenticated by a clear text password. The contents of the Authentication Data field should be set to the locally configured password on transmission. There is no default password. The receiver MUST check that the Authentication Data in the packet matches its configured authentication string. Packets that do not match MUST be discarded.
この認証タイプの使用は、VRRPプロトコル交換がクリアテキストパスワードによって認証されることを意味します。 「認証データ」フィールドの内容は、送信時にローカルに構成されたパスワードに設定する必要があります。デフォルトのパスワードはありません。受信者は、パケット内の認証データが構成された認証文字列と一致することを確認する必要があります。一致しないパケットは破棄しなければなりません（MUST）。
Note that there are security implications to using Simple Text password authentication, and one should see the Security Consideration section of this document.
シンプルテキストパスワード認証の使用にはセキュリティの影響があることに注意してください。このドキュメントの「セキュリティに関する考慮事項」セクションを参照してください。
The use of this authentication type means the VRRP protocol exchanges are authenticated using the mechanisms defined by the IP Authentication Header [AUTH] using "The Use of HMAC-MD5-96 within ESP and AH" [HMAC]. Keys may be either configured manually or via a key distribution protocol.
この認証タイプの使用は、VRRPプロトコル交換が「ESPおよびAH内でのHMAC-MD5-96の使用」[HMAC]を使用するIP認証ヘッダー[AUTH]で定義されたメカニズムを使用して認証されることを意味します。キーは手動で、またはキー配布プロトコルを介して構成できます。
If a packet is received that does not pass the authentication check due to a missing authentication header or incorrect message digest, then the packet MUST be discarded. The contents of the Authentication Data field should be set to zero on transmission and ignored on reception.
認証ヘッダーの欠落または不正なメッセージダイジェストのために認証チェックに合格しないパケットが受信された場合、そのパケットは破棄されなければなりません（MUST）。認証データフィールドの内容は、送信時にはゼロに設定され、受信時には無視されます。
The Advertisement interval indicates the time interval (in seconds) between ADVERTISEMENTS. The default is 1 second. This field is used for troubleshooting misconfigured routers.
Advertisement intervalは、ADVERTISEMENTS間の時間間隔（秒単位）を示します。デフォルトは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.
チェックサムは、バージョンフィールドで始まるVRRPメッセージ全体の1の補数の合計の16ビットの1の補数です。チェックサムを計算するために、チェックサムフィールドはゼロに設定されます。
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アドレスのカウント」フィールドで指定されます。これらのフィールドは、誤って構成されたルーターのトラブルシューティングに使用されます。
The authentication string is currently only utilized for simple text authentication, similar to the simple text authentication found in the Open Shortest Path First routing protocol [OSPF]. It is up to 8 characters of plain text. If the configured authentication string is shorter than 8 bytes, the remaining space MUST be zero-filled. Any VRRP packet received with an authentication string that does not match the locally configured authentication string MUST be discarded. The authentication string is unique on a per interface basis.
認証文字列は現在、Open Shortest Path Firstルーティングプロトコル[OSPF]にあるシンプルテキスト認証と同様に、シンプルテキスト認証にのみ使用されます。最大8文字のプレーンテキストです。設定された認証文字列が8バイトより短い場合、残りのスペースはゼロで埋める必要があります。ローカルで構成された認証文字列と一致しない認証文字列で受信されたVRRPパケットは、破棄する必要があります。認証文字列は、インターフェイスごとに一意です。
There is no default value for this field.
このフィールドにはデフォルト値はありません。
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に固有の認証データ。
VRID Virtual Router Identifier. Configured 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（ゼロ）は、マスタールーターが仮想ルーターの責任を解放していることを示すために予約されています。仮想ルーターをバックアップするVRRPルーターでは、範囲1-254（10進数）を使用できます。デフォルト値は100（10進数）です。
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 ADVERTISEMENTS間の時間間隔（秒）。デフォルトは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 Backupがマスターのダウンを宣言する時間間隔（秒）。次のように計算されます：
(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 not 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 pre-empts independent of the setting of this flag.
注：例外は、仮想ルーターに関連付けられたIPアドレスを所有するルーターが、このフラグの設定に関係なく常にプリエンプトすることです。
Master_Down_Timer Timer that fires when ADVERTISEMENT has not been heard for Master_Down_Interval.
Master_Down_Timer ADVERTISEMENTがMaster_Down_Intervalの間聞こえなかったときに起動するタイマー。
Adver_Timer Timer that fires to trigger sending of ADVERTISEMENT based on Advertisement_Interval.
Adverisement Intervalに基づいてADVERTISEMENTの送信をトリガーするために起動する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.
以下の状態の説明では、状態名は{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仮想ルーターに関連付けられた各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.
{Backup}状態の目的は、マスタールーターの可用性と状態を監視することです。
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 NOT）。
- 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アドレス宛のパケットを受け入れてはならない（MUST NOT）。
- If a Shutdown event is received, then:
- シャットダウンイベントを受信した場合：
o Cancel the Master_Down_Timer o Transition to the {Initialize} state
o Master_Down_Timerをキャンセルしますo {Initialize}状態への移行
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}状態に遷移する
endif
endif
- If an ADVERTISEMENT is received, then:
- ADVERTISEMENTが受信されると、次のようになります。
If the Priority in the ADVERTISEMENT is Zero, then:
ADVERTISEMENTの優先度がゼロの場合、次のようになります。
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の場合、またはADVERTISEMENTの優先度がローカルの優先度以上の場合、次のようになります。
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.
{マスター}状態では、ルーターは仮想ルーターに関連付けられた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 NOT）。
- 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でADVERTISEMENTを送信しますo {Initialize}状態に移行します
endif
endif
- If the Adver_Timer fires, then:
- Adver_Timerが発生した場合：
o Send an ADVERTISEMENT o Reset the Adver_Timer to Advertisement_Interval
o ADVERTISEMENTを送信して、Adver_Timerを広告間隔にリセットします。
endif
endif
- If an ADVERTISEMENT is received, then:
- ADVERTISEMENTが受信されると、次のようになります。
If the Priority in the ADVERTISEMENT is Zero, then:
ADVERTISEMENTの優先度がゼロの場合、次のようになります。
o Send an ADVERTISEMENT o Reset the Adver_Timer to Advertisement_Interval
o ADVERTISEMENTを送信して、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 Adver_Timerをキャンセル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 - MUST verify that the received packet length is greater than or equal to the VRRP header - MUST verify the VRRP checksum - MUST perform authentication specified by Auth Type
- IP TTLが255であることを確認する必要があります。-VRRPバージョンを確認する必要があります-受信したパケット長がVRRPヘッダー以上であることを確認する必要があります-VRRPチェックサムを確認する必要があります-Auth Typeで指定された認証を実行する必要があります
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.
上記のチェックのいずれかが失敗した場合、受信者はパケットを破棄しなければならず（MUST）、イベントをログに記録し（SHOULD）、ネットワーク管理を介してエラーが発生したことを示してもよい（MAY）。
- MUST verify that the VRID is valid on the receiving interface
- VRIDが受信インターフェイスで有効であることを確認する必要があります
If the above check fails, the receiver MUST discard the packet.
上記のチェックが失敗した場合、受信者はパケットを破棄しなければなりません（MUST）。
- MAY verify that the IP address(es) associated with the VRID are valid
- VRIDに関連付けられたIPアドレスが有効であることを確認できます
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.
上記のチェックが失敗した場合、受信者はイベントをログに記録する必要があり（SHOULD）、ネットワーク管理を介して、設定ミスが検出されたことを示すことができます（MAY）。パケットがアドレス所有者によって生成されなかった場合（優先度が255（10進数）に等しくない場合）、受信者はパケットをドロップする必要があります。
- MUST verify that the Adver Interval in the packet is the same as the locally configured for this virtual router
- パケットのAdver Intervalが、この仮想ルーター用にローカルに構成されたものと同じであることを確認する必要があります
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.
上記のチェックが失敗した場合、受信者はパケットを破棄しなければならず（MUST）、イベントをログに記録し（SHOULD）、ネットワーク管理を介して設定ミスが検出されたことを示してもよい（MAY）。
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アドレスを設定します-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アドレスで応答してはなりません（MUST NOT）。これにより、現在のマスタールーターに関係なく、クライアントは常に同じ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メッセージを送信すべきではなく（SHOULD）、仮想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アドレスを含むGratuitous 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アドレスの両方が構成されるまで、Gratuitous 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.
VRRPルーターでプロキシARPを使用する場合、VRRPルーターはプロキシARPメッセージで仮想ルーターのMACアドレスを通知する必要があります。そうしないと、ホストがVRRPルーターの実際のMACアドレスを学習する可能性があります。
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によって複数のマスタールーターが存在する場合があります。マスタールーターが仮想ルーターのMACアドレスをFDDIデバイスのハードウェアアドレスとしてインストールすると、他のマスターのADVERTISEMENTSがマスターコンバージェンス中にリングから削除され、コンバージェンスは失敗します。
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アドレスを構成する必要があります（SHOULD）。これにより、マスタールーターが元の広告を削除しなくなります。
Token ring has several characteristics which 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 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
これらの問題のため、トークンリングよりも優先される動作モードは、VRID仮想MACアドレスにトークンリング機能アドレスを使用することです。トークンリング機能アドレスでは、最初のMACアドレスオクテットの2つの上位ビットがB'1 'に設定されています。それらの範囲は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プロトコルが存在する可能性があります。 Novell IPX [IPX]プロトコルは
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.
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 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 which 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.
さらに、ルーターはユニキャスト動作モードをサポートして、複数のユニキャストMACアドレスの無差別受信をサポートする新しいトークンリングアダプター実装を利用し、トークンリング機能アドレスの使用に関連するマルチキャストトラフィックと使用法の競合の両方を回避できます。ユニキャストモードでは、イーサネットと同じVRIDの仮想MACアドレスへのマッピングを使用します。ただし、重要な違いが1つあります。 ARP要求/応答パケットには、送信元MACアドレスとして仮想MACアドレスが含まれています。これは、トークンリングドライバーの実装によっては、MACアドレス/ソースルーティング情報のキャッシュをARPキャッシュとは別に保持するためです。
Hence, these implementations need have 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アドレスをソースアドレスとして持つパケットを受信する必要があります。
Unicast mode on token ring has one limitation which should be considered. If there are VRID routers on different source-route bridge segments and there are host implementations which 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キャッシュにソースルート情報を保持し、Gratuitous 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].
マルチキャストモードとユニキャストモードのどちらの動作でも、224.0.0.18に送信されるVRRPアドバタイズメントは、[RFC1469]で説明されているようにカプセル化する必要があります。
VRRP is designed for a range of internetworking environments that may employ different security policies. The protocol includes several authentication methods ranging from no authentication, simple clear text passwords, and strong authentication using IP Authentication with MD5 HMAC. The details on each approach including possible attacks and recommended environments follows.
VRRPは、さまざまなセキュリティポリシーを採用している可能性があるさまざまなインターネットワーキング環境向けに設計されています。このプロトコルには、認証なし、単純なクリアテキストパスワード、MD5 HMACによるIP認証を使用した強力な認証など、さまざまな認証方法が含まれています。可能性のある攻撃や推奨環境など、各アプローチの詳細は次のとおりです。
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の設定、受信時のチェック）が含まれています。これにより、ほとんどの脆弱性がローカル攻撃に限定されます。
The use of this authentication type means that VRRP protocol exchanges are not authenticated. This type of authentication SHOULD only be used in environments were there is minimal security risk and little chance for configuration errors (e.g., two VRRP routers on a LAN).
この認証タイプを使用すると、VRRPプロトコル交換は認証されません。このタイプの認証は、セキュリティリスクが最小限で、構成エラーの可能性がほとんどない環境（LAN上の2つのVRRPルーターなど）でのみ使用する必要があります（SHOULD）。
The use of this authentication type means that VRRP protocol exchanges are authenticated by a simple clear text password.
この認証タイプの使用は、VRRPプロトコル交換が単純なクリアテキストパスワードによって認証されることを意味します。
This type of authentication is useful to protect against accidental misconfiguration of routers on a LAN. It protects against routers inadvertently backing up another router. A new router must first be configured with the correct password before it can run VRRP with another router. This type of authentication does not protect against hostile attacks where the password can be learned by a node snooping VRRP packets on the LAN. The Simple Text Authentication combined with the TTL check makes it difficult for a VRRP packet to be sent from another LAN to disrupt VRRP operation.
このタイプの認証は、LAN上のルーターの誤った構成から保護するのに役立ちます。誤って別のルーターをバックアップするルーターから保護します。新しいルーターは、別のルーターでVRRPを実行する前に、正しいパスワードで構成する必要があります。このタイプの認証は、LAN上のVRRPパケットをスヌーピングするノードがパスワードを学習できる悪意のある攻撃から保護しません。 TTLチェックと組み合わせたシンプルテキスト認証により、VRRPパケットが別のLANから送信されてVRRP動作が中断することが困難になります。
This type of authentication is RECOMMENDED when there is minimal risk of nodes on a LAN actively disrupting VRRP operation. If this type of authentication is used the user should be aware that this clear text password is sent frequently, and therefore should not be the same as any security significant password.
このタイプの認証は、LAN上のノードがVRRP動作をアクティブに中断させるリスクが最小限である場合に推奨されます。このタイプの認証を使用する場合、ユーザーはこのクリアテキストのパスワードが頻繁に送信されるため、セキュリティ上重要なパスワードと同じであってはならないことに注意してください。
The use of this authentication type means the VRRP protocol exchanges are authenticated using the mechanisms defined by the IP Authentication Header [AUTH] using "The Use of HMAC-MD5-96 within ESP and AH", [HMAC]. This provides strong protection against configuration errors, replay attacks, and packet corruption/modification.
この認証タイプの使用は、VRRPプロトコル交換が「ESPおよびAH内でのHMAC-MD5-96の使用」、[HMAC]を使用するIP認証ヘッダー[AUTH]で定義されたメカニズムを使用して認証されることを意味します。これにより、構成エラー、リプレイ攻撃、およびパケットの破損/変更に対する強力な保護が提供されます。
This type of authentication is RECOMMENDED when there is limited control over the administration of nodes on a LAN. While this type of authentication does protect the operation of VRRP, there are other types of attacks that may be employed on shared media links (e.g., generation of bogus ARP replies) which are independent from VRRP and are not protected.
このタイプの認証は、LAN上のノードの管理に対する制御が制限されている場合に推奨されます。このタイプの認証はVRRPの動作を保護しますが、VRRPから独立していて保護されていない共有メディアリンク（偽のARP応答の生成など）で使用される可能性のある他のタイプの攻撃があります。
The authors would like to thank Glen Zorn, and Michael Lane, Clark Bremer, Hal Peterson, Tony Li, Barbara Denny, Joel Halpern, Steve Bellovin, and Thomas Narten for their comments and suggestions.
著者は、グレンゾーン、マイケルレーン、クラークブレーマー、ハルピーターソン、トニーリー、バーバラデニー、ジョエルハルパーン、スティーブベロビン、トーマスナルテンのコメントと提案に感謝します。
[802.1D] International Standard ISO/IEC 10038: 1993, ANSI/IEEE Std 802.1D, 1993 edition.
[802.1D]国際標準ISO / IEC 10038：1993、ANSI / IEEE Std 802.1D、1993年版。
[AUTH] Kent, S., and R. Atkinson, "IP Authentication Header", Work in Progress.
[AUTH] Kent、S。、およびR. Atkinson、「IP Authentication Header」、Work in Progress。
[DISC] Deering, S., "ICMP Router Discovery Messages", RFC 1256, September 1991.
[ディスク] Deering、S。、「ICMPルーター発見メッセージ」、RFC 1256、1991年9月。
[DHCP] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[DHCP] Droms、R。、「Dynamic Host Configuration Protocol」、RFC 2131、1997年3月。
[HMAC] Madson, C., and R. Glenn, "The Use of HMAC-MD5-96 within ESP and AH", Work in Progress.
[HMAC] Madson、C。、およびR. Glenn、「ESPおよびAH内でのHMAC-MD5-96の使用」、作業中。
[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。、およびD. Li、「Cisco Hot Standby Router Protocol（HSRP）」、RFC 2281、1998年3月。
[IPSTB] Higginson, P., 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, "Development of Router Clusters to Provide Fast Failover in IP Networks", Digital Technical Journal, Volume 9 Number 3, Winter 1997.
[IPX] Novell Incorporated., "IPX Router Specification", Version 1.10, October 1992.
[IPX] Novell Incorporated。、「IPX Router Specification」、バージョン1.10、1992年10月。
[OSPF] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[OSPF] Moy、J。、「OSPFバージョン2」、STD 54、RFC 2328、1998年4月。
[RIP] Hedrick, C., "Routing Information Protocol", RFC 1058, June 1988.
[RIP] Hedrick、C。、「Routing Information Protocol」、RFC 1058、1988年6月。
[RFC1469] Pusateri, T., "IP over Token Ring LANs", RFC 1469, June 1993.
[RFC1469] Pusateri、T。、「IP over Token Ring LANs」、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月。
[TKARCH] IBM Token-Ring Network, Architecture Reference, Publication SC30-3374-02, Third Edition, (September, 1989).
[TKARCH] IBMトークンリングネットワーク、アーキテクチャリファレンス、出版物SC30-3374-02、第3版（1989年9月）。
Steven Knight Phone: +1 612 943-8990 Ascend Communications EMail: Steven.Knight@ascend.com High Performance Network Division 10250 Valley View Road, Suite 113 Eden Prairie, MN USA 55344 USA
Steven Knight電話：+1 612 943-8990 Ascend Communicationsメール：Steven.Knight@ascend.com High Performance Network Division 10250 Valley View Road、Suite 113 Eden Prairie、MN USA 55344 USA
Douglas Weaver Phone: +1 612 943-8990 Ascend Communications EMail: Doug.Weaver@ascend.com High Performance Network Division 10250 Valley View Road, Suite 113 Eden Prairie, MN USA 55344 USA David Whipple Phone: +1 206 703-3876 Microsoft Corporation EMail: dwhipple@microsoft.com One Microsoft Way Redmond, WA USA 98052-6399 USA
ダグラスウィーバー電話：+1 612 943-8990アセンドコミュニケーションメール：Doug.Weaver@ascend.comハイパフォーマンスネットワーク部門10250バレービューロード、スイート113エデンプレーリー、ミネソタアメリカ合衆国55344アメリカデビッドウィップル電話：+1 206 703-3876マイクロソフトCorporation EMail：dwhipple@microsoft.com One Microsoft Way Redmond、WA USA 98052-6399 USA
Robert Hinden Phone: +1 408 990-2004 Nokia EMail: hinden@iprg.nokia.com 232 Java Drive Sunnyvale, CA 94089 USA
Robert Hindon電話：+1 408 990-2004 Nokiaメール：hindon@ipurg.nokia.com 232 Java Drive Sunnyvale、CA 94089彼
Danny Mitzel Phone: +1 408 990-2037 Nokia EMail: mitzel@iprg.nokia.com 232 Java Drive Sunnyvale, CA 94089 USA
Danny Mitzel電話：+1 408 990-2037ノキアEメール：mitzel@iprg.nokia.com 232 Java Drive Sunnyvale、CA 94089 USA
Peter Hunt Phone: +1 408 990-2093 Nokia EMail: hunt@iprg.nokia.com 232 Java Drive Sunnyvale, CA 94089 USA
Peter Hunt電話：+1408 990-2093 Nokia Eメール：hunt@iprg.nokia.com 232 Java Drive Sunnyvale、CA 94089 USA
P. Higginson Phone: +44 118 920 6293 Digital Equipment Corp. EMail: higginson@mail.dec.com Digital Park Imperial Way Reading Berkshire RG2 0TE UK
P.ヒギンソン電話：+44 118 920 6293 Digital Equipment Corp. Eメール：higginson@mail.dec.com Digital Park Imperial Way Reading Berkshire RG2 0TE UK
M. Shand Phone: +44 118 920 4424 Digital Equipment Corp. EMail: shand@mail.dec.com Digital Park Imperial Way Reading Berkshire RG2 0TE UK
M.シャンド電話：+44 118 920 4424 Digital Equipment Corp. Eメール：shand@mail.dec.com Digital Park Imperial Way Reading Berkshire RG2 0TE UK
Acee Lindem Phone: 1-919-254-1805 IBM Corporation E-Mail: acee@raleigh.ibm.com P.O. Box 12195 Research Triangle Park, NC 27709 USA
Acee Lindem電話：1-919-254-1805 IBM Corporation E-Mail：acee@raleigh.ibm.com P.O. Box 12195 Research Triangle Park、NC 27709 USA
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントとその翻訳はコピーして他のユーザーに提供することができ、コメントまたはその他の方法で説明したり、その実装を支援する二次的著作物は、いかなる種類の制限なしに、全体または一部を準備、コピー、公開、および配布することができますただし、上記の著作権表示とこの段落は、そのようなすべてのコピーと派生物に含まれています。ただし、このドキュメント自体は、著作権に関する通知を削除したり、インターネットソサエティや他のインターネット組織への参照を削除したりするなど、いかなる方法でも変更できません。ただし、インターネット標準を開発する目的で必要な場合は除きます。インターネット標準のプロセスに従うか、または必要に応じて、それを英語以外の言語に翻訳する必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記で付与された制限付きのアクセス許可は永続的であり、インターネットソサエティまたはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。