RFC5014 日本語訳
5014 IPv6 Socket API for Source Address Selection. E. Nordmark, S.Chakrabarti, J. Laganier. September 2007. (Format: TXT=53601 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
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
Nordmarkがコメントのために要求するワーキンググループE.をネットワークでつないでください: 5014年のサン・マイクロシステムズ・インクカテゴリ: 情報のS.Chakrabarti Azaireは2007年9月にJ.Laganier DoCoMoユーロ研究室をネットワークでつなぎます。
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デフォルトアドレス選択ドキュメント(RFC3484)は、ソースと送付先IPv6アドレスを選ぶための規則について説明して、アプリケーションがいくつかの不特定のAPIを通してアドレス選択規則のいくつかの感覚を逆にすることができるべきであるのを示します。 しかしながら、どんなそのようなソケットAPIも基本的(RFC3493)か高度な(RFC3542)IPv6ソケットAPIドキュメントに存在していません。 このドキュメントは、getaddrinfo()APIがデフォルトソースアドレス選択アルゴリズムを変更するソケットレベルオプションに従ってソースアドレス優先順位に基づくアドレス選択を指定するようにソースアドレス選択のための新しいソケットレベルオプションと旗を指定することによって、その不足を部分的にいっぱいにしています。 本書では説明されたソケットAPIが特に一時的で公共のアドレスを選びたがっているIPv6アプリケーション、および使用に欲しいモバイルIPv6意識しているアプリケーションの役に立つ、注意、-、コミュニケーションのためのアドレス。 また、それはCryptographically Generated Address(CGA)か非CGAソースアドレスを選択するためのソケットオプションと旗を指定します。
Nordmark, et al. Informational [Page 1] RFC 5014 Socket API for Source Address Selection September 2007
Nordmark、他 ソースアドレス選択2007年9月のための情報[1ページ]のRFC5014ソケットAPI
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Definition Of Terms . . . . . . . . . . . . . . . . . . . . . 5
3. Usage Scenario . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Design Alternatives . . . . . . . . . . . . . . . . . . . . . 6
5. Address Preference Flags . . . . . . . . . . . . . . . . . . . 7
6. Additions to the Socket Interface . . . . . . . . . . . . . . 9
7. Additions to the Protocol-Independent Nodename Translation . . 10
8. Application Requirements . . . . . . . . . . . . . . . . . . . 11
9. Usage Example . . . . . . . . . . . . . . . . . . . . . . . . 13
10. Implementation Notes . . . . . . . . . . . . . . . . . . . . . 13
11. Mapping to Default Address Selection Rules . . . . . . . . . . 14
12. IPv4-Mapped IPv6 Addresses . . . . . . . . . . . . . . . . . . 16
13. Validating Source Address Preferences . . . . . . . . . . . . 16
14. Summary of New Definitions . . . . . . . . . . . . . . . . . . 19
15. Security Considerations . . . . . . . . . . . . . . . . . . . 19
16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
17.1. Normative References . . . . . . . . . . . . . . . . . . 20
17.2. Informative References . . . . . . . . . . . . . . . . . 20
Appendix A. Per-Packet Address Selection Preference . . . . . . . 21
Appendix B. Intellectual Property Statement . . . . . . . . . . . 22
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 用語. . . . . . . . . . . . . . . . . . . . . 5 3の定義。 用法シナリオ. . . . . . . . . . . . . . . . . . . . . . . . 6 4。 代替手段. . . . . . . . . . . . . . . . . . . . . 6 5を設計してください。 好みが旗. . . . . . . . . . . . . . . . . . . 7 6であると扱ってください。 ソケットへの追加は.9 7を連結します。 プロトコルから独立しているNodename翻訳. . 10 8への追加。 アプリケーション要件. . . . . . . . . . . . . . . . . . . 11 9。 使用例. . . . . . . . . . . . . . . . . . . . . . . . 13 10。 実装注意. . . . . . . . . . . . . . . . . . . . . 13 11。 アドレス選択規則. . . . . . . . . . 14 12をデフォルトに写像します。 IPv4によって写像されたIPv6は.16 13を扱います。 ソースアドレス優先順位. . . . . . . . . . . . 16 14を有効にします。 新しい定義. . . . . . . . . . . . . . . . . . 19 15の概要。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 19 16。 承認. . . . . . . . . . . . . . . . . . . . . . . 19 17。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 20 17.1。 引用規格. . . . . . . . . . . . . . . . . . 20 17.2。 1パケットあたりの有益な参照. . . . . . . . . . . . . . . . . 20付録A.アドレス選択好み. . . . . . . 21の付録B.知的所有権声明. . . . . . . . . . . 22
1. Introduction
1. 序論
[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
現在、IPv6ソケットAPI拡張子は、簡易結合認証()操作かIPV6_PKTINFOソケットオプション[RFC3542]で特定のソースアドレスを選ぶためにメカニズムを提供します。 しかしながら、アプリケーション自体は、ひも()かIPV6_PKTINFOソケットオプションを使用するのに使用しなければなりません。
Nordmark, et al. Informational [Page 2] RFC 5014 Socket API for Source Address Selection September 2007
Nordmark、他 ソースアドレス選択2007年9月のための情報[2ページ]のRFC5014ソケットAPI
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.
ソースアドレスが確実に送付先アドレス(例えばパケットを目的地に送るのに使用されるインタフェースに関する)に適切になるようにしてください。 また、アプリケーションは、送付先アドレスなどに関してソースアドレス範囲の適切さについて確かめる必要があります。 アプリケーションに、これはかなり複雑である場合があります、事実上、規則の1つに関して好みを変えるためにすべてのデフォルトがアドレス選択規則であると実装するのが必要であるので。
The mechanism presented in this document allows the application to specify attributes of the source addresses it prefers while still having the system perform the rest of the address selection rules. For instance, if an application specifies that it prefers to use a care-of address over a home address as the source address and if the host has two care-of addresses, one public and one temporary, then the host would select the public care-of address by following the default address selection rule for preferring a public over a temporary address.
本書では提示されたメカニズムで、アプリケーションはシステムにアドレス選択規則の残りをまだ実行させている間にそれが好むソースアドレスの属性を指定できます。 例えば、アプリケーションがそれを指定するならaを使用するのを好む、注意、-、ホームアドレスの上のソースアドレスとホストがそうしたかどうかとしてのアドレス、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.
ソケットオプションは役に立つとこのために考えられました、アプリケーションが1ソケットあたり1個のベースでアドレス選択好みを指定するのを可能にするとき。 また、それは非接続された(UDP)ソケットでアドレス選択が好みであると可能にして、無効にする柔軟性を提供できます。 ソケットオプションは、アドレス選択好みを指定するのに1セットの旗を使用します。 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
アドレス選択のための確実な要件を指定するのはいくつかの理由で問題が多いでしょう。 主要なものは広大のそれです。
Nordmark, et al. Informational [Page 3] RFC 5014 Socket API for Source Address Selection September 2007
Nordmark、他 ソースアドレス選択2007年9月のための情報[3ページ]のRFC5014ソケットAPI
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.
ケースの大多数、'最適'の属性があるアドレスが利用可能でなくても、アプリケーションは交信したがっています。 例えば..アプリケーション..実行..非常に..急..例えば..取引..交換..例えば..質問..好む..使用..注意..アドレス..走る..モバイルホスト..離れている..ホーム..提供..短い..往復..時間..多くの場合 しかし、アプリケーションがモバイルホストで動いているなら、ホーム、またはモバイルIPv6を提供していないホストで走るのにそれはいます、失敗するアプリケーションのためにそれでいいえと感じないその時、注意、-、利用可能な存在に演説してください。 また、UDPソケットとsendto()かsendmsg()基関数を使用するとき、特に、確実な要件の使用も問題が多かったでしょう、利用可能なIPアドレスのセットが新しい故障モードを導入するだろうsendto()かsendmsg()と呼ぶまでアプリケーションがgetaddrinfo()と呼んだ時から非常によく変化したかもしれないので。
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
このドキュメントが直接[RFC3484]で説明された目的地アドレス選択規則を変更しないことに注意してください。 どの目的地アドレス規則がアプリケーションで変更されるかもしれないかを確認するために、分析しました。 規則No.4(ホームアドレスを好みます)、8(より小さい範囲を好む)、7デフォルトアドレス選択ドキュメント[RFC3484](ネイティブのインタフェースを好む)が目的地アドレス変更のために考慮に入れられました。 しかし、この書くことの時点で、アプリケーションが直接都合のよい目的地タイプのアドレスでsetsockopt()を適用するのによる規則が旗を揚げさせる目的地アドレス選択を変更できるくらいの実用的な用法がありませんでした。 しかしながら、このドキュメントは都合のよい目的地アドレス選択のための旗を加える少しの可能性も除外しません。 しかしながら、[RFC3484]目的地アドレス選択規則がソースアドレス選択に依存している、その結果、本書では説明されたメソッドを使用することによってデフォルトソースアドレス選択を変更することによって、1つは間接的に目的地アドレス選択の選択に影響を及ぼします。 したがって、このドキュメント
Nordmark, et al. Informational [Page 4] RFC 5014 Socket API for Source Address Selection September 2007
Nordmark、他 ソースアドレス選択2007年9月のための情報[4ページ]のRFC5014ソケットAPI
explains how getaddrinfo() can be used to select the destination address while taking the preferred source addresses into consideration (Section 11).
都合のよいソースアドレスを考慮に入れている間、送付先アドレスを選択するのにどうgetaddrinfo()を使用できるかを(セクション11)説明します。
This document specifies extensions only to the Basic IPv6 socket API specified in [RFC3493]. The intent is that this document serves as a model for expressing preferences for attributes of IP addresses that also need to be expressible in other networking API, such as those found in middleware systems and the Java environment. A similar model is also applicable for other socket families.
このドキュメントは[RFC3493]で指定されたBasic IPv6ソケットAPIだけに拡大を指定します。 意図はこのドキュメントがまた、他のネットワークAPIで表現できる必要があるIPアドレスの属性のための好みを言い表すために手本になるということです、ミドルウェアシステムで見つけられたものやJava環境のように。 また、他のソケットファミリーに、同様のモデルも適切です。
2. Definition Of Terms
2. 用語の定義
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[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.
相容れない旗: 与えられたアドレス優先順位を言い表す旗と反対の好みを言い表す旗の両方を含む旗のどんな組み合わせも相容れない旗を構成します。 そのような旗は定義上ソースアドレス選択に関してそれらの有用性で相容れません。 そして、例えば、両方のホームアドレス好みの旗を含む1セットの旗を考えてください、注意、-、アドレス優先順位旗。 または、ソースアドレスが選択であると考えるとき、選択されたアドレスがホームアドレスであるかもしれない、注意、-、アドレス、同時に、唯一のそれは両方であるはずがありません。 そして、したがって、それがアドレスを好むためには、両方である、ホームアドレス、注意、-、アドレス、相容れません。
Nordmark, et al. Informational [Page 5] RFC 5014 Socket API for Source Address Selection September 2007
Nordmark、他 ソースアドレス選択2007年9月のための情報[5ページ]のRFC5014ソケットAPI
3. Usage Scenario
3. 用法シナリオ
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 Privacy Extensions、およびCryptographically Generated Addressesをサポートするアプリケーションに制限されます。 ホームアドレスが好まれるべきである選択ドキュメント[RFC3484]が推薦するアドレス、注意、-、両方であるときに、アドレスは構成されています。 しかしながら、モバイルノードが好みたがっているかもしれない、注意、-、アドレス、質問がソースアドレスとしてホームアドレスを含むとき、外国ネットワークにおけるDNS質問のためのソースアドレスとして、通常、意味するように、より短くて地方のリターンパスはモバイルノードのホームエージェントを通してルートと比較されました。 別の例がIKEアプリケーションである、どれ、必要である、注意、-、アドレス、初期のセキュリティ協会のためのソースアドレスとして、モバイルノードが主要な交換をするために外国ネットワークと必需品で起動している間、うまくいっている本国登録の前にホームエージェント[RFC3775]と対にしてくださいか。 そして、また、モバイル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.
非モバイル環境で、アプリケーションは、同様に、あるケースにソースアドレスとして仮の住所を使用するのを好むかもしれません。 両方が利用可能であるときに、デフォルトで、ソースアドレス選択規則は「公共」のアドレスを選択します。 例えば、ウェブブラウザをサポートするアプリケーションとメールサーバはメールサーバのための前のアドレスと「公共」のアドレスに「一時的な」アドレスを使用したがっているかもしれません、メールサーバが反スパム規則のための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.
同様に、ノードはデフォルトで、Secure Neighborディスカバリー[RFC3971]のようにCryptographically Generated Addresses[RFC3972]を使用するために構成されるかもしれませんが、アプリケーションは、それを使用しないのを好むかもしれません。 例えば、fping[FPING]、平行な送付パケットで複数の目的地の基本的な可到達性をテストするデバッグ用ツール。 これらのパケットは結局、CGAソースアドレスと共に使用されるならSENDを使用する隣人発見シグナリングを開始するかもしれません。 SENDは、前述のCGAアドレスの所有権を立証するためにいくつかの暗号の操作を実行します。 アプリケーションがこの特徴を必要としないなら、それは、SENDによって実行された潜在的に高価な計算を避けるのに非CGAアドレスを使用したがっています。 他方では、ノードがCGAのためにデフォルトとして構成されないとき、アプリケーションは、対応する好みを設定することによってCGAを使用するのを好むかもしれません。
4. Design Alternatives
4. デザイン代替手段
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:
或るものは、ソケットとパケットあたりの旗の代わりに1アプリケーションあたりの旗を持つために示されました。 しかしながら、このデザインは以下の理由でソケットとパケットあたりの旗で残っています:
Nordmark, et al. Informational [Page 6] RFC 5014 Socket API for Source Address Selection September 2007
Nordmark、他 ソースアドレス選択2007年9月のための情報[6ページ]のRFC5014ソケットAPI
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を使用するのは、その事実に気づきません。 したがって、1アプリケーションあたりの旗を提供するメカニズムは、予期せぬ結果の危険を作成しながら、アプリケーション自体だけではなく、ライブラリにも影響するかもしれません。
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().
変更できる各規則のための'旗'と'旗の反対側'の組の代わりに、ソケットオプションは、各規則にただ一つの'旗'値を使用するために定義されたかもしれません。 アプリケーションが最初に既定の設定を検索するためにコード化された限り、異なった実装がこれでまだ異なった既定の設定を持つことができただろう、(setsockopt()でgetsockopt())で、次に、明確な状態で使用したか、彼らの好みに従って'旗'を設定して、または新しい値は最終的にセットしました。
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のunsetの反対の、または、相容れない旗は以前、セットしました。
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の反対の、または、相容れない旗を設定してください。 unset旗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()を通して弛みません。 それらが以前同じソケットによって設定されるなら、いずれも好みを扱うunsetは弛みます。
5. Address Preference Flags
5. アドレス優先順位旗
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_ホーム/*はソース*/としてホームアドレスを好みます。
IPV6_PREFER_SRC_COA /* Prefer Care-of address as source */
SRC_COA/*が好むIPV6_PREFER_、Care、-、ソース*/としてのアドレス
Nordmark, et al. Informational [Page 7] RFC 5014 Socket API for Source Address Selection September 2007
Nordmark、他 ソースアドレス選択2007年9月のための情報[7ページ]のRFC5014ソケットAPI
IPV6_PREFER_SRC_TMP /* Prefer Temporary address as source */
IPV6_PREFER_SRC_TMP/*はソース*/としてTemporaryアドレスを好みます。
IPV6_PREFER_SRC_PUBLIC /* Prefer Public address as source */
IPV6_PREFER_SRC_PUBLIC/*はソース*/としてPublicアドレスを好みます。
IPV6_PREFER_SRC_CGA /* Prefer CGA address as source */
IPV6_PREFER_SRC_CGA/*はソース*/としてCGAアドレスを好みます。
IPV6_PREFER_SRC_NONCGA /* Prefer a non-CGA address as source */
IPV6_PREFER_SRC_NONCGA/*はソース*/として非CGAアドレスを好みます。
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_は_SRC_公衆を好みます。| IPV6_は_SRC_TMPを好みます。
IPV6_PREFER_SRC_HOME | IPV6_PREFER_SRC_COA
IPV6_は_家で_SRCを好みます。| IPV6_は_SRC_コア川を好みます。
IPV6_PREFER_SRC_HOME | IPV6_PREFER_SRC_COA | IPV6_PREFER_SRC_TMP
IPV6_は_家で_SRCを好みます。| IPV6_は_SRC_コア川を好みます。| IPV6_は_SRC_TMPを好みます。
IPV6_PREFER_SRC_CGA | IPV6_PREFER_SRC_NONCGA
IPV6_は_SRC_CGAを好みます。| IPV6_は_SRC_NONCGAを好みます。
Etc.
など
Examples of valid combinations of address selection flags are given below:
アドレス選択旗の有効な組み合わせに関する例は以下に出されます:
IPV6_PREFER_SRC_HOME | IPV6_PREFER_SRC_PUBLIC
IPV6_は_家で_SRCを好みます。| IPV6_は_SRC_公衆を好みます。
IPV6_PREFER_SRC_HOME | IPV6_PREFER_SRC_CGA
IPV6_は_家で_SRCを好みます。| IPV6_は_SRC_CGAを好みます。
IPV6_PREFER_SRC_COA | IPV6_PREFER_SRC_PUBLIC | IPV6_PREFER_SRC_CGA
IPV6_は_SRC_コア川を好みます。| IPV6_は_SRC_公衆を好みます。| IPV6_は_SRC_CGAを好みます。
IPV6_PREFER_SRC_HOME | IPV6_PREFER_SRC_NONCGA
IPV6_は_家で_SRCを好みます。| IPV6_は_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:
'Y'がシステムで旗セットが'X'と'Y'の組み合わせを含んで、適切でもなくて、また利用可能でもないなら、選択されたアドレスには、属性'X'とシステム・デフォルトが属性'Y'のためにあります。 例えば、システムの上では、それは場内放送だけ、旗の有効な組み合わせを持っています:
IPV6_PREFER_SRC_TMP | IPV6_PREFER_SRC_HOME
IPV6_は_SRC_TMPを好みます。| IPV6_は_家で_SRCを好みます。
would result in the selected address being a public home address, since no temporary addresses are available.
どんな仮の住所も利用可能でないので公共のホームアドレスである選択されたアドレスをもたらすでしょう。
Nordmark, et al. Informational [Page 8] RFC 5014 Socket API for Source Address Selection September 2007
Nordmark、他 ソースアドレス選択2007年9月のための情報[8ページ]のRFC5014ソケットAPI
6. Additions to the Socket Interface
6. ソケットインタフェースへの追加
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_ホーム/*はソース*/としてホームアドレスを好みます。
IPV6_PREFER_SRC_COA /* Prefer Care-of address as source */
SRC_COA/*が好むIPV6_PREFER_、Care、-、ソース*/としてのアドレス
IPV6_PREFER_SRC_TMP /* Prefer Temporary address as source */
IPV6_PREFER_SRC_TMP/*はソース*/としてTemporaryアドレスを好みます。
IPV6_PREFER_SRC_PUBLIC /* Prefer Public address as source */
IPV6_PREFER_SRC_PUBLIC/*はソース*/としてPublicアドレスを好みます。
IPV6_PREFER_SRC_CGA /* Prefer CGA address as source */
IPV6_PREFER_SRC_CGA/*はソース*/としてCGAアドレスを好みます。
IPV6_PREFER_SRC_NONCGA /* Prefer a non-CGA address as source */
IPV6_PREFER_SRC_NONCGA/*はソース*/として非CGAアドレスを好みます。
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.
同時に相容れない旗を設定すると、誤りEINVALはもたらされます。
Nordmark, et al. Informational [Page 9] RFC 5014 Socket API for Source Address Selection September 2007
Nordmark、他 ソースアドレス選択2007年9月のための情報[9ページ]のRFC5014ソケットAPI
7. Additions to the Protocol-Independent Nodename Translation
7. プロトコルから独立しているNodename翻訳への追加
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().
Default Address Selection[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:
そのために、Basic IPV6 Socket API Extension[RFC3493]で定義されたaddrinfoデータ構造は拡張「ai_eflags」旗セット分野で広げられて、自由を必要に応じて「ai_旗」旗セット分野で貴重な噛み付いているスペースを混雑させないで、より多くの旗を加えるのからデザイナーに提供しました。 <netdb.h>ヘッダーを含んでいることの結果、拡張addrinfoデータ構造は定義されます:
struct addrinfo {
int ai_flags; /* input flags */
int ai_family; /* protocol family for socket */
int ai_socktype; /* socket type */
int ai_protocol; /* protocol for socket */
socklen_t ai_addrlen; /* length of socket address */
char *ai_canonname; /* canonical name for hostname */
struct sockaddr *ai_addr; /* socket address for socket */
struct addrinfo *ai_next; /* pointer to next in list */
int ai_eflags; /* Extended flags for special usage */
};
struct addrinfo { int ai_flags; /* input flags */ int ai_family; /* protocol family for socket */ int ai_socktype; /* socket type */ int ai_protocol; /* protocol for socket */ socklen_t ai_addrlen; /* length of socket address */ char *ai_canonname; /* canonical name for hostname */ struct sockaddr *ai_addr; /* socket address for socket */ struct addrinfo *ai_next; /* pointer to next in list */ int ai_eflags; /* Extended flags for special usage */ };
Note that the additional field for extended flags are added at the bottom of the addrinfo structure to preserve binary compatibility of the new functionality with the old applications that use the existing addrinfo data structure.
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.
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:
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:
Nordmark, et al. Informational [Page 10] RFC 5014 Socket API for Source Address Selection September 2007
Nordmark, et al. Informational [Page 10] RFC 5014 Socket API for Source Address Selection September 2007
AI_EXTFLAGS /* extended flag-set present */
AI_EXTFLAGS /* extended flag-set present */
If the AI_EXTFLAGS flag is set in "ai_flags" flag-set field of the addrinfo data structure, then the getaddrinfo() implementation MUST look for the "ai_eflags" values stored in the extended flag-set field "ai_eflags" of the addrinfo data structure. The flags stored in the "ai_eflags" field are only meaningful if the AI_EXTFLAGS flag is set in the "ai_flags" flag-set field of the addrinfo data structure. By default, AI_EXTFLAGS is not set in the "ai_flags" flag-set field. If AI_EXTFLAGS is set in the "ai_flags" flag-set field, and the "ai_eflags" extended flag-set field is 0 (zero) or undefined, then AI_EXTFLAGS is ignored.
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.
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.
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.
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.
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.
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.
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.
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].
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].
8. Application Requirements
8. Application Requirements
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:
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:
Nordmark, et al. Informational [Page 11] RFC 5014 Socket API for Source Address Selection September 2007
Nordmark, et al. Informational [Page 11] RFC 5014 Socket API for Source Address Selection September 2007
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");
}
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:
An application that needs to be able to restore the default settings on the socket would instead do this:
uint32_t save_flags, flags;
int optlen = sizeof (save_flags);
uint32_t save_flags, flags; int optlen = sizeof (save_flags);
/* Save the existing IPv6_ADDR_PREFERENCE flags now */
/* Save the existing IPv6_ADDR_PREFERENCE flags now */
if (getsockopt(s, IPPROTO_IPV6, IPV6_ADDR_PREFERENCES,
(void *) &save_flags, &optlen) == -1 {
perror("getsockopt IPV6_ADDR_REFERENCES");
}
if (getsockopt(s, IPPROTO_IPV6, IPV6_ADDR_PREFERENCES, (void *) &save_flags, &optlen) == -1 { perror("getsockopt IPV6_ADDR_REFERENCES"); }
/* Set the new flags */
flags = IPV6_PREFER_SRC_TMP;
if (setsockopt(s, IPPROTO_IPV6, IPV6_ADDR_PREFERENCES,
(void *) &flags, sizeof (flags)) == -1) {
perror("setsockopt IPV6_ADDR_REFERENCES");
}
/* Set the new flags */ flags = IPV6_PREFER_SRC_TMP; if (setsockopt(s, IPPROTO_IPV6, IPV6_ADDR_PREFERENCES, (void *) &flags, sizeof (flags)) == -1) { perror("setsockopt IPV6_ADDR_REFERENCES"); }
/*
*
* Do some work with the socket here.
*
*/
/* * * Do some work with the socket here. * */
/* Restore the flags */
/* Restore the flags */
if (setsockopt(s, IPPROTO_IPV6, IPV6_ADDR_PREFERENCES,
(void *) &save_flags, sizeof (save_flags)) == -1) {
perror("setsockopt IPV6_ADDR_REFERENCES");
}
if (setsockopt(s, IPPROTO_IPV6, IPV6_ADDR_PREFERENCES, (void *) &save_flags, sizeof (save_flags)) == -1) { perror("setsockopt IPV6_ADDR_REFERENCES"); }
Applications should not set contradictory flags at the same time.
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
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
Nordmark, et al. Informational [Page 12] RFC 5014 Socket API for Source Address Selection September 2007
Nordmark, et al. Informational [Page 12] RFC 5014 Socket API for Source Address Selection September 2007
structure when calling getaddrinfo(). If applications are not setting the semantically equivalent flags, the behavior of the implementation is undefined.
structure when calling getaddrinfo(). If applications are not setting the semantically equivalent flags, the behavior of the implementation is undefined.
9. Usage Example
9. Usage Example
An example of usage of this API is given below:
An example of usage of this API is given below:
struct addrinfo hints, *ai, *ai0;
uint32_t preferences;
struct addrinfo hints, *ai, *ai0; uint32_t preferences;
preferences = IPV6_PREFER_SRC_TMP;
preferences = IPV6_PREFER_SRC_TMP;
hints.ai_flags |= AI_EXTFLAGS;
hints.ai_eflags = preferences; /* Chosen address preference flag */
/* Fill in other hints fields */
hints.ai_flags |= AI_EXTFLAGS; hints.ai_eflags = preferences; /* Chosen address preference flag */ /* Fill in other hints fields */
getaddrinfo(....,&hints,. &ai0..);
getaddrinfo(....,&hints,. &ai0..);
/* Loop over all returned addresses and do connect */
for (ai = ai0; ai; ai = ai->ai_next) {
s = socket(ai->ai_family, ...);
/* Loop over all returned addresses and do connect */ for (ai = ai0; ai; ai = ai->ai_next) { s = socket(ai->ai_family, ...);
setsockopt(s, IPV6_ADDR_PREFERENCES, (void *) &preferences,
sizeof (preferences));
setsockopt(s, IPV6_ADDR_PREFERENCES, (void *) &preferences, sizeof (preferences));
if (connect(s, ai->ai_addr, ai->ai_addrlen) == -1){
close (s);
s = -1;
continue;
}
if (connect(s, ai->ai_addr, ai->ai_addrlen) == -1){ close (s); s = -1; continue; }
break;
}
break; }
freeaddrinfo(ai0);
freeaddrinfo(ai0);
10. Implementation Notes
10. Implementation Notes
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 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.
Nordmark, et al. Informational [Page 13] RFC 5014 Socket API for Source Address Selection September 2007
Nordmark, et al. Informational [Page 13] RFC 5014 Socket API for Source Address Selection September 2007
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() 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 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 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 An implementation supporting this API MUST implement both
getaddrinfo() extension flags and socket option flags processing
for portability of applications.
o An implementation supporting this API MUST implement both getaddrinfo() extension flags and socket option flags processing for portability of applications.
o The following flags are set as default values on a system (which
is consistent with [RFC3484] defaults):
o The following flags are set as default values on a system (which is consistent with [RFC3484] defaults):
IPV6_PREFER_SRC_HOME
IPV6_PREFER_SRC_HOME
IPV6_PREFER_SRC_PUBLIC
IPV6_PREFER_SRC_PUBLIC
IPV6_PREFER_SRC_CGA
IPV6_PREFER_SRC_CGA
11. Mapping to Default Address Selection Rules
11. Mapping to Default Address Selection Rules
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].
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].
Source address selection rule #4 (prefer home address):
Source address selection rule #4 (prefer home address):
IPV6_PREFER_SRC_HOME (default)
IPV6_PREFER_SRC_HOME (default)
IPV6_PREFER_SRC_COA
IPV6_PREFER_SRC_COA
Source address selection rule #7 (prefer public address):
Source address selection rule #7 (prefer public address):
IPV6_PREFER_SRC_PUBLIC (default)
IPV6_PREFER_SRC_PUBLIC (default)
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
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
Nordmark, et al. Informational [Page 14] RFC 5014 Socket API for Source Address Selection September 2007
Nordmark, et al. Informational [Page 14] RFC 5014 Socket API for Source Address Selection September 2007
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.
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.
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.
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.
The following numerical example clarifies the above further.
The following numerical example clarifies the above further.
Imagine a host with two addresses:
Imagine a host with two addresses:
1234::1:1 public
1234::1:1 public
9876::1:2 temporary
9876::1:2 temporary
The destination has the following two addresses:
The destination has the following two addresses:
1234::9:3
1234::9:3
9876::9:4
9876::9:4
Nordmark, et al. Informational [Page 15] RFC 5014 Socket API for Source Address Selection September 2007
Nordmark, et al. Informational [Page 15] RFC 5014 Socket API for Source Address Selection September 2007
By default, getaddrinfo() will return the destination addresses in the following order:
By default, getaddrinfo() will return the destination addresses in the following order:
1234::9:3
1234::9:3
9876::9:4
9876::9:4
because the public source is preferred and 1234 matches more bits with the public source address. On the other hand, if ai_flags is set to AI_EXTFLAGS and ai_eflags to IPV6_PREFER_SRC_TMP, getaddrinfo will return the addresses in the reverse order since the temporary source address will be preferred.
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.
Other source address rules (that are not mentioned here) were also deemed not applicable for changing its default on a per-application basis.
Other source address rules (that are not mentioned here) were also deemed not applicable for changing its default on a per-application basis.
12. IPv4-Mapped IPv6 Addresses
12. IPv4-Mapped IPv6 Addresses
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.
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.
13. Validating Source Address Preferences
13. Validating Source Address Preferences
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:
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:
Nordmark, et al. Informational [Page 16] RFC 5014 Socket API for Source Address Selection September 2007
Nordmark, et al. Informational [Page 16] RFC 5014 Socket API for Source Address Selection September 2007
1. The application specifies one or more IPV6_PREFER_SRC_* flags and
AI_EXTFLAGS ai_flags with getaddrinfo().
1. The application specifies one or more IPV6_PREFER_SRC_* flags and AI_EXTFLAGS ai_flags with getaddrinfo().
2. The application specifies the same IPV6_PREFER_SRC_* flags with
setsockopt().
2. The application specifies the same IPV6_PREFER_SRC_* flags with setsockopt().
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. 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.
4. Retrieve the selected source address using the getsockname() API
call.
4. Retrieve the selected source address using the getsockname() API call.
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. 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.
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:
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 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:
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:
o sin6_addr is a 128-bit IPv6 destination address with which the
local node wants to communicate;
o sin6_addr is a 128-bit IPv6 destination address with which the local node wants to communicate;
o sin6_family MUST be set to AF_INET6;
o sin6_family MUST be set to AF_INET6;
Nordmark, et al. Informational [Page 17] RFC 5014 Socket API for Source Address Selection September 2007
Nordmark, et al. Informational [Page 17] RFC 5014 Socket API for Source Address Selection September 2007
o sin6_scope_id MUST be set if the address is link-local;
o sin6_scope_id MUST be set if the address is link-local;
and dstaddrlen is the size of the sockaddr structure passed as argument.
and dstaddrlen is the size of the sockaddr structure passed as argument.
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.
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.
The verification of temporary vs. public, home vs. care-of, CGA vs. not, are performed by a new validation function defined for this purpose:
The verification of temporary vs. public, home vs. care-of, CGA vs. not, are performed by a new validation function defined for this purpose:
#include <netinet/in.h>
#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:
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:
o sin6_addr is a 128-bit IPv6 address of the local node.
o sin6_addr is a 128-bit IPv6 address of the local node.
o sin6_family MUST be set to AF_INET6.
o sin6_family MUST be set to AF_INET6.
o sin6_scope_id MUST be set if the address is link-local.
o sin6_scope_id MUST be set if the address is link-local.
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() 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.)
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.
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.
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).
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).
Nordmark, et al. Informational [Page 18] RFC 5014 Socket API for Source Address Selection September 2007
Nordmark, et al. Informational [Page 18] RFC 5014 Socket API for Source Address Selection September 2007
14. Summary of New Definitions
14. Summary of New Definitions
The following list summarizes the constants, structure, and extern definitions discussed in this memo, sorted by header.
The following list summarizes the constants, structure, and extern definitions discussed in this memo, sorted by header.
<netdb.h> AI_EXTFLAGS
<netdb.h> IPV6_PREFER_SRC_HOME
<netdb.h> IPV6_PREFER_SRC_COA
<netdb.h> IPV6_PREFER_SRC_TMP
<netdb.h> IPV6_PREFER_SRC_PUBLIC
<netdb.h> IPV6_PREFER_SRC_CGA
<netdb.h> IPV6_PREFER_SRC_NONCGA
<netdb.h> EAI_BADEXTFLAGS
<netdb.h> struct addrinfo{};
<netdb.h> AI_EXTFLAGS <netdb.h> IPV6_PREFER_SRC_HOME <netdb.h> IPV6_PREFER_SRC_COA <netdb.h> IPV6_PREFER_SRC_TMP <netdb.h> IPV6_PREFER_SRC_PUBLIC <netdb.h> IPV6_PREFER_SRC_CGA <netdb.h> IPV6_PREFER_SRC_NONCGA <netdb.h> EAI_BADEXTFLAGS <netdb.h> struct addrinfo{};
<netinet/in.h> IPV6_PREFER_SRC_HOME
<netinet/in.h> IPV6_PREFER_SRC_COA
<netinet/in.h> IPV6_PREFER_SRC_TMP
<netinet/in.h> IPV6_PREFER_SRC_PUBLIC
<netinet/in.h> IPV6_PREFER_SRC_CGA
<netinet/in.h> IPV6_PREFER_SRC_NONCGA
<netinet/in.h> short inet6_is_srcaddr(struct sockaddr_in6 *,
uint32_t);
<netinet/in.h> int bind2addrsel(int, const struct sockaddr *,
socklen_t);
<netinet/in.h> IPV6_PREFER_SRC_HOME <netinet/in.h> IPV6_PREFER_SRC_COA <netinet/in.h> IPV6_PREFER_SRC_TMP <netinet/in.h> IPV6_PREFER_SRC_PUBLIC <netinet/in.h> IPV6_PREFER_SRC_CGA <netinet/in.h> IPV6_PREFER_SRC_NONCGA <netinet/in.h> short inet6_is_srcaddr(struct sockaddr_in6 *, uint32_t); <netinet/in.h> int bind2addrsel(int, const struct sockaddr *, socklen_t);
15. Security Considerations
15. Security Considerations
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.
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.
16. Acknowledgments
16. Acknowledgments
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
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
Nordmark, et al. Informational [Page 19] RFC 5014 Socket API for Source Address Selection September 2007
Nordmark, et al. Informational [Page 19] RFC 5014 Socket API for Source Address Selection September 2007
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.
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.
17. References
17. References
17.1. Normative References
17.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.
[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., and W. Stevens, "Basic Socket Interface Extensions for IPv6", RFC 3493, February 2003.
17.2. Informative References
17.2. Informative References
[FPING] "Fping - a program to ping hosts in parallel", Online web
site http://www.fping.com.
[FPING] "Fping - a program to ping hosts in parallel", Online web site http://www.fping.com.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC3041] Narten, T. and R. Draves, "Privacy Extensions for
Stateless Address Autoconfiguration in IPv6", RFC 3041,
January 2001.
[RFC3041] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[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., and T. Jinmei, "Advanced Sockets Application Program Interface (API) for IPv6", RFC 3542, May 2003.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[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., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, March 2005.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005.
Nordmark, et al. Informational [Page 20] RFC 5014 Socket API for Source Address Selection September 2007
Nordmark, et al. Informational [Page 20] RFC 5014 Socket API for Source Address Selection September 2007
Appendix A. Per-Packet Address Selection Preference
Appendix A. Per-Packet Address Selection Preference
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.
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.
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.
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.
しかしながら、このドキュメントは持っているそれがオプションが好きであるそれらの実装のための側を伝えている補助データがデフォルトソースアドレス選択を変更するオブジェクトサポートであると実装するガイドラインを提供します。 したがって、アプリケーションが、1パケットあたりのソースアドレス選択を使用するのを選ぶなら、実装はデータとしてのタイプ(cmsg_はタイプされる)IPV6_ADDR_PREFERENCES含有のIPPROTO_IPV6レベル(cmsg_レベル)補助データオブジェクトで処理されるべきです。(ソースアドレス選択好みが高度なIPV6 Socket API[RFC3542]と同様のファッションで旗を揚げさせる(例えば、IPV6_PREFER_SRC_コア川| IPV6_PREFER_SRC_PUBLIC)cmsg_データの[])のa32ビットの符号のない整数コード化。 このアドレス選択好みの補助データオブジェクトは他の補助データオブジェクトと共に存在しているかもしれません。
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:
補助データオブジェクトを処理する実装は補助データオブジェクトにみられるように都合のよいソースアドレスの選択に原因となります。 したがって、アプリケーションは、アドレス選択好みの補助データオブジェクトをIPv6層に渡すのにsendmsg()を使用できます。 以下の例はアドレス優先順位を設定するために補助データAPIの使用法を示しています:
Nordmark, et al. Informational [Page 21] RFC 5014 Socket API for Source Address Selection September 2007
Nordmark、他 ソースアドレス選択2007年9月のための情報[21ページ]のRFC5014ソケットAPI
void *extptr; socklen_t extlen; struct msghdr msg; struct cmsghdr *cmsgptr; int cmsglen; struct sockaddr_in6 dest; uint32_t flags;
*extptrを欠如させてください。 socklen_t extlen。 struct msghdr msg。 struct cmsghdr*cmsgptr。 int cmsglen。 struct sockaddr_in6 dest。 uint32_tは弛みます。
extlen = sizeof(flags); cmsglen = CMSG_SPACE(extlen); cmsgptr = malloc(cmsglen); cmsgptr->cmsg_len = CMSG_LEN(extlen); cmsgptr->cmsg_level = IPPROTO_IPV6; cmsgptr->cmsg_type = IPV6_ADDR_PREFERENCES;
extlenはsizeofと等しいです(旗)。 cmsglenはCMSG_SPACEと等しいです(extlenします)。 cmsgptrはmallocと等しいです(cmsglenします)。 cmsgptr>のcmsg_lenはCMSG_LENと等しいです(extlenします)。 cmsgptr>cmsg_平らな=IPPROTO_IPV6。 cmsg_がIPV6_ADDR_PREFERENCESと等しいのをタイプするcmsgptr->。
extptr = CMSG_DATA(cmsgptr);
extptrはCMSG_DATAと等しいです(cmsgptr)。
flags = IPV6_PREFER_SRC_COA; memcpy(extptr, &flags, extlen);
旗はIPV6_PREFER_SRC_COAと等しいです。 memcpy(extptr、および旗はextlenされます)。
msg.msg_control = cmsgptr; msg.msg_controllen = cmsglen;
msg.msg_コントロールはcmsgptrと等しいです。 msg.msg_controllenはcmsglenと等しいです。
/* finish filling in msg{} */
中にmsgをいっぱいにする/*終わり、*/
msg.msg_name = dest;
msg.msg_名前は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()によって送られるパケットのためのアドレス優先順位を指定するのに使用されます。
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.
このドキュメントは、適切であるときに、ソースアドレスとしてCryptographically Generated Address(CGA)を選ぶためにソース好みの旗を定義するだけです。 アドレスが所有権であると立証するのに公開鍵とハッシュを使用することでCGAsを入手します。 そのようなメソッドに関していくつかのIPRクレームをしました。
Nordmark, et al. Informational [Page 22] RFC 5014 Socket API for Source Address Selection September 2007
Nordmark、他 ソースアドレス選択2007年9月のための情報[22ページ]のRFC5014ソケットAPI
Authors' Addresses
作者のアドレス
Erik Nordmark Sun Microsystems, Inc. 17 Network Circle Menlo Park, CA 94025 USA
エリックNordmarkサン・マイクロシステムズ・インク17ネットワーク円のカリフォルニア94025メンローパーク(米国)
EMail: Erik.Nordmark@Sun.com
メール: Erik.Nordmark@Sun.com
Samita Chakrabarti Azaire Networks 3121 Jay Street, Suite 210 Santa Clara, CA 95054 USA
Samita Chakrabarti Azaireは3121ジェイ通り、Suite210カリフォルニア95054サンタクララ(米国)をネットワークでつなぎます。
EMail: samitac2@gmail.com
メール: samitac2@gmail.com
Julien Laganier DoCoMo Euro-Labs Landsbergerstrasse 312 D-80687 Muenchen Germany
ジュリアンLaganier DoCoMoユーロ研究室Landsbergerstrasse312D-80687 Muenchenドイツ
EMail: julien.IETF@laposte.net
メール: julien.IETF@laposte.net
Nordmark, et al. Informational [Page 23] RFC 5014 Socket API for Source Address Selection September 2007
Nordmark、他 ソースアドレス選択2007年9月のための情報[23ページ]のRFC5014ソケットAPI
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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に情報を扱ってください。
Nordmark, et al. Informational [Page 24]
Nordmark、他 情報[24ページ]
一覧
スポンサーリンク
