[要約] RFC 5221は、アドレス選択メカニズムの要件に関するものであり、IPv6ネットワークでのアドレス選択の問題を解決するためのガイドラインを提供しています。その目的は、ネットワーク上のホストが最適なアドレスを選択できるようにすることです。
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]メカニズムはメジャーOSSに広く実装されています。ただし、多くのサイトでは、デフォルトのアドレス選択ルールは適切ではなく、通信障害を引き起こします。問題ステートメント（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と互換性があります。RFC3484が広く実装されているため、新しいアドレス選択メカニズムが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. サービスの拒否：これは、アドレス選択ポリシーがない場合にノードが通信する能力に対する攻撃です。攻撃者は、コントローラーに対する洪水攻撃を開始して、アドレス選択ポリシー情報がノードに配信されないようにし、それらのノードが適切に通信できないようにすることができます。
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。、「インターネットプロトコルバージョン6（IPv6）のデフォルトアドレス選択」、RFC 3484、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] Gilligan、R.、Thomson、S.、Bound、J.、McCann、J。、およびW. Stevens、「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. Thaler、「デフォルトのルーターの設定とより固有のルート」、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
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
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
Ruri Hiromi Intec Netcore、Inc。Shinsuna 1-3-3 Koto-ku、東京136-0075日本
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
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）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.
この文書は、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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、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ドキュメントの権利に関する手順に関する情報は、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.
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への情報をお問い合わせください。