[要約] 要約：RFC 4116は、IPv4マルチホーミングの実践と制限に関するガイドラインです。IPv4ネットワークのマルチホーミングの実装における問題や制約について説明しています。目的：このRFCの目的は、IPv4ネットワークのマルチホーミングを実装する際に生じる問題や制約を理解し、効果的な実践を促進することです。
Network Working Group J. Abley
Request for Comments: 4116 ISC
Category: Informational K. Lindqvist
Netnod Internet Exchange
E. Davies
Independent Researcher
B. Black
Layer8 Networks
V. Gill
AOL
July 2005
IPv4 Multihoming Practices and Limitations
IPv4マルチホームの実践と制限
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
概要
Multihoming is an essential component of service for many Internet sites. This document describes some implementation strategies for multihoming with IPv4 and enumerates features for comparison with other multihoming proposals (particularly those related to IPv6).
Multihomingは、多くのインターネットサイトにとってサービスの不可欠なコンポーネントです。このドキュメントでは、IPv4を使用したマルチホミングのためのいくつかの実装戦略について説明し、他のマルチホーム提案（特にIPv6に関連するもの）と比較するための機能を列挙します。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................3
3. IPv4 Multihoming Practices ......................................4
3.1. Multihoming with BGP .......................................4
3.1.1. Addressing Considerations ...........................4
3.1.2. AS Number Considerations ............................6
3.2. Multiple Attachments to a Single Transit Provider ..........6
3.3. NAT- or RFC2260-based Multihoming ..........................7
4. Features of IPv4 Multihoming ....................................7
4.1. Redundancy .................................................7
4.2. Load Sharing ...............................................8
4.3. Performance ................................................8
4.4. Policy .....................................................8
4.5. Simplicity .................................................9
4.6. Transport-Layer Survivability ..............................9
4.7. Impact on DNS ..............................................9
4.8. Packet Filtering ...........................................9
4.9. Scalability ................................................9
4.10. Impact on Routers ........................................10
4.11. Impact on Hosts ..........................................10
4.12. Interactions between Hosts and the Routing System ........10
4.13. Operations and Management ................................10
4.14. Cooperation between Transit Providers ....................10
5. Security Considerations ........................................10
6. Acknowledgements ...............................................10
7. Informative References .........................................11
Multihoming is an important component of service for many Internet sites. Current IPv4 multihoming practices have been added on to the Classless Inter Domain Routing (CIDR) architecture [RFC1519], which assumes that routing table entries can be aggregated based upon a hierarchy of customers and service providers.
Multihomingは、多くのインターネットサイトにとってサービスの重要なコンポーネントです。現在のIPv4マルチホームプラクティスは、クラスレスインタードメインルーティング（CIDR）アーキテクチャ[RFC1519]に追加されています。
Multihoming is a mechanism by which sites can satisfy a number of high-level requirements. It is widely used in the IPv4 Internet. There are some practical limitations, however, including concerns as to how it would scale with future Internet growth. This document aims to document common IPv4 multihoming practices and enumerate their features for comparison with other multihoming approaches.
Multihomingは、サイトが多くの高レベルの要件を満たすメカニズムです。IPv4インターネットで広く使用されています。ただし、将来のインターネットの成長にどのように拡大するかに関する懸念など、いくつかの実際的な制限があります。このドキュメントは、一般的なIPv4マルチホームプラクティスを文書化し、他のマルチホームアプローチと比較するために機能を列挙することを目的としています。
There are a number of different ways to route and manage traffic in and out of a multihomed site: the majority rely on the routing policy capabilities of the inter-domain routing protocol, the Border Gateway Protocol, version 4 (BGP) [RFC1771]. This document also discusses a multi-homing strategy which does not rely on the capabilities of BGP.
マルチホームサイトの内外をルーティングおよび管理する方法はさまざまです。過半数は、ドメイン間ルーティングプロトコル、Border Gateway Protocol、バージョン4（BGP）[RFC1771]のルーティングポリシー機能に依存しています。このドキュメントでは、BGPの能力に依存していないマルチホーミング戦略についても説明しています。
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 [RFC1918].
「サイト」とは、IPを使用してネットワークを自律的に操作するエンティティ、特にそのネットワークのアドレス指定計画とルーティングポリシーを決定するエンティティです。この定義は、[RFC1918]で定義されている「エンタープライズ」に相当することを目的としています。
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 and its own direct customer networks. 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つの接続性の状態間のサイトの移行を示します。
A "multi-attached" site has more than one point of layer-3 interconnection to a single transit provider.
「マルチアタッチ」サイトには、単一のトランジットプロバイダーとのレイヤー-3相互接続の複数のポイントがあります。
Provider-Independent (PI) addresses are globally-unique addresses which are not assigned by a transit provider, but are provided by some other organisation, usually a Regional Internet Registry (RIR).
プロバイダーに依存しない（PI）アドレスは、トランジットプロバイダーによって割り当てられていないが、通常は地域のインターネットレジストリ（RIR）である他の組織によって提供されるグローバルに不一致のアドレスです。
Provider-Aggregatable (PA) addresses are globally-unique addresses assigned by a transit provider to a customer. The addresses are considered "aggregatable" because the set of routes corresponding to the PA addresses are usually covered by an aggregate route set corresponding to the address space operated by the transit provider, from which the assignment was made.
Provider-Aggregatable（PA）アドレスは、顧客へのトランジットプロバイダーによって割り当てられたグローバルに不自然なアドレスです。PAアドレスに対応するルートのセットは、通常、トランジットプロバイダーが操作するアドレススペースに対応する集計ルートセットで覆われ、そこから割り当てが行われたため、アドレスは「集約可能」と見なされます。
Note that the words "assign" and "allocate" have specific meanings in Regional Internet Registry (RIR) address management policies, but are used more loosely in this document.
「割り当て」と「割り当て」という単語は、地域のインターネットレジストリ（RIR）アドレス管理ポリシーで特定の意味を持っているが、このドキュメントではよりゆるく使用されていることに注意してください。
The general approach for multihoming with BGP is to announce a set of routes to two or more transit providers. This provides the rest of the Internet with multiple paths back to the multihomed sites, and each transit provider provides an additional possible path for the site's outbound traffic.
BGPを使用したマルチホミングの一般的なアプローチは、2つ以上のトランジットプロバイダーへのルートのセットを発表することです。これにより、残りのインターネットに複数のパスがマルチホームサイトに戻ることができ、各トランジットプロバイダーは、サイトのアウトバウンドトラフィックに追加の可能なパスを提供します。
The site uses PI addresses, and a set of routes covering those PI addresses is announced or propagated by two or more transit providers.
サイトはPIアドレスを使用し、これらのPIアドレスをカバーするルートのセットが2つ以上のトランジットプロバイダーによって発表または伝播されます。
Using PI addresses has long been the preferred approach for IPv4 multihoming. Until the mid-1990s this was relatively easy to accomplish, as the maximum generally accepted prefix length in the global routing table was a /24, and little justification was needed to obtain a /24 PI assignment. Since then, RIR address management policies have become less liberal in this respect. Not all RIRs support the assignment of address blocks to small, multihomed end-users, and those that do support it require justification for blocks as large as a /24, which cannot be met by small sites. As a consequence, PI addresses are not available to many sites who wish to multihome.
PIアドレスを使用することは、長い間IPv4マルチホミングに好ましいアプローチでした。1990年代半ばまで、これは比較的簡単に達成できました。グローバルルーティングテーブルで一般的に受け入れられている最大プレフィックス長はA /24であり、A /24 PI割り当てを取得するためにはほとんど正当化されなかったためです。それ以来、RIRは、この点で管理ポリシーがリベラルではなくなっています。すべてのRIRSが、小規模でマルチホームのエンドユーザーへのアドレスブロックの割り当てをサポートするわけではなく、それをサポートするものは、小さなサイトでは満たすことができないA /24と同じ大きさのブロックの正当化を必要とします。結果として、Multihomeを希望する多くのサイトではPIアドレスは利用できません。
Each site that uses PI addresses introduces an additional prefix into the global routing system. If this scheme for multihoming became widespread, it would present scaling concerns.
PIアドレスを使用する各サイトは、グローバルルーティングシステムに追加のプレフィックスを導入します。マルチホミングのためのこのスキームが広く普及した場合、スケーリングの懸念を提示します。
The site uses PA addresses assigned by a single transit provider. The set of routes covering those PA addresses (the "site route set") is announced or propagated by one or more additional transit providers. The transit provider which assigned the PA addresses (the "primary transit provider") originates a set of routes which cover the site route set. The primary transit provider often originates or propagates the site route set as well as the covering aggregates.
サイトは、単一のトランジットプロバイダーによって割り当てられたPAアドレスを使用します。これらのPAアドレス（「サイトルートセット」）をカバーするルートのセットは、1つ以上の追加の輸送プロバイダーによって発表または伝播されます。PAアドレス（「プライマリトランジットプロバイダー」）を割り当てたトランジットプロバイダーは、サイトルートセットをカバーする一連のルートを発信します。プライマリトランジットプロバイダーは、多くの場合、サイトルートセットとカバー集合体を発信または伝播します。
The use of PA addresses is applicable to sites whose addressing requirements are not sufficient to meet the requirements for PI assignments by RIRs. However, in the case where the site route set is to be announced or propagated by two or more different transit providers, common operational practice still dictates minimum /24 prefixes, which may be larger than the allocation available to small sites.
PAアドレスの使用は、RIRSによるPI割り当ての要件を満たすのに十分なアドレス指定要件であるサイトに適用できます。ただし、サイトルートセットが2つ以上の異なるトランジットプロバイダーによって発表または伝播される場合、一般的な運用慣行は依然として最小 /24のプレフィックスを決定します。これは、小さなサイトで利用可能な割り当てよりも大きい場合があります。
There have been well-documented examples of sites filtering long-prefix routes which are covered by a transit-providers aggregate. If this practice were to become very widespread, it might limit the effectiveness of multihoming using PA addresses. However, limited filtering of this kind can be tolerated because the aggregate announcements of the primary transit provider should be sufficient to attract traffic from autonomous systems which do not accept the covered site route set. The more traffic that follows the primary transit provider's aggregate in the absence of the covered, more-specific route, the greater the reliance on that primary transit provider. In some cases, this reliance might result in an effective single point of failure.
トランジットプロビダーの集合体でカバーされているロングプレフィックスルートをフィルタリングするサイトのよく文書化された例があります。このプラクティスが非常に広く普及した場合、PAアドレスを使用してマルチホームの有効性を制限する可能性があります。ただし、この種の限られたフィルタリングは、プライマリトランジットプロバイダーの総合的な発表で、対象のサイトルートセットを受け入れない自律システムからトラフィックを引き付けるのに十分であるため、容認できます。対象で特異的なルートがない場合に一次輸送プロバイダーの総計に続くトラフィックが多いほど、その一次輸送プロバイダーへの依存が大きくなります。場合によっては、この依存は効果的な単一の故障につながる可能性があります。
Traffic following the primary transit provider's aggregate routes may still be able to reach the multihomed site, even in the case where the connection between the primary transit provider and the site has failed. The site route set will still be propagating through the site's other transit providers. If that route set reaches (and is accepted by) the primary transit provider, connectivity for traffic following the aggregate route will be preserved.
一次輸送プロバイダーの集合ルートに続くトラフィックは、プライマリトランジットプロバイダーとサイトの接続が失敗した場合でも、マルチホームサイトに到達できる可能性があります。サイトルートセットは、サイトの他のトランジットプロバイダーを通じて引き続き伝播します。そのルートセットがプライマリトランジットプロバイダーに到達する（および受け入れられる）場合、集約ルートに続くトラフィックの接続性が保持されます。
Sites that use PA addresses are usually obliged to renumber if they decide not to retain connectivity to the primary transit provider. While this is a common requirement for all sites using PA addresses (and not just those that are multihomed), it is one that may have more frequent impact on sites whose motivation to multihome is to facilitate changes of ISP. A multihomed site using PA addresses can still add or drop other service providers without having to renumber.
PAアドレスを使用するサイトは、通常、プライマリトランジットプロバイダーへの接続性を保持しないことを決定した場合、Numberを変更する義務があります。これは、PAアドレスを使用しているすべてのサイト（マルチホームのものだけでなく）を使用するすべてのサイトの一般的な要件ですが、Multihomeへの動機がISPの変化を促進することであるサイトにより頻繁に影響を与える可能性があります。PAアドレスを使用したマルチホームサイトでは、変更を受けることなく他のサービスプロバイダーを追加またはドロップできます。
A multihomed site may choose to announce routes to two or more transit providers from a globally-unique Autonomous System (AS) number assigned to the site. This causes the origin of the route to appear consistent when viewed from all parts of the Internet.
マルチホームサイトは、サイトに割り当てられたグローバルにない自律システム（AS）番号から2つ以上の輸送プロバイダーへのルートを発表することを選択できます。これにより、インターネットのすべての部分から表示されると、ルートの起源が一貫しているように見えます。
A multihomed site may choose to use a private-use AS number [RFC1930] to originate routes to transit providers. It is normal practice for private-use AS numbers to be stripped from AS_PATH attributes before they are allowed to propagate from transit providers towards peers. Therefore, routes observed from other parts of the Internet may appear to have inconsistent origins.
マルチホームサイトは、プライベート使用を数[RFC1930]として使用して、プロバイダーへのルートを発信することを選択できます。輸送プロバイダーからピアに向かって伝播することが許可される前に、AS_PATH属性から数字を削除するため、個人使用のための通常の慣行です。したがって、インターネットの他の部分から観察されるルートは、一貫性のない起源を持っているように見える場合があります。
When using private-use AS numbers, collisions between the use of individual numbers by different transit providers are possible. These collisions are arguably best avoided by not using private-use AS numbers for applications which involve routing across administrative domain boundaries.
プライベート使用を数字として使用する場合、異なる輸送プロバイダーによる個々の数値の使用間の衝突が可能です。これらの衝突は、管理ドメインの境界を越えてルーティングを伴うアプリケーションの数値として個人使用を使用しないことで、間違いなく回避されます。
A multihomed site may request that their transit providers each originate the site's routes from the transit providers' ASes. Dynamic routing (for the purposes of withdrawing the site's route in the event that connectivity to the site is lost) is still possible, in this case, using the transit providers' internal routing systems to trigger the externally-visible announcements.
マルチホームサイトは、輸送プロバイダーがそれぞれ輸送プロバイダーのASEからサイトのルートを発信することを要求する場合があります。動的ルーティング（サイトへの接続性が失われた場合のサイトのルートを撤回する目的で）、この場合、トランジットプロバイダーの内部ルーティングシステムを使用して、外部からの発表をトリガーすることが依然として可能です。
Operational troubleshooting is facilitated by the use of a consistent origin AS. This allows import policies to be based on a route's true origin rather than on intermediate routing details, which may change (e.g., as transit providers are added and dropped by the multihomed site).
運用上のトラブルシューティングは、一貫した起源を使用することにより促進されます。これにより、インポートポリシーは、変化する可能性のある中間ルーティングの詳細ではなく、ルートの真の起源に基づくことができます（たとえば、トランジットプロバイダーがマルチホームサイトによって追加およびドロップされるため）。
Multihoming can be achieved through multiple connections to a single transit provider. This imposes no additional load on the global routing table beyond that involved in the site being single-attached. A site that has solved its multihoming needs in this way is commonly referred to as "multi-attached".
マルチホームは、単一のトランジットプロバイダーへの複数の接続を通じて実現できます。これにより、グローバルルーティングテーブルに追加の負荷が課されません。このようにマルチホームのニーズを解決したサイトは、一般に「マルチアタッチ」と呼ばれます。
It is not a requirement that the multi-attached site exchange routing information with its transit provider using BGP. However, in the event of failure, some mechanism for re-routing inbound and outbound traffic over remaining circuits is required. BGP is often used for this purpose.
BGPを使用した交通機関プロバイダーとのマルチアタッチのサイト交換情報が情報を交換することは要件ではありません。ただし、障害が発生した場合、残りの回路上のインバウンドトラフィックとアウトバウンドトラフィックを再ルーティングするメカニズムが必要です。BGPは、この目的のためによく使用されます。
Multi-attached sites gain no advantages from using PI addresses or (where BGP is used) globally-unique AS numbers, and have no need to be able to justify address assignments of a particular minimum size. However, multi-attachment does not protect a site from the failure of the single transit provider.
多目的サイトは、PIアドレスを使用することから、または（BGPが使用されている場合）グローバルに数字として利点を得ることができず、特定の最小サイズのアドレス割り当てを正当化する必要はありません。ただし、マルチアタッチメントは、単一の輸送プロバイダーの障害からサイトを保護しません。
This method uses PA addresses assigned by each transit provider to which the site is connected. The addresses are either allocated to individual hosts within the network according to [RFC2260], or the site uses Network Address Translation (NAT) to translate the various provider addresses into a single set of private-use addresses [RFC1918] within the site. The site is effectively singlehomed to more than one transit provider. None of the transit providers need to make any accommodations beyond those typically made for a non-multihomed customer.
この方法では、サイトが接続されている各トランジットプロバイダーによって割り当てられたPAアドレスを使用します。アドレスは、[RFC2260]に従ってネットワーク内の個々のホストに割り当てられ、サイトはネットワークアドレス変換（NAT）を使用して、サイト内のさまざまなプロバイダーアドレスを単一のプライベートアドレス[RFC1918]のセットに変換します。このサイトは、複数のトランジットプロバイダーに効果的に独身になっています。輸送プロバイダーはいずれも、通常、熟成されていない顧客のために作られたものを超えて宿泊施設を作る必要はありません。
This approach accommodates a wide range of sites, from residential Internet users to very large enterprises, requires no PI addresses or AS numbers, and imposes no additional load on the Internet's global routing system. However, it does not address several common motivations for multihoming, most notably transport-layer survivability.
このアプローチは、住宅のインターネットユーザーから非常に大規模な企業まで、幅広いサイトに対応し、PIアドレスや数字としては必要ありません。また、インターネットのグローバルルーティングシステムに追加の負荷を課しません。ただし、マルチホーム、特に輸送層の生存性については、いくつかの一般的な動機に対処していません。
The following sections describe some of the features of the approaches described in Section 3, in the context of the general goals for multihoming architectures presented in [RFC3582]. Detailed descriptions and rationale for these goals can be found in that document.
次のセクションでは、[RFC3582]に示されている多語のアーキテクチャの一般的な目標の文脈で、セクション3で説明されているアプローチの特徴のいくつかについて説明します。これらの目標の詳細な説明と根拠は、その文書に記載されています。
All the methods described provide redundancy, which can protect a site from some single-point failures. The degree of protection depends on the choice of transit providers and the methods used to interconnect the site to those transit providers.
説明されているすべての方法は、いくつかの単一点障害からサイトを保護できる冗長性を提供します。保護の程度は、トランジットプロバイダーの選択と、サイトをそれらのトランジットプロバイダーと相互接続するために使用される方法に依存します。
All of the methods described provide some measure of load-sharing capability. Outbound traffic can be shared across ISPs using appropriate exit selection policies; inbound traffic can be distributed using appropriate export policies designed to influence the exit selection of remote sites sending traffic back towards the multihomed site.
説明されているすべての方法は、荷重共有機能の尺度を提供します。アウトバウンドトラフィックは、適切な出口選択ポリシーを使用してISP間で共有できます。インバウンドトラフィックは、マルチホームサイトにトラフィックを送信するリモートサイトの出口選択に影響を与えるように設計された適切なエクスポートポリシーを使用して配布できます。
In the case of RFC2260/NAT multihoming, distribution of inbound traffic is controlled by address selection on the host or NAT.
RFC2260/NATマルチホームの場合、インバウンドトラフィックの分布は、ホストまたはNATのアドレス選択によって制御されます。
BGP-speaking sites can employ import policies that cause exit selection to avoid paths known to be problematic. For inbound traffic, sites can often employ route export policy, which affords different treatment of traffic towards particular address ranges within their network.
BGPを話すサイトは、問題があることが知られているパスを回避するために、出口選択を引き起こすインポートポリシーを採用できます。インバウンドトラフィックの場合、サイトは多くの場合、ルートエクスポートポリシーを採用できます。これにより、ネットワーク内の特定のアドレス範囲に向けてトラフィックのさまざまな処理が可能になります。
It should be noted that this is not a comprehensive capability. In general, there are many traffic engineering goals which can only be loosely approximated using this approach.
これは包括的な機能ではないことに注意する必要があります。一般に、このアプローチを使用してしかゆるく近似できない多くの交通工学の目標があります。
In the case of RFC2260/NAT multihoming in the absence of BGP routing information, management of outbound traffic is not possible. The path taken by inbound traffic for a particular session can be controlled by source address selection on the host or NAT.
BGPルーティング情報がない場合、RFC2260/NATマルチホームの場合、アウトバウンドトラフィックの管理は不可能です。特定のセッションのインバウンドトラフィックがとるパスは、ホストまたはNATのソースアドレス選択によって制御できます。
In some circumstances, it is possible to route traffic of a particular type (e.g., protocol) via particular transit providers. This can be done if the devices in the site which source or sink that traffic can be isolated to a set of addresses to which a special export policy can be applied.
状況によっては、特定のタイプ（プロトコルなど）のトラフィックを特定の輸送プロバイダーを介してルーティングすることができます。これは、特別なエクスポートポリシーを適用できるアドレスのセットにトラフィックを分離できるサイトをソースまたはシンクするサイト内のデバイスが適用できる場合に行うことができます。
An example of this capability is the grouping of budget, best-effort Internet customers into a particular range of addresses that is covered by a route which is announced preferentially over a single, low-quality transit path.
この機能の例は、予算のグループ化、ベストエフォルトのインターネット顧客のグループ化が、単一の低品質のトランジットパスで優先的に発表されるルートでカバーされる特定の範囲のアドレスへのグループです。
In the case of RFC2260/NAT multihoming, policies such as those described here can be accommodated by appropriate address selection on the host or NAT. More flexible implementations may be possible for sessions originated from the multihomed site by selecting an appropriate source address on a host or NAT, according to criteria such as transport-layer protocols and addresses (ports).
RFC2260/NATマルチホミングの場合、ここで説明するようなポリシーは、ホストまたはNATの適切なアドレス選択によって対応できます。輸送層プロトコルやアドレス（ポート）などの基準に従って、ホストまたはNATの適切なソースアドレスを選択することにより、マルチホームサイトから発信されるセッションでは、より柔軟な実装が可能になる場合があります。
The current methods used as multihoming solutions are not without their complexities, but have proven to be sufficiently simple to be used. They have the advantage of familiarity due to having been deployed extensively.
マルチホームソリューションとして使用されている現在の方法には、それらに複雑さがないわけではありませんが、使用するのが十分に簡単であることが証明されています。彼らは広範囲に展開されたため、親しみやすさの利点があります。
All BGP-based multihoming practices provide some degree of session survivability for transport-layer protocols. However, in cases where path convergence takes a long time following a re-homing event, sessions may time out.
すべてのBGPベースのマルチホームプラクティスは、輸送層プロトコルにある程度のセッションのサバイバビリティを提供します。ただし、Path Convergenceが再びホーミングイベントの後に長い時間がかかる場合、セッションはタイムアウトする可能性があります。
Transport-layer sessions will not, in general, survive over a re-homing event when using RFC2260/NAT multihoming. Transport protocols which support multiple volatile endpoint addresses may be able to provide session stability; however, these transport protocols are not in wide use.
輸送層セッションは、一般に、RFC2260/NATマルチホミングを使用している場合、再ホミングイベントで生き残ることはありません。複数の揮発性エンドポイントアドレスをサポートする輸送プロトコルは、セッションの安定性を提供できる場合があります。ただし、これらの輸送プロトコルは広く使用されていません。
In all the methods described in this document, new transport-layer sessions are able to be created following a re-homing event.
このドキュメントで説明されているすべての方法で、新しい輸送層セッションは、再びホーミングイベントに続いて作成できます。
These multihoming strategies impose no new requirements on the DNS.
これらのマルチホーム戦略は、DNSに新しい要件を課しません。
These multihoming practices do not preclude filtering of packets with inappropriate source or destination addresses at the administrative boundary of the multihomed site.
これらのマルチホームプラクティスは、マルチホームサイトの管理境界で不適切なソースまたは宛先アドレスを使用したパケットのフィルタリングを排除しません。
Current IPv4 multihoming practices are thought to contribute to significant observed growth in the amount of state held in the global inter-provider routing system. This is a concern because of both the hardware requirements it imposes and the impact on the stability of the routing system. This issue is discussed in greater detail in [RFC3221].
現在のIPv4マルチホームプラクティスは、グローバルなプロバイダールーティングシステムに保持されている状態の量の有意な観察された成長に寄与すると考えられています。これは、それが課すハードウェア要件とルーティングシステムの安定性への影響の両方のために懸念事項です。この問題については、[RFC3221]で詳細に説明します。
Of the methods presented in this document, RFC2260/NAT multihoming and multi-attaching to a single transit provider provide no additional state to be held in the global routing system. All other strategies contribute to routing system state bloat.
このドキュメントに示されている方法のうち、RFC2260/NATマルチホミングと単一のトランジットプロバイダーへのマルチアタッチングは、グローバルルーティングシステムに保持される追加の状態を提供しません。他のすべての戦略は、ルーティングシステムの状態の肥大化に貢献しています。
Globally-unique AS numbers are a finite resource. Thus, widespread multihoming that uses strategies requiring assignment of AS numbers might lead to increased resource contention.
数字が有限のリソースであるため、グローバルにありません。したがって、AS数の割り当てを必要とする戦略を使用する広範なマルチホミングは、リソースの競合の増加につながる可能性があります。
For some of the multihoming approaches described in this document, the routers at the boundary of the multihomed site are required to participate in BGP sessions with transit provider routers. Other routers within the site generally have no special requirements beyond those in singlehomed sites.
このドキュメントで説明されているマルチホームのアプローチのいくつかについては、マルチホームサイトの境界にあるルーターは、トランジットプロバイダールーターとのBGPセッションに参加するために必要です。サイト内の他のルーターには、一般に、単一ホームのサイトにあるもの以外の特別な要件はありません。
There are no requirements of hosts beyond those in singlehomed sites.
シングルホームサイトのホスト以外の要件はありません。
There are no requirements for interaction between routers and hosts beyond those in singlehomed sites.
シングルホームサイトのものを超えて、ルーターとホストの間の相互作用の要件はありません。
There is extensive operational experience in managing IPv4-multihomed sites.
IPv4-Multihomedサイトの管理には、豊富な運用経験があります。
Transit providers who are asked to announce or propagate a PA prefix covered by some other (primary) transit provider usually obtain authorisation first. However, there is no technical requirement or common contractual policy which requires this coordination to take place.
他の（プライマリ）トランジットプロバイダーがカバーしているPAプレフィックスを発表または伝播するように求められたトランジットプロバイダーは、通常、最初に承認を取得します。ただし、この調整を行う必要がある技術的要件や一般的な契約上のポリシーはありません。
This document discusses current IPv4 multihoming practices, but provides no analysis of the security implications of multihoming.
このドキュメントでは、現在のIPv4マルチホームプラクティスについて説明しますが、マルチホームのセキュリティへの影響についての分析は提供していません。
Special acknowledgement goes to John Loughney for proof-reading and corrections. Thanks also goes to Pekka Savola and Iljitsch van Beijnum for providing feedback and contributing text.
校正と修正のために、ジョン・ラフニーに特別な謝辞が与えられます。また、フィードバックを提供し、テキストを提供してくれたPekka SavolaとIljitsch van Beijnumにも感謝します。
This work was supported by the US National Science Foundation (research grant SCI-0427144) and DNS-OARC.
この作業は、米国国立科学財団（研究助成金SCI-0427144）およびDNS-OARCによってサポートされていました。
[RFC1519] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy", RFC 1519, September 1993.
[RFC1519] Fuller、V.、Li、T.、Yu、J。、およびK. Varadhan、「クラスレスインタードメインルーティング（CIDR）：住所割り当てと集約戦略」、1993年9月。
[RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995.
[RFC1771] Rekhter、Y。およびT. Li、「A Border Gateway Protocol 4（BGP-4）」、RFC 1771、1995年3月。
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918] Rekhter、Y.、Moskowitz、R.、Karrenberg、D.、Groot、G。、およびE. Lear、「Private Internetsのアドレス割り当て」、BCP 5、RFC 1918、1996年2月。
[RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation, selection, and registration of an Autonomous System (AS)", BCP 6, RFC 1930, March 1996.
[RFC1930] Hawkinson、J。およびT. Bates、「自律システムの作成、選択、登録に関するガイドライン（AS）」、BCP 6、RFC 1930、1996年3月。
[RFC2260] Bates, T. and Y. Rekhter, "Scalable Support for Multi-homed Multi-provider Connectivity", RFC 2260, January 1998.
[RFC2260] Bates、T。およびY. Rekhter、「マルチホームマルチプロバイダー接続に対するスケーラブルなサポート」、RFC 2260、1998年1月。
[RFC3221] Huston, G., "Commentary on Inter-Domain Routing in the Internet", RFC 3221, December 2001.
[RFC3221] Huston、G。、「インターネット内のドメイン間ルーティングに関する解説」、RFC 3221、2001年12月。
[RFC3582] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site-Multihoming Architectures", RFC 3582, August 2003.
[RFC3582] Eabley、J.、Black、B。、およびV. Gill、「IPv6サイト総構築の目標」、RFC 3582、2003年8月。
Authors' Addresses
著者のアドレス
Joe Abley Internet Systems Consortium, Inc. 950 Charter Street Redwood City, CA 94063 USA
Joeabley Internet Systems Consortium、Inc。950 Charter Street Redwood City、CA 94063 USA
Phone: +1 650 423 1317
EMail: jabley@isc.org
Kurt Erik Lindqvist Netnod Internet Exchange Bellmansgatan 30 Stockholm S-118 47 Sweden
Kurt Erik Lindqvist Netnod Internet Exchange Bellmansgatan 30 Stockholm S-118 47 Sweden
Phone: +46 8 615 85 70
EMail: kurtis@kurtis.pp.se
Elwyn B. Davies Independent Researcher Soham, Cambridgeshire CB7 5AW UK
Elwyn B. Davies Independent Researcher Soham、Cambridgeshire CB7 5AW UK
Phone: +44 7889 488 335
EMail: elwynd@dial.pipex.com
Benjamin Black Layer8 Networks
ベンジャミンブラックレイヤー8ネットワーク
EMail: ben@layer8.net
Vijay Gill AOL 12100 Sunrise Valley Dr Reston, VA 20191 US
Vijay Gill Aol 12100 Sunrise Valley Dr Reston、VA 20191 US
Phone: +1 410 336 4796
EMail: vgill@vijaygill.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エディター機能の資金は現在、インターネット協会によって提供されています。