RFC6724 IPv6默认地址选择-2012

RFC6724 IPv6默认地址选择

2012

该备忘录状态：

本文档为Internet标准跟踪文档。

本文档是互联网工程特别工作组（IETF）的产品。它代表了IETF社区的共识。它得到了公众的评审，并被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参阅RFC 5741第2节。

有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问：

/info/rfc6724。

概述：

本文档描述了两种算法，一种用于源地址选择，另一种用于目的地址选择。算法为所有IPv6的实现指定了默认行为。本文档中的算法并不覆盖应用或上层协议作出的选择，也不能排除其他更高级的地址选择机制。这两种算法公用相同的上下文，包括允许系统管理员提供可选的机制，用于提供覆盖默认行为的策略。在双栈实现中，目的地址选择算法能够同时考虑IPv4和IPv6地址--取决于可用的源地址，算法可以使得IPv6地址优先级高于IPv4地址，反之亦然。

本规范中定义的默认地址选择算法适用于所有IPv6节点，包括主机和路由器。本文档废弃了RFC3484。

修订记录

目录

目录 (3)

1引言 (5)

1.1本文档约定 (6)

2算法运行的上下文 (6)

2.1策略表 (8)

2.2公共前缀长度 (9)

3地址属性 (9)

3.1范围比较 (9)

3.2IPv4地址和IPv4映射地址 (10)

3.3其他内嵌IPv4地址的IPv6地址 (10)

3.4IPv6环回地址和其他格式的前缀 (11)

3.5可移动地址 (11)

4候选源地址 (11)

5源地址选择 (12)

6目的地址选择 (15)

7与路由的交互 (17)

8实现考虑 (18)

9安全考虑 (18)

10示例 (19)

10.1默认源地址选择 (19)

10.2默认目的地址选择 (20)

10.3为IPv6或IPv4配置优先级 (22)

10.3.1处理故障的（Broken）IPv6 (23)

10.4为链路本地地址配置优先级 (23)

10.5配置多宿主站点 (24)

10.6配置ULA优先级 (26)

10.7配置6to4优先级 (27)

11参考文档 (28)

11.1Normative References (28)

11.2Informative References (29)

附录A:致谢 (30)

附录B：自RFC3484的变更 (31)

作者信息 (33)

1引言

IPv6地址架构[RFC4291]允许单个接口配置多个IP地址。这些地址可以具有不同的可达性范围（链路本地、站点本地、或者全球），这些地址也可以是“首选的”或者“降级的”[RFC4862]。处于隐私考虑引入了“公网地址”和“临时地址”的概念[RFC4941]。移动架构引入了“归属地址(home addresses)”和“转交地址(care-of addresses)”[RFC6275]。此外，多宿主情形下将会导致一个节点具有多个地址。比如，节点可以具有多个接口，其中某些是隧道或虚接口，或者一个站点可能有多个ISP接入，每个ISP接入有一个全球前缀。

结果是，IPv6实现在发起通信时，将面对多个可能的源或目的地址。因此，期望一个默认的算法，可以支持多种实现，用于选择源和目的地址，使得开发者和管理员可以对系统的行为进行推理和预测。

进一步，同时支持IPv4和IPv6的双栈或混合栈的实现，比如，当DNS域名同时解析出IPv6和IPv4地址并且网络协议栈同时有可用的IPv4和IPv6源地址，通常在发起通讯时，需要在IPv6和IPv4地址间做出选择。在这种情况下，简单的总是首选IPv6地址，或者总是首选IPv4地址的策略，将导致贫乏的行为。作为一个例子，假定DNS域名解析到一个全球IPv6地址和一个全球IPv4地址。如果节点已经分配了一个全球IPv6地址和一个169.254/16自动配置IPv4地址[RFC3927]，则IPv6是用于通信的最佳选择。但是，如果节点只分配了一个链路本地IPv6地址和一个全球IPv4地址，则IPv4是通信的最佳选择。目的地址选择算法通过在IPv6和IPv4地址之间进行选择的统一过程解决了这一问题。

本文档中算法被定义为一系列的规则，这些规则定义了可使用的地址集上的部分排序。在源地址选择的情况下，节点的接口通常分配多个地址，在第5章中定义的源地址排序规则定义了哪个地址是“最好”的一个。在目的地址选择的情况下，DNS可能为给定域名返回一组地址集合，由应用程序决定使用先使用其中哪一个，并且第一个不可达时，尝试其他地址的顺序。当将第6节中的目标地址排序规则应用于DNS返回的地址集时，将提供这种建议的排序。

本文档虽然分别定义了源和目的地址选择算法，但是使用了相同的上下文，因此这两种算法共同产生

了有用的结果。算法尝试选择合适范围以及配置状态的（RFC4862定义的“首选的”或“降级的”）源和目的地址。进一步，本文档建议了首选的方法，最长匹配前缀，用于在缺少更好信息的多个等效地址间进行选择。

本文档同样指定了策略回调以使得管理可以覆盖默认行为。比如，使用这些回调，管理员可以为目的前缀指定首选的源前缀，或者某个特定的目的前缀优先于其他前缀。这些回调为管理员提供了处理某些多宿主和过渡方案的灵活性，但它们肯定不是万能的。

本文档指定的规则不得用于重写应用或上层明确指定的合法的目的地址或源地址的选择。

1.1本文档约定

本文档中出现的关键字MUST（必须）、MUST NOT（不得）、REQUIRED（必选的）、SHALL（将要）、SHALL NOT（将不会）、SHOULD（应该）、SHOULD NOT（不应该）、RECOMMENDED（推荐）、MAY（可能）、和OPTIONAL（可选），其含义参考RFC2119规范。

2算法运行的上下文

我们用于地址选择的上下文来自最常见的实现体系结构，该体系结构将目标地址的选择与源地址的选择分开。因此，对于这些任务，我们有两种单独的算法。这些算法设计为可以很好地协同工作，并且它们共享一种用于管理策略覆盖的机制。

在本实现架构中，应用程序使用诸如getaddrinfo()[RFC3493]的API返回一个地址列表给应用程序。该列表中可以同时包含IPv6和IPv4地址（有时呈现为IPv4映射地址）。随后应用程序使用connect()或者sendto()，传递目的地址给网络协议栈。应用程序通常尝试列表中的第一个地址，遍历整个地址列表知道找到可以工作的地址。在任何情况下，网络层从不会面对它要从多个目的地址作出选择的情况。应用程序也可以通过bind()指定源地址，但是通常情况下源地址是未定义的，而实际由网络层从多个备选地址中选择一个作为源地址。

因此，我们希望诸如getaddrinfo()这类的API实现，将使用本文档中定义的目的地址选择算法，对返回的包含IPv4和IPv6地址的列表进行排序。另外，当应用程序或上层没有指定源地址时，IPv6