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 ....................................................2
2. Requirements of Address Selection ...............................2
2.1. Effectiveness ..............................................2
2.2. Timing .....................................................2
2.3. Dynamic Behavior Update ....................................3
2.4. Node-Specific Behavior .....................................3
2.5. Application-Specific Behavior ..............................3
2.6. Multiple Interface .........................................3
2.7. Central Control ............................................3
2.8. Next-Hop Selection .........................................3
2.9. Compatibility with RFC 3493 ................................4
2.10. Compatibility and Interoperability with RFC 3484 ..........4
2.11. Security ..................................................4
3. Security Considerations .........................................4
3.1. List of Threats Introduced by New Address-Selection
Mechanism ..................................................4
3.2. List of Recommendations in Which Security Mechanism
Should Be Applied ..........................................5
4. Normative References ............................................5
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]メカニズムは広く主要のOSに実装されています。しかし、多くのサイトでは、デフォルトのアドレス選択ルールは適切でないと、通信障害の原因となります。問題の記述（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.
このドキュメントは、自動的に適切なアドレス選択を実行するホストを可能にするアドレス選択メカニズムのための要件が含まれています。
Address-selection mechanisms have to fulfill the following eleven requirements.
アドレス選択メカニズムは、次の11の要件を満たさなければなりません。
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の文書に記載問題のケースを解決しなければなりません。
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.
メカニズムは、ユーザビリティを低下させてはなりません。メカニズムは、ユーザーにより、長いアドレス選択処理時間を強制してはなりません。したがって、アドレス選択ポリシーテーブルを操作するために、すべての消費者のユーザを強制的に通常的に許容可能な解決策ではありません。したがって、この場合には、自動設定メカニズムのいくつかの種類が望ましいです。
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.
ノードのアドレス選択動作を動的に更新することができます。ネットワーク構造の変更とアドレス選択動作を適宜変更する必要がある場合、ネットワーク管理者は、ノードのアドレス選択動作を変更することができます。
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.
メカニズムは、ノード固有のアドレス選択動作をサポートすることができます。複数のノードが同じサブネット上にある場合でも、メカニズムは、ノードは異なる動作を行うために、ネットワーク管理者のための方法を提供することができるはずです。例えば、各ノードは、割り当てられたプレフィックスの異なるセットを有することができます。このような場合には、適切なアドレス選択挙動が異なっていてもよいです。
The mechanism can support application-specific address-selection behavior or combined use with an application-specific address-selection mechanism such as address-selection APIs.
機構は、アドレス選択用のAPIとして、アプリケーション固有のアドレス選択機構と、アプリケーション固有のアドレス選択動作または併用をサポートすることができます。
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.
機構は、複数のインタフェースを備え、それらのノードをサポートすることができます。機構は、ノードが複数のインタフェースを有し、これらのノードのアドレス選択が適切に動作することができると仮定しなければなりません。
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.
ノードのアドレス選択動作を集中制御することができます。サイト管理者やサービスプロバイダが決定することができるか、そのユーザーのホストのアドレス選択行動に影響を与える可能性があります。
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つのメカニズムが同期して動作することができなければなりません。
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]で定義された基本的なソケットインタフェースを使用するアプリケーションが正しく動作することを可能にすることができます。つまり、アプリケーションが適切なソースと宛先アドレスを選択することができ、宛先ホストと通信することができる基本的なソケットインタフェースです。この要件は、必ずしもOS、プロトコルスタックとソケットライブラリを変更してはならないことを意味するものではありません。
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のメカニズムを持つホストは、相互運用可能でなければなりません。
The mechanism works without any security problems. Possible security threats are described in the Security Considerations section of this document.
メカニズムは、セキュリティ上の問題もなく動作します。可能性のあるセキュリティ上の脅威は、この文書のセキュリティについての考慮事項の項に記載されています。
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.
プロトコルに第2節で説明した要件を組み合わせたときに、いくつかのセキュリティインシデントがあります。漏れ、ハイジャック、およびサービス拒否：特に、脅威の3種類があります。
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).
アドレス選択メカニズムは、下記のセキュリティサービスを与えることがなければなりません。これらのセキュリティサービスは、既存のプロトコル（例えば、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.認証プロトコルに関わる当事者の承認。これは、漏れやハイジャック対策です。
[RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3484] Draves、R.、RFC 3484 "インターネットプロトコルバージョン6（IPv6）のデフォルトのアドレス選択"、2003年2月。
[RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. Stevens, "Basic Socket Interface Extensions for IPv6", RFC 3493, February 2003.
[RFC3493]ギリガン、R.、トムソン、S.、バウンド、J.、マッキャン、J.、およびW.スティーブンス、 "IPv6の基本的なソケットインタフェース拡張"、RFC 3493、2003年2月。
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and More-Specific Routes", RFC 4191, November 2005.
[RFC4191] Draves、R.とD.ターラー、 "デフォルトルータの設定と、より詳細なルート"、RFC 4191、2005年11月。
[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.
[RFC5220]松本、A.、藤崎、T.、ひろみ、R.、およびK.金山、「マルチプレフィックス環境でのデフォルトアドレス選択の問題文：RFC 3484のデフォルトのルールの運用上の問題」、RFC 5220、2008年7月。
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
電話：+81 422 59 3334 Eメール：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
電話：+81 422 59 7351 Eメール：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
電話：+81 3 5665 5069 Eメール：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
電話：+81 76 444 8088 Eメール：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.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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に情報を記述してください。