| TOC |
|
By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 30, 2005.
Copyright (C) The Internet Society (2004). All Rights Reserved.
This memo provides an analysis of the Host Density metric as 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. It is noted that for large allocations there are very significant variations in the target efficiency metric between the two approaches. The memo notes that the IPv6 address assignment efficiency metric would benefit from a detailed technical review, particularly relating to large scale deployments of public infrastructure.
The following changes have been made to the draft:
draft-iab-ipv6-host-density-metric-000:
- Initial draft
1.
Introduction
2.
IPv6 Address Structure
3.
The Host Density Ratio
4.
The Role of an Address Efficiency Metric
5.
Network Structure and Address Efficiency Metric
6.
Considerations
§.
Normative References
§
Author's Address
A.
Comparison Tables
§
Intellectual Property and Copyright Statements
| TOC |
Metrics of address assignment efficiency are used in the context of the public Internet as a part of the address allocation function. Though the use of an address assignment efficiency metric individual networks can be compared to a target model in an objective fashion. The common use of this metric is to form part of the justification of an address allocation request, demonstrating that the network has met the target address efficiency metric and that the allocation of a further address block is justified.
Public IP networks have significant differences in purpose, structure, size and technology. Attempting to impose a single metric across this very diverse environment is a challenging task. Any address assignment efficiency metric has to represent a balance between stating an achievable metric for any competently designed and operated service platform, while not specifying a metric that allows for an address usage rate that imperils the protocol's longer term viability. 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 as currently adopted in the allocation of IPv4 network addresses and that used by the IPv6 protocol. It is noted that for large allocations there are very significant variations in the target efficiency metric.
The conclusion drawn here is that the IPv6 address assignment efficiency metric would benefit from a detailed technical review, particularly relating to large scale deployments of public infrastructure. approaches as required.
| TOC |
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 RFC3513 [1]Hinden, R. and S. Deering, Internet Protocol Version 6 (IPv6) Addressing Architecture, April 2003. as follows (Figure 1).
| 64 - m bits | m bits | 64 bits |
+------------------------+-----------+----------------------------+
| global routing prefix | subnet ID | interface ID |
+------------------------+-----------+----------------------------+
Figure 1. IPv6 Address Structure
Furthermore, 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 is defined as 16 bits, such that the 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.
In relating this address structure to the address allocation function, the efficiency metric is not intended to refer to the 128 bit IPv6 address, nor the 64 bit routing prefix, but is limited to the 48 bit global routing prefix. This allocation model assumes that each customer is allocated a minimum of a /48 address block, and, given that this block allows 2**16 possible subnets, it is also considered 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 the address assignment efficiency in this context is the efficiency of assignment of /48 address allocation units.
| TOC |
The "Host Density Ratio" is first described in RFC 1715 [2]Huitema, C., The H Ratio for Address Assignment Efficiency, November 1994., and subsequently updated in RFC3194 [3]Durand, A. and C. Huitema, The H-Density Ratio for Address Assignment Efficiency An Update on the H ratio, November 2001..
The "H Ratio", as defined in RFC1715, is:
log (number of objects)
H = -----------------------
available bits
The rationale for this approach was to mathematically model hierarchical forms of address assignment, where the number of levels of hierarchy increases with larger address blocks. Such hierarchies are common in IP network deployments, where, for example, address blocks may be assigned per region, and each regional block further divided into an address block per Point of Presence (POP), and from each POP address block there is a per customer address allocation. If the network is to allow for various forms of dynamic change, and if there is a desire to avoid renumbering within the network and renumbering customers' networks, then due allowance must be made for change at each level of the network hierarchy.
The RFC draws on a number of examples to support the assertion that this metric reflected a useful measure of address assignment efficiency, and furthermore that the optimal point for such a utilization efficiency metric lies between 0.14 and 0.26
[side note - to be removed from final]
Interestingly the table in RFC1715, indicating a range of addressed objects for a 64 bit address range was given as between 9 E+8 and 4 E+16, while 128 bits yielded values of 8 E+17 through to 2 E+33. This data was used to support the argument that 64 bits of address space was insufficient. Given that we are now operating in a mode where the IPv6 address unit is somewhere between 48 and 64 bits in effective length (as distinct from 128), there is a somewhat ironic twist in this original observation.
This metric has a maximal value of log base 10 of 2, or 0.30103.
The metric was 'normalized' in RFC3194, and a new metric, the "HD-Ratio" was introduced, with the definition:
log(number of allocated objects)
HD = ------------------------------------------
log(maximum number of allocatable objects)
HD values are directly proportional to the H ratio, and the values of the ratio range from 0 to 1. The RFC then applied this HD-Ratio metric to the examples given in RFC 1715, and on the basis of these examples, postulated that HD-Ratios of 0.85 or higher forced the network into some form of renumbering, while 0.80 or lower was considered to be an acceptable network efficiency metric.
The HD ratio is referenced within the IPv6 address allocation policies used by the Regional Internet Registries, and the 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.
| TOC |
The role of the address efficiency metric is to provide objective metrics than can be used by both the allocation entity and the recipient to determine whether an allocation is warranted, and provide some indication of the size of the allocation that should be undertaken. The metric provides a target address utilization levels that indicates at what point a network's address resource may be considered to be "fully utilized".
The objective here is to allow the network service provider to deploy addresses across both network infrastructure and to 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 routing space. 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 address structure that address space is exhausted not when all address resources have been used, but when one element within the structure has exhausted its pool, and 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. It is noted that the examples used in the HD-Ratio are drawn from, among other sources, the PSTN, and this 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 geo- political distribution system of "call areas" that share a common number prefix. Within each call area 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. Internally within an IP network the interior routing protocol, if uniformly deployed, admits a hierarchical network structure that is only two levels deep. Additional levels of routing hierarchy may be obtained using various forms of route confederations, but this is not a 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.
It should also be noted that large scale IP deployments typically use a relatively flat routing hierarchy. 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.
| TOC |
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 n**e. This then allows us to make some additional observations about the HD-Ratio values. Table 2 of Appendix A 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 is not commonly the case.
As noted above the most common form of structure used in IP networks is a three level structure. For larger networks a four level structure may be used, where the network is the union of a number of distinct operating entities, each of which use a three level internal structure.
Table 3 of Attachment A shows an example of address efficiency outcomes using a per-level efficiency metric of 0.75 and a progressively deeper network structure as the address block expands, up to a 5 level structure for the larger blocks ("limited levels").
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, then the following table 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
HD-Ratio /19 64
75% with Limited Levels /23 4
It is noted that the HD-Ratio produces a significantly lower efficiency level than the other two metrics, and the limited level model appears to point to a more realistic value for an efficiency value for networks of this scale.
| TOC |
The HD ratio as a model of network address utilization efficiency produces very low efficiency outcomes for networks spanning of the order of 10**6 end customers and larger.
The HD-Ratio 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 is not a common feature of public IP network deployments.
The fixed efficiency model uses the assumption that as the allocation block becomes larger the network structure remains at a fixed level of levels, or if the number of levels is increased, then efficiency achieved at each level increases significantly. There is little evidence to suggest that increasing 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 NAT to meet the target efficiency value in a hierarchically structure network. The HD-Ratio model specifies a very low address efficiency target, and while this places no particular stress on network architects in terms of forced renumbering, there is the concern that this represents an extravagant use of address resources. If the objective of IPv6 is to encompass a number of decades of deployment, and span a public network that ultimately encompasses many billions of end customers, then there is legitimate cause for concern that the HD-Ratio may be setting too conservative a target for address efficiency.
It is recommended that further study of address efficiency metrics and the relationship between network structure and address efficiency models considered as part of such a study.
This document has also noted the choice of a fixed length of 16 bits for the subnet ID in the IPv6 unicast address architecture. While this choice has been used in the block of unicast address space spanned by the IPv6 address prefix 2000::/3, it should not be assumed by vendors or network operators that this particular subnet scheme will be used for other unicast address blocks. Prior to the opening of further unicast address blocks for end user assignment it is considered to be a useful exercise to evaluate the effectiveness of this fixed length subnet scheme, and compare it to an subnet scheme with a variable length and a smaller minimum value.
| TOC |
| [1] | Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003. |
| [2] | Huitema, C., "The H Ratio for Address Assignment Efficiency", RFC 1715, November 1994. |
| [3] | Durand, A. and C. Huitema, "The H-Density Ratio for Address Assignment Efficiency An Update on the H ratio", RFC 3194, November 2001. |
| TOC |
| Geoff Huston (editor) | |
| Internet Architecture Board | |
| EMail: | execd@iab.org |
| URI: | http://www.iab.org |
| TOC |
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
Prefix Size Fixed Eff. HD-Ratio Eff. Ratio
Allocation % %
Ratio
/48 1 1 100% 1 100% 1
/47 2 1 50% 1 50% 1
/46 4 3 75% 3 75% 1
/45 8 6 75% 5 62% 1
/44 16 12 75% 9 56% 1
/43 32 25 78% 16 50% 1
/42 64 51 80% 27 42% 1
/41 128 102 80% 48 37% 2
/40 256 204 80% 84 33% 2
/39 512 409 80% 147 29% 2
/38 1024 819 80% 256 25% 3
/37 2048 1638 80% 445 22% 3
/36 4096 3276 80% 776 19% 4
/35 8192 6553 80% 1351 16% 4
/34 16384 13107 80% 2352 14% 5
/33 32768 26214 80% 4096 12% 6
/32 65536 52428 80% 7131 11% 7
/31 131072 104857 80% 12416 9% 8
/30 262144 209715 80% 21618 8% 9
/29 524288 419430 80% 37640 7% 11
/28 1048576 838860 80% 65536 6% 12
/27 2097152 1677721 80% 114104 5% 14
/26 4194304 3355443 80% 198668 5% 16
/25 8388608 6710886 80% 345901 4% 19
/24 16777216 13421772 80% 602248 3% 22
/23 33554432 26843545 80% 1048576 3% 25
/22 67108864 53687091 80% 1825676 3% 29
/21 134217728 107374182 80% 3178688 2% 33
/20 268435456 214748364 80% 5534417 2% 38
/19 536870912 429496729 80% 9635980 2% 44
/18 1073741824 858993459 80% 16777216 2% 51
/17 2147483648 1717986918 80% 29210829 1% 58
/16 4294967296 3435973836 80% 50859008 1% 67
/15 8589934592 6871947673 80% 88550676 1% 77
/14 17179869184 13743895347 80% 154175683 1% 89
/13 34359738368 27487790694 80% 268435456 1% 102
/12 68719476736 54975581388 80% 467373274 1% 117
/11 1.37439E+11 1.09951E+11 80% 813744135 1% 135
/10 2.74878E+11 2.19902E+11 80% 1416810830 1% 155
/9 5.49756E+11 4.39805E+11 80% 2466810933 0% 178
/8 1.09951E+12 8.79609E+11 80% 4294967296 0% 204
/7 2.19902E+12 1.75922E+12 80% 7477972397 0% 235
/6 4.39805E+12 3.51844E+12 80% 13019906166 0% 270
/5 8.79609E+12 7.03687E+12 80% 22668973294 0% 310
Table 1 Comparison of Fixed Efficiency threshold vs HD-Ratio Threshold
One possible assumption behind the HD ratio is that the inefficiencies that are a consequence of large scale deployments are an outcome of increased number of levels of hierarchical structure within the network. The following table calculates the depth of the hierarchy in oder to achieve a 0.8 HD ratio, assuming a 0.8 utilization efficiency at each level in the hierarchy.
HD-Ratio 0.8
Prefix Size HD-Ratio Structure Levels
/48 1 1 1
/47 2 1 1
/46 4 3 1
/45 8 5 2
/44 16 9 2
/43 32 16 3
/42 64 27 3
/41 128 48 4
/40 256 84 4
/39 512 147 5
/38 1024 256 5
/37 2048 445 6
/36 4096 776 6
/35 8192 1351 7
/34 16384 2352 7
/33 32768 4096 8
/32 65536 7131 8
/31 131072 12416 9
/30 262144 21618 9
/29 524288 37640 10
/28 1048576 65536 10
/27 2097152 114104 11
/26 4194304 198668 11
/25 8388608 345901 12
/24 16777216 602248 12
/23 33554432 1048576 13
/22 67108864 1825676 13
/21 134217728 3178688 14
/20 268435456 5534417 14
/19 536870912 9635980 14
/18 1073741824 16777216 15
/17 2147483648 29210829 15
/16 4294967296 50859008 16
/15 8589934592 88550676 16
/14 17179869184 154175683 17
/13 34359738368 268435456 17
/12 68719476736 467373274 18
/11 1.37439E+11 813744135 18
/10 2.74878E+11 1416810830 19
/9 5.49756E+11 2466810933 19
/8 1.09951E+12 4294967296 20
/7 2.19902E+12 7477972397 20
/6 4.39805E+12 13019906166 21
/5 8.79609E+12 22668973294 21
Table 2 Number of Structure Levels assumed by HD-Ratio
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.
Per-Level Target Efficiency: 0.75
Prefix Size Levels Allocations Efficiency
/48 1 1 1 100%
/47 2 2 1 50%
/46 4 2 2 50%
/45 8 2 4 50%
/44 16 2 9 56%
/43 32 3 13 41%
/42 64 3 27 42%
/41 128 3 54 42%
/40 256 3 108 42%
/39 512 3 216 42%
/38 1024 3 432 42%
/37 2048 3 864 42%
/36 4096 3 1728 42%
/35 8192 3 3456 42%
/34 16384 3 6912 42%
/33 32768 3 13824 42%
/32 65536 3 27648 42%
/31 131072 3 55296 42%
/30 262144 3 110592 42%
/29 524288 4 165888 32%
/28 1048576 4 331776 32%
/27 2097152 4 663552 32%
/26 4194304 4 1327104 32%
/25 8388608 4 2654208 32%
/24 16777216 4 5308416 32%
/23 33554432 4 10616832 32%
/22 67108864 5 15925248 24%
/21 134217728 5 31850496 24%
/20 268435456 5 63700992 24%
/19 536870912 5 127401984 24%
/18 1073741824 5 254803968 24%
/17 2147483648 5 509607936 24%
/16 4294967296 5 1019215872 24%
/15 8589934592 5 2038431744 24%
/14 17179869184 5 4076863488 24%
/13 34359738368 5 8153726976 24%
/12 68719476736 5 16307453952 24%
/11 1.37439E+11 5 32614907904 24%
/10 2.74878E+11 5 65229815808 24%
/9 5.49756E+11 5 1.30460E+11 24%
/8 1.09951E+12 5 2.60919E+11 24%
/7 2.19902E+12 5 5.21839E+11 24%
/6 4.39805E+12 5 1.04368E+12 24%
/5 8.79609E+12 5 2.08735E+12 24%
Table 3: Limited Levels of Structure
| TOC |
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.
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.
Copyright (C) The Internet Society (2004). 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.
Funding for the RFC Editor function is currently provided by the Internet Society.