idnits 2.17.1 draft-ietf-v6ops-addcon-03.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 1422. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1433. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1440. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1446. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. 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 (March 3, 2007) is 6261 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: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'RIID' on line 473 == Unused Reference: '5' is defined on line 1259, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2462 (ref. '2') (Obsoleted by RFC 4862) -- Obsolete informational reference (is this intentional?): RFC 2471 (ref. '3') (Obsoleted by RFC 3701) -- Obsolete informational reference (is this intentional?): RFC 3041 (ref. '6') (Obsoleted by RFC 4941) -- Obsolete informational reference (is this intentional?): RFC 3177 (ref. '9') (Obsoleted by RFC 6177) -- Obsolete informational reference (is this intentional?): RFC 3315 (ref. '11') (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3484 (ref. '12') (Obsoleted by RFC 6724) -- Obsolete informational reference (is this intentional?): RFC 3627 (ref. '15') (Obsoleted by RFC 6547) -- Obsolete informational reference (is this intentional?): RFC 3633 (ref. '16') (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3736 (ref. '18') (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 4214 (ref. '25') (Obsoleted by RFC 5214) == Outdated reference: A later version (-07) exists of draft-ooms-v6ops-bgp-tunnel-06 == Outdated reference: A later version (-04) exists of draft-ietf-v6ops-scanning-implications-00 Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 19 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Van de Velde 3 Internet-Draft C. Popoviciu 4 Expires: September 4, 2007 Cisco Systems 5 T. Chown 6 University of Southampton 7 O. Bonness 8 C. Hahn 9 T-Systems Enterprise Services GmbH 10 March 3, 2007 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 September 4, 2007. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2007). 44 Abstract 46 One fundamental aspect of any IP communications infrastructure is its 47 addressing plan. With its new address architecture and allocation 48 policies, the introduction of IPv6 into a network means that network 49 designers and operators need to reconsider their existing approaches 50 to network addressing. Lack of guidelines on handling this aspect of 51 network design could slow down the deployment and integration of 52 IPv6. This document aims to provide the information and 53 recommendations relevant to planning the addressing aspects of IPv6 54 deployments. The document also provides IPv6 addressing case studies 55 for both an enterprise and an ISP network. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2. Network Level Addressing Design Considerations . . . . . . . . 5 61 2.1. Global Unique Addresses . . . . . . . . . . . . . . . . . 5 62 2.2. Unique Local IPv6 Addresses . . . . . . . . . . . . . . . 6 63 2.3. 6Bone Address Space . . . . . . . . . . . . . . . . . . . 7 64 2.4. Network Level Design Considerations . . . . . . . . . . . 7 65 2.4.1. Sizing the Network Allocation . . . . . . . . . . . . 8 66 2.4.2. Address Space Conservation . . . . . . . . . . . . . . 8 67 3. Subnet Prefix Considerations . . . . . . . . . . . . . . . . . 8 68 3.1. Considerations for subnet prefixes shorter then /64 . . . 9 69 3.2. Considerations for /64 prefixes . . . . . . . . . . . . . 9 70 3.3. Considerations for subnet prefixes longer then /64 . . . . 9 71 3.3.1. Anycast addresses . . . . . . . . . . . . . . . . . . 10 72 3.3.2. Addresses used by Embedded-RP (RFC3956) . . . . . . . 11 73 3.3.3. ISATAP addresses . . . . . . . . . . . . . . . . . . . 12 74 3.3.4. /126 addresses . . . . . . . . . . . . . . . . . . . . 12 75 3.3.5. /127 addresses . . . . . . . . . . . . . . . . . . . . 12 76 3.3.6. /128 addresses . . . . . . . . . . . . . . . . . . . . 12 77 4. Allocation of the IID of an IPv6 Address . . . . . . . . . . . 13 78 4.1. Automatic EUI-64 Format Option . . . . . . . . . . . . . . 13 79 4.2. Using Privacy Extensions . . . . . . . . . . . . . . . . . 13 80 4.3. Cryptographically Generated IPv6 Addresses . . . . . . . . 14 81 4.4. Manual/Dynamic Assignment Option . . . . . . . . . . . . . 14 82 5. Case Studies . . . . . . . . . . . . . . . . . . . . . . . . . 15 83 5.1. Enterprise Considerations . . . . . . . . . . . . . . . . 15 84 5.1.1. Obtaining general IPv6 network prefixes . . . . . . . 15 85 5.1.2. Forming an address (subnet) allocation plan . . . . . 16 86 5.1.3. Other considerations . . . . . . . . . . . . . . . . . 17 87 5.1.4. Node configuration considerations . . . . . . . . . . 17 88 5.2. Service Provider Considerations . . . . . . . . . . . . . 18 89 5.2.1. Investigation of objective Requirements for an 90 IPv6 addressing schema of a Service Provider . . . . 18 91 5.2.2. Exemplary IPv6 address allocation plan for a 92 Service Provider . . . . . . . . . . . . . . . . . . . 21 93 5.2.3. Additional Remarks . . . . . . . . . . . . . . . . . . 25 94 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 95 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28 96 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 97 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 98 9.1. Normative References . . . . . . . . . . . . . . . . . . . 28 99 9.2. Informative References . . . . . . . . . . . . . . . . . . 28 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 101 Intellectual Property and Copyright Statements . . . . . . . . . . 33 103 1. Introduction 105 The Internet Protocol Version 6 (IPv6) Addressing Architecture [26] 106 defines three main types of addresses: unicast, anycast and 107 multicast. This document focuses on unicast addresses, for which 108 there are currently two principal allocated types: Global Unique 109 Addresses [14] ('globals') and Unique Local IPv6 Addresses [24] 110 (ULAs). In addition until recently there has been 'experimental' 111 6bone address space [3], though its use has been deprecated since 112 June 2006 [17]. 114 The document covers aspects that should be considered during IPv6 115 deployment for the design and planning of an addressing scheme for an 116 IPv6 network. The network's IPv6 addressing plan may be for an IPv6- 117 only network, or for a dual-stack infrastructure where some or all 118 devices have addresses in both protocols. These considerations will 119 help an IPv6 network designer to efficiently and prudently assign the 120 IPv6 address space that has been allocated to their organization. 122 The address assignment considerations are analyzed separately for the 123 two major components of the IPv6 unicast addresses, namely 'Network 124 Level Addressing' (the allocation of subnets) and the 'interface-id'. 125 Thus the document includes a discussion of aspects of address 126 assignment to nodes and interfaces in an IPv6 network. Finally the 127 document provides two examples of deployed address plans in a service 128 provider (ISP) and an enterprise network. 130 Parts of this document highlight the differences that an experienced 131 IPv4 network designer should consider when planning an IPv6 132 deployment, for example: 134 o IPv6 devices will more likely be multi-addressed in comparison 135 with their IPv4 counterparts 136 o The practically unlimited size of an IPv6 subnet (2^64 bits) 137 reduces the requirement to size subnets to device counts for the 138 purposes of (IPv4) address conservation 139 o Even though there is no broadcast for the IPv6 protocol, there is 140 still need to consider the number of devices in a given subnet due 141 to traffic storm and level of traffic generated by hosts 142 o The implications of the vastly increased subnet size on the threat 143 of address-based host scanning and other scanning techniques, as 144 discussed in [30]. 146 We do not discuss here how a site or ISP should proceed with 147 acquiring its globally routable IPv6 address prefix. However, one 148 should note that IPv6 networks currently receive their global unicast 149 address allocation from their 'upstream' provider, which may be 150 another ISP, a Local Internet Registry (LIR) or a Regional Internet 151 Registry (RIR). In each case the prefix received is provider 152 assigned (PA). Until very recently there has been no provider 153 independent (PI) address space for IPv6 generally available. However 154 ARIN is now providing PI address space allocations, subject to 155 customers meeting certain requirements. 157 We do not discuss PI policy here. The observations and 158 recommendations of this text are largely independent of the PA or PI 159 nature of the address block being used. At this time we assume that 160 most commonly an IPv6 network which changes provider will need to 161 undergo a renumbering process, as described in [23]. A separate 162 document [32] makes recommendations to ease the IPv6 renumbering 163 process. 165 This document does not discuss implementation aspects related to the 166 transition between the ULA addresses and the now obsoleted site-local 167 addresses. Most implementations know about Site-local addresses even 168 though they are deprecated, and do not know about ULAs - even though 169 they represent current specification. As result transitioning 170 between these types of addresses may cause difficulties. 172 2. Network Level Addressing Design Considerations 174 This section discusses the kind of IPv6 addresses used at the network 175 level for the IPv6 infrastructure. The kind of addresses that can be 176 considered are Global Unique Addresses and ULAs. We also comment 177 here on the recently deprecated 6bone address space. 179 2.1. Global Unique Addresses 181 The most commonly used unicast addresses will be Global Unique 182 Addresses ('globals'). No significant considerations are necessary 183 if the organization has an address space assignment and a single 184 prefix is deployed through a single upstream provider. 186 However, a multihomed site may deploy addresses from two or more 187 Service Provider assigned IPv6 address ranges. Here, the network 188 Administrator must have awareness on where and how these ranges are 189 used on the multihomed infrastructure environment. The nature of the 190 usage of multiple prefixes may depend on the reason for multihoming 191 (e.g. resilience failover, load balancing, policy-based routing, or 192 multihoming during an IPv6 renumbering event). IPv6 introduces 193 improved support for multi-addressed hosts through the IPv6 default 194 address selection methods described in RFC3484 [12]. A multihomed 195 host may thus have two addresses, one per prefix (provider), and 196 select source and destination addresses to use as described in that 197 RFC. However multihoming also has some operative and administrative 198 burdens besides chosing multiple addresses per interface [33] 199 [34][35]. 201 2.2. Unique Local IPv6 Addresses 203 ULAs have replaced the originally conceived Site Local addresses in 204 the IPv6 addressing architecture, for reasons described in [19]. 205 ULAs improve on site locals by offering a high probability of the 206 global uniqueness of the prefix used, which can be beneficial in the 207 case of (deliberate or accidental) leakage, or where networks are 208 merged. ULAs are akin to the private address space [1] assigned for 209 IPv4 networks, except that in IPv6 networks we may expect to see ULAs 210 used alongside global addresses, with ULAs used internally and 211 globals used externally. Thus use of ULAs does not imply use of NAT 212 for IPv6. 214 The ULA address range allows network administrators to deploy IPv6 215 addresses on their network without asking for a globally unique 216 registered IPv6 address range. A ULA prefix is 48 bits, i.e. a /48, 217 the same as the currently recommended allocation for a site from the 218 globally routable IPv6 address space [9]. 220 ULAs provide the means to deploy a fixed addressing scheme that is 221 not affected by a change in service provider and the corresponding PA 222 global addresses. Internal operation of the network is thus 223 unaffected during renumbering events. Nevertheless, this type of 224 address must be used with caution. 226 A site using ULAs may or may not also deploy globals. In an isolated 227 network ULAs may be deployed on their own. In a connected network, 228 that also deploys global addresses, both may be deployed, such that 229 hosts become multiaddressed (one global and one ULA address) and the 230 IPv6 default address selection algorithm will pick the appropriate 231 source and destination addresses to use, e.g. ULAs will be selected 232 where both the source and destination hosts have ULA addresses. 233 Because a ULA and a global site prefix are both /48 length, an 234 administrator can choose to use the same subnetting (and host 235 addressing) plan for both prefixes. 237 As an example of the problems ULAs may cause, when using IPv6 238 multicast within the network, the IPv6 default address selection 239 algorithm prefers the ULA address as the source address for the IPv6 240 multicast streams. This is NOT a valid option when sending an IPv6 241 multicast stream to the IPv6 Internet for two reasons. For one, 242 these addresses are not globally routable so RPF checks for such 243 traffic will fail outside the internal network. The other reason is 244 that the traffic will likely not cross the network boundary due to 245 multicast domain control and perimeter security policies. 247 In principle ULAs allow easier network mergers than RFC1918 addresses 248 do for IPv4 because ULA prefixes have a high probability of 249 uniqueness, if the prefix is chosen as described in the RFC. 251 The usage of ULAs should be carefully considered even when not 252 attached to the IPv6 Internet due to the potential for added 253 complexity when connecting to the Internet at some point in the 254 future. 256 2.3. 6Bone Address Space 258 The 6Bone address space was used before the RIRs started to 259 distribute 'production' IPv6 prefixes. The 6Bone prefixes have a 260 common first 16 bits in the IPv6 Prefix of 3FFE::/16. This address 261 range is deprecated as of 6th June 2006 [17] and should be avoided on 262 any new IPv6 network deployments. Sites using 6bone address space 263 should renumber to production address space using procedures as 264 defined in [23]. 266 2.4. Network Level Design Considerations 268 IPv6 provides network administrators with a significantly larger 269 address space, enabling them to be very creative in how they can 270 define logical and practical address plans. The subnetting of 271 assigned prefixes can be done based on various logical schemes that 272 involve factors such as: 273 o Geographical Boundaries - by assigning a common prefix to all 274 subnets within a geographical area 275 o Organizational Boundaries - by assigning a common prefix to an 276 entire organization or group within a corporate infrastructure 277 o Service Type - by reserving certain prefixes for predefined 278 services such as: VoIP, Content Distribution, wireless services, 279 Internet Access, etc 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: 288 o Prefix Aggregation - The larger IPv6 addresses can lead to larger 289 routing tables unless network designers are actively pursuing 290 aggregation. While prefix aggregation will be enforced by the 291 service provider, it is beneficial for the individual 292 organizations to observe the same principles in their network 293 design process 295 o Network growth - The allocation mechanism for flexible growth of a 296 network prefix, documented in RFC3531 [13] can be used to allow 297 the network infrastructure to grow and be numbered in a way that 298 is likely to preserve aggregation (the plan leaves 'holes' for 299 growth) 300 o ULA usage in large networks - Networks which have a large number 301 of 'sites' that each deploy a ULA prefix which will by default be 302 a 'random' /48 under fc00::/7 will have no aggregation of those 303 prefixes. Thus the end result may be cumbersome because the 304 network will have large amounts of non-aggregated ULA prefixes. 305 However, there is no rule to disallow large networks to use a 306 single ULA for all 'sites', as a ULA still provides 16 bits for 307 subnetting to be used internally 309 2.4.1. Sizing the Network Allocation 311 We do not discuss here how a network designer sizes their application 312 for address space. By default a site will receive a /48 prefix [9] , 313 however different RIR service regions policies may suggest 314 alternative default assignments or let the ISPs to decide on what 315 they believe is more appropriate for their specific case [28]. The 316 default provider allocation via the RIRs is currently a /32 [31]. 317 These allocations are indicators for a first allocation for a 318 network. Different sizes may be obtained based on the anticipated 319 address usage [31]. There are examples of allocations as large as 320 /19 having been made from RIRs to providers at the time of writing. 322 2.4.2. Address Space Conservation 324 Despite the large IPv6 address space which enables easier subnetting, 325 it still is important to ensure an efficient use of this resource. 326 Some addressing schemes, while facilitating aggregation and 327 management, could lead to significant numbers of addresses being 328 unused. Address conservation requirements are less stringent in IPv6 329 but they should still be observed. 331 The proposed HD [10] value for IPv6 is 0.94 compared to the current 332 value of 0.96 for IPv4. Note that for IPv6 HD is calculated for 333 sites (i.e. on a basis of /48), instead of based on addresses like 334 with IPv4. 336 3. Subnet Prefix Considerations 338 This section analyzes the considerations applied to define the subnet 339 prefix of the IPv6 addresses. The boundaries of the subnet prefix 340 allocation are specified in RFC4291 [26]. In this document we 341 analyze their practical implications. Based on RFC4291 [26] it is 342 legal for any IPv6 unicast address starting with binary address '000' 343 to have a subnet prefix larger than, smaller than or of equal to 64 344 bits. Each of these three options is discussed in this document. 346 3.1. Considerations for subnet prefixes shorter then /64 348 An allocation of a prefix shorter then 64 bits to a node or interface 349 is considered bad practice. The shortest subnet prefix that could 350 theoretically be assigned to an interface or node is limited by the 351 size of the network prefix allocated to the organization. One 352 exception to this recommendation is when using 6to4 technology where 353 a /16 prefix is utilised for the pseudo-interface [8]. 355 A possible reason for choosing the subnet prefix for an interface 356 shorter then /64 is that it would allow more nodes to be attached to 357 that interface compared to a prescribed length of 64 bits. This 358 however is unnecessary considering that 2^64 provides plenty of node 359 addresses for a well designed IPv6 network. Layer two technologies 360 are unlikely to support such large numbers of nodes within a single 361 link (e.g. Ethernet limited to 48-bits of hosts) 363 The subnet prefix assignments can be made either by manual 364 configuration, by a stateful Host Configuration Protocol [11] or by a 365 stateful prefix delegation mechanism [16]. 367 3.2. Considerations for /64 prefixes 369 Based on RFC3177 [9], 64 bits is the prescribed subnet prefix length 370 to allocate to interfaces and nodes. 372 When using a /64 subnet length, the address assignment for these 373 addresses can be made either by manual configuration, by a stateful 374 Host Configuration Protocol [11] [18] or by stateless 375 autoconfiguration [2]. 377 Note that RFC3177 strongly prescribes 64 bit subnets for general 378 usage, and that stateless autoconfiguration option is only defined 379 for 64 bit subnets. 381 3.3. Considerations for subnet prefixes longer then /64 383 Address space conservation is the main motivation for using a subnet 384 prefix length longer than 64 bits. 386 The address assignment can be made either by manual configuration or 387 by a stateful Host Configuration Protocol [11]. 389 When assigning a subnet prefix of more then 80 bits, according to 390 RFC4291 [26] "u" and "g" bits (respectively the 81st and 82nd bit) 391 need to be taken into consideration and should be set correctly. In 392 currently implemented IPv6 protocol stacks, the relevance of the "u" 393 (universal/local) bit and "g" (the individual/group) bit are marginal 394 and typically will not show an issue when configured wrongly, however 395 future implementations may turn out differently. 397 When using subnet lengths longer then 64 bits, it is important to 398 avoid selecting addresses that may have a predefined use and could 399 confuse IPv6 protocol stacks. The alternate usage may not be a 400 simple unicast address in all cases. The following points should be 401 considered when selecting a subnet length longer then 64 bits. 403 3.3.1. Anycast addresses 405 3.3.1.1. Subnet Router Anycast Address 407 RFC4291 [26] provides a definition for the required Subnet Router 408 Anycast Address as follows: 410 | n bits | 128-n bits | 411 +--------------------------------------------+----------------+ 412 | subnet prefix | 00000000000000 | 413 +--------------------------------------------+----------------+ 415 It is recommended to avoid allocating this IPv6 address to a device 416 which is not a router. No additional dependencies for the subnet 417 prefix while the EUI-64 and an IID dependencies will be discussed 418 later in this document. 420 3.3.1.2. Reserved IPv6 Subnet Anycast Addresses 422 RFC2526 [4] stated that within each subnet, the highest 128 interface 423 identifier values are reserved for assignment as subnet anycast 424 addresses. 426 The construction of a reserved subnet anycast address depends on the 427 type of IPv6 addresses used within the subnet, as indicated by the 428 format prefix in the addresses. 430 The first type of Subnet Anycast addresses have been defined as 431 follows for EUI-64 format: 433 | 64 bits | 57 bits | 7 bits | 434 +------------------------------+------------------+------------+ 435 | subnet prefix | 1111110111...111 | anycast ID | 436 +------------------------------+------------------+------------+ 438 The anycast address structure implies that it is important to avoid 439 creating a subnet prefix where the bits 65 to 121 are defined as 440 "1111110111...111" (57 bits in total) so that confusion can be 441 avoided. 443 For other IPv6 address types (that is, with format prefixes other 444 than those listed above), the interface identifier is not in EUI-64 445 format and may be other than 64 bits in length; these reserved subnet 446 anycast addresses for such address types are constructed as follows: 448 | n bits | 121-n bits | 7 bits | 449 +------------------------------+------------------+------------+ 450 | subnet prefix | 1111111...111111 | anycast ID | 451 +------------------------------+------------------+------------+ 452 | interface identifier field | 454 In the case discussed above there is no additional dependency for the 455 subnet prefix with the exception of the EUI-64 and an IID dependency. 456 These will be discussed later in this document. 458 3.3.2. Addresses used by Embedded-RP (RFC3956) 460 Embedded-RP [20] reflects the concept of integrating the Rendezvous 461 Point (RP) IPv6 address into the IPv6 multicast group address. Due 462 to this embedding and the fact that the length of the IPv6 address 463 AND the IPv6 multicast address are 128 bits, it is not possible to 464 have the complete IPv6 address of the multicast RP embedded as such. 466 This resulted in a restriction of 15 possible RP-addresses per prefix 467 that can be used with embedded-RP. The space assigned for the 468 embedded-RP is based on the 4 low order bits, while the remainder of 469 the Interface ID is set to all '0'. 471 [IPv6-prefix (64 bits)][60 bits all '0'][RIID] 473 Where: [RIID] = 4 bit. 475 This format implies that when selecting subnet prefixes longer then 476 64, and the bits beyond the 64th one are non-zero, the subnet can not 477 use embedded-RP. 479 In addition it is discouraged to assign a matching embedded-RP IPv6 480 address to a device that is not a real Multicast Rendezvous Point, 481 eventhough it would not generate major problems. 483 3.3.3. ISATAP addresses 485 ISATAP [25] is an automatic tunneling protocol used to provide IPv6 486 connectivity over an IPv4 campus or enterprise environment. In order 487 to leverage the underlying IPv4 infrastructure, the IPv6 addresses 488 are constructed in a special format. 490 An IPv6 ISATAP address has the IPv4 address embedded, based on a 491 predefined structure policy that identifies them as an ISATAP 492 address. 494 [IPv6 Prefix (64 bits)][0000:5EFE][IPv4 address] 496 When using subnet prefix length longer then 64 bits it is recommended 497 that that the portion of the IPv6 prefix from bit 65 to the end of 498 the subnet prefix does not match with the well-known ISATAP [0000: 499 5EFE] address portion. 501 In its actual definition there is no multicast support on ISATAP 503 3.3.4. /126 addresses 505 The 126 bit subnet prefixes are typically used for point-to-point 506 links similar to a the IPv4 address conservative /30 allocation for 507 point-to-point links. The usage of this subnet address length does 508 not lead to any additional considerations other than the ones 509 discussed earlier in this section, particularly those related to the 510 "u" and "g" bits. 512 3.3.5. /127 addresses 514 The usage of the /127 addresses is not valid and should be strongly 515 discouraged as documented in RFC3627 [15]. 517 3.3.6. /128 addresses 519 The 128 bit address prefix may be used in those situations where we 520 know that one, and only one address is sufficient. Example usage 521 would be the off-link loopback address of a network device. 523 When choosing a 128 bit prefix, it is recommended to take the "u" and 524 "g" bits into consideration and to make sure that there is no overlap 525 with either the following well-known addresses: 526 o Subnet Router Anycast Address 527 o Reserved Subnet Anycast Address 528 o Addresses used by Embedded-RP 529 o ISATAP Addresses 531 4. Allocation of the IID of an IPv6 Address 533 In order to have a complete IPv6 address, an interface must be 534 associated a prefix and an Interface Identifier (IID). Section 3 of 535 this document analyzed the prefix selection considerations. This 536 section discusses the elements that should be considered when 537 assigning the IID portion of the IPv6 address. 539 There are various ways to allocate an IPv6 address to a device or 540 interface. The option with the least amount of caveats for the 541 network administrator is that of EUI-64 [2] based addresses. For the 542 manual or dynamic options, the overlap with well known IPv6 addresses 543 should be avoided. 545 4.1. Automatic EUI-64 Format Option 547 When using this method the network administrator has to allocate a 548 valid 64 bit subnet prefix. The EUI-64 [2] allocation procedure can 549 from that moment onward assign the remaining 64 IID bits in a 550 stateless manner. All the considerations for selecting a valid IID 551 have been incorporated in the EUI-64 methodology. 553 4.2. Using Privacy Extensions 555 The main purpose of IIDs generated based on RFC3041 [6] is to provide 556 privacy to the entity using this address. While there are no 557 particular constraints in the usage of these addresses as defined in 558 [6] there are some implications to be aware of when using privacy 559 addresses as documented in section 4 of RFC3041 [6]: 560 o The privacy extension algorithm may complicate flexibility in 561 future transport protocols 562 o These addresses may add complexity to the operational management 563 and troubleshooting of the infrastructure (i.e. which address 564 belongs to which real host) 565 o A reverse DNS lookup check may be broken when using privacy 566 extensions 568 4.3. Cryptographically Generated IPv6 Addresses 570 Cryptographically Generated Addresses (CGAs) are based upon RFC3972 571 [22] and provide a method for binding a public signature key to an 572 IPv6 address in the Secure Neighbor Discovery (SEND) protocol [21]. 574 The basic idea is to generate the interface identifier (i.e. the 575 rightmost 64 bits) of the IPv6 address by computing a cryptographic 576 hash of the public key. The resulting IPv6 address is called a 577 cryptographically generated address (CGA). The corresponding private 578 key can then be used to sign messages sent from that address. 580 Implications to be aware of when using CGA addresses are found in 581 section 7 of RFC3972 [22]: 582 o When using CGA addresses the values of the "u" and "g" bits are 583 ignored however it does not add any security or implementation 584 implications 585 o There is no mechanism for proving that an address is not a CGA 586 o When it is discovered that a node has been compromised, a new 587 signature key and a new CGA should be generated 589 Due to the fact that CGA generated addresses are almost 590 indistinguishable from a privacy address and has similar properties 591 for many purposes, the same considerations as with privacy addresses 592 are also valid for CGA generated addresses. 594 4.4. Manual/Dynamic Assignment Option 596 This section discusses those IID allocations that are not implemented 597 through stateless address configuration (Section 4.1). They are 598 applicable regardless of the prefix length used on the link. It is 599 out of scope for this section to discuss the various assignment 600 methods (e.g. manual configuration, DHCPv6, etc). 602 In this situation the actual allocation is done by human intervention 603 and consideration needs to be given to the complete IPv6 address so 604 that it does not result in overlaps with any of the well known IPv6 605 addresses: 606 o Subnet Router Anycast Address 607 o Reserved Subnet Anycast Address 608 o Addresses used by Embedded-RP 609 o ISATAP Addresses 611 When using an address assigned by human intervention it is 612 recommended to choose IPv6 addresses which are not obvious to guess 613 and/or avoid any IPv6 addresses that embed IPv4 addresses used in the 614 current infrastructure. Following these two recommendations will 615 make it more difficult for malicious third parties to guess targets 616 for attack, and thus reduce security threats to a certain extent. 618 5. Case Studies 620 5.1. Enterprise Considerations 622 In this section we consider a case study of a campus network that is 623 deploying IPv6 in parallel with existing IPv4 protocols in a dual- 624 stack environment. The specific example is the University of 625 Southampton (UK), focusing on a large department within that network. 626 The deployment currently spans around 1,000 hosts and over 1,500 627 users. 629 5.1.1. Obtaining general IPv6 network prefixes 631 In the case of a campus network, the site will typically take its 632 connectivity from its National Research and Education Network (NREN). 633 Southampton connects to JANET, the UK academic network, via its local 634 regional network LeNSE. JANET currently has a /32 allocation from 635 RIPE of 2001:630::/32. The current recommended practice is for sites 636 to receive a /48 allocation, and on this basis Southampton has 637 received such a prefix for its own use, specifically 2001:630: 638 d0::/48. The regional network also uses its own allocation from the 639 NREN provider. 641 No ULA addressing is used on site. The campus is not multihomed 642 (JANET is the sole provider), nor does it expect to change service 643 provider, and thus does not plan to use ULAs for the (perceived) 644 benefit of easing network renumbering. Indeed, the campus has 645 renumbered following the aforementioned renumbering procedure [23] on 646 two occasions, and this has proven adequate (with provisos documented 647 in [32]. We also do not see any need to deploy ULAs for in or out of 648 band network management; there are enough IPv6 prefixes available in 649 the site allocation for the infrastructure. In some cases, use of 650 private IP address space in IPv4 creates problems, so we believe that 651 the availability of ample global IPv6 address space for 652 infrastructure may be a benefit for many sites. 654 No 6bone addressing is used on site any more. We note that since the 655 6bone phaseout of June 2006 [17] most transit ISPs have begun 656 filtering attempted use of such prefixes. 658 Southampton does participate in global and organization scope IPv6 659 multicast networks. Multicast address allocations are not discussed 660 here as they are not in scope for the document. We note that IPv6 661 has advantages for multicast group address allocation. In IPv4 a 662 site needs to use techniques like GLOP to pick a globally unique 663 multicast group to use. This is problematic if the site does not use 664 BGP and have an ASN. In IPv6 unicast-prefix-based IPv6 multicast 665 addresses empower a site to pick a globally unique group address 666 based on its unicast own site or link prefix. Embedded RP is also in 667 use, is seen as a potential advantage for IPv6 and multicast, and has 668 been tested successfully across providers between sites (including 669 paths to/from the US and UK). 671 5.1.2. Forming an address (subnet) allocation plan 673 The campus has a /16 prefix for IPv4 use; in principle 256 subnets of 674 256 addresses. In reality the subnetting is muddier, because of 675 concerns of IPv4 address conservation; subnets are sized to the hosts 676 within them, e.g. a /26 IPv4 prefix is used if a subnet has 35 hosts 677 in it. While this is efficient, it increases management burden when 678 physical deployments change, and IPv4 subnets require resizing (up or 679 down), even with DHCP in use. 681 The /48 IPv6 prefix is considerably larger than the IPv4 allocation 682 already in place at the site. It is loosely equivalent to a 'Class 683 A' IPv4 prefix in that it has 2^16 (over 65,000) subnets, but has an 684 effectively unlimited subnet address size (2^64) compared to 256 in 685 the IPv4 equivalent. The increased subnet size means that /64 IPv6 686 prefixes can be used on all subnets, without any requirement to 687 resize them at a later date. The increased subnet volume allows 688 subnets to be allocated more generously to schools and departments in 689 the campus. While address conservation is still important, it is no 690 longer an impediment on network management. Rather, address (subnet) 691 allocation is more about embracing the available address space and 692 planning for future expansion. 694 In a dual-stack network, we choose to deploy our IP subnets 695 congruently for IPv4 and IPv6. This is because the systems are still 696 in the same administrative domains and the same geography. We do not 697 expect to have IPv6-only subnets in production use for a while yet, 698 outside our test beds and our early Mobile IPv6 trials. With 699 congruent addressing, our firewall policies are also aligned for IPv4 700 and IPv6 traffic at our site border. 702 The subnet allocation plan required a division of the address space 703 per school or department. Here a /56 was allocated to the school 704 level of the university; there are around 30 schools currently. A 705 /56 of IPv6 address space equates to 256 /64 size subnet allocations. 706 Further /56 allocations were made for central IT infrastructure, for 707 the network infrastructure and the server side systems. 709 5.1.3. Other considerations 711 The network uses a Demilitarized Zone (DMZ) topology for some level 712 of protection of 'public' systems. Again, this topology is congruent 713 with the IPv4 network. 715 There are no specific transition methods deployed internally to the 716 campus; everything is using the conventional dual-stack approach. 717 There is no use of ISATAP [25] for example. 719 For the Mobile IPv6 early trials, we have allocated one prefix for 720 Home Agent (HA) use. We have not yet considered in detail how Mobile 721 IPv6 usage may grow, and whether more or even every subnet will 722 require HA support. 724 The university operates a tunnel broker [7] service on behalf of 725 UKERNA for JANET sites. This uses separate address space from JANET, 726 not our university site allocation. 728 5.1.4. Node configuration considerations 730 We currently use stateless autoconfiguration on most subnets for IPv6 731 hosts. There is no DHCPv6 service deployed yet, beyond tests of 732 early code releases. We plan to deploy DHCPv6 for address assignment 733 when robust client and server code is available (at the time of 734 writing the potential for this looks good, e.g. via the ISC 735 implementation). We also are seeking a common integrated DHCP/DNS 736 management platform, even if the servers themselves are not co- 737 located, including integrated DHCPv4 and DHCPv6 server configuration, 738 as discussed in [27]. Currently we add client statelessly 739 autoconfigured addresses to the DNS manually, though dynamic DNS is 740 an option. Our administrators would prefer the use of DHCP because 741 they believe it gives them more management control. 743 Regarding the implications of the larger IPv6 subnet address space on 744 scanning attacks [30], we note that all our hosts are dual-stack, and 745 thus are potentially exposed over both protocols anyway. We publish 746 all addresses in DNS, and do not operate a two faced DNS. 748 We have internal usage of RFC3041 privacy addresses [6] currently 749 (certain platforms currently ship with it on by default), but may 750 wish to administratively disable this (perhaps via DHCP) to ease 751 management complexity. However, we need to determine the feasibility 752 of this on all systems, e.g. for guests on wireless LAN or other 753 user-maintained systems. Network management and monitoring should be 754 simpler without RFC3041 in operation, in terms of identifying which 755 physical hosts are using which addresses. We note that RFC3041 is 756 only an issue for outbound connections, and that there is potential 757 to assign privacy addresses via DHCPv6. 759 We manually configure server addresses to avoid address changes on a 760 change of network adaptor. With IPv6 you can choose to pick ::53 for 761 a DNS server, or can pick 'random' addresses for obfuscation, though 762 that's not an issue for publicly advertised addresses (dns, mx, web, 763 etc). 765 5.2. Service Provider Considerations 767 In this section an IPv6 addressing schema is sketched that could 768 serve as an example for an Internet Service Provider. 770 Sub-section 5.2.1 starts with some thoughts regarding objective 771 requirements of such an addressing schema and derives a few general 772 thumb rules that have to be kept in mind when designing an ISP IPv6 773 addressing plan. 775 Sub-section 5.2.2 illustrates these findings of 5.2.1 with an 776 exemplary IPv6 addressing schema for an MPLS-based ISP offering 777 Internet Services as well as Network Access services to several 778 millions of customers. 780 5.2.1. Investigation of objective Requirements for an IPv6 addressing 781 schema of a Service Provider 783 The first step of the IPv6 addressing plan design for a Service 784 provider should identify all technical, operational, political and 785 business requirements that have to be satisfied by the services 786 supported by this addressing schema. 788 According to the different technical constraints and business models 789 as well as the different weights of these requirements (from the 790 point of view of the corresponding Service Provider) it is very 791 likely that different addressing schemas will be developed and 792 deployed by different ISPs. Nevertheless the addressing schema of 793 sub-section 5.2.2 is one possible example. 795 For this document it is assumed that our exemplary ISP has to fulfill 796 several roles for its customers as there are: 798 o Local Internet Registry 799 o Network Access Provider 800 o Internet Service Provider 802 5.2.1.1. Requirements for an IPv6 addressing schema from the LIR 803 perspective of the Service Provider 805 In their role as LIR the Service Providers have to care about the 806 policy constraints of the RIRs and the standards of the IETF 807 regarding IPv6 addressing. In this context, the following basic 808 requirements and recommendations have to be considered and should be 809 satisfied by the IPv6 address allocation plan of a Service Provider: 810 o As recommended in RFC 3177 [9] and in several RIR policies 811 "Common" customers sites (normally private customers) should 812 receive a /48 prefix from the aggregate of the Service Provider. 813 (Note: The addressing plan must be flexible enough and take into 814 account the possible change of the minimum allocation size for end 815 users currently under definition by the RIRs.) 816 o "Big customers" (like big enterprises, governmental agencies etc.) 817 may receive shorter prefixes according to their needs when this 818 need could be documented and justified to the RIR. 819 o The IPv6 address allocation schema has to be able to meet the HD- 820 ratio that is proposed for IPv6. This requirement corresponds to 821 the demand for an efficient usage of the IPv6 address aggregate by 822 the Service Provider. (Note: The currently valid IPv6 HD-ratio of 823 0.94 means an effective usage of about 31% of a /20 prefix of the 824 Service Provider on the basis of /48 assignments.) 825 o All assignments to customers have to be documented and stored into 826 a database that can also be queried by the RIR. 827 o The LIR has to make available means for supporting the reverse DNS 828 mapping of the customer prefixes. 830 5.2.1.2. IPv6 addressing schema requirements from the ISP perspective 831 of the Service Provider 833 From ISP perspective the following basic requirements could be 834 identified: 835 o The IPv6 address allocation schema must be able to realize a 836 maximal aggregation of all IPv6 address delegations to customers 837 into the address aggregate of the Service Provider. Only this 838 provider aggregate will be routed and injected into the global 839 routing table (DFZ). This strong aggregation keeps the routing 840 tables of the DFZ small and eases filtering and access control 841 very much. 842 o The IPv6 addressing schema of the SP should contain maximal 843 flexibility since the infrastructure of the SP will change over 844 the time with new customers, transport technologies and business 845 cases. The requirement of maximal flexibility is contrary to the 846 requirements of strong IPv6 address aggregation and efficient 847 address usage, but at this point each SP has to decide which of 848 these requirements to prioritize. 850 o Keeping the multilevel network hierarchy of an ISP in mind, due to 851 addressing efficiency reasons not all hierarchy levels can and 852 should be mapped into the IPv6 addressing schema of an ISP. 853 Sometimes it is much better to implement "flat" addressing for the 854 ISP network than to loose big chunks of the IPv6 address aggregate 855 in addressing each level of network hierarchy. Besides that a 856 decoupling of provider network addressing and customer addressing 857 is recommended. (Note: A strong aggregation e.g. on POP, 858 aggregation router or Label Edge Router (LER) level limits the 859 numbers of customer routes that are visible within the ISP network 860 but brings also down the efficiency of the IPv6 addressing schema. 861 That's why each ISP has to decide how many internal aggregation 862 levels it wants to deploy.) 864 5.2.1.3. IPv6 addressing schema requirements from the Network Access 865 provider perspective of the Service Provider 867 As already done for the LIR and the ISP roles of the SP it is also 868 necessary to identify requirements that come from its Network Access 869 Provider role. Some of the basic requirements are: 870 o The IPv6 addressing schema of the SP must be flexible enough to 871 adapt changes that are injected from the customer side. This 872 covers changes to addressing architecture or routing topology that 873 are triggered from for instance the growing needs of the customers 874 regarding IPv6 addresses as well as changes that come from 875 topological modifications (e.g. when the customer moves from one 876 point of network attachment (POP) to another). 877 o For each IPv6 address assignment to customers a "buffer zone" must 878 be reserved that allows the customer to grow in its addressing 879 range without renumbering or assignment of additional prefixes. 880 o The IPv6 addressing schema of the SP must deal with multiple- 881 attachments of a single customer to the SP network infrastructure 882 (i.e. multi-homed network access with the same SP). 884 These few requirements are only part of all the requirements a 885 Service Provider has to investigate and keep in mind during the 886 definition phase of its addressing architecture. Each SP will most 887 likely add more constraints to this list. 889 5.2.1.4. A few thumb rules for designing an IPv6 ISP addressing 890 architecture 892 As outcome of the above enumeration of requirements regarding an ISP 893 IPv6 addressing plan the following design "thumb rules" have been 894 derived: 895 o No "One size fits all" Each ISP must develop its own IPv6 address 896 allocation schema depending on its concrete business needs. It is 897 not practicable to design one addressing plan that fits for all 898 kinds of ISPs (Small / big, Routed / MPLS-based, access / transit, 899 LIR / No-LIR, etc.). 900 o The levels of IPv6 address aggregation within the ISP addressing 901 schema should strongly correspond to the implemented network 902 structure and their number should be minimized because of 903 efficiency reasons. It is assumed that the SPs own infrastructure 904 will be addressed in a fairly flat way whereas the part of the 905 customer addressing architecture should contain several levels of 906 aggregation. 907 o Keep the number of IPv6 customer routes inside your network as 908 small as necessary. A totally flat customer IPv6 addressing 909 architecture without any intermediate aggregation level will lead 910 to lots of customer routes inside the SP network. A fair trade- 911 off between address aggregation levels (and hence the size of the 912 internal routing table of the SP) and address conservation of the 913 addressing architecture has to be found. 914 o The ISP IPv6 addressing schema should provide maximal flexibility. 915 This has to be realized for supporting different sizes of customer 916 IPv6 address aggregates ("big" customers vs. "small" customers) as 917 well as to allow future growing rates (e.g. of customer 918 aggregates) and possible topological or infrastructural changes. 919 o A limited number of aggregation levels and sizes of customer 920 aggregates will ease the management of the addressing schema. 921 This has to be weighed against the previous "thumb rule" - 922 flexibility. 924 5.2.2. Exemplary IPv6 address allocation plan for a Service Provider 926 In this example, the Service Provider is assumed to operate an MPLS 927 based backbone and implements 6PE [29] to provide IPv6 backbone 928 transport between the different locations (POPs) of a fully dual- 929 stacked network access and aggregation area. 931 Besides that it is assumed that the Service Provider: 932 o has received a /20 from its RIR 933 o operates its own LIR 934 o has to address its own IPv6 infrastructure 935 o delegates prefixes from this aggregate to its customers 937 This addressing schema should illustrate how the /20 IPv6 prefix of 938 the SP can be used to address the SP-own infrastructure and to 939 delegate IPv6 prefixes to its customers following the above mentioned 940 requirements and thumb rules as far as possible. 942 The below figure summarizes the device types in an SP network and the 943 typical network design of a MPLS-based service provider. The network 944 hierarchy of the SP has to be taken into account for the design of an 945 IPv6 addressing schema and defines its basic shape and the various 946 levels of aggregation. 948 +------------------------------------------------------------------+ 949 | LSRs of the MPLS Backbone of the SP | 950 +------------------------------------------------------------------+ 951 | | | | | 952 | | | | | 953 +-----+ +-----+ +--------+ +--------+ +--------+ 954 | LER | | LER | | LER-BB | | LER-BB | | LER-BB | 955 +-----+ +-----+ +--------+ +--------+ +--------+ 956 | | | | | | / | | | 957 | | | | | | / | | | 958 | | | | +------+ +------+ +------+ | | 959 | | | | |BB-RAR| |BB-RAR| | AG | | | 960 | | | | +------+ +------+ +------+ | | 961 | | | | | | | | | | | | 962 | | | | | | | | | | | | 963 | | | | | | | | +-----+ +-----+ +-----+ +-----+ 964 | | | | | | | | | RAR | | RAR | | RAR | | RAR | 965 | | | | | | | | +-----+ +-----+ +-----+ +-----+ 966 | | | | | | | | | | | | | | | | 967 | | | | | | | | | | | | | | | | 968 +-------------------------------------------------------------------+ 969 | Customer networks | 970 +-------------------------------------------------------------------+ 971 Figure: Exemplary Service Provider Network 973 LSR ... Label Switch Router 974 LER ... Label Edge Router 975 LER-BB ... Broadband Label Edge Router 976 RAR ... Remote Access Router 977 BB-RAR ... Broadband Remote Access Router 978 AG ... Aggregation Router 980 Basic design decisions for the exemplary Service Provider IPv6 981 address plan regarding customer prefixes take into consideration: 982 o The prefixes assigned to all customers behind the same LER (e.g. 983 LER or LER-BB) are aggregated under one LER prefix. This ensures 984 that the number of labels that have to be used for 6PE is limited 985 and hence provides a strong MPLS label conservation. 986 o The /20 prefix of the SP is separated into 3 different pools that 987 are used to allocate IPv6 prefixes to the customers of the SP: 988 * A pool (e.g. /24) for satisfying the addressing needs of really 989 "big" customers (as defined in 5.2.2.1 sub-section A.) that 990 need IPv6 prefixes larger than /48 (e.g. /32). These customers 991 are assumed to be connected to several POPs of the access 992 network, so that this customer prefix will be visible in each 993 of these POPs. 994 * A pool (e.g. /24) for the LERs with direct customer connections 995 (e.g. dedicated line access) and without an additional 996 aggregation area between the customer and the LER. (These LERs 997 are mostly connected to a limited number of customers because 998 of the limited number of interfaces/ports.) 999 * A larger pool (e.g. 14*/24) for LERs (e.g. LER-BB) that serve 1000 a high number of customers that are normally connected via some 1001 kind of aggregation network (e.g. DSL customers behind a BB- 1002 RAR or Dial-In customers behind a RAR). 1003 * The IPv6 address delegation within each Pool (end customer 1004 delegation or also the aggregates that are dedicated to the 1005 LERs itself) should be chosen with an additional buffer zone of 1006 100% - 300% for future growth. I.e. 1 or 2 additional prefix 1007 bits should be reserved according to the expected future growth 1008 rate of the corresponding customer / the corresponding network 1009 device aggregate. 1011 5.2.2.1. Defining an IPv6 address allocation plan for customers of the 1012 Service Provider 1014 5.2.2.1.1. 'Big' customers 1016 SP's "big" customers receive their prefix from the /24 IPv6 address 1017 aggregate that has been reserved for their "big" customers. A 1018 customer is considered as "big" customer if it has a very complex 1019 network infrastructure and/or huge IPv6 address needs (e.g. because 1020 of very large customer numbers) and/or several uplinks to different 1021 POPs of the SP network. 1023 The assigned IPv6 address prefixes can have a prefix length in the 1024 range 32-48 and for each assignment a 100 or 300% future growing zone 1025 is marked as "reserved" for this customer. This means for instance 1026 that with a delegation of a /34 to a customer the corresponding /32 1027 prefix (which contains this /34) is reserved for the customers future 1028 usage. 1030 The prefixes for the "big" customers can be chosen from the 1031 corresponding "big customer" pool by either using an equidistant 1032 algorithm or using mechanisms similar to the Sparse Allocation 1033 Algorithm (SAA) [31]. 1035 5.2.2.1.2. 'Common' customers 1037 All customers that are not "big" customers are considered as "common" 1038 customers. They represent the majority of customers hence they 1039 receive a /48 out of the IPv6 customer address pool of the LER where 1040 they are directly connected or aggregated. 1042 Again a 100 - 300% future growing IPv6 address range is reserved for 1043 each customer, so that a "common" customer receives a /48 allocation 1044 but has a /47 or /46 reserved. 1046 In the network access scenarios where the customer is directly 1047 connected to the LER the customer prefix is directly taken out of the 1048 customer IPv6 address aggregate (e.g. /38) of the corresponding LER. 1050 In all other cases (e.g. the customer is attached to a RAR that is 1051 themselves aggregated to an AG or to a LER) at least 2 different 1052 approaches are possible. 1054 1) Mapping of Aggregation Network Hierarchy into Customer IPv6 1055 Addressing Schema. The aggregation network hierarchy could be mapped 1056 into the design of the customer prefix pools of each network level in 1057 order to achieve a maximal aggregation at the LER level as well as at 1058 the intermediate levels. (Example: Customer - /48, RAR - /38, AG - 1059 /32, LER-BB - /30). At each network level an adequate growing zone 1060 should be reserved. (Note: This approach requires of course some 1061 "fine tuning" of the addressing schema based on a very good knowledge 1062 of the Service Provider network topology including actual growing 1063 ranges and rates.) 1065 When the IPv6 customer address pool of a LER (or another device of 1066 the aggregation network - AG or RAR) is exhausted, the related LER 1067 (or AG or RAR) prefix is shortened by 1 or 2 bits (e.g. from /38 to 1068 /37 or /36) so that the originally reserved growing zone can be used 1069 for further IPv6 address allocations to customers. In the case where 1070 this growing zone is exhausted as well a new prefix range from the 1071 corresponding pool of the next higher hierarchy level can be 1072 requested. 1074 2) "Flat" Customer IPv6 Addressing Schema. The other option is to 1075 allocate all the customer prefixes directly out of the customer IPv6 1076 address pool of the LER where the customers are attached and 1077 aggregated and to ignore the intermediate aggregation network 1078 infrastructure. This approach leads of course to a higher amount of 1079 customer routes at LER and aggregation network level but takes a 1080 great amount of complexity out of the addressing schema. 1081 Nevertheless the aggregation of the customer prefixes to one prefix 1082 at LER level is realized as required above. 1084 (Note: The handling of (e.g. technically triggered) changes within 1085 the ISP access network is shortly discussed in section 5.2.3.5.) 1086 If the actual observed growing rates show that the reserved growing 1087 zones are not needed than these growing areas can be freed and used 1088 for assignments for prefix pools to other devices at the same level 1089 of the network hierarchy. 1091 5.2.2.2. Defining an IPv6 address allocation plan for the Service 1092 Provider Network Infrastructure 1094 For the IPv6 addressing of SPs own network infrastructure a /32 (or 1095 /40) from the "big" customers address pool can be chosen. 1097 This SP infrastructure prefix is used to code the network 1098 infrastructure of the SP by assigning a /48 to every POP/location and 1099 using for instance a /56 for coding the corresponding router within 1100 this POP. Each SP internal link behind a router interface could be 1101 coded using a /64 prefix. (Note: While it is suggested to choose a 1102 /48 for addressing the POP/location of the SP network it is left to 1103 each SP to decide what prefix length to assign to the routers and 1104 links within this POP.) 1106 The IIDs of the router interfaces may be generated by using EUI-64 or 1107 through plain manual configuration e.g. for coding additional network 1108 or operational information into the IID. 1110 It is assumed that again 100 - 300% growing zones for each level of 1111 network hierarchy and additional prefix bits may be assigned to POPs 1112 and/or routers if needed. 1114 Loopback interfaces of routers may be chosen from the first /64 of 1115 the /56 router prefix (in the example above). 1117 (Note: The /32 prefix that has been chosen for addressing SPs own 1118 IPv6 network infrastructure gives enough place to code additional 1119 functionalities like security levels or private and test 1120 infrastructure although such approaches haven't been considered in 1121 more detail for the above described SP until now.) 1123 Point-to-point links to customers (e.g. PPP links, dedicated line 1124 etc.) may be addressed using /126 prefixes out of the first /64 of 1125 the access routers that could be reserved for this reason. 1127 5.2.3. Additional Remarks 1129 5.2.3.1. ULA 1131 From the actual view point of SP there is no compelling reason why 1132 ULAs should be used from a SP. Look at section 2.2. 1134 ULAs could be used inside the SP network in order to have an 1135 additional "site-local scoped" IPv6 address for SPs own 1136 infrastructure for instance for network management reasons and maybe 1137 also in order to have an addressing schema that couldn't be reached 1138 from outside the SP network. 1140 In the case when ULAs are used it is possible to map the proposed 1141 internal IPv6 addressing of SPs own network infrastructure as 1142 described in 5.2.2.2 above directly to the ULA addressing schema by 1143 substituting the /48 POP prefix with a /48 ULA site prefix. 1145 5.2.3.2. Multicast 1147 IPv6 Multicast-related addressing issues are out of the scope of this 1148 document. 1150 5.2.3.3. POP Multi-homing 1152 POP (or better LER) Multi-homing of customers with the same SP can be 1153 realized within the proposed IPv6 addressing schema of the SP by 1154 assigning multiple LER-dependent prefixes to this customer (i.e. 1155 considering each customer location as a single-standing customer) or 1156 by choosing a customer prefix out of the pool of "big" customers. 1157 The second solution has the disadvantage that in every LER where the 1158 customer is attached this prefix will appear inside the IGP routing 1159 table requiring an explicit MPLS label. 1161 (Note: The described negative POP/LER Multi-homing effects to the 1162 addressing architecture in the SP access network are not tackled by 1163 implementing the Shim6 Site Multi-homing approach since this approach 1164 targets only on a mechanism for dealing with multiple prefixes in end 1165 systems -- the SP will nevertheless have unaggregated customer 1166 prefixes in its internal routing tables.) 1168 5.2.3.4. Changing Point of Network Attachement 1170 In the possible case that a customer has to change its point of 1171 network attachment to another POP/LER within the ISP access network 1172 two different approaches can be applied assuming that the customer 1173 uses PA addresses out of the SP aggregate: 1175 1.) The customer has to renumber its network with an adequate 1176 customer prefix out of the aggregate of the corresponding LER/RAR of 1177 its new network attachement. To minimise the administrative burden 1178 for the customer the prefix should be of the same size as the former. 1179 This conserves the IPv6 address aggregation within the SP network 1180 (and the MPLS label space) but adds additional burden to the 1181 customer. Hence this approach will most likely only be chosen in the 1182 case of 'small customers' with temporary addressing needs and/or 1183 prefix delegation with address auto-configuration. 1185 2.) The customer does not need to renumber its network and keeps its 1186 address aggregate. 1188 This apporach leads to additional more-specific routing entries 1189 within the IGP routing table of the LER and will hence consume 1190 additional MPLS labels - but it is totally transparent to the 1191 customer. Because this results in additional administrative effort 1192 and will stress the router resources (label space, memory) of the ISP 1193 this solution will only be offered to the most valuable customers of 1194 an ISP (like e.g. "big customers" or "enterprise customers"). 1196 Nevertheless the ISP has again to find a fair trade-off between 1197 customer renumbering and sub-optimal address aggregation (i.e. the 1198 generation of additional more-specific routing entries within the IGP 1199 and the waste of MPLS Label space). 1201 5.2.3.5. Restructuring of SP (access) network and Renumbering 1203 A technically triggered restructuring of the SP (access) network (for 1204 instance because of split of equipment or installation of new 1205 equipment) should not lead to a customer network renumbering. This 1206 challenge should be handled in advance by an intelligent network 1207 design and IPv6 address planing. 1209 In the worst case the customer network renumbering could be avoided 1210 through the implementation of more specific customer routes. (Note: 1211 Since this kind of network restructuring will mostly happen within 1212 the access network (at the level) below the LER, the LER aggregation 1213 level will not be harmed and the more-specific routes will not 1214 consume additional MPLS label space.) 1216 5.2.3.6. Extensions needed for the later IPv6 migration phases 1218 The proposed IPv6 addressing schema for a SP needs some slight 1219 enhancements / modifications for the later phases of IPv6 1220 integration, for instance in the case when the whole MPLS backbone 1221 infrastructure (LDP, IGP etc.) is realized over IPv6 transport an 1222 addressing of the LSRs is needed. Other changes may be necessary as 1223 well but should not be explained at this point. 1225 6. IANA Considerations 1227 There are no extra IANA consideration for this document. 1229 7. Security Considerations 1231 This IPv6 addressing document does not have any direct impact on 1232 Internet infrastructure security. 1234 8. Acknowledgements 1236 Constructive feedback and contributions have been received from Marla 1237 Azinger, Stig Venaas, Pekka Savola, John Spence, Patrick Grossetete, 1238 Carlos Garcia Braschi, Brian Carpenter, Mark Smith and Ginny Listman. 1240 9. References 1242 9.1. Normative References 1244 9.2. Informative References 1246 [1] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. 1247 Lear, "Address Allocation for Private Internets", BCP 5, 1248 RFC 1918, February 1996. 1250 [2] Thomson, S. and T. Narten, "IPv6 Stateless Address 1251 Autoconfiguration", RFC 2462, December 1998. 1253 [3] Hinden, R., Fink, R., and J. Postel, "IPv6 Testing Address 1254 Allocation", RFC 2471, December 1998. 1256 [4] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast 1257 Addresses", RFC 2526, March 1999. 1259 [5] Retana, A., White, R., Fuller, V., and D. McPherson, "Using 31- 1260 Bit Prefixes on IPv4 Point-to-Point Links", RFC 3021, 1261 December 2000. 1263 [6] Narten, T. and R. Draves, "Privacy Extensions for Stateless 1264 Address Autoconfiguration in IPv6", RFC 3041, January 2001. 1266 [7] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 1267 Tunnel Broker", RFC 3053, January 2001. 1269 [8] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via 1270 IPv4 Clouds", RFC 3056, February 2001. 1272 [9] IAB and IESG, "IAB/IESG Recommendations on IPv6 Address 1273 Allocations to Sites", RFC 3177, September 2001. 1275 [10] Durand, A. and C. Huitema, "The H-Density Ratio for Address 1276 Assignment Efficiency An Update on the H ratio", RFC 3194, 1277 November 2001. 1279 [11] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. 1280 Carney, "Dynamic Host Configuration Protocol for IPv6 1281 (DHCPv6)", RFC 3315, July 2003. 1283 [12] Draves, R., "Default Address Selection for Internet Protocol 1284 version 6 (IPv6)", RFC 3484, February 2003. 1286 [13] Blanchet, M., "A Flexible Method for Managing the Assignment of 1287 Bits of an IPv6 Address Block", RFC 3531, April 2003. 1289 [14] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global Unicast 1290 Address Format", RFC 3587, August 2003. 1292 [15] Savola, P., "Use of /127 Prefix Length Between Routers 1293 Considered Harmful", RFC 3627, September 2003. 1295 [16] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host 1296 Configuration Protocol (DHCP) version 6", RFC 3633, 1297 December 2003. 1299 [17] Fink, R. and R. Hinden, "6bone (IPv6 Testing Address 1300 Allocation) Phaseout", RFC 3701, March 2004. 1302 [18] Droms, R., "Stateless Dynamic Host Configuration Protocol 1303 (DHCP) Service for IPv6", RFC 3736, April 2004. 1305 [19] Huitema, C. and B. Carpenter, "Deprecating Site Local 1306 Addresses", RFC 3879, September 2004. 1308 [20] Savola, P. and B. Haberman, "Embedding the Rendezvous Point 1309 (RP) Address in an IPv6 Multicast Address", RFC 3956, 1310 November 2004. 1312 [21] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 1313 Neighbor Discovery (SEND)", RFC 3971, March 2005. 1315 [22] Aura, T., "Cryptographically Generated Addresses (CGA)", 1316 RFC 3972, March 2005. 1318 [23] Baker, F., Lear, E., and R. Droms, "Procedures for Renumbering 1319 an IPv6 Network without a Flag Day", RFC 4192, September 2005. 1321 [24] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1322 Addresses", RFC 4193, October 2005. 1324 [25] Templin, F., Gleeson, T., Talwar, M., and D. Thaler, "Intra- 1325 Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 4214, 1326 October 2005. 1328 [26] Hinden, R. and S. Deering, "IP Version 6 Addressing 1329 Architecture", RFC 4291, February 2006. 1331 [27] Chown, T., Venaas, S., and C. Strauf, "Dynamic Host 1332 Configuration Protocol (DHCP): IPv4 and IPv6 Dual-Stack 1333 Issues", RFC 4477, May 2006. 1335 [28] ARIN, "http://www.arin.net/policy/nrpm.html#six54". 1337 [29] De Clerq, J., Ooms, D., Prevost, S., and F. Le Faucheur, 1338 "Connecting IPv6 Islands over IPv4 MPLS using IPv6 Provider 1339 Edge Routers (6PE) (draft-ooms-v6ops-bgp-tunnel-06.txt)", 1340 June 2006. 1342 [30] Chown, T., "IPv6 Implications for TCP/UDP Port Scanning 1343 (draft-ietf-v6ops-scanning-implications-00.txt)", June 2006. 1345 [31] APNIC, ARIN, RIPE NCC, "IPv6 Address Allocation and Assignment 1346 Policy (www.ripe.net/ripe/docs/ipv6policy.html)", January 2003. 1348 [32] Chown, T., Thompson, M., Ford, A., and S. Venaas, "Things to 1349 think about when Renumbering an IPv6 network 1350 (draft-chown-v6ops-renumber-thinkabout-05.txt)", March 2007. 1352 [33] "List of Internet-Drafts relevant to the Multi6-WG 1353 (http://ops.ietf.org/multi6/draft-list.html )". 1355 [34] Lear, E., "Things MULTI6 Developers should think about 1356 (draft-ietf-multi6-things-to-think-about-01)", January 2005. 1358 [35] Nordmark, E. and T. Li, "Threats relating to IPv6 multihoming 1359 solutions (draft-ietf-multi6-multihoming-threats-03)", 1360 January 2005. 1362 Authors' Addresses 1364 Gunter Van de Velde 1365 Cisco Systems 1366 De Kleetlaan 6a 1367 Diegem 1831 1368 Belgium 1370 Phone: +32 2704 5473 1371 Email: gunter@cisco.com 1373 Ciprian Popoviciu 1374 Cisco Systems 1375 7025-6 Kit Creek Road 1376 Research Triangle Park, North Carolina PO Box 14987 1377 USA 1379 Phone: +1 919 392-3723 1380 Email: cpopovic@cisco.com 1382 Tim Chown 1383 University of Southampton 1384 Highfield 1385 Southampton, SO17 1BJ 1386 United Kingdom 1388 Phone: +44 23 8059 3257 1389 Email: tjc@ecs.soton.ac.uk 1391 Olaf Bonness 1392 T-Systems Enterprise Services GmbH 1393 Goslarer Ufer 35 1394 Berlin, 10589 1395 Germany 1397 Phone: +49 30 3497 3124 1398 Email: Olaf.Bonness@t-systems.com 1399 Christian Hahn 1400 T-Systems Enterprise Services GmbH 1401 Goslarer Ufer 35 1402 Berlin, 10589 1403 Germany 1405 Phone: +49 30 3497 3164 1406 Email: HahnC@t-systems.com 1408 Full Copyright Statement 1410 Copyright (C) The IETF Trust (2007). 1412 This document is subject to the rights, licenses and restrictions 1413 contained in BCP 78, and except as set forth therein, the authors 1414 retain all their rights. 1416 This document and the information contained herein are provided on an 1417 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1418 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1419 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1420 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1421 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1422 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1424 Intellectual Property 1426 The IETF takes no position regarding the validity or scope of any 1427 Intellectual Property Rights or other rights that might be claimed to 1428 pertain to the implementation or use of the technology described in 1429 this document or the extent to which any license under such rights 1430 might or might not be available; nor does it represent that it has 1431 made any independent effort to identify any such rights. Information 1432 on the procedures with respect to rights in RFC documents can be 1433 found in BCP 78 and BCP 79. 1435 Copies of IPR disclosures made to the IETF Secretariat and any 1436 assurances of licenses to be made available, or the result of an 1437 attempt made to obtain a general license or permission for the use of 1438 such proprietary rights by implementers or users of this 1439 specification can be obtained from the IETF on-line IPR repository at 1440 http://www.ietf.org/ipr. 1442 The IETF invites any interested party to bring to its attention any 1443 copyrights, patents or patent applications, or other proprietary 1444 rights that may cover technology that may be required to implement 1445 this standard. Please address the information to the IETF at 1446 ietf-ipr@ietf.org. 1448 Acknowledgment 1450 Funding for the RFC Editor function is provided by the IETF 1451 Administrative Support Activity (IASA).