[要約] RFC 5220は、RFC 3484のデフォルトルールの運用上の問題に関する問題声明であり、マルチプレフィックス環境でのデフォルトアドレス選択に関するものです。その目的は、デフォルトアドレス選択の問題を明確にし、改善策を提案することです。
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 RFC 3484 Default Rules
マルチプレフィックス環境でのデフォルトアドレス選択の問題ステートメント：RFC 3484デフォルトルールの運用上の問題
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".
一般的に言えば、ネクストホップの決定とアドレス選択の間に相互作用はありません。この例では、ホストが新しい接続を開始し、Router1を介してパケットを送信する場合、ホストは必ずしもアドレス2001：db8：1000：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つは、Router1とRouter2でソースアドレスベースのルーティングを採用することです。別のソリューションは、Router1、Router2、およびホストで静的ルーティングを使用し、ホストで対応する静的アドレス選択ポリシーを使用することです。
==================
| 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.
「顧客ネットワーク」と呼ばれる比較的小さなサイトが2つの上流ISPに接続されている場合、各ISPは通常 /48であるネットワークアドレスブロックを委任し、ホストには複数のIPv6アドレスがあります。
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によって委任されたものではない場合、IngressフィルターによってISPでパケットがドロップされる可能性があります。Ingressフィルタリングは、ISPの間でより一般的になり、サービス拒否（DOS）攻撃の損傷を軽減しています。
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.
ソリューション分析：このケースの可能なソリューションの1つは、ルーターでソースアドレスベースのルーティングを採用することです。別のソリューションは、ルーターで静的ルーティングを使用し、ホストで対応する静的アドレス選択ポリシーを使用することです。
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.
下の図に示すように、グローバルな半分閉鎖された接続性を備えたマルチホームサイトで、2番目の典型的なソースアドレス選択問題を見ることができます。この場合、Host-Aはマルチホームネットワークにあり、2つのIPv6アドレスがあり、1つは上流の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.
HOST-AがISP2でHost-Bへの接続を開始すると、ルール8のために送信されたパケットのソースアドレス（つまり、2001：DB8：8000：1 :: 100）から委任されたものとなります。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.
Host-Cはインターネット上のどこかにあり、IPv6アドレス2001：db8：a000 :: 1があります。ホストAがホストCにパケットを送信すると、ソースアドレスの最長マッチングアルゴリズムが2001：DB8：8000：1 :: 100を選択します。この場合、パケットはISP1を通過し、ISP1のイングレスフィルターによってフィルタリングされる場合があります。ISP1によってパケットがフィルタリングされていない場合でも、Host-Cからの返品パケットをHost-Aに配信することはできません。
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フレームワークで解決できます。たとえば、一部のアドレス選択ポリシーをHost-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.
ただし、将来的には、最長のマッチングルールが正しいアドレスを選択できなくなる可能性があります。これは、これらのグローバルユニキャストアドレスの割り当てが始まる瞬間です。最初のビットは1です。RFC4291[RFC4291]では、最初のビットが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：a：100 :: 100およびfd01：2：3：100 :: 100がある場合、ソースアドレスはFD01になります。2：3：100 :: 100、最長の一致ビットの長さは2001年の0であるため、DB8：A：100 :: 100、FD01：2：3：100 :: 1それぞれそれぞれ1です。
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]は、あるプレフィックスから別のプレフィックスにネットワークを変更するための推奨手順について説明しています。AutoConfiguredアドレスの寿命は一生であるため、古いプレフィックスの広告を停止することにより、最終的に自動構成アドレスが無効になります。
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.
+-----+---+
| 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（「Future Work」）は、より細かい粒度を備えたより良いアドレス選択メカニズムを達成するために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.
デフォルトのポリシーテーブルは、IPv4アドレスが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の優先順位付けの特別な形式です。EnterpriseにIPv4インターネット接続がありますが、まだIPv6インターネット接続を備えておらず、EnterpriseがサイトローカルIPv6接続を提供したい場合、ULAはサイトローカルIPv6接続に最適です。各従業員ホストには、IPv4グローバルまたはプライベートアドレスとULAの両方があります。ここで、このホストがDNSにAとAAAの両方のレコードを登録したHOST-Bに接続しようとすると、ホストは宛先アドレスとしてAAAAを選択し、ソースアドレスのULAを選択します。これにより、接続の障害が明らかになります。
+--------+
| 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フレームワークで解決できます。たとえば、一部のアドレス選択ポリシーをHost-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アドレスベースの認証は、この典型的な例です。もう1つの典型的な例は、従業員または関係者向けの公開ページおよび内部ページ用のページを持つWebサービスです。さらに別の例は、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フレームワークで解決できます。たとえば、一部のアドレス選択ポリシーをHost-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.
中間ルーターがポリシールーティング（例：ソースアドレスベースのルーティング）を実行すると、不適切なアドレス選択は予期しないルーティングを引き起こします。たとえば、セクション2.1.3で説明したネットワークでは、Host-Aがデフォルトのアドレス選択ポリシーを使用して不適切なアドレスを選択する場合、VPNに送信されるパケットをインターネット経由で場所に配信できます。この問題は、パケットの盗聴またはセッションハイジャックにつながる可能性があります。ただし、攻撃者からノードへの正しいパスにパケットを送信するのは簡単ではないため、これらの2つのリスクは深刻ではありません。
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のセキュリティに関する考慮事項セクションに記載されているように、アドレス選択アルゴリズムは潜在的なプライバシーの懸念を公開します。悪意のあるホストがターゲットホストにアドレスの選択を実行できる場合（たとえば、AnycastまたはMulticastパケットを送信することにより）、悪意のあるホストはターゲットホストに添付された複数のアドレスの知識を得ることができます。セクション2.1.4のような場合、攻撃者がホストにマルチキャストパケットを送信できるようにし、ホストがデフォルトのアドレス選択アルゴリズムを実行できる場合、攻撃者はホストに接続されたULAを決定できる場合があります。
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のステートレスアドレスAutoconfigurationのプライバシー拡張」、RFC 3041、2001年1月。
[RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3484] Draves、R。、「インターネットプロトコルバージョン6（IPv6）のデフォルトアドレス選択」、RFC 3484、2003年2月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775] Johnson、D.、Perkins、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] Baker、F.、Lear、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. Haberman、「ユニークなローカルIPv6ユニキャストアドレス」、RFC 4193、2005年10月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291] Hinden、R。およびS. Deering、「IPバージョン6アドレス指定アーキテクチャ」、RFC 4291、2006年2月。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.
[RFC4862] Thomson、S.、Narten、T。、およびT. Jinmei、「IPv6 Stateless Address Autoconfiguration」、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] van de Velde、G.、Hain、T.、Droms、R.、Carpenter、B。、およびE. Klein、「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
Matsumoto ntt PF Lab Midori-Cho 3-9-11 Musashino-Shi、Tokyo 180-8585 Japan
Phone: +81 422 59 3334
EMail: arifumi@nttv6.net
Tomohiro Fujisaki NTT PF Lab Midori-Cho 3-9-11 Musashino-shi, Tokyo 180-8585 Japan
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
Ruri Hiromi Intec Netcore, Inc. Shinsuna 1-3-3 Koto-ku, Tokyo 136-0075 Japan
Ruri Hiromi Intec Netcore、Inc。Shinsuna 1-3-3 Koto-ku、東京136-0075日本
Phone: +81 3 5665 5069
EMail: hiromi@inetcore.com
Ken-ichi Kanayama INTEC Systems Institute, Inc. Shimoshin-machi 5-33 Toyama-shi, Toyama 930-0804 Japan
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
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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への情報をお問い合わせください。