RFC3768 日本語訳
3768 Virtual Router Redundancy Protocol (VRRP). R. Hinden, Ed.. April 2004. (Format: TXT=59969 bytes) (Obsoletes RFC2338) (Status: DRAFT STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group R. Hinden, Ed. Request for Comments: 3768 Nokia Obsoletes: 2338 April 2004 Category: Standards Track
ワーキンググループR.Hinden、エドをネットワークでつないでください。コメントのために以下を要求してください。 3768 ノキアは以下を時代遅れにします。 2338 2004年4月のカテゴリ: 標準化過程
Virtual Router Redundancy Protocol (VRRP)
仮想のルータ冗長プロトコル(VRRP)
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2004). All Rights Reserved.
Copyright(C)インターネット協会(2004)。 All rights reserved。
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.
このメモはVirtual Router Redundancyプロトコル(VRRP)を定義します。 VRRPはダイナミックにLANのVRRPルータの1つに仮想のルータへの責任を割り当てる選挙プロトコルを指定します。 仮想のルータに関連しているIPアドレス(es)を制御するVRRPルータは、Masterと呼ばれて、これらのIPアドレスに送られたパケットを進めます。 Masterが入手できなくなるなら、選挙プロセスはダイナミックなフェイルオーバーを推進責任に提供します。 これは終わりホストでIPがデフォルトとして使用されるためにLANで扱う仮想のルータのいずれにも最初に、ホップルータを許容します。 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
1. 序論。 . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. 貢献者。 . . . . . . . . . . . . . . . . . . . . . 3 1.2. 範囲. . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3。 定義. . . . . . . . . . . . . . . . . . . . . . 4 2。 必要な特徴. . . . . . . . . . . . . . . . . . . . . . 5 2.1。 IPアドレスバックアップ. . . . . . . . . . . . . . . . . . . 5 2.2。 都合のよい経路指示. . . . . . . . . . . . . . . 5 2.3。 不要なサービスの崩壊. . . . 5 2.4の最小化。 拡張LANの上の効率的な操作。 . . . . . . . . 6 3. VRRP概要. . . . . . . . . . . . . . . . . . . . . . . . 6 4。 サンプル構成. . . . . . . . . . . . . . . . . . . . 7
Hinden Standards Track [Page 1] RFC 3768 VRRP April 2004
Hinden規格はVRRP2004年4月にRFC3768を追跡します[1ページ]。
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
4.1. 構成1を抽出してください。 . . . . . . . . . . . . . . . . 7 4.2. 構成2を抽出してください。 . . . . . . . . . . . . . . . . 9 5. 議定書を作ってください。 . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.1. VRRPパケット・フォーマット。 . . . . . . . . . . . . . . . . . . 10 5.2. IPフィールド記述. . . . . . . . . . . . . . . . . 10 5.3。 VRRPは記述. . . . . . . . . . . . . . . . 11 6をさばきます。 州のマシンについて議定書の中で述べてください。 . . . . . . . . . . . . . . . . . . . 13 6.1. 仮想のルータ. . . . . . . . . . . . . 13 6.2あたりのパラメタ。 タイマ。 . . . . . . . . . . . . . . . . . . . . . . . . 14 6.3. 変遷ダイヤグラムを述べてください。 . . . . . . . . . . . . . . . 15 6.4. 記述を述べてください。 . . . . . . . . . . . . . . . . . . 15 7. VRRPパケットを送って、受けます。 . . . . . . . . . . . . . 18 7.1. VRRPパケットを受けます。 . . . . . . . . . . . . . . . . 18 7.2. パケットを伝えます。 . . . . . . . . . . . . . . . . . 19 7.3. 仮想のマックーアドレス. . . . . . . . . . . . . . . . . . 19 8。 操作上の問題。 . . . . . . . . . . . . . . . . . . . . . 20 8.1. ICMPは向け直します。 . . . . . . . . . . . . . . . . . . . . 20 8.2. ARP要求. . . . . . . . . . . . . . . . . . . 20 8.3を主催してください。 プロキシARP. . . . . . . . . . . . . . . . . . . . . . . 20 8.4。 潜在的推進輪. . . . . . . . . . . . . . . 21 9。 FDDI、トークンリング、および気圧車線. . . . . . . . 21 9.1の上の操作。 FDDI. . . . . . . . . . . . . . . . . . 21 9.2の上の操作。 トークンリング. . . . . . . . . . . . . . . 21 9.3の上の操作。 気圧車線. . . . . . . . . . . . . . . . 23 10の上の操作。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 23 11。 承認。 . . . . . . . . . . . . . . . . . . . . . . 24 12. 参照。 . . . . . . . . . . . . . . . . . . . . . . . . . 24 12.1. 引用規格。 . . . . . . . . . . . . . . . . . 24 12.2. 有益な参照。 . . . . . . . . . . . . . . . . 25 13. RFC2338からの変化。 . . . . . . . . . . . . . . . . . . . . 25 14. エディタのアドレス。 . . . . . . . . . . . . . . . . . . . . . . 26 15. 完全な著作権宣言文。 . . . . . . . . . . . . . . . . . . 27
1. Introduction
1. 序論
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
すべての終わりホストにダイナミックルーティングプロトコルを実行するのは様々な意味で実行不可能であるかもしれません、いくつかのプラットホームへのプロトコル実装の管理オーバーヘッド、処理オーバヘッド、安全保障問題、または不足を含んでいて。隣人かルータ発見プロトコルがネットワークのすべてのホストによる積極的な参加を必要とするかもしれません、表面におけるプロトコルオーバーヘッドを下げるために大きいタイマ値に通じて
Hinden Standards Track [Page 2] RFC 3768 VRRP April 2004
Hinden規格はVRRP2004年4月にRFC3768を追跡します[2ページ]。
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実装によってサポートされます。 動的ホスト構成プロトコル[DHCP](終わりホストIPアドレスとデフォルトゲートウェイに構成を通常提供する)が配布されるとき、この運転モードは固執しそうです。 しかしながら、これは1ポイントの失敗を作成します。 デフォルトルータの損失は大惨事をもたらします、どんな利用可能であるかもしれない代替パスも検出できないすべての終わりホストを隔離して。
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.
Virtual Router Redundancyプロトコル(VRRP)は、静的なデフォルト発送された環境で固有の失敗の単一のポイントを排除するように設計されています。 VRRPはダイナミックにLANのVRRPルータの1つに仮想のルータへの責任を割り当てる選挙プロトコルを指定します。 仮想のルータに関連しているIPアドレス(es)を制御するVRRPルータは、Masterと呼ばれて、これらのIPアドレスに送られたパケットを進めます。 Masterが入手できなくなるなら、選挙プロセスはダイナミックなフェイルオーバーを推進責任に提供します。 そして、デフォルトが最初に終わりホストでルータを飛び越すとき、LANに関する仮想のルータのIPアドレスのいずれも使用できます。 VRRPを使用することで得られる利点はすべての終わりホストの上でダイナミックルーティングかルータ発見プロトコルの構成を必要とすることのない、より高い有用性デフォルト経路です。
VRRP provides a function similar to the proprietary protocols "Hot Standby Router Protocol (HSRP)" [HSRP] and "IP Standby Protocol" [IPSTB].
VRRPは固有のプロトコル「ホット・スタンバイ機能ルータプロトコル(HSRP)」[HSRP]と「IP予備プロトコル」[IPSTB]と同様の機能を提供します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
1.1. Contributors
1.1. 貢献者
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.
以下の人々(このドキュメントがあって、取り替えるRFC2338の作者です)は本書ではテキストに貢献しました。 彼らは、P.ヒギンソンと、R.Hindenと、P.Huntと、S.Knightと、A.Lindemと、D.Mitzelと、M.シャンドと、D.ウィーバーと、D.ホイップルです。 それらは現在のRFC-エディタ方針のためドキュメントの作者として記載されていません。
Hinden Standards Track [Page 3] RFC 3768 VRRP April 2004
Hinden規格はVRRP2004年4月にRFC3768を追跡します[3ページ]。
1.2. Scope
1.2. 範囲
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の特徴、デザイン目標、および動作理論について説明します。 メッセージ・フォーマット、プロトコル処理規則、およびそれが提示されるのを独身のVirtual Router Masterへの集合に保証する州のマシン。 最終的に、操作上の問題は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環境で望ましいと決められると、別々の仕様は作り出されるでしょう。
1.3. Definitions
1.3. 定義
VRRP Router A router running the Virtual Router Redundancy
Protocol. It may participate in one or more
virtual routers.
Virtual Router Redundancyプロトコルを実行するVRRP Router Aルータ。 それは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.
仮想のRouter An抽象的なオブジェクトはホストのためのデフォルトルータとして共有されたLANに機能するVRRPによって管理されました。 それは一般的なLANの向こう側に関連IPアドレス(es)のVirtual Router Identifierとセットから成ります。 VRRP Routerは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 Address Owner、本当であるとしての仮想のルータのIPアドレス(es)がアドレス(es)を連結する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 Address An 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.
仮想のRouter Master、パケットを進める責任を負っているVRRPルータは仮想のルータと、ARPに答えると関連しているIPアドレス(es)にこれらのIPアドレスを求める要求を送りました。 IPアドレス所有者が手があくならそれがいつもMasterになることに注意してください。
Hinden Standards Track [Page 4] RFC 3768 VRRP April 2004
Hinden規格はVRRP2004年4月にRFC3768を追跡します[4ページ]。
Virtual Router Backup The set of VRRP routers available to assume
forwarding responsibility for a virtual router
should the current Master fail.
仮想のRouter Backupは仮想のルータへの推進責任はMasterが失敗する電流がそうするべきであると仮定するために利用可能なVRRPルータのセットです。
2. Required Features
2. 必要な特徴
This section outlines the set of features that were considered mandatory and that guided the design of VRRP.
このセクションは義務的であると考えられて、VRRPのデザインを誘導した特徴のセットについて概説します。
2.1. IP Address Backup
2.1. IPアドレスバックアップ
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アドレスのバックアップはVirtual Router Redundancyプロトコルのプライマリ機能です。 Virtual Router Masterの選挙と以下で説明された追加機能性を提供している間、プロトコルは、以下のことように努力するべきです。
- 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サブネットのサポート。
2.2. Preferred Path Indication
2.2. 都合のよい経路指示
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.
余分なルータのセットの中のMaster選挙の単純モデルはMasterとしてどんなルータにも一点に集まった後に、等しい好みとクレームの勝利で各ルータを扱うことになっています。 しかしながら、余分なルータのセットの中に異なった優先(または、好みの範囲)がある多くの環境がありそうです。 例えば、この好みはアクセスリンク費用、速度、ルータ性能、信頼性、または他の方針問題に基づくかもしれません。 プロトコルは直感的な方法におけるこの相対パス好み、および現在利用可能な最も優先ののルータへの保証Master集合の式を許容するべきです。
2.3. Minimization of Unnecessary Service Disruptions
2.3. 不要なサービスの崩壊の最小化
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.
一度、Master選挙は実行されたことがあって、次に、MasterとBackupルータの間のどんな不要な変遷も使用中の状態で分裂をもたらすことができます。 プロトコルは、Master選挙の後にMasterが、適切に機能し続けている限り、状態遷移が全く等しいか下側の好みのどんなBackupルータによっても引き起こされないのを確実にするべきです。
Hinden Standards Track [Page 5] RFC 3768 VRRP April 2004
Hinden規格はVRRP2004年4月にRFC3768を追跡します[5ページ]。
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.
いくつかの環境によって、現在のMasterより好まれるルータが利用可能になるとき引き起こされた状態遷移を避けるのが有益であることがわかるかもしれません。 即座の集合のオーバーライドを都合のよい経路にサポートするのは役に立つかもしれません。
2.4. Efficient Operation over Extended LANs
2.4. 拡張LANの上の効率的な操作
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.
IPパケットを多重処理LANに送るのは、IPアドレスからMACアドレスまで写像するのを必要とします。 拡張LANにおける仮想のルータMACアドレスのラーニングブリッジを使う使用は仮想のルータに送られたパケットの帯域幅オーバーヘッドに重要な影響を与えることができます。 ステーションの位置は決して学習されません、仮想のルータに送られたすべてのパケットの氾濫をもたらして仮想のルータMACアドレスがソースアドレスとしてリンク・レベルフレームで決して使用されないなら。 この環境で能率を上げるために、プロトコルはそうするべきです: 1) パケットのソースがステーション学習の引き金となるようにMasterで発信したので、仮想のルータMACを使用してください。 2) ステーション学習をアップデートするためにMasterに移行する直後メッセージの引き金となってください。 そして、3は、)ステーション学習キャッシュを維持するためにMasterから周期的なメッセージの引き金となります。
3. VRRP Overview
3. VRRP概要
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アドレスをそれに割り当てます。 このドキュメントは、現在、IEEE802の48ビットのMACアドレスを使用することでマッピングをネットワークに詳しく述べるだけです。 すべての周期的なVRRPメッセージのソースが拡張LANにおけるブリッジ学習を可能にするためにMasterルータで発信したので、仮想のルータMACアドレスは使用されています。
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ルータは、インタフェースに関する本当のアドレスに仮想のルータを関連づけて、また、それがバックアップをとっても構わないと思っている仮想のルータのために追加仮想のルータマッピングと優先権によって構成されるかもしれません。 LANに関するすべてのVRRPルータの中でVRIDとアドレスの間のマッピングを調整しなければなりません。 しかしながら、異なった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
ネットワークトラフィックを最小にするために、それぞれの仮想のルータのためのMasterだけが周期的なVRRP Advertisementメッセージを送ります。 それにより高い優先度がないと、Backupルータは、Masterを先取りするのを試みないでしょう。 より都合のよい経路が利用可能にならない場合、これはサービスの崩壊を排除します。 また、行政上すべてを禁止するのも可能です。
Hinden Standards Track [Page 6] RFC 3768 VRRP April 2004
Hinden規格はVRRP2004年4月にRFC3768を追跡します[6ページ]。
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ルータがいつもそれが所有しているアドレスに関連しているどんな仮想のルータのMasterにもなるということです。 Masterが入手できなくなると、最優先Backupは最小量の停電による仮想のルータ責任の制御変遷を提供する少し遅れの後のMasterへの変遷がそうするでしょう。
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プロトコルデザインは、停電を最小にするためにBackupからMasterまでの急速な変化を提供して、典型的な操作上のシナリオのための制御Master変遷を保証している間、プロトコルの複雑さを減少させる最適化を取り入れます。 最小量のランタイムがある選挙プロトコルの最適化結果は要件、最小量の活動的なプロトコル州、単独のメッセージタイプ、および送付者を述べます。 典型的な操作上のシナリオは、各ルータの中の2つの余分なルータ、そして/または、異なった経路好みになるように定義されます。 これらの仮定が違反されるときの副作用(すなわち、等しい好みがあるすべて、2つ以上の冗長パス)はMaster選挙の間の簡潔な期間写しパケットを進めるかもしれないということです。 しかしながら、典型的なシナリオ仮定は展開のかなりの大部分をカバーしそうであって、Masterルータの損失は珍しく、Master選挙集合における予想された持続時間はかなり小さいです(<<1 2番目)。 したがって、VRRP最適化は簡潔なネットワーク退行の意味をなさない確率を被っている間、プロトコルデザインにおける重要な簡素化を表します。
4. Sample Configurations
4. サンプル構成
4.1. Sample Configuration 1
4.1. サンプル構成1
The following figure shows a simple network with two VRRP routers implementing one virtual router. Note that this example is provided to help understand the protocol, but is not expected to occur in actual practice.
以下の図は2つのVRRPルータが1つの仮想のルータを実装している簡単なネットワークを示しています。 この例をプロトコルを理解しているのを助けるために提供しますが、実際行なわれているところでは起こらないと予想することに注意してください。
Hinden Standards Track [Page 7] RFC 3768 VRRP April 2004
Hinden規格はVRRP2004年4月にRFC3768を追跡します[7ページ]。
+-----------+ +-----------+
| 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
+-----------+ +-----------+ | Rtr1| | Rtr2| |(VRID=1さん)| |(Br VRID=1)| | | | | VRID=1+-----------+ +-----------+ IP A---------->* *<、-、-、-、-、-、-、-、-- IP B| | | | ------------------+------------+-----+--------+--------+--------+-- ^ ^ ^ ^ | | | | (IP a) (IP a) (IP a) (IP a) | | | | +--+--+ +--+--+ +--+--+ +--+--+ | H1| | H2| | H3| | H4| +-----+ +-----+ +--+--+ +--+--+ 伝説: ---+---+---+--= マスターホストコンピュータイーサネット、Token Ring、またはFDDI H=MR=Router BRはホストのためにデフォルトバックアップRouter*=IP Address(IP)=ルータと等しいです。
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展開としてそれを残します。 各ルータは永久にIPアドレスをLANインタフェースに割り当てられます、そして、(Rtr1がIP Aに配属されます、そして、Rtr2はIP Bに配属されます)各ホストはルータの1つを通して静的なデフォルトルートをインストールします(この例では、それらは皆、Rtr1のIP Aを使用します)。
Moving to the VRRP environment, each router has the exact same permanently assigned IP address. Rtr1 is said to be the IP address owner of IP A, and Rtr2 is the IP address owner of IP B. A virtual router is then defined by associating a unique identifier (the virtual router ID) with the address owned by a router. Finally, the VRRP protocol manages virtual router fail over to a backup router.
VRRP環境に移行して、各ルータには全く同じ永久に割り当てられたIPアドレスがあります。 Rtr1はIP AのIPアドレス所有者であると言われています、そして、Rtr2はIP B.のIPアドレス所有者です。次に、A仮想のルータは、ユニークな識別子(仮想のルータID)をルータによって所有されているアドレスに関連づけることによって、定義されます。 最終的に、VRRPプロトコルは仮想のルータフェイルオーバーをバックアップルータに管理します。
The example above shows a virtual router configured to cover the IP address owned by Rtr1 (VRID=1,IP_Address=A). When VRRP is enabled on Rtr1 for VRID=1 it will assert itself as Master, with priority=255, since it is the IP address owner for the virtual router IP address. When VRRP is enabled on Rtr2 for VRID=1 it will transition to Backup, with priority=100, since it is not the IP address owner. If Rtr1 should fail then the VRRP protocol will transition Rtr2 to Master, temporarily taking over forwarding responsibility for IP A to provide uninterrupted service to the hosts.
上記の例は、仮想のルータがRtr1によって所有されていたIPアドレスをカバーするのを構成されたのを示します。(VRID=1、IP_Addressはa)と等しいです。 VRRPがVRID=1であるときにRtr1で有効にされるとき、Masterとしてそれ自体について断言するでしょう、優先権=255で、それが仮想のルータIPアドレスのためのIPアドレス所有者であるので。 VRRPがVRID=1であるときにRtr2で有効にされるとき、それはそれがIPアドレス所有者でない時から優先権=100があるBackupへの変遷がそうするでしょう。 Rtr1が失敗すると、VRRPプロトコルはMaster、IP Aがホストに対するとぎれないサービスを提供する一時引き継いでいる推進責任への変遷Rtr2がそうするでしょう。
Hinden Standards Track [Page 8] RFC 3768 VRRP April 2004
Hinden規格はVRRP2004年4月にRFC3768を追跡します[8ページ]。
Note that in this example IP B is not backed up, it is only used by Rtr2 as its interface address. In order to backup IP B, a second virtual router must be configured. This is shown in the next section.
この例のIP Bで支援されない注意、それはインターフェース・アドレスとしてRtr2によって使用されるだけです。 IP Bのバックアップをとるために、2番目の仮想のルータを構成しなければなりません。 これは次のセクションで示されます。
4.2. Sample Configuration 2
4.2. サンプル構成2
The following figure shows a configuration with two virtual routers with the hosts spitting their traffic between them. This example is expected to be very common in actual practice.
以下の図はホストが彼らの間の彼らのトラフィックに痰唾を吐いている2つの仮想のルータで構成を示しています。 この例が実際行なわれているところでは非常に一般的であると予想されます。
+-----------+ +-----------+
| Rtr1 | | Rtr2 |
|(MR VRID=1)| |(BR VRID=1)|
|(BR VRID=2)| |(MR VRID=2)|
VRID=1 +-----------+ +-----------+ VRID=2
IP A ---------->* *<---------- IP B
| |
| |
------------------+------------+-----+--------+--------+--------+--
^ ^ ^ ^
| | | |
(IP A) (IP A) (IP B) (IP B)
| | | |
+--+--+ +--+--+ +--+--+ +--+--+
| H1 | | H2 | | H3 | | H4 |
+-----+ +-----+ +--+--+ +--+--+
Legend:
---+---+---+-- = Ethernet, Token Ring, or FDDI
H = Host computer
MR = Master Router
BR = Backup Router
* = IP Address
(IP) = default router for hosts
+-----------+ +-----------+ | Rtr1| | Rtr2| |(VRID=1さん)| |(Br VRID=1)| |(Br VRID=2)| |(VRID=2さん)| VRID=1+-----------+ +-----------+ VRID=2IP A---------->* *<、-、-、-、-、-、-、-、-、-- IP B| | | | ------------------+------------+-----+--------+--------+--------+-- ^ ^ ^ ^ | | | | (IP a) (IP a) (IP B) (IP B) | | | | +--+--+ +--+--+ +--+--+ +--+--+ | H1| | H2| | H3| | H4| +-----+ +-----+ +--+--+ +--+--+ 伝説: ---+---+---+--= マスターホストコンピュータイーサネット、Token Ring、またはFDDI H=MR=Router BRはホストのためにデフォルトバックアップRouter*=IP Address(IP)=ルータと等しいです。
In the example above, half of the hosts have configured a static route through Rtr1's IP A and half are using Rtr2's IP B. The configuration of virtual router VRID=1 is exactly the same as in the first example (see section 4.1), and a second virtual router has been added to cover the IP address owned by Rtr2 (VRID=2, IP_Address=B). In this case Rtr2 will assert itself as Master for VRID=2 while Rtr1 will act as a backup. This scenario demonstrates a deployment providing load splitting when both routers are available while providing full redundancy for robustness.
半分のホストはRtr1のIP Aを通して上では、例では、スタティックルートを構成しました、そして、半分がRtr2のIP B.を使用しています。仮想のルータVRID=1の構成はまさに最初の例と同じです、そして、(セクション4.1を見てください)Rtr2(VRID=2、IP_Address=B)によって所有されていたIPアドレスをカバーするために2番目の仮想のルータを追加してあります。 この場合、Rtr1がバックアップとして機能する間、Rtr2はVRID=2であることのMasterとしてそれ自体について断言するでしょう。 このシナリオは両方のルータが丈夫さのための完全な冗長を提供している間利用可能であるときに負荷の分かれることを提供する展開を示します。
Hinden Standards Track [Page 9] RFC 3768 VRRP April 2004
Hinden規格はVRRP2004年4月にRFC3768を追跡します[9ページ]。
5. Protocol
5. プロトコル
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パケットの目的は優先権とVirtual Router IDに関連しているMasterルータの状態をすべてのVRRPルータに伝えることです。
VRRP packets are sent encapsulated in IP packets. They are sent to the IPv4 multicast address assigned to VRRP.
パケットが送られるVRRPはIPパケットで要約しました。 VRRPに割り当てられたIPv4マルチキャストアドレスにそれらを送ります。
5.1. VRRP Packet Format
5.1. VRRPパケット・フォーマット
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |バージョン| タイプ| 仮想のRtr ID| 優先権| IP Addrsを数えてください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authはタイプします。| Adver Int| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPアドレス(1)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPアドレス(n)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 認証データ(1)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 認証データ(2)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.2. IP Field Descriptions
5.2. IPフィールド記述
5.2.1. Source Address
5.2.1. ソースアドレス
The primary IP address of the interface the packet is being sent from.
パケットが送られるインタフェースのプライマリIPアドレス。
Hinden Standards Track [Page 10] RFC 3768 VRRP April 2004
Hinden規格はVRRP2004年4月にRFC3768を追跡します[10ページ]。
5.2.2. Destination Address
5.2.2. 送付先アドレス
The IP multicast address as assigned by the IANA for VRRP is:
VRRPのためにIANAによって割り当てられるIPマルチキャストアドレスは以下の通りです。
224.0.0.18
224.0.0.18
This is a link local scope multicast address. Routers MUST NOT forward a datagram with this destination address regardless of its TTL.
これはリンクのローカルの範囲マルチキャストアドレスです。 ルータはTTLにかかわらずこの送付先アドレスがあるデータグラムを進めてはいけません。
5.2.3. TTL
5.2.3. 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 MUST、255に設定されてください。 255と等しくないTTLと共にパケットを受けるVRRPルータはパケットを捨てなければなりません。
5.2.4. Protocol
5.2.4. プロトコル
The IP protocol number assigned by the IANA for VRRP is 112 (decimal).
VRRPのためにIANAによって割り当てられたIPプロトコル番号は112(10進)です。
5.3. VRRP Field Descriptions
5.3. VRRPフィールド記述
5.3.1. Version
5.3.1. バージョン
The version field specifies the VRRP protocol version of this packet. This document defines version 2.
バージョン分野はこのパケットのVRRPプロトコルバージョンを指定します。 このドキュメントはバージョン2を定義します。
5.3.2. Type
5.3.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.
未知のタイプがあるパケットを捨てなければなりません。
5.3.3. Virtual Rtr ID (VRID)
5.3.3. 仮想のRtr ID(VRID)
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.
Virtual Router Identifier(VRID)分野はこのパケットが状態を報告している仮想のルータを特定します。 範囲1-255(小数)における構成可能な項目。 デフォルトが全くありません。
5.3.4. Priority
5.3.4. 優先権
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ビットの符号のない整数分野です。
Hinden Standards Track [Page 11] RFC 3768 VRRP April 2004
Hinden規格はVRRP2004年4月にRFC3768を追跡します[11ページ]。
The priority value for the VRRP router that owns the IP address(es) associated with the virtual router MUST be 255 (decimal).
仮想のルータに関連しているIPアドレス(es)を所有している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).
仮想のルータへの支援が1-254(10進)に優先順位の値を使用しなければならないVRRPルータ。 仮想のルータを支援する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)には、現在のMasterが、VRRPに参加するのを止めたのを示す特別な意味があります。 これは、すばやく現在のMasterをタイムアウトに待つ必要はなくてMasterに移行するのに引き金のBackupルータに使用されます。
5.3.5. Count IP Addrs
5.3.5. IP Addrsを数えてください。
The number of IP addresses contained in this VRRP advertisement.
このVRRP広告に含まれたIPアドレスの数。
5.3.6. Authentication Type
5.3.6. 認証タイプ
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.
利用されていて、認証タイプ分野は認証方法を特定します。 認証タイプはVirtual Routerベースでユニークです。 認証タイプ分野は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)が控えなかった認証全く
5.3.6.1. Authentication Type 0 - No Authentication
5.3.6.1. 認証タイプ0--認証がありません。
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プロトコル交換が認証されないことを意味します。 Authentication Data分野のコンテンツは、トランスミッションのときにゼロに設定されて、レセプションで無視されるべきです。
5.3.6.2. Authentication Type 1 - Reserved
5.3.6.2. 認証タイプ1--予約されます。
This authentication type is reserved to maintain backwards compatibility with RFC 2338.
この認証タイプは、後方にRFC2338との互換性を維持するために予約されます。
Hinden Standards Track [Page 12] RFC 3768 VRRP April 2004
Hinden規格はVRRP2004年4月にRFC3768を追跡します[12ページ]。
5.3.6.3. Authentication Type 2 - Reserved
5.3.6.3. 認証タイプ2--予約されます。
This authentication type is reserved to maintain backwards compatibility with RFC 2338.
この認証タイプは、後方にRFC2338との互換性を維持するために予約されます。
5.3.7. Advertisement Interval (Adver Int)
5.3.7. 広告間隔(Adver Int)
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間隔はADVERTISEMENTSの間に時間間隔を示します(秒に)。 デフォルトは1秒です。 この分野は、misconfiguredルータを障害調査するのに使用されます。
5.3.8. Checksum
5.3.8. チェックサム
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]に関してRFC1071を見てください。
5.3.9. IP Address(es)
5.3.9. IPアドレス(es)
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.
IPがそれを扱う1つか以上が仮想のルータに関連しています。 アドレスを含む数は「カウントIP Addrs」分野で指定されます。 これらの分野は、misconfiguredルータを障害調査するのに使用されます。
5.3.10. Authentication Data
5.3.10. 認証データ
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.
認証ストリングは現在、単に後方にRFC2338との互換性を維持するのにおいて使用されています。 それ、SHOULD、トランスミッションのときにゼロに設定されて、レセプションで無視されます。
6. Protocol State Machine
6. プロトコル州のマシン
6.1. Parameters per Virtual Router
6.1. 仮想のルータあたりのパラメタ
VRID Virtual Router Identifier. Configurable item
in the range 1-255 (decimal). There is no
default.
VRIDの仮想のルータ識別子。 範囲1-255(小数)における構成可能な項目。 デフォルトが全くありません。
Priority Priority value to be used by this VRRP router
in Master election for this virtual router.
The value of 255 (decimal) is reserved for
the router that owns the IP addresses
associated with the virtual router. The
value of 0 (zero) is reserved for Master
Priorityがこの仮想のルータにこのVRRPルータによってMaster選挙に使用されるために評価する優先権。 255(10進)の値は仮想のルータに関連しているIPアドレスを所有しているルータのために予約されます。 0(ゼロ)の値はMasterのために予約されます。
Hinden Standards Track [Page 13] RFC 3768 VRRP April 2004
Hinden規格はVRRP2004年4月にRFC3768を追跡します[13ページ]。
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).
それを示すルータは仮想のルータへの責任をリリースしています。 範囲1-254(小数)は仮想のルータを支援するVRRPルータに利用可能です。 デフォルト値は100(10進)です。
IP_Addresses One or more IP addresses associated with this
virtual router. Configured item. No
default.
Addresses Oneか、より多くのIPが扱うIP_はこの仮想のルータと交際しました。 構成された項目。 デフォルトがありません。
Advertisement_Interval Time interval between ADVERTISEMENTS
(seconds). Default is 1 second.
ADVERTISEMENTS(秒)の広告_Interval Time間隔。 デフォルトは1秒です。
Skew_Time Time to skew Master_Down_Interval in seconds.
Calculated as:
秒に斜行Master_Down_Intervalに_Time Timeを歪曲してください。 以下として計算されました。
( (256 - Priority) / 256 )
((256--優先権)/256)
Master_Down_Interval Time interval for Backup to declare Master
down (seconds). Calculated as:
_Down_Interval Time間隔をマスタリングして、Backupは(秒)にMasterを申告してください。 以下として計算されました。
(3 * Advertisement_Interval) + Skew_time
(3*広告_間隔)+斜行_時間
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.
より高い優先権Backupルータが低優先度Masterを先取りするか否かに関係なく、_Mode Controlsを先取りしてください。 値は先取りとFalseが先取りを禁止するのを許容するTrueです。 デフォルトはTrueです。
Note: Exception is that the router that owns
the IP address(es) associated with the
virtual router always preempts independent of
the setting of this flag.
以下に注意してください。 例外は仮想のルータに関連しているIPアドレス(es)を所有しているルータがいつもこの旗の設定の独立者を先取りするということです。
Authentication_Type Type of authentication being used. Values
are defined in section 5.3.6.
使用される認証の認証_Type Type。 値はセクション5.3.6で定義されます。
Authentication_Data Authentication data specific to the
Authentication_Type being used.
使用されるAuthentication_Typeに特定の認証_Data Authenticationデータ。
6.2. Timers
6.2. タイマ
Master_Down_Timer Timer that fires when ADVERTISEMENT has not
been heard for Master_Down_Interval.
_がADVERTISEMENTがMaster_Down_Intervalに関して聞かれていないとき発火するDown_Timer Timerであるとマスタリングしてください。
Adver_Timer Timer that fires to trigger sending of
ADVERTISEMENT based on
Advertisement_Interval.
ADVERTISEMENTの発信の引き金となるように発火するAdver_Timer Timerが_IntervalをAdvertisementに基礎づけました。
Hinden Standards Track [Page 14] RFC 3768 VRRP April 2004
Hinden規格はVRRP2004年4月にRFC3768を追跡します[14ページ]。
6.3. State Transition Diagram
6.3. 状態遷移ダイヤグラム
+---------------+
+--------->| |<-------------+
| | Initialize | |
| +------| |----------+ |
| | +---------------+ | |
| | | |
| V V |
+---------------+ +---------------+
| |---------------------->| |
| Master | | Backup |
| |<----------------------| |
+---------------+ +---------------+
+---------------+ +--------->| | <、-、-、-、-、-、-、-、-、-、-、-、--+ | | 初期化します。| | | +------| |----------+ | | | +---------------+ | | | | | | | V V| +---------------+ +---------------+ | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、| マスター| | バックアップ| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| +---------------+ +---------------+
6.4. State Descriptions
6.4. 州の記述
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ルータはそれが参加しているそれぞれの仮想のルータ選挙のための州のマシンのインスタンスを実装します。
6.4.1. Initialize
6.4.1. 初期化します。
The purpose of this state is to wait for a Startup event. If a Startup event is received, then:
この状態の目的はStartupイベントを待つことです。 次に、Startupイベントを受け取るなら:
- If the Priority = 255 (i.e., the router owns the IP address(es)
associated with the virtual router)
- 優先権が255と等しいなら(すなわち、ルータは仮想のルータに関連しているIPアドレス(es)を所有しています)
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_Interval o TransitionへのAdver_Timerが述べる仮想のルータ. o Setに関連しているそれぞれのIPアドレスのための仮想のルータMACアドレスを含む無料のARP要求をADVERTISEMENT○Broadcastに送ってください。
else
ほか
o Set the Master_Down_Timer to Master_Down_Interval
o Transition to the {Backup} state
o バックアップへのMaster_Down_Interval o TransitionへのTimerが述べるMaster_Down_を設定してください。
endif
endif
Hinden Standards Track [Page 15] RFC 3768 VRRP April 2004
Hinden規格はVRRP2004年4月にRFC3768を追跡します[15ページ]。
6.4.2. Backup
6.4.2. バックアップ
The purpose of the {Backup} state is to monitor the availability and
state of the Master Router.
状態があるバックアップの目的は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アドレス(es)に扱われたパケットが仮想のルータに関連していると受け入れてはいけません。
- If a Shutdown event is received, then:
- 次に、Shutdownイベントを受け取るなら:
o Cancel the Master_Down_Timer
o Transition to the {Initialize} state
o Master_Down_Timer o Transitionを取り消す、状態を初期化してください。
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_Interval o TransitionへのAdver_Timerが述べる仮想のルータo Setに関連しているそれぞれのIPアドレスのための仮想のルータMACアドレスを含む無料のARP要求をADVERTISEMENT○Broadcastに送ってください。
endif
endif
- If an ADVERTISEMENT is received, then:
- 次に、ADVERTISEMENTを受け取るなら:
If the Priority in the ADVERTISEMENT is Zero, then:
次に、ADVERTISEMENTのPriorityがZeroであるなら:
o Set the Master_Down_Timer to Skew_Time
o マスター_下に_タイマに_時間を歪曲するように設定してください。
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のIf PriorityがFalse以上である、地方のPriority、その時:
o Reset the Master_Down_Timer to Master_Down_Interval
o マスター_下に_タイマをリセットして、_下に_間隔をマスタリングしてください。
Hinden Standards Track [Page 16] RFC 3768 VRRP April 2004
Hinden規格はVRRP2004年4月にRFC3768を追跡します[16ページ]。
else:
ほかに:
o Discard the ADVERTISEMENT
o 広告を捨ててください。
endif
endif
endif
endif endif endif
6.4.3. Master
6.4.3. マスター
While in the {Master} state the router functions as the forwarding
router for the IP address(es) associated with the virtual router.
マスターにある間、IPのための推進ルータとしてのルータ機能が演説する州(es)は仮想のルータと交際しました。
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アドレス(es)を求める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アドレス(es)に扱われたパケットが仮想のルータに関連していると受け入れてはいけません。
- MUST accept packets addressed to the IP address(es) associated
with the virtual router if it is the IP address owner.
- それがIPアドレス所有者であるならIPアドレス(es)に扱われたパケットが仮想のルータに関連していると受け入れなければなりません。
- If a Shutdown event is received, then:
- 次に、Shutdownイベントを受け取るなら:
o Cancel the Adver_Timer
o Send an ADVERTISEMENT with Priority = 0
o Transition to the {Initialize} state
o キャンセル、PriorityとADVERTISEMENTが0○Transitionと等しいAdver_Timer o Send、状態を初期化してください。
endif
endif
- If the Adver_Timer fires, then:
- 次に、Adver_Timerが発火するなら:
o Send an ADVERTISEMENT o Reset the Adver_Timer to
Advertisement_Interval
o Advertisement_IntervalへのReset Adver_TimerをADVERTISEMENT oに送ってください。
endif
endif
- If an ADVERTISEMENT is received, then:
- 次に、ADVERTISEMENTを受け取るなら:
If the Priority in the ADVERTISEMENT is Zero, then:
次に、ADVERTISEMENTのPriorityがZeroであるなら:
o Send an ADVERTISEMENT
o Reset the Adver_Timer to Advertisement_Interval
o Advertisement_IntervalへのReset Adver_TimerをADVERTISEMENT oに送ってください。
Hinden Standards Track [Page 17] RFC 3768 VRRP April 2004
Hinden規格はVRRP2004年4月にRFC3768を追跡します[17ページ]。
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のPriorityが地方のPriorityより大きいか、そして、If Priorityは地方のPriorityと等しいです、そして、送付者のプライマリIP Addressは地方のプライマリIP Addressより優れています、そして:
o Cancel Adver_Timer
o Set Master_Down_Timer to Master_Down_Interval
o Transition to the {Backup} state
o バックアップへのMaster_Down_Interval o TransitionへのDown_Timerが述べるAdver_Timer o Set Master_を取り消してください。
else:
ほかに:
o Discard ADVERTISEMENT
o 広告を捨ててください。
endif
endif
endif
endif endif endif
7. Sending and Receiving VRRP Packets
7. 送受信VRRPパケット
7.1. Receiving VRRP Packets
7.1. VRRPパケットを受けます。
Performed the following functions when a VRRP packet is received:
VRRPパケットが受け取られているとき、以下の機能を実行します:
- MUST verify that the IP TTL is 255.
- MUST verify the VRRP version is 2.
- MUST verify that the received packet contains the complete VRRP
packet (including fixed fields, IP Address(es), and Authentication
Data).
- MUST verify the VRRP checksum.
- MUST verify that the VRID is configured on the receiving interface
and the local router is not the IP Address owner (Priority equals
255 (decimal)).
- MUST verify that the Auth Type matches the locally configured
authentication method for the virtual router and perform that
authentication method.
- IP TTLが255歳であることを確かめなければなりません。 - VRRPについて確かめてください。バージョンは2であるに違いありません。 - 容認されたパケットが完全なVRRPパケット(固定分野、IP Address(es)、およびAuthentication Dataを含んでいる)を含むことを確かめなければなりません。 - VRRPチェックサムについて確かめなければなりません。 - VRIDが受信インタフェースで構成されて、ローカルルータがIP Address所有者でないことを確かめなければなりません(優先権は255(10進)と等しいです)。 - 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.
上のチェックのどれかが失敗するなら、受信機はパケットを捨てなければなりません、そして、SHOULDはイベントを登録します、そして、誤りが発生したのをネットワークマネージメントで示すかもしれません。
- MAY verify that "Count IP Addrs" and the list of IP Address
matches the IP_Addresses configured for the VRID
- 「IP Addrsを数えてください」、IP AddressのリストがVRIDのために構成されたIP_Addressesに合っていることを確かめるかもしれません。
Hinden Standards Track [Page 18] RFC 3768 VRRP April 2004
Hinden規格はVRRP2004年4月にRFC3768を追跡します[18ページ]。
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はイベントを登録します、そして、misconfigurationが検出されたのをネットワークマネージメントで示すかもしれません。 パケットがアドレス所有者によって生成されなかったなら(優先権は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.
上のチェックが失敗するなら、受信機はパケットを捨てなければなりません、そして、SHOULDはイベントを登録します、そして、misconfigurationが検出されたのをネットワークマネージメントで示すかもしれません。
7.2. Transmitting VRRP Packets
7.2. VRRPパケットを伝えます。
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アドレスをVirtual Routerマックーアドレスに設定してください--ソース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セグメントを決定するのを保証します。
7.3. Virtual Router MAC Address
7.3. 仮想のルータマックーアドレス
The virtual router MAC address associated with a virtual router is an IEEE 802 MAC Address in the following format:
仮想のルータに関連している仮想のルータMACアドレスは以下の形式のIEEE802マックーアドレスです:
00-00-5E-00-01-{VRID} (in hex in internet standard bit-order)
00-00-5 E-00-01VRID(インターネットの標準のビットオーダーにおける十六進法における)
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.
IANAのOUIから最初の3つの八重奏を得ます。 次の2つの八重奏(00-01)がVRRPプロトコルに割り当てられたあて先ブロックを示します。 VRIDはVRRP Virtual Router Identifierです。 このマッピングはネットワークの255のVRRPルータまで提供されます。
Hinden Standards Track [Page 19] RFC 3768 VRRP April 2004
Hinden規格はVRRP2004年4月にRFC3768を追跡します[19ページ]。
8. Operational Issues
8. 操作上の問題
8.1. ICMP Redirects
8.1. ICMPは向け直します。
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 Redirectsは使用されるかもしれません。 これは、トポロジーが左右対称でないところに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ルータが仮想のルータのためのMasterとして機能しているなら、それは、パケットがどの仮想のルータに送られたかを決定しなければなりません。 使用される仮想のルータを推論する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が左右対称のトポロジーの多くのルータの間のシェアトラフィックをロードするのに使用されている特定のケースのためにRedirectsを無効にするのは役に立つかもしれません。
8.2. Host ARP Requests
8.2. ホストARP要求
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要求を送るとき、Masterの仮想のルータは仮想のルータのための仮想のMACアドレスでARP要求に応じなければなりません。 Masterの仮想のルータは物理的なMACアドレスで応じてはいけません。 これで、クライアントは現在のMasterルータにかかわらずいつも同じ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ルータがいつ再開するか、そして、ブーツ、それ、SHOULDはそれが所有しているIPアドレスへの物理的なMACアドレスがあるどんなARPメッセージも送らないで、それはVirtual 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応答を遅らせてください。
8.3. Proxy ARP
8.3. プロキシ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.
Proxy ARPがVRRPルータで使用されるつもりであるなら、VRRPルータはProxy ARPメッセージのVirtual Router MACアドレスの広告を出さなければなりません。 別の方法でするのはホストにVRRPルータの本当のMACアドレスを学ばせることができました。
Hinden Standards Track [Page 20] RFC 3768 VRRP April 2004
Hinden規格はVRRP2004年4月にRFC3768を追跡します[20ページ]。
8.4. Potential Forwarding Loop
8.4. 潜在的推進輪
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.
SHOULDがパケットを送らないVRRPルータは、それが所有者でないならAddressがそれがMasterになる(es)であるとIPに扱いました。 これらのパケットを進めると、不要なトラフィックはもたらされるでしょう。 彼らが伝えるパケット(例えば、トークンリング)を受ける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つは、MASTER状態からの/に移行するとき、それぞれの採用されたIPアドレスのために廃棄物ホストルートを加えるか、または削除することです。
9. Operation over FDDI, Token Ring, and ATM LANE
9. FDDI、トークンリング、および気圧車線の上の操作
9.1. Operation over FDDI
9.1. FDDIの上の操作
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が1つ以上のMasterルータをあるかもしれません。 Masterルータがハードウェア・アドレスとして仮想のルータMACアドレスをFDDIデバイスにインストールすると、他のマスターズのADVERTISEMENTSはMaster集合の間、リングから取り外されるでしょう、そして、集合は失敗するでしょう。
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.
これを避けるために、実装SHOULDはハードウェアMACアドレスを変えるよりFDDIデバイスでむしろユニキャストMACフィルタを加えることによって、仮想のルータMACアドレスを構成します。 これは、Masterルータがそれが溯源しなかった少しのADVERTISEMENTSも取り外すのを防ぐでしょう。
9.2. Operation over Token Ring
9.2. トークンリングの上の操作
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.
- どんな一般的なマルチキャストメカニズムも古くて新しいトークンリングアダプターの向こう側に実装をサポートしませんでした。 多くの、より新しいトークンリングアダプターサポートグループアドレスである間、トークンリング機能アドレスサポートは唯一の一般に利用可能なマルチキャストメカニズムです。 トークンリング機能アドレスの限られた数のため、これらは同じトークンリング機能アドレスの他の用法と衝突するかもしれません。
Hinden Standards Track [Page 21] RFC 3768 VRRP April 2004
Hinden規格はVRRP2004年4月にRFC3768を追跡します[21ページ]。
Due to these difficulties, the preferred mode of operation over token ring will be to use a token ring functional address for the VRID virtual MAC address. Token ring functional addresses have the two high order bits in the first MAC address octet set to B'1'. They range from 03-00-00-00-00-80 to 03-00-02-00-00-00 (canonical format). However, unlike multicast addresses, there is only one unique functional address per bit position. The functional addresses 03-00-00-10-00-00 through 03-00-02-00-00-00 are reserved by the Token Ring Architecture [TKARCH] for user-defined applications. However, since there are only 12 user-defined token ring functional addresses, there may be other non-IP protocols using the same functional address. Since the Novell IPX [IPX] protocol uses the 03-00-00-10-00-00 functional address, operation of VRRP over token ring will avoid use of this functional address. In general, token ring VRRP users will be responsible for resolution of other user- defined token ring functional address conflicts.
これらの困難のため、トークンリングの上の操作の最もよく使われる方法はVRIDの仮想のMACアドレスにトークンリング機能アドレスを使用することでしょう。 トークンリング機能アドレスで、最初のMACアドレス八重奏における2高位のビットがB'1'にセットします。 彼らは03-00-00-00-00-80〜03-00-02-00-00-00(正準な形式)まで及びます。 しかしながら、1ビット位置あたり1つのユニークな機能アドレスしかマルチキャストアドレスと異なっていません。 機能アドレス03-00-00-10-00-00〜03-00-02-00-00-00はユーザによって定義されたアプリケーションのためにToken Ring Architecture[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.
VRIDsは直接トークンリング機能アドレスに写像されます。 機能アドレス闘争の見込みを減少させるために、配分は最も大きい機能アドレスで始まるでしょう。 ほとんどの非IPプロトコルが1番目を使用するか、ユーザによって定義された機能アドレスが最初に、結合されて、または1から始まって、VRRPユーザがVRIDsを連続して選ぶと予想されます。
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
VRIDトークンリング機能アドレス---- ----------------------------- 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は正典外の形式において(0×4000>>(VRID--1))と等しいです。
Since a functional address cannot be used as a MAC level source address, the real MAC address is used as the MAC source address in VRRP advertisements. This is not a problem for bridges since packets addressed to functional addresses will be sent on the spanning-tree explorer path [802.1D].
MACの平らなソースアドレスとして機能アドレスを使用できないので、本当のMACアドレスはMACソースアドレスとしてVRRP広告で使用されます。 スパニングツリー探検家経路[802.1D]で機能アドレスに扱われたパケットを送るので、これはブリッジのための問題ではありません。
Hinden Standards Track [Page 22] RFC 3768 VRRP April 2004
Hinden規格はVRRP2004年4月にRFC3768を追跡します[22ページ]。
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アドレスにVRIDsに関する同じマッピングを使用します。 しかしながら、1つの重要な違いが存在しています。 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キャッシュにおけるそれらの送信元経路情報を保って、無料のARPsを聞かないホスト導入があると、オーバースイッチが現れる場合、これらのホストは正しく彼らのARP送信元経路情報をアップデートしないでしょう。 唯一の可能なソリューションは、同じVRIDがあるすべてのルータを同じソースブリッジセグメントに置いて、そのブリッジセグメントが1ポイントの失敗であることを防ぐのにテクニックを使用することです。 これらのテクニックは範囲を超えてこのドキュメントです。
For both the multicast and unicast mode of operation, VRRP advertisements sent to 224.0.0.18 should be encapsulated as described in [RFC1469].
マルチキャストとユニキャスト運転モードの両方に関しては、VRRP広告は.18が[RFC1469]で説明されるようにカプセル化されるべきである.0を224.0に送りました。
9.3. Operation over ATM LANE
9.3. 気圧車線の上の操作
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があるルータのATM LANEの上のVRRPの操作は連結します、そして、LECのプロキシところの後ろのルータはこのドキュメントの範囲を超えています。
10. Security Considerations
10. セキュリティ問題
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
VRRPは現在、どんなタイプの認証も含んでいません。 VRRP仕様の以前のバージョンはなにもから強くなるまで及ぶいくつかのタイプの認証を含んでいました。 運用経験とさらなる分析は、これらがセキュリティの少しの実物的尺度も提供しなかったことを決定しました。 VRRPプロトコルの本質のため、VRRPメッセージが暗号で保護されても、まるでそれらがVRRPマスターであるかのように振る舞うのからの敵対的なルータを防ぎません、複数のマスターを創造して。 VRRPメッセージの認証はそうしたかもしれません。
Hinden Standards Track [Page 23] RFC 3768 VRRP April 2004
Hinden規格はVRRP2004年4月にRFC3768を追跡します[23ページ]。
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を混乱させることができないでも、すべてのルータにバックアップを調べさせるとして、それは、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ができるということであることに注意されるべきです。 MACがL2に言うためにL2ヘッダーで演説するソースがルータの代わりに悪意があるノードにルータに扱われたパケットを送るために切り替わっている間、ルータMACアドレスがあるパケットを送って、どんなルータMACアドレスも発信するので、パケットを受けるLANの悪意があるノードが乱雑に含むことができる攻撃の種類は、彼らのトラフィックを他のどこかに送るようにホストに言うのを向け直して、求められていないARP回答、答えARP要求などを送ってください。 VRRPを実装することの如何にかかわらずこのすべてをできます。 VRRPはこれらの脆弱性に加えません。
Independent of any authentication type VRRP includes a mechanism (setting TTL=255, checking on receipt) that protects against VRRP packets being injected from another remote network. This limits most vulnerabilities to local attacks.
どんな認証の如何にかかわらず、タイプVRRPは別のリモートネットワークから注入されるVRRPパケットから守るメカニズム(領収書を検査して、TTL=255を設定する)を含んでいます。 これはほとんどの脆弱性を地方の攻撃に制限します。
VRRP does not provide any confidentiality. Confidentiality is not necessary for the correct operation of VRRP and there is no information in the VRRP messages that must be kept secret from other nodes on the LAN.
VRRPは少しの秘密性も提供しません。 秘密性はVRRPの正しい操作に必要ではありません、そして、LANの他のノードから秘密にしなければならないVRRPメッセージには情報が全くありません。
11. Acknowledgements
11. 承認
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.
作者は彼らのコメントと提案についてGlenゾルン、マイケル・レイン、クラーク・ブリーマー、ハル・ピーターソン、トニー・李、バーバラ・デニー、ジョエル・アルペルン、スティーブBellovin、トーマスNarten、ロブモンゴメリ、ロブColtun、Radiaパールマン、ラスHousley、ハラルドAlvestrand、スティーブBellovin、ネッド・フリード、テッド・ハーディー、ラスHousley、バートWijnen、ビル・フェナー、およびアレックス・ジニンに感謝したがっています。
12. References
12. 参照
12.1. Normative References
12.1. 引用規格
[802.1D] International Standard ISO/IEC 10038: 1993, ANSI/IEEE Std
802.1D, 1993 edition.
[802.1D]世界規格ISO/IEC10038: 1993 ANSI/IEEE Std 802.1D、1993年の版。
[CKSM] Braden, R., Borman, D. and C. Partridge, "Computing the
Internet checksum", RFC 1071, September 1988.
[CKSM] ブレーデンとR.とボーマンとD.とC.Partridge、「インターネットチェックサムを計算します」、RFC1071、1988年9月。
Hinden Standards Track [Page 24] RFC 3768 VRRP April 2004
Hinden規格はVRRP2004年4月にRFC3768を追跡します[24ページ]。
[HSRP] Li, T., Cole, B., Morton, P. and D. Li, "Cisco Hot Standby
Router Protocol (HSRP)", RFC 2281, March 1998.
[HSRP] 1998年の李とT.とコールとB.とモートンとP.とD.李、「コクチマスホット・スタンバイ機能ルータプロトコル(HSRP)」、RFC2281行進。
[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.シャンド、「ルータの開発は速いフェイルオーバーをIPネットワークに提供するためにクラスタリングします」、デジタル専門誌、第9巻のNo.3、1997年冬。
[IPX] Novell Incorporated., "IPX Router Specification", Version
1.10, October 1992.
[IPX]ノベルが法人組織にした、「IPXルータ仕様」、バージョン1.10、10月1992
[RFC1469] Pusateri, T., "IP Multicast over Token Ring Local Area
Networks", RFC 1469, June 1993.
[RFC1469] Pusateri、T.、「トークンリングローカル・エリア・ネットワークの上のIPマルチキャスト」、RFC1469、1993年6月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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、「仮想のルータ冗長プロトコル」、RFC2338、1998年4月。
[TKARCH] IBM Token-Ring Network, Architecture Reference, Publication
SC30-3374-02, Third Edition, (September, 1989).
[TKARCH]IBMトークンリングネットワーク、アーキテクチャ参照、公表SC30-3374-02、第3版(1989年9月)。
12.2. Informative References
12.2. 有益な参照
[DISC] Deering, S., Ed., "ICMP Router Discovery Messages", RFC
1256, September 1991.
[ディスク] デアリング、S.、エド、「ICMPルータ発見メッセージ」、RFC1256、9月1991日
[DHCP] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997.
[DHCP] Droms、R.、「ダイナミックなホスト構成プロトコル」、RFC2131、1997年3月。
[OSPF] Moy, J., "OSPF version 2", STD 54, RFC 2328, April 1998.
[OSPF]Moy、J.、「OSPF、バージョン2インチ、STD54、RFC2328、1998インチ年4月。
[RIP] Malkin, G., "RIP Version 2", STD 56, RFC 2453, November
1998.
[裂きます] マルキン、G.は「1998年11月にバージョン2インチ、STD56、RFC2453を裂きます」。
13. Changes from RFC 2338
13. RFC2338からの変化
- 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エディタ方針に従うためにRFC2338の作者を新しいContributers部に動かして、R.HindenについてEditorに記載しました。 - VRRPから認証方法を取り除きました。 変化は:だった o パスワードとIPSECのベースの認証のために値を取り除きました。 分野と値は、異なった認証方法の議論を取り除いて、変化に関する動機がわかる新しいテキストを加えて、脆弱性について説明するために後方に広げることができるセキュリティo Updated警備上の配慮部のRFC2338o Removed部との互換性を保つために保有されます。
Hinden Standards Track [Page 25] RFC 3768 VRRP April 2004
Hinden規格はVRRP2004年4月にRFC3768を追跡します[25ページ]。
- 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定義における直っているテキスト。 - Interfaceの代わりにVirtual Router単位であるように認証を変えました。 - ATM LANEの上にそのVRRPを述べる加えられた新しい小区分(9.3)がこのドキュメントの範囲を超えています。 - 容認されたパケット長チェックについて説明するテキストをはっきりさせました。 - 容認された認証チェックについて説明するテキストをはっきりさせました。 - VRID検証チェックについて説明するテキストをはっきりさせました。 - パケットを進めない必要性について説明する加えられた新しい小区分(8.4)がIPアドレスを採用しました。 - セキュリティ問題部に明確化を追加しました。 - インターネットチェックサムを計算する参照を加えました。 - アップデートされた参照と作者情報。 - 様々な小さい編集の変化。
14. Editor's Address
14. エディタのアドレス
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 メールしてください: bob.hinden@nokia.com
Hinden Standards Track [Page 26] RFC 3768 VRRP April 2004
Hinden規格はVRRP2004年4月にRFC3768を追跡します[26ページ]。
15. Full Copyright Statement
15. 完全な著作権宣言文
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.
Copyright(C)インターネット協会(2004)。 このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Hinden Standards Track [Page 27]
Hinden標準化過程[27ページ]
一覧
スポンサーリンク
