Internet Engineering Task Force (IETF) E. Levy-Abegnoli
Request for Comments: 6105 G. Van de Velde
Category: Informational Cisco Systems
ISSN: 2070-1721 C. Popoviciu
Technodyne
J. Mohacsi
NIIF/Hungarnet
February 2011
IPv6 Router Advertisement Guard
Abstract
抽象
Routed protocols are often susceptible to spoof attacks. The canonical solution for IPv6 is Secure Neighbor Discovery (SEND), a solution that is non-trivial to deploy. This document proposes a light-weight alternative and complement to SEND based on filtering in the layer-2 network fabric, using a variety of filtering criteria, including, for example, SEND status.
ルーテッドプロトコルは、多くの場合、攻撃を偽装影響を受けやすいです。 IPv6のカノニカル溶液は、セキュア近隣探索（SEND）、展開する非自明である溶液です。この文書では、軽量の代替物を提案し、例えば、ステータスを送信するなどのフィルタリング基準、のさまざまな方法を使って、レイヤ2ネットワークファブリックにフィルタリングに基づいて、送信する補完します。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはインターネット標準化過程仕様ではありません。それは、情報提供の目的のために公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 IESGによって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6105.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6105で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。
Table of Contents
目次
1. Introduction ....................................................3
2. Model and Applicability .........................................3
3. Stateless RA-Guard ..............................................5
4. Stateful RA-Guard ...............................................6
4.1. State Machine ..............................................6
4.2. SEND-Based RA-Guard ........................................8
5. RA-Guard Use Considerations .....................................8
6. Security Considerations .........................................9
7. Acknowledgements ................................................9
8. References ......................................................9
8.1. Normative References .......................................9
8.2. Informative References .....................................9
When operating IPv6 in a shared layer-2 (L2) network segment without complete SEcure Neighbor Discovery (SEND) support by all devices connected or without the availability of the infrastructure necessary to support SEND [RFC3971], there is always the risk of facing operational problems due to rogue Router Advertisements (RAs) generated maliciously or unintentionally by unauthorized or improperly configured routers connecting to the segment.
接続されているすべてのデバイスによって、またはSENDをサポートするために必要なインフラの利用可能性なしに[RFC3971]をサポートして（送信）完全セキュア近隣探索せずに、共有レイヤ2（L2）ネットワークセグメントでIPv6を操作する場合、オペレーショナル対向する危険性が常に存在しますルータ広告（RAS）を不正に起因する問題は、セグメントに接続する不正又は不適切に構成ルータによって故意又は意図せずに生成されました。
There are several examples of work done on this topic that resulted in related studies and code, including [NDPMON] [KAME] [IPv6-SAMURAIS]. This document describes a solution framework for the rogue-RA problem [RFC6104] where network segments are designed around a single L2-switching device or a set of L2-switching devices capable of identifying invalid RAs and blocking them. The solutions developed within this framework can span the spectrum from basic (where the port of the L2 device is statically instructed to forward or not to forward RAs received from the connected device) to advanced (where a criterion is used by the L2 device to dynamically validate or invalidate a received RA, this criterion can even be based on SEND mechanisms).
[NDPMON] [KAME] [IPv6の-武士]を含む関連の研究やコードをもたらし、このトピックに行った作業のいくつかの例があります。この文書は、ネットワーク・セグメントが単一L2スイッチング素子又は無効のRAを識別し、それらをブロックすることが可能なL2スイッチング素子のセットの周りに設計されている不正-RA問題[RFC6104]のためのソリューションフレームワークを記述する。この枠組みの中で開発されたソリューションは、（L2デバイスのポートが静的に転送するように指示され、またはRASが接続されたデバイスから受信した転送しない）基準を動的にするL2デバイスによって使用される（高度に塩基性のスペクトルにまたがることができ）検証または受信RAを無効、この基準もSENDメカニズムに基づくことができます。
RA-Guard applies to an environment where all messages between IPv6 end-devices traverse the controlled L2 networking devices. It does not apply to shared media, when devices can communicate directly without going through an RA-Guard-capable L2 networking device.
RA-GuardはIPv6のエンドデバイス間のすべてのメッセージが制御さL2ネットワーキングデバイスを通過する環境に適用されます。デバイスは、RA-ガード対応のL2ネットワーキングデバイスを経由せずに直接通信することができたときには、共有メディアには適用されません。
Figure 1 illustrates a deployment scenario for RA-Guard.
図1は、RA-ガードのための配置シナリオを示しています。
Block Allow
+------+ incoming +---------+ incoming +--------+
|Host | RA | L2 | RA | Router |
| |----------------| device |--------------| |
+------+ +----+----+ +--------+
|
|Block
|incoming
|RA
|
|
|
+---+---+
| Host |
| |
+-------+
Figure 1
図1
RA-Guard does not intend to provide a substitute for SEND-based solutions. It actually intends to provide complementary solutions in those environments where SEND might not be suitable or fully supported by all devices involved. It may take time until SEND is ubiquitous in IPv6 networks and some of its large-scale deployment aspects are sorted out, such as provisioning hosts with trust anchors. It is also reasonable to expect that some devices, such as IPv6-enabled sensors, might not consider implementing SEND at all. An RA-Guard implementation that SEND-validates RAs on behalf of hosts would potentially simplify some of these challenges.
RA-GuardはSENDベースのソリューションの代替を提供する予定はありません。これは、実際にSENDは、適切なまたは完全に関与するすべてのデバイスでサポートされない可能性がありますこれらの環境で補完的なソリューションを提供することを目的とします。 SENDは、信頼アンカーでホストをプロビジョニングするよう、整理されているIPv6ネットワークとその大規模な展開の側面の一部に遍在するまでには時間がかかることがあります。このようなIPv6対応センサーなどの一部のデバイスは、全くSENDの実装を検討していない可能性があることを期待するのも合理的です。ホストに代わってのRAを送信-検証RA-ガードの実装は、潜在的にこれらの課題のいくつかを簡素化します。
RA-Guard can be seen as a superset of SEND with regard to router authorization. Its purpose is to filter Router Advertisements based on a set of criteria, from a simplistic "RA disallowed on a given interface" to "RA allowed from pre-defined sources" and up to a full-fledged SEND "RA allowed from authorized sources only".
RA-Guardはルータの認証に関してSENDのスーパーセットとして見ることができます。その目的は、単純な「所定のインターフェイス上で許可RA」から、基準のセットに基づいて認定ソースからの許可本格的SEND「RAに、最大「RAは、事前定義されたソースからの許可」にルータ広告をフィルタリングすることであるのみ」。
In addition to this granularity on the criteria for filtering out Router Advertisements, RA-Guard introduces the concept of router authorization proxy. Instead of each node on the link analyzing RAs and making an individual decision, a legitimate "node-in-the-middle" performs the analysis on behalf of all other nodes on the link. The analysis itself is not different from what each node would do: if SEND is enabled, the RA is checked against X.509 certificates
ルータ広告をフィルタリングするための基準でこの細かに加えて、RA-Guardはルータの認証プロキシの概念を導入しています。代わりに、リンク解析のRA上の各ノードのおよび個々の意思決定、正規「ノード・イン・ザ・ミドル」は、リンク上の他の全てのノードに代わって分析を行います。分析自体は、各ノードがどうなるのかと変わらない：SENDが有効になっている場合、RAは、X.509証明書と照合されます
[RFC4861]. If any other criterion is in use, such as known L3 (addresses) or L2 (link-layer address, port number) legitimate sources of RAs, the node-in-the middle can use this criterion and filter out any RA that does not comply. If this node-in-the-middle is an L2 device, it will not change the content of the validated RA and will avoid any of the ND-proxy pitfalls.
[RFC4861]。他の基準は、そのような既知のL3（アドレス）またはL2（リンク層アドレス、ポート番号）Rasの合法的な供給源として、使用されている場合、ノードに中間がこの基準を使用しない任意のRAを除外することができ準拠しています。このノード・イン・ザ・ミドルはL2デバイスである場合、それは検証RAの内容を変更せず、NDプロキシ落とし穴のいずれかを避けることができます。
RA-Guard intends to provide simple solutions to the rogue-RA problem in contexts where simplicity is required while leveraging SEND in a context environment consisting of a mix of SEND-capable devices (L2 switches and routers) and devices that do not consistently use SEND. Furthermore, RA-Guard is useful to simplify SEND deployments, as only the L2 switch and the routers are required to carry certificates (their own and the trust anchor certificates).
RA-GuardはSEND対応デバイス（L2スイッチおよびルータ）と一貫してSENDを使用していない機器の混在からなるコンテキスト環境を送って活用しながらシンプルさが必要とされるコンテキストで不正-RAの問題にシンプルなソリューションを提供することを目的とします。唯一のL2スイッチとルータが証明書（自分自身とトラストアンカー証明書）を運ぶために必要とされるさらに、RA-Guardは、SENDの展開を簡素化するのに便利です。
Stateless RA-Guard examines incoming RAs and decides whether to forward or block them based solely on information found in the message or in the L2-device configuration. Typical information available in the frames received, useful for RA validation, is as follows:
ステートレスRA-Guardは、着信のRAを調べ、単独メッセージ又はL2-装置構成で見つかった情報に基づいてそれらを転送するか、ブロックするかを決定します。次のようにフレーム内の利用可能な一般的な情報は、RAの検証のために有用な、受信されます。
o Link-layer address of the sender
送信者のOリンク層アドレス
o Port on which the frame was received
フレームが受信されたOポート
o IP source address
O IPソースアドレス
o Prefix list
Oプレフィックスリスト
The following configuration information created on the L2 device can be made available to RA-Guard, to validate against the information found in the received RA frame:
L2デバイス上で作成された次の設定情報は、受信されたRAのフレームで見つかった情報に対して検証するため、RA-Guardに利用可能にすることができます。
o Allowed/Disallowed link-layer address of the RA sender
RA送信者のO可/許可されていないリンク層アドレス
o Allowed/Disallowed ports for receiving RAs
RAを受信するためのO可/許可されていないポート
o Allowed/Disallowed IP source addresses of the RA sender
RA送信者のO可/不許可IP送信元アドレス
o Allowed Prefix list and Prefix ranges
Oプレフィックスリストおよびプレフィックス範囲を可
o Router Priority
Oルータの優先順位
Once the L2 device has validated the content of the RA frame against the configuration, it forwards the RA to its destination, whether unicast or multicast. Otherwise, the RA is dropped.
L2デバイスがコンフィギュレーションに対するRAフレームの内容を検証した後、それはユニキャストまたはマルチキャストするかどうかを、その宛先にRAを転送します。そうでなければ、RAは削除されます。
An example of a very simple stateless RA-Guard implementation could be a small L2 switch for which there is one interface "statically configured" as the interface connecting to a router, while all other interfaces are for non-router devices. With this small static setup, the only interface forwarding RAs will be the pre-assigned router interface, while the non-router interfaces block all RAs.
他のすべてのインターフェイスは、非ルータデバイスのためであるが、非常に単純なステートレスRA-Guardの実装の例は、ルータに接続するインタフェースとして「静的構成」のインターフェイスが存在しているため、小さなL2スイッチとすることができます。非ルータインターフェイスは、すべてのRASがブロック中にこの小さな静的設定で、唯一のインタフェース転送RAは、事前に割り当てられたルータインターフェイスであろう。
Stateful RA-Guard learns dynamically about legitimate RA senders and stores this information for allowing subsequent RAs. A simple stateful scheme would be for the L2 device to listen to RAs during a certain manually configured period of time, where the start of the listening period and the duration of the listening period for a single instance are controlled by the manual intervention. As a result, the L2 device can then allow subsequent RAs only on those ports on which valid RAs were received during this period. Often, the "LEARNING" state will only be activated by manual configuration when a new IPv6 router is provisioned on the L2 network.
ステートフルRA-Guardは、後続のRAを可能にするための合法的なRAの送信者と保存についてこの情報を動的に学習します。 L2デバイスがリスニング期間のスタートと単一インスタンスのリスニング期間の持続時間は、手動介入によって制御される一定の手動で設定期間中のRAを聞くことのための単純なステートフル方式があろう。その結果、L2デバイスは、唯一の有効なRASは、この期間中に受信した上で、これらのポート上の次のRAを可能にすることができます。新しいIPv6ルータは、L2ネットワーク上でプロビジョニングされたとき、多くの場合、「学習」状態にのみ、手動設定によって活性化されます。
A more sophisticated stateful scheme is based on SEND and is described in Section 4.2.
より洗練されたステートフルなスキームは、SENDに基づいており、4.2節に記述されています。
The state machine for stateful RA-Guard can be global, per-interface, or per-peer, depending on the scheme used for authorizing RAs.
ステートフルRA-ガードのためのステートマシンは、RASを承認するために使用される方式に応じて、インターフェイス単位、またはごとピア、グローバルとすることができます。
When RA-Guard is SEND-based, the state machine is per-peer and defined in [RFC3971].
RA-GuardはSENDベースである場合、状態マシンごとのピアであり、[RFC3971]で定義されます。
When RA-Guard is using a discovery method, the state machine of the RA-Guard capability consists of four different states:
RA-ガードが発見方法を使用している場合は、RA-ガード機能のステートマシンは、4つの異なる状態で構成されています。
o State 1: OFF
O状態1：OFF
A device or interface in the RA-Guard "OFF" state operates as if the RA-Guard capability is not available.
RAガード機能が利用できないかのようにRA-Guardの「OFF」状態にあるデバイスまたはインターフェースが動作します。
o State 2: LEARNING
O状態2：学習
A device or interface in the RA-Guard "LEARNING" state is actively acquiring information about the IPv6 routing devices connected to its interfaces. The learning process takes place over a pre-defined unique period of time, as set by manual configuration;
RA-ガード「学習」状態にあるデバイスまたはインターフェースは、積極的インターフェイスに接続されたIPv6ルーティングデバイスに関する情報を取得します。手動設定で設定された学習プロセスは、時間の事前定義されたユニークな期間にわたって行われます。
or it can be event-triggered. The information gathered is compared against pre-defined criteria (criteria similar to the stateless RA-Guard rules) to qualify the validity of the RAs.
またはそれは、イベントトリガすることができます。収集された情報は、Rasの妥当性を修飾する（ステートレスRAガードルールと同様基準）事前定義された基準と比較されます。
In this state, the RA-Guard-enabled device or interface is either blocking "all" RAs until their validity is verified or, alternatively, it can temporarily forward "all" of the RAs until their validity is verified.
その有効性が確認されるまで、この状態では、RA-ガード対応デバイスまたはインタフェースのいずれか、それは、Rasの「すべて」を一時的前進、あるいは、できるその有効性が検証されるまで、「すべて」のRAをブロックしたりしています。
When the L2 device reaches the end of the LEARNING state, it has a record of which interfaces are attached to links with valid IPv6 routers. The L2 device transitions each interface from the LEARNING state into either the BLOCKING state if there was no valid IPv6 router discovered at the interface, or into the FORWARDING state if there was a valid IPv6 router discovered.
L2デバイスはLEARNING状態の終わりに到達すると、それはインタフェースが有効なIPv6ルータとのリンクに取り付けられているのレコードを有しています。 L2デバイス遷移遮断状態のいずれかにLEARNING状態から各インタフェース発見の有効なIPv6ルータがあった場合の界面で、または転送状態に発見された有効なIPv6ルータが存在しない場合。
o State 3: BLOCKING
O状態3：BLOCKING
A device or interface running RA-Guard and in the BLOCKING state will block ingress RA messages.
デバイスまたはインターフェースRAガードを実行し、ブロッキング状態では、入力RAメッセージをブロックします。
An interface can transition from the BLOCKING state into the FORWARDING state directly if explicitly instructed by the L2-device operator.
明示的L2-デバイスオペレータによって指示された場合のインターフェースを直接転送状態に遮断状態から遷移することができます。
An interface can transition from the BLOCKING state into the LEARNING state if either explicitly instructed by the L2-device operator or prompted by a triggered event.
明示的トリガイベントによってL2-デバイスオペレータによって指示または要求された場合のインターフェースはLEARNING状態に遮断状態から遷移することができます。
o State 4: FORWARDING
O状態4：フォワーディング
A device or interface running RA-Guard and in the FORWARDING state will accept valid ingress RAs and forward them to their destination.
RA-Guardとフォワーディングステートで実行しているデバイスまたはインタフェースが有効な入口のRAを受け入れ、彼らの宛先に転送されます。
An interface can transition from the FORWARDING state into the BLOCKING state directly if explicitly instructed by the L2-device operator.
明示的L2-デバイスオペレータによって指示された場合のインターフェースを直接遮断状態にフォワーディング状態から遷移することができます。
An interface can transition from the FORWARDING state into the LEARNING state if either explicitly instructed by the L2-device operator or prompted by a triggered event.
明示的トリガイベントによってL2-デバイスオペレータによって指示または要求された場合のインターフェースはLEARNING状態にフォワーディング状態から遷移することができます。
The transition between these states can be triggered by manual configuration or by meeting a pre-defined criterion.
これらの状態間の遷移は、手動で設定するか、または事前定義された基準を満たすことによってトリガすることができます。
In this scenario, the L2 device is blocking or forwarding RAs based on SEND considerations. Upon capturing an RA on the interface, the L2 device will first verify the Cryptographically Generated Address (CGA) [RFC3971] and the RSA (Rivest, Shamir, and Adleman algorithm for public-key cryptography) signature, as specified in Section 5 of [RFC3971]. The RA should be dropped in case of failure of this verification. It will then apply host behavior as described in Section 6.4.6 of [RFC3971]. In particular, the L2 device will attempt to retrieve a valid certificate from its cache for the public key referred to in the RA. If such a certificate is found, the L2 device will forward the RA to its destination. If not, the L2 device will generate a Certification Path Solicitation (CPS) [RFC3971] with an unspecified source address, to query the router certificate(s). It will then capture the Certification Path Advertisement (CPA) [RFC3971] and attempt to validate the certificate chain. Failure to validate the chain will result in dropping the RA. Upon validation success, the L2 device will forward the RA to its destination and store the router certificate in its cache.
このシナリオでは、L2デバイスは、SENDの考慮に基づいて、RAのをブロックまたは転送されます。のセクション5で指定されたインターフェイス上でRAを取り込む際に、L2デバイスは、第1、暗号化生成アドレス（CGA）[RFC3971]及び署名RSA（公開鍵暗号のためのRivest、Shamir、およびAdlemanのアルゴリズム）を検証します[ RFC3971]。 RAは、この検証が失敗した場合にドロップする必要があります。 [RFC3971]のセクション6.4.6で説明したように、それは、ホストの動作が適用されます。具体的には、L2デバイスは、RAで言及した公開鍵のためにそのキャッシュから有効な証明書を取得しようとします。そのような証明書が見つかった場合、L2デバイスがその宛先にRAを転送します。そうでない場合、L2デバイスは、ルータ証明書を照会するために、不特定の送信元アドレスと証明経路要請（CPS）[RFC3971]を生成します。その後、証明のパス広告（CPA）[RFC3971]をキャプチャし、証明書チェーンを検証しようとします。チェーンを検証に失敗すると、RAをドロップになります。検証成功すると、L2デバイスは、その宛先にRAを転送し、そのキャッシュ内のルータの証明書を格納します。
In order to operate in this scenario, the L2 device should be provisioned with a trust anchor certificate, as specified in Section 6 of [RFC3971]. It may also establish layer-3 connectivity with a Certificate Revocation List (CRL) Certification Path Advertisement server and/or with an NTP server. A bootstrapping issue in this case can be resolved by using the configuration method to specify a trusted port to a first router, and the SEND-based RA-Guard method on all other ports. The first router can then be used for Network Time Protocol (NTP) [RFC5905] and CRL connectivity.
[RFC3971]のセクション6で指定されるように、このシナリオで動作するために、L2デバイスは、トラストアンカ証明書を使用してプロビジョニングされるべきです。また、証明書失効リスト（CRL）証明のパス広告サーバと、および/またはNTPサーバとレイヤ3接続を確立することができます。この場合、ブートストラップの問題は、他のすべてのポートで最初のルータに信頼されたポートを指定するための設定方法を使用して、SENDベースのRA-ガード方法によって解決することができます。最初のルータは、ネットワークタイムプロトコル（NTP）[RFC5905]とCRLの接続に使用することができます。
The RA-Guard mechanism is effective only when all messages between IPv6 devices in the target environment traverse controlled L2 networking devices. In the case of environments such as Ethernet hubs, devices can communicate directly without going through an RA-Guard-capable L2 networking device, and the RA-Guard feature cannot protect against rogue RAs.
RA-ガード機構は、ターゲット環境におけるIPv6デバイス間のすべてのメッセージは、L2ネットワークデバイスを制御トラバース場合にのみ有効です。イーサネットハブなどの環境の場合には、装置は、RA-ガード対応L2ネットワーク装置を介さずに直接通信することができ、およびRA-Guard機能は、不正なバーRASから保護することができません。
RA-Guard mechanisms do not offer protection in environments where IPv6 traffic is tunneled.
RA-ガードメカニズムは、IPv6トラフィックをトンネリングされた環境での保護を提供していません。
Once RA-Guard has set up the proper criteria (for example, it specified that a port is allowed to receive RAs, or it identified legitimate sources of RAs or certificate bases [RFC4861]), then there are no possible instances of accidentally filtered legitimate Router Advertisements, assuming the RA-Guard filter enforcement strictly follows the RA-Guard set criteria.
RA-Guardは、適切な基準を（例えば、それはポートがのRAを受信するように許可されている指定された、またはそれがRASまたは証明書ベースの合法的な情報源を特定し、[RFC4861]）を設定したら、その後、誤って濾過正規のない可能なインスタンスが存在しませんRA-ガードフィルタの適用を想定したルータ広告は、厳密にRA-ガードの設定基準に従っています。
In Section 4.1, a simple mechanism to dynamically learn the valid IPv6 routers connected to an L2 device is explained. It is important that this LEARNING state is only entered intentionally by manual configuration. The list of learned IPv6 routers should be verified by the network manager to make sure that it corresponds with the expected valid RA list. This procedure will make sure that either accidentally or intentionally generated rogue RAs are blocked by RA-Guard.
4.1節では、動的にL2デバイスに接続されている有効なIPv6ルータを学ぶための簡単なメカニズムが説明されています。この学習状態のみ、手動設定によって意図的に入力されていることが重要です。学んだのIPv6ルータのリストは、それが期待される有効なRAのリストに対応することを確認するために、ネットワーク管理者が確認する必要があります。この手順は、どちらか偶然か意図的に生成された不正のRAがRA-ガードによってブロックされていることを確認します。
The authors dedicate this document to the memory of Jun-ichiro Hagino (itojun) for his contributions to the development and deployment of IPv6.
著者は、IPv6の開発と展開への貢献のために6月-一郎萩野（いとぢゅん）のメモリにこの文書を捧げます。
[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3971] Arkko、J.、編、ケンプ、J.、Zill、B.、およびP. Nikander、 "セキュア近隣探索（SEND）"、RFC 3971、2005年3月。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[RFC4861] Narten氏、T.、Nordmarkと、E.、シンプソン、W.、およびH.ソリマン、 "IPバージョン6（IPv6）のための近隣探索"、RFC 4861、2007年9月。
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, June 2010.
[RFC5905]ミルズ、D.、マーティン、J.、エド、バーバンク、J.、およびW. Kasch、 "ネットワークタイムプロトコルバージョン4：プロトコルとアルゴリズムの仕様"、RFC 5905、2010年6月。
[NDPMON] LORIA/INRIA, "NDPMon - IPv6 Neighbor Discovery Protocol Monitor", November 2007, <http://ndpmon.sourceforge.net/>.
[NDPMON] LORIA / INRIA、 "NDPMon - IPv6近隣探索プロトコルモニター"、2007年11月、<http://ndpmon.sourceforge.net/>。
[KAME] KAME Project, "rafixd - developed at KAME - An active rogue RA nullifier", November 2007, <http://www.kame.net/>.
[KAME] KAMEプロジェクト、 "rafixd - KAMEで開発 - アクティブな不正RAのnullifier"、2007年11月、<http://www.kame.net/>。
[IPv6-SAMURAIS] Hagino (itojun), J., "IPv6 demystified: I have a problem with rogue RAs in my IPv6 network", 2007, <http://ipv6samurais.com/>.
[IPv6の-武士]萩野（いとぢゅん）、J.は、 "IPv6は詳解：私は私のIPv6ネットワークに不正なバーRASに問題がある" <http://ipv6samurais.com/>、2007年。
[RFC6104] Chown, T. and S. Venaas, "Rogue IPv6 Router Advertisement Problem Statement", RFC 6104, February 2011.
[RFC6104]のchown、T.とS. Venaas、 "ローグのIPv6ルータアドバタイズメントの問題に関する声明"、RFC 6104、2011年2月。
Authors' Addresses
著者のアドレス
Eric Levy-Abegnoli Cisco Systems Village d'Entreprises Green Side - 400, Avenue Roumanille Biot - Sophia Antipolis, PROVENCE-ALPES-COTE D'AZUR 06410 France
エリック・レヴィ・Abegnoliシスコシステムズエンタープライズヴィレッジグリーンサイド - 400アベニューRoumanilleビオ - ソフィアアンティポリス、プロヴァンス・コートダジュール06410フランス
Phone: +33 49 723 2620 EMail: elevyabe@cisco.com
電話：+33 49 723 2620 Eメール：elevyabe@cisco.com
Gunter Van de Velde Cisco Systems De Kleetlaan 6a Diegem 1831 Belgium
ギュンター・ヴァン・デ・ヴェルデシスコシステムズKleetlaan図6aディーゲム1831ベルギー
Phone: +32 2704 5473 EMail: gunter@cisco.com
電話：+32 2704 5473 Eメール：gunter@cisco.com
Ciprian Popoviciu Technodyne 111 Wood Ave. S. Iselin, NJ 08830 USA
シプリアンPopoviciu Technodyne 111ウッドアベニュー。 S.アイセリン、NJ 08830 USA
Phone: +1 1 919 599-5666 EMail: chip@technodyne.com
電話：+1 1 919 599-5666 Eメール：chip@technodyne.com
Janos Mohacsi NIIF/Hungarnet 18-22 Victor Hugo Budapest H-1132 Hungary
ヤーノシュMohacsi NIIF / Hungarnet 18-22ヴィクトル・ユゴーブダペストH-1132ハンガリー
EMail: mohacsi@niif.hu
メールアドレス：mohacsi@niif.hu