RFC5221 日本語訳
5221 Requirements for Address Selection Mechanisms. A. Matsumoto, T.Fujisaki, R. Hiromi, K. Kanayama. July 2008. (Format: TXT=13732 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group A. Matsumoto
Request for Comments: 5221 T. Fujisaki
Category: Informational NTT
R. Hiromi
Intec NetCore
K. Kanayama
INTEC Systems
July 2008
コメントを求めるワーキンググループA.松本の要求をネットワークでつないでください: 5221年のT.藤崎カテゴリ: 情報のNTTのNetCore K.KanayamaインテックシステムR.広見インテック2008年7月
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.
RFC3484が定義するデフォルトアドレス選択メカニズムを使用するとき、いくつかの問題の多いケースがあります。 このドキュメントは問題を解決するためにRFC3484と共に作動する追加要件について説明します。
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
1. 序論…2 2. アドレス選択の要件…2 2.1. 有効性…2 2.2. タイミング…2 2.3. 動的挙動アップデート…3 2.4. ノード特有の振舞い…3 2.5. アプリケーション特有の振舞い…3 2.6. 複数のインタフェース…3 2.7. 主要なコントロール…3 2.8. 次のホップ選択…3 2.9. RFC3493との互換性…4 2.10. RFC3484がある互換性と相互運用性…4 2.11. セキュリティ…4 3. セキュリティ問題…4 3.1. 新しいアドレス選択メカニズムによって導入された脅威のリスト…4 3.2. 推薦のリストはどのセキュリティー対策で適用されるべきであるか…5 4. 標準の参照…5
Matsumoto, et al. Informational [Page 1] RFC 5221 Address-Selection Reqs July 2008
松本、他 [1ページ]情報のRFC5221アドレス選択Reqs2008年7月
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.
今日、RFC3484[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.
RFC3484はホストのアドレス選択の振舞いを構成可能にしましたが、典型的なユーザはメカニズムと知識不足の複雑さのために彼らのネットワークtopologiesの周りでそれを利用できません。 したがって、アドレス選択自動構成メカニズムが特に典型的なユーザの非管理されたホストに必要です。
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.
メカニズムはノードでRFC3484デフォルトアドレス選択の振舞いを変更できます。 PS[RFC5220]に記録されるように、RFC3484で定義された省略時の解釈はいくつかの環境で適切に働いていません。 したがって、メカニズムは、ホストのアドレス選択の振舞いを変更して、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.
メカニズムはユーザビリティを下がらせるはずがありません。 メカニズムはユーザで長いアドレス選択処理時間を実施するはずがありません。 したがって、通常、すべての消費者ユーザにアドレス選択方針テーブルを操作させるのは、許容できるソリューションではありません。 それで、この場合、ある種の自動構成メカニズムが望ましいです。
Matsumoto, et al. Informational [Page 2] RFC 5221 Address-Selection Reqs July 2008
松本、他 [2ページ]情報のRFC5221アドレス選択Reqs2008年7月
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.
メカニズムはアドレス選択APIなどのようにアプリケーション特有のアドレス選択メカニズムによる振舞いか結合した使用をアプリケーション特有のアドレス選択にサポートすることができます。
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.
メカニズムは、ホストで次のホップ選択の振舞いを制御するか、または他のルーティングメカニズムに協力できます、ルーティング・プロトコルやRFC4191[RFC4191]のように。 アドレス選択メカニズムがルーティングメカニズムと共に使用されるなら、2つのメカニズムが同時働くことができなければなりません。
Matsumoto, et al. Informational [Page 3] RFC 5221 Address-Selection Reqs July 2008
松本、他 [3ページ]情報のRFC5221アドレス選択Reqs2008年7月
2.9. Compatibility with RFC 3493
2.9. RFC3493との互換性
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.
メカニズムで、RFC3493[RFC3493]で定義された基本的なソケットインタフェースを使用するアプリケーションは正しく動作できます。 すなわち、基本的なソケットインタフェースで、アプリケーションは、適切なソースと送付先アドレスを選ぶことができて、あて先ホストとコミュニケートできます。 この要件は、必ずOSプロトコル・スタックとソケットライブラリが変えられるべきでないことを意味するというわけではありません。
2.10. Compatibility and Interoperability with RFC 3484
2.10. RFC3484がある互換性と相互運用性
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.
メカニズムはRFC3484と互換性があります。 RFC3484が広く実装されるので、新しいアドレス選択メカニズムがRFC3484で定義されるアドレス選択メカニズムと闘争しないのは、望ましいです。
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.
ソリューションメカニズムがRFC3484で定義されたアドレス選択メカニズムを変えるか、または置き換えるなら、相互運用性は保有されなければなりません。 すなわち、新しいソリューションメカニズムをもっているホストとRFC3484のメカニズムをもっているホストは共同利用できなければなりません。
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.
メカニズムは少しも警備上の問題なしで動作します。可能な軍事的脅威はこのドキュメントのSecurity Considerations部で説明されます。
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.
セクション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. ハイジャック: ノードは違法な方針情報の悪意がある注射でハイジャックされるかもしれません。 RFC3484はソースと目的地選択アルゴリズムの両方を定義します。 悪意がある方針情報を注入するのにおいて有能な攻撃者は犠牲者ノードによって被害を受け易いコードを見つけるために犠牲者ノード活動をスキャンする故意に選ばれたサーバに送られたパケットを向け直すことができました。 被害を受け易いコードがいったん見つけられると、攻撃者は犠牲者ノードを制御できます。
Matsumoto, et al. Informational [Page 4] RFC 5221 Address-Selection Reqs July 2008
松本、他 [4ページ]情報のRFC5221アドレス選択Reqs2008年7月
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. プロトコルにかかわるパーティーの認証と承認。 これはLeakageとHijackingに対する対策です。
4. Normative References
4. 引用規格
[RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3484]Draves、R.、「インターネットプロトコルバージョン6(IPv6)のためのデフォルトAddress Selection」、RFC3484、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"、RFC3493、2003年2月のための基本的なソケットインタフェース拡大。」
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and
More-Specific Routes", RFC 4191, November 2005.
[RFC4191]Draves、研究開発ターレル、「デフォルトルータ好みの、そして、より特定のルート」、RFC4191、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.Kanayama、「デフォルトのための問題声明はマルチ接頭語環境における選択を扱います」。 「操作上の問題、RFC3484省略時の解釈、」、RFC5220、7月2008日
Matsumoto, et al. Informational [Page 5] RFC 5221 Address-Selection Reqs July 2008
松本、他 [5ページ]情報のRFC5221アドレス選択Reqs2008年7月
Authors' Addresses
作者のアドレス
Arifumi Matsumoto NTT PF Lab Midori-Cho 3-9-11 Musashino-shi, Tokyo 180-8585 Japan
pfの研究室の美土里町の3 9-11テロのArifumi松本NTT武蔵野市、日本東京180-8585
Phone: +81 422 59 3334 EMail: arifumi@nttv6.net
以下に電話をしてください。 +81 422 59 3334はメールされます: arifumi@nttv6.net
Tomohiro Fujisaki NTT PF Lab Midori-Cho 3-9-11 Musashino-shi, Tokyo 180-8585 Japan
pfの研究室の美土里町の3 9-11テロの智宏藤崎NTT武蔵野市、日本東京180-8585
Phone: +81 422 59 7351 EMail: fujisaki@nttv6.net
以下に電話をしてください。 +81 422 59 7351はメールされます: fujisaki@nttv6.net
Ruri Hiromi Intec Netcore, Inc. Shinsuna 1-3-3 Koto-ku, Tokyo 136-0075 Japan
Ruri広見インテックNetcore Inc.Shinsuna1-3-3江東区、日本東京136-0075
Phone: +81 3 5665 5069 EMail: hiromi@inetcore.com
以下に電話をしてください。 +81 3 5665 5069はメールされます: hiromi@inetcore.com
Ken-ichi Kanayama INTEC Systems Institute, Inc. Shimoshin-machi 5-33 Toyama-shi, Toyama 930-0804 Japan
健一KanayamaインテックSystemsはInc.Shimoshin-machi5-33富山市、日本富山930-0804を設けます。
Phone: +81 76 444 8088 EMail: kanayama_kenichi@intec-si.co.jp
以下に電話をしてください。 +81 76 444 8088はメールされます: kanayama_kenichi@intec-si.co.jp
Matsumoto, et al. Informational [Page 6] RFC 5221 Address-Selection Reqs July 2008
松本、他 [6ページ]情報のRFC5221アドレス選択Reqs2008年7月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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に情報を扱ってください。
Matsumoto, et al. Informational [Page 7]
松本、他 情報[7ページ]
一覧
スポンサーリンク
