Network Working Group IAB
Request for Comments: 3177 IESG
Category: Informational September 2001
IAB/IESG Recommendations on IPv6 Address Allocations to Sites
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 (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
Abstract
抽象
This document provides recommendations to the addressing registries (APNIC, ARIN and RIPE-NCC) on policies for assigning IPv6 address blocks to end sites. In particular, it recommends the assignment of /48 in the general case, /64 when it is known that one and only one subnet is needed and /128 when it is absolutely known that one and only one device is connecting.
このドキュメントでは、サイトを終了したIPv6アドレスブロックを割り当てるための政策に取り組むレジストリ（APNIC、ARINやRIPE-NCC）に勧告を提供します。特に、それは、唯一のサブネットが必要であること、それが知られている一般的な場合に/ 48、/ 64、絶対的に唯一つのデバイスが接続されていることが知られている/ 128の割り当てを推奨しています。
The original recommendations were made in an IAB/IESG statement mailed to the registries on September 1, 2000. This document refines the original recommendation and documents it for the historical record.
オリジナルの勧告は、この文書では、元の勧告や歴史的な記録のための書類、それを洗練9月1日、2000年のレジストリに郵送IAB / IESG文で行われました。
There have been many discussions between IETF and RIR experts on the topic of IPv6 address allocation policy. This memo addresses the issue of the boundary in between the public and the private topology in the Internet, that is, how much address space should an ISP allocate to homes, small and large enterprises, mobile networks and transient customers.
IPv6のアドレス割り当てポリシーのトピックに関するIETFとRIRの専門家の間で多くの議論がありました。このメモは、それは多くのアドレス空間は、ISPは、家庭、小規模および大規模企業、モバイルネットワークおよび過渡顧客に割り当てるべきか、され、公開されインターネットでのプライベートトポロジの間に境界線の問題を解決します。
This document does not address the issue of the other boundaries in the public topology, that is, between the RIRs and the LIRs.
この文書では、各RIRとのLIRの間、つまり、公共のトポロジ内の他の境界の問題に対処しません。
This document was developed by the IPv6 Directorate, IAB and IESG, and is a recommendation from the IAB and IESG to the RIRs.
この文書は、IPv6理事、IABとIESGによって開発され、IABとIESGからのRIRへの勧告ですました。
The technical principles that apply to address allocation seek to balance healthy conservation practices and wisdom with a certain ease of access. On one hand, when managing a potentially limited resource, one must conserve wisely to prevent exhaustion within an expected lifetime. On the other hand, the IPv6 address space is in no sense as limited a resource as the IPv4 address space, and unwarranted conservatism acts as a disincentive in a marketplace already dampened by other factors. So from a market development perspective, we would like to see it be very easy for a user or an ISP to obtain as many IPv6 addresses as they really need without a prospect of immediate renumbering or of scaling inefficiencies.
割り当てに対処するために適用する技術の原則は、アクセスの特定のしやすさと健康保全の実践と知恵を両立しようとしています。潜在的に限られたリソースを管理する際一方で、一つは、予想寿命以内に枯渇を防ぐために賢く節約しなければなりません。 IPv4アドレス空間、及び不当な保守などの限られたリソースが既に他の要因によって減衰市場における阻害要因として作用する一方、IPv6アドレス空間はない意味です。だから、市場開発の観点から、我々はそれがユーザまたは彼らが本当にすぐにリナンバリングのか、非効率性をスケーリングの見通しなしに必要な数のIPv6アドレスを取得するISPのために非常に容易で見たいのですが。
The IETF makes no comment on business issues or relationships. However, in general, we observe that technical delegation policy can have strong business impacts. A strong requirement of the address delegation plan is that it not be predicated on or unduly bias business relationships or models.
IETFは、ビジネス上の問題や関係についてはコメントしていません。しかし、一般的に、我々は、技術的な委任ポリシーは強力なビジネスへの影響を持つことができることを確認します。アドレス委譲計画の強力な要件は、それが不当にバイアスビジネス関係やモデルかを前提としないことです。
The IPv6 address, as currently defined, consists of 64 bits of "network number" and 64 bits of "host number". The technical reasons for this are several. The requirements for IPv6 agreed to in 1993 included a plan to be able to address approximately 2^40 networks and 2^50 hosts; the 64/64 split effectively accomplishes this. Procedures used in host address assignment, such as the router advertisement of a network's prefix to hosts [RFC2462], which in turn place a locally unique number in the host portion, depend on this split. Subnet numbers must be assumed to come from the network part. This is not to preclude routing protocols such as IS-IS level 1 (intra-area) routing, which routes individual host addresses, but says that it may not be depended upon in the world outside that zone. The 64-bit host field can also be used with EUI-64 for a flat, uniquely allocated space, and therefore it may not be globally treated as a subnetting resource. Those concerned with privacy issues linked to the presence of a globally unique identifier may note that 64 bits makes a large enough field to maintain excellent random-number-draw properties for self-configured End System Designators. That alternative construction of this 64-bit host part of an IPv6 address is documented in [RFC3041].
IPv6アドレスは、現在定義されているように、「ネットワーク番号」の64ビットと「ホスト番号」の64ビットから成ります。このための技術的な理由はいくつかあります。 IPv6のための要件は、1993年に合意した約2 ^ 40ネットワークおよび2 ^ 50ホストに対処することができるようにする計画が含ま。 64/64の分割はこれを効果的に実現しています。ターン場所にホスト部分で局部的に固有の番号が、この分割に依存し、そのようなホストへのネットワークのプレフィックスのルータ通知としてホストアドレスの割り当て、[RFC2462]で使用される手順。サブネット番号は、ネットワーク部分から来ると想定しなければなりません。これは、IS-ISレベル1（エリア内）ルーティング、ルート個々のホストアドレスなどのルーティングプロトコルを排除するものではないが、それはそのゾーン外の世界にに依存しなくてもよいことを述べています。 64ビットのホスト・フィールドは、フラット、一意に割り当てられたスペースにEUI-64を使用することができ、したがって、グローバルサブネットのリソースとして扱われなくてもよいです。グローバル一意識別子の存在にリンクされているプライバシーの問題に関わるものは64ビットが自己構成されたエンド・システム指定子のための優れた乱数描画特性を維持するために十分な大きさのフィールドを作ることに気づくかもしれません。 IPv6アドレスのこの64ビットのホスト部の別の構成は、[RFC3041]に記載されています。
While the IETF has also gone to a great deal of effort to minimize the impacts of network renumbering, renumbering of IPv6 networks is neither invisible nor completely painless. Therefore, renumbering should be considered a tolerable event, but to be avoided if reasonably feasible.
IETFは、ネットワークのリナンバリングの影響を最小限にするために多大な努力を行ってきましたが、IPv6ネットワークの再番号付けは、目に見えないでも完全に無痛でもありません。したがって、リナンバリングは許容イベントと見なされるべきではなく、合理的に可能な場合は避けなければなりません。
In [RFC2374] and [RFC2450], the IETF's IPNG working group has recommended that the address block given to a single edge network which may be recursively subnetted be a 48-bit prefix. This gives each such network 2^16 subnet numbers to use in routing, and a very large number of unique host numbers within each network. This is deemed to be large enough for most enterprises, and to leave plenty of room for delegation of address blocks to aggregating entities.
[RFC2374]及び[RFC2450]に、IETFのIPNGワーキンググループは、アドレスブロックを再帰的に48ビットのプレフィックスとすることがサブネット化することができる単一のエッジネットワークに与えられることを推奨しています。これは、そのような各ネットワーク2 ^ 16サブネットルーティングで使用する番号、及び各ネットワーク内で一意のホスト番号の非常に大きな数を与えます。これは、ほとんどの企業のために十分な大きさで、かつ集約エンティティにアドレスブロックの委任の余地を残すものとみなされます。
It is not obvious, however, that all edge networks are likely to be recursively subnetted; a single PC in a home or a telephone in a mobile cellular network, for example, may or may not interface to a subnetted local network. When a network number is delegated to a place that will not require subnetting, therefore, it might be acceptable for an ISP to give a single 64-bit prefix - perhaps shared among the dial-in connections to the same ISP router. However this decision may be taken in the knowledge that there is objectively no shortage of /48s, and the expectation that personal, home networks will become the norm. Indeed, it is widely expected that all IPv6 subscribers, whether domestic (homes), mobile (vehicles or individuals), or enterprises of any size, will eventually possess multiple always-on hosts, at least one subnet with the potential for additional subnetting, and therefore some internal routing capability. In other words the subscriber allocation unit is not always a host; it is always potentially a site. The question this memo is addressing is how much address space should be delegated to such sites.
これは、すべてのエッジネットワークを再帰的にサブネット化される可能性があること、しかし、明らかにされていません。家庭内の単一のPCやモバイルセルラーネットワークの電話は、例えば、またはサブネットローカルネットワークとインターフェースしない場合があります。おそらく、同じISPルータへのダイヤルイン接続間で共有 - ネットワーク番号をサブネット化を必要としない場所に委任されている場合、それゆえ、それは単一の64ビットプレフィックスを与えるために、ISPのために許容できるかもしれません。しかし、この決定は、48S /の不足、および個人、ホームネットワークが当たり前になるだろうという期待が客観的に存在しないことを知識で撮影することができます。確かに、それは広くすべてのIPv6加入者は、国内（家庭）、モバイル（自動車または個人）、または任意のサイズの企業かどうか、最終的には複数所持することが期待される常時オンのホスト、追加のサブネットのための潜在性を有する少なくとも一つのサブネット、したがって、いくつかの内部ルーティング機能。換言すれば、加入者割当部は、常にホストではありません。それは潜在的に常にサイトです。このメモが取り組んでいる問題は、このようなサイトに委任する必要がありますどのくらいのアドレス空間です。
The IESG and the IAB recommend the allocations for the boundary between the public and the private topology to follow those general rules:
IESGとIABは、それらの一般的なルールに従うことが、公共と民間のトポロジとの間の境界のための割り当てをお勧めします。
- /48 in the general case, except for very large subscribers. - /64 when it is known that one and only one subnet is needed by design. - /128 when it is absolutely known that one and only one device is connecting.
- /一般的なケースでは48、非常に大規模な加入者を除きます。 - 唯一のサブネットが設計により必要とされることが知られている/ 64。 - 絶対に唯一つのデバイスが接続されていることが知られている/ 128。
In particular, we recommend:
特に、我々はお勧めします：
- Home network subscribers, connecting through on-demand or always-on connections should receive a /48. - Small and large enterprises should receive a /48. - Very large subscribers could receive a /47 or slightly shorter prefix, or multiple /48's.
- オンデマンドまたは接続、常時オン経由で接続するホームネットワークの加入者は、/ 48受けるべきです。 - 小規模および大企業は、/ 48を受けるべきです。 - 非常に大規模な加入者は、/ 47またはわずかに短いプレフィックス、または複数の/ 48年代を受け取ることができます。
- Mobile networks, such as vehicles or mobile phones with an additional network interface (such as bluetooth or 802.11b) should receive a static /64 prefix to allow the connection of multiple devices through one subnet. - A single PC, with no additional need to subnet, dialing-up from a hotel room may receive its /128 IPv6 address for a PPP style connection as part of a /64 prefix.
- そのような（例えばBluetoothや802.11bのような）追加のネットワークインタフェースを備えた車両や携帯電話などのモバイルネットワークは、あるサブネットを介して複数のデバイスの接続を可能にする静的/ 64プレフィックスを受けるべきです。 - 単一PCは、サブネットへの追加なし必要で、ホテルの部屋からダイヤルアップ/ 64プレフィックスの一部としてPPPスタイルの接続のためにその/ 128 IPv6アドレスを受け取ることができます。
Note that there seems to be little benefit in not giving a /48 if future growth is anticipated. In the following, we give the arguments for a uniform use of /48 and then demonstrate that it is entirely compatible with responsible stewardship of the total IPv6 address space.
今後の成長が期待されている場合/ 48を与えないで少し利益があるように思われることに注意してください。以下では、我々は、/ 48の均一な使用のために引数を与え、それが総IPv6アドレス空間の責任の責務と完全に互換性があることを示しています。
The arguments for the fixed boundary are:
固定境界の引数は次のとおりです。
- That only by having a provider-independent boundary can we guarantee that a change of ISP will not require a costly internal restructuring or consolidation of subnets.
- 唯一のプロバイダに依存しない境界を持っていることによって、我々はISPの変更はサブネットの高価な内部再編や統合を必要としないことを保証できること。
- That during straightforward site renumbering from one prefix to another the whole process, including parallel running of the two prefixes, would be greatly complicated if the prefixes had different lengths (depending of course on the size and complexity of the site).
- 接頭辞は、異なる長さ（サイズ、サイトの複雑さに当然依存する）であった場合は、1つのプレフィックスから別の2つのプレフィックスの並走を含むプロセス全体を、リナンバリング簡単サイト中、大幅に複雑になること。
- There are various possible approaches to multihoming for IPv6 sites, including the techniques already used for IPv4 multihoming. The main open issue is finding solutions that scale massively without unduly damaging route aggregation and/or optimal route selection. Much more work remains to be done in this area, but it seems likely that several approaches will be deployed in practice, each with their own advantages and disadvantages. Some (but not all) will work better with a fixed prefix boundary. (Multihoming is discussed in more detail below.)
- すでにIPv4のマルチホーミングのために使用される技術を含めたIPv6サイトのマルチホーミングするためのさまざまな可能なアプローチがあります。主な未解決の問題は、過度に有害な経路集約及び/又は最適経路選択せずに大規模スケールのソリューションを見つけることです。多くのより多くの仕事は、この領域で行われるように残っているが、いくつかのアプローチが自分の長所と短所があり、それぞれ、実際に配備される可能性が高いようです。一部は（すべてではない）の固定プレフィックス境界をよりよく動作します。 （マルチホーミングは、以下でより詳細に説明されています。）
- To allow easy growth of the subscribers' networks without need to go back to ISPs for more space (except for that relatively small number of subscribers for which a /48 is not enough).
- （/ 48が十分なされていない加入者の比較的少数を除いて）より多くのスペースのためにISPに戻る必要なしに、加入者のネットワークの容易な成長を可能にします。
- To remove the burden from the ISPs and registries of judging sites' needs for address space, unless the site requests more space than a /48. This carries several advantages:
- サイトが/ 48より多くのスペースを要求しない限り、アドレス空間のためのサイトのニーズを判断するISPやレジストリからの負担を削除します。これにはいくつかの利点を運びます：
- It may become less critical for ISPs to be able to maintain detailed knowledge of their customers' network architecture and growth plans,
- ISPが顧客のネットワークアーキテクチャと成長計画の詳細な知識を維持できるようにすることは、それほど重要になることがあり
- ISPs and registries may reduce the effort spent on assessing rates of address consumption, with address space ample for long-term growth plans, - Registry operations may be made more efficient or more focused, by reducing the urgency of tracking and assessment. - Address space will no longer be a precious resource for customers, removing the major incentive for subscribers to install v6/v6 NATs, which would defeat the IPv6 restoration of address transparency.
- ISPやレジストリは長期的な成長計画のための十分なアドレス空間と、アドレスの消費量の割合を評価するに費やす労力を減らすことができる、 - レジストリ操作は追跡と評価の緊急性を減らすことによって、より効率的またはより集中してもよいです。 - アドレス空間は、もはやアドレス透明のIPv6の回復を台無しにしてしまうV6 / v6のNATのをインストールするには、加入者のための主要なインセンティブを、削除、顧客のための貴重な資源になることはありません。
- To allow the site to maintain a single reverse-DNS zone covering all prefixes.
- サイトはすべてのプレフィックスをカバーする単一逆DNSゾーンを維持することができるようにするには。
- If and only if a site can use the same subnetting structure under each of its prefixes, then it can use the same zone file for the address-to-name mapping of all of them. And, using the conventions of [RFC2874], it can roll the reverse mapping data into the "forward" (name-keyed) zone.
- サイトはそのプレフィックスのそれぞれの下で同じサブネット化構造を使用することができる場合にのみ、と、それはそれらのすべてのアドレスから名前のマッピングに同じゾーンファイルを使用することができます。そして、[RFC2874]の規則を使用して、それが「フォワード」（名前キー付き）ゾーンに逆マッピングデータをロールバックすることができます。
Specific advantages of the fixed boundary being at /48 include
/ 48挙げである固定された境界の特定の利点
- To leave open the technical option of retro-fitting the GSE (Global, Site and End-System Designator, a.k.a., "8+8") proposal for separating locators and identifiers, which assumes a fixed boundary between global and site addressing at /48. Although the GSE technique was deferred a couple of years ago, it still has strong proponents. Also, the IRTF Namespace Research Group is actively looking into topics closely related to GSE. It is still possible that GSE or a derivative of GSE will be used with IPv6 in the future.
- レトロフィットGSE（グローバル、サイト、およびエンドシステム指定子、別名、「8 + 8」）/に取り組むグローバルとサイトとの間に固定された境界線を想定しているロケータと識別子を分離するための提案、技術的なオプションを開いたままにするに48。 GSE技術は数年前に延期されたが、それはまだ強い支持者を持っています。また、IRTFネームスペースの研究グループは、積極的に密接にGSEに関連するトピックを検討しています。 GSEかGSEの誘導体は、将来的にIPv6で使用されることは可能です。
- Since the site-local prefix is fec0::/48, global site prefixes of /48 will allow sites to easily maintain a trivial (identity) mapping between the global topology and the site-local topology in the SLA field.
- サイトローカルプレフィックスがFEC0あるので、:: / 48、/ 48のグローバルサイトプレフィックスサイトが簡単にグローバルトポロジとSLAフィールドにサイトローカルトポロジ間の些細（アイデンティティ）のマッピングを維持することができるようになります。
- Similarly, if the 6to4 proposal is widely deployed, migration from a 6to4 prefix, which is /48 by construction, to a native IPv6 prefix will be simplified if the native prefix is /48.
- の6to4提案が広く展開されている場合、ネイティブプレフィックスが/ 48であれば同様に、ネイティブIPv6プレフィックスに構成することにより/ 48であるの6to4プリフィックスからの移行は、簡略化します。
The question naturally arises whether giving a /48 to every subscriber represents a profligate waste of address space. Objective analysis shows that this is not the case. A /48 prefix under the 001 Global Unicast Address prefix contains 45 variable bits. That is, the number of available prefixes is 2 to the power 45 or about 35 trillion (35,184,372,088,832).
質問は、当然、すべての加入者に/ 48を与えることがアドレス空間の浪費浪費を表しているかどうかを生じます。客観的な分析は、これがそうでないことを示しています。 001グローバルユニキャストアドレスプレフィックス下/ 48プレフィックスは45個の可変ビットを含みます。それは、利用可能なプレフィックスの数は2電源45、または約35000000000000（35,184,372,088,832）です。
More precisely,
より正確に、
- [RFC1715] defines an "H ratio" based on experience in address space assignment in various networks. The H ratio varies between 0 and 0.3, with larger values denoting denser, more efficient assignment. Experience shows that problems start to occur when the H ratio becomes greater than 0.25. At an H ratio of 0.25, a 45 bit address space would have 178 billion (178 thousand million) identifiers.
- [RFC1715]は、様々なネットワークにおけるアドレス空間割り当ての経験に基づいて「H比」を定義します。 H比が密、より効率的な割り当てを表す大きな値で、0と0.3の間で変化します。経験は問題がH比が0.25より大きくなると発生し始めることを示しています。 0.25のH比では、45ビットのアドレス空間178億円（178000百万円）の識別子を持っているでしょう。
H = log10(178*10^9) / 45 = 0.25
H = LOG10（178 * 10 ^ 9）/ 45 = 0.25
This means that we feel comfortable about the prospect of allocating 178 billions /48 prefixes under that scheme before problems start to appear. To understand how big that number is, one has to compare 178 billion to 10 billion, which is the projected population on earth in year 2050 (see http://www.census.gov/ipc/www/world.html). These numbers give no grounds for concern provided that the ISPs, under the guidance of the RIRs, allocate /48's prudently, and that the IETF refrains from new recommendations that further reduce the remaining 45 variable bits, unless a compelling requirement emerges.
これは、我々は問題が現れ始める前に、そのスキームの下で178億/ 48プレフィックスを割り当てるの見通しについて快適に感じることを意味します。その数はどのように大きな理解するためには、2050年で地球上の投影人口（http://www.census.gov/ipc/www/world.htmlを参照）である10億1780億を比較することがあります。これらの数字は、ISPは、各RIRの指導の下、慎重に/ 48のを割り当てることを提供懸念の根拠を与えていない、と説得力の要件が出ない限り、さらに、残りの45ビット変数を減らす新しい勧告からIETF控えています。
- We are highly confident in the validity of this analysis, based on experience with IPv4 and several other address spaces, and on extremely ambitious scaling goals for the Internet amounting to an 80 bit address space *per person*. Even so, being acutely aware of the history of under-estimating demand, the IETF has reserved more than 85% of the address space (i.e., the bulk of the space not under the 001 Global Unicast Address prefix). Therefore, if the analysis does one day turn out to be wrong, our successors will still have the option of imposing much more restrictive allocation policies on the remaining 85%. However, we must stress that vendors should not encode any of the boundaries discussed here either in software nor hardware. Under that assumption, should we ever have to use the remaining 85% of the address space, such a migration may not be devoid of pain, but it should be far less disruptive than deployment of a new version of IP.
- 私たちは、*一人当たり* IPv4および他のいくつかのアドレス空間での経験に基づいて、この分析の妥当性、中、および80ビットのアドレス空間に相当するインターネットのための非常に野心的なスケーリング目標に非常に自信を持っています。たとえそうであっても、アンダー推定要求の履歴を強く意識し、IETFは、アドレス空間の85％以上を予約している（すなわち、001ないグローバルユニキャストアドレスプレフィックス下空間のバルク）。分析は1日間違っていることが判明しない場合はそのため、私たちの後継者はまだ残りの85％にはるかに制限割り当てポリシーを課すのオプションがあります。しかし、私たちは、ベンダーがソフトウェアやハードウェアのいずれかで、ここで議論境界のいずれかをコードするべきではないことを強調しなければなりません。仮定の下で、我々はこれまで、そのような移行は痛みを欠いではないかもしれないアドレス空間の残りの85％を使用する必要がありますが、それはIPの新しいバージョンの展開よりもはるかに少ない破壊的でなければなりません。
To summarize, we argue that although careful stewardship of IPv6 address space is essential, this is completely compatible with the convenience and simplicity of a uniform prefix size for IPv6 sites of any size. The numbers are such that there seems to be no objective risk of running out of space, giving an unfair amount of space to early customers, or of getting back into the over-constrained IPv4 situation where address conservation and route aggregation damage each other.
要約すると、我々は、IPv6アドレス空間を慎重に管理責任が不可欠ですが、これは任意のサイズのIPv6サイトのための均一なプレフィックスサイズの利便性とシンプルさと完全に互換性があると主張しています。数字は早く顧客にスペースの不当な量を与えて、スペースが不足する、またはバックアドレスの保全とルート集約がお互いを傷つけ上に制約のIPv4状況に入るのない客観的危険がないように思えるようになっています。
In the realm of multi-homed networks, the techniques used in IPv4 can all be applied, but they have known scaling problems. Specifically, if the same prefix is advertised by multiple ISPs, the routing information will grow as a function of the number of multihomed sites. To go beyond this for IPv6, we only have initial proposals on the table at this time, and active work is under way in the IETF IPNG and Multi6 working groups. Until current or new proposals become more fully developed, existing techniques known to work in IPv4 will continue to be used in IPv6.
マルチホームネットワークの分野では、IPv4のに使用される技術はすべて適用することができますが、それらは、スケーリングの問題を知られています。同じプレフィックスを複数のISPによってアドバタイズされた場合は具体的には、ルーティング情報は、マルチホームサイトの数の関数として成長します。 IPv6のためにこれを越えて行くために、私たちは、この時点でテーブルの上に最初の提案、およびアクティブな仕事を持っているIETF IPNGとMulti6ワーキンググループで進行中です。現在または新しい提案は、より完全に開発になるまでは、IPv4の中で働くことが知られている既存の技術では、IPv6で使用され続けます。
Key characteristics of an ideal multi-homing proposal include (at minimum) that it provides routing connectivity to any multi-homed network globally, conserves address space, produces high quality routes via any of the network's providers, enables a multi-homed network to connect to multiple ISPs, does not unintentionally bias routing to use any proper subset of those networks, does not damage route aggregation, and scales to very large numbers of multi-homed networks.
理想的なマルチホーミングの提案の主要な特徴は、それが世界的に任意のマルチホームネットワークにルーティング接続を提供することを（少なくとも）含む、アドレス空間を節約し、ネットワークのプロバイダのいずれかを介して高品質の経路を生成する、接続するマルチホームネットワークを可能にします複数のISPに、意図せずにこれらのネットワークの任意の適切なサブセットを使用するルーティングバイアスは、ルート集約を損傷しないしない、およびマルチホームネットワークの非常に大きな数に比例。
One class of solutions being considered amounts to permanent parallel running of two (or more) prefixes per site. In the absence of a fixed prefix boundary, such a site might be required to have multiple different internal subnet numbering strategies, (one for each prefix length) or, if it only wanted one, be forced to use the most restrictive one as defined by the longest prefix it received from any of its ISPs. In this approach, a multi-homed network would have an address block from each of its upstream providers. Each host would either have exactly one address picked from the set of upstream providers, or one address per host from each of the upstream providers. The first case is essentially a variant on [RFC2260], with known scaling limits.
サイトごとに2つ（またはそれ以上）のプレフィックスの永久的な並列運転に金額検討されている解決策の一つのクラス。それは一つだけ、で定義された最も制限1を使用するように強制されたい場合は、固定プレフィックス境界が存在しない場合には、そのようなサイトは、複数の異なる内部サブネットナンバリング戦略を持つことが必要になる場合があります、（各プレフィックス長のための1）またはそれはそののISPのいずれかから受信した最長プレフィックス。このアプローチでは、マルチホームネットワークは、その上流プロバイダの各々からアドレスブロックを有するであろう。各ホストは、1つのアドレスは、上流プロバイダのそれぞれから上流プロバイダのセット、またはホストごとに一つのアドレスから選んだはずのどちらか。最初のケースは、既知のスケーリング限界と、本質的に[RFC2260]に変異体です。
In the second case (multiple addresses per host), if two multi-homed networks communicate, having respectively M and N upstream providers, then the one initiating the connection will select one address pair from the N*M potential address pairs to connect between, and in so doing will select the providers, and therefore the applicable route, for the life of the connection. Given that each path will have a different available bit rate, loss rate, and delay, if neither host is in possession of any routing or metric information, the initiating host has only a 1/(M*N) probability of selecting the optimal address pair. Work on better-than-random address selection is in progress in the IETF, but is incomplete.
第二のケース（ホストごとに複数のアドレス）で、2つのマルチホームネットワークが通信する場合、それぞれM及びNの上流プロバイダを有する、接続を開始一つは、間を接続するN * M電位アドレスペアから1アドレスペアを選択しますそうすることで、接続の人生のために、提供者、およびので、該当するルートを選択します。どちらのホストが任意のルーティングやメトリック情報を保持している場合は、各パスが、異なる利用可能なビットレート、損失率、及び遅延を有することになることを考えると、開始ホストは、最適のアドレスを選択するだけ1 /（M * N）確率を有しますペア。より良いよりランダムアドレス選択の作業はIETFで進行中であるが、不完全です。
The existing IPv4 Internet shows us that a network prefix which is independent of, and globally advertised to, all upstream providers permits the routing system to select a reasonably good path within the applicable policy. Present-day routing policies are not QoS policies but reachability policies, which means that they will not necessarily select the optimal delay, bit rate, or loss rate, but the route will be the best within the metrics that are in use. One may therefore conclude that this would work correctly for IPv6 networks as well, apart from scaling issues.
既存のIPv4インターネットはとは無関係に、そして世界的にアドバタイズされたネットワークプレフィックス、すべての上流のプロバイダが適用可能なポリシー内で適度に良好なパスを選択するルーティングシステムを許可することを私たちに示しています。現代のルーティングポリシーは、彼らが必ずしも最適な遅延、ビットレート、または損失率を選択しないことを意味しますが、ルートが使用されているメトリック内で最善される、QoSポリシーが、到達可能性の方針ではありません。一つは、したがって、これは、スケーリングの問題とは別に、同様にIPv6ネットワークのために正しく動作することを結論付けることができます。
This document does not have any security implications.
このドキュメントは、セキュリティへの影響はありません。
This document originated from the IETF IPv6 directorate, with much input from the IAB and IESG. The original text forming the basis of this document was contributed by Fred Baker and Brian Carpenter. Allison Mankin and Thomas Narten merged the original contributions into a single document, and Alain Durand edited the document through its final stages.
このドキュメントは、IABとIESGから多くの入力で、IETFのIPv6総局から発信しました。このドキュメントの基礎を形成し、元のテキストは、フレッド・ベイカーとブライアン・カーペンターによって寄贈されました。アリソンマンキンとトーマスNarten氏は、1つの文書に、元の貢献を合併し、そしてアランデュランは最終段階を経て、文書を編集しました。
[RFC1715] Huitema, C., "The H Ratio for Address Assignment Efficiency", RFC 1715, November 1994.
[RFC1715]のHuitema、C.、 "アドレス割り当ての効率化のためのH比"、RFC 1715、1994年11月。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026]ブラドナーの、S.、 "インターネット標準化プロセス - リビジョン3"、BCP 9、RFC 2026、1996年10月。
[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月。
[RFC2374] Hinden, R., O'Dell, M. and S. Deering, "An IPv6 Aggregatable Global Unicast Address Format", RFC 2374, July 1998.
[RFC2374] HindenとR.、オデル、M.とS.デアリング、 "IPv6の集約可能グローバルユニキャストアドレス形式"、RFC 2374、1998年7月。
[RFC2450] Hinden, R., "Proposed TLA and NLA Assignment Rule", RFC 2450, December 1998.
[RFC2450] HindenとR.、 "提案TLAとNLA割当てルール"、RFC 2450、1998年12月。
[RFC2462] Thompson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[RFC2462]トンプソン、S.とT. Narten氏、 "IPv6のステートレスアドレス自動設定"、RFC 2462、1998年12月。
[RFC2874] Crawford, M. and C. Huitema, "DNS Extensions to Support IPv6 Address Aggregation and Renumbering", RFC 2874, July 2000.
[RFC2874]クロフォード、M.とC.のHuitemaは、RFC 2874、2000年7月 "DNSの拡張機能は、IPv6アドレスの集約とリナンバリングを支援します"。
[RFC3041] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[RFC3041] Narten氏、T.およびR. Draves、 "IPv6におけるステートレスアドレス自動設定のための個人情報保護の拡張"、RFC 3041、2001年1月。
[MobIPv6] Johnson, D. and C. Perkins, "Mobility Support in IPv6", Work in Progress.
[MobIPv6]ジョンソン、D.とC.パーキンス、 "IPv6におけるモビリティサポート"、進行中の作業。
Internet Architecture Board
インターネットアーキテクチャ委員会
Email: iab@iab.org
メール：iab@iab.org
Internet Engineering Steering Group
インターネットエンジニアリング運営グループ
Email: iesg@ietf.org
メール：iesg@ietf.org
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。