idnits 2.17.1 draft-ietf-v6ops-addcon-02.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 on line 1364. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1341. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1348. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1354. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 RFC 3978 Section 5.4 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 (October 23, 2006) is 6388 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 467 -- 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. '8') (Obsoleted by RFC 6177) -- Obsolete informational reference (is this intentional?): RFC 3315 (ref. '10') (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3484 (ref. '11') (Obsoleted by RFC 6724) -- Obsolete informational reference (is this intentional?): RFC 3627 (ref. '14') (Obsoleted by RFC 6547) -- Obsolete informational reference (is this intentional?): RFC 3633 (ref. '15') (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3736 (ref. '17') (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 4214 (ref. '24') (Obsoleted by RFC 5214) == Outdated reference: A later version (-04) exists of draft-ietf-v6ops-scanning-implications-00 Summary: 3 errors (**), 0 flaws (~~), 5 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: April 26, 2007 Cisco Systems 5 T. Chown 6 University of Southampton 7 O. Bonness 8 C. Hahn 9 T-Systems Enterprise Services GmbH 10 October 23, 2006 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 April 26, 2007. 40 Copyright Notice 42 Copyright (C) The Internet Society (2006). 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 draft aims to provide the information and recommendations 53 relevant to planning the addressing aspects of IPv6 deployments. The 54 draft also provides IPv6 addressing case studies for both an 55 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 . . . . . . . . 13 81 4.4. Manual/Dynamic Assignment Option . . . . . . . . . . . . . 14 82 5. Case Studies . . . . . . . . . . . . . . . . . . . . . . . . . 14 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 . . . . . . . . . . . . . . . . . 16 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 . . . . . . . . . . . . . . . . . . . . . 26 95 7. Security Considerations . . . . . . . . . . . . . . . . . . . 26 96 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 97 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 98 9.1. Normative References . . . . . . . . . . . . . . . . . . . 27 99 9.2. Informative References . . . . . . . . . . . . . . . . . . 27 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 101 Intellectual Property and Copyright Statements . . . . . . . . . . 32 103 1. Introduction 105 The Internet Protocol Version 6 (IPv6) Addressing Architecture [25] 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 [13] ('globals') and Unique Local IPv6 Addresses [23] 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 [16]. 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 'Subnet Prefix' 125 (address usage within a subnet). Thus the document includes a 126 discussion of aspects of address assignment to nodes and interfaces 127 in an IPv6 network. Finally the document provides two examples of 128 successfully deployed address plans in a service provider (ISP) and 129 an enterprise network. 131 Parts of this document highlight the differences that an experienced 132 IPv4 network designer should consider when planning an IPv6 133 deployment, for example: 135 o IPv6 devices will more likely be multi-addressed in comparison 136 with their IPv4 counterparts 137 o The practically unlimited size of an IPv6 subnet (2^64 bits) 138 reduces the requirement to size subnets to device counts for the 139 purposes of (IPv4) address conservation 140 o Even though there is no broadcast for the IPv6 protocol, there is 141 still need to consider the number of devices in a given subnet due 142 to traffic storm and level of traffic generated by hosts 143 o The implications of the vastly increased subnet size on the threat 144 of address-based host scanning and other scanning techniques, as 145 discussed in [27]. 147 We do not discuss here how a site or ISP should proceed with 148 acquiring its globally routable IPv6 address prefix. However, one 149 should note that IPv6 networks currently receive their global unicast 150 address allocation from their 'upstream' provider, which may be 151 another ISP, a Local Internet Registry (LIR) or a Regional Internet 152 Registry (RIR). In each case the prefix received is provider 153 assigned (PA). Until very recently there has been no provider 154 independent (PI) address space for IPv6 generally available. However 155 ARIN is now piloting PI address space allocations, subject to 156 customers meeting certain requirements. 158 We do not discuss PI policy here. The observations and 159 recommendations of this text are largely independent of the PA or PI 160 nature of the address block being used. At this time we assume that 161 most commonly an IPv6 network which changes provider will need to 162 undergo a renumbering process, as described in [22]. A separate 163 document [29] makes recommendations to ease the IPv6 renumbering 164 process. 166 This document does not discuss implementation aspects related to the 167 transition between the ULA addresses and the now obsoleted site-local 168 addresses. Most implementations know about Site-local addresses even 169 though they are deprecated, and do not know about ULAs - even though 170 they represent current specification. As result transitioning 171 between these types of addresses may cause difficulties. 173 2. Network Level Addressing Design Considerations 175 This section discusses the kind of IPv6 addresses used at the network 176 level for the IPv6 infrastructure. The kind of addresses that can be 177 considered are Global Unique Addresses and ULAs. We also comment 178 here on the recently deprecated 6bone address space. 180 2.1. Global Unique Addresses 182 The most commonly used unicast addresses will be Global Unique 183 Addresses ('globals'). No significant considerations are necessary 184 if the organization has an address space assignment and a single 185 prefix is deployed through a single upstream provider. 187 However, a multihomed site may deploy addresses from two or more 188 Service Provider assigned IPv6 address ranges. Here, the network 189 Administrator must have awareness on where and how these ranges are 190 used on the multihomed infrastructure environment. The nature of the 191 usage of multiple prefixes may depend on the reason for multihoming 192 (e.g. resilience failover, load balancing, policy-based routing, or 193 multihoming during an IPv6 renumbering event). IPv6 introduces 194 improved support for multi-addressed hosts through the IPv6 default 195 address selection methods described in RFC3484 [11]. A multihomed 196 host may thus have two addresses, one per prefix (provider), and 197 select source and destination addresses to use as described in that 198 RFC. 200 2.2. Unique Local IPv6 Addresses 202 ULAs have replaced the originally conceived Site Local addresses in 203 the IPv6 addressing architecture, for reasons described in [18]. 204 ULAs improve on site locals by offering a high probability of the 205 global uniqueness of the prefix used, which can be beneficial in the 206 case of (deliberate or accidental) leakage, or where networks are 207 merged. ULAs are akin to the private address space [1] assigned for 208 IPv4 networks, except that in IPv6 networks we may expect to see ULAs 209 used alongside global addresses, with ULAs used internally and 210 globals used externally. Thus use of ULAs does not imply use of NAT 211 for IPv6. 213 The ULA address range allows network administrators to deploy IPv6 214 addresses on their network without asking for a globally unique 215 registered IPv6 address range. A ULA prefix is 48 bits, i.e. a /48, 216 the same as the currently recommended allocation for a site from the 217 globally routable IPv6 address space [8]. 219 ULAs provide the means to deploy a fixed addressing scheme that is 220 not affected by a change in service provider and the corresponding PA 221 global addresses. Internal operation of the network is thus 222 unaffected during renumbering events. Nevertheless, this type of 223 address must be used with caution. 225 A site using ULAs may or may not also deploy globals. In an isolated 226 network ULAs may be deployed on their own. In a connected network, 227 that also deploys global addresses, both may be deployed, such that 228 hosts become multiaddressed (one global and one ULA address) and the 229 IPv6 default address selection algorithm will pick the appropriate 230 source and destination addresses to use, e.g. ULAs will be selected 231 where both the source and destination hosts have ULA addresses. 232 Because a ULA and a global site prefix are both /48 length, an 233 administrator can choose to use the same subnetting (and host 234 addressing) plan for both prefixes. 236 As an example of the problems ULAs may cause, when using IPv6 237 multicast within the network, the IPv6 default address selection 238 algorithm prefers the ULA address as the source address for the IPv6 239 multicast streams. This is NOT a valid option when sending an IPv6 240 multicast stream to the IPv6 Internet for two reasons. For one, 241 these addresses are not globally routable so RPF checks for such 242 traffic will fail outside the internal network. The other reason is 243 that the traffic will likely not cross the network boundary due to 244 multicast domain control and perimeter security policies. 246 In principle ULAs allow easier network mergers than RFC1918 addresses 247 do for IPv4 because ULA prefixes have a high probability of 248 uniqueness, if the prefix is chosen as described in the RFC. 250 The usage of ULAs should be carefully considered even when not 251 attached to the IPv6 Internet due to the potential for added 252 complexity when connecting to the Internet at some point in the 253 future. 255 2.3. 6Bone Address Space 257 The 6Bone address space was used before the RIRs started to 258 distribute 'production' IPv6 prefixes. The 6Bone prefixes have a 259 common first 16 bits in the IPv6 Prefix of 3FFE::/16. This address 260 range is deprecated as of 6th June 2006 [16] and should be avoided on 261 any new IPv6 network deployments. Sites using 6bone address space 262 should renumber to production address space using procedures as 263 defined in [22]. 265 2.4. Network Level Design Considerations 267 IPv6 provides network administrators with a significantly larger 268 address space, enabling them to be very creative in how they can 269 define logical and practical address plans. The subnetting of 270 assigned prefixes can be done based on various logical schemes that 271 involve factors such as: 272 o Geographical Boundaries - by assigning a common prefix to all 273 subnets within a geographical area 274 o Organizational Boundaries - by assigning a common prefix to an 275 entire organization or group within a corporate infrastructure 276 o Service Type - by reserving certain prefixes for predefined 277 services such as: VoIP, Content Distribution, wireless services, 278 Internet Access, etc 279 Such logical addressing plans have the potential to simplify network 280 operations and service offerings, and to simplify network management 281 and troubleshooting. A very large network would also have no need to 282 consider using private address space for its infrastructure devices, 283 simplifying network management. 285 The network designer must however keep in mind several factors when 286 developing these new addressing schemes: 287 o Prefix Aggregation - The larger IPv6 addresses can lead to larger 288 routing tables unless network designers are actively pursuing 289 aggregation. While prefix aggregation will be enforced by the 290 service provider, it is beneficial for the individual 291 organizations to observe the same principles in their network 292 design process 294 o Network growth - The allocation mechanism for flexible growth of a 295 network prefix, documented in RFC3531 [12] can be used to allow 296 the network infrastructure to grow and be numbered in a way that 297 is likely to preserve aggregation (the plan leaves 'holes' for 298 growth) 299 o ULA usage in large networks - Networks which have a large number 300 of 'sites' that each deploy a ULA prefix which will by default be 301 a 'random' /48 under fc00::/7 will have no aggregation of those 302 prefixes. Thus the end result may be cumbersome because the 303 network will have large amounts of non-aggregated ULA prefixes. 304 However, there is no rule to disallow large networks to use a 305 single ULA for all 'sites', as a ULA still provides 16 bits for 306 subnetting to be used internally 308 2.4.1. Sizing the Network Allocation 310 We do not discuss here how a network designer sizes their application 311 for address space. By default a site will receive a /48 prefix [8]. 312 The default provider allocation via the RIRs is currently a /32 [28]. 313 These allocations are indicators for a first allocation for a 314 network. Different sizes may be obtained based on the anticipated 315 address usage [28]. There are examples of allocations as large as 316 /19 having been made from RIRs to providers at the time of writing. 318 2.4.2. Address Space Conservation 320 Despite the large IPv6 address space which enables easier subnetting, 321 it still is important to ensure an efficient use of this resource. 322 Some addressing schemes, while facilitating aggregation and 323 management, could lead to significant numbers of addresses being 324 unused. Address conservation requirements are less stringent in IPv6 325 but they should still be observed. 327 The proposed HD [9] value for IPv6 is 0.94 compared to the current 328 value of 0.96 for IPv4. Note that for IPv6 HD is calculated for 329 sites (i.e. on a basis of /48), instead of based on addresses like 330 with IPv4. 332 3. Subnet Prefix Considerations 334 This section analyzes the considerations applied to define the subnet 335 prefix of the IPv6 addresses. The boundaries of the subnet prefix 336 allocation are specified in RFC4291 [25]. In this document we 337 analyze their practical implications. Based on RFC4291 [25] it is 338 legal for any IPv6 unicast address starting with binary address '000' 339 to have a subnet prefix larger than, smaller than or of equal to 64 340 bits. Each of these three options is discussed in this document. 342 3.1. Considerations for subnet prefixes shorter then /64 344 An allocation of a prefix shorter then 64 bits to a node or interface 345 is bad practice. The shortest subnet prefix that could theoretically 346 be assigned to an interface or node is limited by the size of the 347 network prefix allocated to the organization. 349 A possible reason for choosing the subnet prefix for an interface 350 shorter then /64 is that it would allow more nodes to be attached to 351 that interface compared to a prescribed length of 64 bits. This 352 however is unnecessary considering that 2^64 provides plenty of node 353 addresses for a well designed IPv6 network. Layer two technologies 354 are unlikely to support such large numbers of nodes within a single 355 link (e.g. Ethernet limited to 48-bits of hosts) 357 The subnet prefix assignments can be made either by manual 358 configuration, by a stateful Host Configuration Protocol [10] or by a 359 stateful prefix delegation mechanism [15]. 361 3.2. Considerations for /64 prefixes 363 Based on RFC3177 [8], 64 bits is the prescribed subnet prefix length 364 to allocate to interfaces and nodes. 366 When using a /64 subnet length, the address assignment for these 367 addresses can be made either by manual configuration, by a stateful 368 Host Configuration Protocol [10] [17] or by stateless 369 autoconfiguration [2]. 371 Note that RFC3177 strongly prescribes 64 bit subnets for general 372 usage, and that stateless autoconfiguration option is only defined 373 for 64 bit subnets. 375 3.3. Considerations for subnet prefixes longer then /64 377 Address space conservation is the main motivation for using a subnet 378 prefix length longer than 64 bits. 380 The address assignment can be made either by manual configuration or 381 by a stateful Host Configuration Protocol [10]. 383 When assigning a subnet prefix of more then 80 bits, according to 384 RFC4291 [25] "u" and "g" bits (respectively the 81st and 82nd bit) 385 need to be taken into consideration and should be set correctly. In 386 currently implemented IPv6 protocol stacks, the relevance of the "u" 387 (universal/local) bit and "g" (the individual/group) bit are marginal 388 and typically will not show an issue when configured wrongly, however 389 future implementations may turn out differently. 391 When using subnet lengths longer then 64 bits, it is important to 392 avoid selecting addresses that may have a predefined use and could 393 confuse IPv6 protocol stacks. The alternate usage may not be a 394 simple unicast address in all cases. The following points should be 395 considered when selecting a subnet length longer then 64 bits. 397 3.3.1. Anycast addresses 399 3.3.1.1. Subnet Router Anycast Address 401 RFC4291 [25] provides a definition for the required Subnet Router 402 Anycast Address as follows: 404 | n bits | 128-n bits | 405 +--------------------------------------------+----------------+ 406 | subnet prefix | 00000000000000 | 407 +--------------------------------------------+----------------+ 409 It is recommended to avoid allocating this IPv6 address to a device 410 which is not a router. No additional dependencies for the subnet 411 prefix while the EUI-64 and an IID dependencies will be discussed 412 later in this document. 414 3.3.1.2. Reserved IPv6 Subnet Anycast Addresses 416 RFC2526 [4] stated that within each subnet, the highest 128 interface 417 identifier values are reserved for assignment as subnet anycast 418 addresses. 420 The construction of a reserved subnet anycast address depends on the 421 type of IPv6 addresses used within the subnet, as indicated by the 422 format prefix in the addresses. 424 The first type of Subnet Anycast addresses have been defined as 425 follows for EUI-64 format: 427 | 64 bits | 57 bits | 7 bits | 428 +------------------------------+------------------+------------+ 429 | subnet prefix | 1111110111...111 | anycast ID | 430 +------------------------------+------------------+------------+ 432 The anycast address structure implies that it is important to avoid 433 creating a subnet prefix where the bits 65 to 121 are defined as 434 "1111110111...111" (57 bits in total) so that confusion can be 435 avoided. 437 For other IPv6 address types (that is, with format prefixes other 438 than those listed above), the interface identifier is not in EUI-64 439 format and may be other than 64 bits in length; these reserved subnet 440 anycast addresses for such address types are constructed as follows: 442 | n bits | 121-n bits | 7 bits | 443 +------------------------------+------------------+------------+ 444 | subnet prefix | 1111111...111111 | anycast ID | 445 +------------------------------+------------------+------------+ 446 | interface identifier field | 448 In the case discussed above there is no additional dependency for the 449 subnet prefix with the exception of the EUI-64 and an IID dependency. 450 These will be discussed later in this document. 452 3.3.2. Addresses used by Embedded-RP (RFC3956) 454 Embedded-RP [19] reflects the concept of integrating the Rendezvous 455 Point (RP) IPv6 address into the IPv6 multicast group address. Due 456 to this embedding and the fact that the length of the IPv6 address 457 AND the IPv6 multicast address are 128 bits, it is not possible to 458 have the complete IPv6 address of the multicast RP embedded as such. 460 This resulted in a restriction of 15 possible RP-addresses per prefix 461 that can be used with embedded-RP. The space assigned for the 462 embedded-RP is based on the 4 low order bits, while the remainder of 463 the Interface ID is set to all '0'. 465 [IPv6-prefix (64 bits)][60 bits all '0'][RIID] 467 Where: [RIID] = 4 bit. 469 This format implies that when selecting subnet prefixes longer then 470 64, and the bits beyond the 64th one are none-zero, the subnet can 471 not use embedded-RP. 473 In addition it is discouraged to assign a matching embedded-RP IPv6 474 address to a device that is not a real Multicast Rendezvous Point. 476 3.3.3. ISATAP addresses 478 ISATAP [24] is an automatic tunneling protocol used to provide IPv6 479 connectivity over an IPv4 campus or enterprise environment. In order 480 to leverage the underlying IPv4 infrastructure, the IPv6 addresses 481 are constructed in a special format. 483 An IPv6 ISATAP address has the IPv4 address embedded, based on a 484 predefined structure policy that identifies them as an ISATAP 485 address. 487 [IPv6 Prefix (64 bits)][0000:5EFE][IPv4 address] 489 When using subnet prefix length longer then 64 bits it is recommended 490 that that the portion of the IPv6 prefix from bit 65 to the end of 491 the subnet prefix does not match with the well-known ISATAP [0000: 492 5EFE] address portion. 494 In its actual definition there is no multicast support on ISATAP 496 3.3.4. /126 addresses 498 The 126 bit subnet prefixes are typically used for point-to-point 499 links similar to the RFC3021 [5] recommendations for IPv4. The usage 500 of this subnet address length does not lead to any additional 501 considerations other than the ones discussed earlier in this section, 502 particularly those related to the "u" and "g" bits. 504 3.3.5. /127 addresses 506 The usage of the /127 addresses is not valid and should be strongly 507 discouraged as documented in RFC3627 [14]. 509 3.3.6. /128 addresses 511 The 128 bit address prefix may be used in those situations where we 512 know that one, and only one address is sufficient. Example usage 513 would be the off-link loopback address of a network device. 515 When choosing a 128 bit prefix, it is recommended to take the "u" and 516 "g" bits into consideration and to make sure that there is no overlap 517 with either the following well-known addresses: 518 o Subnet Router Anycast Address 519 o Reserved Subnet Anycast Address 520 o Addresses used by Embedded-RP 521 o ISATAP Addresses 523 4. Allocation of the IID of an IPv6 Address 525 In order to have a complete IPv6 address, an interface must be 526 associated a prefix and an Interface Identifier (IID). Section 3 of 527 this document analyzed the prefix selection considerations. This 528 section discusses the elements that should be considered when 529 assigning the IID portion of the IPv6 address. 531 There are various ways to allocate an IPv6 address to a device or 532 interface. The option with the least amount of caveats for the 533 network administrator is that of EUI-64 [2] based addresses. For the 534 manual or dynamic options, the overlap with well known IPv6 addresses 535 should be avoided. 537 4.1. Automatic EUI-64 Format Option 539 When using this method the network administrator has to allocate a 540 valid 64 bit subnet prefix. The EUI-64 [2] allocation procedure can 541 from that moment onward assign the remaining 64 IID bits in a 542 stateless manner. All the considerations for selecting a valid IID 543 have been incorporated in the EUI-64 methodology. 545 4.2. Using Privacy Extensions 547 The main purpose of IIDs generated based on RFC3041 [6] is to provide 548 privacy to the entity using this address. While there are no 549 particular constraints in the usage of these addresses as defined in 550 [6] there are some implications to be aware of when using privacy 551 addresses as documented in section 4 of RFC3041 [6]: 552 o The privacy extension algorithm may complicate flexibility in 553 future transport protocols 554 o These addresses may add complexity to the operational management 555 and troubleshooting of the infrastructure (i.e. which address 556 belongs to which real host) 557 o A reverse DNS lookup check may be broken when using privacy 558 extensions 560 4.3. Cryptographically Generated IPv6 Addresses 562 Cryptographically Generated Addresses (CGAs) are based upon RFC3972 563 [21] and provide a method for binding a public signature key to an 564 IPv6 address in the Secure Neighbor Discovery (SEND) protocol [20]. 566 The basic idea is to generate the interface identifier (i.e. the 567 rightmost 64 bits) of the IPv6 address by computing a cryptographic 568 hash of the public key. The resulting IPv6 address is called a 569 cryptographically generated address (CGA). The corresponding private 570 key can then be used to sign messages sent from that address. 572 Implications to be aware of when using CGA addresses are found in 573 section 7 of RFC3972 [21]: 574 o When using CGA addresses the values of the "u" and "g" bits are 575 ignored however it does not add any security or implementation 576 implications 577 o There is no mechanism for proving that an address is not a CGA 578 o When it is discovered that a node has been compromised, a new 579 signature key and a new CGA should be generated 581 Due to the fact that CGA generated addresses are almost 582 indistinguishable from a privacy address and has similar properties 583 for many purposes, the same considerations as with privacy addresses 584 are also valid for CGA generated addresses. 586 4.4. Manual/Dynamic Assignment Option 588 This section discusses those IID allocations that are not implemented 589 through stateless address configuration (Section 4.1). They are 590 applicable regardless of the prefix length used on the link. It is 591 out of scope for this section to discuss the various assignment 592 methods (e.g. manual configuration, DHCPv6, etc). 594 In this situation the actual allocation is done by human intervention 595 and consideration needs to be given to the complete IPv6 address so 596 that it does not result in overlaps with any of the well known IPv6 597 addresses: 598 o Subnet Router Anycast Address 599 o Reserved Subnet Anycast Address 600 o Addresses used by Embedded-RP 601 o ISATAP Addresses 603 When using an address assigned by human intervention it is 604 recommended to choose IPv6 addresses which are not obvious to guess 605 and/or avoid any IPv6 addresses that embed IPv4 addresses used in the 606 current infrastructure. Following these two recommendations will 607 make it more difficult for malicious third parties to guess targets 608 for attack, and thus reduce security threats to a certain extent. 610 5. Case Studies 611 5.1. Enterprise Considerations 613 In this section we consider a case study of a campus network that is 614 deploying IPv6 in parallel with existing IPv4 protocols in a dual- 615 stack environment. The specific example is the University of 616 Southampton (UK), focusing on a large department within that network. 617 The deployment currently spans around 1,000 hosts and over 1,500 618 users. 620 5.1.1. Obtaining general IPv6 network prefixes 622 In the case of a campus network, the site will typically take its 623 connectivity from its National Research and Education Network (NREN). 624 Southampton connects to JANET, the UK academic network, via its local 625 regional network LeNSE. JANET currently has a /32 allocation from 626 RIPE of 2001:630::/32. The current recommended practice is for sites 627 to receive a /48 allocation, and on this basis Southampton has 628 received such a prefix for its own use, specifically 2001:630: 629 d0::/48. The regional network also uses its own allocation from the 630 NREN provider. 632 No ULA addressing is used on site. The campus is not multihomed 633 (JANET is the sole provider), nor does it expect to change service 634 provider, and thus does not plan to use ULAs for the (perceived) 635 benefit of easing network renumbering. Indeed, the campus has 636 renumbered following the aforementioned renumbering procedure [22] on 637 two occasions, and this has proven adequate (with provisos documented 638 in [29]. We also do not see any need to deploy ULAs for in or out of 639 band network management; there are enough IPv6 prefixes available in 640 the site allocation for the infrastructure. In some cases, use of 641 private IP address space in IPv4 creates problems, so we believe that 642 the availability of ample global IPv6 address space for 643 infrastructure may be a benefit for many sites. 645 No 6bone addressing is used on site any more. We note that since the 646 6bone phaseout of June 2006 [16] most transit ISPs have begun 647 filtering attempted use of such prefixes. 649 Southampton does participate in global and organization scope IPv6 650 multicast networks. Multicast address allocations are not discussed 651 here as they are not in scope for the document. We note that IPv6 652 has advantages for multicast group address allocation. In IPv4 a 653 site needs to use techniques like GLOP to pick a globally unique 654 multicast group to use. This is problematic if the site does not use 655 BGP and have an ASN. In IPv6 unicast-prefix-based IPv6 multicast 656 addresses empower a site to pick a globally unique group address 657 based on its unicast own site or link prefix. Embedded RP is also in 658 use, is seen as a potential advantage for IPv6 and multicast, and has 659 been tested successfully across providers between sites (including 660 paths to/from the US and UK). 662 5.1.2. Forming an address (subnet) allocation plan 664 The campus has a /16 prefix for IPv4 use; in principle 256 subnets of 665 256 addresses. In reality the subnetting is muddier, because of 666 concerns of IPv4 address conservation; subnets are sized to the hosts 667 within them, e.g. a /26 IPv4 prefix is used if a subnet has 35 hosts 668 in it. While this is efficient, it increases management burden when 669 physical deployments change, and IPv4 subnets require resizing (up or 670 down), even with DHCP in use. 672 The /48 IPv6 prefix is considerably larger than the IPv4 allocation 673 already in place at the site. It is loosely equivalent to a 'Class 674 A' IPv4 prefix in that it has 2^16 (over 65,000) subnets, but has an 675 effectively unlimited subnet address size (2^64) compared to 256 in 676 the IPv4 equivalent. The increased subnet size means that /64 IPv6 677 prefixes can be used on all subnets, without any requirement to 678 resize them at a later date. The increased subnet volume allows 679 subnets to be allocated more generously to schools and departments in 680 the campus. While address conservation is still important, it is no 681 longer an impediment on network management. Rather, address (subnet) 682 allocation is more about embracing the available address space and 683 planning for future expansion. 685 In a dual-stack network, we chose to deploy our IP subnets 686 congruently for IPv4 and IPv6. This is because the systems are still 687 in the same administrative domains and the same geography. We do not 688 expect to have IPv6-only subnets in production use for a while yet, 689 outside our test beds and our early Mobile IPv6 trials. With 690 congruent addressing, our firewall policies are also aligned for IPv4 691 and IPv6 traffic at our site border. 693 The subnet allocation plan required a division of the address space 694 per school or department. Here a /56 was allocated to the school 695 level of the university; there are around 30 schools currently. A 696 /56 of IPv6 address space equates to 256 /64 size subnet allocations. 697 Further /56 allocations were made for central IT infrastructure, for 698 the network infrastructure and the server side systems. 700 5.1.3. Other considerations 702 The network uses a Demilitarized Zone (DMZ) topology for some level 703 of protection of 'public' systems. Again, this topology is congruent 704 with the IPv4 network. 706 There are no specific transition methods deployed internally to the 707 campus; everything is using the conventional dual-stack approach. 708 There is no use of ISATAP [24] for example. 710 For the Mobile IPv6 early trails, we have allocated one prefix for 711 Home Agent (HA) use. We have not yet considered in detail how Mobile 712 IPv6 usage may grow, and whether more or even every subnet will 713 require HA support. 715 The university operates a tunnel broker [7] service on behalf of 716 UKERNA for JANET sites. This uses separate address space from JANET, 717 not our university site allocation. 719 5.1.4. Node configuration considerations 721 We currently use stateless autoconfiguration on most subnets for IPv6 722 hosts. There is no DHCPv6 service deployed yet, beyond tests of 723 early code releases. We plan to deploy DHCPv6 for address assignment 724 when robust client and server code is available (at the time of 725 writing the potential for this looks good, e.g. via the ISC 726 implementation). We also are seeking a common integrated DHCP/DNS 727 management platform, even if the servers themselves are not co- 728 located, including integrated DHCPv4 and DHCPv6 server configuration, 729 as discussed in [26]. Currently we add client statelessly 730 autoconfigured addresses to the DNS manually, though dynamic DNS is 731 an option. Our administrators would prefer the use of DHCP because 732 they believe it gives them more management control. 734 Regarding the implications of the larger IPv6 subnet address space on 735 scanning attacks [27], we note that all our hosts are dual-stack, and 736 thus are potentially exposed over both protocols anyway. We publish 737 all addresses in DNS, and do not operate a two faced DNS. 739 We have internal usage of RFC3041 privacy addresses [6] currently 740 (certain platforms currently ship with it on by default), but may 741 wish to administratively disable this (perhaps via DHCP) to ease 742 management complexity. However, we need to determine the feasibility 743 of this on all systems, e.g. for guests on wireless LAN or other 744 user-maintained systems. Network management and monitoring should be 745 simpler without RFC3041 in operation, in terms of identifying which 746 physical hosts are using which addresses. We note that RFC3041 is 747 only an issue for outbound connections, and that there is potential 748 to assign privacy addresses via DHCPv6. 750 We manually configure server addresses to avoid address changes on a 751 change of network adaptor. With IPv6 you can choose to pick ::53 for 752 a DNS server, or can pick 'random' addresses for obfuscation, though 753 that's not an issue for publicly advertised addresses (dns, mx, web, 754 etc). 756 5.2. Service Provider Considerations 758 In this section an IPv6 addressing schema is sketched that could 759 serve as an example for an Internet Service Provider. 761 Sub-section 5.2.1 starts with some thoughts regarding objective 762 requirements of such an addressing schema and deriving a few general 763 thumb rules that have to be kept in mind when designing an ISP IPv6 764 addressing plan. 766 Sub-section 5.2.2 illustrates these findings of 5.2.1 with an 767 exemplary IPv6 addressing schema for an MPLS-based ISP offering 768 Internet Services as well as Network Access services to millions of 769 customers. 771 5.2.1. Investigation of objective Requirements for an IPv6 addressing 772 schema of a Service Provider 774 The first step of the IPv6 addressing plan design for a Service 775 provider should identify all technical, operational, political and 776 business requirements that have to be satisfied by the services 777 supported by this addressing schema. 779 According to the different technical constraints and business models 780 as well as the different weights of these requirements (from the 781 point of view of the corresponding Service Provider) it is very 782 likely that different addressing schemas will be developed and 783 deployed by different ISPs. Nevertheless the addressing schema of 784 sub-section 5.2.2 is one possible example. 786 For this document it is assumed that our exemplary ISP has to fulfil 787 several roles for its customers as there are: 789 o Local Internet Registry 790 o Network Access Provider 791 o Internet Service Provider 793 5.2.1.1. Requirements for an IPv6 addressing schema from the LIR 794 perspective of the Service Provider 796 In their role as LIR the Service Providers have to care about the 797 policy constraints of the RIRs and the standards of the IETF 798 regarding IPv6 addressing. In this context, the following basic 799 requirements and recommendations have to be taken into account and 800 should be satisfied by the IPv6 address allocation plan of a Service 801 Provider: 803 o As recommended in RFC 3177 [7] and in several RIR policies 804 "Common" customers sites (normally private customers) should 805 receive a /48 prefix from the aggregate of the Service Provider. 806 (Note: The addressing plan must be flexible enough and take into 807 account the possible change of the minimum allocation size for end 808 users currently under definition by the RIRs.) 809 o "Big customers" (like big enterprises, governmental agencies etc.) 810 may receive shorter prefixes according to their needs when this 811 need could be documented and justified to the RIR. 812 o The IPv6 address allocation schema has to be able to meet the HD- 813 ratio of 0.94 as it is defined for IPv6. This requirement 814 corresponds to the demand for an efficient usage of the IPv6 815 address aggregate by the Service Provider. (Note: A HD-ratio of 816 0.94 means an effective usage of about 31% of a /20 of the Service 817 Provider on the basis of /48 assignments.) 818 o All assignments to customers have to be documented and stored into 819 a database that can also be queried by the RIR. 820 o The LIR has to make available means for supporting the reverse DNS 821 mapping of the customer prefixes. 823 5.2.1.2. IPv6 addressing schema requirements from the ISP perspective 824 of the Service Provider 826 From ISP perspective the following basic requirements could be 827 identified: 828 o The IPv6 address allocation schema must be able to realize a 829 maximal aggregation of all IPv6 address delegations to customers 830 into the address aggregate of the Service Provider. Only this 831 provider aggregate will be routed and injected into the global 832 routing table (DFZ). This strong aggregation keeps the routing 833 tables of the DFZ small and eases filtering and access control 834 very much. 835 o The IPv6 addressing schema of the SP should contain maximal 836 flexibility since the infrastructure of the SP will change over 837 the time with new customers, transport technologies and business 838 cases. The requirement of maximal flexibility is contrary to the 839 requirements of strong IPv6 address aggregation and efficient 840 address usage, but at this point each SP has to decide which of 841 these requirements to prioritize. 842 o Keeping the multilevel network hierarchy of an ISP in mind, due to 843 addressing efficiency reasons not all hierarchy levels can and 844 should be mapped into the IPv6 addressing schema of an ISP. 845 Sometimes it is much better to implement "flat" addressing for the 846 ISP network than to loose big chunks of the IPv6 address aggregate 847 in addressing each level of network hierarchy. Besides that a 848 decoupling of provider network addressing and customer addressing 849 is recommended. (Note: A strong aggregation e.g. on POP, 850 aggregation router or LER level limits the numbers of customer 851 routes that are visible within the ISP network but brings also 852 down the efficiency of the IPv6 addressing schema. That's why 853 each ISP has to decide how many internal aggregation levels he 854 wants to deploy.) 856 5.2.1.3. IPv6 addressing schema requirements from the Network Access 857 provider perspective of the Service Provider 859 As already done for the LIR and the ISP roles of the SP it is also 860 necessary to identify requirements that come from its Network Access 861 Provider role. Some of the basic requirements are: 862 o The IPv6 addressing schema of the SP must be flexible enough to 863 adapt changes that are injected from the customer side. This 864 covers changes to addressing architecture or routing topology that 865 are triggered from for instance the raising needs of the customers 866 regarding IPv6 addresses as well as changes that come from 867 topological modifications (e.g. when the customer moves from one 868 point of network attachment (POP) to another). 869 o For each IPv6 address assignment to customers a "buffer zone" must 870 be reserved that allows the customer to grow in its addressing 871 range without renumbering or assignment of additional prefixes. 872 o The IPv6 addressing schema of the SP must deal with multiple- 873 attachments of a single customer to the SP network infrastructure 874 (i.e. multi-homed network access with the same SP). 876 These few requirements are only part of all the requirements a 877 Service Provider has to investigate and keep in mind during the 878 definition phase of its addressing architecture. Each SP will most 879 likely add more constraints to this list. 881 5.2.1.4. A few thumb rules for designing an IPv6 ISP addressing 882 architecture 884 As outcome of the above investigation of requirements regarding an 885 ISP IPv6 addressing plane the following design "thumb rules" should 886 be derived: 887 o No "One size fits all" Each ISP must develop its own IPv6 address 888 allocation schema depending on its concrete business needs. It is 889 not practicable to design one addressing plan that fits all ISPs 890 (Small / big, Routed / MPLS-based, access / transit, LIR / No-LIR, 891 ...). 892 o The levels of IPv6 address aggregation within the ISP addressing 893 schema should strongly correspond to the implemented network 894 structure and their number should be minimized because of 895 efficiency reasons. It is assumed that the SPs own infrastructure 896 will be addressed in a fairly flat way whereas the part of the 897 customer addressing architecture should contain several levels of 898 aggregation. 900 o Keep the number of IPv6 customer routes inside your network as 901 small as necessary. A totally flat customer IPv6 addressing 902 architecture without any intermediate aggregation level will lead 903 to lots of customer routes inside the SP network. A fair trade- 904 off between address aggregation levels (and hence the size of the 905 internal routing table of the SP) and address conservation of the 906 addressing architecture has to be found. 907 o The ISP IPv6 addressing schema should provide maximal flexibility. 908 This has to be realized for supporting different sizes of customer 909 IPv6 address aggregates ("big" customers vs. "small" customers) as 910 well as to allow future growing rates (e.g. of customer 911 aggregates) and possible topological or infrastructural changes. 912 o A limited number of aggregation levels and sizes of customer 913 aggregates will ease the management of the addressing schema. 914 This has to be weighed against the previous "thumb rule" - 915 flexibility. 917 5.2.2. Exemplary IPv6 address allocation plan for a Service Provider 919 In this example, the Service Provider is assumed to operate an MPLS 920 based backbone and implements 6PE to provide IPv6 backbone transport 921 between the different locations (POPs) of a fully dual-stacked 922 network access and aggregation area. 924 Besides that it is assumed that the Service Provider: 925 o has received a /20 from its RIR 926 o operates its own LIR 927 o has to address its own IPv6 infrastructure 928 o delegates prefixes from this aggregate to its customers 930 This addressing schema should illustrate how the /20 IPv6 prefix of 931 the SP can be used to address the SP-own infrastructure and to 932 delegate IPv6 prefixes to its customers following the above mentioned 933 requirements and thumb rules as far as possible. 935 The below figure summarizes the device types in an SP network and the 936 typical network design. The network hierarchy of the SP has to be 937 taken into account for the design of an IPv6 addressing schema and 938 defines its basic shape and the levels of aggregation. 940 +------------------------------------------------------------------+ 941 | LSRs of the MPLS Backbone of the SP | 942 +------------------------------------------------------------------+ 943 | | | | | 944 | | | | | 945 +-----+ +-----+ +--------+ +--------+ +--------+ 946 | LER | | LER | | LER-BB | | LER-BB | | LER-BB | 947 +-----+ +-----+ +--------+ +--------+ +--------+ 948 | | | | | | / | | | 949 | | | | | | / | | | 950 | | | | +------+ +------+ +------+ | | 951 | | | | |BB-RAR| |BB-RAR| | AG | | | 952 | | | | +------+ +------+ +------+ | | 953 | | | | | | | | | | | | 954 | | | | | | | | | | | | 955 | | | | | | | | +-----+ +-----+ +-----+ +-----+ 956 | | | | | | | | | RAR | | RAR | | RAR | | RAR | 957 | | | | | | | | +-----+ +-----+ +-----+ +-----+ 958 | | | | | | | | | | | | | | | | 959 | | | | | | | | | | | | | | | | 960 +-------------------------------------------------------------------+ 961 | Customer networks | 962 +-------------------------------------------------------------------+ 963 Figure: Exemplary Service Provider Network 965 LSR ... Label Switch Router 966 LER ... Label Edge Router 967 LER-BB ... Broadband Label Edge Router 968 RAR ... Remote Access Router 969 BB-RAR ... Broadband Remote Access Router 970 AG ... Aggregation Router 972 Basic design decisions for the exemplary Service Provider IPv6 973 address plan regarding customer prefixes take into consideration: 974 o The prefixes assigned to all customers behind the same LER (e.g. 975 LER or LER-BB) are aggregated under one prefix. This ensures that 976 the number of labels that have to be used for 6PE is limited and 977 hence provides a strong MPLS label conservation. 978 o The /20 prefix of the SP is separated into 3 different pools that 979 are used to allocate IPv6 prefixes to the customers of the SP: 980 * A pool (e.g. /24) for satisfying the addressing needs of real 981 "big" customers (as defined in 5.2.2.1 sub-section A.) that 982 need IPv6 prefixes larger than /48 (e.g. /32). These customers 983 are assumed to be connected to several POPs of the access 984 network, so that this customer prefix will be visible in each 985 of these POPs. 987 * A pool (e.g. /24) for the LERs with direct customer connections 988 (e.g. dedicated line access) and without an additional 989 aggregation area between the customer and the LER. (These LERs 990 are mostly connected to a limited number of customers because 991 of the limited number of interfaces/ports.) 992 * A larger pool (e.g. 14*/24) for LERs (e.g. LER-BB) that serve 993 a high number of customers that are normally connected via some 994 kind of aggregation network (e.g. DSL customers behind a BB- 995 RAR or Dial-In customers behind a RAR). 996 * The IPv6 address delegation within each Pool (end customer 997 delegation or also the aggregates that are dedicated to the 998 LERs itself) should be chosen with an additional buffer zone of 999 300% for future growth. 1001 5.2.2.1. Defining an IPv6 address allocation plan for customers of the 1002 Service Provider 1004 5.2.2.1.1. 'Big' customers 1006 SP's "big" customers receive their prefix from the /24 IPv6 address 1007 aggregate that has been reserved for their "big" customers. A 1008 customer is considered as "big" customer if it has a very complex 1009 network infrastructure and/or huge IPv6 address needs (e.g. because 1010 of very large customer numbers) and/or several uplinks to different 1011 POPs of the SP network. 1013 The assigned IPv6 address prefixes can have a prefix length in the 1014 range 32-48 and for each assignment a 300% future growing zone is 1015 marked as "reserved" for this customer. This means that for instance 1016 with a delegation of a /34 to a customer the /32 that contains this 1017 /34 is reserved for the customer for future usage. 1019 The prefixes for the "big" customers can be chosen from the 1020 corresponding "big customer" pool by either using an equidistant 1021 algorithm or using mechanisms similar to the Sparse Allocation 1022 Algorithm (SAA) [28]. 1024 5.2.2.1.2. 'Common' customers 1026 All customers that are not "big" customers are considered as "common" 1027 customers. They represent the majority of customers hence they 1028 receive a /48 out of the IPv6 customer address pool of the LER where 1029 they are directly connected or aggregated. 1031 Again a 300% future growing IPv6 address range is reserved for each 1032 customer, so that a "common" customer receives a /48 allocation but 1033 has a /46 reserved. 1035 In the network access scenarios where the customer is directly 1036 connected to the LER the customer prefix is directly taken out of the 1037 customer IPv6 address aggregate (e.g. /38) of the corresponding LER. 1039 In all other cases (e.g. the customer is attached to a RAR that is 1040 themselves aggregated to an AG or to a LER) at least 2 different 1041 approaches are possible. 1043 1) Mapping of Aggregation Network Hierarchy into Customer IPv6 1044 Addressing Schema. The aggregation network hierarchy could be mapped 1045 into the design of the customer prefix pools of each network level in 1046 order to achieve a maximal aggregation at the LER level as well as at 1047 the intermediate levels. (Example: Customer - /48, RAR - /38, AG - 1048 /32, LER-BB - /30). At each network level an adequate growing zone 1049 should be reserved. (Note: This approach requires of course some 1050 "fine tuning" of the addressing schema based on a very good knowledge 1051 of the Service Provider network topology including actual growing 1052 ranges and rates.) 1054 When the IPv6 customer address pool of a LER (or another device of 1055 the aggregation network - AG or RAR) is exhausted, the related LER 1056 (or AG or RAR) prefix is shortened by 1 or 2 bits (e.g. from /38 to 1057 /37 or /36) so that the originally reserved growing zone can be used 1058 for further IPv6 address allocations to customers. In the case where 1059 the growing zone is exhausted as well a new prefix range from the 1060 corresponding pool of the next higher hierarchy level can be 1061 requested. 1063 2) "Flat" Customer IPv6 Addressing Schema. The other option is to 1064 allocate all the customer prefixes directly out of the customer IPv6 1065 address pool of the LER where the customers are attached and 1066 aggregated and ignore the intermediate aggregation network 1067 infrastructure. This approach leads of course to a higher amount of 1068 customer routes at LER and aggregation network level but takes a 1069 great amount of complexity out of the addressing schema. 1070 Nevertheless the aggregation of the customer prefixes to one prefix 1071 at LER level is realized as required above. 1073 If the actual observed growing rates show that the reserved growing 1074 zones are not needed than these growing areas can be freed and used 1075 for assignments for prefix pools to other devices at the same level 1076 of the network hierarchy. 1078 5.2.2.2. Defining an IPv6 address allocation plan for the Service 1079 Provider Network Infrastructure 1081 For the IPv6 addressing of SPs own network infrastructure a /32 (or 1082 /40) from the "big" customers address pool can be chosen. 1084 This SP infrastructure prefix is used to code the network 1085 infrastructure of the SP by assigning a /48 to every POP/location and 1086 using for instance a /56 for coding the corresponding router within 1087 this POP. Each SP internal link behind a router interface could be 1088 coded using a /64 prefix. (Note: While it is suggested to chose a 1089 /48 for addressing the POP/location of the SP network it is left to 1090 each SP to decide what prefix length to assign to the routers and 1091 links within this POP.) 1093 The IIDs of the router interfaces may be generated by using EUI-64 or 1094 through plain manual configuration e.g. for coding additional network 1095 or operational information into the IID. 1097 It is assumed that a 300% growing zones for each level of network 1098 hierarchy and additional prefixes may be assigned to POPs and/or 1099 routers if needed. 1101 Loopback interfaces of routers may be chosen from the first /64 of 1102 the /56 router prefix (in the example above). 1104 (Note: The /32 prefix that has been chosen for addressing SPs own 1105 IPv6 network infrastructure gives enough place to code additional 1106 functionalities like security levels or private and test 1107 infrastructure although such approaches haven't been considered in 1108 more detail for the above described SP until now.) 1110 Point-to-point links to customers (e.g. PPP links, dedicated line 1111 etc.) may be addressed using /126 prefixes out of the first /64 of 1112 the access routers that could be reserved for this reason. 1114 5.2.3. Additional Remarks 1116 5.2.3.1. ULA 1118 From the actual view point of SP there is no compelling reason why 1119 ULAs should be used from a SP. Look at section 2.2. 1121 ULAs could be used inside the SP network in order to have an 1122 additional "site-local scoped" IPv6 address for SPs own 1123 infrastructure for instance for network management reasons and maybe 1124 also in order to have an addressing schema that couldn't be reached 1125 from outside the SP network. 1127 In the case when ULAs are used it is possible to map the proposed 1128 internal IPv6 addressing of SPs own network infrastructure as 1129 described in 5.2.2.2 above directly to the ULA addressing schema by 1130 substituting the /48 POP prefix with a /48 ULA site prefix. 1132 5.2.3.2. Multicast 1134 IPv6 Multicast-related addressing issues are out of the scope of this 1135 document. 1137 5.2.3.3. POP Multi-homing or Change of POP 1139 POP (or better LER) Multi-homing of customers with the same SP can be 1140 realized within the proposed IPv6 addressing schema of the SP by 1141 assigning multiple LER-dependent prefixes to this customer (i.e. 1142 considering each customer location as a single-standing customer) or 1143 by choosing a customer prefix out of the pool of "big" customers. 1144 The second solution has the disadvantage that in every LER where the 1145 customer is attached this prefix will appear inside the IGP routing 1146 table requiring an explicit MPLS label. 1148 An equal effect happens when a customer changes its point of 1149 attachment to another POP/LER since in this case the customer prefix 1150 could not be aggregated into the LER prefix and needs to be 1151 advertised more specific in the IGP. 1153 (Note: The described negative POP/LER Multi-homing effects to the 1154 addressing architecture in the SP access network are not tackled by 1155 implementing the Shim6 Site Multi-homing approach since this approach 1156 targets only on a mechanism for dealing with multiple prefixes in end 1157 systems -- the SP will nevertheless have unaggregated customer 1158 prefixes in its internal routing tables.) 1160 5.2.3.4. Extensions needed for the later IPv6 migration phases 1162 The proposed IPv6 addressing schema for a SP needs some slight 1163 enhancements / modifications for the later phases of IPv6 1164 integration, for instance in the case when the whole MPLS backbone 1165 infrastructure (LDP, IGP etc.) is realized over IPv6 transport an 1166 addressing of the LSRs is needed. Other changes may be necessary as 1167 well but should not be explained at this point. 1169 6. IANA Considerations 1171 There are no extra IANA consideration for this document. 1173 7. Security Considerations 1175 This IPv6 addressing document does not have any direct impact on 1176 Internet infrastructure security. 1178 8. Acknowledgements 1180 Constructive feedback and contributions have been received from Stig 1181 Venaas, Pekka Savola, John Spence, Patrick Grossetete, Carlos Garcia 1182 Braschi, Brain Carpenter and Mark Smith. 1184 9. References 1186 9.1. Normative References 1188 9.2. Informative References 1190 [1] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. 1191 Lear, "Address Allocation for Private Internets", BCP 5, 1192 RFC 1918, February 1996. 1194 [2] Thomson, S. and T. Narten, "IPv6 Stateless Address 1195 Autoconfiguration", RFC 2462, December 1998. 1197 [3] Hinden, R., Fink, R., and J. Postel, "IPv6 Testing Address 1198 Allocation", RFC 2471, December 1998. 1200 [4] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast 1201 Addresses", RFC 2526, March 1999. 1203 [5] Retana, A., White, R., Fuller, V., and D. McPherson, "Using 31- 1204 Bit Prefixes on IPv4 Point-to-Point Links", RFC 3021, 1205 December 2000. 1207 [6] Narten, T. and R. Draves, "Privacy Extensions for Stateless 1208 Address Autoconfiguration in IPv6", RFC 3041, January 2001. 1210 [7] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 1211 Tunnel Broker", RFC 3053, January 2001. 1213 [8] IAB and IESG, "IAB/IESG Recommendations on IPv6 Address 1214 Allocations to Sites", RFC 3177, September 2001. 1216 [9] Durand, A. and C. Huitema, "The H-Density Ratio for Address 1217 Assignment Efficiency An Update on the H ratio", RFC 3194, 1218 November 2001. 1220 [10] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. 1221 Carney, "Dynamic Host Configuration Protocol for IPv6 1222 (DHCPv6)", RFC 3315, July 2003. 1224 [11] Draves, R., "Default Address Selection for Internet Protocol 1225 version 6 (IPv6)", RFC 3484, February 2003. 1227 [12] Blanchet, M., "A Flexible Method for Managing the Assignment of 1228 Bits of an IPv6 Address Block", RFC 3531, April 2003. 1230 [13] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global Unicast 1231 Address Format", RFC 3587, August 2003. 1233 [14] Savola, P., "Use of /127 Prefix Length Between Routers 1234 Considered Harmful", RFC 3627, September 2003. 1236 [15] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host 1237 Configuration Protocol (DHCP) version 6", RFC 3633, 1238 December 2003. 1240 [16] Fink, R. and R. Hinden, "6bone (IPv6 Testing Address 1241 Allocation) Phaseout", RFC 3701, March 2004. 1243 [17] Droms, R., "Stateless Dynamic Host Configuration Protocol 1244 (DHCP) Service for IPv6", RFC 3736, April 2004. 1246 [18] Huitema, C. and B. Carpenter, "Deprecating Site Local 1247 Addresses", RFC 3879, September 2004. 1249 [19] Savola, P. and B. Haberman, "Embedding the Rendezvous Point 1250 (RP) Address in an IPv6 Multicast Address", RFC 3956, 1251 November 2004. 1253 [20] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 1254 Neighbor Discovery (SEND)", RFC 3971, March 2005. 1256 [21] Aura, T., "Cryptographically Generated Addresses (CGA)", 1257 RFC 3972, March 2005. 1259 [22] Baker, F., Lear, E., and R. Droms, "Procedures for Renumbering 1260 an IPv6 Network without a Flag Day", RFC 4192, September 2005. 1262 [23] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1263 Addresses", RFC 4193, October 2005. 1265 [24] Templin, F., Gleeson, T., Talwar, M., and D. Thaler, "Intra- 1266 Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 4214, 1267 October 2005. 1269 [25] Hinden, R. and S. Deering, "IP Version 6 Addressing 1270 Architecture", RFC 4291, February 2006. 1272 [26] Chown, T., Venaas, S., and C. Strauf, "Dynamic Host 1273 Configuration Protocol (DHCP): IPv4 and IPv6 Dual-Stack 1274 Issues", RFC 4477, May 2006. 1276 [27] Chown, T., "IPv6 Implications for TCP/UDP Port Scanning 1277 (draft-ietf-v6ops-scanning-implications-00.txt)", June 2006. 1279 [28] APNIC, ARIN, RIPE NCC, "IPv6 Address Allocation and Assignment 1280 Policy (www.ripe.net/ripe/docs/ipv6policy.html)", January 2003. 1282 [29] Chown, T., Thompson, M., Ford, A., and S. Venaas, "Things to 1283 think about when Renumbering an IPv6 network 1284 (draft-chown-v6ops-renumber-thinkabout-05.txt)", March 2007. 1286 Authors' Addresses 1288 Gunter Van de Velde 1289 Cisco Systems 1290 De Kleetlaan 6a 1291 Diegem 1831 1292 Belgium 1294 Phone: +32 2704 5473 1295 Email: gunter@cisco.com 1297 Ciprian Popoviciu 1298 Cisco Systems 1299 7025-6 Kit Creek Road 1300 Research Triangle Park, North Carolina PO Box 14987 1301 USA 1303 Phone: +1 919 392-3723 1304 Email: cpopovic@cisco.com 1306 Tim Chown 1307 University of Southampton 1308 Highfield 1309 Southampton, SO17 1BJ 1310 United Kingdom 1312 Phone: +44 23 8059 3257 1313 Email: tjc@ecs.soton.ac.uk 1315 Olaf Bonness 1316 T-Systems Enterprise Services GmbH 1317 Goslarer Ufer 35 1318 Berlin, 10589 1319 Germany 1321 Phone: +49 30 3497 3124 1322 Email: Olaf.Bonness@t-systems.com 1323 Christian Hahn 1324 T-Systems Enterprise Services GmbH 1325 Goslarer Ufer 35 1326 Berlin, 10589 1327 Germany 1329 Phone: +49 30 3497 3164 1330 Email: HahnC@t-systems.com 1332 Intellectual Property Statement 1334 The IETF takes no position regarding the validity or scope of any 1335 Intellectual Property Rights or other rights that might be claimed to 1336 pertain to the implementation or use of the technology described in 1337 this document or the extent to which any license under such rights 1338 might or might not be available; nor does it represent that it has 1339 made any independent effort to identify any such rights. Information 1340 on the procedures with respect to rights in RFC documents can be 1341 found in BCP 78 and BCP 79. 1343 Copies of IPR disclosures made to the IETF Secretariat and any 1344 assurances of licenses to be made available, or the result of an 1345 attempt made to obtain a general license or permission for the use of 1346 such proprietary rights by implementers or users of this 1347 specification can be obtained from the IETF on-line IPR repository at 1348 http://www.ietf.org/ipr. 1350 The IETF invites any interested party to bring to its attention any 1351 copyrights, patents or patent applications, or other proprietary 1352 rights that may cover technology that may be required to implement 1353 this standard. Please address the information to the IETF at 1354 ietf-ipr@ietf.org. 1356 Disclaimer of Validity 1358 This document and the information contained herein are provided on an 1359 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1360 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1361 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1362 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1363 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1364 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1366 Copyright Statement 1368 Copyright (C) The Internet Society (2006). This document is subject 1369 to the rights, licenses and restrictions contained in BCP 78, and 1370 except as set forth therein, the authors retain all their rights. 1372 Acknowledgment 1374 Funding for the RFC Editor function is currently provided by the 1375 Internet Society.