この文書はRFC 5221の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
Network Working Group A. Matsumoto
Request for Comments: 5221 T. Fujisaki
Category: Informational NTT
R. Hiromi
Intec NetCore
K. Kanayama
INTEC Systems
July 2008
Requirements for Address Selection Mechanisms
アドレス選択メカニズムの必要条件
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
要約
There are some problematic cases when using the default address
selection mechanism that RFC 3484 defines. This document describes
additional requirements that operate with RFC 3484 to solve the
problems.
RFC 3484が定義するデフォルトアドレス選択メカニズムを使用するとき、
いくつかの問題の多い場合があります。この文書は問題を解決するために
RFC 3484と共に作動する追加要件について説明します。
Table of Contents
目次
1. Introduction
1. はじめに
2. Requirements of Address Selection
2. アドレス選択の要件
2.1. Effectiveness
2.1. 有効性
2.2. Timing
2.2. タイミング
2.3. Dynamic Behavior Update
2.3. 動的挙動更新
2.4. Node-Specific Behavior
2.4. ノード個別行動
2.5. Application-Specific Behavior
2.5. アプリケーション固有行動
2.6. Multiple Interface
2.6. 複数のインタフェース
2.7. Central Control
2.7. 集中管理
2.8. Next-Hop Selection
2.8. 次のホップ選択
2.9. Compatibility with RFC 3493
2.9. RFC 3493との互換性
2.10. Compatibility and Interoperability with RFC 3484
2.10. RFC 3484との互換性と相互運用性
2.11. Security
2.11. セキュリティ
3. Security Considerations
3. セキュリティの考察
3.1. List of Threats Introduced by New Address-Selection Mechanism
3.1. 新しいアドレス選択メカニズムによって導入される脅威のリスト
3.2. List of Recommendations in Which Security Mechanism Should Be Applied
3.2. セキュリティ対策が適用されるべき推薦のリスト
4. Normative References
4. 引用規格
1. Introduction
1. はじめに
Today, the RFC 3484 [RFC3484] mechanism is widely implemented in
major OSs. However, in many sites, the default address-selection
rules are not appropriate, and cause a communication failure. The
problem statement (PS) document [RFC5220] lists problematic cases
that resulted from incorrect address selection.
今日、RFC 3484 [RFC3484]メカニズムが主要なＯＳで広く実装されています。
しかしながら、多くのサイトでデフォルトアドレス選択規則は適切ではなく、
通信障害を引き起こします。問題宣言(PS)文書の[RFC5220]は不正確なア
ドレス選択から生じた問題の多い事例を記載します。
Though RFC 3484 made the address-selection behavior of a host
configurable, typical users cannot make use of that because of the
complexity of the mechanism and lack of knowledge about their network
topologies. Therefore, an address-selection autoconfiguration
mechanism is necessary, especially for unmanaged hosts of typical
users.
RFC 3484はホストのアドレス選択の振舞いを設定可能にしましたが、典型的
なユーザはメカニズムの複雑さと彼らのネットワークトポロジー知識不足から
これを利用できません。したがって、アドレス選択自動構成メカニズムが特に
典型的なユーザの非管理ホストで必要です。
This document contains requirements for address-selection mechanisms
that enable hosts to perform appropriate address selection
automatically.
この文書はホストが自動的に適切なアドレス選択を実行するのを可能にする
アドレス選択メカニズムのための要件を含んでいます。
2. Requirements of Address Selection
2. アドレス選択の要件
Address-selection mechanisms have to fulfill the following eleven
requirements.
アドレス選択メカニズムは以下の11の要件を実現させなければなりません。
2.1. Effectiveness
2.1. 有効性
The mechanism can modify RFC 3484 default address-selection behavior
at nodes. As documented in the PS [RFC5220], the default rules
defined in RFC 3484 do not work properly in some environments.
Therefore, the mechanism has to be able to modify the address-
selection behavior of a host and to solve the problematic cases
described in the PS document.
メカニズムはRFC 3484のノードのデフォルトアドレス選択の振舞いを変更
できます。PS[RFC5220]に記録されるように、RFC 3484で定義された省略時
の解釈はいくつかの環境で適切に働いていません。したがって、メカニズム
は、ホストのアドレス選択の振舞いを変更し、PS文書で説明された問題の多
い事例を解決できなければなりません。
2.2. Timing
2.2. タイミング
Nodes can perform appropriate address selection when they select
addresses.
アドレスを選択するとき、ノードは適切なアドレス選択を実行できます。
If nodes need to have address-selection information to perform
appropriate address selection, then the mechanism has to provide a
function for nodes to obtain the necessary information beforehand.
ノードが適切なアドレス選択を実行するためにアドレス選択情報を必要と
するなら、ノードがあらかじめ必要事項を得られるように、メカニズムは
機能を提供しなければなりません。
The mechanism should not degrade usability. The mechanism should not
enforce long address-selection processing time upon users.
Therefore, forcing every consumer user to manipulate the address-
selection policy table is usually not an acceptable solution. So, in
this case, some kind of autoconfiguration mechanism is desirable.
メカニズムはユーザビリティを下がらせないべきです。メカニズムはアド
レス選択処理にユーザから見て長い時間をかけるべきではありません。
したがって、通常、すべての末端ユーザにアドレス選択方針テーブルを操作
させるのは、許容できる解決策ではありません。それで、この場合、ある種
の自動構成メカニズムが望ましいです。
2.3. Dynamic Behavior Update
2.3. 動的挙動更新
The address-selection behavior of nodes can be dynamically updated.
When the network structure changes and the address-selection behavior
has to be changed accordingly, a network administrator can modify the
address-selection behavior of nodes.
動的にノードのアドレス選択の動きを更新できます。ネットワーク構造が変化
し、それに従ってアドレス選択の振舞いを変えなければならないとき、ネット
ワーク管理者はノードのアドレス選択の動きを変更できます。
2.4. Node-Specific Behavior
2.4. ノード個別行動
The mechanism can support node-specific address-selection behavior.
Even when multiple nodes are on the same subnet, the mechanism should
be able to provide a method for the network administrator to make
nodes behave differently. For example, each node may have a
different set of assigned prefixes. In such a case, the appropriate
address-selection behavior may be different.
メカニズムは、ノード固有のアドレス選択の振舞いをサポートすることがで
きます。複数のノードが同じサブネットにあるときでも、メカニズムはネッ
トワーク管理者がノード毎に異なる振る舞をさせる手段を提供するはずです。
例えば、各ノードには、割り当てられたプレフィックスの集合が異なるかも
しれません。このような場合、適切なアドレス選択の振舞いは異なるかもし
れません。
2.5. Application-Specific Behavior
2.5. アプリケーション固有行動
The mechanism can support application-specific address-selection
behavior or combined use with an application-specific address-
selection mechanism such as address-selection APIs.
メカニズムはアプリケーション固有のアドレス選択メカニズムか、アドレス
選択ＡＰＩのようにアプリケーション特有のアドレス選択の結合した使用を
サポートすることができます。
2.6. Multiple Interface
2.6. 複数のインタフェース
The mechanism can support those nodes equipped with multiple
interfaces. The mechanism has to assume that nodes have multiple
interfaces and makes address selection of those nodes work
appropriately.
メカニズムは複数のインタフェースを備えたノードをサポートできます。
メカニズムはノードには複数のインタフェースがあると仮定しなければ
ならず、それらのノードのアドレス選択は適切に働きます。
2.7. Central Control
2.7. 集中管理
The address-selection behavior of nodes can be centrally controlled.
A site administrator or a service provider could determine or could
have an effect on the address-selection behavior at their users'
hosts.
集中的にノードのアドレス選択の動きを制御できます。サイトの管理者か
サービスプロバイダーが、彼らのユーザのホストのアドレス選択の振舞い
を決定するまたはに影響を与えることができます。
2.8. Next-Hop Selection
2.8. 次のホップ選択
The mechanism can control next-hop-selection behavior at hosts or
cooperate with other routing mechanisms, such as routing protocols
and RFC 4191 [RFC4191]. If the address-selection mechanism is used
with a routing mechanism, the two mechanisms have to be able to work
synchronously.
メカニズムは、ホストの次のホップの選択の振舞いを制御するか、または、
ルーティング・プロトコルやRFC 4191 [RFC4191]の様な、他のルーティング
メカニズムに協調できます。アドレス選択メカニズムがルーティングメカニ
ズムと共に使用されるなら、２つのメカニズムが同時働くことができなけれ
ばなりません。
2.9. Compatibility with RFC 3493
2.9. RFC 3493との互換性
The mechanism can allow an application that uses the basic socket
interface defined in RFC 3493 [RFC3493] to work correctly. That is,
with the basic socket interface the application can select
appropriate source and destination addresses and can communicate with
the destination host. This requirement does not necessarily mean
that OS protocol stack and socket libraries should not be changed.
メカニズムはRFC 3493 [RFC3493]で定義された基本的なソケットインタフェー
スを使用するアプリケーションで正しく動作できます。すなわち、基本的な
ソケットインタフェースで、アプリケーションは、適切なソースと宛先アド
レスを選ぶことができて、宛先ホストと通信できます。この要件は、ＯＳプロ
トコル・スタックとソケットライブラリがの変更が必要という意味ではあり
ません。
2.10. Compatibility and Interoperability with RFC 3484
2.10. RFC 3484との互換性と相互運用性
The mechanism is compatible with RFC 3484. Now that RFC 3484 is
widely implemented, it is preferable that a new address selection
mechanism does not conflict with the address selection mechanisms
defined in RFC 3484.
メカニズムはRFC 3484と互換性があります。RFC 3484が広く実装される
ので、新しいアドレス選択メカニズムがRFC 3484で定義されるアドレス
選択メカニズムと競合しないのは、望ましいです。
If the solution mechanism changes or replaces the address-selection
mechanism defined in RFC 3484, interoperability has to be retained.
That is, a host with the new solution mechanism and a host with the
mechanism of RFC 3484 have to be interoperable.
問題解決のメカニズムがRFC 3484で定義されたアドレス選択メカニズムを
変えるかまたは置き換えるなら、相互運用性が保有されなければなりません。
すなわち、新しいメカニズムをもつホストとRFC 3484メカニズムをもる
ホストは同時利用できなければなりません。
2.11. Security
2.11. セキュリティ
The mechanism works without any security problems. Possible security
threats are described in the Security Considerations section of this
document.
メカニズムは少しもセキュリティ上の問題なしで動作します。可能性のある
脅威はこの文書のセキュリティの考察部で説明されます。
3. Security Considerations
3. セキュリティの考察
3.1. List of Threats Introduced by New Address-Selection Mechanism
3.1. 新しいアドレス選択メカニズムによって導入される脅威のリスト
There will be some security incidents when combining the requirements
described in Section 2 into a protocol. In particular, there are 3
types of threats: leakage, hijacking, and denial of service.
２章のプロトコルに説明された要件を結合するとき、いくつかのセキュリティ
インシデントがあるでしょう。特に、３つのタイプの脅威があります:漏洩、
ハイジャック、サービス妨害。
1. Leakage: Malicious nodes may tap to collect the network policy
information and leak it to unauthorized parties.
1. 漏洩:悪意があるノードはネットワーク方針情報を集めるために傍受を
行い、権限のないパーティーにそれを漏らすかもしれません。
2. Hijacking: Nodes may be hijacked by malicious injection of
illegitimate policy information. RFC 3484 defines both a source
and destination selection algorithm. An attacker able to inject
malicious policy information could redirect packets sent by a
victim node to an intentionally chosen server that would scan the
victim node activities to find vulnerable code. Once vulnerable
code is found, the attacker can take control of the victim node.
2. ハイジャック:ノードは違法な方針情報の悪意がある注入でハイジャック
されるかもしれません。RFC 3484はソースと宛先選択アルゴリズムの
両方を定義します。悪意がある方針情報を注入する能力のある攻撃者は、
犠牲者ノード活動をスキャンし、犠牲者ノードの脆弱なコードを見つ
けるために、故意に選ばれたサーバにパケットの送信先を直すことが
できます。脆弱なコードがいったん見つけられると、攻撃者は犠牲者
ノードを制御できます。
3. Denial of Service: This is an attack on the ability of nodes to
communicate in the absence of the address-selection policy. An
attacker could launch a flooding attack on the controller to
prevent it from delivering the address selection policy
information to nodes, thus preventing those nodes from
appropriately communicating.
3. サービス妨害:これはノードがアドレス選択方針がないときの交信能力に
対する攻撃です。 攻撃者はアドレス選択方針情報をノードに提供するの
を防ぐためにコントローラ上で洪水攻撃に着手できます、その結果、
それらのノードが適切に交信するのを防ぎます。
3.2. List of Recommendations in Which Security Mechanism Should Be Applied
3.2. セキュリティ対策が適用されるべき推薦のリスト
The address selection mechanism should be afforded security services
listed below. It is preferable that these security services are
afforded via use of existing protocols (e.g., IPsec).
以下に記載されたセキュリティー・サービスをアドレス選択メカニズムに
提供するべきです。 既存のプロトコル(例えば、ＩＰｓｅｃ)の使用でこれ
らのセキュリティー・サービスを提供するのは望ましいです。
1. Integrity of the network policy information itself and the
messages exchanged in the protocol. This is a countermeasure
against leakage, hijacking, and denial of service.
1. ネットワーク方針情報自体とプロトコルで交換されたメッセージの
完全性。これは漏洩、ハイジャック、サービス妨害に対する対策です。
2. Authentication and authorization of parties involved in the
protocol. This is a countermeasure against Leakage and
Hijacking.
2. プロトコルにかかわる当事者の認証と承認。これは漏洩とハイジャック
に対する対策です。
4. Normative References
4. 引用規格
[RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W.
Stevens, "Basic Socket Interface Extensions for IPv6", RFC
3493, February 2003.
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and
More-Specific Routes", RFC 4191, November 2005.
[RFC5220] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama,
"Problem Statement for Default Address Selection in
Multi-Prefix Environments: Operational Issues of RFC 3484
Default Rules", RFC 5220, July 2008.
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のＩＥＴＦに情報を伝えてください。