Network Working Group E. Nordmark
Request for Comments: 5014 Sun Microsystems, Inc.
Category: Informational S. Chakrabarti
Azaire Networks
J. Laganier
DoCoMo Euro-Labs
September 2007
Network Working Group E. Nordmark
Request for Comments: 5014 Sun Microsystems, Inc.
Category: Informational S. Chakrabarti
Azaire Networks
J. Laganier
DoCoMo Euro-Labs
September 2007
IPv6 Socket API for Source Address Selection
用于源地址选择的IPv6套接字API
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
摘要
The IPv6 default address selection document (RFC 3484) describes the rules for selecting source and destination IPv6 addresses, and indicates that applications should be able to reverse the sense of some of the address selection rules through some unspecified API. However, no such socket API exists in the basic (RFC 3493) or advanced (RFC 3542) IPv6 socket API documents. This document fills that gap partially by specifying new socket-level options for source address selection and flags for the getaddrinfo() API to specify address selection based on the source address preference in accordance with the socket-level options that modify the default source address selection algorithm. The socket API described in this document will be particularly useful for IPv6 applications that want to choose between temporary and public addresses, and for Mobile IPv6 aware applications that want to use the care-of address for communication. It also specifies socket options and flags for selecting Cryptographically Generated Address (CGA) or non-CGA source addresses.
IPv6默认地址选择文档（RFC 3484）描述了选择源和目标IPv6地址的规则，并指出应用程序应该能够通过一些未指定的API反转某些地址选择规则的含义。但是，基本（RFC 3493）或高级（RFC 3542）IPv6套接字API文档中不存在此类套接字API。本文档通过为源地址选择指定新的套接字级别选项和getaddrinfo（）API的标志，根据修改默认源地址选择算法的套接字级别选项，基于源地址首选项指定地址选择，部分填补了这一空白。本文档中描述的套接字API对于希望在临时地址和公共地址之间进行选择的IPv6应用程序，以及希望使用转交地址进行通信的支持IPv6的移动应用程序，将特别有用。它还指定用于选择加密生成地址（CGA）或非CGA源地址的套接字选项和标志。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Definition Of Terms . . . . . . . . . . . . . . . . . . . . . 5
3. Usage Scenario . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Design Alternatives . . . . . . . . . . . . . . . . . . . . . 6
5. Address Preference Flags . . . . . . . . . . . . . . . . . . . 7
6. Additions to the Socket Interface . . . . . . . . . . . . . . 9
7. Additions to the Protocol-Independent Nodename Translation . . 10
8. Application Requirements . . . . . . . . . . . . . . . . . . . 11
9. Usage Example . . . . . . . . . . . . . . . . . . . . . . . . 13
10. Implementation Notes . . . . . . . . . . . . . . . . . . . . . 13
11. Mapping to Default Address Selection Rules . . . . . . . . . . 14
12. IPv4-Mapped IPv6 Addresses . . . . . . . . . . . . . . . . . . 16
13. Validating Source Address Preferences . . . . . . . . . . . . 16
14. Summary of New Definitions . . . . . . . . . . . . . . . . . . 19
15. Security Considerations . . . . . . . . . . . . . . . . . . . 19
16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
17.1. Normative References . . . . . . . . . . . . . . . . . . 20
17.2. Informative References . . . . . . . . . . . . . . . . . 20
Appendix A. Per-Packet Address Selection Preference . . . . . . . 21
Appendix B. Intellectual Property Statement . . . . . . . . . . . 22
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Definition Of Terms . . . . . . . . . . . . . . . . . . . . . 5
3. Usage Scenario . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Design Alternatives . . . . . . . . . . . . . . . . . . . . . 6
5. Address Preference Flags . . . . . . . . . . . . . . . . . . . 7
6. Additions to the Socket Interface . . . . . . . . . . . . . . 9
7. Additions to the Protocol-Independent Nodename Translation . . 10
8. Application Requirements . . . . . . . . . . . . . . . . . . . 11
9. Usage Example . . . . . . . . . . . . . . . . . . . . . . . . 13
10. Implementation Notes . . . . . . . . . . . . . . . . . . . . . 13
11. Mapping to Default Address Selection Rules . . . . . . . . . . 14
12. IPv4-Mapped IPv6 Addresses . . . . . . . . . . . . . . . . . . 16
13. Validating Source Address Preferences . . . . . . . . . . . . 16
14. Summary of New Definitions . . . . . . . . . . . . . . . . . . 19
15. Security Considerations . . . . . . . . . . . . . . . . . . . 19
16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
17.1. Normative References . . . . . . . . . . . . . . . . . . 20
17.2. Informative References . . . . . . . . . . . . . . . . . 20
Appendix A. Per-Packet Address Selection Preference . . . . . . . 21
Appendix B. Intellectual Property Statement . . . . . . . . . . . 22
[RFC3484] specifies the default address selection rules for IPv6
[RFC2460]. This document defines socket API extensions that allow
applications to override the default choice of source address
selection. It therefore indirectly affects the destination address
selection through getaddrinfo(). Privacy considerations [RFC3041]
have introduced "public" and "temporary" addresses. IPv6 Mobility
[RFC3775] introduces "home address" and "care-of address" definitions
in the mobile systems.
[RFC3484] specifies the default address selection rules for IPv6
[RFC2460]. This document defines socket API extensions that allow
applications to override the default choice of source address
selection. It therefore indirectly affects the destination address
selection through getaddrinfo(). Privacy considerations [RFC3041]
have introduced "public" and "temporary" addresses. IPv6 Mobility
[RFC3775] introduces "home address" and "care-of address" definitions
in the mobile systems.
The default address selection rules in [RFC3484], in summary, are that a public address is preferred over a temporary address, that a mobile IPv6 home address is preferred over a care-of address, and that a larger scope address is preferred over a smaller scope address. Although it is desirable to have default rules for address selection, an application may want to reverse certain address selection rules for efficiency and other application-specific reasons.
总之，[RFC3484]中的默认地址选择规则是，公共地址优先于临时地址，移动IPv6家庭地址优先于转交地址，较大范围地址优先于较小范围地址。尽管希望有地址选择的默认规则，但出于效率和其他特定于应用程序的原因，应用程序可能希望反转某些地址选择规则。
Currently, IPv6 socket API extensions provide mechanisms to choose a specific source address through simple bind() operation or IPV6_PKTINFO socket option [RFC3542]. However, in order to use bind() or IPV6_PKTINFO socket option, the application itself must
目前，IPv6套接字API扩展提供了通过简单的bind（）操作或IPv6_PKTINFO套接字选项[RFC3542]选择特定源地址的机制。但是，为了使用bind（）或IPV6_PKTINFO套接字选项，应用程序本身必须
make sure that the source address is appropriate for the destination address (e.g., with respect to the interface used to send packets to the destination). The application also needs to verify the appropriateness of the source address scope with respect to the destination address and so on. This can be quite complex for the application, since in effect, it needs to implement all the default address selection rules in order to change its preference with respect to one of the rules.
确保源地址适合目标地址（例如，关于用于向目标发送数据包的接口）。应用程序还需要验证源地址范围相对于目标地址的适当性，等等。对于应用程序来说，这可能相当复杂，因为实际上，它需要实现所有默认地址选择规则，以便更改其相对于其中一个规则的首选项。
The mechanism presented in this document allows the application to specify attributes of the source addresses it prefers while still having the system perform the rest of the address selection rules. For instance, if an application specifies that it prefers to use a care-of address over a home address as the source address and if the host has two care-of addresses, one public and one temporary, then the host would select the public care-of address by following the default address selection rule for preferring a public over a temporary address.
本文档中介绍的机制允许应用程序指定其首选的源地址的属性，同时仍让系统执行其余的地址选择规则。例如，如果应用程序指定它更喜欢使用转交地址而不是家庭地址作为源地址，并且如果主机有两个转交地址，一个公共地址和一个临时地址，那么主机将通过遵循默认的地址选择规则来选择公共转交地址，以便优先使用公共地址而不是临时地址。
A socket option has been deemed useful for this purpose, as it enables an application to specify address selection preferences on a per-socket basis. It can also provide the flexibility of enabling and disabling address selection preferences in non-connected (UDP) sockets. The socket option uses a set of flags for specifying address selection preferences. Since the API should not assume a particular implementation method of the address selection [RFC3484] in the network layer or in getaddrinfo(), the corresponding set of flags are also defined for getaddrinfo(), as it depends on the source address selection.
套接字选项被认为是用于此目的的，因为它使应用程序能够在每个套接字的基础上指定地址选择首选项。它还可以提供在未连接（UDP）套接字中启用和禁用地址选择首选项的灵活性。套接字选项使用一组标志来指定地址选择首选项。由于API不应采用网络层或getaddrinfo（）中地址选择[RFC3484]的特定实现方法，因此也为getaddrinfo（）定义了相应的标志集，因为它取决于源地址选择。
As a result, this document introduces several flags for address selection preferences that alter the default address selection [RFC3484] for a number of rules. It analyzes the usefulness of providing API functionality for different default address selection rules; it provides API to alter only those rules that are possibly used by certain classes of applications. In addition, it also considers CGA [RFC3972] and non-CGA source addresses when CGA addresses are available in the system. In the future, more source flags may be added to expand the API as the needs may arise.
因此，本文档为地址选择首选项引入了几个标志，这些标志改变了许多规则的默认地址选择[RFC3484]。它分析了为不同的默认地址选择规则提供API功能的有用性；它提供的API仅用于更改某些类应用程序可能使用的规则。此外，当CGA地址在系统中可用时，它还考虑CGA[RFC3972]和非CGA源地址。将来，可能会根据需要添加更多源标志以扩展API。
The approach in this document is to allow the application to specify preferences for address selection and not to be able to specify hard requirements. For instance, an application can set a flag to prefer a temporary source address, but if no temporary source addresses are available at the node, a public address would be chosen instead.
本文档中的方法是允许应用程序指定地址选择的首选项，而不是指定硬需求。例如，应用程序可以设置一个标志来选择临时源地址，但如果节点上没有可用的临时源地址，则会选择公共地址。
Specifying hard requirements for address selection would be problematic for several reasons. The major one is that, in the vast
指定地址选择的硬要求会有问题，原因有几个。主要的一点是，在广大的
majority of cases, the application would like to be able to communicate even if an address with the 'optimal' attributes is not available. For instance, an application that performs very short, e.g., UDP, transactional exchanges (e.g., DNS queries), might prefer to use a care-of address when running on a mobile host that is away from home since this provides a short roundtrip time in many cases. But if the application is running on a mobile host that is at home, or running on a host that isn't providing Mobile IPv6, then it doesn't make sense for the application to fail due to no care-of address being available. Also, in particular, when using UDP sockets and the sendto() or sendmsg() primitives, the use of hard requirements would have been problematic, since the set of available IP addresses might very well have changed from when the application called getaddrinfo() until it called sendto() or sendmsg(), which would introduce new failure modes.
大多数情况下，应用程序希望能够通信，即使具有“最佳”属性的地址不可用。例如，执行非常短（例如UDP）事务性交换（例如DNS查询）的应用程序在离家的移动主机上运行时可能更喜欢使用转交地址，因为在许多情况下，这会提供较短的往返时间。但是，如果应用程序运行在家中的移动主机上，或者运行在不提供移动IPv6的主机上，那么由于不关心地址可用，应用程序失败是没有意义的。另外，特别是在使用UDP套接字和sendto（）或sendmsg（）原语时，硬需求的使用可能会有问题，因为从应用程序调用getaddrinfo（）到调用sendto（）或sendmsg（），可用IP地址集很可能已经发生了变化，这将引入新的故障模式。
For the few applications that have hard requirements on the attributes of the IP addresses they use, this document defines a verification function that allows such applications to properly fail to communicate when their address selection requirements are not met.
对于少数对其使用的IP地址属性有严格要求的应用程序，本文档定义了一个验证功能，允许此类应用程序在其地址选择要求未得到满足时正确地失败通信。
Furthermore, the approach is to define two flags for each rule that can be modified so that an application can specify its preference for addresses selected as per the rule, the opposite preference (i.e., an address selected as per the rule reverted), or choose not to set either of the flags relating to that rule and leave it up to the system default (Section 4). This approach allows different implementations to have different system defaults, and works with getaddrinfo() as well as setsockopt(). (For setsockopt, a different approach could have been chosen, but that would still require the same approach for getaddrinfo.)
此外，该方法是为每个可修改的规则定义两个标志，以便应用程序可以为根据该规则选择的地址指定其首选项，相反的首选项（即，根据还原的规则选择的地址），或者选择不设置与该规则相关的任何标志，并将其保留为系统默认值（第4节）。这种方法允许不同的实现具有不同的系统默认值，并且可以使用getaddrinfo（）和setsockopt（）。（对于setsockopt，可以选择不同的方法，但对于getaddrinfo仍然需要相同的方法。）
Note that this document does not directly modify the destination address selection rules described in [RFC3484]. An analysis has been done to see which destination address rules may be altered by the applications. Rule number 4(prefer home address), 8(prefer smaller scope), 7(prefer native interfaces) of default address selection document [RFC3484] were taken into consideration for destination address alteration. But as of this writing, there was not enough practical usage for applications to alter destination address selection rules directly by applying the setsockopt() with a preferred destination type of address flag. However, this document does not rule out any possibility of adding flags for preferred destination address selection. However, [RFC3484] destination address selection rules are dependent on source address selections, thus by altering the default source address selection by using the methods described in this document, one indirectly influences the choice of destination address selection. Hence, this document
请注意，本文档不会直接修改[RFC3484]中描述的目标地址选择规则。已经进行了分析，以查看应用程序可能会更改哪些目标地址规则。目的地地址变更考虑了默认地址选择文档[RFC3484]的第4条规则（首选家庭地址）、第8条规则（首选较小范围）、第7条规则（首选本机接口）。但在撰写本文时，应用程序还没有足够的实际用途来直接通过应用带有首选目标类型地址标志的setsockopt（）来更改目标地址选择规则。但是，本文档不排除为首选目标地址选择添加标志的可能性。但是，[RFC3484]目标地址选择规则取决于源地址选择，因此，通过使用本文档中描述的方法更改默认源地址选择，可以间接影响目标地址选择。因此，本文件
explains how getaddrinfo() can be used to select the destination address while taking the preferred source addresses into consideration (Section 11).
解释如何使用getaddrinfo（）选择目标地址，同时考虑首选源地址（第11节）。
This document specifies extensions only to the Basic IPv6 socket API specified in [RFC3493]. The intent is that this document serves as a model for expressing preferences for attributes of IP addresses that also need to be expressible in other networking API, such as those found in middleware systems and the Java environment. A similar model is also applicable for other socket families.
本文档仅指定对[RFC3493]中指定的基本IPv6套接字API的扩展。本文档的目的是作为一个模型，用于表达IP地址属性的首选项，这些属性也需要在其他网络API中表达，如中间件系统和Java环境中的属性。类似的模型也适用于其他插座系列。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
Address preference flag: A flag expressing a preference for a particular type of address (e.g., temporary, public).
地址首选标志：表示对特定类型地址（例如，临时、公共）首选的标志。
Opposite flags: Each flag expressing an address preference has an "opposite flag" expressing the opposite preference:
反向标志：每个表示地址首选项的标志都有一个表示反向首选项的“反向标志”：
* Home address preference flag is the opposite of the care-of address preference flag.
* 家庭地址首选项标志与转交地址首选项标志相反。
* Temporary address preference flag is the opposite of the public address preference flag.
* 临时地址首选项标志与公共地址首选项标志相反。
* CGA address preference flag is the opposite of the non-CGA address preference flag.
* CGA地址首选项标志与非CGA地址首选项标志相反。
Contradictory flags: Any combination of flags including both a flag expressing a given address preference and a flag expressing the opposite preference constitutes contradictory flags. Such flags are contradictory by definition of their usefulness with respect to source address selection. For example, consider a set of flags, including both the home address preference flag and the care-of address preference flag. When considering source address selection, the selected address can be a home address, or a care-of address, but it cannot be both at the same time. Hence, to prefer an address that is both a home address and a care-of address is contradictory.
矛盾标志：任何标志组合，包括表示给定地址首选项的标志和表示相反首选项的标志，构成矛盾标志。这些标志在源地址选择方面的有用性定义上是相互矛盾的。例如，考虑一组标志，包括主页地址偏好标志和转交地址偏好标志。在考虑源地址选择时，所选地址可以是家庭地址或转交地址，但不能同时是两个地址。因此，选择一个既是家庭住址又是照顾住址的住址是矛盾的。
The examples discussed here are limited to applications supporting Mobile IPv6, IPv6 Privacy Extensions, and Cryptographically Generated Addresses. Address selection document [RFC3484] recommends that home addresses should be preferred over care-of address when both are configured. However, a mobile node may want to prefer a care-of address as the source address for a DNS query in the foreign network, as it normally means a shorter and local return path compared to the route via the mobile node's home-agent when the query contains a home address as the source address. Another example is the IKE application, which requires a care-of address as its source address for the initial security association pair with a Home Agent [RFC3775] while the mobile node boots up at the foreign network and wants to do the key exchange before a successful home-registration. Also, a Mobile IPv6 aware application may want to toggle between the home address and care-of address, depending on its location and state of the application. It may also want to open different sockets and use the home address as the source address for one socket and a care-of address for the others.
这里讨论的示例仅限于支持移动IPv6、IPv6隐私扩展和加密生成地址的应用程序。地址选择文件[RFC3484]建议，在配置家庭地址和转交地址时，家庭地址应优先于转交地址。然而，移动节点可能希望优选转交地址作为外部网络中DNS查询的源地址，因为当查询包含归属地址作为源地址时，它通常意味着与经由移动节点的归属代理的路由相比更短的本地返回路径。另一个例子是IKE应用程序，当移动节点在外部网络启动并希望在成功的家庭注册之前进行密钥交换时，IKE应用程序需要一个转交地址作为其与家庭代理[RFC3775]的初始安全关联对的源地址。此外，支持移动IPv6的应用程序可能希望在家庭地址和转交地址之间切换，具体取决于其位置和应用程序的状态。它可能还希望打开不同的套接字，并将家庭地址用作一个套接字的源地址，以及其他套接字的转交地址。
In a non-mobile environment, an application may similarly prefer to use a temporary address as the source address for certain cases. By default, the source address selection rule selects "public" address when both are available. For example, an application supporting Web browser and mail-server may want to use a "temporary" address for the former and a "public" address for the mail-server, as a mail-server may require a reverse path for DNS records for anti-spam rules.
在非移动环境中，对于某些情况，应用程序可能更喜欢使用临时地址作为源地址。默认情况下，源地址选择规则在两个地址都可用时选择“公共”地址。例如，支持Web浏览器和邮件服务器的应用程序可能希望为前者使用“临时”地址，为邮件服务器使用“公共”地址，因为邮件服务器可能需要DNS记录的反向路径来执行反垃圾邮件规则。
Similarly, a node may be configured to use Cryptographically Generated Addresses [RFC3972] by default, as in Secure Neighbor Discovery [RFC3971], but an application may prefer not to use it; for instance, fping [FPING], a debugging tool that tests basic reachability of multiple destinations by sending packets in parallel. These packets may end up initiating neighbor discovery signaling that uses SEND if used with a CGA source address. SEND performs some cryptographic operations to prove ownership of the said CGA address. If the application does not require this feature, it would like to use a non-CGA address to avoid potentially expensive computations performed by SEND. On the other hand, when a node is not configured for CGA as default, an application may prefer using CGA by setting the corresponding preference.
类似地，节点可被配置为默认使用加密生成的地址[RFC3972]，如在安全邻居发现[RFC3971]中，但应用程序可能不喜欢使用它；例如，fping[fping]，一种调试工具，通过并行发送数据包来测试多个目的地的基本可达性。如果与CGA源地址一起使用，这些数据包可能会启动使用SEND的邻居发现信令。SEND执行一些加密操作以证明所述CGA地址的所有权。如果应用程序不需要此功能，则希望使用非CGA地址来避免SEND执行的潜在昂贵计算。另一方面，当未将节点配置为CGA作为默认值时，应用程序可能更喜欢通过设置相应的首选项来使用CGA。
Some suggested to have per-application flags instead of per-socket and per-packet flags. However, this design stays with per-socket and per-packet flags for the following reasons:
一些人建议使用每个应用程序标志，而不是每个套接字和每个数据包标志。但是，出于以下原因，此设计保留每个套接字和每个数据包标志：
o While some systems have per-environment/application flags (such as environment variables in Unix systems) this might not be available in all systems that implement the socket API.
o 虽然有些系统具有每个环境/应用程序的标志（例如Unix系统中的环境变量），但这可能不适用于所有实现socket API的系统。
o When an application links with some standard library, that library might use the socket API while the application is unaware of that fact. Mechanisms that would provide per-application flags may affect not only the application itself but also the libraries, hence, creating risks of unintended consequences.
o 当应用程序链接到某个标准库时，该库可能会在应用程序不知道这一事实的情况下使用套接字API。提供每个应用程序标志的机制可能不仅会影响应用程序本身，还会影响库，从而产生意外后果的风险。
Instead of the pair of 'flag' and 'opposite flag' for each rule that can be modified, the socket option could have been defined to use a single 'flag' value for each rule. This would still have allowed different implementations to have different default settings as long as the applications were coded to first retrieve the default setting (using getsockopt()), and then clear or set the 'flag' according to their preferences, and finally set the new value with setsockopt().
对于可以修改的每个规则，套接字选项可以定义为对每个规则使用单个“标志”值，而不是一对“标志”和“相反标志”。这仍然允许不同的实现具有不同的默认设置，只要应用程序被编码为首先检索默认设置（使用getsockopt（）），然后根据其首选项清除或设置“标志”，最后使用setsockopt（）设置新值。
But such an approach would not be possible for getaddrinfo() because all the preferences would need to be expressible in the parameters that are passed with a single getaddrinfo() call. Hence, for consistency, the 'flag' and 'opposite flag' approach is used for both getaddrinfo() and setsockopt().
但是这种方法对于getaddrinfo（）是不可能的，因为所有的首选项都需要在通过单个getaddrinfo（）调用传递的参数中表达。因此，为了保持一致性，getaddrinfo（）和setsockopt（）都使用了“标志”和“相反标志”方法。
Thus, in this API document, an application has three choices on source address selection:
因此，在本API文档中，应用程序在源地址选择上有三种选择：
a) The application wants to use an address with flag X: Set flag X; unset opposite/contradictory flags of X if they are set before.
a) 应用程序希望使用带有标志X的地址：Set flag X；取消设置X的相反/矛盾标志（如果之前已设置）。
b) The application wants to use an address with 'opposite' or contradictory flag of X: Set opposite or contradictory flag of X; unset flag X, if already set.
b) 应用程序希望使用“相反”或矛盾标志为X的地址：设置相反或矛盾标志为X；取消设置标志X（如果已设置）。
c) The application does not care about the presence of flag X and would like to use default: No need to set any address preference flags through setsockopt() or getaddrinfo(); unset any address preference flags if they are set before by the same socket.
c) 应用程序不关心标志X的存在，并且希望使用默认值：无需通过setsockopt（）或getaddrinfo（）设置任何地址首选项标志；如果之前由同一套接字设置了地址首选项标志，则取消设置这些标志。
The following flags are defined to alter or set the default rule of source address selection rules discussed in default address selection specification [RFC3484].
定义以下标志以更改或设置默认地址选择规范[RFC3484]中讨论的源地址选择规则的默认规则。
IPV6_PREFER_SRC_HOME /* Prefer Home address as source */
IPV6_PREFER_SRC_HOME /* Prefer Home address as source */
IPV6_PREFER_SRC_COA /* Prefer Care-of address as source */
IPV6_PREFER_SRC_COA /* Prefer Care-of address as source */
IPV6_PREFER_SRC_TMP /* Prefer Temporary address as source */
IPV6_PREFER_SRC_TMP /* Prefer Temporary address as source */
IPV6_PREFER_SRC_PUBLIC /* Prefer Public address as source */
IPV6_PREFER_SRC_PUBLIC /* Prefer Public address as source */
IPV6_PREFER_SRC_CGA /* Prefer CGA address as source */
IPV6_PREFER_SRC_CGA /* Prefer CGA address as source */
IPV6_PREFER_SRC_NONCGA /* Prefer a non-CGA address as source */
IPV6_PREFER_SRC_NONCGA /* Prefer a non-CGA address as source */
These flags can be combined together in a flag-set to express more complex address preferences. However, such combinations can result in a contradictory flag-set, for example:
这些标志可以组合在一个标志集中，以表示更复杂的地址首选项。但是，这种组合可能会导致相互矛盾的标志集，例如：
IPV6_PREFER_SRC_PUBLIC | IPV6_PREFER_SRC_TMP
IPV6_preference_SRC_PUBLIC|IPV6_preference_SRC_TMP
IPV6_PREFER_SRC_HOME | IPV6_PREFER_SRC_COA
IPV6_preference_SRC_HOME|IPV6_preference_SRC_COA
IPV6_PREFER_SRC_HOME | IPV6_PREFER_SRC_COA | IPV6_PREFER_SRC_TMP
IPV6|u preference|u SRC|u HOME|IPV6|u preference|u SRC|u COA|IPV6|u preference|u SRC|TMP
IPV6_PREFER_SRC_CGA | IPV6_PREFER_SRC_NONCGA
IPV6_preference_SRC_CGA | IPV6_preference_SRC_NONCGA
Etc.
等
Examples of valid combinations of address selection flags are given below:
地址选择标志的有效组合示例如下所示：
IPV6_PREFER_SRC_HOME | IPV6_PREFER_SRC_PUBLIC
IPV6_preference_SRC_HOME|IPV6_preference_SRC_PUBLIC|
IPV6_PREFER_SRC_HOME | IPV6_PREFER_SRC_CGA
IPV6_preference_SRC_HOME|IPV6_preference_SRC_CGA
IPV6_PREFER_SRC_COA | IPV6_PREFER_SRC_PUBLIC | IPV6_PREFER_SRC_CGA
IPV6|u preference|u SRC|u COA|IPV6|u preference|u SRC|u PUBLIC|IPV6|u preference|u SRC|u CGA
IPV6_PREFER_SRC_HOME | IPV6_PREFER_SRC_NONCGA
IPV6_preference_SRC_HOME|IPV6_preference_SRC_NONCGA
If a flag-set includes a combination of 'X' and 'Y', and if 'Y' is not applicable or available in the system, then the selected address has attribute 'X' and system default for the attribute 'Y'. For example, on a system that has only public addresses, the valid combination of flags:
如果标志集包含“X”和“Y”的组合，并且如果“Y”在系统中不适用或不可用，则所选地址具有属性“X”，系统默认为属性“Y”。例如，在只有公共地址的系统上，标志的有效组合：
IPV6_PREFER_SRC_TMP | IPV6_PREFER_SRC_HOME
IPV6_preference_SRC_TMP|IPV6_preference_SRC_HOME
would result in the selected address being a public home address, since no temporary addresses are available.
将导致所选地址成为公共家庭地址，因为没有可用的临时地址。
The IPv6 Basic Socket API [RFC3493] defines socket options for IPv6. To allow applications to influence address selection mechanisms, this document adds a new socket option at the IPPROTO_IPV6 level. This socket option is called IPV6_ADDR_PREFERENCES. It can be used with setsockopt() and getsockopt() calls to set and get the address selection preferences affecting all packets sent via a given socket. The socket option value (optval) is a 32-bit unsigned integer argument. The argument consists of a number of flags where each flag indicates an address selection preference that modifies one of the rules in the default address selection specification.
IPv6基本套接字API[RFC3493]定义了IPv6的套接字选项。为了允许应用程序影响地址选择机制，本文档在IPPROTO_IPV6级别添加了一个新的套接字选项。此套接字选项称为IPV6\u ADDR\u首选项。它可以与setsockopt（）和getsockopt（）调用一起使用，以设置和获取影响通过给定套接字发送的所有数据包的地址选择首选项。套接字选项值（optval）是一个32位无符号整数参数。该参数由多个标志组成，其中每个标志表示修改默认地址选择规范中的一个规则的地址选择首选项。
The following flags are defined to alter or set the default rule of source address selection rules discussed in default address selection specification [RFC3484]. They are defined as a result of including the <netinet/in.h> header:
定义以下标志以更改或设置默认地址选择规范[RFC3484]中讨论的源地址选择规则的默认规则。它们被定义为包含<netinet/in.h>标题的结果：
IPV6_PREFER_SRC_HOME /* Prefer Home address as source */
IPV6_PREFER_SRC_HOME /* Prefer Home address as source */
IPV6_PREFER_SRC_COA /* Prefer Care-of address as source */
IPV6_PREFER_SRC_COA /* Prefer Care-of address as source */
IPV6_PREFER_SRC_TMP /* Prefer Temporary address as source */
IPV6_PREFER_SRC_TMP /* Prefer Temporary address as source */
IPV6_PREFER_SRC_PUBLIC /* Prefer Public address as source */
IPV6_PREFER_SRC_PUBLIC /* Prefer Public address as source */
IPV6_PREFER_SRC_CGA /* Prefer CGA address as source */
IPV6_PREFER_SRC_CGA /* Prefer CGA address as source */
IPV6_PREFER_SRC_NONCGA /* Prefer a non-CGA address as source */
IPV6_PREFER_SRC_NONCGA /* Prefer a non-CGA address as source */
NOTE: No source preference flag for the longest matching prefix is defined here because it is believed to be handled by the policy table defined in the default address selection specification.
注意：此处未定义最长匹配前缀的源首选项标志，因为它被认为是由默认地址选择规范中定义的策略表处理的。
When the IPV6_ADDR_PREFERENCES is successfully set with setsockopt(), the option value given is used to specify the address preference for any connection initiation through the socket and all subsequent packets sent via that socket. If no option is set, the system selects a default value as per default address selection algorithm or by some other equivalent means.
使用setsockopt（）成功设置IPV6_ADDR_首选项时，给定的选项值用于指定通过套接字发起的任何连接以及通过该套接字发送的所有后续数据包的地址首选项。如果未设置任何选项，系统将根据默认地址选择算法或通过其他等效方式选择默认值。
Setting contradictory flags at the same time results in the error EINVAL.
同时设置相互矛盾的标志将导致错误EINVAL。
Section 8 of the Default Address Selection [RFC3484] document indicates possible implementation strategies for getaddrinfo() [RFC3493]. One of them suggests that getaddrinfo() collects available source/destination pairs from the network layer after being sorted at the network layer with full knowledge of source address selection. Another strategy is to call down to the network layer to retrieve source address information and then sort the list in the context of getaddrinfo().
默认地址选择[RFC3484]文档的第8节指出了getaddrinfo（）[RFC3493]可能的实现策略。其中一个建议是，getaddrinfo（）在网络层对源地址选择进行充分了解后，从网络层收集可用的源/目标对。另一种策略是调用网络层来检索源地址信息，然后在getaddrinfo（）的上下文中对列表进行排序。
This implies that getaddrinfo() should be aware of the address selection preferences of the application, since getaddrinfo() is independent of any socket the application might be using.
这意味着getaddrinfo（）应该知道应用程序的地址选择首选项，因为getaddrinfo（）独立于应用程序可能使用的任何套接字。
Thus, if an application alters the default address selection rules by using setsockopt() with the IPV6_ADDR_PREFERENCES option, the application should also use the corresponding address selection preference flags with its getaddrinfo() call.
因此，如果应用程序通过将setsockopt（）与IPV6_ADDR_PREFERENCES选项一起使用来更改默认地址选择规则，则应用程序还应在其getaddrinfo（）调用中使用相应的地址选择首选标志。
For that purpose, the addrinfo data structure defined in Basic IPV6 Socket API Extension [RFC3493] has been extended with an extended "ai_eflags" flag-set field to provide the designers freedom from adding more flags as necessary without crowding the valuable bit space in the "ai_flags" flag-set field. The extended addrinfo data structure is defined as a result of including the <netdb.h> header:
为此，基本IPV6套接字API扩展[RFC3493]中定义的addrinfo数据结构已通过扩展的“ai_eflags”标志集字段进行了扩展，以使设计者无需根据需要添加更多标志，而不会占用“ai_标志”标志集字段中的宝贵位空间。扩展的addrinfo数据结构定义为包含<netdb.h>头的结果：
struct addrinfo {
int ai_flags; /* input flags */
int ai_family; /* protocol family for socket */
int ai_socktype; /* socket type */
int ai_protocol; /* protocol for socket */
socklen_t ai_addrlen; /* length of socket address */
char *ai_canonname; /* canonical name for hostname */
struct sockaddr *ai_addr; /* socket address for socket */
struct addrinfo *ai_next; /* pointer to next in list */
int ai_eflags; /* Extended flags for special usage */
};
struct addrinfo {
int ai_flags; /* input flags */
int ai_family; /* protocol family for socket */
int ai_socktype; /* socket type */
int ai_protocol; /* protocol for socket */
socklen_t ai_addrlen; /* length of socket address */
char *ai_canonname; /* canonical name for hostname */
struct sockaddr *ai_addr; /* socket address for socket */
struct addrinfo *ai_next; /* pointer to next in list */
int ai_eflags; /* Extended flags for special usage */
};
Note that the additional field for extended flags are added at the bottom of the addrinfo structure to preserve binary compatibility of the new functionality with the old applications that use the existing addrinfo data structure.
请注意，扩展标志的附加字段添加在addrinfo结构的底部，以保持新功能与使用现有addrinfo数据结构的旧应用程序的二进制兼容性。
A new flag (AI_EXTFLAGS) is defined for the "ai_flags" flag-set field of the addrinfo data structure to tell the system to look for the "ai_eflags" extended flag-set field in the addrinfo structure. It is defined in the <netdb.h> header:
为addrinfo数据结构的“AI_flags”标志集字段定义了一个新标志（AI_EXTFLAGS），以告知系统在addrinfo结构中查找“AI_eflags”扩展标志集字段。它在<netdb.h>标题中定义：
AI_EXTFLAGS /* extended flag-set present */
AI_EXTFLAGS /* extended flag-set present */
If the AI_EXTFLAGS flag is set in "ai_flags" flag-set field of the addrinfo data structure, then the getaddrinfo() implementation MUST look for the "ai_eflags" values stored in the extended flag-set field "ai_eflags" of the addrinfo data structure. The flags stored in the "ai_eflags" field are only meaningful if the AI_EXTFLAGS flag is set in the "ai_flags" flag-set field of the addrinfo data structure. By default, AI_EXTFLAGS is not set in the "ai_flags" flag-set field. If AI_EXTFLAGS is set in the "ai_flags" flag-set field, and the "ai_eflags" extended flag-set field is 0 (zero) or undefined, then AI_EXTFLAGS is ignored.
如果在addrinfo数据结构的“AI_flags”标志集字段中设置了AI_EXTFLAGS标志，则getaddrinfo（）实现必须查找存储在addrinfo数据结构的扩展标志集字段“AI_eflags”中的“AI_eflags”值。只有在addrinfo数据结构的“ai_标志”标志集字段中设置了ai_EXTFLAGS标志时，“ai_eflags”字段中存储的标志才有意义。默认情况下，“AI_标志”标志集字段中未设置AI_EXTFLAGS。如果在“AI_标志”标志集字段中设置了AI_EXTFLAGS，“AI_eflags”扩展标志集字段为0（零）或未定义，则忽略AI_EXTFLAGS。
The IPV6 source address preference values (IPV6_PREFER_SRC_*) defined for the IPV6_ADDR_PREFERENCES socket option are also defined as address selection preference flags for the "ai_eflags" extended flag-set field of the addrinfo data structure, so that getaddrinfo() can return matching destination addresses corresponding to the source address preferences expressed by the caller application.
为IPV6_ADDR_PREFERENCES套接字选项定义的IPV6源地址首选项值（IPV6_preference_SRC_*）也被定义为addrinfo数据结构的“ai_eflags”扩展标志集字段的地址选择首选项标志，因此getaddrinfo（）可以返回与调用方应用程序表示的源地址首选项相对应的匹配目标地址。
Thus, an application passes source address selection hints to getaddrinfo by setting AI_EXTFLAGS in the "ai_flags" field of the addrinfo structure, and the corresponding address selection preference flags (IPV6_PREFER_SRC_*) in the "ai_eflags" field.
因此，应用程序通过在addrinfo结构的“AI_标志”字段中设置AI_EXTFLAGS，并在“AI_eflags”字段中设置相应的地址选择首选标志（IPV6_preference_SRC_*），将源地址选择提示传递给getaddrinfo。
Currently, AI_EXTFLAGS is defined for the AF_INET6 socket protocol family only. But its usage should be extendable to other socket protocol families -- such as AF_INET or as appropriate.
目前，AI_EXTFLAGS仅为AF_INET6套接字协议系列定义。但它的使用应该可以扩展到其他套接字协议系列，如AF_INET或其他合适的协议。
If contradictory flags, such as IPV6_PREFER_SRC_HOME and IPV6_PREFER_SRC_COA, are set in ai_eflags, the getaddrinfo() fails and return the value EAI_BADEXTFLAGS, defined as a result of including the <netdb.h> header. This error value MUST be interpreted into a descriptive text string when passed to the gai_strerror() function [RFC3493].
如果在ai_eflags中设置了相互矛盾的标志，例如IPV6_preference_SRC_HOME和IPV6_preference_SRC_COA，则getaddrinfo（）将失败并返回值EAI_BADEXTFLAGS，该值是由于包含<netdb.h>头而定义的。当传递给gai_strerror（）函数[RFC3493]时，必须将此错误值解释为描述性文本字符串。
An application should call getsockopt() prior to calling setsockopt() if the application needs to be able to restore the socket back to the system default preferences. Note that this is suggested for portability. An application that does not have this requirement can just use getaddrinfo() while specifying its preferences, followed by:
如果应用程序需要能够将套接字还原回系统默认首选项，则应在调用setsockopt（）之前调用getsockopt（）。请注意，建议这样做是为了便于携带。没有此要求的应用程序可以在指定其首选项时使用getaddrinfo（），然后执行以下操作：
uint32_t flags = IPV6_PREFER_SRC_TMP;
uint32\u t flags=IPV6\u preference\u SRC\u TMP；
if (setsockopt(s, IPPROTO_IPV6, IPV6_ADDR_PREFERENCES,
(void *) &flags, sizeof (flags)) == -1) {
perror("setsockopt IPV6_ADDR_REFERENCES");
}
if (setsockopt(s, IPPROTO_IPV6, IPV6_ADDR_PREFERENCES,
(void *) &flags, sizeof (flags)) == -1) {
perror("setsockopt IPV6_ADDR_REFERENCES");
}
An application that needs to be able to restore the default settings on the socket would instead do this:
需要能够恢复套接字上默认设置的应用程序将执行以下操作：
uint32_t save_flags, flags;
int optlen = sizeof (save_flags);
uint32_t save_flags, flags;
int optlen = sizeof (save_flags);
/* Save the existing IPv6_ADDR_PREFERENCE flags now */
/* Save the existing IPv6_ADDR_PREFERENCE flags now */
if (getsockopt(s, IPPROTO_IPV6, IPV6_ADDR_PREFERENCES,
(void *) &save_flags, &optlen) == -1 {
perror("getsockopt IPV6_ADDR_REFERENCES");
}
if (getsockopt(s, IPPROTO_IPV6, IPV6_ADDR_PREFERENCES,
(void *) &save_flags, &optlen) == -1 {
perror("getsockopt IPV6_ADDR_REFERENCES");
}
/* Set the new flags */
flags = IPV6_PREFER_SRC_TMP;
if (setsockopt(s, IPPROTO_IPV6, IPV6_ADDR_PREFERENCES,
(void *) &flags, sizeof (flags)) == -1) {
perror("setsockopt IPV6_ADDR_REFERENCES");
}
/* Set the new flags */
flags = IPV6_PREFER_SRC_TMP;
if (setsockopt(s, IPPROTO_IPV6, IPV6_ADDR_PREFERENCES,
(void *) &flags, sizeof (flags)) == -1) {
perror("setsockopt IPV6_ADDR_REFERENCES");
}
/*
*
* Do some work with the socket here.
*
*/
/*
*
* Do some work with the socket here.
*
*/
/* Restore the flags */
/* Restore the flags */
if (setsockopt(s, IPPROTO_IPV6, IPV6_ADDR_PREFERENCES,
(void *) &save_flags, sizeof (save_flags)) == -1) {
perror("setsockopt IPV6_ADDR_REFERENCES");
}
if (setsockopt(s, IPPROTO_IPV6, IPV6_ADDR_PREFERENCES,
(void *) &save_flags, sizeof (save_flags)) == -1) {
perror("setsockopt IPV6_ADDR_REFERENCES");
}
Applications should not set contradictory flags at the same time.
应用程序不应同时设置相互矛盾的标志。
In order to allow different implementations to do different parts of address selection in getaddrinfo() and in the protocol stack, this specification requires that applications set the semantically equivalent flags when calling getaddrinfo() and setsockopt(). For example, if the application sets the IPV6_PREFER_SRC_COA flag, it MUST use the same for the "ai_eflag" field of the addrinfo data
为了允许不同的实现在getaddrinfo（）和协议栈中执行不同部分的地址选择，本规范要求应用程序在调用getaddrinfo（）和setsockopt（）时设置语义等效的标志。例如，如果应用程序设置了IPV6_preference_SRC_COA标志，则它必须对addrinfo数据的“ai_eflag”字段使用相同的标志
structure when calling getaddrinfo(). If applications are not setting the semantically equivalent flags, the behavior of the implementation is undefined.
调用getaddrinfo（）时的结构。如果应用程序未设置语义等价的标志，则实现的行为未定义。
An example of usage of this API is given below:
下面给出了此API的使用示例：
struct addrinfo hints, *ai, *ai0;
uint32_t preferences;
struct addrinfo hints, *ai, *ai0;
uint32_t preferences;
preferences = IPV6_PREFER_SRC_TMP;
首选项=IPV6\u首选项\u SRC\u TMP；
hints.ai_flags |= AI_EXTFLAGS;
hints.ai_eflags = preferences; /* Chosen address preference flag */
/* Fill in other hints fields */
hints.ai_flags |= AI_EXTFLAGS;
hints.ai_eflags = preferences; /* Chosen address preference flag */
/* Fill in other hints fields */
getaddrinfo(....,&hints,. &ai0..);
getaddrinfo(....,&hints,. &ai0..);
/* Loop over all returned addresses and do connect */
for (ai = ai0; ai; ai = ai->ai_next) {
s = socket(ai->ai_family, ...);
/* Loop over all returned addresses and do connect */
for (ai = ai0; ai; ai = ai->ai_next) {
s = socket(ai->ai_family, ...);
setsockopt(s, IPV6_ADDR_PREFERENCES, (void *) &preferences, sizeof (preferences));
setsockopt（s，IPV6地址首选项，（void*）和首选项，sizeof（首选项））；
if (connect(s, ai->ai_addr, ai->ai_addrlen) == -1){
close (s);
s = -1;
continue;
}
if (connect(s, ai->ai_addr, ai->ai_addrlen) == -1){
close (s);
s = -1;
continue;
}
break;
}
break;
}
freeaddrinfo(ai0);
freeaddrinfo（ai0）；
o Within the same application, if a specific source address is set by either bind() or IPV6_PKTINFO socket option, while at the same time an address selection preference is expressed with the IPV6_ADDR_PREFERENCES socket option, then the source address setting carried by bind() or IPV6_PKTINFO takes precedence over the address selection setting.
o 在同一应用程序中，如果通过bind（）或IPV6_PKTINFO套接字选项设置特定的源地址，同时使用IPV6_ADDR_PREFERENCES套接字选项表示地址选择首选项，则bind（）或IPV6_PKTINFO携带的源地址设置优先于地址选择设置。
o setsockopt() and getaddrinfo() should silently ignore any address preference flags that are not supported in the system. For example, a host that does not implement Mobile IPv6, should not fail setsockopt() or getaddrinfo() that specify preferences for home or care-of addresses. The socket option calls should return error (-1) and set errno to EINVAL when contradictory flags values are passed to them.
o setsockopt（）和getaddrinfo（）应自动忽略系统中不支持的任何地址首选项标志。例如，未实现移动IPv6的主机不应使setsockopt（）或getaddrinfo（）失败，因为它们指定了home或care-of地址的首选项。套接字选项调用应返回错误（-1），并在向其传递相互矛盾的标志值时将errno设置为EINVAL。
o If an implementation supports both stream and datagram sockets, it should implement the address preference mechanism API described in this document on both types of sockets.
o 如果一个实现同时支持流套接字和数据报套接字，那么它应该在这两种类型的套接字上实现本文档中描述的地址首选机制API。
o An implementation supporting this API MUST implement both getaddrinfo() extension flags and socket option flags processing for portability of applications.
o 支持此API的实现必须同时实现getaddrinfo（）扩展标志和套接字选项标志处理，以实现应用程序的可移植性。
o The following flags are set as default values on a system (which is consistent with [RFC3484] defaults):
o 以下标志设置为系统上的默认值（与[RFC3484]默认值一致）：
IPV6_PREFER_SRC_HOME
IPV6\u首选\u SRC\u主页
IPV6_PREFER_SRC_PUBLIC
IPV6\u首选\u SRC\u公共
IPV6_PREFER_SRC_CGA
IPV6\u首选\u SRC\u CGA
This API defines only those flags that are deemed to be useful by the applications to alter default address selection rules. Thus, we discuss the mapping of each set of flags to the corresponding rule number in the address selection document [RFC3484].
此API仅定义应用程序认为对更改默认地址选择规则有用的标志。因此，我们在地址选择文档[RFC3484]中讨论了每组标志到相应规则编号的映射。
Source address selection rule #4 (prefer home address):
源地址选择规则#4（首选家庭地址）：
IPV6_PREFER_SRC_HOME (default)
IPV6\u首选\u SRC\u主页（默认）
IPV6_PREFER_SRC_COA
IPV6\u首选\u SRC\u COA
Source address selection rule #7 (prefer public address):
源地址选择规则#7（首选公共地址）：
IPV6_PREFER_SRC_PUBLIC (default)
IPV6\u首选\u SRC\u公共（默认）
IPV6_PREFER_SRC_TMP
IPV6\u首选\u SRC\u TMP
At this time, this document does not define flags to alter source address selection rule #2 (prefer appropriate scope for destination) and destination address selection rule #8 (prefer smaller scope), as the implementers felt that there were no practical applications that
此时，本文档没有定义标志来更改源地址选择规则#2（首选合适的目的地范围）和目的地地址选择规则#8（首选较小的范围），因为实施者认为没有实际的应用程序
can take advantage of reverting the scoping rules of IPv6 default address selection. Flags altering other destination address selection rules (#4, prefer home address and #7, prefer native transport) could have applications, but the problem is that the local system cannot systematically determine whether a destination address is a tunnel address for destination rule #7 (although it can when the destination address is one of its own, or can be syntactically recognized as a tunnel address, e.g., a 6-to-4 address.) The flags defined for source address selection rule #4 (prefer home address) should also take care of destination address selection rule #4. Thus, at this point, it was decided not to define flags for these destination rules.
可以利用恢复IPv6默认地址选择的作用域规则。改变其他目标地址选择规则的标志（#4，首选家庭地址和#7，首选本机传输）可能有应用程序，但问题是本地系统无法系统地确定目标地址是否是目标规则#7的隧道地址（尽管当目标地址是它自己的地址时，它可以，或者可以在语法上被识别为隧道地址，例如6到4地址）为源地址选择规则#4（首选家庭地址）定义的标志还应注意目标地址选择规则#4。因此，此时决定不为这些目标规则定义标志。
Also, note that there is no corresponding destination address selection rule for source address selection rule #7 (prefer public addresses) of default address selection document [RFC3484]. However, this API provides a way for an application to make sure that the source address preference set in setsockopt() is taken into account by the getaddrinfo() function. Let's consider an example to understand this scenario. DA and DB are two global destination addresses and the node has two global source addresses SA and SB through interface A and B respectively. SA is a temporary address while SB is a public address. The application has set IPV6_PREFER_SRC_TMP in the setsockopt() flag. The route to DA points to interface A and the route to DB points to interface B. Thus, when AI_EXTFLAGS in ai_flags and IPV6_PREFER_SRC_TMP in ai_eflags are set, getaddrinfo() returns DA before DB in the list of destination addresses and thus, SA will be used to communicate with the destination DA. Similarly, getaddrinfo() returns DB before DA when AI_EXTFLAGS and ai_eflags are set to IPV6_PREFER_SRC_PUBLIC. Thus, the source address preference is taking effect into destination address selection as well as source address selection by the getaddrinfo() function.
另外，请注意，默认地址选择文档[RFC3484]的源地址选择规则#7（首选公共地址）没有相应的目标地址选择规则。但是，此API为应用程序提供了一种方法，以确保getaddrinfo（）函数考虑了setsockopt（）中设置的源地址首选项。让我们考虑一个例子来理解这个场景。DA和DB是两个全局目标地址，节点通过接口A和B分别拥有两个全局源地址SA和SB。SA是临时地址，SB是公共地址。应用程序已在setsockopt（）标志中设置了IPV6_preference_SRC_TMP。到DA的路由指向接口A，到DB的路由指向接口B。因此，当设置了AI_标志中的AI_EXTFLAGS和AI_eflags中的IPV6_preference_SRC_TMP时，getaddrinfo（）在目标地址列表中返回DB之前的DA，因此SA将用于与目标DA通信。类似地，当AI_EXTFLAGS和AI_eflags设置为IPV6_preference_SRC_PUBLIC时，getaddrinfo（）返回DA之前的DB。因此，源地址首选项将在目标地址选择以及getaddrinfo（）函数选择源地址时生效。
The following numerical example clarifies the above further.
下面的数值示例进一步澄清了上述内容。
Imagine a host with two addresses:
设想一台主机有两个地址：
1234::1:1 public
1234::1:1 public
9876::1:2 temporary
9876::1:2 temporary
The destination has the following two addresses:
目标具有以下两个地址：
1234::9:3
1234::9:3
9876::9:4
9876::9:4
By default, getaddrinfo() will return the destination addresses in the following order:
默认情况下，getaddrinfo（）将按以下顺序返回目标地址：
1234::9:3
1234::9:3
9876::9:4
9876::9:4
because the public source is preferred and 1234 matches more bits with the public source address. On the other hand, if ai_flags is set to AI_EXTFLAGS and ai_eflags to IPV6_PREFER_SRC_TMP, getaddrinfo will return the addresses in the reverse order since the temporary source address will be preferred.
因为首选公共源，1234将更多位与公共源地址匹配。另一方面，如果ai_flags设置为ai_EXTFLAGS，ai_eflags设置为IPV6_preference_SRC_TMP，则getaddrinfo将以相反的顺序返回地址，因为临时源地址将是首选的。
Other source address rules (that are not mentioned here) were also deemed not applicable for changing its default on a per-application basis.
其他源地址规则（此处未提及）也被视为不适用于更改每个应用程序的默认值。
IPv4-mapped IPv6 addresses for AF_INET6 sockets are supported in this API. In some cases, the application of IPv4-mapped addresses are limited because the API attributes are IPv6 specific. For example, IPv6 temporary addresses and cryptographically generated addresses have no IPv4 counterparts. Thus, the IPV6_PREFER_SRC_TMP or IPV6_PREFER_SRC_CGA are not directly applicable to an IPv4-mapped IPv6 address. However, the IPv4-mapped address support may be useful for mobile-IPv4 applications shifting the source address between the home address and the care-of address. Thus, the IPV6_PREFER_SRC_COA and IPV6_PREFER_SRC_HOME are applicable to an IPv4-mapped IPv6 address. At this point, it is not well understood whether this particular API has any value to IPv4 addresses or AF_INET family of sockets, but a similar model still applies to AF_INET socket family if corresponding address flags are defined.
此API支持AF_INET6套接字的IPv4映射IPv6地址。在某些情况下，IPv4映射地址的应用受到限制，因为API属性是特定于IPv6的。例如，IPv6临时地址和加密生成的地址没有IPv4对应项。因此，IPV6_preference_SRC_TMP或IPV6_preference_SRC_CGA不直接适用于IPv4映射的IPV6地址。但是，IPv4映射地址支持对于移动IPv4应用程序在家庭地址和转交地址之间移动源地址可能很有用。因此，IPV6_preference_SRC_COA和IPV6_preference_SRC_HOME适用于IPv4映射的IPV6地址。目前，还不清楚这个特定的API是否对IPv4地址或AF_INET套接字系列有任何价值，但如果定义了相应的地址标志，类似的模型仍然适用于AF_INET套接字系列。
Sometimes an application may have a requirement to only use addresses with some particular attribute, and if no such address is available, the application should fail to communicate instead of communicating using the 'wrong' address. In that situation, address selection preferences do not guarantee that the application requirements are met. Instead, the application has to use a new call that binds a socket to the source address that would be selected to communicate with a given destination address, according to its preferences, and then explicitly verify that the chosen address satisfies its requirements using a validation function. Such an application would go through the following steps:
有时，应用程序可能要求仅使用具有某些特定属性的地址，如果没有此类地址可用，则应用程序应无法通信，而不是使用“错误”地址进行通信。在这种情况下，地址选择首选项不能保证满足应用程序要求。相反，应用程序必须使用一个新的调用，该调用将套接字绑定到源地址，该源地址将根据其首选项选择与给定的目标地址通信，然后使用验证函数显式验证所选地址是否满足其要求。此类应用程序将经历以下步骤：
1. The application specifies one or more IPV6_PREFER_SRC_* flags and AI_EXTFLAGS ai_flags with getaddrinfo().
1. 应用程序使用getaddrinfo（）指定一个或多个IPV6_preference_SRC_*标志和AI_EXTFLAGS AI_标志。
2. The application specifies the same IPV6_PREFER_SRC_* flags with setsockopt().
2. 应用程序使用setsockopt（）指定相同的IPV6_preference_SRC_*标志。
3. The application calls the stack to select a source address to communicate with the specified destination address, according to the expressed address selection preferences. This is achieved with a connect() call, or a bind2addrsel() call as specified below. The connect() function must not be used when the application uses connection-oriented communication (e.g., TCP) and want to ensure that no single packet (e.g., TCP SYN) is sent before the application could verify that its requirements were fulfilled. Instead, the application must use the newly introduced bind2addrsel() call, which binds a socket to the source address that would be selected to communicate with a given destination address, according to the application's preferences. For datagram-oriented communications (e.g., UDP), the connect() call can be used since it results in the stack selecting a source address without sending any packets.
3. 应用程序调用堆栈，根据表示的地址选择首选项，选择与指定目标地址通信的源地址。这是通过以下指定的connect（）调用或bind2addrsel（）调用实现的。当应用程序使用面向连接的通信（如TCP）并希望确保在应用程序验证其要求得到满足之前不发送任何数据包（如TCP SYN）时，不得使用connect（）函数。相反，应用程序必须使用新引入的bind2addrsel（）调用，该调用将套接字绑定到源地址，根据应用程序的首选项，源地址将被选择与给定的目标地址通信。对于面向数据报的通信（例如UDP），可以使用connect（）调用，因为它会导致堆栈选择源地址而不发送任何数据包。
4. Retrieve the selected source address using the getsockname() API call.
4. 使用getsockname（）API调用检索选定的源地址。
5. Verify with the validation function that the retrieved address is satisfactory as specified below. If not, abort the communication, e.g., by closing the socket.
5. 使用验证功能验证检索到的地址是否符合以下规定。如果没有，则中止通信，例如关闭套接字。
The binding of the socket to the address that would be selected to communicate with a given destination address, according to the application preferences, is accomplished via a new binding function defined for this purpose:
根据应用程序首选项，通过为此目的定义的新绑定函数，将套接字绑定到将被选择与给定目标地址通信的地址：
#include <netinet/in.h>
#include <netinet/in.h>
int bind2addrsel(int s, const struct sockaddr *dstaddr, socklen_t dstaddrlen);
int bind2addssel（int s，常量结构sockaddr*dstaddr，socklen_t dstaddrlen）；
where s is the socket that source address selection preferences have been expressed by the application, the dstaddr is a non-NULL pointer to a sockaddr_in6 structure initialized as follows:
其中s是应用程序已表示源地址选择首选项的套接字，dstaddr是指向sockaddr_in6结构的非空指针，初始化如下：
o sin6_addr is a 128-bit IPv6 destination address with which the local node wants to communicate;
o sin6_addr是本地节点想要与之通信的128位IPv6目标地址；
o sin6_family MUST be set to AF_INET6;
o sin6_族必须设置为AF_INET6；
o sin6_scope_id MUST be set if the address is link-local;
o 如果地址是本地链路，则必须设置sin6_scope_id；
and dstaddrlen is the size of the sockaddr structure passed as argument.
dstaddrlen是作为参数传递的sockaddr结构的大小。
The bind2addrsel() call is defined to return the same values as the bind() call, i.e., 0 if successful, -1 otherwise while the global variable errno is set to indicate the error. The bind2addrsel() call fails for the same reasons that the bind() call.
bind2addrsel（）调用被定义为返回与bind（）调用相同的值，即如果成功返回0，否则返回1，而全局变量errno被设置为指示错误。bind2addrsel（）调用失败的原因与bind（）调用失败的原因相同。
The verification of temporary vs. public, home vs. care-of, CGA vs. not, are performed by a new validation function defined for this purpose:
临时与公共、家庭与护理、CGA与非的验证由为此目的定义的新验证功能执行：
#include <netinet/in.h>
#include <netinet/in.h>
short inet6_is_srcaddr(struct sockaddr_in6 *srcaddr, uint32_t flags);
短inet6_为srcadr（6*srcadr中的结构sockaddr_，uint32_t标志）；
where the flags contain the specified IPV6_PREFER_SRC_* source preference flags, and the srcaddr is a non-NULL pointer to a sockaddr_in6 structure initialized as follows:
其中，标志包含指定的IPV6_preference_SRC_*源首选项标志，srcadr是指向sockaddr_in6结构的非空指针，初始化如下：
o sin6_addr is a 128-bit IPv6 address of the local node.
o sin6_addr是本地节点的128位IPv6地址。
o sin6_family MUST be set to AF_INET6.
o sin6_族必须设置为AF_INET6。
o sin6_scope_id MUST be set if the address is link-local.
o 如果地址是本地链接，则必须设置sin6_范围_id。
inet6_is_srcaddr() is defined to return three possible values (0, 1, -1): The function returns true (1) when the IPv6 address corresponds to a valid address in the node and satisfies the given preference flags. If the IPv6 address input value does not correspond to any address in the node or if the flags are not one of the valid preference flags, it returns a failure (-1). If the input address does not match an address that satisfies the preference flags indicated, the function returns false (0.)
inet6_is_srcadr（）定义为返回三个可能的值（0，1，-1）：当IPv6地址对应于节点中的有效地址并满足给定的首选项标志时，函数返回true（1）。如果IPv6地址输入值与节点中的任何地址都不对应，或者如果这些标志不是有效的首选项标志之一，则返回失败（-1）。如果输入地址与满足指定首选项标志的地址不匹配，则函数返回false（0）
This function can handle multiple valid preference flag combinations as its second parameter, for example, IPV6_PREFER_SRC_COA | IPV6_PREFER_SRC_TMP, which means that all flags MUST be satisfied for the result to be true. Contradictory flag values result in a false return value.
此函数可以处理多个有效的首选项标志组合作为其第二个参数，例如IPV6_preference_SRC_COA | IPV6_preference_SRC_TMP，这意味着必须满足所有标志才能使结果为真。相互矛盾的标志值会导致错误的返回值。
The function will return true for IPV6_PREFER_SRC_HOME even if the host is not implementing mobile IPv6, as well as for a mobile node that is at home (i.e., does not have any care-of address).
即使主机未实现移动IPV6，对于IPV6_preference_SRC_HOME，以及对于在家中的移动节点（即，没有任何转交地址），该函数也将返回true。
The following list summarizes the constants, structure, and extern definitions discussed in this memo, sorted by header.
以下列表总结了本备忘录中讨论的常量、结构和外部定义，并按标题排序。
<netdb.h> AI_EXTFLAGS
<netdb.h> IPV6_PREFER_SRC_HOME
<netdb.h> IPV6_PREFER_SRC_COA
<netdb.h> IPV6_PREFER_SRC_TMP
<netdb.h> IPV6_PREFER_SRC_PUBLIC
<netdb.h> IPV6_PREFER_SRC_CGA
<netdb.h> IPV6_PREFER_SRC_NONCGA
<netdb.h> EAI_BADEXTFLAGS
<netdb.h> struct addrinfo{};
<netdb.h> AI_EXTFLAGS
<netdb.h> IPV6_PREFER_SRC_HOME
<netdb.h> IPV6_PREFER_SRC_COA
<netdb.h> IPV6_PREFER_SRC_TMP
<netdb.h> IPV6_PREFER_SRC_PUBLIC
<netdb.h> IPV6_PREFER_SRC_CGA
<netdb.h> IPV6_PREFER_SRC_NONCGA
<netdb.h> EAI_BADEXTFLAGS
<netdb.h> struct addrinfo{};
<netinet/in.h> IPV6_PREFER_SRC_HOME
<netinet/in.h> IPV6_PREFER_SRC_COA
<netinet/in.h> IPV6_PREFER_SRC_TMP
<netinet/in.h> IPV6_PREFER_SRC_PUBLIC
<netinet/in.h> IPV6_PREFER_SRC_CGA
<netinet/in.h> IPV6_PREFER_SRC_NONCGA
<netinet/in.h> short inet6_is_srcaddr(struct sockaddr_in6 *,
uint32_t);
<netinet/in.h> int bind2addrsel(int, const struct sockaddr *,
socklen_t);
<netinet/in.h> IPV6_PREFER_SRC_HOME
<netinet/in.h> IPV6_PREFER_SRC_COA
<netinet/in.h> IPV6_PREFER_SRC_TMP
<netinet/in.h> IPV6_PREFER_SRC_PUBLIC
<netinet/in.h> IPV6_PREFER_SRC_CGA
<netinet/in.h> IPV6_PREFER_SRC_NONCGA
<netinet/in.h> short inet6_is_srcaddr(struct sockaddr_in6 *,
uint32_t);
<netinet/in.h> int bind2addrsel(int, const struct sockaddr *,
socklen_t);
This document conforms to the same security implications as specified in the Basic IPv6 socket API [RFC3493] and address selection rules [RFC3484]. Allowing applications to specify a preference for temporary addresses provides per-application (and per-socket) ability to use the privacy benefits of the temporary addresses. The setting of certain address preferences (e.g., not using a CGA address, or not using a temporary address) may be restricted to privileged processes because of security implications.
本文档符合基本IPv6套接字API[RFC3493]和地址选择规则[RFC3484]中规定的相同安全含义。允许应用程序指定临时地址的首选项，使每个应用程序（和每个套接字）能够使用临时地址的隐私优势。某些地址首选项的设置（例如，不使用CGA地址或不使用临时地址）可能由于安全问题而限制为特权进程。
The authors like to thank members of Mobile-IP and IPV6 working groups for useful discussion on this topic. Richard Draves and Dave Thaler suggested that getaddrinfo also needs to be considered along with the new socket option. Gabriel Montenegro suggested that CGAs may also be considered in this document. Thanks to Alain Durand, Renee Danson, Alper Yegin, Francis Dupont, Keiichi Shima, Michael Hunter, Sebastien Roy, Robert Elz, Pekka Savola, Itojun, Jim Bound, Jeff Boote, Steve Cipolli, Vlad Yasevich, Mika Liljeberg, Ted Hardie, Vidya Narayanan, and Lars Eggert for useful discussions and
作者要感谢移动IP和IPV6工作组的成员对此主题进行了有益的讨论。Richard Draves和Dave Thaler建议，getaddrinfo还需要与新的套接字选项一起考虑。加布里埃尔·黑山建议在本文件中也考虑CGA。感谢阿兰·杜兰德、蕾妮·丹森、阿尔珀·耶金、弗朗西斯·杜邦、石庆一、迈克尔·亨特、塞巴斯蒂安·罗伊、罗伯特·埃尔兹、佩卡·萨沃拉、伊藤忠、吉姆·邦德、杰夫·布特、史蒂夫·西波利、弗拉德·亚舍维奇、米卡·利耶贝格、特德·哈迪、维迪亚·纳拉亚南和拉尔斯·艾格特的有益讨论和支持
suggestions. Thanks to Remi Denis-Courmont, Brian Haberman, Brian Haley, Bob Gilligan, Jack McCann, Jim Bound, Jinmei Tatuya, Suresh Krishnan, Hilarie Orman, Geoff Houston, Marcelo Bungulo, and Jari Arkko for the review of this document and suggestions for improvement.
建议。感谢Remi Denis Courmon、Brian Haberman、Brian Haley、Bob Gilligan、Jack McCann、Jim Bond、Jimmi Tatuya、Suresh Krishnan、Hilarie Orman、Geoff Houston、Marcelo Bungulo和Jari Arkko对本文件的审查和改进建议。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[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月。
[RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. Stevens, "Basic Socket Interface Extensions for IPv6", RFC 3493, February 2003.
[RFC3493]Gilligan，R.，Thomson，S.，Bound，J.，McCann，J.，和W.Stevens，“IPv6的基本套接字接口扩展”，RFC 3493，2003年2月。
[FPING] "Fping - a program to ping hosts in parallel", Online web site http://www.fping.com.
[FPING]“FPING-并行ping主机程序”，在线网站http://www.fping.com.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[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月。
[RFC3542] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei, "Advanced Sockets Application Program Interface (API) for IPv6", RFC 3542, May 2003.
[RFC3542]Stevens，W.，Thomas，M.，Nordmark，E.，和T.Jinmei，“IPv6的高级套接字应用程序接口（API）”，RFC 3542，2003年5月。
[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月。
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3971]Arkko，J.，Kempf，J.，Zill，B.，和P.Nikander，“安全邻居发现（SEND）”，RFC 39712005年3月。
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005.
[RFC3972]Aura，T.，“加密生成地址（CGA）”，RFC 39722005年3月。
This document discusses setting source address selection preferences on a per-socket basis with the new IPV6_ADDR_PREFERENCES socket option used in setsockopt(). The document does not encourage setting the source address selection preference on a per-packet basis through the use of ancillary data objects with sendmsg(), or setsockopt() with unconnected datagram sockets.
本文档讨论如何使用setsockopt（）中使用的新IPV6_ADDR_preferences套接字选项，在每个套接字的基础上设置源地址选择首选项。本文档不鼓励通过将辅助数据对象与sendmsg（）一起使用，或将setsockopt（）与未连接的数据报套接字一起使用，在每个数据包的基础上设置源地址选择首选项。
Per-packet source address selection is expensive, as the system will have to determine the source address indicated by the application preference before sending each packet, while setsockopt() address preference on a connected socket makes the selection once and uses that source address for all packets transmitted through that socket endpoint, as long as the socket option is set.
每个数据包的源地址选择是昂贵的，因为在发送每个数据包之前，系统必须确定应用程序首选项指示的源地址，而连接套接字上的setsockopt（）地址首选项只进行一次选择，并将该源地址用于通过该套接字端点传输的所有数据包，只要设置了套接字选项。
However, this document provides guidelines for those implementations that like to have an option on implementing transmit-side ancillary data object support for altering default source address selection. Therefore, if an application chooses to use the per-packet source address selection, then the implementation should process at the IPPROTO_IPV6 level (cmsg_level) ancillary data object of type (cmsg_type) IPV6_ADDR_PREFERENCES containing as data (cmsg_data[]) a 32-bit unsigned integer encoding the source address selection preference flags (e.g., IPV6_PREFER_SRC_COA | IPV6_PREFER_SRC_PUBLIC) in a fashion similar to the advanced IPV6 Socket API [RFC3542]. This address selection preference ancillary data object may be present along with other ancillary data objects.
但是，本文档为那些希望实现传输端辅助数据对象支持以改变默认源地址选择的实现提供了指导。因此，如果应用程序选择使用每包源地址选择，则实现应在IPPROTO_IPV6级别（cmsg_级别）处理类型为（cmsg_类型）IPV6_ADDR_首选项的辅助数据对象，其中包含作为数据（cmsg_data[]）的32位无符号整数编码源地址选择首选项标志（例如，IPV6_preference_SRC_COA | IPV6_preference_SRC_PUBLIC）以类似于高级IPV6套接字API[RFC3542]的方式。此地址选择首选项辅助数据对象可能与其他辅助数据对象一起出现。
The implementation processing the ancillary data object is responsible for the selection of the preferred source address as indicated in the ancillary data object. Thus, an application can use sendmsg() to pass an address selection preference ancillary data object to the IPv6 layer. The following example shows usage of the ancillary data API for setting address preferences:
处理辅助数据对象的实现负责选择辅助数据对象中指示的首选源地址。因此，应用程序可以使用sendmsg（）将地址选择首选项辅助数据对象传递给IPv6层。以下示例显示了用于设置地址首选项的辅助数据API的用法：
void *extptr;
socklen_t extlen;
struct msghdr msg;
struct cmsghdr *cmsgptr;
int cmsglen;
struct sockaddr_in6 dest;
uint32_t flags;
void *extptr;
socklen_t extlen;
struct msghdr msg;
struct cmsghdr *cmsgptr;
int cmsglen;
struct sockaddr_in6 dest;
uint32_t flags;
extlen = sizeof(flags);
cmsglen = CMSG_SPACE(extlen);
cmsgptr = malloc(cmsglen);
cmsgptr->cmsg_len = CMSG_LEN(extlen);
cmsgptr->cmsg_level = IPPROTO_IPV6;
cmsgptr->cmsg_type = IPV6_ADDR_PREFERENCES;
extlen = sizeof(flags);
cmsglen = CMSG_SPACE(extlen);
cmsgptr = malloc(cmsglen);
cmsgptr->cmsg_len = CMSG_LEN(extlen);
cmsgptr->cmsg_level = IPPROTO_IPV6;
cmsgptr->cmsg_type = IPV6_ADDR_PREFERENCES;
extptr = CMSG_DATA(cmsgptr);
extptr = CMSG_DATA(cmsgptr);
flags = IPV6_PREFER_SRC_COA;
memcpy(extptr, &flags, extlen);
flags = IPV6_PREFER_SRC_COA;
memcpy(extptr, &flags, extlen);
msg.msg_control = cmsgptr;
msg.msg_controllen = cmsglen;
msg.msg_control = cmsgptr;
msg.msg_controllen = cmsglen;
/* finish filling in msg{} */
/* finish filling in msg{} */
msg.msg_name = dest;
msg.msg_name=dest；
sendmsg(s, &msg, 0);
sendmsg（s和msg，0）；
Thus, when an IPV6_ADDR_PREFERENCES ancillary data object is passed to sendmsg(), the value included in the object is used to specify address preference for the packet being sent by sendmsg().
因此，当IPV6_ADDR_PREFERENCES辅助数据对象传递给sendmsg（）时，该对象中包含的值用于指定sendmsg（）发送的数据包的地址首选项。
This document only defines a source preference flag to choose Cryptographically Generated Address (CGA) as the source address when applicable. CGAs are obtained using public keys and hashes to prove address ownership. Several IPR claims have been made about such methods.
本文档仅定义一个源首选项标志，以在适用时选择加密生成地址（CGA）作为源地址。CGA是使用公钥和哈希来证明地址所有权的。已经就此类方法提出了几项知识产权要求。
Authors' Addresses
作者地址
Erik Nordmark Sun Microsystems, Inc. 17 Network Circle Menlo Park, CA 94025 USA
Erik Nordmark Sun Microsystems，Inc.美国加利福尼亚州门罗公园17号网络圈，邮编94025
EMail: Erik.Nordmark@Sun.com
EMail: Erik.Nordmark@Sun.com
Samita Chakrabarti Azaire Networks 3121 Jay Street, Suite 210 Santa Clara, CA 95054 USA
Samita Chakrabarti Azaire Networks美国加利福尼亚州圣克拉拉市杰街3121号210室，邮编95054
EMail: samitac2@gmail.com
EMail: samitac2@gmail.com
Julien Laganier DoCoMo Euro-Labs Landsbergerstrasse 312 D-80687 Muenchen Germany
Julien Laganier DoCoMo Euro Labs Landsbergerstrasse 312 D-80687德国慕尼黑
EMail: julien.IETF@laposte.net
EMail: julien.IETF@laposte.net
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
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.