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