RFC3484 日本語訳
3484 Default Address Selection for Internet Protocol version 6 (IPv6).R. Draves. February 2003. (Format: TXT=55076 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group R. Draves Request for Comments: 3484 Microsoft Research Category: Standards Track February 2003
Dravesがコメントのために要求するワーキンググループR.をネットワークでつないでください: 3484年のマイクロソフト研究カテゴリ: 標準化過程2003年2月
Default Address Selection for Internet Protocol version 6 (IPv6)
インターネットプロトコルバージョン6のためのデフォルトAddress Selection(IPv6)
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
Abstract
要約
This document describes two algorithms, for source address selection and for destination address selection. The algorithms specify default behavior for all Internet Protocol version 6 (IPv6) implementations. They do not override choices made by applications or upper-layer protocols, nor do they preclude the development of more advanced mechanisms for address selection. The two algorithms share a common context, including an optional mechanism for allowing administrators to provide policy that can override the default behavior. In dual stack implementations, the destination address selection algorithm can consider both IPv4 and IPv6 addresses - depending on the available source addresses, the algorithm might prefer IPv6 addresses over IPv4 addresses, or vice-versa.
このドキュメントはソースアドレス選択と目的地アドレス選択のための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ノードが、この仕様に基づき定義されるようにデフォルトがアドレス選択であると実装しなければなりません。
Draves Standards Track [Page 1] RFC 3484 Default Address Selection for IPv6 February 2003
IPv6 February 2003のためのDraves標準化過程[1ページ]RFC3484デフォルトアドレス選択
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
1. 序論…2 1.1. このドキュメントで中古のコンベンション…4 2. アルゴリズムが作動する文脈…4 2.1. 方針テーブル…5 2.2. 一般的な接頭語の長さ…6 3. 特性を扱ってください…6 3.1. 範囲比較…7 3.2. IPv4アドレスとIPv4によって写像されたアドレス…7 3.3. 他のIPv6は埋め込まれたIPv4と共にアドレスを扱います…8 3.4. IPv6ループバックアドレスと他の形式接頭語…8 3.5. 移動性アドレス…8 4. 候補ソースアドレス…8 5. ソースアドレス選択…10 6. 目的地アドレス選択…12 7. ルート設定との相互作用…14 8. 実装問題…15 9. セキュリティ問題…15 10. 例…16 10.1. デフォルトソースアドレス選択…16 10.2. デフォルト目的地アドレス選択…17 10.3. IPv6かIPv4のために好みを構成します…18 10.4. 見られたアドレスのための好みを構成します…19 10.5. aを構成する、マルチ、家へ帰り、サイト…19 標準の参照…21 有益な参照…22の承認…23作者のアドレス…23 完全な著作権宣言文…24
1. Introduction
1. 序論
The IPv6 addressing architecture [1] allows multiple unicast addresses to be assigned to interfaces. These addresses may have different reachability scopes (link-local, site-local, or global). These addresses may also be "preferred" or "deprecated" [2]. Privacy considerations have introduced the concepts of "public addresses" and "temporary addresses" [3]. The mobility architecture introduces "home addresses" and "care-of addresses" [8]. In addition, multi- homing situations will result in more addresses per node. For example, a node may have multiple interfaces, some of them tunnels or virtual interfaces, or a site may have multiple ISP attachments with a global prefix per ISP.
アーキテクチャが[1]であると扱うIPv6は、複数のユニキャストアドレスがインタフェースに割り当てられるのを許容します。 これらのアドレスは(リンク地方、サイト地方、グローバル)であるのに異なった可到達性範囲を持っているかもしれません。 また、これらのアドレスは「都合のよい」か「推奨しない」[2]であるかもしれません。 プライバシー問題は「場内放送」と「仮の住所」[3]の概念を紹介しました。 そして、移動性アーキテクチャが「ホームアドレス」を導入する、「注意、-、」 [8]を扱います。 さらに、マルチの家へ帰り状況は、より多くの1ノードあたりのアドレスをもたらすでしょう。 例えば、ノードには、複数のインタフェースがあるかもしれませんか、またはサイトに複数のISP付属が1ISPあたり1つのグローバルな接頭語と共にあるかもしれません。(それらのいくつかがトンネルかインタフェースのための仮想インターフェース)
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
結末はコミュニケーションを開始するとき、IPv6実装は頻繁に複数の可能なソースと送付先アドレスに直面するということです。 デフォルトを持っているのは望ましいです。
Draves Standards Track [Page 2] RFC 3484 Default Address Selection for IPv6 February 2003
IPv6 February 2003のためのDraves標準化過程[2ページ]RFC3484デフォルトアドレス選択
algorithms, common across all implementations, for selecting source and destination addresses so that developers and administrators can reason about and predict the behavior of their systems.
開発者と管理者が彼らのシステムについて推論して、振舞いを予測できるようにソースと送付先アドレスを選ぶのに、すべての実装の向こう側に一般的なアルゴリズム。
Furthermore, dual or hybrid stack implementations, which support both IPv6 and IPv4, will very often need to choose between IPv6 and IPv4 when initiating communication. For example, when DNS name resolution yields both IPv6 and IPv4 addresses and the network protocol stack has available both IPv6 and IPv4 source addresses. In such cases, a simple policy to always prefer IPv6 or always prefer IPv4 can produce poor behavior. As one example, suppose a DNS name resolves to a global IPv6 address and a global IPv4 address. If the node has assigned a global IPv6 address and a 169.254/16 auto-configured IPv4 address [9], then IPv6 is the best choice for communication. But if the node has assigned only a link-local IPv6 address and a global IPv4 address, then IPv4 is the best choice for communication. The destination address selection algorithm solves this with a unified procedure for choosing among both IPv6 and IPv4 addresses.
その上、二元的であるかハイブリッドのスタック実装(IPv6とIPv4の両方をサポートする)は、頻繁にコミュニケーションを開始するとき、IPv6とIPv4を選ぶ必要があるでしょう。 DNS名前解決がIPv6とIPv4アドレスとネットワークの両方をもたらすとき、例えば、プロトコル・スタックにはIPv6とIPv4ソースアドレスの利用可能な両方があります。 そのような場合、いつもIPv6を好むか、またはいつもIPv4を好む簡単な方針は不十分な振舞いを起こすことができます。 1つの例として、DNS名がアドレスとグローバルなIPv4アドレスをグローバルなIPv6に決議すると仮定してください。 ノードがグローバルなIPv6アドレスと169.254/16の自動構成されたIPv4アドレス[9]を割り当てたなら、IPv6はコミュニケーションのための最も良い選択です。 しかし、ノードがリンクローカルのIPv6アドレスとグローバルなIPv4アドレスだけを割り当てたなら、IPv4はコミュニケーションのための最も良い選択です。 目的地アドレス選択アルゴリズムはIPv6とIPv4アドレスの両方で選ぶための統一された手順でこれを解決します。
The algorithms in this document are specified as a set of rules that define a partial ordering on the set of addresses that are available for use. In the case of source address selection, a node typically has multiple addresses assigned to its interfaces, and the source address ordering rules in section 5 define which address is the "best" one to use. In the case of destination address selection, the DNS may return a set of addresses for a given name, and an application needs to decide which one to use first, and in what order to try others should the first one not be reachable. The destination address ordering rules in section 6, when applied to the set of addresses returned by the DNS, provide such a recommended ordering.
アルゴリズムは使用に利用可能なアドレスのセットで順序を定義する1セットの規則として本書では指定されます。 ソースアドレス選択の場合では、ノードで、セクション5の規則が使用するためにどのアドレスが「最も良い」ものであるかを定義するインタフェース、およびソースアドレス注文に複数のアドレスを通常割り当てます。 選択、DNSが名のための1セットのアドレスを返すかもしれなくて、最初の届かないならアプリケーションが最初に、そして、どんなオーダーを試みたらよいかで他のものを使用するのにどれを決める必要がある送付先アドレスの場合で。 DNSによって返されたアドレスのセットに適用されると送付先アドレスがセクション6で規則を注文して、そのようなお勧めの注文を提供してください。
This document specifies source address selection and destination address selection separately, but using a common context so that together the two algorithms yield useful results. The algorithms attempt to choose source and destination addresses of appropriate scope and configuration status (preferred or deprecated in the RFC 2462 sense). Furthermore, this document suggests a preferred method, longest matching prefix, for choosing among otherwise equivalent addresses in the absence of better information.
このドキュメントは別々にソースアドレス選択と目的地アドレス選択を指定しますが、一緒にいるように一般的な文脈を使用して、2つのアルゴリズムが役に立つ結果をもたらします。 アルゴリズムは、(RFC2462意味で都合のよいか推奨しない)の適切な範囲と構成状態のソースと送付先アドレスを選ぶのを試みます。 その上、このドキュメントは適した方法を示します、最も長い合っている接頭語、より良い情報がないときそうでなければ、同等なアドレスの中で選ぶために。
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つの接頭語がある状態で、別の接頭語で送付先アドレスを好むことができます。 これらのフックは何らかのマルチホーミングと変遷シナリオに対処する際に管理者の柔軟性を与えますが、確かに、それらは万能薬ではありません。
Draves Standards Track [Page 3] RFC 3484 Default Address Selection for IPv6 February 2003
IPv6 February 2003のためのDraves標準化過程[3ページ]RFC3484デフォルトアドレス選択
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 [4].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14(RFC2119[4])で説明されるように本書では解釈されることであるべきです。
2. Context in Which the Algorithms Operate
2. アルゴリズムが作動する文脈
Our context for address selection derives from the most common implementation architecture, which separates the choice of destination address from the choice of source address. Consequently, we have two separate algorithms for these tasks. The algorithms are designed to work well together and they share a mechanism for administrative policy override.
アドレス選択のための私たちの文脈が最も一般的な実装アーキテクチャに由来しています。(それは、ソースアドレスの選択と送付先アドレスの選択を切り離します)。 その結果、私たちには、これらのタスクのための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によって写像されたアドレスとして時々表される)を含むかもしれません。 ネットワークへの送付先アドレスが積み重ねるアプリケーションの当時のパスは()かsendto()を接続します。 次に、アプリケーションはリストにおける最初のアドレスを通常試みるでしょう、働くアドレスを見つけるまで住所録の上で輪にして。 どのような場合でも、ネットワーク層がそれがいくつかの選択肢からの送付先アドレスを選ぶ必要があるところに状況に決してありません。 また、アプリケーションはひも()でソースアドレスを指定するかもしれませんが、しばしば、ソースアドレスは不特定のままにされます。 したがって、ネットワーク層はしばしばいくつかの選択肢からのソースアドレスを選びます。
As a consequence, we intend that implementations of getaddrinfo() will use the destination address selection algorithm specified here to sort the list of IPv6 and IPv4 addresses that they return. Separately, the IPv6 network layer will use the source address selection algorithm when an application or upper-layer has not specified a source address. Application of this specification to source address selection in an IPv4 network layer may be possible but this is not explored further here.
結果として、私たちは、getaddrinfo()の実装がIPv6のリストを分類するためにここで指定された目的地アドレス選択アルゴリズムとそれらが返すIPv4アドレスを使用することを意図します。 アプリケーションか上側の層がソースアドレスを指定していないとき、別々に、IPv6ネットワーク層はソースアドレス選択アルゴリズムを使用するでしょう。 IPv4ネットワーク層におけるソースアドレス選択へのこの仕様の適用は可能であるかもしれませんが、これはここでさらに探検されません。
Well-behaved applications SHOULD iterate through the list of addresses returned from getaddrinfo() until they find a working address.
彼らが働くアドレスを見つけるまで、SHOULDが住所録を通して繰り返す行儀のよいアプリケーションはgetaddrinfo()から戻りました。
Draves Standards Track [Page 4] RFC 3484 Default Address Selection for IPv6 February 2003
IPv6 February 2003のためのDraves標準化過程[4ページ]RFC3484デフォルトアドレス選択
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]で、ホームアドレスが好まれる、終わっている、注意、-、アドレス。 同時にアドレスがホームアドレスとaである、注意、-、次に、ホーム/を扱う、(モバイルノードがそのアドレスのために「ホーム」にあるのを示します)注意、-、アドレスが唯一ホームアドレスであるアドレスの上か唯一好まれる、注意、-、アドレス
This specification optionally allows for the possibility of administrative configuration of policy that can override the default behavior of the algorithms. The policy override takes the form of a configurable table that specifies precedence values and preferred source prefixes for destination prefixes. If an implementation is not configurable, or if an implementation has not been configured, then the default policy table specified in this document SHOULD be used.
この仕様は任意にアルゴリズムのデフォルトの振舞いをくつがえすことができる方針の管理構成の可能性を考慮します。方針オーバーライドは先行値と都合のよいソース接頭語を目的地接頭語に指定する構成可能なテーブルの形を取ります。 実装が構成可能でないか、または実装が構成されていないなら、デフォルト方針テーブルは本書ではSHOULDを指定しました。使用されます。
2.1. Policy Table
2.1. 方針テーブル
The policy table is a longest-matching-prefix lookup table, much like a routing table. Given an address A, a lookup in the policy table produces two values: a precedence value Precedence(A) and a classification or label Label(A).
方針テーブルは経路指定テーブルのように最も長い合っている接頭語ルックアップ表です。 アドレス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を扱うより高い先行があると言います、私たちのアルゴリズムが送付先アドレスBの前に送付先アドレスAを分類するのを好む意味。
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)がラベル(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
IPv6実装SHOULDは、構成可能なアドレスが選択であるとここで定義された方針テーブルと少なくとも同じくらい強力なメカニズムでサポートします。 そこでのこの書くこと時点のそれが1セットの可能なIPv6アドレスから選び抜く方針の使用の限られた経験にすぎないことに注意してください。 より多くの経験をするのに従って、お勧めのデフォルト方針は変化するかもしれません。 その結果、実装がデフォルトを変える方法を提供するのは、重要です。
Draves Standards Track [Page 5] RFC 3484 Default Address Selection for IPv6 February 2003
IPv6 February 2003のためのDraves標準化過程[5ページ]RFC3484デフォルトアドレス選択
policies as more experience is gained. Sections 10.3 and 10.4 provide examples of the kind of changes that might be needed.
より多くの経験をするような方針。 セクション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:
実装は、構成可能でないか、または構成されていなくて、次に、それはSHOULDです。ここで以下のデフォルト方針テーブルに関連して指定されたアルゴリズムに従って、作動してください:
Prefix Precedence Label
::1/128 50 0
::/0 40 1
2002::/16 30 2
::/96 20 3
::ffff:0:0/96 10 4
接頭語先行は以下をラベルします:1/128 50 0 ::/0 40 1 2002::/16 30 2 ::/96 20 3 ::ffff: 0:0/96 10 4
One effect of the default policy table is to prefer using native source addresses with native destination addresses, 6to4 [5] source addresses with 6to4 destination addresses, and v4-compatible [1] source addresses with v4-compatible destination addresses. Another effect of the default policy table is to prefer communication using IPv6 addresses to communication using IPv4 addresses, if matching source addresses are available.
デフォルト方針テーブルの1つの効果は固有の送付先アドレスがある固有のソースアドレス、6to4送付先アドレスがある6to4[5]ソースアドレス、およびv4コンパチブル送付先アドレスがあるv4コンパチブル[1]ソースアドレスを使用するのを好むことです。 デフォルト方針テーブルの別の効果はIPv4アドレスを使用することでIPv6アドレスをコミュニケーションに使用することでコミュニケーションを好むことです、合っているソースアドレスが利用可能であるなら。
Policy table entries for scoped address prefixes MAY be qualified with an optional zone index. If so, a prefix table entry only matches against an address during a lookup if the zone index also matches the address's zone index.
見られたアドレス接頭語のための方針テーブル項目は任意のゾーンインデックスで資格があるかもしれません。 そうだとすれば、また、ゾーンインデックスがアドレスsのゾーンインデックスに合っている場合にだけ、接頭語テーブルエントリーはアドレスに対してルックアップの間、合っています。
2.2. Common Prefix Length
2.2. 一般的な接頭語の長さ
We define the common prefix length CommonPrefixLen(A, B) of two addresses A and B as the length of the longest prefix (looking at the most significant, or leftmost, bits) that the two addresses have in common. It ranges from 0 to 128.
私たちは2つのアドレスが共通である中で最も長い接頭語(最も重要であるか、または一番左のビットを見る)の長さと2つのアドレスAとBの一般的な接頭語の長さのCommonPrefixLen(A、B)を定義します。 それは0〜128まで及びます。
3. Address Properties
3. アドレスの特性
In the rules given in later sections, addresses of different types (e.g., IPv4, IPv6, multicast and unicast) are compared against each other. Some of these address types have properties that aren't directly comparable to each other. For example, IPv6 unicast addresses can be "preferred" or "deprecated" [2], while IPv4 addresses have no such notion. To compare such addresses using the ordering rules (e.g., to use "preferred" addresses in preference to "deprecated" addresses), the following mappings are defined.
後のセクションで与えられた規則で、異なったタイプ(例えば、IPv4、IPv6、マルチキャスト、およびユニキャスト)のアドレスは互いに対して比較されます。 これらのアドレスタイプの中には、直接互いに匹敵しない特性を持っている人もいます。 例えば、IPv6ユニキャストアドレスは「都合のよい」か「推奨しない」[2]であることができますが、IPv4アドレスには、どんなそのような考えもありません。 注文規則(例えば「推奨しない」アドレスに優先して「都合のよい」アドレスを使用する)を使用することでそのようなアドレスを比較するために、以下のマッピングは定義されます。
Draves Standards Track [Page 6] RFC 3484 Default Address Selection for IPv6 February 2003
IPv6 February 2003のためのDraves標準化過程[6ページ]RFC3484デフォルトアドレス選択
3.1. Scope Comparisons
3.1. 範囲比較
Multicast destination addresses have a 4-bit scope field that controls the propagation of the multicast packet. The IPv6 addressing architecture defines scope field values for interface- local (0x1), link-local (0x2), subnet-local (0x3), admin-local (0x4), site-local (0x5), organization-local (0x8), and global (0xE) scopes [11].
マルチキャスト送付先アドレスには、マルチキャストパケットの伝播を制御する4ビットの範囲分野があります。 IPv6アドレッシング体系はインタフェースの地方の(0×1)のために範囲分野値を定義します、リンク地方です(0×2)、サブネット地方です(0×3)、アドミン地方です(0×4)、サイト地方です(0×5)、組織地方(0×8)の、そして、グローバルな(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.Forの例の範囲を意味するためにScope(A)に書きます、Aがリンクローカルのユニキャストアドレスであり、Bがサイトローカルのマルチキャストアドレス、当時のScope(A)<Scope(B)であるなら。
This mapping implicitly conflates unicast site boundaries and multicast site boundaries [11].
このマッピングはそれとなくユニキャストサイト境界とマルチキャストサイト境界[11]を融合します。
3.2. IPv4 Addresses and IPv4-Mapped Addresses
3.2. IPv4アドレスとIPv4によって写像されたアドレス
The destination address selection algorithm operates on both IPv6 and IPv4 addresses. For this purpose, IPv4 addresses should be represented as IPv4-mapped addresses [1]. For example, to lookup the precedence or other attributes of an IPv4 address in the policy table, lookup the corresponding IPv4-mapped IPv6 address.
目的地アドレス選択アルゴリズムはIPv6とIPv4アドレスの両方を作動させます。 このために、IPv4アドレスはIPv4によって写像されたアドレス[1]として表されるべきです。 例えば方針テーブルのIPv4アドレスのルックアップの他の先行か属性への対応するIPv4によって写像されたIPv6が扱うルックアップ。
IPv4 addresses are assigned scopes as follows. IPv4 auto- configuration addresses [9], which have the prefix 169.254/16, are assigned link-local scope. IPv4 private addresses [12], which have the prefixes 10/8, 172.16/12, and 192.168/16, are assigned site-local scope. IPv4 loopback addresses [12, section 4.2.2.11], which have the prefix 127/8, are assigned link-local scope (analogously to the treatment of the IPv6 loopback address [11, section 4]). Other IPv4 addresses are assigned global scope.
以下の範囲はIPv4アドレスに割り当てられます。 リンク地方の範囲はIPv4自動構成アドレス[9](接頭語169.254/16を持っています)に割り当てられます。 サイト地方の範囲はIPv4プライベート・アドレス[12](接頭語10/8、172.16/12、および192.168/16を持っています)に割り当てられます。 IPv4ループバックアドレス、[12、4.2に、リンク地方で.11(接頭語127/8を持っている)が]割り当てられる.2を区分してください、範囲、(類似して、IPv6ループバックアドレス[11、セクション4)の処理に。 グローバルな範囲は他のIPv4アドレスに割り当てられます。
IPv4 addresses should be treated as having "preferred" (in the RFC 2462 sense) configuration status.
IPv4アドレスは構成状態が「好み」であったとして(RFC2462意味で)扱われるべきです。
Draves Standards Track [Page 7] RFC 3484 Default Address Selection for IPv6 February 2003
IPv6 February 2003のためのDraves標準化過程[7ページ]RFC3484デフォルトアドレス選択
3.3. Other IPv6 Addresses with Embedded IPv4 Addresses
3.3. 他のIPv6は埋め込まれたIPv4と共にアドレスを扱います。
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コンパチブルアドレスIPv4によって写像された[1]、[1]、IPv4翻訳できる[6]、および6to4アドレス[5]は埋め込まれたIPv4アドレスを含んでいます。 このドキュメントの目的のために、これらのアドレスはグローバルな範囲を持っているとして扱われるべきです。
IPv4-compatible, IPv4-mapped, and IPv4-translatable addresses should be treated as having "preferred" (in the RFC 2462 sense) configuration status.
IPv4コンパチブル、そして、IPv4によって写像されて、IPv4翻訳できるアドレスは構成状態が「好み」であったとして(RFC2462意味で)扱われるべきです。
3.4. IPv6 Loopback Address and Other Format Prefixes
3.4. IPv6ループバックアドレスと他の形式接頭語
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]と「都合のよい」(RFC2462意味における)構成状態を持っているとして扱われるべきです。
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アドレスと他のアドレス、まだ未定義の形式として、接頭語はグローバルな範囲と「都合のよい」(RFC2462の)構成状態を持っているとして扱われるべきです。 後の規格はこの処理に取って代わるかもしれません。
3.5. Mobility Addresses
3.5. 移動性アドレス
Some nodes may support mobility using the concepts of a home address and a care-of address (for example see [8]). Conceptually, a home address is an IP address assigned to a mobile node and used as the permanent address of the mobile node. A care-of address is an IP address associated with a mobile node while visiting a foreign link. When a mobile node is on its home link, it may have an address that is simultaneously a home address and a care-of address.
いくつかのノードが移動性がホームアドレスの概念を使用して、aであることを支えるかもしれない、注意、-、アドレス、(例えば、[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.
このドキュメントの目的のために、自分自身のアドレスがアドレスのホームアドレスか注意として指定されるかどうかを知るのは十分です。 または、アドレスがホームアドレスに指定されるべきである、注意、-、このドキュメントの範囲の外にアドレスがあります。
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.
ソースアドレス選択アルゴリズムは与えられた送付先アドレスに潜在的ソースアドレスの「候補セット」の概念を使用します。 候補セットはソースアドレスとして使用できたすべてのアドレスのセットです。 ソースアドレス選択アルゴリズムはそのセットからアドレスを選ぶでしょう。 私たちは、アドレスAのために候補セットを指示するためにCandidateSource(A)に書きます。
Draves Standards Track [Page 8] RFC 3484 Default Address Selection for IPv6 February 2003
IPv6 February 2003のためのDraves標準化過程[8ページ]RFC3484デフォルトアドレス選択
It is RECOMMENDED that the candidate source addresses be the set of unicast addresses assigned to the interface that will be used to send to the destination. (The "outgoing" interface.) On routers, the candidate set MAY include unicast addresses assigned to any interface that forwards packets, subject to the restrictions described below.
候補ソースアドレスが目的地に発信するのに使用されるインタフェースに割り当てられたユニキャストアドレスのセットであることはRECOMMENDEDです。 (「送信する」インタフェース。) ルータでは、候補セットは以下で説明された制限を条件としてパケットを進めるどんなインタフェースにも割り当てられたユニキャストアドレスを含むかもしれません。
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.
議論: NeighborディスカバリーRedirectメカニズム[14]は、ルータが、Redirectを生成する前にパケットのソースアドレスが隣人を特定するのでホストが外向的なインタフェースに割り当てられたソースアドレスを選ぶのが、有利であることを確かめるのを必要とします。 まるでループバックインタフェースがパケットを溯源して、進めるかのようにループバックインタフェースに割り当てられたグローバルなソースアドレスの使用をサポートしたがっている実装は振る舞うべきです。
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.
議論: 現在配布しているマルチキャスト推進アルゴリズムがReverse Path Forwarding(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
SIITが[6、特にセクション5]であると支えるIPv6だけノードの上では、候補セットは送付先アドレスがIPv4によって写像されたアドレスであるならIPv4翻訳できるアドレスだけを含まなければなりません。 the
Draves Standards Track [Page 9] RFC 3484 Default Address Selection for IPv6 February 2003
IPv6 February 2003のためのDraves標準化過程[9ページ]RFC3484デフォルトアドレス選択
destination address is not an IPv4-mapped address, then the candidate set MUST NOT contain IPv4-translatable addresses.
送付先アドレスがIPv4によって写像されたアドレスでない、そして、候補セットはIPv4翻訳できるアドレスを含んではいけません。
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.
選択アルゴリズムが生産するソースアドレスは与えられた送付先アドレスで使用のためのただ一つのソースアドレスを出力しました。 このアルゴリズムは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.
アルゴリズムがここでaを課す(与えられた送付先アドレス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.
概念的に、候補セットの種類が実行されていることに注意してください、1セットの規則がアドレスの中で注文を定義するところで。 しかし、アルゴリズムの出力がただ一つのソースアドレスであるので、実装は実際にセットを分類する必要はありません。 それは分類されたリストの前部で終わる「最大」の値を特定するだけでよいです。
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.
The ordering of the addresses in the candidate set is defined by a list of eight pair-wise comparison rules, with each rule placing a "greater than," "less than" or "equal to" ordering on two source addresses with respect to each other (and that rule). In the case that a given rule produces a tie, i.e., provides an "equal to" result for the two addresses, the remaining rules are applied (in order) to just those addresses that are tied to break the tie. Note that if a rule produces a single clear "winner" (or set of "winners" in the case of ties), those addresses not in the winning set can be discarded from further consideration, with subsequent rules applied only to the remaining addresses. If the eight rules fail to choose a single address, some unspecified tie-breaker should be used.
When comparing two addresses SA and SB from the candidate set, we say "prefer SA" to mean that SA is "greater than" SB, and similarly we say "prefer SB" to mean that SA is "less than" SB.
When comparing two addresses SA and SB from the candidate set, we say "prefer SA" to mean that SA is "greater than" SB, and similarly we say "prefer SB" to mean that SA is "less than" SB.
Rule 1: Prefer same address. If SA = D, then prefer SA. Similarly, if SB = D, then prefer SB.
Rule 1: Prefer same address. If SA = D, then prefer SA. Similarly, if SB = D, then prefer SB.
Rule 2: Prefer appropriate scope. If Scope(SA) < Scope(SB): If Scope(SA) < Scope(D), then prefer SB and otherwise prefer SA. Similarly, if Scope(SB) < Scope(SA): If Scope(SB) < Scope(D), then prefer SA and otherwise prefer SB.
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.
Draves Standards Track [Page 10] RFC 3484 Default Address Selection for IPv6 February 2003
Draves Standards Track [Page 10] RFC 3484 Default Address Selection for IPv6 February 2003
Rule 3: Avoid deprecated addresses. The addresses SA and SB have the same scope. If one of the two source addresses is "preferred" and one of them is "deprecated" (in the RFC 2462 sense), then prefer the one that is "preferred."
Rule 3: Avoid deprecated addresses. The addresses SA and SB have the same scope. If one of the two source addresses is "preferred" and one of them is "deprecated" (in the RFC 2462 sense), then prefer the one that is "preferred."
Rule 4: Prefer home addresses. If SA is simultaneously a home address and care-of address and SB is not, then prefer SA. Similarly, if SB is simultaneously a home address and care-of address and SA is not, then prefer SB. If SA is just a home address and SB is just a care-of address, then prefer SA. Similarly, if SB is just a home address and SA is just a care-of address, then prefer SB.
Rule 4: Prefer home addresses. If SA is simultaneously a home address and care-of address and SB is not, then prefer SA. Similarly, if SB is simultaneously a home address and care-of address and SA is not, then prefer SB. If SA is just a home address and SB is just a care-of address, then prefer SA. Similarly, if SB is just a home address and SA is just a care-of address, then prefer SB.
Implementations should provide a mechanism allowing an application to reverse the sense of this preference and prefer care-of addresses over home addresses (e.g., via appropriate API extensions). Use of the mechanism should only affect the selection rules for the invoking application.
Implementations should provide a mechanism allowing an application to reverse the sense of this preference and prefer care-of addresses over home addresses (e.g., via appropriate API extensions). Use of the mechanism should only affect the selection rules for the invoking application.
Rule 5: Prefer outgoing interface. If SA is assigned to the interface that will be used to send to D and SB is assigned to a different interface, then prefer SA. Similarly, if SB is assigned to the interface that will be used to send to D and SA is assigned to a different interface, then prefer SB.
Rule 5: Prefer outgoing interface. If SA is assigned to the interface that will be used to send to D and SB is assigned to a different interface, then prefer SA. Similarly, if SB is assigned to the interface that will be used to send to D and SA is assigned to a different interface, then prefer SB.
Rule 6: Prefer matching label. If Label(SA) = Label(D) and Label(SB) <> Label(D), then prefer SA. Similarly, if Label(SB) = Label(D) and Label(SA) <> Label(D), then prefer SB.
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.
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.
Rule 7: Prefer public addresses. If SA is a public address and SB is a temporary address, then prefer SA. Similarly, if SB is a public address and SA is a temporary address, then prefer SB.
Implementations MUST provide a mechanism allowing an application to reverse the sense of this preference and prefer temporary addresses over public addresses (e.g., via appropriate API extensions). Use of the mechanism should only affect the selection rules for the invoking application. This rule avoids applications potentially failing due to the relatively short lifetime of temporary addresses or due to the possibility of the reverse lookup of a temporary address either failing or returning a randomized name. Implementations for which privacy considerations outweigh these application compatibility concerns MAY reverse the sense of this rule and by default prefer temporary addresses over public addresses.
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.
Draves Standards Track [Page 11] RFC 3484 Default Address Selection for IPv6 February 2003
Draves Standards Track [Page 11] RFC 3484 Default Address Selection for IPv6 February 2003
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.
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.
Rule 8 may be superseded if the implementation has other means of choosing among source addresses. For example, if the implementation somehow knows which source address will result in the "best" communications performance.
Rule 8 may be superseded if the implementation has other means of choosing among source addresses. For example, if the implementation somehow knows which source address will result in the "best" communications performance.
Rule 2 (prefer appropriate scope) MUST be implemented and given high priority because it can affect interoperability.
Rule 2 (prefer appropriate scope) MUST be implemented and given high priority because it can affect interoperability.
6. Destination Address Selection
6. Destination Address Selection
The destination address selection algorithm takes a list of destination addresses and sorts the addresses to produce a new list. It is specified here in terms of the pair-wise comparison of addresses DA and DB, where DA appears before DB in the original list.
The destination address selection algorithm takes a list of destination addresses and sorts the addresses to produce a new list. It is specified here in terms of the pair-wise comparison of addresses DA and DB, where DA appears before DB in the original list.
The algorithm sorts together both IPv6 and IPv4 addresses. To find the attributes of an IPv4 address in the policy table, the IPv4 address should be represented as an IPv4-mapped address.
The algorithm sorts together both IPv6 and IPv4 addresses. To find the attributes of an IPv4 address in the policy table, the IPv4 address should be represented as an IPv4-mapped address.
We write Source(D) to indicate the selected source address for a destination D. For IPv6 addresses, the previous section specifies the source address selection algorithm. Source address selection for IPv4 addresses is not specified in this document.
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.
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.
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.
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.
The pair-wise comparison of destination addresses consists of ten rules, which should be applied in order. If a rule determines a result, then the remaining rules are not relevant and should be ignored. Subsequent rules act as tie-breakers for earlier rules. See the previous section for a lengthier description of how pair-wise comparison tie-breaker rules can be used to sort a list.
Rule 1: Avoid unusable destinations. If DB is known to be unreachable or if Source(DB) is undefined, then prefer DA. Similarly, if DA is known to be unreachable or if Source(DA) is undefined, then prefer DB.
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.
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
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
Draves Standards Track [Page 12] RFC 3484 Default Address Selection for IPv6 February 2003
Draves Standards Track [Page 12] RFC 3484 Default Address Selection for IPv6 February 2003
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Rule 6: Prefer higher precedence. If Precedence(DA) > Precedence(DB), then prefer DA. Similarly, if Precedence(DA) < Precedence(DB), then prefer DB.
Rule 6: Prefer higher precedence. If Precedence(DA) > Precedence(DB), then prefer DA. Similarly, if Precedence(DA) < Precedence(DB), then prefer 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.
Rule 7: Prefer native transport. If DA is reached via an encapsulating transition mechanism (e.g., IPv6 in IPv4) and DB is not, then prefer DB. Similarly, if DB is reached via encapsulation and DA is not, then prefer DA.
Discussion: 6-over-4 [15], ISATAP [16], and configured tunnels
[17] are examples of encapsulating transition mechanisms for which
the destination address does not have a specific prefix and hence
can not be assigned a lower precedence in the policy table. An
implementation MAY generalize this rule by using a concept of
interface preference, and giving virtual interfaces (like the
IPv6-in-IPv4 encapsulating interfaces) a lower preference than
native interfaces (like ethernet interfaces).
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).
Draves Standards Track [Page 13] RFC 3484 Default Address Selection for IPv6 February 2003
Draves Standards Track [Page 13] RFC 3484 Default Address Selection for IPv6 February 2003
Rule 8: Prefer smaller scope. If Scope(DA) < Scope(DB), then prefer DA. Similarly, if Scope(DA) > Scope(DB), then prefer DB.
Rule 8: Prefer smaller scope. If Scope(DA) < Scope(DB), then prefer DA. Similarly, if Scope(DA) > Scope(DB), then prefer 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.
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.
Rule 10: Otherwise, leave the order unchanged. If DA preceded DB in the original list, prefer DA. Otherwise prefer DB.
Rule 10: Otherwise, leave the order unchanged. If DA preceded DB in the original list, prefer DA. Otherwise prefer DB.
Rules 9 and 10 may be superseded if the implementation has other means of sorting destination addresses. For example, if the implementation somehow knows which destination addresses will result in the "best" communications performance.
Rules 9 and 10 may be superseded if the implementation has other means of sorting destination addresses. For example, if the implementation somehow knows which destination addresses will result in the "best" communications performance.
7. Interactions with Routing
7. Interactions with Routing
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.
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.
For example, suppose a node has interfaces on two different links, with both links having a working default router. Both of the interfaces have preferred (in the RFC 2462 sense) global addresses. When sending to a global destination address, if there's no routing reason to prefer one interface over the other, then an implementation may preferentially choose the outgoing interface that will allow it to use the source address that shares a longer common prefix with the destination.
Implementations may also use the choice of router to influence the choice of source address. For example, suppose a host is on a link with two routers. One router is advertising a global prefix A and the other router is advertising global prefix B. Then when sending via the first router, the host may prefer source addresses with prefix A and when sending via the second router, prefer source addresses with prefix B.
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.
Draves Standards Track [Page 14] RFC 3484 Default Address Selection for IPv6 February 2003
Draves Standards Track [Page 14] RFC 3484 Default Address Selection for IPv6 February 2003
8. Implementation Considerations
8. Implementation Considerations
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.
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.
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.
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.
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.
In any case, if the implementation uses cached and possibly stale information in its implementation of destination address selection, or if the ordering of a cached list of destination addresses is possibly stale, then it should ensure that the destination address ordering returned to the application is no more than one second out of date. For example, an implementation might make a system call to check if any routing table entries or source address assignments that might affect these algorithms have changed. Another strategy is to use an invalidation counter that is incremented whenever any underlying state is changed. By caching the current invalidation counter value with derived state and then later comparing against the current value, the implementation could detect if the derived state is potentially stale.
9. Security Considerations
9. Security Considerations
This document has no direct impact on Internet infrastructure security.
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
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
Draves Standards Track [Page 15] RFC 3484 Default Address Selection for IPv6 February 2003
Draves Standards Track [Page 15] RFC 3484 Default Address Selection for IPv6 February 2003
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.
multicast address, or perhaps the upper-layer protocol chosen for the attack does not specify a particular source address for its reply packets.) By using different addresses for itself, the unfriendly node can cause the target node to expose the target's own addresses.
10. Examples
10. Examples
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.
This section contains a number of examples, first of default behavior and then demonstrating the utility of policy table configuration. These examples are provided for illustrative purposes; they should not be construed as normative.
10.1. Default Source Address Selection
10.1. Default Source Address Selection
The source address selection rules, in conjunction with the default policy table, produce the following behavior:
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: 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: 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: 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: 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: 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: 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 or 3ffe::2 Result: 2001::2 (longest-matching-prefix)
Draves Standards Track [Page 16] RFC 3484 Default Address Selection for IPv6 February 2003
Draves Standards Track [Page 16] RFC 3484 Default Address Selection for IPv6 February 2003
Destination: 2001::1 Candidate Source Addresses: 2001::2 (care-of address) or 3ffe::2 (home address) Result: 3ffe::2 (prefer home address)
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: 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)
Destination: 2001::d5e3:0:0:1 Candidate Source Addresses: 2001::2 or 2001::d5e3:7953:13eb:22e8 (temporary) Result: 2001::2 (prefer public address)
10.2. Default Destination Address Selection
10.2. Default Destination Address Selection
The destination address selection rules, in conjunction with the default policy table and the source address selection rules, produce the following behavior:
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: 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: 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 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 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 (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)
Draves Standards Track [Page 17] RFC 3484 Default Address Selection for IPv6 February 2003
Draves Standards Track [Page 17] RFC 3484 Default Address Selection for IPv6 February 2003
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 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: 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 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)
Candidate Source Addresses: 2002:836b:4179::2 or 2001::2 or fe80::2 Destination Address List: 2002:836b:4179::1 or 2001::1 Result: 2001::1 (src 2001::2) then 2002:836b:4179::1 (src 2002:836b:4179::2) (prefer higher precedence)
10.3. Configuring Preference for IPv6 or IPv4
10.3. Configuring Preference for IPv6 or 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:
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:
Prefix Precedence Label
::1/128 50 0
::/0 40 1
2002::/16 30 2
::/96 20 3
::ffff:0:0/96 100 4
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:
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: 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: 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)
Draves Standards Track [Page 18] RFC 3484 Default Address Selection for IPv6 February 2003
Draves Standards Track [Page 18] RFC 3484 Default Address Selection for IPv6 February 2003
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)
Candidate Source Addresses: 2001::2 or fe80::1 or 10.1.2.4 Destination Address List: 2001::1 or 10.1.2.3 New Result: 10.1.2.3 (src 10.1.2.4) then 2001::1 (src 2001::2) (prefer higher precedence)
10.4. Configuring Preference for Scoped Addresses
10.4. Configuring Preference for Scoped Addresses
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:
The destination address selection rules give preference to destinations of smaller scope. For example, a site-local destination will be sorted before a global scope destination when the two are otherwise equally suitable. An administrator can change the policy table to reverse this preference and sort global destinations before site-local destinations, and site-local destinations before link- local destinations:
Prefix Precedence Label
::1/128 50 0
::/0 40 1
fec0::/10 37 1
fe80::/10 33 1
2002::/16 30 2
::/96 20 3
::ffff:0:0/96 10 4
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:
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 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)
Candidate Source Addresses: 2001::2 (deprecated) or fec0::2 or fe80::2 Destination Address List: 2001::1 or fec0::1 Unchanged Result: fec0::1 (src fec0::2) then 2001::1 (src 2001::2) (avoid deprecated addresses)
10.5. Configuring a Multi-Homed Site
10.5. Configuring a Multi-Homed Site
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.
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.
Draves Standards Track [Page 19] RFC 3484 Default Address Selection for IPv6 February 2003
Draves Standards Track [Page 19] RFC 3484 Default Address Selection for IPv6 February 2003
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.
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.
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.
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.
The default policy table and address selection rules produce the following behavior:
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)
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.
In other words, when a host in site A initiates a connection to a host in site B, the traffic does not take advantage of their connections to the high-performance ISP. This is not their desired behavior.
Candidate Source Addresses: 2001:aaaa:aaaa::a or 2007:0:aaaa::a or fe80::a Destination Address List: 2001:cccc:cccc::c or 2006:cccc:cccc::c Result: 2001:cccc:cccc::c (src 2001:aaaa:aaaa::a) then 2006:cccc:cccc::c (src 2007:0:aaaa::a) (longest matching prefix)
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.
In other words, when a host in site A initiates a connection to a host in some other site C, the reverse traffic may come back through the high-performance ISP. Again, this is not their desired behavior.
This predicament demonstrates the limitations of the longest- matching-prefix heuristic in multi-homed situations.
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:
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:
Draves Standards Track [Page 20] RFC 3484 Default Address Selection for IPv6 February 2003
Draves Standards Track [Page 20] RFC 3484 Default Address Selection for IPv6 February 2003
Prefix Precedence Label
::1 50 0
2001:aaaa:aaaa::/48 45 5
2001:bbbb:bbbb::/48 45 5
::/0 40 1
2002::/16 30 2
::/96 20 3
::ffff:0:0/96 10 4
接頭語先行は以下をラベルします:1 50 0 2001:aaaa:aaaa:、:/48 45 5 2001:bbbb:bbbb:、:/48 45 5 ::/0 40 1 2002::/16 30 2 ::/96 20 3 ::ffff: 0:0/96 10 4
This policy table produces the following behavior:
この方針テーブルは以下の振舞いを起こします:
Candidate Source Addresses: 2001:aaaa:aaaa::a or 2007:0:aaaa::a or fe80::a Destination Address List: 2001:bbbb:bbbb::b or 2007:0:bbbb::b New Result: 2001:bbbb:bbbb::b (src 2001:aaaa:aaaa::a) then 2007:0:bbbb::b (src 2007:0:aaaa::a) (prefer higher precedence)
候補ソースアドレス: 2001:aaaa:aaaa:、:aか2007:0:aaaa:、:aかfe80:、:目的地住所録: 2001:bbbb:bbbb:、:bか2007:0:bbbb:、:b新しいResult: 2001:bbbb:bbbb:、:b、(src2001:aaaa:aaaa: 次に、: a)2007:0:bbbb:、:b、(src2007:0:aaaa: : a)(より高い先行を好みます)
In other words, when a host in site A initiates a connection to a host in site B, the traffic uses the high-performance ISP as desired.
言い換えれば、サイトAのホストがサイトBのホストに接続を開始するとき、交通は望まれているように高性能ISPを使用します。
Candidate Source Addresses: 2001:aaaa:aaaa::a or 2007:0:aaaa::a or fe80::a Destination Address List: 2001:cccc:cccc::c or 2006:cccc:cccc::c New Result: 2006:cccc:cccc::c (src 2007:0:aaaa::a) then 2001:cccc:cccc::c (src 2007:0:aaaa::a) (longest matching prefix)
候補ソースアドレス: 2001:aaaa:aaaa:、:aか2007:0:aaaa:、:aかfe80:、:目的地住所録: 2001:cccc:cccc:、:cか2006:cccc:cccc:、:c新しいResult: 2006:cccc:cccc:、:c、(src2007:0:aaaa: 次に、: a)2001:cccc:cccc:、:c、(src2007:0:aaaa: : a)(最も長い合っている接頭語)
In other words, when a host in site A initiates a connection to a host in some other site C, the traffic uses the normal ISP as desired.
言い換えれば、サイトAのホストがある他のサイトCのホストに接続を開始するとき、交通は望まれているように正常なISPを使用します。
Normative References
引用規格
[1] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, July 1998.
[1]HindenとR.とS.デアリング、「IPバージョン6アドレッシング体系」、RFC2373、1998年7月。
[2] Thompson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462 , December 1998.
[2] トンプソンとS.とT.Narten、「IPv6の国がないアドレス自動構成」、RFC2462、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"での国がないアドレス自動構成のためのプライバシー拡大、RFC3041、2001年1月。」
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[4] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[5] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4
Clouds", RFC 3056, February 2001.
[5] 大工とB.とK.ムーア、「IPv4 Cloudsを通したIPv6 Domainsの接続」、RFC3056、2001年2月。
Draves Standards Track [Page 21] RFC 3484 Default Address Selection for IPv6 February 2003
IPv6 February 2003のためのDraves標準化過程[21ページ]RFC3484デフォルトアドレス選択
[6] Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)",
RFC 2765, February 2000.
[6]Nordmark、E.、「国がないIP/ICMP変換アルゴリズム(SIIT)」、RFC2765、2000年2月。
Informative References
有益な参照
[7] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
[7] ブラドナー、S.、「改正3インチ、BCP9、RFC2026、1996年インターネット標準化過程--10月。」
[8] Johnson, D. and C. Perkins, "Mobility Support in IPv6", Work in
Progress.
[8] ジョンソンとD.とC.パーキンス、「IPv6"での移動性サポート、進行中の仕事。」
[9] S. Cheshire, B. Aboba, "Dynamic Configuration of IPv4 Link-local
Addresses", Work in Progress.
[9] S.チェーシャー州、「IPv4のリンクローカルのアドレスの動的設定」というB.Abobaは進行中で働いています。
[10] Gilligan, R., Thomson, S., Bound, J. and W. Stevens, "Basic
Socket Interface Extensions for IPv6", RFC 2553, March 1999.
[10] ギリガンとR.とトムソンとS.とバウンドとJ.とW.スティーブンス、「IPv6"、RFC2553、1999年3月のための基本的なソケットインタフェース拡大。」
[11] S. Deering et. al, "IP Version 6 Scoped Address Architecture",
Work in Progress.
[11] et S.デアリングアル、「IPバージョン6はアドレス体系を見た」ProgressのWork。
[12] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. and E.
Lear, "Address Allocation for Private Internets", BCP 5, RFC
1918, February 1996.
[12] Rekhter(Y.、マスコウィッツ、B.、Karrenberg、D.、deグルート、G.、およびE.リア)は「個人的なインターネットのための配分を記述します」、BCP5、RFC1918、1996年2月。
[13] Baker, F, "Requirements for IP Version 4 Routers", RFC 1812,
June 1995.
[13] ベイカー、F、「IPバージョン4ルータのための要件」、RFC1812、1995年6月。
[14] Narten, T. and E. Nordmark, and W. Simpson, "Neighbor Discovery
for IP Version 6", RFC 2461, December 1998.
IPのために発見を近所付き合いさせてください。[14] Narten、T.、E.Nordmark、およびW.シンプソン、「バージョン6インチ、RFC2461、1998インチ年12月。
[15] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4
Domains without Explicit Tunnels", RFC 2529, March 1999.
[15] 大工とB.とC.ユング、「明白なTunnelsのいないIPv4ドメインの上のIPv6のトランスミッション」、RFC2529、1999年3月。
[16] F. Templin et. al, "Intra-Site Automatic Tunnel Addressing
Protocol (ISATAP)", Work in Progress.
[16] et F.テンプリンアル、「イントラサイトの自動トンネルアドレシングプロトコル(ISATAP)」、ProgressのWork。
[17] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6
Hosts and Routers", RFC 1933, April 1996.
[17] ギリガンとR.とE.Nordmark、「IPv6ホストとルータのための変遷メカニズム」、RFC1933、1996年4月。
Draves Standards Track [Page 22] RFC 3484 Default Address Selection for IPv6 February 2003
IPv6 February 2003のためのDraves標準化過程[22ページ]RFC3484デフォルトアドレス選択
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作業部会、特にマークBlanchet、ブライアンCarpenter、マット・クロフォード、アラン・ジュランド、スティーブ・デアリングロバートElz、6月-ichiro itojun Hagino、トニー・ハイン、M.T.ホリンガー、JINMEI Tatuya、トーマスNarten、エリックNordmark、ケン・パウエル、マルックSavela、ペッカSavola、Heshamソリマン、デーヴThaler、マウロTortonesi、Ole Troan、およびスティVenaasの貢献を承諾したがっています。 さらに、匿名のIESG評論家には、明確化のための多くの素晴らしいコメントと提案がありました。
Author's Address
作者のアドレス
Richard Draves Microsoft Research One Microsoft Way Redmond, WA 98052
リチャードDravesマイクロソフトは1つのマイクロソフト方法でレッドモンド、ワシントン 98052について研究します。
Phone: +1 425 706 2268 EMail: richdr@microsoft.com
以下に電話をしてください。 +1 2268年の425 706メール: richdr@microsoft.com
Draves Standards Track [Page 23] RFC 3484 Default Address Selection for IPv6 February 2003
IPv6 February 2003のためのDraves標準化過程[23ページ]RFC3484デフォルトアドレス選択
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Draves Standards Track [Page 24]
Draves標準化過程[24ページ]
一覧
スポンサーリンク
