この文書はRFC3484の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
Network Working Group R. Draves Request for Comments: 3484 Microsoft Research Category: Standards Track February 2003 Default Address Selection for Internet Protocol version 6 (IPv6) インターネット・プロトコルバージョン６（ＩＰｖ６）のための デフォルトアドレス選択 Status of this Memo この文書の状態 This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. この文書はインターネット共同体のためのインターネット標準化作業中のプ ロトコルを指定して、そして改良のために議論と提案を求めます。標準化状 態とこのプロトコル状態は「インターネット公式プロトコル標準」（ＳＴＤ １）の現在の版を参照してください。このメモの配布は無制限です。 Copyright Notice 著作権表示 Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract 概要 This document describes two algorithms, for source address selection and for destination address selection. The algorithms specify default behavior for all Internet Protocol version 6 (IPv6) implementations. They do not override choices made by applications or upper-layer protocols, nor do they preclude the development of more advanced mechanisms for address selection. The two algorithms share a common context, including an optional mechanism for allowing administrators to provide policy that can override the default behavior. In dual stack implementations, the destination address selection algorithm can consider both IPv4 and IPv6 addresses - depending on the available source addresses, the algorithm might prefer IPv6 addresses over IPv4 addresses, or vice-versa. この文書は、ソースアドレス選択と、宛先アドレス選択の、２つのアルゴリ ズムを記述します。アルゴリズムはすべてのインターネット・プロトコルバー ジョン６（ＩＰｖ６）実装のデフォルト行動を指定します。これらはアプリ ケーションによってされた選択あるいは上位レイヤプロトコルに優先しませ ん、同様にこれらはアドレス選択のためにいっそう進歩したメカニズムの開 発を妨げません。２つのアルゴリズムは管理者にデフォルト行動に優先する ポリシーの供給を許すオプションメカニズムを含めて、共通コンテキストを 共有します。デュアルスタック実装で、宛先アドレス選択アルゴリズムは、 利用可能なソースアドレスに依存して、ＩＰｖ４とＩＰｖ６アドレスの両方 を考えることができます、アルゴリズムはＩＰｖ４アドレスよりＩＰｖ６ア ドレスの方が優先かもしれないし、逆かもしれません。 All IPv6 nodes, including both hosts and routers, must implement default address selection as defined in this specification. ホストとルーター両方を含めて、すべてのＩＰｖ６ノードは、この仕様書で 定義されるように、デフォルトアドレス選択を実装しなくてはなりません。 Table of Contents 目次 1. Introduction 1. はじめに 1.1. Conventions Used in This Document 1.1. この文書で使われる取り決め 2. Context in Which the Algorithms Operate 2. アルゴリズムが稼働する状況 2.1. Policy Table 2.1. ポリシー表 2.2. Common Prefix Length 2.2. 共通プレフィックス長 3. Address Properties 3. アドレス特性 3.1. Scope Comparisons 3.1. 範囲比較 3.2. IPv4 Addresses and IPv4-Mapped Addresses 3.2. ＩＰｖ４アドレスとＩＰｖ４マップアドレス 3.3. Other IPv6 Addresses with Embedded IPv4 Addresses 3.3. 他の埋込みＩＰｖ４アドレスを持つＩＰｖ６アドレス 3.4. IPv6 Loopback Address and Other Format Prefixes 3.4. ＩＰｖ６ループバックアドレスと他のフォーマットプレフィックス 3.5. Mobility Addresses 3.5. 移動アドレス 4. Candidate Source Addresses 4. 候補ソースアドレス 5. Source Address Selection 5. ソースアドレス選択 6. Destination Address Selection 6. 宛先アドレス選択 7. Interactions with Routing 7. ルーティングの相互作用 8. Implementation Considerations 8. 実装の考察 9. Security Considerations 9. セキュリティの考察 10. Examples 10. 例 10.1. Default Source Address Selection 10.1. デフォルトソースアドレス選択 10.2. Default Destination Address Selection 10.2. デフォルト宛先アドレス選択 10.3. Configuring Preference for IPv6 or IPv4 10.3. ＩＰｖ６あるいはＩＰｖ４に対する優先の設定 10.4. Configuring Preference for Scoped Addresses 10.4. 範囲アドレスに対する優先設定 10.5. Configuring a Multi-Homed Site 10.5. マルチホームサイト設定 Normative References 参照する参考文献 Informative References 有益な参考文献 Acknowledgments 謝辞 Author's Address 著者のアドレス Full Copyright Statement 著作権表示全文 1. Introduction 1. はじめに The IPv6 addressing architecture [1] allows multiple unicast addresses to be assigned to interfaces. These addresses may have different reachability scopes (link-local, site-local, or global). These addresses may also be "preferred" or "deprecated" [2]. Privacy considerations have introduced the concepts of "public addresses" and "temporary addresses" [3]. The mobility architecture introduces "home addresses" and "care-of addresses" [8]. In addition, multi- homing situations will result in more addresses per node. For example, a node may have multiple interfaces, some of them tunnels or virtual interfaces, or a site may have multiple ISP attachments with a global prefix per ISP. ＩＰｖ６アドレス体系[1]は多数のユニキャストアドレスをインタフェースに 割り当てることを許します。これらのアドレスは異なった可到達性範囲を持っ ているかもしれません（リンクローカル、サイトローカル、グローバル）。 これらのアドレスは同じく「望ましい」か、あるいは「抑制」かもしれませ ん[2]。プライバシー考慮が「公共アドレス」と「一時的アドレス」の概念を 紹介しました[3]。移動アーキテクチャは「ホームアドレス」と「立ち寄りア ドレス」を紹介します[8]。加えるに、マルチホーム状態がノード毎にもっと 多くのアドレスをもたらすでしょう。例えば、ノードが多数のインタフェー スを持っているかもしれません、それらのいくつかはトンネルや仮想インタ フェースかもしれません、あるいはサイトがＩＰＳ毎のグローバルプレフィッ クスで多数のＩＳＰに接続しているかもしれません。 The end result is that IPv6 implementations will very often be faced with multiple possible source and destination addresses when initiating communication. It is desirable to have default algorithms, common across all implementations, for selecting source and destination addresses so that developers and administrators can reason about and predict the behavior of their systems. 最終結果はＩＰｖ６実装が、通信を始める時、非常にしばしば多数の可能な ソースと宛先アドレスに直面するであろうということです。開発者と管理者 がシステムの行動について推論し予言ができるように、ソースと宛先アドレ スを選ぶことに対してデフォルトアルゴリズム、すべての実装での常識、を 持つことは望ましいです。 Furthermore, dual or hybrid stack implementations, which support both IPv6 and IPv4, will very often need to choose between IPv6 and IPv4 when initiating communication. For example, when DNS name resolution yields both IPv6 and IPv4 addresses and the network protocol stack has available both IPv6 and IPv4 source addresses. In such cases, a simple policy to always prefer IPv6 or always prefer IPv4 can produce poor behavior. As one example, suppose a DNS name resolves to a global IPv6 address and a global IPv4 address. If the node has assigned a global IPv6 address and a 169.254/16 auto-configured IPv4 address [9], then IPv6 is the best choice for communication. But if the node has assigned only a link-local IPv6 address and a global IPv4 address, then IPv4 is the best choice for communication. The destination address selection algorithm solves this with a unified procedure for choosing among both IPv6 and IPv4 addresses. さらに、ＩＰｖ６とＩＰｖ４両方をサポートするデュアル、あるいはハイブ リッドスタック実装が非常にしばしば通信を始める時、ＩＰｖ６とＩＰｖ４ の間の選択をする必要があるでしょう。例えば、ＤＮＳ名解決がＩＰｖ６と ＩＰｖ４アドレスの両方をもたらし、ネットワークプロトコルスタックがＩ Ｐｖ６とＩＰｖ４の両方のソースアドレスを利用可能である場合です。この ような場合、常にＩＰｖ６の方が優先化、あるいは常にＩＰｖ４の方が優先 かの単純なポリシーが程度が低い行動を引き起こします。１つの例として、 グローバルＩＰｖ６アドレスとグローバルＩＰｖ４アドレスのＤＮＳ名前リ ゾルバを考えてください。もしノードがグローバルなＩＰｖ６アドレスと 169.254/16自動設定ＩＰｖ４アドレス[9]を割り当てられたなら、ＩＰｖ６は 通信の最も良い選択です。けれどももしノードがただリンクローカルＩＰｖ ６アドレスとグローバルＩＰｖ４アドレスだけを割り当てられたなら、ＩＰ ｖ４は通信の最も良い選択です。宛先アドレス選択アルゴリズムはＩＰｖ６ とＩＰｖ４アドレス両方の間で選択することのための統一された手順でこれ を解きます。 The algorithms in this document are specified as a set of rules that define a partial ordering on the set of addresses that are available for use. In the case of source address selection, a node typically has multiple addresses assigned to its interfaces, and the source address ordering rules in section 5 define which address is the "best" one to use. In the case of destination address selection, the DNS may return a set of addresses for a given name, and an application needs to decide which one to use first, and in what order to try others should the first one not be reachable. The destination address ordering rules in section 6, when applied to the set of addresses returned by the DNS, provide such a recommended ordering. この文書のアルゴリズムは利用可能アドレス集合上に部分的順序を定義する 規則群として明示されます。ソースアドレス選択の場合、ノードが典型的に インタフェースに割り当てられた多数のアドレスを持ち、５章のソースアド レス順位付け規則がどのアドレスが「最も良い」か定義します。宛先アドレ ス選択のばあい、ＤＮＳは与えられた名前についてアドレス集合を返すでしょ う、そしてアプリケーションが最初にどれを使うべきか、もし最初のが連絡 可能ではなかったなら、どの順序で他のものを試みるべきか決める必要があ ります。６章の宛先アドレス順序規則は、ＤＮＳによって返されたアドレス の集合に適用される時、推薦された順序を供給します。 This document specifies source address selection and destination address selection separately, but using a common context so that together the two algorithms yield useful results. The algorithms attempt to choose source and destination addresses of appropriate scope and configuration status (preferred or deprecated in the RFC 2462 sense). Furthermore, this document suggests a preferred method, longest matching prefix, for choosing among otherwise equivalent addresses in the absence of better information. この文書はソースアドレス選択と宛先アドレス選択を別に指定しますが、２ つのアルゴリズムが有用な結果を生じるように、共通のコンテキストを使い ます。アルゴリズムは適切な範囲のソースと宛先アドレスと設定状態（ＲＦ Ｃ２４６２の意味で、好ましいか、抑制か）を選択しようと試みます。さら に、この文書はほかに良い情報がない場合に等しいアドレス間で選択する際 の望ましい方法、最長一致プレフィックス、を提案します。 This document also specifies policy hooks to allow administrative override of the default behavior. For example, using these hooks an administrator can specify a preferred source prefix for use with a destination prefix, or prefer destination addresses with one prefix over addresses with another prefix. These hooks give an administrator flexibility in dealing with some multi-homing and transition scenarios, but they are certainly not a panacea. この文章は同じく管理上で許すべき優先デフォルト行動のポリシーフックを 指定します。例えば、これらのフックを使って、管理者が宛先プレフィック スで使が望ましいソースプレフィックスを指定するか、あるいは宛先アドレ スで他のプレフィックスより優先なプレフィックスでを指定できます。これ らのフックはあるマルチホームと移行シナリオを扱う際に管理者に柔軟性を 与えますが、それらは確かに万能薬ではありません。 The selection rules specified in this document MUST NOT be construed to override an application or upper-layer's explicit choice of a legal destination or source address. この文書で指定した選択規則はアプリケーションあるいは上位レイヤの正当 な宛先あるいはソースアドレスの明白な選択に優先すると解釈されてはなり ません(MUST NOT)。 1.1. Conventions Used in This Document 1.1. この文書で使われる取り決め 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 BCP 14, RFC 2119 [4]. この文書のキーワード"MUST"と"MUST NOT"と"REQUIRED"と"SHALL"と"SHALL NOT"と"SHOULD"と"SHOULD NOT"と"RECOMMENDED"と"MAY"と"OPTIONAL"はＢＣ Ｐ１４、ＲＦＣ２１１９[4]で記述したように解釈されるはずです。 2. Context in Which the Algorithms Operate 2. アルゴリズムが稼働する状況 Our context for address selection derives from the most common implementation architecture, which separates the choice of destination address from the choice of source address. Consequently, we have two separate algorithms for these tasks. The algorithms are designed to work well together and they share a mechanism for administrative policy override. 我々のアドレス選択のための状況は最もありふれた実装構造から生じ、そし てこれは宛先アドレスの選択をソースアドレスの選択から分離します。従っ て、我々はこれらの仕事のために２つの別のアルゴリズムを持っています。 アルゴリズムは一緒に上手に働くよう意図され、そしてそれらは管理ポリシー の優先メカニズムを共有します。 In this implementation architecture, applications use APIs [10] like getaddrinfo() that return a list of addresses to the application. This list might contain both IPv6 and IPv4 addresses (sometimes represented as IPv4-mapped addresses). The application then passes a destination address to the network stack with connect() or sendto(). The application would then typically try the first address in the list, looping over the list of addresses until it finds a working address. In any case, the network layer is never in a situation where it needs to choose a destination address from several alternatives. The application might also specify a source address with bind(), but often the source address is left unspecified. Therefore the network layer does often choose a source address from several alternatives. この実装構造で、アプリケーションにアドレスのリストを返すgetaddrinfo() のようなＡＰＩ[10]をアプリケーションは使います。このリストはＩＰｖ６ とＩＰｖ４アドレス（時々ＩＰｖ４マップアドレスと描かれる）の両方を含 んでいるかもしれません。アプリケーションはconnect()やsendto()でネット ワークスタックに宛先アドレスを渡します。アプリケーションは一般に、動 いているアドレスを見いだすまで、アドレスリストの輪を作って、リストの 最初のアドレスを試みるでしょう。いずれの場合も、ネットワーク層は決し て代替宛先アドレスを選ぶ必要がある状態ではありません。アプリケーショ ンはbind()で同じくソースアドレスを指定するかもしれませんが、しばしば ソースアドレスは特定されていないままにしておかれます。それ故にネット ワーク層はしばしばいくつかの代案からソースアドレスを選択します。 As a consequence, we intend that implementations of getaddrinfo() will use the destination address selection algorithm specified here to sort the list of IPv6 and IPv4 addresses that they return. Separately, the IPv6 network layer will use the source address selection algorithm when an application or upper-layer has not specified a source address. Application of this specification to source address selection in an IPv4 network layer may be possible but this is not explored further here. 結果として、我々はgetaddrinfo()の実装が、返すＩＰｖ６とＩＰｖ４アドレ スのリストをソートするためにここで指定された宛先アドレス選択アルゴリ ズムを使うであろうことを意図します。別に、ＩＰｖ６ネットワーク層は、 アプリケーションや上位レイヤがソースアドレスを指定しなかった時、ソー スアドレス選択アルゴリズムを使うでしょう。ＩＰｖ４ネットワーク層でソー スアドレス選択をするためのこの仕様書の適用は可能であるかもしれません が、ここではこれ以上探索しません。 Well-behaved applications SHOULD iterate through the list of addresses returned from getaddrinfo() until they find a working address. 行儀が良いアプリケーションが、動作しているアドレスを見つけるまで、 getaddrinfo()から返されたアドレスリストを反復するべきです(SHOULD)。 The algorithms use several criteria in making their decisions. The combined effect is to prefer destination/source address pairs for which the two addresses are of equal scope or type, prefer smaller scopes over larger scopes for the destination address, prefer non- deprecated source addresses, avoid the use of transitional addresses when native addresses are available, and all else being equal prefer address pairs having the longest possible common prefix. For source address selection, public addresses [3] are preferred over temporary addresses. In mobile situations [8], home addresses are preferred over care-of addresses. If an address is simultaneously a home address and a care-of address (indicating the mobile node is "at home" for that address), then the home/care-of address is preferred over addresses that are solely a home address or solely a care-of address. アルゴリズムはこれらの決定にいくつかの基準を使います。結合効果は、宛 先／ソースアドレス対の範囲かタイプが同じのが優先で、宛先アドレスは広 い範囲より狭い範囲が優先で、抑制ソースアドレスでないのが優先で、ネイ ティブアドレスが利用可能なら移行アドレスを避け、他の同じ優先度のアド レスはプレフィックスが最長一致であるのが優先です。ソースアドレス選択 のために、公共アドレス[3]が一時的アドレスより優先です。移動状態[8]で、 ホームアドレスが立ち寄りアドレスより優先です。もしアドレスが同時にホー ムアドレスと立ち寄りアドレスならば（移動ノードをそのアドレスについて 「家にいる」）、ホーム／立ち寄りアドレスは、ホームだけのアドレスや、 立ち寄りだけのアドレスより好まれます。 This specification optionally allows for the possibility of administrative configuration of policy that can override the default behavior of the algorithms. The policy override takes the form of a configurable table that specifies precedence values and preferred source prefixes for destination prefixes. If an implementation is not configurable, or if an implementation has not been configured, then the default policy table specified in this document SHOULD be used. この仕様書は任意指定の、アルゴリズムのデフォルト行動に優先する、管理 ポリシー設定の可能性を考慮します。ポリシーは、宛先プレフィックスに対 する優先のソースプレフィックスと優先度を指定する構成可能な表の形式で す。もし実装が構成可能ではないなら、あるいはもし実装が構成を設定され なかったら、この文書で指定したデフォルトポリシーが使われるべきです (SHOULD)。 2.1. Policy Table 2.1. ポリシー表 The policy table is a longest-matching-prefix lookup table, much like a routing table. Given an address A, a lookup in the policy table produces two values: a precedence value Precedence(A) and a classification or label Label(A). ポリシー表は、ルーティングテーブルとほとんど同じように、最長一致プレ フィックス検索テーブルです。与えられたアドレスＡに対し、ポリシー表検 索は2つの値を検索します：優先値Precedence(A)、分類あるいはラベル Label(A)。 The precedence value Precedence(A) is used for sorting destination addresses. If Precedence(A) > Precedence(B), we say that address A has higher precedence than address B, meaning that our algorithm will prefer to sort destination address A before destination address B. 優先値Precedence(A)は宛先アドレスを並べ替えるのに使います。もし Precedence(A) > Precedence(B)なら、我々はアドレスＡはアドレスＢより優 先と言い、我々のアルゴリズムが宛先アドレスＢの前に宛先アドレスＡを並 べることを好むことを意味します。 The label value Label(A) allows for policies that prefer a particular source address prefix for use with a destination address prefix. The algorithms prefer to use a source address S with a destination address D if Label(S) = Label(D). ラベル値Label(A)は宛先アドレスプレフィックスと共に使用する特定のソー スアドレスプレフィックスが優先であるポリシーを考慮します。アルゴリズ ムは、もしLabel(S) = Label(D)なら、宛先アドレスＤに対し、ソースアドレ スＳを使うことをより好みます。 IPv6 implementations SHOULD support configurable address selection via a mechanism at least as powerful as the policy tables defined here. Note that at the time of this writing there is only limited experience with the use of policies that select from a set of possible IPv6 addresses. As more experience is gained, the recommended default policies may change. Consequently it is important that implementations provide a way to change the default policies as more experience is gained. Sections 10.3 and 10.4 provide examples of the kind of changes that might be needed. ＩＰｖ６実装が少なくともここで定義したポリシー表と同じぐらい強力なメ カニズムの構成可能なアドレス選択をサポートするべきです(SHOULD)。利用 可能なＩＰｖ６アドレスの集合から選択するポリシーの使用について、この 著作時点で、限定された経験があるだけのことに注意してください。もっと 多くの経験が得られるにつれて、推薦されたデフォルトポリシーは変化する かもしれません。従って実装が、もっと多くの経験が得られるにつれて、デ フォルトポリシーを変える方法を供給することは重要です。１０.３章と １０.４章が必要とされるかもしれない変更の種類の例を供給します。 If an implementation is not configurable or has not been configured, then it SHOULD operate according to the algorithms specified here in conjunction with the following default policy table: もし実装が構成可能ではないか、あるいは構成を設定されなかったなら、次 のデフォルトポリシー表と共にここで指定されたアルゴリズムで稼働するべ きです(SHOULD)： Prefix Precedence Label ::1/128 50 0 ::/0 40 1 2002::/16 30 2 ::/96 20 3 ::ffff:0:0/96 10 4 One effect of the default policy table is to prefer using native source addresses with native destination addresses, 6to4 [5] source addresses with 6to4 destination addresses, and v4-compatible [1] source addresses with v4-compatible destination addresses. Another effect of the default policy table is to prefer communication using IPv6 addresses to communication using IPv4 addresses, if matching source addresses are available. デフォルトポリシー表の１つの効果は、ネイティブソースアドレスとネイティ ブの宛先アドレス、６to４[5]ソースアドレスと６to４ 宛先アドレス、ｖ４ コンパチブルの[1]ソースアドレスとｖ４コンパチブル宛先アドレス、をより 優先することです。他のデフォルトポリシー表の効果は、もし一致するソー スアドレスが利用可能であるなら、ＩＰｖ６アドレスを使う通信がＩＰｖ４ アドレスを使う通信より優先する事です。 Policy table entries for scoped address prefixes MAY be qualified with an optional zone index. If so, a prefix table entry only matches against an address during a lookup if the zone index also matches the address's zone index. 範囲付きアドレスプレフィックスのポリシー表項目は、オプションのゾーン インデックスが設定されるかもしれません(MAY)。もしそうであるなら、プレ フィックス表項目は、ゾーンインデックスがアドレスのゾーンインデックス と一致する場合にだけ、検索アドレスに対して一致します。 2.2. Common Prefix Length 2.2. 共通プレフィックス長 We define the common prefix length CommonPrefixLen(A, B) of two addresses A and B as the length of the longest prefix (looking at the most significant, or leftmost, bits) that the two addresses have in common. It ranges from 0 to 128. 我々は２つのアドレスAとBの共通プレフィックス長CommonPrefixLen(A, B) を、２つのアドレスが共通にもつ最大のプレフィックス（最重要、又は最左 ビットを見る）と、定義します。これは０から１２８までです。 3. Address Properties 3. アドレス特性 In the rules given in later sections, addresses of different types (e.g., IPv4, IPv6, multicast and unicast) are compared against each other. Some of these address types have properties that aren't directly comparable to each other. For example, IPv6 unicast addresses can be "preferred" or "deprecated" [2], while IPv4 addresses have no such notion. To compare such addresses using the ordering rules (e.g., to use "preferred" addresses in preference to "deprecated" addresses), the following mappings are defined. 後の章で与えられた規則で、異なったタイプのアドレス（例えば、ＩＰｖ４ とＩＰｖ６、マルチキャストとユニキャスト）がお互いを基準にして判断さ れます。これらのアドレスタイプのいくつかが直接お互いに比較できない特 性を持っています。例えば、ＩＰｖ６ユニキャストアドレスは「望ましい」 と「抑制」があります[2]、他方ＩＰｖ４アドレスがこのようなどの考えを 持っていません。このようなアドレスを順序規則で比較するために、次の マッピングを定義します（例えば、「抑制」アドレスに対する「望ましい」 アドレスの優先使用）。 3.1. Scope Comparisons 3.1. 範囲比較 Multicast destination addresses have a 4-bit scope field that controls the propagation of the multicast packet. The IPv6 addressing architecture defines scope field values for interface- local (0x1), link-local (0x2), subnet-local (0x3), admin-local (0x4), site-local (0x5), organization-local (0x8), and global (0xE) scopes [11]. マルチキャスト宛先アドレスがマルチキャストパケットの配布をコントロー ルする４ビットの範囲フィールドを持っています。ＩＰｖ６アドレス体系は 範囲フィールド値に、インタフェースローカル（０ｘ１）、リンクローカル （０ｘ２）、サブネットローカル（０ｘ３）、管理ローカル（０ｘ４）、サ イトローカル（０ｘ５）、組織ローカル（０ｘ８）、グローバル（０ｘＥ） 範囲[11]。 Use of the source address selection algorithm in the presence of multicast destination addresses requires the comparison of a unicast address scope with a multicast address scope. We map unicast link- local to multicast link-local, unicast site-local to multicast site- local, and unicast global scope to multicast global scope. For example, unicast site-local is equal to multicast site-local, which is smaller than multicast organization-local, which is smaller than unicast global, which is equal to multicast global. マルチキャスト宛先アドレスの場合のソースアドレス選択アルゴリズムの使 用は、マルチキャストアドレス範囲とユニキャストアドレス範囲の比較を必 要とします。我々は、リンクローカルマルチキャストにユニキャストリンク ローカルを、サイトローカルマルチキャストにユニキャストサイトローカル を、グローバルマルチキャストにユニキャストグローバルを、マップします。 例えば、ユニキャストサイトローカルは、サイトローカルマルチキャストと 等しく、組織ローカルマルチキャストより小さく、グローバルマルチキャス トと等しいユニキャストグローバルより小さいです。 We write Scope(A) to mean the scope of address A. For example, if A is a link-local unicast address and B is a site-local multicast address, then Scope(A) < Scope(B). 我々はアドレスＡの範囲を意味するためにScope(A)と書きます。例えば、も しＡがリンクローカルユニキャストアドレスで、とＢサイトローカルマルチ キャストアドレスなら、Scope(A) < Scope(B)です。 This mapping implicitly conflates unicast site boundaries and multicast site boundaries [11]. このマッピングは暗黙のうちにユニキャストサイト境界とマルチキャストサ イト境界[11]をまとめます。 3.2. IPv4 Addresses and IPv4-Mapped Addresses 3.2. ＩＰｖ４アドレスとＩＰｖ４マップアドレス The destination address selection algorithm operates on both IPv6 and IPv4 addresses. For this purpose, IPv4 addresses should be represented as IPv4-mapped addresses [1]. For example, to lookup the precedence or other attributes of an IPv4 address in the policy table, lookup the corresponding IPv4-mapped IPv6 address. 宛先アドレス選択アルゴリズムはＩＰｖ６アドレスとＩＰｖ４アドレスの両 方に作用します。この目的のために、ＩＰｖ４アドレスがＩＰｖ４マップア ドレス[1]として描かれるべきです。例えば、ポリシー表でＩＰｖ４アドレス の優先や他の属性を検索するために、対応するＩＰｖ４マップのＩＰｖ６ア ドレスを検索します。 IPv4 addresses are assigned scopes as follows. IPv4 auto- configuration addresses [9], which have the prefix 169.254/16, are assigned link-local scope. IPv4 private addresses [12], which have the prefixes 10/8, 172.16/12, and 192.168/16, are assigned site-local scope. IPv4 loopback addresses [12, section 4.2.2.11], which have the prefix 127/8, are assigned link-local scope (analogously to the treatment of the IPv6 loopback address [11, section 4]). Other IPv4 addresses are assigned global scope. ＩＰｖ４アドレスが次のように範囲を割り当てられます。プレフィックスが 169.254/16のＩＰｖ４自動設定アドレス[9]がリンクローカル範囲を割り当て られます。プレフィックスが10/8か172.16/12か192.168/16のＩＰｖ４プライ ベートアドレス[12]がサイトローカル範囲を割り当てられます。プレフィッ クスが127/8のＩＰｖ４ループバックアドレス[12、４.２.２.１１章]がリン クローカル範囲を割り当てられます（ＩＰｖ６ループバックアドレス[11、４ 章]同様の扱い）。他のＩＰｖ４アドレスがグローバル範囲を割り当てられま す。 IPv4 addresses should be treated as having "preferred" (in the RFC 2462 sense) configuration status. ＩＰｖ４アドレスは設定状態が「好ましい」（ＲＦＣ２４６２の意味で）と 見なされるべきです。 3.3. Other IPv6 Addresses with Embedded IPv4 Addresses 3.3. 他の埋込みＩＰｖ４アドレスを持つＩＰｖ６アドレス IPv4-compatible addresses [1], IPv4-mapped [1], IPv4-translatable [6] and 6to4 addresses [5] contain an embedded IPv4 address. For the purposes of this document, these addresses should be treated as having global scope. ＩＰｖ４互換アドレス[1]とＩＰｖ４マップアドレス[1]とＩＰｖ４翻訳可能 アドレス[6]と６to４アドレス[5]は埋め込みのＩＰｖ４アドレスを含んでい ます。この文書の目的で、これらのアドレスは世界的な範囲を持っていると 見なされるべきです。 IPv4-compatible, IPv4-mapped, and IPv4-translatable addresses should be treated as having "preferred" (in the RFC 2462 sense) configuration status. ＩＰｖ４互換アドレスとＩＰｖ４マップアドレスとＩＰｖ４翻訳可能アドレ スが、（ＲＦＣ２４６２の意味で）設定状態が「好ましい」と扱われるべき です。 3.4. IPv6 Loopback Address and Other Format Prefixes 3.4. ＩＰｖ６ループバックアドレスと他のフォーマットプレフィックス The loopback address should be treated as having link-local scope [11, section 4] and "preferred" (in the RFC 2462 sense) configuration status. ループバックアドレスは、設定状態で、リンクローカル範囲で[11、４章]、 （ＲＦＣ２４６２の意味で）「好ましい」と扱うべきです。 NSAP addresses and other addresses with as-yet-undefined format prefixes should be treated as having global scope and "preferred" (in the RFC 2462) configuration status. Later standards may supersede this treatment. ＮＳＡＰアドレスや、他のまだ未定義のフォーマットプレフィックスのアド レスは、設定状態で、グローバル範囲で、（ＲＦＣ２４６２の意味で）「好 ましい」と扱うべきです。後に標準がこの扱いを変えるかもしれません。 3.5. Mobility Addresses 3.5. 移動アドレス Some nodes may support mobility using the concepts of a home address and a care-of address (for example see [8]). Conceptually, a home address is an IP address assigned to a mobile node and used as the permanent address of the mobile node. A care-of address is an IP address associated with a mobile node while visiting a foreign link. When a mobile node is on its home link, it may have an address that is simultaneously a home address and a care-of address. あるノードがホームアドレスと立ち寄りアドレスの概念を使う移動をサポー トするかもしれません（例えば[8]参照）。概念的に、ホームアドレスが移動 ノードに割り当てられた、移動ノードの永久アドレスとして用いられるＩＰ アドレスです。立ち寄りアドレスが、外のリンクを訪問してる間に、移動ノー ドと結び付けられるＩＰアドレスです。移動ノードがホームリンク上にある 時、ホームアドレス兼立ち寄りアドレスのアドレスを持っているかもしれま せん。 For the purposes of this document, it is sufficient to know whether or not one's own addresses are designated as home addresses or care- of addresses. Whether or not an address should be designated a home address or care-of address is outside the scope of this document. この文書の目的で、自分の自身のアドレスがホームアドレスか立ち寄りアド レスかを知っていれば十分です。アドレスがホームアドレスと指定されるか、 立ち寄りアドレスに指定されるかは、この文書の範囲の外です。 4. Candidate Source Addresses 4. 候補ソースアドレス The source address selection algorithm uses the concept of a "candidate set" of potential source addresses for a given destination address. The candidate set is the set of all addresses that could be used as a source address; the source address selection algorithm will pick an address out of that set. We write CandidateSource(A) to denote the candidate set for the address A. ソースアドレス選択アルゴリズムは、与えられた宛先アドレスについて、ソー スアドレスの可能性がある「候補集合」の概念を使います。候補集合はソー スアドレスとして用いられることができるすべてのアドレスの集合です；ソー スアドレス選択アルゴリズムはその集合からアドレスを選ぶでしょう。我々 はアドレスＡの候補アドレスの集合を示すためにCandidateSource(A)と書き ます。 It is RECOMMENDED that the candidate source addresses be the set of unicast addresses assigned to the interface that will be used to send to the destination. (The "outgoing" interface.) On routers, the candidate set MAY include unicast addresses assigned to any interface that forwards packets, subject to the restrictions described below. 候補ソースアドレスが、宛先に送信するために使うであろうインタフェース に割り当てられたユニキャストアドレスの集合であることは勧められます (RECOMMENDED)。（「外向」インタフェース。）ルータの候補集合が、下記 の制限を除き、パケットを転送をするインターフェースに割当てられたユニ キャストアドレスをふくみます(MAY)。 Discussion: The Neighbor Discovery Redirect mechanism [14] requires that routers verify that the source address of a packet identifies a neighbor before generating a Redirect, so it is advantageous for hosts to choose source addresses assigned to the outgoing interface. Implementations that wish to support the use of global source addresses assigned to a loopback interface should behave as if the loopback interface originates and forwards the packet. 議論：近隣探索リダイレクト機構[14]はルータがパケットのソースアドレ スにリダイレクトを送る前に近隣の識別を確認することを要求します、そ れでホストが外向インタフェースに割り当てられたソースアドレスを選択 することは有利です。ループバックインタフェースに割り当てられてグロー バルソースアドレスの使用をサポートすることを望む実装は、ループバッ クインタフェースから来たパケットを転送するかのように振る舞うべきで す。 In some cases the destination address may be qualified with a zone index or other information that will constrain the candidate set. ある場合には宛先アドレスはゾーンインデックスや候補集合を制限する他の 情報の条件付きであるかもしれません。 For multicast and link-local destination addresses, the set of candidate source addresses MUST only include addresses assigned to interfaces belonging to the same link as the outgoing interface. マルチキャストとリンクローカル宛先アドレスのために、候補ソースアドレ ス集合は外向インタフェースと同じリンクに属しているインタフェースに割 り当てられたアドレスだけを含まなければなりません(MUST)。 Discussion: The restriction for multicast destination addresses is necessary because currently-deployed multicast forwarding algorithms use Reverse Path Forwarding (RPF) checks. 論議：マルチキャスト宛先アドレスの制限は、現在配置されたマルチ キャスト転送アルゴリズムが逆パス転送（ＲＰＦ）点検を使うから、必 要です。 For site-local destination addresses, the set of candidate source addresses MUST only include addresses assigned to interfaces belonging to the same site as the outgoing interface. サイトローカル宛先アドレスのための、候補ソースアドレス集合は外向イン タフェースと同じサイトに属しているインタフェースに割り当てられたアド レスだけを含まなければなりません。 In any case, anycast addresses, multicast addresses, and the unspecified address MUST NOT be included in a candidate set. いずれの場合も、エニキャストアドレスと、マルチキャストアドレスと、特 定されていないアドレスは候補集合に含められてはなりません(MUST NOT)。 If an application or upper-layer specifies a source address that is not in the candidate set for the destination, then the network layer MUST treat this as an error. The specified source address may influence the candidate set, by affecting the choice of outgoing interface. If the application or upper-layer specifies a source address that is in the candidate set for the destination, then the network layer MUST respect that choice. If the application or upper-layer does not specify a source address, then the network layer uses the source address selection algorithm specified in the next section. もしアプリケーションあるいは上位レイヤが宛先の候補集合にないソースア ドレスを指定するなら、ネットワーク層はこれをエラーと扱わなくてはなり ません。指定されたソースアドレスは、外向インタフェースの選択に影響を 与えることで、候補セットに影響を与えるかもしれません。もしアプリケー ションあるいは上位レイヤが宛先の候補集合にあるソースアドレスを指定す るなら、ネットワーク層はその選択を尊重しなくてはなりません。もしアプ リケーションあるいは上位レイヤがソースアドレスを指定しないなら、ネッ トワーク層は次章で指定するソースアドレス選択アルゴリズムを使います。 On IPv6-only nodes that support SIIT [6, especially section 5], if the destination address is an IPv4-mapped address then the candidate set MUST contain only IPv4-translatable addresses. If the destination address is not an IPv4-mapped address, then the candidate set MUST NOT contain IPv4-translatable addresses. ＳＩＩＴ[6、特に５章］をサポートするＩＰｖ６のみのノードの上で、もし 宛先アドレスがＩＰｖ４マップアドレスであるなら、候補セットはただＩＰ ｖ４翻訳可能アドレスだけを含んでいなくてはなりません(MUST)。もし宛先 アドレスがＩＰｖ４マップアドレスではないなら、候補セットはＩＰｖ４翻 訳可能アドレスを含んでいてはなりません(MUST NOT)。 5. Source Address Selection 5. ソースアドレス選択 The source address selection algorithm produces as output a single source address for use with a given destination address. This algorithm only applies to IPv6 destination addresses, not IPv4 addresses. ソースアドレス選択アルゴリズムは与えられた宛先アドレスで使用するソー スアドレスを１つだけ出力します。このアルゴリズムは、ＩＰｖ４アドレス ではなく、ＩＰｖ６宛先アドレスに当てはまるだけです。 The algorithm is specified here in terms of a list of pair-wise comparison rules that (for a given destination address D) imposes a "greater than" ordering on the addresses in the candidate set CandidateSource(D). The address at the front of the list after the algorithm completes is the one the algorithm selects. ここで指定するアルゴリズムは対語との比較規則のリストに関していて、 （与えられた宛先アドレスＤに対して）に候補集合CandidateSource(D)のア ドレスを「大きい」順に並べます。アルゴリズムが終わった後のリストの最 初のアドレスがアルゴリズムが選択するものです。 Note that conceptually, a sort of the candidate set is being performed, where a set of rules define the ordering among addresses. But because the output of the algorithm is a single source address, an implementation need not actually sort the set; it need only identify the "maximum" value that ends up at the front of the sorted list. 概念的に、規則集合がアドレス間の順序を定義し、候補集合のソートが行わ れる事に注意してください。けれどもアルゴリズムの出力がソースアドレス の１つだけなので、実装が実際に集合をソートする必要がありません；ただ ソートの最後にリストの最初にあらわれる「最大値」を識別することが必要 なだけです。 The ordering of the addresses in the candidate set is defined by a list of eight pair-wise comparison rules, with each rule placing a "greater than," "less than" or "equal to" ordering on two source addresses with respect to each other (and that rule). In the case that a given rule produces a tie, i.e., provides an "equal to" result for the two addresses, the remaining rules are applied (in order) to just those addresses that are tied to break the tie. Note that if a rule produces a single clear "winner" (or set of "winners" in the case of ties), those addresses not in the winning set can be discarded from further consideration, with subsequent rules applied only to the remaining addresses. If the eight rules fail to choose a single address, some unspecified tie-breaker should be used. 候補集合でのアドレスの順序は、８つの対毎の規則で定義され、各規則は各 ソースアドレス対に「大きい」「小さい」「等しい」の順序をつけます。与 えられた規則が２つのアドレスに対して引き分け、つまり「等しい」結果を 生成する場合、残りの規則が（順に）引き分けでなくなるまで適用されます。 もし規則がひとつの明確な「勝者」を作り出すなら（あるいは引き分けの場 合は複数の「勝者」）、勝者でないアドレスが以降の検討では捨てられ、残 留アドレスにだけ次の規則が適用される事に注意してください。もし８つの 規則がひとつのアドレスを選択し損ねるなら、ここで指定しないなんらかの 選択が使われます。 When comparing two addresses SA and SB from the candidate set, we say "prefer SA" to mean that SA is "greater than" SB, and similarly we say "prefer SB" to mean that SA is "less than" SB. 候補集合の２つのアドレスＳＡとＳＢを比較する際に、我々は「ＳＡが優先」 をＳＡがＳＢより「大きい」の意味で使い、同様に「ＳＢが優先」をＳＡが ＳＢより「小さい」の意味で使います。 Rule 1: Prefer same address. If SA = D, then prefer SA. Similarly, if SB = D, then prefer SB. 規則１：同じアドレスが優先。 もしＳＡ＝Ｄなら、ＳＡが優先で、同様にＳＢ＝ＤならＳＢが優先です。 Rule 2: Prefer appropriate scope. If Scope(SA) < Scope(SB): If Scope(SA) < Scope(D), then prefer SB and otherwise prefer SA. Similarly, if Scope(SB) < Scope(SA): If Scope(SB) < Scope(D), then prefer SA and otherwise prefer SB. 規則２：適切範囲が優先。 もしScope(SA)＜Scope(SB)なら：もしScope(SA)＜Scope(D)なら、ＳＢが優先 で、そうでなければＳＡが優先です。同様に、もし範囲Scope(SB)＜Scope(SA) なら：もしScope(SB)＜Scope(D)なら、ＳＡが優先で、さもなければＳＢが優 先です。 Rule 3: Avoid deprecated addresses. The addresses SA and SB have the same scope. If one of the two source addresses is "preferred" and one of them is "deprecated" (in the RFC 2462 sense), then prefer the one that is "preferred." 規則３：抑制アドレスを避ける。 アドレスＳＡとＳＢは同じ範囲です。（ＲＦＣ２４６２の意味で）もし２つ のソースアドレスのうち１つが「好ましい」くもう１つが「抑制」なら、 「好ましい」方が優先です。 Rule 4: Prefer home addresses. If SA is simultaneously a home address and care-of address and SB is not, then prefer SA. Similarly, if SB is simultaneously a home address and care-of address and SA is not, then prefer SB. If SA is just a home address and SB is just a care-of address, then prefer SA. Similarly, if SB is just a home address and SA is just a care-of address, then prefer SB. 規則４：ホームアドレスが優先。 もしＳＡがホームアドレス兼立ち寄りアドレスで、ＳＢがそうではないなら、 ＳＡが優先です。同様に、もしＳＢがホームアドレス兼立ち寄りアドレスで、 ＳＡがそうではないなら、ＳＢが優先です。もしＳＡがホームアドレスで、 ＳＢが立ち寄りアドレスであるなら、ＳＡが優先です。同様に、もしＳＢが ホームアドレスで、ＳＡが立ち寄りアドレスであるなら、ＳＢが優先です。 Implementations should provide a mechanism allowing an application to reverse the sense of this preference and prefer care-of addresses over home addresses (e.g., via appropriate API extensions). Use of the mechanism should only affect the selection rules for the invoking application. アプリケーションがこの優先性の意味を反転し、ホームアドレスより立ち寄 りアドレスを優先とするのを可能するメカニズム（例えば、適切なＡＰＩ拡 張）を、実装が供給するべきです。メカニズムを使用する事がただそのアプ リケーションの選択規則に影響を与えるだけであるべきです。 Rule 5: Prefer outgoing interface. If SA is assigned to the interface that will be used to send to D and SB is assigned to a different interface, then prefer SA. Similarly, if SB is assigned to the interface that will be used to send to D and SA is assigned to a different interface, then prefer SB. 規則５：外向インタフェースが優先。 もしＳＡがＤに送信するために使われるインタフェースに割り当てられ、Ｓ Ｂが異なるインタフェースに割り当てられるなら、ＳＡが優先です。同様に、 もしＳＢがＤに送信するために使われるインタフェースに割り当てられ、Ｓ Ａが異なるインタフェースに割り当てられるなら、ＳＢが優先です。 Rule 6: Prefer matching label. If Label(SA) = Label(D) and Label(SB) <> Label(D), then prefer SA. Similarly, if Label(SB) = Label(D) and Label(SA) <> Label(D), then prefer SB. 規則６：ラベルの一致が優先。 もしLabel(SA)＝Label(D)かつLabel(SB)≠Label(D)ならＳＡが優先です。同 様に、もしLabel(SB)＝Label(D)かつLabel(SA)≠Label(D)ならＳＡが優先で す。 Rule 7: Prefer public addresses. If SA is a public address and SB is a temporary address, then prefer SA. Similarly, if SB is a public address and SA is a temporary address, then prefer SB. 規則７：公共アドレスが優先。 もしＳＡが公共アドレスで、ＳＢが一時的なアドレスであるなら、ＳＡが優 先です。同様に、もしＳＢが公共アドレスで、ＳＡが一時的なアドレスであ るなら、ＳＢが優先です。 Implementations MUST provide a mechanism allowing an application to reverse the sense of this preference and prefer temporary addresses over public addresses (e.g., via appropriate API extensions). Use of the mechanism should only affect the selection rules for the invoking application. This rule avoids applications potentially failing due to the relatively short lifetime of temporary addresses or due to the possibility of the reverse lookup of a temporary address either failing or returning a randomized name. Implementations for which privacy considerations outweigh these application compatibility concerns MAY reverse the sense of this rule and by default prefer temporary addresses over public addresses. アプリケーションがこの優先性の意味を反転し、公共アドレスより一時的ア ドレスを優先する事を可能にするメカニズム（例えば、適切な ＡＰＩ拡張 で）を、実装が供給しなくてはなりません(MUST)。メカニズムの使用がただ そのアプリケーションの選択規則に影響を与えるだけであるべきです。この 規則は一時的アドレスの比較的短い寿命による失敗や、一時的なアドレスの 逆検索が失敗するかランダムな名前を返す可能性による、潜在的なアプリケー ションの失敗を避けます。アプリケーション互換性懸念よりもプライバシー の考慮が重要な実装が、この規則の意味を反転し、デフォルトで公共アドレ スより一時的アドレスを優先するかもしれません(MAY)。 Rule 8: Use longest matching prefix. If CommonPrefixLen(SA, D) > CommonPrefixLen(SB, D), then prefer SA. Similarly, if CommonPrefixLen(SB, D) > CommonPrefixLen(SA, D), then prefer SB. 規則８：最長一致プレフィックスの使用。 もしCommonPrefixLen(SA, D) > CommonPrefixLen(SB, D)なら、ＳＡが優先で す。同様に、もしCommonPrefixLen(SB, D) > CommonPrefixLen(SA, D)なら、 ＳＢが優先です。 Rule 8 may be superseded if the implementation has other means of choosing among source addresses. For example, if the implementation somehow knows which source address will result in the "best" communications performance. 規則８は、もし実装がソースアドレス選択の他の手段を持っているなら、置 き換えられるかもしれません。例えば、もし実装がどのソースアドレスが 「最も良い」通信性能をもたらすか知っているなら、です。 Rule 2 (prefer appropriate scope) MUST be implemented and given high priority because it can affect interoperability. 規則２が（適切な範囲が優先）は相互運用性に影響を与えるから、実装され、 高い優先権を与えられなくてはなりません(MUST)。 6. Destination Address Selection 6. 宛先アドレス選択 The destination address selection algorithm takes a list of destination addresses and sorts the addresses to produce a new list. It is specified here in terms of the pair-wise comparison of addresses DA and DB, where DA appears before DB in the original list. 宛先アドレス選択アルゴリズムは宛先アドレスのリストを得て、そして新し いリストを作り出すためにアドレスをソートします。ここで指定されるもの は、元のリストでＤＡがＤＢより前にあるような、アドレスＤＡとＤＢの対 の比較に関して指定されます。 The algorithm sorts together both IPv6 and IPv4 addresses. To find the attributes of an IPv4 address in the policy table, the IPv4 address should be represented as an IPv4-mapped address. アルゴリズムはＩＰｖ４アドレスとＩＰｖ４アドレスの両方を一緒にソート します。ポリシー表でＩＰｖ４アドレスの属性を見いだすために、ＩＰｖ４ アドレスはＩＰｖ４マップアドレスとして描かれるべきです。 We write Source(D) to indicate the selected source address for a destination D. For IPv6 addresses, the previous section specifies the source address selection algorithm. Source address selection for IPv4 addresses is not specified in this document. 我々は宛先Ｄのために選択されたソースアドレスを示すためにSource(D)と書 きます。ＩＰｖ６アドレスに対して、前の章のソースアドレス選択アルゴリ ズムを指定します。ＩＰｖ４アドレスに対して、ソースアドレス選択がこの 文書で指定されません。 We say that Source(D) is undefined if there is no source address available for destination D. For IPv6 addresses, this is only the case if CandidateSource(D) is the empty set. 我々は、もし宛先Ｄのために利用可能な情報源アドレスがないなら、 Source(D)は不確定であると言います。ＩＰｖ６アドレスに対して、これは CandidateSource(D)が空集合の場合だけです。 The pair-wise comparison of destination addresses consists of ten rules, which should be applied in order. If a rule determines a result, then the remaining rules are not relevant and should be ignored. Subsequent rules act as tie-breakers for earlier rules. See the previous section for a lengthier description of how pair-wise comparison tie-breaker rules can be used to sort a list. 先アドレスの対毎の比較は１０の規則から成り立ち、そしてこれは順番に適 用されるべきです。もし規則が結果を決定するなら、残りの規則は適切でな く、無視されるべきです。次の規則が以前の規則の引き分けの役を務めます。 対毎の比較の引き分け規則がリストをソートするために使われることができ る方法のより長い記述のために前の章を見てください。 Rule 1: Avoid unusable destinations. If DB is known to be unreachable or if Source(DB) is undefined, then prefer DA. Similarly, if DA is known to be unreachable or if Source(DA) is undefined, then prefer DB. 規則１：使用できない宛先を避ける。 もしＤＢが到達不可能であることを知られていているか、Source(DB)が不確 定であるなら、ＤＡが優先です。同様に、もしＤＡが到達不可能であること を知られていているか、Source(DA)が不確定であるなら、ＤBが優先です。 Discussion: An implementation may know that a particular destination is unreachable in several ways. For example, the destination may be reached through a network interface that is currently unplugged. For example, the implementation may retain for some period of time information from Neighbor Unreachability Detection [14]. In any case, the determination of unreachability for the purposes of this rule is implementation-dependent. 論議：実装が特定の宛先がいくつかの意味で到達不可能であることを知っ ているかもしれません。例えば、宛先は現在止まっているネットワークイ ンタフェースを通って届くかもしれません。例えば、実装はいずれかの一 定の期間、近隣非接続発見[14]からの情報を維持するかもしれません。ど んな場合でも、この規則の目的に関する到達不能の決定は実装に依存しま す。 Rule 2: Prefer matching scope. If Scope(DA) = Scope(Source(DA)) and Scope(DB) <> Scope(Source(DB)), then prefer DA. Similarly, if Scope(DA) <> Scope(Source(DA)) and Scope(DB) = Scope(Source(DB)), then prefer DB. 規則２：範囲の一致が優先。 もしScope(DA)＝Scope(Source(DA))かつScope(DB)≠Scope(Source(DB))なら、 ＤＡが優先です。同様に、もしScope(DA)≠Scope(Source(DA))かつ Scope(DB)＝Scope(Source(DB))なら、ＤＢが優先です。 Rule 3: Avoid deprecated addresses. If Source(DA) is deprecated and Source(DB) is not, then prefer DB. Similarly, if Source(DA) is not deprecated and Source(DB) is deprecated, then prefer DA. 規則３：抑制アドレスを避ける。 もしSource(DA)が抑制でSource(DB)がそうではないなら、DBが優先です。 同様に、もしSource(DA)が望ましくないのではなくSource(DB)が抑制なら、 ＤＡが優先です。 Rule 4: Prefer home addresses. If Source(DA) is simultaneously a home address and care-of address and Source(DB) is not, then prefer DA. Similarly, if Source(DB) is simultaneously a home address and care-of address and Source(DA) is not, then prefer DB. 規則４：ホームアドレスの優先。 もしSource(DA)が同時にホームアドレスと立ち寄りアドレスであり、 Source(DB)がそうではないなら、ＤＡが優先です。同様に、もしSource(DB) が同時にホームアドレスと立ち寄りアドレスで、Source(DA)がそうでないな ら、ＤＢが優先です。 If Source(DA) is just a home address and Source(DB) is just a care-of address, then prefer DA. Similarly, if Source(DA) is just a care-of address and Source(DB) is just a home address, then prefer DB. もし Source(DA)がホームアドレスで、そしてSource(DB)が立ち寄りアドレス であるなら、ＤＡが優先です。同様に、もしSource(DA)が立ち寄りアドレス で、そしてSource(DB)がホームアドレスであるなら、ＤＢが優先です。 Rule 5: Prefer matching label. If Label(Source(DA)) = Label(DA) and Label(Source(DB)) <> Label(DB), then prefer DA. Similarly, if Label(Source(DA)) <> Label(DA) and Label(Source(DB)) = Label(DB), then prefer DB. 規則５：ラベルにの一致の優先。 もしLabel(Source(DA))＝Label(DA)かつLabel(Source(DB))≠Label(DB)なら、 ＤＡが優先です。同様に、もしLabel(Source(DA))≠Label(DA)かつ Label(Source(DB))＝Label(DB)なら、ＤＢが優先です。 Rule 6: Prefer higher precedence. If Precedence(DA) > Precedence(DB), then prefer DA. Similarly, if Precedence(DA) < Precedence(DB), then prefer DB. 規則６：優先度の高いほうが優先。 もしPrecedence(DA)＞Precedence(DB)なら、ＤＡが優先です。同様に、もし Precedence(DA)＜Precedence(DB)なら、ＤＢが優先です。 Rule 7: Prefer native transport. If DA is reached via an encapsulating transition mechanism (e.g., IPv6 in IPv4) and DB is not, then prefer DB. Similarly, if DB is reached via encapsulation and DA is not, then prefer DA. 規則７：自然な転送の方が優先。 もしＤＡがカプセル化移行メカニズムによって到達し（例えば、ＩＰｖ４内 のＩＰｖ６）、ＤＢがそうではないなら、ＤＢが優先です。同様に、もしＤ Ｂがカプセル化によって到達し、ＤＡがそうでないなら、ＤＡが優先です。 Discussion: 6-over-4 [15], ISATAP [16], and configured tunnels [17] are examples of encapsulating transition mechanisms for which the destination address does not have a specific prefix and hence can not be assigned a lower precedence in the policy table. An implementation MAY generalize this rule by using a concept of interface preference, and giving virtual interfaces (like the IPv6-in-IPv4 encapsulating interfaces) a lower preference than native interfaces (like ethernet interfaces). 論議：６over４[15]とISATAP[16]と配置されたトンネル[16]は宛先アドレ スが特定のプレフィックスを持たないカプセル化以降メカニズムの例で、 それ故ポリシー表でより低い優先度を割り当てることができません。実装 がインタフェース優先性の概念を使い、そして仮想インターフェース （IPv6-in-IPv4カプセル化インタフェースなど）に本来のインターフェー ス（イーサネットインタフェースなど）より低い優先性を与えることでこ の規則を一般化するかもしれません(MAY)。 Rule 8: Prefer smaller scope. If Scope(DA) < Scope(DB), then prefer DA. Similarly, if Scope(DA) > Scope(DB), then prefer DB. 規則８：より小さい範囲が優先。 もしScope(DA)＜Scope(DB)なら、ＤＡが優先です。同様に、もし Scope(DA)＞Scope(DB)なら、ＤＢが優先です。 Rule 9: Use longest matching prefix. When DA and DB belong to the same address family (both are IPv6 or both are IPv4): If CommonPrefixLen(DA, Source(DA)) > CommonPrefixLen(DB, Source(DB)), then prefer DA. Similarly, if CommonPrefixLen(DA, Source(DA)) < CommonPrefixLen(DB, Source(DB)), then prefer DB. 規則９：最長一致プレフィックスの使用。 もしＤＡとＤＢが同じアドレスファミリーに属する場合（共にＩＰｖ６であ るか、共にＩＰｖ４の場合）：もしCommonPrefixLen(DA, Source(DA))＞ CommonPrefixLen(DB, Source(DB))ならＤＡが優先です。同様に、もし CommonPrefixLen(DA, Source(DA))＜CommonPrefixLen(DB, Source(DB))なら、 ＤＢが優先です。 Rule 10: Otherwise, leave the order unchanged. If DA preceded DB in the original list, prefer DA. Otherwise prefer DB. 規則１０：さもなければ、順序を変えない。 もしＤＡが元のリストでＤＢより先にあるなら、ＤＡの方が優先です。さも なければＤＢが優先です。 Rules 9 and 10 may be superseded if the implementation has other means of sorting destination addresses. For example, if the implementation somehow knows which destination addresses will result in the "best" communications performance. もし実装が宛先アドレスのソートの他の手段を持っているなら、規則９と １０が置き換えられるかもしれません。例えば、もし実装がどうにかしてい ずれかの宛先アドレスが「最も良い」通信能力をもたらすと知っている場合 です。 7. Interactions with Routing 7. ルーティングの相互作用 This specification of source address selection assumes that routing (more precisely, selecting an outgoing interface on a node with multiple interfaces) is done before source address selection. However, implementations may use source address considerations as a tiebreaker when choosing among otherwise equivalent routes. このソースアドレス選択の仕様はルーティング（より正確には、ノード上の 多数のインタフェースから外向インタフェースの選択）がソースアドレス選 択の前にされると想定します。しかしながら、実装が同等な経路の間で選択 をする時、ソースアドレスの考慮を引き分けを避けるのに用いるかもしれま せん。 For example, suppose a node has interfaces on two different links, with both links having a working default router. Both of the interfaces have preferred (in the RFC 2462 sense) global addresses. When sending to a global destination address, if there's no routing reason to prefer one interface over the other, then an implementation may preferentially choose the outgoing interface that will allow it to use the source address that shares a longer common prefix with the destination. 例えば、ノードが２つの異なったリンクのインタフェースを持ち、両方のリ ンクが動作しているデフォルトルータを持つと考えてください。インタフェー スの両方が（ＲＦＣ２４６２の意味で）好ましいグローバルアドレスを持ち ます。グローバル宛先アドレスに送信するとき、もし他より１つのインタフェー スの方が優先となるルーティング上の理由がないなら、実装が宛先とより長 い共通プレフィックスを共有するソースアドレスが使える外向インタフェー スを優先的に選択するかもしれません。 Implementations may also use the choice of router to influence the choice of source address. For example, suppose a host is on a link with two routers. One router is advertising a global prefix A and the other router is advertising global prefix B. Then when sending via the first router, the host may prefer source addresses with prefix A and when sending via the second router, prefer source addresses with prefix B. 実装が同じくルータのソースアドレスの選択に影響を与える選択を使うかも しれません。例えば、ホストが２つのルータのあるリンク上にあると考えて ください。１つのルータがグローバルなプレフィックスＡを広告し、他のルー タはグローバルなプレフィックスＢを広告しています。最初のルータを通し て送信する時、ホストはプレフィックスＡのソースアドレスが優先で、そし て２番目のルータによって送信する時、プレフィックスＢのソースアドレス の方が優先であるかもしれません。 8. Implementation Considerations 8. 実装の考察 The destination address selection algorithm needs information about potential source addresses. One possible implementation strategy is for getaddrinfo() to call down to the network layer with a list of destination addresses, sort the list in the network layer with full current knowledge of available source addresses, and return the sorted list to getaddrinfo(). This is simple and gives the best results but it introduces the overhead of another system call. One way to reduce this overhead is to cache the sorted address list in the resolver, so that subsequent calls for the same name do not need to resort the list. 宛先アドレス選択アルゴリズムは可能性があるソースアドレスについての情 報を必要とします。１つの可能なgetaddrinfo()の実装戦略は、宛先アドレス リストと共にネットワーク層を呼び出し、ネットワーク層で利用可能なソー スアドレスの現在の完全な知識でリストをソートし、ソート済みのリストを getaddrinfo()に返すことです。これは単純で最も良い結果を返しますが、他 のシステムコールのオーバーヘッドを導入します。このオーバーヘッドを減 らす一つの方法がリゾルバでソートされたアドレスリストをキャッシュする 事で、それで同じ名前に対する次の要求で再度ソートする必要がありません。 Another implementation strategy is to call down to the network layer to retrieve source address information and then sort the list of addresses directly in the context of getaddrinfo(). To reduce overhead in this approach, the source address information can be cached, amortizing the overhead of retrieving it across multiple calls to getaddrinfo(). In this approach, the implementation may not have knowledge of the outgoing interface for each destination, so it MAY use a looser definition of the candidate set during destination address ordering. 他の実装戦略はソースアドレス情報を得るためにネットワーク層を呼び出し、 getaddrinfo()の環境で直接アドレスリストをソートする事です。この方法で のオーバーヘッドを減らすために、getaddrinfo()への多数の呼び出しのオー バーヘッドを減らすように、ソースアドレス情報をキャッシュできます。こ の方法で、実装はそれぞれの宛先の外向インタフェースの知識を持たないか もしれません、それで宛先アドレス順序付けの間の候補集合の緩い定義を使 うかもしれません(MAY)。 In any case, if the implementation uses cached and possibly stale information in its implementation of destination address selection, or if the ordering of a cached list of destination addresses is possibly stale, then it should ensure that the destination address ordering returned to the application is no more than one second out of date. For example, an implementation might make a system call to check if any routing table entries or source address assignments that might affect these algorithms have changed. Another strategy is to use an invalidation counter that is incremented whenever any underlying state is changed. By caching the current invalidation counter value with derived state and then later comparing against the current value, the implementation could detect if the derived state is potentially stale. どんな場合でも、もし実装が宛先アドレス選択の実装でキャッシュと多分古 い情報を使うなら、あるいはもし宛先アドレスのリストのキャッシュの順序 が古いなら、アプリケーションに渡す宛先アドレスの順序は１秒以上時代遅 れでないことを保障すべきです。例えば、実装が、アルゴリズムに影響を与 える可能性のある、経路表項目やソースアドレス割当ての変化があったかど うかを調べる、システムコールをするかもしれません。もう１つの戦略は、 基礎をなす状態が変わる時に常に増加する無効化カウンターを使う事です。 引き出された状態と共に現在の無効化カウンター値をキャッシュする事で、 そして後で現在の値と比較することで、実装は得られる状態が潜在的に古い かどうか検出できます。 9. Security Considerations 9. セキュリティの考察 This document has no direct impact on Internet infrastructure security. この文書はインターネット基盤のセキュリティに直接の影響を持ちません。 Note that most source address selection algorithms, including the one specified in this document, expose a potential privacy concern. An unfriendly node can infer correlations among a target node's addresses by probing the target node with request packets that force the target host to choose its source address for the reply packets. (Perhaps because the request packets are sent to an anycast or multicast address, or perhaps the upper-layer protocol chosen for the attack does not specify a particular source address for its reply packets.) By using different addresses for itself, the unfriendly node can cause the target node to expose the target's own addresses. たいていのソースアドレス選択アルゴリズムが、この文書で指定されたもの を含めて、プライバシの懸念の可能性があることに注意してください。非友 好的なノードが応答パケットで目標ホストのソースアドレス選択を強いるリ クエストパケットを送って目標ノードを探ることで、目標ノードのアドレス 間の相互関係を推論することができます。（多分要求パケットがエニキャス トあるいはマルチキャストアドレスに送られるから、あるいは多分攻撃のた めに選ばれた上位レイヤプロトコルがその答えパケットに特定のソースアド レスを指定しないから。）非友好的ノードは自己の異なるアドレスを使うこ とによって、目標ノードに目標ノードのアドレスをさらけさせることができ ます。 10. Examples 10. 例 This section contains a number of examples, first of default behavior and then demonstrating the utility of policy table configuration. These examples are provided for illustrative purposes; they should not be construed as normative. この章は多くの有益な例、最初にデフォルト行動、そして次に政策表設定、 を含んでいます。これらの例は説明的な目的に提供されます；これらは標準 と解釈されるべきではありません。 10.1. Default Source Address Selection 10.1. デフォルトソースアドレス選択 The source address selection rules, in conjunction with the default policy table, produce the following behavior: ソースアドレス選択規則は、デフォルトポリシー表と関連して、次の行動を 引き起こします： Destination: 2001::1 Candidate Source Addresses: 3ffe::1 or fe80::1 Result: 3ffe::1 (prefer appropriate scope) Destination: 2001::1 Candidate Source Addresses: fe80::1 or fec0::1 Result: fec0::1 (prefer appropriate scope) Destination: fec0::1 Candidate Source Addresses: fe80::1 or 2001::1 Result: 2001::1 (prefer appropriate scope) Destination: ff05::1 Candidate Source Addresses: fe80::1 or fec0::1 or 2001::1 Result: fec0::1 (prefer appropriate scope) Destination: 2001::1 Candidate Source Addresses: 2001::1 (deprecated) or 2002::1 Result: 2001::1 (prefer same address) Destination: fec0::1 Candidate Source Addresses: fec0::2 (deprecated) or 2001::1 Result: fec0::2 (prefer appropriate scope) Destination: 2001::1 Candidate Source Addresses: 2001::2 or 3ffe::2 Result: 2001::2 (longest-matching-prefix) Destination: 2001::1 Candidate Source Addresses: 2001::2 (care-of address) or 3ffe::2 (home address) Result: 3ffe::2 (prefer home address) Destination: 2002:836b:2179::1 Candidate Source Addresses: 2002:836b:2179::d5e3:7953:13eb:22e8 (temporary) or 2001::2 Result: 2002:836b:2179::d5e3:7953:13eb:22e8 (prefer matching label) Destination: 2001::d5e3:0:0:1 Candidate Source Addresses: 2001::2 or 2001::d5e3:7953:13eb:22e8 (temporary) Result: 2001::2 (prefer public address) 10.2. Default Destination Address Selection 10.2. デフォルト宛先アドレス選択 The destination address selection rules, in conjunction with the default policy table and the source address selection rules, produce the following behavior: 宛先アドレス選択規則は、デフォルトポリシー表とソースアドレス選択規則 と関連して、次の行動を引き起こします： Candidate Source Addresses: 2001::2 or fe80::1 or 169.254.13.78 Destination Address List: 2001::1 or 131.107.65.121 Result: 2001::1 (src 2001::2) then 131.107.65.121 (src 169.254.13.78) (prefer matching scope) Candidate Source Addresses: fe80::1 or 131.107.65.117 Destination Address List: 2001::1 or 131.107.65.121 Result: 131.107.65.121 (src 131.107.65.117) then 2001::1 (src fe80::1) (prefer matching scope) Candidate Source Addresses: 2001::2 or fe80::1 or 10.1.2.4 Destination Address List: 2001::1 or 10.1.2.3 Result: 2001::1 (src 2001::2) then 10.1.2.3 (src 10.1.2.4) (prefer higher precedence) Candidate Source Addresses: 2001::2 or fec0::2 or fe80::2 Destination Address List: 2001::1 or fec0::1 or fe80::1 Result: fe80::1 (src fe80::2) then fec0::1 (src fec0::2) then 2001::1 (src 2001::2) (prefer smaller scope) Candidate Source Addresses: 2001::2 (care-of address) or 3ffe::1 (home address) or fec0::2 (care-of address) or fe80::2 (care-of address) Destination Address List: 2001::1 or fec0::1 Result: 2001:1 (src 3ffe::1) then fec0::1 (src fec0::2) (prefer home address) Candidate Source Addresses: 2001::2 or fec0::2 (deprecated) or fe80::2 Destination Address List: 2001::1 or fec0::1 Result: 2001::1 (src 2001::2) then fec0::1 (src fec0::2) (avoid deprecated addresses) Candidate Source Addresses: 2001::2 or 3f44::2 or fe80::2 Destination Address List: 2001::1 or 3ffe::1 Result: 2001::1 (src 2001::2) then 3ffe::1 (src 3f44::2) (longest matching prefix) Candidate Source Addresses: 2002:836b:4179::2 or fe80::2 Destination Address List: 2002:836b:4179::1 or 2001::1 Result: 2002:836b:4179::1 (src 2002:836b:4179::2) then 2001::1 (src 2002:836b:4179::2) (prefer matching label) Candidate Source Addresses: 2002:836b:4179::2 or 2001::2 or fe80::2 Destination Address List: 2002:836b:4179::1 or 2001::1 Result: 2001::1 (src 2001::2) then 2002:836b:4179::1 (src 2002:836b:4179::2) (prefer higher precedence) 10.3. Configuring Preference for IPv6 or IPv4 10.3. ＩＰｖ６あるいはＩＰｖ４に対する優先の設定 The default policy table gives IPv6 addresses higher precedence than IPv4 addresses. This means that applications will use IPv6 in preference to IPv4 when the two are equally suitable. An administrator can change the policy table to prefer IPv4 addresses by giving the ::ffff:0.0.0.0/96 prefix a higher precedence: デフォルトポリシー表はＩＰｖ６アドレスにＩＰｖ４アドレスより高い優先 を与えます。これはアプリケーションが、２つが同じく適当である時、ＩＰ ｖ４に対すしてＩＰｖ６を優先して使うであろうことを意味します。管理者 が::ffff:0.0.0.0/96に高い優先度を与えることで、ＩＰｖ４アドレスの優先 のポリシー表を変えることができます： Prefix Precedence Label ::1/128 50 0 ::/0 40 1 2002::/16 30 2 ::/96 20 3 ::ffff:0:0/96 100 4 This change to the default policy table produces the following behavior: このデフォルトポリシー表に対する変更は次の行動を引き起こします： Candidate Source Addresses: 2001::2 or fe80::1 or 169.254.13.78 Destination Address List: 2001::1 or 131.107.65.121 Unchanged Result: 2001::1 (src 2001::2) then 131.107.65.121 (src 169.254.13.78) (prefer matching scope) Candidate Source Addresses: fe80::1 or 131.107.65.117 Destination Address List: 2001::1 or 131.107.65.121 Unchanged Result: 131.107.65.121 (src 131.107.65.117) then 2001::1 (src fe80::1) (prefer matching scope) Candidate Source Addresses: 2001::2 or fe80::1 or 10.1.2.4 Destination Address List: 2001::1 or 10.1.2.3 New Result: 10.1.2.3 (src 10.1.2.4) then 2001::1 (src 2001::2) (prefer higher precedence) 10.4. Configuring Preference for Scoped Addresses 10.4. 範囲アドレスに対する優先設定 The destination address selection rules give preference to destinations of smaller scope. For example, a site-local destination will be sorted before a global scope destination when the two are otherwise equally suitable. An administrator can change the policy table to reverse this preference and sort global destinations before site-local destinations, and site-local destinations before link- local destinations: 宛先アドレス選択規則はより小さい範囲の宛先に優先を与えます。例えば、 他が等しく適当であるとき、サイトローカルの宛先が、グローバルな範囲の 宛先の前にソートされるでしょう。管理者がこの優先性を反転して、そして リンクローカル宛先の前にサイトローカル宛先を、サイトローカル宛先の前 にグローバル宛先をソートするように、ポリシー表を変えることができます： Prefix Precedence Label ::1/128 50 0 ::/0 40 1 fec0::/10 37 1 fe80::/10 33 1 2002::/16 30 2 ::/96 20 3 ::ffff:0:0/96 10 4 This change to the default policy table produces the following behavior: このデフォルトポリシー表に対する変更は次の行動を引き起こします： Candidate Source Addresses: 2001::2 or fec0::2 or fe80::2 Destination Address List: 2001::1 or fec0::1 or fe80::1 New Result: 2001::1 (src 2001::2) then fec0::1 (src fec0::2) then fe80::1 (src fe80::2) (prefer higher precedence) Candidate Source Addresses: 2001::2 (deprecated) or fec0::2 or fe80::2 Destination Address List: 2001::1 or fec0::1 Unchanged Result: fec0::1 (src fec0::2) then 2001::1 (src 2001::2) (avoid deprecated addresses) 10.5. Configuring a Multi-Homed Site 10.5. マルチホームサイト設定 Consider a site A that has a business-critical relationship with another site B. To support their business needs, the two sites have contracted for service with a special high-performance ISP. This is in addition to the normal Internet connection that both sites have with different ISPs. The high-performance ISP is expensive and the two sites wish to use it only for their business-critical traffic with each other. あるサイトＡが他のサイトＢとのビジネス上重要な関係を持っていると思っ てください。彼らのビジネスの必要を支援するために、２つのサイトは特別 な高性能のＩＳＰでサービスを契約しました。これは両方のサイトが異なる ＩＳＰでで標準インターネット接続を行っていて、これは接続の追加です。 高性能なＩＳＰは高価で、そして２つのサイトは相互間の重要ビジネストラ フィックのためにだけそれを使うことを望みます。 Each site has two global prefixes, one from the high-performance ISP and one from their normal ISP. Site A has prefix 2001:aaaa:aaaa::/48 from the high-performance ISP and prefix 2007:0:aaaa::/48 from its normal ISP. Site B has prefix 2001:bbbb:bbbb::/48 from the high- performance ISP and prefix 2007:0:bbbb::/48 from its normal ISP. All hosts in both sites register two addresses in the DNS. それぞれのサイトが２つのグローバルプレフィックスを持ち、一方が高性能 ＩＳＰからで、一方が標準的ＩＳＰからです。サイトＡが高性能ＩＳＰから のプレフィックス2001:aaaa:aaaa::/48を、そして標準的なＩＳＰからのプレ フィックス2007:0:aaaa::/48を持っています。サイトＡが高性能ＩＳＰから のプレフィックス2001:bbbb:bbbb::/48を、そして標準的なＩＳＰからのプレ フィックス2007:0:bbbb::/48を持っています。両サイトの全てのホストはＤ ＮＳに２つのアドレスを登録します。 The routing within both sites directs most traffic to the egress to the normal ISP, but the routing directs traffic sent to the other site's 2001 prefix to the egress to the high-performance ISP. To prevent unintended use of their high-performance ISP connection, the two sites implement ingress filtering to discard traffic entering from the high-performance ISP that is not from the other site. 両サイトのルーティングは標準的なＩＳＰにたいていのトラフィックを向け ますが、しかし他のサイトの2001プレフィックスあてのトラヒックはは高性 能ＩＳＰの出口に向けます。高性能ＩＳＰ接続の思いがけない使用を妨げる ために、２つのサイトは高性能なＩＳＰから入ってくる他のサイトからでな いトラフィックを捨てる侵入フィルタを実行します。 The default policy table and address selection rules produce the following behavior: デフォルトポリシー表とアドレス選択規則は次の行動を引き起こします： Candidate Source Addresses: 2001:aaaa:aaaa::a or 2007:0:aaaa::a or fe80::a Destination Address List: 2001:bbbb:bbbb::b or 2007:0:bbbb::b Result: 2007:0:bbbb::b (src 2007:0:aaaa::a) then 2001:bbbb:bbbb::b (src 2001:aaaa:aaaa::a) (longest matching prefix) In other words, when a host in site A initiates a connection to a host in site B, the traffic does not take advantage of their connections to the high-performance ISP. This is not their desired behavior. 言い換えると、サイトＡのホストがサイトＢのホストに接続を始める時、ト ラフィックは高性能ＩＳＰの接続を利用しません。これは望ましい行動では ありません。 Candidate Source Addresses: 2001:aaaa:aaaa::a or 2007:0:aaaa::a or fe80::a Destination Address List: 2001:cccc:cccc::c or 2006:cccc:cccc::c Result: 2001:cccc:cccc::c (src 2001:aaaa:aaaa::a) then 2006:cccc:cccc::c (src 2007:0:aaaa::a) (longest matching prefix) In other words, when a host in site A initiates a connection to a host in some other site C, the reverse traffic may come back through the high-performance ISP. Again, this is not their desired behavior. 言い換えれば、サイトＡのホストが何か他のサイトＣのホストに接続を始め る時、逆のトラフィックは高性能ＩＳＰを通して戻って来るかもしれません。 再び、これは望ましい行動ではありません。 This predicament demonstrates the limitations of the longest- matching-prefix heuristic in multi-homed situations. この苦境はマルチホーム状態での発見的最長一致プレフィックスの限界を証 明します。 However, the administrators of sites A and B can achieve their desired behavior via policy table configuration. For example, they can use the following policy table: しかしながら、サイトＡとサイトＢの管理者がポリシー表設定によって望ま しい行動を成し遂げます。例えば、彼らは次のポリシー表を使うことができ ます： Prefix Precedence Label ::1 50 0 2001:aaaa:aaaa::/48 45 5 2001:bbbb:bbbb::/48 45 5 ::/0 40 1 2002::/16 30 2 ::/96 20 3 ::ffff:0:0/96 10 4 This policy table produces the following behavior: このポリシー表は次の行動を引き起こします： Candidate Source Addresses: 2001:aaaa:aaaa::a or 2007:0:aaaa::a or fe80::a Destination Address List: 2001:bbbb:bbbb::b or 2007:0:bbbb::b New Result: 2001:bbbb:bbbb::b (src 2001:aaaa:aaaa::a) then 2007:0:bbbb::b (src 2007:0:aaaa::a) (prefer higher precedence) In other words, when a host in site A initiates a connection to a host in site B, the traffic uses the high-performance ISP as desired. 言い替えれば、サイトＡのホストがサイトＢのホストに接続を始める時、ト ラフィックは望まれるように高性能ＩＳＰを使います。 Candidate Source Addresses: 2001:aaaa:aaaa::a or 2007:0:aaaa::a or fe80::a Destination Address List: 2001:cccc:cccc::c or 2006:cccc:cccc::c New Result: 2006:cccc:cccc::c (src 2007:0:aaaa::a) then 2001:cccc:cccc::c (src 2007:0:aaaa::a) (longest matching prefix) In other words, when a host in site A initiates a connection to a host in some other site C, the traffic uses the normal ISP as desired. 言い替えれば、サイトＡのホストが何か他のサイトＣのホストに接続を始め る時、トラフィックは望まれるように標準的ＩＳＰを使います。 Normative References 参照する参考文献 [1] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998. [2] Thompson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462 , December 1998. [3] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001. [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [5] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001. [6] Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)", RFC 2765, February 2000. Informative References 有益な参考文献 [7] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [8] Johnson, D. and C. Perkins, "Mobility Support in IPv6", Work in Progress. [9] S. Cheshire, B. Aboba, "Dynamic Configuration of IPv4 Link-local Addresses", Work in Progress. [10] Gilligan, R., Thomson, S., Bound, J. and W. Stevens, "Basic Socket Interface Extensions for IPv6", RFC 2553, March 1999. [11] S. Deering et. al, "IP Version 6 Scoped Address Architecture", Work in Progress. [12] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [13] Baker, F, "Requirements for IP Version 4 Routers", RFC 1812, June 1995. [14] Narten, T. and E. Nordmark, and W. Simpson, "Neighbor Discovery for IP Version 6", RFC 2461, December 1998. [15] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 Domains without Explicit Tunnels", RFC 2529, March 1999. [16] F. Templin et. al, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", Work in Progress. [17] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", RFC 1933, April 1996. Acknowledgments 謝辞 The author would like to acknowledge the contributions of the IPng Working Group, particularly Marc Blanchet, Brian Carpenter, Matt Crawford, Alain Durand, Steve Deering, Robert Elz, Jun-ichiro itojun Hagino, Tony Hain, M.T. Hollinger, JINMEI Tatuya, Thomas Narten, Erik Nordmark, Ken Powell, Markku Savela, Pekka Savola, Hesham Soliman, Dave Thaler, Mauro Tortonesi, Ole Troan, and Stig Venaas. In addition, the anonymous IESG reviewers had many great comments and suggestions for clarification. 著者はＩＰｎｇワーキンググループ、特にMarc BlanchetとBrian Carpenter とMatt CrawfordとAlain DurandとSteve DeeringとRobert ElzとJun-ichiro itojun HaginoとTony HainとM. T. HollingerとJINMEI TatuyaとThomas NartenとErik NordmarkとKen PowellとMarkku SavelaとPekka Savolaと Hesham SolimanとDave ThalerとMauro TortonesiとOle TroanとStig Venaas の貢献を認めたいです。加えて、匿名のＩＥＳＧ評者は明確化のために多く の大きいコメントと示唆を持っていました。 Author's Address 著者のアドレス Richard Draves Microsoft Research One Microsoft Way Redmond, WA 98052 Phone: +1 425 706 2268 EMail: richdr@microsoft.com Full Copyright Statement 著作権表示全文 Copyright (C) The Internet Society (2003). All Rights Reserved. 著作権（Ｃ）インターネット学会（２００３）。すべての権利は保留される。 This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. 上記著作権表示とこの段落が全ての複写や派生的な仕事につけられていれば、 この文書と翻訳は複写や他者への提供ができ、そしてコメントや説明や実装 を支援する派生的な仕事のためにこの文書の全部か一部を制約なく複写や出 版や配布できます。しかし、この文書自身は、英語以外の言葉への翻訳やイ ンターネット標準を開発する目的で必要な場合以外は、インターネット学会 や他のインターネット組織は著作権表示や参照を削除されるような変更がで きません、インターネット標準を開発する場合はインターネット標準化プロ セスで定義された著作権の手順に従われます。 The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. 上に与えられた限定された許可は永久で、インターネット学会やその後継者 や譲渡者によって無効にされません。 This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. この文書とここに含む情報は無保証で供給され、そしてインターネット学会 とインターネット技術標準化タスクフォースは、特別にも暗黙にも、この情 報の利用が権利を侵害しないことや商業利用や特別の目的への利用に適当で ある事の保障を含め、すべての保証を拒否します。 Acknowledgement 謝辞 Funding for the RFC Editor function is currently provided by the Internet Society. ＲＦＣエディタ機能のための資金供給が現在インターネット学会によって 供給されます。