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