Internet Engineering Task Force (IETF) O. Troan, Ed.
Request for Comments: 7157 Cisco
Category: Informational D. Miles
ISSN: 2070-1721 Google Fiber
S. Matsushima
Softbank Telecom
T. Okimoto
NTT West
D. Wing
Cisco
March 2014
Internet Engineering Task Force (IETF) O. Troan, Ed.
Request for Comments: 7157 Cisco
Category: Informational D. Miles
ISSN: 2070-1721 Google Fiber
S. Matsushima
Softbank Telecom
T. Okimoto
NTT West
D. Wing
Cisco
March 2014
IPv6 Multihoming without Network Address Translation
无网络地址转换的IPv6多宿主
Abstract
摘要
Network Address and Port Translation (NAPT) works well for conserving global addresses and addressing multihoming requirements because an IPv4 NAPT router implements three functions: source address selection, next-hop resolution, and (optionally) DNS resolution. For IPv6 hosts, one approach could be the use of IPv6-to-IPv6 Network Prefix Translation (NPTv6). However, NAT and NPTv6 should be avoided, if at all possible, to permit transparent end-to-end connectivity. In this document, we analyze the use cases of multihoming. We also describe functional requirements and possible solutions for multihoming without the use of NAT in IPv6 for hosts and small IPv6 networks that would otherwise be unable to meet minimum IPv6-allocation criteria. We conclude that DHCPv6-based solutions are suitable to solve the multihoming issues described in this document, but NPTv6 may be required as an intermediate solution.
网络地址和端口转换（NAPT）在保存全局地址和满足多主需求方面效果良好，因为IPv4 NAPT路由器实现了三个功能：源地址选择、下一跳解析和（可选）DNS解析。对于IPv6主机，一种方法是使用IPv6到IPv6网络前缀转换（NPTv6）。然而，如果可能的话，应该避免NAT和NPTv6，以允许透明的端到端连接。在本文中，我们分析了多归宿的用例。我们还描述了在IPv6中不使用NAT的情况下，对于无法满足最低IPv6分配标准的主机和小型IPv6网络，多宿主的功能需求和可能的解决方案。我们得出结论，基于DHCPv6的解决方案适合解决本文档中描述的多主问题，但NPTv6可能需要作为中间解决方案。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7157.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7157.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. IPv6 Multihomed Network Scenarios . . . . . . . . . . . . . . 6
3.1. Classification of Network Scenarios for Multihomed Host . 6
3.2. Multihomed Network Environment . . . . . . . . . . . . . 8
3.3. Problem Statement . . . . . . . . . . . . . . . . . . . . 9
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. End-to-End Transparency . . . . . . . . . . . . . . . . . 11
4.2. Scalability . . . . . . . . . . . . . . . . . . . . . . . 11
5. Problem Analysis . . . . . . . . . . . . . . . . . . . . . . 11
5.1. Source Address Selection . . . . . . . . . . . . . . . . 11
5.2. Next Hop Selection . . . . . . . . . . . . . . . . . . . 12
5.3. DNS Recursive Name Server Selection . . . . . . . . . . . 13
6. Implementation Approach . . . . . . . . . . . . . . . . . . . 13
6.1. Source Address Selection . . . . . . . . . . . . . . . . 14
6.2. Next Hop Selection . . . . . . . . . . . . . . . . . . . 14
6.3. DNS Recursive Name Server Selection . . . . . . . . . . . 15
6.4. Other Algorithms Available in RFCs . . . . . . . . . . . 16
7. Considerations for MHMP Deployment . . . . . . . . . . . . . 16
7.1. Non-MHMP Host Consideration . . . . . . . . . . . . . . . 16
7.2. Coexistence Considerations . . . . . . . . . . . . . . . 17
7.3. Policy Collision Consideration . . . . . . . . . . . . . 17
8. Security Considerations . . . . . . . . . . . . . . . . . . . 18
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
10.1. Normative References . . . . . . . . . . . . . . . . . . 20
10.2. Informative References . . . . . . . . . . . . . . . . . 20
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. IPv6 Multihomed Network Scenarios . . . . . . . . . . . . . . 6
3.1. Classification of Network Scenarios for Multihomed Host . 6
3.2. Multihomed Network Environment . . . . . . . . . . . . . 8
3.3. Problem Statement . . . . . . . . . . . . . . . . . . . . 9
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. End-to-End Transparency . . . . . . . . . . . . . . . . . 11
4.2. Scalability . . . . . . . . . . . . . . . . . . . . . . . 11
5. Problem Analysis . . . . . . . . . . . . . . . . . . . . . . 11
5.1. Source Address Selection . . . . . . . . . . . . . . . . 11
5.2. Next Hop Selection . . . . . . . . . . . . . . . . . . . 12
5.3. DNS Recursive Name Server Selection . . . . . . . . . . . 13
6. Implementation Approach . . . . . . . . . . . . . . . . . . . 13
6.1. Source Address Selection . . . . . . . . . . . . . . . . 14
6.2. Next Hop Selection . . . . . . . . . . . . . . . . . . . 14
6.3. DNS Recursive Name Server Selection . . . . . . . . . . . 15
6.4. Other Algorithms Available in RFCs . . . . . . . . . . . 16
7. Considerations for MHMP Deployment . . . . . . . . . . . . . 16
7.1. Non-MHMP Host Consideration . . . . . . . . . . . . . . . 16
7.2. Coexistence Considerations . . . . . . . . . . . . . . . 17
7.3. Policy Collision Consideration . . . . . . . . . . . . . 17
8. Security Considerations . . . . . . . . . . . . . . . . . . . 18
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
10.1. Normative References . . . . . . . . . . . . . . . . . . 20
10.2. Informative References . . . . . . . . . . . . . . . . . 20
In this document, we analyze the use cases of multihoming, describe functional requirements, and describe the problems with IPv6 multihoming. There are two ways to avoid the problems of IPv6 multihoming:
在本文档中，我们分析了多宿主的用例，描述了功能需求，并描述了IPv6多宿主的问题。有两种方法可以避免IPv6多宿主问题：
1. using IPv6-to-IPv6 network prefix translation (NPTv6) [RFC6296], or;
1. 使用IPv6到IPv6网络前缀转换（NPTv6）[RFC6296]，或；
2. refining IPv6 specifications to resolve the problems with IPv6 multihoming.
2. 完善IPv6规范以解决IPv6多宿主问题。
This document concerns itself with the latter and explores the solution space. We hope this will encourage the development of solutions to the problem so that, in the long run, NPTv6 can be avoided.
本文档关注后者并探索解决方案空间。我们希望这将鼓励开发解决问题的方案，以便从长远来看避免NPTv6。
IPv6 provides enough globally unique addresses to permit every conceivable host on the Internet to be uniquely addressed without the requirement for Network Address Port Translation (NAPT) [RFC3022], offering a renaissance in end-to-end transparent connectivity.
IPv6提供了足够多的全局唯一地址，允许在不需要网络地址端口转换（NAPT）[RFC3022]的情况下对Internet上的每个可能的主机进行唯一寻址，从而复兴了端到端的透明连接。
Unfortunately, this may not be possible in every case, due to the possible necessity of NAT even in IPv6, because of multihoming. Though there are mechanisms to implement multihoming, such as BGP multihoming [RFC4116] at the network level and multihoming based on the Stream Control Transmission Protocol (SCTP) [RFC4960] in the transport layer, there is no mechanism in IPv6 that serves as a replacement for NAT-based multihoming in IPv4. In IPv4, for a host or a small network, NAT-based multihoming is easily deployable and is an already-deployed technique.
不幸的是，这不可能在所有情况下都实现，因为即使在IPv6中也可能需要NAT，这是因为多宿。虽然有实现多主的机制，例如网络级别的BGP多主[RFC4116]和传输层基于流控制传输协议（SCTP）[RFC4960]的多主，但IPv6中没有替代IPv4中基于NAT的多主的机制。在IPv4中，对于主机或小型网络，基于NAT的多宿主很容易部署，并且是一种已经部署的技术。
Whenever a host or small network (that does not meet minimum IPv6 allocation criteria) is connected to multiple upstream networks, an IPv6 address is assigned by each respective service provider resulting in hosts with multiple global scope IPv6 addresses with different prefixes. As each service provider is allocated a different address space from its Internet Registry, it, in turn, assigns a different address space to the end-user network or host. For example, a remote access user's host or router may use a VPN to simultaneously connect to a remote network and retain a default route to the Internet for other purposes.
每当主机或小型网络（不满足最低IPv6分配标准）连接到多个上游网络时，每个相应的服务提供商都会分配一个IPv6地址，从而使主机具有多个具有不同前缀的全局范围IPv6地址。由于每个服务提供商都从其Internet注册表中分配了不同的地址空间，因此，它会依次为最终用户网络或主机分配不同的地址空间。例如，远程访问用户的主机或路由器可以使用VPN同时连接到远程网络，并保留到Internet的默认路由以用于其他目的。
In IPv4, a common solution to the multihoming problem is to employ NAPT on a border router and use private address space for individual host addressing. The use of NAPT allows hosts to have exactly one IP address visible on the public network, and the combination of NAPT with provider-specific outside addresses (one for each uplink) and destination-based routing insulates a host from the impacts of multiple upstream networks. The border router may also implement a DNS cache or DNS policy to resolve address queries from hosts.
在IPv4中，多主问题的常见解决方案是在边界路由器上使用NAPT，并使用专用地址空间进行单个主机寻址。NAPT的使用允许主机在公共网络上只有一个IP地址可见，并且NAPT与特定于提供商的外部地址（每个上行链路一个）和基于目的地的路由的组合使主机免受多个上游网络的影响。边界路由器还可以实现DNS缓存或DNS策略来解析来自主机的地址查询。
It is our goal to avoid the IPv6 equivalent of NAT. So, the goals for IPv6 multihoming defined in [RFC3582] do not match the goals of this document. Also, regardless of what the NPTv6 specification is, we are trying to avoid any form of network address translation technique that may not be visible to either of the end hosts. To reach this goal, several mechanisms are needed for end-user hosts to have multiple address assignments and resolve issues such as which address to use for sourcing traffic to which destination:
我们的目标是避免IPv6等同于NAT。因此，[RFC3582]中定义的IPv6多宿主目标与本文档的目标不匹配。此外，无论NPTv6规范是什么，我们都在努力避免任何形式的网络地址转换技术，这些技术可能对任何一个终端主机都不可见。为了实现这一目标，最终用户主机需要几种机制来分配多个地址，并解决诸如使用哪个地址将通信源发送到哪个目的地等问题：
o If multiple routers exist on a single link, the host must select the appropriate next hop for each connected network. Each router is in turn connected to a different service provider network, which provides independent address assignment. Routing protocols that would normally be employed for router-to-router network advertisement seem inappropriate for use by individual hosts.
o 如果单个链路上存在多个路由器，则主机必须为每个连接的网络选择适当的下一跳。每个路由器依次连接到不同的服务提供商网络，该网络提供独立的地址分配。通常用于路由器到路由器网络广告的路由协议似乎不适合单个主机使用。
o Source address selection becomes difficult whenever a host has more than one address of the same address scope. Current address selection criteria may result in hosts using an arbitrary or random address when sourcing upstream traffic. Unfortunately, for the host, the appropriate source address is a function of the upstream network for which the packet is bound. If an upstream service provider uses IP anti-spoofing or ingress filtering, it is conceivable that the packets that have an inappropriate source address for the upstream network would never reach their destination.
o 每当主机具有多个相同地址范围的地址时，源地址选择就会变得困难。当前地址选择标准可能导致主机在寻找上游流量时使用任意或随机地址。不幸的是，对于主机，适当的源地址是数据包绑定到的上游网络的函数。如果上游服务提供商使用IP防欺骗或入口过滤，则可以想象，对于上游网络具有不适当源地址的数据包将永远不会到达其目的地。
o In a multihomed environment, different DNS scopes or partitions may exist in each independent upstream network. A DNS query sent to an arbitrary upstream DNS recursive name server may result in incorrect or poisoned responses.
o 在多宿环境中，每个独立的上游网络中可能存在不同的DNS作用域或分区。发送到任意上游DNS递归名称服务器的DNS查询可能会导致错误或中毒响应。
In short, while IPv6 facilitates hosts having more than one address in the same address scope, the application of this causes significant issues for a host from routing, source address selection, and DNS resolution perspectives. A possible consequence of assigning a host multiple identically scoped addresses is severely impaired IP connectivity.
简言之，虽然IPv6有助于主机在同一地址范围内拥有多个地址，但应用IPv6会从路由、源地址选择和DNS解析角度给主机带来重大问题。为主机分配多个作用域相同的地址可能导致IP连接严重受损。
If a host connects to a network behind an IPv4 NAPT, the host has one private address in the local network. There is no confusion. The NAT becomes the gateway of the host and forwards the packet to an appropriate network when it is multihomed. It also operates a DNS cache server or DNS proxy, which receives all DNS inquires, and gives a correct answer to the host.
如果主机连接到IPv4 NAPT后面的网络，则该主机在本地网络中有一个专用地址。没有混乱。NAT成为主机的网关，并在数据包被多址时将其转发到适当的网络。它还运行一个DNS缓存服务器或DNS代理，接收所有DNS查询，并向主机提供正确答案。
NPTv6 IPv6-to-IPv6 Network Prefix Translation as described in [RFC6296].
NPTv6 IPv6到IPv6网络前缀转换，如[RFC6296]中所述。
NAPT Network Address Port Translation as described in [RFC3022]. In other contexts, NAPT is often pronounced "NAT" or written as "NAT".
NAPT网络地址端口转换，如[RFC3022]所述。在其他上下文中，NAPT通常发音为“NAT”或写为“NAT”。
MHMP Multihomed with multi-prefix. A host implementation that supports the mechanisms described in this document; namely, source address selection policy, next hop selection, and DNS selection policy.
MHMP多址多前缀。支持本文件所述机制的主机实现；即，源地址选择策略、下一跳选择和DNS选择策略。
In this section, we classify three scenarios of the multihoming environment.
在本节中，我们将对多主环境的三种场景进行分类。
Scenario 1:
情景1：
In this scenario, two or more routers are present on a single link shared with the host(s). Each router is, in turn, connected to a different service provider network, which provides independent address assignment and DNS recursive name servers. A host in this environment would be offered multiple prefixes and DNS recursive name servers advertised from the two different routers.
在这种情况下，与主机共享的单个链路上存在两个或多个路由器。每个路由器依次连接到不同的服务提供商网络，该网络提供独立的地址分配和DNS递归名称服务器。此环境中的主机将从两个不同的路由器提供多个前缀和DNS递归名称服务器。
+------+ ___________
| | / \
+---| rtr1 |=====/ network \
| | | \ 1 /
+------+ | +------+ \___________/
| | |
| hosts|-----+
| | |
+------+ | +------+ ___________
| | | / \
+---| rtr2 |=====/ network \
| | \ 2 /
+------+ \___________/
+------+ ___________
| | / \
+---| rtr1 |=====/ network \
| | | \ 1 /
+------+ | +------+ \___________/
| | |
| hosts|-----+
| | |
+------+ | +------+ ___________
| | | / \
+---| rtr2 |=====/ network \
| | \ 2 /
+------+ \___________/
Figure 1: Single Uplink, Multiple Next Hop, Multiple Prefix (Scenario 1)
图1：单上行链路、多下一跳、多前缀（场景1）
Figure 1 illustrates the host connecting to rtr1 and rtr2 via a shared link. Networks 1 and 2 are reachable via rtr1 and rtr2, respectively. When the host sends packets to network 1, the next hop to network 1 is rtr1. Similarly, rtr2 is the next hop to network 2.
图1显示了通过共享链接连接到rtr1和rtr2的主机。网络1和网络2分别可通过rtr1和rtr2访问。当主机向网络1发送数据包时，到网络1的下一跳是rtr1。类似地，rtr2是网络2的下一跳。
Example: multiple broadband service providers (Internet, VoIP, IPTV, etc.)
示例：多个宽带服务提供商（互联网、VoIP、IPTV等）
Scenario 2:
情景2：
In this scenario, a single gateway router connects the host to two or more upstream service provider networks. This gateway router would receive prefix delegations and a different set of DNS recursive name servers from each independent service provider network. The gateway, in turn, advertises the provider prefixes to the host, and for DNS, may either act as a lightweight DNS cache server or advertise the complete set of service provider DNS recursive name servers to the hosts.
在此场景中，单个网关路由器将主机连接到两个或多个上游服务提供商网络。该网关路由器将从每个独立的服务提供商网络接收前缀委派和一组不同的DNS递归名称服务器。网关依次向主机播发提供商前缀，对于DNS，网关可以充当轻型DNS缓存服务器，或者向主机播发整套服务提供商DNS递归名称服务器。
+------+ ___________
+-----+ | | / \
| |=======| rtr1 |=====/ network \
| |port1 | | \ 1 /
+------+ | | +------+ \___________/
| | | |
| hosts|-----| GW |
| | | rtr |
+------+ | | +------+ ___________
| |port2 | | / \
| |-------| rtr2 |=====/ network \
+-----+ | | \ 2 /
+------+ \___________/
+------+ ___________
+-----+ | | / \
| |=======| rtr1 |=====/ network \
| |port1 | | \ 1 /
+------+ | | +------+ \___________/
| | | |
| hosts|-----| GW |
| | | rtr |
+------+ | | +------+ ___________
| |port2 | | / \
| |-------| rtr2 |=====/ network \
+-----+ | | \ 2 /
+------+ \___________/
Figure 2: Single Uplink, Single Next Hop, Multiple Prefix (Scenario 2)
图2：单上行链路、单下一跳、多前缀（场景2）
Figure 2 illustrates the host connected to GW rtr. GW rtr connects to networks 1 and 2 via port1 and 2, respectively. As the figure shows a logical topology of the scenario, port1 could be a pseudo-interface for tunneling, which connects to network 1 through network 2 and vice versa. When the host sends packets to either network 1 or 2, the next hop is GW rtr. When the packets are sent to network 1 (network 2), GW rtr forwards the packets to port1 (port2).
图2显示了连接到GW rtr的主机。GW rtr分别通过端口1和端口2连接到网络1和网络2。如图所示，该场景的逻辑拓扑结构表明，端口1可以是隧道的伪接口，它通过网络2连接到网络1，反之亦然。当主机向网络1或网络2发送数据包时，下一跳为GW rtr。当数据包被发送到网络1（网络2）时，GW rtr将数据包转发到端口1（端口2）。
Example: Internet + VPN / Application Service Provider (ASP)
Example: Internet + VPN / Application Service Provider (ASP)
Scenario 3:
情景3：
In this scenario, a host has more than one active interface that connects to different routers and service provider networks. Each router provides the host with a different address prefix and set of DNS recursive name servers, resulting in a host with a unique address per link/interface.
在这种情况下，主机有多个活动接口连接到不同的路由器和服务提供商网络。每个路由器为主机提供不同的地址前缀和一组DNS递归名称服务器，从而使主机在每个链路/接口上具有唯一的地址。
+------+ +------+ ___________
| | | | / \
| |-----| rtr1 |=====/ network \
| | | | \ 1 /
| | +------+ \___________/
| |
| host |
| |
| | +------+ ___________
| | | | / \
| |=====| rtr2 |=====/ network \
| | | | \ 2 /
+------+ +------+ \___________/
+------+ +------+ ___________
| | | | / \
| |-----| rtr1 |=====/ network \
| | | | \ 1 /
| | +------+ \___________/
| |
| host |
| |
| | +------+ ___________
| | | | / \
| |=====| rtr2 |=====/ network \
| | | | \ 2 /
+------+ +------+ \___________/
Figure 3: Multiple Uplink, Multiple Next Hop, Multiple Prefix (Scenario 3)
图3：多上行链路、多下一跳、多前缀（场景3）
Figure 3 illustrates the host connecting to rtr1 and rtr2 via a direct connection or a virtual link. When the host sends packets to network 1, the next hop to network 1 is rtr1. Similarly, rtr2 is the next hop to network 2.
图3显示了通过直接连接或虚拟链接连接到rtr1和rtr2的主机。当主机向网络1发送数据包时，到网络1的下一跳是rtr1。类似地，rtr2是网络2的下一跳。
Example: Mobile Wifi + 3G, ISP A + ISP B
Example: Mobile Wifi + 3G, ISP A + ISP B
In an IPv6 multihomed network, a host is assigned two or more IPv6 addresses and DNS recursive name servers from independent service provider networks. When this multihomed host attempts to connect with other hosts, it may incorrectly resolve the next-hop router, use an inappropriate source address, or use a DNS response from an incorrect service provider that may result in impaired IP connectivity.
在IPv6多宿主网络中，主机从独立的服务提供商网络分配两个或多个IPv6地址和DNS递归名称服务器。当此多宿主机尝试与其他主机连接时，它可能会错误解析下一跳路由器、使用不正确的源地址或使用来自不正确服务提供商的DNS响应，从而导致IP连接受损。
In many cases, multihomed networks in IPv4 have been implemented through the use of a gateway router with NAPT function (scenario 2 with NAPT). An analysis of the current IPv4 NAPT and DNS functions within the gateway router should provide a baseline set of
在许多情况下，IPv4中的多宿网络是通过使用具有NAPT功能的网关路由器实现的（场景2具有NAPT）。对网关路由器中当前IPv4 NAPT和DNS功能的分析应提供一组基线
requirements for IPv6 multihomed environments. A destination prefix/ route is often used on the gateway router to separate traffic between the networks.
IPv6多宿主环境的要求。网关路由器上经常使用目的地前缀/路由来分离网络之间的流量。
+------+ ___________
| | / \
+---| rtr1 |=====/ network \
| | | \ 1 /
+------+ +-----+ | +------+ \___________/
| IPv4 | | | |
| hosts|-----| GW |---+
| | | rtr | |
+------+ +-----+ | +------+ ___________
(NAPT&DNS) | | | / \
(private +---| rtr2 |=====/ network \
address | | \ 2 /
space) +------+ \___________/
+------+ ___________
| | / \
+---| rtr1 |=====/ network \
| | | \ 1 /
+------+ +-----+ | +------+ \___________/
| IPv4 | | | |
| hosts|-----| GW |---+
| | | rtr | |
+------+ +-----+ | +------+ ___________
(NAPT&DNS) | | | / \
(private +---| rtr2 |=====/ network \
address | | \ 2 /
space) +------+ \___________/
Figure 4: IPv4 Multihomed Environment with Gateway Router Performing NAPT
图4：网关路由器执行NAPT的IPv4多宿主环境
A multihomed IPv6 host has one or more assigned IPv6 addresses and DNS recursive name servers from each upstream service provider, resulting in the host having multiple valid IPv6 addresses and DNS recursive name servers. The host must be able to resolve the appropriate next hop, the correct source address, and the correct DNS recursive name server to use based on the destination prefix. To prevent IP spoofing, operators will often implement ingress filtering to discard traffic with an inappropriate source address, making it essential for the host to correctly resolve these three items before sourcing the first packet.
多宿IPv6主机具有来自每个上游服务提供商的一个或多个分配的IPv6地址和DNS递归名称服务器，从而使主机具有多个有效IPv6地址和DNS递归名称服务器。主机必须能够基于目标前缀解析要使用的适当下一跳、正确的源地址和正确的DNS递归名称服务器。为了防止IP欺骗，运营商通常会实施入口过滤，以丢弃具有不适当源地址的流量，这使得主机在获取第一个数据包之前必须正确解决这三个问题。
IPv6 has mechanisms for the provision of multiple routers on a single link and multiple address assignments to a single host. However, when these mechanisms are applied to the three scenarios described in Section 3.1, a number of connectivity issues are identified:
IPv6具有在单个链路上提供多个路由器和向单个主机分配多个地址的机制。但是，当这些机制应用于第3.1节中描述的三种场景时，会发现一些连接问题：
Scenario 1:
情景1：
The host has been assigned an address from each router and recognizes both rtr1 and rtr2 as valid default routers (in the default routers list).
主机已从每个路由器分配一个地址，并将rtr1和rtr2识别为有效的默认路由器（在默认路由器列表中）。
o The source address selection policy on the host does not deterministically resolve a source address. Ingress filtering or filter policies will discard traffic with source addresses that the operator did not assign.
o 主机上的源地址选择策略无法确定解析源地址。入口筛选或筛选策略将丢弃具有操作员未分配的源地址的流量。
o The host will select one of the two routers as the active default router. No traffic is sent to the other router.
o 主机将选择两个路由器中的一个作为活动默认路由器。没有流量发送到其他路由器。
Scenario 2:
情景2：
The host has been assigned two different addresses from the single gateway router. The gateway router is the only default router on the link.
主机已从单个网关路由器分配了两个不同的地址。网关路由器是链路上唯一的默认路由器。
o The source address selection policy on the host does not deterministically resolve a source address. Ingress filtering or filter policies will discard traffic with source addresses that the operator did not assign.
o 主机上的源地址选择策略无法确定解析源地址。入口筛选或筛选策略将丢弃具有操作员未分配的源地址的流量。
o The gateway router does not have an autonomous mechanism for determining which traffic should be sent to which network. If the gateway router is implementing host functions (i.e., processing Router Advertisement (RA)), then two valid default routers may be recognized.
o 网关路由器没有用于确定应将哪些流量发送到哪个网络的自治机制。如果网关路由器正在实现主机功能（即，处理路由器广告（RA）），则可以识别两个有效的默认路由器。
Scenario 3:
情景3：
A host has two separate interfaces, and each interface has a different address assigned. Each link has its own router.
主机有两个独立的接口，每个接口分配了不同的地址。每个链路都有自己的路由器。
o The host does not have enough information to determine which traffic should be sent to which upstream routers. The host will select one of the two routers as the active default router, and no traffic is sent to the other router. The default address selection rules select the address assigned to the outgoing interface as the source address. So, if a host has an appropriate routing table, an appropriate source address will be selected.
o 主机没有足够的信息来确定哪些流量应该发送到哪个上游路由器。主机将选择两个路由器中的一个作为活动默认路由器，并且不会向另一个路由器发送任何通信量。默认地址选择规则选择分配给传出接口的地址作为源地址。因此，如果主机具有适当的路由表，则将选择适当的源地址。
All scenarios:
所有场景：
o In network deployments utilizing local namespaces, the host may choose to communicate with a "wrong" DNS recursive server unable to serve a local namespace.
o 在使用本地名称空间的网络部署中，主机可能会选择与无法为本地名称空间提供服务的“错误”DNS递归服务器通信。
This section describes requirements that any solution multi-address and multi-uplink architectures need to meet.
本节描述了任何解决方案多地址和多上行链路架构需要满足的要求。
One of the major design goals for IPv6 is to restore the end-to-end transparency of the Internet. If NAT is applied to IP communication between hosts, NAT traversal mechanisms are required to establish bidirectional IP communication. In an environment with end-to-end transparency, a NAT traversal mechanism does not need to be implemented in an application (e.g., ICE [RFC5245]). Therefore, the IPv6 multihoming solution should strive to avoid NPTv6 to achieve end-to-end transparency.
IPv6的主要设计目标之一是恢复互联网的端到端透明度。如果NAT应用于主机之间的IP通信，则需要NAT遍历机制来建立双向IP通信。在具有端到端透明性的环境中，NAT遍历机制不需要在应用程序中实现（例如，ICE[RFC5245]）。因此，IPv6多主解决方案应努力避免NPTv6，以实现端到端的透明性。
The solution will have to be able to manage a large number of sites/ nodes. In services for residential users, provider edge devices have to manage thousands of sites. In such environments, sending packets periodically to each site may affect edge system performance.
解决方案必须能够管理大量站点/节点。在为住宅用户提供的服务中，提供商边缘设备必须管理数千个站点。在这种环境中，定期向每个站点发送数据包可能会影响边缘系统的性能。
The problems described in Section 3 can be classified into these three types:
第3节中描述的问题可分为以下三类：
o Wrong source address selection
o 错误的源地址选择
o Wrong next hop selection
o 错误的下一跳选择
o Wrong DNS server selection
o 错误的DNS服务器选择
This section reviews the problem statements presented above and the proposed functional requirements to resolve the issues.
本节回顾了上述问题陈述以及解决问题的拟议功能需求。
A multihomed IPv6 host will typically have different addresses assigned from each service provider on either the same link (scenarios 1 and 2) or different links (scenario 3). When the host wishes to send a packet to any given destination, the current source address selection rules [RFC6724] may not deterministically select the correct source address. [RFC7078] describes the use of the policy table (as discussed in [RFC6724]) to resolve this problem, using a DHCPv6 mechanism for host policy table management.
多宿IPv6主机通常会在同一链路（场景1和场景2）或不同链路（场景3）上从每个服务提供商分配不同的地址。当主机希望向任何给定目的地发送数据包时，当前源地址选择规则[RFC6724]可能无法确定地选择正确的源地址。[RFC7078]描述了使用策略表（如[RFC6724]中所述）来解决此问题，使用DHCPv6机制来管理主机策略表。
Again, by employing DHCPv6, the server could restrict address assignment (of additional prefixes) only to hosts that support policy table management.
同样，通过使用DHCPv6，服务器可以将地址分配（附加前缀）限制为仅限于支持策略表管理的主机。
Scenario 1: Host needs to support the solution for this problem.
场景1：主机需要支持此问题的解决方案。
Scenario 2: Host needs to support the solution for this problem.
场景2：主机需要支持此问题的解决方案。
Scenario 3: If Host supports the next hop selection solution, there is no need to support the address selection functionality on the host.
场景3：如果主机支持下一跳选择解决方案，则无需在主机上支持地址选择功能。
It is noted that the network's DHCP server and DHCP-forwarding routers must also support the Address Selection option [RFC7078].
请注意，网络的DHCP服务器和DHCP转发路由器还必须支持地址选择选项[RFC7078]。
A multihomed IPv6 host or gateway may have multiple uplinks to different service providers. Here, each router would use Router Advertisements [RFC4861] to distribute default route/next-hop information to the host or gateway router.
多宿IPv6主机或网关可能有多个到不同服务提供商的上行链路。这里，每个路由器将使用路由器广告[RFC4861]将默认路由/下一跳信息分发到主机或网关路由器。
In this case, the host or gateway router may select any valid default router from the default routers list, resulting in traffic being sent to the wrong router and discarded by the upstream service provider. Using the above scenarios as an example, whenever the host wishes to reach a destination in network 2 and there is no connectivity between networks 1 and 2 (as is the case for a walled-garden or closed service), the host or gateway router does not know whether to forward traffic to rtr1 or rtr2 to reach a destination in network 2. The host or gateway router may choose rtr1 as the default router, but traffic will fail to reach the destination server. The host or gateway router requires route information for each upstream service provider, but the use of a routing protocol between the gateway and the two routers causes both configuration and scaling issues. In IPv4, gateway routers are often pre-configured with static routes or use the Classless Static Route Options [RFC3442] for DHCPv4. An extension to Router Advertisements through Default Router Preference and More-Specific Routes [RFC4191] provides for link-specific preferences but does not address per-host configuration in a multi-access topology because of its reliance on Router Advertisements.
在这种情况下，主机或网关路由器可以从默认路由器列表中选择任何有效的默认路由器，从而导致流量被发送到错误的路由器并被上游服务提供商丢弃。以上述场景为例，每当主机希望到达网络2中的目的地，并且网络1和2之间没有连接时（如围墙花园或封闭服务的情况），主机或网关路由器不知道是否将流量转发到rtr1或rtr2以到达网络2中的目的地。主机或网关路由器可以选择rtr1作为默认路由器，但流量将无法到达目标服务器。主机或网关路由器需要每个上游服务提供商的路由信息，但是在网关和两个路由器之间使用路由协议会导致配置和扩展问题。在IPv4中，网关路由器通常预先配置了静态路由，或者对DHCPv4使用无类静态路由选项[RFC3442]。通过默认路由器首选项和更具体的路由[RFC4191]对路由器播发进行扩展，提供了特定于链路的首选项，但由于其依赖于路由器播发，因此在多址拓扑中不寻址每主机配置。
Scenario 1: Host needs to support the solution for this problem.
场景1：主机需要支持此问题的解决方案。
Scenario 2: GW rtr needs to support the solution for this problem.
场景2:GW rtr需要支持此问题的解决方案。
Scenario 3: Host needs to support the solution for this problem.
场景3：主机需要支持此问题的解决方案。
A multihomed IPv6 host or gateway router may be provided multiple DNS recursive name servers through DHCPv6 [RFC3646] or RA [RFC6106]. When the host or gateway router sends a DNS query, it would normally choose one of the available DNS recursive name servers for the query.
可以通过DHCPv6[RFC3646]或RA[RFC6106]向多个DNS递归名称服务器提供多宿IPv6主机或网关路由器。当主机或网关路由器发送DNS查询时，它通常会为查询选择一个可用的DNS递归名称服务器。
In the IPv6 gateway router scenario, the Broadband Forum (BBF) [TR-124] requires that the query be sent to all DNS recursive name servers and that the gateway wait for the first reply. In IPv6, given our use of specific destination-based policy for both routing and source address selection, it is desirable to extend a policy-based concept to DNS recursive name server selection. Doing so can minimize DNS recursive name server load and avoid issues where DNS recursive name servers in different networks have connectivity issues, or the DNS recursive name servers are not publicly accessible. In the worst case, a DNS query for a name from a local namespace may not be resolved correctly if sent towards a DNS server not aware of said local namespace, resulting in a lack of connectivity.
在IPv6网关路由器方案中，宽带论坛（BBF）[TR-124]要求将查询发送到所有DNS递归名称服务器，并且网关等待第一个应答。在IPv6中，由于我们对路由和源地址选择都使用了特定的基于目的地的策略，因此需要将基于策略的概念扩展到DNS递归名称服务器选择。这样做可以最小化DNS递归名称服务器负载，并避免不同网络中的DNS递归名称服务器存在连接问题，或者DNS递归名称服务器不可公开访问的问题。在最坏的情况下，如果向不知道所述本地名称空间的DNS服务器发送对来自本地名称空间的名称的DNS查询，则可能无法正确解析，从而导致缺乏连接。
It is not an issue of the Domain Name System model itself, but an IPv6 multihomed host or gateway router should have the ability to select appropriate DNS recursive name servers for each service based on the domain space for the destination, and each service should provide rules specific to that network. [RFC6731] proposes a solution for distributing DNS server selection policy using a DHCPv6 option.
这不是域名系统模型本身的问题，但IPv6多宿主主机或网关路由器应能够根据目的地的域空间为每个服务选择适当的DNS递归名称服务器，并且每个服务应提供特定于该网络的规则。[RFC6731]提出了一种使用DHCPv6选项分发DNS服务器选择策略的解决方案。
Scenario 1: Host needs to support the solution for this problem.
场景1：主机需要支持此问题的解决方案。
Scenario 2: GW rtr needs to support the solution for this problem.
场景2:GW rtr需要支持此问题的解决方案。
Scenario 3: Host needs to support the solution for this problem.
场景3：主机需要支持此问题的解决方案。
It is noted that the network's DHCP server and DHCP-forwarding routers must also support the Address Selection option [RFC6731].
注意，网络的DHCP服务器和DHCP转发路由器还必须支持地址选择选项[RFC6731]。
As mentioned in Section 5, in the multi-prefix environment, we have three problems: source address selection, next hop selection, and DNS recursive name server selection. In this section, possible solutions for each problem are introduced and evaluated against the requirements in Section 4.
如第5节所述，在多前缀环境中，我们有三个问题：源地址选择、下一跳选择和DNS递归名称服务器选择。在本节中，将介绍每个问题的可能解决方案，并根据第4节中的要求进行评估。
The problems of address selection in multi-prefix environments are summarized in [RFC5220]. When solutions are examined against the requirements in Section 4, the proactive approaches, such as the policy table distribution mechanism and the routing hints mechanism, are more appropriate in that they can propagate the network administrator's policy directly. The policy distribution mechanism has an advantage with regard to the host's protocol stack impact and the static nature of the assumed target network environment.
[RFC5220]总结了多前缀环境中的地址选择问题。当根据第4节中的要求检查解决方案时，主动方法（如策略表分发机制和路由提示机制）更合适，因为它们可以直接传播网络管理员的策略。策略分发机制在主机的协议栈影响和假定目标网络环境的静态性质方面具有优势。
As for the source address selection problem, both a policy-based approach and a non-policy-based approach are possible with regard to the next hop selection problem. Because of the same requirements, the policy propagation-based solution mechanism, whatever the policy, should be more appropriate.
对于源地址选择问题，对于下一跳选择问题，基于策略的方法和非基于策略的方法都是可能的。由于相同的需求，基于策略传播的解决方案机制，无论是何种策略，都应该更合适。
Routing information is a typical example of policy related to next hop selection. If we assume source-address-based routing at hosts or intermediate routers, pairs of source prefixes and next hops can be another example of next hop selection policy.
路由信息是与下一跳选择相关的策略的典型示例。如果我们假设主机或中间路由器上基于源地址的路由，则源前缀和下一跳对可以是下一跳选择策略的另一个示例。
The routing-information-based approach has a clear advantage in implementation and is already commonly used.
基于路由信息的方法在实现上具有明显的优势，并且已经被广泛使用。
The existing proposed or standardized routing information distribution mechanisms are routing protocols (such as Routing Information Protocol Next Generation (RIPng) and OSPFv3), the RA extension option defined in [RFC4191], and the CPE WAN Management Protocol (CWMP) [TR069] standardized at BBF.
现有提议或标准化的路由信息分发机制是路由协议（如下一代路由信息协议（RIPng）和OSPFv3）、[RFC4191]中定义的RA扩展选项以及BBF标准化的CPE WAN管理协议（CWMP）[TR069]。
The RA-based mechanism doesn't handle distribution of per-host routing information easily. Dynamic routing protocols are not typically used between residential users and ISPs, because of their scalability and security implications. The DHCPv6 mechanism does not have these problems and has the advantage of relay functionality. It is commonly used and is thus easy to deploy.
基于RA的机制不容易处理每主机路由信息的分发。动态路由协议通常不在住宅用户和ISP之间使用，因为它们具有可扩展性和安全性。DHCPv6机制没有这些问题，并且具有中继功能的优势。它是常用的，因此易于部署。
[TR069], mentioned above, defines a possible solution mechanism for routing information distribution to customer premises equipment (CPE). It assumes, however, that IP reachability to the Auto Configuration Server (ACS) has been established. Therefore, if the CPE requires routing information to reach the ACS, CWMP [TR069] cannot be used to distribute this information.
上面提到的[TR069]定义了一种可能的解决方案机制，用于将信息分发路由到客户场所设备（CPE）。但是，它假设自动配置服务器（ACS）的IP可达性已经建立。因此，如果CPE需要路由信息才能到达ACS，则CWMP[TR069]不能用于分发此信息。
Note: Split-horizon DNS is discussed in this section. Split-horizon DNS is known to cause problems with applications to allow information leakage. The discussion of split-horizon DNS is not condoning its use, but rather acknowledging that split-horizon DNS is used and that its use is another justification for network address translation. The goal of this document is to encourage building solutions that do not need network address translation. Two solutions appear possible: improve the function of split-horizon DNS (which is discussed below) or meet network administrators' requirements without split-horizon DNS (which is out of scope of this document).
注：本节将讨论拆分地平线DNS。众所周知，拆分地平线DNS会导致应用程序出现问题，从而导致信息泄漏。对拆分地平线DNS的讨论并不是纵容其使用，而是承认使用了拆分地平线DNS，并且其使用是网络地址转换的另一个理由。本文档的目标是鼓励构建不需要网络地址转换的解决方案。似乎有两种解决方案是可行的：改进拆分地平线DNS的功能（如下所述）或在不使用拆分地平线DNS的情况下满足网络管理员的要求（这超出了本文档的范围）。
As in the above two problems, a policy-based approach and a non-policy-based approach are possible. In a non-policy-based approach, a host or a home gateway router is assumed to send DNS queries to several DNS recursive name servers at once or to select one of the available servers.
正如上述两个问题一样，基于政策的方法和非基于政策的方法是可能的。在非基于策略的方法中，假设主机或家庭网关路由器一次向多个DNS递归名称服务器发送DNS查询，或选择一个可用服务器。
In the non-policy-based approach, by making a query to a DNS recursive name server in a different service provider to that which hosts the service, a user could be directed to an unexpected IP address or receive an invalid response, and thus it could not connect to the service provider's private and legitimate service. For example, some DNS recursive name servers reply with different answers depending on the source address of the DNS query, which is sometimes called "split-horizon". When the host mistakenly makes a query to a different provider's DNS recursive name server to resolve a Fully Qualified Domain Name (FQDN) of another provider's private service, and the DNS recursive name server adopts the split-horizon configuration, the queried server returns an IP address of the non-private side of the service. Another problem with this approach is that it causes unnecessary DNS traffic to the DNS recursive name servers that are visible to the users.
在非基于策略的方法中，通过对托管服务的不同服务提供商中的DNS递归名称服务器进行查询，用户可能会被定向到意外的IP地址或接收到无效响应，从而无法连接到服务提供商的私有和合法服务。例如，一些DNS递归名称服务器根据DNS查询的源地址（有时称为“拆分地平线”）使用不同的答案进行回复。当主机错误地向其他提供商的DNS递归名称服务器进行查询以解析另一提供商的专用服务的完全限定域名（FQDN），并且DNS递归名称服务器采用拆分地平线配置时，被查询的服务器返回服务的非专用端的IP地址。这种方法的另一个问题是，它会对用户可见的DNS递归名称服务器造成不必要的DNS流量。
The alternative to a policy-based approach is documented in [RFC6731], where several pairs of DNS recursive name server addresses and DNS domain suffixes are defined as part of a policy and conveyed to hosts in a new DHCP option. In an environment where there is a home gateway router, that router can act as a DNS recursive name server, interpret this option, and distribute DNS queries to the appropriate DNS servers according to the policy.
[RFC6731]中记录了基于策略的方法的替代方案，其中定义了若干对DNS递归名称服务器地址和DNS域后缀作为策略的一部分，并以新的DHCP选项传送给主机。在有家庭网关路由器的环境中，该路由器可以充当DNS递归名称服务器，解释此选项，并根据策略将DNS查询分发到适当的DNS服务器。
The authors of this document are aware of a variety of other algorithms and architectures, such as Shim6 [RFC5533] and HIP [RFC5206], that may be useful in this environment. At the time of this writing, there is not enough operational experience on which to base a recommendation. Should such operational experience become available, this document may be updated in the future.
本文档的作者了解在这种环境中可能有用的各种其他算法和体系结构，如Shim6[RFC5533]和HIP[RFC5206]。在撰写本文时，没有足够的操作经验作为建议的基础。如果有此类操作经验，本文件可能会在将来更新。
This section describes considerations to mitigate possible problems in a network that implements MHMP (described in Section 6).
本节描述了缓解实施MHMP的网络中可能出现的问题的注意事项（如第6节所述）。
In a typical IPv4 multihomed network deployment, IPv4 NAPT is practically used and it can eventually avoid assigning multiple addresses to the hosts and solve the next hop selection problem. In a similar fashion, NPTv6 can be used as a last resort for IPv6 multihomed network deployments where one needs to assign a single IPv6 address to a non-MHMP host.
在典型的IPv4多宿主网络部署中，实际使用了IPv4 NAPT，它最终可以避免为主机分配多个地址，并解决下一跳选择问题。以类似的方式，NPTv6可以作为IPv6多宿主网络部署的最后手段，在这种情况下，需要将单个IPv6地址分配给非MHMP主机。
__________
/ \
+---/ Internet \
gateway router | \ /
+------+ +---------------------+ | \__________/
| | | | | WAN1 +--+
| host |-----|LAN| Router |--------|
| | | | |NAT|WAN2+--+
+------+ +---------------------+ | __________
| / \
+---/ ASP \
\ /
\__________/
__________
/ \
+---/ Internet \
gateway router | \ /
+------+ +---------------------+ | \__________/
| | | | | WAN1 +--+
| host |-----|LAN| Router |--------|
| | | | |NAT|WAN2+--+
+------+ +---------------------+ | __________
| / \
+---/ ASP \
\ /
\__________/
Figure 5: Legacy Host
图5：遗留主机
The gateway router also has to support the two features, next hop selection and DNS server selection, shown in Section 6.
网关路由器还必须支持两个功能，下一跳选择和DNS服务器选择，如第6节所示。
The implementation and issues of NPTv6 are out of the scope of this document, but are discussed in Section 5 of [RFC6296].
NPTv6的实施和问题不在本文件范围内，但在[RFC6296]第5节中讨论。
To allow the coexistence of non-MHMP hosts and MHMP hosts (i.e., hosts supporting multi-prefix with the enhancements for the source address selection), GW rtr may need to treat those hosts separately.
为了允许非MHMP主机和MHMP主机共存（即支持多前缀的主机以及源地址选择的增强功能），GW rtr可能需要单独处理这些主机。
An idea for how to achieve this would be for GW rtr to identify the hosts, and then assign a single prefix to non-MHMP hosts and assign multiple prefixes to MHMP hosts. In this case, GW rtr can perform IPv6 NAT only for the traffic from non-MHMP hosts if its source address is not appropriate.
如何实现这一点的想法是，GW rtr识别主机，然后将单个前缀分配给非MHMP主机，并将多个前缀分配给MHMP主机。在这种情况下，如果源地址不合适，GW rtr只能对来自非MHMP主机的流量执行IPv6 NAT。
Another idea is that GW rtr could assign multiple prefixes to both hosts and perform IPv6 NAT for traffic from non-MHMP hosts if its source address is not appropriate.
另一个想法是，如果源地址不合适，GW rtr可以为两台主机分配多个前缀，并对来自非MHMP主机的流量执行IPv6 NAT。
In scenarios 1 and 3, the non-MHMP hosts can be placed behind the NAT box. In this case, the non-MHMP host can access the service through the NAT box.
在场景1和场景3中，非MHMP主机可以放置在NAT盒后面。在这种情况下，非MHMP主机可以通过NAT盒访问服务。
The implementation of identifying non-MHMP hosts and NAT policy is outside the scope of this document.
识别非MHMP主机和NAT策略的实施不在本文档的范围内。
When multiple policy distributors exist, a policy receiver may not follow each of the received policies. In particular, when a policy conflicts with another policy, a policy receiver cannot implement both of the policies. To solve or mitigate this issue, a prioritization rule is required to align the policies with the preferences of a trusted interface. Another solution is to preclude the functionality of the acceptance of multiple policies at the receiver side. In this case, a policy distributor should cooperate with other policy distributors, and a single representative provider should distribute a merged policy.
当存在多个策略分发服务器时，策略接收者可能不会遵循每个接收到的策略。特别是，当一个策略与另一个策略冲突时，策略接收者不能同时实现这两个策略。要解决或缓解此问题，需要使用优先级规则将策略与受信任接口的首选项对齐。另一个解决方案是排除在接收方接受多个策略的功能。在这种情况下，策略分发者应与其他策略分发者合作，单个代表提供程序应分发合并的策略。
This document does not presume specific recommendations for resolving policy collision. It is expected that the implementation will decide how to resolve the conflicts. If they are not resolved consistently by different implementations, that could affect interoperability and security trust boundaries. Future work is expected to address the need for consistent policy resolution to avoid interoperability and security trust boundary issues.
本文档不假定解决策略冲突的具体建议。预计实施将决定如何解决冲突。如果不同的实现不能一致地解决这些问题，则可能会影响互操作性和安全信任边界。未来的工作预计将解决一致性策略解决方案的需要，以避免互操作性和安全信任边界问题。
In today's multihomed IPv4 networks, it is difficult to resolve or coordinate conflicts between the two upstream networks. This problem persists with IPv6, no matter if the hosts use IPv6 provider-dependent or provider-independent addresses.
在当今的多宿IPv4网络中，很难解决或协调两个上游网络之间的冲突。无论主机使用IPv6提供程序相关地址还是独立于提供程序的地址，IPv6都会存在此问题。
This document requires that MHMP solutions have functions that provide policy controls. New security threats can be introduced depending on the kind and form of the policy. The threats can be categorized in two parts: the policy receiver side and the policy distributor side.
本文档要求MHMP解决方案具有提供策略控制的功能。根据策略的种类和形式，可能会引入新的安全威胁。威胁可以分为两部分：策略接收方和策略分发方。
A policy receiver may receive an evil policy from a policy distributor. A policy distributor should expect that some hosts in its network will not follow the distributed policy. At the time of this writing, there are no known methods to resolve conflicts between the host's own policy (policy receiver) and the policies of upstream providers (policy provider). As this document is analyzing the problem space, rather than proposing a solution, we note the following problems:
策略接收者可能会从策略分发者处接收恶意策略。策略分发服务器应该期望其网络中的某些主机不会遵循分布式策略。在撰写本文时，还没有已知的方法来解决主机自己的策略（策略接收方）和上游提供者（策略提供者）的策略之间的冲突。由于本文档正在分析问题空间，而不是提出解决方案，我们注意到以下问题：
Threats related to the policy distributor side:
与策略分发服务器端相关的威胁：
The service provider should expect the existence of hosts that will not obey the received policy. A possible solution is to ingress-filter those packets that do not match the distributed policy and drop them. For route selection, packet forwarding or redirection can be another possible solution. For source address selection, IPv6 NAT can be another possible solution.
服务提供商应该期望存在不遵守接收到的策略的主机。一种可能的解决方案是入口过滤那些与分布式策略不匹配的数据包并丢弃它们。对于路由选择，包转发或重定向可以是另一种可能的解决方案。对于源地址选择，IPv6 NAT可以是另一种可能的解决方案。
In a multihomed multiple-provider network, nodes in the network may be administered by different organizations. Administrators might need to control policies (and a node's behavior) independently of other administrators. Access control policies need to be in place to restrict the administrator's access to only the nodes it is authorized to control.
在多宿多提供商网络中，网络中的节点可以由不同的组织管理。管理员可能需要独立于其他管理员控制策略（以及节点的行为）。需要制定访问控制策略，将管理员的访问权限限制在其授权控制的节点上。
Threats related to the policy receiver side:
与策略接收方相关的威胁：
For the policy receiver side, who should be trusted to accept policies is a fundamental issue. How is the trust established? How can the network element be assured that it can establish that trust before the network is fully configured? If a policy receiver trusts an untrusted network, it will cause the distributing of the unwanted and unauthorized policy that is described below.
对于策略接收方来说，应该信任谁来接受策略是一个基本问题。信托是如何建立的？在网络完全配置之前，如何确保网元能够建立信任？如果策略接收者信任不受信任的网络，它将导致分发不需要的和未经授权的策略，如下所述。
A policy receiver is exposed to the threats of unauthorized policy, which can lead to session hijack, falsification, DoS, wiretapping, and phishing. Unauthorized policy here means a policy distributed from an entity that does not have rights to do so. Usually, only a site administrator and a network service provider have rights to distribute these policies in addition to IP address assignment and DNS server address notification. Regarding source address selection, unauthorized policy can expose an IP address that will not usually be exposed to an external server, which can be a privacy problem. To solve or mitigate the problem of unauthorized policy, one approach is to limit the use of these policy distribution mechanisms, as described in the Section 4.4 of [RFC6731]. For example, a policy should be preferred or accepted if delivered over a secure, trusted channel such as a cellular data connection. The proposed solutions are based on DHCP, so the limitation of local site communication, which is often used in WiFi access services, should be another solution or mitigation for this problem. For the DNS server selection issue, DNS Security (DNSSEC) can be another solution. For source address selection, the ingress filter at the network service provider router can be a solution.
策略接收者面临未经授权策略的威胁，这可能导致会话劫持、伪造、拒绝服务、窃听和网络钓鱼。此处的未授权策略是指从无权执行此操作的实体分发的策略。通常，除了IP地址分配和DNS服务器地址通知之外，只有站点管理员和网络服务提供商有权分发这些策略。关于源地址选择，未经授权的策略可能会暴露通常不会暴露给外部服务器的IP地址，这可能是一个隐私问题。为了解决或缓解未授权策略的问题，一种方法是限制这些策略分发机制的使用，如[RFC6731]第4.4节所述。例如，如果通过安全、可信的通道（如蜂窝数据连接）交付策略，则应首选或接受该策略。建议的解决方案基于DHCP，因此，WiFi接入服务中经常使用的本地站点通信限制应该是解决此问题的另一个解决方案或缓解措施。对于DNS服务器选择问题，DNS安全性（DNSSEC）可以是另一个解决方案。对于源地址选择，网络服务提供商路由器上的入口过滤器可以是一个解决方案。
Another threat is the leakage of the policy and privacy issues resulting from that. Especially when clients receive different policies from the network service provider, that difference provides hints about the host itself and can be useful to uniquely identify the host. Encryption of the communication channel and separation of the communication channel per host can be solutions for this problem.
另一个威胁是由此导致的政策泄露和隐私问题。特别是当客户端从网络服务提供商处接收到不同的策略时，这种差异提供了有关主机本身的提示，并可用于唯一标识主机。通信信道加密和每个主机的通信信道分离可以解决此问题。
The security threats related to IPv6 multihoming are described in [RFC4218].
[RFC4218]中描述了与IPv6多宿主相关的安全威胁。
The following people contributed to this document: Akiko Hattori, Arifumi Matsumoto, Frank Brockners, Fred Baker, Tomohiro Fujisaki, Jun-ya Kato, Shigeru Akiyama, Seiichi Morikawa, Mark Townsley, Wojciech Dec, Yasuo Kashimura, and Yuji Yamazaki. This document has greatly benefited from inputs by Randy Bush, Brian Carpenter, and Teemu Savolainen.
以下人士对本文件做出了贡献：服部明子、松本明夫、弗兰克·布罗克内斯、弗雷德·贝克、藤崎智博、加藤俊雅、秋山茂、森川胜一、马克·汤斯利、沃伊切赫·德克、鹿村安夫和山崎裕司。本文件从兰迪·布什、布赖恩·卡彭特和蒂姆·萨沃莱宁的投入中获益匪浅。
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and More-Specific Routes", RFC 4191, November 2005.
[RFC4191]Draves，R.和D.Thaler，“默认路由器首选项和更具体的路由”，RFC 41912005年11月。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[RFC4861]Narten，T.，Nordmark，E.，Simpson，W.，和H.Soliman，“IP版本6（IPv6）的邻居发现”，RFC 48612007年9月。
[RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix Translation", RFC 6296, June 2011.
[RFC6296]Wasserman，M.和F.Baker，“IPv6到IPv6网络前缀转换”，RFC 62962011年6月。
[RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, September 2012.
[RFC6724]Thaler，D.，Draves，R.，Matsumoto，A.，和T.Chown，“互联网协议版本6（IPv6）的默认地址选择”，RFC 67242012年9月。
[RFC6731] Savolainen, T., Kato, J., and T. Lemon, "Improved Recursive DNS Server Selection for Multi-Interfaced Nodes", RFC 6731, December 2012.
[RFC6731]Savolainen，T.，Kato，J.，和T.Lemon，“多接口节点的改进递归DNS服务器选择”，RFC 67312012年12月。
[RFC7078] Matsumoto, A., Fujisaki, T., and T. Chown, "Distributing Address Selection Policy Using DHCPv6", RFC 7078, January 2014.
[RFC7078]Matsumoto，A.，Fujisaki，T.，和T.Chown，“使用DHCPv6分发地址选择策略”，RFC 7078，2014年1月。
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001.
[RFC3022]Srisuresh，P.和K.Egevang，“传统IP网络地址转换器（传统NAT）”，RFC 3022，2001年1月。
[RFC3442] Lemon, T., Cheshire, S., and B. Volz, "The Classless Static Route Option for Dynamic Host Configuration Protocol (DHCP) version 4", RFC 3442, December 2002.
[RFC3442]Lemon，T.，Cheshire，S.，和B.Volz，“动态主机配置协议（DHCP）版本4的无类静态路由选项”，RFC 3442，2002年12月。
[RFC3582] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site-Multihoming Architectures", RFC 3582, August 2003.
[RFC3582]Abley，J.，Black，B.和V.Gill，“IPv6站点多主架构的目标”，RFC 3582，2003年8月。
[RFC3646] Droms, R., "DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, December 2003.
[RFC3646]Droms，R.，“IPv6动态主机配置协议（DHCPv6）的DNS配置选项”，RFC 36462003年12月。
[RFC4116] Abley, J., Lindqvist, K., Davies, E., Black, B., and V. Gill, "IPv4 Multihoming Practices and Limitations", RFC 4116, July 2005.
[RFC4116]Abley，J.，Lindqvist，K.，Davies，E.，Black，B.，和V.Gill，“IPv4多宿主实践和限制”，RFC 41162005年7月。
[RFC4218] Nordmark, E. and T. Li, "Threats Relating to IPv6 Multihoming Solutions", RFC 4218, October 2005.
[RFC4218]Nordmark，E.和T.Li，“与IPv6多宿主解决方案相关的威胁”，RFC 4218，2005年10月。
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960]Stewart，R.，“流控制传输协议”，RFC 49602007年9月。
[RFC5206] Nikander, P., Henderson, T., Vogt, C., and J. Arkko, "End-Host Mobility and Multihoming with the Host Identity Protocol", RFC 5206, April 2008.
[RFC5206]Nikander，P.，Henderson，T.，Vogt，C.，和J.Arkko，“使用主机身份协议的终端主机移动性和多宿”，RFC 52062008年4月。
[RFC5220] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, "Problem Statement for Default Address Selection in Multi-Prefix Environments: Operational Issues of RFC 3484 Default Rules", RFC 5220, July 2008.
[RFC5220]Matsumoto，A.，Fujisaki，T.，Hiromi，R.，和K.Kanayama，“多前缀环境中默认地址选择的问题陈述：RFC 3484默认规则的操作问题”，RFC 52202008年7月。
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010.
[RFC5245]Rosenberg，J.，“交互式连接建立（ICE）：提供/应答协议的网络地址转换器（NAT）遍历协议”，RFC 52452010年4月。
[RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming Shim Protocol for IPv6", RFC 5533, June 2009.
[RFC5533]Nordmark，E.和M.Bagnulo，“Shim6:IPv6的3级多主垫片协议”，RFC 55332009年6月。
[RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, "IPv6 Router Advertisement Options for DNS Configuration", RFC 6106, November 2010.
[RFC6106]Jeong，J.，Park，S.，Beloeil，L.，和S.Madanapalli，“DNS配置的IPv6路由器广告选项”，RFC 61062010年11月。
[TR-124] The Broadband Forum, "TR-124, Functional Requirements for Broadband Residential Gateway Devices", Issue: 2, May 2010, <http://www.broadband-forum.org/technical/download/ TR-124_Issue-2.pdf>.
[TR-124]宽带论坛，“TR-124，宽带住宅网关设备的功能要求”，发行日期：2010年5月2日<http://www.broadband-forum.org/technical/download/ TR-124_Issue-2.pdf>。
[TR069] The Broadband Forum, "TR-069, CPE WAN Management Protocol v1.1", Version: Issue 1 Amendment 2, December 2007, <http://www.broadband-forum.org/technical/download/ TR-069_Amendment-2.pdf>.
[TR069]宽带论坛，“TR-069，CPE WAN管理协议v1.1”，版本：2007年12月第1期修正案2<http://www.broadband-forum.org/technical/download/ TR-069_修正案-2.pdf>。
Authors' Addresses
作者地址
Ole Troan (editor) Cisco Oslo Norway
Ole Troan（编辑）思科奥斯陆挪威
EMail: ot@cisco.com
EMail: ot@cisco.com
David Miles Google Fiber Mountain View, CA USA
David Miles谷歌纤维山景，美国加利福尼亚州
EMail: davidmiles@google.com
EMail: davidmiles@google.com
Satoru Matsushima Softbank Telecom Tokyo Japan
松岛佐藤软银日本东京电信
EMail: satoru.matsushima@g.softbank.co.jp
EMail: satoru.matsushima@g.softbank.co.jp
Tadahisa Okimoto NTT West Osaka Japan
日本大阪西部冈本忠雄NTT
EMail: t.okimoto@west.ntt.co.jp
EMail: t.okimoto@west.ntt.co.jp
Dan Wing Cisco 170 West Tasman Drive San Jose USA
美国圣何塞西塔斯曼大道170号丹荣思科
EMail: dwing@cisco.com
EMail: dwing@cisco.com