Network Working Group E. Lear
Request for Comments: 4219 Cisco Systems
Category: Informational October 2005
Things Multihoming in IPv6 (MULTI6) Developers Should Think About
物事IPv6でのマルチホーミング（MULTI6）開発者が考えなければなりません
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.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
著作権（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でマルチホーミングするソリューションの一部として答えるために準備しなければならない質問のセットを指定します。質問は、マルチホーミングは、関心の唯一の問題であることを前提とせず、また、より一般的な解決策を求めてください。
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
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
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.
これは、他の提案されたソリューションのおそらく作者はその解決策のギャップを識別するために、この文書を使用して、それらのギャップを埋めるために協力する作者の希望です。
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.
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.
この文書では、[2] RFC 3582に精通している前提、そして仕事が集まっ要件を繰り返すようにしようとしません。
Please scope the problem you are attempting to solve and what you are not attempting to solve.
スコープにあなたが解決しようとしている問題と何を解決しようとされていないしてください。
Is it applied in every packet? If so, what fields are used?
それはすべてのパケットに適用されますか？もしそうなら、どのようなフィールドが使用されていますか？
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).
各層は、その利点とトレードオフがあります。 IP層ソリューションは、パケットまたは（したがって、トランスポート層への変更を必要とする）疑似ヘッダの変更の膨張を伴うかもしれないが、例えば、輸送層溶液はすべての輸送が改変されることを必要とするであろう。
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の）と相互に作用します
Expanding the size of an IP packet may cause excessive fragmentation in some circumstances.
IPパケットのサイズを展開すると、いくつかの状況で過度の断片化を引き起こす可能性があります。
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.
提案は、追加のオーバーヘッドが発生した場合、情報が何らかの形で既に使用されているメッセージにピギーバックすることができますか？これは、接続設定を一定に保つために有用であろう。また、これによるピギーバックに適用される場合があります任意の欠点を記入してください。
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?
あなたはシム・アプローチを使用する場合は、シムの上または下に断片化していますか？彼らは再組み立てすることができるように断片には、どのように識別されますか？あなたが任意の追加の名前を使用する場合は、フラグメントに関連付けられる必要がありますか？そうでない場合は、なぜ？もしそうなら、どのようにそれが起こるのだろうか？
While IPv6 has a simplified approach to layer 2, perhaps you unsimplified it. If so, please provide details.
IPv6は2層に簡略化されたアプローチがありますが、おそらくあなたはそれをunsimplified。その場合は、詳細をお知らせください。
3.2. Does your solution provide for a split between identifiers and locators?
3.2. あなたのソリューションは、識別子とロケータの間の分割のために提供していますか？
Will transport connections remain up when new paths become available or when old ones become unavailable? How does the end node discover these events?
接続は、新しいパスが利用可能になったときや、古いものが使用できなくなったときにアップしたまま輸送しますか？どのようにエンド・ノードは、これらのイベントを発見するのですか？
If you are establishing a new identity, how does the host learn it?
あなたが新しいアイデンティティを確立している場合は、どのホストがそれを学ぶのでしょうか？
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?
両方向のマッピング作業をしていますか？どのようにネットワークをデバッグ誰かが関与しているエンドステーション決めるのでしょうか？
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と対話するのだろうか？そのスケーリング特性は何ですか？
How are bindings authenticated and authorized. What technology do you build on for this mechanism?
どのようにバインディングが認証され、承認されています。あなたは、このメカニズムのためにどのような技術で構築していますか？
Please describe the hierarchical breakdown.
階層的な内訳を記載してください。
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?
ファイアウォールのための含意は何ですか？ネットワークアドレス変換（NAT）との相互作用は何ですか？ Webキャッシュとの相互作用は何ですか？どのような合併症は、あなたのソリューションを導入していますか？例えば、イングレスフィルタのための含意があるのですか？もしそうなら、彼らは何ですか？
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つの問題があります。まず、NATのは、IPアドレスのために行うようミドルボックスは、何らかの方法でヘッダを書き換えることにより、ソリューションを妨げ、およびWebキャッシュは、上位層で行うのでしょうか？第二に、ミドルボックスは、実際にあなたのソリューションの一部である方法はありますか？特に、それらが必要とされていますか？これは、一般構造エレメント（GSE）（8 + 8）を用いて、例えば、場合です。
Please see RFC 3513 [1]. How does your mechanism interact with multicast?
RFC 3513 [1]を参照してください。どのようにあなたのメカニズムは、マルチキャストと対話していますか？
How does your solution interact with link-local addressing
どのようにあなたのソリューションは、リンクローカルアドレッシングと対話しません
How does your solution interact with Son-Of-Sitelocal (whatever that will be)?
どのようにあなたのソリューションは、ソン・オブ・Sitelocal（それはなります何でも）と対話していますか？
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?
ホストとネットワークは、エントリの比較的少数に集約することができますので、今日のインターネットスケールでのルーティング。あなたのソリューションは、ルート集約が発生する方法を変更していますか？
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のマルチホーミングソリューションの重要な目標の一つは、適切にBGP広告を調整するに基づいてトラフィックエンジニアリングを実行する機能となっています。そのようなサイトで使用されるプレフィックスは、トラフィック・エンジニアリングを行うための能力減少されるだろう（特にサイト「サイトの国境を越えて）」が集約された場合。
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?
もしそうなら、どのように？これは、ホストごとに、またはサイト単位で制御可能ですか？
Is it desirable or required that, in order to scale distribution of any mapping information, an aggregation method be introduced?
これは、任意のマッピング情報の分布をスケーリングするために、凝集法を導入することが望ましいまたは必要ですか？
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番号の追加が必要になりますか？
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?
あなたは、新しいコードを作成しますか？もしそうなら、なぜ、彼らは何を意味するのですか？あなたのスキームを認識していないホストは、それらを見るのだろうか？
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型などの任意の追加の管理要件がある場合は、同様にそれらを説明してください。
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].
NATの背後にあるホストが内部ホストに対して1つのアドレスを取得するようにNAT外部ホストが別のものを取得しながら、2-顔DNSは、使用されます。同様のメカニズムは、SOCKSなどのアプリケーション層ゲートウェイ、[5]のために使用されます。
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?
また、どのように中央集権登録が管理されますか？
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リゾルバとサーバ間の通信は、あなたのソリューションを利用することができますか？アプリケーションとレゾルバの間ではどう？
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に影響を与えるのだろうか？ここでも、任意の依存関係ループがあるのですか？おそらくことを確認するために、依存関係を図式化。
Can the load be distributed? Remember that DNS is optimized for READ operations.
負荷を分散することができますか？ DNSは、READ操作用に最適化されていることを覚えておいてください。
If so, please describe. For instance, currently reverse mappings are delegated down from upstream providers. How would this work with your solution?
もしそうなら、説明してください。例えば、現在のマッピングが上流プロバイダからダウン委任されている逆。どうでしょうあなたのソリューションで、この作品？
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?
どのようにpingやtracerouteのようなツールを強化する必要があるでしょうか？便利または必要に応じて追加的にどのようなツールを証明するのでしょうか？ ID /ロケータ分離がある場合、例えば、一方が識別子をpingすることができますか？もしそうなら、何が返されますか？
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呼び出しはどうですか？
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?
いくつかの可能なアプローチがあります。例えば、マルチホーミングサービスは、IPアドレスはAPIと連携不透明な塊になるかもしれませんが、アプリケーションはアドレスについて行い、動作の前提を壊すかもしれない可能性があり、その場合には、APIへの変更を必要としないを試みる可能性があります。 IPアドレスを記録したいWebサーバのケースを考えてみましょう。それはどのようにこのタスクを達成するのだろうか？
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.
一つの有用な運動は、任意のAPIの変更を実証コードの断片を提供するだろう。
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ノードに差し込む場合はどうなりますか？
How will your mechanism interact with 6to4 gateways and IPv4 hosts?
どのようにあなたのメカニズムは、6to4ゲートウェイと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.これは第一に考慮されていないが、特定の溶液の多分側利益。
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アドホックサイト（アグリゲーター無線のISPと思います）
In particular, consider ongoing administration, renumbering events, and mobile work forces.
具体的には、継続的な管理、リナンバリングイベント、および移動作業力を考えます。
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アクティブモードは、比較的単純なファイアウォールで今日経験するものとしてありますか？時間ベース - 我々が今日持っているものよりもより多くのように時間をかけて失敗する（URLなど）の紹介を引き起こす可能性の溶液の性質についてのはかないものが、ありますか？ロケーションベース - 結合は、当事者がネットワーク内に存在せず、1つの動くならば、彼らはもはやお互いを見つけることができるようになりますどこに基づいて変化する場合？
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 +リアルタイムストリーミングプロトコル（SIP + RTSP）の詳細なウォークスルーを提供します。どのように暗号化されたRTSPは、あなたの分析の変更に使用されない場合、またはときとSIPは、S / MIMEのエンド・ツー・エンド（E2E）シグナリングが使用されていますか？
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.
新しい名前空間を管理するために必要な組織はありますか？もしそうなら、彼らが何であるかを説明し、この方法は、スケールされているかしてください。
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]を参照してください。
As IP addresses can often be tied to individuals, are there any auditing or privacy concerns introduced by your solution?
IPアドレスは、多くの場合、個人に結び付けられるように、あなたのソリューションにより導入されたすべての監査やプライバシーの問題があるのですか？
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、クルト・エリックLindqvist、ジョー・タッチ、パトリックFaltstrom、ブライアン・カーペンター、およびIljitschバンBeijnumは、この文書に入力を提供します。
[1] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003.
[1] HindenとR.とS.デアリング、 "インターネットプロトコルバージョン6（IPv6）のアドレス指定アーキテクチャ"、RFC 3513、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のサイトマルチホーミングアーキテクチャの目標"、RFC 3582、2003年8月。
[3] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[3]ジョンソン、D.、パーキンス、C.、およびJ. Arkko、 "IPv6におけるモビリティサポート"、RFC 3775、2004年6月。
[4] Nordmark, E., "Threats Relating to IPv6 Multihoming Solutions", RFC 4218, October 2005.
[4]、RFC 4218、2005年10月Nordmarkと、E.、 "IPv6のマルチホーミングソリューションに関連脅威を"。
[5] Kitamura, H., "A SOCKS-based IPv6/IPv4 Gateway Mechanism", RFC 3089, April 2001.
[5]北村、H.、 "SOCKSベースのIPv6 / IPv4のゲートウェイ機構"、RFC 3089、2001年4月。
Author's Address
著者のアドレス
Eliot Lear Cisco Systems GmbH Glatt-com, 2nd Floor CH-8301 Glattzentrum ZH Switzerland
エリオット・リアシスコシステムズ社グラット-COM、2階のCH-8301 Glattzentrum ZHスイス
EMail: lear@cisco.com
メールアドレス：lear@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（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.
この文書では、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 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が表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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に情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。