2. Context in Which the Algorithms Operate (算法运行的上下文)

2. Context in Which the Algorithms Operate (算法运行的上下文)

我们的地址选择上下文源自最常见的实现架构, 该架构将目标地址的选择与源地址的选择分开。因此, 我们为这些任务提供了两个独立的算法。这些算法被设计为能够很好地协同工作, 并且它们共享一个管理员策略覆盖的机制。

在这种实现架构中, 应用程序使用诸如 getaddrinfo() [RFC3493] 之类的 API, 这些 API 向应用程序返回一个地址列表。此列表可能同时包含 IPv6 和 IPv4 地址 (有时表示为 IPv4 映射地址)。然后, 应用程序通过 connect() 或 sendto() 将目标地址传递给网络栈。然后, 应用程序通常会尝试列表中的第一个地址, 循环遍历地址列表直到找到一个有效的地址。无论如何, 网络层永远不会处于需要从多个备选方案中选择目标地址的情况。应用程序也可能通过 bind() 指定源地址, 但通常源地址是未指定的。因此, 网络层经常确实需要从多个备选方案中选择源地址。

因此, 我们的意图是, 诸如 getaddrinfo() 之类的 API 的实现将使用此处指定的目标地址选择算法对它们返回的 IPv6 和 IPv4 地址列表进行排序。另外, 当应用程序或上层未指定源地址时, IPv6 网络层将使用源地址选择算法。将本规范应用于 IPv4 网络层中的源地址选择可能是可行的, 但这里不再进一步探讨。

行为良好的应用程序不应该简单地使用从诸如 getaddrinfo() 之类的 API 返回的第一个地址, 然后如果失败就放弃。对于许多应用程序, 适当的做法是遍历从 getaddrinfo() 返回的地址列表, 直到找到一个有效的地址。对于其他应用程序, 适当的做法可能是并行尝试多个地址 (例如, 它们之间有一些小的延迟), 并使用第一个成功的地址。

虽然源地址和目标地址选择最典型地在启动通信时完成, 但响应者也必须处理地址选择。在许多情况下, 这可以通过应用程序使用接收数据包的源地址作为响应目标地址, 并使用接收数据包的目标地址作为响应源地址来简单处理。然而, 其他情况的处理方式类似于发起者, 例如当请求是多播时, 因此在生成响应时仍然必须进行源地址选择, 或者当请求包含发起者的地址列表以供选择目标地址时。最后, 第三个应用程序场景是侦听应用程序选择在哪些本地地址上侦听。这第三个场景不在本文档的范围内。

算法在做出决策时使用几个标准。综合效果是偏好两个地址具有相等范围或类型的目标/源地址对, 对于目标地址偏好较小的范围而非较大的范围, 偏好非弃用的源地址, 在本地地址可用时避免使用过渡地址, 在其他条件相同的情况下, 偏好具有最长公共前缀的地址对。对于源地址选择, 临时地址 [RFC4941] 优先于公共地址。在移动情况下 [RFC6275], 归属地址优先于转交地址。如果一个地址同时是归属地址和转交地址 (表示移动节点对于该地址 "在家"), 则归属/转交地址优先于仅是归属地址或仅是转交地址的地址。

本规范可选地允许管理员配置策略 (例如, 通过手动配置或 DHCP 选项, 如 [ADDR-SEL-OPT] 中提出的) 的可能性, 该策略可以覆盖算法的默认行为。策略覆盖包括以下状态集, 应该是可配置的:

• Policy Table (策略表) (第 2.1 节): 一个表, 为目标前缀指定优先级值和首选源前缀。

• Automatic Row Additions flag (自动行添加标志) (第 2.1 节): 一个标志, 指定实现是否被允许自动为某些类型的地址添加站点特定的行。

• Privacy Preference flag (隐私偏好标志) (第 5 节): 一个标志, 指定当两种类型都存在时, 默认情况下是偏好临时源地址还是稳定源地址。