Internet Engineering Task Force (IETF) J. Linkova
Request for Comments: 8475 Google
Category: Informational M. Stucchi
ISSN: 2070-1721 RIPE NCC
October 2018
Internet Engineering Task Force (IETF) J. Linkova
Request for Comments: 8475 Google
Category: Informational M. Stucchi
ISSN: 2070-1721 RIPE NCC
October 2018
Using Conditional Router Advertisements for Enterprise Multihoming
使用条件路由器广告实现企业多主
Abstract
摘要
This document discusses the most common scenarios of connecting an enterprise network to multiple ISPs using an address space assigned by an ISP and how the approach proposed in "Enterprise Multihoming using Provider-Assigned Addresses without Network Prefix Translation: Requirements and Solution" could be applied in those scenarios. The problem of enterprise multihoming without address translation of any form has not been solved yet as it requires both the network to select the correct egress ISP based on the packet source address and hosts to select the correct source address based on the desired egress ISP for that traffic. The aforementioned document proposes a solution to this problem by introducing a new routing functionality (Source Address Dependent Routing) to solve the uplink selection issue. It also proposes using Router Advertisements to influence the host source address selection. It focuses on solving the general problem and covering various complex use cases, and this document adopts its proposed approach to provide a solution for a limited number of common use cases. In particular, the focus of this document is on scenarios in which an enterprise network has two Internet uplinks used either in primary/backup mode or simultaneously and hosts in that network might not yet properly support multihoming as described in RFC 8028.
本文档讨论了使用ISP分配的地址空间将企业网络连接到多个ISP的最常见场景，以及如何在这些场景中应用“使用供应商分配的地址而不转换网络前缀的企业多主：要求和解决方案”中提出的方法。没有任何形式的地址转换的企业多宿问题尚未解决，因为它要求网络根据数据包源地址选择正确的出口ISP，主机根据该流量所需的出口ISP选择正确的源地址。上述文档通过引入新的路由功能（源地址相关路由）来解决上行链路选择问题，从而提出了该问题的解决方案。它还建议使用路由器广告来影响主机源地址的选择。它侧重于解决一般问题并涵盖各种复杂用例，本文档采用其提出的方法为有限数量的常见用例提供解决方案。特别是，本文档的重点是企业网络具有两个在主/备份模式下使用或同时使用的Internet上行链路，并且该网络中的主机可能尚未正确支持RFC 8028中所述的多址。
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 candidates for any level of Internet Standard; see Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8475.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8475.
Copyright Notice
版权公告
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2018 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Common Enterprise Multihoming Scenarios . . . . . . . . . . . 4
2.1. Two ISP Uplinks, Primary and Backup . . . . . . . . . . . 4
2.2. Two ISP Uplinks, Used for Load-Balancing . . . . . . . . 5
3. Conditional Router Advertisements . . . . . . . . . . . . . . 5
3.1. Solution Overview . . . . . . . . . . . . . . . . . . . . 5
3.1.1. Uplink Selection . . . . . . . . . . . . . . . . . . 5
3.1.2. Source Address Selection and Conditional RAs . . . . 5
3.2. Example Scenarios . . . . . . . . . . . . . . . . . . . . 8
3.2.1. Single Router, Primary/Backup Uplinks . . . . . . . . 8
3.2.2. Two Routers, Primary/Backup Uplinks . . . . . . . . . 9
3.2.3. Single Router, Load-Balancing between Uplinks . . . . 12
3.2.4. Two Routers, Load-Balancing between Uplinks . . . . . 12
3.2.5. Topologies with Dedicated Border Routers . . . . . . 13
3.2.6. Intrasite Communication during Simultaneous Uplinks
Outage . . . . . . . . . . . . . . . . . . . . . . . 15
3.2.7. Uplink Damping . . . . . . . . . . . . . . . . . . . 15
3.2.8. Routing Packets When the Corresponding Uplink Is
Unavailable . . . . . . . . . . . . . . . . . . . . . 16
3.3. Solution Limitations . . . . . . . . . . . . . . . . . . 16
3.3.1. Connections Preservation . . . . . . . . . . . . . . 17
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
5. Security Considerations . . . . . . . . . . . . . . . . . . . 18
5.1. Privacy Considerations . . . . . . . . . . . . . . . . . 18
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
6.1. Normative References . . . . . . . . . . . . . . . . . . 18
6.2. Informative References . . . . . . . . . . . . . . . . . 20
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Common Enterprise Multihoming Scenarios . . . . . . . . . . . 4
2.1. Two ISP Uplinks, Primary and Backup . . . . . . . . . . . 4
2.2. Two ISP Uplinks, Used for Load-Balancing . . . . . . . . 5
3. Conditional Router Advertisements . . . . . . . . . . . . . . 5
3.1. Solution Overview . . . . . . . . . . . . . . . . . . . . 5
3.1.1. Uplink Selection . . . . . . . . . . . . . . . . . . 5
3.1.2. Source Address Selection and Conditional RAs . . . . 5
3.2. Example Scenarios . . . . . . . . . . . . . . . . . . . . 8
3.2.1. Single Router, Primary/Backup Uplinks . . . . . . . . 8
3.2.2. Two Routers, Primary/Backup Uplinks . . . . . . . . . 9
3.2.3. Single Router, Load-Balancing between Uplinks . . . . 12
3.2.4. Two Routers, Load-Balancing between Uplinks . . . . . 12
3.2.5. Topologies with Dedicated Border Routers . . . . . . 13
3.2.6. Intrasite Communication during Simultaneous Uplinks
Outage . . . . . . . . . . . . . . . . . . . . . . . 15
3.2.7. Uplink Damping . . . . . . . . . . . . . . . . . . . 15
3.2.8. Routing Packets When the Corresponding Uplink Is
Unavailable . . . . . . . . . . . . . . . . . . . . . 16
3.3. Solution Limitations . . . . . . . . . . . . . . . . . . 16
3.3.1. Connections Preservation . . . . . . . . . . . . . . 17
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
5. Security Considerations . . . . . . . . . . . . . . . . . . . 18
5.1. Privacy Considerations . . . . . . . . . . . . . . . . . 18
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
6.1. Normative References . . . . . . . . . . . . . . . . . . 18
6.2. Informative References . . . . . . . . . . . . . . . . . 20
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
Multihoming is an obvious requirement for many enterprise networks to ensure the desired level of network reliability. However, using more than one ISP (and address space assigned by those ISPs) introduces the problem of assigning IP addresses to hosts. In IPv4, there is no choice but using address space [RFC1918] and NAT [RFC3022] at the network edge [RFC4116]. Using Provider Independent (PI) address space is not always an option, since it requires running BGP between the enterprise network and the ISPs. The administrative overhead of obtaining and managing PI address space can also be a concern. As IPv6 hosts can, by design, have multiple addresses of the global scope [RFC4291], multihoming using provider addresses looks even easier for IPv6: each ISP assigns an IPv6 block (usually /48), and hosts in the enterprise network have addresses assigned from each ISP block. However, using IPv6 provider-assigned (PA) blocks in a multihoming scenario introduces some challenges, including, but not limited to:
多宿是许多企业网络的一个明显要求，以确保所需的网络可靠性水平。但是，使用多个ISP（以及由这些ISP分配的地址空间）会导致将IP地址分配给主机的问题。在IPv4中，除了在网络边缘[RFC4116]使用地址空间[RFC1918]和NAT[RFC3022]之外别无选择。使用独立于提供商（PI）的地址空间并不总是一个选项，因为它需要在企业网络和ISP之间运行BGP。获取和管理PI地址空间的管理开销也是一个问题。由于IPv6主机在设计上可以具有全局范围的多个地址[RFC4291]，因此使用提供商地址的多宿主对于IPv6来说看起来更容易：每个ISP分配一个IPv6块（通常为/48），企业网络中的主机从每个ISP块分配地址。但是，在多主场景中使用IPv6提供程序分配（PA）块会带来一些挑战，包括但不限于：
o Selecting the correct uplink based on the packet source address;
o 基于分组源地址选择正确的上行链路；
o Signaling to hosts that some source addresses should or should not be used (e.g., an uplink to the ISP went down or became available again).
o 向主机发出一些源地址应该使用或不应该使用的信号（例如，ISP的上行链路中断或重新可用）。
[PROVIDER-ASSIGNED] discusses these and other related challenges in detail in relation to the general multihoming scenario for enterprise networks. It proposes a solution that relies heavily on Rule 5.5 of the default address selection algorithm [RFC6724]. Rule 5.5 makes hosts prefer source addresses in a prefix advertised by the next hop and, therefore, is very useful in multihomed scenarios when different routers may advertise different prefixes. While [RFC6724] defines Rule 5.5 as optional, the recent [RFC8028] recommends that multihomed hosts SHOULD support it. Unfortunately, that rule has not been widely implemented at the time of writing. Therefore, network administrators in enterprise networks can't yet assume that all devices in their network support Rule 5.5, especially in the quite common BYOD ("Bring Your Own Device") scenario. However, while it does not seem feasible to solve all the possible multihoming scenarios without relying on Rule 5.5, it is possible to provide IPv6 multihoming using PA address space for the most common use cases. This document discusses how the general approach described in [PROVIDER-ASSIGNED] can be applied to solve multihoming scenarios when:
[PROVIDER-ASSIGNED]详细讨论了与企业网络通用多主场景相关的这些挑战和其他相关挑战。它提出了一种严重依赖默认地址选择算法[RFC6724]规则5.5的解决方案。规则5.5使主机更喜欢下一跳播发的前缀中的源地址，因此，当不同的路由器可能播发不同的前缀时，在多址场景中非常有用。虽然[RFC6724]将规则5.5定义为可选，但最近的[RFC8028]建议多宿主主机应支持该规则。不幸的是，在编写本报告时，这一规则尚未得到广泛实施。因此，企业网络中的网络管理员还不能假设其网络中的所有设备都支持规则5.5，特别是在非常常见的BYOD（“自带设备”）场景中。然而，尽管在不依赖规则5.5的情况下解决所有可能的多宿主场景似乎不可行，但对于最常见的用例，可以使用PA地址空间提供IPv6多宿主。本文件讨论了在以下情况下，如何应用[PROVIDER-ASSIGNED]中描述的一般方法来解决多主场景：
o An enterprise network has two or more ISP uplinks;
o 一个企业网络有两个或多个ISP上行链路；
o Those uplinks are used for Internet access in active/backup or load-sharing mode without any sophisticated traffic engineering requirements;
o 这些上行链路用于主动/备份或负载共享模式下的互联网接入，无需任何复杂的流量工程要求；
o Each ISP assigns the network a subnet from its own PA address space; and
o 每个ISP从自己的PA地址空间为网络分配一个子网；和
o Hosts in the enterprise network are not expected to support Rule 5.5 of the default address selection algorithm [RFC6724].
o 企业网络中的主机不应支持默认地址选择算法[RFC6724]的规则5.5。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
This scenario has the following key characteristics:
此场景具有以下关键特征：
o The enterprise network uses uplinks to two (or more) ISPs for Internet access;
o 企业网络使用两个（或更多）ISP的上行链路进行互联网接入；
o Each ISP assigns IPv6 PA address space for the network;
o 每个ISP为网络分配IPv6 PA地址空间；
o Uplink(s) to one ISP is a primary (preferred) one. All other uplinks are backup and are not expected to be used while the primary one is operational;
o 到一个ISP的上行链路是主（首选）链路。所有其他上行链路均为备用链路，且在主上行链路运行时，预计不会使用；
o If the primary uplink is operational, all Internet traffic should flow via that uplink;
o 如果主上行链路是可操作的，则所有互联网流量应通过该上行链路；
o When the primary uplink fails, the Internet traffic needs to flow via the backup uplinks;
o 当主上行链路故障时，互联网流量需要通过备用上行链路进行传输；
o Recovery of the primary uplink needs to trigger the traffic switchover from the backup uplinks back to the primary one;
o 主上行链路的恢复需要触发从备用上行链路到主上行链路的业务切换；
o Hosts in the enterprise network are not expected to support Rule 5.5 of the default address selection algorithm [RFC6724].
o 企业网络中的主机不应支持默认地址选择算法[RFC6724]的规则5.5。
This scenario has the following key characteristics:
此场景具有以下关键特征：
o The enterprise network is using uplinks to two (or more) ISPs for Internet access;
o 企业网络使用两个（或更多）ISP的上行链路进行互联网接入；
o Each ISP assigns an IPv6 PA address space;
o 每个ISP分配一个IPv6 PA地址空间；
o All the uplinks may be used simultaneously, with the traffic flows being randomly (not necessarily equally) distributed between them;
o 所有上行链路可同时使用，交通流在它们之间随机（不一定相等）分布；
o Hosts in the enterprise network are not expected to support Rule 5.5 of the default address selection algorithm [RFC6724].
o 企业网络中的主机不应支持默认地址选择算法[RFC6724]的规则5.5。
As discussed in [PROVIDER-ASSIGNED], one of the two main problems to be solved in the enterprise multihoming scenario is the problem of the next-hop (uplink) selection based on the packet source address. For example, if the enterprise network has two uplinks, to ISP_A and ISP_B, and hosts have addresses from subnet_A and subnet_B (belonging to ISP_A and ISP_B, respectively), then packets sourced from subnet_A must be sent to the ISP_A uplink while packets sourced from subnet_B must be sent to the ISP_B uplink. Sending packets with source addresses belonging to one ISP address space to another ISP might cause those packets to be filtered out if those ISPs or their uplinks implement antispoofing ingress filtering [RFC2827][RFC3704].
如[PROVIDER-ASSIGNED]中所述，在企业多宿场景中要解决的两个主要问题之一是基于数据包源地址的下一跳（上行链路）选择问题。例如，如果企业网络有到ISP_A和ISP_B的两条上行链路，并且主机有来自子网_A和子网_B（分别属于ISP_A和ISP_B）的地址，则来自子网_A的数据包必须发送到ISP_A上行链路，而来自子网_B的数据包必须发送到ISP_B上行链路。如果这些ISP或其上行链路实施反屏蔽入口过滤[RFC2827][RFC3704]，则将源地址属于一个ISP地址空间的数据包发送给另一个ISP可能会导致这些数据包被过滤掉。
While some work is being done in the Source Address Dependent Routing (SADR) (such as [DESTINATION]), the simplest way to implement the desired functionality currently is to apply a policy that selects a next hop or an egress interface based on the packet source address. Currently, most SMB/Enterprise-grade routers have such functionality available.
虽然在源地址相关路由（SADR）（例如[DESTINATION]）中正在进行一些工作，但当前实现所需功能的最简单方法是应用基于分组源地址选择下一跳或出口接口的策略。目前，大多数SMB/企业级路由器都具有此类功能。
Another problem to be solved in the multihoming scenario is the source address selection on hosts. In the normal situation (all uplinks are up/operational), hosts have multiple global unique addresses and can rely on the default address selection algorithm [RFC6724] to pick up a source address, while the network is responsible for choosing the correct uplink based on the source
在多宿主场景中要解决的另一个问题是主机上的源地址选择。在正常情况下（所有上行链路均已启动/运行），主机具有多个全局唯一地址，并且可以依靠默认地址选择算法[RFC6724]拾取源地址，同时网络负责根据源选择正确的上行链路
address selected by a host, as described in Section 3.1.1. However, some network topology changes (i.e., changing uplink status) might affect the global reachability for packets sourced from particular prefixes; therefore, such changes have to be signaled back to the hosts. For example:
主机选择的地址，如第3.1.1节所述。然而，一些网络拓扑变化（即，改变上行链路状态）可能会影响来自特定前缀的数据包的全局可达性；因此，必须向主机发回此类更改的信号。例如：
o An uplink to ISP_A went down. Hosts should not use addresses from an ISP_A prefix;
o ISP_A的上行线路中断。主机不应使用来自ISP的地址作为前缀；
o A primary uplink to ISP_A that was not operational has come back up. Hosts should start using the source addresses from an ISP_A prefix.
o 未运行的ISP_A主上行已恢复。主机应开始使用ISP的源地址作为前缀。
[PROVIDER-ASSIGNED] provides a detailed explanation of why Stateless Address Autoconfiguration (SLAAC) [RFC4862] and Router Advertisements (RAs) [RFC4861] are the most suitable mechanisms for signaling network topology changes to hosts, thereby influencing the source address selection. Sending an RA to change the preferred lifetime for a given prefix provides the following functionality:
[PROVIDER-ASSIGNED]详细解释了为什么无状态地址自动配置（SLAAC）[RFC4862]和路由器广告（RAs）[RFC4861]是向主机发送网络拓扑更改信号的最合适机制，从而影响源地址选择。发送RA以更改给定前缀的首选生存期可提供以下功能：
o Deprecating addresses by sending an RA with preferred_lifetime set to 0 in the corresponding Prefix Information option (PIO) [RFC4861]. This indicates to hosts that addresses from that prefix should not be used;
o 通过发送在相应前缀信息选项（PIO）中首选_生存期设置为0的RA来弃用地址[RFC4861]。这向主机指示不应使用该前缀中的地址；
o Making a previously unused (deprecated) prefix usable again by sending an RA containing a PIO with nonzero preferred lifetime. This indicates to hosts that addresses from that prefix can be used again.
o 通过发送包含具有非零首选生存期的PIO的RA，使以前未使用（不推荐使用）的前缀再次可用。这向主机指示该前缀中的地址可以再次使用。
It should be noted that only the preferred lifetime for the affected prefix needs to be changed. As the goal is to influence the source address selection algorithm on hosts rather than prevent them from forming addresses from a specific prefix, the valid lifetime should not be changed. Actually, changing the valid lifetime would not even be possible for unauthenticated RAs (which is the most common deployment scenario), because Section 5.5.3 of [RFC4862] prevents hosts from setting the valid lifetime for addresses to zero unless RAs are authenticated.
应该注意的是，只需要更改受影响前缀的首选生存期。由于目标是影响主机上的源地址选择算法，而不是阻止它们从特定前缀形成地址，因此不应更改有效生存期。实际上，更改未经验证的RAs的有效生存期甚至是不可能的（这是最常见的部署场景），因为[RFC4862]的第5.5.3节阻止主机将地址的有效生存期设置为零，除非RAs经过验证。
To provide the desired functionality, first-hop routers are required to:
为了提供所需的功能，第一跳路由器需要：
o Send RAs triggered by defined event policies in response to an uplink status change event; and
o 发送由定义的事件策略触发的RAs，以响应上行链路状态更改事件；和
o While sending periodic or solicited RAs, set the value in the given RA field (e.g., PIO preferred lifetime) based on the uplink status.
o 在发送定期或请求的RA时，根据上行链路状态在给定RA字段中设置值（例如，PIO首选寿命）。
The exact definition of the "uplink status" depends on the network topology and may include conditions like:
“上行链路状态”的确切定义取决于网络拓扑，可能包括以下条件：
o Uplink interface status change;
o 上行接口状态变化；
o Presence of a particular route in the routing table;
o 在路由表中存在特定路由；
o Presence of a particular route with a particular attribute (next hop, tag, etc.) in the routing table;
o 在路由表中存在具有特定属性（下一跳、标记等）的特定路由；
o Protocol adjacency change.
o 协议邻接改变。
In some scenarios, when two routers are providing first-hop redundancy via Virtual Router Redundancy Protocol (VRRP) [RFC5798], the master-backup status can be considered to be a condition for sending RAs and changing the preferred lifetime value. See Section 3.2.2 for more details.
在某些情况下，当两个路由器通过虚拟路由器冗余协议（VRRP）[RFC5798]提供第一跳冗余时，可以将主备份状态视为发送RAs和更改首选生存期值的条件。详见第3.2.2节。
If hosts are provided with the IPv6 addresses of ISP DNS servers via a Recursive DNS Server (RDNSS) (see "IPv6 Router Advertisement Options for DNS Configuration" [RFC8106]), it might be desirable for the conditional RAs to update the Lifetime field of the RDNSS option as well.
如果通过递归DNS服务器（RDNS）向主机提供ISP DNS服务器的IPv6地址（请参阅“DNS配置的IPv6路由器公告选项”[RFC8106]），则条件RAs可能还需要更新RDNS选项的生存期字段。
The trigger is not only forcing the router to send an unsolicited RA to propagate the topology changes to all hosts. Obviously, the values of the RA fields (like PIO Preferred Lifetime or DNS Server Lifetime) changed by the particular trigger need to stay the same until another event causes the value to be updated. For example, if an ISP_A uplink failure causes the prefix to be deprecated, all solicited and unsolicited RAs sent by the router need to have the preferred lifetime for that PIO set to 0 until the uplink comes back up.
触发器不仅强制路由器发送未经请求的RA以将拓扑更改传播到所有主机。显然，由特定触发器更改的RA字段的值（如PIO首选生存期或DNS服务器生存期）需要保持不变，直到另一个事件导致更新该值。例如，如果ISP_A上行链路故障导致前缀被弃用，则路由器发送的所有请求和未请求的RAs需要将该PIO的首选生存期设置为0，直到上行链路恢复。
It should be noted that the proposed solution is quite similar to the existing requirement L-13 for IPv6 Customer Edge Routers [RFC7084] and the documented behavior of homenet devices [RFC7788]. It is using the same mechanism of deprecating a prefix when the corresponding uplink is not operational, applying it to an enterprise-network scenario.
需要注意的是，提议的解决方案与IPv6客户边缘路由器[RFC7084]的现有要求L-13以及homenet设备的记录行为[RFC7788]非常相似。它使用相同的机制，在相应的上行链路不工作时弃用前缀，将其应用于企业网络场景。
This section illustrates how the conditional RAs solution can be applied to the most common enterprise multihoming scenarios, described in Section 2.
本节说明了如何将条件RAs解决方案应用于最常见的企业多主场景，如第2节所述。
--------
,-------, / \
+----+ 2001:db8:1::/48 ,' ', : :
| |-----------------+ ISP_A +--+: :
2001:db8:1:1::/64 | | ', ,' : :
| | '-------' : :
H1-----------------| R1 | : INTERNET :
| | ,-------, : :
2001:db8:2:1::/64 | | 2001:db8:2::/48 ,' ', : :
| |-----------------+ ISP_B +--+: :
+----+ ', ,' : :
'-------' \ /
--------
--------
,-------, / \
+----+ 2001:db8:1::/48 ,' ', : :
| |-----------------+ ISP_A +--+: :
2001:db8:1:1::/64 | | ', ,' : :
| | '-------' : :
H1-----------------| R1 | : INTERNET :
| | ,-------, : :
2001:db8:2:1::/64 | | 2001:db8:2::/48 ,' ', : :
| |-----------------+ ISP_B +--+: :
+----+ ', ,' : :
'-------' \ /
--------
Figure 1: Single Router, Primary/Backup Uplinks
图1：单路由器、主/备份上行链路
Let's look at a simple network topology where a single router acts as a border router to terminate two ISP uplinks and as a first-hop router for hosts. Each ISP assigns a /48 to the network, and the ISP_A uplink is a primary one, to be used for all Internet traffic, while the ISP_B uplink is a backup, to be used only when the primary uplink is not operational.
让我们看一个简单的网络拓扑，其中一个路由器充当边界路由器来终止两个ISP上行链路，并充当主机的第一跳路由器。每个ISP将a/48分配给网络，ISP_a上行链路是主上行链路，用于所有互联网流量，而ISP_B上行链路是备份，仅在主上行链路不工作时使用。
To ensure that packets with source addresses from ISP_A and ISP_B are only routed to ISP_A and ISP_B uplinks, respectively, the network administrator needs to configure a policy on R1:
为确保源地址来自ISP_A和ISP_B的数据包仅分别路由到ISP_A和ISP_B上行链路，网络管理员需要在R1上配置策略：
IF (packet_source_address is in 2001:db8:1::/48)
and
(packet_destination_address is not in
(2001:db8:1::/48 or 2001:db8:2::/48))
THEN
default next hop is ISP_A_uplink
IF (packet_source_address is in 2001:db8:1::/48)
and
(packet_destination_address is not in
(2001:db8:1::/48 or 2001:db8:2::/48))
THEN
default next hop is ISP_A_uplink
IF (packet_source_address is in 2001:db8:2::/48)
and
(packet_destination_address is not in
(2001:db8:1::/48 or 2001:db8:2::/48))
THEN
default next hop is ISP_B_uplink
IF (packet_source_address is in 2001:db8:2::/48)
and
(packet_destination_address is not in
(2001:db8:1::/48 or 2001:db8:2::/48))
THEN
default next hop is ISP_B_uplink
Under normal circumstances, it is desirable that all traffic be sent via the ISP_A uplink; therefore, hosts (the host H1 in the example topology figure) should be using source addresses from 2001:db8:1:1::/64. When or if the ISP_A uplink fails, hosts should stop using the 2001:db8:1:1::/64 prefix and start using 2001:db8:2:1::/64 until the ISP_A uplink comes back up. To achieve this, the RA configuration on the R1 device for the interface facing H1 needs to have the following policy:
在正常情况下，希望所有业务都通过ISP_A上行链路发送；因此，主机（示例拓扑图中的主机H1）应该使用2001:db8:1:1:：/64中的源地址。当或如果ISP_A上行出现故障，主机应停止使用2001:db8:1:1:：/64前缀，并开始使用2001:db8:2:1:：/64，直到ISP_A上行恢复。为此，R1设备上面向H1接口的RA配置需要具有以下策略：
prefix 2001:db8:1:1::/64 {
IF (ISP_A_uplink is up)
THEN
preferred_lifetime = 604800
ELSE
preferred_lifetime = 0
}
prefix 2001:db8:1:1::/64 {
IF (ISP_A_uplink is up)
THEN
preferred_lifetime = 604800
ELSE
preferred_lifetime = 0
}
prefix 2001:db8:2:1::/64 {
IF (ISP_A_Uplink is up)
THEN
preferred_lifetime = 0
ELSE
preferred_lifetime = 604800
}
prefix 2001:db8:2:1::/64 {
IF (ISP_A_Uplink is up)
THEN
preferred_lifetime = 0
ELSE
preferred_lifetime = 604800
}
A similar policy needs to be applied to the RDNSS lifetime if ISP_A and ISP_B DNS servers are used.
如果使用ISP_A和ISP_B DNS服务器，则需要对RDNS生存期应用类似的策略。
Let's look at a more complex scenario where two border routers are terminating two ISP uplinks (one each), acting as redundant first-hop routers for hosts. The topology is shown in Figure 2.
让我们看一个更复杂的场景，其中两个边界路由器终止两个ISP上行链路（每个链路一个），充当主机的冗余第一跳路由器。拓扑如图2所示。
--------
,-------, / \
2001:db8:1:1::/64 +----+ 2001:db8:1::/48 ,' ', : :
_| |----------------+ ISP_A +--+: :
| | R1 | ', ,' : :
| +----+ '-------' : :
H1----------------| : INTERNET :
| +----+ ,-------, : :
|_| | 2001:db8:2::/48 ,' ', : :
| R2 |----------------+ ISP_B +--+: :
2001:db8:2:1::/64 +----+ ', ,' : :
'-------' \ /
--------
--------
,-------, / \
2001:db8:1:1::/64 +----+ 2001:db8:1::/48 ,' ', : :
_| |----------------+ ISP_A +--+: :
| | R1 | ', ,' : :
| +----+ '-------' : :
H1----------------| : INTERNET :
| +----+ ,-------, : :
|_| | 2001:db8:2::/48 ,' ', : :
| R2 |----------------+ ISP_B +--+: :
2001:db8:2:1::/64 +----+ ', ,' : :
'-------' \ /
--------
Figure 2: Two Routers, Primary/Backup Uplinks
图2：两个路由器，主/备份上行链路
In this scenario, R1 sends RAs with PIO for 2001:db8:1:1::/64 (ISP_A address space), and R2 sends RAs with PIO for 2001:db8:2:1::/64 (ISP_B address space). Each router needs to have a forwarding policy configured for packets received on its hosts-facing interface:
在这种情况下，R1为2001:db8:1:1:：/64（ISP_A地址空间）发送带有PIO的RAs，R2为2001:db8:2:1:：/64（ISP_B地址空间）发送带有PIO的RAs。每个路由器都需要为其面向主机的接口上接收的数据包配置转发策略：
IF (packet_source_address is in 2001:db8:1::/48)
and
(packet_destination_address is not in
(2001:db8:1::/48 or 2001:db8:2::/48))
THEN
default next hop is ISP_A_uplink
IF (packet_source_address is in 2001:db8:1::/48)
and
(packet_destination_address is not in
(2001:db8:1::/48 or 2001:db8:2::/48))
THEN
default next hop is ISP_A_uplink
IF (packet_source_address is in 2001:db8:2::/48)
and
(packet_destination_address is not in
(2001:db8:1::/48 or 2001:db8:2::/48))
THEN
default next hop is ISP_B_uplink
IF (packet_source_address is in 2001:db8:2::/48)
and
(packet_destination_address is not in
(2001:db8:1::/48 or 2001:db8:2::/48))
THEN
default next hop is ISP_B_uplink
In this case, there is more than one way to ensure that hosts are selecting the correct source address based on the uplink status. If VRRP is used to provide first-hop redundancy, and the master router is the one with the active uplink, then the simplest way is to use the VRRP mastership as a condition for RA. So, if ISP_A is the primary uplink, the routers R1 and R2 need to be configured in the following way:
在这种情况下，有多种方法可以确保主机根据上行链路状态选择正确的源地址。如果VRRP用于提供第一跳冗余，并且主路由器是具有活动上行链路的路由器，那么最简单的方法是使用VRRP主路由器作为RA的条件。因此，如果ISP_A是主上行链路，则路由器R1和R2需要按以下方式配置：
R1 is the VRRP master by default (when the ISP_A uplink is up). If the ISP_A uplink is down, then R1 becomes a backup (the VRRP interface-status tracking is expected to be used to automatically
R1默认为VRRP主机（当ISP_A上行链路启动时）。如果ISP_A上行链路关闭，则R1将成为备份（预计将使用VRRP接口状态跟踪自动
modify the VRRP priorities and trigger the mastership switchover). RAs on R1's interface facing H1 needs to have the following policy applied:
修改VRRP优先级并触发主控权切换）。R1接口上面向H1的RAs需要应用以下策略：
prefix 2001:db8:1:1::/64 {
IF (vrrp_master)
THEN
preferred_lifetime = 604800
ELSE
preferred_lifetime = 0
}
prefix 2001:db8:1:1::/64 {
IF (vrrp_master)
THEN
preferred_lifetime = 604800
ELSE
preferred_lifetime = 0
}
R2 is VRRP backup by default. RA on R2's interface facing H1 needs to have the following policy applied:
R2默认为VRRP备份。R2接口上面向H1的RA需要应用以下策略：
prefix 2001:db8:2:1::/64 {
IF(vrrp_master)
THEN
preferred_lifetime = 604800
ELSE
preferred_lifetime = 0
}
prefix 2001:db8:2:1::/64 {
IF(vrrp_master)
THEN
preferred_lifetime = 604800
ELSE
preferred_lifetime = 0
}
If VRRP is not used or interface status tracking is not used for mastership switchover, then each router needs to be able to detect the uplink failure/recovery on the neighboring router, so that RAs with updated preferred lifetime values are triggered. Depending on the network setup, various triggers can be used, such as a route to the uplink interface subnet or a default route received from the uplink. The obvious drawback of using the routing table to trigger the conditional RAs is that some additional configuration is required. For example, if a route to the prefix assigned to the ISP uplink is used as a trigger, then the conditional RA policy would have the following logic:
如果VRRP未使用或接口状态跟踪未用于主控权切换，则每个路由器需要能够检测相邻路由器上的上行链路故障/恢复，以便触发具有更新的首选生存期值的RAs。根据网络设置，可以使用各种触发器，例如到上行链路接口子网的路由或从上行链路接收的默认路由。使用路由表触发条件RAs的明显缺点是需要一些额外的配置。例如，如果将分配给ISP上行链路的前缀的路由用作触发器，则条件RA策略将具有以下逻辑：
R1:
R1:
prefix 2001:db8:1:1::/64 {
IF (ISP_A_uplink is up)
THEN
preferred_lifetime = 604800
ELSE
preferred_lifetime = 0
}
prefix 2001:db8:1:1::/64 {
IF (ISP_A_uplink is up)
THEN
preferred_lifetime = 604800
ELSE
preferred_lifetime = 0
}
R2:
R2:
prefix 2001:db8:2:1::/64 {
IF (ISP_A_uplink_route is present)
THEN
preferred_lifetime = 0
ELSE
preferred_lifetime = 604800
}
prefix 2001:db8:2:1::/64 {
IF (ISP_A_uplink_route is present)
THEN
preferred_lifetime = 0
ELSE
preferred_lifetime = 604800
}
Let's look at the example topology shown in Figure 1, but with both uplinks used simultaneously. In this case, R1 would send RAs containing PIOs for both prefixes, 2001:db8:1:1::/64 and 2001:db8:2:1::/64, changing the preferred lifetime based on particular uplink availability. If the interface status is used as an uplink availability indicator, then the policy logic would look like the following:
让我们看看图1所示的示例拓扑，但同时使用两个上行链路。在这种情况下，R1将发送包含两个前缀（2001:db8:1:1:：/64和2001:db8:2:1:：/64）的PIO的RAs，并根据特定的上行可用性更改首选生存期。如果接口状态用作上行可用性指示器，则策略逻辑如下所示：
prefix 2001:db8:1:1::/64 {
IF (ISP_A_uplink is up)
THEN
preferred_lifetime = 604800
ELSE
preferred_lifetime = 0
}
prefix 2001:db8:2:1::/64 {
IF (ISP_B_uplink is up)
THEN
preferred_lifetime = 604800
ELSE
preferred_lifetime = 0
}
prefix 2001:db8:1:1::/64 {
IF (ISP_A_uplink is up)
THEN
preferred_lifetime = 604800
ELSE
preferred_lifetime = 0
}
prefix 2001:db8:2:1::/64 {
IF (ISP_B_uplink is up)
THEN
preferred_lifetime = 604800
ELSE
preferred_lifetime = 0
}
R1 needs a forwarding policy to be applied to forward packets to the correct uplink based on the source address, similar to the policy described in Section 3.2.1.
R1需要应用转发策略，根据源地址将数据包转发到正确的上行链路，类似于第3.2.1节中描述的策略。
In this scenario, the example topology is similar to the one shown in Figure 2, but both uplinks can be used at the same time. This means that both R1 and R2 need to have the corresponding forwarding policy to forward packets based on their source addresses.
在这个场景中，示例拓扑与图2中所示的拓扑相似，但是两个上行链路可以同时使用。这意味着R1和R2都需要有相应的转发策略来根据其源地址转发数据包。
Each router would send RAs with PIO for the corresponding prefix, setting preferred_lifetime to a nonzero value when the ISP uplink is up and deprecating the prefix by setting preferred_lifetime to 0 in the case of uplink failure. The uplink recovery would trigger another RA with a nonzero preferred lifetime to make the addresses from the prefix preferred again. The example RA policy on R1 and R2 would look like:
每个路由器都会为相应的前缀发送带有PIO的RAs，当ISP上行链路启动时，将首选_生存期设置为非零值，并在上行链路故障时，通过将首选_生存期设置为0来弃用前缀。上行链路恢复将触发另一个首选生存期非零的RA，以使前缀中的地址再次成为首选地址。R1和R2上的RA策略示例如下所示：
R1:
prefix 2001:db8:1:1::/64 {
IF (ISP_A_uplink is up)
THEN
preferred_lifetime = 604800
ELSE
preferred_lifetime = 0
}
R1:
prefix 2001:db8:1:1::/64 {
IF (ISP_A_uplink is up)
THEN
preferred_lifetime = 604800
ELSE
preferred_lifetime = 0
}
R2:
R2:
prefix 2001:db8:2:1::/64 {
IF (ISP_B_uplink is up)
THEN
preferred_lifetime = 604800
ELSE
preferred_lifetime = 0
}
prefix 2001:db8:2:1::/64 {
IF (ISP_B_uplink is up)
THEN
preferred_lifetime = 604800
ELSE
preferred_lifetime = 0
}
For simplicity, all topologies above show the ISP uplinks terminated on the first-hop routers. Obviously, the proposed approach can be used in more complex topologies when dedicated devices are used for terminating ISP uplinks. In that case, VRRP mastership or interface status cannot be used as a trigger for conditional RAs. Route presence as described in Section 3.2.2 should be used instead.
为简单起见，以上所有拓扑均显示了在第一跳路由器上终止的ISP上行链路。显然，当专用设备用于终止ISP上行链路时，所提出的方法可用于更复杂的拓扑。在这种情况下，VRRP主控权或接口状态不能用作条件RAs的触发器。应改用第3.2.2节所述的路线存在。
Let's look at the example topology shown in Figure 3:
让我们看看图3所示的示例拓扑：
2001:db8:1::/48 --------
2001:db8:1:1::/64 ,-------, ,' ',
+----+ +---+ +----+ ,' ', : :
_| |--| |--| R3 |----+ ISP_A +---+: :
| | R1 | | | +----+ ', ,' : :
| +----+ | | '-------' : :
H1--------| |LAN| : INTERNET :
| +----+ | | ,-------, : :
|_| | | | +----+ ,' ', : :
| R2 |--| |--| R4 |----+ ISP_B +---+: :
+----+ +---+ +----+ ', ,' : :
2001:db8:2:1::/64 '-------' ', ,'
2001:db8:2::/48 --------
2001:db8:1::/48 --------
2001:db8:1:1::/64 ,-------, ,' ',
+----+ +---+ +----+ ,' ', : :
_| |--| |--| R3 |----+ ISP_A +---+: :
| | R1 | | | +----+ ', ,' : :
| +----+ | | '-------' : :
H1--------| |LAN| : INTERNET :
| +----+ | | ,-------, : :
|_| | | | +----+ ,' ', : :
| R2 |--| |--| R4 |----+ ISP_B +---+: :
+----+ +---+ +----+ ', ,' : :
2001:db8:2:1::/64 '-------' ', ,'
2001:db8:2::/48 --------
Figure 3: Dedicated Border Routers
图3：专用边界路由器
For example, if ISP_A is a primary uplink and ISP_B is a backup, then the following policy might be used to achieve the desired behavior (H1 is using ISP_A address space, 2001:db8:1:1::/64, while the ISP_A uplink is up and only using the ISP_B 2001:db8:2:1::/64 prefix if the uplink is non-operational):
例如，如果ISP_A是主上行链路，而ISP_B是备份，则可以使用以下策略来实现所需的行为（H1使用ISP_A地址空间，2001:db8:1:：/64，而ISP_A上行链路启动，并且如果上行链路不工作，则仅使用ISP_B 2001:db8:2:1:：/64前缀）：
R1 and R2 policy:
R1和R2策略：
prefix 2001:db8:1:1::/64 {
IF (ISP_A_uplink_route is present)
THEN
preferred_lifetime = 604800
ELSE
preferred_lifetime = 0
}
prefix 2001:db8:1:1::/64 {
IF (ISP_A_uplink_route is present)
THEN
preferred_lifetime = 604800
ELSE
preferred_lifetime = 0
}
prefix 2001:db8:2:1::/64 {
IF (ISP_A_uplink_route is present)
THEN
preferred_lifetime = 0
ELSE
preferred_lifetime = 604800
}
prefix 2001:db8:2:1::/64 {
IF (ISP_A_uplink_route is present)
THEN
preferred_lifetime = 0
ELSE
preferred_lifetime = 604800
}
For the load-balancing case, the policy would look slightly different: each prefix has a nonzero preferred_lifetime only if the corresponding ISP uplink route is present:
对于负载平衡情况，策略看起来略有不同：仅当存在相应的ISP上行链路路由时，每个前缀具有非零的首选_生存期：
prefix 2001:db8:1:1::/64 {
IF (ISP_A_uplink_route is present)
THEN
preferred_lifetime = 604800
ELSE
preferred_lifetime = 0
}
prefix 2001:db8:1:1::/64 {
IF (ISP_A_uplink_route is present)
THEN
preferred_lifetime = 604800
ELSE
preferred_lifetime = 0
}
prefix 2001:db8:2:1::/64 {
IF (ISP_B_uplink_route is present)
THEN
preferred_lifetime = 604800
ELSE
preferred_lifetime = 0
}
prefix 2001:db8:2:1::/64 {
IF (ISP_B_uplink_route is present)
THEN
preferred_lifetime = 604800
ELSE
preferred_lifetime = 0
}
Prefix deprecation as a result of an uplink status change might lead to a situation in which all global prefixes are deprecated (all ISP uplinks are not operational for some reason). Even when there is no Internet connectivity, it might be still desirable to have intrasite IPv6 connectivity (especially when the network in question is an IPv6-only one). However, while an address is in a deprecated state, its use is discouraged, but not strictly forbidden [RFC4862]. In such a scenario, all IPv6 source addresses in the candidate set [RFC6724] are deprecated, which means that they still can be used (as there are no preferred addresses available), and the source address selection algorithm can pick up one of them, allowing intrasite communication. However, some operating systems might just fall back to IPv4 if the network interface has no preferred IPv6 global addresses. Therefore, if intrasite connectivity is vital during simultaneous outages of multiple uplinks, administrators might consider using Unique Local Addresses (ULAs) [RFC4193] or provisioning additional backup uplinks to protect the network from double-failure cases.
上行链路状态更改导致的前缀弃用可能导致所有全局前缀都弃用的情况（由于某些原因，所有ISP上行链路都无法运行）。即使在没有Internet连接的情况下，也可能希望有站点内IPv6连接（特别是当所讨论的网络仅为IPv6连接时）。但是，当地址处于不推荐状态时，不鼓励使用，但并非严格禁止[RFC4862]。在这种情况下，候选集[RFC6724]中的所有IPv6源地址都不推荐使用，这意味着它们仍然可以使用（因为没有可用的首选地址），并且源地址选择算法可以选择其中一个，从而允许站点内通信。但是，如果网络接口没有首选的IPv6全局地址，某些操作系统可能会退回到IPv4。因此，如果在多个上行链路同时中断的情况下，内部连接是至关重要的，管理员可能会考虑使用唯一本地地址（ULAS）[RCF4193]或提供额外的备份上行链路来保护网络免受双重故障的影响。
If an actively used uplink (a primary one or one used in a load-balancing scenario) starts flapping, it might lead to the undesirable situation of flapping addresses on hosts: every time the uplink goes up, hosts receive an RA with a nonzero preferred PIO lifetime, and every time the uplink goes down, all addresses in the affected prefix
如果主动使用的上行链路（主上行链路或负载平衡场景中使用的上行链路）开始摆动，则可能会导致主机上地址摆动的不良情况：每次上行链路上升时，主机都会收到首选PIO生存期为非零的RA，而每次上行链路下降时，受影响前缀中的所有地址都会出现摆动
become deprecated. This would, undoubtedly, negatively impact the user experience, not to mention the impact of spikes of duplicate address detection traffic every time an uplink comes back up. Therefore, it's recommended that router vendors implement some form of damping policy for conditional RAs and either postpone sending an RA with a nonzero lifetime for a PIO when the uplink comes up for a number of seconds or (even) introduce accumulated penalties/ exponential backoff algorithm for such delays. (In the case of multiple simultaneous uplink failure, when all but one of the uplinks are down and the last remaining one is flapping, it might result in all addresses being deprecated for a while after the flapping uplink recovers.)
变得不受欢迎。这无疑会对用户体验产生负面影响，更不用说每次上行链路恢复时重复地址检测流量峰值的影响了。因此，建议路由器供应商为条件RAs实施某种形式的阻尼策略，或者在上行链路出现数秒时延迟发送PIO的非零生存期RA，或者（甚至）为此类延迟引入累积惩罚/指数退避算法。（在多个同时上行链路故障的情况下，当除一个上行链路外的所有上行链路都已关闭且最后一个剩余上行链路正在摆动时，可能会导致在摆动上行链路恢复后的一段时间内，所有地址都被弃用。）
Deprecating IPv6 addresses by setting the preferred lifetime to 0 discourages but does not strictly forbid its usage in new communications. A deprecated address may still be used for existing connections [RFC4862]. Therefore, when an ISP uplink goes down, the corresponding border router might still receive packets with source addresses belonging to that ISP address space while there is no available uplink to send those packets to.
通过将首选生存期设置为0来弃用IPv6地址不鼓励但并不严格禁止在新通信中使用它。不推荐使用的地址仍可用于现有连接[RFC4862]。因此，当ISP上行链路断开时，相应的边界路由器仍可能接收源地址属于该ISP地址空间的数据包，而没有可用的上行链路将这些数据包发送到该地址空间。
The expected router behavior would depend on the uplink selection mechanism. For example, if some form of SADR is used, then such packets will be dropped as there is no route to the destination. If policy-based routing is used to set a next hop, then the behavior would be implementation dependent and may vary from dropping the packets to forwarding them based on the routing table entries. It should be noted that there is no return path to the packet source (as the ISP uplink is not operational). Therefore, even if the outgoing packets are sent to another ISP, the return traffic might not be delivered.
预期的路由器行为将取决于上行链路选择机制。例如，如果使用某种形式的SADR，则由于没有到目的地的路由，这些数据包将被丢弃。如果使用基于策略的路由来设置下一个跃点，那么行为将取决于实现，可能会有所不同，从丢弃数据包到根据路由表条目转发数据包。应该注意的是，没有到数据包源的返回路径（因为ISP上行链路不工作）。因此，即使传出的数据包被发送到另一个ISP，返回的流量也可能无法传递。
It should be noted that the proposed approach is not a "silver bullet" for all possible multihoming scenarios. It would work very well for networks with relatively simple topologies and straightforward routing policies. The more complex the network topology and the corresponding routing policies, the more configuration would be required to implement the solution.
应该指出的是，对于所有可能的多宿情况，拟议的方法并不是一个“银弹”。对于具有相对简单的拓扑结构和直接的路由策略的网络，它将非常有效。网络拓扑和相应的路由策略越复杂，实现解决方案所需的配置就越多。
Another limitation is related to the load-balancing between the uplinks. In the scenario in which both uplinks are active, hosts would select the source prefix using the Default Address Selection algorithm [RFC6724]; therefore, the load between two uplinks most likely would not be evenly distributed. (However, the proposed
另一个限制与上行链路之间的负载平衡有关。在两条上行链路都处于活动状态的场景中，主机将使用默认地址选择算法[RFC6724]选择源前缀；因此，两条上行链路之间的荷载很可能不会均匀分布。（但是，拟议的
mechanism does allow a creative way of controlling uplinks load in software-defined networks where controllers might selectively deprecate prefixes on some hosts but not others to move egress traffic between uplinks). Also, the prefix selection does not take into account any other properties of uplinks (such as latency), so egress traffic might not be sent to the nearest uplink if the corresponding prefix is selected as a source. In general, if not all uplinks are equal, and some uplinks are expected to be preferred over others, then the network administrator should ensure that prefixes from non-preferred ISP(s) are kept deprecated (so primary/backup setup is used).
该机制确实允许在软件定义的网络中控制上行链路负载的创造性方法，其中控制器可能会有选择地拒绝使用某些主机上的前缀，而不是其他主机上的前缀，以在上行链路之间移动出口流量）。此外，前缀选择不考虑上行链路的任何其他属性（例如延迟），因此如果选择相应的前缀作为源，则出口业务可能不会发送到最近的上行链路。一般来说，如果并非所有上行链路都相同，并且某些上行链路预期优于其他上行链路，则网络管理员应确保来自非首选ISP的前缀保持不推荐（因此使用主/备份设置）。
The proposed solution is not designed to preserve connection state after an uplink failure. If all uplinks to an ISP go down, all sessions to/from addresses from that ISP address space are interrupted as there is no egress path for those packets and there is no return path from the Internet to the corresponding prefix. In this regard, it is similar to IPv4 multihoming using NAT, where an uplink failure and failover to another uplink means that a public IPv4 address changes and all existing connections are interrupted.
所提出的解决方案不是为了在上行链路故障后保持连接状态而设计的。如果到ISP的所有上行链路都中断，则与该ISP地址空间的地址之间的所有会话都会中断，因为这些数据包没有出口路径，也没有从Internet到相应前缀的返回路径。在这方面，它类似于使用NAT的IPv4多宿主，其中上行链路故障和到另一上行链路的故障切换意味着公共IPv4地址发生更改，并且所有现有连接中断。
However, an uplink recovery does not necessarily lead to connections interruption. In the load-sharing/balancing scenario, an uplink recovery does not affect any existing connections at all. In the active/backup topology, when the primary uplink recovers from the failure and the backup prefix is deprecated, the existing sessions (established to/from the backup ISP addresses) can be preserved if the routers are configured as described in Section 3.2.1 and send packets with the backup ISP source addresses to the backup uplink, even when the primary one is operational. As a result, the primary uplink recovery makes the usage of the backup ISP addresses discouraged but still possible.
但是，上行链路恢复不一定会导致连接中断。在负载共享/平衡场景中，上行链路恢复根本不会影响任何现有连接。在主动/备份拓扑中，当主上行链路从故障中恢复，并且备份前缀被弃用时，如果路由器按照第3.2.1节所述进行配置，并向备份上行链路发送带有备份ISP源地址的数据包，则可以保留现有会话（在备份ISP地址之间建立），即使主要的一个在运行。因此，主上行恢复不鼓励使用备份ISP地址，但仍有可能。
It should be noted that in IPv4 multihoming with NAT, when the egress interface is chosen without taking packet source address into account (as internal hosts usually have addresses from [RFC1918] space), sessions might not be preserved after an uplink recovery unless packet forwarding is integrated with existing NAT sessions tracking.
应该注意的是，在使用NAT的IPv4多宿主中，当选择出口接口而不考虑包源地址时（因为内部主机通常具有来自[RFC1918]空间的地址），除非包转发与现有NAT会话跟踪集成，否则在上行链路恢复后可能不会保留会话。
This document has no IANA actions.
本文档没有IANA操作。
This memo introduces no new security considerations. It relies on RAs [RFC4861] and the SLAAC [RFC4862] mechanism and inherits their security properties. If an attacker is able to send a rogue RA, they could deprecate IPv6 addresses on hosts or influence source-address-selection processes on hosts.
此备忘录没有引入新的安全注意事项。它依赖于RAs[RFC4861]和SLAAC[RFC4862]机制，并继承它们的安全属性。如果攻击者能够发送流氓RA，他们可能会拒绝主机上的IPv6地址或影响主机上的源地址选择过程。
The potential attack vectors include, but are not limited to:
潜在攻击向量包括但不限于：
o An attacker sends a rogue RA deprecating IPv6 addresses on hosts;
o 攻击者在主机上发送盗贼RA拒绝使用IPv6地址；
o An attacker sends a rogue RA making addresses preferred while the corresponding ISP uplink is not operational;
o 当相应的ISP上行链路不工作时，攻击者发送恶意RA，使地址成为首选地址；
o An attacker sends a rogue RA making addresses preferred for a backup ISP, steering traffic to an undesirable (e.g., more expensive) uplink.
o 攻击者发送流氓RA，使备份ISP首选地址，将流量引导到不需要的（例如，更昂贵的）上行链路。
Therefore, the network administrators SHOULD secure RAs, e.g., by deploying an RA guard [RFC6105].
因此，网络管理员应保护RAs，例如，通过部署RA防护[RFC6105]。
This memo introduces no new privacy considerations.
此备忘录没有引入新的隐私注意事项。
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, <https://www.rfc-editor.org/info/rfc1918>.
[RFC1918]Rekhter，Y.，Moskowitz，B.，Karrenberg，D.，de Groot，G.，和E.Lear，“私人互联网地址分配”，BCP 5，RFC 1918，DOI 10.17487/RFC1918，1996年2月<https://www.rfc-editor.org/info/rfc1918>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, May 2000, <https://www.rfc-editor.org/info/rfc2827>.
[RFC2827]Ferguson，P.和D.Senie，“网络入口过滤：击败利用IP源地址欺骗的拒绝服务攻击”，BCP 38，RFC 2827，DOI 10.17487/RFC2827，2000年5月<https://www.rfc-editor.org/info/rfc2827>.
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, DOI 10.17487/RFC3022, January 2001, <https://www.rfc-editor.org/info/rfc3022>.
[RFC3022]Srisuresh，P.和K.Egevang，“传统IP网络地址转换器（传统NAT）”，RFC 3022，DOI 10.17487/RFC3022，2001年1月<https://www.rfc-editor.org/info/rfc3022>.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March 2004, <https://www.rfc-editor.org/info/rfc3704>.
[RFC3704]Baker，F.和P.Savola，“多宿网络的入口过滤”，BCP 84，RFC 3704，DOI 10.17487/RFC3704，2004年3月<https://www.rfc-editor.org/info/rfc3704>.
[RFC4116] Abley, J., Lindqvist, K., Davies, E., Black, B., and V. Gill, "IPv4 Multihoming Practices and Limitations", RFC 4116, DOI 10.17487/RFC4116, July 2005, <https://www.rfc-editor.org/info/rfc4116>.
[RFC4116]Abley，J.，Lindqvist，K.，Davies，E.，Black，B.，和V.Gill，“IPv4多宿主实践和限制”，RFC 4116，DOI 10.17487/RFC4116，2005年7月<https://www.rfc-editor.org/info/rfc4116>.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, <https://www.rfc-editor.org/info/rfc4193>.
[RFC4193]Hinden，R.和B.Haberman，“唯一本地IPv6单播地址”，RFC 4193，DOI 10.17487/RFC4193，2005年10月<https://www.rfc-editor.org/info/rfc4193>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, <https://www.rfc-editor.org/info/rfc4291>.
[RFC4291]Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 4291，DOI 10.17487/RFC42912006年2月<https://www.rfc-editor.org/info/rfc4291>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007, <https://www.rfc-editor.org/info/rfc4862>.
[RFC4862]Thomson，S.，Narten，T.和T.Jinmei，“IPv6无状态地址自动配置”，RFC 4862，DOI 10.17487/RFC4862，2007年9月<https://www.rfc-editor.org/info/rfc4862>.
[RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, DOI 10.17487/RFC6105, February 2011, <https://www.rfc-editor.org/info/rfc6105>.
[RFC6105]Levy Abegnoli，E.，Van de Velde，G.，Popoviciu，C.，和J.Mohacsi，“IPv6路由器广告保护”，RFC 6105DOI 10.17487/RFC6105，2011年2月<https://www.rfc-editor.org/info/rfc6105>.
[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, <https://www.rfc-editor.org/info/rfc6724>.
[RFC6724]Thaler，D.，Ed.，Draves，R.，Matsumoto，A.，和T.Chown，“互联网协议版本6（IPv6）的默认地址选择”，RFC 6724，DOI 10.17487/RFC67242012年9月<https://www.rfc-editor.org/info/rfc6724>.
[RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by Hosts in a Multi-Prefix Network", RFC 8028, DOI 10.17487/RFC8028, November 2016, <https://www.rfc-editor.org/info/rfc8028>.
[RFC8028]Baker，F.和B.Carpenter，“多前缀网络中主机的第一跳路由器选择”，RFC 8028，DOI 10.17487/RFC8028，2016年11月<https://www.rfc-editor.org/info/rfc8028>.
[RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, "IPv6 Router Advertisement Options for DNS Configuration", RFC 8106, DOI 10.17487/RFC8106, March 2017, <https://www.rfc-editor.org/info/rfc8106>.
[RFC8106]Jeong，J.，Park，S.，Beloeil，L.，和S.Madanapalli，“DNS配置的IPv6路由器广告选项”，RFC 8106，DOI 10.17487/RFC8106，2017年3月<https://www.rfc-editor.org/info/rfc8106>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[DESTINATION] Lamparter, D. and A. Smirnov, "Destination/Source Routing", Work in Progress, draft-ietf-rtgwg-dst-src-routing-06, October 2017.
[目的地]Lamparter，D.和A.Smirnov，“目的地/源路由”，正在进行的工作，草稿-ietf-rtgwg-dst-src-Routing-062017年10月。
[PROVIDER-ASSIGNED] Baker, F., Bowers, C., and J. Linkova, "Enterprise Multihoming using Provider-Assigned Addresses without Network Prefix Translation: Requirements and Solution", Work in Progress, draft-ietf-rtgwg-enterprise-pa-multihoming-07, June 2018.
[PROVIDER-ASSIGNED]Baker，F.，Bowers，C.，和J.Linkova，“使用提供商分配的地址而无网络前缀转换的企业多址：要求和解决方案”，正在进行的工作，草稿-ietf-rtgwg-Enterprise-pa-Multihoming-07，2018年6月。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, <https://www.rfc-editor.org/info/rfc4861>.
[RFC4861]Narten，T.，Nordmark，E.，Simpson，W.，和H.Soliman，“IP版本6（IPv6）的邻居发现”，RFC 4861，DOI 10.17487/RFC48612007年9月<https://www.rfc-editor.org/info/rfc4861>.
[RFC5798] Nadas, S., Ed., "Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6", RFC 5798, DOI 10.17487/RFC5798, March 2010, <https://www.rfc-editor.org/info/rfc5798>.
[RFC5798]Nadas，S.，Ed.，“IPv4和IPv6的虚拟路由器冗余协议（VRRP）第3版”，RFC 5798，DOI 10.17487/RFC5798，2010年3月<https://www.rfc-editor.org/info/rfc5798>.
[RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic Requirements for IPv6 Customer Edge Routers", RFC 7084, DOI 10.17487/RFC7084, November 2013, <https://www.rfc-editor.org/info/rfc7084>.
[RFC7084]Singh，H.，Beebee，W.，Donley，C.，和B.Stark，“IPv6客户边缘路由器的基本要求”，RFC 7084，DOI 10.17487/RFC7084，2013年11月<https://www.rfc-editor.org/info/rfc7084>.
[RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April 2016, <https://www.rfc-editor.org/info/rfc7788>.
[RFC7788]Stenberg，M.，Barth，S.，和P.Pfister，“家庭网络控制协议”，RFC 7788，DOI 10.17487/RFC7788，2016年4月<https://www.rfc-editor.org/info/rfc7788>.
Acknowledgements
致谢
Thanks to the following people (in alphabetical order) for their review and feedback: Mikael Abrahamsson, Lorenzo Colitti, Marcus Keane, Erik Kline, David Lamparter, Dusan Mudric, Erik Nordmark, and Dave Thaler.
感谢以下人员（按字母顺序）的审阅和反馈：米凯尔·亚伯拉罕松、洛伦佐·科利蒂、马库斯·基恩、埃里克·克莱恩、大卫·兰帕特、杜桑·穆德里克、埃里克·诺德马克和戴夫·泰勒。
Authors' Addresses
作者地址
Jen Linkova Google Mountain View, California 94043 United States of America
Jen Linkova谷歌山景，加利福尼亚94043美利坚合众国
Email: furry@google.com
Email: furry@google.com
Massimiliano Stucchi RIPE NCC Stationsplein, 11 Amsterdam 1012 AB The Netherlands
Massimiliano Stucchi成熟NCC站Plein，11阿姆斯特丹1012 AB荷兰
Email: mstucchi@ripe.net
Email: mstucchi@ripe.net