[要約] RFC 3582は、IPv6サイトマルチホーミングアーキテクチャの目標を定義しています。要約すると、IPv6サイトマルチホーミングの目的は、ネットワークの可用性、負荷分散、およびアドレス空間の効率的な利用を実現することです。
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
IPv6サイトマルチホームアーキテクチャの目標
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.
Copyright（c）The Internet Society（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.
「Transit Provider」は、1つ以上の外部サイトへのインターネットへの接続を直接提供するサイトを運営しています。提供された接続は、トランジットプロバイダー自身のサイトを超えています。トランジットプロバイダーのサイトは、トランジットを提供するサイトに直接接続されています。
A "multihomed" site is one with more than one transit provider. "Site-multihoming" is the practice of arranging a site to be multihomed.
「マルチホーム」サイトは、複数のトランジットプロバイダーを持つものです。「サイトマルチホミング」は、マルチホームのサイトを配置する慣行です。
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レイヤーの下のインフラストラクチャの共通性により、接続性が発生する可能性があり、これは明らかに多様であり、単一の障害点を共有します。たとえば、異なるサプライヤーから注文し、サイトを独立した輸送プロバイダーに接続する2つの別々のDS3サーキットは、通りから単一の導管を建物に共有する場合があります。この場合、両方の回路の物理的な混乱（「バックホーフデ」と呼ばれることもあります）は、路上での単一の事件のために経験される場合があります。2つのサーキットは「運命を共有する」と言われています。
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,
o BGPピアリセットなどのルーティングプロトコル障害、
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 Provider間のピアリングで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つのプロバイダーと別のプロバイダーが異なる間隔で使用するだけでなく、複数のトランジットプロバイダーを同時に使用することです。
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.
顧客は、技術的範囲（コスト、受け入れ可能な使用条件など）を超えてさまざまな政策上の理由でマルチホームを選択することができます。たとえば、ポリシーの問題として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 [3]、RFC 2460 [4]、RFC 3493 [5]、および2003年4月に現在のその他の基本的なIPv6仕様を実装するレガシーホストの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] Fuller、V.、Li、T.、Yu、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.、Moskowitz、B.、Karrenberg、D.、de Groot、G。and E. Lear、「Private Internetsのアドレス割り当て」、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。and S. Deering、「インターネットプロトコルバージョン6（IPv6）アドレス指定アーキテクチャ」、RFC 3513、2003年4月。
[4] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[4] Deering、S。and 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] Gilligan、R.、Thomson、S.、Bound、J.、McCann、J。、およびW. Stevens、「IPv6用の基本ソケットインターフェイス拡張」、RFC 3493、2003年2月。
[6] Huston, G., "Commentary on Inter-Domain Routing in the Internet", RFC 3221, December 2001.
[6] Huston、G。、「インターネット内のドメイン間ルーティングに関する解説」、RFC 3221、2001年12月。
Joe Abley Internet Software Consortium 950 Charter Street Redwood City, CA 94063 USA
Joeabley Internet Software Consortium 950 Charter Street Redwood City、CA 94063 USA
Phone: +1 650 423 1317
EMail: jabley@isc.org
Benjamin Black Layer8 Networks
ベンジャミンブラックレイヤー8ネットワーク
EMail: ben@layer8.net
Vijay Gill AOL Time Warner
Vijay Gill Aol Time Warner
EMail: vijaygill9@aol.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。