Network Working Group J. Abley
Request for Comments: 3582 ISC
Category: Informational B. Black
Layer8 Networks
V. Gill
AOL Time Warner
August 2003
Goals for IPv6 Site-Multihoming Architectures
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 (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
Abstract
抽象
This document outlines a set of goals for proposed new IPv6 site-multihoming architectures. It is recognised that this set of goals is ambitious and that some goals may conflict with others. The solution or solutions adopted may only be able to satisfy some of the goals presented here.
この文書は、提案された新しいIPv6サイトマルチホーミングアーキテクチャの目標のセットを概説します。目標のこのセットは、野心的であることが認識されていると、いくつかの目標が他の人と競合する可能性があること。採用されたソリューションやソリューションは、ここでしか提示目標のいくつかを満たすことができるかもしれません。
Site-multihoming, i.e., connecting to more than one IP service provider, is an essential component of service for many sites which are part of the Internet.
サイトマルチホーミングは、すなわち、複数のIPサービスプロバイダに接続し、インターネットの一部である多くのサイトのためのサービスの必須成分です。
Current IPv4 site-multihoming practices have been added on to the CIDR architecture [1], which assumes that routing table entries can be aggregated based upon a hierarchy of customers and service providers.
現在のIPv4サイトマルチホーミングプラクティスは、ルーティングテーブルエントリは、顧客とサービス・プロバイダの階層に基づいて集計することができると仮定CIDRアーキテクチャ[1]へ追加されています。
However, it appears that this hierarchy is being supplanted by a dense mesh of interconnections [6]. Additionally, there has been an enormous growth in the number of multihomed sites. For purposes of redundancy and load-sharing, the multihomed address blocks are introduced into the global table even if they are covered by a provider aggregate. This contributes to the rapidly-increasing size of both the global routing table and the turbulence exhibited within it, and places stress on the inter-provider routing system.
しかし、この階層は、配線の密なメッシュ[6]に取って代わられていることが表示されます。さらに、マルチホームサイトの数が急増がありました。冗長性と負荷分散の目的のために、マルチホームアドレスブロックは、それらが、プロバイダの集計でカバーされている場合でも、グローバルテーブルに導入されています。これは、グローバルルーティングテーブルとその中に展示乱流の両方の急速に大型化に寄与し、およびインタープロバイダのルーティングシステムにストレスを置きます。
Continued growth of both the Internet and the practice of site-multihoming will seriously exacerbate this stress. The site-multihoming architecture for IPv6 should allow the routing system to scale more pleasantly.
インターネットとサイトマルチホーミングの実践の両方の継続的な成長は真剣にこのストレスを悪化させるだろう。 IPv6のサイトマルチホーミングアーキテクチャは、ルーティングシステムをより楽しく拡張できるようにする必要があります。
A "site" is an entity autonomously operating a network using IP, and in particular, determining the addressing plan and routing policy for that network. This definition is intended to be equivalent to "enterprise" as defined in [2].
「サイト」とは、エンティティが自律的にIPを使用するネットワークを動作させる、特に、そのネットワークのアドレス計画およびルーティングポリシーを決定することです。この定義は、[2]で定義されるように「企業」と同等であることが意図されています。
A "transit provider" operates a site that directly provides connectivity to the Internet to one or more external sites. The connectivity provided extends beyond the transit provider's own site. A transit provider's site is directly connected to the sites for which it provides transit.
「トランジットプロバイダは、」直接1つまたは複数の外部サイトへのインターネットへの接続性を提供し、サイトを運営しています。提供される接続は、トランジットプロバイダ自身のサイトを越えて延びています。トランジットプロバイダーのサイトでは、それはトランジットを提供しているサイトに直接接続されています。
A "multihomed" site is one with more than one transit provider. "Site-multihoming" is the practice of arranging a site to be multihomed.
「マルチホーム」サイトには、複数のトランジットプロバイダーとの1です。 「サイトマルチホーミングは、」マルチホームするサイトを配置する方法です。
The term "re-homing" denotes a transition of a site between two states of connectedness due to a change in the connectivity between the site and its transit providers' sites.
用語「再ホーミングは」によるサイトとそのトランジットプロバイダーのサイト間の接続性の変化につながりの2つの状態の間、サイトの推移を示しています。
The following capabilities of current IPv4 multihoming practices should be supported by an IPv6 multihoming architecture.
現在のIPv4のマルチホーミング慣行の次の機能は、IPv6マルチホーミングアーキテクチャによってサポートされる必要があります。
By multihoming, a site should be able to insulate itself from certain failure modes within one or more transit providers, as well as failures in the network providing interconnection among one or more transit providers.
マルチホーミングにより、サイトは、一つ以上のトランジット・プロバイダ内の特定の故障モードから自身を隔離、並びにネットワークの障害が1つ以上のトランジット・プロバイダ間で相互接続を提供することができなければなりません。
Infrastructural commonalities below the IP layer may result in connectivity which is apparently diverse, sharing single points of failure. For example, two separate DS3 circuits ordered from different suppliers and connecting a site to independent transit providers may share a single conduit from the street into a building; in this case, physical disruption (sometimes referred to as "backhoe-fade") of both circuits may be experienced due to a single incident in the street. The two circuits are said to "share fate".
IP層の下のインフラ共通は、単一障害点を共有し、明らかに多様である接続性をもたらすことができます。例えば、二つの別々のDS3回路異なる供給元から注文し、独立したトランジットプロバイダにサイトを接続は、建物に通りから単一の導管を共有することができます。この場合には、両方の回路の物理的破壊は、（時には「バックホウフェード」と呼ぶ）による通りに単一のインシデントに経験することができます。二つの回路は、「共有運命」と言われています。
The multihoming architecture should accommodate (in the general case, issues of shared fate notwithstanding) continuity of connectivity during the following failures:
マルチホーミングアーキテクチャは（一般的な場合にもかかわらず、共有運命の問題）は、以下の障害の間の接続の連続性に対応すべきです。
o Physical failure, such as a fiber cut, or router failure,
物理的な障害O、そのようなファイバの切断、またはルータの障害など、
o Logical link failure, such as a misbehaving router interface,
Oなどの動作不良ルータインターフェイスなどの論理リンク障害、
o Routing protocol failure, such as a BGP peer reset,
そのようなBGPピアリセットとしてOルーティングプロトコルの失敗、
o Transit provider failure, such as a backbone-wide IGP failure, and
Oトランジットプロバイダーなどのバックボーン全体のIGP障害などの障害や、
o Exchange failure, such as a BGP reset on an inter-provider peering.
O BGPなどの取引の失敗は、インタープロバイダのピアリングにリセットします。
By multihoming, a site should be able to distribute both inbound and outbound traffic between multiple transit providers. This goal is for concurrent use of the multiple transit providers, not just the usage of one provider over one interval of time and another provider over a different interval.
マルチホーミングでは、サイトには、複数のトランジットプロバイダ間でインバウンドとアウトバウンドの両方のトラフィックを分散することができるはずです。この目標は、複数のトランジットプロバイダの同時使用、1時間の間隔と異なる間隔で別のプロバイダを超える1つのプロバイダだけではなく使用するためです。
By multihoming, a site should be able to protect itself from performance difficulties directly between the site's transit providers.
マルチホーミングでは、サイトには、直接サイトのトランジットプロバイダーの間でパフォーマンスの難しさから自身を保護することができるはずです。
For example, suppose site E obtains transit from transit providers T1 and T2, and there is long-term congestion between T1 and T2. The multihoming architecture should allow E to ensure that in normal operation, none of its traffic is carried over the congested interconnection T1-T2. The process by which this is achieved should be a manual one.
例えば、仮定するサイトEはトランジットプロバイダーのT1およびT2からのトランジットを取得し、T1とT2との間に長期的な輻輳があります。マルチホーミングアーキテクチャは、Eが正常に動作して、そのトラフィックのいずれも混雑配線T1-T2を介して搬送されていないことを確認することを可能にするべきです。これが達成される過程は、手動ものでなければなりません。
A multihomed site should be able to distribute inbound traffic from particular multiple transit providers according to the particular address range within their site which is sourcing or sinking the traffic.
マルチホームサイトは、調達やトラフィックを沈没されて自分のサイト内の特定のアドレス範囲に応じて、特定の複数のトランジットプロバイダからのインバウンドトラフィックを分散することができるはずです。
A customer may choose to multihome for a variety of policy reasons beyond technical scope (e.g., cost, acceptable use conditions, etc.) For example, customer C homed to ISP A may wish to shift traffic of a certain class or application, NNTP, for example, to ISP B as matter of policy. A new IPv6 multihoming proposal should provide support for site-multihoming for external policy reasons.
顧客は、例えば技術的範囲（例えば、コスト、許容可能な使用条件など）を超えた政策の様々な理由のためにマルチホームすることを選択でき、顧客Cは、ISP Aにホーミング特定のクラスまたはアプリケーションのトラフィックをシフトしたい場合があり、NNTP、例えば、ISP Bへの政策の問題として。新しいIPv6マルチホーミングの提案は、外部ポリシー上の理由から、サイトマルチホーミングのサポートを提供する必要があります。
As any proposed multihoming solution must be deployed in real networks with real customers, simplicity is paramount. The current multihoming solution is quite straightforward to deploy and maintain.
任意の提案マルチホーミングソリューションは、実際の顧客との実際のネットワークで展開されなければならないとして、シンプルさが最も重要です。現在のマルチホーミングソリューションを展開し、維持するのは非常に簡単です。
A new IPv6 multihoming solution should not be substantially more complex to deploy and operate (for multihomed sites or for the rest of the Internet) than current IPv4 multihoming practices.
新しいIPv6マルチホーミングソリューションは、現在のIPv4のマルチホーミング慣行よりも（マルチホームのサイトまたはインターネットの残りのために）を展開して動作させるために、実質的に、より複雑であってはなりません。
Multihoming solutions should provide re-homing transparency for transport-layer sessions; i.e., exchange of data between devices on the multihomed site and devices elsewhere on the Internet may proceed with no greater interruption than that associated with the transient packet loss during the re-homing event.
マルチホーミングソリューションは、トランスポート層セッションの再ホーミング透明性を提供する必要があります。即ち、インターネット上の他の場所でマルチホームサイトとデバイス上のデバイス間のデータ交換は、再ホーミングイベント中過渡パケット損失に関連付けられているものよりも大きくない中断を進めることができます。
New transport-layer sessions should be able to be created following a re-homing event.
新しいトランスポート層セッションは、再ホーミングイベント以下に作成することができなければなりません。
Transport-layer sessions include those involving transport-layer protocols such as TCP, UDP and SCTP over IP. Applications which communicate over raw IP and other network-layer protocols may also enjoy re-homing transparency.
トランスポート層セッションは、IP上、このようなTCP、UDPおよびSCTPなどのトランスポート層プロトコルが関与するものが含まれます。生のIPおよび他のネットワーク層プロトコルを介して通信するアプリケーションも再ホーミング透明性を楽しむことができます。
Multi-homing solutions either should be compatible with the observed dynamics of the current DNS system, or the solutions should demonstrate that the modified name resolution system required to support them is readily deployable.
マルチホーミングソリューションは、現在のDNSシステムの観察ダイナミクス、または溶液と適合性でなければならないのいずれかで、それらをサポートするために必要な改変名前解決システムが容易に展開可能であることを証明すべきです。
Multihoming solutions should not preclude filtering packets with forged or otherwise inappropriate source IP addresses at the administrative boundary of the multihomed site, or at the administrative boundaries of any site in the Internet.
マルチホーミングソリューションは、マルチホームサイトの管理境界で、またはインターネットで任意のサイトの管理境界で鍛造またはその他の不適切な送信元IPアドレスを持つパケットをフィルタリング排除するべきではありません。
Current IPV4 multihoming practices contribute to the significant growth currently observed in the state held in the global inter-provider routing system; this is a concern, both because of the hardware requirements it imposes, and also because of the impact on the stability of the routing system. This issue is discussed in great detail in [6].
現在のIPv4のマルチホーミングの実践は、現在、世界的なプロバイダー間のルーティングシステムで開催された状態で観察された大幅な成長に貢献します。これは、両方のために、それは、またために、ルーティングシステムの安定性に影響を課すハードウェア要件の関心事です。この問題は、[6]に非常に詳細に説明されています。
A new IPv6 multihoming architecture should scale to accommodate orders of magnitude more multihomed sites without imposing unreasonable requirements on the routing system.
新しいIPv6マルチホーミングアーキテクチャは、ルーティングシステムに不当な要求を課すことなく大きさよりマルチホームのサイトの受注に対応するために拡張する必要があります。
The solutions may require changes to IPv6 router implementations, but these changes should be either minor, or in the form of logically separate functions added to existing functions.
ソリューションは、IPv6ルータの実装への変更を必要とするかもしれないが、これらの変更は、マイナー、または既存の機能に追加し、論理的に別々の機能の形態のいずれかでなければなりません。
Such changes should not prevent normal single-homed operation, and routers implementing these changes should be able to interoperate fully with hosts and routers not implementing them.
このような変化は、通常のシングルホーム動作を妨げるべきではない、とこれらの変更を実装するルータは、それらを実装していないホストとルータと完全に相互運用することができるはずです。
The solution should not destroy IPv6 connectivity for a legacy host implementing RFC 3513 [3], RFC 2460 [4], RFC 3493 [5], and other basic IPv6 specifications current in April 2003. That is to say, if a host can work in a single-homed site, it should still be able to work in a multihomed site, even if it cannot benefit from site-multihoming.
ソリューションは、RFC 3513を実装するレガシーホストのIPv6接続を破壊してはならない[3]、RFC 2460 [4]、RFC 3493 [5]、およびホストが働くことができれば、と言うことです2003年4月中の他の基本的なIPv6の仕様電流シングルホームサイトでは、まだそれがサイトマルチホーミングの恩恵を受けることができない場合でも、マルチホームのサイトで作業することができるはずです。
It would be compatible with this goal for such a host to lose connectivity if a site lost connectivity to one transit provider, despite the fact that other transit provider connections were still operational.
サイトには、他のトランジットプロバイダーの接続がまだ動作したという事実にもかかわらず、1つのトランジットプロバイダーへの接続を失った場合には、そのようなホストが接続を失うことは、この目標と互換性があるでしょう。
If the solution requires changes to the host stack, these changes should be either minor, or in the form of logically separate functions added to existing functions.
ソリューションは、ホストスタックへの変更を必要とする場合、これらの変更は、マイナー、または既存の機能に追加し、論理的に別々の機能の形態のいずれかでなければなりません。
If the solution requires changes to the socket API and/or the transport layer, it should be possible to retain the original socket API and transport protocols in parallel, even if they cannot benefit from multihoming.
解決策は、ソケットAPIおよび/またはトランスポート層への変更を必要とする場合、彼らがマルチホーミングの恩恵を受けることができない場合でも、並行して、元のソケットAPIおよび輸送プロトコルを保持することが可能でなければなりません。
The multihoming solution may allow host or application changes if that would enhance transport-layer survivability.
それは、トランスポート層の存続を高めるであろう場合マルチホーミングソリューションは、ホストやアプリケーションの変更を可能にすることができます。
The solution may involve interaction between a site's hosts and its routing system; such an interaction should be simple, scalable and securable.
ソリューションは、サイトのホストおよびそのルーティングシステム間の相互作用を伴うこと。このような相互作用は、簡単なスケーラブルかつ固定可能なはずです。
It should be possible for staff responsible for the operation of a site to monitor and configure the site's multihoming system.
これは、スタッフのために、サイトのマルチホーミングシステムを監視し、設定するサイトの運営を担当することが可能なはずです。
A multihoming strategy may require cooperation between a site and its transit providers, but should not require cooperation (relating specifically to the multihomed site) directly between the transit providers.
マルチホーミング戦略は、サイトとそのトランジットプロバイダ間の協力を必要とするかもしれないが、直接トランジットプロバイダ間（マルチホームサイトに特異的に関連する）の協力を必要とすべきではありません。
The impact of any inter-site cooperation that might be required to facilitate the multihoming solution should be examined and assessed from the point of view of operational practicality.
マルチホーミング溶液を容易にするために必要とされる可能性のあるサイト間の協力の影響を調べ、動作実用性の観点から評価されるべきです。
There may be more than one approach to multihoming, provided all approaches are orthogonal (i.e., each approach addresses a distinct segment or category within the site multihoming problem). Multiple solutions will incur a greater management overhead, however, and the adopted solutions should attempt to cover as many multihoming scenarios and goals as possible.
すべてのアプローチは、（すなわち、各アプローチがサイトマルチホーミングの問題内の別個のセグメントまたはカテゴリに対処する）直交して設けられ、マルチホーミングへの複数のアプローチが存在してもよいです。複数の解決策は、しかし、より大きな管理オーバーヘッドが発生し、採用ソリューションは、できるだけ多くのマルチホーミングシナリオと目標をカバーしようとしなければなりません。
A multihomed site should not be more vulnerable to security breaches than a traditionally IPv4-multihomed site.
マルチホームサイトは、伝統的にはIPv4-マルチホームサイトよりセキュリティ侵害に対して脆弱ではありません。
Any changes to routing practices made to accommodate multihomed sites should not cause non-multihomed sites to become more vulnerable to security breaches.
マルチホームのサイトに対応するために作られたルーティング慣行への変更は、非マルチホームのサイトはセキュリティ侵害に対してより脆弱になることを引き起こすことはありません。
The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat.
IETFは、そのような権限下で、ライセンスがたりないかもしれない可能性があるためにどの本書または程度に記載されている技術の実装や使用に関係すると主張される可能性があります任意の知的財産やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能。また、そうした権利を特定するために取り組んできたことを表していないん。スタンダードトラックおよび標準関連文書における権利に関するIETFの手続きの情報は、BCP-11に記載されています。権利の主張のコピーは、出版のために利用可能とライセンスの保証が利用できるようにする、または本仕様の実装者または利用者が、そのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますIETF事務局から。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFは、その注意にこの標準を実践するために必要な場合があり技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 IETF専務に情報を扱ってください。
[1] Fuller, V., Li, T., Yu, J. and K. Varadhan, "Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy", RFC 1519, September 1993.
[1]フラー、V.、李、T.、ゆう、J.及びK. Varadhan、 "クラスレスドメイン間ルーティング（CIDR）：アドレス割り当ておよび集約戦略"、RFC 1519、1993年9月。
[2] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[2] Rekhter、Y.、モスコウィッツ、B.、Karrenberg、D.、デ・グルート、G.、およびE.リア、BCP 5、RFC 1918、1996年2月、 "個人的なインターネットのための配分"。
[3] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003.
[3] HindenとR.とS.デアリング、 "インターネットプロトコルバージョン6（IPv6）のアドレス指定アーキテクチャ"、RFC 3513、2003年4月。
[4] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[4]デアリング、S.とR. Hindenと "インターネットプロトコル、バージョン6（IPv6）の仕様"、RFC 2460、1998年12月。
[5] Gilligan, R., Thomson, S., Bound, J., McCann, J. and W. Stevens, "Basic Socket Interface Extensions for IPv6", RFC 3493, February 2003.
[5]ギリガン、R.、トムソン、S.、バウンド、J.、マッキャン、J.とW.スティーブンス、 "IPv6の基本的なソケットインタフェース拡張"、RFC 3493、2003年2月。
[6] Huston, G., "Commentary on Inter-Domain Routing in the Internet", RFC 3221, December 2001.
[6]ヒューストン、G.、 "インターネットにおけるドメイン間ルーティングの解説"、RFC 3221、2001年12月。
Joe Abley Internet Software Consortium 950 Charter Street Redwood City, CA 94063 USA
ジョーAbleyインターネットSoftware Consortiumの950憲章通りカリフォルニア州レッドウッドシティー94063 USA
Phone: +1 650 423 1317 EMail: jabley@isc.org
電話：+1 650 423 1317 Eメール：jabley@isc.org
Benjamin Black Layer8 Networks
ベンジャミン・ブラックLayer8ネットワーク
EMail: ben@layer8.net
メールアドレス：ben@layer8.net
Vijay Gill AOL Time Warner
ビジェイ・ギルAOLタイム・ワーナー
EMail: vijaygill9@aol.com
メールアドレス：vijaygill9@aol.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.
上記の制限は永続的なものであり、インターネットソサエティもしくはその継承者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。