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
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的标准解决方案是安全邻居发现（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批准的所有文件都适用于任何级别的互联网标准；见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信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第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标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在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
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.
在共享第2层（L2）网段中运行IPv6时，如果没有所有连接设备的完全安全邻居发现（SEND）支持，或者没有支持SEND[RFC3971]所需的基础设施可用，则始终存在由于恶意路由器广告（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武士]。本文档描述了rogue RA问题[RFC6104]的解决方案框架，其中网段围绕单个二级交换设备或一组二级交换设备设计，这些设备能够识别无效的RA并阻止它们。在此框架内开发的解决方案可以跨越从基本（L2设备的端口被静态指示转发或不转发从连接设备接收的RAs）到高级（advanced）的范围（在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 Guard的L2网络设备即可直接通信时，它不适用于共享媒体。
Figure 1 illustrates a deployment scenario for RA-Guard.
图1展示了RA Guard的部署场景。
Block Allow
+------+ incoming +---------+ incoming +--------+
|Host | RA | L2 | RA | Router |
| |----------------| device |--------------| |
+------+ +----+----+ +--------+
|
|Block
|incoming
|RA
|
|
|
+---+---+
| Host |
| |
+-------+
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可能不适合或不完全受所有相关设备支持的环境中提供补充解决方案。发送在IPv6网络中无处不在，并且它的一些大规模部署方面得到解决，例如使用信任锚为主机提供服务，这可能需要一段时间。同样合理的是，一些设备，如IPv6启用的传感器，可能根本不考虑实现发送。代表主机发送验证RAs的RA Guard实现可能会简化其中的一些挑战。
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可以被视为发送路由器授权的超集。其目的是根据一组标准过滤路由器广告，从简单的“给定接口上不允许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并做出单个决策。分析本身与每个节点将执行的操作并无不同：如果启用了发送，则会根据X.509证书检查RA
[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打算在需要简单性的环境中为流氓RA问题提供简单的解决方案，同时在由支持发送的设备（L2交换机和路由器）和不一致使用发送的设备组成的环境中利用发送。此外，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 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 Guard使用，以根据接收到的RA帧中的信息进行验证：
o Allowed/Disallowed link-layer address of the RA sender
o RA发送方允许/不允许的链路层地址
o Allowed/Disallowed ports for receiving RAs
o 允许/不允许接收RAs的端口
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帧的内容，它将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的唯一接口将是预先分配的路由器接口，而非路由器接口将阻止所有RAs。
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发送者，并存储此信息以允许后续RAs。简单的有状态方案是，L2设备在某个手动配置的时间段内侦听RAs，其中单个实例的侦听时间段的开始和持续时间由手动干预控制。因此，L2设备随后只能在在此期间接收有效RAs的端口上允许后续RAs。通常，只有在L2网络上配置新的IPv6路由器时，才能通过手动配置激活“学习”状态。
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 Guard的状态机可以是全局的、每个接口的或每个对等的，这取决于用于授权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 Guard功能的状态机由四种不同的状态组成：
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 Guard“学习”状态的设备或接口正在主动获取有关连接到其接口的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.
也可以是事件触发的。将收集的信息与预定义的标准（类似于无状态RA Guard规则的标准）进行比较，以确定RAs的有效性。
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 Guard的设备或接口要么阻止“所有”RAs，直到验证其有效性，要么暂时转发“所有”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 Guard且处于阻止状态的设备或接口将阻止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设备操作员明确指示或触发事件提示，接口可以从阻塞状态转换为学习状态。
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并处于转发状态的设备或接口将接受有效的RAs入口并将其转发到目的地。
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.
如果二级设备操作员明确指示或触发事件提示，接口可以从转发状态转换为学习状态。
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设备基于发送考虑因素阻塞或转发RAs。在接口上捕获RA后，L2设备将首先验证加密生成的地址（CGA）[RFC3971]和RSA（用于公钥加密的Rivest、Shamir和Adleman算法）签名，如[RFC3971]第5节所述。如果验证失败，则应放弃RA。然后，它将应用[RFC3971]第6.4.6节所述的主机行为。特别是，二级设备将尝试从其缓存中检索RA中引用的公钥的有效证书。如果找到这样的证书，L2设备将把RA转发到其目的地。如果没有，L2设备将生成带有未指定源地址的认证路径请求（CPS）[RFC3971]，以查询路由器证书。然后，它将捕获证书路径公告（CPA）[RFC3971]并尝试验证证书链。未能验证链将导致RA掉落。验证成功后，二级设备将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 Guard方法来解决。然后，第一个路由器可用于网络时间协议（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-Guard的L2网络设备，并且RA-Guard功能无法抵御恶意RAs。
RA-Guard mechanisms do not offer protection in environments where IPv6 traffic is tunneled.
RA Guard机制在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防护过滤器强制严格遵循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 Guard阻止意外或故意生成的恶意RAs。
The authors dedicate this document to the memory of Jun-ichiro Hagino (itojun) for his contributions to the development and deployment of IPv6.
作者将本文档献给Jun ichiro Hagino（itojun），以纪念他对IPv6的开发和部署所做的贡献。
[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，“安全邻居发现（SEND）”，RFC 39712005年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 48612007年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 59052010年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清除器”，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武士]Hagino（itojun），J.，“IPv6解谜：我的IPv6网络中存在流氓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，“流氓IPv6路由器广告问题声明”，RFC 61042011年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'Enterprises Green Side-法国普罗旺斯-阿尔卑斯-蓝色海岸索菲亚安提波利斯鲁马尼尔大道400号
Phone: +33 49 723 2620
EMail: elevyabe@cisco.com
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比利时
Phone: +32 2704 5473
EMail: gunter@cisco.com
Phone: +32 2704 5473
EMail: gunter@cisco.com
Ciprian Popoviciu Technodyne 111 Wood Ave. S. Iselin, NJ 08830 USA
美国新泽西州伊塞林南伍德大道111号Ciprian Popoviciu Technodyne 08830
Phone: +1 1 919 599-5666
EMail: chip@technodyne.com
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维克多雨果布达佩斯H-1132匈牙利
EMail: mohacsi@niif.hu
EMail: mohacsi@niif.hu