Internet Engineering Task Force (IETF) T. Chown
Request for Comments: 6104 University of Southampton
Category: Informational S. Venaas
ISSN: 2070-1721 Cisco Systems
February 2011
Internet Engineering Task Force (IETF) T. Chown
Request for Comments: 6104 University of Southampton
Category: Informational S. Venaas
ISSN: 2070-1721 Cisco Systems
February 2011
Rogue IPv6 Router Advertisement Problem Statement
流氓IPv6路由器播发问题声明
Abstract
摘要
When deploying IPv6, whether IPv6-only or dual-stack, routers are configured to send IPv6 Router Advertisements (RAs) to convey information to nodes that enable them to autoconfigure on the network. This information includes the implied default router address taken from the observed source address of the RA message, as well as on-link prefix information. However, unintended misconfigurations by users or administrators, or possibly malicious attacks on the network, may lead to bogus RAs being present, which in turn can cause operational problems for hosts on the network. In this document, we summarise the scenarios in which rogue RAs may be observed and present a list of possible solutions to the problem. We focus on the unintended causes of rogue RAs in the text. The goal of this text is to be Informational, and as such to present a framework around which solutions can be proposed and discussed.
在部署IPv6时，无论是仅IPv6还是双栈，路由器都配置为发送IPv6路由器广告（RAs），以将信息传递给节点，使其能够在网络上自动配置。此信息包括从RA消息的观察源地址中获取的隐含默认路由器地址，以及链路前缀信息。但是，用户或管理员无意中的错误配置，或可能对网络进行的恶意攻击，可能会导致存在虚假RAs，从而导致网络上主机的操作问题。在本文档中，我们总结了可能观察到流氓RAs的场景，并给出了问题的可能解决方案列表。在本文中，我们重点讨论了流氓RAs的意外原因。本文的目标是提供信息，并因此提出一个框架，围绕该框架可以提出和讨论解决方案。
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/rfc6104.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6104.
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 ....................................................4
2. Bogus RA Scenarios ..............................................4
2.1. Administrator Misconfiguration .............................5
2.2. User Misconfiguration ......................................5
2.3. Malicious Misconfiguration .................................5
3. Methods to Mitigate against Rogue RAs ...........................6
3.1. Manual Configuration .......................................6
3.2. Introducing RA Snooping ....................................6
3.3. Using ACLs on Managed Switches .............................7
3.4. SEcure Neighbor Discovery (SEND) ...........................7
3.5. Router Preference Option ...................................8
3.6. Relying on Layer 2 Admission Control .......................8
3.7. Using Host-Based Packet Filters ............................8
3.8. Using an "Intelligent" Deprecation Tool ....................8
3.9. Using Layer 2 Partitioning .................................9
3.10. Adding Default Gateway/Prefix Options to DHCPv6 ...........9
4. Scenarios and Mitigations ......................................10
5. Other Related Considerations ...................................11
5.1. Unicast RAs ...............................................11
5.2. The DHCP versus RA Threat Model ...........................11
5.3. IPv4-Only Networks ........................................12
5.4. Network Monitoring Tools ..................................12
5.5. Recovering from Bad Configuration State ...................12
5.6. Isolating the Offending Rogue RA Source ...................13
6. Conclusions ....................................................13
7. Security Considerations ........................................14
8. Acknowledgments ................................................14
9. Informative References .........................................15
1. Introduction ....................................................4
2. Bogus RA Scenarios ..............................................4
2.1. Administrator Misconfiguration .............................5
2.2. User Misconfiguration ......................................5
2.3. Malicious Misconfiguration .................................5
3. Methods to Mitigate against Rogue RAs ...........................6
3.1. Manual Configuration .......................................6
3.2. Introducing RA Snooping ....................................6
3.3. Using ACLs on Managed Switches .............................7
3.4. SEcure Neighbor Discovery (SEND) ...........................7
3.5. Router Preference Option ...................................8
3.6. Relying on Layer 2 Admission Control .......................8
3.7. Using Host-Based Packet Filters ............................8
3.8. Using an "Intelligent" Deprecation Tool ....................8
3.9. Using Layer 2 Partitioning .................................9
3.10. Adding Default Gateway/Prefix Options to DHCPv6 ...........9
4. Scenarios and Mitigations ......................................10
5. Other Related Considerations ...................................11
5.1. Unicast RAs ...............................................11
5.2. The DHCP versus RA Threat Model ...........................11
5.3. IPv4-Only Networks ........................................12
5.4. Network Monitoring Tools ..................................12
5.5. Recovering from Bad Configuration State ...................12
5.6. Isolating the Offending Rogue RA Source ...................13
6. Conclusions ....................................................13
7. Security Considerations ........................................14
8. Acknowledgments ................................................14
9. Informative References .........................................15
The Neighbor Discovery protocol [RFC4861] describes the operation of IPv6 Router Advertisements (RAs) that are used to determine node configuration information during the IPv6 autoconfiguration process, whether that node's configuration is stateful, via the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315] or stateless, as per [RFC4862], possibly in combination with DHCPv6 Light [RFC3736].
邻居发现协议[RFC4861]描述了IPv6路由器播发（RAs）的操作，这些播发用于在IPv6自动配置过程中通过IPv6动态主机配置协议（DHCPv6）[RFC3315]或无状态来确定节点的配置信息，如图所示[RFC4862]，可能与DHCPv6灯[RFC3736]结合使用。
In observing the operation of deployed IPv6 networks, it is apparent that there is a problem with undesired or "bogus" IPv6 RAs appearing on network links or subnets. By "bogus" we mean RAs that were not the intended configured RAs, but rather RAs that have appeared for some other reason. While the problem appears more common in shared wireless environments, it is also seen on wired enterprise networks.
在观察已部署IPv6网络的运行情况时，很明显，网络链路或子网上出现了不希望出现的或“伪造”的IPv6 RAs。所谓“伪造”，我们指的是不是预期配置的RAs，而是由于其他原因出现的RAs。虽然这个问题在共享无线环境中更为常见，但在有线企业网络中也可以看到。
The problem with rogue RAs is that they can cause partial or complete failure of operation of hosts on an IPv6 link. For example, the default router address is drawn directly from the source address of the RA message. In addition, rogue RAs can cause hosts to assume wrong prefixes to be used for stateless address autoconfiguration. In a case where there may be mixing of "good" and "bad" RAs, a host might keep on using the "good" default gateway, but pick a wrong source address, leading to egress filtering problems. As such, rogue RAs are an operational issue for which solution(s) are required, and for which best practice needs to be conveyed. This not only includes preventing or detecting rogue RAs, but also where necessary ensuring the network (and hosts on the network) have the ability to quickly recover from a state where host configuration is incorrect as a result of processing such an RA.
rogue RAs的问题在于，它们可能导致IPv6链路上主机的部分或完全操作失败。例如，默认路由器地址直接从RA消息的源地址提取。此外，恶意RAs可能会导致主机假定错误的前缀用于无状态地址自动配置。在可能混合使用“好”和“坏”RAs的情况下，主机可能会继续使用“好”默认网关，但选择错误的源地址，从而导致出口过滤问题。因此，流氓RAs是一个需要解决方案的操作问题，需要传达最佳实践。这不仅包括防止或检测恶意RAs，还包括在必要时确保网络（以及网络上的主机）能够从主机配置因处理此类RAs而不正确的状态中快速恢复。
In the next section, we discuss the scenarios that may give rise to rogue RAs being present. In the following section, we present some candidate solutions for the problem, some of which may be more practical to deploy than others. This document focuses on "accidental" rogue RAs; while malicious RAs are of course also possible, the common problem today lies with unintended RAs. In addition, a network experiencing malicious attack of this kind is likely to also experience malicious Neighbor Advertisement (NA) and related messages.
在下一节中，我们将讨论可能导致出现流氓RAs的场景。在下一节中，我们将为该问题提供一些备选解决方案，其中一些解决方案可能比其他解决方案更易于部署。本文件主要关注“意外”流氓RAs；虽然恶意的RAs当然也有可能，但今天的常见问题在于意外的RAs。此外，遇到此类恶意攻击的网络也可能遇到恶意邻居广告（NA）和相关消息。
There are three broad classes of scenario in which bogus RAs may be introduced to an IPv6 network.
有三大类场景可将伪RAs引入IPv6网络。
Here an administrator incorrectly configures RAs on a router interface, causing incorrect RAs to appear on links and causing hosts to generate incorrect or unintended IPv6 address, gateway, or other information. In such a case, the default gateway may be correct, but a host might for example become multiaddressed, possibly with a correct and incorrect address based on a correct and incorrect prefix. There is also the possibility of other configuration information being misconfigured, such as the lifetime option.
此处，管理员在路由器接口上错误地配置RAs，导致不正确的RAs出现在链路上，并导致主机生成不正确或意外的IPv6地址、网关或其他信息。在这种情况下，默认网关可能是正确的，但主机可能例如变为多地址，可能基于正确和不正确的前缀使用正确和不正确的地址。还存在其他配置信息被错误配置的可能性，例如生存期选项。
In the case of a Layer 2 IEEE 802.1Q Virtual LAN (VLAN) misconfiguration, RAs may "flood" to unintended links, causing hosts or more than one link to potentially become incorrectly multiaddressed, with possibly two different default routers available.
在第2层IEEE 802.1Q虚拟LAN（VLAN）配置错误的情况下，RAs可能会“泛滥”到非预期链路，导致主机或多个链路可能被错误地多寻址，可能有两个不同的默认路由器可用。
In this case, a user's device "accidentally" transmits RAs onto the local link, potentially adding an additional default gateway and associated prefix information.
在这种情况下，用户的设备“意外”将RAs传输到本地链路上，可能会添加额外的默认网关和相关前缀信息。
This seems to typically be seen on wireless (though sometimes wired) networks where a laptop has enabled the Windows Internet Connection Sharing (ICS) service, which can turn a host into a 6to4 [RFC3056] gateway; this can be a useful feature, unless of course it is run when not intended. This service can also cause IPv4 problems, as it will typically start a "rogue" DHCPv4 server on the host.
这似乎在无线（尽管有时是有线）网络上常见，其中笔记本电脑启用了Windows Internet连接共享（ICS）服务，可以将主机转换为6to4[RFC3056]网关；这可能是一个有用的特性，当然，除非它是在非预期的情况下运行的。此服务还可能导致IPv4问题，因为它通常会在主机上启动“恶意”DHCPv4服务器。
We have also had reports that hosts may not see genuine IPv6 RAs on a link due to host firewalls, causing them to turn on a connection-sharing service and 6to4 as a result. In some cases, more technical users may also use a laptop as a home gateway (e.g., again a 6to4 gateway) and then connect to another network, forgetting their previous gateway configuration is still active.
我们还收到报告称，由于主机防火墙的原因，主机可能无法在链路上看到真正的IPv6 RAs，从而导致它们打开连接共享服务，并因此导致6to4。在某些情况下，更多的技术用户也可能将笔记本电脑用作家庭网关（例如，再次是6to4网关），然后连接到另一个网络，忘记他们以前的网关配置仍然处于活动状态。
There are also reported incidents in enterprise networks of users physically plugging Ethernet cables into the wrong sockets and bridging two subnets together, causing a problem similar to VLAN flooding.
据报道，在企业网络中，用户将以太网电缆物理插入错误的插座，并将两个子网桥接在一起，从而导致类似于VLAN泛洪的问题。
Here an attacker is deliberately generating RAs on the local network in an attempt to perform some form of denial-of-service or man-in-the-middle attack.
这里，攻击者故意在本地网络上生成RAs，试图执行某种形式的拒绝服务或中间人攻击。
As stated above, while this is a genuine concern for network administrators, there have been few if any reports of such activity, while in contrast reports of accidental rogue RAs are very commonplace. In writing this text, and with the feedback of the v6ops working group, we came to the conclusion that the issue of malicious attack, due to the other complementary attacks that are likely to be launched using rogue NA and similar messages, are best considered by further work and document(s). As a result, this text intends to provide informational guidance for operators looking for practical measures to take to avoid "accidental" rogue RAs on their own networks.
如上所述，虽然这是网络管理员真正关心的问题，但很少有关于此类活动的报告，而相比之下，关于意外盗贼RAs的报告非常常见。在撰写本文的过程中，根据v6ops工作组的反馈，我们得出结论，由于可能使用rogue NA和类似消息发起的其他补充攻击，恶意攻击的问题最好通过进一步的工作和文档加以考虑。因此，本文旨在为运营商提供信息指导，以寻求实际措施，避免在其自己的网络上出现“意外”恶意RAs。
In this section, we present a summary of methods suggested to date for reducing or removing the possibility of rogue RAs being seen on a network.
在本节中，我们总结了迄今为止为减少或消除网络上出现恶意RAs的可能性而建议的方法。
The default gateway and host address can usually be manually configured on a node. This of course can be a resource intensive solution, and also prone to administrative mistakes in itself.
默认网关和主机地址通常可以在节点上手动配置。当然，这可能是一个资源密集型解决方案，而且本身也容易出现管理错误。
Manual configuration implies that RA processing is disabled. Most operating systems allow RA messages to be ignored, such that if an IPv6 address is manually configured on a system, an additional global autoconfigured address will not be added should an unexpected RA appear on the link.
手动配置意味着RA处理被禁用。大多数操作系统都允许忽略RA消息，因此，如果在系统上手动配置IPv6地址，则在链接上出现意外RA时，不会添加额外的全局自动配置地址。
It should be possible to implement "RA snooping" in Layer 2 switches in a similar way to DHCP snooping, such that RAs observed from incorrect sources are blocked or dropped, and not propagated through a subnet. One candidate solution in this space, called "RA-Guard" [RFC6105], has been proposed. This type of solution has appeal because it is a familiar model for enterprise network managers, but it can also be used to complement SEcure Neighbor Discovery (SEND) [RFC3971], by a switch acting as a SEND proxy for hosts.
应该可以在第2层交换机中以类似于DHCP窥探的方式实现“RA窥探”，从而阻止或删除从错误源观察到的RAs，而不是通过子网传播。在这一领域，已经提出了一种称为“RA Guard”[RFC6105]的候选解决方案。这种类型的解决方案很有吸引力，因为它是企业网络管理器熟悉的模型，但也可以通过充当主机发送代理的交换机来补充安全邻居发现（SEND）[RFC3971]。
This type of solution may not be applicable everywhere, e.g., in environments where there are not centrally controlled or manageable switches.
这种类型的解决方案可能不适用于任何地方，例如，在没有集中控制或可管理交换机的环境中。
Certain switch platforms can already implement some level of rogue RA filtering by the administrator configuring Access Control Lists (ACLs) that block RA ICMP messages that might be inbound on "user" ports. Again this type of "solution" depends on the presence of such configurable switches.
某些交换机平台已经可以通过管理员配置访问控制列表（ACL）实施某种级别的rogue RA过滤，以阻止可能在“用户”端口上入站的RA ICMP消息。同样，这种类型的“解决方案”取决于此类可配置交换机的存在。
A recent document describes the RA message format(s) for filtering [IPv6-AUTOCFG-FILTER]. The document also notes requirements for DHCPv6 snooping, which can then be implemented similarly to DHCPv4 snooping.
最近的一份文档介绍了用于筛选的RA消息格式[IPv6 AUTOCFG FILTER]。本文档还说明了DHCPv6窥探的要求，然后可以类似于DHCPv4窥探来实现。
The SEcure Neighbor Discovery (SEND) [RFC3971] protocol provides a method for hosts and routers to perform secure Neighbor Discovery. Thus, it can in principle protect a network against rogue RAs.
安全邻居发现（SEND）[RFC3971]协议为主机和路由器提供了执行安全邻居发现的方法。因此，它原则上可以保护网络免受恶意RAs的攻击。
SEND is not yet widely used at the time of writing, in part because there are very few implementations of the protocol. Some other deployment issues have been raised, though these are likely to be resolved in due course. For example, routers probably don't want to use autogenerated addresses (which might need to be protected by ACLs), so SEND needs to be shown to work with non-autogenerated addresses. Also, it has been argued that there are "bootstrapping" issues, in that hosts wanting to validate router credentials (e.g., to a certificate server or Network Time Protocol (NTP) server) are likely to need to communicate via the router for that information.
在撰写本文时，SEND尚未得到广泛使用，部分原因是该协议的实现很少。还提出了一些其他部署问题，尽管这些问题可能会在适当的时候得到解决。例如，路由器可能不想使用自动生成的地址（可能需要ACL保护），因此需要显示SEND以处理非自动生成的地址。此外，有人认为存在“引导”问题，因为想要验证路由器凭据（例如，到证书服务器或网络时间协议（NTP）服务器）的主机可能需要通过路由器进行通信以获取该信息。
Further, it's not wholly clear how widely adopted SEND could or would be in site networks with "lightweight" security (e.g., many campus networks), especially where hosts are managed by users and not administratively. Public or conference wireless networks may face similar challenges. There may also be networks, like perhaps sensor networks, where use of SEND is less practical. These networks still require rogue RA protection.
此外，目前还不完全清楚SEND在具有“轻量级”安全性的站点网络（例如，许多校园网络）中能够或将会被广泛采用，特别是在主机由用户管理而非管理的情况下。公共或会议无线网络可能面临类似的挑战。也可能有一些网络，比如传感器网络，在这些网络中使用SEND不太实际。这些网络仍然需要恶意RA保护。
While SEND clearly can provide a good, longer-term solution, especially in networks where malicious activity is a significant concern, there is a requirement today for practical solutions, and/or solutions more readily applicable in more "relaxed" environments. In the latter case, solutions like "RA snooping" or applied ACLs are more attractive now.
虽然SEND显然可以提供一个良好的长期解决方案，特别是在恶意活动严重的网络中，但现在需要实用的解决方案，和/或更容易适用于更“宽松”环境的解决方案。在后一种情况下，像“RA窥探”或应用ACL这样的解决方案现在更具吸引力。
[RFC4191] introduced a Router Preference option, such that an RA could carry one of three Router Preference values: High, Medium (default), or Low. Thus, an administrator could use "High" settings for managed RAs, and hope that "accidental" RAs would be medium priority. This of course would only work in some scenarios -- if the user who accidentally sends out a rogue RA on the network has configured their device with "High" precedence for their own intended usage, the priorities would clash. But for accidental rogue RAs caused by software like Windows ICS and 6to4, which would use the default precedence, it could be useful. Obviously this solution would also rely on clients (and routers) having implementations of the Router Preference option.
[RFC4191]引入了路由器首选项，这样RA可以携带三个路由器首选项值之一：高、中（默认）或低。因此，管理员可以对托管RAs使用“高”设置，并希望“意外”RAs具有中等优先级。当然，这只在某些情况下起作用——如果在网络上意外发送恶意RA的用户为自己的预期用途将其设备配置了“高”优先级，则优先级将发生冲突。但对于由Windows ICS和6to4等软件（将使用默认优先级）导致的意外恶意RAs，它可能是有用的。显然，此解决方案还依赖于具有路由器首选项实现的客户端（和路由器）。
In principle, if a technology such as IEEE 802.1x is used, devices would first need to authenticate to the network before being able to send or receive IPv6 traffic. Ideally, authentication would be mutual. Deployment of 802.1x, with mutual authentication, may however be seen as somewhat "heavyweight", akin to SEND, for some deployments.
原则上，如果使用IEEE 802.1x等技术，设备在能够发送或接收IPv6流量之前，首先需要通过网络身份验证。理想情况下，身份验证应该是相互的。然而，对于某些部署，802.1x的部署（带有相互认证）可能被视为某种“重量级”，类似于发送。
Improving Layer 2 security may help to mitigate against an attacker's capability to join the network to send RAs, but it doesn't prevent misconfiguration issues. A user can happily authenticate and still launch a Windows ICS service, for example.
提高第2层安全性可能有助于抵御攻击者加入网络发送RAs的能力，但这并不能防止错误配置问题。例如，用户可以愉快地进行身份验证并仍然启动Windows ICS服务。
In a managed environment, hosts could be configured via their "personal firewall" to only accept RAs from trusted sources. Hosts could also potentially be configured to discard 6to4-based RAs in a managed enterprise environment.
在托管环境中，可以通过其“个人防火墙”将主机配置为仅接受来自可信来源的RAs。还可以将主机配置为在托管企业环境中丢弃基于6to4的RAs。
However, the problem is then pushed to keeping this configuration maintained and correct. If a router fails and is replaced, possibly with a new Layer 2 interface address, the link local source address in the filter may become incorrect, and thus no method would be available to push the new information to the host over the network.
然而，问题随后被推到保持此配置的维护和正确。如果路由器发生故障并被替换（可能是新的第2层接口地址），则过滤器中的链路本地源地址可能会变得不正确，因此无法通过网络将新信息推送到主机。
It is possible to run a daemon on a link (perhaps on the router on the link) to watch for incorrect RAs and to send a deprecating RA with a router lifetime of zero when such an RA is observed. The KAME rafixd is an example of such a tool, which has been used at IETF
可以在链路上（可能在链路上的路由器上）运行守护程序，以监视不正确的RAs，并在观察到路由器生存期为零的RA时发送不推荐RA。KAME rafixd就是这种工具的一个例子，已在IETF中使用
meetings with some success. A slightly enhanced tool called RAMOND has since been developed from this code, and is now available as a Sourceforge project. As with host-based firewalling, the daemon would need to somehow know what "good" and "bad" RAs are, from some combination of known good sources and/or link prefixes. In an environment with native IPv6, though, 6to4-based RAs would certainly be known to be rogue.
会议取得了一些成功。从此代码中开发了一个名为RAMOND的稍微增强的工具，现在作为Sourceforge项目提供。与基于主机的防火墙一样，守护进程需要通过已知良好源和/或链接前缀的组合，以某种方式知道什么是“好”和“坏”RAs。不过，在使用本机IPv6的环境中，基于6to4的RAs肯定是流氓。
Whether or not use of such a tool is the preferred method, monitoring a link for observed RAs seems prudent from a network management perspective. Some such tools exist already, e.g., NDPMon, which can also detect other undesirable behaviour.
无论使用这样的工具是否是首选方法，从网络管理的角度来看，监控链路中观察到的RAs似乎是谨慎的。一些这样的工具已经存在，例如NDPMon，它还可以检测其他不良行为。
If each system or user on a network is partitioned into a different Layer 2 medium, then the impact of rogue RAs can be limited. In broadband networks, bridging [RFC2684] may be available, for example. The benefit may be scenario-specific, e.g., whether a given user or customer has their own network prefix or whether the provisioning is in a shared subnet or link. It is certainly desirable that any given user or customer's system(s) are unable to see RAs that may be generated by other users or customers.
如果网络上的每个系统或用户被划分到不同的第2层介质中，那么流氓RAs的影响是有限的。例如，在宽带网络中，桥接[RFC2684]可能可用。好处可能是特定于场景的，例如，给定用户或客户是否有自己的网络前缀，或者供应是否在共享子网或链路中。任何给定用户或客户的系统都不能看到其他用户或客户可能生成的RAs，这当然是可取的。
However, such partitioning would probably increase address space consumption significantly if applied in enterprise networks, and in many cases, hardware costs and software licensing costs to enable routing to the edge can be quite significant.
然而，如果在企业网络中应用，这种分区可能会显著增加地址空间消耗，并且在许多情况下，实现路由到边缘的硬件成本和软件许可成本可能相当大。
Adding Default Gateway and Prefix options for DHCPv6 would allow network administrators to configure hosts to only use DHCPv6 for default gateway and prefix configuration in managed networks, where RAs would be required today. A new document has proposed such a default router option, along with prefix advertisement options for DHCPv6 [DHCPv6-DEFAULT-RTR]. Even with such options added to DHCPv6, an RA is in principle still required to inform hosts to use DHCPv6.
为DHCPv6添加默认网关和前缀选项将允许网络管理员将主机配置为仅在托管网络中使用DHCPv6进行默认网关和前缀配置，而现在需要RAs。一份新的文档提出了这样一个默认路由器选项，以及DHCPv6[DHCPv6 default RTR]的前缀广告选项。即使将这些选项添加到DHCPv6中，原则上仍然需要RA通知主机使用DHCPv6。
An advantage of DHCPv6 is that should an error be introduced, only hosts that have refreshed their DHCP information since that time are affected, while a multicast rogue RA will most likely affect all hosts immediately. DHCPv6 also allows different answers to be given to different hosts.
DHCPv6的一个优点是，如果引入错误，只有自那时起刷新了DHCP信息的主机才会受到影响，而多播流氓RA很可能会立即影响所有主机。DHCPv6还允许为不同的主机提供不同的答案。
While making host configuration possible via DHCPv6 alone is a viable option that would allow IPv6 configuration to be done in a way similar to IPv4 today, the problem has only been shifted: rather than
尽管仅通过DHCPv6实现主机配置是一个可行的选项，它将允许以类似于今天的IPv4的方式进行IPv6配置，但问题只是转移了：而不是
rogue RAs being the problem, rogue DHCPv6 servers would be an equivalent issue. As with IPv4, a network would then still require use of Authenticated DHCP, or DHCP(v6) snooping, as suggested in [IPv6-AUTOCFG-FILTER].
rogue-RAs是一个问题，rogue-DHCPv6服务器将是一个同等的问题。与IPv4一样，网络仍然需要使用经过身份验证的DHCP或DHCP（v6）监听，如[IPv6 AUTOCFG FILTER]中所建议的。
There is certainly some demand in the community for DHCPv6-only host configuration. While this may mitigate the rogue RA issue, it simply moves the trust problem elsewhere, albeit to a place administrators are familiar with today.
社区中对仅DHCPv6主机配置肯定有一些需求。虽然这可能会缓解rogue RA问题，但它只是将信任问题转移到其他地方，尽管是管理员现在熟悉的地方。
In this section, we summarise the error/misconfiguration scenarios and practical mitigation methods described above in a matrix format. We consider, for the case of a rogue multicast RA, which of the mitigation methods helps protect against administrator and user errors. For the administrator error, we discount an error in configuring the countermeasure itself; rather, we consider an administrator error to be an error in configuration elsewhere in the network.
在本节中，我们以矩阵形式总结了上述错误/错误配置场景和实际缓解方法。我们认为，对于流氓多播RA的情况下，减轻方法有助于防止管理员和用户错误。对于管理员错误，我们不考虑配置对策本身的错误；相反，我们认为管理员错误是网络中其他地方的配置错误。
+------------------------+---------------------------+
| | Scenario |
| Mitigation |---------------------------|
| Method | Admin Error | User Error |
+------------------------+-------------+-------------+
| Manual configuration | Y | Y |
+------------------------+-------------+-------------+
| SEND | Y | Y |
+------------------------+-------------+-------------+
| RA snooping | Y | Y |
+------------------------+-------------+-------------+
| Use switch ACLs | Y | Y |
+------------------------+-------------+-------------+
| Router preference | N | Y |
+------------------------+-------------+-------------+
| Layer 2 admission | N | N |
+------------------------+-------------+-------------+
| Host firewall | Y | Y |
+------------------------+-------------+-------------+
| Deprecation daemon | Y | Y |
+------------------------+-------------+-------------+
| Layer 2 partition | N | Y |
+------------------------+-------------+-------------+
| DHCPv6 gateway option | Partly | If Auth |
+------------------------+-------------+-------------+
+------------------------+---------------------------+
| | Scenario |
| Mitigation |---------------------------|
| Method | Admin Error | User Error |
+------------------------+-------------+-------------+
| Manual configuration | Y | Y |
+------------------------+-------------+-------------+
| SEND | Y | Y |
+------------------------+-------------+-------------+
| RA snooping | Y | Y |
+------------------------+-------------+-------------+
| Use switch ACLs | Y | Y |
+------------------------+-------------+-------------+
| Router preference | N | Y |
+------------------------+-------------+-------------+
| Layer 2 admission | N | N |
+------------------------+-------------+-------------+
| Host firewall | Y | Y |
+------------------------+-------------+-------------+
| Deprecation daemon | Y | Y |
+------------------------+-------------+-------------+
| Layer 2 partition | N | Y |
+------------------------+-------------+-------------+
| DHCPv6 gateway option | Partly | If Auth |
+------------------------+-------------+-------------+
What the above summary does not consider is the practicality of deploying the measure. An easy-to-deploy method that buys improved resilience to rogue RAs without significant administrative overhead is attractive. On that basis, the RA snooping proposal, e.g., RA-Guard, has merit, while approaches like manual configuration are less appealing. However, RA-Guard is not yet fully defined or available, while only certain managed switch equipment may support the required ACLs.
上述总结没有考虑的是部署措施的实用性。一种易于部署的方法很有吸引力，它可以在不增加大量管理开销的情况下提高对恶意RAs的恢复能力。在此基础上，RA窥探建议（如RA Guard）具有优点，而手动配置等方法吸引力较小。但是，RA Guard尚未完全定义或可用，而只有某些受管交换机设备可以支持所需的ACL。
There are a number of related issues that have come out of discussions on the rogue RA topic, which the authors believe are worth capturing in this document.
在关于rogue RA主题的讨论中出现了许多相关问题，作者认为这些问题值得在本文中加以阐述。
The above discussion was initially held on the assumption that rogue multicast RAs were the cause of problems on a shared network subnet. However, the specifications for Router Advertisements allow them to be sent unicast to a host, as per Section 6.2.6 of RFC 4861. If a host sending rogue RAs sends them unicast to the soliciting host, that RA may not be seen by other hosts on the shared medium, e.g., by a monitoring daemon. In most cases, though, an accidental rogue RA is likely to be multicast.
上述讨论最初是基于以下假设进行的：恶意多播RAs是共享网络子网上出现问题的原因。然而，根据RFC 4861第6.2.6节，路由器广告规范允许将其单播发送到主机。如果发送恶意RAs的主机将其单播发送到请求主机，则共享介质上的其他主机（例如，监控守护程序）可能看不到该RA。不过，在大多数情况下，意外的流氓RA很可能是多播的。
Comparing the threat model for rogue RAs and rogue DHCPv6 servers is an interesting exercise. In the case of Windows ICS causing rogue 6to4-based RAs to appear on a network, it is very likely that the same host is also acting as a rogue IPv4 DHCP server. The rogue DHCPv4 server can allocate a default gateway and an address to hosts, just as a rogue RA can lead hosts to learning of a new (additional) default gateway, prefix(es), and address. In the case of multicast rogue RAs, however, the impact is potentially immediate to all hosts, while the rogue DHCP server's impact will depend on lease timers for hosts.
比较rogue RAs和rogue DHCPv6服务器的威胁模型是一个有趣的练习。在Windows ICS导致基于6to4的恶意RAs出现在网络上的情况下，很可能同一主机也充当恶意IPv4 DHCP服务器。rogue DHCPv4服务器可以为主机分配默认网关和地址，就像rogue RA可以引导主机学习新的（额外的）默认网关、前缀和地址一样。但是，在多播恶意RAs的情况下，其影响可能会立即影响到所有主机，而恶意DHCP服务器的影响将取决于主机的租用计时器。
In principle, Authenticated DHCP can be used to protect against rogue DHCPv4 (and DHCPv6) servers, just as SEND could be used to protect against rogue IPv6 RAs. However, actual use of Authenticated DHCP in typical networks is currently minimal. Were new DHCPv6 default gateway and prefix options to be standardised as described above, then without Authenticated DHCP the (lack of) security is just pushed to another place.
原则上，经过身份验证的DHCP可用于防范恶意DHCPv4（和DHCPv6）服务器，就像SEND可用于防范恶意IPv6 RAs一样。然而，目前在典型网络中实际使用经过身份验证的DHCP的情况很少。如果新的DHCPv6默认网关和前缀选项如上所述被标准化，那么如果没有经过身份验证的DHCP，安全性（缺乏）就会被推到另一个地方。
The RA-Guard approach is essentially using a similar model to DHCP message snooping to protect against rogue RAs in network (switch) equipment. As noted above, DHCPv6 message snooping would also be very desirable in IPv6 networks.
RA Guard方法本质上是使用类似于DHCP消息窥探的模型来防止网络（交换机）设备中的恶意RAs。如上所述，DHCPv6消息窥探在IPv6网络中也是非常理想的。
The rogue RA problem should also be considered by administrators and operators of IPv4-only networks, where IPv6 monitoring, firewalling, and other related mechanisms may not be in place.
只有IPv4网络的管理员和运营商也应该考虑rogue RA问题，因为IPv6监控、防火墙和其他相关机制可能不存在。
For example, a comment has been made that in the case of 6to4 being run by a host on a subnet that is not administratively configured with IPv6, some OSes or applications may begin using IPv6 to the 6to4 host (router) rather than IPv4 to the intended default IPv4 router, because they have IPv6 enabled by default and some applications prefer IPv6 by default. Technically aware users may also deliberately choose to use IPv6, possibly for subversive reasons. Mitigating against this condition can also be seen to be important.
例如，有人评论说，如果6to4由未使用IPv6进行管理配置的子网上的主机运行，某些操作系统或应用程序可能会开始使用IPv6连接到6to4主机（路由器），而不是IPv4连接到预期的默认IPv4路由器，因为默认情况下它们启用了IPv6，而某些应用程序默认情况下更喜欢IPv6。有技术意识的用户也可能故意选择使用IPv6，可能是出于颠覆性的原因。缓解这种情况也很重要。
It would generally be prudent for network monitoring or management platforms to be able to observe and report on observed RAs, and whether unintended RAs (possibly from unintended sources) are present on a network. Further, it may be useful for individual hosts to be able to report their address status (assuming their configuration status allowed it, of course), e.g., this could be useful during an IPv6 renumbering phased process as described in RFC 4192 [RFC4192].
通常，网络监控或管理平台应能够观察和报告观察到的RAs，以及网络上是否存在非预期RAs（可能来自非预期来源）。此外，单个主机能够报告其地址状态（当然，假设其配置状态允许），这可能是有用的，例如，在RFC 4192[RFC4192]中描述的IPv6重新编号阶段过程中，这可能是有用的。
The above assumes, of course, that what defines a "good" (or "bad") RA can be configured in a trustworthy manner within the network's management framework.
当然，以上假设定义“好”（或“坏”）RA的内容可以在网络管理框架内以可靠的方式进行配置。
After a host receives and processes a rogue RA, it may have multiple default gateways, global addresses, and potentially clashing RA options (e.g., M/O bits [RFC4861]). The host's behaviour may then be unpredictable, in terms of the default router that is used, and the (source) address(es) used in communications. A host that is aware of protocols such as Shim6 [RFC5533] may believe it is genuinely multihomed.
主机接收并处理恶意RA后，可能会有多个默认网关、全局地址和可能冲突的RA选项（例如，M/O位[RFC4861]）。然后，主机的行为可能是不可预测的，即使用的默认路由器和通信中使用的（源）地址。知道Shim6[RFC5533]等协议的主机可能会认为它是真正的多址主机。
An important issue is how readily a host can recover from receiving and processing bad configuration information, e.g., considering the "2 hour rule" mentioned in Section 5.5.3 of RFC 4862 (though this applies to the valid address lifetime and not the router lifetime). We should ensure that methods exist for a network administrator to correct bad configuration information on a link or subnet, and that OS platforms support these methods. At least if the problem can be detected, and corrected promptly, the impact is minimised.
一个重要的问题是主机从接收和处理错误的配置信息中恢复的容易程度，例如，考虑到RFC 4862第5.5.3节中提到的“2小时规则”（尽管这适用于有效地址生存期而不是路由器生存期）。我们应该确保存在网络管理员纠正链路或子网上错误配置信息的方法，并且操作系统平台支持这些方法。至少，如果能够发现问题并及时纠正，那么影响将降至最低。
In addition to issuing a deprecating RA, it would be desirable to isolate the offending source of the rogue RA from the network. It may be possible to use Network Access Control methods to quarantine the offending host, or rather the network point of attachment or port that it is using.
除了发布不推荐RA之外，最好将恶意RA的攻击源与网络隔离。可以使用网络访问控制方法隔离有问题的主机，或者更确切地说隔离它正在使用的网络连接点或端口。
In this text we have described scenarios via which rogue Router Advertisements (RAs) may appear on a network, and some measures that could be used to mitigate against these. We have also noted some related issues that have arisen in the rogue RA discussions. Our discussion is generally focused on the assumption that rogue RAs are appearing as a result of accidental misconfiguration on the network, by a user or administrator.
在本文中，我们描述了恶意路由器广告（RAs）可能出现在网络上的场景，以及可以用来缓解这些问题的一些措施。我们还注意到在rogue RA讨论中出现的一些相关问题。我们的讨论通常集中在一个假设上，即恶意RAs是由于用户或管理员在网络上的意外错误配置而出现的。
While SEND perhaps offers the most robust solution, implementations and deployment guidelines are not yet widely available. SEND is very likely to be a good, longer-term solution, but many administrators are seeking solutions today. Such administrators are also often in networks with security models for which SEND is a "heavyweight" solution, e.g., campus networks, or wireless conference or public networks. For such scenarios, simpler measures are desirable.
虽然SEND可能提供了最健壮的解决方案，但实现和部署指南尚未广泛提供。SEND很可能是一个很好的长期解决方案，但现在许多管理员都在寻找解决方案。此类管理员通常也在具有安全模型的网络中，SEND是一个“重量级”解决方案，例如校园网、无线会议或公共网络。对于这种情况，更简单的措施是可取的。
Adding new DHCPv6 Default Gateway and Prefix options would allow IPv6 host configuration by DHCP only and would be a method that IPv4 administrators are comfortable with (for better or worse), but this simply shifts the robustness issue elsewhere.
添加新的DHCPv6默认网关和前缀选项将只允许通过DHCP配置IPv6主机，并且将是IPv4管理员可以接受的方法（无论是好是坏），但这只会将健壮性问题转移到其他地方。
While a number of the mitigations described above have their appeal, the simplest solutions probably lie in switch-based ACLs and RA-Guard-style approaches. Where managed switches are not available, use of the Router Preference option and (more so in managed desktop environments) host firewalls may be appropriate.
虽然上述许多缓解措施都有其吸引力，但最简单的解决方案可能在于基于交换机的ACL和RA Guard风格的方法。如果托管交换机不可用，则可以使用路由器首选项选项和主机防火墙（在托管桌面环境中更是如此）。
In the longer term, wider experience of SEND will be beneficial, while the use of RA snooping will remain useful either to complement SEND (where a switch running RA-Guard can potentially be a SEND proxy) or to assist in scenarios for which SEND is not deployed.
从长远来看，更广泛的SEND体验将是有益的，而RA窥探的使用对于补充SEND（运行RA Guard的交换机可能是SEND代理）或在未部署SEND的情况下提供帮助仍然是有用的。
This Informational document is focused on discussing solutions to operational problems caused by rogue RAs resulting from unintended misconfiguration by users or administrators. Earlier versions of this text included some analysis of rogue RAs introduced maliciously; e.g., the text included an extra column in the matrix in Section 4. However, the consensus of the v6ops working group feedback was to instead focus on the common operational problem of "accidental" rogue RAs seen today.
本信息性文档的重点是讨论由用户或管理员意外错误配置导致的恶意RAs引起的操作问题的解决方案。本文的早期版本包括对恶意引入的流氓RAs的一些分析；e、 例如，文本在第4节的矩阵中增加了一列。然而，v6ops工作组反馈意见的一致意见是将重点放在今天看到的“意外”流氓RAs的常见操作问题上。
Thus, the final version of this text does not address attacks on a network where rogue RAs are intentionally introduced as part of a broader attack, e.g., including malicious NA messages. On the wire, malicious rogue RAs will generally look the same as "accidental" ones, though they are more likely, for example, to spoof the Media Access Control (MAC) or IPv6 source address of the genuine router, or to use a "High" Router Preference option. It is also likely that malicious rogue RAs will be accompanied by other attacks on the IPv6 infrastructure, making discussion of mitigations more complex. Administrators may be able to detect such activity by the use of tools such as NDPMon.
因此，本文的最终版本不涉及网络上的攻击，其中恶意RAs是作为更广泛攻击的一部分故意引入的，例如，包括恶意NA消息。在网络上，恶意恶意恶意RAs通常看起来与“意外”RAs相同，但它们更有可能欺骗真正路由器的媒体访问控制（MAC）或IPv6源地址，或使用“高”路由器首选项选项。恶意恶意恶意RAs还可能伴随着对IPv6基础设施的其他攻击，这使得缓解措施的讨论更加复杂。管理员可以通过使用NDPMon等工具来检测此类活动。
It is worth noting that the deprecation daemon could be used as part of a denial-of-service attack, should the tool be used to deprecate the genuine RA.
值得注意的是，如果该工具用于弃用正版RA，则弃用守护程序可以用作拒绝服务攻击的一部分。
Thanks are due to members of the IETF IPv6 Operations and DHCP working groups for their inputs on this topic, as well as some comments from various operational mailing lists, and private comments, including but not limited to: Iljitsch van Beijnum, Dale Carder, Remi Denis-Courmont, Tony Hain, Bob Hinden, Christian Huitema, Tatuya Jinmei, Eric Levy-Abegnoli, David Malone, Thomas Narten, Chip Popoviciu, Dave Thaler, Gunter Van de Velde, Goeran Weinholt, and Dan White.
感谢IETF IPv6运营和DHCP工作组成员在此主题上的投入，以及来自各种运营邮件列表的一些评论和私人评论，包括但不限于：Iljitsch van Beijnum、Dale Carder、Remi Denis Courmon、Tony Hain、Bob Hinden、Christian Huitema、Tatuya Jinmei、，埃里克·利维·阿贝格诺利、大卫·马龙、托马斯·纳滕、奇普·波波维西奥、戴夫·泰勒、冈特·范德维尔德、戈兰·温霍尔特和丹·怀特。
[RFC2684] Grossman, D. and J. Heinanen, "Multiprotocol Encapsulation over ATM Adaptation Layer 5", RFC 2684, September 1999.
[RFC2684]Grossman，D.和J.Heinanen，“ATM适配层5上的多协议封装”，RFC 2684，1999年9月。
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
[RFC3056]Carpenter，B.和K.Moore，“通过IPv4云连接IPv6域”，RFC 3056，2001年2月。
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315]Droms，R.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC3315，2003年7月。
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6", RFC 3736, April 2004.
[RFC3736]Droms，R.，“IPv6的无状态动态主机配置协议（DHCP）服务”，RFC 3736，2004年4月。
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3971]Arkko，J.，Kempf，J.，Zill，B.，和P.Nikander，“安全邻居发现（SEND）”，RFC 39712005年3月。
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and More-Specific Routes", RFC 4191, November 2005.
[RFC4191]Draves，R.和D.Thaler，“默认路由器首选项和更具体的路由”，RFC 41912005年11月。
[RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for Renumbering an IPv6 Network without a Flag Day", RFC 4192, September 2005.
[RFC4192]Baker，F.，Lear，E.，和R.Droms，“在没有国旗日的情况下对IPv6网络重新编号的程序”，RFC 41922005年9月。
[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月。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.
[RFC4862]Thomson，S.，Narten，T.，和T.Jinmei，“IPv6无状态地址自动配置”，RFC 48622007年9月。
[RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming Shim Protocol for IPv6", RFC 5533, June 2009.
[RFC5533]Nordmark，E.和M.Bagnulo，“Shim6:IPv6的3级多主垫片协议”，RFC 55332009年6月。
[RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, February 2011.
[RFC6105]Levy Abegnoli，E.，Van de Velde，G.，Popoviciu，C.，和J.Mohacsi，“IPv6路由器广告保护”，RFC 61052011年2月。
[IPv6-AUTOCFG-FILTER] Ward, N., "IPv6 Autoconfig Filtering on Ethernet Switches", Work in Progress, March 2009.
[IPv6自动配置过滤器]沃德，N.，“以太网交换机上的IPv6自动配置过滤”，正在进行的工作，2009年3月。
[DHCPv6-DEFAULT-RTR] Droms, R. and T. Narten, "Default Router and Prefix Advertisement Options for DHCPv6", Work in Progress, March 2009.
[DHCPv6默认RTR]Droms，R.和T.Narten，“DHCPv6的默认路由器和前缀广告选项”，正在进行的工作，2009年3月。
Authors' Addresses
作者地址
Tim Chown University of Southampton Highfield Southampton, Hampshire SO17 1BJ United Kingdom
提姆南安普敦大学英国南安普顿
EMail: tjc@ecs.soton.ac.uk
EMail: tjc@ecs.soton.ac.uk
Stig Venaas Cisco Systems Tasman Drive San Jose, CA 95134 USA
美国加利福尼亚州圣何塞市塔斯曼大道Stig Venaas思科系统公司，邮编95134
EMail: stig@cisco.com
EMail: stig@cisco.com