Internet Engineering Task Force (IETF) F. Baker
Request for Comments: 8028
Updates: 4861 B. Carpenter
Category: Standards Track Univ. of Auckland
ISSN: 2070-1721 November 2016
Internet Engineering Task Force (IETF) F. Baker
Request for Comments: 8028
Updates: 4861 B. Carpenter
Category: Standards Track Univ. of Auckland
ISSN: 2070-1721 November 2016
First-Hop Router Selection by Hosts in a Multi-Prefix Network
多前缀网络中主机的第一跳路由器选择
Abstract
摘要
This document describes expected IPv6 host behavior in a scenario that has more than one prefix, each allocated by an upstream network that is assumed to implement BCP 38 ingress filtering, when the host has multiple routers to choose from. It also applies to other scenarios such as the usage of stateful firewalls that effectively act as address-based filters. Host behavior in choosing a first-hop router may interact with source address selection in a given implementation. However, the selection of the source address for a packet is done before the first-hop router for that packet is chosen. Given that the network or host is, or appears to be, multihomed with multiple provider-allocated addresses, that the host has elected to use a source address in a given prefix, and that some but not all neighboring routers are advertising that prefix in their Router Advertisement Prefix Information Options, this document specifies to which router a host should present its transmission. It updates RFC 4861.
本文档描述了当主机有多个路由器可供选择时，具有多个前缀（每个前缀由假定实施BCP 38入口过滤的上游网络分配）的场景中的预期IPv6主机行为。它还适用于其他场景，例如使用有效充当基于地址的过滤器的有状态防火墙。在给定的实现中，选择第一跳路由器的主机行为可能与源地址选择交互。然而，在选择分组的第一跳路由器之前，完成分组的源地址的选择。假设网络或主机是或似乎是多址的，具有多个提供商分配的地址，主机已选择在给定前缀中使用源地址，并且一些但不是所有相邻路由器正在其路由器广告前缀信息选项中广告该前缀，本文档指定主机应向哪个路由器显示其传输。它更新了RFC4861。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
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). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（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 http://www.rfc-editor.org/info/rfc8028.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc8028.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 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许可证中所述的无担保。
Table of Contents
目录
1. Introduction and Applicability . . . . . . . . . . . . . . . 3
1.1. Host Model . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. Sending Context Expected by the Host . . . . . . . . . . . . 5
2.1. Expectations the Host Has of the Network . . . . . . . . 5
2.2. Expectations of Multihomed Networks . . . . . . . . . . . 7
3. Reasonable Expectations of the Host . . . . . . . . . . . . . 7
3.1. Interpreting Router Advertisements . . . . . . . . . . . 7
3.2. Default Router Selection . . . . . . . . . . . . . . . . 9
3.3. Source Address Selection . . . . . . . . . . . . . . . . 9
3.4. Redirects . . . . . . . . . . . . . . . . . . . . . . . . 9
3.5. History . . . . . . . . . . . . . . . . . . . . . . . . . 10
4. Residual Issues . . . . . . . . . . . . . . . . . . . . . . . 10
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1. Normative References . . . . . . . . . . . . . . . . . . 11
7.2. Informative References . . . . . . . . . . . . . . . . . 12
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction and Applicability . . . . . . . . . . . . . . . 3
1.1. Host Model . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. Sending Context Expected by the Host . . . . . . . . . . . . 5
2.1. Expectations the Host Has of the Network . . . . . . . . 5
2.2. Expectations of Multihomed Networks . . . . . . . . . . . 7
3. Reasonable Expectations of the Host . . . . . . . . . . . . . 7
3.1. Interpreting Router Advertisements . . . . . . . . . . . 7
3.2. Default Router Selection . . . . . . . . . . . . . . . . 9
3.3. Source Address Selection . . . . . . . . . . . . . . . . 9
3.4. Redirects . . . . . . . . . . . . . . . . . . . . . . . . 9
3.5. History . . . . . . . . . . . . . . . . . . . . . . . . . 10
4. Residual Issues . . . . . . . . . . . . . . . . . . . . . . . 10
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1. Normative References . . . . . . . . . . . . . . . . . . 11
7.2. Informative References . . . . . . . . . . . . . . . . . 12
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
This document describes the expected behavior of an IPv6 [RFC2460] host in a network that has more than one prefix, each allocated by an upstream network that is assumed to implement BCP 38 [RFC2827] ingress filtering, and in which the host is presented with a choice of routers. It expects that the network will implement some form of egress routing, so that packets sent to a host outside the local network from a given ISP's prefix will go to that ISP. If the packet is sent to the wrong egress, it is liable to be discarded by the BCP 38 filter. However, the mechanics of egress routing once the packet leaves the host are out of scope. The question here is how the host interacts with that network.
本文档描述了IPv6[RFC2460]主机在具有多个前缀的网络中的预期行为，每个前缀由假定实现BCP 38[RFC2827]入口过滤的上游网络分配，并且在该网络中，主机可选择路由器。它期望网络将实现某种形式的出口路由，以便从给定ISP的前缀发送到本地网络外部主机的数据包将到达该ISP。如果分组被发送到错误的出口，则它容易被BCP 38滤波器丢弃。然而，一旦数据包离开主机，出口路由机制就超出了范围。这里的问题是主机如何与该网络交互。
Various aspects of this issue, and possible solution approaches, are discussed in "IPv6 Multihoming without Network Address Translation" [RFC7157].
“无网络地址转换的IPv6多宿主”[RFC7157]中讨论了此问题的各个方面以及可能的解决方法。
BCP 38 filtering by ISPs is not the only scenario where such behavior is valuable. Implementations that combine existing recommendations, such as [RFC6092] and [RFC7084] can also result in such filtering. Another case is when the connections to the upstream networks include stateful firewalls, such that return packets in a stream will be discarded if they do not return via the firewall that created the state for the outgoing packets. A similar cause of such discards is unicast reverse path forwarding (uRPF) [RFC3704].
ISP的BCP 38过滤并不是此类行为有价值的唯一场景。结合现有建议的实现，如[RFC6092]和[RFC7084]也可能导致此类过滤。另一种情况是，当到上游网络的连接包括有状态防火墙时，这样，如果流中的返回数据包没有通过为传出数据包创建状态的防火墙返回，则流中的返回数据包将被丢弃。此类丢弃的类似原因是单播反向路径转发（uRPF）[RFC3704]。
In this document, the term "filter" is used for simplicity to cover all such cases. In any case, one cannot assume that the host is aware whether an ingress filter, a stateful firewall, or any other type of filter is in place. Therefore, the only known consistent solution is to implement the features defined in this document.
在本文档中，为了简单起见，使用术语“过滤器”来涵盖所有此类情况。在任何情况下，都不能假设主机知道是否存在入口过滤器、有状态防火墙或任何其他类型的过滤器。因此，唯一已知的一致解决方案是实现本文档中定义的功能。
Note that, apart from ensuring that a message with a given source address is given to a first-hop router that appears to know about the prefix in question, this specification is consistent with [RFC4861]. Nevertheless, implementers of Sections 6.2.3, 6.3.4, 6.3.6, and 8.1 of RFC 4861 should extend their implementations accordingly. This specification is fully consistent with [RFC6724] and depends on support for its Rule 5.5 (see Section 3.3). Hosts that do not support these features may fail to communicate in the presence of filters as described above.
注意，除了确保将具有给定源地址的消息发送给似乎知道所述前缀的第一跳路由器外，本规范与[RFC4861]一致。尽管如此，RFC 4861第6.2.3节、第6.3.4节、第6.3.6节和第8.1节的实施者应相应地扩展其实施。本规范与[RFC6724]完全一致，并取决于对其规则5.5的支持（见第3.3节）。不支持这些功能的主机在存在上述筛选器的情况下可能无法通信。
It could be argued that the proposal in this document, which is to send messages using a source address in a given prefix to the router that advertised the prefix in its Router Advertisement (RA), is a form of the Strong End System (ES, e.g., Host) model, discussed in Section 3.3.4.2 of [RFC1122]. In short, [RFC1122] identifies two basic models. First, the "strong host" model describes the host as a set of hosts in one chassis, each of which uses a single address on a single interface and always both sends and receives on that interface. Alternatively, the "weak host" model treats the host as one system with zero or more addresses on every interface and is capable of using any interface for any communication. As noted there, neither model is completely satisfactory. For example, a host with a link-local-only interface and a default route pointing to that interface will necessarily send packets using that interface but with a source address derived from some other interface, and will therefore be a de facto weak host. If the router upstream from such a host implements BCP 38 Ingress Filtering [RFC2827], such as by implementing uRPF on each interface, the router might prevent communication by weak hosts.
可以认为，本文件中的建议，即使用给定前缀中的源地址向在其路由器公告（RA）中公告前缀的路由器发送消息，是[RFC1122]第3.3.4.2节中讨论的强端系统（ES，例如主机）模型的一种形式。简而言之，[RFC1122]确定了两种基本模型。首先，“强主机”模型将主机描述为一个机箱中的一组主机，每个主机在单个接口上使用一个地址，并且始终在该接口上发送和接收。或者，“弱主机”模型将主机视为一个系统，每个接口上都有零个或多个地址，并且能够使用任何接口进行任何通信。如上所述，这两种模式都不完全令人满意。例如，具有仅本地链路接口和指向该接口的默认路由的主机将必然使用该接口发送数据包，但源地址来自其他接口，因此将是事实上的弱主机。如果来自该主机的路由器上游实施BCP 38入口过滤[RFC2827]，例如通过在每个接口上实施uRPF，则路由器可能阻止弱主机的通信。
+-----------------+
| |
| MIF Router +---/--- Other interfaces
| |
+---+---------+---+
| | Two interfaces with subnets
| | from a common prefix
--+-+-- --+-+--
| |
+--+---------+--+
| MIF Host |
+---------------+
+-----------------+
| |
| MIF Router +---/--- Other interfaces
| |
+---+---------+---+
| | Two interfaces with subnets
| | from a common prefix
--+-+-- --+-+--
| |
+--+---------+--+
| MIF Host |
+---------------+
Figure 1: Hypothetical MIF Interconnection
图1：假设的MIF互连
The proposal also differs slightly from the language in [RFC1122] for the Strong Host model. The proposal is that the packet will go to a router that advertised a given prefix but that does not specify what interface that might happen on. Hence, if the router is a multi-interface (MIF) router and it is using a common prefix spanning two or more LANs shared by the host (as in Figure 1), the host might use either of those LANs, according to this proposal. The Strong Host model is not stated in those terms, but in terms of the interface used. A strong host would treat such an MIF router as two separate routers when obeying the rules from RFC 1122 as they apply in the Strong case:
该提案与[RFC1122]中针对强主机模型的语言也略有不同。建议是，数据包将发送到一个路由器，该路由器公布了一个给定的前缀，但没有指定可能发生的接口。因此，如果路由器是多接口（MIF）路由器，并且它使用跨越主机共享的两个或多个LAN的公共前缀（如图1所示），则根据此建议，主机可能使用这些LAN中的任何一个。强主机模型不是在这些术语中说明的，而是在所使用的接口方面说明的。当遵守RFC 1122中适用于强情况的规则时，强主机会将此类MIF路由器视为两个独立的路由器：
(A) A host MUST silently discard an incoming datagram whose destination address does not correspond to the physical interface through which it is received.
（A） 主机必须悄悄地丢弃目标地址与接收数据的物理接口不一致的传入数据报。
(B) A host MUST restrict itself to sending (non-source-routed) IP datagrams only through the physical interface that corresponds to the IP source address of the datagrams.
（B） 主机必须限制自己仅通过与数据报的IP源地址对应的物理接口发送（非源路由）IP数据报。
However, when comparing the presumptive route lookup mechanisms in each model, this proposal is indeed most similar to the Strong Host model, as is any source/destination routing paradigm.
然而，当比较每个模型中的假定路由查找机制时，该建议确实与强主机模型最为相似，就像任何源/目的地路由范例一样。
Strong: route (src IP addr, dest IP addr, TOS) -> gateway
Strong: route (src IP addr, dest IP addr, TOS) -> gateway
Weak: route (dest IP addr, TOS) -> gateway, interface
Weak: route (dest IP addr, TOS) -> gateway, interface
In the hypothetical MIF model suggested in Figure 1, the address fails to identify a single interface, but it does identify a single gateway.
在图1中建议的假设MIF模型中，地址无法识别单个接口，但它确实识别单个网关。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
A host receives prefixes in a Router Advertisement [RFC4861], which goes on to identify whether they are usable by Stateless Address Autoconfiguration (SLAAC) [RFC4862] with any type of interface identifier [RFC4941] [RFC7217]. When no prefixes are usable for SLAAC, the Router Advertisement would normally signal the availability of DHCPv6 [RFC3315] and the host would use it to configure its addresses. In the latter case (or if both SLAAC and DHCPv6 are used on the same link for some reason), the configured addresses generally match one of the prefixes advertised in a Router Advertisement that are supposed to be on-link for that link.
主机接收路由器播发[RFC4861]中的前缀，该播发接着通过无状态地址自动配置（SLAAC）[RFC4862]和任何类型的接口标识符[RFC4941][RFC7217]来识别前缀是否可用。当SLAAC没有可用的前缀时，路由器公告通常会发出DHCPv6[RFC3315]可用的信号，主机将使用它来配置其地址。在后一种情况下（或者如果SLAAC和DHCPv6出于某种原因在同一链路上使用），配置的地址通常与路由器公告中的前缀之一匹配，该前缀应该位于该链路的链路上。
The simplest multihomed network implementation in which a host makes choices among routers might be a LAN with one or more hosts on it and two or more routers, one for each upstream network, or a host that is served by disjoint networks on separate interfaces. In such a network, especially the latter, there is not necessarily a routing protocol, and the two routers may not even know that the other is a router as opposed to a host, or may be configured to ignore its
主机在路由器之间进行选择的最简单的多宿主网络实现可能是一个局域网，其中有一个或多个主机，两个或多个路由器，每个上游网络一个，或者是一个主机由独立接口上的不相交网络提供服务。在这样的网络中，尤其是在后者中，不一定存在路由协议，并且两个路由器甚至可能不知道另一个是与主机相对的路由器，或者可能被配置为忽略其路由协议
presence. One might expect that the routers may or may not receive each other's RAs and form an address in the other router's prefix (which is not per [RFC4862], but is implemented by some stub router implementations). However, all hosts in such a network might be expected to create an address in each prefix so advertised.
在场人们可能期望路由器可能接收或可能不接收彼此的RAs，并在另一个路由器的前缀中形成地址（该前缀不是per[RFC4862]，而是由一些存根路由器实现的）。然而，这样一个网络中的所有主机可能都会在这样公布的每个前缀中创建一个地址。
+---------+ +---------+ +---------+ +---------+
| ISP | | ISP | | ISP | | ISP |
+----+----+ +----+----+ +----+----+ +----+----+
| | | |
| | | |
+----+----+ +----+----+ +----+----+ +----+----+
| Router | | Router | | Router | | Router |
+----+----+ +----+----+ +----+----+ +----+----+
| | | |
+------+------+ | +--------+ |
| +--+ Host +--+
+----+----+ +--------+
| Host |
+---------+
Common LAN Case Disjoint LAN Case
(Multihomed Network) (Multihomed Host)
+---------+ +---------+ +---------+ +---------+
| ISP | | ISP | | ISP | | ISP |
+----+----+ +----+----+ +----+----+ +----+----+
| | | |
| | | |
+----+----+ +----+----+ +----+----+ +----+----+
| Router | | Router | | Router | | Router |
+----+----+ +----+----+ +----+----+ +----+----+
| | | |
+------+------+ | +--------+ |
| +--+ Host +--+
+----+----+ +--------+
| Host |
+---------+
Common LAN Case Disjoint LAN Case
(Multihomed Network) (Multihomed Host)
Figure 2: Two Simple Networks
图2：两个简单的网络
If there is no routing protocol among those routers, there is no mechanism by which packets can be deterministically forwarded between the routers (as described in BCP 84 [RFC3704]) in order to avoid filters. Even if there was routing, it would result in an indirect route, rather than a direct route originating with the host; this is not "wrong", but can be inefficient. Therefore, the host would do well to select the appropriate router itself.
如果这些路由器之间没有路由协议，则不存在可在路由器之间确定转发数据包的机制（如BCP 84[RFC3704]中所述），以避免过滤。即使存在路由，也会产生一条间接路由，而不是源自主机的直接路由；这不是“错误”，但可能是低效的。因此，主机最好选择合适的路由器本身。
Since the host derives fundamental default routing information from the Router Advertisement, this implies that, in any network with hosts using multiple prefixes, each prefix SHOULD be advertised via a Prefix Information Option (PIO) [RFC4861] by one of the attached routers, even if addresses are being assigned using DHCPv6. A router that advertises a prefix indicates that it is able to appropriately route packets with source addresses within that prefix, regardless of the setting of the L and A flags in the PIO.
由于主机从路由器公告中获得基本默认路由信息，这意味着，在具有使用多个前缀的主机的任何网络中，每个前缀都应该由一个连接的路由器通过前缀信息选项（PIO）[RFC4861]进行公告，即使使用DHCPv6分配地址也是如此。播发前缀的路由器表示它能够适当地路由具有该前缀内的源地址的数据包，而不管PIO中的L和A标志的设置如何。
In some circumstances, both L and A might be zero. If SLAAC is not wanted (A=0) and there is no reason to announce an on-link prefix (L=0), a PIO SHOULD be sent to inform hosts that they should use the router in question as the first hop for packets with source addresses in the PIO prefix. An example case is the MIF router in Figure 1, which could send PIOs with A=L=0 for the common prefix. Although
在某些情况下，L和A都可能为零。如果不需要SLAAC（A=0），并且没有理由宣布链路上的前缀（L=0），则应发送PIO通知主机，它们应使用相关路由器作为PIO前缀中包含源地址的数据包的第一跳。图1中的MIF路由器就是一个例子，它可以发送公共前缀为A=L=0的PIO。虽然
this does not violate the existing standard [RFC4861], such a PIO has not previously been common, and it is possible that existing host implementations simply ignore such a PIO or that existing router implementations are not capable of sending such a PIO. Newer implementations that support this mechanism should be updated accordingly:
这并不违反现有标准[RFC4861]，此类PIO以前并不常见，现有主机实现可能只是忽略此类PIO，或者现有路由器实现无法发送此类PIO。应相应更新支持此机制的较新实现：
o A host SHOULD NOT ignore a PIO simply because both L and A flags are cleared (extending Section 6.3.4 of [RFC4861]).
o 主机不应仅仅因为L和A标志都已清除而忽略PIO（扩展[RFC4861]第6.3.4节）。
o A router SHOULD be able to send such a PIO (extending Section 6.2.3 of [RFC4861]).
o 路由器应能够发送此类PIO（扩展[RFC4861]第6.2.3节）。
Networking equipment needs to support source/destination routing for at least some of the routes in the Forwarding Information Base (FIB), such as default egress routes differentiated by source prefix. Installation of source/destination routes in the FIB might be accomplished using static routes, Software-Defined Networking (SDN) technologies, or dynamic routing protocols.
网络设备需要支持转发信息库（FIB）中至少一些路由的源/目的地路由，例如由源前缀区分的默认出口路由。FIB中源/目标路由的安装可以使用静态路由、软件定义网络（SDN）技术或动态路由协议来完成。
As described in [RFC4191] and [RFC4861], a Router Advertisement may contain zero or more Prefix Information Options (PIOs) or zero or more Route Information Options (RIOs). In their original intent, these indicate general information to a host: "the router whose address is found in the source address field of this packet is one of your default routers", "you might create an address in this prefix", or "this router would be a good place to send traffic directed to a given destination prefix". In a multi-prefix network with multiple exits, the host's characterization of each default router SHOULD include the prefixes it has announced (extending Section 6.3.4 of [RFC4861]). In other words, the PIO is reinterpreted to also imply that the advertising router would be a reasonable first hop for any packet using a source address in any advertised prefix, regardless of Default Router Preference.
如[RFC4191]和[RFC4861]中所述，路由器公告可包含零个或多个前缀信息选项（PIO）或零个或多个路由信息选项（RIO）。在其原始意图中，这些向主机指示一般信息：“在该数据包的源地址字段中找到其地址的路由器是您的默认路由器之一”、“您可以在此前缀中创建地址”或“此路由器将是发送定向到给定目的地前缀的流量的好地方”。在具有多个出口的多前缀网络中，主机对每个默认路由器的描述应包括其已宣布的前缀（扩展[RFC4861]第6.3.4节）。换句话说，PIO被重新解释为也意味着广告路由器将是使用任何广告前缀中的源地址的任何分组的合理第一跳，而不管默认路由器偏好如何。
+---------+ |
( ISP A ) - + Bob-A +--+ +-----+
+-------+ / +---------+ +--+ |
| | / | | |
| Alice +--/--( The Internet ) | Bob |
| | \ | | |
+-------+ \ +---------+ +--+ |
( ISP B ) - + Bob-B +--+ +-----+
+---------+ |
+---------+ |
( ISP A ) - + Bob-A +--+ +-----+
+-------+ / +---------+ +--+ |
| | / | | |
| Alice +--/--( The Internet ) | Bob |
| | \ | | |
+-------+ \ +---------+ +--+ |
( ISP B ) - + Bob-B +--+ +-----+
+---------+ |
Figure 3: PIOs, RIOs, and Default Routes
图3:PIO、RIOs和默认路由
The implications bear consideration. Imagine, Figure 3, that hosts Alice and Bob are in communication. Bob's network consists of at least Bob (the computer), two routers (Bob-A and Bob-B), and the links between them; it may be much larger, for example, a campus or corporate network. Bob's network is therefore multihomed, and Bob's first-hop routers are Bob-A (to the upstream ISP A advertising prefix PA) and Bob-B (to the upstream network B and advertising prefix PB). We assume that Bob is not applying Rule 5.5 of [RFC6724]. If Bob is responding to a message from Alice, his choice of source address is forced to be the address Alice used as a destination (which we may presume to have been in prefix PA). Hence, Bob either created or was assigned an address in PA, and can only reasonably send traffic using it to Bob-A as a first-hop router. If there are several routers in Bob's network advertising the prefix PA (referred to as "Bob-Ax" routers), then Bob should choose its first-hop router only from among those routers. From among the multiple Bob-Ax routers, Bob should choose the first-hop router based on the criteria specified in Section 3 of [RFC4191]. If none of the Bob-Ax routers has advertised an RA with a non-zero Router Lifetime or an RIO with a non-zero Route Lifetime that includes Alice, but router Bob-B has, it is irrelevant. Bob is using the address allocated in PA and courts a BCP 38 discard if he doesn't send the packet to Bob-A.
其影响值得考虑。想象一下，图3中的主人Alice和Bob正在通信。Bob的网络至少由Bob（计算机）、两个路由器（Bob-A和Bob-B）以及它们之间的链路组成；它可能更大，例如，校园或公司网络。因此，Bob的网络是多址的，Bob的第一跳路由器是Bob-A（到上游ISP A广告前缀PA）和Bob-B（到上游网络B和广告前缀PB）。我们假设Bob没有应用[RFC6724]的规则5.5。如果Bob正在响应Alice发送的消息，则他选择的源地址将强制为Alice用作目的地的地址（我们可以假定该地址在前缀PA中）。因此，Bob在PA中创建或分配了一个地址，并且只能合理地将其作为第一跳路由器发送到Bob-A。如果Bob的网络中有多个路由器宣传前缀PA（称为“Bob Ax”路由器），则Bob应仅从这些路由器中选择其第一跳路由器。从多个Bob Ax路由器中，Bob应根据[RFC4191]第3节中规定的标准选择第一跳路由器。如果Bob Ax路由器中没有一个公布路由器生存期非零的RA或包含Alice的路由生存期非零的RIO，但路由器Bob-B公布了，则这与此无关。Bob正在使用PA中分配的地址，如果他不将数据包发送给Bob-a，则会要求BCP 38放弃。
In the special case that Bob is initiating the conversation, an RIO might, however, influence source address choice. Bob could presumably use any address allocated to him, in this case, his address in PA or PB. If Bob-B has advertised an RIO for Alice's prefix and Bob-A has not, Bob MAY take that fact into account in address selection -- choosing an address that would allow him to make use of the RIO.
在Bob发起对话的特殊情况下，RIO可能会影响源地址的选择。Bob可能会使用分配给他的任何地址，在本例中，他在PA或PB中的地址。若Bob-B为Alice的前缀做了RIO广告，而Bob-A并没有，Bob可能会在地址选择中考虑到这一事实——选择一个允许他使用RIO的地址。
Default Router Selection (Section 6.3.6 of [RFC4861]) is extended as follows: A host SHOULD select default routers for each prefix it is assigned an address in. Routers that have advertised the prefix in their Router Advertisement message SHOULD be preferred over routers that do not advertise the prefix, regardless of Default Router Preference. Note that this document does not change the way in which default router preferences are communicated [RFC4191].
默认路由器选择（RFC4861第6.3.6节）扩展如下：主机应为其分配地址的每个前缀选择默认路由器。无论默认路由器首选项如何，在其路由器广告消息中广告前缀的路由器应优先于不广告前缀的路由器。请注意，本文档不会更改默认路由器首选项的通信方式[RFC4191]。
If no router has advertised the prefix in an RA, normal routing metrics will apply. An example is a host connected to the Internet via one router, and at the same time connected by a VPN to a private domain that is also connected to the global Internet.
如果没有路由器在RA中公布前缀，则将应用正常路由度量。例如，主机通过一个路由器连接到互联网，同时通过VPN连接到也连接到全球互联网的私有域。
As a result of this, when a host sends a packet using a source address in one of those prefixes and has no history directing it otherwise, it SHOULD send it to the indicated default router. In the "simplest" network described in Section 2.1, that would get it to the only router that is directly capable of getting it to the right ISP. This will also apply in more complex networks, even when more than one physical or virtual interface is involved.
因此，当主机使用其中一个前缀中的源地址发送数据包，并且没有其他指向它的历史记录时，它应该将数据包发送到指定的默认路由器。在第2.1节中描述的“最简单”网络中，这将使其连接到唯一能够直接将其连接到正确ISP的路由器。这也适用于更复杂的网络，即使涉及多个物理或虚拟接口。
In more complex cases, wherein routers advertise RAs for multiple prefixes whether or not they have direct or isolated upstream connectivity, the host is dependent on the routing system already. If the host gives the packet to a router advertising its source prefix, it should be able to depend on the router to do the right thing.
在更复杂的情况下，无论路由器是否具有直接或隔离的上游连接，路由器都会向RAs播发多个前缀，主机已经依赖于路由系统。如果主机将数据包交给一个公布其源前缀的路由器，它应该能够依靠路由器做正确的事情。
There is an interaction with Default Address Selection [RFC6724]. A host following the recommendation in the previous section will store information about which next hops advertised which prefixes. Rule 5.5 of RFC 6724 states that the source address used to send to a given destination address should, if possible, be chosen from a prefix known to be advertised by the next-hop router for that destination. Therefore, this selection rule SHOULD be implemented in a host following the recommendation in the previous section.
存在与默认地址选择[RFC6724]的交互。遵循上一节中的建议的主机将存储关于哪些下一跳广告哪些前缀的信息。RFC 6724的规则5.5规定，如果可能的话，用于发送到给定目的地地址的源地址应该从下一跳路由器为该目的地通告的前缀中选择。因此，应按照上一节中的建议在主机中实施此选择规则。
There is potential for adverse interaction with any off-link Redirect (Redirect for a destination that is not on-link) message sent by a router in accordance with Section 8 of [RFC4861]. Hosts SHOULD apply off-link redirects only for the specific pair of source and destination addresses concerned, so the host's Destination Cache
根据[RFC4861]第8节，路由器发送的任何非链路重定向（针对非链路上的目的地的重定向）消息可能存在不利交互。主机应仅对相关的特定源地址和目标地址对应用非链接重定向，以便主机的目标缓存
might need to contain appropriate source-specific entries. This extends the validity check specified in Section 8.1 of [RFC4861].
可能需要包含适当的源特定条目。这扩展了[RFC4861]第8.1节中规定的有效性检查。
Some modern hosts maintain history, in terms of what has previously worked or not worked for a given address or prefix and in some cases the effective window and Maximum Segment Size (MSS) values for TCP or other protocols. This might include a next-hop address for use when a packet is sent to the indicated address.
一些现代主机维护历史记录，包括以前对给定地址或前缀有效或无效的内容，以及在某些情况下TCP或其他协议的有效窗口和最大段大小（MSS）值。这可能包括一个下一跳地址，以便在将数据包发送到指定地址时使用。
When such a host makes a successful exchange with a remote destination using a particular address pair, and the host has previously received a PIO that matches the source address, then the host SHOULD include the prefix in such history, whatever the setting of the L and A flags in the PIO. On subsequent attempts to communicate with that destination, if it has an address in that prefix at that time, a host MAY use an address in the remembered prefix for the session.
当这样的主机使用特定的地址对与远程目的地成功交换，并且该主机先前已收到与源地址匹配的PIO时，则该主机应在此类历史记录中包含前缀，无论PIO中的L和a标志设置如何。在随后尝试与该目的地通信时，如果该目的地当时在该前缀中有地址，则主机可以在会话中使用记住的前缀中的地址。
Consider a network where routers on a link run a routing protocol and are configured with the same information. Thus, on each link, all routers advertise all prefixes on that link. The assumption that packets will be forwarded to the appropriate egress by the local routing system might cause at least one extra hop in the local network (from the host to the wrong router, and from there to another router on the same link).
考虑链路上的路由器运行路由协议并配置相同信息的网络。因此，在每个链路上，所有路由器都会公布该链路上的所有前缀。假设数据包将由本地路由系统转发到适当的出口，可能会导致本地网络中至少有一个额外的跃点（从主机到错误的路由器，并从那里到同一链路上的另一个路由器）。
In a slightly more complex situation such as the disjoint LAN case of Figure 2, for example, a home plus corporate home-office configuration, the two upstream routers might be on different LANs and therefore different subnets (e.g., the host is itself multihomed). In that case, there is no way for the "wrong" router to detect the existence of the "right" router, or to route to it.
在稍微复杂一些的情况下，如图2的不相交LAN情况，例如，家庭+公司家庭办公室配置，两个上游路由器可能位于不同的LAN上，因此位于不同的子网（例如，主机本身是多宿的）。在这种情况下，“错误”路由器无法检测到“正确”路由器的存在，也无法路由到它。
In such a case, it is particularly important that hosts take the responsibility to memorize and select the best first hop as described in Section 3.
在这种情况下，如第3节所述，主机承担记忆和选择最佳第一跳的责任尤为重要。
This document does not request any registry actions.
本文档不请求任何注册表操作。
This document is intended to avoid connectivity issues in the presence of BCP 38 ingress filters or stateful firewalls combined with multihoming. It does not, in itself, create any new security or privacy exposures. However, since the solution is designed to ensure that routing occurs correctly in situations where it previously failed, this might result in unexpected exposure of networks that were previously unreachable.
本文档旨在避免BCP 38入口过滤器或结合多主的有状态防火墙出现连接问题。它本身不会造成任何新的安全或隐私暴露。但是，由于该解决方案旨在确保在以前失败的情况下正确进行路由，这可能会导致以前无法访问的网络意外暴露。
There might be a small privacy improvement: with the current practice, a multihomed host that sends packets with the wrong address to an upstream router or network discloses the prefix of one upstream to the other upstream network. This practice reduces the probability of that occurrence.
可能有一点隐私改进：按照目前的做法，向上游路由器或网络发送地址错误的数据包的多宿主机会将一个上游的前缀泄露给另一个上游网络。这种做法降低了发生这种情况的可能性。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998, <http://www.rfc-editor.org/info/rfc2460>.
[RFC2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，DOI 10.17487/RFC2460，1998年12月<http://www.rfc-editor.org/info/rfc2460>.
[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>.
[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>.
[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>.
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989, <http://www.rfc-editor.org/info/rfc1122>.
[RFC1122]Braden，R.，Ed.“互联网主机的要求-通信层”，STD 3，RFC 1122，DOI 10.17487/RFC1122，1989年10月<http://www.rfc-editor.org/info/rfc1122>.
[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>.
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2003, <http://www.rfc-editor.org/info/rfc3315>.
[RFC3315]Droms，R.，Ed.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC 3315，DOI 10.17487/RFC3315，2003年7月<http://www.rfc-editor.org/info/rfc3315>.
[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>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007, <http://www.rfc-editor.org/info/rfc4862>.
[RFC4862]Thomson，S.，Narten，T.和T.Jinmei，“IPv6无状态地址自动配置”，RFC 4862，DOI 10.17487/RFC4862，2007年9月<http://www.rfc-editor.org/info/rfc4862>.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, <http://www.rfc-editor.org/info/rfc4941>.
[RFC4941]Narten，T.，Draves，R.，和S.Krishnan，“IPv6中无状态地址自动配置的隐私扩展”，RFC 4941，DOI 10.17487/RFC49411907年9月<http://www.rfc-editor.org/info/rfc4941>.
[RFC6092] Woodyatt, J., Ed., "Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service", RFC 6092, DOI 10.17487/RFC6092, January 2011, <http://www.rfc-editor.org/info/rfc6092>.
[RFC6092]Woodyatt，J.，Ed.，“提供住宅IPv6互联网服务的客户场所设备（CPE）中推荐的简单安全功能”，RFC 6092，DOI 10.17487/RFC6092，2011年1月<http://www.rfc-editor.org/info/rfc6092>.
[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, <http://www.rfc-editor.org/info/rfc7084>.
[RFC7084]Singh，H.，Beebee，W.，Donley，C.，和B.Stark，“IPv6客户边缘路由器的基本要求”，RFC 7084，DOI 10.17487/RFC7084，2013年11月<http://www.rfc-editor.org/info/rfc7084>.
[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>.
[RFC7217] Gont, F., "A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)", RFC 7217, DOI 10.17487/RFC7217, April 2014, <http://www.rfc-editor.org/info/rfc7217>.
[RFC7217]Gont，F.“使用IPv6无状态地址自动配置（SLAAC）生成语义不透明接口标识符的方法”，RFC 7217，DOI 10.17487/RFC72172014年4月<http://www.rfc-editor.org/info/rfc7217>.
Acknowledgements
致谢
Comments were received from Jinmei Tatuya and Ole Troan, who have suggested important text, plus Mikael Abrahamsson, Steven Barth, Carlos Bernardos Cano, Chris Bowers, Zhen Cao, Juliusz Chroboczek, Toerless Eckert, David Farmer, Bob Hinden, Ben Laurie, Dusan Mudric, Tadahisa Okimoto, Pierre Pfister, Behcet Sarikaya, Mark Smith, and James Woodyatt.
金美·塔图亚（Jinmei Tatuya）和奥勒·特隆（Ole Troan）提出了重要的文本，加上米凯尔·亚伯拉罕松（Mikael Abrahamsson）、史蒂文·巴特（Steven Barth）、卡洛斯·贝尔纳多·卡诺（Carlos Bernardos Cano）、克里斯·鲍尔斯（Chris Bowers）、曹震（Zhen Cao）、朱利叶斯·克洛博采克（Juliusz Chroboczek）、托利斯·埃克特（Toerless Eckert）、大卫·法默（David Farmer）、鲍勃·欣登（Bo。
Authors' Addresses
作者地址
Fred Baker Santa Barbara, California 93117 United States of America
加利福尼亚州圣巴巴拉市弗雷德·贝克93117美利坚合众国
Email: FredBaker.IETF@gmail.com
Email: FredBaker.IETF@gmail.com
Brian Carpenter Department of Computer Science University of Auckland PB 92019 Auckland 1142 New Zealand
Brian Carpenter奥克兰大学计算机系，奥克兰92019，新西兰1142
Email: brian.e.carpenter@gmail.com
Email: brian.e.carpenter@gmail.com