Network Working Group J. Hagino
Request for Comments: 3178 Research Laboratory, IIJ
Category: Informational H. Snyder
Vail Systems
October 2001
Network Working Group J. Hagino
Request for Comments: 3178 Research Laboratory, IIJ
Category: Informational H. Snyder
Vail Systems
October 2001
IPv6 Multihoming Support at Site Exit Routers
在站点出口路由器上支持IPv6多宿主
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
Abstract
摘要
The document describes a mechanism for basic IPv6 multihoming support, and its operational requirements. Unlike currently-practiced IPv4 multihoming, the technique does not impact the worldwide routing table size, nor IGP (Interior Gateway Protocol) routing table size in upstream ISPs. The mechanism can be combined with more sophisticated (or complex) multihoming support mechanisms, and can be used as a foundation for other mechanisms. The document is largely based on RFC 2260 by Tony Bates.
本文档描述了基本IPv6多宿主支持的机制及其操作要求。与目前实践的IPv4多主不同，该技术不会影响全球路由表大小，也不会影响上游ISP中的IGP（内部网关协议）路由表大小。该机制可以与更复杂（或复杂）的多宿主支持机制相结合，并且可以用作其他机制的基础。该文件主要基于Tony Bates的RFC 2260。
Routing table size has been a major issue for both IPv4 and IPv6. As IPv6 addresses are 4 times larger in bit width than IPv4, the routing table size issue would have more serious negative effects on router memory usage, as well as routing table lookup performance. To cope with this problem, the IPv6 addressing architecture [Hinden, 1998] is designed to take advantage of aggregated routing announcements to reduce the number of routes in default-free zone. Also, 6bone operation guideline [Rockell, 2000] (which is the currently-practiced guideline for IPv6 network operation) suggests that ASes not announce non-aggregatable announcements to the default-free zone, if there is no special agreement with the peer.
路由表大小一直是IPv4和IPv6的主要问题。由于IPv6地址的比特宽度是IPv4的4倍，路由表大小问题将对路由器内存使用以及路由表查找性能产生更严重的负面影响。为了解决这个问题，IPv6寻址体系结构[Hinden，1998]旨在利用聚合路由公告来减少无默认区域中的路由数量。此外，6bone操作指南[Rockell，2000]（这是目前实践的IPv6网络操作指南）建议，如果与对等方没有特别协议，ASE不会向默认自由区发布不可聚合的公告。
In IPv4, a multihomed site uses either of the following techniques to achieve better reachability:
在IPv4中，多址站点使用以下任一技术来实现更好的可达性：
o Obtain a portable IPv4 address prefix, and announce it from multiple upstream providers.
o 获取一个可移植的IPv4地址前缀，并从多个上游提供商宣布它。
o Obtain a single IPv4 address prefix from ISP A, and announce it from multiple upstream providers the site is connected to.
o 从ISP a获取单个IPv4地址前缀，并从站点连接到的多个上游提供商宣布该前缀。
Since the above two methodologies effectively inject additional routes to the worldwide routing table, they have negative impact on the worldwide routing table size issue. They also are not compatible with current IPv6 operational practice.
由于上述两种方法有效地向全球路由表注入了额外的路由，因此它们对全球路由表大小问题产生了负面影响。它们也与当前的IPv6操作实践不兼容。
This document provides a way to configure site exit routers and ISP routers, so that the site can achieve better reachability from multihomed connectivity, without impacting worldwide routing table size issues. The technique uses multiple distinct IPv6 address prefixes, assigned from multiple upstream ISPs. The technique uses an already-defined routing protocol (BGP or RIPng) and tunneling of IPv6 packets; therefore, this document introduces no new protocol standard (the document describes how to operate the configuration).
本文档提供了一种配置站点出口路由器和ISP路由器的方法，以便站点可以通过多宿连接实现更好的可达性，而不会影响全球路由表大小问题。该技术使用多个不同的IPv6地址前缀，由多个上游ISP分配。该技术使用已定义的路由协议（BGP或RIPng）和IPv6数据包的隧道；因此，本文件未引入新的协议标准（本文件描述了如何操作配置）。
This document is largely based on RFC 2260 [Bates, 1998] by Tony Bates.
本文件主要基于Tony Bates的RFC 2260[Bates，1998]。
The goal of this document is to achieve better packet delivery from a site to the outside, or from the outside to the site, even when some of the site exit links are down.
本文档的目标是实现从站点到外部或从外部到站点的更好的数据包交付，即使某些站点出口链接关闭。
Non goals are:
非目标是：
o Choose the "best" exit link as possible. Note that there can be no common definition of the "best" exit link.
o 尽可能选择“最佳”退出链接。请注意，“最佳”退出链接没有通用定义。
o Achieve load-balancing between multiple exit links.
o 在多个退出链接之间实现负载平衡。
o Cope with breakage of any of the upstream ISPs.
o 应对任何上游ISP的损坏。
We use the technique described in RFC 2260 section 5.2 in our configuration. To summarize, for IPv4-only networks, RFC 2260 says that:
我们在配置中使用RFC 2260第5.2节中描述的技术。总之，对于仅IPv4网络，RFC 2260指出：
o We assume that our site is connected to 2 ISPs, ISP-A and ISP-B.
o 我们假设我们的站点连接到两个ISP，ISP-A和ISP-B。
o We are assigned IP address prefixes, Pref-A and Pref-B, from ISP-A and ISP-B respectively. Hosts near ISP-A will get an address from Pref-A, and vice versa.
o 我们分别从ISP-A和ISP-B获得IP地址前缀Pref-A和Pref-B。ISP-A附近的主机将从Pref-A获得地址，反之亦然。
o In the site, we locally exchange routes for Pref-A and Pref-B, so that hosts in the site can communicate with each other without using external link.
o 在站点中，我们在本地交换Pref-A和Pref-B的路由，以便站点中的主机可以在不使用外部链接的情况下相互通信。
o ISP-A and our site are connected by a "primary link" between ISP router ISP-BR-A and our router E-BR-A. ISP B and our site are connected by a primary link between ISP router ISP-BR-B and our router E-BR-B.
o ISP-A和我们的站点通过ISP路由器ISP-BR-A和我们的路由器E-BR-A之间的“主链路”连接。ISP B和我们的站点通过ISP路由器ISP-BR-B和我们的路由器E-BR-B之间的主链路连接。
(ISP A) (ISP B)
（ISPA）（ISPB）
ISP-BR-A ISP-BR-B
| |
|Primary link |
| |
| |
+---|-----------------------------|--+
| E-BR-A E-BR-B |
| |
| Pref-A <----------> Pref-B |
+------------------------------------+
ISP-BR-A ISP-BR-B
| |
|Primary link |
| |
| |
+---|-----------------------------|--+
| E-BR-A E-BR-B |
| |
| Pref-A <----------> Pref-B |
+------------------------------------+
o Establish a secondary link, between ISP-BR-A and E-BR-B, and ISP-BR-B and E-BR-A, respectively. The secondary link usually is an IP-over-IP tunnel. It is important to have the secondary link on top of a different medium than the primary link, so that one of them survives link failure. For example, the secondary link between ISP-BR-A and E-BR-B should go through a different medium than the primary link between ISP-BR-A and E-BR-A. If the secondary link is an IPv4-over-IPv4 tunnel, the tunnel endpoint at E-BR-A needs to be an address in Pref-A, not in Pref-B (tunneled packet needs to travel from ISP-BR-B to E-BR-A, over the primary link between ISP-BR-A and E-BR-A).
o 分别在ISP-BR-a和E-BR-B以及ISP-BR-B和E-BR-a之间建立辅助链路。辅助链路通常是IP over IP隧道。重要的是，使辅助链路位于与主链路不同的介质之上，以便其中一个链路能够在链路故障中生存。例如，ISP-BR-A和E-BR-B之间的辅助链路应通过与ISP-BR-A和E-BR-A之间的主链路不同的介质。如果辅助链路是IPv4-over-IPv4隧道，则E-BR-A处的隧道端点需要是Pref-A中的地址，而不是Pref-B中的地址（隧道数据包需要通过ISP-BR-A和E-BR-A之间的主链路从ISP-BR-B传输到E-BR-A）。
(ISP A) (ISP B)
（ISPA）（ISPB）
ISP-BR-A ISP-BR-B
| | | |
| \-----------------------+ | |
| Secondary link | | |
| +----------------------|-/ |
| | | |
| | | |
| | | |
| | | |
+---|--|----------------------|---|--+
| E-BR-A E-BR-B |
| |
| |
+------------------------------------+
ISP-BR-A ISP-BR-B
| | | |
| \-----------------------+ | |
| Secondary link | | |
| +----------------------|-/ |
| | | |
| | | |
| | | |
| | | |
+---|--|----------------------|---|--+
| E-BR-A E-BR-B |
| |
| |
+------------------------------------+
o For inbound packets, E-BR-A will advertise (1) Pref-A toward ISP-BR-A with strong preference the over primary link, and (2) Pref-B toward ISP-BR-B with weak preference over the secondary link. Similarly, E-BR-B will advertise (1) Pref-B toward ISP-BR-B with strong preference over the primary link, and (2) Pref-A toward ISP-BR-A with weak preference over the secondary link.
o 对于入站数据包，E-BR-A将通告（1）优先于主链路的ISP-BR-A和（2）优先于次链路的ISP-BR-B。类似地，E-BR-B将向ISP-BR-B播发（1）优先于主链路的Pref-B，以及（2）向ISP-BR-A播发优先于次链路的Pref-A。
Note that we always announce Pref-A to ISP-BR-A, and Pref-B to ISP-BR-B.
请注意，我们总是向ISP-BR-A和ISP-BR-B分别发布Pref-A和Pref-B。
o For outbound packets, ISP-BR-A will advertise (1) default route (or specific routes) toward E-BR-A with strong preference over the primary link, and (2) default route (or specific routes) toward E-BR-B with weak preference over the secondary link. Similarly, ISP-BR-B will advertise (1) default route (or specific routes) toward E-BR-B with strong preference over the primary link, and (2) default route (or specific routes) toward E-BR-A with weak preference over the secondary link.
o 对于出站数据包，ISP-BR-A将公布（1）向E-BR-A的默认路由（或特定路由），优先于主链路；（2）向E-BR-B的默认路由（或特定路由），优先于次链路。类似地，ISP-BR-B将公布（1）对E-BR-B的默认路由（或特定路由），优先于主链路；（2）对E-BR-A的默认路由（或特定路由），优先于次链路。
Under this configuration, both inbound and outbound packets can survive link failure on either side. Routing information with weak preference will be available as backup, for both inbound and outbound cases.
在这种配置下，入站和出站数据包都可以在任何一方的链路故障下生存。对于入站和出站情况，首选项较弱的路由信息将作为备份提供。
RFC 2260 is written for IPv4 and BGP. With IPv6 and BGP4+, or IPv6 and RIPng, similar results can be achieved, without impacting worldwide IPv6 routing table size.
RFC2260是为IPv4和BGP编写的。使用IPv6和BGP4+，或IPv6和RIPng，可以获得类似的结果，而不会影响全球IPv6路由表的大小。
In RFC 2260, we announce Pref-A toward ISP-BR-A only, and Pref-B toward ISP-BR-B only. Therefore, there will be no extra routing announcement to the outside of the site. This meets the suggestions in 6bone aggregation guidelines [Rockell, 2000]. Also, RFC 2260 does not require portable addresses.
在RFC 2260中，我们宣布Pref-A仅针对ISP-BR-A，而Pref-B仅针对ISP-BR-B。因此，将不会有额外的路由公告到网站外。这符合6bone聚合指南[Rockell，2000]中的建议。此外，RFC 2260不需要可移植地址。
In IPv4, it is usually assumed that a node will be assigned a single IPv4 address. Therefore, RFC 2260 assumed that addresses from Pref-A will be assigned to nodes near E-BR-A, and vice versa (second bullet in the previous section).
在IPv4中，通常假定节点将被分配一个IPv4地址。因此，RFC 2260假设来自Pref-A的地址将分配给E-BR-A附近的节点，反之亦然（上一节中的第二个项目符号）。
With IPv6, multiple IPv6 addresses can be assigned to a node. So we can assign (1) one address from Pref-A, (2) one address from Pref-B, or (3) addresses from both prefixes, to a single node in the site. This will allow more flexibility in node configuration.
使用IPv6，可以将多个IPv6地址分配给一个节点。因此，我们可以将（1）Pref-A中的一个地址，（2）Pref-B中的一个地址，或（3）两个前缀中的地址分配给站点中的单个节点。这将允许节点配置具有更大的灵活性。
When multiple IPv6 global addresses are assigned to an IPv6 node, source address selection must take place on packet transmissions. Source address selection itself is out of scope of the document. Refer to a separate draft [Draves, 2001] for more discussions.
将多个IPv6全局地址分配给IPv6节点时，必须在数据包传输时选择源地址。源地址选择本身超出了文档的范围。更多讨论请参考单独的草案[Draves，2001]。
One simplifying approach is to place the site's Internet hosts on separate subnets, one with addresses in Pref-A and connected to E-BR-A, the other having addresses in Pref-B and connected to E-BR-B. This approach generalizes to having E-BR-A and E-BR-B at different sites, where site A and site B have links to the Internet and to each other.
一种简化方法是将站点的Internet主机放在单独的子网上，一个地址在Pref-A中并连接到E-BR-A，另一个地址在Pref-B中并连接到E-BR-B。这种方法概括为将E-BR-A和E-BR-B放在不同的站点上，其中站点A和站点B具有到Internet和彼此的链接。
With IPv6, the primary link can be IPv6 native connectivity, RFC 2893 [Gilligan, 2000] IPv6-over-IPv4 configured tunnel, 6to4 [Carpenter, 2000] IPv6-over-IPv4 encapsulation, or some others.
使用IPv6，主链路可以是IPv6本机连接、RFC 2893[Gilligan，2000]IPv6-over-IPv4配置隧道、6to4[Carpenter，2000]IPv6-over-IPv4封装或其他一些。
If tunnel-based connectivity is used in some of primary links, administrators may want to avoid IPv6-over-IPv6 tunnels for secondary links. For example, if:
如果在某些主链路中使用基于隧道的连接，则管理员可能希望避免在辅助链路中使用IPv6-over-IPv6隧道。例如，如果：
o primary links to ISP-A and ISP-B are RFC 2893 IPv6-over-IPv4 tunnels, and
o 到ISP-A和ISP-B的主要链路是RFC 2893 IPv6-over-IPv4隧道，以及
o ISP-A, ISP-B and the site have IPv4 connectivity with each other.
o ISP-A、ISP-B和站点之间具有IPv4连接。
It makes no sense to configure a secondary link by IPv6-over-IPv6 tunnel, since it will actually be IPv6-over-IPv6-over-IPv4 tunnel. In this case, IPv6-over-IPv4 tunnel should be used for secondary link. IPv6-over-IPv4 configuration has a big advantage against IPv6-over-IPv6-over-IPv4 configuration, as secondary link will be able to have the same path MTU than the primary link.
通过IPv6-over-IPv6隧道配置辅助链路毫无意义，因为它实际上是IPv6-over-IPv6-over-IPv4隧道。在这种情况下，应将IPv6-over-IPv4隧道用于辅助链路。IPv6-over-IPv4配置相对于IPv6-over-IPv6-over-IPv4配置具有很大的优势，因为辅助链路将能够拥有与主链路相同的路径MTU。
In the figure, ISP-BR-A and E-BR-A are both single points of failure for inbound traffic to Pref-A. This could be remedied by using different routers for primary vs. backup links.
在图中，ISP-BR-A和E-BR-A都是Pref-A入站流量的单点故障。这可以通过为主链路和备份链路使用不同的路由器来解决。
The RFC 2260 approach on top of IPv6 will work fine as documented in RFC 2260. There will be no extra twists necessary. Since the multihomed site is not doing transit, variations are possible that do not require it to have a public AS number.
IPv6之上的RFC 2260方法可以很好地工作，如RFC 2260中所述。不需要额外的扭转。由于多址站点不进行传输，因此可能会出现不需要公共AS号码的变体。
It is possible to run an RFC 2260-like configuration with RIPng [Malkin, 1997] , with careful control of metric. Routers in the figure need to increase RIPng metric on the secondary link, to make the primary link a preferred path.
可以使用RIPng运行类似RFC 2260的配置[Malkin，1997]，并仔细控制度量。图中的路由器需要增加次要链路上的RIPng度量，以使主要链路成为首选路径。
If we denote the RIPng metric for route announcement, from router R1 toward router R2, as metric(R1, R2), the invariants that must hold are:
如果我们将路由公告的RIPng度量（从路由器R1到路由器R2）表示为度量（R1，R2），则必须保持的不变量为：
o metric(E-BR-A, ISP-BR-A) < metric(E-BR-B, ISP-BR-A)
o 公制（E-BR-A，ISP-BR-A）<公制（E-BR-B，ISP-BR-A）
o metric(E-BR-B, ISP-BR-B) < metric(E-BR-A, ISP-BR-B)
o 公制（E-BR-B，ISP-BR-B）<公制（E-BR-A，ISP-BR-B）
o metric(ISP-BR-A, E-BR-A) < metric(ISP-BR-A, E-BR-B)
o 公制（ISP-BR-A，E-BR-A）<公制（ISP-BR-A，E-BR-B）
o metric(ISP-BR-B, E-BR-B) < metric(ISP-BR-B, E-BR-A)
o 公制（ISP-BR-B，E-BR-B）<公制（ISP-BR-B，E-BR-A）
Note that smaller metric means stronger route in RIPng.
请注意，在RIPng中，较小的度量值意味着更强的路由。
If the upstream ISP imposes ingress filters [Ferguson, 1998] to outbound traffic, the story becomes much more complex. A packet with source address taken from Pref-A must go out from ISP-BR-A. Similarly, a packet with source address taken from Pref-B must go out from ISP-BR-B. Since none of the routers in the site network will route packets based on source address, packets can easily be routed to incorrect border router.
如果上游ISP对出站流量施加入口过滤器[Ferguson，1998]，情况会变得更加复杂。源地址取自Pref-A的数据包必须从ISP-BR-A传出。同样，源地址取自Pref-B的数据包必须从ISP-BR-B传出。由于站点网络中没有路由器会根据源地址路由数据包，数据包很容易被路由到错误的边界路由器。
One possible way is to negotiate with both ISPs, to allow both Pref-B and Pref-A to be used as source address. This approach does not work if upstream ISP of ISP-A imposes ingress filtering. Since there will be multiple levels of ISP on top of ISP-A, it will be hard to understand which upstream ISP imposes the filter. In reality, this problem will be very rare, as ingress filter is not suitable for use in large ISPs where smaller ISPs are connected beneath.
一种可能的方法是与两个ISP协商，允许Pref-B和Pref-A都用作源地址。如果ISP-A的上游ISP实施入口过滤，则此方法不起作用。由于在ISP-A之上将有多个级别的ISP，因此很难理解哪个上游ISP施加了过滤器。在现实中，这个问题将非常罕见，因为入口过滤器不适合在大型ISP中使用，在大型ISP中，较小的ISP连接在下面。
Another possibility is to use source-based routing at E-BR-A and E-BR-B. Here we assume that IPv6-over-IPv6 tunnel is used for secondary links. When an outbound packet arrives to E-BR-A with source address in Pref-B, E-BR-A will forward it to the secondary link (tunnel to ISP-BR-B) based on source-based routing decision. The packet will look like this:
另一种可能性是在E-BR-A和E-BR-B使用基于源的路由。这里我们假设IPv6-over-IPv6隧道用于辅助链路。当出站数据包到达E-BR-A且源地址在Pref-B中时，E-BR-A将根据基于源的路由决策将其转发到辅助链路（到ISP-BR-B的隧道）。数据包将如下所示：
o Outer IPv6 header: source = address of E-BR-A in Pref-A, dest = ISP-BR-B
o 外部IPv6标头：源=Pref-A中E-BR-A的地址，目的地=ISP-BR-B
o Inner IPv6 header: source = address in Pref-B, dest = final dest
o 内部IPv6标头：源=Pref-B中的地址，目的地=最终目的地
A tunneled packet will travel across ISP-BR-A toward ISP-BR-B. The packet can go through ingress filter at ISP-BR-A, since it has outer IPv6 source address in Pref-A. The packet will reach ISP-BR-B and be decapsulated before ingress filter is applied. Decapsulated packet can go through ingress filter at ISP-BR-B, since it now has source address in Pref-B (from inner IPv6 header). Notice the following facts when configuring this:
隧道数据包将穿过ISP-BR-A到达ISP-BR-B。数据包可以通过ISP-BR-A处的入口过滤器，因为它在Pref-A中有外部IPv6源地址。数据包将到达ISP-BR-B，并在应用入口过滤器之前解封。解除封装的数据包可以通过ISP-BR-B的入口过滤器，因为它现在的源地址位于Pref-B（来自内部IPv6报头）。配置时请注意以下事实：
o Not every router implements source-based routing.
o 并非每个路由器都实现基于源的路由。
o The interaction between normal routing and source-based routing at E-BR-A (and/or E-BR-B) varies by router implementations.
o E-BR-A（和/或E-BR-B）的正常路由和源路由之间的交互因路由器实现而异。
o At ISP-BR-B (and/or ISP-BR-A), the interaction between tunnel egress processing and filtering rules varies by router implementations and filter configurations.
o 在ISP-BR-B（和/或ISP-BR-A），隧道出口处理和过滤规则之间的交互因路由器实现和过滤器配置而异。
The document discussed the cases where a site has two upstream ISPs. The document can easily be extended to the cases where there are 3 or more upstream ISPs.
该文件讨论了一个站点有两个上游ISP的情况。该文件可以很容易地扩展到有3个或更多上游ISP的情况。
If you have many upstream providers, you would not make all ISPs backup each other, as it requires O(N^2) tunnels for N ISPs. Rather, it is better to make N/2 pairs of ISPs, and let each pair of ISPs
如果您有许多上游提供商，则不会让所有ISP相互备份，因为这需要为N个ISP提供O（N^2）个隧道。相反，最好是制作N/2对ISP，并让每对ISP
backup each other. It is important to pick pairs which are unlikely to be down simultaneously. In this way, number of tunnels will be O(N).
互相支援。重要的是要选择不太可能同时下降的对。这样，隧道数量将为O（N）。
Suppose that the site is very large and it has ISP links in very distant locations, such as in the United States and in Japan. In such a case, it is wiser to use this technique only among ISP links in the US, and only among ISP links in Japan. If you use this technique between ISP link A in the US and ISP link B in Japan, the secondary link makes packets travel a very long path, for example, from a host in the site in the US, to E-BR-B in Japan, to ISP-BR-B (again in Japan), and then to the final destination in the US. This may not make sense for actual use, due to excessive delay.
假设该站点非常大，并且在非常遥远的地方有ISP链接，例如在美国和日本。在这种情况下，更明智的做法是仅在美国的ISP链路中使用此技术，而仅在日本的ISP链路中使用此技术。如果在美国的ISP链路A和日本的ISP链路B之间使用此技术，则次链路会使数据包经过很长的路径，例如，从美国站点的主机到日本的E-BR-B，再到ISP-BR-B（同样在日本），然后到达美国的最终目的地。由于过度延迟，这对于实际使用可能没有意义。
Similarly, in a large site, addresses must be assigned to end nodes with great care, to minimize delays due to extra path packets may travel. It may be wiser to avoid assigning an address in a prefix assigned from Japanese ISP, to an end node in the US.
类似地，在大型站点中，必须非常小心地将地址分配给终端节点，以最大限度地减少由于额外路径数据包可能移动而造成的延迟。更明智的做法可能是避免将日本ISP分配的前缀中的地址分配给美国的终端节点。
If one of the primary links is down for a long time, administrators may want to control source address selection on end hosts so that secondary link is less likely to be used. This can be achieved by marking the unwanted prefix as deprecated. Suppose the primary link toward ISP-A has been down. You will issue router advertisement [Thomson, 1998; Narten, 1998] packets from routers, with preferred lifetime set to 0 in prefix information option for Pref-A. End hosts will consider addresses in Pref-A as deprecated, and will not use any of them as source address for future connections. If an end host in the site makes a new connection to outside, the host will use an address in Pref-B as source address, and the reply packet to the end host will travel the primary link from ISP-BR-B toward E-BR-B. A great care must be taken when you try to automate this by using router renumbering protocols [Crawford, 2000] , as the approach could lead your site into very unstable state if any of the links flap. The author does not recommend to automate it.
如果其中一个主链接长时间处于关闭状态，管理员可能希望控制终端主机上的源地址选择，以便不太可能使用辅助链接。这可以通过将不需要的前缀标记为已弃用来实现。假设通向ISP-A的主链路已断开。您将从路由器发出路由器广告[ToMSON，1998；NARTEN，1998 ]数据包，在PREF.A的前缀信息选项中，首选的生存期设置为0。终端主机将考虑PREF-A中的地址为不推荐的，并且不会将它们中的任何一个用作将来连接的源地址。如果站点中的终端主机与外部建立了新连接，则主机将使用Pref-B中的地址作为源地址，发送给终端主机的回复数据包将从ISP-BR-B的主链路传输到E-BR-B。当您尝试使用路由器重新编号协议来自动执行此操作时，必须非常小心[Crawford，2000]，由于这种方法可能会导致你的网站进入非常不稳定的状态，如果任何链接皮瓣。作者不建议将其自动化。
Some of non-goals (such as "best" exit link selection) can be achieved by combining the technique described in this document, with some other techniques. One example of the technique would be the source/destination address selection [Draves, 2001] on the end nodes.
一些非目标（如“最佳”退出链接选择）可以通过将本文档中描述的技术与一些其他技术相结合来实现。该技术的一个例子是在终端节点上选择源/目标地址[Draves，2001]。
Hal Snyder has been running the technique, with two upstream ISPs (lava.net and iijlab), using 2 RFC 2893 IPv6-over-IPv4 tunnels to each of them (in total 4 tunnels), and BGP4+ peering over them.
Hal Snyder一直在运行这项技术，两个上游ISP（lava.net和iijlab）使用2个RFC 2893 IPv6-over-IPv4隧道（总共4个隧道）和BGP4+通过它们进行窥视。
As expected, when the primary links goes down the routing switches to the secondary link within BGP hold time, i.e., we see approximately the relations:
正如预期的那样，当主链路在BGP保持时间内下行时，路由交换机到辅助链路，即，我们大致可以看到以下关系：
o (hold time - keepalive time) < failover time
o （保持时间-保持时间）<故障切换时间
o failover time < hold time
o 故障转移时间<保持时间
o failback time < keepalive time
o 回切时间<保留时间
This has been tested with keepalive and hold times from as low as 3 and 10 seconds respectively, up to 60 and 180 seconds respectively.
这已经用keepalive和hold时间分别从3秒和10秒到60秒和180秒进行了测试。
The routing change will affect ISP-BR-A (or B) only. Because route instability is not propagated beyond one ISP, it should be feasible to use lower hold and keepalive times than in a conventional IPv4 setting. If primary and backup links terminate on the same router at the ISP, then failover from primary to backup link need not affect reachability information upstream of that router.
路由更改将仅影响ISP-BR-A（或B）。由于路由不稳定性不会传播到一个ISP之外，因此使用比传统IPv4设置更低的保持和保持时间应该是可行的。如果主链路和备份链路在ISP的同一路由器上终止，则从主链路到备份链路的故障切换不必影响该路由器上游的可达性信息。
Many of the existing IPv6 networks (connected to worldwide 6bone) are assigned multiple IPv6 prefixes from multiple upstreams. In many cases people assign global IPv6 addresses generated from multiple address prefixes. There has been almost no problems raised about complication due to source address selection.
许多现有的IPv6网络（连接到全球6bone）都从多个上游分配了多个IPv6前缀。在许多情况下，人们分配由多个地址前缀生成的全局IPv6地址。由于源地址选择的复杂性，几乎没有出现任何问题。
The configuration described in the document introduces no new security problem.
文档中描述的配置没有引入新的安全问题。
If primary links toward ISP-A and ISP-B have different security characteristics (like encrypted link and non-encrypted link), administrators need to be careful setting up secondary links tunneled on them. Packets may travel an unwanted path, if secondary links are configured without care.
如果指向ISP-A和ISP-B的主链路具有不同的安全特性（如加密链路和非加密链路），则管理员需要小心设置在其上隧道传输的辅助链路。如果不小心配置了辅助链路，则数据包可能会经过不需要的路径。
References
工具书类
[Bates, 1998] Bates, T. and Y. Rekhter, "Scalable Support for Multi-homed Multi-provider Connectivity", RFC 2260, January 1998.
[Bates，1998]Bates，T.和Y.Rekhter，“多宿多提供商连接的可扩展支持”，RFC 2260，1998年1月。
[Hinden, 1998] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
[Hinden，1998]Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 23731998年7月。
[Rockell, 2000] Rockell, R. and B. Fink, "6Bone Backbone Routing Guidelines", RFC 2772, February 2000.
[Rockell，2000]Rockell，R.和B.Fink，“6Bone主干路由指南”，RFC 27722000年2月。
[Draves, 2001] Draves, R., "Default Address Selection for IPv6", Work in Progress.
[Draves，2001]Draves，R.，“IPv6的默认地址选择”，正在进行中。
[Gilligan, 2000] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", RFC 2893, August 2000.
[Gilligan，2000]Gilligan，R.和E.Nordmark，“IPv6主机和路由器的过渡机制”，RFC 28932000年8月。
[Carpenter, 2000] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
[Carpenter，2000]Carpenter，B.和K.Moore，“通过IPv4云连接IPv6域”，RFC 3056，2001年2月。
[Malkin, 1997] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, January 1997.
[Malkin，1997]Malkin，G.和R.Minnear，“IPv6的RIPng”，RFC 20801997年1月。
[Ferguson, 1998] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", RFC 2267, January 1998.
[Ferguson，1998]Ferguson，P.和D.Senie，“网络入口过滤：击败使用IP源地址欺骗的拒绝服务攻击”，RFC 2267，1998年1月。
[Thomson, 1998] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[Thomson，1998]Thomson，S.和T.Narten，“IPv6无状态地址自动配置”，RFC 24621998年12月。
[Narten, 1998] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[Narten，1998]Narten，T.，Nordmark，E.和W.Simpson，“IP版本6（IPv6）的邻居发现”，RFC 246112998年12月。
[Crawford, 2000] Crawford, M., "Router Renumbering for IPv6", RFC 2894, August 2000.
[Crawford，2000]Crawford，M.，“IPv6路由器重新编号”，RFC 28942000年8月。
Acknowledgements
致谢
The document was made possible by cooperation from people participated in JEPG-IP IPv6 multihoming study meeting (1999), people in ipngwg multihoming design team, people in WIDE/KAME project and George Tsirtsis.
通过参加JEPG-IP IPv6多宿研究会议（1999年）的人员、ipngwg多宿设计团队的人员、WIDE/KAME项目的人员和George Tsirtsis的合作，该文件得以实现。
Authors' Addresses
作者地址
Jun-ichiro itojun Hagino Research Laboratory, Internet Initiative Japan Inc. Takebashi Yasuda Bldg., 3-13 Kanda Nishiki-cho, Chiyoda-ku, Tokyo 101-0054, JAPAN
Jun ichiro itojun Hagino研究实验室，互联网倡议日本公司，日本东京千代田区神田西池町3-13号竹桥安田大厦，101-0054
Phone: +81-3-5259-6350
Fax: +81-3-5259-6351
EMail: itojun@iijlab.net
Phone: +81-3-5259-6350
Fax: +81-3-5259-6351
EMail: itojun@iijlab.net
Hal Snyder Vail Systems, Inc. 570 Lake Cook Rd, Ste 408 Deerfield, IL 60015, US
Hal Snyder Vail Systems，Inc.美国伊利诺伊州迪尔菲尔德大街408号库克湖路570号，邮编：60015
Phone: +1-312-360-8245
EMail: hal@vailsys.com
Phone: +1-312-360-8245
EMail: hal@vailsys.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。