Network Working Group A. Matsumoto
Request for Comments: 5220 T. Fujisaki
Category: Informational NTT
R. Hiromi
Intec Netcore
K. Kanayama
INTEC Systems
July 2008
Network Working Group A. Matsumoto
Request for Comments: 5220 T. Fujisaki
Category: Informational NTT
R. Hiromi
Intec Netcore
K. Kanayama
INTEC Systems
July 2008
Problem Statement for Default Address Selection in Multi-Prefix Environments: Operational Issues of RFC 3484 Default Rules
多前缀环境中默认地址选择的问题陈述：RFC 3484默认规则的操作问题
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.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Abstract
摘要
A single physical link can have multiple prefixes assigned to it. In that environment, end hosts might have multiple IP addresses and be required to use them selectively. RFC 3484 defines default source and destination address selection rules and is implemented in a variety of OSs. But, it has been too difficult to use operationally for several reasons. In some environments where multiple prefixes are assigned on a single physical link, the host using the default address selection rules will experience some trouble in communication. This document describes the possible problems that end hosts could encounter in an environment with multiple prefixes.
单个物理链接可以有多个前缀。在这种环境中，终端主机可能有多个IP地址，需要有选择地使用它们。RFC 3484定义了默认的源地址和目标地址选择规则，并在各种操作系统中实现。但是，由于几个原因，它在操作上太难使用。在某些环境中，在单个物理链路上分配了多个前缀，使用默认地址选择规则的主机将在通信中遇到一些问题。本文档描述了终端主机在具有多个前缀的环境中可能遇到的问题。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Scope of This Document .....................................3
2. Problem Statement ...............................................4
2.1. Source Address Selection ...................................4
2.1.1. Multiple Routers on a Single Interface ..............4
2.1.2. Ingress Filtering Problem ...........................5
2.1.3. Half-Closed Network Problem .........................6
2.1.4. Combined Use of Global and ULA ......................7
2.1.5. Site Renumbering ....................................8
2.1.6. Multicast Source Address Selection ..................9
2.1.7. Temporary Address Selection .........................9
2.2. Destination Address Selection .............................10
2.2.1. IPv4 or IPv6 Prioritization ........................10
2.2.2. ULA and IPv4 Dual-Stack Environment ................11
2.2.3. ULA or Global Prioritization .......................12
3. Conclusion .....................................................13
4. Security Considerations ........................................14
5. Normative References ...........................................14
1. Introduction ....................................................2
1.1. Scope of This Document .....................................3
2. Problem Statement ...............................................4
2.1. Source Address Selection ...................................4
2.1.1. Multiple Routers on a Single Interface ..............4
2.1.2. Ingress Filtering Problem ...........................5
2.1.3. Half-Closed Network Problem .........................6
2.1.4. Combined Use of Global and ULA ......................7
2.1.5. Site Renumbering ....................................8
2.1.6. Multicast Source Address Selection ..................9
2.1.7. Temporary Address Selection .........................9
2.2. Destination Address Selection .............................10
2.2.1. IPv4 or IPv6 Prioritization ........................10
2.2.2. ULA and IPv4 Dual-Stack Environment ................11
2.2.3. ULA or Global Prioritization .......................12
3. Conclusion .....................................................13
4. Security Considerations ........................................14
5. Normative References ...........................................14
In IPv6, a single physical link can have multiple prefixes assigned to it. In such cases, an end host may have multiple IP addresses assigned to an interface on that link. In the IPv4-IPv6 dual-stack environment or in a site connected to both a Unique Local Address (ULA) [RFC4193] and globally routable networks, an end host typically has multiple IP addresses. These are examples of the networks that we focus on in this document. In such an environment, an end host may encounter some communication troubles.
在IPv6中，单个物理链路可以分配多个前缀。在这种情况下，终端主机可能有多个IP地址分配给该链路上的接口。在IPv4-IPv6双栈环境中，或在连接到唯一本地地址（ULA）[RFC4193]和全局可路由网络的站点中，终端主机通常具有多个IP地址。这些是我们在本文件中重点关注的网络示例。在这种环境中，终端主机可能会遇到一些通信问题。
Inappropriate source address selection at the end host causes unexpected asymmetric routing, filtering by a router, or discarding of packets because there is no route to the host.
在终端主机上选择不适当的源地址会导致意外的不对称路由、路由器过滤或丢弃数据包，因为没有到主机的路由。
Considering a multi-prefix environment, destination address selection is also important for correct or better communication establishment.
考虑到多前缀环境，目标地址选择对于正确或更好的通信建立也很重要。
RFC 3484 [RFC3484] defines default source and destination address selection algorithms and is implemented in a variety of OSs. But, it has been too difficult to use operationally for several reasons, such as lack of an autoconfiguration method. There are some problematic cases where the hosts using the default address selection rules encounter communication troubles.
RFC 3484[RFC3484]定义了默认的源地址和目标地址选择算法，并在各种操作系统中实现。但是，由于一些原因，例如缺乏自动配置方法，它在操作上太难使用。在一些有问题的情况下，使用默认地址选择规则的主机会遇到通信问题。
This document describes the possibilities of incorrect address selection that lead to dropping packets and communication failure.
本文档描述了地址选择错误导致丢包和通信失败的可能性。
As other mechanisms already exist, the multi-homing techniques for achieving redundancy are basically out of our scope.
由于其他机制已经存在，用于实现冗余的多归宿技术基本上超出了我们的范围。
We focus on an end-site network environment and unmanaged hosts in such an environment. This is because address selection behavior at these kinds of hosts is difficult to manipulate, owing to the users' lack of knowledge, hosts' location, or massiveness of the hosts.
我们主要关注终端站点网络环境和此类环境中的非托管主机。这是因为，由于用户缺乏知识、主机的位置或主机的庞大性，这类主机上的地址选择行为很难操作。
The scope of this document is to sort out problematic cases related to address selection. It includes problems that can be solved in the framework of RFC 3484 and problems that cannot. For the latter, RFC 3484 might be modified to meet their needs, or another address selection solution might be necessary. For the former, an additional mechanism that mitigates the operational difficulty might be necessary.
本文档的范围是整理与地址选择相关的问题案例。它包括可以在RFC 3484框架内解决的问题和不能解决的问题。对于后者，可能会修改RFC 3484以满足其需要，或者可能需要另一个地址选择解决方案。对于前者，可能需要一个额外的机制来缓解操作困难。
This document also includes simple solution analysis for each problematic case. This analysis basically just focuses on whether or not the case can be solved in the framework of RFC 3484. If not, some possible solutions are described. Even if a case can be solved in the framework of RFC 3484, as mentioned above, it does not necessarily mean that there is no operational difficulty. For example, in the environment stated above, it is not a feasible solution to configure each host's policy table by hand. So, for such a solution, the difficulty of configuration is yet another common problem.
本文档还包括每个问题案例的简单解决方案分析。该分析基本上只关注是否可以在RFC 3484框架内解决该案例。如果不是，则描述一些可能的解决方案。即使如上文所述，案例可以在RFC 3484框架内解决，也不一定意味着没有操作困难。例如，在上述环境中，手动配置每个主机的策略表不是一个可行的解决方案。因此，对于这种解决方案，配置的困难是另一个常见问题。
==================
| Internet |
==================
| |
2001:db8:1000::/36 | | 2001:db8:8000::/36
+----+-+ +-+----+
| ISP1 | | ISP2 |
+----+-+ +-+----+
| |
2001:db8:1000:::/48 | | 2001:db8:8000::/48
+-----+---+ +----+----+
| Router1 | | Router2 |
+-------+-+ +-+-------+
| |
2001:db8:1000:1::/64 | | 2001:db8:8000:1::/64
| |
-----+-+-----+------
|
+-+----+ 2001:db8:1000:1::100
| Host | 2001:db8:8000:1::100
+------+
==================
| Internet |
==================
| |
2001:db8:1000::/36 | | 2001:db8:8000::/36
+----+-+ +-+----+
| ISP1 | | ISP2 |
+----+-+ +-+----+
| |
2001:db8:1000:::/48 | | 2001:db8:8000::/48
+-----+---+ +----+----+
| Router1 | | Router2 |
+-------+-+ +-+-------+
| |
2001:db8:1000:1::/64 | | 2001:db8:8000:1::/64
| |
-----+-+-----+------
|
+-+----+ 2001:db8:1000:1::100
| Host | 2001:db8:8000:1::100
+------+
Figure 1
图1
Generally speaking, there is no interaction between next-hop determination and address selection. In this example, when a host starts a new connection and sends a packet via Router1, the host does not necessarily choose address 2001:db8:1000:1::100 given by Router1 as the source address. This causes the same problem as described in the next section, "Ingress Filtering Problem".
一般来说，下一跳的确定和地址选择之间没有交互作用。在此示例中，当主机启动新连接并通过Router1发送数据包时，主机不一定选择Router1提供的地址2001:db8:1000:1:：100作为源地址。这会导致与下一节“入口过滤问题”中描述的问题相同的问题。
Solution analysis: As this case depends on next-hop selection, controlling the address selection behavior at the Host alone doesn't solve the entire problem. One possible solution for this case is adopting source-address-based routing at Router1 and Router2. Another solution may be using static routing at Router1, Router2, and the Host, and using the corresponding static address selection policy at the Host.
解决方案分析：由于这种情况取决于下一跳选择，因此仅在主机上控制地址选择行为并不能解决整个问题。对于这种情况，一种可能的解决方案是在Router1和Router2采用基于源地址的路由。另一种解决方案可能是在路由器1、路由器2和主机上使用静态路由，并在主机上使用相应的静态地址选择策略。
==================
| Internet |
==================
| |
2001:db8:1000::/36 | | 2001:db8:8000::/36
+----+-+ +-+----+
| ISP1 | | ISP2 |
+----+-+ +-+----+
| |
2001:db8:1000:::/48 | | 2001:db8:8000::/48
++-------++
| Router |
+----+----+
| 2001:db8:1000:1::/64
| 2001:db8:8000:1::/64
------+---+----------
|
+-+----+ 2001:db8:1000:1::100
| Host | 2001:db8:8000:1::100
+------+
==================
| Internet |
==================
| |
2001:db8:1000::/36 | | 2001:db8:8000::/36
+----+-+ +-+----+
| ISP1 | | ISP2 |
+----+-+ +-+----+
| |
2001:db8:1000:::/48 | | 2001:db8:8000::/48
++-------++
| Router |
+----+----+
| 2001:db8:1000:1::/64
| 2001:db8:8000:1::/64
------+---+----------
|
+-+----+ 2001:db8:1000:1::100
| Host | 2001:db8:8000:1::100
+------+
Figure 2
图2
When a relatively small site, which we call a "customer network", is attached to two upstream ISPs, each ISP delegates a network address block, which is usually /48, and a host has multiple IPv6 addresses.
当一个相对较小的站点（我们称之为“客户网络”）连接到两个上游ISP时，每个ISP代表一个网络地址块（通常为/48），并且一个主机有多个IPv6地址。
When the source address of an outgoing packet is not the one that is delegated by an upstream ISP, there is a possibility that the packet will be dropped at the ISP by its ingress filter. Ingress filtering is becoming more popular among ISPs to mitigate the damage of denial-of-service (DoS) attacks.
当传出数据包的源地址不是由上游ISP委派的地址时，数据包有可能被其入口过滤器丢弃在ISP处。为减轻拒绝服务（DoS）攻击的危害，ISP越来越流行入口过滤。
In this example, when the router chooses the default route to ISP2 and the host chooses 2001:db8:1000:1::100 as the source address for packets sent to a host (2001:db8:2000::1) somewhere on the Internet, the packets may be dropped at ISP2 because of ingress filtering.
在本例中，当路由器选择到ISP2的默认路由，并且主机选择2001:db8:1000:1:：100作为发送到Internet某处主机（2001:db8:2000:：1）的数据包的源地址时，由于入口过滤，数据包可能会在ISP2处丢弃。
Solution analysis: One possible solution for this case is adopting source-address-based routing at the Router. Another solution may be using static routing at the Router, and using the corresponding static address selection policy at the Host.
解决方案分析：对于这种情况，一种可能的解决方案是在路由器上采用基于源地址的路由。另一种解决方案可能是在路由器上使用静态路由，并在主机上使用相应的静态地址选择策略。
You can see a second typical source address selection problem in a multi-homed site with global half-closed connectivity, as shown in the figure below. In this case, Host-A is in a multi-homed network and has two IPv6 addresses, one delegated from each of the upstream ISPs. Note that ISP2 is a closed network and does not have connectivity to the Internet.
在具有全局半封闭连接的多宿站点中，您可以看到第二个典型的源地址选择问题，如下图所示。在这种情况下，主机A位于多宿网络中，具有两个IPv6地址，其中一个由每个上游ISP委派。请注意，ISP2是一个封闭网络，无法连接到Internet。
+--------+
| Host-C | 2001:db8:a000::1
+-----+--+
|
============== +--------+
| Internet | | Host-B | 2001:db8:8000::1
============== +--------+
| |
2001:db8:1000:/36 | | 2001:db8:8000::/36
+----+-+ +-+---++
| ISP1 | | ISP2 | (Closed Network/VPN tunnel)
+----+-+ +-+----+
| |
2001:db8:1000:/48 | | 2001:db8:8000::/48
++-------++
| Router |
+----+----+
| 2001:db8:1000:1::/64
| 2001:db8:8000:1::/64
------+---+----------
|
+--+-----+ 2001:db8:1000:1::100
| Host-A | 2001:db8:8000:1::100
+--------+
+--------+
| Host-C | 2001:db8:a000::1
+-----+--+
|
============== +--------+
| Internet | | Host-B | 2001:db8:8000::1
============== +--------+
| |
2001:db8:1000:/36 | | 2001:db8:8000::/36
+----+-+ +-+---++
| ISP1 | | ISP2 | (Closed Network/VPN tunnel)
+----+-+ +-+----+
| |
2001:db8:1000:/48 | | 2001:db8:8000::/48
++-------++
| Router |
+----+----+
| 2001:db8:1000:1::/64
| 2001:db8:8000:1::/64
------+---+----------
|
+--+-----+ 2001:db8:1000:1::100
| Host-A | 2001:db8:8000:1::100
+--------+
Figure 3
图3
You do not need two physical network connections here. The connection from the Router to ISP2 can be a logical link over ISP1 and the Internet.
这里不需要两个物理网络连接。从路由器到ISP2的连接可以是通过ISP1和Internet的逻辑链路。
When Host-A starts the connection to Host-B in ISP2, the source address of a packet that has been sent will be the one delegated from ISP2 (that is, 2001:db8:8000:1::100) because of rule 8 (longest matching prefix) in RFC 3484.
当主机A在ISP2中启动与主机B的连接时，由于RFC 3484中的规则8（最长匹配前缀），已发送数据包的源地址将是从ISP2（即，2001:db8:8000:1:：100）委派的地址。
Host-C is located somewhere on the Internet and has IPv6 address
2001:db8:a000::1. When Host-A sends a packet to Host-C, the longest
matching algorithm chooses 2001:db8:8000:1::100 for the source
Host-C is located somewhere on the Internet and has IPv6 address
2001:db8:a000::1. When Host-A sends a packet to Host-C, the longest
matching algorithm chooses 2001:db8:8000:1::100 for the source
address. In this case, the packet goes through ISP1 and may be filtered by ISP1's ingress filter. Even if the packet is not filtered by ISP1, a return packet from Host-C cannot possibly be delivered to Host-A because the return packet is destined for 2001: db8:8000:1::100, which is closed from the Internet.
住址在这种情况下，数据包通过ISP1，并可能被ISP1的入口过滤器过滤。即使数据包没有被ISP1过滤，来自主机C的返回数据包也不可能被传送到主机a，因为返回数据包的目的地是2001:db8:8000:1:：100，这是从Internet关闭的。
The important point is that each host chooses a correct source address for a given destination address. To solve this kind of network-policy-based address selection problem, it is likely that delivering additional information to a node provides a better solution than using algorithms that are local to the node.
重要的一点是，每个主机为给定的目标地址选择正确的源地址。为了解决这种基于网络策略的地址选择问题，向节点提供附加信息可能比使用节点本地算法提供更好的解决方案。
Solution analysis: This problem can be solved in the RFC 3484 framework. For example, configuring some address selection policies into Host-A's RFC 3484 policy table can solve this problem.
解决方案分析：这个问题可以在RFC3484框架中解决。例如，将一些地址选择策略配置到Host-A的RFC 3484策略表中可以解决此问题。
============
| Internet |
============
|
|
+----+----+
| ISP |
+----+----+
|
2001:db8:a::/48 |
+----+----+
| Router |
+-+-----+-+
| | 2001:db8:a:100::/64
fd01:2:3:200:/64 | | fd01:2:3:100:/64
-----+--+- -+--+----
| |
fd01:2:3:200::101 | | 2001:db8:a:100::100
+----+----+ +-+----+ fd01:2:3:100::100
| Printer | | Host |
+---------+ +------+
============
| Internet |
============
|
|
+----+----+
| ISP |
+----+----+
|
2001:db8:a::/48 |
+----+----+
| Router |
+-+-----+-+
| | 2001:db8:a:100::/64
fd01:2:3:200:/64 | | fd01:2:3:100:/64
-----+--+- -+--+----
| |
fd01:2:3:200::101 | | 2001:db8:a:100::100
+----+----+ +-+----+ fd01:2:3:100::100
| Printer | | Host |
+---------+ +------+
Figure 4
图4
As RFC 4864 [RFC4864] describes, using a ULA may be beneficial in some scenarios. If the ULA is used for internal communication, packets with the ULA need to be filtered at the Router.
正如RFC 4864[RFC4864]所描述的，在某些场景中使用ULA可能是有益的。如果ULA用于内部通信，则需要在路由器上过滤带有ULA的数据包。
This case does not presently create an address selection problem because of the dissimilarity between the ULA and the global unicast address. The longest matching rule of RFC 3484 chooses the correct address for both intra-site and extra-site communication.
由于ULA和全局单播地址之间的不同，这种情况目前不会产生地址选择问题。RFC 3484的最长匹配规则为站点内和站点外通信选择正确的地址。
In the future, however, there is a possibility that the longest matching rule will not be able to choose the correct address anymore. That is the moment when the assignment of those global unicast addresses starts, where the first bit is 1. In RFC 4291 [RFC4291], almost all address spaces of IPv6, including those whose first bit is 1, are assigned as global unicast addresses.
但是，在将来，最长的匹配规则可能无法再选择正确的地址。这是开始分配这些全局单播地址的时刻，其中第一位是1。在RFC 4291[RFC4291]中，几乎所有IPv6地址空间（包括第一位为1的地址空间）都被指定为全局单播地址。
Namely, when we start to assign a part of the address block 8000::/1 as the global unicast address and that part is used somewhere in the Internet, the longest matching rule ceases to function properly for the people trying to connect to the servers with those addresses.
也就是说，当我们开始将地址块8000:：/1的一部分指定为全局单播地址，并且该部分在Internet中的某个位置使用时，对于试图使用这些地址连接到服务器的用户，最长匹配规则将停止正常工作。
For example, when the destination host has an IPv6 address 8000::1, and the originating host has 2001:db8:a:100::100 and fd01:2:3:100::100, the source address will be fd01:2:3:100::100, because the longest matching bit length is 0 for 2001:db8:a:100::100 and 1 for fd01:2:3:100::100, respectively.
例如，当目标主机的IPv6地址为8000:：1，而源主机的IPv6地址为2001:db8:a:100:：100和fd01:2:3:100:：100时，源地址将为fd01:2:3:100:：100，因为2001:db8:a:100:：100的最长匹配位长度分别为0，fd01:2:3:100:：100的最长匹配位长度分别为1。
Solution analysis: This problem can be solved in the RFC 3484 framework. For example, configuring some address selection policies into the Host's RFC 3484 policy table can solve this problem. Another solution is to modify RFC 3484 and define ULA's scope smaller than the global scope.
解决方案分析：这个问题可以在RFC3484框架中解决。例如，将某些地址选择策略配置到主机的RFC 3484策略表中可以解决此问题。另一个解决方案是修改RFC 3484并定义小于全局范围的ULA范围。
RFC 4192 [RFC4192] describes a recommended procedure for renumbering a network from one prefix to another. An autoconfigured address has a lifetime, so by stopping advertisement of the old prefix, the autoconfigured address is eventually invalidated.
RFC 4192[RFC4192]描述了将网络从一个前缀重新编号到另一个前缀的推荐程序。自动配置的地址有一个生存期，因此通过停止旧前缀的播发，自动配置的地址最终会失效。
However, invalidating the old prefix takes a long time. You cannot stop routing to the old prefix as long as the old prefix is not removed from the host. This can be a tough issue for ISP network administrators.
但是，使旧前缀无效需要很长时间。只要未从主机中删除旧前缀，就无法停止路由到旧前缀。对于ISP网络管理员来说，这可能是一个棘手的问题。
There is a technique of advertising the prefix with the preferred lifetime zero; however, RFC 4862 [RFC4862], Section 5.5.4, does not absolutely prohibit the use of a deprecated address for a new outgoing connection due to limitations on the capabilities of applications.
有一种技术是用首选寿命为零的前缀进行广告宣传；但是，RFC 4862[RFC4862]第5.5.4节并没有绝对禁止将不推荐的地址用于新的传出连接，因为应用程序的功能受到限制。
+-----+---+
| Router |
+----+----+
| 2001:db8:b::/64 (new)
| 2001:db8:a::/64 (old)
------+---+----------
|
+--+---+ 2001:db8:b::100 (new)
| Host | 2001:db8:a::100 (old)
+------+
+-----+---+
| Router |
+----+----+
| 2001:db8:b::/64 (new)
| 2001:db8:a::/64 (old)
------+---+----------
|
+--+---+ 2001:db8:b::100 (new)
| Host | 2001:db8:a::100 (old)
+------+
Figure 5
图5
Solution analysis: This problem can be mitigated in the RFC 3484 framework. For example, configuring some address selection policies into the Host's RFC 3484 policy table can solve this problem.
解决方案分析：这个问题可以在RFC3484框架中得到缓解。例如，将某些地址选择策略配置到主机的RFC 3484策略表中可以解决此问题。
This case is an example of site-local or global unicast prioritization. When you send a multicast packet across site borders, the source address of the multicast packet should be a globally routable address. The longest matching algorithm, however, selects a ULA if the sending host has both a ULA and a Global Unicast Address.
此案例是站点本地或全局单播优先级排序的示例。当您跨站点边界发送多播数据包时，多播数据包的源地址应为全局可路由地址。然而，如果发送主机同时具有ULA和全局单播地址，则最长匹配算法选择ULA。
Solution analysis: This problem can be solved in the RFC 3484 framework. For example, configuring some address selection policies into the sending host's RFC 3484 policy table can solve this problem.
解决方案分析：这个问题可以在RFC3484框架中解决。例如，将一些地址选择策略配置到发送主机的RFC 3484策略表中可以解决此问题。
RFC 3041 [RFC3041] defines a Temporary Address. The usage of a Temporary Address has both pros and cons. It is good for viewing web pages or communicating with the general public, but it is bad for a service that uses address-based authentication and for logging purposes.
RFC 3041[RFC3041]定义了一个临时地址。使用临时地址既有好处也有坏处。它有利于查看网页或与普通公众通信，但对于使用基于地址的身份验证和日志记录的服务则不好。
If you could turn the temporary address on and off, that would be better. If you could switch its usage per service (destination address), that would also be better. The same situation can be found when using an HA (home address) and a CoA (care-of address) in a Mobile IPv6 [RFC3775] network.
如果你能打开和关闭临时地址，那就更好了。如果您可以切换每个服务（目标地址）的使用情况，那也会更好。在移动IPv6[RFC3775]网络中使用HA（家庭地址）和CoA（转交地址）时，也会出现同样的情况。
Section 6 ("Future Work") of RFC 3041 discusses that an API extension might be necessary to achieve a better address selection mechanism with finer granularity.
RFC3041的第6节（“未来工作”）讨论了可能需要API扩展来实现更细粒度的更好的地址选择机制。
Solution analysis: This problem cannot be solved in the RFC 3484 framework. A possible solution is to make applications to select desirable addresses by using the IPv6 Socket API for Source Address Selection defined in RFC 5014 [RFC5014].
解决方案分析：在RFC 3484框架中无法解决此问题。一种可能的解决方案是让应用程序通过使用IPv6套接字API来选择RFC 5014[RFC5014]中定义的源地址选择，从而选择所需的地址。
The default policy table gives IPv6 addresses higher precedence than IPv4 addresses. There seem to be many cases, however, where network administrators want to control the address selection policy of end hosts so that it is the other way around.
默认策略表为IPv6地址提供了高于IPv4地址的优先级。然而，在许多情况下，网络管理员希望控制终端主机的地址选择策略，从而实现相反的目的。
+---------+
| Tunnel |
| Service |
+--+---++-+
| ||
| ||
===========||==
| Internet || |
===========||==
| ||
192.0.2.0/24 | ||
+----+-+ ||
| ISP | ||
+----+-+ ||
| ||
IPv4 (Native) | || IPv6 (Tunnel)
192.0.2.0/26 | ||
++-----++-+
| Router |
+----+----+
| 2001:db8:a:1::/64
| 192.0.2.0/28
|
------+---+----------
|
+-+----+ 2001:db8:a:1::100
| Host | 192.0.2.2
+------+
+---------+
| Tunnel |
| Service |
+--+---++-+
| ||
| ||
===========||==
| Internet || |
===========||==
| ||
192.0.2.0/24 | ||
+----+-+ ||
| ISP | ||
+----+-+ ||
| ||
IPv4 (Native) | || IPv6 (Tunnel)
192.0.2.0/26 | ||
++-----++-+
| Router |
+----+----+
| 2001:db8:a:1::/64
| 192.0.2.0/28
|
------+---+----------
|
+-+----+ 2001:db8:a:1::100
| Host | 192.0.2.2
+------+
Figure 6
图6
In the figure above, a site has native IPv4 and tunneled IPv6 connectivity. Therefore, the administrator may want to set a higher priority for using IPv4 than for using IPv6 because the quality of the tunnel network seems to be worse than that of the native transport.
在上图中，站点具有本机IPv4和隧道IPv6连接。因此，管理员可能希望为使用IPv4设置比使用IPv6更高的优先级，因为隧道网络的质量似乎比本机传输的质量差。
Solution analysis: This problem can be solved in the RFC 3484 framework. For example, configuring some address selection policies into the Host's RFC 3484 policy table can solve this problem.
解决方案分析：这个问题可以在RFC3484框架中解决。例如，将某些地址选择策略配置到主机的RFC 3484策略表中可以解决此问题。
This is a special form of IPv4 and IPv6 prioritization. When an enterprise has IPv4 Internet connectivity but does not yet have IPv6 Internet connectivity, and the enterprise wants to provide site-local IPv6 connectivity, a ULA is the best choice for site-local IPv6
这是IPv4和IPv6优先级划分的一种特殊形式。当企业具有IPv4 Internet连接但尚未具有IPv6 Internet连接，并且企业希望提供站点本地IPv6连接时，ULA是站点本地IPv6的最佳选择
connectivity. Each employee host will have both an IPv4 global or private address and a ULA. Here, when this host tries to connect to Host-B that has registered both A and AAAA records in the DNS, the host will choose AAAA as the destination address and the ULA for the source address. This will clearly result in a connection failure.
连通性每个员工主机将同时具有IPv4全局或专用地址和ULA。这里，当此主机尝试连接到在DNS中同时注册了A和AAAA记录的主机B时，主机将选择AAAA作为目标地址，选择ULA作为源地址。这显然会导致连接故障。
+--------+
| Host-B | AAAA = 2001:db8::80
+-----+--+ A = 192.0.2.1
|
============
| Internet |
============
| no IPv6 connectivity
+----+----+
| Router |
+----+----+
|
| fd01:2:3::/48 (ULA)
| 192.0.2.128/25
++--------+
| Router |
+----+----+
| fd01:2:3:4::/64 (ULA)
| 192.0.2.240/28
------+---+----------
|
+-+------+ fd01:2:3:4::100 (ULA)
| Host-A | 192.0.2.245
+--------+
+--------+
| Host-B | AAAA = 2001:db8::80
+-----+--+ A = 192.0.2.1
|
============
| Internet |
============
| no IPv6 connectivity
+----+----+
| Router |
+----+----+
|
| fd01:2:3::/48 (ULA)
| 192.0.2.128/25
++--------+
| Router |
+----+----+
| fd01:2:3:4::/64 (ULA)
| 192.0.2.240/28
------+---+----------
|
+-+------+ fd01:2:3:4::100 (ULA)
| Host-A | 192.0.2.245
+--------+
Figure 7
图7
Solution analysis: This problem can be solved in the RFC 3484 framework. For example, configuring some address selection policies into Host-A's RFC 3484 policy table can solve this problem.
解决方案分析：这个问题可以在RFC3484框架中解决。例如，将一些地址选择策略配置到Host-A的RFC 3484策略表中可以解决此问题。
Differentiating services by the client's source address is very common. IP-address-based authentication is a typical example of this. Another typical example is a web service that has pages for the public and internal pages for employees or involved parties. Yet another example is DNS zone splitting.
根据客户的源地址区分服务是非常常见的。基于IP地址的身份验证就是一个典型的例子。另一个典型的例子是一个web服务，它有公共页面和员工或相关方的内部页面。另一个例子是DNS区域分割。
However, a ULA and an IPv6 global address both have global scope, and RFC 3484 default rules do not specify which address should be given priority. This point makes IPv6 implementation of address-based service differentiation a bit harder.
但是，ULA和IPv6全局地址都具有全局作用域，RFC 3484默认规则没有指定哪个地址应具有优先级。这一点使得基于地址的服务差异化的IPv6实现更加困难。
+--------+
| Host-B |
+-+--|---+
| |
===========|==
| Internet | |
===========|==
| |
| |
+----+-+ +-->+------+
| ISP +------+ DNS | 2001:db8:a::80
+----+-+ +-->+------+ fc12:3456:789a::80
| |
2001:db8:a::/48 | |
fc12:3456:789a::/48 | |
+----+----|+
| Router ||
+---+-----|+
| | 2001:db8:a:100::/64
| | fc12:3456:789a:100::/64
--+-+---|-----
| |
+-+---|--+ 2001:db8:a:100::100
| Host-A | fc12:3456:789a:100::100
+--------+
+--------+
| Host-B |
+-+--|---+
| |
===========|==
| Internet | |
===========|==
| |
| |
+----+-+ +-->+------+
| ISP +------+ DNS | 2001:db8:a::80
+----+-+ +-->+------+ fc12:3456:789a::80
| |
2001:db8:a::/48 | |
fc12:3456:789a::/48 | |
+----+----|+
| Router ||
+---+-----|+
| | 2001:db8:a:100::/64
| | fc12:3456:789a:100::/64
--+-+---|-----
| |
+-+---|--+ 2001:db8:a:100::100
| Host-A | fc12:3456:789a:100::100
+--------+
Figure 8
图8
Solution analysis: This problem can be solved in the RFC 3484 framework. For example, configuring some address selection policies into Host-A's RFC 3484 policy table can solve this problem.
解决方案分析：这个问题可以在RFC3484框架中解决。例如，将一些地址选择策略配置到Host-A的RFC 3484策略表中可以解决此问题。
We have covered problems related to destination or source address selection. These problems have their roots in the situation where end hosts have multiple IP addresses. In this situation, every end host must choose an appropriate destination and source address; this choice cannot be achieved only by routers.
我们已经讨论了与目标地址或源地址选择相关的问题。这些问题的根源在于终端主机具有多个IP地址的情况。在这种情况下，每个终端主机必须选择合适的目的地和源地址；这种选择不能仅通过路由器实现。
It should be noted that end hosts must be informed about routing policies of their upstream networks for appropriate address selection. A site administrator must consider every possible address false-selection problem and take countermeasures beforehand.
应该注意的是，终端主机必须了解其上游网络的路由策略，以便进行适当的地址选择。网站管理员必须考虑每一个可能的地址错误选择问题，并预先采取对策。
When an intermediate router performs policy routing (e.g., source-address-based routing), inappropriate address selection causes unexpected routing. For example, in the network described in Section 2.1.3, when Host-A uses a default address selection policy and chooses an inappropriate address, a packet sent to a VPN can be delivered to a location via the Internet. This issue can lead to packet eavesdropping or session hijack. However, sending the packet back to the correct path from the attacker to the node is not easy, so these two risks are not serious.
当中间路由器执行策略路由（例如，基于源地址的路由）时，不适当的地址选择会导致意外路由。例如，在第2.1.3节所述的网络中，当主机A使用默认地址选择策略并选择了不适当的地址时，发送到VPN的数据包可以通过互联网发送到某个位置。此问题可能导致数据包窃听或会话劫持。但是，将数据包发送回从攻击者到节点的正确路径并不容易，因此这两个风险并不严重。
As documented in the Security Considerations section of RFC 3484, address selection algorithms expose a potential privacy concern. When a malicious host can make a target host perform address selection (for example, by sending an anycast or multicast packet), the malicious host can get knowledge of multiple addresses attached to the target host. In a case like Section 2.1.4, if an attacker can make the Host to send a multicast packet and the Host performs the default address selection algorithm, the attacker may be able to determine the ULAs attached to the host.
如RFC 3484的安全注意事项部分所述，地址选择算法暴露了潜在的隐私问题。当恶意主机可以使目标主机执行地址选择（例如，通过发送选播或多播数据包）时，恶意主机可以获得连接到目标主机的多个地址的信息。在类似第2.1.4节的情况下，如果攻击者可以让主机发送多播数据包，并且主机执行默认地址选择算法，则攻击者可能能够确定连接到主机的ULA。
These security risks have roots in inappropriate address selection. Therefore, if a countermeasure is taken, and hosts always select an appropriate address that is suitable to a site's network structure and routing, these risks can be avoided.
这些安全风险的根源在于地址选择不当。因此，如果采取对策，并且主机总是选择适合站点网络结构和路由的适当地址，则可以避免这些风险。
[RFC3041] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[RFC3041]Narten，T.和R.Draves，“IPv6中无状态地址自动配置的隐私扩展”，RFC 3041，2001年1月。
[RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3484]Draves，R.，“互联网协议版本6（IPv6）的默认地址选择”，RFC 3484，2003年2月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775]Johnson，D.，Perkins，C.，和J.Arkko，“IPv6中的移动支持”，RFC 37752004年6月。
[RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for Renumbering an IPv6 Network without a Flag Day", RFC 4192, September 2005.
[RFC4192]Baker，F.，Lear，E.，和R.Droms，“在没有国旗日的情况下对IPv6网络重新编号的程序”，RFC 41922005年9月。
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005.
[RFC4193]Hinden，R.和B.Haberman，“唯一本地IPv6单播地址”，RFC 41932005年10月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291]Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 42912006年2月。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.
[RFC4862]Thomson，S.，Narten，T.，和T.Jinmei，“IPv6无状态地址自动配置”，RFC 48622007年9月。
[RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and E. Klein, "Local Network Protection for IPv6", RFC 4864, May 2007.
[RFC4864]Van de Velde，G.，Hain，T.，Droms，R.，Carpenter，B.，和E.Klein，“IPv6的本地网络保护”，RFC 4864，2007年5月。
[RFC5014] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6 Socket API for Source Address Selection", RFC 5014, September 2007.
[RFC5014]Nordmark，E.，Chakrabarti，S.，和J.Laganier，“用于源地址选择的IPv6套接字API”，RFC 50142007年9月。
Authors' Addresses
作者地址
Arifumi Matsumoto NTT PF Lab Midori-Cho 3-9-11 Musashino-shi, Tokyo 180-8585 Japan
松本明文NTT PF实验室Midori Cho 3-9-11武藏野市，日本东京180-8585
Phone: +81 422 59 3334
EMail: arifumi@nttv6.net
Phone: +81 422 59 3334
EMail: arifumi@nttv6.net
Tomohiro Fujisaki NTT PF Lab Midori-Cho 3-9-11 Musashino-shi, Tokyo 180-8585 Japan
藤崎智宏NTT PF实验室Midori Cho 3-9-11武藏野市，东京180-8585日本
Phone: +81 422 59 7351
EMail: fujisaki@nttv6.net
Phone: +81 422 59 7351
EMail: fujisaki@nttv6.net
Ruri Hiromi Intec Netcore, Inc. Shinsuna 1-3-3 Koto-ku, Tokyo 136-0075 Japan
日本东京新宿1-3-3 Koto-ku，Ruri Hiromi Intec Netcore，Inc.日本东京136-0075
Phone: +81 3 5665 5069
EMail: hiromi@inetcore.com
Phone: +81 3 5665 5069
EMail: hiromi@inetcore.com
Ken-ichi Kanayama INTEC Systems Institute, Inc. Shimoshin-machi 5-33 Toyama-shi, Toyama 930-0804 Japan
Ken ichi Kanayama INTEC Systems Institute，Inc.Shimoshin machi 5-33富山市，富山930-0804日本
Phone: +81 76 444 8088
EMail: kanayama_kenichi@intec-si.co.jp
Phone: +81 76 444 8088
EMail: kanayama_kenichi@intec-si.co.jp
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（2008年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.