インターネットプロトコルバージョン6（IPv6）のデフォルトアドレス選択
英文を機械翻訳で日本語訳としています。日本語訳が正しくないことが考えられますので原文をメインとし、参考程度にご利用ください。
日本語訳
Internet Engineering Task Force (IETF) D. Thaler, Ed.
Request for Comments: 6724 Microsoft
Obsoletes: 3484 R. Draves
Category: Standards Track Microsoft Research
ISSN: 2070-1721 A. Matsumoto
NTT
T. Chown
University of Southampton
September 2012
Default Address Selection for Internet Protocol Version 6 (IPv6)
インターネットプロトコルバージョン6（IPv6）のデフォルトアドレス選択
Abstract
概要
This document describes two algorithms, one for source address selection and one 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アドレスを優先する場合があり、その逆の場合もあります。
Default address selection as defined in this specification applies to all IPv6 nodes, including both hosts and routers. This document obsoletes RFC 3484.
この仕様で定義されているデフォルトのアドレス選択は、ホストとルーターの両方を含むすべてのIPv6ノードに適用されます。 このドキュメントはRFC 3484を廃止します。
Status of This Memo
このメモのステータス
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。 これは、IETFコミュニティのコンセンサスを表しています。 これは公開レビューを受けており、Internet Engineering Steering Group（IESG）による公開が承認されています。 インターネット標準の詳細については、RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6724.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6724で入手できます。
Thaler, et al. Standards Track [Page 1] RFC 6724 Default Address Selection for IPv6 September 2012 Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 IETF Trustおよびドキュメントの作成者として特定された人物。 全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。 これらのドキュメントは、このドキュメントに関するあなたの権利と制限について説明しているため、注意深く確認してください。 このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................4
2. Context in Which the Algorithms Operate .........................4
2.1. Policy Table ...............................................6
2.2. Common Prefix Length .......................................7
3. Address Properties ..............................................7
3.1. Scope Comparisons ..........................................8
3.2. IPv4 Addresses and IPv4-Mapped Addresses ...................8
3.3. Other IPv6 Addresses with Embedded IPv4 Addresses ..........9
3.4. IPv6 Loopback Address and Other Format Prefixes ............9
3.5. Mobility Addresses .........................................9
4. Candidate Source Addresses .....................................10
5. Source Address Selection .......................................11
6. Destination Address Selection ..................................14
7. Interactions with Routing ......................................16
8. Implementation Considerations ..................................16
9. Security Considerations ........................................17
10. Examples ......................................................18
10.1. Default Source Address Selection .........................18
10.2. Default Destination Address Selection ....................19
10.3. Configuring Preference for IPv6 or IPv4 ..................20
10.3.1. Handling Broken IPv6 ..............................21
10.4. Configuring Preference for Link-Local Addresses ..........21
10.5. Configuring a Multi-Homed Site ...........................22
10.6. Configuring ULA Preference ...............................24
10.7. Configuring 6to4 Preference ..............................25
11. References ....................................................26
11.1. Normative References .....................................26
11.2. Informative References ...................................27
Appendix A. Acknowledgements .....................................29
Appendix B. Changes since RFC 3484 ...............................29
1.はじめに............................................... ..... 3
1.1.このドキュメントで使用されている規則........................4
2.アルゴリズムが動作するコンテキスト......................... 4
2.1.ポリシー表............................................... 6
2.2.共通のプレフィックス長......................................7
3.アドレスのプロパティ.............................................7
3.1.スコープの比較.......................................... 8
3.2. IPv4アドレスとIPv4マップアドレス................... 8
3.3. IPv4アドレスが埋め込まれたその他のIPv6アドレス.......... 9
3.4. IPv6ループバックアドレスとその他の形式のプレフィックス.....9
3.5.モビリティアドレス......................................... 9
4.候補ソースアドレス..................................... 10
5.発信元アドレスの選択.............................................11
6.宛先アドレスの選択.................................. 14
7.ルーティングとの相互作用.........................................16
8.実装に関する考慮事項.................................. 16
9.セキュリティに関する考慮事項.....................................17
10.例......................................................... ....18
10.1デフォルトの送信元アドレスの選択............................18
10.2デフォルトの宛先アドレスの選択.................... 19
10.3 IPv6またはIPv4のプリファレンスの設定.......................20
10.3.1.壊れたIPv6の処理....................................21
10.4.リンクローカルアドレスのプリファレンスの設定.......... 21
10.5.マルチホームサイトの構成........................... 22
10.6. ULA設定の構成............................... 24
10.7. 6to4設定の構成............................................25
11.参考資料............................................... ..... 26
11.1規範的な参考文献..................................... 26
11.2有益な参照................................... 27
付録A.謝辞..................................... 29
付録B. RFC 3484以降の変更............................... 29
Thaler, et al. Standards Track [Page 2] RFC 6724 Default Address Selection for IPv6 September 2012 1. Introduction
1.はじめに
The IPv6 addressing architecture [RFC4291] allows multiple unicast addresses to be assigned to interfaces. These addresses might have different reachability scopes (link-local, site-local, or global). These addresses might also be "preferred" or "deprecated" [RFC4862]. Privacy considerations have introduced the concepts of "public addresses" and "temporary addresses" [RFC4941]. The mobility architecture introduces "home addresses" and "care-of addresses" [RFC6275]. In addition, multi-homing situations will result in more addresses per node. For example, a node might have multiple interfaces, some of them tunnels or virtual interfaces, or a site might have multiple ISP attachments with a global prefix per ISP.
IPv6アドレス指定アーキテクチャ[RFC4291]では、複数のユニキャストアドレスをインターフェイスに割り当てることができます。 これらのアドレスは、異なる到達可能性スコープ（リンクローカル、サイトローカル、またはグローバル）を持つ場合があります。 これらのアドレスは、「推奨」または「非推奨」の場合もあります[RFC4862]。 プライバシーに関する考慮事項により、「パブリックアドレス」と「一時アドレス」[RFC4941]の概念が導入されました。 モビリティアーキテクチャは、「ホームアドレス」と「気付アドレス」[RFC6275]を導入しています。 さらに、マルチホーミングの状況では、ノードあたりのアドレスが多くなります。 たとえば、ノードに複数のインターフェースがあり、その一部がトンネルまたは仮想インターフェースである場合や、サイトに複数の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 [RFC3927], 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の両方をサポートするデュアルスタックまたはハイブリッドスタックの実装では、通信を開始するとき、たとえばDNS名前解決でIPv6とIPv4の両方のアドレスが生成され、ネットワークプロトコルスタックが IPv6とIPv4の両方の送信元アドレスを使用できます。 そのような場合、常にIPv6を優先するか、常にIPv4を優先する単純なポリシーでは、動作が低下する可能性があります。 一例として、DNS名がグローバルIPv6アドレスとグローバルIPv4アドレスに解決されるとします。 ノードがグローバルIPv6アドレスと169.254 / 16自動構成IPv4アドレス[RFC3927]を割り当てている場合、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 might 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 if the first one is not 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.
このドキュメントのアルゴリズムは、使用可能な一連のアドレスの部分的な順序を定義する一連のルールとして指定されています。 送信元アドレス選択の場合、ノードには通常、そのインターフェースに割り当てられた複数のアドレスがあり、セクション5の送信元アドレスの順序付けルールは、どのアドレスが「最適」なアドレスを使用するかを定義します。 宛先アドレスを選択する場合、DNSは指定された名前のアドレスのセットを返す可能性があり、アプリケーションは最初に使用するアドレスと、最初のアドレスに到達できない場合に他のアドレスを試す順序を決定する必要があります。 セクション6の宛先アドレスの順序付け規則は、DNSから返されるアドレスのセットに適用されると、そのような推奨順序を提供します。
Thaler, et al. Standards Track [Page 3]
RFC 6724 Default Address Selection for IPv6 September 2012
This document specifies source address selection and destination
address selection separately but uses 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 4862 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 4862の意味で「推奨」または「非推奨」）の送信元アドレスと宛先アドレスを選択しようとします。 さらに、このドキュメントでは、より適切な情報がない場合に同等のアドレスを選択するための、優先される最長のプレフィックスという好ましい方法を提案しています。
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.
このドキュメントで指定されている選択ルールは、アプリケーションまたは上位層の明示的な選択の正当な宛先または送信元アドレスをオーバーライドするものと解釈してはなりません。
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 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 BCP 14、RFC 2119 [RFC2119]で説明されているように解釈されます。
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.
アドレス選択のコンテキストは、宛先アドレスの選択と送信元アドレスの選択を分離する、最も一般的な実装アーキテクチャから派生しています。 したがって、これらのタスクには2つの別々のアルゴリズムがあります。 アルゴリズムは連携して機能するように設計されており、管理ポリシーを上書きするメカニズムを共有しています。
In this implementation architecture, applications use APIs such as getaddrinfo() [RFC3493] 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 Thaler, et al. Standards Track [Page 4] RFC 6724 Default Address Selection for IPv6 September 2012 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（）[RFC3493]などのAPIを使用します。 このリストには、IPv6アドレスとIPv4アドレスの両方が含まれる場合があります（IPv4マップアドレスとして表されることもあります）。 次に、アプリケーションは、connect（）またはsendto（）を使用して宛先アドレスをネットワークスタックに渡します。 次に、アプリケーションは通常、リストの最初のアドレスを試し、有効なアドレスが見つかるまでアドレスのリストをループします。 いずれにせよ、ネットワーク層は、いくつかの選択肢から宛先アドレスを選択する必要がある状況になることは決してありません。 アプリケーションはbind（）で送信元アドレスを指定することもありますが、多くの場合、送信元アドレスは指定されないままになります。 したがって、ネットワーク層は多くの場合、いくつかの選択肢から送信元アドレスを選択します。
As a consequence, we intend that implementations of APIs such as 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 might be possible, but this is not explored further here.
結果として、getaddrinfo（）などのAPIの実装は、ここで指定された宛先アドレス選択アルゴリズムを使用して、それらが返すIPv6およびIPv4アドレスのリストをソートすることを意図しています。 これとは別に、IPv6ネットワーク層は、アプリケーションまたは上位層がソースアドレスを指定していない場合に、ソースアドレス選択アルゴリズムを使用します。 この仕様をIPv4ネットワーク層の送信元アドレス選択に適用することは可能かもしれませんが、これについてはここでは詳しく説明しません。
Well-behaved applications SHOULD NOT simply use the first address returned from an API such as getaddrinfo() and then give up if it fails. For many applications, it is appropriate to iterate through the list of addresses returned from getaddrinfo() until a working address is found. For other applications, it might be appropriate to try multiple addresses in parallel (e.g., with some small delay in between) and use the first one to succeed.
正常に動作するアプリケーションは、getaddrinfo（）などのAPIから返された最初のアドレスを単純に使用してはならず、失敗した場合はあきらめないでください。 多くのアプリケーションでは、有効なアドレスが見つかるまで、getaddrinfo（）から返されたアドレスのリストを反復処理するのが適切です。 他のアプリケーションの場合、複数のアドレスを並行して試行し（その間に多少の遅延があるなど）、最初のアドレスを使用して成功することが適切な場合があります。
Although source and destination address selection is most typically done when initiating communication, a responder also must deal with address selection. In many cases, this is trivially dealt with by an application using the source address of a received packet as the response destination and the destination address of the received packet as the response source. Other cases, however, are handled like an initiator, such as when the request is multicast and hence source address selection must still occur when generating a response or when the request includes a list of the initiator's addresses from which to choose a destination. Finally, a third application scenario is that of a listening application choosing on what local addresses to listen. This third scenario is out of the scope of this document.
発信元と宛先のアドレス選択は、通信を開始するときに最も一般的に行われますが、レスポンダもアドレス選択を処理する必要があります。 多くの場合、これは、受信パケットの送信元アドレスを応答先として、受信パケットの宛先アドレスを応答元として使用するアプリケーションによって簡単に処理されます。 ただし、その他のケースは、要求がマルチキャストである場合など、イニシエーターのように処理されるため、応答の生成時、または要求に宛先を選択するイニシエーターのアドレスのリストが含まれる場合でも、送信元アドレスの選択を行う必要があります。 最後に、3番目のアプリケーションシナリオは、リッスンするアプリケーションがリッスンするローカルアドレスを選択するシナリオです。 この3番目のシナリオは、このドキュメントの範囲外です。
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, temporary addresses [RFC4941] are preferred over public addresses. In mobile situations [RFC6275], 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つのアドレスが同じスコープまたはタイプである宛先/ソースアドレスのペアを優先し、宛先アドレスの大きなスコープよりも小さなスコープを優先し、非推奨のソースアドレスを優先し、ネイティブアドレスの場合は移行アドレスの使用を回避することです。 が利用可能であり、他のすべてが等しい場合、可能な限り共通のプレフィックスが最も長いアドレスのペアを優先します。 送信元アドレスの選択では、一時アドレス[RFC4941]がパブリックアドレスよりも優先されます。 モバイルの状況では[RFC6275]、気付アドレスよりもホームアドレスが優先されます。 アドレスが同時にホームアドレスと気付アドレス（モバイルノードがそのアドレスに対して「在宅」であることを示す）である場合、ホーム/気付アドレスは、ホームアドレスのみまたはアドレスのみのアドレスよりも優先されます。 気付アドレス。
Thaler, et al. Standards Track [Page 5] RFC 6724 Default Address Selection for IPv6 September 2012 This specification optionally allows for the possibility of administrative configuration of policy (e.g., via manual configuration or a DHCP option such as that proposed in [ADDR-SEL-OPT]) that can override the default behavior of the algorithms. The policy override consists of the following set of state, which SHOULD be configurable:
この仕様はオプションで、アルゴリズムのデフォルトの動作を上書きできるポリシーの管理構成の可能性を許可します（たとえば、[ADDR-SEL-OPT]で提案されているような手動構成またはDHCPオプションを介して）。 ポリシーのオーバーライドは、次の状態セットで構成され、構成可能である必要があります（SHOULD）。
o Policy Table (Section 2.1): a table that specifies precedence
values and preferred source prefixes for destination prefixes.
oポリシーテーブル（セクション2.1）：宛先プレフィックスの優先値と優先ソースプレフィックスを指定するテーブル。
o Automatic Row Additions flag (Section 2.1): a flag that specifies
whether the implementation is permitted to automatically add site-
specific rows for certain types of addresses.
o自動行追加フラグ（2.1）：特定のタイプのアドレスに対してサイト固有の行を自動的に追加することを実装に許可するかどうかを指定するフラグ。
o Privacy Preference flag (Section 5): a flag that specifies whether
temporary source addresses or stable source addresses are
preferred by default when both types exist.
oプライバシー設定フラグ（セクション5）：両方のタイプが存在する場合、一時的な送信元アドレスまたは安定した送信元アドレスがデフォルトで優先されるかどうかを指定するフラグ
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 denoted Precedence(A) and a classification or label denoted Label(A).
ポリシーテーブルは、ルーティングテーブルによく似た、最長一致プレフィックスルックアップテーブルです。 アドレス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）の場合、アドレス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).
ラベル値Label（A）は、宛先アドレスプレフィックスで使用するために特定の送信元アドレスプレフィックスを優先するポリシーを許可します。 アルゴリズムは、Label（S）= Label（D）の場合、送信元アドレスSと宛先アドレスDの使用を優先します。
IPv6 implementations SHOULD support configurable address selection via a mechanism at least as powerful as the policy tables defined here. It is important that implementations provide a way to change the default policies as more experience is gained. Sections 10.3 through 10.7 provide examples of the kind of changes that might be needed.
IPv6実装は、少なくともここで定義されたポリシーテーブルと同じくらい強力なメカニズムを介して、構成可能なアドレス選択をサポートする必要があります（SHOULD）。 より多くの経験が得られたときに、実装がデフォルトのポリシーを変更する方法を提供することが重要です。 セクション10.3から10.7は、必要になる可能性のある変更の種類の例を示しています。
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）。
Thaler, et al. Standards Track [Page 6]
RFC 6724 Default Address Selection for IPv6 September 2012
Prefix Precedence Label
::1/128 50 0
::/0 40 1
::ffff:0:0/96 35 4
2002::/16 30 2
2001::/32 5 5
fc00::/7 3 13
::/96 1 3
fec0::/10 1 11
3ffe::/16 1 12
An implementation MAY automatically add additional site-specific rows
to the default table based on its configured addresses, such as for
Unique Local Addresses (ULAs) [RFC4193] and 6to4 [RFC3056] addresses,
for instance (see Sections 10.6 and 10.7 for examples). Any such
rows automatically added by the implementation as a result of address
acquisition MUST NOT override a row for the same prefix configured
via other means. That is, rows can be added but never updated
automatically. An implementation SHOULD provide a means (the
Automatic Row Additions flag) for an administrator to disable
automatic row additions.
実装は、たとえば、一意のローカルアドレス（ULA）[RFC4193]および6to4 [RFC3056]アドレスなどの構成済みアドレスに基づいて、デフォルトのテーブルにサイト固有の行を自動的に追加できます（例についてはセクション10.6および10.7を参照）。 。 アドレス取得の結果として実装によって自動的に追加されたそのような行は、他の方法で構成された同じプレフィックスの行をオーバーライドしてはなりません（MUST NOT）。 つまり、行は追加できますが、自動的に更新されることはありません。 実装は、管理者が自動行追加を無効にする手段（自動行追加フラグ）を提供する必要があります（SHOULD）。
As will become apparent later, one effect of the default policy table is to prefer using native source addresses with native destination addresses, 6to4 source addresses with 6to4 destination addresses, etc. 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の宛先アドレスなどを優先的に使用することです。 デフォルトのポリシーテーブルのもう1つの効果は、一致する送信元アドレスが利用可能な場合、IPv4アドレスを使用した通信よりもIPv6アドレスを使用した通信を優先することです。
Policy table entries for address prefixes that are not of global scope 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.
グローバルスコープではないアドレスプレフィックスのポリシーテーブルエントリは、オプションのゾーンインデックスで修飾できます。 その場合、ゾーンインデックスがアドレスのゾーンインデックスにも一致する場合、ルックアップ中にプレフィックステーブルエントリはアドレスに対してのみ一致します。
2.2. Common Prefix Length
2.2。 共通のプレフィックス長
We define the common prefix length CommonPrefixLen(S, D) of a source address S and a destination address D as the length of the longest prefix (looking at the most significant, or leftmost, bits) that the two addresses have in common, up to the length of S's prefix (i.e., the portion of the address not including the interface ID). For example, CommonPrefixLen(fe80::1, fe80::2) is 64.
送信元アドレスSと宛先アドレスDの共通プレフィックス長CommonPrefixLen（S、D）を、2つのアドレスが共通して上にある最長プレフィックス（最上位ビットまたは左端ビットを見て）の長さとして定義します Sのプレフィックスの長さ（つまり、インターフェースIDを含まないアドレスの部分）。 たとえば、CommonPrefixLen（fe80 :: 1、fe80 :: 2）は64です。
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 Thaler, et al. Standards Track [Page 7] RFC 6724 Default Address Selection for IPv6 September 2012 directly comparable to each other. For example, IPv6 unicast addresses can be "preferred" or "deprecated" [RFC4862], 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、マルチキャスト、ユニキャストなど）のアドレスが互いに比較されます。 これらのアドレスタイプの一部には、互いに直接比較できないプロパティがあります。 たとえば、IPv6ユニキャストアドレスは「推奨」または「非推奨」[RFC4862]にすることができますが、IPv4アドレスにはそのような概念はありません。 順序付けルールを使用してそのようなアドレスを比較する（たとえば、「非推奨」アドレスよりも「優先」アドレスを使用する）ために、次のマッピングが定義されています。
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), admin-local (0x4), site-local (0x5), organization-local (0x8), and global (0xE) scopes (Section 2.7 of [RFC4291]).
マルチキャスト宛先アドレスには、マルチキャストパケットの伝播を制御する4ビットのスコープフィールドがあります。 IPv6アドレッシングアーキテクチャは、インターフェイスローカル（0x1）、リンクローカル（0x2）、管理ローカル（0x4）、サイトローカル（0x5）、組織ローカル（0x8）、およびグローバル（0xE）スコープのスコープフィールド値を定義します （[RFC4291]のセクション2.7）。
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. (Note that IPv6 site-local unicast addresses are deprecated [RFC4291]. However, some existing implementations and deployments may still use these addresses; they are therefore included in the procedures in this specification. Also, note that ULAs are considered as global, not site-local, scope but are handled via the prefix policy table as discussed in Section 10.6.)
マルチキャスト宛先アドレスが存在する場合にソースアドレス選択アルゴリズムを使用するには、ユニキャストアドレススコープとマルチキャストアドレススコープを比較する必要があります。 ユニキャストリンクローカルをマルチキャストリンクローカルに、ユニキャストサイトローカルをマルチキャストサイトローカルに、ユニキャストグローバルスコープをマルチキャストグローバルスコープにマッピングします。 たとえば、ユニキャストサイトローカルはマルチキャストサイトローカルに等しく、マルチキャストサイトローカルは、マルチキャストグローバルに等しいユニキャストグローバルよりも小さいマルチキャスト組織ローカルよりも小さいです。 （IPv6サイトローカルユニキャストアドレスは非推奨であることに注意してください[RFC4291]。 ただし、一部の既存の実装およびデプロイメントでは、これらのアドレスが引き続き使用される場合があります。 したがって、これらはこの仕様の手順に含まれています。 また、ULAはサイトローカルではなくグローバルスコープと見なされますが、セクション10.6で説明するように、プレフィックスポリシーテーブルを介して処理されることに注意してください。
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）は、アドレスAのスコープを意味するように記述します。 たとえば、Aがリンクローカルユニキャストアドレスで、Bがサイトローカルマルチキャストアドレスの場合、Scope（A）<Scope（B）になります。
This mapping implicitly conflates unicast site boundaries and multicast site boundaries [RFC4007].
このマッピングは、ユニキャストサイト境界とマルチキャストサイト境界を暗黙的に統合します[RFC4007]。
3.2. IPv4 Addresses and IPv4-Mapped Addresses
3.2。 IPv4アドレスとIPv4マップアドレス
The destination address selection algorithm operates on both IPv6 and IPv4 addresses. For this purpose, IPv4 addresses MUST be represented as IPv4-mapped addresses [RFC4291]. For example, to look up the precedence or other attributes of an IPv4 address in the policy table, look up the corresponding IPv4-mapped IPv6 address.
宛先アドレス選択アルゴリズムは、IPv6アドレスとIPv4アドレスの両方で動作します。 この目的のために、IPv4アドレスはIPv4マップアドレス[RFC4291]として表現されなければなりません（MUST）。 たとえば、ポリシーテーブルでIPv4アドレスの優先順位または他の属性を検索するには、対応するIPv4にマップされたIPv6アドレスを検索します。
IPv4 addresses are assigned scopes as follows. IPv4 auto- configuration addresses [RFC3927], which have the prefix 169.254/16, are assigned link-local scope. IPv4 loopback addresses (Section Thaler, et al. Standards Track [Page 8] RFC 6724 Default Address Selection for IPv6 September 2012 4.2.2.11 of [RFC1812]), which have the prefix 127/8, are assigned link-local scope (analogously to the treatment of the IPv6 loopback address (Section 4 of [RFC4007])). Other IPv4 addresses (including IPv4 private addresses [RFC1918] and Shared Address Space addresses [RFC6598]) are assigned global scope.
IPv4アドレスには、次のようにスコープが割り当てられます。 接頭辞が169.254 / 16のIPv4自動構成アドレス[RFC3927]には、リンクローカルスコープが割り当てられます。 プレフィックス127/8を持つIPv4ループバックアドレス（[RFC1812]のセクション4.2.2.11）には、リンクローカルスコープが割り当てられます（IPv6ループバックアドレスの扱い（[RFC4007]のセクション4）と同様）。 その他のIPv4アドレス（IPv4プライベートアドレス[RFC1918]および共有アドレススペースアドレス[RFC6598]を含む）には、グローバルスコープが割り当てられます。
IPv4 addresses MUST be treated as having "preferred" (in the RFC 4862 sense) configuration status.
IPv4アドレスは、「RFC 4862の意味で」「推奨」構成ステータスを持つものとして扱う必要があります。
3.3. Other IPv6 Addresses with Embedded IPv4 Addresses
3.3。 IPv4アドレスが埋め込まれたその他のIPv6アドレス
IPv4-compatible addresses [RFC4291], IPv4-mapped [RFC4291], IPv4- converted [RFC6145], IPv4-translatable [RFC6145], and 6to4 addresses [RFC3056] contain an embedded IPv4 address. For the purposes of this document, these addresses MUST be treated as having global scope.
IPv4互換アドレス[RFC4291]、IPv4マップ[RFC4291]、IPv4変換[RFC6145]、IPv4-translatable [RFC6145]、6to4アドレス[RFC3056]には、埋め込まれたIPv4アドレスが含まれています。 このドキュメントでは、これらのアドレスをグローバルスコープとして扱う必要があります。
IPv4-compatible, IPv4-mapped, and IPv4-converted addresses MUST be treated as having "preferred" (in the RFC 4862 sense) configuration status.
IPv4互換、IPv4マップ、およびIPv4変換のアドレスは、「RFC 4862の意味で」「優先」構成ステータスを持つものとして扱われなければなりません（MUST）。
3.4. IPv6 Loopback Address and Other Format Prefixes
3.4。 IPv6ループバックアドレスとその他の形式のプレフィックス
The loopback address MUST be treated as having link-local scope (Section 4 of [RFC4007]) and "preferred" (in the RFC 4862 sense) configuration status.
ループバックアドレスは、リンクローカルスコープ（[RFC4007]のセクション4）および "推奨"（RFC 4862の意味で）構成ステータスを持つものとして扱われなければなりません（MUST）。
NSAP addresses and other addresses with as-yet-undefined format prefixes MUST be treated as having global scope and "preferred" (in the RFC 4862) configuration status. Later standards might supersede this treatment.
NSAPアドレスと、まだ未定義のフォーマットプレフィックスを持つ他のアドレスは、グローバルスコープと「推奨」（RFC 4862）構成ステータスを持つものとして扱われる必要があります。 後の基準はこの扱いに取って代わるかもしれません。
3.5. Mobility Addresses
3.5。 モビリティアドレス
Some nodes might support mobility using the concepts of home address and care-of address (for example, see [RFC6275]). 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 might have an address that is simultaneously a home address and a care-of address.
一部のノードは、ホームアドレスと気付アドレスの概念を使用してモビリティをサポートする場合があります（たとえば、[RFC6275]を参照）。 概念的には、ホームアドレスは、モバイルノードに割り当てられ、モバイルノードの永続アドレスとして使用されるIPアドレスです。 気付アドレスは、外部リンクにアクセスしている間のモバイルノードに関連付けられたIPアドレスです。 モバイルノードがホームリンク上にある場合、ホームアドレスと気付アドレスを同時に兼ねているアドレスが存在する可能性があります。
For the purposes of this document, it is sufficient to know whether one's own addresses are designated as home addresses or care-of addresses. Whether an address ought to be designated a home address or care-of address is outside the scope of this document.
このドキュメントでは、自分のアドレスがホームアドレスと気付アドレスのどちらとして指定されているかを知っていれば十分です。 アドレスをホームアドレスまたは気付アドレスのどちらに指定する必要があるかは、このドキュメントの範囲外です。
Thaler, et al. Standards Track [Page 9] RFC 6724 Default Address Selection for IPv6 September 2012 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）を記述して、住所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. Implementations that wish to support the use of global source addresses assigned to a loopback interface MUST behave as if the loopback interface originates and forwards the packet.
候補送信元アドレスは、宛先（「発信」インターフェース）への送信に使用されるインターフェースに割り当てられたユニキャストアドレスのセットであることが推奨されます。 ルーターでは、候補セットには、パケットを転送する任意のインターフェースに割り当てられたユニキャストアドレスが含まれる場合がありますが、これは以下で説明する制限に従います。 ループバックインターフェイスに割り当てられたグローバルソースアドレスの使用をサポートする実装は、ループバックインターフェイスがパケットを発信および転送するかのように動作する必要があります。
Discussion: The Neighbor Discovery Redirect mechanism [RFC4861]
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.
ディスカッション：近隣探索リダイレクトメカニズム[RFC4861]では、ルーターがリダイレクトを生成する前に、パケットの送信元アドレスが近隣を特定していることを確認する必要があるため、ホストが発信インターフェイスに割り当てられている送信元アドレスを選択すると便利です。
In some cases, the destination address might be qualified with a zone index or other information that will constrain the candidate set.
場合によっては、宛先セットがゾーンインデックスまたは候補セットを制約するその他の情報で修飾されることがあります。
For all 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 unicast 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, multicast addresses and the unspecified address MUST NOT be included in a candidate set.
いずれの場合も、マルチキャストアドレスと未指定のアドレスを候補セットに含めることはできません。
On IPv6-only nodes that support Stateless IP/ICMP Translation (SIIT) [RFC6145], if the destination address is an IPv4-converted address, then the candidate set MUST contain only IPv4-translatable addresses.
ステートレスIP / ICMP変換（SIIT）[RFC6145]をサポートするIPv6のみのノードでは、宛先アドレスがIPv4変換アドレスである場合、候補セットにはIPv4変換可能アドレスのみが含まれている必要があります。
Thaler, et al. Standards Track [Page 10] RFC 6724 Default Address Selection for IPv6 September 2012 If an application or upper layer specifies a source address, it may affect the choice of outgoing interface. Regardless, if the 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. 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.
アプリケーションまたは上位層が送信元アドレスを指定している場合、発信インターフェイスの選択に影響を与える可能性があります。 とにかく、アプリケーションまたは上位層が宛先の候補セットにない送信元アドレスを指定する場合、ネットワーク層はこれをエラーとして扱わなければなりません（MUST）。 アプリケーションまたは上位層が宛先の候補セットにある送信元アドレスを指定する場合、ネットワーク層はその選択を尊重しなければなりません（MUST）。 アプリケーションまたは上位層が送信元アドレスを指定しない場合、ネットワーク層は次のセクションで指定される送信元アドレス選択アルゴリズムを使用します。
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.
ソースアドレス選択アルゴリズムは、特定の宛先アドレスで使用する単一のソースアドレスを出力として生成します。 このアルゴリズムは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）のアドレスに「より大きい」順序を課します。 アルゴリズムが完了した後のリストの先頭にあるアドレスは、アルゴリズムが選択したアドレスです。
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 MUST be 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, the tiebreaker is implementation-specific.
候補セット内のアドレスの順序は、8つのペアワイズ比較ルールのリストによって定義されます。各ルールは、2つのソースアドレスに対して、「より大きい」、「より小さい」、または「等しい」の順序で配置されます。 お互い（そしてそのルール）。 特定のルールがタイを生成する場合、つまり、2つのアドレスに「等しい」結果を提供する場合、タイを破るためにタイされているアドレスのみに残りのルールを（順番に）適用する必要があります。 ルールによって1つの明確な「勝者」（または同点の場合は「勝者」のセット）が生成される場合、勝者セットにないそれらのアドレスは、以降のルールが残りのアドレスにのみ適用され、それ以上の検討から破棄されます。 8つのルールが単一のアドレスを選択できない場合、タイブレーカーは実装固有です。
Thaler, et al. Standards Track [Page 11] RFC 6724 Default Address Selection for IPv6 September 2012 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. If neither is stated to be preferred, this means that SA is "equal to" SB, and the remaining rules apply as noted above.
候補セットの2つのアドレスSAとSBを比較する場合、SAがSBより「大きい」ことを意味する「SAを優先する」と言い、同様に、SBが「より小さい」ことを意味する「SBを優先する」と言います。 どちらも好ましいと述べられていない場合、これはSAが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の場合、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：適切なスコープを優先します。 Scope（SA）<Scope（SB）の場合：Scope（SA）<Scope（D）の場合、SBを優先し、それ以外の場合はSAを優先します。 同様に、Scope（SB）<Scope（SA）の場合：Scope（SB）<Scope（D）の場合、SAを優先し、それ以外の場合はSBを優先します。
Discussion: This rule must be given high priority because it can
affect interoperability.
ディスカッション：このルールは相互運用性に影響を与える可能性があるため、優先度を高くする必要があります。
Rule 3: Avoid deprecated addresses. If one of the two source addresses is "preferred" and one of them is "deprecated" (in the RFC 4862 sense), then prefer the one that is "preferred".
ルール3：非推奨のアドレスを避けます。 2つの送信元アドレスの1つが「推奨」であり、それらの1つが「非推奨」である（RFC 4862の意味で）場合は、「推奨」の方を優先します。
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 supporting home addresses MUST 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 such as [RFC5014]). Use of the mechanism MUST only affect the selection rules for the invoking application.
ホームアドレスをサポートする実装は、アプリケーションがこの設定の意味を逆にして、ホームアドレスよりも気付アドレスを優先できるようにするメカニズムを提供する必要があります（たとえば、[RFC5014]などの適切なAPI拡張を介して）。 メカニズムの使用は、起動するアプリケーションの選択ルールにのみ影響を与えなければなりません（MUST）。
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：発信インターフェースを優先します。 Dへの送信に使用されるインターフェースにSAが割り当てられており、SBが別のインターフェースに割り当てられている場合は、SAを優先します。 同様に、SBがDへの送信に使用されるインターフェースに割り当てられ、SAが別のインターフェースに割り当てられている場合、SBを優先します。
Rule 5.5: Prefer addresses in a prefix advertised by the next-hop. If SA or SA's prefix is assigned by the selected next-hop that will be used to send to D and SB or SB's prefix is assigned by a different next-hop, then prefer SA. Similarly, if SB or SB's prefix is assigned by the next-hop that will be used to send to D and SA or SA's prefix is assigned by a different next-hop, then prefer SB.
ルール5.5：ネクストホップによってアドバタイズされるプレフィックスのアドレスを優先します。 Dへの送信に使用される選択したネクストホップによってSAまたはSAのプレフィックスが割り当てられ、SBまたはSBのプレフィックスが別のネクストホップによって割り当てられる場合は、SAを優先します。 同様に、SBまたはSBのプレフィックスがDへの送信に使用されるネクストホップによって割り当てられ、SAまたはSAのプレフィックスが別のネクストホップによって割り当てられる場合、SBを優先します。
Thaler, et al. Standards Track [Page 12]
RFC 6724 Default Address Selection for IPv6 September 2012
Discussion: An IPv6 implementation is not required to remember
which next-hops advertised which prefixes. The conceptual models
of IPv6 hosts in Section 5 of [RFC4861] and Section 3 of [RFC4191]
have no such requirement. Hence, Rule 5.5 is only applicable to
implementations that track this information.
考察：IPv6の実装では、どのネクストホップがどのプレフィックスをアドバタイズしたかを覚えておく必要はありません。 [RFC4861]のセクション5と[RFC4191]のセクション3のIPv6ホストの概念モデルには、そのような要件はありません。 したがって、ルール5.5は、この情報を追跡する実装にのみ適用されます。
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：一致するラベルを優先します。 Label（SA）= Label（D）およびLabel（SB）<> Label（D）の場合、SAを優先します。 同様に、Label（SB）= Label（D）およびLabel（SA）<> Label（D）の場合、SBを優先します。
Rule 7: Prefer temporary addresses. If SA is a temporary address and SB is a public address, then prefer SA. Similarly, if SB is a temporary address and SA is a public 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 public addresses over temporary addresses (e.g., via appropriate API extensions such as [RFC5014]). Use of the mechanism MUST only affect the selection rules for the invoking application. This default is intended to address privacy concerns as discussed in [RFC4941] but introduces a risk of 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 application compatibility considerations outweigh these privacy concerns MAY reverse the sense of this rule and by default prefer public addresses over temporary addresses. There SHOULD be an administrative option (the Privacy Preference flag) to change this preference, if the implementation supports temporary addresses. If there is no such option, there MUST be an administrative option to disable temporary addresses.
実装は、アプリケーションがこの設定の意味を逆転させ、一時アドレスよりもパブリックアドレスを優先できるようにするメカニズムを提供する必要があります（たとえば、[RFC5014]などの適切なAPI拡張を介して）。 メカニズムの使用は、起動するアプリケーションの選択ルールにのみ影響を与えなければなりません（MUST）。 このデフォルトは、[RFC4941]で説明されているプライバシーの問題に対処することを目的としていますが、一時アドレスのライフタイムが比較的短いため、または一時アドレスの逆ルックアップが失敗するかランダム化されたアドレスを返す可能性があるため、アプリケーションが失敗する可能性があります。名前。 アプリケーションの互換性に関する考慮事項がこれらのプライバシーの問題を上回る実装は、このルールの意味を逆転させ、デフォルトでは一時アドレスよりもパブリックアドレスを優先する場合があります。 実装が一時アドレスをサポートしている場合、この設定を変更するための管理オプション（プライバシー設定フラグ）が必要です（SHOULD）。 そのようなオプションがない場合は、一時アドレスを無効にする管理オプションが必要です。
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は、実装に送信元アドレスから選択する他の手段がある場合は、置き換えられる場合があります。 たとえば、実装が何らかの方法でどの送信元アドレスが「最良の」通信パフォーマンスをもたらすかを知っている場合。
Thaler, et al. Standards Track [Page 13] RFC 6724 Default Address Selection for IPv6 September 2012 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.
宛先アドレス選択アルゴリズムは、宛先アドレスのリストを受け取り、アドレスをソートして新しいリストを作成します。 ここでは、アドレス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 MUST 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.
Source（D）を書き込んで、宛先Dの選択されたソースアドレスを示します。 IPv6アドレスの場合、前のセクションではソースアドレス選択アルゴリズムを指定します。 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.
宛先Dに使用可能なソースアドレスがない場合、Source（D）は未定義であると言います。 IPv6アドレスの場合、これはCandidateSource（D）が空のセットである場合にのみ当てはまります。
The pair-wise comparison of destination addresses consists of ten rules, which MUST be applied in order. If a rule determines a result, then the remaining rules are not relevant and MUST be ignored. Subsequent rules act as tiebreakers for earlier rules. See the previous section for a lengthier description of how pair-wise comparison tiebreaker 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に到達できないことがわかっている場合、またはSource（DB）が定義されていない場合は、DAを優先します。 同様に、DAに到達できないことがわかっている場合、またはSource（DA）が定義されていない場合は、DBを優先します。
Discussion: An implementation might know that a particular
destination is unreachable in several ways. For example, the
destination might be reached through a network interface that is
currently unplugged. For example, the implementation might retain
information from Neighbor Unreachability Detection [RFC4861] for
some period of time. In any case, the determination of
unreachability for the purposes of this rule is implementation-
dependent.
ディスカッション：特定の宛先がいくつかの方法で到達できないことを実装が知っている場合があります。 たとえば、現在接続されていないネットワークインターフェイスを介して宛先に到達する場合があります。 たとえば、実装では、近隣到達不能検出[RFC4861]からの情報を一定期間保持する場合があります。 いずれの場合も、このルールの目的のための到達不能の決定は実装依存です。
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：一致するスコープを優先します。 Scope（DA）= Scope（Source（DA））およびScope（DB）<> Scope（Source（DB））の場合、DAを優先します。 同様に、Scope（DA）<> Scope（Source（DA））およびScope（DB）= Scope（Source（DB））の場合、DBを優先します。
Thaler, et al. Standards Track [Page 14] RFC 6724 Default Address Selection for IPv6 September 2012 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：非推奨のアドレスを避けます。 Source（DA）が廃止され、Source（DB）が廃止されない場合は、DBを優先してください。 同様に、Source（DA）が非推奨ではなく、Source（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：自宅の住所を優先します。 Source（DA）が同時にホームアドレスと気付アドレスであり、Source（DB）がそうでない場合、DAを優先します。 同様に、Source（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.
Source（DA）が単なるホームアドレスであり、Source（DB）が単なる気付アドレスである場合、DAを優先します。 同様に、Source（DA）が単なる気付アドレスであり、Source（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：一致するラベルを優先します。 Label（Source（DA））= Label（DA）およびLabel（Source（DB））<> Label（DB）の場合、DAを優先します。 同様に、Label（Source（DA））<> Label（DA）およびLabel（Source（DB））= Label（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：優先順位を高くする。 Precedence（DA）> Precedence（DB）の場合、DAを優先します。 同様に、Precedence（DA）<Precedence（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：ネイティブトランスポートを優先します。 カプセル化移行メカニズム（たとえば、IPv4のIPv6）を介してDAに到達し、DBに到達しない場合は、DBを優先します。 同様に、カプセル化によってDBに到達し、DAに到達しない場合は、DAを優先します。
Discussion: The IPv6 Rapid Deployment on IPv4 Infrastructures
(6rd) Protocol [RFC5969], the Intra-Site Automatic Tunnel
Addressing Protocol (ISATAP) [RFC5214], and configured tunnels
[RFC4213] 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).
ディスカッション：IPv4インフラストラクチャでのIPv6迅速な展開（第6）プロトコル[RFC5969]、サイト内自動トンネルアドレスプロトコル（ISATAP）[RFC5214]、および構成済みトンネル[RFC4213]は、宛先アドレスが行うカプセル化移行メカニズムの例です 特定のプレフィックスがないため、ポリシーテーブルでより低い優先順位を割り当てることができません。 実装は、インターフェース設定の概念を使用し、仮想インターフェース（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.
ルール8：小さいスコープを優先します。 Scope（DA）<Scope（DB）の場合、DAを優先します。 同様に、Scope（DA）> Scope（DB）の場合、DBを優先します。
Thaler, et al. Standards Track [Page 15] RFC 6724 Default Address Selection for IPv6 September 2012 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(Source(DA), DA) > CommonPrefixLen(Source(DB), DB), then prefer DA. Similarly, if CommonPrefixLen(Source(DA), DA) < CommonPrefixLen(Source(DB), DB), then prefer DB.
ルール9：一致する最長のプレフィックスを使用します。 DAとDBが同じアドレスファミリーに属している場合（両方がIPv6、または両方がIPv4です）：CommonPrefixLen（Source（DA）、DA）> CommonPrefixLen（Source（DB）、DB）の場合、DAを優先します。 同様に、CommonPrefixLen（Source（DA）、DA）<CommonPrefixLen（Source（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は、実装に宛先アドレスをソートする他の手段がある場合は、置き換えられる場合があります。 たとえば、実装が何らかの宛先アドレスを知っている場合、「最良の」通信パフォーマンスが得られます。
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 4862 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 4862の意味で）優先グローバルアドレスがあります。 グローバル宛先アドレスに送信するときに、一方のインターフェースを他方よりも優先するルーティング理由がない場合、実装は、宛先とより長い共通のプレフィックスを共有する送信元アドレスを使用できるようにする発信インターフェースを優先的に選択できます。
Implementations that support Rule 5.5 of source address selection (Section 5) 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 might prefer source addresses with prefix A and when sending via the second router, prefer source addresses with prefix B.
送信元アドレス選択の規則5.5（セクション5）をサポートする実装も、送信元アドレスの選択に影響を与えるためにルーターの選択を使用します。 たとえば、ホストが2つのルーターとのリンク上にあるとします。 一方のルーターはグローバルプレフィックスAをアドバタイズし、もう一方のルーターはグローバルプレフィックスBをアドバタイズしています。 次に、最初のルーターを介して送信する場合、ホストはプレフィックスAの送信元アドレスを優先し、2番目のルーターを介して送信する場合、プレフィックス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 Thaler, et al. Standards Track [Page 16] RFC 6724 Default Address Selection for IPv6 September 2012 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 re-sort the list.
宛先アドレス選択アルゴリズムには、潜在的な送信元アドレスに関する情報が必要です。 1つの可能な実装戦略は、getaddrinfo（）が宛先アドレスのリストを使用してネットワーク層を呼び出し、利用可能なソースアドレスの現在の完全な知識でネットワーク層のリストをソートし、ソートされたリストをgetaddrinfo（）に返すことです。 これは単純であり、最良の結果が得られますが、別のシステムコールのオーバーヘッドが発生します。 このオーバーヘッドを削減する1つの方法は、リゾルバーにソートされたアドレスリストをキャッシュすることです。これにより、同じ名前に対する後続の呼び出しでリストを再ソートする必要がなくなります。
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 might 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 MUST 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, source address assignments, or prefix policy table entries 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秒以上古い。 たとえば、実装は、これらのアルゴリズムに影響を与える可能性のあるルーティングテーブルエントリ、送信元アドレス割り当て、またはプレフィックスポリシーテーブルエントリが変更されたかどうかを確認するためにシステムコールを実行する場合があります。 別の戦略は、基礎となる状態が変更されるたびにインクリメントされる無効化カウンターを使用することです。 現在の無効化カウンター値を派生状態と共にキャッシュし、後で現在値と比較することにより、実装は派生状態が古くなっている可能性があるかどうかを検出できます。
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 because 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. The source address selection default preference for temporary addresses helps mitigate this concern.
このドキュメントで指定されているものを含め、ほとんどの送信元アドレス選択アルゴリズムは、潜在的なプライバシーの問題を明らかにしていることに注意してください。 非友好的なノードは、ターゲットホストに応答パケットのソースアドレスを選択させる要求パケットでターゲットノードをプローブすることにより、ターゲットノードのアドレス間の相関関係を推測できます（おそらく、要求パケットがエニーキャストアドレスまたはマルチキャストアドレスに送信されるか、あるいは 攻撃のために選択された上位層プロトコルは、応答パケットの特定の送信元アドレスを指定していません。 それ自体に異なるアドレスを使用することにより、不親切なノードはターゲットノードにターゲット自身のアドレスを公開させる可能性があります。 一時アドレスの送信元アドレス選択のデフォルト設定は、この懸念を軽減するのに役立ちます。
Thaler, et al. Standards Track [Page 17] RFC 6724 Default Address Selection for IPv6 September 2012 Similarly, most source and destination address selection algorithms, including the one specified in this document, influence the choice of network path taken (as do routing algorithms that are orthogonal to, but used together with, such algorithms) and hence whether data might be sent over a path or network that might be more or less trusted than other paths or networks. Administrators should consider the security impact of the rows they configure in the prefix policy table, just as they should consider the security impact of the interface metrics used in the routing algorithms.
同様に、このドキュメントで指定されているものを含む、ほとんどの送信元および宛先アドレス選択アルゴリズムは、使用されるネットワークパスの選択（このようなアルゴリズムと直交しているが、そのようなアルゴリズムと一緒に使用されるルーティングアルゴリズムと同様）に影響を与え、したがってデータが送信されるかどうかに影響します 他のパスまたはネットワークよりも多かれ少なかれ信頼されている可能性があるパスまたはネットワークを介して。 管理者は、ルーティングアルゴリズムで使用されるインターフェイスメトリックのセキュリティへの影響を考慮する必要があるのと同様に、プレフィックスポリシーテーブルで構成する行のセキュリティへの影響を考慮する必要があります。
In addition, some address selection rules might be administratively configurable. Care must be taken to make sure that all administrative options are secured against illicit modification, or else an attacker could redirect and/or block traffic.
さらに、一部のアドレス選択ルールは管理上構成可能である場合があります。 すべての管理オプションが不正な変更から保護されていることを確認するように注意する必要があります。そうしないと、攻撃者がトラフィックをリダイレクトまたはブロックする可能性があります。
10. Examples
10.例
This section contains a number of examples, first showing default behavior and then demonstrating the utility of policy table configuration. These examples are provided for illustrative purposes; they are not to 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:db8:1::1 Candidate Source Addresses: 2001:db8:3::1 or fe80::1 Result: 2001:db8::1 (prefer appropriate scope) Destination: ff05::1 Candidate Source Addresses: 2001:db8:3::1 or fe80::1 Result: 2001:db8:3::1 (prefer appropriate scope) Destination: 2001:db8:1::1 Candidate Source Addresses: 2001:db8:1::1 (deprecated) or 2001:db8:2::1 Result: 2001:db8:1::1 (prefer same address) Destination: fe80::1 Candidate Source Addresses: fe80::2 (deprecated) or 2001:db8:1::1 Result: fe80::2 (prefer appropriate scope) Destination: 2001:db8:1::1 Candidate Source Addresses: 2001:db8:1::2 or 2001:db8:3::2 Result: 2001:db8:1:::2 (longest matching prefix) Thaler, et al. Standards Track [Page 18] RFC 6724 Default Address Selection for IPv6 September 2012 Destination: 2001:db8:1::1 Candidate Source Addresses: 2001:db8:1::2 (care-of address) or 2001: db8:3::2 (home address) Result: 2001:db8:3::2 (prefer home address) Destination: 2002:c633:6401::1 Candidate Source Addresses: 2002:c633:6401::d5e3:7953:13eb:22e8 (temporary) or 2001:db8:1::2 Result: 2002:c633:6401::d5e3:7953:13eb:22e8 (prefer matching label) Destination: 2001:db8:1::d5e3:0:0:1 Candidate Source Addresses: 2001:db8:1::2 (public) or 2001:db8:1::d5e3:7953:13eb:22e8 (temporary) Result: 2001:db8:1::d5e3:7953:13eb:22e8 (prefer temporary 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:db8:1::2 or fe80::1 or 169.254.13.78 Destination Address List: 2001:db8:1::1 or 198.51.100.121 Result: 2001:db8:1::1 (src 2001:db8:1::2) then 198.51.100.121 (src 169.254.13.78) (prefer matching scope) Candidate Source Addresses: fe80::1 or 198.51.100.117 Destination Address List: 2001:db8:1::1 or 198.51.100.121 Result: 198.51.100.121 (src 198.51.100.117) then 2001:db8:1::1 (src fe80::1) (prefer matching scope) Candidate Source Addresses: 2001:db8:1::2 or fe80::1 or 10.1.2.4 Destination Address List: 2001:db8:1::1 or 10.1.2.3 Result: 2001:db8:1::1 (src 2001:db8:1::2) then 10.1.2.3 (src 10.1.2.4) (prefer higher precedence) Candidate Source Addresses: 2001:db8:1::2 or fe80::2 Destination Address List: 2001:db8:1::1 or fe80::1 Result: fe80::1 (src fe80::2) then 2001:db8:1::1 (src 2001:db8:1::2) (prefer smaller scope) Candidate Source Addresses: 2001:db8:1::2 (care-of address) or 2001: db8:3::1 (home address) or fe80::2 (care-of address) Destination Address List: 2001:db8:1::1 or fe80::1 Result: 2001:db8:1::1 (src 2001:db8:3::1) then fe80::1 (src fe80::2) (prefer home address) Thaler, et al. Standards Track [Page 19] RFC 6724 Default Address Selection for IPv6 September 2012 Candidate Source Addresses: 2001:db8:1::2 or fe80::2 (deprecated) Destination Address List: 2001:db8:1::1 or fe80::1 Result: 2001:db8:1::1 (src 2001:db8:1::2) then fe80::1 (src fe80::2) (avoid deprecated addresses) Candidate Source Addresses: 2001:db8:1::2 or 2001:db8:3f44::2 or fe80::2 Destination Address List: 2001:db8:1::1 or 2001:db8:3ffe::1 Result: 2001:db8:1::1 (src 2001:db8:1::2) then 2001:db8:3ffe::1 (src 2001:db8:3f44::2) (longest matching prefix) Candidate Source Addresses: 2002:c633:6401::2 or fe80::2 Destination Address List: 2002:c633:6401::1 or 2001:db8:1::1 Result: 2002:c633:6401::1 (src 2002:c633:6401::2) then 2001:db8:1::1 (src 2002:c633:6401::2) (prefer matching label) Candidate Source Addresses: 2002:c633:6401::2 or 2001:db8:1::2 or fe80::2 Destination Address List: 2002:c633:6401::1 or 2001:db8:1::1 Result: 2001:db8:1::1 (src 2001:db8:1::2) then 2002:c633:6401::1 (src 2002:c633:6401::2) (prefer higher precedence) 10.3. Configuring Preference for IPv6 or IPv4
10.3 IPv6またはIPv4のプリファレンスの構成
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を使用します。 管理者は、:: ffff：0.0.0.0/96プレフィックスに高い優先順位を与えることにより、IPv4アドレスを優先するようにポリシーテーブルを変更できます。
Prefix Precedence Label
::1/128 50 0
::/0 40 1
::ffff:0:0/96 100 4
2002::/16 30 2
2001::/32 5 5
fc00::/7 3 13
::/96 1 3
fec0::/10 1 11
3ffe::/16 1 12
This change to the default policy table produces the following
behavior:
デフォルトのポリシーテーブルに対するこの変更により、次の動作が発生します。
Candidate Source Addresses: 2001:db8::2 or fe80::1 or 169.254.13.78 Destination Address List: 2001:db8::1 or 198.51.100.121 Unchanged Result: 2001:db8::1 (src 2001:db8::2) then 198.51.100.121 (src 169.254.13.78) (prefer matching scope) Thaler, et al. Standards Track [Page 20] RFC 6724 Default Address Selection for IPv6 September 2012 Candidate Source Addresses: fe80::1 or 198.51.100.117 Destination Address List: 2001:db8::1 or 198.51.100.121 Unchanged Result: 198.51.100.121 (src 198.51.100.117) then 2001:db8::1 (src fe80::1) (prefer matching scope) Candidate Source Addresses: 2001:db8::2 or fe80::1 or 10.1.2.4 Destination Address List: 2001:db8::1 or 10.1.2.3 New Result: 10.1.2.3 (src 10.1.2.4) then 2001:db8::1 (src 2001:db8::2) (prefer higher precedence) 10.3.1. Handling Broken IPv6
10.3.1。 壊れたIPv6の処理
One problem in practice that has been recently observed occurs when a host has IPv4 connectivity to the Internet but has "broken" IPv6 connectivity to the Internet in that it has a global IPv6 address but is disconnected from the IPv6 Internet. Since the default policy table prefers IPv6, this can result in unwanted timeouts.
ホストがインターネットにIPv4接続しているが、グローバルIPv6アドレスを持っているがIPv6インターネットから切断されているという点で、インターネットへのIPv6接続が「壊れている」場合、実際に最近観察された1つの問題が発生します。 デフォルトのポリシーテーブルはIPv6を優先するため、これにより不要なタイムアウトが発生する可能性があります。
This can be solved by configuring the table to prefer IPv4 as shown above. An implementation that has some means to detect that it is not connected to the IPv6 Internet MAY do this automatically. An implementation could instead treat it as part of its implementation of Rule 1 (avoid unusable destinations).
これは、上記のようにIPv4を優先するようにテーブルを構成することで解決できます。 IPv6インターネットに接続されていないことを検出する何らかの手段を持つ実装は、これを自動的に実行してもよい（MAY）。 代わりに、実装では、ルール1の実装の一部として扱うことができます（使用できない宛先は避けてください）。
10.4. Configuring Preference for Link-Local Addresses
10.4。 リンクローカルアドレスの優先設定
The destination address selection rules give preference to destinations of smaller scope. For example, a link-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 link-local destinations:
宛先アドレス選択ルールは、より小さなスコープの宛先を優先します。 たとえば、リンクローカルの宛先は、グローバルスコープの宛先の前にソートされますが、2つの宛先が同等に適している場合です。 管理者は、ポリシーテーブルを変更してこの設定を元に戻し、リンクローカル宛先の前にグローバル宛先をソートできます。
Prefix Precedence Label
::1/128 50 0
::/0 40 1
::ffff:0:0/96 35 4
fe80::/10 33 1
2002::/16 30 2
2001::/32 5 5
fc00::/7 3 13
::/96 1 3
fec0::/10 1 11
3ffe::/16 1 12
Thaler, et al. Standards Track [Page 21]
RFC 6724 Default Address Selection for IPv6 September 2012
This change to the default policy table produces the following
behavior:
デフォルトのポリシーテーブルに対するこの変更により、次の動作が発生します。
Candidate Source Addresses: 2001:db8::2 or fe80::2 Destination Address List: 2001:db8::1 or fe80::1 New Result: 2001:db8::1 (src 2001:db8::2) then fe80::1 (src fe80::2) (prefer higher precedence) Candidate Source Addresses: 2001:db8::2 (deprecated) or fe80::2 Destination Address List: 2001:db8::1 or fe80::1 Unchanged Result: fe80::1 (src fe80::2) then 2001:db8::1 (src 2001: db8::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.
別のサイト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:db8:1aaa::/48 from the high-performance ISP and prefix 2001:db8:70aa::/48 from its normal ISP. Site B has prefix 2001:db8:1bbb::/48 from the high- performance ISP and prefix 2001:db8:70bb::/48 from its normal ISP. All hosts in both sites register two addresses in the DNS.
各サイトには2つのグローバルプレフィックスがあり、1つは高性能ISPからのもので、もう1つは通常のISPからのものです。 サイトAには、高性能ISPからのプレフィックス2001：db8：1aaa :: / 48と、通常のISPからのプレフィックス2001：db8：70aa :: / 48があります。 サイトBには、高性能ISPからのプレフィックス2001：db8：1bbb :: / 48と、通常のISPからのプレフィックス2001：db8：70bb :: / 48があります。 両方のサイトのすべてのホストは、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への出力に転送しますが、ルーティングは、他のサイトの2001プレフィックスに送信されたトラフィックを高性能ISPへの出力に転送します。 高性能ISP接続の意図しない使用を防ぐために、2つのサイトは、他のサイトからではなく、高性能ISPから入ってくるトラフィックを破棄するための入口フィルタリングを実装します。
The default policy table and address selection rules produce the following behavior:
デフォルトのポリシーテーブルとアドレス選択ルールは、次の動作を生成します。
Candidate Source Addresses: 2001:db8:1aaa::a or 2001:db8:70aa::a or fe80::a Destination Address List: 2001:db8:1bbb::b or 2001:db8:70bb::b Result: 2001:db8:70bb::b (src 2001:db8:70aa::a) then 2001:db8:1bbb::b (src 2001:db8:1aaa::a) (longest matching prefix) Thaler, et al. Standards Track [Page 22] RFC 6724 Default Address Selection for IPv6 September 2012 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:db8:1aaa::a or 2001:db8:70aa::a or fe80::a Destination Address List: 2001:db8:1ccc::c or 2001:db8:6ccc::c Result: 2001:db8:1ccc::c (src 2001:db8:1aaa::a) then 2001:db8:6ccc::c (src 2001:db8:70aa::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 might 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/128 50 0
2001:db8:1aaa::/48 43 6
2001:db8:1bbb::/48 43 6
::/0 40 1
::ffff:0:0/96 35 4
2002::/16 30 2
2001::/32 5 5
fc00::/7 3 13
::/96 1 3
fec0::/10 1 11
3ffe::/16 1 12
This policy table produces the following behavior:
このポリシーテーブルは、次の動作を生成します。
Candidate Source Addresses: 2001:db8:1aaa::a or 2001:db8:70aa::a or fe80::a Destination Address List: 2001:db8:1bbb::b or 2001:db8:70bb::b New Result: 2001:db8:1bbb::b (src 2001:db8:1aaa::a) then 2001:db8: 70bb::b (src 2001:db8:70aa::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.
つまり、サイトAのホストがサイトBのホストへの接続を開始すると、トラフィックは必要に応じて高性能ISPを使用します。
Thaler, et al. Standards Track [Page 23] RFC 6724 Default Address Selection for IPv6 September 2012 Candidate Source Addresses: 2001:db8:1aaa::a or 2001:db8:70aa::a or fe80::a Destination Address List: 2001:db8:1ccc::c or 2001:db8:6ccc::c New Result: 2001:db8:6ccc::c (src 2001:db8:70aa::a) then 2001:db8: 1ccc::c (src 2001:db8:70aa::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.
つまり、サイトAのホストが他のサイトCのホストへの接続を開始すると、トラフィックは必要に応じて通常のISPを使用します。
10.6. Configuring ULA Preference
10.6。 ULA設定の構成
Sections 2.1.4, 2.2.2, and 2.2.3 of RFC 5220 [RFC5220] describe address selection problems related to Unique Local Addresses (ULAs) [RFC4193]. By default, global IPv6 destinations are preferred over ULA destinations, since an arbitrary ULA is not necessarily reachable:
RFC 5220 [RFC5220]のセクション2.1.4、2.2.2、および2.2.3では、一意のローカルアドレス（ULA）[RFC4193]に関連するアドレス選択の問題について説明しています。 デフォルトでは、任意のULAが必ずしも到達可能ではないため、グローバルIPv6宛先がULA宛先よりも優先されます。
Candidate Source Addresses: 2001:db8:1::1 or fd11:1111:1111:1::1 Destination Address List: 2001:db8:2::2 or fd22:2222:2222:2::2 Result: 2001:db8:2::2 (src 2001:db8:1::1) then fd22:2222:2222:2::2 (src fd11:1111:1111:1::1) (prefer higher precedence) However, a site-specific policy entry can be used to cause ULAs within a site to be preferred over global addresses as follows.
ただし、次のように、サイト固有のポリシーエントリを使用して、サイト内のULAをグローバルアドレスよりも優先させることができます。
Prefix Precedence Label
::1/128 50 0
fd11:1111:1111::/48 45 14
::/0 40 1
::ffff:0:0/96 35 4
2002::/16 30 2
2001::/32 5 5
fc00::/7 3 13
::/96 1 3
fec0::/10 1 11
3ffe::/16 1 12
Such a configuration would have the following effect:
このような構成には次の効果があります。
Candidate Source Addresses: 2001:db8:1::1 or fd11:1111:1111:1::1 Destination Address List: 2001:db8:2::2 or fd22:2222:2222:2::2 Unchanged Result: 2001:db8:2::2 (src 2001:db8:1::1) then fd22:2222: 2222:2::2 (src fd11:1111:1111:1::1) (prefer higher precedence) Thaler, et al. Standards Track [Page 24] RFC 6724 Default Address Selection for IPv6 September 2012 Candidate Source Addresses: 2001:db8:1::1 or fd11:1111:1111:1::1 Destination Address List: 2001:db8:2::2 or fd11:1111:1111:2::2 New Result: fd11:1111:1111:2::2 (src fd11:1111:1111:1::1) then 2001: db8:2::2 (src 2001:db8:1::1) (prefer higher precedence) Since ULAs are defined to have a /48 site prefix, an implementation might choose to add such a row automatically on a machine with a ULA.
ULAは/ 48サイトプレフィックスを持つように定義されているため、実装では、ULAを備えたマシンにそのような行を自動的に追加することを選択できます。
It is also worth noting that ULAs are assigned global scope. As such, the existence of one or more rows in the prefix policy table is important so that source address selection does not choose a ULA purely based on longest match:
ULAにはグローバルスコープが割り当てられていることにも注意してください。 そのため、プレフィックスポリシーテーブルに1つまたは複数の行が存在することが重要です。これにより、送信元アドレスの選択で、最も長い一致のみに基づいてULAが選択されなくなります。
Candidate Source Addresses: 2001:db8:1::1 or fd11:1111:1111:1::1 Destination Address List: ff00:1 Result: 2001:db8:1::1 (prefer matching label) 10.7. Configuring 6to4 Preference
10.7。 6to4設定の構成
By default, NATed IPv4 is preferred over 6to4-relayed connectivity:
デフォルトでは、NATされたIPv4が6to4リレー接続よりも優先されます。
Candidate Source Addresses: 2002:c633:6401::2 or 10.1.2.3 Destination Address List: 2001:db8:1::1 or 203.0.113.1 Result: 203.0.113.1 (src 10.1.2.3) then 2001:db8:1::1 (src 2002:c633: 6401::2) (prefer matching label) However, NATed IPv4 is now also preferred over 6to4-to-6to4 connectivity by default. Since a 6to4 prefix might be used natively within an organization, a site-specific policy entry can be used to cause native IPv6 communication (using a 6to4 prefix) to be preferred over NATed IPv4 as follows.
ただし、NATされたIPv4は、デフォルトで6to4から6to4への接続よりも優先されるようになりました。 6to4プレフィックスは組織内でネイティブに使用される可能性があるため、サイト固有のポリシーエントリを使用して、ネイティブIPv6通信（6to4プレフィックスを使用）を次のようにNATed IPv4よりも優先させることができます。
Prefix Precedence Label
::1/128 50 0
2002:c633:6401::/48 45 14
::/0 40 1
::ffff:0:0/96 35 4
2002::/16 30 2
2001::/32 5 5
fc00::/7 3 13
::/96 1 3
fec0::/10 1 11
3ffe::/16 1 12
Thaler, et al. Standards Track [Page 25]
RFC 6724 Default Address Selection for IPv6 September 2012
Such a configuration would have the following effect:
このような構成には次の効果があります。
Candidate Source Addresses: 2002:c633:6401:1::1 or 10.1.2.3 Destination Address List: 2002:c633:6401:2::2 or 203.0.113.1 New Result: 2002:c633:6401:2::2 (src 2002:c633:6401:1::1) then 203.0.113.1 (sec 10.1.2.3) (prefer higher precedence) Since 6to4 addresses are defined to have a /48 site prefix, an implementation might choose to add such a row automatically on a machine with a native IPv6 address with a 6to4 prefix.
6to4アドレスは/ 48サイトプレフィックスを持つように定義されているため、実装では、6to4プレフィックスを持つネイティブIPv6アドレスを持つマシンにそのような行を自動的に追加する場合があります。
11. References
11.リファレンス
11.1. Normative References
11.1 規範的な参考文献
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6
Domains via IPv4 Clouds", RFC 3056, February 2001.
[RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local
Addresses", RFC 3879, September 2004.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6
Unicast Addresses", RFC 4193, October 2005.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through
Network Address Translations (NATs)", RFC 4380,
February 2006.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6
Stateless Address Autoconfiguration", RFC 4862,
September 2007.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, September 2007.
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
Algorithm", RFC 6145, April 2011.
Thaler, et al. Standards Track [Page 26]
RFC 6724 Default Address Selection for IPv6 September 2012
11.2. Informative References
11.2 参考情報
[ADDR-SEL-OPT] Matsumoto, A., Fujisaki, T., Kato, J., and T. Chown,
"Distributing Address Selection Policy using DHCPv6",
Work in Progress, August 2012.
[RFC1794] Brisco, T., "DNS Support for Load Balancing",
RFC 1794, April 1995.
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers",
RFC 1812, June 1995.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot,
G., and E. Lear, "Address Allocation for Private
Internets", BCP 5, RFC 1918, February 1996.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress
Filtering: Defeating Denial of Service Attacks which
employ IP Source Address Spoofing", BCP 38, RFC 2827,
May 2000.
[RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and
W. Stevens, "Basic Socket Interface Extensions for
IPv6", RFC 3493, February 2003.
[RFC3701] Fink, R. and R. Hinden, "6bone (IPv6 Testing Address
Allocation) Phaseout", RFC 3701, March 2004.
[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
Configuration of IPv4 Link-Local Addresses",
RFC 3927, May 2005.
[RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E.,
and B. Zill, "IPv6 Scoped Address Architecture",
RFC 4007, March 2005.
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences
and More-Specific Routes", RFC 4191, November 2005.
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition
Mechanisms for IPv6 Hosts and Routers", RFC 4213,
October 2005.
Thaler, et al. Standards Track [Page 27]
RFC 6724 Default Address Selection for IPv6 September 2012
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H.
Soliman, "Neighbor Discovery for IP version 6
(IPv6)", RFC 4861, September 2007.
[RFC5014] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6
Socket API for Source Address Selection", RFC 5014,
September 2007.
[RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site
Automatic Tunnel Addressing Protocol (ISATAP)",
RFC 5214, March 2008.
[RFC5220] Matsumoto, A., Fujisaki, T., Hiromi, R., and K.
Kanayama, "Problem Statement for Default Address
Selection in Multi-Prefix Environments: Operational
Issues of RFC 3484 Default Rules", RFC 5220,
July 2008.
[RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on
IPv4 Infrastructures (6rd) -- Protocol
Specification", RFC 5969, August 2010.
[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility
Support in IPv6", RFC 6275, July 2011.
[RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe,
C., and M. Azinger, "IANA-Reserved IPv4 Prefix for
Shared Address Space", BCP 153, RFC 6598, April 2012.
Thaler, et al. Standards Track [Page 28]
RFC 6724 Default Address Selection for IPv6 September 2012
Appendix A. Acknowledgements
RFC 3484 [RFC3484] acknowledged 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.
This revision was heavily influenced by the work by Arifumi
Matsumoto, Jun-ya Kato, and Tomohiro Fujisaki in a working document
that made proposals for this revision to adopt, with input from Pekka
Savola, Remi Denis-Courmont, Francois-Xavier Le Bail, and the 6man
Working Group. Dmitry Anipko, Mark Andrews, Ray Hunter, and Wes
George also provided valuable feedback on this revision.
Appendix B. Changes since RFC 3484
付録B. RFC 3484以降の変更
Some changes were made to the default policy table that were deemed to be universally useful and cause no harm in every reasonable network environment. In doing so, care was taken to use the same preference and label values as in RFC 3484 whenever possible and for new rows to use label values less likely to collide with values that might already be in use in additional rows on some hosts. These changes are:
デフォルトのポリシーテーブルにいくつかの変更が加えられましたが、これらは普遍的に有用であり、あらゆる合理的なネットワーク環境に害を及ぼすことはないと考えられています。 その際、RFC 3484と同じ設定とラベル値を可能な限り使用し、新しい行が一部のホストの追加行ですでに使用されている可能性のある値と衝突する可能性が低いラベル値を使用するように注意が払われました。 これらの変更は次のとおりです。
1. Added the Teredo [RFC4380] prefix (2001::/32), with the
preference and label values already widely used in popular
implementations.
1. Teredo [RFC4380]プレフィックス（2001 :: / 32）を追加しました。一般的な実装ですでに広く使用されている設定とラベルの値が含まれています。
2. Added a row for ULAs (fc00::/7) below native IPv6 since they are
not globally reachable, as discussed in Section 10.6.
2.セクション10.6で説明するように、グローバルに到達できないため、ネイティブIPv6の下にULA（fc00 :: / 7）の行を追加しました。
3. Added a row for site-local addresses (fec0::/10) in order to
depreference them, for consistency with the example in
Section 10.3, since they are deprecated [RFC3879].
3.サイトローカルアドレス（fec0 :: / 10）の行を追加しました。これらは非推奨であるため、セクション10.3の例との一貫性を保つためです。[RFC3879]。
4. Depreferenced 6to4 (2002::/32) below native IPv4 since 6to4
connectivity is less reliable today (and is expected to be phased
out over time, rather than becoming more reliable). It remains
above Teredo since 6to4 is more efficient in terms of connection
establishment time, bandwidth, and server load.
4.現在、6to4接続は信頼性が低いため、ネイティブIPv4より優先度が低い6to4（2002 :: / 32）です（信頼性が高まるのではなく、時間の経過とともに段階的に廃止される予定です）。 接続確立時間、帯域幅、サーバー負荷の点で6to4の方が効率的であるため、Teredoを上回っています。
5. Depreferenced IPv4-Compatible addresses (::/96) since they are
now deprecated [RFC4291] and not in common use.
5. IPv4互換アドレス（:: / 96）が非推奨になりました。これらは非推奨になり[RFC4291]、一般的に使用されなくなったためです。
Thaler, et al. Standards Track [Page 29]
RFC 6724 Default Address Selection for IPv6 September 2012
6. Added a row for 6bone testing addresses (3ffe::/16) in order to
depreference them as they have also been phased out [RFC3701].
6. 6boneテストアドレス（3ffe :: / 16）の行が追加されました。これらも廃止されているため、優先度を下げるためです[RFC3701]。
7. Added optional ability for an implementation to add automatic
rows to the table for site-specific ULA prefixes and site-
specific native 6to4 prefixes.
7.サイト固有のULAプレフィックスとサイト固有のネイティブ6to4プレフィックスのテーブルに自動行を追加する実装のオプション機能が追加されました。
Similarly, some changes were made to the rules, as follows:
同様に、次のようにルールにいくつかの変更が加えられました。
1. Changed the definition of CommonPrefixLen() to only compare bits
up to the source address's prefix length. The previous
definition used the entire source address, rather than only its
prefix. As a result, when a source and destination addresses had
the same prefix, common bits in the interface ID would previously
result in overriding DNS load balancing [RFC1794] by forcing the
destination address with the most bits in common to be always
chosen. The updated definition allows DNS load balancing to
continue to be used as a tie breaker.
1. CommonPrefixLen（）の定義を変更して、送信元アドレスのプレフィックス長までのビットのみを比較するようにしました。 前の定義では、プレフィックスだけではなく、送信元アドレス全体を使用していました。 その結果、送信元アドレスと宛先アドレスのプレフィックスが同じである場合、インターフェースIDの共通ビットにより、以前はほとんどのビットが共通の宛先アドレスが常に選択されるように強制することで、DNSロードバランシング[RFC1794]が上書きされていました。 更新された定義により、DNSロードバランシングをタイブレーカーとして引き続き使用できます。
2. Added Rule 5.5 to allow choosing a source address from a prefix
advertised by the chosen next-hop for a given destination. This
allows better connectivity in the presence of BCP 38 [RFC2827]
ingress filtering and egress filtering. Previously, RFC 3484 had
issues with multiple egress networks reached via the same
interface, as discussed in [RFC5220].
2.ルール5.5が追加され、指定された宛先の選択されたネクストホップによってアドバタイズされたプレフィックスから送信元アドレスを選択できるようになりました。 これにより、BCP 38 [RFC2827]入力フィルタリングと出力フィルタリングが存在する場合の接続性が向上します。 以前は、RFC 3484には、[RFC5220]で説明されているように、同じインターフェイスを介して到達する複数の出力ネットワークに関する問題がありました。
3. Removed restriction against anycast addresses in the candidate
set of source addresses, since the restriction against using IPv6
anycast addresses as source addresses was removed in Section 2.6
of RFC 4291 [RFC4291].
3. IPv4エニーキャストアドレスをソースアドレスとして使用することに対する制限がRFC 4291 [RFC4291]のセクション2.6で削除されたため、ソースアドレスの候補セット内のエニーキャストアドレスに対する制限を削除しました。
4. Changed mapping of RFC 1918 [RFC1918] addresses to global scope
in Section 3.2. Previously, they were mapped to site-local
scope. However, experience has resulted in current
implementations already using global scope instead. When they
were mapped to site-local, Destination Address Selection Rule 2
(Prefer matching scope) would cause IPv6 to be preferred in
scenarios such as that described in Section 10.7. The change to
global scope allows configurability via the prefix policy table.
4. RFC 1918 [RFC1918]アドレスのマッピングをセクション3.2のグローバルスコープに変更しました。 以前は、サイトローカルスコープにマップされていました。 ただし、経験上、現在の実装ではすでに代わりにグローバルスコープを使用しています。 それらがサイトローカルにマップされた場合、宛先アドレス選択ルール2（一致スコープを優先）により、セクション10.7で説明されているようなシナリオでIPv6が優先されます。 グローバルスコープへの変更により、プレフィックスポリシーテーブルを介した構成が可能になります。
5. Changed the default recommendation for Source Address Selection
Rule 7 to prefer temporary addresses rather than public
addresses, while providing an administrative override (in
addition to the application-specific override that was already
specified). This change was made because of the increasing
importance of privacy considerations, as well as the fact that
widely deployed implementations have preferred temporary
addresses for many years without major application issues.
5.送信元アドレス選択ルール7のデフォルトの推奨事項を変更して、（すでに指定されているアプリケーション固有のオーバーライドに加えて）管理オーバーライドを提供しながら、パブリックアドレスではなく一時アドレスを優先するようにしました。 この変更は、プライバシーへの配慮の重要性が増していること、および広く展開されている実装が、アプリケーションに大きな問題を起こすことなく、長年にわたって一時アドレスを優先していたために行われました。
Thaler, et al. Standards Track [Page 30] RFC 6724 Default Address Selection for IPv6 September 2012 Finally, some editorial changes were made, including:
最後に、以下を含むいくつかの編集上の変更が行われました。
1. Changed global IP addresses in examples to use ranges reserved
for documentation.
1.ドキュメントで予約されている範囲を使用するように、例のグローバルIPアドレスを変更しました。
2. Added additional examples in Sections 10.6 and 10.7.
2.セクション10.6および10.7に追加の例を追加しました。
3. Added Section 10.3.1 on "broken" IPv6.
3.「壊れた」IPv6に関するセクション10.3.1を追加。
4. Updated references.
4.参照を更新しました。
Thaler, et al. Standards Track [Page 31] RFC 6724 Default Address Selection for IPv6 September 2012 Authors' Addresses Dave Thaler (editor) Microsoft One Microsoft Way Redmond, WA 98052 USA Phone: +1 425 703 8835 EMail: dthaler@microsoft.com Richard Draves Microsoft Research One Microsoft Way Redmond, WA 98052 USA Phone: +1 425 706 2268 EMail: richdr@microsoft.com Arifumi Matsumoto NTT SI Lab Midori-Cho 3-9-11 Musashino-shi, Tokyo 180-8585 Japan Phone: +81 422 59 3334 EMail: arifumi@nttv6.net Tim Chown University of Southampt on Southampton, Hampshire SO17 1BJ United Kingdom EMail: tjc@ecs.soton.ac.uk Thaler, et al. Standards Track [Page 32]