RFC4116 日本語訳
4116 IPv4 Multihoming Practices and Limitations. J. Abley, K.Lindqvist, E. Davies, B. Black, V. Gill. July 2005. (Format: TXT=26598 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
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
Ableyがコメントのために要求するワーキンググループJ.をネットワークでつないでください: 4116年のISCカテゴリ: 情報のK.Netnodインターネット交換E.デイヴィースリンクヴィスト独自の研究を行っている人のB.の黒いLayer8は2005年7月にV.エラAOLをネットワークでつなぎます。
IPv4 Multihoming Practices and Limitations
IPv4マルチホーミング習慣と制限
Status of this Memo
この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)インターネット協会(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に関連しました)。
Abley, et al. Informational [Page 1] RFC 4116 IPv4 Multihoming July 2005
Abley、他 [1ページ]情報のRFC4116IPv4マルチホーミング2005年7月
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
1. 序論…3 2. 用語…3 3. IPv4マルチホーミングは練習されます…4 3.1. BGPがあるマルチホーミング…4 3.1.1. 問題を記述します…4 3.1.2. 数の問題として…6 3.2. ただ一つのトランジットプロバイダーへの複数の付属…6 3.3. NATかRFC2260ベースのマルチホーミング…7 4. IPv4マルチホーミングの特徴…7 4.1. 冗長…7 4.2. 負荷分割法…8 4.3. パフォーマンス…8 4.4. 方針…8 4.5. 簡単さ…9 4.6. トランスポート層の生存性…9 4.7. DNSで影響を与えてください…9 4.8. パケットフィルタリング…9 4.9. スケーラビリティ…9 4.10. ルータで影響を与えてください…10 4.11. ホストの上で影響を与えてください…10 4.12. ホストとルート設定システムとの相互作用…10 4.13. 操作と管理…10 4.14. トランジットプロバイダーの間の協力…10 5. セキュリティ問題…10 6. 承認…10 7. 有益な参照…11
Abley, et al. Informational [Page 2] RFC 4116 IPv4 Multihoming July 2005
Abley、他 [2ページ]情報のRFC4116IPv4マルチホーミング2005年7月
1. Introduction
1. 序論
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.
マルチホーミングは重要な多くのインターネット・サイトに対するサービスのコンポーネントです。 Classless Inter Domainルート設定(CIDR)構造[RFC1519]に現在のIPv4マルチホーミング習慣を追加してあります。(それは、顧客とサービスプロバイダーの階層構造に基づいた状態で経路指定テーブルエントリーを集めることができると仮定します)。
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の能力を当てにしないマルチホーミング戦略について議論します。
2. Terminology
2. 用語
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つ以上のトランジットプロバイダーがある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.
「マルチ付属している」サイトは1ポイント以上の層-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)アドレスはトランジットプロバイダーによって割り当てられませんが、ある他の機構、通常RegionalインターネットRegistry(RIR)によって提供されるグローバルにユニークなアドレスです。
Abley, et al. Informational [Page 3] RFC 4116 IPv4 Multihoming July 2005
Abley、他 [3ページ]情報のRFC4116IPv4マルチホーミング2005年7月
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.
プロバイダー-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.
単語「割り当て」と「割り当て」がRegionalインターネットRegistry(RIR)アドレス経営政策で特定の意味を持っていますが、より緩く本書では使用されることに注意してください。
3. IPv4 Multihoming Practices
3. IPv4マルチホーミング習慣
3.1. Multihoming with BGP
3.1. BGPがあるマルチホーミング
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があるマルチホーミングのための一般的方法は1セットのルートを2つ以上のトランジットプロバイダーに発表することです。 これは「マルチ-家へ帰」っているサイトへの複数の経路をインターネットの残りに提供します、そして、それぞれのトランジットプロバイダーは追加可能な経路をサイトのアウトバウンドトラフィックに提供します。
3.1.1. Addressing Considerations
3.1.1. 問題を記述します。
3.1.1.1. PI Addresses
3.1.1.1. パイアドレス
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アドレスをカバーする1セットのルートが、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年代の半ばまで、これは比較的達成しやすかったです、グローバルな経路指定テーブルの一般に、受け入れられた最大の接頭語の長さが/24であり、正当化は/24PI課題を得るのにほとんど必要でなかったときに。 それ以来、RIRアドレス経営政策はこの点でより寛容でなくなっています。 すべてのRIRsが小さくて、「マルチ-家へ帰」っている終わりのユーザにあて先ブロックの課題をサポートするというわけではありません、そして、それを支持する人が小さいサイトで会うことができない/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アドレスを使用する各サイトがグローバルなルーティングシステムに追加接頭語を取り入れます。 マルチホーミングのこの計画が広範囲になるなら、それはスケーリング関心を提示するでしょうに。
Abley, et al. Informational [Page 4] RFC 4116 IPv4 Multihoming July 2005
Abley、他 [4ページ]情報のRFC4116IPv4マルチホーミング2005年7月
3.1.1.2. PA Addresses
3.1.1.2. PAアドレス
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アドレスにサイトルートをカバーする1セットのルートを割り当てたトランジットプロバイダーはセットしました。 第一のトランジットプロバイダーは、しばしば覆い集合と同様に設定されたサイトルートを、溯源するか、または伝播します。
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が記述する使用が強いられるサイトは、それらであるなら第一のトランジットプロバイダーに接続性を保有しないと決めます。 これはPAアドレス(そして、「マルチ-家へ帰」るものであるだけではない)を使用するすべてのサイトのための一般的な要件ですが、それはISPの変化を容易にする「マルチ-家」における動機がことであるサイトにより頻繁な影響力を持っているかもしれないものです。 PAアドレスを使用する「マルチ-家へ帰」っているサイトは、番号を付け替えさせる有なしで他のサービスプロバイダーをまだ加えるか、または落とすことができます。
Abley, et al. Informational [Page 5] RFC 4116 IPv4 Multihoming July 2005
Abley、他 [5ページ]情報のRFC4116IPv4マルチホーミング2005年7月
3.1.2. AS Number Considerations
3.1.2. 数の問題として
3.1.2.1. Consistent Origin AS
3.1.2.1. 一貫した起源
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.
「マルチ-家へ帰」っているサイトは、数が割り当てたグローバルにユニークなAutonomous System(AS)からサイトまで2つ以上のトランジットプロバイダーにルートを発表するのを選ぶかもしれません。 インターネットのすべての地域から見られると、これはルートの起源を一貫しているように見せます。
3.1.2.2. Inconsistent Origin AS
3.1.2.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.
「マルチ-家へ帰」っているサイトは、トランジットプロバイダーにルートを溯源するのに、私用AS番号[RFC1930]を使用するのを選ぶかもしれません。 トランジットプロバイダーから同輩に向かって伝播できる前にAS_PATH属性から私用AS番号を剥取るのは、正常な習慣です。 したがって、インターネットの他の地域から観測されたルートは矛盾した起源を持っているように見えるかもしれません。
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.
「マルチ-家へ帰」っているサイトは、それらのトランジットプロバイダーがトランジットプロバイダーのASesからサイトのルートをそれぞれ溯源するよう要求するかもしれません。 ダイナミックルーティング(サイトへの接続性が無くなる場合サイトのルートを引っ込める目的のための)はまだ可能です、この場合、外部的に目に見える発表の引き金となるのにトランジットプロバイダーの内部のルーティングシステムを使用して。
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の使用で容易にされます。 これで、輸入政策は変化するかもしれない中間的ルーティングの詳細でというよりむしろルートの本当の起源に基づきます(例えば、トランジットプロバイダーが「マルチ-家へ帰」っているサイトによって加えられて、落とされるのに従って)。
3.2. Multiple Attachments to a Single Transit Provider
3.2. ただ一つのトランジットプロバイダーへの複数の付属
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".
ただ一つのトランジットプロバイダーとの複数の接続でマルチホーミングを達成できます。 これは、単一に付属しているので、サイトにかかわるそれを超えてどんな追加負荷もグローバルな経路指定テーブルに課しません。 このようにマルチホーミングの必要性を解決したサイトは一般的に同じくらい「マルチ同じくらい付属していた」状態で参照されます。
Abley, et al. Informational [Page 6] RFC 4116 IPv4 Multihoming July 2005
Abley、他 [6ページ]情報のRFC4116IPv4マルチホーミング2005年7月
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が使用されているところ)グローバルにユニークなAS番号を使用するのから利点を全く獲得しないで、また特定の最小規模のアドレス課題を正当化できる必要性を全く持っていません。 しかしながら、マルチ付属はただ一つのトランジットプロバイダーの失敗からサイトを保護しません。
3.3. NAT- or RFC2260-based Multihoming
3.3. NATかRFC2260ベースのマルチホーミング
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]に応じて、ネットワークの中に個々のホストにアドレスを割り当てるか、またはサイトは、サイトの中の1セットの私用アドレス[RFC1918]に様々なプロバイダーアドレスを翻訳するのに、Network Address Translation(NAT)を使用します。 事実上、サイトは1つ以上のトランジットプロバイダーに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番号も必要としないで、またどんな追加負荷も課しません。 しかしながら、それはマルチホーミングに関するいくつかの一般的な動機、最も著しくトランスポート層の生存性を記述しません。
4. Features of IPv4 Multihoming
4. IPv4マルチホーミングの特徴
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.
以下のセクションはセクション3で説明されたアプローチの特徴のいくつかについて説明します、[RFC3582]に提示されたマルチホーミング構造の一般的な目標の文脈で。 そのドキュメントでこれらの目標への詳述と原理を見つけることができます。
4.1. Redundancy
4.1. 冗長
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.
方法が説明したすべてが冗長を提供します。(それは、いくつかの単一のポイント失敗からサイトを保護できます)。 保護の度合いはそれらのトランジットプロバイダーとサイトとインタコネクトするのに使用されるトランジットプロバイダーと方法の選択に依存します。
Abley, et al. Informational [Page 7] RFC 4116 IPv4 Multihoming July 2005
Abley、他 [7ページ]情報のRFC4116IPv4マルチホーミング2005年7月
4.2. Load Sharing
4.2. 負荷分割法
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におけるアドレス選択で制御されます。
4.3. Performance
4.3. パフォーマンス
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におけるソースアドレス選択で特定のセッションの間にインバウンドトラフィックによって取られた経路は制御できます。
4.4. Policy
4.4. 方針
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.
いくつかの事情では、特定のトランジットプロバイダーで特定のタイプ(例えば、議定書を作る)の交通を発送するのは可能です。 サイトのその交通がそれのソースか流し台をそうすることができる装置が特別な輸出方針を適用できる1セットのアドレスに孤立しているなら、これができます。
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に関する適切なソースアドレス(ポート)を選択することによって溯源されていた状態で可能であるかもしれません。
Abley, et al. Informational [Page 8] RFC 4116 IPv4 Multihoming July 2005
Abley、他 [8ページ]情報のRFC4116IPv4マルチホーミング2005年7月
4.5. Simplicity
4.5. 簡単さ
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.
マルチホーミング解決として使用される現在の方法は、それらの複雑さと共にありますが、使用されているのが十分簡単であると判明しました。 それらは手広く配備されたためよく知られているという強みがあります。
4.6. Transport-Layer Survivability
4.6. トランスポート層の生存性
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.
本書では説明されたすべての方法で、再の家へ帰り出来事に続いて、新しいトランスポート層セッションは作成できます。
4.7. Impact on DNS
4.7. DNSで影響を与えてください。
These multihoming strategies impose no new requirements on the DNS.
これらのマルチホーミング戦略はいいえ新しい要件をDNSに課します。
4.8. Packet Filtering
4.8. パケットフィルタリング
These multihoming practices do not preclude filtering of packets with inappropriate source or destination addresses at the administrative boundary of the multihomed site.
これらのマルチホーミング習慣は、「マルチ-家へ帰」っているサイトの管理境界で不適当なソースか送付先アドレスでフィルターにかけるのをパケットを排除しません。
4.9. Scalability
4.9. スケーラビリティ
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マルチホーミングとただ一つのトランジットプロバイダーへのマルチの付けはグローバルなルーティングシステムに保持されるどんな追加状態も提供しません。 他の戦略がルーティングシステム状態に寄付するすべてがふくれます。
Abley, et al. Informational [Page 9] RFC 4116 IPv4 Multihoming July 2005
Abley、他 [9ページ]情報のRFC4116IPv4マルチホーミング2005年7月
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番号の課題を必要とする戦略を使用する広範囲のマルチホーミングは増加するリソース主張につながるかもしれません。
4.10. Impact on Routers
4.10. ルータで影響を与えてください。
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サイトにそれらを超えてどんな特別な要件も持っていません。
4.11. Impact on Hosts
4.11. ホストの上で影響を与えてください。
There are no requirements of hosts beyond those in singlehomed sites.
ホストの要件は全くsinglehomedサイトのそれらを超えていません。
4.12. Interactions between Hosts and the Routing System
4.12. ホストとルート設定システムとの相互作用
There are no requirements for interaction between routers and hosts beyond those in singlehomed sites.
相互作用のための要件は全くルータとホストの間にsinglehomedサイトのそれらを超えていません。
4.13. Operations and Management
4.13. 操作と管理
There is extensive operational experience in managing IPv4-multihomed sites.
IPv4-multihomedサイトを管理する大規模な運用経験があります。
4.14. Cooperation between Transit Providers
4.14. トランジットプロバイダーの間の協力
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接頭語を発表するか、または伝播するように頼まれるトランジットプロバイダーは最初に、認可を得ます。 しかしながら、このコーディネートが行われるのを必要とするどんな技術的要求事項も一般的な契約上の方針もありません。
5. Security Considerations
5. セキュリティ問題
This document discusses current IPv4 multihoming practices, but provides no analysis of the security implications of multihoming.
このドキュメントは、現在のIPv4マルチホーミング習慣について議論しますが、マルチホーミングのセキュリティ含意の分析を全く提供しません。
6. Acknowledgements
6. 承認
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によって支持されました。
Abley, et al. Informational [Page 10] RFC 4116 IPv4 Multihoming July 2005
Abley、他 [10ページ]情報のRFC4116IPv4マルチホーミング2005年7月
7. Informative References
7. 有益な参照
[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)階級のない相互ドメイン」 「アドレス課題と集合戦略」、RFC1519、9月1993日
[RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4
(BGP-4)", RFC 1771, March 1995.
1995年の[RFC1771]RekhterとY.とT.李、「ボーダ・ゲイトウェイ・プロトコル4(BGP-4)」、RFC1771行進。
[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.リア、「個人的なインターネットのためのアドレス配分」BCP5、RFC1918(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.ベイツ、「Autonomous System(AS)の創造、選択、および登録のためのガイドライン」BCP6、RFC1930(1996年3月)。
[RFC2260] Bates, T. and Y. Rekhter, "Scalable Support for Multi-
homed Multi-provider Connectivity", RFC 2260,
January 1998.
T.とY.Rekhter、[RFC2260]が和らげる、「MultiのためのスケーラブルなSupportが家へ帰った、Multi-プロバイダーConnectivity、」、RFC2260、1月1998日
[RFC3221] Huston, G., "Commentary on Inter-Domain Routing in the
Internet", RFC 3221, December 2001.
[RFC3221]ヒューストン、G.、「インターネットの相互ドメインルート設定の論評」、RFC3221、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サイトマルチホーミング構造の目標」、RFC3582、2003年8月。
Abley, et al. Informational [Page 11] RFC 4116 IPv4 Multihoming July 2005
Abley、他 [11ページ]情報のRFC4116IPv4マルチホーミング2005年7月
Authors' Addresses
作者のアドレス
Joe Abley Internet Systems Consortium, Inc. 950 Charter Street Redwood City, CA 94063 USA
ジョーAbleyインターネットSystems共同体Inc.950憲章通りカリフォルニア94063レッドウッドシティー(米国)
Phone: +1 650 423 1317 EMail: jabley@isc.org
以下に電話をしてください。 +1 1317年の650 423メール: jabley@isc.org
Kurt Erik Lindqvist Netnod Internet Exchange Bellmansgatan 30 Stockholm S-118 47 Sweden
カートエリックリンクヴィストNetnodインターネット交換Bellmansgatan30ストックホルムS-118 47スウェーデン
Phone: +46 8 615 85 70 EMail: kurtis@kurtis.pp.se
以下に電話をしてください。 +46 8 615 85 70はメールされます: kurtis@kurtis.pp.se
Elwyn B. Davies Independent Researcher Soham, Cambridgeshire CB7 5AW UK
Elwyn B.デイヴィース・独自の研究を行っている人Soham、ケンブリッジ州CB7 5AWイギリス
Phone: +44 7889 488 335 EMail: elwynd@dial.pipex.com
以下に電話をしてください。 +44 7889 488 335はメールされます: elwynd@dial.pipex.com
Benjamin Black Layer8 Networks
Layer8がネットワークでつなぐベンジャミンBlack
EMail: ben@layer8.net
メール: ben@layer8.net
Vijay Gill AOL 12100 Sunrise Valley Dr Reston, VA 20191 US
日の出バレーレストン博士、ビジェイエラAOL12100ヴァージニア20191米国
Phone: +1 410 336 4796 EMail: vgill@vijaygill.com
以下に電話をしてください。 +1 4796年の410 336メール: vgill@vijaygill.com
Abley, et al. Informational [Page 12] RFC 4116 IPv4 Multihoming July 2005
Abley、他 [12ページ]情報のRFC4116IPv4マルチホーミング2005年7月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Abley, et al. Informational [Page 13]
Abley、他 情報[13ページ]
一覧
スポンサーリンク
