INTERNET-DRAFT Thomas Narten IBM June 16, 2005 Issues Related to the Management of IPv6 Address Space Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft expires on December 16, 2005. Abstract This document reviews the history of IPv6 address delegation and examines some of the technical implications of various allocation policies in terms of their impact on long-term address space utilization and aggregation. The purpose of this document is to stimulate discussion and foster improved understanding of the implications of various policies, so that appropriate policies are adopted that preserve the long-term scalability of IPv6. Contents draft-narten-iana-rir-ipv6-considerations-00.txt [Page 1] INTERNET-DRAFT June 16, 2005 Status of this Memo.......................................... 1 1. Introduction............................................. 3 2. Definitions.............................................. 3 2.1. Internet Registry (IR).............................. 3 2.2. Regional Internet Registry (RIR).................... 4 2.3. National Internet Registry (NIR).................... 4 2.4. Local Internet Registry (LIR)....................... 4 2.5. Allocate............................................ 4 2.6. Assign.............................................. 4 2.7. Utilization......................................... 4 2.8. HD-Ratio............................................ 5 3. Background............................................... 5 3.1. IPv6 Address Structure.............................. 6 3.2. IPv6 Address Assignment History..................... 7 3.3. Goals of IPv6 Address Space Management.............. 7 3.4. Utilization......................................... 8 3.5. Aggregation......................................... 9 4. How Much Address Space Do We Really Have?................ 10 4.1. An example: Cable Modem/DSL Service in US........... 10 4.2. How Much Is Enough?................................. 11 5. On RIR->LIR->End User Assignment and Allocation Policies. 12 5.1. On the HD Ratio Metric.............................. 12 5.2. On /48 Assignments to End Sites..................... 12 5.3. On the /64 Boundary................................. 15 5.4. Summing It All Up................................... 15 6. On Reservations and Aggregation.......................... 17 6.1. On RIR Reservations................................. 17 6.2. On IANA->RIR Assignments............................ 18 7. Security Considerations.................................. 18 8. IANA Considerations...................................... 18 9. Acknowledgments.......................................... 18 10. References.............................................. 18 11. Appendix A: HD-Ratio.................................... 20 12. Authorどﾖs Address...................................... 21 draft-narten-iana-rir-ipv6-considerations-00.txt [Page 2] INTERNET-DRAFT June 16, 2005 1. Introduction The assignment and allocation of global IPv6 unicast address space to ISPs and end-users is implemented under policies maintained and implemented by the Regional Internet Registries (RIRs) and IANA. End users typically get IPv6 address space from their ISPs, who in turn obtain allocations from RIRs. RIRs in turn obtain address space from IANA. This document reviews the history of IPv6 address delegation and examines some of the technical implications of various allocation policies in terms of their impact on long-term address space utilization and aggregation. The purpose of this document is stimulate discussion and foster improved understanding of the implications of various policies, so that appropriate policies are adopted that preserve the long-term scalability of IPv6. Questions that this document attempts to shed light on include: - How large should the chunks be that IANA allocates to RIRs? - How much (if any) space should IANA hold in "reserve", to allow a RIR (or LIR) to "grow into" if/when it needs a further allocation? - What algorithms should RIRs use to manage their space, and at what point are they justified in asking IANA for more address space? - What are the long-term implications of these algorithms on overall IPv6 address space consumption, utilization and aggregability? 2. Definitions [Note: the following definitions are taken (and in some cases slightly modified) from the "IPv6 Address Allocation and Assignment Assignment Policy" document that was produced and adopted by the APNIC, ARIN and RIPE communities in 2002.] 2.1. Internet Registry (IR) An Internet Registry (IR) is an organization that is responsible for distributing IP address space to its members or customers and for registering those distributions. IRs are classified according to their primary function and territorial scope. draft-narten-iana-rir-ipv6-considerations-00.txt [Page 3] INTERNET-DRAFT June 16, 2005 2.2. Regional Internet Registry (RIR) Regional Internet Registries (RIRs) are established and authorized by respective regional communities, and recognized by the IANA to serve and represent large geographical regions. The primary role of RIRs is to manage and distribute public Internet address space within their respective regions. Currently, there are five RIRs: AFRINIC, APNIC, ARIN, LACNIC, and RIPE. 2.3. National Internet Registry (NIR) A National Internet Registry (NIR) primarily allocates address space to its members or constituents, which are generally LIRs organized at a national level. NIRs exist mostly in the Asia Pacific region. 2.4. Local Internet Registry (LIR) A Local Internet Registry (LIR) is an IR that primarily assigns address space to the users of the network services that it provides. LIRs are generally ISPs, whose customers are primarily end users or other ISPs. 2.5. Allocate To allocate means to distribute address space to IRs for the purpose of subsequent distribution by them. 2.6. Assign To assign means to delegate address space to an ISP or end-user, for specific use within the Internet infrastructure they operate. Assignments are made for specific documented purposes by specific organizations and are not sub-assigned to other parties. 2.7. Utilization In IPv4, the utilization of a chunk of address space is defined as the ratio of the actual number of host assignments to the theoretical maximum number of host assignments. For example, a /24 in IPv4 can number 256 hosts, and if 200 have been assigned to hosts, the utilization would be 200/256 or 78%. In IPv4, a utilization ratio of 80% is the threshold value used to justify the granting of additional address space. When an entity has used up 80% of its space, it is draft-narten-iana-rir-ipv6-considerations-00.txt [Page 4] INTERNET-DRAFT June 16, 2005 eligible to receive more. Unlike IPv4, IPv6 is generally assigned to end sites in fixed amounts (e.g., in the /48 to /64 range per current address distribution policies). The actual "utilization" of an IPv6 address block in absolute terms (i.e., counting numbers of assigned hosts) will be exceedingly low. Thus, in IPv6, "utilization" is no longer the metric used for determining when additional address space can be obtained. Instead, an HD Metric is used, and it counts "links" or "subnets" rather than individual host assignments. In the context of IPv6, the term utilization refers to the allocation of address blocks to end sites, and not the number of addresses assigned within individual /48s at end sites. 2.8. HD-Ratio The HD-Ratio is a way of measuring the efficiency of address assignment [RFC 3194]. It is an adaptation of the H-Ratio originally defined in [RFC1715] and is expressed as follows: Log (number of allocated objects) HD = ------------------------------------------------ Log (maximum number of allocatable objects) where the objects are IPv6 end site assignments (e.g., /48s) assigned from an IPv6 prefix of a given size. The term "HD ratio" is somewhat misleading in the context of IPv6, since it is used to measure "site density" rather than "host density". 3. Background The IETF has indicated that IANA may allocate IPv6 unicast address space out of the block 2000::/3, with the remaining 7/8ths of the address space to be held in reserve [RFC3513]. IANA, in turn, has been allocating small chunks of that address space to individual RIRs. The individual RIRs allocate addresses to ISPs (or more precisely, to LIRs), who then assign them to end sites. End sites are typically given assignments in the /48-/64 range, consistent with the recommendations given in [RFC 3177] and adopted RIR policy [RIR- IPV6]. draft-narten-iana-rir-ipv6-considerations-00.txt [Page 5] INTERNET-DRAFT June 16, 2005 3.1. IPv6 Address Structure The general format of an IPv6 global unicast address is defined in RFC3513 [RFC3513]: | 64 - m bits | m bits | 64 bits | +------------------------+-----------+----------------------------+ | global routing prefix | subnet ID | interface ID | +------------------------+-----------+----------------------------+ IPv6 Address Structure Figure 1 The 64-bit IPv6 interface ID is an architectural boundary defined by Stateless Address Autoconfiguration [RFC2462]. Thus, in terms of RIR/IANA address allocation policy, the left-most 64 bits of an IPv6 address are managed through the IANA/RIR processes. Under the current IPv6 allocation policies, the value for どﾖmどﾖ in the figure above is commonly assumed to be 16, such that the global routing prefix is 48 bits in length and the per-customer subnet ID is 16 bits in length. It is worth noting that the 16-bit subnet identifier is a policy choice, not an architectural one. Specifically, [RFC 3513bis] Section 2.5 says: A slightly sophisticated host (but still rather simple) may additionally be aware of subnet prefix(es) for the link(s) it is attached to, where different addresses may have different values for n: | n bits | 128-n bits | +-------------------------------+---------------------------------+ | subnet prefix | interface ID | +-------------------------------+---------------------------------+ Though a very simple router may have no knowledge of the internal structure of IPv6 unicast addresses, routers will more generally have knowledge of one or more of the hierarchical boundaries for the operation of routing protocols. The known boundaries will differ from router to router, depending on what positions the router holds in the routing hierarchy. Except for the knowledge of the subnet boundary discussed in the previous paragraphs nodes should not make any assumptions about the structure of an IPv6 address. draft-narten-iana-rir-ipv6-considerations-00.txt [Page 6] INTERNET-DRAFT June 16, 2005 The use of a 16-bit subnet ID is a policy rather than architectural boundary, and the arguments for choosing a subnet ID of 16 are documented in the IAB/IESG recommendations given in [RFC3177]. Although the RIR community adopted these recommendations, there have been on-going discussions within the RIR community as to whether giving a full 16 bits of subnet space to (essentially) all end sites is justified, necessary or prudent. The size of the subnet ID that is used by end sites has a significant impact on the overall utilization of IPv6 address space that can be achieved. For example, using a subnet ID of 8 bits (i.e., 256 values) would increase the effective size of the global routing prefix from 48 to 56 bits, an increase in size of two orders of magnitude. 3.2. IPv6 Address Assignment History The earliest allocations from IANA to RIRs were made in July, 1999 and consisted of /23 allocations [IAB-IANA98]. Out of these allocations, the RIRs began allocating /35s to LIRs. In 2001, [RFC 3177] was developed, which called for assigning /48s to end sites in many cases. These recommendations were adopted by the RIRs in 2002 [RIR-IPV6]. Simultaneously, it was recognized that if LIRs were assigning /48s, but were assigning them out of a /35, the size of the RIR->LIR allocation also needed to be increased. Both changes are described in [RIR-IPV6], and that policy is still largely in place today. From 1999 until December 2004, the size of the IANA->RIR allocation was a /23, an allocation size that had not been changed even though allocation policies had been significantly revised and updated since 1999. Moreover, in 2004, the RIRs began receiving requests from LIRs for (relatively) large amounts of address space that were justified under the in-place allocation policies, including requests for more than the default minimum size of /32. The combination of in-place allocation policies together with ISPs requesting IPv6 address allocations for numbering millions of end sites led to a need to revisit the default IANA->RIR allocation size, a topic under current discussion within the RIR community [RIR-IANA-IPV6]. A detailed listing of all the IPv6 assignments that have been made can be found at [IPv6-STATS]. 3.3. Goals of IPv6 Address Space Management Two important goals in the management of address space are to ensure reasonable levels of utilization (so that we donどﾖt exhaust the address space itself) as well as achieving good levels of draft-narten-iana-rir-ipv6-considerations-00.txt [Page 7] INTERNET-DRAFT June 16, 2005 aggregation. In the current Internet routing architecture (i.e., CIDR) aggregation is necessary in order to keep the size of the routing table manageable. By "size", we refer not just to the size of forwarding table (in terms of numbers of individual entries), but also the cost and overhead of sending routing updates (in terms of bandwidth needed), the processing power needed for the routing algorithms to converge in a timely fashion, and on the overall understandability and manageability of the system from an operational perspective. 3.4. Utilization In IPv4, there has been much emphasis on maintaining high utilization of the address space. Indeed, IPv4 address allocation policies use an "80% utilization" rule. Sites and LIRs are eligible for additional address space when they can demonstrate usage of 80% of the space they have been assigned. Likewise, LIRs obtain more space from RIRs when their utilization reaches 80%. With IPv6, justification for obtaining address space is different in two important ways: 1) Rather than use a "absolute percentage utilization" metric to indicate thresholds, an HD-ratio metric is used. Under the policy rules adopted in 2002, a site or LIR is eligible for more address space once it shows that the amount of address space it has used exceeds an HD ratio of .8. 2) Rather than count "numbers of hosts assigned", the IPv6 HD ratio counts "assignments to end sites", typically /48 assignments; the actual number of devices assigned to those sites is not a factor. Comparing just the HD-ratio metric to the 80% rule, an HD-ratio metric of .8 is significantly easier to satisfy than 80% rule, especially for LIRs (e.g., see [huston-hd-metric]). As the table in Appendix A shows, for a /32 assignment, an LIR need only assign 7132 /48s to reach the threshold, which corresponds to an absolute utilization of only 10.9%. Moreover, Appendix A also shows that the required level of utilization (in absolute percentage terms) decreases as the amount of address space the ratio is applied to increases. For example, one need only achieve a utilization of roughly 2-3% to justify allocations in the /20-/23 range, and this does not even consider that the IPv6 formula counts sites rather than host assignments. The amount of address space available in IPv6 is immensely larger than that available in IPv4. The IETF has intentionally chosen to use draft-narten-iana-rir-ipv6-considerations-00.txt [Page 8] INTERNET-DRAFT June 16, 2005 address space relatively inefficiently (compared with IPv4) in order to simplify other aspects of IPv6. For example, lower utilization levels have the benefit of simplifying addressing at end sites (e.g., through use of stateless address autoconfiguration [RFC 2462]); end sites get enough address space that they do not constantly have to renumber in order to maintain a high utilization, and get significantly more address space for a given sized-site than under the corresponding policies for IPv4 space. Having said that, prudence calls for not being needlessly wasteful in terms of address space usage. It is hard to predict what the Internet will look like in 20-50 years, and poor decisions made now will almost certainly be very difficult to undo later. 3.5. Aggregation One important goal for IPv6 is to achieve good aggregation of addresses over significantly longer-term time frames than in IPv4. Specifically, thought should be given to ensuring aggregation over time frames on the order of 10-20 years (and longer), rather than just 2 or 3. Routing in IPv6 is fundamentally equivalent to routing in IPv4, namely CIDR. Thus, the same pressures that have dominated IPv4 routing can be expected in IPv6. Namely, the desire for "provider independent" (PI) space, the desire to multi-home, etc. Although the IETFどﾖs multi6 and shim6 [shim6] efforts are developing a routing- infrastructure friendly (i.e., scalable) multi-homing solution, that work is still at a relatively early stage and is unlikely to result in widely-available, mature products for at least 5 years, even in optimistic scenarios. Moreover, it is unclear at the present time how broadly applicable the shim6 solution will ultimately be. Thus, it would be foolish at the present time to assume that routing in IPv6 will avoid any of the route scaling issues that continue to be a significant issue in IPv4. One consequence to the 80% rule as it has been applied to IPv4 is that it has contributed to significant fragmentation of the IPv4 address space, which leads to an inability to aggregate routes as much as might be desired. To be fair, that is not a result of the 80% rule per se, rather, it results from a number of factors: - RIRs do not hold in reserve large amounts of address space adjacent to an existing allocation to allow subsequent requests for additional space to be satisfied from an adjacent block. That is, policies governing when RIRs can request additional address space from IANA do not favor achieving good aggregation by draft-narten-iana-rir-ipv6-considerations-00.txt [Page 9] INTERNET-DRAFT June 16, 2005 allowing large amounts of space to be held in reserve. Indeed, achieving good levels of aggregation have simply not been considered important in practice and are not part of the adopted policies. Consequently, there are no incentives in the system for encouraging aggregation over long periods. - For various reasons (e.g., to get more optimal routing, traffic engineering, etc.), some LIRs deaggregate their allocations and advertise multiple longer prefixes. It should be noted that this type of fragmentation is reversible, since an LIR could fall back to advertising a single aggregate if necessary. That is, this type of fragmentation is an optimization, and isnどﾖt required in order to maintain basic connectivity for all end sites. - Mergers and acquisitions results in administratively related sites being comprised of address space that is not aggregatable. To support aggregation over time frames of 10-20 years (and beyond), and to avoid reliving the fragmentation experience of IPv4, RIR address policies must support the holding of adequately-sized "reservations" of address space adjacent to address space that has been delegated. Thus, the amount of space held in reserve by the RIRs, the manner in which it is held, and the time frame over which RIRs maintain that reserve are key policy questions with significant implications on long-term aggregation and fragmentation of the IPv6 address space. 4. How Much Address Space Do We Really Have? 4.1. An example: Cable Modem/DSL Service in US In the hallway at a recent ARIN meeting, I was cornered by someone who had done a back-of-the envelope calculation that led him to believe the current policies needed adjustment. The argument went like: If I assign 4M /48どﾖs of IPv6 (one to each cable modem on my network), according to the HD-ratio I am justified to obtain something around a /20 of IPv6 addresses. In other words, I am justified in getting 268M /48どﾖs even though I am only using 4M of them. That would be enough for me to assign at least two for every household in the US (not just the 19M on my network). Now if all the cable providers (e.g., Comcast, Cox, Adelphia, Cablevision, Time-Warner, etc.) did the same for their networks; and each of the DSL companies made a similar move (SBC, Verizon, draft-narten-iana-rir-ipv6-considerations-00.txt [Page 10] INTERNET-DRAFT June 16, 2005 Quest, etc.); perhaps we could easily see the broadband market in the US alone obtaining some 16 /20どﾖs of IPv6 or a total of /16. There are only 8192 of those available in the current global unicast space of 2001::/3. Anyhow, you can see where this might lead... 4.2. How Much Is Enough? At various times in the past, it has been asserted that we will "never run out of IPv6 addresses". For example, Wikipedia repeats the myth [WIKIPEDIA]: If the earth were made entirely out of 1 cubic millimetre grains of sand, then you could give a unique address to each grain in 300 million planets the size of the earth. These sorts of statements are made on the assumption that all of IPv6どﾖs 128-bit address space can be use efficiently for addressing devices. But as discussed earlier, only 64-bits are available for addressing links, since 64 bits are used for an interface identifier. Or, stated differently, the above figure is only true if one believes that one can have single links, on which 2^64 hosts can be attached; in practice, the actual number of hosts connected to a single link is on the order of tens to thousands, with most links at the lower end of the range. A more realistic measure is to consider how many links, or end sites can be addressed. One way to frame the discussion is to ask the question: how many devices will a person or end site need to be able to assign addresses to? World population projections for the year 2050 estimate a world population of 9.2B persons [CENSUS]. Under the current address allocation policies (specifically, /48 to end sites and use of an HD- ratio threshold of .8), the following observation can be made. If we allow for one /48 per person, and assume there is only a single ISP for everyone, 9.2B /48s corresponds to a /7, or 1/128th of the entire available address space (and fully 1/16th of 2001::/3). Clearly, this does not indicate a need to panic or that IPv6 will run out of addresses. However, such numbers are also nowhere near "practically infinite". A key policy question is whether the community is comfortable with a projection that can result in fully 1% of the available address space used up in 50 years, given: draft-narten-iana-rir-ipv6-considerations-00.txt [Page 11] INTERNET-DRAFT June 16, 2005 - the inherent uncertainties of predicting future address consumption rates (e.g., an appropriate number of devices per person, and indeed whether a per-person perspective is even the appropriate one). - the inherent uncertainty in the length of time that IPv6 will be a key part of the underlying infrastructure (i.e., 50 vs. 100 vs. 200 years). - a long history of infamous "predictions", e.g., "640K ought to be enough for anybody." - Bill Gates [GATES-640K] 5. On RIR->LIR->End User Assignment and Allocation Policies 5.1. On the HD Ratio Metric The current use of the HD Metric is documented in [RIR-IPV6]. An HD ratio of .8 is the threshold for justifying additional allocations. Now that we have some operational experience with using the HD-Ratio, we are seeing some (on the surface surprisingly) large allocations being made. They are "surprising" in the sense that people who look at specific examples feel that the current policies grant far more address space than a service provider actually needs to (comfortably) number their infrastructure and customer networks. Using the example from Section 4.1, a large cable/DSL provider could obtain a /20, even though that corresponds to a utilization of only 2.1% (In IPv4, 80% utilization would be required). The topic of various HD Ratio values and their implications are discussed in more detail in [huston-hd-ratio]. That work suggests that changing the HD ratio threshold from .8 to .94 reduces the overall address space consumption by an equivalent of 3 bits of address space over the next 50 years, without imposing hardship on ISPs/LIRs in numbering their networks. In addition, the work also suggests that a small number of "big" allocations accounts for a disproportionately large amount of total projected address space consumption. 5.2. On /48 Assignments to End Sites Per existing policy, the RIRs assume that end site assignments are /48s, and thus utilization measurements are based on an HD-ratio that counts numbers of /48 assignments. Granting a /48 to an end site, allows a site to have up to 65,536 subnets. While that number may make sense for larger sites, it is hard to imagine a typical home draft-narten-iana-rir-ipv6-considerations-00.txt [Page 12] INTERNET-DRAFT June 16, 2005 user requiring so much space. Indeed, the default end site assignment today is in practice the same for home users and larger businesses. Looking back at some of the original motivations behind the /48 recommendation [RFC 3177], one overriding concern was to ensure that end sites could easily obtain sufficient address space without having to "jump through hoops" to do so. For example, if someone felt they needed more space, just the act of asking would at some level be sufficient justification. As a comparison point, in IPv4, typical home users are given a single public IP address (even this is not always assured), but getting even a small number more is typically more expensive either in terms of the effort needed to obtain additional addresses, or in the actual monthly cost. (It should be noted that the "cost" of additional addresses cannot be justified by the actual cost of those addresses as charged by the RIRs, but the need for additional addresses is sometimes used to imply a different type or "higher grade" of service, for which some ISPs charge extra.) Thus, an important goal in IPv6 was to significantly change the default and minimal end site assignment, from "a single address" to "multiple networks". Another concern was that if a site changes ISPs and subsequently renumbers, renumbering from a larger set of "subnet bits" into a smaller set is particularly painful, as it it can require making changes to the network itself (e.g., collapsing links). In contrast, renumbering a site into a prefix that has the same number (or more) of subnet bits is easier, because only the top-level bits of the address need to change. Thus, another goal of the RFC 3177 recommendation is to ensure that upon renumbering, one does not have to deal with renumbering into a smaller subnet size. The above concerns were met by the /48 recommendation, but could also be realized through a more conservative approach. For example, one can imagine "classes" of network types, with default sizes for each class. For example: - a PDA-type device with a low bandwidth WAN connection and one additional PAN connection - a single network or /64 assignment. A /64 assignment allows for the addressing of a number of hosts, each connected to the same PAN (personal area network, e.g., Bluetooth) link as the device. This would be appropriate in deployments where the end device is not expected to provide connectivity for a larger site, but is intended to provide connectivity for the device and a small number of additional devices directly connected to the same PAN as the device. - home user - expected to have a small number of subnets, e.g., less than 10 - a /56 (or /60) assignment draft-narten-iana-rir-ipv6-considerations-00.txt [Page 13] INTERNET-DRAFT June 16, 2005 - small business/organization - one having a small number of networks, e.g., less than 100 - a /56 assignment - large business/organization - an organization having more than 100 subnets - a /48. A change in policy (such as above) would have a significant impact on address consumption projections and the expected longevity for IPv6. For example, changing the default assignment from a /48 to /56 (for the vast majority of end sites) would result in a savings of up to 8 bits, reducing the "total projected address consumption" by (up to) 8 bits or two orders of magnitude. (The exact amount of savings depends on the relative number of home users compared with the number of larger sites.) One can, of course, imagine a policy supporting the entire range of assignments between /48 and /64, depending on the size or type of end site. However, there are a number of arguments in favor of having a small number of classes of sizes: - It becomes easier for end users to identify an assignment size that is appropriate for them - It increases the likelihood that there will be agreement among ISPs on the appropriate assignment sizes for the various customer classes. - Having excess flexibility in selecting an appropriate assignment size for a given customer type can lead to different ISPs offering different assignment sizes to the same customer. This is undesirable because it may result in - an end site needing to renumber into a smaller subnet space when switching ISPs, or - it may lead to ISPs attempting to differentiate their service offerings by offering the most liberal address assignment policies (to attract customers), defeating the purpose of having multiple class assignment sizes. - The operational management of the reverse DNS tree is simplified if delegations are on nibble boundaries (e.g., /48, /52, /56, and /64). draft-narten-iana-rir-ipv6-considerations-00.txt [Page 14] INTERNET-DRAFT June 16, 2005 5.3. On the /64 Boundary In theory, even more savings could be realized by reducing the size of the Interface identifier, i.e., making it smaller than 64 bits. While possible, this is the most difficult boundary to move in practice. Considerations include: - Stateless address autoconfiguration [RFC 2462] assumes Interface identifiers are fixed at 64 bits. Changing this would require revising that specification and devising a transition plan for migrating existing implementations from 64-bit identifiers to something shorter. - Stateless address autoconfiguration has been widely implemented, with additional implementations in the pipeline. Removing those implementations and replacing them with upgraded implementations will take many years. - it is unclear how one would transition to Interface identifiers of shorter length in the short term while preserving stateless address autoconfiguration. - one transition strategy might be to disable stateless address autoconfiguration completely (for generating addresses) and use DHCP to assign addresses. However, client implementation of DHC for address configuration is not mandatory in IPv6, and it is believed that few IPv6 devices actually implement the client portion of address configuration via DHC. - some existing IPv6 multicast standards assume that an IPv6 routing prefix is no more than 64-bits in length, and include the 64-bit subnet prefix within an IPv6 multicast address [RFC3306,RFC3956]. 5.4. Summing It All Up A fundamental question to ask is whether the Internet community is comfortable that the current allocation policies will result in an reasonable address consumption projections over the lifetime of IPv6, and if not where and how does it make sense to propose changes. It should be noted that some have argued: Weどﾖre currently only allocating address space out out of prefix 001 and are holding the remaining 7/8ths of the available space in reserve. If we later determine weどﾖve been too liberal in our address usage, we can just implement more conservative policies draft-narten-iana-rir-ipv6-considerations-00.txt [Page 15] INTERNET-DRAFT June 16, 2005 for the remainder of the space. There are a number of reasons to give pause to that line of thinking: - The Internet has become a critical component of the worldどﾖs infrastructure, and its overall stewardship is a matter of public concern. Indeed, IP addresses are a global public resource that must be managed prudently and fairly. - It is far easier in practice to (later) liberalize a more conservative allocation policy than it is to convert a more liberal policy to one that is more conservative. Indeed, the IPv4 experience, in which early adopters were able to obtain large amounts of address space (e.g., class A and B blocks) while later adopters got significantly less, has led to significant and continuing unhappiness about unfairness in IPv4 address management. - Relatively small policy adjustments now would appear to significantly reduce the projected consumption of IPv6 address space, without causing significant hardship. In terms of ease of implementation, changing the HD ratio metric from .8 to something larger (e.g., .94) is the least painful. It has no impact on the assignments made to end sites and effects only the very largest of sites (at least in the short term). It would also be an easy value to change back downward (in the future), if needed. Making this type of change will reduce projected address space consumption my approximately one order of magnitude. Changing the default end site assignment sizes (e.g., moving from /48 to /56 for SOHO sites) has the potential for realizing even larger savings, i.e., on the order of two orders of magnitude. However, some issues apply: - a (relatively) small number of assignments have already been made. What should be done with those? How should they be counted? Should an attempt be made to reclaim them? - The existing minimum RIR->LIR allocation size of /32 is based on the assumption that end sites will be getting /48s. If the default size is end site allocation is changed, should the default minimum RIR->LIR allocation size also be adjusted downward? Finally, some of the issues relating to changing the size of the Interface identifier have been discussed in Section 5.3. In addition, draft-narten-iana-rir-ipv6-considerations-00.txt [Page 16] INTERNET-DRAFT June 16, 2005 the above concerns related to changing the /48 boundary would also apply to changing the /64 boundary, and in all likelihood would be even more complex (e.g., to deal with transition issues). In summary, in deciding which of the above factors to change, it is important to find an adequate balance between obtaining reasonable utilization for the long term balanced against the desire to maximize aggregatability within the routing table and to limit the amount of forwarding table route fragmentation. In addition, because IPv6 adddress space is a shared global resource, it must be managed in a prudent and fair manner. 6. On Reservations and Aggregation 6.1. On RIR Reservations In order to allow subsequent allocations from an LIR to expand the size of an existing address block allocation (as opposed to requiring the allocation of a different, non-aggregatable block), RIRs need to hold some space in reserve adjacent to an allocated block to allow for future growth. The reservation can be an explicit reservation, or it can be implicit if sparse allocation is employed [SPARSE]. As an RIR allocates address blocks to LIRs, at some point it will need to go back to the IANA to obtain additional space. In order to allow for good aggregation over very long periods of time (e.g., 10 years or more), it is important that sufficient space be held in reserve to allow for potential growth (i.e., subsequent adjacent allocations) over long time frames. That is, to allow for future aggregation, it would be better for RIRs to obtain additional space from IANA than to have them potentially fragment the address space by allocating space that would better be held in reserve for future adjacent allocations . An important policy question is how much space should be held for potential growth, the time period over which the space should be held in reserve, and how it is accounted for (e.g., when justifying the need for additional space from IANA). That is, what is the metric an RIR uses to justify going back to IANA for an additional address block. Does it count the reserved portion as being "allocated"? Does the RIR just use the same HD-ratio metric or a fixed percentage like IPv4? At the present time, it is unclear how much IPv6 address space the RIRs are holding in reserve for subsequent allocations, but there is some evidence that it is not very much, e.g., on the order of a draft-narten-iana-rir-ipv6-considerations-00.txt [Page 17] INTERNET-DRAFT June 16, 2005 single bit. 6.2. On IANA->RIR Assignments A current proposal under discussion with the RIR community calls for having a /12 being the default IANA->RIR allocation unit [IANA-RIR- IPV6]. This size appears to be large enough to allow RIRs to implement sparse allocation or a related scheme and hold sufficient space in "reserve" for the time being. [XXX need to fill in/explore this space in more detail.] Note that it generally makes no sense for IANA to hold additional space in reserve when delegating space to an RIR, because an RIR will sub-allocate chunks to LIRs out its delegation. In order for a subsequent allocation for one of those LIRs to aggregate, free space must exist adjacent to the requesting LIRどﾖs existing allocation. Any space held in reserve by IANA can only be adjacent to the left most or right most sub-delegated block. 7. Security Considerations 8. IANA Considerations This document makes no requests to IANA. 9. Acknowledgments This work has been greatly facilitated and influenced by discussions held within the IAB ad-hoc IPv6 committee, hallway and public discussions at ARIN XV and RIPE 50 meetings, and by discussions with Geoff Huston in particular. It has also benefit from review comments from Andrew Dul, Geoff Huston, Lea Roberts and Leo Vegoda. 10. References [GATES-640K] http://www.brainyquote.com/quotes/quotes/b/billgates103747.html [IAB-IANA98] http://www.iab.org/documents/docs/ipv6-address- space.html [IPv6-STATS] http://www.ripe.net/rs/ipv6/stats/ draft-narten-iana-rir-ipv6-considerations-00.txt [Page 18] INTERNET-DRAFT June 16, 2005 [RFC 3194] The H-Density Ratio for Address Assignment Efficiency An Update on the H ratio. A. Durand, C. Huitema. November 2001. [RFC 1715] The H Ratio for Address Assignment Efficiency. C. Huitema. November 1994. [RFC 3513] Internet Protocol Version 6 (IPv6) Addressing Architecture. R. Hinden, S. Deering. April 2003. [RFC 3513bis] draft-ietf-ipv6-addr-arch-v4-04.txt (Approved by IESG, awaiting publication in RFC Editor Queue.) [RFC 2462] IPv6 Stateless Address Autoconfiguration. S. Thomson, T. Narten. December 1998. [RFC3306] Unicast-Prefix-based IPv6 Multicast Addresses. B. Haberman, D. Thaler. August 2002. [RFC 3177] IAB/IESG Recommendations on IPv6 Address Allocations to Sites. IAB, IESG. September 2001. [RFC 3956] Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address. P. Savola, B. Haberman. November 2004. [RIR-IPV6] ARIN: http://www.arin.net/policy/index.html#six; RIPE Document ID: ripe-267, Date: 22 January 2003 http://www.ripe.net/ripe/docs/ipv6policy.html; APNIC: http://www.apnic.net/docs/policy/ipv6-address- policy.html [RIR-IANA-IPV6] http://www.arin.net/policy/proposals/2004_8.html (similar discussion can be found at the other RIRs as well) [shim6] shim6 is not yet a WG, but will be soon (hopefully). mailing list: shim6@psg.com, subscribe: majordomo:shim6@psg.com, archive: ftp://ftp.psg.com/pub/lists/shim6.* [huston-hd-metric] draft-huston-hd-metric-00.txt [WIKIPEDIA] http://en.wikipedia.org/wiki/IP_address [CENSUS] http://www.census.gov/ipc/www/worldpop.html draft-narten-iana-rir-ipv6-considerations-00.txt [Page 19] INTERNET-DRAFT June 16, 2005 [SPARSE] "IPv6 Address Space Management", Document ID: ripe-343, Date: 22 February 2005, Paul Wilson, Raymond Plzak, Axel Pawlik, http://www.ripe.net/ripe/docs/ipv6-sparse.html 11. Appendix A: HD-Ratio The following table provides equivalent absolute and percentage address utilization figures for IPv6 prefixes, corresponding to an HD-Ratio of 0.8 P 48-P Total /48s Threshold Util% 48 0 1 1 100.0% 47 1 2 2 87.1% 46 2 4 3 75.8% 45 3 8 5 66.0% 44 4 16 9 57.4% 43 5 32 16 50.0% 42 6 64 28 43.5% 41 7 128 49 37.9% 40 8 256 84 33.0% 39 9 512 147 28.7% 38 10 1024 256 25.0% 37 11 2048 446 21.8% 36 12 4096 776 18.9% 35 13 8192 1351 16.5% 34 14 16384 2353 14.4% 33 15 32768 4096 12.5% 32 16 65536 7132 10.9% 31 17 131072 12417 9.5% 30 18 262144 21619 8.2% 29 19 524288 37641 7.2% 28 20 1048576 65536 6.3% 27 21 2097152 114105 5.4% 26 22 4194304 198668 4.7% 25 23 8388608 345901 4.1% 24 24 16777216 602249 3.6% 23 25 33554432 1048576 3.1% 22 26 67108864 1825677 2.7% 21 27 134217728 3178688 2.4% 20 28 268435456 5534417 2.1% 19 29 536870912 9635980 1.8% 18 30 1073741824 16777216 1.6% 17 31 2147483648 29210830 1.4% 16 32 4294967296 50859008 1.2% 15 33 8589934592 88550677 1.0% draft-narten-iana-rir-ipv6-considerations-00.txt [Page 20] INTERNET-DRAFT June 16, 2005 14 34 17179869184 154175683 0.9% 13 35 34359738368 268435456 0.8% 12 36 68719476736 467373275 0.7% 11 37 137438953472 813744135 0.6% 10 38 274877906944 1416810831 0.5% 9 39 549755813888 2466810934 0.4% 8 40 1099511627776 4294967296 0.4% 7 41 2199023255552 7477972398 0.3% 6 42 4398046511104 13019906166 0.3% 5 43 8796093022208 22668973294 0.3% 4 44 17592186044416 39468974941 0.2% 12. Authorどﾖs Address Thomas Narten IBM Corporation 3039 Cornwallis Ave. PO Box 12195 - BRQA/502 Research Triangle Park, NC 27709-2195 Phone: 919-254-7798 EMail: narten@us.ibm.com Intellectual Property Statement 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. draft-narten-iana-rir-ipv6-considerations-00.txt [Page 21] INTERNET-DRAFT June 16, 2005 Disclaimer of Validity 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 Statement Copyright (C) The Internet Society (2005). 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. draft-narten-iana-rir-ipv6-considerations-00.txt [Page 22]