この文書は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に情報を伝えてください。

Japanese translation by Ishida So