[要約] RFC 4219は、IPv6のマルチホーミングに関する開発者が考慮すべき事項をまとめたものであり、その目的はIPv6ネットワークの効果的なマルチホーミング実装を支援することです。
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）開発者のMultihomingのことを考える必要があります
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).
Copyright（c）The Internet Society（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.
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.
このドキュメントは、RFC 3582 [2]に精通していると仮定しており、そこに収集された要件を繰り返すことを試みません。
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.
レイテンシは、音声を含む多くのアプリケーションで重要な要素です。セッションの開始を含むかなりの量の追加の遅延は、非常に望ましくありません。
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への単純化されたアプローチがありますが、おそらくあなたはそれを単純化していないでしょう。もしそうなら、詳細を提供してください。
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?
もしそうなら、アプリケーションはどのようにアイデンティティを選択しますか？
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アドレスに対して行うように、何らかの方法でヘッダーを書き直すことにより、ミドルボックスがソリューションを妨げますか？第二に、ミドルボックスが実際にあなたのソリューションの一部である方法はありますか？特に、それらは必要ですか？これは、たとえば、一般化された構造要素（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
ソリューションは、Link-Localアドレス指定とどのように相互作用します
How does your solution interact with Son-Of-Sitelocal (whatever that will be)?
あなたのソリューションはどのように息子の息子と相互作用しますか（それが何であれ）？
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マルチホームソリューションの重要な目標の1つは、BGP広告の適切な調整に基づいてトラフィックエンジニアリングを実行する能力です。そのようなサイトで使用されている接頭辞が集約されている場合（特にサイト「S Borderを超えて）、サイトエンジニアリングを実行する能力が減少します。
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を使用して分散したアドレスプレフィックスが含まれる場合、それは数字の使用と相互作用しますか？追加の数字が必要になりますか？
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].
2フェイスのDNSが使用されているため、NATの後ろにホストが内部ホストの1つのアドレスを取得し、NATの外側のホストは別のアドレスを取得します。同様のメカニズムは、靴下などのアプリケーションレイヤーゲートウェイに使用されます[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は読み取り操作に最適化されていることを忘れないでください。
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? 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呼び出しはどうですか？いくつかの可能なアプローチがあります。たとえば、マルチホームサービスはAPIに変更を必要とせずに試みることができます。その場合、IPアドレスは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.
有用な演習の1つは、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) In particular, consider ongoing administration, renumbering events, and mobile work forces.
o 単一の家庭用サイトo小さなマルチホームサイトo大規模なマルチホームサイトoアドホックサイトo短命の接続（アグリゲーターワイヤレスISPを考えてください）特に、継続的な管理、イベントの変更、およびモバイルの労働力を検討してください。
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など）が時間の経過とともに失敗する可能性のあるソリューションの性質については、私たちが今日持っているものよりもはるかに何かがありますか？ロケーションベース - バインディングは、当事者がネットワークのどこにあるか、そして動く場合、彼らはお互いを見つけることができなくなりますか？
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を使用したとき、またはS/MIMEエンドツーエンド（E2E）シグナルを使用してSIPを使用すると、分析はどのように変化しますか？
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グループや他の場所のすべての人に提案を提案していることを認めたいと考えています。このドキュメントで見つかったような質問をするのは簡単です。ランニングコードを開発して回答するのはかなり困難です。Marcelo Bagnulo、Kurt Erik Lindqvist、Joe Touch、Patrik Faltstrom、Brian Carpenter、およびIljitsch van Beijnumは、この文書への入力を提供しました。
[1] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003.
[1] Hinden、R。and S. Deering、「インターネットプロトコルバージョン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.、Black、B。、およびV. Gill、「IPv6サイト監督アーキテクチャの目標」、RFC 3582、2003年8月。
[3] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[3] Johnson、D.、Perkins、C。、およびJ. Arkko、「IPv6のモビリティサポート」、RFC 3775、2004年6月。
[4] Nordmark, E., "Threats Relating to IPv6 Multihoming Solutions", RFC 4218, October 2005.
[4] Nordmark、E。、「IPv6マルチホームソリューションに関連する脅威」、RFC 4218、2005年10月。
[5] Kitamura, H., "A SOCKS-based IPv6/IPv4 Gateway Mechanism", RFC 3089, April 2001.
[5] Kitamura、H。、「ソックスベースのIPv6/IPv4ゲートウェイメカニズム」、RFC 3089、2001年4月。
Author's Address
著者の連絡先
Eliot Lear Cisco Systems GmbH Glatt-com, 2nd Floor CH-8301 Glattzentrum ZH Switzerland
Eliot Lear Cisco Systems Gmbh Glatt-Com、2階CH-8301 Glattzentrum Zh Switzerland
EMail: lear@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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への情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。