この文書はRFC 5220の日本語訳(和訳)です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、誤りの指摘は適切です。 この文書の配布は元のRFC同様に無制限です。
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 マルチプレフィックスの環境でのデフォルトアドレス選択の問題の宣言: RFC3484のデフォルト規則の運用上の問題 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 1. はじめに 1.1. Scope of This Document 1.1. この文書の範囲 2. Problem Statement 2. 問題宣言 2.1. Source Address Selection 2.1. ソースアドレス選択 2.1.1. Multiple Routers on a Single Interface 2.1.1. 単一のインタフェースの複数のルータ 2.1.2. Ingress Filtering Problem 2.1.2. 侵入フィルタ問題 2.1.3. Half-Closed Network Problem 2.1.3. 半開きネットワーク問題 2.1.4. Combined Use of Global and ULA 2.1.4. グローバルとULAの混在使用 2.1.5. Site Renumbering 2.1.5. サイトのアドレス変更 2.1.6. Multicast Source Address Selection 2.1.6. マルチキャストソースアドレス選択 2.1.7. Temporary Address Selection 2.1.7. 一時アドレス選択 2.2. Destination Address Selection 2.2. 宛先アドレス選択 2.2.1. IPv4 or IPv6 Prioritization 2.2.1. IPv4とIPv6の優先順位 2.2.2. ULA and IPv4 Dual-Stack Environment 2.2.2. ULAとIPv4二重スタック環境 2.2.3. ULA or Global Prioritization 2.2.3. ULAとグローバルの優先順位 3. Conclusion 3. 結論 4. Security Considerations 4. セキュリティの考察 5. Normative References 5. 参照する参考文献 1. Introduction 1. はじめに 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. この文書ははパケット破棄と通信障害に通じる不正確なアドレス選択の可能 性について説明します。 1.1. Scope of This Document 1.1. この文書の範囲 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の枠組みで事例を解決できても、上記のように、運用上の困難がな いことを意味するというわけではありません。例えば、上で述べられた環境 で、手で各ホストの方針テーブルを構成するのは、可能な解決策ではありま せん。それで、このような解決策での設定の困難さは別の共通問題です。 2. Problem Statement 2. 問題宣言 2.1. Source Address Selection 2.1. ソースアドレス選択 2.1.1. Multiple Routers on a Single Interface 2.1.1. 単一のインタフェースの複数のルータ ================== | 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を通してパケットを送る とき、ホストが必ず、ソースアドレスとしてルータ1から与えられたアドレ ス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つの可能な解決策は、 このような場合にルータ1とルータ2にソースアドレスベースのルーティ ングを採用させる事です。他の解決策は、ルータ1とルータ2とホスト で静的ルーティングを使用し、ホストで対応する静的アドレス選択方針 を使用する事です。 2.1.2. Ingress Filtering Problem 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. 私たちは「顧客ネットワーク」と呼ぶ、比較的小さいサイトは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から委任されているもので ないときに、パケット侵入フィルタによって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:2000::1)へ送るパケットのソー スアドレスに2001:db8:1000:1::100を選択するなら、パケットは侵入フィル タリングのために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つの可能な解決策はこのような場合ルータがソースアドレスに基づく ルーティングを採用する事です。他の解決法は、ルータでスタティック ルーティングを使用し、ホストで対応する静的なアドレス選択方針を使 用する事です。 2.1.3. Half-Closed Network Problem 2.1.3. 半開きネットワーク問題 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の典型的なソースアド レス選択問題を、以下の図に示します。この事例で、マルチホームネット ワークのホスト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に接続を始めるとき、送るパケットのソー スアドレスは、RFC 3484の規則8(最長一致プレフィックス)のために、 ISP2から委任されたもの(つまり、2001:db8:8000:1::100)です。 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でフィ ルタされなくても、ホストCからの応答パケットは宛先がdb8:8000:1::100 で、このアドレスはインターネットから閉じているので、ホスト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の枠組みでこの問題を解決できます。例えば、ホストAの RFC 3484方針テーブルにいくつかのアドレス選択方針を設定すると、 この問題を解決できます。 2.1.4. Combined Use of Global and ULA 2.1.4. グローバルとULAの混在使用 ============ | 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であるグローバルユニキャストアドレスの割 当が始まるときがその瞬間です。RFC 4291 [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を持つとき、 2001:db8:a:100::100との最長一致ビット数は0で、fd01:2:3:100::100 との最長一致ビット数は1なので、ソースアドレスはfd01:2:3: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の 範囲をグローバル範囲より狭く定義することです。 2.1.5. Site Renumbering 2.1.5. サイトのアドレス変更 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方針テーブルにいくつかのアドレス選択方針を設定すると、 この問題を解決できます。 2.1.6. Multicast Source Address Selection 2.1.6. マルチキャストソースアドレス選択 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方針テーブルにいくつかのアドレス選択方針を設 定すると、この問題を解決できます。 2.1.7. Temporary Address Selection 2.1.7. 一時アドレス選択 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]は一時アドレスを定義します。一時アドレスの使用法は、 賛否両論があります。ウェブページを見たり一般の通信では良いのですが、 アドレスベースの認証を使用するサービスとログ目的には悪いです。 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を使い、好ましいアドレスを選択する事 です、 2.2. Destination Address Selection 2.2. 宛先アドレス選択 2.2.1. IPv4 or IPv6 Prioritization 2.2.1. IPv4とIPv6の優先順位 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アドレスより高い優先権をIPv6アド レスに与えます。しかしながら、ネットワーク管理者が終端ホストのアドレ ス選択方針を制御したがる多くの事例で、それは逆です。 +---------+ | 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方針テーブルにいくつかのアドレス選択方針を設定すると、こ の問題を解決できます。 2.2.2. ULA and IPv4 Dual-Stack Environment 2.2.2. ULAとIPv4二重スタック環境 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に接続しようとするとき、ホストは宛先アド レスに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フレームワークでこの問題を解決できます。例えば、ホスト AHのRFC 3484方針テーブルにいくつかのアドレス選択方針を設定す ると、この問題を解決できます。 2.2.3. ULA or Global Prioritization 2.2.3. ULAとグローバルの優先順位 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方針テーブルにいくつかのアドレス選択方針を設定する と、この問題を解決できます。 3. Conclusion 3. 結論 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. 終端ホストは適切なアドレス選択のために上流ネットワークのルーティング 方針に関して知識が必要な事に注意するべきです。サイトの管理者は、あら ゆる可能なアドレスの誤った選択の問題を考えて、あらかじめ対抗策を取ら なければなりません。 4. Security Considerations 4. セキュリティの考察 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で送られます。この問題はパケッ ト盗聴やセッションハイジャックを導くことができます。しかしながら、攻 撃者からノードへの正しい経路にパケットを送り返すのが簡単でないので、 これらの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のセキュリティの考察で記述されるように、アドレス選択アルゴ リズムは、潜在的にプライバシの懸念があります。悪意があるホストが標 的ホストにアドレス選択を実施させる事が出来るなら(例えばエニキャスト かマルチキャストパケットを送ることで)、悪意があるホストは標的ホスト の複数のアドレスに関する知識を得ることができます。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. これらのセキュリティリスクは不適当なアドレス選択が原因です。したがっ て、対策を取って、ホストがいつもサイトのネットワーク構造とルーティン グに適した適切なアドレスを選択するなら、これらの危険を避けることがで きます。 5. Normative References 5. 参照する参考文献 [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001. [RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for Renumbering an IPv6 Network without a Flag Day", RFC 4192, September 2005. [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005. [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006. [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007. [RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and E. Klein, "Local Network Protection for IPv6", RFC 4864, May 2007. [RFC5014] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6 Socket API for Source Address Selection", RFC 5014, September 2007. 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 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 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 Phone: +81 76 444 8088 EMail: 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. この文書はBCP78に含まれる権利と許可と制限の適用を受け、そして この中に明らかにされる以外は著者がすべての権利を維持します。 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文書の権利に関する手続 きの情報はBCP78とBCP79を見てください。 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に情報を伝えてください。