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
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
Abstract
抽象
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).
マルチホーミングは、多くのインターネットサイトに対するサービスの必須成分です。この文書では、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.
マルチホーミングは、多くのインターネットサイトに対するサービスの重要な要素です。現在の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.
マルチホーミングは、サイトは、高レベルの要件の数を満たすことができる機構です。それは広く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.
そこルートに異なるいくつかの方法があり、中にとマルチホームサイト外のトラフィックを管理する：大半は、ドメイン間ルーティングプロトコルのルーティングポリシー機能に依存して、ボーダーゲートウェイプロトコルバージョン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.
「トランジットプロバイダは、」直接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つの状態の間、サイトの移行を意味します。
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（Regional Internet Registry）が提供されています。
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.
プロバイダ集約（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アドレスをカバーするルートのセットを発表しましたか二つ以上のトランジットプロバイダーによって伝播されます。
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年代半ばまでは、これは、達成するのは比較的簡単だった/ 24だった、と少し正当化は、/ 24 PIの割り当てを得るために必要とされました。それ以来、RIRのアドレス管理ポリシーは、この点ではあまりリベラルとなっています。必ずしもすべてのRIRは、小型、マルチホームエンドユーザー、そしてそれは、小さなサイトでは満たすことができない/ 24ほどの大きなブロックを正当化する理由を、必要とサポートしないものにアドレスブロックの割り当てをサポートしています。その結果、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アドレスの使用は、そのアドレス指定の要件のRIRでPIの割り当てのための要件を満たすのに十分でないサイトに適用されます。しかし、サイトのルートセットが発表されたまたは二つ以上の異なるトランジットプロバイダーによって伝播する場合には、一般的な操作の練習はまだ小さなサイトで利用可能な配分よりも大きくすることができる最小/ 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アドレスを使用するサイトは、通常、彼らは主のトランジットプロバイダーへの接続を保持しないと決めた場合に番号を付け直すことが義務付けられています。これはPAアドレス（およびないマルチホームされているものだけ）を使用して、すべてのサイトのための一般的な要件ですが、それがモチベーションマルチホームにする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）番号からの二つ以上のトランジットプロバイダーへのルートを発表することもできます。これは、インターネットのすべての部分から見たときの経路の起源は一貫現れます。
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-使用を使用することもできます。番号は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.
AS番号私的利用を使用する場合は、別のトランジットプロバイダによる個々の数値の使用との間の衝突が可能です。これらの衝突は、間違いなく最高の管理ドメインの境界を越えてルーティングを必要とするアプリケーションのためのAS番号私的利用を使用しないことによって回避されます。
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.
マルチホームサイトは、彼らのトランジットプロバイダーそれぞれがトランジットプロバイダーののASからサイトのルートを発信することを要求することができます。 （サイトへの接続が失われた場合には、サイトのルートを引き出す目的で）動的ルーティングは外部に見えるアナウンスをトリガするためにトランジットプロバイダーの内部ルーティング・システムを使用して、この場合には、まだ可能です。
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).
運用トラブルシューティングがAS一貫性の起源の使用によって促進されます。これは、インポート・ポリシーは経路の真の起源にはなく（例えば、トランジットプロバイダがマルチホームサイトが追加され、ドロップされる）を変更することができる中間ルーティングの詳細に基づくことを可能にします。
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.
マルチ添付のサイトはAS番号をグローバルにユニーク（BGPが使用されている）PIアドレスまたはを使用してから何の利点を得ることなく、特定の最小サイズのアドレス割り当てを正当化することができるようにする必要がありません。しかし、マルチ添付ファイルは、単一のトランジットプロバイダーの失敗からサイトを保護することはできません。
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]によれば、ネットワーク内の個々のホストに割り当てられているか、またはサイトがサイト内の私的利用アドレス[RFC1918]の単一セットにさまざまなプロバイダのアドレスを変換するネットワークアドレス変換（NAT）を使用します。サイトでは、効果的に、複数のトランジットプロバイダーにsinglehomedされます。トランジットプロバイダーのいずれも、典型的には、非マルチホームの顧客のために作られたもの以外のすべての宿泊施設を作る必要がありません。
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アドレスやAS番号を必要とせず、インターネットのグローバルルーティングシステムに追加の負担を課しません。しかし、それはマルチホーミング、最も顕著なトランスポート層の存続のためのいくつかの一般的な動機に対応していません。
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.
RFC2260の場合は/ NATは、BGPルーティング情報が存在しない場合にマルチホーム、アウトバウンドトラフィックの管理が不可能です。特定のセッションのためのインバウンドトラフィックによって撮影したパスは、ホストまたは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ベースのマルチホーミングの実践は、トランスポート層プロトコルのためのセッションの存続のいくつかの学位を提供しています。しかし、パス収束が再ホーミングイベントを以下の長い時間を要する場合には、セッションがタイムアウトすることがあります。
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は有限な資源です。したがって、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セッションに参加するために必要とされています。サイト内の他のルータは、一般的にsinglehomedサイトのものを超えて特別な要件を持っていません。
There are no requirements of hosts beyond those in singlehomed sites.
singlehomedサイトにおけるものを超えてのホストの要件はありません。
There are no requirements for interaction between routers and hosts beyond those in singlehomed sites.
singlehomedサイトにおけるものを超えてルータとホスト間の相互作用のための要件はありません。
There is extensive operational experience in managing IPv4-multihomed sites.
IPv4の-マルチホームのサイトの管理に豊富な運用経験があります。
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.
特別な承認は、プルーフリーディングや訂正のためにジョンLoughneyに行きます。おかげでもフィードバックを提供し、テキストを貢献するためペッカSavolaとIljitschバン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]フラー、V.、李、T.、ゆう、J.、およびK. Varadhan、 "クラスレスドメイン間ルーティング（CIDR）：アドレス割り当ておよび集約戦略"、RFC 1519、1993年9月。
[RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995.
[RFC1771] Rekhter、Y.、およびT.李、 "ボーダーゲートウェイプロトコル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.、モスコウィッツ、R.、Karrenberg、D.、グルート、G.、およびE.リア、 "個人的なインターネットのための配分"、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]ホーキンソン、J.およびT.ベイツ、 "作成、選択、および自律システム（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]ベイツ、T.とY. Rekhter、 "マルチホームマルチプロバイダ接続のためのスケーラブルなサポート"、RFC 2260、1998年1月。
[RFC3221] Huston, G., "Commentary on Inter-Domain Routing in the Internet", RFC 3221, December 2001.
[RFC3221]ヒューストン、G.、 "インターネットにおけるドメイン間ルーティングの解説"、RFC 3221、2001年12月。
[RFC3582] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site-Multihoming Architectures", RFC 3582, August 2003.
[RFC3582] Abley、J.、ブラック、B.、およびV.ギル、 "IPv6のサイトマルチホーミングアーキテクチャの目標"、RFC 3582、2003年8月。
Authors' Addresses
著者のアドレス
Joe Abley Internet Systems Consortium, Inc. 950 Charter Street Redwood City, CA 94063 USA
ジョーAbleyインターネットシステムコンソーシアム株式会社950憲章通りカリフォルニア州レッドウッドシティー94063 USA
Phone: +1 650 423 1317 EMail: jabley@isc.org
電話：+1 650 423 1317 Eメール：jabley@isc.org
Kurt Erik Lindqvist Netnod Internet Exchange Bellmansgatan 30 Stockholm S-118 47 Sweden
クルト・エリックLindqvist、NetnodインターネットエクスチェンジBellmansgatan 30ストックホルムS-118 47スウェーデン
Phone: +46 8 615 85 70 EMail: kurtis@kurtis.pp.se
電話：+46 8 615 85 70 Eメール：kurtis@kurtis.pp.se
Elwyn B. Davies Independent Researcher Soham, Cambridgeshire CB7 5AW UK
エルウィンB.デイヴィス独立した研究ソーハム、ケンブリッジCB7 5AW英国
Phone: +44 7889 488 335 EMail: elwynd@dial.pipex.com
電話：+44 7889 488 335 Eメール：elwynd@dial.pipex.com
Benjamin Black Layer8 Networks
ベンジャミン・ブラックLayer8ネットワーク
EMail: ben@layer8.net
メールアドレス：ben@layer8.net
Vijay Gill AOL 12100 Sunrise Valley Dr Reston, VA 20191 US
ビジェイ・ギルAOL 12100日の出バレー博士レストン、バージニア州20191米国
Phone: +1 410 336 4796 EMail: vgill@vijaygill.com
電話：+1 410 336 4796 Eメール：vgill@vijaygill.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。