[要約] RFC 6105は、IPv6ルータ広告ガードの仕様を定義しています。その目的は、不正なルータ広告からの攻撃を防ぐために、ネットワークセキュリティを強化することです。
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
IPv6ルーター広告ガード
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の標準的なソリューションは、展開するのが重要ではないソリューションである安全な近隣発見（送信）です。このドキュメントは、たとえばSENTステータスを含むさまざまなフィルタリング基準を使用して、Layer-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によって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。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を操作する場合、常に運用に直面するリスクがありますRogue Router Advertisements（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-samurais]を含む関連研究とコードをもたらしたこのトピックに関する作業の例がいくつかあります。このドキュメントでは、Rogue-RA問題[RFC6104]のソリューションフレームワークについて説明します。ここでは、ネットワークセグメントが単一のL2スイッチングデバイスまたは無効なRAを識別してブロックできる一連のL2スイッチングデバイスを中心に設計されています。このフレームワーク内で開発されたソリューションは、基本（L2デバイスのポートが、接続されたデバイスから受信したRASを転送または転送しないように静的に指示されている場合）から高度（L2デバイスによって基準がL2デバイスによって使用されている場合）から動的に使用されるように、静的に指示されている場合があります。受信したRAを検証または無効にすると、この基準は送信メカニズムに基づいている場合さえできます）。
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は、送信ベースのソリューションの代替品を提供するつもりはありません。実際には、送信が関係するすべてのデバイスに適していない、または完全にサポートされていない環境で補完的なソリューションを提供する予定です。送信がIPv6ネットワークでユビキタスになるまで時間がかかる場合があり、その大規模な展開の側面の一部は、信頼できるアンカーのホストをプロビジョニングするなど、整理されています。また、IPv6対応センサーなどの一部のデバイスが送信の実装をまったく検討しないことを期待することも合理的です。ホストに代わって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ガードは、ルーター認証に関して送信のスーパーセットと見なすことができます。その目的は、一連の基準に基づいてルーターの広告をフィルタリングすることです。単純な「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は、ルーター広告を除外するための基準に関するこの粒度に加えて、ルーター認証プロキシの概念を紹介します。RASを分析して個別の決定を下すリンク上の各ノードの代わりに、正当な「中間ノード」は、リンク上の他のすべてのノードに代わって分析を実行します。分析自体は、各ノードが行うことと違いはありません。送信が有効になっている場合、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の正当なソースなどの他の基準が使用されている場合、中間ノードはこの基準を使用して、準拠。この中間ノードがL2デバイスである場合、検証されたRAのコンテンツを変更せず、ND-Proxyの落とし穴を回避します。
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は、送信可能なデバイス（L2スイッチとルーター）の組み合わせで構成されるコンテキスト環境での送信を活用しながら、シンプルさが必要なコンテキストでRogue-RAの問題に簡単なソリューションを提供することを意図しています。。さらに、RA-Guardは、L2スイッチとルーターのみが証明書（独自のアンカー証明書と信頼のアンカー証明書）を携帯するために必要であるため、送信展開を簡素化するのに役立ちます。
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ガードは、着信RASを調べ、メッセージまたは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フレームで見つかった情報に対して検証できます。
o Allowed/Disallowed link-layer address of the RA sender
o RA送信者のリンク層アドレスを許可/許可しない
o Allowed/Disallowed ports for receiving RAs
o RAを受信するための許可/許可されたポート
o Allowed/Disallowed IP source addresses of the RA sender
o RA送信者の許可/許可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フレームのコンテンツを検証すると、UnicastまたはMulticastであろうと、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ガードの実装の例は、ルーターに接続するインターフェイスとして「静的に構成された」1つのインターフェイスがあり、他のすべてのインターフェイスが非ルーターデバイス用であるという小さな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ガードは、正当なRA送信者について動的に学び、この情報を保存して、その後のRAを許可します。簡単なステートフルなスキームは、L2デバイスが特定の手動で構成された期間中にRAを聴くことです。ここでは、リスニング期間の開始と1つのインスタンスのリスニング期間の期間が手動介入によって制御されます。その結果、L2デバイスは、この期間中に有効なRAが受信されたポートでのみ後続のRASを許可できます。多くの場合、「学習」状態は、新しいIPv6ルーターがL2ネットワークにプロビジョニングされている場合にのみ、手動構成によって作動します。
A more sophisticated stateful scheme is based on SEND and is described in Section 4.2.
より洗練されたステートフルスキームは送信に基づいており、セクション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が送信ベースの場合、状態マシンはピアごとに[RFC3971]で定義されています。
When RA-Guard is using a discovery method, the state machine of the RA-Guard capability consists of four different states:
Ra-Guardが発見方法を使用している場合、RAガード機能の状態マシンは4つの異なる状態で構成されています。
o State 1: OFF
o 状態1：オフ
A device or interface in the RA-Guard "OFF" state operates as if the RA-Guard capability is not available.
RAガードの「オフ」状態のデバイスまたはインターフェイスは、RAガード機能が利用できないかのように動作します。
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ガード対応のデバイスまたはインターフェイスは、有効性が検証されるまで「すべて」RAをブロックするか、あるいはその有効性が検証されるまでRASのすべての「すべて」を一時的に転送できます。
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デバイスが学習状態の終わりに到達すると、有効なIPv6ルーターとのリンクにインターフェイスが接続されているレコードがあります。L2デバイスは、インターフェイスで発見された有効なIPv6ルーターがない場合は、学習状態からブロッキング状態のいずれかに各インターフェイスを遷移するか、有効なIPv6ルーターが発見された場合は転送状態に移行します。
o State 3: BLOCKING
o 状態3：ブロック
A device or interface running RA-Guard and in the BLOCKING state will block ingress RA messages.
RAガードを実行しているデバイスまたはインターフェイスとブロッキング状態で、Ingress RAメッセージをブロックします。
An interface can transition from the BLOCKING state into the FORWARDING state directly if explicitly instructed by the L2-device operator.
L2-Deviceオペレーターによって明示的に指示された場合、インターフェイスはブロッキング状態から転送状態に直接移行できます。
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-Deviceオペレーターが明示的に指示するか、トリガーされたイベントによってプロンプトされた場合、インターフェイスはブロッキング状態から学習状態に移行できます。
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ガードを実行しているデバイスまたはインターフェイスおよびフォワーディング状態では、有効なイングレスRASを受け入れ、それらを目的地に転送します。
An interface can transition from the FORWARDING state into the BLOCKING state directly if explicitly instructed by the L2-device operator.
L2-Deviceオペレーターによって明示的に指示された場合、インターフェイスは転送状態からブロッキング状態に直接移行できます。
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-Deviceオペレーターが明示的に指示するか、トリガーされたイベントによってプロンプトされた場合、インターフェイスは転送状態から学習状態に移行できます。
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デバイスは、考慮事項の送信に基づいてRAをブロックまたは転送しています。インターフェイス上のRAをキャプチャすると、L2デバイスは、最初に暗号化されたアドレス（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接続を確立する場合があります。この場合のブートストラップの問題は、構成方法を使用して最初のルーターに信頼できるポートを指定し、他のすべてのポートで送信ベースの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-Guardメカニズムは、ターゲット環境のIPv6デバイス間のすべてのメッセージがL2ネットワーキングデバイスを通過した場合にのみ有効です。イーサネットハブなどの環境の場合、デバイスはRAガード対応のL2ネットワーキングデバイスを通過することなく直接通信でき、RAガード機能はRogue 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が適切な基準を設定すると（たとえば、ポートがRASを受信することを許可されていること、またはRASまたは証明書ベースの正当なソース[RFC4861]を特定することが許可されていることを指定しました）、誤ってフィルタリングされた合法的な事例はありません。RA-Guardフィルターの施行が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の開発と展開への貢献について、Jun-Ichiro Hagino（Itojun）の記憶に捧げています。
[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3971] Arkko、J.、Ed。、Kempf、J.、Zill、B。、およびP. Nikander、「Secure Neighbor Discovery（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.、Simpson、W。、およびH. Soliman、「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] Mills、D.、Martin、J.、Ed。、Burbank、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 neighbor discoveryプロトコルモニター」、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 Project、「RafixD -Kameで開発 - アクティブなRogue 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-samurais] hagino（itojun）、J。、「IPv6 Demystified：私はIPv6ネットワークでRogue Rasに問題があります」、2007年、<http://ipv6samurais.com/>。
[RFC6104] Chown, T. and S. Venaas, "Rogue IPv6 Router Advertisement Problem Statement", RFC 6104, February 2011.
[RFC6104] Chown、T。およびS. Venaas、「Rogue 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
Eric Levy-Abegnoli Cisco Systems Village D'Entreprises Green Side-400、Avenue Roumanille Biot-Sophia Antipolis、Provence-Alpes-Cote D'Azur 06410 France
Phone: +33 49 723 2620
EMail: elevyabe@cisco.com
Gunter Van de Velde Cisco Systems De Kleetlaan 6a Diegem 1831 Belgium
Gunter Van de Velde Cisco Systems de Kleetlaan 6a Diegem 1831 Belgium
Phone: +32 2704 5473
EMail: gunter@cisco.com
Ciprian Popoviciu Technodyne 111 Wood Ave. S. Iselin, NJ 08830 USA
Ciprian Popoviciu Technodyne 111 Wood Ave. S. Iselin、NJ 08830 USA
Phone: +1 1 919 599-5666
EMail: chip@technodyne.com
Janos Mohacsi NIIF/Hungarnet 18-22 Victor Hugo Budapest H-1132 Hungary
Janos Mohacsi Niif/Hungarnet 18-22 Victor Hugo Budapest H-1132ハンガリー
EMail: mohacsi@niif.hu