RFC4219 日本語訳
4219 Things Multihoming in IPv6 (MULTI6) Developers Should ThinkAbout. E. Lear. October 2005. (Format: TXT=25141 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group E. Lear Request for Comments: 4219 Cisco Systems Category: Informational October 2005
コメントを求めるワーキンググループE.リア要求をネットワークでつないでください: 4219年のシスコシステムズカテゴリ: 情報の2005年10月
Things Multihoming in IPv6 (MULTI6) Developers Should Think About
IPv6(MULTI6)開発者のマルチホーミングが考えるべきであるもの
Status of this Memo
この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.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
Abstract
要約
This document specifies a set of questions that authors should be prepared to answer as part of a solution to multihoming with IPv6. The questions do not assume that multihoming is the only problem of interest, nor do they demand a more general solution.
このドキュメントは作者がIPv6と共にマルチホーミングの解決の一部として答える用意ができているべきであるという1セットの疑問を指定します。 質問は、マルチホーミングが興味がある唯一の問題であると仮定しません、そして、彼らは、より一般的な解決策を要求しません。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Reading this Document ......................................3
2. On the Wire Behavior ............................................4
2.1. How will your solution solve the multihoming problem? ......4
2.2. At what layer is your solution applied, and how? ...........4
2.3. Why is the layer you chose the correct one? ................4
2.4. Does your solution address mobility? .......................4
2.5. Does your solution expand the size of an IP packet? ........4
2.6. Will your solution add additional latency? .................4
2.7. Can multihoming capabilities be negotiated
end-to-end during a ........................................4
2.8. Do you change the way fragmenting is handled? ..............5
2.9. Are there any layer 2 implications to your proposal? .......5
3. Identifiers and Locators ........................................5
3.1. Uniqueness .................................................5
3.2. Does your solution provide for a split between
identifiers and ............................................5
3.3. What is the lifetime of a binding from an
identifier to a locator? ...................................5
3.4. How is the binding updated? ................................5
3.5. How does a host know its identity? .........................5
3.6. Can a host have multiple identifiers? ......................5
1. 序論…3 1.1. このDocumentを読みます…3 2. ワイヤの振舞いに関して…4 2.1. あなたの解決策はどのようにマルチホーミング問題を解決するでしょうか? ......4 2.2. あなたの解決策はどんな層に適用されるか、そして、どのようにですか? ...........4 2.3. あなたが選んだ層はなぜ正しい方ですか? ................4 2.4. あなたの解決策は移動性を記述しますか? .......................4 2.5. あなたの解決策はIPパケットのサイズを広くしますか? ........4 2.6. あなたの解決策は追加潜在を加えるでしょうか? .................4 2.7. aの間、…………………………………マルチホーミング能力は、交渉された終わりから終わりであるかもしれませんか?4 2.8. あなたは断片化が扱われる方法を変えますか? ..............5 2.9. 何かあなたの提案への層2の含意がありますか? .......5 3. 識別子とロケータ…5 3.1. ユニークさ…5 3.2. そして、あなたの解決策が識別子の間の分裂に備える、…5 3.3. 識別子からロケータまでの結合の寿命は何ですか? ...................................5 3.4. どのように結合をアップデートしますか? ................................5 3.5. ホストはどのようにアイデンティティを知っていますか? .........................5 3.6. ホストは複数の識別子を持つことができますか? ......................5
Lear Informational [Page 1] RFC 4219 MULTI6 Solution Questionnaire October 2005
[1ページ]RFC4219MULTI6ソリューションアンケート2005年10月の情報のリア
3.7. If you have separate locators and identifiers, how
will they be ...............................................5
3.8. Does your solution create an alternate "DNS-like"
service? ...................................................5
3.9. Please describe authentication/authorization ...............6
3.10. Is your mechanism hierarchical? ...........................6
3.11. Middlebox interactions ....................................6
3.12. Are there any implications for scoped addressing? .........6
4. Routing System Interactions .....................................6
4.1. Does your solution change existing aggregation methods? ....6
4.2. Does the solution solve traffic engineering requirements? ..7
4.3. Does the solution offer ways for the site to manage
its traffic ................................................7
4.4. If you introduce any new name spaces, do they
require aggregation? .......................................7
4.5. Does your solution interact with Autonomous System
numbering? .................................................7
4.6. Are there any changes to ICMP error semantics? .............7
5. Name Service Interactions .......................................7
5.1. Please explain the relationship of your solution to DNS ....7
5.2. Please explain interactions with "2-faced" DNS .............7
5.3. Does your solution require centralized registration? .......8
5.4. Have you checked for DNS circular dependencies? ............8
5.5. What if a DNS server itself is multihomed? .................8
5.6. What additional load will be placed on DNS servers? ........8
5.7. Any upstream provider support required? ....................8
5.8. How do you debug connectivity? .............................8
6. Application Concerns and Backward Compatibility .................8
6.1. What application/API changes are needed? ...................8
6.2. Is this solution backward compatible with "old" IP
version 6? .................................................9
6.3. Is your solution backward compatible with IPv4? ............9
6.4. Can IPv4 devices take advantage of this solution? ..........9
6.5. What is the impact of your solution on different
types of sites? ............................................9
6.6. How will your solution interact with other middleboxes? ...10
6.7. Referrals .................................................10
6.8. Demonstrate use with a real life complex application ......10
7. Legal Concerns .................................................10
8. Security Considerations ........................................10
9. Acknowledgements ...............................................11
10. References ....................................................11
10.1. Normative References .....................................11
10.2. Informative References ...................................11
3.7. 別々のロケータと識別子がありましたら、それらはどのようにあるだろうか…5 3.8. あなたの解決策は交互の「DNSのような」サービスを作成しますか? ...................................................5 3.9. 認証/認可について説明してください…6 3.10. あなたのメカニズムは階層的ですか? ...........................6 3.11. Middlebox相互作用…6 3.12. 何か見られたアドレシングのための含意がありますか? .........6 4. ルート設定システム相互作用…6 4.1. あなたの解決策は既存の集合方法を変えますか? ....6 4.2. 解決策は交通工学要件を解決しますか? ..7 4.3. サイトが交通を管理する解決策申し出方法をします…7 4.4. あなたが何か新しい名前空間を導入するなら、彼らは集合を必要としますか? .......................................7 4.5. あなたの解決策はAutonomous System付番と対話しますか? .................................................7 4.6. ICMP誤り意味論へのいくつかの変化がありますか? .............7 5. サービスを相互作用と命名してください…7 5.1. DNSの解決策の関係について説明してください…7 5.2. 「2顔をした」DNSとの相互作用について説明してください…7 5.3. あなたの解決策は集結された登録を必要としますか? .......8 5.4. あなたはDNSの円形の依存がないかどうかチェックしましたか? ............8 5.5. DNSサーバ自体が「マルチ-家へ帰」ると、どうなるでしょうか? .................8 5.6. どんな追加負荷がDNSサーバに置かれるでしょうか? ........8 5.7. サポートが必要とした上流のプロバイダーがありますか? ....................8 5.8. あなたはどのように接続性をデバッグしますか? .............................8 6. アプリケーション関心と後方の互換性…8 6.1. どんなアプリケーション/API変化が必要ですか? ...................8 6.2. この解決策が後方にある、「古い」IPバージョン6と互換性がありますか? .................................................9 6.3. あなたの解決策が後方にある、IPv4と互換性がありますか? ............9 6.4. IPv4装置はこの解決策を利用できますか? ..........9 6.5. 異なったタイプのサイトへのあなたの解決策の影響は何ですか? ............................................9 6.6. あなたの解決策はどのように他のmiddleboxesと対話するでしょうか? ...10 6.7. 紹介…10 6.8. 現実の複雑なアプリケーションで使用を示してください…10 7. 法的な関心…10 8. セキュリティ問題…10 9. 承認…11 10. 参照…11 10.1. 標準の参照…11 10.2. 有益な参照…11
Lear Informational [Page 2] RFC 4219 MULTI6 Solution Questionnaire October 2005
[2ページ]RFC4219MULTI6ソリューションアンケート2005年10月の情報のリア
1. Introduction
1. 序論
At the time of this writing there are quite a number of proposed solutions to the problem of multihoming within IPv6, and related problems such as the locator/identifier split.
この書くこと時点で、IPv6の中にマルチホーミングの問題のかなりの数の提案された解決がありました、そして、ロケータ/識別子などの関連する問題は分かれました。
This document contains several sets of questions that attempt to focus these solutions on operational problems. This document does not suggest methods to solve the problem. Rather, we simply want to ensure that while solving a problem the medicine is not worse than the cure. We focus on practical operational problems that both single-homed and multihomed deployments may face.
このドキュメントは運転上の問題にこれらの解決策の焦点を合わせるのを試みる数セットの質問を含んでいます。このドキュメントは問題を解決する方法を示しません。 むしろ、単に薬が確実に問題を解いている間療法より悪くならないようにしたいと思います。 私たちは両方がシングル家へ帰って、「マルチ-家へ帰」っている展開に面するかもしれないという実用的な運転上の問題に焦点を合わせます。
It is the hope of the author that perhaps the authors of other proposed solutions will use this document to identify gaps in their solutions, and cooperate to close those gaps.
それは他の提案された解決策の作者が恐らく、彼らの解決策のギャップを特定するのにこのドキュメントを使用して、協力して、それらのギャップを閉じるという作者の望みです。
1.1. Reading this Document
1.1. このDocumentを読みます。
The questions are organized along the following lines:
質問は以下のやり方でまとめられます:
o changes to on the wire behavior; o routing system interactions; o identifier/mapping split; o application concerns and backward compatibility; o name service interactions; o legal concerns; and o security considerations.
o ワイヤの振舞いのときに変化する、。 o ルーティングシステム相互作用。 o 識別子/マッピングは分かれました。 o アプリケーション関心と後方の互換性。 o サービスを相互作用と命名してください。 o 法的な関心。 そして、oセキュリティ問題。
In reality many questions cut across all of these concerns. For instance, the identifier / locator split has substantial application implications, and every area has security considerations.
ほんとうは多くの質問がこれらの関心のすべてを横切りました。 例えば、識別子/ロケータ分裂には、かなりのアプリケーション意味があります、そして、あらゆる領域には、セキュリティ問題があります。
Unless it is blatantly obvious, each question contains some reasoning as to why it is being asked. It is envisioned that no solution will answer every question with completeness, but that there will be tradeoffs to be made. The answers by the various designers of solutions will hopefully shed some light on which tradeoffs we as a community wish to make.
それがおく面もなく明白でない場合、各質問はそれが尋ねられている理由に関して何らかの推理を含んでいます。 それは思い描かれます。どんな解決策も完全性であらゆる質問に答えるというわけではないでしょうが、作られている見返りがあるでしょう。 解決策の様々なデザイナーによる答えは希望をいだいて共同体としてのどの見返りを作りたいと思うかに関して軽いいくつかをはじくでしょう。
It would seem silly for people who have written detailed answers to these questions to have to repeat the exercise. Therefore, a simple reference to existing documents will suffice, so long as the answer is complete. If it is not complete, then feel free to reference it and add what text is necessary to make the answer complete.
運動を繰り返さなければならないのはこれらの質問の詳細な答えを書いた人々にとって愚かに思えるでしょう。 したがって、答えが完全である限り、既存のドキュメントの簡単な参照は十分でしょう。 それが完全でないなら、それを参照に解放するように感じてください、そして、テキストがものであると答えを完全にするのに必要な状態で言い足してください。
This document presumes a familiarity with RFC 3582 [2], and does not attempt to repeat the requirements work gathered there.
このドキュメントは、RFC3582[2]への親しみを推定して、そこに集められた要件仕事を繰り返すのを試みません。
Lear Informational [Page 3] RFC 4219 MULTI6 Solution Questionnaire October 2005
[3ページ]RFC4219MULTI6ソリューションアンケート2005年10月の情報のリア
2. On the Wire Behavior
2. ワイヤの振舞いに関して
2.1. How will your solution solve the multihoming problem?
2.1. あなたの解決策はどのようにマルチホーミング問題を解決するでしょうか?
Please scope the problem you are attempting to solve and what you are not attempting to solve.
あなたが解決するのを試みている問題とあなたが解決するのを試みていないことを見てください。
2.2. At what layer is your solution applied, and how?
2.2. あなたの解決策はどんな層に適用されるか、そして、どのようにですか?
Is it applied in every packet? If so, what fields are used?
それはあらゆるパケットで適用されますか? そうだとすれば、どんな分野が使用されていますか?
2.3. Why is the layer you chose the correct one?
2.3. あなたが選んだ層はなぜ正しい方ですか?
Each layer has its benefits and tradeoffs. For instance, transport layer solutions would require that EVERY transport be modified, while IP layer solutions may entail expansion of the packet or a change to the pseudo-header (thus requiring changes to the transport layer).
各層には、その利益と見返りがあります。 例えば、トランスポート層溶液は、EVERY輸送が変更されるのを必要とするでしょう、IP層の溶液がパケットの膨張か疑似ヘッダーへの変化を伴うかもしれませんが(その結果、トランスポート層への変化を必要とします)。
2.4. Does your solution address mobility?
2.4. あなたの解決策は移動性を記述しますか?
If so, how are rendezvous handled? Can your solution handle both locators changing at the same time? If so, please explain. Should it? If not, how will your solution interact with MOBILEIP-V6 [3] (MIPv6)
そうだとすれば、ランデブーはどのように扱われますか? あなたの解決策は同時に変化する両方のロケータを扱うことができますか? そうだとすれば、説明してください。 それはそうするべきですか? そうでなければ、あなたの解決策はどのようにMOBILEIP-V6[3]と対話するでしょうか?(MIPv6)
2.5. Does your solution expand the size of an IP packet?
2.5. あなたの解決策はIPパケットのサイズを広くしますか?
Expanding the size of an IP packet may cause excessive fragmentation in some circumstances.
IPパケットのサイズを広げると、いくつかの事情における過度の断片化は引き起こされるかもしれません。
2.6. Will your solution add additional latency?
2.6. あなたの解決策は追加潜在を加えるでしょうか?
Latency is an important factor in many applications, including voice. Any substantial amount of additional latency, including session initiation would be highly undesirable.
潜在は声を含む多くのアプリケーションで重要な要素です。 追加潜在のどんなかなりの量でありも、セッションを含んでいて、開始は非常に望ましくないでしょう。
2.7. Can multihoming capabilities be negotiated end-to-end during a
connection?
2.7. 接続の間、マルチホーミング能力は、交渉された終わりから終わりであるかもしれませんか?
If the proposal introduces additional overhead, can the information be somehow piggybacked on messages that are already used? This would be useful in order to keep connection setup constant. Please also indicate any drawbacks that might apply due to this piggybacking.
提案が追加オーバーヘッドを導入するなら、既に使用されるメッセージでどうにか情報を背負うことができますか? これは、接続設定を一定に保つために役に立つでしょう。 また、この便乗のため適用されるあらゆる欠点を示してください。
Lear Informational [Page 4] RFC 4219 MULTI6 Solution Questionnaire October 2005
[4ページ]RFC4219MULTI6ソリューションアンケート2005年10月の情報のリア
2.8. Do you change the way fragmenting is handled?
2.8. あなたは断片化が扱われる方法を変えますか?
If you use a shim approach, do you fragment above or below the shim? How are fragments identified, so that they can be reassembled? If you use any additional names, do they need to be associated with fragments? If not, why not? If so, how will that happen?
詰め物のアプローチを使用するなら、あなたは詰め物の上、または、詰め物の下で断片化しますか? 断片は、それらを組み立て直すことができるようにどのように特定されますか? あなたが何か追加名前を使用するなら、それらは、断片に関連している必要がありますか? ,? そうだとすれば、それはどのように起こるでしょうか?
2.9. Are there any layer 2 implications to your proposal?
2.9. 何かあなたの提案への層2の含意がありますか?
While IPv6 has a simplified approach to layer 2, perhaps you unsimplified it. If so, please provide details.
IPv6には、2を層にする簡単なアプローチがありますが、恐らく、あなたはそれを非簡素化しました。 そうだとすれば、詳細を明らかにしてください。
3. Identifiers and Locators
3. 識別子とロケータ
3.1. Uniqueness
3.1. ユニークさ
3.2. Does your solution provide for a split between identifiers and
locators?
3.2. あなたの解決策は識別子とロケータの間の分裂に備えますか?
3.3. What is the lifetime of a binding from an identifier to a locator?
3.3. 識別子からロケータまでの結合の寿命は何ですか?
3.4. How is the binding updated?
3.4. どのように結合をアップデートしますか?
Will transport connections remain up when new paths become available or when old ones become unavailable? How does the end node discover these events?
新しい経路が利用可能になるか、古いものであるときに接続が上がり続ける輸送は入手できなくなるでしょうか? エンドノードはどのようにこれらの出来事を発見しますか?
3.5. How does a host know its identity?
3.5. ホストはどのようにアイデンティティを知っていますか?
If you are establishing a new identity, how does the host learn it?
あなたが新しいアイデンティティを確立しているなら、ホストはどのようにそれを学びますか?
3.6. Can a host have multiple identifiers?
3.6. ホストは複数の識別子を持つことができますか?
If so, how does an application choose an identity?
そうだとすれば、アプリケーションはどのようにアイデンティティを選びますか?
3.7. If you have separate locators and identifiers, how will they be
mapped?
3.7. 別々のロケータと識別子がありましたら、それらはどのように写像されるでしょうか?
Does the mapping work in both directions? How would someone debugging a network determine which end stations are involved?
マッピングは両方の方向に取り組みますか? どのようにがネットワークをデバッグするのが決定するそれの端のステーションがかかわるだれかがそうするでしょうか?
3.8. Does your solution create an alternate "DNS-like" service?
3.8. あなたの解決策は交互の「DNSのような」サービスを作成しますか?
If you use mechanisms other than DNS, first, why was DNS not appropriate? Also, how will this other mechanism interact with DNS? What are its scaling properties?
あなたがDNS以外のメカニズムを使用するなら、最初に、DNSはなぜ適切ではありませんでしたか? また、この他のメカニズムはどのようにDNSと対話するでしょうか? スケーリング特性は何ですか?
Lear Informational [Page 5] RFC 4219 MULTI6 Solution Questionnaire October 2005
[5ページ]RFC4219MULTI6ソリューションアンケート2005年10月の情報のリア
3.9. Please describe authentication/authorization
3.9. 認証/認可について説明してください。
How are bindings authenticated and authorized. What technology do you build on for this mechanism?
結合は、どのように認証されて、認可されますか? どんな技術で、あなたはこのメカニズムのために建てますか?
3.10. Is your mechanism hierarchical?
3.10. あなたのメカニズムは階層的ですか?
Please describe the hierarchical breakdown.
階層的な故障について説明してください。
3.11. Middlebox interactions
3.11. Middlebox相互作用
What are the implications for firewalls? What are the interactions with Network Address Translation (NAT)? What are the interactions with web caches? What complications are introduced with your solution? For instance, are there implication for ingress filters? If so, what are they?
ファイアウォールへの含意は何ですか? Network Address Translation(NAT)との相互作用は何ですか? ウェブキャッシュとの相互作用は何ですか? あなたの解決策でどんな複雑さを導入しますか? 例えば、イングレスフィルタのための含意がありますか? そうだとすれば、それらは何ですか?
When considering this question, there are really two issues. First, will middleboxes impede your solution by rewriting headers in some way, as NATs do for IP addresses, and web caches do at higher layers? Second, is there a way in which middleboxes are actually part of your solution? In particular, are they required? This would be the case, for example, with Generalized Structure Element (GSE) (8+8).
この質問を考えるとき、本当に、2冊があります。 まず最初に、middleboxesは、NATsがIPアドレスのためにして、ウェブキャッシュが、より高い層でするように何らかの方法でヘッダーを書き直すことによって、あなたの解決策を妨害するでしょうか? 2番目に、middleboxesが実際にあなたの解決策の一部である方法がありますか? それらが特に、必要ですか? 例えば、これがGeneralized Structure Element(GSE)があるそうであるだろう、(8 +8)
3.12. Are there any implications for scoped addressing?
3.12. 何か見られたアドレシングのための含意がありますか?
Please see RFC 3513 [1]. How does your mechanism interact with multicast?
RFC3513[1]を見てください。 あなたのメカニズムはどのようにマルチキャストと対話しますか?
How does your solution interact with link-local addressing
あなたの解決策はどのようにリンクローカルのアドレシングと対話しますか?
How does your solution interact with Son-Of-Sitelocal (whatever that will be)?
あなたの解決策はどのようにSitelocalのSon(それは何でもになる)と対話しますか?
4. Routing System Interactions
4. ルート設定システム相互作用
4.1. Does your solution change existing aggregation methods?
4.1. あなたの解決策は既存の集合方法を変えますか?
Routing on the Internet scales today because hosts and networks can be aggregated into a relatively small number of entries. Does your solution change the way in which route aggregation occurs?
インターネットにおけるルート設定は、ホストとネットワークを比較的少ない数のエントリーに集めることができるので、今日、比例します。 あなたの解決策はルート集合が起こる方法を変えますか?
Lear Informational [Page 6] RFC 4219 MULTI6 Solution Questionnaire October 2005
[6ページ]RFC4219MULTI6ソリューションアンケート2005年10月の情報のリア
4.2. Does the solution solve traffic engineering requirements?
4.2. 解決策は交通工学要件を解決しますか?
One of the significant goals of IPv4 multihoming solutions has been the ability to perform traffic engineering based on appropriately adjusting the BGP advertisements. If the prefixes used by such sites was be aggregated (particularly beyond the site"s border), the site"s ability to perform traffic engineering would be diminished.
IPv4マルチホーミング解決の重要な目標の1つは適切にBGP広告を調整することに基づいて交通工学を実行する能力です。 そのようなサイトによって使用される接頭語があったなら集められてください、(特にサイト、「s境界)、減少していて、」 s履行能力交通工学がそうするサイト。
4.3. Does the solution offer ways for the site to manage its traffic
flows?
4.3. 解決策はサイトが交通の流れを管理する方法を提供しますか?
If so, how? Is this controllable on a per-host basis, or on a per-site basis?
そうだとすれば、どのようにですか? これは1ホストあたり1個のベースの上、または、1サイトあたり1個のベースの上で制御可能ですか?
4.4. If you introduce any new name spaces, do they require aggregation?
4.4. あなたが何か新しい名前空間を導入するなら、彼らは集合を必要としますか?
Is it desirable or required that, in order to scale distribution of any mapping information, an aggregation method be introduced?
何かマッピング情報の分配をスケーリングする集合方法を導入するのが、望ましいですか、必要ですか?
4.5. Does your solution interact with Autonomous System numbering?
4.5. あなたの解決策はAutonomous System付番と対話しますか?
If your solution involves address prefixes distributed using BGP4+, does it interact with the use of AS numbers and, if so, how? Will it require additional AS numbers?
あなたの解決策がBGP4+を使用することで分配されたアドレス接頭語にかかわるなら、AS番号の使用と対話します、そして、そうだとすれば、どのようにですか? それは追加AS番号を必要とするでしょうか?
4.6. Are there any changes to ICMP error semantics?
4.6. ICMP誤り意味論へのいくつかの変化がありますか?
Do you create new codes? If so, why and what do they mean? Will a host that is not aware of your scheme see them?
あなたは新法を作成しますか? そして、まあ、そうだとすれば、彼らは何を意味しますか? あなたの計画を意識していないホストはそれらを見るでしょうか?
5. Name Service Interactions
5. 名前サービス相互作用
5.1. Please explain the relationship of your solution to DNS
5.1. DNSの解決策の関係について説明してください。
If your solution uses new names for identifiers, please explain what mappings are defined, and how they are performed?
解決策が識別子に新しい名前を使用するなら、どんなマッピングが定義されるか、そして、それらがどのように実行されるか説明してくれますか?
If there are any additional administrative requirements, such as new zones or RR types to manage, please explain them as well.
新しいゾーンなどの追加どんな管理要件もあるか、またはRRが管理するためにタイプするなら、また、それらについて説明してください。
5.2. Please explain interactions with "2-faced" DNS
5.2. 「2顔をした」DNSとの相互作用について説明してください。
2-faced DNS is used so that hosts behind a NAT get one address for internal hosts, while hosts outside the NAT get another. Similar mechanisms are used for application layer gateways, such as SOCKS [5].
2顔をしたDNSが使用されているので、NATの後ろのホストは内部のホストに1つのアドレスを届けます、NATの外におけるホストが別のものを得ますが。 同様のメカニズムはSOCKS[5]などの応用層ゲートウェイに使用されます。
Lear Informational [Page 7] RFC 4219 MULTI6 Solution Questionnaire October 2005
[7ページ]RFC4219MULTI6ソリューションアンケート2005年10月の情報のリア
5.3. Does your solution require centralized registration?
5.3. あなたの解決策は集結された登録を必要としますか?
For instance, if you are using the DNS, what will be the top level domain, and how will the name space distribute through it?
例えば、あなたがDNSを使用しているなら、トップ・レベル・ドメインは何になるだろうか、そして、名前スペースはそれを通してどのように分配するでしょうか?
Also, how will the centralized registration be managed?
また、集結された登録はどのように管理されるでしょうか?
5.4. Have you checked for DNS circular dependencies?
5.4. あなたはDNSの円形の依存がないかどうかチェックしましたか?
If you are using the DNS in your solution, is it required for connectivity? What happens if the DNS fails? Can communication between the DNS resolver and the server make use of your solution? What about between the application and the resolver?
あなたが解決策にDNSを使用しているなら、それが接続性に必要ですか? DNSが失敗するなら、何が起こりますか? DNSレゾルバとサーバとのコミュニケーションはあなたの解決策を利用できますか? アプリケーションとレゾルバの間でどうがどうですか?
5.5. What if a DNS server itself is multihomed?
5.5. DNSサーバ自体が「マルチ-家へ帰」ると、どうなるでしょうか?
If a link fails or a service is dropped, how will it impact DNS? Again, are there any dependency loops? Perhaps diagram out your dependencies to make sure.
リンクが失敗するか、またはサービスが落とされると、それはどのようにDNSに影響を与えるでしょうか? 一方、何か依存輪がありますか? 確実にするために恐らく外に依存を図解してください。
5.6. What additional load will be placed on DNS servers?
5.6. どんな追加負荷がDNSサーバに置かれるでしょうか?
Can the load be distributed? Remember that DNS is optimized for READ operations.
負荷を分配できますか? DNSがREAD操作のために最適化されたのを覚えていてください。
5.7. Any upstream provider support required?
5.7. サポートが必要とした上流のプロバイダーがありますか?
If so, please describe. For instance, currently reverse mappings are delegated down from upstream providers. How would this work with your solution?
そうだとすれば、説明してください。 例えば、上流のプロバイダーから現在逆のマッピングを代表として派遣します。 これはあなたの解決策でどのように働いていますか?
5.8. How do you debug connectivity?
5.8. あなたはどのように接続性をデバッグしますか?
How would tools like ping and traceroute need to be enhanced? What additional tools would prove useful or necessary? For instance, if there is an id/locator split, can one ping an identifier? If so, what gets returned?
ピングとトレースルートのようなツールは、どのように高められる必要がありますか? どんな追加ツールが役に立つか、または必要であると判明するでしょうか? 例えば、イド/ロケータ分裂があれば、1つは識別子を確認できますか? そうだとすれば、何を返しますか?
6. Application Concerns and Backward Compatibility
6. アプリケーション関心と後方の互換性
6.1. What application/API changes are needed?
6.1. どんなアプリケーション/API変化が必要ですか?
Will old code work with the new mechanism? For instance, what about code that uses gethostbyname()?
旧法は新しいメカニズムで働くでしょうか? 例えば、gethostbyname()を使用するコードはどうですか?
Will getaddrinfo() need to change?
getaddrinfo()は、変化する必要があるでしょうか?
What about other API calls?
他のAPI呼び出しはどうですか?
Lear Informational [Page 8] RFC 4219 MULTI6 Solution Questionnaire October 2005
[8ページ]RFC4219MULTI6ソリューションアンケート2005年10月の情報のリア
There are several possible approaches. For instance, a multihoming service could attempt to require no changes to the API, in which case it is possible that IP addresses might become opaque blobs that work with the API, but might break operational assumptions that applications make about addresses. Consider the case of a web server that wants to log IP addresses. How will it accomplish this task?
いくつかの可能なアプローチがあります。 例えば、マルチホーミングサービスは、APIへの変化を全く必要としないのを試みるかもしれなくて、その場合、IPアドレスがAPIで働いている不透明な一滴になるかもしれませんが、アプリケーションがアドレスに関してする操作上の仮定を破るのは、可能です。 IPアドレスを登録したがっているウェブサーバーに関するケースを考えてください。 それはどのようにこのタスクを達成するでしょうか?
Another approach is to have some sort of compatibility library for legacy applications, but also provide a richer calling interface for transparency.
別のアプローチが遺産アプリケーションのためのある種の互換性ライブラリを持つことですが、より豊かな呼ぶインタフェースを透明にまた提供してください。
Yet another approach would be to only provide the new functionality to those applications that make use of a new calling interface.
さらに別のアプローチは新しい呼ぶインタフェースを利用するそれらのアプリケーションに新しい機能性を提供するだけであるだろうことです。
One useful exercise would be to provide code fragments that demonstrate any API changes.
1回の役に立つ運動はどんなAPI変化もデモをするコード断片を提供するだろうことです。
6.2. Is this solution backward compatible with "old" IP version 6?
6.2. この解決策が後方にある、「古い」IPバージョン6と互換性がありますか?
Can it be deployed incrementally? Please describe how.
それを増加して配備できますか? その方法を説明してください。
Does your solution impose requirements on non-multihomed/non-mobile hosts?
あなたの解決策は非「マルチ-家へ帰」っている/非モバイルホストに要件を課しますか?
What happens if someone plugs in a normal IPv6 node?
だれかが正常なIPv6ノードのプラグを差し込むなら、何が起こりますか?
6.3. Is your solution backward compatible with IPv4?
6.3. あなたの解決策が後方にある、IPv4と互換性がありますか?
How will your mechanism interact with 6to4 gateways and IPv4 hosts?
あなたのメカニズムはどのように6to4ゲートウェイとIPv4ホストと対話するでしょうか?
6.4. Can IPv4 devices take advantage of this solution?
6.4. IPv4装置はこの解決策を利用できますか?
Can the same mechanism somehow be used on the existing network? N.B. this is NOT a primary consideration, but perhaps a side benefit of a particular solution.
既存のネットワークでどうにか同じメカニズムを使用できますか? N. B. これは第一の考慮ではなく、恐らく特殊解の役得です。
6.5. What is the impact of your solution on different types of sites?
6.5. 異なったタイプのサイトへのあなたの解決策の影響は何ですか?
What will the impact of your solution be on the following types of systems?
あなたの解決策の影響は以下のタイプのシステムの上で何になるでしょうか?
o single homed sites o small multihomed sites o large multihomed sites o ad-hoc sites o short lived connections (think aggregator wireless ISPs)
o シングルが家へ帰った、遺跡のo小さい「マルチ-家へ帰」っているサイトo多、は遺跡の臨時の遺跡o背の低い送られたo接続を「マルチ-家へ帰」らせました。(アグリゲータ無線電信ISPを考えます)
Lear Informational [Page 9] RFC 4219 MULTI6 Solution Questionnaire October 2005
[9ページ]RFC4219MULTI6ソリューションアンケート2005年10月の情報のリア
In particular, consider ongoing administration, renumbering events, and mobile work forces.
出来事、および可動の労働人口に番号を付け替えさせて、特に、進行中の管理を考えてください。
6.6. How will your solution interact with other middleboxes?
6.6. あなたの解決策はどのように他のmiddleboxesと対話するでしょうか?
6.7. Referrals
6.7. 紹介
How will your solution handle referrals, such as those within FTP or various conferencing or other peer to peer systems?
あなたの解決策はどのようにFTPの中のそれらなどの紹介か様々な会議の、または、他のピアツーピアシステムを扱うでしょうか?
Referrals exist within various other protocols, such as so-called "peer to peer" applications. Note that referrals might suffer three types of failure:
紹介はいわゆる「ピアツーピア」アプリケーションなどの他の様々なプロトコルの中に存在しています。 紹介が3つのタイプの失敗を受けるかもしれないことに注意してください:
firewall and NAT - Is there failure just as what FTP active mode
experiences today with relatively simple firewalls?
time-based - Is there something ephemeral about the nature of the
solution that might cause a referral (such as a URL) to fail over
time, more so than what we have today?
location-based - If the binding varies based on where the parties are
in the network, and if one moves, will they no longer be able to
find each other?
ファイアウォールとNAT--ちょうど今日の比較的簡単なファイアウォールのどんなFTPの活発なモード経験(時間ベースである)が結合がどこに基づいてパーティーを変えるかならネットワークには私たちが今日持っている位置のベースのものがあるよりそうであるフェイルオーバー時間まで紹介(1つのURLなどの)を引き起こすかもしれない解決策の本質に関して何かはかないものがあるかとき失敗があって、人が動くと、彼らはもう互いを見つけることができないでしょうか?
6.8. Demonstrate use with a real life complex application
6.8. 現実の複雑なアプリケーションで使用を示してください。
Provide a detailed walk-through of SIP + Real Time Streaming Protocol (SIP+RTSP) when one or several of the peers are multihomed. How does your analysis change when encrypted RTSP is used or when SIP with S/MIME end-to-end (e2e) signalling is used?
1か数人の同輩が「マルチ-家へ帰」ったら、SIP+本当のTime Streamingプロトコル(SIP+RTSP)の詳細な立ち稽古を提供してください。 あなたの分析は、コード化されたRTSPがいつ使用されているか、そして、またはMIMEの終わりからS/終わりへの(e2e)が合図しているSIPがいつ使用されているかをどのように変えますか?
7. Legal Concerns
7. 法的な関心
Are you introducing a namespace that might involve mnemonics? Doing so might introduce trademark concerns. If so, how do you plan to address such concerns?
あなたはニーモニックにかかわるかもしれない名前空間を導入していますか? そうするのは商標関心を導入するかもしれません。 そうだとすれば、あなたは、そのような関心を記述するのをどのように計画していますか?
Are there any organizations required to manage a new name space? If so, please describe what they are and how the method will scale.
新しい名前スペースを管理するのに必要である組織がありますか? そうだとすれば、それらが何であるか、そして、方法がどのように比例するか説明してください。
8. Security Considerations
8. セキュリティ問題
How secure should a multi6 solution be? This is a reasonable question for each solution to answer. The author opines that the worst case should be no worse than what we have today. For example, would a multi6 solution open up a host, on either end of a communication, to a time-based attack? Any such risks should be clearly stated by the authors. Considerable time should be spent on threat analysis. Please see [4] for more details.
multi6解決策はどれくらい安全であるべきですか? これは各解決策が答える道理に合った質問です。 最悪がケースに入れる作者オピンは私たちが今日持っているものより悪いはずがありません。 例えば、multi6解決策は時間ベースの攻撃へのコミュニケーションのどちらの終わりにもホストを開けるでしょうか? どんなそのような危険も作者によって明確に述べられているべきです。 かなりの時間は脅威分析に費やされるべきです。 その他の詳細のための[4]を見てください。
Lear Informational [Page 10] RFC 4219 MULTI6 Solution Questionnaire October 2005
[10ページ]RFC4219MULTI6ソリューションアンケート2005年10月の情報のリア
As IP addresses can often be tied to individuals, are there any auditing or privacy concerns introduced by your solution?
IPアドレスがしばしばあることができるように、個人に結ばれて、あなたの解決策で導入して、何か監査やプライバシーの問題がありますか?
9. Acknowledgements
9. 承認
The author wishes to acknowledge everyone in the multi6 group and elsewhere that is putting forward proposals. It is easy to ask questions like the ones found in this document. It is quite a bit harder to develop running code to answer them. Marcelo Bagnulo, Kurt Erik Lindqvist, Joe Touch, Patrik Faltstrom, Brian Carpenter, and Iljitsch van Beijnum provided input to this document.
作者はmulti6グループとそれが提案について提唱しているほかの場所で皆を承認したがっています。 本書では見つけられたもののように質問するのは簡単です。 それらに答えるために走行コードをかなりのビットより開発しにくいです。 このドキュメントに入力されるなら、マルセロBagnulo、カート・エリック・リンクヴィスト、ジョーTouch、パトリクFaltstrom、ブライアンCarpenter、およびIljitschはBeijnumをバンに積みます。
10. References
10. 参照
10.1. Normative References
10.1. 引用規格
[1] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
Addressing Architecture", RFC 3513, April 2003.
[1]HindenとR.とS.デアリング、「インターネットプロトコルバージョン6(IPv6)アドレッシング体系」、RFC3513、2003年4月。
[2] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site-
Multihoming Architectures", RFC 3582, August 2003.
[2]Abley、J.、黒、B.、およびV.エラ、「IPv6サイトマルチホーミング構造の目標」、RFC3582、2003年8月。
[3] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[3] ジョンソンとD.とパーキンス、C.とJ.Arkko、「IPv6"、RFC3775、2004年6月の移動性サポート。」
[4] Nordmark, E., "Threats Relating to IPv6 Multihoming Solutions",
RFC 4218, October 2005.
[4]Nordmark、E.、「IPv6マルチホーミング解決に関係する脅威」、RFC4218、2005年10月。
10.2. Informative References
10.2. 有益な参照
[5] Kitamura, H., "A SOCKS-based IPv6/IPv4 Gateway Mechanism",
RFC 3089, April 2001.
[5] 喜田村、H.、「ソックスベースのIPv6/IPv4ゲートウェイメカニズム」、RFC3089、2001年4月。
Author's Address
作者のアドレス
Eliot Lear Cisco Systems GmbH Glatt-com, 2nd Floor CH-8301 Glattzentrum ZH Switzerland
エリオットリアシスコシステムズGmbHグラット-com、2階のCH-8301 Glattzentrum ZHスイス
EMail: lear@cisco.com
メール: lear@cisco.com
Lear Informational [Page 11] RFC 4219 MULTI6 Solution Questionnaire October 2005
[11ページ]RFC4219MULTI6ソリューションアンケート2005年10月の情報のリア
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
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 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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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に情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Lear Informational [Page 12]
リアInformationalです。[12ページ]
一覧
スポンサーリンク
