Network Working Group A. Matsumoto
Request for Comments: 5220 T. Fujisaki
Category: Informational NTT
R. Hiromi
Intec Netcore
K. Kanayama
INTEC Systems
July 2008
Problem Statement for Default Address Selection in Multi-Prefix
Environments: Operational Issues of Default Rules
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Abstract
抽象
A single physical link can have multiple prefixes assigned to it. In that environment, end hosts might have multiple IP addresses and be required to use them selectively. RFC 3484 defines default source and destination address selection rules and is implemented in a variety of OSs. But, it has been too difficult to use operationally for several reasons. In some environments where multiple prefixes are assigned on a single physical link, the host using the default address selection rules will experience some trouble in communication. This document describes the possible problems that end hosts could encounter in an environment with multiple prefixes.
単一の物理リンクは、それに割り当てられた複数のプレフィックスを持つことができます。その環境では、エンドホストが複数のIPアドレスを持っている可能性があり、それらを選択的に使用するために必要なこと。 RFC 3484は、デフォルトの送信元および宛先アドレス選択ルールを定義するとOSのさまざまな実装されています。しかし、いくつかの理由で運用に使用するには余りにも困難でした。複数のプレフィックスは、単一の物理リンクに割り当てられている一部の環境では、デフォルトのアドレス選択ルールを使用して、ホストが通信中に何らかのトラブルが発生します。この文書では、ホストが複数のプレフィックスを持つ環境で遭遇する可能性が終わる可能性のある問題について説明します。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Scope of This Document .....................................3
2. Problem Statement ...............................................4
2.1. Source Address Selection ...................................4
2.1.1. Multiple Routers on a Single Interface ..............4
2.1.2. Ingress Filtering Problem ...........................5
2.1.3. Half-Closed Network Problem .........................6
2.1.4. Combined Use of Global and ULA ......................7
2.1.5. Site Renumbering ....................................8
2.1.6. Multicast Source Address Selection ..................9
2.1.7. Temporary Address Selection .........................9
2.2. Destination Address Selection .............................10
2.2.1. IPv4 or IPv6 Prioritization ........................10
2.2.2. ULA and IPv4 Dual-Stack Environment ................11
2.2.3. ULA or Global Prioritization .......................12
3. Conclusion .....................................................13
4. Security Considerations ........................................14
5. Normative References ...........................................14
In IPv6, a single physical link can have multiple prefixes assigned to it. In such cases, an end host may have multiple IP addresses assigned to an interface on that link. In the IPv4-IPv6 dual-stack environment or in a site connected to both a Unique Local Address (ULA) [RFC4193] and globally routable networks, an end host typically has multiple IP addresses. These are examples of the networks that we focus on in this document. In such an environment, an end host may encounter some communication troubles.
IPv6では、単一の物理リンクは、それに割り当てられた複数のプレフィックスを持つことができます。このような場合には、エンドホストは、リンク上のインターフェイスに割り当てられた複数のIPアドレスを有していてもよいです。 IPv4にIPv6のデュアルスタック環境でまたはユニークローカルアドレス（ULA）[RFC4193]とグローバルにルーティング可能なネットワークの両方に接続されているサイトでは、エンドホストは、一般的に複数のIPアドレスを持っています。これらは、私たちは、この文書に集中ネットワークの例です。このような環境では、エンドホストは、何らかの通信トラブルが発生することがあります。
Inappropriate source address selection at the end host causes unexpected asymmetric routing, filtering by a router, or discarding of packets because there is no route to the host.
エンドホストでの不適切なソースアドレス選択ホストへのルートがないため、予期しない非対称ルーティング、ルータによるフィルタリング、またはパケットの廃棄を引き起こします。
Considering a multi-prefix environment, destination address selection is also important for correct or better communication establishment.
マルチプレフィックス環境を考慮すると、送信先アドレスの選択も正しいか、より良い通信確立のために重要です。
RFC 3484 [RFC3484] defines default source and destination address selection algorithms and is implemented in a variety of OSs. But, it has been too difficult to use operationally for several reasons, such as lack of an autoconfiguration method. There are some problematic cases where the hosts using the default address selection rules encounter communication troubles.
RFC 3484 [RFC3484]は、デフォルトの送信元および宛先アドレス選択アルゴリズムを定義するとOSのさまざまな実装されています。しかし、このような自動設定方法がないことなど、いくつかの理由から、運用に使用するには余りにも困難でした。デフォルトアドレス選択規則を使用しているホストは、通信トラブルが発生したいくつかの問題の場合があります。
This document describes the possibilities of incorrect address selection that lead to dropping packets and communication failure.
この文書では、パケットのドロップや通信障害につながる誤ったアドレスの選択の可能性を説明しています。
As other mechanisms already exist, the multi-homing techniques for achieving redundancy are basically out of our scope.
他のメカニズムが既に存在するように、冗長性を実現するためのマルチホーミング技術は、我々の範囲の外に基本的です。
We focus on an end-site network environment and unmanaged hosts in such an environment. This is because address selection behavior at these kinds of hosts is difficult to manipulate, owing to the users' lack of knowledge, hosts' location, or massiveness of the hosts.
私たちは、このような環境では、エンドサイトのネットワーク環境と管理対象外のホストに焦点を当てます。ホストのこれらの種類のアドレス選択動作は、ユーザーの知識の欠如、ホストの場所、またはホストの莫大に起因して、操作することが困難であるためです。
The scope of this document is to sort out problematic cases related to address selection. It includes problems that can be solved in the framework of RFC 3484 and problems that cannot. For the latter, RFC 3484 might be modified to meet their needs, or another address selection solution might be necessary. For the former, an additional mechanism that mitigates the operational difficulty might be necessary.
この文書の範囲は、アドレス選択に関連する問題の例を整理することです。これは、RFC 3484とできない問題の枠組みの中で解決することができる問題を含んでいます。後者の場合は、RFC 3484には、彼らのニーズを満たすように変更される可能性があります、または別のアドレス選択ソリューションが必要になる場合があります。かつての場合、運用困難を軽減する追加のメカニズムが必要になる場合があります。
This document also includes simple solution analysis for each problematic case. This analysis basically just focuses on whether or not the case can be solved in the framework of RFC 3484. If not, some possible solutions are described. Even if a case can be solved in the framework of RFC 3484, as mentioned above, it does not necessarily mean that there is no operational difficulty. For example, in the environment stated above, it is not a feasible solution to configure each host's policy table by hand. So, for such a solution, the difficulty of configuration is yet another common problem.
この文書は、各問題の場合のための簡単な解決策の分析を含みます。この分析は、基本的にはケースはRFC 3484の枠組みの中で解決することができない場合、いくつかの可能な解決策が説明されているかどうかに焦点を当てています。前述したように場合は、RFC 3484の枠組みの中で解決することができたとしても、それは必ずしも何の操作難易度が存在しないことを意味するものではありません。例えば、上記の環境では、手で各ホストのポリシーテーブルを設定するために実行可能な解決ではありません。ですから、そのような解決のために、設定の難しさは、さらに別の共通の問題です。
==================
| Internet |
==================
| |
2001:db8:1000::/36 | | 2001:db8:8000::/36
+----+-+ +-+----+
| ISP1 | | ISP2 |
+----+-+ +-+----+
| |
2001:db8:1000:::/48 | | 2001:db8:8000::/48
+-----+---+ +----+----+
| Router1 | | Router2 |
+-------+-+ +-+-------+
| |
2001:db8:1000:1::/64 | | 2001:db8:8000:1::/64
| |
-----+-+-----+------
|
+-+----+ 2001:db8:1000:1::100
| Host | 2001:db8:8000:1::100
+------+
Figure 1
図1
Generally speaking, there is no interaction between next-hop determination and address selection. In this example, when a host starts a new connection and sends a packet via Router1, the host does not necessarily choose address 2001:db8:1000:1::100 given by Router1 as the source address. This causes the same problem as described in the next section, "Ingress Filtering Problem".
一般的に言って、次のホップの決意とアドレス選択の間の相互作用はありません。ホストが新しい接続を開始し、ルータ1を経由してパケットを送信するとき、この例では、ホストは、必ずしもアドレス2001を選択していません：DB8：1000：1 ::ソースアドレスとしてルータ1によって与えられる100。これは、次のセクション、「入力フィルタリングの問題」で説明したのと同じ問題が発生します。
Solution analysis: As this case depends on next-hop selection, controlling the address selection behavior at the Host alone doesn't solve the entire problem. One possible solution for this case is adopting source-address-based routing at Router1 and Router2. Another solution may be using static routing at Router1, Router2, and the Host, and using the corresponding static address selection policy at the Host.
ソリューション分析：この場合は、ホストのアドレス選択動作を制御し、ネクストホップの選択に依存するだけでは全体の問題を解決していません。この場合の一つの可能な解決策は、ルータ1及びルータ2のソースアドレスベースのルーティングを採用しています。別の解決策は、ルータ1、ルータ2でスタティックルーティングを使用して、ホスト、およびホストに対応する静的アドレス選択ポリシーを使用してもよいです。
==================
| Internet |
==================
| |
2001:db8:1000::/36 | | 2001:db8:8000::/36
+----+-+ +-+----+
| ISP1 | | ISP2 |
+----+-+ +-+----+
| |
2001:db8:1000:::/48 | | 2001:db8:8000::/48
++-------++
| Router |
+----+----+
| 2001:db8:1000:1::/64
| 2001:db8:8000:1::/64
------+---+----------
|
+-+----+ 2001:db8:1000:1::100
| Host | 2001:db8:8000:1::100
+------+
Figure 2
図2
When a relatively small site, which we call a "customer network", is attached to two upstream ISPs, each ISP delegates a network address block, which is usually /48, and a host has multiple IPv6 addresses.
ときに私たちは、「顧客のネットワーク」と呼んで比較的小さなサイトでは、各ISP代表団は、通常は/ 48であり、ホストが複数のIPv6アドレスを持つネットワークアドレスブロックは、2つのアップストリームのISPに接続されています。
When the source address of an outgoing packet is not the one that is delegated by an upstream ISP, there is a possibility that the packet will be dropped at the ISP by its ingress filter. Ingress filtering is becoming more popular among ISPs to mitigate the damage of denial-of-service (DoS) attacks.
発信パケットの送信元アドレスが上流ISPによって委任されたものでない場合、パケットがイングレスフィルタによってISPでドロップされる可能性があります。イングレスフィルタリングは、サービス拒否（DoS）攻撃のダメージを軽減するためにISPの間でより人気が高まっています。
In this example, when the router chooses the default route to ISP2 and the host chooses 2001:db8:1000:1::100 as the source address for packets sent to a host (2001:db8:2000::1) somewhere on the Internet, the packets may be dropped at ISP2 because of ingress filtering.
この例では、ルータはISP2へのデフォルトルートを選択し、ホストが2001を選択したとき：DB8：1000：1 :: 100ホストに送信されたパケットの送信元アドレスとして（2001：DB8：2000 :: 1）上のどこかにインターネットは、パケットがために入力フィルタリングのISP2でドロップすることができます。
Solution analysis: One possible solution for this case is adopting source-address-based routing at the Router. Another solution may be using static routing at the Router, and using the corresponding static address selection policy at the Host.
溶液分析：この場合の一つの可能な解決策は、ルータのソースアドレスベースのルーティングを採用しています。別の解決策は、ルータに静的なルーティングを使用して、ホストに対応する静的アドレス選択ポリシーを使用してもよいです。
You can see a second typical source address selection problem in a multi-homed site with global half-closed connectivity, as shown in the figure below. In this case, Host-A is in a multi-homed network and has two IPv6 addresses, one delegated from each of the upstream ISPs. Note that ISP2 is a closed network and does not have connectivity to the Internet.
以下の図に示すように、グローバルなハーフクローズ接続とマルチホームサイトにおける第二の典型的なソースアドレス選択問題を見ることができます。この場合、ホストAは、マルチホームネットワーク内にあり、2つのIPv6アドレス、上流のISPのそれぞれから委任つを有します。 ISP2は、閉じたネットワークで、インターネットへの接続性を持っていないことに注意してください。
+--------+
| Host-C | 2001:db8:a000::1
+-----+--+
|
============== +--------+
| Internet | | Host-B | 2001:db8:8000::1
============== +--------+
| |
2001:db8:1000:/36 | | 2001:db8:8000::/36
+----+-+ +-+---++
| ISP1 | | ISP2 | (Closed Network/VPN tunnel)
+----+-+ +-+----+
| |
2001:db8:1000:/48 | | 2001:db8:8000::/48
++-------++
| Router |
+----+----+
| 2001:db8:1000:1::/64
| 2001:db8:8000:1::/64
------+---+----------
|
+--+-----+ 2001:db8:1000:1::100
| Host-A | 2001:db8:8000:1::100
+--------+
Figure 3
図3
You do not need two physical network connections here. The connection from the Router to ISP2 can be a logical link over ISP1 and the Internet.
あなたはここに2つの物理ネットワーク接続を必要としません。 ISP2へのルーターからの接続はISP1とインターネット上で論理リンクすることができます。
When Host-A starts the connection to Host-B in ISP2, the source address of a packet that has been sent will be the one delegated from ISP2 (that is, 2001:db8:8000:1::100) because of rule 8 (longest matching prefix) in RFC 3484.
ホストAがISP2で-Bのホストへの接続を開始すると、送信されたパケットの送信元アドレスがISP2から委任されたものであろう（すなわち、2001：DB8：8000：1 :: 100）ためのルール8のRFC 3484に（最長一致プレフィクス）。
Host-C is located somewhere on the Internet and has IPv6 address 2001:db8:a000::1. When Host-A sends a packet to Host-C, the longest matching algorithm chooses 2001:db8:8000:1::100 for the source address. In this case, the packet goes through ISP1 and may be filtered by ISP1's ingress filter. Even if the packet is not filtered by ISP1, a return packet from Host-C cannot possibly be delivered to Host-A because the return packet is destined for 2001: db8:8000:1::100, which is closed from the Internet.
ホストCは、インターネット上のどこかに位置し、IPv6アドレス2001ありさ：DB8：A000 :: 1。ホストAは、ホストCにパケットを送信する場合、最長一致アルゴリズム2001を選択：DB8：8000：1 ::ソースアドレス100。この場合、パケットはISP1を通過し、ISP1の侵入フィルタによってフィルタリングすることができます。パケットはISP1によってフィルタリングされていない場合でも、戻りパケットは2001年のために運命づけられているので、ホストCからの戻りパケットは、おそらく-Aをホストに配信することができません：DB8：8000：1 :: 100、インターネットから閉鎖されています。
The important point is that each host chooses a correct source address for a given destination address. To solve this kind of network-policy-based address selection problem, it is likely that delivering additional information to a node provides a better solution than using algorithms that are local to the node.
重要な点は、各ホストが特定の宛先アドレスの正しいソースアドレスを選択することです。ネットワーク・ポリシーベースのアドレス選択この種の問題を解決するために、ノードに追加情報を提供するノードにローカルなアルゴリズムを使用するよりも、より良い解決策を提供する可能性があります。
Solution analysis: This problem can be solved in the RFC 3484 framework. For example, configuring some address selection policies into Host-A's RFC 3484 policy table can solve this problem.
ソリューション分析：この問題は、RFC 3484の枠組みで解決することができます。たとえば、ホストAのRFC 3484方針テーブルにいくつかのアドレス選択ポリシーを設定することで、この問題を解決することができます。
============
| Internet |
============
|
|
+----+----+
| ISP |
+----+----+
|
2001:db8:a::/48 |
+----+----+
| Router |
+-+-----+-+
| | 2001:db8:a:100::/64
fd01:2:3:200:/64 | | fd01:2:3:100:/64
-----+--+- -+--+----
| |
fd01:2:3:200::101 | | 2001:db8:a:100::100
+----+----+ +-+----+ fd01:2:3:100::100
| Printer | | Host |
+---------+ +------+
Figure 4
図4
As RFC 4864 [RFC4864] describes, using a ULA may be beneficial in some scenarios. If the ULA is used for internal communication, packets with the ULA need to be filtered at the Router.
RFC 4864 [RFC4864]が記載したように、ULAを使用すると、いくつかのシナリオにおいて有益であり得ます。 ULAは、内部通信のために使用される場合、ULAのパケットは、ルータでフィルタリングする必要があります。
This case does not presently create an address selection problem because of the dissimilarity between the ULA and the global unicast address. The longest matching rule of RFC 3484 chooses the correct address for both intra-site and extra-site communication.
この場合は、現在ので、ULAとグローバルユニキャストアドレス間の相違のアドレス選択問題を作成しません。 RFC 3484の最長一致規則は、イントラサイトとエクストラサイト通信の両方のための正しいアドレスを選択します。
In the future, however, there is a possibility that the longest matching rule will not be able to choose the correct address anymore. That is the moment when the assignment of those global unicast addresses starts, where the first bit is 1. In RFC 4291 [RFC4291], almost all address spaces of IPv6, including those whose first bit is 1, are assigned as global unicast addresses.
将来的には、しかし、最長一致規則はもう正しいアドレスを選択することができなくなる可能性があります。すなわち、これらのグローバルユニキャストアドレスの割り当ては、最初のビットが[RFC4291] RFC 4291で1である場合、開始、その最初のビット1であるものを含めたIPv6のほとんどすべてのアドレス空間は、グローバルユニキャストアドレスとして割り当てられた瞬間です。
Namely, when we start to assign a part of the address block 8000::/1 as the global unicast address and that part is used somewhere in the Internet, the longest matching rule ceases to function properly for the people trying to connect to the servers with those addresses.
グローバルユニキャストアドレスとその一部がインターネットのどこかで使用されているようすなわち、我々はアドレスブロック8000の一部を割り当てるために起動したときに:: / 1、最長一致規則は、サーバーに接続しようとしている人々のために適切に機能しなくなりますこれらのアドレスを持ちます。
For example, when the destination host has an IPv6 address 8000::1, and the originating host has 2001:db8:a:100::100 and fd01:2:3:100::100, the source address will be fd01:2:3:100::100, because the longest matching bit length is 0 for 2001:db8:a:100::100 and 1 for fd01:2:3:100::100, respectively.
例えば、宛先ホストがIPv6アドレス8000 :: 1を有し、発信元ホスト2001有する場合：DB8：100 :: 100及びFD01：3：2：100 :: 100、送信元アドレスは、FD01であろう。 3：2：100 :: 100、最長一致ビット長が2001 0であるため：DB8：FD01 100 :: 100及び1：3：2：100 :: 100、それぞれ。
Solution analysis: This problem can be solved in the RFC 3484 framework. For example, configuring some address selection policies into the Host's RFC 3484 policy table can solve this problem. Another solution is to modify RFC 3484 and define ULA's scope smaller than the global scope.
ソリューション分析：この問題は、RFC 3484の枠組みで解決することができます。たとえば、ホストのRFC 3484方針テーブルにいくつかのアドレス選択ポリシーを設定することで、この問題を解決することができます。別の解決策は、RFC 3484を変更し、グローバルスコープよりも小さいULAの範囲を定義することです。
RFC 4192 [RFC4192] describes a recommended procedure for renumbering a network from one prefix to another. An autoconfigured address has a lifetime, so by stopping advertisement of the old prefix, the autoconfigured address is eventually invalidated.
RFC 4192 [RFC4192]は別のプレフィックスからネットワークをリナンバリングするための推奨手順を説明します。古いプレフィックスの広告を停止することにより、自動構成アドレスが最終的に無効化されるので、自動設定アドレスは、寿命があります。
However, invalidating the old prefix takes a long time. You cannot stop routing to the old prefix as long as the old prefix is not removed from the host. This can be a tough issue for ISP network administrators.
しかし、古い接頭辞を無効にすることは、長い時間がかかります。あなたは限り古い接頭語がホストから削除されないよう、古いプレフィックスへのルーティングを停止することはできません。これは、ISPのネットワーク管理者のための厳しい問題になることができます。
There is a technique of advertising the prefix with the preferred lifetime zero; however, RFC 4862 [RFC4862], Section 5.5.4, does not absolutely prohibit the use of a deprecated address for a new outgoing connection due to limitations on the capabilities of applications.
好適寿命がゼロでプレフィックスを広告する技術があります。しかし、RFC 4862 [RFC4862]、セクション5.5.4は、絶対に起因するアプリケーションの機能上の制限のために新しい発信接続のための非推奨アドレスの使用を禁止するものではありません。
+-----+---+
| Router |
+----+----+
| 2001:db8:b::/64 (new)
| 2001:db8:a::/64 (old)
------+---+----------
|
+--+---+ 2001:db8:b::100 (new)
| Host | 2001:db8:a::100 (old)
+------+
Figure 5
図5
Solution analysis: This problem can be mitigated in the RFC 3484 framework. For example, configuring some address selection policies into the Host's RFC 3484 policy table can solve this problem.
ソリューション分析：この問題は、RFC 3484の枠組みに緩和することができます。たとえば、ホストのRFC 3484方針テーブルにいくつかのアドレス選択ポリシーを設定することで、この問題を解決することができます。
This case is an example of site-local or global unicast prioritization. When you send a multicast packet across site borders, the source address of the multicast packet should be a globally routable address. The longest matching algorithm, however, selects a ULA if the sending host has both a ULA and a Global Unicast Address.
この場合は、サイトローカルまたはグローバルユニキャストの優先順位付けの一例です。あなたはサイトの国境を越えてマルチキャストパケットを送信すると、マルチキャストパケットの送信元アドレスは、グローバルにルーティング可能なアドレスでなければなりません。送信ホストは、ULAとグローバルユニキャストアドレスの両方を有する場合、最長一致アルゴリズムは、しかしながら、ULAを選択します。
Solution analysis: This problem can be solved in the RFC 3484 framework. For example, configuring some address selection policies into the sending host's RFC 3484 policy table can solve this problem.
ソリューション分析：この問題は、RFC 3484の枠組みで解決することができます。例えば、送信側のホストのRFC 3484方針テーブルにいくつかのアドレス選択ポリシーを設定することで、この問題を解決することができます。
RFC 3041 [RFC3041] defines a Temporary Address. The usage of a Temporary Address has both pros and cons. It is good for viewing web pages or communicating with the general public, but it is bad for a service that uses address-based authentication and for logging purposes.
RFC 3041 [RFC3041]は一時アドレスを定義します。一時アドレスの使用は、長所と短所の両方があります。これは、Webページの表示や一般市民との通信のために良いですが、それは、アドレスベースの認証を使用するサービスのために、ロギングのために悪いです。
If you could turn the temporary address on and off, that would be better. If you could switch its usage per service (destination address), that would also be better. The same situation can be found when using an HA (home address) and a CoA (care-of address) in a Mobile IPv6 [RFC3775] network.
あなたはオンとオフの一時的なアドレスを回すことができれば、それが良いだろう。あなたはサービスごとにその利用状況（宛先アドレス）を切り替えることができれば、それも良いだろう。モバイルIPv6 [RFC3775]ネットワーク内のHA（ホームアドレス）とCoA（気付アドレス）を使用したときと同じ状況が見つけることができます。
Section 6 ("Future Work") of RFC 3041 discusses that an API extension might be necessary to achieve a better address selection mechanism with finer granularity.
RFC 3041のセクション6は、（「今後の課題」）APIの拡張機能は、より細かい粒度で、より良いアドレス選択メカニズムを達成するために必要かもしれないと論じています。
Solution analysis: This problem cannot be solved in the RFC 3484 framework. A possible solution is to make applications to select desirable addresses by using the IPv6 Socket API for Source Address Selection defined in RFC 5014 [RFC5014].
ソリューション分析：この問題は、RFC 3484の枠組みで解決することはできません。可能な解決策は、RFC 5014 [RFC5014]で定義されたソースアドレス選択のIPv6ソケットAPIを使用して、望ましいアドレスを選択するようにアプリケーションを作ることです。
The default policy table gives IPv6 addresses higher precedence than IPv4 addresses. There seem to be many cases, however, where network administrators want to control the address selection policy of end hosts so that it is the other way around.
デフォルトポリシーテーブルは、IPv6はIPv4アドレスよりも高い優先順位を与え取り組みます。ネットワーク管理者は、それが他の方法で回避されるように、エンドホストのアドレス選択ポリシーを制御したい場合は、しかし、多くの例があるように思われます。
+---------+
| Tunnel |
| Service |
+--+---++-+
| ||
| ||
===========||==
| Internet || |
===========||==
| ||
192.0.2.0/24 | ||
+----+-+ ||
| ISP | ||
+----+-+ ||
| ||
IPv4 (Native) | || IPv6 (Tunnel)
192.0.2.0/26 | ||
++-----++-+
| Router |
+----+----+
| 2001:db8:a:1::/64
| 192.0.2.0/28
|
------+---+----------
|
+-+----+ 2001:db8:a:1::100
| Host | 192.0.2.2
+------+
Figure 6
図6
In the figure above, a site has native IPv4 and tunneled IPv6 connectivity. Therefore, the administrator may want to set a higher priority for using IPv4 than for using IPv6 because the quality of the tunnel network seems to be worse than that of the native transport.
上の図では、サイトがネイティブIPv4およびトンネリングされたIPv6接続を持っています。そのため、管理者は、トンネルネットワークの品質は、ネイティブの輸送のそれよりも悪いように思わので、IPv6を使用するよりもIPv4を使用するために高い優先度を設定することもできます。
Solution analysis: This problem can be solved in the RFC 3484 framework. For example, configuring some address selection policies into the Host's RFC 3484 policy table can solve this problem.
ソリューション分析：この問題は、RFC 3484の枠組みで解決することができます。たとえば、ホストのRFC 3484方針テーブルにいくつかのアドレス選択ポリシーを設定することで、この問題を解決することができます。
This is a special form of IPv4 and IPv6 prioritization. When an enterprise has IPv4 Internet connectivity but does not yet have IPv6 Internet connectivity, and the enterprise wants to provide site-local IPv6 connectivity, a ULA is the best choice for site-local IPv6 connectivity. Each employee host will have both an IPv4 global or private address and a ULA. Here, when this host tries to connect to Host-B that has registered both A and AAAA records in the DNS, the host will choose AAAA as the destination address and the ULA for the source address. This will clearly result in a connection failure.
これは、IPv4とIPv6の優先順位付けの特殊な形式です。企業は、IPv4インターネット接続を持っているが、まだIPv6インターネット接続を持っていない、と企業がサイトローカルIPv6接続を提供したい場合は、ULAは、サイトローカルIPv6接続のための最良の選択です。各従業員のホストは、IPv4グローバルまたはプライベートアドレスとULAの両方を持つことになります。このホストがDNSの両方のAとAAAAレコードを登録した-Bをホストに接続しようとするとここでは、ホストは、宛先アドレスと送信元アドレスのためのULAとしてAAAAを選択します。これは明らかに接続障害になります。
+--------+
| Host-B | AAAA = 2001:db8::80
+-----+--+ A = 192.0.2.1
|
============
| Internet |
============
| no IPv6 connectivity
+----+----+
| Router |
+----+----+
|
| fd01:2:3::/48 (ULA)
| 192.0.2.128/25
++--------+
| Router |
+----+----+
| fd01:2:3:4::/64 (ULA)
| 192.0.2.240/28
------+---+----------
|
+-+------+ fd01:2:3:4::100 (ULA)
| Host-A | 192.0.2.245
+--------+
Figure 7
図7
Solution analysis: This problem can be solved in the RFC 3484 framework. For example, configuring some address selection policies into Host-A's RFC 3484 policy table can solve this problem.
ソリューション分析：この問題は、RFC 3484の枠組みで解決することができます。たとえば、ホストAのRFC 3484方針テーブルにいくつかのアドレス選択ポリシーを設定することで、この問題を解決することができます。
Differentiating services by the client's source address is very common. IP-address-based authentication is a typical example of this. Another typical example is a web service that has pages for the public and internal pages for employees or involved parties. Yet another example is DNS zone splitting.
クライアントの送信元アドレスによってサービスを差別化することは非常に一般的です。 IPアドレスベースの認証は、この典型的な例です。もう一つの典型的な例は、従業員や関係者のための公共および内部ページ用のページを持っているウェブサービスです。さらに別の例では、DNSゾーンの分割です。
However, a ULA and an IPv6 global address both have global scope, and RFC 3484 default rules do not specify which address should be given priority. This point makes IPv6 implementation of address-based service differentiation a bit harder.
しかし、ULAとIPv6のグローバルアドレスの両方がグローバルスコープを持ち、RFC 3484のデフォルトのルールが優先されるべきアドレスを指定しないでください。この点は、アドレスベースのサービスの差別のIPv6の実装が少し難しくなります。
+--------+
| Host-B |
+-+--|---+
| |
===========|==
| Internet | |
===========|==
| |
| |
+----+-+ +-->+------+
| ISP +------+ DNS | 2001:db8:a::80
+----+-+ +-->+------+ fc12:3456:789a::80
| |
2001:db8:a::/48 | |
fc12:3456:789a::/48 | |
+----+----|+
| Router ||
+---+-----|+
| | 2001:db8:a:100::/64
| | fc12:3456:789a:100::/64
--+-+---|-----
| |
+-+---|--+ 2001:db8:a:100::100
| Host-A | fc12:3456:789a:100::100
+--------+
Figure 8
図8
Solution analysis: This problem can be solved in the RFC 3484 framework. For example, configuring some address selection policies into Host-A's RFC 3484 policy table can solve this problem.
ソリューション分析：この問題は、RFC 3484の枠組みで解決することができます。たとえば、ホストAのRFC 3484方針テーブルにいくつかのアドレス選択ポリシーを設定することで、この問題を解決することができます。
We have covered problems related to destination or source address selection. These problems have their roots in the situation where end hosts have multiple IP addresses. In this situation, every end host must choose an appropriate destination and source address; this choice cannot be achieved only by routers.
私たちは、宛先や送信元アドレス選択に関連する問題をカバーしています。これらの問題は、エンドホストが複数のIPアドレスを持っている状況で自分のルーツを持っています。このような状況では、すべてのエンドホストは、適切な宛先と送信元アドレスを選択する必要があります。この選択は、ルータだけでは達成できません。
It should be noted that end hosts must be informed about routing policies of their upstream networks for appropriate address selection. A site administrator must consider every possible address false-selection problem and take countermeasures beforehand.
エンドホストが適切なアドレス選択のための彼らの上流のネットワークのルーティングポリシーについて通知しなければならないことに留意すべきです。サイト管理者は、すべての可能なアドレス誤選択問題を考慮し、事前に対策を取る必要があります。
When an intermediate router performs policy routing (e.g., source-address-based routing), inappropriate address selection causes unexpected routing. For example, in the network described in Section 2.1.3, when Host-A uses a default address selection policy and chooses an inappropriate address, a packet sent to a VPN can be delivered to a location via the Internet. This issue can lead to packet eavesdropping or session hijack. However, sending the packet back to the correct path from the attacker to the node is not easy, so these two risks are not serious.
中間ルータがポリシールーティング（例えば、送信元アドレスベースのルーティング）を行う際に、不適切なアドレスの選択は、予期しないルーティングを引き起こします。例えば、ホストAは、デフォルトのアドレス選択ポリシーを使用して、不適切なアドレスを選択し、セクション2.1.3に記載のネットワークにおいて、VPNに送信されたパケットは、インターネットを介して場所に送達することができます。この問題は、パケットの盗聴やセッションハイジャックにつながることができます。しかし、ノードへの攻撃者から戻って正しいパスにパケットを送信することは容易ではないので、これら二つのリスクは深刻ではありません。
As documented in the Security Considerations section of RFC 3484, address selection algorithms expose a potential privacy concern. When a malicious host can make a target host perform address selection (for example, by sending an anycast or multicast packet), the malicious host can get knowledge of multiple addresses attached to the target host. In a case like Section 2.1.4, if an attacker can make the Host to send a multicast packet and the Host performs the default address selection algorithm, the attacker may be able to determine the ULAs attached to the host.
RFC 3484のセキュリティの考慮事項のセクションに記載されているように、アドレス選択アルゴリズムは、潜在的なプライバシーの懸念を公開します。悪質なホストは、ターゲットホストを作ることができた場合（例えば、エニーキャストまたはマルチキャストパケットを送信することにより）アドレス選択を実行し、悪質なホストは、ターゲットホストに接続されている複数のアドレスの知識を得ることができます。攻撃者は、ホストがマルチキャストパケットを送信するために行うことができ、ホストがデフォルトアドレス選択アルゴリズムを実行する場合、セクション2.1.4のような場合には、攻撃者がホストに接続さULAsを決定することができます。
These security risks have roots in inappropriate address selection. Therefore, if a countermeasure is taken, and hosts always select an appropriate address that is suitable to a site's network structure and routing, these risks can be avoided.
これらのセキュリティリスクは、不適切なアドレス選択にルーツを持っています。対策を講じ、およびホストは、常にサイトのネットワーク構造とルーティングに適している適切なアドレスを選択した場合そのため、これらのリスクを回避することができます。
[RFC3041] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[RFC3041] Narten氏、T.およびR. Draves、 "IPv6におけるステートレスアドレス自動設定のための個人情報保護の拡張"、RFC 3041、2001年1月。
[RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3484] Draves、R.、RFC 3484 "インターネットプロトコルバージョン6（IPv6）のデフォルトのアドレス選択"、2003年2月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775]ジョンソン、D.、パーキンス、C.、およびJ. Arkko、 "IPv6におけるモビリティサポート"、RFC 3775、2004年6月。
[RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for Renumbering an IPv6 Network without a Flag Day", RFC 4192, September 2005.
[RFC4192]ベイカー、F.、リア、E.、およびR. Droms、 "国旗の日なしでIPv6ネットワークを再番号付けのための手順"、RFC 4192、2005年9月。
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005.
[RFC4193] HindenとR.とB.ハーバーマン、 "ユニークローカルIPv6ユニキャストアドレス"、RFC 4193、2005年10月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291] HindenとR.とS.デアリング、 "IPバージョン6アドレッシング体系"、RFC 4291、2006年2月。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.
[RFC4862]トムソン、S.、Narten氏、T.、およびT.神明、 "IPv6のステートレスアドレス自動設定"、RFC 4862、2007年9月。
[RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and E. Klein, "Local Network Protection for IPv6", RFC 4864, May 2007.
[RFC4864]ヴァン・デ・ヴェルデ、G.、ハイン、T.、Droms、R.、大工、B.、およびE.クライン、 "IPv6のローカルネットワークの保護"、RFC 4864、2007年5月。
[RFC5014] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6 Socket API for Source Address Selection", RFC 5014, September 2007.
[RFC5014] Nordmarkと、E.、Chakrabarti、S.、およびJ. Laganier、 "ソースアドレス選択のIPv6ソケットAPI"、RFC 5014、2007年9月。
Authors' Addresses
著者のアドレス
Arifumi Matsumoto NTT PF Lab Midori-Cho 3-9-11 Musashino-shi, Tokyo 180-8585 Japan
ありふみ まつもと んっｔ ＰＦ ぁｂ みどりーちょ ３ー９ー１１ むさしのーし、 ときょ １８０ー８５８５ じゃぱん
Phone: +81 422 59 3334 EMail: arifumi@nttv6.net
電話：+81 422 59 3334 Eメール：arifumi@nttv6.net
Tomohiro Fujisaki NTT PF Lab Midori-Cho 3-9-11 Musashino-shi, Tokyo 180-8585 Japan
ともひろ ふじさき んっｔ ＰＦ ぁｂ みどりーちょ ３ー９ー１１ むさしのーし、 ときょ １８０ー８５８５ じゃぱん
Phone: +81 422 59 7351 EMail: fujisaki@nttv6.net
電話：+81 422 59 7351 Eメール：fujisaki@nttv6.net
Ruri Hiromi Intec Netcore, Inc. Shinsuna 1-3-3 Koto-ku, Tokyo 136-0075 Japan
るり ひろみ いんてｃ ねｔこれ、 いんｃ。 しんすな １ー３ー３ ことーく、 ときょ １３６ー００７５ じゃぱん
Phone: +81 3 5665 5069 EMail: hiromi@inetcore.com
電話：+81 3 5665 5069 Eメール：hiromi@inetcore.com
Ken-ichi Kanayama INTEC Systems Institute, Inc. Shimoshin-machi 5-33 Toyama-shi, Toyama 930-0804 Japan
けんーいち かなやま いんてＣ Ｓｙｓてｍｓ いんｓちつて、 いんｃ。 しもしんーまち ５ー３３ とやまーし、 とやま ９３０ー０８０４ じゃぱん
Phone: +81 76 444 8088 EMail: kanayama_kenichi@intec-si.co.jp
電話：+81 76 444 8088 Eメール：kanayama_kenichi@intec-si.co.jp
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。