idnits 2.17.1 draft-huston-hd-metric-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 762. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 739. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 746. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 752. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 11, 2005) is 6735 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 1715 ** Obsolete normative reference: RFC 3177 (Obsoleted by RFC 6177) ** Downref: Normative reference to an Informational RFC: RFC 3194 ** Obsolete normative reference: RFC 3513 (Obsoleted by RFC 4291) Summary: 8 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Individual Submission G. Huston 3 Internet-Draft APNIC 4 Expires: May 15, 2006 November 11, 2005 6 Considerations on the IPv6 Host density Metric 7 draft-huston-hd-metric-02.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on May 15, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2005). 38 Abstract 40 This memo provides an analysis of the Host Density metric as 41 currently used to guide registry allocations of IPv6 unicast address 42 blocks. This document contrasts the address efficiency as currently 43 adopted in the allocation of IPv4 network addresses and that used by 44 the IPv6 protocol. It is noted that for large allocations there are 45 very significant variations in the target efficiency metric between 46 the two approaches. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. IPv6 Address Structure . . . . . . . . . . . . . . . . . . . . 3 52 3. The Host Density Ratio . . . . . . . . . . . . . . . . . . . . 4 53 4. The Role of an Address Efficiency Metric . . . . . . . . . . . 6 54 5. Network Structure and Address Efficiency Metric . . . . . . . 7 55 6. Varying the HD Ratio . . . . . . . . . . . . . . . . . . . . . 8 56 6.1. Simulation Results . . . . . . . . . . . . . . . . . . . . 9 57 7. Considerations . . . . . . . . . . . . . . . . . . . . . . . . 11 58 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 59 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 60 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 61 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 62 10.2. Informative References . . . . . . . . . . . . . . . . . . 13 63 Appendix A. Comparison Tables . . . . . . . . . . . . . . . . . . 13 64 Appendix B. Draft Notes . . . . . . . . . . . . . . . . . . . . . 18 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19 66 Intellectual Property and Copyright Statements . . . . . . . . . . 20 68 1. Introduction 70 Metrics of address assignment efficiency are used in the context of 71 the Regional Internet Registries' address allocation function. 72 Through the use of a common address assignment efficiency metric 73 individual networks can be compared to a threshold value in an 74 objective fashion. The common use of this metric is to form part of 75 the supporting material for an address allocation request, 76 demonstrating that the network has met or exceeded the threshold 77 address efficiency value and it forms part of the supportive material 78 relating to the justification of the allocation of a further address 79 block. 81 Public and private IP networks have significant differences in 82 purpose, structure, size and technology. Attempting to impose a 83 single efficiency metric across this very diverse environment is a 84 challenging task. Any address assignment efficiency threshold value 85 has to represent a balance between stating an achievable outcome for 86 any competently designed and operated service platform, while at the 87 same time not setting a level of consumption of address resources 88 that imperils the protocol's longer term viability through consequent 89 address scarcity. There are a number of views relating to address 90 assignment efficiency, both in terms of theoretic analyses of 91 assignment efficiency and in terms of practical targets that are part 92 of current address assignment practices in today's Internet. 94 This document contrasts the address efficiency metric and threshold 95 value as currently adopted in the allocation of IPv4 network 96 addresses and the framework used by the address allocation process 97 for the IPv6 protocol. 99 2. IPv6 Address Structure 101 Before looking at address allocation efficiency metrics it is 102 appropriate to summarize the address structure for IPv6 global 103 unicast addresses. 105 The general format for IPv6 global unicast addresses is defined in 106 [RFC3513] as follows (Figure 1). 108 | 64 - m bits | m bits | 64 bits | 109 +------------------------+-----------+----------------------------+ 110 | global routing prefix | subnet ID | interface ID | 111 +------------------------+-----------+----------------------------+ 113 IPv6 Address Structure 115 Figure 1 117 Within the current policy framework for allocation of IPv6 addresses 118 in the context of the public Internet, the value for 'm' in the 119 figure above, referring to the subnet ID, is commonly a 16 bit field. 120 Therefore, the end-site global routing prefix is 48 bits in length, 121 the per-customer subnet ID is 16 bits in length and the interface ID 122 is 64 bits in length [RFC3177]. 124 In relating this address structure to the address allocation 125 function, the efficiency metric is not intended to refer to the use 126 of individual 128 bit IPv6 addresses, nor that of the use of the 64 127 bit subnet prefix, but is limited to measure of efficiency of use of 128 the end-site global routing prefix. This allocation model assumes 129 that each customer is allocated a minimum of a single /48 address 130 block, and, given that this block allows 2^16 possible subnets, it is 131 also assumed that a /48 allocation will be used in the overall 132 majority of cases of end-customer address assignment. 134 The following discussion makes the assumption that the address 135 allocation unit in IPv6 is an address prefix of 48 bits in length, 136 and the address assignment efficiency in this context is the 137 efficiency of assignment of /48 address allocation units. However, 138 the analysis presented here refers more generally to end-site address 139 allocation practices rather than /48 address prefixes in particular, 140 and is applicable in the context of any size of end-site global 141 routing prefix. 143 3. The Host Density Ratio 145 The "Host Density Ratio" is first described in [RFC1715], and 146 subsequently updated in [RFC3194]. 148 The "H Ratio", as defined in RFC1715, is: 150 log (number of objects) 151 H = ----------------------- 152 available bits 154 Figure 2 156 The argument presented in [RFC1715] draws on a number of examples to 157 support the assertion that this metric reflects a useful generic 158 measure of address assignment efficiency in a range of end-site 159 addressed networks, and furthermore that the optimal point for such a 160 utilization efficiency metric lies in an H Ratio value between 0.14 161 and 0.26. Lower H Ratio values represent inefficient address use, 162 and higher H Ratio values tend to be associated with various forms of 163 additional network overhead related to forced re-addressing 164 operations. 166 This particular metric has a maximal value of log base 10 of 2, or 167 0.30103. 169 The metric was 'normalized' in RFC3194, and a new metric, the "HD- 170 Ratio" was introduced, with the definition: 172 log(number of allocated objects) 173 HD = ------------------------------------------ 174 log(maximum number of allocatable objects) 176 Figure 3 178 HD-ratio values are proportional to the H ratio, and the values of 179 the HD ratio range from 0 to 1. The analysis described in [RFC3194] 180 has applied this HD-Ratio metric to the examples given in [RFC1715], 181 and on the basis of these examples, postulated that HD-Ratio values 182 of 0.85 or higher force the network into some form of renumbering, 183 while HD-Ratio values 0.80 or lower was considered to be an 184 acceptable network efficiency metric. 186 The HD-ratio is referenced within the IPv6 address allocation 187 policies used by the Regional Internet Registries, and their IPv6 188 address allocation policy documents specify that an HD-Ratio metric 189 of 0.8 is an acceptable objective in terms of address assignment 190 efficiency for an IPv6 network. 192 By contrast, the generally used address efficiency metric for IPv4 is 193 the simple ratio of the number of allocated (or addressed) objects to 194 the maximum number of allocatable objects. For IPv4 the commonly 195 applied value for this ratio is 0.8 (or 80%). 197 A comparison of these two metrics is given in Table 1 of Attachment 198 A. 200 4. The Role of an Address Efficiency Metric 202 The role of the address efficiency metric is to provide objective 203 metrics relating to a network's use of address space than can be used 204 by both the allocation entity and the applicant to determine whether 205 an address allocation is warranted, and provide some indication of 206 the size of the address allocation that should be undertaken. The 207 metric provides a target address utilization level that indicates at 208 what point a network's address resource may be considered to be 209 "fully utilized". 211 The objective here is to allow the network service provider to deploy 212 addresses across both network infrastructure and the network's 213 customers in a manner that does not entail periodic renumbering, and 214 in a manner that allows both the internal routing system and inter- 215 domain routing system to operate without excessive fragmentation of 216 the address space and consequent expansion of the number of route 217 objects carried within the routing systems. This entails use of an 218 addressing plan where at each level of structure within the network 219 there is a pool of address blocks that allows expansion of the 220 network at that structure level without requiring renumbering of the 221 remainder of the network. 223 It is recognized that an address utilization efficiency metric of 224 100% is unrealistic in any scenario. Within a typical network 225 address plan the network's address space is exhausted not when all 226 address resources have been used, but at the point when one element 227 within the structure has exhausted its pool, and when augmentation of 228 this pool by drawing from the pools of other elements would entail 229 extensive renumbering. While it is not possible to provide a 230 definitive threshold of what overall efficiency level is obtainable 231 in all IP networks, experience with IPv4 network deployments suggests 232 that it is reasonable to observe that at any particular level within 233 a hierarchically structured address deployment plan an efficiency 234 level of between 60% to 80% is an achievable metric in the general 235 case. 237 This IPv4 efficiency threshold is significantly greater than that 238 observed in the examples provided in conjunction with the HD-Ratio 239 description in [RFC1715]. It is noted that the examples used in the 240 HD-Ratio are drawn from, among other sources, the PSTN. This 241 comparison with the PSTN warrants some additional examination. There 242 are a number of differences between public IP network deployments and 243 PSTN deployments that may account for this difference. IP addresses 244 are deployed on a per-provider basis with an alignment to network 245 topology. PSTN addresses are, on the whole, deployed using a 246 geographical distribution system of "call areas" that share a common 247 number prefix. Within each call area sufficient number blocks from 248 the number prefix must be available to allow each operator to draw 249 their own number block from the area pool. Within the IP environment 250 service providers do not draw address blocks from a common geographic 251 number pool, but receive address blocks from the regional Internet 252 registry on a 'whole of network' basis. This difference in the 253 address structure allows an IP environment to achieve an overall 254 higher level of address utilization efficiency. 256 In terms of considering the number of levels of internal hierarchy in 257 IP networks, the interior routing protocol, if uniformly deployed, 258 admits a hierarchical network structure that is only two levels deep, 259 with a fully connected backbone "core" and a number of satellite 260 areas that are directly attached to this "core". Additional levels 261 of routing hierarchy may be obtained using various forms of routing 262 confederations, but this is not an extremely common deployment 263 technique. The most common form of network structure used in large 264 IP networks is a three-level structure using regions, individual 265 Points of Presence (POPs), and end-customers. 267 It should also be noted that large scale IP deployments typically use 268 a relatively flat routing structure, as compared to a deeply 269 hierarchical structure. In order to improve the dynamic performance 270 of the interior routing protocol the number of routes carried in the 271 interior routing protocol is commonly restricted to the routes 272 corresponding to next hop destinations for iBGP routes, and customer 273 routes are carried in the iBGP domain, and aggregated at the point 274 where the routes are announced in eBGP sessions. This implies that 275 per-POP or per-region address aggregations according to some fixed 276 address hierarchy is not a necessary feature of large IP networks, so 277 strict hierarchical address structure within all parts of the network 278 is not a necessity in such routing environments. 280 5. Network Structure and Address Efficiency Metric 282 An address efficiency metric can be expressed using the number of 283 levels of structure (n) and the efficiency achieved at each level 284 (e). If the same efficiency threshold is applied at each level of 285 structure the resultant efficiency threshold is e^n. This then 286 allows us to make some additional observations about the HD-Ratio 287 values. Table 2 of Appendix A (Figure 8) indicates the number of 288 levels of structure that are implied by a given HD-Ratio value of 0.8 289 for each address allocation block size, assuming a fixed efficiency 290 level at all levels of the structure. The implication is that for 291 large address blocks the HD-Ratio assumes a large number of elements 292 in the hierarchical structure, or a very low level of address 293 efficiency at the lower levels. In the case of IP network 294 deployments this latter situation is not commonly the case. 296 The most common form of interior routing structure used in IP 297 networks is a two level routing structure. It is consistent with 298 this constrained routing architecture that network address plans 299 appear to be commonly devised using up to a three level hierarchical 300 structure, while for larger networks a four level structure may be 301 generally used. 303 Table 3 of Attachment A (Figure 9) shows an example of address 304 efficiency outcomes using a per-level efficiency metric of 0.75 (75%) 305 and a progressively deeper network structure as the address block 306 expands. This model (termed here "limited levels"), limits the 307 maximal number of levels of internal hierarchy to 6, and uses a model 308 where the number of levels of network hierarchy increases by 1 when 309 the network increases in size by a factor of a little over one order 310 of magnitude. 312 It is illustrative to compare these metrics for a larger network 313 deployment. If, for example, the network is designed to encompass 8 314 million end customers, each of which is assigned a 16 bit subnet ID 315 for their end site, then the following table Figure 4 indicates the 316 associated allocation size as determined by the address efficiency 317 metric. 319 Allocation: 8M Customers 321 Allocation Relative Ratio 323 100% Allocation Efficiency /25 1 324 80% Efficiency (IPv4) /24 2 325 0.8 HD-Ratio /19 64 326 75% with Limited Level /23 4 327 0.94 HD Ratio /23 4 329 Figure 4 331 It is noted that the 0.8 HD-Ratio produces a significantly lower 332 efficiency level than the other metrics. The limited level model 333 appears to point to a more realistic value for an efficiency value 334 for networks of this scale (corresponding to a network with 4 levels 335 of internal hierarchy, each with a target utilization efficiency of 336 75%). This limited level model corresponds to an HD Ratio with a 337 threshold value of 0.945. 339 6. Varying the HD Ratio 341 One way to model the range of outcomes of taking a more limited 342 approach to the number of levels of aggregateable hierarchy is to 343 look at a comparison of various values for the HD Ratio with the 344 model of a fixed efficiency and the "Limited Levels" model. This is 345 indicated in Figure 5. 347 Prefix Length (bits) 348 | 349 | 350 | Limited HD-Ratio 351 | Levels 0.98 0.94 0.90 0.86 0.82 0.80 352 | | | | | | | | 353 1 0.750 0.986 0.959 0.933 0.908 0.883 0.871 354 4 0.750 0.946 0.847 0.758 0.678 0.607 0.574 355 8 0.750 0.895 0.717 0.574 0.460 0.369 0.330 356 12 0.563 0.847 0.607 0.435 0.312 0.224 0.189 357 16 0.563 0.801 0.514 0.330 0.212 0.136 0.109 358 20 0.422 0.758 0.435 0.250 0.144 0.082 0.062 359 24 0.422 0.717 0.369 0.189 0.097 0.050 0.036 360 28 0.316 0.678 0.312 0.144 0.066 0.030 0.021 361 32 0.316 0.642 0.264 0.109 0.045 0.018 0.012 362 36 0.237 0.607 0.224 0.082 0.030 0.011 0.007 363 40 0.237 0.574 0.189 0.062 0.021 0.007 0.004 364 44 0.178 0.543 0.160 0.047 0.014 0.004 0.002 365 48 0.178 0.514 0.136 0.036 0.009 0.003 0.001 367 Figure 5 369 As shown in this figure it is possible to select an HD-Ratio value 370 that models IP level structures in a fashion that behaves more 371 consistently for very large deployments. In this case the choice of 372 an HD-Ratio of 0.94 is consistent with a limited level model of up to 373 6 levels of hierarchy with a metric of 75% density at each level. 374 This correlation is indicated in Table 3 of Attachment A. 376 6.1. Simulation Results 378 In attempting to assess the impact of potentially changing the HD- 379 Ratio to a lower value, it is useful to assess this using actual 380 address consumption data. The results described here use the IPv4 381 allocation data as published by the Regional Internet Registries 382 [RIR-Data] . The simulation work assumes that the IPv4 delegation 383 data uses an IPv4 /32 for each end customer, and that assignments 384 have been made based on an 80% density metric in terms of assumed 385 customer count. The customer count is then used as the basis of an 386 IPv6 address allocation, using the HD-Ratio to map from a customer 387 count to the size of an address allocation. 389 The result presented here is that of a simulation of an IPv6 address 390 allocation registry, using IPv4 allocation data as published by the 391 RIRs spanning the period from January 1, 1999 until August 31, 2004. 392 The aim is to identify the relative level of IPv6 address consumption 393 using a IPv6 request size profile based on the application of various 394 HD-Ratio values to the derived customer numbers. 396 The profile of total address consumption for selected HD-Ratio values 397 is indicated in Figure 6. The simulation results indicate that the 398 choice of an HD-Ratio of 0.8 consumes a total of 7 times the address 399 space than that consumed when using an HD-Ratio of 0.94. 401 HD-Ratio Total Address Consumption 402 | Prefix Length Count of 403 | Notation /32 prefixes 404 0.80 /14.45 191,901 405 0.81 /14.71 160,254 406 0.82 /15.04 127,488 407 0.83 /15.27 108,701 408 0.84 /15.46 95,288 409 0.85 /15.73 79,024 410 0.86 /15.88 71,220 411 0.87 /16.10 61,447 412 0.88 /16.29 53,602 413 0.89 /16.52 45,703 414 0.90 /16.70 40,302 415 0.91 /16.77 38,431 416 0.92 /16.81 37,381 417 0.93 /16.96 33,689 418 0.94 /17.26 27,364 419 0.95 /17.32 26,249 420 0.96 /17.33 26,068 421 0.97 /17.33 26,068 422 0.98 /17.40 24,834 423 0.99 /17.67 20,595 425 Figure 6 427 The implication of these results is that it is probable that a IPv6 428 address registry will see sufficient distribution of allocation 429 request sizes such that the choice of a threshold HD- Ratio will 430 impact the total address consumption rates, and the variance between 431 an HD-Ratio of 0.8 and an HD-Ratio of 0.99 is a factor of one order 432 of magnitude in relative address consumption over an extended period 433 of time. The simulation also indicates that the overall majority of 434 allocations fall within a /32 minimum allocation size (between 74% to 435 95% of all address allocations), and the selection of a particular 436 HD-Ratio value has a significant impact in terms of allocation sizes 437 for a small proportion of allocation transactions (the remainder of 438 allocations range between a /19 to a /31 for an HD-Ratio of 0.8 and 439 between a /26 and a /31 for an HD-Ratio of 0.99). 441 The conclusion here is that the choice of the HD-Ratio will have some 442 impact on one quarter of all allocations, while the remainder are 443 serviced using the minimum allocation unit of a /32 address prefix. 444 Of these 'impacted' allocations that are larger than the minimum 445 allocation, approximately one tenth of these allocations are 'large' 446 allocations. These large allocations have a significant impact on 447 total address consumption, and varying the HD-Ratio for these 448 allocations between 0.8 to 0.99 results in a net difference in total 449 address consumption of approximately one order of magnitude. This is 450 a heavy-tail distribution, where a small proportion of large address 451 allocations significantly impact the total address consumption rate. 452 Altering the HD-Ratio will have little impact on more than 95% of the 453 IPv6 allocations, but will generate significant variance within the 454 largest 2% of these allocations, which, in turn, will have a 455 significant impact on total address consumption rates. 457 7. Considerations 459 The HD-Ratio with a value of 0.8 as a model of network address 460 utilization efficiency produces extremely low efficiency outcomes for 461 networks spanning of the order of 10**6 end customers and larger. 463 The HD-Ratio with a 0.8 value makes the assumption that as the 464 address allocation block increases in size the network within which 465 the addresses will be deployed adds additional levels of hierarchical 466 structure. This increasing depth of hierarchical structure to 467 arbitrarily deep hierarchies is not a commonly observed feature of 468 public IP network deployments. 470 The fixed efficiency model, as used in the IPv4 address allocation 471 policy, uses the assumption that as the allocation block becomes 472 larger the network structure remains at a fixed level of levels, or 473 if the number of levels is increased, then efficiency achieved at 474 each level increases significantly. There is little evidence to 475 suggest that increasing number of levels in a network hierarchy 476 increases the efficiency at each level. 478 It is evident that neither of these models accurately encompass IP 479 network infrastructure models and the associated requirements of 480 address deployment. The fixed efficiency model places an excessive 481 burden on the network operator to achieve very high levels of 482 utilization at each level in the network hierarchy, leading to either 483 customer renumbering or deployment of technologies such as Network 484 Address Translation (NAT) to meet the target efficiency value in a 485 hierarchically structured network. The HD-Ratio model using a value 486 of 0.8 specifies an extremely low address efficiency target for 487 larger networks, and while this places no particular stress on 488 network architects in terms of forced renumbering, there is the 489 concern that this represents an extremely inefficient use of address 490 resources. If the objective of IPv6 is to encompass a number of 491 decades of deployment, and span a public network that ultimately 492 encompasses many billions of end customers, and a very high range and 493 number of end use devices and components, then there is legitimate 494 cause for concern that the HD-Ratio value of 0.8 may be setting too 495 conservative a target for address efficiency, in that the total 496 address consumption targets may be achieved too early. 498 This study concludes that consideration should be given to the 499 viability of specifying a higher HD-Ratio value as representing a 500 more relevant model of internal network structure, internal routing 501 and internal address aggregation structures in the context of IPv6 502 network deployment. 504 8. Security Considerations 506 Considerations of various forms of host density metrics creates no 507 new threats to the security of the Internet. 509 9. Acknowledgements 511 The document was reviewed by Kurt Lindqvist, Thomas Narten, Paul 512 Wilson, David Kessens, Bob Hinden, Brian Haberman and Marcelo 513 Bagnulo. 515 10. References 517 10.1. Normative References 519 [RFC1715] Huitema, C., "The H Ratio for Address Assignment 520 Efficiency", RFC 1715, November 1994. 522 [RFC3177] IAB and IESG, "IAB/IESG Recommendations on IPv6 Address 523 Allocations to Sites", RFC 3177, September 2001. 525 [RFC3194] Durand, A. and C. Huitema, "The H-Density Ratio for 526 Address Assignment Efficiency An Update on the H ratio", 527 RFC 3194, November 2001. 529 [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 530 (IPv6) Addressing Architecture", RFC 3513, April 2003. 532 10.2. Informative References 534 [RIR-Data] 535 RIRs, "RIR Delegation Records", February 2005, 536 . 538 Appendix A. Comparison Tables 540 The first table compares the threshold number of /48 end user 541 allocations that would be performed for a given assigned address 542 block in order to consider that the utilization has achieved its 543 threshold utilization level. 545 Fixed Efficiency Value 0.8 546 HD-Ratio Value 0.8 548 Number of /48 allocations to fill the 549 address block to the threshold level 551 Prefix Size Fixed Efficiency HD-Ratio 552 0.8 0.8 554 /48 1 1 100% 1 100% 555 /47 2 2 100% 2 87% 556 /46 4 4 100% 3 76% 557 /45 8 7 88% 5 66% 558 /44 16 13 81% 9 57% 559 /43 32 26 81% 16 50% 560 /42 64 52 81% 28 44% 561 /41 128 103 80% 49 38% 562 /40 256 205 80% 84 33% 563 /39 512 410 80% 147 29% 564 /38 1,024 820 80% 256 25% 565 /37 2,048 1,639 80% 446 22% 566 /36 4,096 3,277 80% 776 19% 567 /35 8,192 6,554 80% 1,351 16% 568 /34 16,384 13,108 80% 2,353 14% 569 /33 32,768 26,215 80% 4,096 13% 570 /32 65,536 52,429 80% 7,132 11% 571 /31 131,072 104,858 80% 12,417 9% 572 /30 262,144 209,716 80% 21,619 8% 573 /29 524,288 419,431 80% 37,641 7% 574 /28 1,048,576 838,861 80% 65,536 6% 575 /27 2,097,152 1,677,722 80% 114,105 5% 576 /26 4,194,304 3,355,444 80% 198,668 5% 577 /25 8,388,608 6,710,887 80% 345,901 4% 578 /24 16,777,216 13,421,773 80% 602,249 4% 579 /23 33,554,432 26,843,546 80% 1,048,576 3% 580 /22 67,108,864 53,687,092 80% 1,825,677 3% 581 /21 134,217,728 107,374,180 80% 3,178,688 2% 582 /20 268,435,456 214,748,365 80% 5,534,417 2% 583 /19 536,870,912 429,496,730 80% 9,635,980 2% 584 /18 1,073,741,824 858,993,460 80% 16,777,216 2% 585 /17 2,147,483,648 1,717,986,919 80% 29,210,830 1% 586 /16 4,294,967,296 3,435,973,837 80% 50,859,008 1% 587 /15 8,589,934,592 6,871,947,674 80% 88,550,677 1% 588 /14 17,179,869,184 13,743,895,348 80% 154,175,683 1% 589 /13 34,359,738,368 27,487,790,695 80% 268,435,456 1% 590 /12 68,719,476,736 54,975,581,389 80% 467,373,275 1% 591 /11 137,438,953,472 109,951,162,778 80% 813,744,135 1% 592 /10 274,877,906,944 219,902,325,556 80% 1,416,810,831 1% 593 /9 549,755,813,888 439,804,651,111 80% 2,466,810,934 0% 594 /8 1,099,511,627,776 879,609,302,221 80% 4,294,967,296 0% 595 /7 2,199,023,255,552 1,759,218,604,442 80% 7,477,972,398 0% 596 /6 4,398,046,511,104 3,518,437,208,884 80% 13,019,906,166 0% 597 /5 8,796,093,022,208 7,036,874,417,767 80% 22,668,973,294 0% 599 Table 1: Comparison of Fixed Efficiency threshold vs HD-Ratio 600 Threshold 602 Figure 7 604 One possible assumption behind the HD ratio is that the 605 inefficiencies that are a consequence of large scale deployments are 606 an outcome of increased number of levels of hierarchical structure 607 within the network. The following table calculates the depth of the 608 hierarchy in order to achieve a 0.8 HD ratio, assuming a 0.8 609 utilization efficiency at each level in the hierarchy. 611 Prefix Size 0.8 Structure 612 HD Ratio Levels 613 /48 1 1 1 614 /47 2 2 1 615 /46 4 3 2 616 /45 8 5 2 617 /44 16 9 3 618 /43 32 16 4 619 /42 64 28 4 620 /41 128 49 5 621 /40 256 84 5 622 /39 512 147 6 623 /38 1,024 256 7 624 /37 2,048 446 7 625 /36 4,096 776 8 626 /35 8,192 1,351 9 627 /34 16,384 2,353 9 628 /33 32,768 4,096 10 629 /32 65,536 7,132 10 630 /31 131,072 12,417 11 631 /30 262,144 21,619 12 632 /29 524,288 37,641 12 633 /28 1,048,576 65,536 13 634 /27 2,097,152 114,105 14 635 /26 4,194,304 198,668 14 636 /25 8,388,608 345,901 15 637 /24 16,777,216 602,249 15 638 /23 33,554,432 1,048,576 16 639 /22 67,108,864 1,825,677 17 640 /21 134,217,728 3,178,688 17 641 /20 268,435,456 5,534,417 18 642 /19 536,870,912 9,635,980 19 643 /18 1,073,741,824 16,777,216 19 644 /17 2,147,483,648 29,210,830 20 645 /16 4,294,967,296 50,859,008 20 646 /15 8,589,934,592 88,550,677 21 647 /14 17,179,869,184 154,175,683 22 648 /13 34,359,738,368 268,435,456 22 649 /12 68,719,476,736 467,373,275 23 650 /11 137,438,953,472 813,744,135 23 651 /10 274,877,906,944 1,416,810,831 24 652 /9 549,755,813,888 2,466,810,934 25 653 /8 1,099,511,627,776 4,294,967,296 25 655 Table 2: Number of Structure Levels assumed by HD-Ratio 657 Figure 8 658 An alternative approach is to use a model of network deployment where 659 the number of levels of hierarchy increases at a lower rate than that 660 indicated in a 0.8 HD ratio model. One such model is indicated in 661 the following table. This is compared to using an HD-Ratio value of 662 0.94. 664 Per-Level Target Efficiency: 0.75 666 Prefix Size Stepped Stepped Efficiency HD-Ratio 667 Levels 0.75 0.94 669 /48 1 1 1 100% 1 100% 670 /47 2 1 2 100% 2 100% 671 /46 4 1 3 75% 4 100% 672 /45 8 1 6 75% 7 88% 673 /44 16 1 12 75% 13 81% 674 /43 32 1 24 75% 25 78% 675 /42 64 1 48 75% 48 75% 676 /41 128 1 96 75% 92 72% 677 /40 256 1 192 75% 177 69% 678 /39 512 2 384 75% 338 66% 679 /38 1,024 2 576 56% 649 63% 680 /37 2,048 2 1,152 56% 1,244 61% 681 /36 4,096 2 2,304 56% 2,386 58% 682 /35 8,192 2 4,608 56% 4,577 56% 683 /34 16,384 2 9,216 56% 8,780 54% 684 /33 32,768 2 18,432 56% 16,845 51% 685 /32 65,536 2 36,864 56% 32,317 49% 686 /31 131,072 3 73,728 56% 62,001 47% 687 /30 262,144 3 110,592 42% 118,951 45% 688 /29 524,288 3 221,184 42% 228,210 44% 689 /28 1,048,576 3 442,368 42% 437,827 42% 690 /27 2,097,152 3 884,736 42% 839,983 40% 691 /26 4,194,304 3 1,769,472 42% 1,611,531 38% 692 /25 8,388,608 3 3,538,944 42% 3,091,767 37% 693 /24 16,777,216 3 7,077,888 42% 5,931,642 35% 694 /23 33,554,432 4 14,155,776 42% 11,380,022 34% 695 /22 67,108,864 4 21,233,664 32% 21,832,894 33% 696 /21 134,217,728 4 42,467,328 32% 41,887,023 31% 697 /20 268,435,456 4 84,934,656 32% 80,361,436 30% 698 /19 536,870,912 4 169,869,312 32% 154,175,684 29% 699 /18 1,073,741,824 4 339,738,624 32% 295,790,403 28% 700 /17 2,147,483,648 4 679,477,248 32% 567,482,240 26% 701 /16 4,294,967,296 4 1,358,954,496 32% 1,088,730,702 25% 702 /15 8,589,934,592 5 2,717,908,992 32% 2,088,760,595 24% 703 /14 17,179,869,184 5 4,076,863,488 24% 4,007,346,185 23% 704 /13 34,359,738,368 5 8,153,726,976 24% 7,688,206,818 22% 705 /12 68,719,476,736 5 16,307,453,952 24% 14,750,041,884 21% 706 /11 137,438,953,472 5 32,614,907,904 24% 28,298,371,876 21% 707 /10 274,877,906,944 5 65,229,815,808 24% 54,291,225,552 20% 708 /9 549,755,813,888 5 130,459,631,616 24% 104,159,249,331 19% 709 /8 1,099,511,627,776 5 260,919,263,232 24% 199,832,461,158 18% 710 Table 3: Limited Levels of Structure 712 Figure 9 714 Appendix B. Draft Notes 716 [This section not for RFC publication] 718 This memo has been reviewed by an ad hoc advisory committee to advise 719 the IAB on a number of matters relating to IPv6. It is proposed that 720 the note be published as an informational RFC, as it does not propose 721 any specific alteration to the IPv6 specification. 723 Author's Address 725 Geoff Huston 726 APNIC 728 Email: gih@apnic.net 730 Intellectual Property Statement 732 The IETF takes no position regarding the validity or scope of any 733 Intellectual Property Rights or other rights that might be claimed to 734 pertain to the implementation or use of the technology described in 735 this document or the extent to which any license under such rights 736 might or might not be available; nor does it represent that it has 737 made any independent effort to identify any such rights. Information 738 on the procedures with respect to rights in RFC documents can be 739 found in BCP 78 and BCP 79. 741 Copies of IPR disclosures made to the IETF Secretariat and any 742 assurances of licenses to be made available, or the result of an 743 attempt made to obtain a general license or permission for the use of 744 such proprietary rights by implementers or users of this 745 specification can be obtained from the IETF on-line IPR repository at 746 http://www.ietf.org/ipr. 748 The IETF invites any interested party to bring to its attention any 749 copyrights, patents or patent applications, or other proprietary 750 rights that may cover technology that may be required to implement 751 this standard. Please address the information to the IETF at 752 ietf-ipr@ietf.org. 754 Disclaimer of Validity 756 This document and the information contained herein are provided on an 757 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 758 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 759 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 760 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 761 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 762 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 764 Copyright Statement 766 Copyright (C) The Internet Society (2005). This document is subject 767 to the rights, licenses and restrictions contained in BCP 78, and 768 except as set forth therein, the authors retain all their rights. 770 Acknowledgment 772 Funding for the RFC Editor function is currently provided by the 773 Internet Society.