Network Working Group G. Huston
Request for Comments: 4692 APNIC
Category: Informational October 2006
Considerations on the IPv6 Host Density Metric
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 (2006).
著作権（C）インターネット協会（2006）。
Abstract
抽象
This memo provides an analysis of the Host Density metric as it is currently used to guide registry allocations of IPv6 unicast address blocks. This document contrasts the address efficiency as currently adopted in the allocation of IPv4 network addresses and that used by the IPv6 protocol. Note that for large allocations there are very significant variations in the target efficiency metric between the two approaches.
このメモは、現在、IPv6ユニキャストアドレスブロックのレジストリ割り当てを案内するために使用されるメトリックホスト密度の分析を提供します。このドキュメントは、現在のIPv4ネットワークアドレスの割当ておよびIPv6プロトコルによって使用されることを採用アドレス効率を対比します。大割り当てのための2つのアプローチの間のメトリック目標効率の非常に有意な変動があることに注意してください。
Table of Contents
目次
1. Introduction ....................................................2
2. IPv6 Address Structure ..........................................2
3. The Host Density Ratio ..........................................3
4. The Role of an Address Efficiency Metric ........................4
5. Network Structure and Address Efficiency Metric .................6
6. Varying the HD-Ratio ............................................7
6.1. Simulation Results .........................................8
7. Considerations .................................................10
8. Security Considerations ........................................11
9. Acknowledgements ...............................................11
10. References ....................................................12
10.1. Normative References .....................................12
10.2. Informative References ...................................12
Appendix A. Comparison Tables ....................................13
Metrics of address assignment efficiency are used in the context of the Regional Internet Registries' (RIRs') address allocation function. Through the use of a common address assignment efficiency metric, individual networks can be compared to a threshold value in an objective fashion. The common use of this metric is to form part of the supporting material for an address allocation request, demonstrating that the network has met or exceeded the threshold address efficiency value, and it forms part of the supportive material relating to the justification of the allocation of a further address block.
アドレス割当効率の指標は、地域インターネットレジストリ（のRIR）アドレス割り当て機能との関連で使用されています。共通アドレス割当効率メトリックを使用することによって、個々のネットワークは、対物様式で閾値と比較することができます。このメトリックの一般的な使用は、ネットワークに達するか、閾値アドレス効率値を超えたことを実証し、アドレス割当要求のための支持材料の一部を形成することであり、それはの割り当ての正当化に関連する支持材料の一部を形成しますさらにアドレスブロック。
Public and private IP networks have significant differences in purpose, structure, size, and technology. Attempting to impose a single efficiency metric across this very diverse environment is a challenging task. Any address assignment efficiency threshold value has to represent a balance between stating an achievable outcome for any competently designed and operated service platform while without setting a level of consumption of address resources that imperils the protocol's longer term viability through consequent address scarcity. There are a number of views relating to address assignment efficiency, both in terms of theoretic analyses of assignment efficiency and in terms of practical targets that are part of current address assignment practices in today's Internet.
パブリックおよびプライベートIPネットワークは、目的、構造、大きさ、および技術に大きな違いがあります。この非常に多様な環境全体で単一の効率メトリックを課すことをしようとすると困難な作業です。任意のアドレス割当効率閾値は、結果として、アドレス不足を介してプロトコルの長期生存率をimperilsアドレスリソースの消費レベルを設定せず、一方、任意の有能設計および操作サービスプラットフォームのための達成可能な結果を述べるとの間のバランスを表現しなければなりません。アドレス割り当て効率に関連するビューの数が割り当て効率の理論的分析の観点から、今日のインターネットの現在のアドレス割り当て慣行の一部で実用的な目標の両方の観点から、があります。
This document contrasts the address efficiency metric and threshold value as currently adopted in the allocation of IPv4 network addresses and the framework used by the address allocation process for the IPv6 protocol.
このドキュメントは、現在のIPv4ネットワークアドレスの割当とIPv6プロトコルのためのアドレス割当処理で使用されるフレームワークに採用アドレス効率メトリックと閾値とを対比します。
Before looking at address allocation efficiency metrics, it is appropriate to summarize the address structure for IPv6 global unicast addresses.
アドレス割り当て効率指標を見る前に、IPv6グローバルユニキャストアドレスのアドレス構造を要約することが適切です。
The general format for IPv6 global unicast addresses is defined in [RFC4291] as follows (Figure 1).
IPv6グローバルユニキャストアドレスの一般的な形式は、（図1）を次のように[RFC4291]で定義されています。
| 64 - m bits | m bits | 64 bits |
+------------------------+-----------+----------------------------+
| global routing prefix | subnet ID | interface ID |
+------------------------+-----------+----------------------------+
IPv6 Address Structure
IPv6アドレスの構造
Figure 1
図1
Within the current policy framework for allocation of IPv6 addresses in the context of the public Internet, the value for 'm' in the figure above, referring to the subnet ID, is commonly a 16-bit field. Therefore, the end-site global routing prefix is 48 bits in length, the per-customer subnet ID is 16 bits in length, and the interface ID is 64 bits in length [RFC3177].
公共のインターネットの文脈におけるIPv6アドレスの割り当てのための現在のポリシーのフレームワーク内で、サブネットIDを参照して上図の「M」の値は、一般に16ビットのフィールドです。したがって、エンドサイトのグローバルルーティングプレフィックスの長さは48ビットであり、毎顧客サブネットIDの長さは16ビットであり、インタフェースIDは、長さが64ビット[RFC3177]です。
In relating this address structure to the address allocation function, the efficiency metric is not intended to refer to the use of individual 128-bit IPv6 addresses nor that of the use of the 64- bit subnet prefix. Instead, it is limited to a measure of efficiency of use of the end-site global routing prefix. This allocation model assumes that each customer is allocated a minimum of a single /48 address block. Given that this block allows 2^16 possible subnets, it is also assumed that a /48 allocation will be used in the overall majority of cases of end-customer address assignment.
アドレス割当機能にこのアドレス構造に関連において、効率メトリックは、64ビットのサブネットプレフィックスの使用の個々の128ビットのIPv6アドレスの使用も、それを参照するように意図されていません。その代わりに、エンドサイトグローバルルーティングプレフィクスの使用効率の尺度に限定されています。この割り当てモデルは、各顧客が単一の/ 48アドレスブロックの最小値を割り当てられていることを前提としています。このブロックは、2 ^ 16の可能なサブネットを可能にすることを考えると、また、/ 48割り当ては、エンド顧客のアドレス割り当ての症例の大部分全体で使用されることが想定されます。
The following discussion makes the assumption that the address allocation unit in IPv6 is an address prefix of 48 bits in length, and that the address assignment efficiency in this context is the efficiency of assignment of /48 address allocation units. However, the analysis presented here refers more generally to end-site address allocation practices rather than /48 address prefixes in particular, and is applicable in the context of any size of end-site global routing prefix.
以下の議論は、IPv6のアドレス割り当て部は、長さが48ビットのアドレスプレフィックスであり、この文脈におけるアドレス割り当て効率が/ 48アドレスアロケーションユニットの割り当ての効率であるという仮定を行います。しかし、ここに提示分析は、特にエンドサイトアドレス割り当て慣行ではなく/ 48アドレスプレフィックスをより一般的にいうと、エンドサイトのグローバルルーティングプレフィックスの任意のサイズの文脈において適用可能です。
The "Host Density Ratio" was first described in [RFC1715] and subsequently updated in [RFC3194].
「ホスト密度比は、」最初の[RFC1715]で説明し、その後、[RFC3194]に更新されました。
The "H Ratio", as defined in RFC 1715, is:
RFC 1715で定義されている「H比」は、次のとおりです。
log (number of objects)
H = -----------------------
available bits
Figure 2
図2
The argument presented in [RFC1715] draws on a number of examples to support the assertion that this metric reflects a useful generic measure of address assignment efficiency in a range of end-site addressed networks, and furthermore that the optimal point for such a utilization efficiency metric lies in an H Ratio value between 0.14 and 0.26. Lower H Ratio values represent inefficient address use, and higher H Ratio values tend to be associated with various forms of additional network overhead related to forced re-addressing operations.
[RFC1715]に提示引数は、このメトリックは、エンドサイトの範囲内のアドレス割り当て効率の有用な一般的な尺度はネットワークに対処し、さらにそのような利用効率のための最適なポイントことを反映するという主張を支持するために例の数に描画しますメトリックは、0.14と0.26の間にH比の値です。低いH比の値は、非効率的なアドレスの使用を示し、より高いH比値強制再アドレッシング動作に関連する追加のネットワーク・オーバーヘッドの様々な形態と関連する傾向があります。
This particular metric has a maximal value of log base 10 of 2, or 0.30103.
この特定のメトリックは、ログ2のベース10、または0.30103の極大値を有しています。
The metric was 'normalized' in RFC 3194, and a new metric, the "HD-Ratio" was introduced, with the following definition:
メトリックは、RFC 3194で「正規化」だった、と新しいメトリック、「HD-比」は次のように定義して、導入されました：
log(number of allocated objects)
HD = ------------------------------------------
log(maximum number of allocatable objects)
Figure 3
図3
HD-Ratio values are proportional to the H ratio, and the values of the HD-Ratio range from 0 to 1. The analysis described in [RFC3194] applied this HD-Ratio metric to the examples given in [RFC1715] and, on the basis of these examples, postulated that HD-Ratio values of 0.85 or higher force the network into some form of renumbering. HD-Ratio values of 0.80 or lower were considered an acceptable network efficiency metric.
HD-比の値は、H比に比例し、そして0から1にHD-比範囲の値[RFC3194]で説明分析は[RFC1715]で与えられた例に、このHD-レシオメトリックを適用し、オンこれらの実施例の基礎は、0.85以上のHD-比の値は、リナンバリングのいくつかのフォームにネットワークを強制すると仮定しました。 0.80以下のHD-比の値は、許容されるネットワーク効率メトリックと考えられました。
The HD-Ratio is referenced within the IPv6 address allocation policies used by the Regional Internet Registries, and their IPv6 address allocation policy documents specify that an HD-Ratio metric of 0.8 is an acceptable objective in terms of address assignment efficiency for an IPv6 network.
HD-比率は、地域インターネットレジストリによって使用されたIPv6アドレスの割り当てポリシー内で参照され、そのIPv6アドレス割り当てポリシー文書は、0.8のHD-レシオメトリックは、IPv6ネットワークのためのアドレス割り当て効率の面で許容できる客観的であることを指定します。
By contrast, the generally used address efficiency metric for IPv4 is the simple ratio of the number of allocated (or addressed) objects to the maximum number of allocatable objects. For IPv4, the commonly applied value for this ratio is 0.8 (or 80%).
対照的に、IPv4の一般的に使用されるアドレス効率メトリックが割り当てオブジェクトの最大数に割り当てられた（またはアドレス指定）オブジェクトの数の単純な比です。 IPv4の場合、この比は一般的に適用される値は、0.8（又は80％）です。
A comparison of these two metrics is given in Table 1 of Attachment A.
これら2つのメトリックの比較は、別紙Aの表1に与えられています
The role of the address efficiency metric is to provide objective metrics relating to a network's use of address space that can be used by both the allocation entity and the applicant to determine whether an address allocation is warranted, and provide some indication of the size of the address allocation that should be undertaken. The metric provides a target address utilization level that indicates at what point a network's address resource may be considered "fully utilized".
アドレス効率メトリックの役割は、アドレス割り当てが保証されるかどうかを決定するために割り当てエンティティと出願人の両方で使用可能なアドレス空間のネットワークの使用に関連する客観的指標を提供し、サイズのいくつかの指標を提供することです行うべきアドレス割り当て。メトリックは、どの時点でネットワークのアドレスリソースは、「十分に活用」と考えることができる示し、ターゲットアドレスの使用率レベルを提供します。
The objective here is to allow the network service provider to deploy addresses across both network infrastructure and the network's customers in a manner that does not entail periodic renumbering, and in a manner that allows both the internal routing system and inter-domain routing system to operate without excessive fragmentation of the address space and consequent expansion of the number of route objects carried within the routing systems. This entails use of an addressing plan where at each level of structure within the network there is a pool of address blocks that allows expansion of the network at that structure level without requiring renumbering of the remainder of the network.
ここでの目的は、ネットワークサービスプロバイダは、定期的な再番号付けを必要としない方法で、両方のネットワークインフラストラクチャ全体アドレスとネットワークの顧客を展開できるようにすることで、内部ルーティングシステムおよびドメイン間ルーティングシステムの両方が動作することを可能にする方法で、アドレス空間の過剰な断片化およびルーティングシステム内で搬送ルートオブジェクトの数の結果として膨張せず。これは、ネットワーク内の構造の各レベルでネットワークの残りのリナンバリングを必要とすることなく、その構造レベルでのネットワークの拡張を可能にするアドレスブロックのプールがあるアドレッシング計画の使用を伴います。
It is recognized that an address utilization efficiency metric of 100% is unrealistic in any scenario. Within a typical network address plan, the network's address space is exhausted not when all address resources have been used, but at the point when one element within the structure has exhausted its pool, and when augmentation of this pool by drawing from the pools of other elements would entail extensive renumbering. While it is not possible to provide a definitive threshold of what overall efficiency level is obtainable in all IP networks, experience with IPv4 network deployments suggests that it is reasonable to observe that at any particular level within a hierarchically structured address deployment plan an efficiency level of between 60% to 80% is an achievable metric in the general case.
100％のアドレス利用効率メトリックはどのシナリオでは非現実的であることが認識されています。典型的なネットワークアドレス計画の中で、ネットワークのアドレス空間は、すべてのアドレスリソースが使用されていないとき排出されるが、ポイントで構造内の一つの要素は、そのプールを使い果たしたとき、そしてときに、他のプールから描画することにより、このプールの増強要素は、大規模な再番号付けを伴うだろう。全体的な効率レベルはすべてIPネットワークで得られるものの決定的なしきい値を提供することはできませんが、IPv4ネットワークの展開での経験は、階層構造のアドレス展開計画の効率レベル内の任意の特定のレベルでそれを観察するのが妥当であることを示唆しています80％〜60％の間には一般的な場合に達成メトリックです。
This IPv4 efficiency threshold is significantly greater than that observed in the examples provided in conjunction with the HD-Ratio description in [RFC1715]. Note that the examples used in the HD-Ratio are drawn from, among other sources, the Public Switched Telephone Network (PSTN). This comparison with the PSTN warrants some additional examination. There are a number of differences between public IP network deployments and PSTN deployments that may account for this difference. IP addresses are deployed on a per-provider basis with an alignment to network topology. PSTN addresses are, on the whole, deployed using a geographical distribution system of "call areas" that share a common number prefix. Within each call area, a sufficient number blocks from the number prefix must be available to allow each operator to draw their own number block from the area pool. Within the IP environment, service providers do not draw address blocks from a common geographic number pool but receive address blocks from the Regional Internet Registry on a 'whole of network' basis. This difference in the address structure allows an IP environment to achieve an overall higher level of address utilization efficiency.
このIPv4の効率閾値は[RFC1715]でHD比の説明に関連して提供される例において観察されたものよりも有意に大きいです。 HD-比率で使用される例は、他のソースの中から引き出されていることに注意してください、公衆交換電話網（PSTN）。 PSTNとのこの比較は、いくつかの追加の検査を保証します。この違いを説明することができるパブリックIPネットワークの展開とPSTNの展開の違いがいくつかあります。 IPアドレスは、ネットワークトポロジに整列してあたりのプロバイダに基づいて展開されています。 PSTNアドレスは、全体的に、共通番号のプレフィックスを共有する「通話エリア」の地理的分布システムを使用して展開されています。各通話エリア内では、番号のプレフィックスから、十分な数のブロックは、各オペレータがエリアプールから自分の番号ブロックを描画できるようにするために使用可能でなければなりません。 IP環境では、サービスプロバイダは、共通の地理的な番号プールからアドレスブロックを描画しませんが、「ネットワーク全体の」基づいて地域インターネットレジストリからアドレスブロックを受け取ります。アドレス構造の違いは、アドレスの利用効率の全体的な、より高いレベルを達成するためのIP環境を可能にします。
In terms of considering the number of levels of internal hierarchy in IP networks, the interior routing protocol, if uniformly deployed, admits a hierarchical network structure that is only two levels deep, with a fully connected backbone "core" and a number of satellite areas that are directly attached to this "core". Additional levels of routing hierarchy may be obtained using various forms of routing confederations, but this is not an extremely common deployment technique. The most common form of network structure used in large IP networks is a three-level structure using regions, individual Points of Presence (POPs), and end-customers.
IPネットワークの内部階層のレベル数を考慮の観点から、内部のルーティングプロトコルは、一様に展開されている場合、完全に接続されたバックボーン「コア」とサテライト領域の数と、2つだけのレベルの深さの階層ネットワーク構造を認めますそれは直接、この「コア」に添付されています。ルーティング階層の付加的なレベルは、ルーティング同盟の様々な形態を使用して得ることができるが、これは非常に一般的な展開技術ではありません。大規模なIPネットワークで使用されるネットワーク構造の最も一般的な形態は、領域、プレゼンスの個々の点（のPOP）、およびエンド顧客を使用して、3つのレベルの構造です。
Also, note that large-scale IP deployments typically use a relatively flat routing structure, as compared to a deeply hierarchical structure. In order to improve the dynamic performance of the interior routing protocol the number of routes carried in the interior routing protocol, is commonly restricted to the routes corresponding to next-hop destinations for iBGP routes, and customer routes are carried in the iBGP domain and aggregated at the point where the routes are announced in eBGP sessions. This implies that per-POP or per-region address aggregations according to some fixed address hierarchy is not a necessary feature of large IP networks, so strict hierarchical address structure within all parts of the network is not a necessity in such routing environments.
また、深い階層構造と比較して、大規模なIP導入は、典型的には、比較的平坦なルーティング構造を使用することに注意してください。内部ルーティングプロトコルで運ばれるルートの数を内部ルーティングプロトコルの動的性能を向上させるために、一般にiBGPルートのネクストホップの宛先に対応するルートに制限され、顧客ルートはiBGPのドメインに運ばれ、凝集ルートはeBGPセッションで発表されている時点で。これは、いくつかの固定アドレス階層に従ってPOP単位または領域アドレス集計が大きいIPネットワークの必要な特徴ではないことを意味し、ネットワークのすべての部分内そう厳密階層アドレス構造は、ルーティング環境で必要ではありません。
An address efficiency metric can be expressed using the number of levels of structure (n) and the efficiency achieved at each level (e). If the same efficiency threshold is applied at each level of structure, the resultant efficiency threshold is e^n. This then allows us to make some additional observations about the HD-Ratio values. Table 2 of Appendix A (Figure 8) indicates the number of levels of structure that are implied by a given HD-Ratio value of 0.8 for each address allocation block size, assuming a fixed efficiency level at all levels of the structure. The implication is that for large address blocks, the HD-Ratio assumes a large number of elements in the hierarchical structure, or a very low level of address efficiency at the lower levels. In the case of IP network deployments, this latter situation is not commonly the case.
アドレス効率メトリックは、構造のレベルの数（N）と、各レベル（E）で達成効率を使用して発現させることができます。同じ効率閾値は構造の各レベルで適用される場合、結果として得られる効率閾値はE ^ nです。そして、これは私たちがHD-比の値についてのいくつかの追加の観測を行うことができます。付録A（図8）の表2は、構造のすべてのレベルで一定の効率レベルを仮定すると、各アドレス割当ブロックサイズに対して0.8の所与HD-比の値によって暗示されている構造のレベルの数を示しています。含意は大きなアドレスブロックに対して、HD-比は、階層構造内の要素の数が多い、またはより低いレベルでアドレス効率の非常に低いレベルになることです。 IPネットワークの展開の場合は、この後者の状況は、一般的にそうではありません。
The most common form of interior routing structure used in IP networks is a two-level routing structure. It is consistent with this constrained routing architecture that network address plans appear to be commonly devised using up to a three-level hierarchical structure, while for larger networks a four-level structure may generally be used.
IPネットワークで使用される内部のルーティング構造の最も一般的な形態は、2レベルの配線構造です。これは、ネットワークアドレス計画は大規模ネットワークのための4レベルの構造は、一般的に使用することができるが、一般的に、3レベルの階層構造まで使用して考案されるように見えるこの制約ルーティングアーキテクチャと一致しています。
Table 3 of Attachment A (Figure 9) shows an example of address efficiency outcomes using a per-level efficiency metric of 0.75 (75%) and a progressively deeper network structure as the address block expands. This model (termed here "limited levels") limits the maximal number of levels of internal hierarchy to 6 and uses a model where the number of levels of network hierarchy increases by 1 when the network increases in size by a factor of a little over one order of magnitude.
テーブルアタッチメントAの3（図9）は、アドレスブロックが拡張として0.75（75％）の単位のレベルの効率メトリックと徐々に深くネットワーク構造を用いたアドレス効率の結果の一例を示しています。このモデル（ここでは呼ばれる「制限されたレベルが」）6内部の階層レベルの最大数を制限一強倍サイズが1と、ネットワーク増加によるネットワーク階層増加のレベルの数モデルを使用します大きさの順。
It is illustrative to compare these metrics for a larger network deployment. If, for example, the network is designed to encompass 8 million end customers, each of which is assigned a 16-bit subnet ID for their end site, then the following table Figure 4 indicates the associated allocation size as determined by the address efficiency metric.
大規模なネットワーク展開のためのこれらの指標を比較する例示です。例えば、ネットワークは、そのエンドサイトの16ビットのサブネットIDが割り当てられ、それぞれが800万人のエンド顧客を包含するように設計されている場合、アドレス効率メトリックによって決定されるように、次のテーブル図4は、関連割り当てサイズを示します。
Allocation: 8M Customers
割当：8Mのお客様
Allocation Relative Ratio
割当相対比
100% Allocation Efficiency /25 1 80% Efficiency (IPv4) /24 2 0.8 HD-Ratio /19 64 75% with Limited Level /23 4 0.94 HD-Ratio /23 4
100％割り当て効率/ 25 1〜80％の効率（IPv4）の限定レベル/ 23 4 0.94 HD比/ 23 4と/ 24 2 0.8 HD比/ 19 64 75％
Figure 4
図4
Note that the 0.8 HD-Ratio produces a significantly lower efficiency level than the other metrics. The limited-level model appears to point to a more realistic value for an efficiency value for networks of this scale (corresponding to a network with 4 levels of internal hierarchy, each with a target utilization efficiency of 75%). This limited-level model corresponds to an HD-Ratio with a threshold value of 0.945.
0.8 HD-比が他の指標よりも有意に低い効率レベルを生成することに留意されたいです。限られたレベルのモデルは、（内部階層の4つのレベル、75％のターゲット利用効率のそれぞれにネットワークに対応する）は、この規模のネットワークのための効率値のためのより現実的な値を指すように見えます。この限られたレベルのモデルは、0.945の閾値とHD-比に相当します。
One way to model the range of outcomes of taking a more limited approach to the number of levels of aggregateable hierarchy is to look at a comparison of various values for the HD-Ratio with the model of a fixed efficiency and the "Limited Levels" model. This is indicated in Figure 5.
aggregateable階層のレベルの数により限定されたアプローチを取っての結果の範囲をモデル化する一つの方法は、固定された効率のモデルと「リミテッドレベル」モデルとHD-比のための様々な値の比較を見ることです。これは図5に示されています。
Prefix Length (bits)
|
|
| Limited HD-Ratio
| Levels 0.98 0.94 0.90 0.86 0.82 0.80
| | | | | | | |
1 0.750 0.986 0.959 0.933 0.908 0.883 0.871
4 0.750 0.946 0.847 0.758 0.678 0.607 0.574
8 0.750 0.895 0.717 0.574 0.460 0.369 0.330
12 0.563 0.847 0.607 0.435 0.312 0.224 0.189
16 0.563 0.801 0.514 0.330 0.212 0.136 0.109
20 0.422 0.758 0.435 0.250 0.144 0.082 0.062
24 0.422 0.717 0.369 0.189 0.097 0.050 0.036
28 0.316 0.678 0.312 0.144 0.066 0.030 0.021
32 0.316 0.642 0.264 0.109 0.045 0.018 0.012
36 0.237 0.607 0.224 0.082 0.030 0.011 0.007
40 0.237 0.574 0.189 0.062 0.021 0.007 0.004
44 0.178 0.543 0.160 0.047 0.014 0.004 0.002
48 0.178 0.514 0.136 0.036 0.009 0.003 0.001
Figure 5
図5
As shown in this figure, it is possible to select an HD-Ratio value that models IP level structures in a fashion that behaves more consistently for very large deployments. In this case, the choice of an HD-Ratio of 0.94 is consistent with a limited-level model of up to 6 levels of hierarchy with a metric of 75% density at each level. This correlation is indicated in Table 3 of Attachment A.
この図に示すように、非常に大規模な導入のために、より一貫して振る舞いの方法でモデルIPレベルの構造をHD-比の値を選択することが可能です。この場合には、0.94のHD比の選択は、各レベルで75％の密度のメトリックを持つ階層の最大6つのレベルの限られたレベルのモデルと一致しています。この相関は、添付Aの表3に示されています
In attempting to assess the impact of potentially changing the HD-Ratio to a lower value, it is useful to assess this using actual address consumption data. The results described here use the IPv4 allocation data as published by the Regional Internet Registries [RIR-Data]. The simulation work assumes that the IPv4 delegation data uses an IPv4 /32 for each end customer, and that assignments have been made based on an 80% density metric in terms of assumed customer count. The customer count is then used as the basis of an IPv6 address allocation, using the HD-Ratio to map from a customer count to the size of an address allocation.
潜在的に低い値にHD-比を変更の影響を評価しようとするには、実際のアドレス消費データを使用して、これを評価するために有用です。ここに記載した結果は、地域インターネットレジストリ[RIR-データ]により公開されたIPv4割り当てデータを使用します。シミュレーション作業は、IPv4委任データが各エンドユーザのIPv4 / 32を使用することを前提とし、割り当てが想定顧客数の点でメトリック80％の密度に基づいて行われていること。顧客数は、アドレス割り当てのサイズに顧客数からマップするためにHD-比率を使用して、IPv6アドレス割り当ての基礎として使用されます。
The result presented here is that of a simulation of an IPv6 address allocation registry, using IPv4 allocation data as published by the RIRs spanning the period from January 1, 1999 until August 31, 2004. The aim is to identify the relative level of IPv6 address consumption using a IPv6 request size profile based on the application of various HD-Ratio values to the derived customer numbers.
ここに提示した結果は、8月31日まで1999年1月1日からの期間にまたがるのRIRによって発行されたIPv4の割り当てデータを使用して、IPv6アドレスの割り当てレジストリのシミュレーション、で、2004年の目標は、IPv6アドレスの相対的なレベルを識別することであるということです派生顧客番号への各種HD-比の値の適用に基づいてIPv6の要求サイズのプロファイルを使用して消費。
The profile of total address consumption for selected HD-Ratio values is indicated in Figure 6. The simulation results indicate that the choice of an HD-Ratio of 0.8 consumes a total of 7 times the address space of that consumed when using an HD-Ratio of 0.94.
選択されたHD-比の値の合計アドレスの消費量のプロファイルは、シミュレーション結果は、0.8のHD-比の選択は、HD-比率を使用したときにの7倍のアドレス空間の合計が消費を消費することを示す図6に示されています0.94の。
HD-Ratio Total Address Consumption
| Prefix Length Count of
| Notation /32 prefixes
0.80 /14.45 191,901
0.81 /14.71 160,254
0.82 /15.04 127,488
0.83 /15.27 108,701
0.84 /15.46 95,288
0.85 /15.73 79,024
0.86 /15.88 71,220
0.87 /16.10 61,447
0.88 /16.29 53,602
0.89 /16.52 45,703
0.90 /16.70 40,302
0.91 /16.77 38,431
0.92 /16.81 37,381
0.93 /16.96 33,689
0.94 /17.26 27,364
0.95 /17.32 26,249
0.96 /17.33 26,068
0.97 /17.33 26,068
0.98 /17.40 24,834
0.99 /17.67 20,595
Figure 6
図6
The implication of these results imply that an IPv6 address registry will probably see sufficient distribution of allocation request sizes such that the choice of a threshold HD-Ratio will impact the total address consumption rates, and the variance between an HD-Ratio of 0.8 and an HD-Ratio of 0.99 is a factor of one order of magnitude in relative address consumption over an extended period of time. The simulation also indicates that the overall majority of allocations fall within a /32 minimum allocation size (between 74% to 95% of all address allocations), and that the selection of a particular HD-Ratio value has a significant impact in terms of allocation sizes for a small proportion of allocation transactions (the remainder of allocations range between a /19 to a /31 for an HD-Ratio of 0.8 and between a /26 and a /31 for an HD-Ratio of 0.99).
これらの結果の意味するところは、IPv6アドレスのレジストリは、おそらく十分なしきい値HD-比の選択は、全アドレス消費率に影響を与えるような割り当て要求サイズの分布、および0.8のHD-比とANとの間に差異が表示されますことを意味するもの150のHD-比率は、長期間にわたって相対アドレスの消費量の一桁の要因です。シミュレーションはまた、割り当ての全体的な大部分が（74％の間の全てのアドレス割り当ての95％）最小割り当てサイズ/ 32に入ることを示し、そして特定のHD-比の値の選択は、割当の点で重大な影響を有すること割り当てトランザクションの少量のためにサイズ（割り当ての残りは0.8のHD-比について、および/ 26および150のHD比/ 31間/ 31/19の範囲で）。
The conclusion here is that the choice of the HD-Ratio will have some impact on one quarter of all allocations, while the remainder are serviced using the minimum allocation unit of a /32 address prefix. Of these 'impacted' allocations that are larger than the minimum allocation, approximately one tenth of these allocations are 'large' allocations. These large allocations have a significant impact on total address consumption, and varying the HD-Ratio for these allocations between 0.8 to 0.99 results in a net difference in total address consumption of approximately one order of magnitude. This is a heavy-tail distribution, where a small proportion of large address allocations significantly impact the total address consumption rate. Altering the HD-Ratio will have little impact on more than 95% of the IPv6 allocations but will generate significant variance within the largest 2% of these allocations, which, in turn, will have a significant impact on total address consumption rates.
ここでの結論は、残りは/ 32アドレスプレフィックスの最小割り当て単位を使用してサービスを提供している一方、HD-比の選択は、すべての割り当ての四分の一に何らかの影響を持っているということです。最小割り振りよりも大きいこれらの「影響」の割り当てのために、これらの割り当ての約1/10「大きい」配分です。これらの大規模な割り当ては、全アドレスの消費量に大きな影響を持っており、約1桁の合計アドレス消費のネット差が0.8から0.99の結果との間にこれらの割り当てのためにHD-比を変化させます。これは、大規模なアドレス割り当ての小さな割合が有意総アドレス消費率に影響を与える重テール分布、です。 HD-比を変更すると、IPv6割り振りの95％以上にはほとんど影響を与えますが、今度は、総アドレス消費率に大きな影響を与えるだろう、これらの割り当て、最大2％以内の重要な差異を生成します。
The HD-Ratio with a value of 0.8 as a model of network address utilization efficiency produces extremely low efficiency outcomes for networks spanning of the order of 10**6 end customers and larger.
ネットワークアドレスの利用効率のモデルとして、0.8の値を持つHD-比率は10人の** 6最終顧客とより大きな程度に及ぶネットワークのための非常に低い効率の結果を生成します。
The HD-Ratio with a 0.8 value makes the assumption that as the address allocation block increases in size, the network within which the addresses will be deployed adds additional levels of hierarchical structure. This increasing depth of hierarchical structure to arbitrarily deep hierarchies is not a commonly observed feature of public IP network deployments.
0.8の値を持つHD比は、サイズのアドレス割当ブロックが増加すると、アドレスが展開される内ネットワークは、階層構造の追加のレベルを追加することを仮定しています。階層構造の任意の深い階層のこの増加深さは、パブリックIPネットワークの展開の一般的に観察機能ではありません。
The fixed efficiency model, as used in the IPv4 address allocation policy, uses the assumption that as the allocation block becomes larger, the network structure remains at a fixed level of levels; if the number of levels is increased, then efficiency achieved at each level increases significantly. There is little evidence to suggest that increasing a number of levels in a network hierarchy increases the efficiency at each level.
固定された効率モデルは、IPv4のアドレス割り当てポリシーで使用されるように、アロケーションブロックが大きいほど、ネットワーク構造はレベルの一定レベルのままであるという仮定を使用します。レベルの数が増加する場合、効率が大幅に各レベルの増加で達成しました。ネットワーク階層内のレベルの数を増加させると、各レベルでの効率を増加させることを示唆する証拠はほとんどありません。
It is evident that neither of these models accurately encompass IP network infrastructure models and the associated requirements of address deployment. The fixed efficiency model places an excessive burden on the network operator to achieve very high levels of utilization at each level in the network hierarchy, leading to either customer renumbering or deployment of technologies such as Network Address Translation (NAT) to meet the target efficiency value in a hierarchically structured network. The HD-Ratio model using a value of 0.8 specifies an extremely low address efficiency target for larger networks, and while this places no particular stress on network architects in terms of forced renumbering, there is the concern that this represents an extremely inefficient use of address resources. If the objective of IPv6 is to encompass a number of decades of deployment, and to span a public network that ultimately encompasses many billions of end customers and a very high range and number of end use devices and components, then there is legitimate cause for concern that the HD-Ratio value of 0.8 may be setting too conservative a target for address efficiency, in that the total address consumption targets may be achieved too early.
これらのモデルのいずれもが正確にIPネットワークインフラストラクチャモデルとアドレス展開の関連する要求事項を包含することは明らかです。固定効率モデルは、目標効率値を満たすために、顧客のリナンバリングや、ネットワークアドレス変換（NAT）などの技術の展開のいずれかにつながる、ネットワーク階層の各レベルでの利用の非常に高いレベルを達成するために、ネットワークオペレータに過度の負担を課します階層構造のネットワークインチ0.8の値を使用してHD-比モデルは、大規模なネットワークのための非常に低いアドレス効率ターゲットを指定し、これは強制的なリナンバリングの面でネットワーク設計には特にストレスを置いていないが、これはアドレスの極めて非効率的な使用を表していることが懸念されます資源。 IPv6のの目的は、展開の数十年の数を包含するように、そして最終的には最終顧客と非常に高い範囲と最終使用機器および部品の数の多くの十億を含むパブリックネットワークにまたがることであれば、懸念の正当な原因があります総アドレス消費量目標はあまりにも早く達成することができるという点で、0.8のHD-比の値は、アドレスの効率化のためにあまりにも保守的な目標を設定することができること。
This study concludes that consideration should be given to the viability of specifying a higher HD-Ratio value as representing a more relevant model of internal network structure, internal routing, and internal address aggregation structures in the context of IPv6 network deployment.
この研究は、対価がIPv6ネットワーク展開の文脈における内部ネットワーク構造、内部ルーティング、および内部アドレス集約構造のより適切なモデルを表すものとして高いHD-比の値を指定することの実現可能性を考慮すべきであると結論づけています。
Considerations of various forms of host density metrics create no new threats to the security of the Internet.
ホスト密度指標の様々な形の考慮事項は、インターネットのセキュリティへの新しい脅威を作成しません。
The document was reviewed by Kurt Lindqvist, Thomas Narten, Paul Wilson, David Kessens, Bob Hinden, Brian Haberman, and Marcelo Bagnulo.
文書はクルトLindqvist、トーマスNarten氏、ポール・ウィルソン、デヴィッドKessens、ボブHindenとブライアンハーバーマン、とマルセロBagnuloにより検討しました。
[RFC1715] Huitema, C., "The H Ratio for Address Assignment Efficiency", RFC 1715, November 1994.
[RFC1715]のHuitema、C.、 "アドレス割り当ての効率化のためのH比"、RFC 1715、1994年11月。
[RFC3177] IAB and IESG, "IAB/IESG Recommendations on IPv6 Address Allocations to Sites", RFC 3177, September 2001.
[RFC3177] IABとIESG、RFC 3177、2001年9月 "サイトへのIPv6アドレスの割り当てにIAB / IESG勧告"。
[RFC3194] Durand, A. and C. Huitema, "The H-Density Ratio for Address Assignment Efficiency An Update on the H ratio", RFC 3194, November 2001.
[RFC3194]デュラン、A.及びC.のHuitema、 "アドレス割り当て効率のためにH-密度比H比でアップデート"、RFC 3194、2001年11月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291] HindenとR.とS.デアリング、 "IPバージョン6アドレッシング体系"、RFC 4291、2006年2月。
[RIR-Data] RIRs, "RIR Delegation Records", February 2005, <ftp://ftp.apnic.net/pub/stats/>.
[RIR-データ]のRIR、 "RIR委任レコード"、2005年2月、<ftp://ftp.apnic.net/pub/stats/>。
Appendix A. Comparison Tables
付録A.比較表
The first table compares the threshold number of /48 end user allocations that would be performed for a given assigned address block in order to consider that the utilization has achieved its threshold utilization level.
最初の表は、利用率がその閾値利用レベルを達成したことを考慮するために与えられた割り当てられたアドレスブロックのために実行される/ 48エンドユーザー割り当ての閾値数とを比較します。
Fixed Efficiency Value 0.8 HD-Ratio Value 0.8
固定効率値0.8 HD-比の値0.8
Number of /48 allocations to fill the
address block to the threshold level
Prefix Size Fixed Efficiency HD-Ratio 0.8 0.8
プレフィックスサイズ固定効率HD-比0.8 0.8
/48 1 1 100% 1 100% /47 2 2 100% 2 87% /46 4 4 100% 3 76% /45 8 7 88% 5 66% /44 16 13 81% 9 57% /43 32 26 81% 16 50% /42 64 52 81% 28 44% /41 128 103 80% 49 38% /40 256 205 80% 84 33% /39 512 410 80% 147 29% /38 1,024 820 80% 256 25% /37 2,048 1,639 80% 446 22% /36 4,096 3,277 80% 776 19% /35 8,192 6,554 80% 1,351 16% /34 16,384 13,108 80% 2,353 14% /33 32,768 26,215 80% 4,096 13% /32 65,536 52,429 80% 7,132 11% /31 131,072 104,858 80% 12,417 9% /30 262,144 209,716 80% 21,619 8% /29 524,288 419,431 80% 37,641 7% /28 1,048,576 838,861 80% 65,536 6% /27 2,097,152 1,677,722 80% 114,105 5% /26 4,194,304 3,355,444 80% 198,668 5% /25 8,388,608 6,710,887 80% 345,901 4% /24 16,777,216 13,421,773 80% 602,249 4% /23 33,554,432 26,843,546 80% 1,048,576 3% /22 67,108,864 53,687,092 80% 1,825,677 3% /21 134,217,728 107,374,180 80% 3,178,688 2% /20 268,435,456 214,748,365 80% 5,534,417 2% /19 536,870,912 429,496,730 80% 9,635,980 2% /18 1,073,741,824 858,993,460 80% 16,777,216 2% /17 2,147,483,648 1,717,986,919 80% 29,210,830 1%
/48 1 1 100% 1 100% /47 2 2 100% 2 87% /46 4 4 100% 3 76% /45 8 7 88% 5 66% /44 16 13 81% 9 57% /43 32 26 81% 16 50% /42 64 52 81% 28 44% /41 128 103 80% 49 38% /40 256 205 80% 84 33% /39 512 410 80% 147 29% /38 1,024 820 80% 256 25% /37 2,048 1,639 80% 446 22% /36 4,096 3,277 80% 776 19% /35 8,192 6,554 80% 1,351 16% /34 16,384 13,108 80% 2,353 14% /33 32,768 26,215 80% 4,096 13% /32 65,536 52,429 80% 7,132 11% /31 131,072 104,858 80% 12,417 9% /30 262,144 209,716 80% 21,619 8% /29 524,288 419,431 80% 37,641 7% /28 1,048,576 838,861 80% 65,536 6% /27 2,097,152 1,677,722 80% 114,105 5% /26 4,194,304 3,355,444 80% 198,668 5% /25 8,388,608 6,710,887 80% 345,901 4% /24 16,777,216 13,421,773 80% 602,249 4% /23 33,554,432 26,843,546 80% 1,048,576 3% /22 67,108,864 53,687,092 80% 1,825,677 3% /21 134,217,728 107,374,180 80% 3,178,688 2% /20 268,435,456 214,748,365 80% 5,534,417 2% /19 536,870,912 429,496,730 80% 9,635,980 2% /18 1,073,741,824 858,993,460 80% 16,777,216 2% /17 2,147,483,648 1,717,986,919 80% 29,210,830 1%
/16 4,294,967,296 3,435,973,837 80% 50,859,008 1% /15 8,589,934,592 6,871,947,674 80% 88,550,677 1% /14 17,179,869,184 13,743,895,348 80% 154,175,683 1% /13 34,359,738,368 27,487,790,695 80% 268,435,456 1% /12 68,719,476,736 54,975,581,389 80% 467,373,275 1% /11 137,438,953,472 109,951,162,778 80% 813,744,135 1% /10 274,877,906,944 219,902,325,556 80% 1,416,810,831 1% /9 549,755,813,888 439,804,651,111 80% 2,466,810,934 0% /8 1,099,511,627,776 879,609,302,221 80% 4,294,967,296 0% /7 2,199,023,255,552 1,759,218,604,442 80% 7,477,972,398 0% /6 4,398,046,511,104 3,518,437,208,884 80% 13,019,906,166 0% /5 8,796,093,022,208 7,036,874,417,767 80% 22,668,973,294 0%
/16 4,294,967,296 3,435,973,837 80% 50,859,008 1% /15 8,589,934,592 6,871,947,674 80% 88,550,677 1% /14 17,179,869,184 13,743,895,348 80% 154,175,683 1% /13 34,359,738,368 27,487,790,695 80% 268,435,456 1% /12 68,719,476,736 54,975,581,389 80% 467,373,275 1% /11 137,438,953,472 109,951,162,778 80% 813,744,135 1% /10 274,877,906,944 219,902,325,556 80% 1,416,810,831 1% /9 549,755,813,888 439,804,651,111 80% 2,466,810,934 0% /8 1,099,511,627,776 879,609,302,221 80% 4,294,967,296 0% /7 2,199,023,255,552 1,759,218,604,442 80% 7,477,972,398 0% /6 4,398,046,511,104 3,518,437,208,884 80% 13,019,906,166 0% /5 8,796,093,022,208 7,036,874,417,767 80% 22,668,973,294 0%
Table 1. Comparison of Fixed Efficiency Threshold vs
HD-Ratio Threshold
Figure 7
図7
One possible assumption behind the HD-Ratio is that the inefficiencies that are a consequence of large-scale deployments are an outcome of an increased number of levels of hierarchical structure within the network. The following table calculates the depth of the hierarchy in order to achieve a 0.8 HD-Ratio, assuming a 0.8 utilization efficiency at each level in the hierarchy.
HD-比の背後に一つの可能な仮定は、大規模な展開の結果である非効率性は、ネットワーク内の階層構造のレベル数の増加の結果であるということです。次の表は、階層の各レベルでの0.8の利用効率を仮定すると、0.8 HD-比を達成するために、階層の深さを計算します。
Prefix Size 0.8 Structure HD-Ratio Levels /48 1 1 1 /47 2 2 1 /46 4 3 2 /45 8 5 2 /44 16 9 3 /43 32 16 4 /42 64 28 4 /41 128 49 5 /40 256 84 5 /39 512 147 6 /38 1,024 256 7 /37 2,048 446 7 /36 4,096 776 8 /35 8,192 1,351 9 /34 16,384 2,353 9 /33 32,768 4,096 10 /32 65,536 7,132 10 /31 131,072 12,417 11 /30 262,144 21,619 12 /29 524,288 37,641 12 /28 1,048,576 65,536 13
接頭語サイズ0.8構造HD比レベル/ 48 1 1 47分の1 2 2 46分の1 4 3 45分の2 8 5 44分の2 16 9 43分の3 32 16 42分の4 64 28 41分の4 128 49 40分の5 16,384 2,353 33分の9 256 84 39分の5 512 147 38分の6 1024 256 37分の7 2048 446 36分の7 4096 776 35分の8 8192 1351 34分の9 32,768 4096 32分の10 65,536 7132 10月31日131072 12417 11月30日262,144 21619 12月29日524288 37641 12月28日1,048,576 65,536 13
/27 2,097,152 114,105 14 /26 4,194,304 198,668 14 /25 8,388,608 345,901 15 /24 16,777,216 602,249 15 /23 33,554,432 1,048,576 16 /22 67,108,864 1,825,677 17 /21 134,217,728 3,178,688 17 /20 268,435,456 5,534,417 18 /19 536,870,912 9,635,980 19 /18 1,073,741,824 16,777,216 19 /17 2,147,483,648 29,210,830 20 /16 4,294,967,296 50,859,008 20 /15 8,589,934,592 88,550,677 21 /14 17,179,869,184 154,175,683 22 /13 34,359,738,368 268,435,456 22 /12 68,719,476,736 467,373,275 23 /11 137,438,953,472 813,744,135 23 /10 274,877,906,944 1,416,810,831 24 /9 549,755,813,888 2,466,810,934 25 /8 1,099,511,627,776 4,294,967,296 25
/27 2,097,152 114,105 14 /26 4,194,304 198,668 14 /25 8,388,608 345,901 15 /24 16,777,216 602,249 15 /23 33,554,432 1,048,576 16 /22 67,108,864 1,825,677 17 /21 134,217,728 3,178,688 17 /20 268,435,456 5,534,417 18 /19 536,870,912 9,635,980 19 /18 1,073,741,824 16,777,216 19 /17 2,147,483,648 29,210,830 20 /16 4,294,967,296 50,859,008 20 /15 8,589,934,592 88,550,677 21 /14 17,179,869,184 154,175,683 22 /13 34,359,738,368 268,435,456 22 /12 68,719,476,736 467,373,275 23 /11 137,438,953,472 813,744,135 23 /10 274,877,906,944 1,416,810,831 24 /9 549,755,813,888 2,466,810,934 25 /8 1,099,511,627,776 4,294,967,296 25
Table 2: Number of Structure Levels Assumed by HD-Ratio
表2：HD-比により想定構造レベルの数
Figure 8
図8
An alternative approach is to use a model of network deployment where the number of levels of hierarchy increases at a lower rate than that indicated in a 0.8 HD-Ratio model. One such model is indicated in the following table. This is compared to using an HD-Ratio value of 0.94.
別のアプローチは、階層のレベル数が0.8 HD比モデルで示されたものよりも低い速度で増加するネットワーク展開のモデルを使用することです。そのようなモデルは、以下の表に示されています。これは0.94のHD-比の値を使用して比較されます。
Per-Level Target Efficiency: 0.75
パーレベル目標効率：0.75
Prefix Size Stepped Stepped Efficiency HD-Ratio Levels 0.75 0.94
プレフィックスサイズ段段効率HD-比レベル0.75 0.94
/48 1 1 1 100% 1 100% /47 2 1 2 100% 2 100% /46 4 1 3 75% 4 100% /45 8 1 6 75% 7 88% /44 16 1 12 75% 13 81% /43 32 1 24 75% 25 78% /42 64 1 48 75% 48 75% /41 128 1 96 75% 92 72% /40 256 1 192 75% 177 69% /39 512 2 384 75% 338 66% /38 1,024 2 576 56% 649 63% /37 2,048 2 1,152 56% 1,244 61%
/48 1 1 1 100% 1 100% /47 2 1 2 100% 2 100% /46 4 1 3 75% 4 100% /45 8 1 6 75% 7 88% /44 16 1 12 75% 13 81% /43 32 1 24 75% 25 78% /42 64 1 48 75% 48 75% /41 128 1 96 75% 92 72% /40 256 1 192 75% 177 69% /39 512 2 384 75% 338 66% /38 1,024 2 576 56% 649 63% /37 2,048 2 1,152 56% 1,244 61%
/36 4,096 2 2,304 56% 2,386 58% /35 8,192 2 4,608 56% 4,577 56% /34 16,384 2 9,216 56% 8,780 54% /33 32,768 2 18,432 56% 16,845 51% /32 65,536 2 36,864 56% 32,317 49% /31 131,072 3 73,728 56% 62,001 47% /30 262,144 3 110,592 42% 118,951 45% /29 524,288 3 221,184 42% 228,210 44% /28 1,048,576 3 442,368 42% 437,827 42% /27 2,097,152 3 884,736 42% 839,983 40% /26 4,194,304 3 1,769,472 42% 1,611,531 38% /25 8,388,608 3 3,538,944 42% 3,091,767 37% /24 16,777,216 3 7,077,888 42% 5,931,642 35% /23 33,554,432 4 14,155,776 42% 11,380,022 34% /22 67,108,864 4 21,233,664 32% 21,832,894 33% /21 134,217,728 4 42,467,328 32% 41,887,023 31% /20 268,435,456 4 84,934,656 32% 80,361,436 30% /19 536,870,912 4 169,869,312 32% 154,175,684 29% /18 1,073,741,824 4 339,738,624 32% 295,790,403 28% /17 2,147,483,648 4 679,477,248 32% 567,482,240 26% /16 4,294,967,296 4 1,358,954,496 32% 1,088,730,702 25% /15 8,589,934,592 5 2,717,908,992 32% 2,088,760,595 24% /14 17,179,869,184 5 4,076,863,488 24% 4,007,346,185 23% /13 34,359,738,368 5 8,153,726,976 24% 7,688,206,818 22% /12 68,719,476,736 5 16,307,453,952 24% 14,750,041,884 21% /11 137,438,953,472 5 32,614,907,904 24% 28,298,371,876 21% /10 274,877,906,944 5 65,229,815,808 24% 54,291,225,552 20% /9 549,755,813,888 5 130,459,631,616 24% 104,159,249,331 19% /8 1,099,511,627,776 5 260,919,263,232 24% 199,832,461,158 18%
/36 4,096 2 2,304 56% 2,386 58% /35 8,192 2 4,608 56% 4,577 56% /34 16,384 2 9,216 56% 8,780 54% /33 32,768 2 18,432 56% 16,845 51% /32 65,536 2 36,864 56% 32,317 49% /31 131,072 3 73,728 56% 62,001 47% /30 262,144 3 110,592 42% 118,951 45% /29 524,288 3 221,184 42% 228,210 44% /28 1,048,576 3 442,368 42% 437,827 42% /27 2,097,152 3 884,736 42% 839,983 40% /26 4,194,304 3 1,769,472 42% 1,611,531 38% /25 8,388,608 3 3,538,944 42% 3,091,767 37% /24 16,777,216 3 7,077,888 42% 5,931,642 35% /23 33,554,432 4 14,155,776 42% 11,380,022 34% /22 67,108,864 4 21,233,664 32% 21,832,894 33% /21 134,217,728 4 42,467,328 32% 41,887,023 31% /20 268,435,456 4 84,934,656 32% 80,361,436 30% /19 536,870,912 4 169,869,312 32% 154,175,684 29% /18 1,073,741,824 4 339,738,624 32% 295,790,403 28% /17 2,147,483,648 4 679,477,248 32% 567,482,240 26% /16 4,294,967,296 4 1,358,954,496 32% 1,088,730,702 25% /15 8,589,934,592 5 2,717,908,992 32% 2,088,760,595 24% /14 17,179,869,184 5 4,076,863,488 24% 4,007,346,185 23% /13 34,359,738,368 5 8,153,726,976 24% 7,688,206,818 22% /12 68,719,476,736 5 16,307,453,952 24% 14,750,041,884 21% /11 137,438,953,472 5 32,614,907,904 24% 28,298,371,876 21% /10 274,877,906,944 5 65,229,815,808 24% 54,291,225,552 20% /9 549,755,813,888 5 130,459,631,616 24% 104,159,249,331 19% /8 1,099,511,627,776 5 260,919,263,232 24% 199,832,461,158 18%
Table 3: Limited Levels of Structure
表3：構造の限られたレベル
Figure 9
図9
Author's Address
著者のアドレス
Geoff Huston APNIC
ジェフ・ヒューストンAPNIC
EMail: gih@apnic.net
メールアドレス：gih@apnic.net
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。