idnits 2.17.1 draft-ietf-v6ops-addcon-09.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 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1500. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1511. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1518. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1524. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (August 8, 2008) is 5734 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 3177 (Obsoleted by RFC 6177) -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3484 (Obsoleted by RFC 6724) -- Obsolete informational reference (is this intentional?): RFC 3627 (Obsoleted by RFC 6547) -- Obsolete informational reference (is this intentional?): RFC 3633 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3736 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) -- Obsolete informational reference (is this intentional?): RFC 5157 (Obsoleted by RFC 7707) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 16 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Operations G. Van de Velde 3 Internet-Draft C. Popoviciu 4 Intended status: Informational Cisco Systems 5 Expires: February 9, 2009 T. Chown 6 University of Southampton 7 O. Bonness 8 C. Hahn 9 T-Systems Enterprise Services GmbH 10 August 8, 2008 12 IPv6 Unicast Address Assignment Considerations 13 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on February 9, 2009. 40 Abstract 42 One fundamental aspect of any IP communications infrastructure is its 43 addressing plan. With its new address architecture and allocation 44 policies, the introduction of IPv6 into a network means that network 45 designers and operators need to reconsider their existing approaches 46 to network addressing. Lack of guidelines on handling this aspect of 47 network design could slow down the deployment and integration of 48 IPv6. This document aims to provide the information and 49 recommendations relevant to planning the addressing aspects of IPv6 50 deployments. The document also provides IPv6 addressing case studies 51 for both an enterprise and an ISP network. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2. Network Level Addressing Design Considerations . . . . . . . . 5 57 2.1. Globally Unique Addresses . . . . . . . . . . . . . . . . 5 58 2.2. Unique Local IPv6 Addresses . . . . . . . . . . . . . . . 5 59 2.3. 6Bone Address Space . . . . . . . . . . . . . . . . . . . 7 60 2.4. Network Level Design Considerations . . . . . . . . . . . 7 61 2.4.1. Sizing the Network Allocation . . . . . . . . . . . . 8 62 2.4.2. Address Space Conservation . . . . . . . . . . . . . . 9 63 3. Subnet Prefix Considerations . . . . . . . . . . . . . . . . . 9 64 3.1. Considerations for Subnet Prefixes Shorter then /64 . . . 9 65 3.2. Considerations for /64 Prefixes . . . . . . . . . . . . . 10 66 3.3. Considerations for Subnet Prefixes Longer then /64 . . . . 10 67 3.3.1. Anycast Addresses . . . . . . . . . . . . . . . . . . 11 68 3.3.2. Addresses Used by Embedded-RP (RFC3956) . . . . . . . 12 69 3.3.3. ISATAP Addresses . . . . . . . . . . . . . . . . . . . 13 70 3.3.4. /126 Addresses . . . . . . . . . . . . . . . . . . . . 14 71 3.3.5. /127 Addresses . . . . . . . . . . . . . . . . . . . . 14 72 3.3.6. /128 Addresses . . . . . . . . . . . . . . . . . . . . 14 73 4. Allocation of the IID of an IPv6 Address . . . . . . . . . . . 14 74 4.1. Automatic EUI-64 Format Option . . . . . . . . . . . . . . 14 75 4.2. Using Privacy Extensions . . . . . . . . . . . . . . . . . 15 76 4.3. Manual/Dynamic Assignment Option . . . . . . . . . . . . . 15 77 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 78 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 79 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 80 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 81 8.1. Normative References . . . . . . . . . . . . . . . . . . . 16 82 8.2. Informative References . . . . . . . . . . . . . . . . . . 16 83 Appendix A. Case Studies . . . . . . . . . . . . . . . . . . . . 19 84 A.1. Enterprise Considerations . . . . . . . . . . . . . . . . 19 85 A.1.1. Obtaining General IPv6 Network Prefixes . . . . . . . 19 86 A.1.2. Forming an Address (subnet) Allocation Plan . . . . . 20 87 A.1.3. Other Considerations . . . . . . . . . . . . . . . . . 21 88 A.1.4. Node Configuration Considerations . . . . . . . . . . 21 89 A.2. Service Provider Considerations . . . . . . . . . . . . . 22 90 A.2.1. Investigation of objective Requirements for an 91 IPv6 addressing schema of a Service Provider . . . . 22 92 A.2.2. Exemplary IPv6 Address Allocation Plan for a 93 Service Provider . . . . . . . . . . . . . . . . . . . 26 94 A.2.3. Additional Remarks . . . . . . . . . . . . . . . . . . 30 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 96 Intellectual Property and Copyright Statements . . . . . . . . . . 35 98 1. Introduction 100 The Internet Protocol Version 6 (IPv6) Addressing Architecture 101 [RFC4291] defines three main types of addresses: unicast, anycast and 102 multicast. This document focuses on unicast addresses, for which 103 there are currently two principal allocated types: Globally Unique 104 Addresses [RFC3587] ('globals') and Unique Local IPv6 Addresses 105 [RFC4193] (ULAs). In addition until recently there has been 106 'experimental' 6bone address space [RFC3701], though its use has been 107 deprecated since June 2006 [RFC3701]. 109 The document covers aspects that should be considered during IPv6 110 deployment for the design and planning of an addressing scheme for an 111 IPv6 network. The network's IPv6 addressing plan may be for an IPv6- 112 only network, or for a dual-stack infrastructure where some or all 113 devices have addresses in both protocols. These considerations will 114 help an IPv6 network designer to efficiently and prudently assign the 115 IPv6 address space that has been allocated to their organization. 117 The address assignment considerations are analyzed separately for the 118 two major components of the IPv6 unicast addresses, namely 'Network 119 Level Addressing' (the allocation of subnets) and the 'interface-id' 120 (the identification of the interface within a subnet). Thus the 121 document includes a discussion of aspects of address assignment to 122 nodes and interfaces in an IPv6 network. Finally the document 123 provides two examples of deployed address plans in a service provider 124 (ISP) and an enterprise network. 126 Parts of this document highlight the differences that an experienced 127 IPv4 network designer should consider when planning an IPv6 128 deployment, for example: 130 o IPv6 devices will more likely be multi-addressed in comparison 131 with their IPv4 counterparts 132 o The practically unlimited size of an IPv6 subnet (2^64 bits) 133 reduces the requirement to size subnets to device counts for the 134 purposes of (IPv4) address conservation 135 o The implications of the vastly increased subnet size on the threat 136 of address-based host scanning and other scanning techniques, as 137 discussed in [RFC5157]. 139 We do not discuss here how a site or ISP should proceed with 140 acquiring its globally routable IPv6 address prefix. In each case 141 the prefix received is either provider assigned (PA) or provider 142 independent (PI). 144 We do not discuss PI policy here. The observations and 145 recommendations of this text are largely independent of the PA or PI 146 nature of the address block being used. At this time we assume that 147 most commonly an IPv6 network which changes provider will need to 148 undergo a renumbering process, as described in [RFC4192]. A separate 149 document [THINKABOUT] makes recommendations to ease the IPv6 150 renumbering process. 152 This document does not discuss implementation aspects related to the 153 transition between the ULA addresses and the now obsoleted site-local 154 addresses. Some implementations know about Site-local addresses even 155 though they are deprecated, and do not know about ULAs - even though 156 they represent current specification. As result transitioning 157 between these types of addresses may cause difficulties. 159 2. Network Level Addressing Design Considerations 161 This section discusses the kind of IPv6 addresses used at the network 162 level for the IPv6 infrastructure. The kind of addresses that can be 163 considered are Globally Unique Addresses and ULAs. We also comment 164 here on the deprecated 6bone address space. 166 2.1. Globally Unique Addresses 168 The most commonly used unicast addresses will be Globally Unique 169 Addresses ('globals'). No significant considerations are necessary 170 if the organization has an address space assignment and a single 171 prefix is deployed through a single upstream provider. 173 However, a multihomed site may deploy addresses from two or more 174 Service Provider assigned IPv6 address ranges. Here, the network 175 Administrator must have awareness on where and how these ranges are 176 used on the multihomed infrastructure environment. The nature of the 177 usage of multiple prefixes may depend on the reason for multihoming 178 (e.g. resilience failover, load balancing, policy-based routing, or 179 multihoming during an IPv6 renumbering event). IPv6 introduces 180 improved support for multi-addressed hosts through the IPv6 default 181 address selection methods described in RFC3484 [RFC3484]. A 182 multihomed host may thus have two or more addresses, one per prefix 183 (provider), and select source and destination addresses to use as 184 described in that RFC. However multihoming also has some operational 185 and administrative burdens besides chosing multiple addresses per 186 interface [RFC4219][RFC4218]. 188 2.2. Unique Local IPv6 Addresses 190 ULAs have replaced the originally conceived Site Local addresses in 191 the IPv6 addressing architecture, for reasons described in [RFC3879]. 192 ULAs improve on site locals by offering a high probability of the 193 global uniqueness of the prefix used, which can be beneficial in the 194 case of (deliberate or accidental) leakage, or where networks are 195 merged. ULAs are akin to the private address space [RFC1918] 196 assigned for IPv4 networks, except that in IPv6 networks we may 197 expect to see ULAs used alongside global addresses, with ULAs used 198 internally and globals used externally. Thus use of ULAs does not 199 imply use of NAT for IPv6. 201 The ULA address range allows network administrators to deploy IPv6 202 addresses on their network without asking for a globally unique 203 registered IPv6 address range. A ULA prefix is 48 bits, i.e. a /48, 204 the same as the currently recommended allocation for a site from the 205 globally routable IPv6 address space [RFC3177]. 207 A site willing to use ULA address space can have either (a) multiple 208 /48 prefixes (e.g. a /44) and wishes to use ULAs, or (b) has one /48 209 and wishes to use ULAs or (c) a site has a less-than-/48 prefix (e.g. 210 a /56 or /64) and wishes to use ULAs. In all above cases the ULA 211 addresses can be randomly chosen according the principles specified 212 in [RFC4193]. However, in case (a) the use of randomly chosen ULA 213 addresses will provide suboptimal aggregation capabilities. 215 ULAs provide the means to deploy a fixed addressing scheme that is 216 not affected by a change in service provider and the corresponding PA 217 global addresses. Internal operation of the network is thus 218 unaffected during renumbering events. Nevertheless, this type of 219 address must be used with caution. 221 A site using ULAs may or may not also deploy global addresses. In an 222 isolated network ULAs may be deployed on their own. In a connected 223 network, that also deploys global addresses, both may be deployed, 224 such that hosts become multiaddressed (one global and one ULA 225 address) and the IPv6 default address selection algorithm will pick 226 the appropriate source and destination addresses to use, e.g. ULAs 227 will be selected where both the source and destination hosts have ULA 228 addresses. Because a ULA and a global site prefix are both /48 229 length, an administrator can choose to use the same subnetting (and 230 host addressing) plan for both prefixes. 232 As an example of the problems ULAs may cause, when using IPv6 233 multicast within the network, the IPv6 default address selection 234 algorithm prefers the ULA address as the source address for the IPv6 235 multicast streams. This is NOT a valid option when sending an IPv6 236 multicast stream to the IPv6 Internet for two reasons. For one, 237 these addresses are not globally routable so Reverse Path Forwarding 238 checks for such traffic will fail outside the internal network. The 239 other reason is that the traffic will likely not cross the network 240 boundary due to multicast domain control and perimeter security 241 policies. 243 In principle ULAs allow easier network mergers than RFC1918 addresses 244 do for IPv4 because ULA prefixes have a high probability of 245 uniqueness, if the prefix is chosen as described in the RFC. 247 2.3. 6Bone Address Space 249 The 6Bone address space was used before the Regional Internet 250 Registries (RIRs) started to distribute 'production' IPv6 prefixes. 251 The 6Bone prefixes have a common first 16 bits in the IPv6 Prefix of 252 3FFE::/16. This address range is deprecated as of 6th June 2006 253 [RFC3701] and must not be used on any new IPv6 network deployments. 254 Sites using 6bone address space should renumber to production address 255 space using procedures as defined in [RFC4192]. 257 2.4. Network Level Design Considerations 259 IPv6 provides network administrators with a significantly larger 260 address space, enabling them to be very creative in how they can 261 define logical and practical address plans. The subnetting of 262 assigned prefixes can be done based on various logical schemes that 263 involve factors such as: 264 o Using existing systems 265 * translate the existing subnet number into IPv6 subnet id 266 * translate the VLAN id into IPv6 subnet id 267 o Redesign 268 * allocate according to your need 269 o Aggregation 270 * Geographical Boundaries - by assigning a common prefix to all 271 subnets within a geographical area 272 * Organizational Boundaries - by assigning a common prefix to an 273 entire organization or group within a corporate infrastructure 274 * Service Type - by reserving certain prefixes for predefined 275 services such as: VoIP, Content Distribution, wireless 276 services, Internet Access, Security areas etc. This type of 277 addressing may create dependencies on IP addresses that can 278 make renumbering harder if the nodes or interfaces supporting 279 those services on the network are sparse within the topology. 280 Such logical addressing plans have the potential to simplify network 281 operations and service offerings, and to simplify network management 282 and troubleshooting. A very large network would also have no need to 283 consider using private address space for its infrastructure devices, 284 simplifying network management. 286 The network designer must however keep in mind several factors when 287 developing these new addressing schemes for networks with and without 288 global connectivity: 290 o Prefix Aggregation - The larger IPv6 addresses can lead to larger 291 routing tables unless network designers are actively pursuing 292 aggregation. While prefix aggregation will be enforced by the 293 service provider, it is beneficial for the individual 294 organizations to observe the same principles in their network 295 design process 296 o Network growth - The allocation mechanism for flexible growth of a 297 network prefix, documented in RFC3531 [RFC3531] can be used to 298 allow the network infrastructure to grow and be numbered in a way 299 that is likely to preserve aggregation (the plan leaves 'holes' 300 for growth) 301 o ULA usage in large networks - Networks which have a large number 302 of 'sites' that each deploy a ULA prefix which will by default be 303 a 'random' /48 under fc00::/7 will have no aggregation of those 304 prefixes. Thus the end result may be cumbersome because the 305 network will have large amounts of non-aggregated ULA prefixes. 306 However, there is no rule to disallow large networks to use a 307 single ULA prefix for all 'sites', as a ULA still provides 16 bits 308 for subnetting to be used internally 309 o It is possible that as registry policies evolve, a small site may 310 experience an increase in prefix length when renumbering, e.g. 311 from /48 to /56. For this reason, the best practice is number 312 subnets compactly rather than sparsely, and to use low-order bits 313 as much as possible when numbering subnets. In other words, even 314 if a /48 is allocated, act as though only a /56 is available. 315 Clearly, this advice does not apply to large sites and enterprises 316 that have an intrinsic need for a /48 prefix. 317 o A small site may want to enable routing amongst interfaces 318 connected to a gateway device. For example, a residential gateway 319 which receives a /48, is situated in a home with multiple LANs of 320 different media types (sensor network, wired, wifi, etc.), or has 321 a need for traffic segmentation (home, work, kids, etc.) and could 322 benefit greatly from multiple subnets and routing in IPv6. 323 Ideally, residential networks would be given an address range of a 324 /48 or /56 [reference2] such that multiple /64 subnets could be 325 used within the residence. 327 2.4.1. Sizing the Network Allocation 329 We do not discuss here how a network designer sizes their application 330 for address space. By default a site will receive a /48 prefix 331 [RFC3177] , however different RIR service regions policies may 332 suggest alternative default assignments or let the ISPs to decide on 333 what they believe is more appropriate for their specific case [ARIN]. 334 The default provider allocation via the RIRs is currently a /32 335 [reference2]. These allocations are indicators for a first 336 allocation for a network. Different sizes may be obtained based on 337 the anticipated address usage [reference2]. There are examples of 338 allocations as large as /19 having been made from RIRs to providers 339 at the time of writing. 341 2.4.2. Address Space Conservation 343 Despite the large IPv6 address space which enables easier subnetting, 344 it still is important to ensure an efficient use of this resource. 345 Some addressing schemes, while facilitating aggregation and 346 management, could lead to significant numbers of addresses being 347 unused. Address conservation requirements are less stringent in IPv6 348 but they should still be observed. 350 The proposed Host-Density (HD) [RFC3194] value for IPv6 is 0.94 351 compared to the current value of 0.96 for IPv4. Note that for IPv6 352 HD is calculated for sites (e.g. on a basis of /48), instead of based 353 on addresses like with IPv4. 355 3. Subnet Prefix Considerations 357 This section analyzes the considerations applied to define the subnet 358 prefix of the IPv6 addresses. The boundaries of the subnet prefix 359 allocation are specified in RFC4291 [RFC4291]. In this document we 360 analyze their practical implications. Based on RFC4291 [RFC4291] it 361 is legal for any IPv6 unicast address starting with binary address 362 '000' to have a subnet prefix larger than, smaller than or equal to 363 64 bits. Each of these three options is discussed in this document. 364 This document mainly considers global addresses (assigned from RIR/ 365 LIR) and ULAs and while neither of these address types starts with 366 binary "000" only /64 prefixes are allowed on these types of 367 addresses, however note that a future revision of the address 368 architecture [RFC4291] and a future link-type-specific document, 369 which will still be consistent with each other, could potentially 370 allow for an interface identifier of length other than the value 371 defined in the current documents. 373 3.1. Considerations for Subnet Prefixes Shorter then /64 375 An allocation of a prefix shorter then 64 bits to a node or interface 376 is considered bad practice. One exception to this statement is when 377 using 6to4 technology where a /16 prefix is utilized for the pseudo- 378 interface [RFC3056]. The shortest subnet prefix that could 379 theoretically be assigned to an interface or node is limited by the 380 size of the network prefix allocated to the organization. 382 A possible reason for choosing the subnet prefix for an interface 383 shorter then /64 is that it would allow more nodes to be attached to 384 that interface compared to a prescribed length of 64 bits. This 385 however is unnecessary for most networks considering that 2^64 386 provides plenty of node addresses. 388 The subnet prefix assignments can be made either by manual 389 configuration, by a stateful Host Configuration Protocol [RFC3315], 390 by a stateful prefix delegation mechanism [RFC3633] or implied by 391 stateless autoconfiguration from prefix RAs. 393 3.2. Considerations for /64 Prefixes 395 Based on RFC3177 [RFC3177], 64 bits is the prescribed subnet prefix 396 length to allocate to interfaces and nodes. 398 When using a /64 subnet length, the address assignment for these 399 addresses can be made either by manual configuration, by a stateful 400 Host Configuration Protocol [RFC3315] [RFC3736] or by stateless 401 autoconfiguration [RFC4862]. 403 Note that RFC3177 strongly prescribes 64 bit subnets for general 404 usage, and that stateless autoconfiguration option is only defined 405 for 64 bit subnets. While in theory it might be possible that some 406 future autoconfiguration mechanisms would allow longer than 64 bit 407 prefix lengths to be used, the use of such prefixes is not 408 recommended at this time. 410 3.3. Considerations for Subnet Prefixes Longer then /64 412 Address space conservation is the main motivation for using a subnet 413 prefix length longer than 64 bits, however this kind of address 414 conservation is of little benefit compared with the additional 415 considerations one must make when creating and maintain an IPv6 416 address plan. 418 Using a subnet prefix length of longer then a /64 will break amongst 419 other technologies for example Neighbor Discovery (ND), Secure 420 Neighborship Discovery (SeND) and privacy extensions (RFC4193). As a 421 result, the use of prefix lengths beyond /64 is not recommended for 422 general use. 424 The address assignment can be made either by manual configuration or 425 by a stateful Host Configuration Protocol [RFC3315]. 427 When assigning a subnet prefix of more then 70 bits, according to 428 RFC4291 [RFC4291] 'u' and 'g' bits (respectively the 71st and 72nd 429 bit) need to be taken into consideration and should be set correct. 431 The 'u' (universal/local) bit is the 71st bit of IPv6 address and is 432 used to determine whether the address is universally or locally 433 administered. If 0, the IEEE, through the designation of a unique 434 company ID, has administered the address. If 1, the address is 435 locally administered. The network administrator has overridden the 436 manufactured address and specified a different address. 438 The 'g' (the individual/group) bit is the 72st bit and is used to 439 determine whether the address is an individual address (unicast) or a 440 group address (multicast). If '0', the address is a unicast address. 441 If '1', the address is a multicast address. 443 In current IPv6 protocol stacks, the relevance of the 'u' and 'g' bit 444 is marginal and typically will not show an issue when configured 445 wrongly, however future implementations may turn out differently if 446 they would be processing the 'u' and 'g' bit in IEEE like behavior. 448 When using subnet lengths longer then 64 bits, it is important to 449 avoid selecting addresses that may have a predefined use and could 450 confuse IPv6 protocol stacks. The alternate usage may not be a 451 simple unicast address in all cases. The following points should be 452 considered when selecting a subnet length longer then 64 bits. 454 3.3.1. Anycast Addresses 456 3.3.1.1. Subnet Router Anycast Address 458 RFC4291 [RFC4291] provides a definition for the required Subnet 459 Router Anycast Address as follows: 461 | n bits | 128-n bits | 462 +--------------------------------------------+----------------+ 463 | subnet prefix | 00000000000000 | 464 +--------------------------------------------+----------------+ 466 It is recommended to avoid allocating this IPv6 address to a device 467 which expects to have a normal unicast address. There is no 468 additional dependency for the subnet prefix with the exception of the 469 64-bit extended unique identifier (EUI-64) and an Interface 470 Identifier (IID) dependency. These will be discussed later in this 471 document. 473 3.3.1.2. Reserved IPv6 Subnet Anycast Addresses 475 RFC2526 [RFC2526] stated that within each subnet, the highest 128 476 interface identifier values are reserved for assignment as subnet 477 anycast addresses. 479 The construction of a reserved subnet anycast address depends on the 480 type of IPv6 addresses used within the subnet, as indicated by the 481 format prefix in the addresses. 483 The first type of Subnet Anycast addresses have been defined as 484 follows for EUI-64 format: 486 | 64 bits | 57 bits | 7 bits | 487 +------------------------------+------------------+------------+ 488 | subnet prefix | 1111110111...111 | anycast ID | 489 +------------------------------+------------------+------------+ 491 The anycast address structure implies that it is important to avoid 492 creating a subnet prefix where the bits 65 to 121 are defined as 493 "1111110111...111" (57 bits in total) so that confusion can be 494 avoided. 496 For other IPv6 address types (that is, with format prefixes other 497 than those listed above), the interface identifier is not in 64-bit 498 extended unique identifier (EUI-64) format and may be other than 64 499 bits in length; these reserved subnet anycast addresses for such 500 address types are constructed as follows: 502 | n bits | 121-n bits | 7 bits | 503 +------------------------------+------------------+------------+ 504 | subnet prefix | 1111111...111111 | anycast ID | 505 +------------------------------+------------------+------------+ 506 | interface identifier field | 508 It is recommended to avoid allocating this IPv6 address to a device 509 which expects to have a normal unicast address. There is no 510 additional dependency for the subnet prefix with the exception of the 511 EUI-64 and an Interface Identifier (IID) dependency. These will be 512 discussed later in this document. 514 3.3.2. Addresses Used by Embedded-RP (RFC3956) 516 Embedded-RP [RFC3956] reflects the concept of integrating the 517 Rendezvous Point (RP) IPv6 address into the IPv6 multicast group 518 address. Due to this embedding and the fact that the length of the 519 IPv6 address AND the IPv6 multicast address are 128 bits, it is not 520 possible to have the complete IPv6 address of the multicast RP 521 embedded as such. 523 This resulted in a restriction of 15 possible RP-addresses per prefix 524 that can be used with embedded-RP. The space assigned for the 525 embedded-RP is based on the 4 low order bits, while the remainder of 526 the Interface ID (RIID) is set to all '0'. 528 (IPv6-prefix (64 bits))(60 bits all '0')(RIID) 530 Where: (RIID) = 4 bit. 532 This format implies that when selecting subnet prefixes longer then 533 64, and the bits beyond the 64th one are non-zero, the subnet can not 534 use embedded-RP. 536 In addition it is discouraged to assign a matching embedded-RP IPv6 537 address to a device that is not a real Multicast Rendezvous Point, 538 even though it would not generate major problems. 540 3.3.3. ISATAP Addresses 542 ISATAP [RFC5214] is an experimental automatic tunneling protocol used 543 to provide IPv6 connectivity over an IPv4 campus or enterprise 544 environment. In order to leverage the underlying IPv4 545 infrastructure, the IPv6 addresses are constructed in a special 546 format. 548 An IPv6 ISATAP address has the IPv4 address embedded, based on a 549 predefined structure policy that identifies them as an ISATAP 550 address. 552 [IPv6 Prefix (64 bits)][0000:5EFE][IPv4 address] 554 When using subnet prefix length longer then 64 bits it is good 555 engineering practice that the portion of the IPv6 prefix from bit 65 556 to the end of the host-id does not match with the well-known ISATAP 557 [0000:5EFE] address when assigning an IPv6 address to a non-ISATAP 558 interface. 560 Note that the definition of ISATAP does not support multicast. 562 3.3.4. /126 Addresses 564 126 bit subnet prefixes are typically used for point-to-point links 565 similar to a the IPv4 address conservative /30 allocation for point- 566 to-point links. The usage of this subnet address length does not 567 lead to any additional considerations other than the ones discussed 568 earlier in this section, particularly those related to the "u" and 569 "g" bits. 571 3.3.5. /127 Addresses 573 The usage of the /127 addresses, the equivalent of IPv4's RFC3021 574 [RFC3021] is not valid and should be strongly discouraged as 575 documented in RFC3627 [RFC3627]. 577 3.3.6. /128 Addresses 579 The 128 bit address prefix may be used in those situations where we 580 know that one, and only one address is sufficient. Example usage 581 would be the off-link loopback address of a network device. 583 When choosing a 128 bit prefix, it is recommended to take the "u" and 584 "g" bits into consideration and to make sure that there is no overlap 585 with either the following well-known addresses: 586 o Subnet Router Anycast Address 587 o Reserved Subnet Anycast Address 588 o Addresses used by Embedded-RP 589 o ISATAP Addresses 591 4. Allocation of the IID of an IPv6 Address 593 In order to have a complete IPv6 address, an interface must be 594 associated a prefix and an Interface Identifier (IID). Section 3 of 595 this document analyzed the prefix selection considerations. This 596 section discusses the elements that should be considered when 597 assigning the IID portion of the IPv6 address. 599 There are various ways to allocate an IPv6 address to a device or 600 interface. The option with the least amount of caveats for the 601 network administrator is that of EUI-64 [RFC4862] based addresses. 602 For the manual or dynamic options, the overlap with well known IPv6 603 addresses should be avoided. 605 4.1. Automatic EUI-64 Format Option 607 When using this method the network administrator has to allocate a 608 valid 64 bit subnet prefix. The EUI-64 [RFC4862] allocation 609 procedure can from that moment onward assign the remaining 64 IID 610 bits in a stateless manner. All the considerations for selecting a 611 valid IID have been incorporated in the EUI-64 methodology. 613 4.2. Using Privacy Extensions 615 The main purpose of IIDs generated based on RFC4941 [RFC4941] is to 616 provide privacy to the entity using this address. While there are no 617 particular constraints in the usage of these addresses as defined in 618 [RFC4941] there are some implications to be aware of when using 619 privacy addresses as documented in section 4 of RFC4941 [RFC4941] 621 4.3. Manual/Dynamic Assignment Option 623 This section discusses those IID allocations that are not implemented 624 through stateless address configuration (Section 4.1). They are 625 applicable regardless of the prefix length used on the link. It is 626 out of scope for this section to discuss the various assignment 627 methods (e.g. manual configuration, DHCPv6, etc). 629 In this situation the actual allocation is done by human intervention 630 and consideration needs to be given to the complete IPv6 address so 631 that it does not result in overlaps with any of the well known IPv6 632 addresses: 633 o Subnet Router Anycast Address 634 o Reserved Subnet Anycast Address 635 o Addresses used by Embedded-RP 636 o ISATAP Addresses 638 When using an address assigned by human intervention it is 639 recommended to choose IPv6 addresses which are not obvious to guess 640 and/or avoid any IPv6 addresses that embed IPv4 addresses used in the 641 current infrastructure. Following these two recommendations will 642 make it more difficult for malicious third parties to guess targets 643 for attack, and thus reduce security threats to a certain extent. 645 5. IANA Considerations 647 There are no extra IANA consideration for this document. 649 6. Security Considerations 651 This document doesn't add any new security considerations that aren't 652 already outlined in the security considerations of the references. 654 It must be noted that using subnet prefixes other than /64 breaks 655 security mechanisms such as Cryptographically Generated Addresses 656 (CGAs) and Hash Based Addresses (HBAs), and thus makes it impossible 657 to use protocols that depend on them. 659 7. Acknowledgements 661 Constructive feedback and contributions have been received during 662 IESG review cycle and from Marla Azinger, Stig Venaas, Pekka Savola, 663 John Spence, Patrick Grossetete, Carlos Garcia Braschi, Brian 664 Carpenter, Mark Smith, Janos Mohacsi, Jim Bound, Fred Templin, Ginny 665 Listman, Salman Assadullah and Krishnan Thirukonda. 667 8. References 669 8.1. Normative References 671 8.2. Informative References 673 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 674 E. Lear, "Address Allocation for Private Internets", 675 BCP 5, RFC 1918, February 1996. 677 [RFC2526] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast 678 Addresses", RFC 2526, March 1999. 680 [RFC3021] Retana, A., White, R., Fuller, V., and D. McPherson, 681 "Using 31-Bit Prefixes on IPv4 Point-to-Point Links", 682 RFC 3021, December 2000. 684 [RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 685 Tunnel Broker", RFC 3053, January 2001. 687 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 688 via IPv4 Clouds", RFC 3056, February 2001. 690 [RFC3177] IAB and IESG, "IAB/IESG Recommendations on IPv6 Address 691 Allocations to Sites", RFC 3177, September 2001. 693 [RFC3180] Meyer, D. and P. Lothberg, "GLOP Addressing in 233/8", 694 BCP 53, RFC 3180, September 2001. 696 [RFC3194] Durand, A. and C. Huitema, "The H-Density Ratio for 697 Address Assignment Efficiency An Update on the H ratio", 698 RFC 3194, November 2001. 700 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 701 and M. Carney, "Dynamic Host Configuration Protocol for 702 IPv6 (DHCPv6)", RFC 3315, July 2003. 704 [RFC3484] Draves, R., "Default Address Selection for Internet 705 Protocol version 6 (IPv6)", RFC 3484, February 2003. 707 [RFC3531] Blanchet, M., "A Flexible Method for Managing the 708 Assignment of Bits of an IPv6 Address Block", RFC 3531, 709 April 2003. 711 [RFC3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global 712 Unicast Address Format", RFC 3587, August 2003. 714 [RFC3627] Savola, P., "Use of /127 Prefix Length Between Routers 715 Considered Harmful", RFC 3627, September 2003. 717 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 718 Host Configuration Protocol (DHCP) version 6", RFC 3633, 719 December 2003. 721 [RFC3701] Fink, R. and R. Hinden, "6bone (IPv6 Testing Address 722 Allocation) Phaseout", RFC 3701, March 2004. 724 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 725 (DHCP) Service for IPv6", RFC 3736, April 2004. 727 [RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local 728 Addresses", RFC 3879, September 2004. 730 [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous 731 Point (RP) Address in an IPv6 Multicast Address", 732 RFC 3956, November 2004. 734 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 735 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 736 September 2005. 738 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 739 Addresses", RFC 4193, October 2005. 741 [RFC4218] Nordmark, E. and T. Li, "Threats Relating to IPv6 742 Multihoming Solutions", RFC 4218, October 2005. 744 [RFC4219] Lear, E., "Things Multihoming in IPv6 (MULTI6) Developers 745 Should Think About", RFC 4219, October 2005. 747 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 748 Protocol 4 (BGP-4)", RFC 4271, January 2006. 750 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 751 Architecture", RFC 4291, February 2006. 753 [RFC4477] Chown, T., Venaas, S., and C. Strauf, "Dynamic Host 754 Configuration Protocol (DHCP): IPv4 and IPv6 Dual-Stack 755 Issues", RFC 4477, May 2006. 757 [RFC4798] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur, 758 "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 759 Provider Edge Routers (6PE)", RFC 4798, February 2007. 761 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 762 Address Autoconfiguration", RFC 4862, September 2007. 764 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 765 Extensions for Stateless Address Autoconfiguration in 766 IPv6", RFC 4941, September 2007. 768 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 769 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 770 March 2008. 772 [RFC5157] Chown, T., "IPv6 Implications for Network Scanning", 773 RFC 5157, March 2008. 775 [ARIN] ARIN, "http://www.arin.net/policy/nrpm.html#six54". 777 [reference2] 778 APNIC, ARIN, RIPE NCC, "www.ripe.net/ripe/docs/ 779 ipv6policy.html", July 2007. 781 [reference3] 782 APNIC, ARIN, RIPE NCC, 783 "http://www.ripe.net/ripe/docs/ripe-412.html", July 2007. 785 [reference4] 786 ARIN, "http://www.arin.net/policy/nrpm.html#ipv6", 787 March 2008. 789 [reference5] 790 APNIC, 791 "http://www.apnic.net/policy/ipv6-address-policy.html", 792 March 2007. 794 [reference6] 795 LACNIC, "http://lacnic.net/en/politicas/ipv6.html". 797 [reference7] 798 AFRINIC, "http://www.afrinic.net/docs/policies/ 799 afpol-v6200407-000.htm", March 2004. 801 [THINKABOUT] 802 Chown, T., Thompson, M., Ford, A., and S. Venaas, "Things 803 to think about when Renumbering an IPv6 network 804 (draft-chown-v6ops-renumber-thinkabout-05.txt)", 805 March 2007. 807 Appendix A. Case Studies 809 This appendix contains two case studies for IPv6 addressing schemas 810 that have been based on the statements and considerations of this 811 draft. These case studies illustrate how this draft has been used in 812 two specific network scenarios. The case studies may serve as basic 813 considerations for an administrator who designs the IPv6 addressing 814 schema for an enterprise or ISP network, but are not intended to 815 serve as general design proposal for every kind of IPv6 network. All 816 subnet sizes used in this appendix are for practical visualization 817 and do not dictate RIR policy. 819 A.1. Enterprise Considerations 821 In this section one considers a case study of a campus network that 822 is deploying IPv6 in parallel with existing IPv4 protocols in a dual- 823 stack environment. The specific example is the University of 824 Southampton (UK), focusing on a large department within that network. 825 The deployment currently spans around 1,000 hosts and over 1,500 826 users. 828 A.1.1. Obtaining General IPv6 Network Prefixes 830 In the case of a campus network, the site will typically take its 831 connectivity from its National Research and Education Network (NREN). 832 Southampton connects to JANET, the UK academic network, via its local 833 regional network LeNSE. JANET currently has a /32 allocation from 834 RIPE NCC. The current recommended practice is for sites to receive a 835 /48 allocation, and on this basis Southampton has received such a 836 prefix for its own use. The regional network also uses its own 837 allocation from the NREN provider. 839 No ULA addressing is used on site. The campus is not multihomed 840 (JANET is the sole provider), nor does it expect to change service 841 provider, and thus does not plan to use ULAs for the (perceived) 842 benefit of easing network renumbering. Indeed, the campus has 843 renumbered following the aforementioned renumbering procedure 844 [RFC4192] on two occasions, and this has proven adequate (with 845 provisos documented in [THINKABOUT]. The campus do not see any need 846 to deploy ULAs for in or out of band network management; there are 847 enough IPv6 prefixes available in the site allocation for the 848 infrastructure. In some cases, use of private IP address space in 849 IPv4 creates problems, so University of Southampton believe that the 850 availability of ample global IPv6 address space for infrastructure 851 may be a benefit for many sites. 853 No 6bone addressing is used on site any more. Since the 6bone 854 phaseout of June 2006 [RFC3701] most transit ISPs have begun 855 filtering attempted use of such prefixes. 857 Southampton does participate in global and organization scope IPv6 858 multicast networks. Multicast address allocations are not discussed 859 here as they are not in scope for the document. It is noted that 860 IPv6 has advantages for multicast group address allocation. In IPv4 861 a site needs to use techniques like GLOP [RFC3180] to pick a globally 862 unique multicast group to use. This is problematic if the site does 863 not use Border Gateway Protocol (BGP) [RFC4271] and have an 864 Autonomous System Number (ASN). In IPv6 unicast-prefix-based IPv6 865 multicast addresses empower a site to pick a globally unique group 866 address based on its unicast own site or link prefix. Embedded RP is 867 also in use, is seen as a potential advantage for IPv6 and multicast, 868 and has been tested successfully across providers between sites 869 (including paths to/from the US and UK). 871 A.1.2. Forming an Address (subnet) Allocation Plan 873 The campus has a /16 prefix for IPv4 use; in principle 256 subnets of 874 256 addresses. In reality the subnetting is muddier, because of 875 concerns of IPv4 address conservation; subnets are sized to the hosts 876 within them, e.g. a /26 IPv4 prefix is used if a subnet has 35 hosts 877 in it. While this is efficient, it increases management burden when 878 physical deployments change, and IPv4 subnets require resizing (up or 879 down), even with DHCP in use. 881 The /48 IPv6 prefix is considerably larger than the IPv4 allocation 882 already in place at the site. It is loosely equivalent to a 'Class 883 A' IPv4 prefix in that it has 2^16 (over 65,000) subnets, but has an 884 effectively unlimited subnet address size (2^64) compared to 256 in 885 the IPv4 equivalent. The increased subnet size means that /64 IPv6 886 prefixes can be used on all subnets, without any requirement to 887 resize them at a later date. The increased subnet volume allows 888 subnets to be allocated more generously to schools and departments in 889 the campus. While address conservation is still important, it is no 890 longer an impediment on network management. Rather, address (subnet) 891 allocation is more about embracing the available address space and 892 planning for future expansion. 894 In a dual-stack network, it was chosen to deploy our IP subnets 895 congruently for IPv4 and IPv6. This is because the systems are still 896 in the same administrative domains and the same geography. It is not 897 expected to have IPv6-only subnets in production use for a while yet, 898 outside the test beds and some early Mobile IPv6 trials. With 899 congruent addressing, our firewall policies are also aligned for IPv4 900 and IPv6 traffic at the site border. 902 The subnet allocation plan required a division of the address space 903 per school or department. Here a /56 was allocated to the school 904 level of the university; there are around 30 schools currently. A 905 /56 of IPv6 address space equates to 256 /64 size subnet allocations. 906 Further /56 allocations were made for central IT infrastructure, for 907 the network infrastructure and the server side systems. 909 A.1.3. Other Considerations 911 The network uses a Demilitarized Zone (DMZ) topology for some level 912 of protection of 'public' systems. Again, this topology is congruent 913 with the IPv4 network. 915 There are no specific transition methods deployed internally to the 916 campus; everything is using the conventional dual-stack approach. 917 There is no use of ISATAP [RFC5214] for example. 919 For the Mobile IPv6 early trials there is one allocated prefix for 920 Home Agent (HA) use. However there has been no detailed 921 consideration yet how Mobile IPv6 usage may grow, and whether more or 922 even every subnet will require HA support. 924 The university operates a tunnel broker [RFC3053] service on behalf 925 of UKERNA for JANET sites. This uses separate address space from 926 JANET, not our university site allocation. 928 A.1.4. Node Configuration Considerations 930 Currently stateless autoconfiguration is used on most subnets for 931 IPv6 hosts. There is no DHCPv6 service deployed yet, beyond tests of 932 early code releases. It is planned to deploy DHCPv6 for address 933 assignment when robust client and server code is available (at the 934 time of writing the potential for this looks good, e.g. via the ISC 935 implementation). University of Southampton is also investigating a 936 common integrated DHCP/DNS management platform, even if the servers 937 themselves are not co-located, including integrated DHCPv4 and DHCPv6 938 server configuration, as discussed in [RFC4477]. Currently clients 939 with statelessly autoconfigured addresses are added to the DNS 940 manually, though dynamic DNS is an option. The network 941 administrators would prefer the use of DHCP because they believe it 942 gives them more management control. 944 Regarding the implications of the larger IPv6 subnet address space on 945 scanning attacks [RFC5157], it is noted that all the hosts are dual- 946 stack, and thus are potentially exposed over both protocols anyway. 947 All addresses or published in DNS, and hence do not operate a two 948 faced DNS. 950 There is internal usage of RFC4941 privacy addresses [RFC4941] 951 currently (certain platforms currently ship with it on by default), 952 but may desire to administratively disable this (perhaps via DHCP) to 953 ease management complexity. However, it is desired to determine the 954 feasibility of this on all systems, e.g. for guests on wireless LAN 955 or other user-maintained systems. Network management and monitoring 956 should be simpler without RFC4941 in operation, in terms of 957 identifying which physical hosts are using which addresses. Note 958 that RFC4941 is only an issue for outbound connections, and that 959 there is potential to assign privacy addresses via DHCPv6. 961 Manually configured server addresses are used to avoid address 962 changes based upon change of network adaptor. With IPv6 you can 963 choose to pick ::53 for a DNS server, or can pick 'random' addresses 964 for obfuscation, though that's not an issue for publicly advertised 965 addresses (dns, mx, web, etc). 967 A.2. Service Provider Considerations 969 In this section an IPv6 addressing schema is sketched that could 970 serve as an example for an Internet Service Provider. 972 Sub-section A.2.1 starts with some thoughts regarding objective 973 requirements of such an addressing schema and derives a few general 974 rules of thumb that have to be kept in mind when designing an ISP 975 IPv6 addressing plan. 977 Sub-section A.2.2 illustrates these findings of A.2.1 with an 978 exemplary IPv6 addressing schema for an MPLS-based ISP offering 979 Internet Services as well as Network Access services to several 980 millions of customers. 982 A.2.1. Investigation of objective Requirements for an IPv6 addressing 983 schema of a Service Provider 985 The first step of the IPv6 addressing plan design for a Service 986 provider should identify all technical, operational, political and 987 business requirements that have to be satisfied by the services 988 supported by this addressing schema. 990 According to the different technical constraints and business models 991 as well as the different weights of these requirements (from the 992 point of view of the corresponding Service Provider) it is very 993 likely that different addressing schemas will be developed and 994 deployed by different ISPs. Nevertheless the addressing schema of 995 sub-section A.2.2 is one possible example. 997 For this document it is assumed that our exemplary ISP has to fulfill 998 several roles for its customers as there are: 1000 o Local Internet Registry 1001 o Network Access Provider 1002 o Internet Service Provider 1004 A.2.1.1. Recommendations for an IPv6 Addressing Schema from the LIR 1005 Perspective of the Service Provider 1007 In their role as Local Internet Registry (LIR) the Service Providers 1008 have to care about the policy constraints of the RIRs and the 1009 standards of the IETF regarding IPv6 addressing. In this context, 1010 the following basic recommendations have to be considered and should 1011 be satisfied by the IPv6 address allocation plan of a Service 1012 Provider: 1013 o As recommended in RFC 3177 [RFC3177] and in several RIR policies 1014 "Common" customers sites (normally private customers) should 1015 receive a /48 prefix from the aggregate of the Service Provider. 1016 (Note: The addressing plan must be flexible enough and take into 1017 account the possible change of the minimum allocation size for end 1018 users currently under definition by the RIRs.) 1019 o "Big customers" (like big enterprises, governmental agencies etc.) 1020 may receive shorter prefixes according to their needs when this 1021 need could be documented and justified to the RIR. 1022 o The IPv6 address allocation schema has to be able to meet the HD- 1023 ratio that is proposed for IPv6. This requirement corresponds to 1024 the demand for an efficient usage of the IPv6 address aggregate by 1025 the Service Provider. (Note: The currently valid IPv6 HD-ratio of 1026 0.94 means an effective usage of about 31% of a /20 prefix of the 1027 Service Provider on the basis of /48 assignments.) 1028 o All assignments to customers have to be documented and stored into 1029 a database that can also be queried by the RIR. 1030 o The LIR has to make available means for supporting the reverse DNS 1031 mapping of the customer prefixes. 1032 o IPv6 Address Allocation and Assignment Policies can be found at 1033 RIRs and are similar in many aspects: 1034 [reference2][reference3][reference4] [reference5][reference6] 1036 A.2.1.2. IPv6 Addressing Schema Recommendations from the ISP 1037 Perspective of the Service Provider 1039 From ISP perspective the following basic requirements could be 1040 identified: 1041 o The IPv6 address allocation schema must be able to realize a 1042 maximal aggregation of all IPv6 address delegations to customers 1043 into the address aggregate of the Service Provider. Only this 1044 provider aggregate will be routed and injected into the global 1045 routing table (DFZ). This strong aggregation keeps the routing 1046 tables of the DFZ small and eases filtering and access control 1047 very much. 1048 o The IPv6 addressing schema of the SP should contain optimal 1049 flexibility since the infrastructure of the SP will change over 1050 the time with new customers, transport technologies and business 1051 cases. The requirement of optimal flexibility is contrary to the 1052 recommendation of strong IPv6 address aggregation and efficient 1053 address usage, but at this point each SP has to decide which of 1054 these requirements to prioritize. 1055 o Keeping the multilevel network hierarchy of an ISP in mind, due to 1056 addressing efficiency reasons not all hierarchy levels can and 1057 should be mapped into the IPv6 addressing schema of an ISP. 1058 Sometimes it is much better to implement a more "flat" addressing 1059 for the ISP network than to loose big chunks of the IPv6 address 1060 aggregate in addressing each level of network hierarchy. (Note: 1061 In special cases it is even recommendable for really "small" ISPs 1062 to design and implement a totally flat IPv6 addressing schema 1063 without any level of hierarchy.) 1064 o Besides that a decoupling of provider network addressing and 1065 customer addressing is recommended. (Note: A strong aggregation 1066 e.g. on POP, aggregation router or Label Edge Router (LER) level 1067 limits the numbers of customer routes that are visible within the 1068 ISP network but brings also down the efficiency of the IPv6 1069 addressing schema. That's why each ISP has to decide how many 1070 internal aggregation levels it wants to deploy.) 1072 A.2.1.3. IPv6 Addressing Schema Recommendations from the Network Access 1073 provider Perspective of the Service Provider 1075 As already done for the LIR and the ISP roles of the SP it is also 1076 necessary to identify requirements that come from its Network Access 1077 Provider role. Some of the basic requirements are: 1078 o The IPv6 addressing schema of the SP must be chosen in a way that 1079 it can handle new requirements that are triggered from customer 1080 side. This can be for instance the growing needs of the customers 1081 regarding IPv6 addresses as well as customer driven modifications 1082 within the access network topology (e.g. when the customer moves 1083 from one point of network attachment (POP) to another). (See 1084 section A.2.3.4 "Changing Point of Network Attachment".) 1085 o For each IPv6 address assignment to customers a "buffer zone" 1086 should be reserved that allows the customer to grow in its 1087 addressing range without renumbering or assignment of additional 1088 prefixes. 1089 o The IPv6 addressing schema of the SP must deal with multiple- 1090 attachments of a single customer to the SP network infrastructure 1091 (i.e. multi-homed network access with the same SP). 1093 These few requirements are only part of all the requirements a 1094 Service Provider has to investigate and keep in mind during the 1095 definition phase of its addressing architecture. Each SP will most 1096 likely add more constraints to this list. 1098 A.2.1.4. A Few Rules of Thumb for Designing an IPv6 ISP Addressing 1099 Architecture 1101 As outcome of the above enumeration of requirements regarding an ISP 1102 IPv6 addressing plan the following design "rules of thumb" have been 1103 derived: 1104 o No "One size fits all". Each ISP must develop its own IPv6 1105 address allocation schema depending on its concrete business 1106 needs. It is not practicable to design one addressing plan that 1107 fits for all kinds of ISPs (Small / big, Routed / MPLS-based, 1108 access / transit, LIR / No-LIR, etc.). 1109 o The levels of IPv6 address aggregation within the ISP addressing 1110 schema should strongly correspond to the implemented network 1111 structure and their number should be minimized because of 1112 efficiency reasons. It is assumed that the SPs own infrastructure 1113 will be addressed in a fairly flat way whereas the part of the 1114 customer addressing architecture should contain several levels of 1115 aggregation. 1116 o Keep the number of IPv6 customer routes inside your network as 1117 small as necessary. A totally flat customer IPv6 addressing 1118 architecture without any intermediate aggregation level will lead 1119 to lots of customer routes inside the SP network. A fair trade- 1120 off between address aggregation levels (and hence the size of the 1121 internal routing table of the SP) and address conservation of the 1122 addressing architecture has to be found. 1123 o The ISP IPv6 addressing schema should provide maximal flexibility. 1124 This has to be realized for supporting different sizes of customer 1125 IPv6 address aggregates ("big" customers vs. "small" customers) as 1126 well as to allow future growing rates (e.g. of customer 1127 aggregates) and possible topological or infrastructural changes. 1128 o A limited number of aggregation levels and sizes of customer 1129 aggregates will ease the management of the addressing schema. 1130 This has to be weighed against the previous "thumb rule" - 1131 flexibility. 1133 A.2.2. Exemplary IPv6 Address Allocation Plan for a Service Provider 1135 In this example, the Service Provider is assumed to operate an MPLS 1136 based backbone and implements 6PE [RFC4798] to provide IPv6 backbone 1137 transport between the different locations (POPs) of a fully dual- 1138 stacked network access and aggregation area. 1140 Besides that it is assumed that the Service Provider: 1141 o has received a /20 from its RIR 1142 o operates its own LIR 1143 o has to address its own IPv6 infrastructure 1144 o delegates prefixes from this aggregate to its customers 1146 This addressing schema should illustrate how the /20 IPv6 prefix of 1147 the SP can be used to address the SP-own infrastructure and to 1148 delegate IPv6 prefixes to its customers following the above mentioned 1149 requirements and rules of thumb as far as possible. 1151 The below figure summarizes the device types in a SP network and the 1152 typical network design of a MPLS-based service provider. The network 1153 hierarchy of the SP has to be taken into account for the design of an 1154 IPv6 addressing schema and defines its basic shape and the various 1155 levels of aggregation. 1157 +------------------------------------------------------------------+ 1158 | LSRs of the MPLS Backbone of the SP | 1159 +------------------------------------------------------------------+ 1160 | | | | | 1161 | | | | | 1162 +-----+ +-----+ +--------+ +--------+ +--------+ 1163 | LER | | LER | | LER-BB | | LER-BB | | LER-BB | 1164 +-----+ +-----+ +--------+ +--------+ +--------+ 1165 | | | | | | / | | | 1166 | | | | | | / | | | 1167 | | | | +------+ +------+ +------+ | | 1168 | | | | |BB-RAR| |BB-RAR| | AG | | | 1169 | | | | +------+ +------+ +------+ | | 1170 | | | | | | | | | | | | 1171 | | | | | | | | | | | | 1172 | | | | | | | | +-----+ +-----+ +-----+ +-----+ 1173 | | | | | | | | | RAR | | RAR | | RAR | | RAR | 1174 | | | | | | | | +-----+ +-----+ +-----+ +-----+ 1175 | | | | | | | | | | | | | | | | 1176 | | | | | | | | | | | | | | | | 1177 +-------------------------------------------------------------------+ 1178 | Customer networks | 1179 +-------------------------------------------------------------------+ 1180 Figure: Exemplary Service Provider Network 1182 LSR ... Label Switch Router 1183 LER ... Label Edge Router 1184 LER-BB ... Broadband Label Edge Router 1185 RAR ... Remote Access Router 1186 BB-RAR ... Broadband Remote Access Router 1187 AG ... Aggregation Router 1189 Basic design decisions for the exemplary Service Provider IPv6 1190 address plan regarding customer prefixes take into consideration: 1191 o The prefixes assigned to all customers behind the same LER (e.g. 1192 LER or LER-BB) are aggregated under one LER prefix. This ensures 1193 that the number of labels that have to be used for 6PE is limited 1194 and hence provides a strong MPLS label conservation. 1195 o The /20 prefix of the SP is separated into 3 different pools that 1196 are used to allocate IPv6 prefixes to the customers of the SP: 1197 * A pool (e.g. /24) for satisfying the addressing needs of really 1198 "big" customers (as defined in A.2.2.1 sub-section A.) that 1199 need IPv6 prefixes larger than /48 (e.g. /32). These customers 1200 are assumed to be connected to several POPs of the access 1201 network, so that this customer prefix will be visible in each 1202 of these POPs. 1204 * A pool (e.g. /24) for the LERs with direct customer connections 1205 (e.g. dedicated line access) and without an additional 1206 aggregation area between the customer and the LER. (These LERs 1207 are mostly connected to a limited number of customers because 1208 of the limited number of interfaces/ports.) 1209 * A larger pool (e.g. 14*/24) for LERs (e.g. LER-BB) that serve 1210 a high number of customers that are normally connected via some 1211 kind of aggregation network (e.g. DSL customers behind a BB- 1212 RAR or Dial-In customers behind a RAR). 1213 * The IPv6 address delegation within each Pool (end customer 1214 delegation or also the aggregates that are dedicated to the 1215 LERs itself) should be chosen with an additional buffer zone of 1216 100% - 300% for future growth. I.e. 1 or 2 additional prefix 1217 bits should be reserved according to the expected future growth 1218 rate of the corresponding customer / the corresponding network 1219 device aggregate. 1221 A.2.2.1. Defining an IPv6 Address Allocation Plan for Customers of the 1222 Service Provider 1224 A.2.2.1.1. 'Big' Customers 1226 SP's "big" customers receive their prefix from the /24 IPv6 address 1227 aggregate that has been reserved for their "big" customers. A 1228 customer is considered as "big" customer if it has a very complex 1229 network infrastructure and/or huge IPv6 address needs (e.g. because 1230 of very large customer numbers) and/or several uplinks to different 1231 POPs of the SP network. 1233 The assigned IPv6 address prefixes can have a prefix length in the 1234 range 32-48 and for each assignment a 100 or 300% future growing zone 1235 is marked as "reserved" for this customer. This means for instance 1236 that with a delegation of a /34 to a customer the corresponding /32 1237 prefix (which contains this /34) is reserved for the customers future 1238 usage. 1240 The prefixes for the "big" customers can be chosen from the 1241 corresponding "big customer" pool by either using an equidistant 1242 algorithm or using mechanisms similar to the Sparse Allocation 1243 Algorithm (SAA) [reference2]. 1245 A.2.2.1.2. 'Common' Customers 1247 All customers that are not "big" customers are considered as "common" 1248 customers. They represent the majority of customers hence they 1249 receive a /48 out of the IPv6 customer address pool of the LER where 1250 they are directly connected or aggregated. 1252 Again a 100 - 300% future growing IPv6 address range is reserved for 1253 each customer, so that a "common" customer receives a /48 allocation 1254 but has a /47 or /46 reserved. 1256 (Note: If it is obvious that the likelyhood of needing a /47 or /46 1257 in the future is very small for a "common" customer, than no growing 1258 buffer should be reserved for it and only a /48 will be assigned 1259 without any growing buffer.) 1261 In the network access scenarios where the customer is directly 1262 connected to the LER the customer prefix is directly taken out of the 1263 customer IPv6 address aggregate (e.g. /38) of the corresponding LER. 1265 In all other cases (e.g. the customer is attached to a RAR that is 1266 themselves aggregated to an AG or to a LER-BB) at least 2 different 1267 approaches are possible. 1269 1) Mapping of Aggregation Network Hierarchy into Customer IPv6 1270 Addressing Schema. The aggregation network hierarchy could be mapped 1271 into the design of the customer prefix pools of each network level in 1272 order to achieve a maximal aggregation at the LER level as well as at 1273 the intermediate levels. (Example: Customer - /48, RAR - /38, AG - 1274 /32, LER-BB - /30). At each network level an adequate growing zone 1275 should be reserved. (Note: This approach requires of course some 1276 "fine tuning" of the addressing schema based on a very good knowledge 1277 of the Service Provider network topology including actual growing 1278 ranges and rates.) 1280 When the IPv6 customer address pool of a LER (or another device of 1281 the aggregation network - AG or RAR) is exhausted, the related LER 1282 (or AG or RAR) prefix is shortened by 1 or 2 bits (e.g. from /38 to 1283 /37 or /36) so that the originally reserved growing zone can be used 1284 for further IPv6 address allocations to customers. In the case where 1285 this growing zone is exhausted as well a new prefix range from the 1286 corresponding pool of the next higher hierarchy level can be 1287 requested. 1289 2) "Flat" Customer IPv6 Addressing Schema. The other option is to 1290 allocate all the customer prefixes directly out of the customer IPv6 1291 address pool of the LER where the customers are attached and 1292 aggregated and to ignore the intermediate aggregation network 1293 infrastructure. This approach leads of course to a higher amount of 1294 customer routes at LER and aggregation network level but takes a 1295 great amount of complexity out of the addressing schema. 1296 Nevertheless the aggregation of the customer prefixes to one prefix 1297 at LER level is realized as required above. 1299 (Note: The handling of (e.g. technically triggered) changes within 1300 the ISP access network is shortly discussed in section A.2.3.5.) 1302 If the actual observed growing rates show that the reserved growing 1303 zones are not needed than these growing areas can be freed and used 1304 for assignments for prefix pools to other devices at the same level 1305 of the network hierarchy. 1307 A.2.2.2. Defining an IPv6 Address Allocation Plan for the Service 1308 Provider Network Infrastructure 1310 For the IPv6 addressing of SPs own network infrastructure a /32 (or 1311 /40) from the "big" customers address pool can be chosen. 1313 This SP infrastructure prefix is used to code the network 1314 infrastructure of the SP by assigning a /48 to every POP/location and 1315 using for instance a /56 for coding the corresponding router within 1316 this POP. Each SP internal link behind a router interface could be 1317 coded using a /64 prefix. (Note: While it is suggested to choose a 1318 /48 for addressing the POP/location of the SP network it is left to 1319 each SP to decide what prefix length to assign to the routers and 1320 links within this POP.) 1322 The IIDs of the router interfaces may be generated by using EUI-64 or 1323 through plain manual configuration e.g. for coding additional network 1324 or operational information into the IID. 1326 It is assumed that again 100 - 300% growing zones for each level of 1327 network hierarchy and additional prefix bits may be assigned to POPs 1328 and/or routers if needed. 1330 Loopback interfaces of routers may be chosen from the first /64 of 1331 the /56 router prefix (in the example above). 1333 (Note: The /32 (or /40) prefix that has been chosen for addressing 1334 SPs own IPv6 network infrastructure gives enough place to code 1335 additional functionalities like security levels or private and test 1336 infrastructure although such approaches haven't been considered in 1337 more detail for the above described SP until now.) 1339 Point-to-point links to customers (e.g. PPP links, dedicated line 1340 etc.) may be addressed using /126 prefixes out of the first /64 of 1341 the access routers that could be reserved for this reason. 1343 A.2.3. Additional Remarks 1344 A.2.3.1. ULA 1346 From the actual view point of SP there is no compelling reason why 1347 ULAs should be used from a SP. Look at section 2.2. 1349 ULAs could be used inside the SP network in order to have an 1350 additional "site-local scoped" IPv6 address for SPs own 1351 infrastructure for instance for network management reasons and maybe 1352 also in order to have an addressing schema that couldn't be reached 1353 from outside the SP network. 1355 In the case when ULAs are used it is possible to map the proposed 1356 internal IPv6 addressing of SPs own network infrastructure as 1357 described in A.2.2.2 above directly to the ULA addressing schema by 1358 substituting the /48 POP prefix with a /48 ULA site prefix. 1360 A.2.3.2. Multicast 1362 IPv6 Multicast-related addressing issues are out of the scope of this 1363 document. 1365 A.2.3.3. POP Multi-homing 1367 POP (or better LER) Multi-homing of customers with the same SP can be 1368 realized within the proposed IPv6 addressing schema of the SP by 1369 assigning multiple LER-dependent prefixes to this customer (i.e. 1370 considering each customer location as a single-standing customer) or 1371 by choosing a customer prefix out of the pool of "big" customers. 1372 The second solution has the disadvantage that in every LER where the 1373 customer is attached this prefix will appear inside the IGP routing 1374 table requiring an explicit MPLS label. 1376 (Note: The described negative POP/LER Multi-homing effects to the 1377 addressing architecture in the SP access network are not tackled by 1378 implementing the Shim6 Site Multi-homing approach since this approach 1379 targets only on a mechanism for dealing with multiple prefixes in end 1380 systems -- the SP will nevertheless have unaggregated customer 1381 prefixes in its internal routing tables.) 1383 A.2.3.4. Changing Point of Network Attachement 1385 In the possible case that a customer has to change its point of 1386 network attachment to another POP/LER within the ISP access network 1387 two different approaches can be applied assuming that the customer 1388 uses PA addresses out of the SP aggregate: 1390 1.) The customer has to renumber its network with an adequate 1391 customer prefix out of the aggregate of the corresponding LER/RAR of 1392 its new network attachement. To minimise the administrative burden 1393 for the customer the prefix should be of the same size as the former. 1394 This conserves the IPv6 address aggregation within the SP network 1395 (and the MPLS label space) but adds additional burden to the 1396 customer. Hence this approach will most likely only be chosen in the 1397 case of "small customers" with temporary addressing needs and/or 1398 prefix delegation with address auto-configuration. 1400 2.) The customer does not need to renumber its network and keeps its 1401 address aggregate. 1403 This apporach leads to additional more-specific routing entries 1404 within the IGP routing table of the LER and will hence consume 1405 additional MPLS labels - but it is totally transparent to the 1406 customer. Because this results in additional administrative effort 1407 and will stress the router resources (label space, memory) of the ISP 1408 this solution will only be offered to the most valuable customers of 1409 an ISP (like e.g. "big customers" or "enterprise customers"). 1411 Nevertheless the ISP has again to find a fair trade-off between 1412 customer renumbering and sub-optimal address aggregation (i.e. the 1413 generation of additional more-specific routing entries within the IGP 1414 and the waste of MPLS Label space). 1416 A.2.3.5. Restructuring of SP (access) Network and Renumbering 1418 A technically triggered restructuring of the SP (access) network (for 1419 instance because of split of equipment or installation of new 1420 equipment) should not lead to a customer network renumbering. This 1421 challenge should be handled in advance by an intelligent network 1422 design and IPv6 address planing. 1424 In the worst case the customer network renumbering could be avoided 1425 through the implementation of more specific customer routes. (Note: 1426 Since this kind of network restructuring will mostly happen within 1427 the access network (at the level) below the LER, the LER aggregation 1428 level will not be harmed and the more-specific routes will not 1429 consume additional MPLS label space.) 1431 A.2.3.6. Extensions Needed for the Later IPv6 Migration Phases 1433 The proposed IPv6 addressing schema for a SP needs some slight 1434 enhancements / modifications for the later phases of IPv6 1435 integration, for instance in the case when the whole MPLS backbone 1436 infrastructure (LDP, IGP etc.) is realized over IPv6 transport and an 1437 IPv6 addressing of the LSRs is needed. Other changes may be 1438 necessary as well but should not be explained at this point. 1440 Authors' Addresses 1442 Gunter Van de Velde 1443 Cisco Systems 1444 De Kleetlaan 6a 1445 Diegem 1831 1446 Belgium 1448 Phone: +32 2704 5473 1449 Email: gunter@cisco.com 1451 Ciprian Popoviciu 1452 Cisco Systems 1453 7025-6 Kit Creek Road 1454 Research Triangle Park, North Carolina PO Box 14987 1455 USA 1457 Phone: +1 919 392-3723 1458 Email: cpopovic@cisco.com 1460 Tim Chown 1461 University of Southampton 1462 Highfield 1463 Southampton, SO17 1BJ 1464 United Kingdom 1466 Phone: +44 23 8059 3257 1467 Email: tjc@ecs.soton.ac.uk 1469 Olaf Bonness 1470 T-Systems Enterprise Services GmbH 1471 Goslarer Ufer 35 1472 Berlin, 10589 1473 Germany 1475 Phone: +49 30 3497 3124 1476 Email: Olaf.Bonness@t-systems.com 1477 Christian Hahn 1478 T-Systems Enterprise Services GmbH 1479 Goslarer Ufer 35 1480 Berlin, 10589 1481 Germany 1483 Phone: +49 30 3497 3164 1484 Email: HahnC@t-systems.com 1486 Full Copyright Statement 1488 Copyright (C) The IETF Trust (2008). 1490 This document is subject to the rights, licenses and restrictions 1491 contained in BCP 78, and except as set forth therein, the authors 1492 retain all their rights. 1494 This document and the information contained herein are provided on an 1495 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1496 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1497 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1498 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1499 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1500 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1502 Intellectual Property 1504 The IETF takes no position regarding the validity or scope of any 1505 Intellectual Property Rights or other rights that might be claimed to 1506 pertain to the implementation or use of the technology described in 1507 this document or the extent to which any license under such rights 1508 might or might not be available; nor does it represent that it has 1509 made any independent effort to identify any such rights. Information 1510 on the procedures with respect to rights in RFC documents can be 1511 found in BCP 78 and BCP 79. 1513 Copies of IPR disclosures made to the IETF Secretariat and any 1514 assurances of licenses to be made available, or the result of an 1515 attempt made to obtain a general license or permission for the use of 1516 such proprietary rights by implementers or users of this 1517 specification can be obtained from the IETF on-line IPR repository at 1518 http://www.ietf.org/ipr. 1520 The IETF invites any interested party to bring to its attention any 1521 copyrights, patents or patent applications, or other proprietary 1522 rights that may cover technology that may be required to implement 1523 this standard. Please address the information to the IETF at 1524 ietf-ipr@ietf.org.