idnits 2.17.1 draft-iesg-ipv6-addressing-recommendations-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 481 lines 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.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (June 11, 2001) is 8355 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) -- Missing reference section? 'RFC2026' on line 16 looks like a reference -- Missing reference section? 'RFC2462' on line 88 looks like a reference -- Missing reference section? 'PRIVACY' on line 101 looks like a reference -- Missing reference section? 'RFC2374' on line 109 looks like a reference -- Missing reference section? 'RFC2450' on line 109 looks like a reference -- Missing reference section? 'RFC2874' on line 218 looks like a reference -- Missing reference section? 'RFC1715' on line 253 looks like a reference -- Missing reference section? 'RFC2260' on line 331 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT IAB/IESG 2 June 11, 2001 4 IAB/IESG Recommendations on IPv6 Address Allocations to Sites 6 8 Status of this Memo 10 [Note: This document is a draft position of the IAB and IESG. 11 Comments should be directed to iab@isi.edu and iesg@ietf.org. This 12 note will be removed upon publication as an RFC.] 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of [RFC2026]. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet- Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Abstract 35 This document provides recommendations to the addressing 36 registries(APNIC, ARIN and RIPE-NCC) on policies for assigning IPv6 37 address blocks to end sites. In particular, it recommends the 38 assignment of /48 in the general case, /64 when it is known that one 39 and only one subnet is needed and /128 when it is absolutely known 40 that one and only one device is connecting. 42 The original recommendations were made in an IESG/IAB statement 43 mailed to the registries on September 1, 2000. This document refines 44 the original recommendation and documents it for the historical 45 record. 47 1. Introduction 49 There have been many discussions between IETF and RIR experts on the 50 topic of IPv6 address allocation policy. This memo addresses the 51 issue of the boundary in between the public and the private topology 52 in the Internet, that is, how much address space should an ISP 53 allocate to homes, small and large enterprises, mobile networks and 54 transient customers. 56 This document does not address the issue of the other boundaries in 57 the public topology, that is, between the RIRs and the LIRs. 59 This document was developed by the IPv6 Directorate, IAB and IESG, 60 and is a recommendation from the IAB and IESG to the RIRs. 62 2. Background 64 The technical principles that apply to address allocation seek to 65 balance healthy conservation practices and wisdom with a certain ease 66 of access. On one hand, when managing a potentially limited 67 resource, one must conserve wisely to prevent exhaustion within an 68 expected lifetime. On the other hand, the IPv6 address space is in 69 no sense as limited a resource as the IPv4 address space, and 70 unwarranted conservatism acts as a disincentive in a marketplace 71 already dampened by other factors. So from a market development 72 perspective, we would like to see it be very easy for a user or an 73 ISP to obtain as many IPv6 addresses as they really need without a 74 prospect of immediate renumbering or of scaling inefficiencies. 76 The IETF makes no comment on business issues or relationships. 77 However, in general, we observe that technical delegation policy can 78 have strong business impacts. A strong requirement of the address 79 delegation plan is that it not be predicated on or unduly bias 80 business relationships or models. 82 The IPv6 address, as currently defined, consists of 64 bits of 83 "network number" and 64 bits of "host number". The technical reasons 84 for this are several. The requirements for IPv6 agreed to in 1993 85 included a plan to be able to address approximately 2^40 networks and 86 2^50 hosts; the 64/64 split effectively accomplishes this. 87 Procedures used in host address assignment, such as the router 88 advertisement of a network's prefix to hosts [RFC2462], which in turn 89 place a locally unique number in the host portion, depend on this 90 split. Subnet numbers must be assumed to come from the network part. 91 This is not to preclude routing protocols such as IS-IS level 1 92 (intra-area) routing, which routes individual host addresses, but 93 says that it may not be depended upon in the world outside that zone. 94 The 64-bit host field can also be used with EUI-64 for a flat, 95 uniquely allocated space, and therefore it may not be globally 96 treated as a subnetting resource. Those concerned with privacy 97 issues linked to the presence of a globally unique identifier may 98 note that 64 bits makes a large enough field to maintain excellent 99 random-number-draw properties for self-configured End System 100 Designators. That alternative construction of this 64-bit host part 101 of an IPv6 address is documented in [PRIVACY]. 103 While the IETF has also gone to a great deal of effort to minimize 104 the impacts of network renumbering, renumbering of IPv6 networks is 105 neither invisible nor completely painless. Therefore, renumbering 106 should be considered an tolerable event, but to be avoided if 107 reasonably feasible. 109 In [RFC2374] and [RFC2450], the IETF's IPNG working group has 110 recommended that the address block given to a single edge network 111 which may be recursively subnetted be a 48-bit prefix. This gives 112 each such network 2^16 subnet numbers to use in routing, and a very 113 large number of unique host numbers within each network. This is 114 deemed to be large enough for most enterprises, and to leave plenty 115 of room for delegation of address blocks to aggregating entities. 117 It is not obvious, however, that all edge networks are likely to be 118 recursively subnetted; a single PC in a home or a telephone in a 119 mobile cellular network, for example, may or may not interface to a 120 subnetted local network. When a network number is delegated to a 121 place that will not require subnetting, therefore, it might be 122 acceptable for an ISP to give a single 64-bit prefix - perhaps shared 123 among the dial-in connections to the same ISP router. However this 124 decision may be taken in the knowledge that there is objectively no 125 shortage of /48s, and the expectation that personal, home networks 126 will become the norm. Indeed, it is widely expected that all IPv6 127 subscribers, whether domestic (homes), mobile (vehicles or 128 individuals), or enterprises of any size, will eventually possess 129 multiple always-on hosts, at least one subnet with the potential for 130 additional subnetting, and therefore some internal routing 131 capability. In other words the subscriber allocation unit is not 132 always a host; it is always potentially a site. The question this 133 memo is addressing is how much address space should be delegated to 134 such sites. 136 3. Address Delegation Recommendations 138 The IESG and the IAB recommend the allocations for the boundary 139 between the public and the private topology to follow those general 140 rules: 142 - /48 in the general case, except for very large subscribers. 143 - /64 when it is known that one and only one subnet is needed by 144 design. 145 - /128 when it is absolutely known that one and only one device is 146 connecting. 148 In particular, we recommend: 150 - Home network subscribers, connecting through on-demand or 151 always-on connections should receive a /48. 152 - Small and large enterprises should receive a /48. 153 - Very large subscribers could receive a /47 or slightly shorter 154 prefix, or multiple /48's. 155 - Mobile networks, such as vehicles or mobile phones with an 156 additional network interface (such as bluetooth or 802.11b) 157 should receive a static /64 prefix to allow the connection of 158 multiple devices through one subnet. 159 - A single PC, with no additional need to subnet, dialing-up from 160 a hotel room may receive its /128 IPv6 address for a PPP style 161 connection as part of a /64 prefix. 163 Note that there seems to be little benefit in not giving a /48 if 164 future growth is anticipated. In the following, we give the 165 arguments for a uniform use of /48 and then demonstrate that it is 166 entirely compatible with responsible stewardship of the total IPv6 167 address space. 169 The arguments for the fixed boundary are: 171 - That only by having a provider-independent boundary can we 172 guarantee that a change of ISP will not require a costly internal 173 restructuring or consolidation of subnets. 175 - That during straightforward site renumbering from one prefix to 176 another the whole process, including parallel running of the two 177 prefixes, would be greatly complicated if the prefixes had 178 different lengths (depending of course on the size and complexity 179 of the site). 181 - There are various possible approaches to multihoming for IPv6 182 sites, including the techniques already used for IPv4 multihoming. 183 The main open issue is finding solutions that scale massively 184 without unduly damaging route aggregation and/or optimal route 185 selection. Much more work remains to be done in this area, but it 186 seems likely that several approaches will be deployed in practice, 187 each with their own advantages and disadvantages. Some (but not 188 all) will work better with a fixed prefix boundary. (Multihoming 189 is discussed in more detail below.) 191 - To allow easy growth of the subscribers' networks without need to 192 go back to ISPs for more space (except for that relatively small 193 number of subscribers for which a /48 is not enough). 195 - To remove the burden from the ISPs and registries of judging 196 sites' needs for address space, unless the site requests more 197 space than a /48. This carries several advantages: 199 - It may become less critical for ISPs to be able to maintain 200 detailed knowledge of their customers' network architecture and 201 growth plans, 202 - ISPs and registries may reduce the effort spent on assessing 203 rates of address consumption, with address space ample for 204 long-term growth plans, 205 - Registry operations may be made more efficient or more focused, 206 by reducing the urgency of tracking and assessment. 207 - Address space will no longer be a precious resource for 208 customers, removing the major incentive for subscribers to 209 install v6/v6 NATs, which would defeat the IPv6 restoration of 210 address transparency. 212 - To allow the site to maintain a single reverse-DNS zone covering 213 all prefixes. 215 - If and only if a site can use the same subnetting structure 216 under each of its prefixes, then it can use the same zone file 217 for the address-to-name mapping of all of them. And, using the 218 conventions of [RFC2874], it can roll the reverse mapping data 219 into the "forward" (name-keyed) zone. 221 Specific advantages of the fixed boundary being at /48 include 223 - To leave open the technical option of retro-fitting the GSE 224 (Global, Site and End-System Designator, a.k.a "8+8") proposal for 225 separating locators and identifiers, which assumes a fixed 226 boundary between global and site addressing at /48. Although the 227 GSE technique was deferred a couple of years ago, it still has 228 strong proponents. Also, the IRTF Namespace Research Group is 229 actively looking into topics closely related to GSE. It is still 230 possible that GSE or a derivative of GSE will be used with IPv6 in 231 the future. 233 - Since the site-local prefix is fec0::/48, global site prefixes of 234 /48 will allow sites to easily maintain a trivial (identity) 235 mapping between the global topology and the site-local topology in 236 the SLA field. 238 - Similarly, if the 6to4 proposal is widely deployed, migration from 239 a 6to4 prefix, which is /48 by construction, to a native IPv6 240 prefix will be simplified if the native prefix is /48. 242 4. Conservation of Address Space 244 The question naturally arises whether giving a /48 to every 245 subscriber represents a profligate waste of address space. Objective 246 analysis shows that this is not the case. A /48 prefix under the 001 247 Global Unicast Address format prefix contains 45 variable bits. That 248 is, the number of available prefixes is 2 to the power 45 or about 35 249 trillion (35,184,372,088,832). 251 More precisely, 253 - [RFC1715] defines an "H ratio" based on experience in address 254 space assignment in various networks. The H ratio varies between 255 0 and 0.3, with larger values denoting denser, more efficient 256 assignment. Experience shows that problems start to occur when 257 the H ratio becomes greater than 0.25. At an H ratio of 0.25, a 258 45 bit address space would have 178 billion (178 thousand million) 259 identifiers. 261 H = log10(178*10^9) / 45 = 0.25 263 This means that we feel comfortable about the prospect of 264 allocating 178 billions /48 prefixes under that scheme before 265 problems start to appear. To understand how big that number is, 266 one has to compare 178 billion to 10 billion, which is the 267 projected population on earth in year 2050 (see 268 http://www.popin.org/pop1998/). These numbers give no grounds for 269 concern provided that the ISPs, under the guidance of the RIRs, 270 allocate /48's prudently, and that the IETF refrains from new 271 recommendations that further reduce the remaining 45 variable 272 bits, unless a compelling requirement emerges. 274 - We are highly confident in the validity of this analysis, based on 275 experience with IPv4 and several other address spaces, and on 276 extremely ambitious scaling goals for the Internet amounting to an 277 80 bit address space *per person*. Even so, being acutely aware 278 of the history of under-estimating demand, the IETF has reserved 279 more than 85% of the address space (i.e., the bulk of the space 280 not under the 001 Global Unicast Address format prefix). 281 Therefore, if the analysis does one day turn out to be wrong, our 282 successors will still have the option of imposing much more 283 restrictive allocation policies on the remaining 85%. However, we 284 must stress that vendors should not encode any of the boundaries 285 discussed here either in software nor hardware. Under that 286 assumption, should we ever have to use the remaining 85% of the 287 address space, such a migration may not be devoid of pain, but it 288 should be far less disruptive than deployment of a new version of 289 IP. 291 To summarize, we argue that although careful stewardship of IPv6 292 address space is essential, this is completely compatible with the 293 convenience and simplicity of a uniform prefix size for IPv6 sites of 294 any size. The numbers are such that there seems to be no objective 295 risk of running out of space, giving an unfair amount of space to 296 early customers, or of getting back into the over-constrained IPv4 297 situation where address conservation and route aggregation damage 298 each other. 300 5. Multihoming Issues 302 In the realm of multi-homed networks, the techniques used in IPv4 can 303 all be applied, but they have known scaling problems. Specifically, 304 if the same prefix is advertised by multiple ISPs, the routing 305 information will grow as a function of the number of multihomed 306 sites. To go beyond this for IPv6, we only have initial proposals on 307 the table at this time, and active work is under way in the IETF IPNG 308 and Multi6 working groups. Until current or new proposals become 309 more fully developed, existing techniques known to work in IPv4 will 310 continue to be used in IPv6. 312 Key characteristics of an ideal multi-homing proposal include (at 313 minimum) that it provides routing connectivity to any multi-homed 314 network globally, conserves address space, produces high quality 315 routes via any of the network's providers, enables a multi-homed 316 network to connect to multiple ISPs, does not unintentionally bias 317 routing to use any proper subset of those networks, does not damage 318 route aggregation, and scales to very large numbers of multi-homed 319 networks. 321 One class of solutions being considered amounts to permanent parallel 322 running of two (or more) prefixes per site. In the absence of a 323 fixed prefix boundary, such a site might be required to have multiple 324 different internal subnet numbering strategies, (one for each prefix 325 length) or, if it only wanted one, be forced to use the most 326 restrictive one as defined by the longest prefix it received from any 327 of its ISPs. In this approach, a multi-homed network would have an 328 address block from each of its upstream providers. Each host would 329 either have exactly one address picked from the set of upstream 330 providers, or one address per host from each of the upstream 331 providers. The first case is essentially a variant on [RFC2260], 332 with known scaling limits. 334 In the second case (multiple addresses per host), if two multi-homed 335 networks communicate, having respectively M and N upstream providers, 336 then the one initiating the connection will select one address pair 337 from the N*M potential address pairs to connect between, and in so 338 doing will select the providers, and therefore the applicable route, 339 for the life of the connection. Given that each path will have a 340 different available bit rate, loss rate, and delay, if neither host 341 is in possession of any routing or metric information, the initiating 342 host has only a 1/(M*N) probability of selecting the optimal address 343 pair. Work on better-than-random address selection is in progress in 344 the IETF, but is incomplete. 346 The existing IPv4 Internet shows us that a network prefix which is 347 independent of, and globally advertised to, all upstream providers 348 permits the routing system to select a reasonably good path within 349 the applicable policy. Present-day routing policies are not QoS 350 policies but reachability policies, which means that they will not 351 necessarily select the optimal delay, bit rate, or loss rate, but the 352 route will be the best within the metrics that are in use. One may 353 therefore conclude that this would work correctly for IPv6 networks 354 as well, apart from scaling issues. 356 6. Security Considerations 358 This document does not have any security implications. 360 7. Acknowledgments 362 The IESG and IAB would like to thank the members of the IPv6 363 directorate for their contribution and acknowledge the editorial role 364 of Alain Durand during the elaboration of this document. 366 8. References 368 RFC1715 The H Ratio for Address Assignment Efficiency. C. Huitema. 369 November 1994. 371 RFC2026 The Internet Standards Process -- Revision 3. S. Bradner. 372 October 1996. 374 RFC2260 Scalable Support for Multi-homed Multi-provider Connectivity. 375 T. Bates, Y. Rekhter. January 1998. 377 RFC2374 An IPv6 Aggregatable Global Unicast Address Format. R. 378 Hinden, M.O'Dell, S. Deering. July 1998. 380 RFC2450 Proposed TLA and NLA Assignment Rule. R. Hinden. December 381 1998. 383 RFC2462 IPv6 Stateless Address Autoconfiguration. S. Thomson, T. 384 Narten. December 1998. 386 RFC2874 DNS Extensions to Support IPv6 Address Aggregation and 387 Renumbering. M. Crawford, C. Huitema. July 2000. 389 PRIVACY Privacy Extensions for Stateless Address Autoconfiguration in 390 IPv6. draft-ietf-ipngwg-addrconf-privacy-04.txt 392 MobIPv6 Mobility Support in IPv6. draft-ietf-mobileip-ipv6-13.txt