[要約] RFC 3177は、IPv6アドレスの割り当てに関するIAB/IESGの推奨事項をまとめたものであり、その目的は、インターネット上のサイトに適切なIPv6アドレスを割り当てるためのガイドラインを提供することです。
Network Working Group IAB
Request for Comments: 3177 IESG
Category: Informational September 2001
IAB/IESG Recommendations on IPv6 Address Allocations to Sites
IPv6に関するIAB/IESGの推奨事項は、サイトへの割り当てアドレス
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.
Copyright（c）The Internet Society（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は、1つのサブネットのみが必要であることがわかっている場合、および1つのデバイスのみが接続していることが絶対に知られている場合は /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.
元の推奨事項は、2000年9月1日にレジストリに郵送された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.
IETFとRIRの専門家の間で、IPv6アドレス割り当てポリシーのトピックに関する多くの議論がありました。このメモは、インターネット内の公共トポロジーとプライベートトポロジの間の境界の問題、つまり、ISPが家、大小企業、モバイルネットワーク、一時的な顧客に割り当てるべき住所スペースの量です。
This document does not address the issue of the other boundaries in the public topology, that is, between the RIRs and the LIRs.
このドキュメントは、公共トポロジーの他の境界、つまりRIRSとLIRSの間の問題に対処していません。
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からRIRSへの推奨事項です。
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.
アドレス配分に適用される技術原則は、健全な保全の実践と知恵と特定のアクセスのバランスをとることを求めています。一方では、潜在的に限られたリソースを管理する場合、予想される生涯以内の疲労を防ぐために賢明に保存する必要があります。一方、IPv6アドレス空間は、IPv4アドレス空間ほどリソースに限定されていないという意味ではなく、不当な保守主義は、すでに他の要因によって衰退している市場で妨害されるものとして機能します。したがって、市場開発の観点からは、ユーザーまたはISPが即時の変更や非効率性のスケーリングの見通しなしに本当に必要な限り多くのIPv6アドレスを取得することが非常に簡単になることを望んでいます。
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ビットの「ホスト番号」で構成されています。これの技術的な理由はいくつかです。1993年に合意されたIPv6の要件には、約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ルーターへのダイヤルイン接続間で共有されます。ただし、この決定は、客観的に /48の不足がないこと、および個人的なホームネットワークが標準になるという期待に基づいて行われる可能性があります。確かに、国内（家庭）、モバイル（車両または個人）、またはあらゆるサイズの企業など、すべての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デザインで1つのサブネットのみが必要であることがわかっている場合。 - /128 1つのデバイスのみが接続していることが絶対に知られている場合。
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.
- ホームネットワークサブスクライバーは、オンデマンドまたは常に接続されている接続を介してA /48を受信する必要があります。 - 中小企業はA /48を受け取る必要があります。 - 非常に大規模なサブスクライバーは、A /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など）は、1つのサブネットを介した複数のデバイスの接続を可能にする静的 /64プレフィックスを受け取る必要があります。-Subnetを追加する必要のない単一のPCで、ホテルの部屋からダイヤルアップすると、A /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.
将来の成長が予想される場合、A /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 Multihomingにすでに使用されている手法など、IPv6サイトのマルチホームにはさまざまなアプローチがあります。主なオープンな問題は、過度に損傷を与えるルート集約や最適なルート選択なしで大規模にスケーリングするソリューションを見つけることです。この分野ではさらに多くの作業が行われていますが、それぞれが独自の利点と短所を備えたいくつかのアプローチが実際に展開される可能性が高いようです。一部（すべてではありませんが）は、固定されたプレフィックス境界を使用するとより適切に機能します。（Multihomingについては、以下で詳しく説明します。）
- 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).
- より多くのスペースのためにISPに戻る必要なく、加入者のネットワークの容易な成長を可能にするため（A /48で十分ではない比較的少数の加入者を除く）。
- 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:
- サイトがA /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とレジストリは、アドレス消費率の評価に費やされる努力を減らすことができます。長期的な成長計画には住所スペースが十分にあり、追跡と評価の緊急性を減らすことにより、レジストリ操作がより効率的またはより焦点を絞ることができます。 - 住所スペースは顧客にとって貴重なリソースではなくなり、サブスクライバーが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」）をレトロフィッティングする技術的オプションを開くには、グローバルとサイトアドレス指定の固定境界を想定しているロケーターと識別子を分離するための提案。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の場合、6to4プレフィックス（建設による /48）からネイティブIPv6プレフィックスへの移行が簡素化されます。
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).
問題は、すべてのサブスクライバーにA /48を与えることがアドレス空間の豊富な無駄を表すかどうかを当然発生します。客観的な分析は、そうではないことを示しています。001グローバルユニキャストアドレスの下のA /48プレフィックスプレフィックスには、45の可変ビットが含まれています。つまり、利用可能なプレフィックスの数は、パワー45または約35兆（35,184,372,088,832）に2です。
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ビットアドレススペースには1,780億（178千万）の識別子があります。
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.
これは、問題が発生し始める前に、そのスキームに1億7,800億 /48の接頭辞を割り当てる見込みについて快適に感じることを意味します。その数がどれだけ大きいかを理解するには、2050年の地球上の人口である1,780億から100億を比較する必要があります（http://www.census.gov/ipc/www/world.htmlを参照）。これらの数字は、ISPがRIRSのガイダンスの下で /48を慎重に割り当て、IETFが、説得力のある要件が現れない限り、残りの45可変ビットをさらに減らす新しい推奨事項を控えることを条件として、懸念の根拠を与えません。
- 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や他のいくつかのアドレススペースの経験に基づいて、この分析の妥当性に非常に自信があり、インターネットの非常に野心的なスケーリング目標は、1人あたり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.
考慮されるソリューションの1つのクラスは、サイトごとに2つ（またはそれ以上）のプレフィックスの永続的な並列実行に相当します。固定されたプレフィックス境界がない場合、そのようなサイトには、複数の異なる内部サブネット番号の戦略（1つ）が必要な場合、またはそれが必要な場合は、定義されているように最も制限的なものを使用することを余儀なくされる必要があります。ISPのいずれかから受信した最長のプレフィックス。このアプローチでは、マルチホームネットワークには、各アップストリームプロバイダーからのアドレスブロックがあります。各ホストには、アップストリームプロバイダーのセットから選択された1つのアドレスが1つ、または各上流プロバイダーのホストごとに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番目のケース（ホストあたりの複数のアドレス）では、2つのマルチホームネットワークがそれぞれMおよびnアップストリームプロバイダーを担当する場合、接続を開始する1つは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.
このドキュメントは、IETF IPv6局長から発信され、IABとIESGからの多くの入力があります。この文書の基礎を形成する元のテキストは、フレッド・ベイカーとブライアン・カーペンターによって貢献されました。アリソン・マンキンとトーマス・ナルテンは、元の貢献を単一のドキュメントに統合し、アラン・デュランドは最終段階でドキュメントを編集しました。
[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] Bradner、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] Bates、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.、O'Dell、M。、およびS. Deering、「IPv6 Agregatable Global Unicastアドレス形式」、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] Thompson、S。およびT. Narten、「IPv6 Stateless Address Autoconfiguration」、RFC 2462、1998年12月。
[RFC2874] Crawford, M. and C. Huitema, "DNS Extensions to Support IPv6 Address Aggregation and Renumbering", RFC 2874, July 2000.
[RFC2874] Crawford、M。およびC. Huitema、「IPv6アドレスの集約と変更をサポートするDNS拡張」、RFC 2874、2000年7月。
[RFC3041] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[RFC3041] Narten、T。およびR. Draves、「IPv6のステートレスアドレスAutoconfigurationのプライバシー拡張」、RFC 3041、2001年1月。
[MobIPv6] Johnson, D. and C. Perkins, "Mobility Support in IPv6", Work in Progress.
[Mobipv6] Johnson、D。およびC. Perkins、「IPv6のモビリティサポート」、進行中の作業。
Internet Architecture Board
インターネットアーキテクチャボード
Email: iab@iab.org
Internet Engineering Steering Group
インターネットエンジニアリングステアリンググループ
Email: iesg@ietf.org
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。