summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4692.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc4692.txt')
-rw-r--r--doc/rfc/rfc4692.txt955
1 files changed, 955 insertions, 0 deletions
diff --git a/doc/rfc/rfc4692.txt b/doc/rfc/rfc4692.txt
new file mode 100644
index 0000000..d5456b2
--- /dev/null
+++ b/doc/rfc/rfc4692.txt
@@ -0,0 +1,955 @@
+
+
+
+
+
+
+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).
+
+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.
+
+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
+
+
+
+
+
+
+
+
+Huston Informational [Page 1]
+
+RFC 4692 IPv6 Host Density Metric October 2006
+
+
+1. Introduction
+
+ 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.
+
+ 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.
+
+ 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.
+
+2. IPv6 Address Structure
+
+ Before looking at address allocation efficiency metrics, it is
+ appropriate to summarize the address structure for IPv6 global
+ unicast addresses.
+
+ The general format for IPv6 global unicast addresses is defined in
+ [RFC4291] as follows (Figure 1).
+
+ | 64 - m bits | m bits | 64 bits |
+ +------------------------+-----------+----------------------------+
+ | global routing prefix | subnet ID | interface ID |
+ +------------------------+-----------+----------------------------+
+
+ IPv6 Address Structure
+
+ Figure 1
+
+
+
+Huston Informational [Page 2]
+
+RFC 4692 IPv6 Host Density Metric October 2006
+
+
+ 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].
+
+ 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.
+
+ 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.
+
+3. The Host Density Ratio
+
+ The "Host Density Ratio" was first described in [RFC1715] and
+ subsequently updated in [RFC3194].
+
+ The "H Ratio", as defined in RFC 1715, is:
+
+ log (number of objects)
+ H = -----------------------
+ available bits
+
+ Figure 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.
+
+
+
+Huston Informational [Page 3]
+
+RFC 4692 IPv6 Host Density Metric October 2006
+
+
+ This particular metric has a maximal value of log base 10 of 2, or
+ 0.30103.
+
+ The metric was 'normalized' in RFC 3194, and a new metric, the "HD-
+ Ratio" was introduced, with the following definition:
+
+ log(number of allocated objects)
+ HD = ------------------------------------------
+ log(maximum number of allocatable objects)
+
+ Figure 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.
+
+ 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.
+
+ 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%).
+
+ A comparison of these two metrics is given in Table 1 of Attachment
+ A.
+
+4. The Role of an Address Efficiency Metric
+
+ 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
+
+
+
+Huston Informational [Page 4]
+
+RFC 4692 IPv6 Host Density Metric October 2006
+
+
+ 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.
+
+ 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.
+
+ 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
+
+
+
+Huston Informational [Page 5]
+
+RFC 4692 IPv6 Host Density Metric October 2006
+
+
+ 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.
+
+ 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.
+
+5. Network Structure and Address Efficiency Metric
+
+ 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.
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+Huston Informational [Page 6]
+
+RFC 4692 IPv6 Host Density Metric October 2006
+
+
+ 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.
+
+ 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.
+
+ Allocation: 8M Customers
+
+ 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
+
+ Figure 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.
+
+6. Varying the HD-Ratio
+
+ 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.
+
+
+
+
+
+
+
+
+Huston Informational [Page 7]
+
+RFC 4692 IPv6 Host Density Metric October 2006
+
+
+ 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
+
+ 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.
+
+6.1. Simulation Results
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+Huston Informational [Page 8]
+
+RFC 4692 IPv6 Host Density Metric October 2006
+
+
+ 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.
+
+ 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-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
+
+ 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
+
+
+
+Huston Informational [Page 9]
+
+RFC 4692 IPv6 Host Density Metric October 2006
+
+
+ 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).
+
+ 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.
+
+7. Considerations
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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
+
+
+
+Huston Informational [Page 10]
+
+RFC 4692 IPv6 Host Density Metric October 2006
+
+
+ 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.
+
+ 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.
+
+8. Security Considerations
+
+ Considerations of various forms of host density metrics create no new
+ threats to the security of the Internet.
+
+9. Acknowledgements
+
+ The document was reviewed by Kurt Lindqvist, Thomas Narten, Paul
+ Wilson, David Kessens, Bob Hinden, Brian Haberman, and Marcelo
+ Bagnulo.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Huston Informational [Page 11]
+
+RFC 4692 IPv6 Host Density Metric October 2006
+
+
+10. References
+
+10.1. Normative References
+
+ [RFC1715] Huitema, C., "The H Ratio for Address Assignment
+ Efficiency", RFC 1715, November 1994.
+
+ [RFC3177] IAB and IESG, "IAB/IESG Recommendations on IPv6 Address
+ Allocations to Sites", RFC 3177, September 2001.
+
+ [RFC3194] Durand, A. and C. Huitema, "The H-Density Ratio for
+ Address Assignment Efficiency An Update on the H ratio",
+ RFC 3194, November 2001.
+
+ [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
+ Architecture", RFC 4291, February 2006.
+
+10.2. Informative References
+
+ [RIR-Data] RIRs, "RIR Delegation Records", February 2005,
+ <ftp://ftp.apnic.net/pub/stats/>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Huston Informational [Page 12]
+
+RFC 4692 IPv6 Host Density Metric October 2006
+
+
+Appendix A. Comparison Tables
+
+ 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.
+
+ Fixed Efficiency Value 0.8
+ HD-Ratio Value 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
+
+ /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%
+
+
+
+Huston Informational [Page 13]
+
+RFC 4692 IPv6 Host Density Metric October 2006
+
+
+ /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
+
+ 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.
+
+ 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
+
+
+
+Huston Informational [Page 14]
+
+RFC 4692 IPv6 Host Density Metric October 2006
+
+
+ /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
+
+ Figure 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.
+
+ Per-Level Target Efficiency: 0.75
+
+ Prefix Size Stepped Stepped Efficiency HD-Ratio
+ Levels 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%
+
+
+
+Huston Informational [Page 15]
+
+RFC 4692 IPv6 Host Density Metric October 2006
+
+
+ /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
+
+ Figure 9
+
+Author's Address
+
+ Geoff Huston
+ APNIC
+
+ EMail: gih@apnic.net
+
+
+
+
+
+
+
+
+
+
+
+Huston Informational [Page 16]
+
+RFC 4692 IPv6 Host Density Metric October 2006
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (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.
+
+ 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.
+
+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.
+
+ 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.
+
+ 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.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Huston Informational [Page 17]
+