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)
インターネットプロトコルバージョン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.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
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.
この文書では、ソースアドレス選択のために、宛先アドレスの選択のために、2つのアルゴリズムを説明しています。アルゴリズムは、すべてのインターネットプロトコルバージョン6（IPv6）の実装のためのデフォルトの動作を指定します。彼らは、アプリケーションや上位層プロトコルによって行われた選択をオーバーライドしない、また彼らは、アドレス選択のためのより高度なメカニズムの開発を排除します。 2つのアルゴリズムを使用すると、管理者はデフォルトの動作をオーバーライドすることができ、ポリシーを提供することを可能にするための任意の機構を含む、共通のコンテキストを共有します。デュアルスタックの実装では、宛先アドレス選択アルゴリズムは、IPv4とIPv6の両方がアドレス考えることができる - 利用可能な送信元アドレスに応じて、アルゴリズムは、IPv4アドレス上のIPv6アドレスを好むかもしれない、またはその逆。
All IPv6 nodes, including both hosts and routers, must implement default address selection as defined in this specification.
この仕様で定義されたホストとルータの両方を含むすべてのIPv6ノードは、デフォルトのアドレス選択を実装する必要があります。
Table of Contents
目次
1. Introduction................................................2
1.1. Conventions Used in This Document.....................4
2. Context in Which the Algorithms Operate.....................4
2.1. Policy Table..........................................5
2.2. Common Prefix Length..................................6
3. Address Properties..........................................6
3.1. Scope Comparisons.....................................7
3.2. IPv4 Addresses and IPv4-Mapped Addresses..............7
3.3. Other IPv6 Addresses with Embedded IPv4 Addresses.....8
3.4. IPv6 Loopback Address and Other Format Prefixes.......8
3.5. Mobility Addresses....................................8
4. Candidate Source Addresses..................................8
5. Source Address Selection...................................10
6. Destination Address Selection..............................12
7. Interactions with Routing..................................14
8. Implementation Considerations..............................15
9. Security Considerations....................................15
10. Examples...................................................16
10.1. Default Source Address Selection.....................16
10.2. Default Destination Address Selection................17
10.3. Configuring Preference for IPv6 or IPv4..............18
10.4. Configuring Preference for Scoped Addresses..........19
10.5. Configuring a Multi-Homed Site.......................19
Normative References.............................................21
Informative References...........................................22
Acknowledgments..................................................23
Author's Address.................................................23
Full Copyright Statement.........................................24
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] IPv6アドレス指定アーキテクチャは、複数のユニキャストアドレスがインタフェースに割り当てられることを可能にします。これらのアドレスは異なる到達可能性スコープ（リンクローカル、サイトローカル、またはグローバル）を有することができます。これらのアドレスは、「好ましい」または「非推奨」することができる[2]。プライバシーの考慮事項は、「パブリックアドレス」と「一時アドレス」の概念を導入している[3]。モビリティ・アーキテクチャは、「ホームアドレス」と「気付アドレス」を紹介する[8]。また、マルチホーミングの状況は、ノードごとに複数のアドレスになります。例えば、ノードは、それらのいくつかのトンネルまたは仮想インターフェイス、複数のインタフェースを有していてもよく、またはサイトは、ISPごとにグローバルプレフィックスを持つ複数のISPの添付ファイルを持つことができます。
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.
最終結果は、通信を開始するときのIPv6実装が非常にしばしば複数の可能な送信元アドレスと宛先アドレスに直面することです。開発者や管理者は、について推論し、そのシステムの挙動を予測できるように、送信元アドレスと宛先アドレスを選択するために、すべての実装に共通するデフォルトのアルゴリズムを有することが望ましいです。
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.
さらに、IPv6とIPv4の両方をサポートするデュアルまたはハイブリッドスタックの実装は、非常に頻繁に通信を開始する際にIPv6とIPv4の間で選択する必要があります。例えば、DNS名の解決は、IPv6とIPv4の両方のアドレスを生成し、ネットワーク・プロトコル・スタックは、利用可能なIPv6とIPv4の両方のソースアドレスを有します。このような場合には、簡単なポリシーは常にIPv6を好むか、いつものIPv4が悪い行動を生成することができます好むします。一例として、DNS名はグローバルIPv6アドレスとグローバルIPv4アドレスに解決されたとします。ノードがグローバルIPv6アドレス及び169.254 / 16自動設定IPv4アドレスを割り当てた場合[10]、その後のIPv6通信のために最良の選択です。ノードは唯一のリンクローカルIPv6アドレスとグローバルIPv4アドレスが割り当てられている場合しかし、その後、IPv4の通信のために最良の選択です。宛先アドレス選択アルゴリズムは、IPv6とIPv4アドレスの両方の中から選択するための統一された手順でこれを解決します。
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.
この文書に記載されているアルゴリズムは使用のために利用可能なアドレスのセットに半順序を定義する一連の規則として指定されています。ソースアドレス選択の場合には、ノードは、通常、1つは使用する「最良」であるアドレス定義部5に複数のインターフェイスに割り当てられたアドレス、およびソースアドレス順序付けルールを有しています。宛先アドレス選択の場合、DNSは、与えられた名前のアドレスのセットを返すことができ、アプリケーションが最初に使用するかを決定する必要があり、他人をしようとするどのような順序で最初の1が到達すべきではありません。 DNSによって返されたアドレスのセットに適用されるセクション6、内の宛先アドレス順序付け規則は、推奨される順序を提供しています。
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.
この文書では、別々のソースアドレス選択および宛先アドレスの選択を指定するが、その結果、互いに共通のコンテキストを使用して、2つのアルゴリズムは、有用な結果をもたらします。アルゴリズムは、適切な範囲および構成ステータス（RFC 2462の意味で好ましいまたは非推奨）の送信元アドレスと宛先アドレスを選択することを試みます。また、この文書は、より良好な情報が存在しない場合にさもなければ等価アドレスの中から選択するための好ましい方法は、最長一致プレフィクスを、示唆しています。
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.
また、このドキュメントでは、デフォルトの動作の管理オーバーライドを許可するポリシーのフックを指定します。例えば、これらのフック用いて管理者は、宛先プレフィックスで使用するための好ましいソース・プレフィックスを指定することができ、または別のプレフィックスを持つアドレスを介して1つのプレフィックスと宛先アドレスを好みます。これらのフックは、いくつかのマルチホーミングと移行のシナリオに対処する管理者の柔軟性を与え、彼らは確かに万能薬ではありません。
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.
この文書で指定された選択ルールは、アプリケーションまたは法的宛先または送信元アドレスの上位層の明示的な選択を上書きするように解釈してはなりません。
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"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14、RFC 2119に記載されるように解釈される[4]。
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.
アドレス選択のための私たちのコンテキストは、送信元アドレスの選択から宛先アドレスの選択を分ける最も一般的な実装アーキテクチャから派生します。したがって、我々は、これらのタスクのための2つの別々のアルゴリズムを持っています。アルゴリズムはよく一緒に動作するように設計されており、彼らが管理ポリシーオーバーライドするためのメカニズムを共有しています。
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.
この実装アーキテクチャでは、アプリケーションは、APIを使用する[10]アプリケーションにアドレスのリストを返すのgetaddrinfo（）が挙げられます。このリストは、IPv6およびIPv4アドレス（時には、IPv4射影アドレスとして表される）の両方を含む可能性があります。その後、アプリケーションは）接続（）またはのsendto（とネットワークスタックに送信先アドレスを渡します。次に、アプリケーションは、通常、それが働いアドレスを見つけるまで、アドレスのリストをループ、リストの最初のアドレスをしようとするだろう。いずれの場合も、ネットワーク層は、それはいくつかの選択肢から宛先アドレスを選択する必要がある状況では決してありません。また、アプリケーションは、バインド（）と送信元アドレスを指定するかもしれないが、多くの場合、送信元アドレスが未指定のままにされます。したがって、ネットワーク層は、多くの場合、いくつかの選択肢から送信元アドレスを選択しません。
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（の実装）がIPv6とIPv4のリストをソートするために、ここで指定した宛先アドレス選択アルゴリズムを使用することを意図するが、彼らは返すことを対処しています。アプリケーションまたは上位層は送信元アドレスを指定しなかった場合に別々に、IPv6ネットワーク層は、ソースアドレス選択アルゴリズムを使用します。 IPv4ネットワーク層のソースアドレス選択にこの仕様の適用は可能であるが、これはここでさらに探求されていません。
Well-behaved applications SHOULD iterate through the list of addresses returned from getaddrinfo() until they find a working address.
行儀のアプリケーションは、アドレスのリストを反復処理すべきである彼らは、作業アドレスを見つけるまで）（getaddrinfoはから返されました。
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.
アルゴリズムは彼らの決定を行う際にいくつかの基準を使用します。組み合わされた効果は、2つのアドレスが非廃止予定のソースアドレス、同じ範囲またはタイプである宛先アドレスの大きいスコープの上に小さいスコープを好む、好まれるソース/宛先アドレス対を好む遷移アドレスネイティブアドレスの使用を回避することです利用可能であり、他のすべてが等しい最長可能共通のプレフィックスを持つアドレスペアを好みます。ソースアドレス選択の場合は、[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.
この仕様は、必要に応じてアルゴリズムのデフォルトの動作をオーバーライドできるポリシーの管理上の設定の可能性を可能にします。ポリシーオーバーライドは、宛先プレフィクスのための優先順位値および好ましいソース・プレフィックスを指定する設定テーブルの形をとります。実装は、設定されていない場合、実装が設定されていない場合、または、この文書で指定されたデフォルトのポリシーテーブルを使用する必要があります。
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).
ポリシーテーブルには、多くのルーティングテーブルのように、最長一致プレフィックスルックアップテーブルです。優先順位の値優先（A）と分類またはラベルラベル（A）：アドレスAを考えると、ポリシーテーブル内のルックアップは、2つの値を生成します。
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.
優先順位値の優先順位（A）は、宛先アドレスをソートするために使用されます。優先（A）>優先順位（B）した場合、我々は、アドレスAが我々のアルゴリズムは、宛先アドレスBの前に宛先アドレスAを並べ替えることを好むだろうことを意味し、アドレス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).
ラベル値ラベル（A）は、宛先アドレスのプレフィックスを使用するため、特定の送信元アドレスのプレフィックスを好む政策が可能になります。アルゴリズムは、ラベル（S）=ラベル（D）場合、宛先アドレスDとソースアドレスSを使用することを好みます。
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.
IPv6実装は、ここで定義されたポリシーテーブルと少なくとも同程度の強力な機構を介して設定可能なアドレス選択をサポートする必要があります。この記事の執筆時点で可能のIPv6アドレスのセットから選択したポリシーを使用して限られた経験があることに注意してください。より多くの経験が得られるよう、推奨されるデフォルトのポリシーが変更されることがあります。したがって、実装がより多くの経験が得られるように、デフォルトのポリシーを変更する方法を提供することが重要です。セクション10.3と10.4が必要になる可能性がある変更の種類の例を提供しています。
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:
実装は設定できませんか、構成されていない場合、それは次のデフォルトポリシーテーブルと一緒にここで指定したアルゴリズムに従って動作する必要があります。
Prefix Precedence Label ::1/128 50 0 ::/0 40 1 2002::/16 30 2 ::/96 20 3 ::ffff:0:0/96 10 4
接頭辞順位ラベル:: 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.
デフォルトポリシーテーブルの1つの効果は、ネイティブの宛先アドレスを持つ天然のソースアドレスを使用して好む6to4の宛先アドレスとの6to4 [5]送信元アドレス、及びV4互換宛先アドレスとV4互換[1]のソースアドレスです。一致する発信元アドレスが利用可能な場合、デフォルトのポリシーテーブルの別の効果は、IPv4アドレスを用いた通信にIPv6アドレスを用いて通信を好むことです。
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.
スコープのアドレスプレフィックスのポリシーテーブルのエントリは、オプションのゾーンインデックスで修飾することができます。もしそうなら、ゾーンインデックスは、アドレスのゾーンインデックスと一致する場合は、プリフィックス・テーブル・エントリーは、ルックアップ中にアドレスに対して一致しました。
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.
我々は、2つのアドレスが共通していることが最も長い接頭辞（最上位、又は左端を見て、ビット）の長ように、2つのアドレスAとBの共通プレフィックス長CommonPrefixLen（A、B）を定義します。これは、0から128の範囲です。
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.
後のセクションで与えられた規則では、異なる種類（例えば、IPv4の、IPv6の、マルチキャストおよびユニキャスト）のアドレスが互いに比較されます。これらのアドレスタイプのいくつかは、互いに直接比較できない性質を持っています。 IPv4アドレスは、そのような概念を持たない間、例えば、[2]、IPv6ユニキャストアドレスは、「好ましい」ことができ、または「非推奨します」。順序付けルールを使用してこのようなアドレスを比較する（例えば、アドレスを「非推奨」に優先して「好ましい」アドレスを使用する）、次のマッピングが定義されています。
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].
マルチキャスト宛先アドレスがマルチキャストパケットの伝搬を制御する4ビット・スコープ・フィールドを有します。 IPv6のアドレス体系は、インタフェースローカル（0x1の）、リンクローカル（0x2の）、サブネットローカル（0x3の）、管理ローカル（0x4の）、サイトローカル（0x5）、組織局所（0x8という）のためのスコープフィールドの値を定義します、およびグローバル（から0xE）スコープ[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).
我々は、範囲（A）<スコープ（B）は、Aがリンクローカルユニキャストアドレスであり、Bは、サイトローカルマルチキャストアドレスである場合、例えば、アドレスAの範囲を意味するスコープ（A）を書き込みます。
This mapping implicitly conflates unicast site boundaries and multicast site boundaries [11].
このマッピングは、暗黙的にユニキャストサイト境界とマルチキャストサイト境界[11]を融合します。
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.
宛先アドレス選択アルゴリズムは、IPv6とIPv4アドレスの両方で動作します。この目的のために、IPv4アドレスは、IPv4マップアドレス[1]として表現されなければなりません。例えば、優先またはポリシーテーブルにIPv4アドレスの他の属性を検索するために、対応するIPv4マップIPv6アドレスをルックアップします。
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.
次のようにIPv4アドレスは、スコープを割り当てられています。接頭169.254 / 16を有しているIPv4の自動設定アドレス[9]は、リンクローカルスコープが割り当てられています。プレフィックス10/8、172.16 / 12、及び192.168 / 16を持っているIPv4のプライベートアドレス[12]は、サイトローカルスコープが割り当てられています。接頭8分の127を有しているIPv4のループバックアドレス[12、セクション4.2.2.11]は、リンクローカルスコープが割り当てられている（同様のIPv6ループバックアドレスの治療[11、セクション4]に）。その他のIPv4アドレスがグローバルスコープに割り当てられています。
IPv4 addresses should be treated as having "preferred" (in the RFC 2462 sense) configuration status.
IPv4アドレスは、コンフィギュレーションステータス（RFC 2462の意味で）「好ましい」ものとして扱われるべきです。
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.
IPv4互換アドレス[1]、IPv4マップ[1]、IPv4に並進[6]との6to4アドレス[5]埋め込まれたIPv4アドレスを含みます。このドキュメントの目的のために、これらのアドレスは、グローバルスコープを持つものとして扱われるべきです。
IPv4-compatible, IPv4-mapped, and IPv4-translatable addresses should be treated as having "preferred" (in the RFC 2462 sense) configuration status.
IPv4互換、IPv4マップ、およびIPv4に並進アドレスが設定ステータス（RFC 2462の意味で）「好ましい」ものとして扱われるべきです。
The loopback address should be treated as having link-local scope [11, section 4] and "preferred" (in the RFC 2462 sense) configuration status.
ループバックアドレスは、リンクローカル範囲[11、セクション4]、「好ましい」（RFC 2462におけるセンス）設定ステータスを有するものとして扱われるべきです。
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.
まだ未定義のフォーマットプレフィックスとNSAPアドレスと他のアドレスは、グローバルスコープと「好ましい」（RFC 2462で）設定ステータスを有するものとして扱われるべきです。その後の規格は、この治療法に取って代わることがあります。
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]を参照）ホームアドレスと気付アドレスの概念を使用してモビリティをサポートすることができます。概念的には、ホームアドレスは、モバイルノードに割り当てられ、モバイルノードのパーマネントアドレスとして使用するIPアドレスです。気付けアドレスは、外部リンクを訪問している間、移動ノードに関連付けられたIPアドレスです。モバイルノードがホームリンク上にある場合、それは同時にホームアドレスと気付アドレスであるアドレスを有することができます。
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.
このドキュメントの目的のためには、自分のアドレスがホームアドレスまたは気付アドレスとして指定されているか否かを知るのに十分です。アドレスはホームアドレスまたは気付アドレスを指定する必要があるかどうかは、このドキュメントの範囲外です。
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）はアドレス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.
候補送信元アドレスが宛先に送信するために使用されるインタフェースに割り当てられたユニキャストアドレスのセットであることが推奨されます。 （「発信」インターフェース。）ルータでは、候補セットは、以下に説明する制限を受けるパケットを転送する任意のインターフェイスに割り当てられたユニキャストアドレスを含むことができます。
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.
マルチキャスト及びリンクローカル宛先アドレスのために、候補ソースアドレスのセットは、発信インタフェースと同じリンクに属するインタフェースに割り当てられたアドレスを含まなければなりません。
Discussion: The restriction for multicast destination addresses is necessary because currently-deployed multicast forwarding algorithms use Reverse Path Forwarding (RPF) checks.
議論：現在展開マルチキャスト転送アルゴリズムはリバースパス転送（RPF）チェックを使用するため、マルチキャスト宛先アドレスの制限が必要です。
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.
いずれの場合においても、エニーキャストアドレス、マルチキャストアドレス、および未指定アドレスは候補セットに含まれてはいけません。
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.
SIIT [6、特に部5]をサポートIPv6専用ノードで、宛先アドレスがIPv4マップアドレスであるならば、候補セットは、IPv4のみ、翻訳可能なアドレスを含まなければなりません。宛先アドレスがIPv4マップアドレスでない場合は、候補セットは、IPv4翻訳可能アドレスを含めることはできません。
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.
ソースアドレス選択アルゴリズムは、出力として与えられた宛先アドレスと共に使用するための単一のソースアドレスを生成します。このアルゴリズムは、IPv6宛先アドレスではなく、IPv4のアドレスに適用されます。
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.
アルゴリズムは、（与えられた宛先アドレスD用）CandidateSource（D）を設定候補のアドレスに「より大きい」順序を課しペアワイズ比較規則のリストの観点から、ここで指定されています。アルゴリズムが完了した後、リストの先頭にアドレスが1アルゴリズムの選択です。
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.
候補セット内のアドレスの順序は、各ルールがそれぞれに対して二つのソースアドレスに順序付け「等しい「または」より少ない」「より大きい」を配置することで、8ペアワイズ比較ルールのリストによって定義されます。その他（およびそのルール）。二つのアドレスのための結果が「等しい」を提供する所定のルールはネクタイを生成する場合には、すなわち、残りの規則は、タイを破るために結び付けられているだけで、これらのアドレスに（順番に）適用されます。ルールは、（タイの場合には「勝者」の設定または）単一の明確な「勝者」を生成する場合、後続のルールが残っているアドレスにのみ適用ではなく、勝利セットにおけるこれらのアドレスは、さらなる考慮から廃棄することができることに留意されたいです。 8つのルールは、単一のアドレスを選択するために失敗した場合、いくつかの不特定タイブレーカを使用する必要があります。
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.
候補セットからの二つのアドレスSAとSBを比較すると、私たちは、SAがSB「より大きい」であることを意味するために「SAを好む」と言う、と同様に私たちは、SAがSB「未満」であることを意味する「SBを好む」と言います。
Rule 1: Prefer same address. If SA = D, then prefer SA. Similarly, if SB = D, then prefer SB.
ルール1：同じアドレスを優先する。 SAはDを=場合は、SAを好みます。 SBがDをIF =同様に、次に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.
ルール2：適切な範囲を好みます。もしスコープ（SA）<範囲（SB）：スコープ（SA）<スコープ（D）場合には、SBを好むし、そうでなければSAを好みます。同様に、範囲（SB）<スコープ（SA）は：範囲（SB）<スコープ（D）場合、SAを好むし、そうでなければSBを好みます。
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."
ルール3：非推奨アドレスを避けてください。アドレスSAとSBは同じスコープを持っています。二つのソースアドレスの一つが「優先」され、そのうちの一つは、（RFC 2462の意味で）「非推奨」された場合、その後されたものを好む「好ましい」を
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.
ルール4：ホームアドレスを優先。 SAは、同時にホームアドレスと気付アドレスで、SBがない場合は、SAを好みます。 SBが同時にホームアドレスと気付アドレスであり、SAがない場合は同様に、その後、SBを好みます。 SAはちょうどホームアドレスで、SBがちょうど気付アドレスである場合には、SAを好みます。 SBはちょうどホームアドレスで、SAがある場合は同様に、ちょうど気付アドレス、そして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.
実装は、この設定の意味を逆にし、ホームアドレス（例えば、適切なAPIの拡張機能を介して）上に気付アドレスを好むアプリケーションを可能にする機構を提供しなければなりません。メカニズムの使用は唯一の呼び出しアプリケーションのための選択ルールに影響を与える必要があります。
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.
ルール5：発信インターフェイスを優先する。 SAがDに送信するために使用され、SBを異なるインタフェースに割り当てられているインターフェイスに割り当てられている場合、SAを好みます。 SBがDに送信するために使用され、SAが異なるインタフェースに割り当てられているインターフェイスに割り当てられている場合も同様に、次に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.
ルール6：ラベルに一致好みます。もしラベル（SA）=ラベル（D）とラベル（SB）<>ラベル（D）は、SAを好みます。同様に、ラベル（SB）=ラベル（D）とラベル（SA）<>ラベル（D）は、その後、SBを好む場合。
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.
ルール7：パブリックアドレスを好みます。 SAがパブリックアドレスで、SBが一時的なアドレスである場合には、SAを好みます。 SBがパブリックアドレスで、SAは一時アドレスであれば同様に、その後、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.
実装は、（適切なAPIの拡張を介して例えば、）この設定の意味を逆にし、パブリックアドレス上に一時アドレスを好むアプリケーションを可能にする機構を提供しなければなりません。メカニズムの使用は唯一の呼び出しアプリケーションのための選択ルールに影響を与える必要があります。この規則は、一時アドレスの比較的短い寿命のか、一時的なアドレス失敗またはランダム化された名前を返すのいずれかの逆引き参照の可能性に起因する障害が発生し、潜在的なアプリケーションを避けることができます。検討事項は、これらのアプリケーションの互換性の懸念を上回るどのプライバシーのために実装はこのルールの意味を逆にして、デフォルトでパブリックアドレス上で一時アドレスを好むかもしれません。
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.
ルール8：最長一致接頭辞を使用します。 CommonPrefixLen（SA、D）> CommonPrefixLen（SB、D）場合、SAを好みます。同様に、CommonPrefixLen（SB、D）> CommonPrefixLen（SA、D）場合には、SBを好みます。
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.
実装は、送信元アドレスの中から選択するの他の手段を持っている場合、ルール8は、無効とされることがあり。例えば、実装は、何らかの形で「最良の」通信性能になりますどのソースアドレスを知っている場合。
Rule 2 (prefer appropriate scope) MUST be implemented and given high priority because it can affect interoperability.
ルール2は、（適切な範囲を好む）を実施して、相互運用性に影響を与えることができるため、高い優先度が与えられなければなりません。
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.
宛先アドレス選択アルゴリズムは、宛先アドレスのリストを取り、新しいリストを生成するためのアドレスをソートします。これは、DAが元のリストにDBの前に表示されたアドレスDAとDBのペアワイズ比較の観点から、ここで指定されています。
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.
このアルゴリズムは、一緒にIPv6とIPv4の両方のアドレスをソートします。ポリシーテーブルにIPv4アドレスの属性を見つけるために、IPv4アドレスは、IPv4マップアドレスとして表されるべきです。
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.
我々は、前のセクションでは、送信元アドレス選択アルゴリズムを指定し、IPv6アドレスの送信先D.のための選択の送信元アドレスを示すために、ソース（D）を書き込みます。 IPv4アドレスの送信元アドレスの選択は、この文書で指定されていません。
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.
我々はCandidateSource（D）が空集合である場合、これが唯一のケースで、IPv6アドレスの送信先D.のために利用可能な送信元アドレスが存在しない場合は、ソース（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.
宛先アドレスのペアワイズ比較は順番に適用されるべき10個の規則からなります。ルールが結果を決定した場合、残りのルールは関連していないと無視されるべきです。後続のルールは、以前のルールのタイブレーカーとして機能します。ペアワイズ比較タイブレーカルールはリストをソートするために使用することができる方法のより長い説明は、前のセクションを参照してください。
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.
ルール1：使用できない目的地を避けてください。 DBが到達不能であることが知られている場合、またはソース（DB）が未定義である場合、DAを好みます。 DAは到達不能であることが知られている場合、またはソース（DA）が未定義の場合、同様に、その後、DBを好みます。
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.
ルール2：一致する範囲を好みます。スコープ（DA）=スコープ（ソース（DA））、および範囲（DB）<>スコープ（ソース（DB））場合には、DAを好みます。同様に、スコープ（DA）<>スコープ（ソース（DA））、および範囲（DB）=スコープ（ソース（DB））、その後、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.
ルール3：非推奨アドレスを避けてください。ソース（DA）が廃止され、ソース（DB）がない場合は、DBを好みます。ソース（DA）が非推奨されておらず、ソース（DB）が廃止された場合も同様に、そのDAを好みます。
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.
ルール4：ホームアドレスを優先。ソース（DA）が同時にホームアドレスとアドレスとSource（DB）気付であれば、DAを好むされていません。ソース（DB）が同時にある場合は同様に、ホームアドレスと気付アドレスとSource（DA）は、その後、DBを好む、ではありません。
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.
ソース（DA）はちょうど家の住所であるとSource（DB）はちょうど気付アドレスである場合には、DAを好みます。ソース（DA）は、単にアドレスと送信元（DB）気付でちょうど家の住所であれば同様に、その後、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.
ルール5：ラベルに一致好みます。もしラベル（出典（DA））=ラベル（DA）とラベル（出典（DB））<>ラベル（DB）、その後、DAを好みます。同様に、ラベル（ソース（DA））<>ラベル（DA）とラベル（ソース（DB））=ラベル（DB）は、DBを好みます。
Rule 6: Prefer higher precedence. If Precedence(DA) > Precedence(DB), then prefer DA. Similarly, if Precedence(DA) < Precedence(DB), then prefer DB.
ルール6：高い優先順位を優先する。優先順位（DA）>優先順位（DB）は、その後、DAを好む場合。同様に、優先順位（DA）<優先順位（DB）場合、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.
ルール7：ネイティブの輸送を優先。 DAは、カプセル化遷移機構を介して到達した場合（例えば、IPv4のIPv6の）とDBは次に、DBを好むではありません。 DBは、カプセル化を介して到達され、DAがない場合は同様に、次に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).
ディスカッション：6オーバー4 [15]、ISATAP [16]、及び設定されたトンネル[17]宛先アドレスが特定のプレフィックスを持っていない、従ってより低い優先順位を割り当てることができないため、遷移機構をカプセル化の例でありますポリシーテーブル。実装は、インターフェース優先の概念を用いて、および（IPv6の型のIPv4カプセル化インターフェースなど）（イーサネットインターフェイスのような）ネイティブインターフェースよりも低い優先度を仮想インターフェイスを与えることによってこの規則を一般化するかもしれません。
Rule 8: Prefer smaller scope. If Scope(DA) < Scope(DB), then prefer DA. Similarly, if Scope(DA) > Scope(DB), then prefer DB.
ルール8：小さい範囲を好みます。スコープ（DA）<スコープ（DB）場合は、DAを好みます。同様に、スコープ（DA）>スコープ（DB）は、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.
ルール9：最長一致接頭辞を使用します。 DAとDBは（両方がIPv6であるか、その両方がIPv4ている）同じアドレスファミリに属しているとき：CommonPrefixLen（DA、ソース（DA））> CommonPrefixLen（DB、ソース（DB））場合は、DAを好みます。同様に、CommonPrefixLen（DA、ソース（DA））<CommonPrefixLen（DB、ソース（DB））、その後、DBを好みます。
Rule 10: Otherwise, leave the order unchanged. If DA preceded DB in the original list, prefer DA. Otherwise prefer DB.
ルール10：それ以外の場合は、そのままの順序を残します。 DAが元のリストにDBを先行した場合は、DAを好みます。それ以外の場合は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.
実装は、宛先アドレスをソートする他の手段を有している場合、ルール9及び図10は、置き換えてもよいです。例えば、実装は、何らかの形で、宛先アドレスが「最良の」通信性能につながるかを知っている場合。
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.
例えば、ノードが動作してデフォルトルータを有する両方のリンクを持つ2つの異なるリンク上のインタフェースを有していると仮定する。インターフェイスの両方がグローバルアドレス（RFC 2462の意味で）が好ましいています。グローバル宛先アドレスに送信するとき、何のルーティング理由がない場合は、優先的には、宛先と長い共通のプレフィックスを共有する送信元アドレスを使用できるようになります発信インターフェイスを選択することができ、他の、実装上の1つのインターフェイスを好みます。
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.
また、実装は、送信元アドレスの選択に影響を与えるために、ルータの選択を使用することができます。例えば、ホスト2つのルータとのリンクの上にあると仮定します。一つのルータは、グローバルプレフィックスAを広告し、他のルータは、グローバルプレフィックスB.をアドバタイズされた最初のルータを介して送信するときに、ホストは、接頭辞Aとソースアドレスを優先し、第2のルータを介して送信する際に、接頭辞Bとソースアドレスを好みます
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するために複数の呼び出しを渡ってそれを取り出すのオーバーヘッドを償却、キャッシュすることができます。このアプローチでは、インプリメンテーションは、各宛先の発信インタフェースの知識を有していなくてもよいので、宛先アドレス順序付け中候補セットの緩い定義を使用するかもしれません。
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.
いずれの場合も、実装は、宛先アドレス選択の実装にキャッシュされ、おそらく古い情報を使用している場合、または宛先アドレスのキャッシュされたリストの順序は、おそらく古くなっている場合、それはアプリケーションがあると宛先アドレスの順序が返されることを確認する必要があります日付のうち1秒以上なかっなし。例えば、実装は、これらのアルゴリズムに影響を与える可能性のあるすべてのルーティングテーブルエントリまたは送信元アドレスの割り当てが変更されているかどうかを確認するためにシステムコールを行うことがあります。別の戦略は、任意の根底にある状態が変更されるたびにインクリメントされた無効化カウンタを使用することです。誘導された状態が潜在的に失効している場合に由来する状態と現在の無効カウンタ値をキャッシュし、その後現在の値と比較することにより、実装が検出できます。
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.
この文書で指定されたものを含め、ほとんどのソースアドレス選択アルゴリズムは、潜在的なプライバシーの懸念を公開することに注意してください。無愛想なノードが応答パケットのソースアドレスを選択するために、ターゲットホストを強制要求パケットをターゲットノードを探索することによって、ターゲットノードのアドレスの間の相関を推測することができます。 （おそらく、要求パケットがエニーキャスト又はマルチキャストアドレスに送信されるため、またはおそらく攻撃のために選択された上位層プロトコルは、その返信パケットのための特定のソースアドレスを指定していない。）自体に異なるアドレスを使用して、非友好的なノードができターゲット自身のアドレスを公開するために、ターゲットノードを引き起こします。
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.
このセクションでは、最初のデフォルトの動作をして、ポリシーテーブルのコンフィギュレーションの有用性を実証し、多くの例が含まれています。これらの実施例は例示の目的のために提供されます。彼らは規範として解釈されるべきではありません。
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)
送信先：2001 :: 1つの候補ソースアドレス：3FFE :: 1またはFE80 ::検索結果：3FFE :: 1（適切なスコープを好みます）
Destination: 2001::1 Candidate Source Addresses: fe80::1 or fec0::1 Result: fec0::1 (prefer appropriate scope)
送信先：2001 :: 1つの候補ソースアドレス：FE80 :: 1またはFEC0 ::検索結果：FEC0 :: 1（適切なスコープを好みます）
Destination: fec0::1 Candidate Source Addresses: fe80::1 or 2001::1 Result: 2001::1 (prefer appropriate scope)
目的地：FEC0 :: 1つの候補ソースアドレス：FE80 :: 1または2001 ::検索結果：2001 :: 1（適切なスコープを好みます）
Destination: ff05::1 Candidate Source Addresses: fe80::1 or fec0::1 or 2001::1 Result: fec0::1 (prefer appropriate scope)
目的地：FF05 :: 1つの候補ソースアドレス：FE80 :: 1またはFEC0 :: 1または2001 ::検索結果：FEC0 :: 1（適切なスコープを好みます）
Destination: 2001::1 Candidate Source Addresses: 2001::1 (deprecated) or 2002::1 Result: 2001::1 (prefer same address)
送信先：2001 :: 1候補ソースアドレス：2001 :: 1（非推奨）または2002 ::検索結果：2001 :: 1（同じアドレスを好みます）
Destination: fec0::1 Candidate Source Addresses: fec0::2 (deprecated) or 2001::1 Result: fec0::2 (prefer appropriate scope)
目的地：FEC0 :: 1つの候補ソースアドレス：FEC0 :: 2（非推奨）または2001 ::検索結果：FEC0 :: 2（適切なスコープを好みます）
Destination: 2001::1 Candidate Source Addresses: 2001::2 or 3ffe::2 Result: 2001::2 (longest-matching-prefix)
送信先：2001 :: 1候補ソースアドレス：2001 :: 2または3FFE :: 2結果：2001 :: 2（最長一致プレフィックス）
Destination: 2001::1 Candidate Source Addresses: 2001::2 (care-of address) or 3ffe::2 (home address) Result: 3ffe::2 (prefer home address)
送信先：2001 :: 1候補ソースアドレス：2001 :: 2（気付アドレス）または3FFE :: 2（ホームアドレス）結果：3FFE :: 2（好むホームアドレス）
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)
送信先：2002：836B：2179 :: 1候補ソースアドレス：2002：836B：2179 :: d5e3：7953：13eb：22e8（一時的な）または2001 :: 2結果：2002：836B：2179 :: d5e3：7953：13eb ：22e8（一致するラベルを好みます）
Destination: 2001::d5e3:0:0:1 Candidate Source Addresses: 2001::2 or 2001::d5e3:7953:13eb:22e8 (temporary) Result: 2001::2 (prefer public address)
送信先：2001 :: d5e3：0：0：1つの候補ソースアドレス：2001 :: 2または2001 :: d5e3：7953：13eb：22e8（一時的な）結果：2001 :: 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)
候補ソースアドレス：2001 :: 2またはFE80 :: 1つのまたは169.254.13.78送信先アドレス一覧：2001 :: 1または131.107.65.121結果：2001 :: 1（SRC 2001 :: 2）その後、131.107.65.121（SRC 169.254。 13.78）（マッチング範囲を好みます）
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)
候補ソースアドレス：FE80 :: 1または131.107.65.117送信先アドレス一覧：2001 :: 1または131.107.65.121結果：131.107.65.121（SRC 131.107.65.117）は、2001 :: 1（SRC FE80 :: 1）（マッチングを好みます範囲）
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)
候補ソースアドレス：2001 :: 2またはFE80 :: 1または10.1.2.4送信先アドレス一覧：2001 :: 1または10.1.2.3結果：2001 :: 1（SRC 2001 :: 2）その後、10.1.2.3（SRC 10.1。 2.4）（高い優先順位を好みます）
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)
候補ソースアドレス：2001 :: 2またはFEC0 :: 2またはFE80 :: 2送信先アドレス一覧：2001 :: 1またはFEC0 :: 1またはFE80 ::検索結果：FE80 :: 1（SRC FE80 :: 2）その後、 FEC0 :: 1（SRCのFEC0 :: 2）を2001 :: 1（SRC 2001 :: 2）（より小さな範囲を好みます）
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)
候補ソースアドレス：2001 :: 2（気付アドレス）または3FFE :: 1（ホームアドレス）またはFEC0 ::（気付アドレスの）2またはFE80 :: 2（気付アドレス）送信先アドレス一覧：2001 :: 1またはFEC0 ::検索結果：2001：1（SRCの3FFE :: 1）をFEC0 :: 1（SRC FEC0 :: 2）（ホームアドレスを好みます）
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)
候補ソースアドレス：2001 :: 2またはFEC0 :: 2（非推奨）またはFE80 :: 2送信先アドレス一覧：2001 :: 1またはFEC0 ::検索結果：2001 :: 1（SRC 2001 :: 2）その後、FEC0： ：1（SRC FEC0 :: 2）（廃止予定のアドレスを避けるため）
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)
候補ソースアドレス：2001 :: 2または3f44 :: 2またはFE80 :: 2送信先アドレス一覧：2001 :: 1または3FFE ::検索結果：2001 :: 1（SRC 2001 :: 2）その後の3ffe :: 1（ SRC 3f44 :: 2）（最長一致プレフィックス）
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)
候補ソースアドレス：2002：836B：4179 :: 2またはFE80 :: 2宛先アドレスのリスト：2002：836B：4179 :: 1または2001 ::検索結果：2002：836B：4179 :: 1（SRC 2002：836B： 4179 :: 2）その後、2001 :: 1（SRC 2002：836B：4179 :: 2）（一致するラベルを好みます）
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)
候補ソースアドレス：2002：836B：4179 :: 2または2001 :: 2またはFE80 :: 2宛先アドレスのリスト：2002：836B：4179 :: 1または2001 ::検索結果：2001 :: 1（SRC 2001 :: 2）その後、2002：836B：4179 :: 1（SRC 2002：836B：4179 :: 2）（高い優先順位を好みます）
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:
デフォルトポリシーテーブルは、IPv6はIPv4アドレスよりも高い優先順位を与え取り組みます。これは、2つの同様に適しているときにアプリケーションがIPv4よりも優先してIPv6を使用することを意味します。 0.0.0.0/96プレフィックス高い優先順位：管理者は、::のFFFFを与えることによって、IPv4アドレスを好むポリシーテーブルを変更することができます。
Prefix Precedence Label ::1/128 50 0 ::/0 40 1 2002::/16 30 2 ::/96 20 3 ::ffff:0:0/96 100 4
接頭辞順位ラベル:: 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)
候補ソースアドレス：2001 :: 2またはFE80 :: 1または169.254.13.78送信先アドレス一覧：2001 :: 1または131.107.65.121変化なし結果：2001 :: 1（SRC 2001 :: 2）その後、131.107.65.121（SRC 169.254 .13.78）（）マッチング範囲を好みます
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)
候補ソースアドレス：FE80 :: 1または131.107.65.117送信先アドレス一覧：2001 :: 1または131.107.65.121変化なし結果：131.107.65.121（SRC 131.107.65.117）、その後2001 :: 1（SRC FE80 :: 1）（好みます一致する範囲）
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)
候補ソースアドレス：2001 :: 2またはFE80 :: 1または10.1.2.4送信先アドレス一覧：2001 :: 1または10.1.2.3新しい結果：10.1.2.3（SRC 10.1.2.4）、その後2001 :: 1（SRC 2001： ：2）（）は、より高い優先順位を好みます
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
接頭辞順位ラベル:: 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)
候補ソースアドレス：2001 :: 2またはFEC0 :: 2またはFE80 :: 2送信先アドレス一覧：2001 :: 1またはFEC0 :: 1つのまたはFE80 :: 1新しい結果：2001 :: 1（SRC 2001 :: 2）次いでFEC0 :: 1（SRC FEC0 :: 2）次に、FE80 :: 1（SRC FE80 :: 2）（好む高い優先順位）
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)
候補ソースアドレス：2001 :: 2（非推奨）またはFEC0 :: 2またはFE80 :: 2送信先アドレス一覧：2001 :: 1またはFEC0 :: 1変化なし結果：FEC0 :: 1（SRC FEC0 :: 2）その後、2001 :: 1（SRC 2001 :: 2）（非推奨アドレスを避けるため）
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.
自社のビジネスニーズをサポートする別のサイトBとのビジネスに不可欠な関係を持っているサイトAを考えてみましょう、2つのサイトが特別な高性能のISPとのサービスのために契約しています。これは、両方のサイトが異なるISPに持っていることを、通常のインターネット接続に加えています。高性能のISPは、高価であり、2つのサイトがお互いにのみ、ビジネスクリティカルなトラフィックのためにそれを使用したいです。
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.
各サイトには、二つのグローバルプレフィックス、高性能ISPから1と、それらの通常のISPからいずれかを持っています。サイトAは、プレフィックス2001を持っている：AAAA：AAAA ::高性能ISPとプレフィックス2007年/ 48：0：AAAA ::通常のISPから/ 48。 BBBB：高性能ISPとプレフィックス2007からBBBB :: / 48：0：BBBB :: / 48は通常のISPからサイトBは、プレフィックス2001を持っています。両方のサイト内のすべてのホストは、DNSに2つのアドレスを登録します。
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.
両方のサイト内のルーティングは、通常のISPへの出口に最もトラフィックを指示しますが、ルーティングは、高性能のISPへの出口に他のサイトの2001プレフィックスに送信されるトラフィックを誘導します。その高性能ISP接続の意図しない使用を防止するために、二つのサイトが他のサイトからのものではない高性能ISPから入るトラフィックを破棄するイングレスフィルタリングを実装します。
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)
候補ソースアドレス：2001：AAAA：AAAA :: Aまたは2007：0：AAAA :: AまたはFE80 ::宛先アドレス一覧：2001：BBBB：BBBB :: Bまたは2007：0：BBBB :: B結果：2007 ：0：BBBB :: B（SRC 2007：0：AAAA :: a）は、その後2001：BBBB：BBBB :: B（SRC 2001：AAAA：AAAA :: A）（最長一致プレフィックス）
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.
サイトA内のホストがサイトBにおけるホストへの接続を開始するときに、他の言葉では、トラフィックは、高性能のISPへの接続の利点を取ることはありません。これは、それらの所望の動作ではありません。
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)
候補ソースアドレス：2001：AAAA：AAAA :: Aまたは2007：0：AAAA :: AまたはFE80 ::宛先アドレス一覧：2001：CCCC：CCCC :: Cまたは2006：CCCC：CCCC :: C結果：2001 ：CCCC：CCCC :: C（SRC 2001：AAAA：AAAA :: a）は、その後2006：CCCC：CCCC :: C（SRC 2007：0：AAAA :: A）（最長一致プレフィックス）
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.
サイトAにおけるホストは、いくつかの他のサイトCにおけるホストへの接続を開始したときつまり、逆方向トラフィックは、高性能のISPを介して戻ってくることができます。繰り返しますが、これは彼らの希望の動作ではありません。
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:
ただし、サイトAとBの管理者は、ポリシーテーブルの設定を経由して、それらの所望の動作を実現することができます。例えば、彼らは次のポリシーテーブルを使用することができます。
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
接頭辞の優先順位は、レーベル:: 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)
候補ソースアドレス：2001：AAAA：AAAA :: Aまたは2007：0：AAAA :: AまたはFE80 ::宛先アドレス一覧：2001：BBBB：BBBB :: Bまたは2007：0：BBBB ::新しい結果B： 2001：BBBB：BBBB :: B（SRC 2001：AAAA：AAAA :: a）は、その後2007：0：BBBB :: B（SRC 2007：0：AAAA :: A）（高い優先順位を好みます）
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.
サイトAにおけるホストがサイトBにおけるホストへの接続を開始したときに所望のように換言すれば、トラフィックは、高性能のISPを使用します。
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)
候補ソースアドレス：2001：AAAA：AAAA :: Aまたは2007：0：AAAA :: AまたはFE80 ::宛先アドレスのリスト：2001：CCCC：CCCC :: Cまたは2006：CCCC：CCCC ::新しい結果C： 2006：CCCC：CCCC :: C（SRC 2007：0：AAAA :: a）は、その後2001：CCCC：CCCC :: C（SRC 2007：0：AAAA :: A）（最長一致プレフィックス）
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.
サイトAにおけるホストは、いくつかの他のサイトC内のホストへの接続を開始するときに、所望のように換言すれば、トラフィックは通常ISPを使用します。
Normative References
引用規格
[1] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
[1] HindenとR.とS.デアリング、 "IPバージョン6アドレッシング体系"、RFC 2373、1998年7月。
[2] Thompson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462 , December 1998.
[2]トンプソン、S.とT. Narten氏、 "IPv6のステートレスアドレス自動設定"、RFC 2462、1998年12月。
[3] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[3] Narten氏、T.およびR. Draves、 "IPv6におけるステートレスアドレス自動設定のための個人情報保護の拡張"、RFC 3041、2001年1月。
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[4]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[5] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
[5]カーペンター、B.およびK.ムーア、 "IPv4の雲を介したIPv6ドメインの接続"、RFC 3056、2001年2月。
[6] Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)", RFC 2765, February 2000.
[6] Nordmarkと、E.、 "ステートレスIP / ICMP翻訳アルゴリズム（SIIT）"、RFC 2765、2000年2月。
Informative References
参考文献
[7] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[7]ブラドナーの、S.、 "インターネット標準化プロセス - リビジョン3"、BCP 9、RFC 2026、1996年10月。
[8] Johnson, D. and C. Perkins, "Mobility Support in IPv6", Work in Progress.
[8]ジョンソン、D.とC.パーキンス、 "IPv6におけるモビリティサポート"、進行中の作業。
[9] S. Cheshire, B. Aboba, "Dynamic Configuration of IPv4 Link-local Addresses", Work in Progress.
[9] S.チェシャー、B. Aboba、 "IPv4のリンクローカルアドレスの動的構成"、ProgressのWork。
[10] Gilligan, R., Thomson, S., Bound, J. and W. Stevens, "Basic Socket Interface Extensions for IPv6", RFC 2553, March 1999.
[10]ギリガン、R.、トムソン、S.、バウンド、J.とW.スティーブンス、 "IPv6の基本的なソケットインタフェース拡張"、RFC 2553、1999年3月。
[11] S. Deering et. al, "IP Version 6 Scoped Address Architecture", Work in Progress.
[11] S.デアリングら。ら、「IPバージョン6つのスコープアドレスアーキテクチャ」、進行中の作業します。
[12] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[12] Rekhter、Y.、モスコウィッツ、B.、Karrenberg、D.、グルート、G.、およびE.リアド、 "個人的なインターネットのための配分"、BCP 5、RFC 1918、1996年2月。
[13] Baker, F, "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[13]ベイカー、F、 "IPバージョン4つのルータのための要件"、RFC 1812、1995年6月。
[14] Narten, T. and E. Nordmark, and W. Simpson, "Neighbor Discovery for IP Version 6", RFC 2461, December 1998.
[14] Narten氏、T.およびE. Nordmarkと、およびW.シンプソン、 "IPバージョン6のための近隣探索"、RFC 2461、1998年12月。
[15] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 Domains without Explicit Tunnels", RFC 2529, March 1999.
[15]カーペンター、B.及びC.チョン、 "明示的なトンネルなしでのIPv4ドメイン上のIPv6の送信"、RFC 2529、1999年3月。
[16] F. Templin et. al, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", Work in Progress.
[16] F.テンプリンら。アルは、「イントラサイト自動トンネルは、プロトコル（ISATAP）をアドレス指定」、進行中の作業。
[17] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", RFC 1933, April 1996.
[17]ギリガン、R.およびE. Nordmarkと、 "IPv6ホストとルータの移行メカニズム"、RFC 1933、1996年4月。
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.
著者はIPngのワーキンググループ、特にマルク・ブランシェ、ブライアン・カーペンター、マット・クロフォード、アラン・デュラン、スティーブデアリング、ロバート・エルツ、Jun-ichiro itojun Haginoは、トニーハイン、M.T.の貢献を認めるしたいと思いますホリンガー、神明達也、トーマスNarten氏、エリックNordmarkと、ケン・パウエル、マルックSavela、ペッカSavola、Heshamソリマン、デイヴ・ターラー、マウロTortonesi、オレTroan、およびスティグVenaas。また、匿名のIESGのレビューアが明確化のために多くの偉大なコメントや提案がありました。
Author's Address
著者のアドレス
Richard Draves Microsoft Research One Microsoft Way Redmond, WA 98052
リチャードDravesマイクロソフトリサーチ1つのマイクロソフト道、レッドモンド、WA 98052
Phone: +1 425 706 2268 EMail: richdr@microsoft.com
電話：+1 425 706 2268 Eメール：richdr@microsoft.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
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.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。