この文書はRFC 5220の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
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
マルチプレフィックスの環境でのデフォルトアドレス選択の問題の宣言：
ＲＦＣ３４８４のデフォルト規則の運用上の問題
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.
単一の物理的なリンクで、複数のプレフィックスを割り当てることができま
す。その環境で、終端ホストは、複数のＩＰアドレスを持ち、選択的にそれ
らを使用しなければならないかもしれません。RFC 3484はデフォルトソース
と宛先アドレス選択の規則を定義しており、さまざまなＯＳで実装されます。
しかし、それはいくつかの理由で運用上使用が難しいです。複数のプレフィッ
クスが単一の物理的なリンクに割り当てられるいくつかの環境で、デフォル
トアドレス選択規則を使用しているホストは通信における問題に遭遇するで
しょう。この文書は終端ホストが複数のプレフィックスの環境で遭遇しうる
問題について説明します。
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. グローバルとＵＬＡの混在使用
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. ＩＰｖ４とＩＰｖ６の優先順位
2.2.2. ULA and IPv4 Dual-Stack Environment
2.2.2. ＵＬＡとＩＰｖ４二重スタック環境
2.2.3. ULA or Global Prioritization
2.2.3. ＵＬＡとグローバルの優先順位
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.
ＩＰｖ６では、単一の物理リンクに、複数のプレフィックスを割り当てるこ
とができます。このような場合、終端ホストはそのリンクのインターフェー
スに複数のＩＰアドレスを割り当てるかもしれません。ＩＰｖ４−ＩＰｖ６
二重スタック環境や、一意ローカルアドレス(ULA)[RFC4193]とグローバルルー
チングネットワークの両方につなげられたサイトでは、終端ホストは複数の
ＩＰアドレスを通常持っています。これらは私たちが本書で焦点を合わせる
ネットワークにの例です。このような環境で、終端ホストはいくつかの通信
問題に遭遇するかもしれません。
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]はデフォルトソースと宛先アドレス選択アルゴリズムを
定義し、さまざまなＯＳで実装されています。しかし、これは自動構成手段
の不足などのいくつかの理由に運用上の使用が難しいです。デフォルトアド
レス選択規則を使用しているホストが通信問題に遭遇するいくつかの問題の
多い事例があります。
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
図１
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".
一般に、次のホップの決定とアドレス選択の相互作用が全くありません。
この例で、ホストが新しい接続を始めて、ルータ１を通してパケットを送る
とき、ホストが必ず、ソースアドレスとしてルータ１から与えられたアドレ
ス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.
本件は次のホップの選択に依存し、ホストのアドレス選択の振舞いだけ
を制御するのでは全体の問題を解決しません。１つの可能な解決策は、
このような場合にルータ１とルータ２にソースアドレスベースのルーティ
ングを採用させる事です。他の解決策は、ルータ１とルータ２とホスト
で静的ルーティングを使用し、ホストで対応する静的アドレス選択方針
を使用する事です。
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
図２
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.
私たちは「顧客ネットワーク」と呼ぶ、比較的小さいサイトは２つの上流
ＩＳＰと接続していて、各ＩＳＰがネットワーク・アドレスブロック、
通常/48、を委任し、ホストが複数のＩＰｖ６アドレスを持つとします。
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.
送出パケットのソースアドレスが上流のＩＳＰから委任されているもので
ないときに、パケット侵入フィルタによってＩＳＰで廃棄される可能性が
あります。侵入フィルタリングは、サービス妨害(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.
この例で、もしルータがＩＳＰ２へのデフォルトルートを選択し、ホストが
インターネットのどこかのホスト(2001:db8:2000::1)へ送るパケットのソー
スアドレスに2001:db8:1000:1::100を選択するなら、パケットは侵入フィル
タリングのためにＩＳＰ２で廃棄されるかもしれません。
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.
１つの可能な解決策はこのような場合ルータがソースアドレスに基づく
ルーティングを採用する事です。他の解決法は、ルータでスタティック
ルーティングを使用し、ホストで対応する静的なアドレス選択方針を使
用する事です。
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.
グローバルに半開きのマルチホームサイトでの第２の典型的なソースアド
レス選択問題を、以下の図に示します。この事例で、マルチホームネット
ワークのホストＡは２つのＩＰｖ６アドレスを持ち、いつは上流ＩＳＰか
ら委任されたものです。ＩＳＰ２は閉じたネットワークで、インターネッ
トへの接続性を持っていないことに注意してください。
+--------+
| 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.
ここで２つの物理ネットワークは接続性を必要としていません。ルータか
らＩＳＰ２までの接続はＩＳＰ１とインターネットの上の論理的なリンク
であるかもしれません。
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.
ホストＡがＩＳＰ２のホストＢに接続を始めるとき、送るパケットのソー
スアドレスは、RFC 3484の規則８(最長一致プレフィックス)のために、
ＩＳＰ２から委任されたもの(つまり、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.
ホストＣは、インターネットのどこかにあり、ＩＰｖ６アドレス
2001:db8:a000::1を持っています。ホストＡがホストＣへパケットを送る
とき、最長一致アルゴリズムはソースアドレスに2001:db8:8000:1::100を
選びます。この場合、パケットは、ＩＳＰ１に向かい、ＩＳＰ１の侵入フィ
ルタによってフィルタされるかもしれません。パケットがＩＳＰ１でフィ
ルタされなくても、ホストＣからの応答パケットは宛先が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の枠組みでこの問題を解決できます。例えば、ホストＡの
RFC 3484方針テーブルにいくつかのアドレス選択方針を設定すると、
この問題を解決できます。
2.1.4. Combined Use of Global and ULA
2.1.4. グローバルとＵＬＡの混在使用
============
| 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]で説明されるように、いくつかのシナリオでＵＬＡの使
用は有益かもしれません。ＵＬＡが内部通信に使用されるなら、ＵＬＡを含
むパケットは、ルータでフィルタされる必要があります。
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.
現在のＵＬＡとグローバルユニキャストアドレスの違いのために、本件は
アドレス選択問題を生じさせません。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.
しかしながら、将来、最長一致規則が正しいアドレスを選べない可能性が
あります。最初のビットが１であるグローバルユニキャストアドレスの割
当が始まるときがその瞬間です。RFC 4291 [RFC4291]によると、最初のビッ
トが１であるものを含め、ＩＰｖ６のほとんどすべてのアドレス空間がグ
ローバルユニキャストアドレスとして割り当てられます。
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.
例えば、あて先ホストがＩＰｖ６アドレス8000::1を持ち、送信元ホスト
が2001:db8:a:100::100とfd01:2:3:100::100を持つとき、
2001:db8:a:100::100との最長一致ビット数は０で、fd01:2:3:100::100
との最長一致ビット数は１なので、ソースアドレスは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を変更し、ＵＬＡの
範囲をグローバル範囲より狭く定義することです。
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.
しかしながら、古いプレフィックスを無効にするのは長くかかります。古い
プレフィックスがホストから除かれない限り、古いプレフィックスのルーチ
ングを止めることができません。これはＩＳＰネットワーク管理者の難しい
問題かもしれません。
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.
この事例はサイトローカルとグローバルユニキャストの優先順位づけに関
する例です。サイト境界を超えてマルチキャストパケットを送るとき、マ
ルチキャストパケットのソースアドレスはグローバルにルーチンぐ可能な
アドレスであるべきです。しかしながら、送信ホストにＵＬＡとグローバ
ルユニキャストアドレスの両方があるなら、最長一致アルゴリズムは
ＵＬＡを選択します。
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.
一時アドレスをオンオフできるなら、それはより良いでしょう。また、サー
ビス(送付先アドレス)毎に使用するかどうかを切り換えるできるなら、それ
もより良いでしょう。同じ状況はモバイルＩＰｖ６[RFC3775]ネットワークで
ＨＡ(ホームアドレス)とＣｏＡ（気付けアドレス）を使用するときにも生じ
ます。
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の６章(「今後の活動」)は、よりよい精度でより良いアドレス選択
メカニズムを達成するために、ＡＰＩ拡張が必要かもしれない事を議論しす。
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]で定義されたソースアドレス
選択のＩＰｖ６ソケットＡＰＩを使い、好ましいアドレスを選択する事
です、
2.2. Destination Address Selection
2.2. 宛先アドレス選択
2.2.1. IPv4 or IPv6 Prioritization
2.2.1. ＩＰｖ４とＩＰｖ６の優先順位
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.
デフォルト方針テーブルはＩＰｖ４アドレスより高い優先権をＩＰｖ６アド
レスに与えます。しかしながら、ネットワーク管理者が終端ホストのアドレ
ス選択方針を制御したがる多くの事例で、それは逆です。
+---------+
| 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
図６
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.
上図では、サイトがネイティブのＩＰｖ４とトンネルのＩＰｖ６接続を持っ
ています。したがって、管理者はトンネルネットワークの品質がネイティブ
より悪いように思えるのでＩＰｖ６を使用するよりＩＰｖ４を使用するのに
高い優先度を設定したがっているかもしれません。
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. ＵＬＡとＩＰｖ４二重スタック環境
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.
これは、ＩＰｖ４とＩＰｖ６の優先順位の特別な形式です。企業には、
ＩＰｖ４インターネットの接続性を持っていますが、ＩＰｖ６インターネッ
トの接続性はまだなくて、企業がサイトローカルのＩＰｖ６接続を提供し
たがっているとき、ＵＬＡはサイトローカルのＩＰｖ６接続の最も良い選
択です。それぞれの従業員のホストには、ＩＰｖ４グローバルとプライベー
トととＵＬＡの全てがあるでしょう。このホストがＤＮＳのAとAAAAレコー
ドの両方を登録したホストＢに接続しようとするとき、ホストは宛先アド
レスに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
図７
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フレームワークでこの問題を解決できます。例えば、ホスト
ＡHのRFC 3484方針テーブルにいくつかのアドレス選択方針を設定す
ると、この問題を解決できます。
2.2.3. ULA or Global Prioritization
2.2.3. ＵＬＡとグローバルの優先順位
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.
クライアントのソースアドレスでサービスを差別化するのは非常に一般的
です。ＩＰアドレスベースの認証はこの典型的な例です。別の典型的な例
は、一般用のページと従業員か関係者のための内部のページがあるウェブ
サービスです。さらに別の例はＤＮＳゾーンの分割です。
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.
しかしながら、ＵＬＡとＩＰｖ６グローバルアドレスはどちらもグローバ
ル範囲でRFC 3484のデフォルトの解釈はどのアドレスを優先するべきかを
指定しません。この点で、アドレスベースのサービス分離のＩＰｖ６での
実装は少し困難になります。
+--------+
| 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
図８
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フレームワークでこの問題を解決できます。例えば、ホスト
Ａの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.
私たちは宛先かソースアドレス選択に関連する問題を提示しました。これら
の問題は終端ホストが複数のＩＰアドレスを持つ状況が原因です。この状況
で、すべての終終端ホストが適切な宛先とソースアドレスを選ばなければな
りません。ルータだけはこの選択を達成できません。
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.
もし中間ルータがポリシルーティング(例えば、ソースアドレスベースのルー
ティング)を実行するとき、不適当なアドレス選択は予期しないルーティン
グを引き起こします。例えば、ホストＡがデフォルトアドレス選択方針を使
用して、不適当なアドレスを選ぶとき2.1.3章で説明されたネットワークで
は、パケットはインターネットを通るＶＰＮで送られます。この問題はパケッ
ト盗聴やセッションハイジャックを導くことができます。しかしながら、攻
撃者からノードへの正しい経路にパケットを送り返すのが簡単でないので、
これらの２つのリスクは重大ではありません。
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章のような場
合、攻撃者がマルチキャストパケットを送るためにホストを作ることがで
きてて、ホストがデフォルトアドレス選択アルゴリズムを実行するなら、
攻撃者はホストのＵＬＡを決定できるかもしれません。
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).
著作権（Ｃ）ＩＥＴＦ信託（２００８）。
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.
この文書はＢＣＰ７８に含まれる権利と許可と制限の適用を受け、そして
この中に明らかにされる以外は著者がすべての権利を維持します。
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.
この文書とここに含まれる情報はあるがままに供給されます、貢献者と貢献
者が代表するか貢献者を後援する組織（もしあれば）とインターネット学会
とＩＥＴＦ信託とインターネット技術標準化タスクフォースは、明確にも暗
黙にも、この情報の使用が権利の侵害しないことや商業利用や特別の目的へ
の利用に適当である事の保障を含め、全ての保証を拒否します。
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.
この文書に記述された実装や技術に関して主張される知的財産権や他の権利の
正当性や範囲について、この様な権利の元でライセンスが利用可能か利用不
可能かの範囲について、ＩＥＴＦは何の立場もとりません；この様な権利を
認識する独立の調査をしたとは述べません。ＲＦＣ文書の権利に関する手続
きの情報はＢＣＰ７８とＢＣＰ７９を見てください。
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.
ＩＥＴＦ事務局に公開されたＩＰＲの写しと、利用可能な許可証と、仕様書
の実装者や利用者によってされた一般的な許可書や許可を得るためにされた
試みの結果は、http://www.ietf.org/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-ipr@ietf.orgのＩＥＴＦに情報を伝えてください。