Independent Submission B. Sarikaya
Request for Comments: 8043 Huawei USA
Category: Informational M. Boucadair
ISSN: 2070-1721 Orange
January 2017
Independent Submission B. Sarikaya
Request for Comments: 8043 Huawei USA
Category: Informational M. Boucadair
ISSN: 2070-1721 Orange
January 2017
Source-Address-Dependent Routing and Source Address Selection for IPv6 Hosts: Overview of the Problem Space
IPv6主机的源地址相关路由和源地址选择：问题空间概述
Abstract
摘要
This document presents the source-address-dependent routing (SADR) problem space from the host's perspective. Both multihomed hosts and hosts with multiple interfaces are considered. Several network architectures are presented to illustrate why source address selection and next-hop resolution are needed in view of source-address-dependent routing.
本文档从主机的角度介绍源地址相关路由（SADR）问题空间。同时考虑多宿主主机和具有多个接口的主机。本文介绍了几种网络结构，说明了在源地址依赖路由的情况下，为什么需要源地址选择和下一跳解析。
The document is scoped on identifying a set of scenarios for source-address-dependent routing from the host's perspective and analyzing a set of solutions to mitigate encountered issues. The document does not make any solution recommendations.
本文档的范围是从主机的角度确定源地址相关路由的一组场景，并分析一组解决方案以缓解遇到的问题。该文件没有提出任何解决方案建议。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
这是对RFC系列的贡献，独立于任何其他RFC流。RFC编辑器已选择自行发布此文档，并且未声明其对实现或部署的价值。RFC编辑批准发布的文件不适用于任何级别的互联网标准；见RFC 7841第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/rfc8043.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc8043.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Overall Context . . . . . . . . . . . . . . . . . . . . . 3
1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Source-Address-Dependent Routing (SADR) Scenarios . . . . . . 4
2.1. Multi-Prefix Multihoming . . . . . . . . . . . . . . . . 5
2.2. Multi-Prefix Multi-Interface . . . . . . . . . . . . . . 5
2.3. Home Network (Homenet) . . . . . . . . . . . . . . . . . 7
2.4. Service-Specific Egress Routing . . . . . . . . . . . . . 7
3. Analysis of Source-Address-Dependent Routing . . . . . . . . 8
3.1. Scenarios Analysis . . . . . . . . . . . . . . . . . . . 8
3.2. Provisioning Domains and SADR . . . . . . . . . . . . . . 10
4. Discussion of Alternate Solutions . . . . . . . . . . . . . . 11
4.1. Router Advertisement Option . . . . . . . . . . . . . . . 11
4.2. Router Advertisement Option Set . . . . . . . . . . . . . 12
4.3. Rule 5.5 for Source Address Selection . . . . . . . . . . 12
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1. Normative References . . . . . . . . . . . . . . . . . . 13
6.2. Informative References . . . . . . . . . . . . . . . . . 14
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Overall Context . . . . . . . . . . . . . . . . . . . . . 3
1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Source-Address-Dependent Routing (SADR) Scenarios . . . . . . 4
2.1. Multi-Prefix Multihoming . . . . . . . . . . . . . . . . 5
2.2. Multi-Prefix Multi-Interface . . . . . . . . . . . . . . 5
2.3. Home Network (Homenet) . . . . . . . . . . . . . . . . . 7
2.4. Service-Specific Egress Routing . . . . . . . . . . . . . 7
3. Analysis of Source-Address-Dependent Routing . . . . . . . . 8
3.1. Scenarios Analysis . . . . . . . . . . . . . . . . . . . 8
3.2. Provisioning Domains and SADR . . . . . . . . . . . . . . 10
4. Discussion of Alternate Solutions . . . . . . . . . . . . . . 11
4.1. Router Advertisement Option . . . . . . . . . . . . . . . 11
4.2. Router Advertisement Option Set . . . . . . . . . . . . . 12
4.3. Rule 5.5 for Source Address Selection . . . . . . . . . . 12
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1. Normative References . . . . . . . . . . . . . . . . . . 13
6.2. Informative References . . . . . . . . . . . . . . . . . 14
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
BCP 38 recommends ingress traffic filtering to prohibit Denial-of-Service (DoS) attacks. As such, datagrams with source addresses that do not match with the network where the host is attached are discarded [RFC2827]. Preventing packets from being dropped due to ingress filtering is difficult, especially in multihomed networks where the host receives more than one prefix from the networks it is connected to, and consequently may have more than one source address. Based on BCP 38, BCP 84 introduced recommendations on the routing system for multihomed networks [RFC3704].
BCP 38建议进行入口流量过滤，以禁止拒绝服务（DoS）攻击。因此，源地址与主机连接的网络不匹配的数据报将被丢弃[RFC2827]。防止由于入口过滤而丢弃数据包是困难的，特别是在多宿网络中，其中主机从其连接的网络接收到多个前缀，因此可能具有多个源地址。基于BCP 38，BCP 84介绍了关于多宿网络路由系统的建议[RFC3704]。
Recommendations on the routing system for ingress filtering such as in BCP 84 inevitably involve source address checks. This leads to source-address-dependent-routing (SADR). Source-address-dependent routing can be problematic, especially when the host is connected to a multihomed network and is communicating with another host in another multihomed network. In such a case, the communication can be broken in both directions if Network Providers apply ingress filtering and the datagrams contain the wrong source addresses (see [INGRESS_FIL] for more details).
关于诸如BCP 84中的入口过滤的路由系统的建议不可避免地涉及源地址检查。这将导致源地址相关路由（SADR）。源地址相关的路由可能会出现问题，尤其是当主机连接到多址网络并且正在与另一个多址网络中的另一台主机通信时。在这种情况下，如果网络提供商应用入口过滤，并且数据报包含错误的源地址，则通信可能在两个方向上中断（有关更多详细信息，请参阅[ingress_FIL]）。
Hosts with simultaneously active interfaces receive multiple prefixes and have multiple source addresses. Datagrams originating from such hosts are likely to be filtered due to ingress filtering policies. The source address selection algorithm needs to carefully avoid ingress filtering on the next-hop router [RFC6724].
同时具有活动接口的主机接收多个前缀并具有多个源地址。由于入口过滤策略，来自此类主机的数据报可能会被过滤。源地址选择算法需要小心避免下一跳路由器上的入口过滤[RFC6724]。
Many use cases have been reported for source/destination routing -- see [SD_RTG]. These use cases clearly indicate that the multihomed host or Customer Premises Equipment (CPE) router needs to be configured with the correct source prefixes/addresses so that it can forward packets upstream correctly to prevent the ingress filtering applied by an upstream Network Provider from dropping the packets.
对于源/目标路由，已经报告了许多用例——请参见[SD_RTG]。这些用例清楚地表明，多宿主机或客户场所设备（CPE）路由器需要配置正确的源前缀/地址，以便它能够正确地向上游转发数据包，以防止上游网络提供商应用的入口过滤丢弃数据包。
In multihomed networks, there is a need to enforce source-address-based routing if some providers are performing ingress filtering. This requires that the routers consider the source addresses as well as the destination addresses in determining the packet's next hop.
在多址网络中，如果某些提供商正在执行入口过滤，则需要强制实施基于源地址的路由。这要求路由器在确定分组的下一跳时考虑源地址以及目的地址。
Based on the use cases defined in [SD_RTG], the routers may be informed about the source addresses to use for forwarding using extensions to the routing protocols like IS-IS [ISO.10589.1992] [SD_RTG_ISIS], OSPF [RFC5340] [SD_RTG_OSPF].
基于[SD_RTG]中定义的用例，路由器可以被告知使用诸如IS-IS[ISO.10589.1992][SD_RTG_ISIS]、OSPF[RFC5340][SD_RTG_OSPF]等路由协议的扩展进行转发所使用的源地址。
In this document, we describe the scenarios for source-address-dependent routing from the host's perspective. Two flavors can be considered:
在本文中，我们从主机的角度描述了源地址相关路由的场景。可以考虑两种口味：
1. A host may have a single interface with multiple addresses (from different prefixes or /64s). Each prefix is delegated from different exit routers, and this case can be called "multihomed with multi-prefix" (MHMP). In such case, source address selection is performed by the host while source-dependent routing is enforced by an upstream router.
1. 一台主机可能有一个带有多个地址的接口（来自不同的前缀或/64）。每个前缀都由不同的出口路由器委派，这种情况可以称为“多前缀多宿”（MHMP）。在这种情况下，源地址选择由主机执行，而源依赖路由由上游路由器执行。
2. A host may have simultaneously connected multiple interfaces where each interface is connected to a different exit router, and this case can be called "multi-prefix multiple interface" (MPMI). For this case, the host is required to support both source address selection and source-dependent routing to avoid the need for an upstream router to rewrite the IPv6 prefix.
2. 主机可以同时连接多个接口，其中每个接口连接到不同的出口路由器，这种情况可以称为“多前缀多接口”（MPMI）。在这种情况下，主机需要同时支持源地址选择和源相关路由，以避免上游路由器重写IPv6前缀的需要。
Several limitations arise in multihoming contexts based on NAT and IPv6-to-IPv6 Network Prefix Translation (NPTv6) [RFC6296]; see, for example, [RFC4116]. NPTv6 is out of scope for this document.
基于NAT和IPv6-to-IPv6网络前缀转换（NPTv6）[RFC6296]的多主上下文中出现了一些限制；例如，参见[RFC4116]。NPTv6不在本文件的范围内。
This document was initially written to inform the community about the SADR problem space. It was updated to record the various sets of alternate solutions to address that problem space. The 6man WG consensus is documented in [RFC8028].
本文件最初编写的目的是向社区通报萨德尔问题空间。它已更新，以记录解决该问题空间的各种备选解决方案集。[RFC8028]中记录了6man工作组的共识。
This section describes a set of scenarios to illustrate the SADR problem. Scenarios are listed in order of increasing complexity.
本节描述了一组场景来说明SADR问题。场景按复杂性增加的顺序列出。
The scenario shown in Figure 1 is a multi-prefix multihoming use case. "rtr" is a CPE router that is connected to two Network Providers, each advertising its own prefixes. In this case, the host may have a single interface, but it receives multiple prefixes from the upstream Network Providers. Assuming that providers apply the ingress filtering policy, the packets for any external communication from the host should follow source-address-dependent routing in order to avoid getting dropped.
图1所示的场景是一个多前缀多归属用例。“rtr”是一个连接到两个网络提供商的CPE路由器，每个网络提供商都宣传自己的前缀。在这种情况下，主机可能只有一个接口，但它从上游网络提供商处接收多个前缀。假设提供者应用入口过滤策略，来自主机的任何外部通信的数据包应遵循源地址相关路由，以避免丢失。
In this scenario, the host does not need to perform source-dependent routing; it only needs to perform source address selection.
在这种情况下，主机不需要执行源相关路由；它只需要执行源地址选择。
+------+ |
| | | (Network)
| | |=====|(Provider 1)|=====
| | +------+ |
| | | | |
| |=====| rtr |=====|
| host | | | |
| | +------+ |
| | |
| | | (Network)
| | |=====|(Provider 2)|=====
| | |
+------+ |
+------+ |
| | | (Network)
| | |=====|(Provider 1)|=====
| | +------+ |
| | | | |
| |=====| rtr |=====|
| host | | | |
| | +------+ |
| | |
| | | (Network)
| | |=====|(Provider 2)|=====
| | |
+------+ |
Figure 1: Multihomed Host with Multiple CPE Routers
图1：具有多个CPE路由器的多主机主机
The scenario shown in Figure 2 is multi-prefix multi-interface, where "rtr1" and "rtr2" represent CPE routers and there are exit routers in both "network 1" and "network 2". If the packets from the host communicating with a remote destination are routed to the wrong exit router, i.e., they carry the wrong source address, they will get dropped due to ingress filtering.
图2所示的场景是多前缀多接口，其中“rtr1”和“rtr2”表示CPE路由器，“网络1”和“网络2”中都有出口路由器。如果来自与远程目的地通信的主机的数据包被路由到错误的出口路由器，即它们携带错误的源地址，它们将由于入口过滤而被丢弃。
In order to avoid complications when sending packets and to avoid the need to rewrite the source IPv6 prefix, the host is required to perform both source address selection and source-dependent routing so that the appropriate next hop is selected while taking into account the source address.
为了避免发送数据包时的复杂性，并避免重写源IPv6前缀的需要，主机需要执行源地址选择和源相关路由，以便在考虑源地址的同时选择适当的下一跳。
+------+ +------+ ___________
| | | | / \
| |-----| rtr1 |=====/ network \
| | | | \ 1 /
| | +------+ \___________/
| |
| host |
| |
| | +------+ ___________
| | | | / \
| |=====| rtr2 |=====/ network \
| | | | \ 2 /
+------+ +------+ \___________/
+------+ +------+ ___________
| | | | / \
| |-----| rtr1 |=====/ network \
| | | | \ 1 /
| | +------+ \___________/
| |
| host |
| |
| | +------+ ___________
| | | | / \
| |=====| rtr2 |=====/ network \
| | | | \ 2 /
+------+ +------+ \___________/
Figure 2: Multiple Interfaced Host with Two CPE Routers
图2：具有两个CPE路由器的多接口主机
There is a variant of Figure 2 that is often referred to as a corporate VPN, i.e., a secure tunnel from the host to a router attached to a corporate network. In this case, "rtr2" provides access directly to the corporate network, and the link from the host to "rtr2" is a secure tunnel (for example, an IPsec tunnel). Therefore, the interface is a virtual interface with its own IP address/prefix assigned by the corporate network.
图2的一个变体通常被称为企业VPN，即从主机到连接到企业网络的路由器的安全隧道。在这种情况下，“rtr2”直接提供对公司网络的访问，从主机到“rtr2”的链接是一个安全隧道（例如，IPsec隧道）。因此，该接口是一个虚拟接口，其IP地址/前缀由公司网络分配。
+------+ +------+ ___________
| |-----| rtr1 | / \
| ==========\\ |=====/ network \
| |-----| || | \ 1 /
| | +--||--+ \___________/
| | ||
| host | ||
| | ||
| | +--||--+ ___________
| | | | / corporate \
| | | rtr2 |=====/ network \
| | | | \ 2 /
+------+ +------+ \___________/
+------+ +------+ ___________
| |-----| rtr1 | / \
| ==========\\ |=====/ network \
| |-----| || | \ 1 /
| | +--||--+ \___________/
| | ||
| host | ||
| | ||
| | +--||--+ ___________
| | | | / corporate \
| | | rtr2 |=====/ network \
| | | | \ 2 /
+------+ +------+ \___________/
Figure 3: VPN Case
图3:VPN案例
There are at least two sub-cases:
至少有两个子案例：
a. Dedicated forwarding entries are created in the host such that only traffic directed to the corporate network is sent to "rtr2"; everything else is sent to "rtr1".
a. 在主机中创建专用转发条目，以便仅将定向到公司网络的流量发送到“rtr2”；其他所有内容都发送到“rtr1”。
b. All traffic is sent to "rtr2" and then routed to the Internet if necessary. This case doesn't need host routes but leads to unnecessary traffic and latency because of the path stretch via "rtr2".
b. 所有流量都发送到“rtr2”，然后在必要时路由到Internet。这种情况不需要主机路由，但由于通过“rtr2”的路径拉伸，会导致不必要的流量和延迟。
In the homenet scenario depicted in Figure 4, representing a simple home network, there is a host connected to a local network that is serviced with two CPEs that are connected to Providers 1 and 2, respectively. Each network delegates a different prefix. Also, each router provides a different prefix to the host. The issue in this scenario is that ingress filtering is used by each provider. This scenario can be considered as a variation of the scenario described in Section 2.2.
在图4所示的家庭网络场景中，代表一个简单的家庭网络，有一台主机连接到一个本地网络，该网络由两个分别连接到提供商1和提供商2的CPE提供服务。每个网络代表不同的前缀。此外，每个路由器为主机提供不同的前缀。此场景中的问题是每个提供者都使用入口过滤。这种情况可视为第2.2节所述情况的一种变化。
+------+
| | +------+
| | | | (Network)
| |==+==| rtr1 |====|(Provider 1)|=====
| | | | |
| | | +------+
| host | |
| | |
| | | +------+
| | | | | (Network)
| | +==| rtr2 |====|(Provider 2)|=====
| | | |
+------+ +------+
+------+
| | +------+
| | | | (Network)
| |==+==| rtr1 |====|(Provider 1)|=====
| | | | |
| | | +------+
| host | |
| | |
| | | +------+
| | | | | (Network)
| | +==| rtr2 |====|(Provider 2)|=====
| | | |
+------+ +------+
Figure 4: Simple Home Network with Two CPE Routers
图4：带有两个CPE路由器的简单家庭网络
The host has to select the source address from the prefixes of Providers 1 or 2 when communicating with other hosts in Provider 1 or 2. The next issue is to select the correct next-hop router, "rtr1" or "rtr2" that can reach the correct provider, Network Provider 1 or 2.
在与提供程序1或2中的其他主机通信时，主机必须从提供程序1或2的前缀中选择源地址。下一个问题是选择正确的下一跳路由器、“rtr1”或“rtr2”，它们可以到达正确的提供商，即网络提供商1或2。
A variation of the scenario in Section 2.1 is specialized egress routing. Upstream networks offer different services with specific requirements, e.g., Voice over IP (VoIP) or IPTV. The hosts using this service need to use the service's source and destination addresses. No other service will accept this source address, i.e., those packets will be dropped [SD_RTG].
第2.1节中场景的一个变体是专用出口路由。上游网络提供具有特定要求的不同服务，例如IP语音（VoIP）或IPTV。使用此服务的主机需要使用该服务的源地址和目标地址。没有其他服务将接受此源地址，即，这些数据包将被丢弃[SD_RTG]。
Both source address selection and source-dependent routing are required to be performed by the host.
源地址选择和源相关路由都需要由主机执行。
___________ +------+
/ \ +------+ | |
/ network \ | | | |
\ 1 /--| rtr1 |----| |
\___________/ | | | | +------+ ___________
+------+ | host | | | / \
| |=====| rtr3 |=====/ network \
___________ | | | | \ 3 /
/ \ +------+ | | +------+ \___________/
/ network \ | | | |
\ 2 /--| rtr2 |----| |
\___________/ | | | |
+------+ | |
+------+
___________ +------+
/ \ +------+ | |
/ network \ | | | |
\ 1 /--| rtr1 |----| |
\___________/ | | | | +------+ ___________
+------+ | host | | | / \
| |=====| rtr3 |=====/ network \
___________ | | | | \ 3 /
/ \ +------+ | | +------+ \___________/
/ network \ | | | |
\ 2 /--| rtr2 |----| |
\___________/ | | | |
+------+ | |
+------+
Figure 5: Multi-Interfaced Host with Three CPE Routers
图5：具有三个CPE路由器的多接口主机
The scenario shown in Figure 5 is a variation of a multi-prefix multi-interface scenario (Section 2.2). "rtr1", "rtr2", and "rtr3" are CPE routers. The networks apply ingress routing. Source-address-dependent routing should be used to avoid dropping any external communications.
图5所示的场景是多前缀多接口场景的变体（第2.2节）。“rtr1”、“rtr2”和“rtr3”是CPE路由器。网络采用入口路由。应使用源地址相关路由，以避免中断任何外部通信。
SADR can be facilitated at the host with proper source address and next-hop selection. For this, each router connected to different interfaces of the host uses Router Advertisements (RAs) [RFC4861] to distribute a default route, the next hop, and the source address/ prefix information to the host. As a reminder, while the Prefix Information Option (PIO) is defined in [RFC4861], the Route Information Option (RIO) is defined in [RFC4191].
通过正确的源地址和下一跳选择，可以在主机上促进SADR。为此，连接到主机不同接口的每个路由器使用路由器广告（RAs）[RFC4861]向主机分发默认路由、下一跳和源地址/前缀信息。作为提醒，虽然[RFC4861]中定义了前缀信息选项（PIO），但[RFC4191]中定义了路由信息选项（RIO）。
Section 3.1 presents an analysis of the scenarios in Section 2, and Section 3.2 discusses the relevance of SADR to the provisioning domains.
第3.1节对第2节中的场景进行了分析，第3.2节讨论了SADR与供应域的相关性。
As in [RFC7157], we assume that the routers in Section 2 use RAs to distribute default route and source address prefixes supported in each next hop to the hosts or that the gateway/CPE router relays this information to the hosts.
与[RFC7157]一样，我们假设第2节中的路由器使用RAs将每个下一跳中支持的默认路由和源地址前缀分发到主机，或者网关/CPE路由器将此信息中继到主机。
Referring to Section 2.1, source address selection is undertaken by the host while source-dependent routing must be followed by "rtr" to avoid packets being dropped. No particular modification is required for next-hop selection at the host.
参考第2.1节，源地址选择由主机进行，而源相关路由必须紧跟“rtr”，以避免数据包被丢弃。主机上的下一跳选择不需要进行特殊修改。
Referring to the scenario in Figure 2, source-address-dependent routing can present a solution to the problem of when the host wishes to reach a destination in network 2 and the host chooses "rtr1" as the default router. The solution assumes that the host is correctly configured. The host should be configured with the prefixes supported in these next hops. This way the host, having received many prefixes, will have the correct information for selecting the right source address and next hop when sending packets to remote destinations.
参考图2中的场景，源地址相关路由可以为主机希望到达网络2中的目的地并且主机选择“rtr1”作为默认路由器的问题提供解决方案。该解决方案假定主机已正确配置。应使用这些下一个跃点中支持的前缀配置主机。这样，接收到许多前缀的主机在向远程目的地发送数据包时，将具有选择正确源地址和下一跳的正确信息。
Note that similar considerations apply to the scenario in Figure 5.
注意，类似的注意事项适用于图5中的场景。
In the configuration of the scenario (Figure 1), it is also useful to configure the host with the prefixes and source address prefixes they support. This will enable the host to select the right prefix when sending packets to the right next hop and avoid any issues with ingress filtering.
在场景的配置中（图1），使用它们支持的前缀和源地址前缀配置主机也很有用。这将使主机在向正确的下一跳发送数据包时能够选择正确的前缀，并避免任何入口过滤问题。
Let us analyze the scenario in Section 2.3. If a source-address-dependent routing protocol is used, the two routers ("rtr1" and "rtr2") are both able to route traffic correctly, no matter which next-hop router and source address the host selects. In case the host chooses the wrong next-hop router, e.g., "rtr1" is selected for Provider 2, "rtr1" will forward the traffic to "rtr2" to be sent to Network Provider 2 and no ingress filtering will happen.
让我们分析第2.3节中的场景。如果使用源地址相关的路由协议，则无论主机选择哪个下一跳路由器和源地址，这两个路由器（“rtr1”和“rtr2”）都能够正确路由流量。如果主机选择了错误的下一跳路由器，例如，为提供商2选择了“rtr1”，则“rtr1”会将流量转发到“rtr2”以发送到网络提供商2，并且不会发生入口过滤。
Note that home networks are expected to comply with requirements for source-address-dependent routing and that the routers will be configured accordingly no matter which routing protocol is used [RFC7788].
请注意，家庭网络应符合源地址相关路由的要求，并且无论使用何种路由协议，路由器都将进行相应配置[RFC7788]。
This would work, but with some issues. The host traffic to Provider 2 will have to go over two links instead of one, i.e., the link bandwidth will be halved. Another possibility is that "rtr1" can send an ICMPv6 Redirect message to the host to direct the traffic to "rtr2". The host would then redirect Provider 2 traffic to "rtr2".
这是可行的，但有一些问题。到提供商2的主机流量必须通过两条链路而不是一条链路，即链路带宽将减半。另一种可能性是“rtr1”可以向主机发送ICMPv6重定向消息，将通信量定向到“rtr2”。然后主机将提供程序2通信重定向到“rtr2”。
The problem with redirects is that the ICMPv6 Redirect message can only convey two addresses, i.e., in this case the router address, or "rtr2" address and the destination address, or the destination host in Provider 2. That means that the source address will not be communicated. As a result, the host would send packets to the same destination using both source addresses, which causes "rtr2" to send
重定向的问题是，ICMPv6重定向消息只能传送两个地址，即在本例中，路由器地址或“rtr2”地址和目标地址，或提供程序2中的目标主机。这意味着源地址将无法通信。因此，主机将使用两个源地址向同一目的地发送数据包，从而导致“rtr2”发送数据包
a redirect message to "rtr1", resulting in ping-pong redirects sent by "rtr1" and "rtr2".
将消息重定向到“rtr1”，导致“rtr1”和“rtr2”发送乒乓重定向。
A solution to these issues is to configure the host with the source address prefixes that the next hop supports. In a homenet context, each interface of the host can be configured by its next-hop router, so that all that is needed is to add the information about source address prefixes. This results in the hosts selecting the right router, no matter what.
这些问题的解决方案是使用下一跳支持的源地址前缀配置主机。在homenet上下文中，主机的每个接口都可以由其下一跳路由器进行配置，因此只需添加有关源地址前缀的信息。这将导致主机选择正确的路由器，无论发生什么情况。
Source-address-dependent routing in the use case of specialized egress routing (Section 2.4) may work as follows. The specialized service router advertises one or more specific prefixes with appropriate source prefixes, e.g., to the CPE router, "rtr" in Figure 1. The CPE router in turn advertises the specific service's prefixes and source prefixes to the host. This will allow proper configuration at the host so that the host can use the service by sending the packets with the correct source and destination addresses.
专用出口路由（第2.4节）用例中的源地址相关路由可按如下方式工作。专用服务路由器用适当的源前缀播发一个或多个特定前缀，例如，向图1中的CPE路由器“rtr”。CPE路由器依次向主机播发特定服务的前缀和源前缀。这将允许在主机上进行适当配置，以便主机可以通过发送具有正确源地址和目标地址的数据包来使用服务。
A consistent set of network configuration information is called a provisioning domain (PvD). In the case of multihomed with multi-prefix (MHMP), more than one provisioning domain is present on a single link. In the case of multi-prefix multiple interface (MPMI) environments, elements of the same domain may be present on multiple links. PvD-aware nodes support association of configuration information into PvDs and use these PvDs to serve requests for network connections, e.g., choosing the right source address for the packets. PvDs can be constructed from one of more DHCP or Router Advertisement (RA) options carrying such information as PvD identity and PvD container [MPvD_NDP] [MPvD_DHCP]. PvDs constructed based on such information are called explicit PvDs [RFC7556].
一组一致的网络配置信息称为配置域（PvD）。在多址多前缀（MHMP）的情况下，单个链路上存在多个供应域。在多前缀多接口（MPMI）环境中，同一域的元素可能存在于多个链路上。支持PvD的节点支持将配置信息关联到PvD中，并使用这些PvD为网络连接请求提供服务，例如，为数据包选择正确的源地址。PvD可以由一个或多个DHCP或路由器广告（RA）选项构成，其中包含PvD标识和PvD容器[MPvD_NDP][MPvD_DHCP]等信息。基于此类信息构建的PVD称为显式PVD[RFC7556]。
Apart from PvD identity, PvD content may be encapsulated in separate RA or DHCP options called the PvD Container Option. These options are placed in the container options of an explicit PvD.
除了PvD标识，PvD内容还可以封装在单独的RA或DHCP选项中，称为PvD容器选项。这些选项放置在显式PvD的容器选项中。
Explicit PvDs may be received from different interfaces. A single PvD may be accessible over one interface or simultaneously accessible over multiple interfaces. Explicit PvDs may be scoped to a configuration related to a particular interface; however, in general, this does not apply. What matters is that the PvD identity is authenticated by the node even in cases where the node has a single connected interface. The authentication of the PvD ID should meet the level required by the node policy. Single PvD information may be received over multiple interfaces as long as the PvD ID is the same.
可从不同接口接收明确的PVD。单个PvD可以通过一个接口访问，也可以通过多个接口同时访问。显式PVD的范围可限定为与特定接口相关的配置；然而，一般来说，这并不适用。重要的是，即使在节点具有单个连接接口的情况下，PvD标识也由节点进行身份验证。PvD ID的身份验证应满足节点策略要求的级别。只要PvD ID相同，可以通过多个接口接收单个PvD信息。
This applies to the Router Advertisements (RAs) in which case a multihomed host (that is, with multiple interfaces) should trust a message from a router on one interface to install a route to a different router on another interface.
这适用于路由器广告（RAs），在这种情况下，多宿主主机（即具有多个接口）应信任一个接口上的路由器发送的消息，以将路由安装到另一个接口上的不同路由器。
We presented many topologies in which a host with multiple interfaces or a multihomed host is connected to various networks or Network Providers, which in turn may apply ingress routing. The scenario analysis in Section 3.1 shows that in order to prevent packets from being dropped due to ingress routing, source-address-dependent routing is needed. Also, source-address-dependent routing should be supported by routers throughout a site that has multiple egress points.
我们提出了许多拓扑结构，其中具有多个接口的主机或多宿主主机连接到各种网络或网络提供商，而这些网络或网络提供商又可以应用入口路由。第3.1节中的场景分析表明，为了防止由于入口路由而丢弃数据包，需要源地址相关路由。此外，具有多个出口点的站点中的路由器应支持源地址相关路由。
In this section, we provide some alternate solutions vis-a-vis the scenarios presented in Section 2. We start with Rule 5.5 in [RFC6724] for source address selection and the scenarios it solves, and then continue with solutions that state exactly what information hosts need in terms of new Router Advertisement options for correct source address selection in those scenarios. No recommendation is made in this section.
在本节中，我们针对第2节中介绍的场景提供了一些替代解决方案。我们从[RFC6724]中关于源地址选择及其解决方案的规则5.5开始，然后继续介绍解决方案，该解决方案准确说明主机在这些方案中正确选择源地址所需的新路由器播发选项方面的信息。本节未提出建议。
There is a need to configure the host not only with the prefixes, but also with the source prefixes that the next-hop routers support. Such a configuration may prevent the host from getting ingress/egress policy error messages such as ICMP source address failure messages.
不仅需要使用前缀配置主机，还需要使用下一跳路由器支持的源前缀配置主机。这样的配置可以防止主机获取入口/出口策略错误消息，例如ICMP源地址失败消息。
If host configuration is done using Router Advertisement messages, then there is a need to define new Router Advertisement options for source-address-dependent routing. These options include the Route Prefix with Source Address/Prefix Option. Other options such as the Next-Hop Address with the Route Prefix Option and the Next-Hop Address with the Source Address and Route Prefix Option will be considered in Section 4.2.
如果主机配置是使用路由器播发消息完成的，则需要为源地址相关路由定义新的路由器播发选项。这些选项包括带有源地址/前缀的路由前缀选项。第4.2节将考虑其他选项，如带有路由前缀选项的下一跳地址以及带有源地址和路由前缀选项的下一跳地址。
As discussed in Section 3.1, the scenario in Figure 4 can be solved by defining a new Router Advertisement option.
如第3.1节所述，图4中的场景可以通过定义一个新的路由器广告选项来解决。
If host configuration is done using DHCP, then there is a need to define new DHCP options for Route Prefix with Source Address/Prefix. As mentioned above, DHCP server configuration is interface specific. New DHCP options for source-address-dependent routing such as route prefix and source prefix need to be configured separately for each interface.
如果主机配置是使用DHCP完成的，则需要为具有源地址/前缀的路由前缀定义新的DHCP选项。如上所述，DHCP服务器配置是特定于接口的。需要为每个接口分别配置源地址相关路由的新DHCP选项，例如路由前缀和源前缀。
The scenario in Figure 4 can be solved by defining a new DHCP option.
图4中的场景可以通过定义一个新的DHCP选项来解决。
Rule 5.5 for source address selection may be a solution for selecting the right source addresses for each next hop, but there are cases where the next-hop routers on each interface of the host are not known by the host initially. Such use cases are out of scope. Guidelines for use cases that require the Router Advertisement option set involving third-party next-hop addresses are also out of scope.
源地址选择规则5.5可能是为每个下一跳选择正确源地址的解决方案，但在某些情况下，主机的每个接口上的下一跳路由器最初不为主机所知。这样的用例超出了范围。对于需要路由器广告选项集（涉及第三方下一跳地址）的用例的指南也不在范围之内。
One possible solution is Rule 5.5 in [RFC6724], the default rule for source address selection, which recommends selecting the source addresses advertised by the next hop. Considering the above scenarios, we can state that this rule can solve the problem in Figures 1, 2, and 5.
一个可能的解决方案是[RFC6724]中的规则5.5，这是源地址选择的默认规则，它建议选择下一跳播发的源地址。考虑到上述场景，我们可以说明此规则可以解决图1、2和5中的问题。
Source address selection rules can be distributed by the DHCP server using the DHCP option OPTION_ADDRSEL_TABLE defined in [RFC7078].
DHCP服务器可以使用[RFC7078]中定义的DHCP选项\u ADDRSEL_表分发源地址选择规则。
In case of DHCP-based host configuration, the DHCP server can configure only the interface of the host to which it is directly connected. In order for Rule 5.5 to apply on other interfaces, the option should be sent on those interfaces as well using the DHCPv6 address selection policy option defined in [RFC7078].
在基于DHCP的主机配置的情况下，DHCP服务器只能配置其直接连接的主机的接口。为了使规则5.5适用于其他接口，还应使用[RFC7078]中定义的DHCPv6地址选择策略选项在这些接口上发送该选项。
Rule 5.5, the default rule for source address selection, solves that problem when an application sends a packet with an unspecified source address. In the presence of two default routes, one route will be chosen, and Rule 5.5 will make sure that the right source address is used.
规则5.5是源地址选择的默认规则，它解决了应用程序发送带有未指定源地址的数据包时的问题。在存在两个默认路由的情况下，将选择一个路由，规则5.5将确保使用正确的源地址。
When the application selects a source address, i.e., the source address is chosen before next-hop selection, even though the source address is a way for the application to select the exit point, in this case, that purpose will not be served. In the presence of multiple default routes, one will be picked, ignoring the source address that was selected by the application because it is known that IPv6 implementations are not required to remember which next hops advertised which prefixes. Therefore, the next-hop router may not be the correct one, and the packets may be filtered.
当应用程序选择源地址时，即，在选择下一跳之前选择源地址，即使源地址是应用程序选择出口点的一种方式，在这种情况下，该目的将不起作用。在存在多个默认路由的情况下，将选择一个路由，忽略应用程序选择的源地址，因为众所周知，IPv6实现不需要记住哪些下一个跃点播发哪些前缀。因此，下一跳路由器可能不是正确的路由器，并且分组可能被过滤。
This implies that the hosts should register which next-hop router announced each prefix. It is required that RAs be sent by the routers and that they contain PIO on all links. It is also required that the hosts remember the source addresses of the routers that sent
这意味着主机应该注册哪个下一跳路由器宣布了每个前缀。要求路由器发送RAs，并在所有链路上包含PIO。还要求主机记住发送的路由器的源地址
PIOs together with the prefixes advertised. This can be achieved by updating redirect rules specified in [RFC4861]. [RFC8028] further elaborates this to specify to which router a host should present its transmission.
PIO以及广告中的前缀。这可以通过更新[RFC4861]中指定的重定向规则来实现。[RFC8028]进一步阐述了这一点，以指定主机应向哪个路由器呈现其传输。
The source-address-dependent routing solution is not complete without support from the edge routers. All routers in edge networks need to be required to support routing based on not only the destination address but also the source address. All edge routers need to be required to satisfy filters as defined in BCP 38.
如果没有边缘路由器的支持，源地址相关路由解决方案是不完整的。边缘网络中的所有路由器都需要支持基于目标地址和源地址的路由。所有边缘路由器都需要满足BCP 38中定义的过滤器。
This document describes some use cases, and thus brings no additional security risks. Solution documents should further elaborate on specific security considerations.
本文档描述了一些用例，因此不会带来额外的安全风险。解决方案文件应进一步详细说明具体的安全注意事项。
[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, <http://www.rfc-editor.org/info/rfc2827>.
[RFC2827]Ferguson，P.和D.Senie，“网络入口过滤：击败利用IP源地址欺骗的拒绝服务攻击”，BCP 38，RFC 2827，DOI 10.17487/RFC2827，2000年5月<http://www.rfc-editor.org/info/rfc2827>.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March 2004, <http://www.rfc-editor.org/info/rfc3704>.
[RFC3704]Baker，F.和P.Savola，“多宿网络的入口过滤”，BCP 84，RFC 3704，DOI 10.17487/RFC3704，2004年3月<http://www.rfc-editor.org/info/rfc3704>.
[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, <http://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月<http://www.rfc-editor.org/info/rfc4861>.
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, <http://www.rfc-editor.org/info/rfc5340>.
[RFC5340]Coltun，R.，Ferguson，D.，Moy，J.，和A.Lindem，“IPv6的OSPF”，RFC 5340，DOI 10.17487/RFC5340，2008年7月<http://www.rfc-editor.org/info/rfc5340>.
[RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011, <http://www.rfc-editor.org/info/rfc6296>.
[RFC6296]Wasserman，M.和F.Baker，“IPv6到IPv6网络前缀转换”，RFC 6296DOI 10.17487/RFC62962011年6月<http://www.rfc-editor.org/info/rfc6296>.
[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, <http://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月<http://www.rfc-editor.org/info/rfc6724>.
[RFC7078] Matsumoto, A., Fujisaki, T., and T. Chown, "Distributing Address Selection Policy Using DHCPv6", RFC 7078, DOI 10.17487/RFC7078, January 2014, <http://www.rfc-editor.org/info/rfc7078>.
[RFC7078]Matsumoto，A.，Fujisaki，T.，和T.Chown，“使用DHCPv6分发地址选择策略”，RFC 7078，DOI 10.17487/RFC7078，2014年1月<http://www.rfc-editor.org/info/rfc7078>.
[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, <http://www.rfc-editor.org/info/rfc8028>.
[RFC8028]Baker，F.和B.Carpenter，“多前缀网络中主机的第一跳路由器选择”，RFC 8028，DOI 10.17487/RFC8028，2016年11月<http://www.rfc-editor.org/info/rfc8028>.
[INGRESS_FIL] Huitema, C., Draves, R., and M. Bagnulo, "Ingress filtering compatibility for IPv6 multihomed sites", Work in Progress, draft-huitema-multi6-ingress-filtering-00, October 2004.
[INGRESS_FIL]Huitema，C.，Draves，R.，和M.Bagnulo，“IPv6多宿主站点的入口过滤兼容性”，正在进行的工作，draft-Huitema-multi6-INGRESS-filtering-00，2004年10月。
[ISO.10589.1992] International Organization for Standardization, "Intermediate system to intermediate system intra-domain-routing routine information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode Network Service (ISO 8473), ISO Standard 10589", ISO ISO.10589.1992, 1992.
[ISO.10589.1992]国际标准化组织，“与提供无连接模式网络服务的协议一起使用的中间系统到中间系统域内路由例程信息交换协议（ISO 8473），ISO标准10589”，ISO ISO.10589.1992，1992年。
[MPvD_DHCP] Krishnan, S., Korhonen, J., and S. Bhandari, "Support for multiple provisioning domains in DHCPv6", Work in Progress, draft-ietf-mif-mpvd-dhcp-support-02, October 2015.
[MPvD_DHCP]Krishnan，S.，Korhonen，J.，和S.Bhandari，“支持DHCPv6中的多个供应域”，正在进行的工作，草稿-ietf-mif-MPvD-DHCP-Support-022015年10月。
[MPvD_NDP] Korhonen, J., Krishnan, S., and S. Gundavelli, "Support for multiple provisioning domains in IPv6 Neighbor Discovery Protocol", Work in Progress, draft-ietf-mif-mpvd-ndp-support-03, February 2016.
[MPvD_NDP]Korhonen，J.，Krishnan，S.，和S.Gundavelli，“支持IPv6邻居发现协议中的多个供应域”，正在进行的工作，草稿-ietf-mif-MPvD-NDP-Support-032016年2月。
[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, <http://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月<http://www.rfc-editor.org/info/rfc4116>.
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, November 2005, <http://www.rfc-editor.org/info/rfc4191>.
[RFC4191]Draves，R.and D.Thaler，“默认路由器首选项和更具体的路由”，RFC 4191，DOI 10.17487/RFC4191，2005年11月<http://www.rfc-editor.org/info/rfc4191>.
[RFC7157] Troan, O., Ed., Miles, D., Matsushima, S., Okimoto, T., and D. Wing, "IPv6 Multihoming without Network Address Translation", RFC 7157, DOI 10.17487/RFC7157, March 2014, <http://www.rfc-editor.org/info/rfc7157>.
[RFC7157]Troan，O.，Ed.，Miles，D.，Matsushima，S.，Okimoto，T.，和D.Wing，“无网络地址转换的IPv6多宿主”，RFC 7157，DOI 10.17487/RFC7157，2014年3月<http://www.rfc-editor.org/info/rfc7157>.
[RFC7556] Anipko, D., Ed., "Multiple Provisioning Domain Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015, <http://www.rfc-editor.org/info/rfc7556>.
[RFC7556]Anipko，D.，编辑，“多供应域体系结构”，RFC 7556，DOI 10.17487/RFC7556，2015年6月<http://www.rfc-editor.org/info/rfc7556>.
[RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April 2016, <http://www.rfc-editor.org/info/rfc7788>.
[RFC7788]Stenberg，M.，Barth，S.，和P.Pfister，“家庭网络控制协议”，RFC 7788，DOI 10.17487/RFC7788，2016年4月<http://www.rfc-editor.org/info/rfc7788>.
[SD_RTG] Baker, F., Xu, M., Yang, S., and J. Wu, "Requirements and Use Cases for Source/Destination Routing", Work in Progress, draft-baker-rtgwg-src-dst-routing-use-cases-02, April 2016.
[SD_RTG]Baker，F.，Xu，M.，Yang，S.，和J.Wu，“源/目的路由的需求和用例”，正在进行的工作，草稿-Baker-rtgwg-src-dst-Routing-Use-Cases-022016年4月。
[SD_RTG_ISIS] Baker, F. and D. Lamparter, "IPv6 Source/Destination Routing using IS-IS", Work in Progress, draft-baker-ipv6- isis-dst-src-routing-06, October 2016.
[SD_RTG_ISIS]Baker，F.和D.Lamparter，“使用IS-IS的IPv6源/目标路由”，正在进行的工作，草稿-Baker-IPv6-ISIS-dst-src-Routing-062016年10月。
[SD_RTG_OSPF] Baker, F., "IPv6 Source/Destination Routing using OSPFv3", Work in Progress, draft-baker-ipv6-ospf-dst-src-routing-03, August 2013.
[SD_RTG_OSPF]Baker，F.，“使用OSPFv3的IPv6源/目标路由”，正在进行的工作，草稿-Baker-IPv6-OSPF-dst-src-Routing-032013年8月。
Acknowledgements
致谢
In writing this document, we benefited from the ideas expressed by the electronic mail discussion participants on 6man Working Group: Brian Carpenter, Ole Troan, Pierre Pfister, Alex Petrescu, Ray Hunter, Lorenzo Colitti, and others.
在撰写本文件时，我们受益于6man工作组电子邮件讨论参与者表达的想法：Brian Carpenter、Ole Troan、Pierre Pfister、Alex Petrescu、Ray Hunter、Lorenzo Colliti和其他人。
Pierre Pfister proposed the scenario in Figure 4 as well as some text for Rule 5.5.
皮埃尔·普菲斯特（Pierre Pfister）在图4中提出了该情景，并为规则5.5提供了一些文本。
The text on corporate VPN in Section 2 was provided by Brian Carpenter.
第2节中关于企业VPN的文本由Brian Carpenter提供。
Authors' Addresses
作者地址
Behcet Sarikaya Huawei USA 5340 Legacy Dr. Building 175 Plano, TX 75024 United States of America
Behcet Sarikaya Huawei USA 5340 Legacy Dr.Building 175 Plano，TX 75024美利坚合众国
Email: sarikaya@ieee.org
Email: sarikaya@ieee.org
Mohamed Boucadair Orange Rennes 35000 France
穆罕默德·布卡代尔·奥兰治·雷恩35000法国
Email: mohamed.boucadair@orange.com
Email: mohamed.boucadair@orange.com