[要約] RFC 5014は、IPv6ソケットAPIのソースアドレス選択に関する仕様です。その目的は、IPv6ネットワーク上でのソケット通信において、適切な送信元アドレスを選択するための手法を提供することです。
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
[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 Mobility [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拡張機能は、単純なbind（）操作またはIPv6_pktinfoソケットオプション[RFC3542]を介して特定のソースアドレスを選択するメカニズムを提供します。ただし、bind（）または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つの一時的なアドレスがある場合、ホストはパブリックケアを選択します - 一時的なアドレスよりもパブリックを優先するためのデフォルトのアドレス選択ルールに従ってアドレス。
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（）プリミティブを使用する場合、利用可能なIPアドレスのセットがgetaddrinfo（）と呼ばれるアプリケーションの場合から大きく変更された可能性があるため、ハード要件の使用には問題がありました。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）。このアプローチにより、異なる実装が異なるシステムのデフォルトを持つことができ、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 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]の7（ネイティブインターフェイスを好む）は、宛先アドレスの変更について考慮されました。しかし、この執筆時点では、アプリケーションが宛先アドレスの選択ルールを直接変更するのに十分な実用的な使用法はありませんでした。ただし、このドキュメントでは、優先宛先アドレスの選択のためにフラグを追加する可能性は除外されていません。ただし、[RFC3484]宛先アドレスの選択ルールは、ソースアドレスの選択に依存するため、このドキュメントで説明した方法を使用してデフォルトのソースアドレス選択を変更することにより、宛先アドレスの選択の選択に間接的に影響します。したがって、このドキュメントでは、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にのみ拡張機能を指定します。意図は、このドキュメントが、ミドルウェアシステムや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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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アプリケーションです。これは、モバイルノードが外国ネットワークで起動し、キーエクスチェンジを行いたいと思う一方、ホームエージェントとの初期セキュリティアソシエーションペアのソースアドレスとしてのケアアドレスを必要とします。成功したホームレジスタレーション。また、モバイルIPv6 Awareアプリケーションは、アプリケーションの場所と状態に応じて、ホームアドレスとケアオブアドレスを切り替えることをお勧めします。また、さまざまなソケットを開き、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ブラウザーとメールサーバーをサポートするアプリケーションは、Mail-Serverが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ソースアドレスで使用されている場合に送信を使用するNeighbor Discoveryシグナルを開始することになります。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.
一部の人々は、サケットごとのフラグとパケットごとのフラグの代わりに、アプリケーションごとのフラグを持つことを提案しました。ただし、このデザインは次の理由でソケットごとのフラグとパケットごとのフラグを維持します。O一部のシステムには、環境ごと/アプリケーションフラグ（UNIXシステムの環境変数など）がありますが、これはすべてのシステムで使用できない場合があります。ソケット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：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) アプリケーションはFlag 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 Basic Socket API [RFC3493]は、IPv6のソケットオプションを定義します。アプリケーションがアドレス選択メカニズムに影響を与えることを可能にするために、このドキュメントはIPPROTO_IPV6レベルで新しいソケットオプションを追加します。このソケットオプションは、IPv6_addr_preferencesと呼ばれます。SetSockopt（）で使用でき、GetSockopt（）は、特定のソケットを介して送信されるすべてのパケットに影響を与えるアドレス選択設定を設定および取得するために呼び出します。ソケットオプション値（OptVal）は、32ビットの署名されていない整数引数です。引数は、各フラグがデフォルトのアドレス選択仕様のルールの1つを変更するアドレス選択選好を示す多くのフラグで構成されています。
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（）で正常に設定されると、与えられたオプション値は、ソケットを介した接続開始のアドレス選好を指定するために使用され、そのソケットを介して送信されるすべての後続のパケットが指定されます。オプションが設定されていない場合、システムは、デフォルトのアドレス選択アルゴリズムまたは他の同等の手段に従ってデフォルト値を選択します。
Setting contradictory flags at the same time results in the error 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]の可能な実装戦略を示しています。そのうちの1つは、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_FLAGS」フラグセットフィールド用に定義され、AddRINFO構造の「AI_EFLAGS」拡張フラグセットフィールドを探すようシステムに指示します。<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（）の実装は、Adrinfoデータ構造の拡張フラグセットフィールドに格納されている「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」拡張フラグセットフィールドのアドレス選択優先フラグとして定義されます。発信者アプリケーションによって表明されたソースアドレス設定に対応します。
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を設定し、「AI_EFLAGS」フィールドの対応するアドレス選択設定フラグ（IPv6_Prefer_Src_*）を設定することにより、Sourceアドレスの選択のヒントを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].
IPv6_prefer_src_homeやipv6_prefer_src_coaなどの矛盾したフラグがai_eflagsに設定されている場合、getaddrinfo（）は<netdb.h> headerを含む結果として定義された値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 flags = ipv6_prefer_src_tmp;
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 */
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");
}
/*
*
* 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");
}
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..);
/* 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_addr_preferences、（void *）＆foredences、sizeof（feprences））;
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 同じアプリケーション内で、特定のソースアドレスがbind（）またはIPv6_pktinfoソケットオプションのいずれかによって設定されている場合、同時にアドレスの選択選好はIPv6_addr_preferencesソケットオプションで表され、次にbind（）またはbind（）またはcomperided settionを設定します。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 この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_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.
現時点では、このドキュメントは、ソースアドレスの選択ルール＃2（目的地に適切な範囲を好む）と宛先アドレスの選択ルール＃8（より小さな範囲を好む）を変更するフラグを定義していません。実装者は、実用的なアプリケーションがないと感じたためIPv6デフォルトアドレス選択のスコーピングルールの戻りを活用してください。他の宛先アドレスの選択ルールを変更するフラグ（＃4、ホームアドレスを好む、＃7、ネイティブトランスポートを好む）はアプリケーションを持つ可能性がありますが、問題はローカルシステムが宛先アドレスが宛先ルール＃7のトンネルアドレスであるかどうかを体系的に判断できないことです（宛先アドレスが独自の1つである場合、またはトンネルアドレスとして構文的に認識できる場合、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は2つのグローバル宛先アドレスであり、ノードにはインターフェイスAとBを介してそれぞれ2つのグローバルソースアドレスSAとSBがあります。SAは一時的な住所であり、SBはパブリックアドレスです。このアプリケーションは、SetSockopt（）フラグにIPv6_Prefer_Src_tmpを設定しています。DAへのルートはインターフェイスAとDBへのルートがインターフェースBに指さします。したがって、AI_FLAGSのAI_EXTFLAGSがAI_EFLAGSのIPv6_Prefer_Src_tmpが設定されている場合、getaddrinfo（）がDAをDBの前にDAを返します。宛先DAとの通信に使用されます。同様に、getaddrinfo（）は、ai_extflagsとai_eflagsがipv6_prefer_src_publicに設定されている場合、daの前にdbを返します。したがって、ソースアドレスの選好は、getaddrinfo（）関数による宛先アドレスの選択とソースアドレスの選択に有効になっています。
The following numerical example clarifies the above further.
次の数値例は、上記をさらに明確にします。
Imagine a host with two addresses:
2つのアドレスを持つホストを想像してください。
1234::1:1 public
9876::1:2 temporary
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がai_extflagsに設定され、ai_eflagsがipv6_prefer_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-Mapped IPv6アドレスがサポートされています。場合によっては、API属性がIPv6固有であるため、IPv4マップアドレスの適用が制限されています。たとえば、IPv6の一時的なアドレスと暗号化されたアドレスには、IPv4の対応物がありません。したがって、IPv6_prefer_src_tmpまたはipv6_prefer_src_cgaは、IPv4-Mapped IPv6アドレスに直接適用できません。ただし、IPv4-Mappedアドレスサポートは、ホームアドレスとケアオブアドレスの間のソースアドレスをシフトするモバイル-IPV4アプリケーションに役立つ場合があります。したがって、IPv6_prefer_src_coaとipv6_prefer_src_homeは、IPv4-mapped 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 ai_flagsをgetaddrinfo（）を指定します。
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（）コールを使用する必要があります。Datagram指向の通信（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>
int bind2addrsel(int s, const struct sockaddr *dstaddr, socklen_t dstaddrlen);
int bind2addrsel（int s、const struct 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_familyはaf_inet6に設定する必要があります。
o sin6_scope_id MUST be set if the address is link-local;
o アドレスがLink-Localの場合、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、それ以外の場合はグローバル変数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およびCGAの検証。この目的のために定義された新しい検証関数によって実行されません。
#include <netinet/in.h>
short inet6_is_srcaddr(struct sockaddr_in6 *srcaddr, uint32_t flags);
short inet6_is_srcaddr（struct sockaddr_in6 *srcaddr、uint32_t flags）;
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構造の非ヌルポインターです。
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 アドレスがLink-Localの場合、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）：関数はtrue（1）を返します。IPv6アドレスがノードの有効なアドレスに対応し、指定された優先フラグを満たします。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.
この関数は、複数の有効な設定フラグの組み合わせを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.
次のリストは、このメモで説明されている定数、構造、および外部定義を、ヘッダーでソートしたものをまとめたものです。
<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);
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.
著者は、このトピックに関する有用な議論をしてくれたMobile-IPおよびIPv6ワーキンググループのメンバーに感謝します。Richard DravesとDave Thalerは、Getaddrinfoも新しいソケットオプションとともに考慮する必要があることを提案しました。ガブリエルモンテネグロは、この文書でもCGAも考慮される可能性があることを示唆しました。Alain Durand、Renee Danson、Alper Yegin、Francis Dupont、Michael Hunter、Sebastien Roy、Robert Elz、Pekka Savola、Itojun、Jim Bound、Jeff Boote、Steve Cipolli、Vlad Yasevich、Mika Liljeberg、Ted Hardie、Tedナラヤナン、および有用な議論と提案のためにラースエッガート。レミ・デニス・コールモント、ブライアン・ハーバーマン、ブライアン・ヘイリー、ボブ・ギリガン、ジャック・マッキャン、ジム・バウンド、ジンメイ・タトゥヤ、スレシュ・クリシュナン、ヒラリー・オルマン、ジェフ・ヒューストン、マルセロ・ブングロ、ジャリ・アークコのおかげで、この文書のレビューと提案のレビューのレビューについて。
[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するプログラム」、オンラインWebサイト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のステートレスアドレスAutoconfigurationのプライバシー拡張」、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用Advanced Socketsアプリケーションプログラムインターフェイス（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 3775、2004年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、「Secure Neighbor Discovery（Send）」、RFC 3971、2005年3月。
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005.
[RFC3972]オーラ、T。、「暗号化されたアドレス（CGA）」、RFC 3972、2005年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.
パケットごとのソースアドレスの選択は高価です。システムは、各パケットを送信する前にアプリケーションの選好で示されるソースアドレスを決定する必要があります。一方ソケットオプションが設定されている限り、そのソケットエンドポイントを介して送信されたパケット。
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のIPPROTO_IPV6レベル（CMSG_LEVEL）補助データオブジェクトで処理する必要があります（CMSG_DATA []）ソースアドレスをエンコードする整数選択の選好フラグ（例：IPv6_prefer_src_coa | ipv6_prefer_src_public）。このアドレス選択選好補助データオブジェクトは、他の補助データオブジェクトとともに存在する場合があります。
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);
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 = 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は、パブリックキーとハッシュを使用して取得して、住所の所有権を証明します。そのような方法についていくつかのIPRの主張がなされています。
Authors' Addresses
著者のアドレス
Erik Nordmark Sun Microsystems, Inc. 17 Network Circle Menlo Park, CA 94025 USA
Erik Nordmark Sun Microsystems、Inc。17 Network Circle Menlo Park、CA 94025 USA
EMail: Erik.Nordmark@Sun.com
Samita Chakrabarti Azaire Networks 3121 Jay Street, Suite 210 Santa Clara, CA 95054 USA
Samita Chakrabarti Azaire Networks 3121 Jay Street、Suite 210 Santa Clara、CA 95054 USA
EMail: samitac2@gmail.com
Julien Laganier DoCoMo Euro-Labs Landsbergerstrasse 312 D-80687 Muenchen Germany
Julien Laganier Docomo Euro-Labs Landsbergerstrasse 312 D-80687 Muenchen Germany
EMail: julien.IETF@laposte.net
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（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事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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への情報をお問い合わせください。