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
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を介してアドレス選択規則の一部の意味を逆転させることができなければならないことを示しています。しかし、そのようなソケットAPIは、基本的な（RFC 3493）または高度（RFC 3542）は、IPv6ソケット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
[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]はIPv6の[RFC2460]のデフォルトのアドレス選択規則を指定します。この文書では、アプリケーションがソースアドレス選択のデフォルトの選択を上書きできるようにするソケットAPIの拡張機能を定義します。したがって、間接的のgetaddrinfo介して宛先アドレスの選択を（）に影響を与えます。プライバシーの考慮事項[RFC3041]は、「パブリック」と「一時的な」アドレスを導入しました。 IPv6のモビリティ[RFC3775]は、モバイルシステムで「自宅住所」と「気付アドレス」の定義を紹介しています。
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 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.
現在、IPv6のソケットAPIの拡張機能は、単純なバインド（）操作またはIPV6_PKTINFOソケットオプション[RFC3542]を通じて特定の送信元アドレスを選択するためのメカニズムを提供します。しかし、（バインドを使用するために）またはIPV6_PKTINFOソケットオプション、アプリケーション自体は、送信元アドレス（例えば、宛先にパケットを送信するために使用されるインターフェースに対して）宛先アドレスのために適切であることを確認しなければなりません。アプリケーションはまたように宛先アドレスに対して送信元アドレス範囲の妥当性を検証する必要があると。実際に、それはルールのいずれかに関連して、その設定を変更するために、すべてのデフォルトのアドレス選択ルールを実装する必要があるので、これは、アプリケーションのための非常に複雑になることがあります。
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.
この文書のメカニズムは、まだシステムを持ちながら、それが好む送信元アドレスの属性を指定するには、アプリケーションがアドレス選択ルールの残りの部分を行うことができます。例えば、もしアプリケーションが、それはソースアドレスとしてホームアドレス上で気付アドレスを使用することを好むことを指定し、ホストが2気付アドレス、公共の1と1の一時を持っている場合、ホストは、公共のケアを選択することになります一時アドレスの上に国民を好むため、デフォルトのアドレス選択ルールに従うことによって-ofアドレス。
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を提供していないホスト上で実行されている場合でも、それが原因気付アドレスのNOが利用可能であることに失敗するアプリケーションのために意味がありません。利用可能なIPアドレスのセットは非常によく、アプリケーションがgetaddrinfoは呼び出されたときから変更されている可能性があるためまた、UDPソケットとのsendto（）またはsendmsgのを（）プリミティブ使用した場合、特に、ハード要件の使用は、問題となっているだろう（）それはのsendto（）またはsendmsgのを（）と呼ばれるまで、新たな故障モードを導入思われます。
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.)
さらに、このアプローチは、アプリケーションは、ルールに従って選択されたアドレスのためにその嗜好を指定反対嗜好（すなわち、復帰規則に従って選択されたアドレス）、または選択できるように変更することができ、各ルールのための2つのフラグを定義することですそのルールに関連するフラグのいずれかを設定し、システムのデフォルト（第4節）にそれを残していません。このアプローチは、異なる実装が異なるシステムデフォルトを持つことができ、及び（）のsetsockoptと同様）のgetaddrinfo（と連動します。 （の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 explains how getaddrinfo() can be used to select the destination address while taking the preferred source addresses into consideration (Section 11).
この文書は、直接[RFC3484]に記載の宛先アドレス選択規則を変更しないことに留意されたいです。分析は、アプリケーションによって変更することができる宛先アドレスルールを参照することが行われています。デフォルトアドレス選択文書のルール番号4（ホームアドレスを好む）、8（小さい範囲を好む）、7（ネイティブインタフェースを好む）[RFC3484]は、宛先アドレスの変更を考慮に入れました。アプリケーションは、アドレスフラグの好適な宛先タイプとのsetsockopt（）を適用することによって、直接宛先アドレス選択規則を変更するが、これを書いているように、十分に実用的な使用量はありませんでした。しかし、この文書では、優先送信先アドレスを選択するためのフラグを追加することの可能性を排除していません。しかしながら、[RFC3484]宛先アドレス選択ルールは、このように、本書に記載された方法を使用して、デフォルトのソースアドレス選択を変更することによって、一つは間接宛先アドレス選択の選択に影響を与える、送信元アドレスの選択に依存しています。したがって、この文書は、検討（セクション11）に好適なソースアドレスをながら宛先アドレスを選択するために使用することができる方法のgetaddrinfo（）説明します。
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に拡張子を指定します。その意図は、この文書はまた、ミドルウェアシステムやJava環境で見られるような、他のネットワークAPIで表現する必要がIPアドレスの属性のための好みを表現するためのモデルとして役立つということです。同様のモデルは、他のソケットの家族のために適用されます。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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アプリケーション、[RFC3775]であり、Aの前に鍵交換をしたいです成功ホーム登録。また、モバイルIPv6対応アプリケーションは、ホームアドレスを切り替えると気付アドレス、アプリケーションのその場所と状態に応じてすることができます。それはまた別のソケットをオープンし、1つのソケットと気付アドレスの他の人のためのソースアドレスとしてホームアドレスを使用することをお勧めします。
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.
同様に、ノードは、セキュア近隣探索[RFC3971]のように、デフォルトで暗号化生成アドレス[RFC3972]を使用するように構成されてもよいが、アプリケーションは、それを使用しないことができます。例えば、[FPING]、並列にパケットを送信することにより、複数の目的地の基本的な到達可能性をテストし、デバッグツールをfping。これらのパケットは、CGAソースアドレスを使用している場合、SEND使用する近隣探索のシグナル伝達を開始するに終わる可能性があります。言っCGAアドレスの所有権を証明するために実行するにいくつかの暗号化操作を送信します。アプリケーションは、この機能を必要としない場合は、SENDによって行われる潜在的に高価な計算を避けるために、非CGAアドレスを使用したいと思います。ノードはデフォルトとして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.
いくつかは、アプリケーションごとのフラグの代わりに、ソケット単位およびパケットのフラグを持つことが示唆されました。しかし、この設計は、次の理由でソケットごとおよびパケットフラグでとどまる：一部のシステムでは、（例えばUnixシステムでの環境変数など）ごとの環境/アプリケーションフラグを持っているが、これは実装するすべてのシステムで利用できない場合がありますoをソケット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文書では、アプリケーションはソースアドレス選択の3つの選択肢があります。
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とアドレスを使用したい：セットフラグ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_COA /* Prefer Care-of address as source */
IPV6_PREFER_SRC_TMP /* Prefer Temporary address as source */
IPV6_PREFER_SRC_PUBLIC /* Prefer Public address as source */
IPV6_PREFER_SRC_CGA /* Prefer 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_PREFER_SRC_PUBLIC | IPV6_PREFER_SRC_TMP
IPV6_PREFER_SRC_HOME | IPV6_PREFER_SRC_COA
IPV6_PREFER_SRC_HOME | IPV6_PREFER_SRC_COA
IPV6_PREFER_SRC_HOME | IPV6_PREFER_SRC_COA | IPV6_PREFER_SRC_TMP
IPV6_PREFER_SRC_HOME | IPV6_PREFER_SRC_COA | IPV6_PREFER_SRC_TMP
IPV6_PREFER_SRC_CGA | IPV6_PREFER_SRC_NONCGA
IPV6_PREFER_SRC_CGA | IPV6_PREFER_SRC_NONCGA
Etc.
等。
Examples of valid combinations of address selection flags are given below:
アドレス選択フラグの有効な組み合わせの例を以下に示します：
IPV6_PREFER_SRC_HOME | IPV6_PREFER_SRC_PUBLIC
IPV6_PREFER_SRC_HOME | IPV6_PREFER_SRC_PUBLIC
IPV6_PREFER_SRC_HOME | IPV6_PREFER_SRC_CGA
IPV6_PREFER_SRC_HOME | IPV6_PREFER_SRC_CGA
IPV6_PREFER_SRC_COA | IPV6_PREFER_SRC_PUBLIC | IPV6_PREFER_SRC_CGA
IPV6_PREFER_SRC_COA | IPV6_PREFER_SRC_PUBLIC | IPV6_PREFER_SRC_CGA
IPV6_PREFER_SRC_HOME | IPV6_PREFER_SRC_NONCGA
IPV6_PREFER_SRC_HOME | IPV6_PREFER_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_PREFER_SRC_TMP | IPV6_PREFER_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_ADDR_PREFERENCESと呼ばれています。これは、の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_COA /* Prefer Care-of address as source */
IPV6_PREFER_SRC_TMP /* Prefer Temporary address as source */
IPV6_PREFER_SRC_PUBLIC /* Prefer Public address as source */
IPV6_PREFER_SRC_CGA /* Prefer 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.
IPV6_ADDR_PREFERENCESが正常のsetsockopt（）で設定されている場合、指定したオプションの値は、ソケットを介して、任意の接続開始とそのソケットを介して送信された後続のすべてのパケットのアドレス設定を指定するために使用されます。 noオプションが設定されていない場合、システムはデフォルトアドレス選択アルゴリズムに従ってまたは他の同等の手段により、デフォルト値を選択します。
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.
アプリケーションがIPV6_ADDR_PREFERENCESオプション付きのsetsockopt（）を使用して、デフォルトのアドレス選択ルールを変更する場合したがって、アプリケーションは、そのの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_flags」フラグ設定フィールド。拡張の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 */
};
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:
新しいフラグ（AI_EXTFLAGS）はaddrinfo構造体の「ai_eflags」拡張フラグ設定フィールドを探すためにシステムに指示するためのaddrinfoデータ構造の「ai_flags」フラグセットフィールドに対して定義されています。それは、<netdb.h>ヘッダに定義されています。
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.
AI_EXTFLAGSフラグはADDRINFOデータ構造の「ai_flags」フラグ設定フィールドに設定されている場合、その後のgetaddrinfo（）の実装はADDRINFOデータ構造の拡張フラグ設定フィールド「ai_eflags」に格納されている「ai_eflags」値を探さなければなりません。 「ai_eflags」フィールドに格納されたフラグがAI_EXTFLAGSフラグはADDRINFOデータ構造の「ai_flags」フラグ設定フィールドに設定されている場合にのみ意味があります。デフォルトでは、AI_EXTFLAGSは「ai_flags」フラグ設定フィールドに設定されていません。 AI_EXTFLAGSが「ai_flags」フラグ設定フィールドに設定され、「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_PREFER_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_flags」フィールドにAI_EXTFLAGSを設定することによってのgetaddrinfoにヒント、および「ai_eflags」フィールド内の対応するアドレス選択優先フラグ（IPV6_PREFER_SRC_ *）ソースアドレス選択を渡します。
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].
例えばIPV6_PREFER_SRC_HOMEとIPV6_PREFER_SRC_COAとして矛盾フラグが、ai_eflagsに設定されている場合、のgetaddrinfo（）は失敗し、<netdb.h>ヘッダを含めた結果として定義された値のEAI_BADEXTFLAGSを返します。 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_tフラグ= IPV6_PREFER_SRC_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、（ボイド*）＆フラグはsizeof（フラグ））== -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);
/* 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、（ボイド*）＆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");
}
/*
*
* Do some work with the socket here.
*
*/
/* 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、（ボイド*）＆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 structure when calling getaddrinfo(). If applications are not setting the semantically equivalent flags, the behavior of the implementation is undefined.
異なる実装（）は、プロトコル・スタック内のgetaddrinfoのアドレス選択の異なる部分を実行することを可能にするために、この仕様は、はgetaddrinfo（）とのsetsockopt（）を呼び出す場合、アプリケーションが意味的に等価なフラグを設定する必要があります。アプリケーションがIPV6_PREFER_SRC_COAフラグを設定した場合のgetaddrinfoを呼び出すとき、例えば、それは（）のaddrinfoデータ構造の「ai_eflag」フィールドに同じものを使用しなければなりません。アプリケーションは、意味的に同等のフラグを設定されていない場合は、実装の動作は未定義です。
An example of usage of this API is given below:
このAPIの使い方の例を以下に示します：
struct addrinfo hints, *ai, *ai0;
uint32_t preferences;
preferences = IPV6_PREFER_SRC_TMP;
好み= IPV6_PREFER_SRC_TMP。
hints.ai_flags |= AI_EXTFLAGS;
hints.ai_eflags = preferences; /* Chosen address preference flag */
/* Fill in other hints fields */
getaddrinfo(....,&hints,. &ai0..);
getaddrinfo（....、＆ヒント,.＆AI0 ...）。
/* 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));
if (connect(s, ai->ai_addr, ai->ai_addrlen) == -1){
close (s);
s = -1;
continue;
}
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、同時にアドレス選択嗜好をバインド（によって運ばれ、ソースアドレス設定IPV6_ADDR_PREFERENCESソケットオプションで発現される特定の送信元アドレス）、バインド（）またはIPV6_PKTINFOソケットオプションのいずれかによって設定された場合または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は（）それは家のための環境設定を指定するか、気付アドレスを失敗してはいけません。ソケットオプションコールは（-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アプリケーションの移植性のために、両方のgetaddrinfo（）拡張フラグとソケットオプションフラグ処理を実装しなければならない。このAPIをサポートする実装。
o The following flags are set as default values on a system (which is consistent with [RFC3484] defaults):
以下のフラグは、（[RFC3484]のデフォルト値と一致している）システムのデフォルト値として設定されています○：
IPV6_PREFER_SRC_HOME
IPV6_PREFER_SRC_HOME
IPV6_PREFER_SRC_PUBLIC
IPV6_PREFER_SRC_PUBLIC
IPV6_PREFER_SRC_CGA
IPV6_PREFER_SRC_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_PREFER_SRC_HOME（デフォルト）
IPV6_PREFER_SRC_COA
IPV6_PREFER_SRC_COA
Source address selection rule #7 (prefer public address):
ソースアドレス選択ルール＃7（パブリックアドレスを好みます）：
IPV6_PREFER_SRC_PUBLIC (default)
IPV6_PREFER_SRC_PUBLIC（デフォルト）
IPV6_PREFER_SRC_TMP
IPV6_PREFER_SRC_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 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.
この時点で、この文書は、実装が実用的なアプリケーションが存在しなかったと感じたように、宛先アドレス選択ルール＃8（小さい範囲を好む）（適切な宛先のスコープを好む）ソースアドレス選択ルール＃2を変更するためのフラグを定義していないことができ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は、アプリケーションがのsetsockoptで設定した送信元アドレスの好みは、（）はgetaddrinfo（）関数によって考慮されていることを確認するための方法を提供します。のは、このシナリオを理解するための例を考えてみましょう。 DA及びDBは、二つのグローバル宛先アドレスであり、ノードは、それぞれ、インタフェースA及びBを介して2つのグローバルソースアドレスSA及びSBを有します。 SBがパブリックアドレスである一方、SAは、一時的なアドレスです。アプリケーションは、のsetsockopt（）フラグでIPV6_PREFER_SRC_TMPを設定しています。 ai_eflagsでai_flagsにAI_EXTFLAGSとIPV6_PREFER_SRC_TMPが設定されている場合、このようB.をインタフェースするDBポイントにA及び経路をインタフェースするDAポイントへのルート、のgetaddrinfo（）は、宛先アドレスのリストにDB前に、DAを返し、したがって、SAは、あろう宛先DAとの通信に使用されます。 AI_EXTFLAGSとai_eflagsがIPV6_PREFER_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公共
9876::1:2 temporary
9876 :: 1：2の一時
The destination has the following two addresses:
先には、以下の2つのアドレスを持っています：
1234::9:3
１２３４：：９：３
9876::9:4
９８７６：：９：４
By default, getaddrinfo() will return the destination addresses in the following order:
デフォルトでは、はgetaddrinfo（）は次の順序で宛先アドレスを返します。
1234::9:3
１２３４：：９：３
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がIPV6_PREFER_SRC_TMPにAI_EXTFLAGSとai_eflagsに設定されている場合、一時的なソースアドレスが好ましいであろうので、一方、の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.
AF_INET6ソケット用IPv4射影IPv6アドレスは、このAPIでサポートされています。 API属性がIPv6固有であるため、いくつかのケースでは、IPv4射影アドレスの用途は限られています。たとえば、IPv6の一時アドレスと暗号化によって生成されたアドレスにはIPv4のカウンターパートを持っていません。したがって、IPV6_PREFER_SRC_TMPまたはIPV6_PREFER_SRC_CGAは、IPv4射影IPv6アドレスに直接適用されません。ただし、IPv4マップアドレスサポートは、ホームアドレスと気付アドレスと送信元アドレスをシフトモバイルIPv4アプリケーションのために有用であり得ます。したがって、IPV6_PREFER_SRC_COAとIPV6_PREFER_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.）アプリケーションは、1つのまたは複数のIPV6_PREFER_SRC_ *フラグを指定するとAI_EXTFLAGSは（getaddrinfoはとai_flags。
2. The application specifies the same IPV6_PREFER_SRC_* flags with setsockopt().
2.アプリケーションは、（）のsetsockoptと同じIPV6_PREFER_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）を適用する前に送信される単一のパケットがその要件が満たされたことを確認することができなかったことを確実にしたい時に接続（）関数を使用することはできません。その代わりに、アプリケーションは、アプリケーションの好みに応じて、所定の宛先アドレスと通信するように選択されるソースアドレスにソケットを結合する新たに導入された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型bind2addrsel（int型の、constの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構造体への非NULLポインタです。
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_scope_id MUST be set if the address is link-local;
O sin6_family AF_INET6に設定する必要があります。アドレスがリンクローカルである場合、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（）呼び出しは、グローバル変数errnoがエラーを示すように設定されているときにバインド（）コール、すなわち、0成功した場合、そうでなければ-1と同じ値を返すように定義されています。 bind2addrsel（）の呼び出しは、同じ理由バインド（）の呼び出しで失敗しました。
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_is_srcaddr（構造体のsockaddr_in6 * SRCADDR、の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_PREFER_SRC_ *ソース優先フラグを含み、SRCADDRは次のように初期化sockaddr_in6構造体に非NULLポインタです。
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_family AF_INET6に設定しなければなりません。
o sin6_scope_id MUST be set if the address is link-local.
アドレスがリンクローカルである場合、Oではsin6_scope_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_srcaddr（）は3つの値（0、1、-1）を返すように定義される：この関数は真を返す（1）IPv6アドレスはノード内の有効アドレスに対応し、所定の優先フラグを満たす場合。 IPv6アドレスの入力値は、ノードの任意のアドレスに対応していないか、フラグが有効な優先フラグの1つでない場合、それは失敗を返し（-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.
この機能は、例えば、その2番目のパラメータとして複数の有効な優先フラグの組み合わせを扱うことができ、IPV6_PREFER_SRC_COA |結果が真であるために、すべてのフラグが満たされなければならないことを意味IPV6_PREFER_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_PREFER_SRC_HOMEのためにtrueを返します。
The following list summarizes the constants, structure, and extern definitions discussed in this memo, sorted by header.
以下のリストは、定数、構造、およびヘッダでソートこのメモで議論のextern定義をまとめたものです。
<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>構造体の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);
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 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.
著者は、このトピックに関する有益な議論のためにモバイルIPおよびIPv6ワーキンググループのメンバーに感謝したいです。リチャードDravesとDaveターラーはgetaddrinfoはまた、新しいソケットオプションと一緒に検討する必要があることを示唆しました。ガブリエルモンテネグロはCGAsも、この文書で考慮することができることを示唆しました。アラン・デュラン、レニーダンソン、アルパースYegin、フランシスデュポン、恵一志摩、マイケル・ハンター、セバスチャン・ロイ、ロバート・エルツ、ペッカSavola、いとぢゅん、ジム・バウンド、ジェフBOOTE、スティーブCipolli、ヴラドYasevich、ミカLiljeberg、テッドハーディー、Vidyaのおかげで有益な議論や提案のためのナラヤナン、およびラースエッゲルト。このドキュメントおよび改善のための提案の審査のためのレミデニス・Courmontのおかげで、ブライアンハーバーマン、ブライアン・ヘイリー、ボブギリガン、ジャック・マッキャン、ジム・バウンド、神明達也、スレシュクリシュナン、ヒラリーオーマン、ジェフ・ヒューストン、マルセロBungulo、とヤリArkko 。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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.、RFC 3484 "インターネットプロトコルバージョン6（IPv6）のデフォルトのアドレス選択"、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]ギリガン、R.、トムソン、S.、バウンド、J.、マッキャン、J.、およびW.スティーブンス、 "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]デアリング、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.
"IPv6用の拡張ソケットアプリケーション・プログラム・インターフェース（API）" [RFC3542]スティーブンス、W.、トーマス、M.、Nordmarkと、E.、およびT.神明、RFC 3542、2003年5月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775]ジョンソン、D.、パーキンス、C.、およびJ. Arkko、 "IPv6におけるモビリティサポート"、RFC 3775、2004年6月。
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3971] Arkko、J.、ケンプ、J.、Zill、B.、およびP. Nikander、 "セキュア近隣探索（SEND）"、RFC 3971、2005年3月。
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005.
[RFC3972]オーラ、T.、 "暗号的に生成されたアドレス（CGA）"、RFC 3972、2005年3月。
Appendix A. Per-Packet Address Selection Preference
付録A.パケット単位のアドレス選択好み
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_levelメンバ）補助データオブジェクト（cmsg_type）データとして含有するIPV6_ADDR_PREFERENCES（CMSG_DATA []）は、32ビットの符号なしの場合高度IPV6ソケットAPI [RFC3542]と同様の方法で|（IPV6_PREFER_SRC_PUBLIC例えば、IPV6_PREFER_SRC_COA）整数ソースアドレス選択優先フラグを符号化します。このアドレス選択嗜好補助的なデータオブジェクトは、他の補助的なデータオブジェクトとともに存在してもよいです。
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: 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;
extptr = CMSG_DATA(cmsgptr);
extptr = CMSG_DATA（cmsgptr）。
flags = IPV6_PREFER_SRC_COA;
memcpy(extptr, &flags, extlen);
msg.msg_control = cmsgptr;
msg.msg_controllen = cmsglen;
/* finish filling in msg{} */
msg.msg_name = dest;
msg.msg_name =始めます。
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（によって送信されるパケット）のためのアドレス設定を指定するために使用されます。
Appendix B. Intellectual Property Statement
付録B.知的財産権に関する声明
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）を選択するために、ソース優先フラグを定義します。 CGAsは、アドレスの所有権を証明するために、公開鍵とハッシュを使用して得られます。いくつかのIPRクレームは、そのような方法について行われています。
Authors' Addresses
著者のアドレス
Erik Nordmark Sun Microsystems, Inc. 17 Network Circle Menlo Park, CA 94025 USA
エリックNordmarkとサン・マイクロシステムズ株式会社17ネットワークサークルメンロパーク、CA 94025 USA
EMail: Erik.Nordmark@Sun.com
メールアドレス：Erik.Nordmark@Sun.com
Samita Chakrabarti Azaire Networks 3121 Jay Street, Suite 210 Santa Clara, CA 95054 USA
3121クミンチャクラインベントリストリートでのネットワークのサミット、サンタクララにあるスイート10、ソース95054
EMail: samitac2@gmail.com
メールアドレス：samitac2@gmail.com
Julien Laganier DoCoMo Euro-Labs Landsbergerstrasse 312 D-80687 Muenchen Germany
ジュリアンLAGANIERドコモユーロ-Labsのランツベルクは312 D-80687ミュンヘンドイツを繁殖します
EMail: julien.IETF@laposte.net
メールアドレス：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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンライン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-ipr@ietf.orgのIETFに情報を記述してください。