idnits 2.17.1 draft-ietf-v6ops-addcon-01.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 1283. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1260. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1267. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1273. ** 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 (June 2006) is 6524 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 454 == Unused Reference: '24' is defined on line 1183, but no explicit reference was found in the text == Unused Reference: '29' is defined on line 1201, 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. '7') (Obsoleted by RFC 6177) -- Obsolete informational reference (is this intentional?): RFC 3315 (ref. '9') (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3484 (ref. '10') (Obsoleted by RFC 6724) -- Obsolete informational reference (is this intentional?): RFC 3627 (ref. '13') (Obsoleted by RFC 6547) -- Obsolete informational reference (is this intentional?): RFC 3633 (ref. '14') (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3736 (ref. '16') (Obsoleted by RFC 8415) -- Duplicate reference: draft-ietf-ngtrans-isatap, mentioned in '25', was also mentioned in '24'. == Outdated reference: A later version (-05) exists of draft-chown-v6ops-renumber-thinkabout-03 Summary: 3 errors (**), 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: December 3, 2006 Cisco Systems 5 T. Chown 6 University of Southampton 7 O. Bonness 8 C. Hahn 9 T-Systems Enterprise Services GmbH 10 June 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 December 3, 2006. 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 integration of IPv6. This draft 52 aims to provide the information and recommendations relevant to 53 planning the addressing aspects of IPv6 deployments. The draft also 54 provides IPv6 addressing case studies for both an enterprise and an 55 ISP network. In this first version of the draft we aim to provoke 56 discussion on this important topic; more detailed case study texts 57 will follow. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2. Network Level Addressing Design Considerations . . . . . . . . 5 63 2.1. Global Unique Addresses . . . . . . . . . . . . . . . . . 5 64 2.2. Unique Local IPv6 Addresses . . . . . . . . . . . . . . . 5 65 2.3. 6Bone Address Space . . . . . . . . . . . . . . . . . . . 6 66 2.4. Network Level Design Considerations . . . . . . . . . . . 7 67 2.4.1. Sizing the Network Allocation . . . . . . . . . . . . 8 68 2.4.2. Address Space Conservation . . . . . . . . . . . . . . 8 69 3. Subnet Prefix Considerations . . . . . . . . . . . . . . . . . 8 70 3.1. Considerations for subnet prefixes shorter then /64 . . . 8 71 3.2. Considerations for /64 prefixes . . . . . . . . . . . . . 9 72 3.3. Considerations for subnet prefixes longer then /64 . . . . 9 73 3.3.1. Anycast addresses . . . . . . . . . . . . . . . . . . 9 74 3.3.2. Addresses used by Embedded-RP (RFC3956) . . . . . . . 11 75 3.3.3. ISATAP addresses . . . . . . . . . . . . . . . . . . . 11 76 3.3.4. /126 addresses . . . . . . . . . . . . . . . . . . . . 12 77 3.3.5. /127 addresses . . . . . . . . . . . . . . . . . . . . 12 78 3.3.6. /128 addresses . . . . . . . . . . . . . . . . . . . . 12 79 4. Allocation of the IID of an IPv6 Address . . . . . . . . . . . 12 80 4.1. Automatic EUI-64 Format Option . . . . . . . . . . . . . . 13 81 4.2. Using Privacy Extensions . . . . . . . . . . . . . . . . . 13 82 4.3. Cryptographically Generated IPv6 Addresses . . . . . . . . 13 83 4.4. Manual/Dynamic Assignment Option . . . . . . . . . . . . . 14 84 5. Case Studies . . . . . . . . . . . . . . . . . . . . . . . . . 14 85 5.1. Enterprise Considerations . . . . . . . . . . . . . . . . 14 86 5.1.1. Obtaining general IPv6 network prefixes . . . . . . . 14 87 5.1.2. Forming an address (subnet) allocation plan . . . . . 15 88 5.1.3. Other considerations . . . . . . . . . . . . . . . . . 16 89 5.1.4. Node configuration considerations . . . . . . . . . . 16 90 5.1.5. Observations . . . . . . . . . . . . . . . . . . . . . 17 91 5.2. Service Provider Considerations . . . . . . . . . . . . . 17 92 5.2.1. Investigation of objective Requirements for an 93 IPv6 addressing schema of a Service Provider . . . . . 17 94 5.2.2. IPv6 address allocation plan for a Service Provider . 19 95 5.2.3. Additional Remarks . . . . . . . . . . . . . . . . . . 23 96 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 97 7. Security Considerations . . . . . . . . . . . . . . . . . . . 24 98 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 99 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 100 9.1. Normative References . . . . . . . . . . . . . . . . . . . 25 101 9.2. Informative References . . . . . . . . . . . . . . . . . . 25 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 103 Intellectual Property and Copyright Statements . . . . . . . . . . 30 105 1. Introduction 107 The Internet Protocol Version 6 (IPv6) Addressing Architecture [23] 108 defines three main types of addresses: unicast, anycast and 109 multicast. This document focuses on unicast addresses, for which 110 there are currently three principal allocated types: Global Unique 111 Addresses [12] ('globals'), Unique Local IPv6 Addresses [22] (ULAs) 112 and 6bone address space [3]. 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 its 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 will provide two examples 128 of successfully deployed address plans in a service provider (ISP) 129 and 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 reduced threat of address-based host 144 scanning, as discussed in [26]. 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 receive their global unicast address 149 allocation from their 'upstream' provider, which may be another ISP, 150 a Local Internet Registry (LIR) or a Regional Internet Registry 151 (RIR). In each case the prefix received is provider assigned (PA); 152 there is currently no provider independent (PI) address space for 153 IPv6. Thus an IPv6 network which changes provider will need to 154 undergo a renumbering process, as described in [21]. A separate 155 document [28] makes recommendations to ease the IPv6 renumbering 156 process. 158 This document neither discusses implementation aspects between ULA 159 addresses and Site-local addresses. Most implementations know about 160 Site-local addresses even though they are deprecated, and do not know 161 about ULAs - even though they are according current specification. 162 As result transitioning between these types of addresses may cause 163 difficulties. 165 2. Network Level Addressing Design Considerations 167 This section discusses the kind of IPv6 addresses used at the network 168 level for the IPv6 infrastructure. The kind of addresses that can be 169 considered are Global Unique Addresses, ULAs and 6bone address space. 171 2.1. Global Unique Addresses 173 The most commonly used unicast addresses will be Global Unique 174 Addresses ('globals'). No significant considerations are necessary 175 if the organization has an address space assignment and a single 176 prefix is deployed through a single upstream provider. 178 However, a multihomed site may deploy addresses from two or more 179 Service Provider assigned IPv6 address ranges. Here, the network 180 Administrator must have awareness on where and how these ranges are 181 used on the multihomed infrastructure environment. The nature of the 182 usage of multiple prefixes may depend on the reason for multihoming 183 (e.g. resilience failover, load balancing, policy-based routing, or 184 multihoming during an IPv6 renumbering event). IPv6 introduces 185 improved support for multi-addressed hosts through the IPv6 default 186 address selection methods described in RFC3484 [10]. A multihomed 187 host may thus have two addresses, one per prefix (provider), and 188 select source and destination addresses to use as described in that 189 RFC. 191 2.2. Unique Local IPv6 Addresses 193 ULAs have replaced the originally conceived Site Local addresses in 194 the IPv6 addressing architecture, for reasons described in [17]. 195 ULAs improve on site locals by offering a high probability of the 196 global uniqueness of the prefix used, which can be beneficial in the 197 case of (deliberate or accidental) leakage, or where networks are 198 merged. ULAs are akin to the private address space [1] assigned for 199 IPv4 networks. 201 The ULA address range allows a network administrator to deploy IPv6 202 addresses on their network without asking for a globally unique 203 registered IPv6 address range. A ULA prefix is 48 bits, i.e. a /48, 204 the same as the currently recommended allocation for a site from the 205 globally routable IPv6 address space [7]. 207 ULAs provide the means to deploy a fixed addressing scheme that is 208 not affected by a change in service provider and the corresponding PA 209 global addresses. Internal operation of the network is thus 210 unaffected during renumbering events. Nevertheless, this type of 211 address must be used with caution. 213 A site using ULAs may or may not also deploy globals. In an isolated 214 network ULAs may be deployed on their own. In a connected network, 215 that also deploys global addresses, both may be deployed, such that 216 hosts become multiaddressed (one global and one ULA address) and the 217 IPv6 default address selection algorithm will pick the appropriate 218 source and destination addresses to use, e.g. ULAs will be selected 219 where both the source and destination hosts have ULA addresses. 220 Because a ULA and a global site prefix are both /48 length, an 221 administrator can choose to use the same subnetting (and host 222 addressing) plan for both prefixes. 224 As an example of the problems ULAs may cause, when using IPv6 225 multicast within the network, the IPv6 default address selection 226 algorithm prefers the ULA address as the source address for the IPv6 227 multicast streams. This is NOT a valid option when sending an IPv6 228 multicast stream to the IPv6 Internet for two reasons. For one, 229 these addresses are not globally routable so RPF checks for such 230 traffic will fail outside the internal network. The other reason is 231 that the traffic will likely not cross the network boundary due to 232 multicast domain control and perimeter security policies. 234 In principal ULAs allow easier network mergers than RFC1918 addresses 235 do for IPv4 because ULA prefixes have a high probability of 236 uniqueness, if the prefix is chosen as described in the RFC. 238 The usage of ULAs should be carefully considered even when not 239 attached to the IPv6 Internet due to the potential for added 240 complexity when connecting to the Internet at some point in the 241 future. 243 2.3. 6Bone Address Space 245 The 6Bone address space was used before the RIRs started to 246 distribute 'production' IPv6 prefixes. The 6Bone prefixes have a 247 common first 16 bits in the IPv6 Prefix of 3FFE::/16. This address 248 range is deprecated as of 6th June 2006 [15] and should be avoided on 249 any new IPv6 network deployments. Sites using 6bone address space 250 should renumber to production address space using procedures as 251 defined in [21]. 253 2.4. Network Level Design Considerations 255 IPv6 provides network administrators with a significantly larger 256 address space, enabling them to be very creative in how they can 257 define logical and practical address plans. The subnetting of 258 assigned prefixes can be done based on various logical schemes that 259 involve factors such as: 260 o Geographical Boundaries - by assigning a common prefix to all 261 subnets within a geographical area. 262 o Organizational Boundaries - by assigning a common prefix to an 263 entire organization or group within a corporate infrastructure. 264 o Service Type - by reserving certain prefixes for predefined 265 services such as: VoIP, Content Distribution, wireless services, 266 Internet Access, etc. 267 Such logical addressing plans have the potential to simplify network 268 operations and service offerings, and to simplify network management 269 and troubleshooting. A very large network would also have no need to 270 consider using private address space for its infrastructure devices, 271 simplifying network management. 273 The network designer must however keep in mind several factors when 274 developing these new addressing schemes: 275 o Prefix Aggregation - The larger IPv6 addresses can lead to larger 276 routing tables unless network designers are actively pursuing 277 aggregation. While prefix aggregation will be enforced by the 278 service provider, it is beneficial for the individual 279 organizations to observe the same principles in their network 280 design process. 281 o Network growth - The allocation mechanism for flexible growth of a 282 network prefix, documented in RFC3531 [11] can be used to allow 283 the network infrastructure to grow and be numbered in a way that 284 is likely to preserve aggregation (the plan leaves 'holes' for 285 growth). 286 o ULA usage in large networks - Networks which have a large number 287 of 'sites' that each deploy a ULA prefix which will by default be 288 a 'random' /48 under fc00::/7 will have no aggregation of those 289 prefixes. Thus the end result may be cumbersome because the 290 network will have large amounts of non-aggregated ULA prefixes. 291 However, there is no rule to disallow large networks to use a 292 single ULA for all 'sites', as a ULA still provides 16 bits for 293 subnetting to be used internally. 295 2.4.1. Sizing the Network Allocation 297 We do not discuss here how a network designer sizes their application 298 for address space. By default a site will receive a /48 prefix [7]. 299 The default provider allocation via the RIRs is currently a /32 [27]. 300 These allocations are indicators for a first allocation for a 301 network. Different sizes may be obtained based on the anticipated 302 address usage [27]. There are examples of allocations as large as 303 /19 having been made from RIRs to providers at the time of writing. 305 2.4.2. Address Space Conservation 307 Despite the large IPv6 address space which enables easier subnetting, 308 it still is important to ensure an efficient use of this resource. 309 Some addressing schemes, while facilitating aggregation and 310 management, could lead to significant numbers of addresses being 311 unused. Address conservation requirements are less stringent in IPv6 312 but they should still be observed. 314 The proposed HD [8] value for IPv6 is 0.94 compared to the current 315 value of 0.96 for IPv4. Note that for IPv6 HD is calculated for 316 sites (i.e. on a basis of /48), instead of based on addresses like 317 with IPv4. 319 3. Subnet Prefix Considerations 321 This section analyzes the considerations applied to define the subnet 322 prefix of the IPv6 addresses. The boundaries of the subnet prefix 323 allocation are specified in RFC4291 [23]. In this document we 324 analyze their practical implications. Based on RFC4291 [23] it is 325 legal for any IPv6 unicast address starting with binary address '000' 326 to have a subnet prefix larger than, smaller than or of equal to 64 327 bits. Each of these three options is discussed in this document. 329 3.1. Considerations for subnet prefixes shorter then /64 331 An allocation of a prefix shorter then 64 bits to a node or interface 332 is bad practice. The shortest subnet prefix that could theoretically 333 be assigned to an interface or node is limited by the size of the 334 network prefix allocated to the organization. 336 A possible reason for choosing the subnet prefix for an interface 337 shorter then /64 is that it would allow more nodes to be attached to 338 that interface compared to a prescribed length of 64 bits. This 339 however is unnecessary considering that 2^64 provides plenty of node 340 addresses for a well designed IPv6 network. Layer two technologies 341 are unlikely to support such large numbers of nodes within a single 342 link (e.g. Ethernet limited to 48-bits of hosts) 344 The subnet prefix assignments can be made either by manual 345 configuration, by a stateful Host Configuration Protocol [9] or by a 346 stateful prefix delegation mechanism [14]. 348 3.2. Considerations for /64 prefixes 350 Based on RFC3177 [7], 64 bits is the prescribed subnet prefix length 351 to allocate to interfaces and nodes. 353 When using a /64 subnet length, the address assignment for these 354 addresses can be made either by manual configuration, by a stateful 355 Host Configuration Protocol [9] [16] or by stateless 356 autoconfiguration [2]. 358 Note that RFC3177 strongly prescribes 64 bit subnets for general 359 usage, and that stateless autoconfiguration option is only defined 360 for 64 bit subnets. 362 3.3. Considerations for subnet prefixes longer then /64 364 Address space conservation is the main motivation for using a subnet 365 prefix length longer than 64 bits. 367 The address assignment can be made either by manual configuration or 368 by a stateful Host Configuration Protocol [9]. 370 When assigning a subnet prefix of more then 80 bits, according to 371 RFC4291 [23] "u" and "g" bits (respectively the 81st and 82nd bit) 372 need to be taken into consideration and should be set correctly. In 373 currently implemented IPv6 protocol stacks, the relevance of the "u" 374 (universal/local) bit and "g" (the individual/group) bit are marginal 375 and typically will not show an issue when configured wrongly, however 376 future implementations may turn out differently. 378 When using subnet lengths longer then 64 bits, it is important to 379 avoid selecting addresses that may have a predefined use and could 380 confuse IPv6 protocol stacks. The alternate usage may not be a 381 simple unicast address in all cases. The following points should be 382 considered when selecting a subnet length longer then 64 bits. 384 3.3.1. Anycast addresses 386 3.3.1.1. Subnet Router Anycast Address 388 RFC4291 [23] provides a definition for the required Subnet Router 389 Anycast Address as follows: 391 | n bits | 128-n bits | 392 +--------------------------------------------+----------------+ 393 | subnet prefix | 00000000000000 | 394 +--------------------------------------------+----------------+ 396 It is recommended to avoid allocating this IPv6 address to a device 397 which is not a router. No additional dependencies for the subnet 398 prefix while the EUI-64 and an IID dependencies will be discussed 399 later in this document. 401 3.3.1.2. Reserved IPv6 Subnet Anycast Addresses 403 RFC2526 [4] stated that within each subnet, the highest 128 interface 404 identifier values are reserved for assignment as subnet anycast 405 addresses. 407 The construction of a reserved subnet anycast address depends on the 408 type of IPv6 addresses used within the subnet, as indicated by the 409 format prefix in the addresses. 411 The first type of Subnet Router Anycast addresses have been defined 412 as follows for EUI-64 format: 414 | 64 bits | 57 bits | 7 bits | 415 +------------------------------+------------------+------------+ 416 | subnet prefix | 1111110111...111 | anycast ID | 417 +------------------------------+------------------+------------+ 419 The anycast address structure implies that it is important to avoid 420 creating a subnet prefix where the bits 65 to 121 are defined as 421 "1111110111...111" (57 bits in total) so that confusion can be 422 avoided. 424 For other IPv6 address types (that is, with format prefixes other 425 than those listed above), the interface identifier is not in EUI-64 426 format and may be other than 64 bits in length; these reserved subnet 427 anycast addresses for such address types are constructed as follows: 429 | n bits | 121-n bits | 7 bits | 430 +------------------------------+------------------+------------+ 431 | subnet prefix | 1111111...111111 | anycast ID | 432 +------------------------------+------------------+------------+ 433 | interface identifier field | 435 In the case discussed above there is no additional dependency for the 436 subnet prefix with the exception of the EUI-64 and an IID dependency. 437 These will be discussed later in this document. 439 3.3.2. Addresses used by Embedded-RP (RFC3956) 441 Embedded-RP [18] reflects the concept of integrating the Rendezvous 442 Point (RP) IPv6 address into the IPv6 multicast group address. Due 443 to this embedding and the fact that the length of the IPv6 address 444 AND the IPv6 multicast address are 128 bits, it is not possible to 445 have the complete IPv6 address of the multicast RP embedded as such. 447 This resulted in a restriction of 15 possible RP-addresses per prefix 448 that can be used with embedded-RP. The space assigned for the 449 embedded-RP is based on the 4 low order bits, while the remainder of 450 the Interface ID is set to all '0'. 452 [IPv6-prefix (64 bits)][60 bits all '0'][RIID] 454 Where: [RIID] = 4 bit. 456 This format implies that when selecting subnet prefixes longer then 457 64, and the bits beyond the 64th one are none-zero, the subnet can 458 not use embedded-RP. 460 In addition it is discouraged to assign a matching embedded-RP IPv6 461 address to a device that is not a real Multicast Rendezvous Point. 463 3.3.3. ISATAP addresses 465 ISATAP [25] is an automatic tunneling protocol used to provide IPv6 466 connectivity over an IPv4 campus or enterprise environment. In order 467 to leverage the underlying IPv4 infrastructure, the IPv6 addresses 468 are constructed in a special format. 470 An IPv6 ISATAP [25] address has the IPv4 address embedded, based on a 471 predefined structure policy that identifies them as an ISATAP [25] 472 address. 474 [IPv6 Prefix (64 bits)][0000:5EFE][IPv4 address] 476 When using subnet prefix length longer then 64 bits it is recommended 477 that that the portion of the IPv6 prefix from bit 65 to the end of 478 the subnet prefix does not match with the well-known ISATAP [0000: 479 5EFE] address portion. 481 In its actual definition there is no multicast support on ISATAP 483 3.3.4. /126 addresses 485 The 126 bit subnet prefixes are typically used for point-to-point 486 links similar to the RFC3021 [5] recommendations for IPv4. The usage 487 of this subnet address length does not lead to any additional 488 considerations other than the ones discussed earlier in this section, 489 particularly those related to the "u" and "g" bits. 491 3.3.5. /127 addresses 493 The usage of the /127 addresses is not valid and should be strongly 494 discouraged as documented in RFC3627 [13]. 496 3.3.6. /128 addresses 498 The 128 bit address prefix may be used in those situations where we 499 know that one, and only one address is sufficient. Example usage 500 would be the off-link loopback address of a network device. 502 When choosing a 128 bit prefix, it is recommended to take the "u" and 503 "g" bits into consideration and to make sure that there is no overlap 504 with either the following well-known addresses: 505 o Subnet Router Anycast Address 506 o Reserved Subnet Anycast Address 507 o Addresses used by Embedded-RP 508 o ISATAP Addresses 510 4. Allocation of the IID of an IPv6 Address 512 In order to have a complete IPv6 address, an interface must be 513 associated a prefix and an Interface Identifier (IID). Section 3 of 514 this document analyzed the prefix selection considerations. This 515 section discusses the elements that should be considered when 516 assigning the IID portion of the IPv6 address. 518 There are various ways to allocate an IPv6 address to a device or 519 interface. The option with the least amount of caveats for the 520 network administrator is that of EUI-64 [2] based addresses. For the 521 manual or dynamic options, the overlap with well known IPv6 addresses 522 should be avoided. 524 4.1. Automatic EUI-64 Format Option 526 When using this method the network administrator has to allocate a 527 valid 64 bit subnet prefix. The EUI-64 [2] allocation procedure can 528 from that moment onwards assign the remaining 64 IID bits in a 529 stateless manner. All the considerations for selecting a valid IID 530 have been incorporated in the EUI-64 methodology. 532 4.2. Using Privacy Extensions 534 The main purpose of IIDs generated based on RFC3041 [6] is to provide 535 privacy to the entity using this address. While there are no 536 particular constraints in the usage of these addresses as defined in 537 [6] there are some implications to be aware of when using privacy 538 addresses as documented in section 4 of RFC3041 [6]: 539 o The privacy extension algorithm may complicate flexibility in 540 future transport protocols 541 o These addresses may add complexity to the operational management 542 and troubleshooting of the infrastructure (i.e. which address 543 belongs to which real host) 544 o A reverse DNS lookup check may be broken when using privacy 545 extensions 547 4.3. Cryptographically Generated IPv6 Addresses 549 Cryptographically Generated Addresses (CGAs) are based upon RFC3972 550 [20] and provide a method for binding a public signature key to an 551 IPv6 address in the Secure Neighbor Discovery (SEND) protocol [19]. 553 The basic idea is to generate the interface identifier (i.e. the 554 rightmost 64 bits) of the IPv6 address by computing a cryptographic 555 hash of the public key. The resulting IPv6 address is called a 556 cryptographically generated address (CGA). The corresponding private 557 key can then be used to sign messages sent from that address. 559 Implications to be aware of when using CGA addresses are found in 560 section 7 of RFC3972 [20]: 561 o When using CGA addresses the values of the "u" and "g" bits are 562 ignored however it does not add any security or implementation 563 implications 564 o There is no mechanism for proving that an address is not a CGA 565 o When it is discovered that a node has been compromised, a new 566 signature key and a new CGA should be generated 568 Due to the fact that CGA generated addresses are almost 569 indistinguishable from a privacy address and has similar properties 570 for many purposes, the same considerations as with privacy addresses 571 are also valid for CGA generated addresses. 573 4.4. Manual/Dynamic Assignment Option 575 This section discusses those IID allocations that are not implemented 576 through stateless address configuration (Section 4.1). They are 577 applicable regardless of the prefix length used on the link. It is 578 out of scope for this section to discuss the various assignment 579 methods (e.g. manual configuration, DHCPv6, etc). 581 In this situation the actual allocation is done by human intervention 582 and consideration needs to be given to the complete IPv6 address so 583 that it does not result in overlaps with any of the well known IPv6 584 addresses: 585 o Subnet Router Anycast Address 586 o Reserved Subnet Anycast Address 587 o Addresses used by Embedded-RP 588 o ISATAP Addresses 590 When using an address assigned by human intervention it is 591 recommended to choose IPv6 addresses which are not obvious to guess 592 and/or avoid any IPv6 addresses that embed IPv4 addresses used in the 593 current infrastructure. Following these two recommendations will 594 make it more difficult for malicious third parties to guess targets 595 for attack, and thus reduce security threats to a certain extent. 597 5. Case Studies 599 tbc. 601 5.1. Enterprise Considerations 603 In this section we consider a case study of a campus network that is 604 deploying IPv6 in parallel with existing IPv4 protocols in a dual- 605 stack environment. The specific example is the University of 606 Southampton (UK). The case study is a 'work in progress' as the 607 deployment is an evolving one, currently covering around 1,500 hosts. 609 5.1.1. Obtaining general IPv6 network prefixes 611 In the case of a campus network, the site will typically take its 612 connectivity from its National Research and Education Network (NREN). 613 Southampton connects to JANET, the UK academic network. JANET 614 currently has a /32 allocation from RIPE of 2001:630::/32. The 615 current recommended practice is for sites to receive a /48 616 allocation, and on this basis Southampton has received such a prefix 617 for its own use, specifically 2001:630:d0::/48. 619 No ULA addressing is used on site. The campus does not expect to 620 change service provider, and thus does not plan to use ULAs for the 621 (perceived) benefit of easing network renumbering. Indeed, the 622 campus has renumbered following the aforementioned renumbering 623 procedure [21] on two occasions, and this has proven adequate (with 624 provisos documented in [28]. We also do not see any need to deploy 625 ULAs for in or out of band network management; there are enough IPv6 626 prefixes available in the site allocation for the infrastructure. 628 No 6bone addressing is used on site. This was phased out some time 629 ago. We note that as of 6th June 2006 transit ISPs will likely 630 filter any attempted use of such prefixes. 632 Southampton does participate in global and organization scope IPv6 633 multicast networks. Multicast address allocations are not discussed 634 here as they are not in scope for the document. Embedded RP is in 635 use, and has been tested successfully across providers between sites. 637 5.1.2. Forming an address (subnet) allocation plan 639 The campus has a /16 prefix for IPv4 use; in principle 256 subnets of 640 256 addresses. In reality the subnetting is muddier, because of 641 concerns of IPv4 address conservation; subnets are sized to the hosts 642 within them, e.g. a /26 IPv4 prefix is used if a subnet has 35 hosts 643 in it. While this is efficient, it increases management burden when 644 physical deployments change, and IPv4 subnets require resizing (up or 645 down), even with DHCP in use. 647 The /48 IPv6 prefix is considerably larger than the IPv4 allocation 648 already in place at the site. It is loosely equivalent to a 'Class 649 A' IPv4 prefix in that it has 2^16 (over 65,000) subnets, but has an 650 effectively unlimited subnet address size (2^64) compared to 256 in 651 the IPv4 equivalent. The increased subnet size means that /64 IPv6 652 prefixes can be used on all subnets, without any requirement to 653 resize them at a later date. The increased subnet volume allows 654 subnets to be allocated more generously to schools and departments in 655 the campus. While address conservation is still important, it is no 656 longer an impediment on network management. Rather, address (subnet) 657 allocation is more about planning for future expansion. 659 In a dual-stack network, we chose to deploy our IP subnets 660 congruently for IPv4 and IPv6. This is because the systems are still 661 in the same administrative domains and the same geography. We do not 662 expect to have IPv6-only subnets in production use for a while yet, 663 outside test beds and our early Mobile IPv6 trials. The firewall 664 would ideally be a single dual-stack device with consistent policies 665 (by host rather than IP version), however this is currently 666 implemented as a firewall per IP protocol due to vendor limitations 667 (Nokia/Checkpoint for IPv4, BSD pf tool for IPv6). 669 The subnet allocation plan required a division of the address space 670 per school or department. Here a /56 was allocated to the school 671 level of the university; there are around 30 schools currently. 672 Further allocations were made for central IT infrastructure, for the 673 network infrastructure and the server side systems. 675 5.1.3. Other considerations 677 The network uses a Demilitarized Zone (DMZ) topology for some level 678 of protection of 'public' systems. Again, this topology is congruent 679 with the IPv4 network. 681 There are no specific transition methods deployed internally to the 682 campus; everything is using the conventional dual-stack approach. 683 There is no use of tools such as ISATAP for example. 685 For the Mobile IPv6 early trails, we have allocated one prefix for 686 Home Agent (HA) use. We have not yet considered how Mobile IPv6 687 usage may grow, and whether more or even every subnet will require HA 688 support. 690 The university operates a tunnel broker service on behalf of UKERNA. 691 This uses separate address space from JANET, not the main university 692 allocation. 694 5.1.4. Node configuration considerations 696 We currently use stateless autoconfiguration on most subnets for IPv6 697 hosts. There is no DHCPv6 service deployed yet, beyond tests of 698 early code releases. We do seek a common integrated DHCP/DNS 699 management platform, even if the servers themselves are not co- 700 located. Currently we add client statelessly autoconfigured 701 addresses to the DNS manually. Our administrators would prefer the 702 use of DHCP because they believe it gives them some management 703 control. 705 Regarding the [26] implications, we note that all our hosts are dual- 706 stack, and thus are potentially exposed over both protocols anyway. 707 We publish all addresses in DNS, and do not operate a two faced DNS. 709 We have internal usage of RFC3041 privacy addresses currently, but 710 may wish to administratively disable this (perhaps via DHCP), but we 711 need to determine the feasibility of this on all systems, e.g. for 712 WLAN guests or other user-maintained systems. Network management 713 should be simpler without RFC3041 in operation. Note RFC3041 is only 714 an issue for outbound connections. 716 We manually configure server addresses to avoid address changes on a 717 change of network adaptor. With IPv6 you can choose to pick ::53 for 718 a DNS server, or can pick 'random' addresses for obfuscation, though 719 that's not an issue for publicly advertised addresses (dns, mx, web, 720 etc). 722 5.1.5. Observations 724 The site is not (yet) using prefix delegation tools for IPv6. 726 5.2. Service Provider Considerations 728 In this section an IPv6 addressing schema is sketched that could 729 serve as an example by a Service Provider offering Internet Services 730 as well as Network Access services to millions of customers. In this 731 example, the Service Provider is assumed to operate an MPLS based 732 backbone and implements 6PE to provide IPv6 backbone transport 733 between the different locations (POPs) of a fully dual-stacked 734 network access and aggregation area. 736 Besides that it is assumed that the Service Provider 738 o has received a /20 from its RIR 739 o operates its own LIR 740 o has to address its own IPv6 infrastructure 741 o delegates prefixes from this aggregate to its customers. 743 Hence this addressing schema covers the numbering of the Service 744 Provider IPv6 network devices as well the customer aggregates chosen 745 out of the /20 prefix of the SP. 747 5.2.1. Investigation of objective Requirements for an IPv6 addressing 748 schema of a Service Provider 750 The first step of the IPv6 addressing plan design for a Service 751 provider should be the identification of all technical, operational, 752 political and business requirements that have to be satisfied by the 753 services supported by this addressing schema. 755 According to the different technical constraints and business models 756 as well as the different weights of these requirements (from the 757 point of view of the corresponding Service Provider) it is very 758 likely that different addressing schemas will be developed and 759 deployed by different ISPs. Nevertheless the addressing schema of 760 this section is one possible example. 762 5.2.1.1. Requirements for an IPv6 addressing schema from the LIR 763 perspective of the Service Provider 765 In their role as LIR the Service Providers have to care about the 766 policy constraints of the RIRs and the standards of the IETF 767 regarding IPv6 addressing. In this context, the following basic 768 requirements and recommendations have to be taken into account and 769 should be satisfied by the IPv6 address allocation plan of a Service 770 Provider: 771 o As recommended in RFC 3177 [7] and in several RIR policies 772 "Common" customers sites (normally private customers) should 773 receive a /48 prefix from the aggregate of the Service Provider. 774 (Note: The addressing plan must be flexible enough and take into 775 account the possible change of the minimum allocation size for end 776 users currently under definition by the RIRs.) 777 o "Big customers" (like big enterprises, governmental agencies etc.) 778 may receive shorter prefixes according to their needs when this 779 need could be documented and justified to the RIR. 780 o The IPv6 address allocation schema has to be able to meet the HD- 781 ratio of 0.94 as it is defined for IPv6. This requirement 782 corresponds to the demand for an efficient usage of the IPv6 783 address aggregate by the Service Provider. (Note: A HD-ratio of 784 0.94 means an effective usage of about 31% of the /20 of the 785 Service Provider on the basis of /48 assignments.) 786 o All assignments to customers have to be documented and stored into 787 a database that can also be queried by the RIR. 788 o The LIR has to make available means for supporting the reverse DNS 789 mapping of the customer prefixes. 791 5.2.1.2. IPv6 addressing schema requirements from the ISP perspective 792 of the Service Provider 794 From ISP perspective the following basic requirements could be 795 identified: 796 o The IPv6 address allocation schema must be able to realize a 797 maximal aggregation of all IPv6 address delegations to customers 798 into the /20 of the Service Provider. Only this /20 will be 799 routed and injected from the Service Provider into the global 800 routing table (DFZ). This strong aggregation keeps the routing 801 tables of the DFZ small and eases filtering and access control 802 very much. (Note: A strong aggregation e.g. on POP or LER basis 803 limits as well the numbers of customer routes that are visible 804 within the ISP network.) 805 o The IPv6 addressing schema of the SP should contain maximal 806 flexibility since the infrastructure of the SP will change over 807 the time with new customers, transport technologies and business 808 cases. The requirement of maximal flexibility is contrary to the 809 requirements of strong IPv6 address aggregation and efficient 810 address usage, but at this point each SP has to decide which of 811 these requirements to prioritize. 813 o Keeping the multilevel network hierarchy of an ISP in mind, due to 814 addressing efficiency reasons not all hierarchy levels can and 815 should be mapped into the IPv6 addressing schema of an ISP. 816 Sometimes it is much better to implement "flat" addressing for the 817 ISP network than to loose big chunks of the IPv6 address aggregate 818 in addressing each level of network hierarchy. Besides that a 819 decoupling of provider network addressing and customer addressing 820 is recommended. 822 5.2.1.3. IPv6 addressing schema requirements from the Network Access 823 provider perspective of the Service Provider 825 As already done for the LIR and the ISP roles of the SP it is also 826 necessary to identify requirements that come from its Network Access 827 Provider role. Some of the basic requirements are: 828 o The IPv6 addressing schema of the SP must be flexible enough to 829 adapt changes that are injected from the customer side. This 830 covers changes that are based on the raising IPv6 address needs of 831 the customer as well as changes that come from topological 832 modifications (e.g. when the customer moves from one point of 833 network attachment (POP) to another). 834 o For each IPv6 address assignment to customers a "buffer zone" must 835 be reserved that allows the customer to grow in its addressing 836 range without renumbering or assignment of additional prefixes. 837 o The IPv6 addressing schema of the SP must deal with multiple- 838 attachments of a single customer to the SP network infrastructure 839 (i.e. multi-homed network access with the same SP). 841 These few requirements are only part of all the requirements a 842 Service Provider has to investigate and keep in mind during the 843 definition phase of its addressing architecture. Each SP will most 844 likely add more constraints to this list. 846 5.2.2. IPv6 address allocation plan for a Service Provider 848 This section illustrates how the /20 IPv6 prefix of the SP can be 849 used to address the SP-own infrastructure and to delegate IPv6 850 prefixes to its customers following the above mentioned requirements 851 as far as possible. 853 The below figure summarizes the device types in an SP network and the 854 typical network design. The network hierarchy of the SP has to be 855 taken into account for the design of an IPv6 addressing schema and 856 defines its basic shape. 858 +------------------------------------------------------------------+ 859 | LSRs of the MPLS Backbone of the SP | 860 +------------------------------------------------------------------+ 861 | | | | | 862 | | | | | 863 +-----+ +-----+ +--------+ +--------+ +--------+ 864 | LER | | LER | | LER-BB | | LER-BB | | LER-BB | 865 +-----+ +-----+ +--------+ +--------+ +--------+ 866 | | | | | | / | | | 867 | | | | | | / | | | 868 | | | | +------+ +------+ +------+ | | 869 | | | | |BB-RAR| |BB-RAR| | AG | | | 870 | | | | +------+ +------+ +------+ | | 871 | | | | | | | | | | | | 872 | | | | | | | | | | | | 873 | | | | | | | | +-----+ +-----+ +-----+ +-----+ 874 | | | | | | | | | RAR | | RAR | | RAR | | RAR | 875 | | | | | | | | +-----+ +-----+ +-----+ +-----+ 876 | | | | | | | | | | | | | | | | 877 | | | | | | | | | | | | | | | | 878 +-------------------------------------------------------------------+ 879 | Customer networks | 880 +-------------------------------------------------------------------+ 881 Figure: Exemplary Service Provider Network 883 LSR ... Label Switch Router 884 LER ... Label Edge Router 885 LER-BB ... Broadband Label Edge Router 886 RAR ... Remote Access Router 887 BB-RAR ... Broadband Remote Access Router 888 AG ... Aggregation Router 890 Basic design decisions for the SP IPv6 address plan regarding 891 customer prefixes take into consideration: 892 o The prefixes assigned to all customers behind the same LER (e.g. 893 LER or LER-BB) are aggregated under one prefix. This ensures that 894 the number of labels that have to be used for 6PE is limited and 895 hence provides a strong MPLS label conservation. 896 o The /20 prefix of the SP is separated into 3 different pools that 897 are used to allocate IPv6 prefixes to the customers of the SP: 898 * A pool (e.g. /24) for satisfying the addressing needs of real 899 "big" customers (as defined in 5.2.2.1 sub-section A.) that 900 need IPv6 prefixes larger than /48 (e.g. /32). These customers 901 are assumed to be connected to several POPs of the access 902 network, so that this customer prefix will be visible in each 903 of these POPs. 905 * A pool (e.g. /24) for the LERs with direct customer connections 906 (e.g. dedicated line access) and without an additional 907 aggregation area between the customer and the LER. (These LERs 908 are mostly connected to a limited number of customers because 909 of the limited number of interfaces/ports.) 910 * A larger pool (e.g. 14*/24) for LERs (e.g. LER-BB) that serve 911 a high number of customers that are normally connected via some 912 kind of aggregation network (e.g. DSL customers behind a BB- 913 RAR or Dial-In customers behind a RAR). 914 * The IPv6 address delegation within each Pool (end customer 915 delegation or also the aggregates that are dedicated to the 916 LERs itself) should be chosen with an additional buffer zone of 917 300% for future growth. 919 5.2.2.1. Defining an IPv6 address allocation plan for customers of the 920 Service Provider 922 5.2.2.1.1. 'Big' customers 924 SP's "big" customers receive their prefix from the /24 IPv6 address 925 aggregate that has been reserved for their "big" customers. A 926 customer is considered as "big" customer if it has a very complex 927 network infrastructure and/or huge IPv6 address needs (e.g. because 928 of very large customer numbers) and/or several uplinks to different 929 POPs of the SP network. 931 The assigned IPv6 address prefixes can have a prefix length in the 932 range 32-48 and for each assignment a 300% future growing zone is 933 marked as "reserved" for this customer. This means that for instance 934 with a delegation of a /34 to a customer the /32 that contains this 935 /34 is reserved for the customer for future usage. 937 The prefixes for the "big" customers can be chosen from the 938 corresponding LER customer pool by either using an equidistant 939 algorithm or using mechanisms simililar to the Sparse Alocation 940 Algorithm (SAA) [27]. 942 5.2.2.1.2. 'Common' customers 944 All customers that are not "big" customers are considered as "common" 945 customers. They represent the majority of customers hence they 946 receive a /48 out of the IPv6 customer address pool of the LER where 947 they are directly connected or aggregated. 949 Again a 300% future growing IPv6 address range is reserved for each 950 customer, so that a "common" customer receives a /48 allocation but 951 has a /46 reserved. 953 In the network access scenarios where the customer is directly 954 connected to the LER the customer prefix is directly taken out of the 955 customer IPv6 address aggregate (e.g. /38) of the corresponding LER. 957 In all other cases (e.g. the customer is attached to a RAR that is 958 themselves aggregated to an AG or to a LER) at least 2 different 959 approaches are possible. 961 1.) Mapping of Aggregation Network Hierarchy into Customer IPv6 962 Addressing Schema. The aggregation network hierarchy could be mapped 963 into the design of the customer prefix pools of each network level in 964 order to achieve a maximal aggregation at the LER level as well as at 965 the intermediate levels. (Example: Customer - /48, RAR - /38, AG - 966 /32, LER-BB - /30). At each network level an adequate growing zone 967 should be reserved. (Note: This approach requires of course some 968 "fine tuning" of the addressing schema based on a very good knowledge 969 of the Service Provider network topology including actual growing 970 ranges and rates.) 972 When the IPv6 customer address pool of a LER (or another device of 973 the aggregation network - AG or RAR) is exhausted, the related LER 974 (or AG or RAR) prefix is shortened by 1 or 2 bits (e.g. from /38 to 975 /37 or /36) so that the originally reserved growing zone can be used 976 for further IPv6 address allocations to customers. In the case where 977 the growing zone is exhausted as well a new prefix range from the 978 corresponding pool of the next higher hierarchy level can be 979 requested. 981 2.) "Flat" Customer IPv6 Addressing Schema. The other option is to 982 allocate all the customer prefixes directly out of the customer IPv6 983 address pool of the LER where the customers are attached and 984 aggregated and ignore the intermediate aggregation network 985 infrastructure. This approach leads of course to a higher amount of 986 customer routes at LER and aggregation network level but takes a 987 great amount of complexity out of the addressing schema. 988 Nevertheless the aggregation of the customer prefixes to one prefix 989 at LER level is realized as required above. 991 If the actual observed growing rates show that the reserved growing 992 zones are not needed than these growing areas can be freed and used 993 for assignments for prefix pools to other devices at the same level 994 of the network hierarchy. 996 5.2.2.2. Defining an IPv6 address allocation plan for the Service 997 Provider Network Infrastructure 999 For the IPv6 addressing of SPs own network infrastructure a /32 (or 1000 /40) from the "big" customers address pool can be chosen. 1002 This SP infrastructure prefix is used to code the network 1003 infrastructure of the SP by assigning a /48 to every POP/location and 1004 using for instance a /56 for coding the corresponding router within 1005 this POP. Each SP internal link behind a router interface could be 1006 coded using a /64 prefix. (Note: While it is suggested to chose a 1007 /48 for addressing the POP/location of the SP network it is left to 1008 each SP to decide what prefix length to assign to the routers and 1009 links within this POP.) 1011 The IIDs of the router interfaces may be generated by using EUI-64 or 1012 through plain manual configuration e.g. for coding additional network 1013 or operational information into the IID. 1015 It is assumed that a 300% growing zones for each level of network 1016 hierarchy and additional prefixes may be assigned to POPs and/or 1017 routers if needed. 1019 Loopback interfaces of routers may be chosen from the first /64 of 1020 the /56 router prefix (in the example above). 1022 (Note: The /32 prefix that has been chosen for addressing SPs own 1023 IPv6 network infrastructure gives enough place to code additional 1024 functionalities like security levels or private and test 1025 infrastructure although such approaches haven't been considered in 1026 more detail for the above described SP until now.) 1028 Point-to-point links to customers (e.g. PPP links, dedicated line 1029 etc.) may be addressed using /126 prefixes out of the first /64 of 1030 the access routers that could be reserved for this reason. 1032 5.2.3. Additional Remarks 1034 5.2.3.1. ULA 1036 From the actual view point of SP there is no compelling reason why 1037 ULAs should be used from a SP. Look at section 2.2. 1039 ULAs could be used inside the SP network in order to have an 1040 additional "site-local scoped" IPv6 address for SPs own 1041 infrastructure for instance for network management reasons and maybe 1042 also in order to have an addressing schema that couldn't be reached 1043 from outside the SP network. 1045 In the case when ULAs are used it is possible to map the proposed 1046 internal IPv6 addressing of SPs own network infrastructure as 1047 described in 5.2.2.2 above directly to the ULA addressing schema by 1048 substituting the /48 POP prefix with a /48 ULA site prefix. 1050 5.2.3.2. Multicast 1052 IPv6 Multicast-related addressing issues are out of the scope of this 1053 document. 1055 5.2.3.3. POP Multi-homing or Change of POP 1057 POP (or better LER) Multi-homing of customers with the same SP can be 1058 realized within the proposed IPv6 addressing schema of the SP by 1059 assigning multiple LER-dependent prefixes to this customer (i.e. 1060 considering each customer location as a single-standing customer) or 1061 by choosing a customer prefix out of the pool of "big" customers. 1062 The second solution has the disadvantage that in every LER where the 1063 customer is attached this prefix will appear inside the IGP routing 1064 table requiring an explicit MPLS label. 1066 An equal effect happens when a customer changes its point of 1067 attachment to another POP/LER since in this case the customer prefix 1068 could not be aggregated into the LER prefix and needs to be 1069 advertised more specific in the IGP. 1071 (Note: The described negative POP/LER Multi-homing effects to the 1072 addressing architecture in the SP access network are not tackled by 1073 implementing the Shim6 Site Multi-homing approach since this approach 1074 targets only on a mechanism for dealing with multiple prefixes in end 1075 systems -- the SP will nevertheless have unaggregated customer 1076 prefixes in its internal routing tables.) 1078 5.2.3.4. Extensions needed for the later IPv6 migration phases 1080 The proposed IPv6 addressing schema for a SP needs some slight 1081 enhancements / modifications for the later phases of IPv6 1082 integration, for instance in the case when the whole MPLS backbone 1083 infrastructure (LDP, IGP etc.) is realized over IPv6 transport an 1084 addressing of the LSRs is needed. Other changes may be necessary as 1085 well but should not be explained at this point. 1087 6. IANA Considerations 1089 There are no extra IANA consideration for this document. 1091 7. Security Considerations 1093 This IPv6 addressing documents does not have any direct impact on 1094 Internet infrastructure security. 1096 8. Acknowledgements 1098 Constructive feedback and contributions have been received from Stig 1099 Venaas, Pekka Savola, John Spencer, Patrick Grossetete and Carlos 1100 Garcia Braschi. 1102 9. References 1104 9.1. Normative References 1106 9.2. Informative References 1108 [1] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. 1109 Lear, "Address Allocation for Private Internets", BCP 5, 1110 RFC 1918, February 1996. 1112 [2] Thomson, S. and T. Narten, "IPv6 Stateless Address 1113 Autoconfiguration", RFC 2462, December 1998. 1115 [3] Hinden, R., Fink, R., and J. Postel, "IPv6 Testing Address 1116 Allocation", RFC 2471, December 1998. 1118 [4] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast 1119 Addresses", RFC 2526, March 1999. 1121 [5] Retana, A., White, R., Fuller, V., and D. McPherson, "Using 31- 1122 Bit Prefixes on IPv4 Point-to-Point Links", RFC 3021, 1123 December 2000. 1125 [6] Narten, T. and R. Draves, "Privacy Extensions for Stateless 1126 Address Autoconfiguration in IPv6", RFC 3041, January 2001. 1128 [7] IAB and IESG, "IAB/IESG Recommendations on IPv6 Address 1129 Allocations to Sites", RFC 3177, September 2001. 1131 [8] Durand, A. and C. Huitema, "The H-Density Ratio for Address 1132 Assignment Efficiency An Update on the H ratio", RFC 3194, 1133 November 2001. 1135 [9] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. 1136 Carney, "Dynamic Host Configuration Protocol for IPv6 1137 (DHCPv6)", RFC 3315, July 2003. 1139 [10] Draves, R., "Default Address Selection for Internet Protocol 1140 version 6 (IPv6)", RFC 3484, February 2003. 1142 [11] Blanchet, M., "A Flexible Method for Managing the Assignment of 1143 Bits of an IPv6 Address Block", RFC 3531, April 2003. 1145 [12] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global Unicast 1146 Address Format", RFC 3587, August 2003. 1148 [13] Savola, P., "Use of /127 Prefix Length Between Routers 1149 Considered Harmful", RFC 3627, September 2003. 1151 [14] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host 1152 Configuration Protocol (DHCP) version 6", RFC 3633, 1153 December 2003. 1155 [15] Fink, R. and R. Hinden, "6bone (IPv6 Testing Address 1156 Allocation) Phaseout", RFC 3701, March 2004. 1158 [16] Droms, R., "Stateless Dynamic Host Configuration Protocol 1159 (DHCP) Service for IPv6", RFC 3736, April 2004. 1161 [17] Huitema, C. and B. Carpenter, "Deprecating Site Local 1162 Addresses", RFC 3879, September 2004. 1164 [18] Savola, P. and B. Haberman, "Embedding the Rendezvous Point 1165 (RP) Address in an IPv6 Multicast Address", RFC 3956, 1166 November 2004. 1168 [19] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 1169 Neighbor Discovery (SEND)", RFC 3971, March 2005. 1171 [20] Aura, T., "Cryptographically Generated Addresses (CGA)", 1172 RFC 3972, March 2005. 1174 [21] Baker, F., Lear, E., and R. Droms, "Procedures for Renumbering 1175 an IPv6 Network without a Flag Day", RFC 4192, September 2005. 1177 [22] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1178 Addresses", RFC 4193, October 2005. 1180 [23] Hinden, R. and S. Deering, "IP Version 6 Addressing 1181 Architecture", RFC 4291, February 2006. 1183 [24] Templin, F., Gleeson, T., Talwar, M., and D. Thaler, "Intra- 1184 Site Automatic Tunnel Addressing Protocol (ISATAP)", 1185 draft-ietf-ngtrans-isatap-24 (work in progress), January 2005. 1187 [25] Templin, F., Gleeson, T., Talwar, M., and D. Thaler, "Intra- 1188 Site Automatic Tunnel Addressing Protocol 1189 (draft-ietf-ngtrans-isatap-24.txt)", July 2005. 1191 [26] Chown, T., "IPv6 Implications for TCP/UDP Port Scanning (chown- 1192 v6ops- port-scanning-implications-02.txt)", October 2005. 1194 [27] APNIC, ARIN, RIPE NCC, "IPv6 Address Allocation and Assignment 1195 Policy (www.ripe.net/ripe/docs/ipv6policy.html)", January 2003. 1197 [28] Chown, T., Thompson, M., Ford, A., and S. Venaas, "Things to 1198 think about when Renumbering an IPv6 network 1199 (draft-chown-v6ops-renumber-thinkabout-03.txt)", July 2005. 1201 [29] Paul Wilson, Raymond Plzak, Axel Pawlik, "IPv6 Address Space 1202 Management (www.ripe.net/ripe/docs/ipv6-sparse.html)", 1203 February 2005. 1205 Authors' Addresses 1207 Gunter Van de Velde 1208 Cisco Systems 1209 De Kleetlaan 6a 1210 Diegem 1831 1211 Belgium 1213 Phone: +32 2704 5473 1214 Email: gunter@cisco.com 1216 Ciprian Popoviciu 1217 Cisco Systems 1218 7025-6 Kit Creek Road 1219 Research Triangle Park, North Carolina PO Box 14987 1220 USA 1222 Phone: +1 919 392-3723 1223 Email: cpopovic@cisco.com 1225 Tim Chown 1226 University of Southampton 1227 Highfield 1228 Southampton, SO17 1BJ 1229 United Kingdom 1231 Phone: +44 23 8059 3257 1232 Email: tjc@ecs.soton.ac.uk 1234 Olaf Bonness 1235 T-Systems Enterprise Services GmbH 1236 Goslarer Ufer 35 1237 Berlin, 10589 1238 Germany 1240 Phone: +49 30 3497 3124 1241 Email: Olaf.Bonness@t-systems.com 1242 Christian Hahn 1243 T-Systems Enterprise Services GmbH 1244 Goslarer Ufer 35 1245 Berlin, 10589 1246 Germany 1248 Phone: +49 30 3497 3164 1249 Email: HahnC@t-systems.com 1251 Intellectual Property Statement 1253 The IETF takes no position regarding the validity or scope of any 1254 Intellectual Property Rights or other rights that might be claimed to 1255 pertain to the implementation or use of the technology described in 1256 this document or the extent to which any license under such rights 1257 might or might not be available; nor does it represent that it has 1258 made any independent effort to identify any such rights. Information 1259 on the procedures with respect to rights in RFC documents can be 1260 found in BCP 78 and BCP 79. 1262 Copies of IPR disclosures made to the IETF Secretariat and any 1263 assurances of licenses to be made available, or the result of an 1264 attempt made to obtain a general license or permission for the use of 1265 such proprietary rights by implementers or users of this 1266 specification can be obtained from the IETF on-line IPR repository at 1267 http://www.ietf.org/ipr. 1269 The IETF invites any interested party to bring to its attention any 1270 copyrights, patents or patent applications, or other proprietary 1271 rights that may cover technology that may be required to implement 1272 this standard. Please address the information to the IETF at 1273 ietf-ipr@ietf.org. 1275 Disclaimer of Validity 1277 This document and the information contained herein are provided on an 1278 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1279 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1280 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1281 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1282 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1283 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1285 Copyright Statement 1287 Copyright (C) The Internet Society (2006). This document is subject 1288 to the rights, licenses and restrictions contained in BCP 78, and 1289 except as set forth therein, the authors retain all their rights. 1291 Acknowledgment 1293 Funding for the RFC Editor function is currently provided by the 1294 Internet Society.