idnits 2.17.1 draft-ietf-v6ops-addcon-00.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 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 893. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 870. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 877. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 883. ** 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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 13 instances of too long lines in the document, the longest one being 1 character in excess of 72. == 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 1, 2006) is 6540 days in the past. Is this intentional? 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 445 == Unused Reference: '24' is defined on line 814, 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: 5 errors (**), 0 flaws (~~), 5 warnings (==), 18 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 June 1, 2006 9 IPv6 Unicast Address Assignment Considerations 10 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on December 3, 2006. 37 Copyright Notice 39 Copyright (C) The Internet Society (2006). 41 Abstract 43 One fundamental aspect of any IP communications infrastructure is its 44 addressing plan. With its new address architecture and allocation 45 policies, the introduction of IPv6 into a network means that network 46 designers and operators need to reconsider their existing approaches 47 to network addressing. Lack of guideliness on handling this aspect 48 of network design could slow down the integration of IPv6. This 49 draft aims to provide the information and recommendations relevant to 50 planning the addressing aspects of IPv6 deployments. The draft also 51 provides IPv6 addressing case studies for both an enterprise and an 52 ISP network. In this first version of the draft we aim to provoke 53 discussion on this important topic; more detailed case study texts 54 will follow. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Network Level Addressing Design Considerations . . . . . . . . 4 60 2.1. Global Unique Addresses . . . . . . . . . . . . . . . . . 4 61 2.2. Unique Local IPv6 Addresses . . . . . . . . . . . . . . . 4 62 2.3. 6Bone Address Space . . . . . . . . . . . . . . . . . . . 5 63 2.4. Network Level Design Considerations . . . . . . . . . . . 6 64 2.4.1. Sizing the Network Allocation . . . . . . . . . . . . 7 65 2.4.2. Address Space Conservation . . . . . . . . . . . . . . 7 66 3. Subnet Prefix Considerations . . . . . . . . . . . . . . . . . 7 67 3.1. Considerations for subnet prefixes shorter then /64 . . . 7 68 3.2. Considerations for /64 prefixes . . . . . . . . . . . . . 8 69 3.3. Considerations for subnet prefixes longer then /64 . . . . 8 70 3.3.1. Anycast addresses . . . . . . . . . . . . . . . . . . 8 71 3.3.2. Addresses used by Embedded-RP (RFC3956) . . . . . . . 10 72 3.3.3. ISATAP addresses . . . . . . . . . . . . . . . . . . . 10 73 3.3.4. /126 addresses . . . . . . . . . . . . . . . . . . . . 11 74 3.3.5. /127 addresses . . . . . . . . . . . . . . . . . . . . 11 75 3.3.6. /128 addresses . . . . . . . . . . . . . . . . . . . . 11 76 4. Allocation of the IID of an IPv6 Address . . . . . . . . . . . 11 77 4.1. Automatic EUI-64 Format Option . . . . . . . . . . . . . . 12 78 4.2. Using Privacy Extensions . . . . . . . . . . . . . . . . . 12 79 4.3. Cryptographically Generated IPv6 Addresses . . . . . . . . 12 80 4.4. Manual/Dynamic Assignment Option . . . . . . . . . . . . . 13 81 5. Case Studies . . . . . . . . . . . . . . . . . . . . . . . . . 13 82 5.1. Enterprise Considerations . . . . . . . . . . . . . . . . 13 83 5.1.1. Obtaining general IPv6 network prefixes . . . . . . . 13 84 5.1.2. Forming an address (subnet) allocation plan . . . . . 14 85 5.1.3. Other considerations . . . . . . . . . . . . . . . . . 15 86 5.1.4. Node configuration considerations . . . . . . . . . . 15 87 5.1.5. Observations . . . . . . . . . . . . . . . . . . . . . 16 88 5.2. Service Provider Considerations . . . . . . . . . . . . . 16 89 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 90 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 91 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 92 8.1. Normative References . . . . . . . . . . . . . . . . . . . 16 93 8.2. Informative References . . . . . . . . . . . . . . . . . . 16 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 95 Intellectual Property and Copyright Statements . . . . . . . . . . 20 97 1. Introduction 99 The Internet Protocol Version 6 (IPv6) Addressing Architecture [23] 100 defines three main types of addresses: unicast, anycast and 101 multicast. This document focuses on unicast addresses, for which 102 there are currently three principal allocated types: Global Unique 103 Addresses [12] ('globals'), Unique Local IPv6 Addresses [22] (ULAs) 104 and 6bone address space [3]. 106 The document covers aspects that should be considered during IPv6 107 deployment for the design and planning of an addressing scheme for an 108 IPv6 network. The network's IPv6 addressing plan may be for an IPv6- 109 only network, or for a dual-stack infrastructure where some or all 110 devices have addresses in both protocols. These considerations will 111 help an IPv6 network designer to efficiently and prudently assign the 112 IPv6 address space that has been allocated to its organization. 114 The address assignment considerations are analyzed separately for the 115 two major components of the IPv6 unicast addresses, namely 'Network 116 Level Addressing' (the allocation of subnets) and the 'Subnet Prefix' 117 (address usage within a subnet). Thus the document includes a 118 discussion of aspects of address assignment to nodes and interfaces 119 in an IPv6 network. Finally the document will provide two examples 120 of a successfully deployed address plan in a service provider (ISP) 121 and an enterprise network. 123 Parts of this document highlight the differences that an experienced 124 IPv4 network designer should consider when planning an IPv6 125 deployment, for example: 127 o IPv6 devices will more likely be multi-addressed in comparison 128 with their IPv4 counterparts. 129 o The practically unlimited size of an IPv6 subnet (2^64 bits) 130 reduces the requirement to size subnets to device counts for the 131 purposes of (IPv4) address conservation. 132 o Eventhough there is no broadcast for the IPv6 protocol, there is 133 still need to consider the number of devices in a given subnet due 134 to traffic storm and level of traffic generated by hosts. 135 o The implications of the reduced threat of address-based host 136 scanning, as discussed in [26]. 138 We do not discuss here how a site or ISP should proceed with 139 acquiring its globally routable IPv6 address prefix. However, one 140 should note that IPv6 networks receive their global unicast address 141 allocation from their 'upstream' provider, which may be another ISP, 142 a Local Internet Registry (LIR) or a Regional Internet Registry 143 (RIR). In each case the prefix received is provider assigned (PA); 144 there is currently no provider independent (PI) address space for 145 IPv6. Thus an IPv6 network which changes provider will need to 146 undergo a renumbering process, as described in [21]. A separate 147 document [28] makes recommendations to ease the IPv6 renumbering 148 process. 150 This document neither discusses implemention aspects between ULA 151 addresses and Site-local addresses. Most implementations know about 152 Site-local addresses even though they are deprecated, and do not know 153 about ULAs - even though they are according current specification. 154 As result transitioning between these types of addresses may cause 155 difficulties. 157 2. Network Level Addressing Design Considerations 159 This section discusses the kind of IPv6 addresses used at the network 160 level for the IPv6 infrastructure. The kind of addresses that can be 161 considered are Global Unique Addresses, ULAs and 6bone address space. 163 2.1. Global Unique Addresses 165 The most commonly used unicast addresses will be Global Unique 166 Addresses ('globals'). No significant considerations are neccesary 167 if the organization has an address space assignment and a single 168 prefix is deployed through a single upstream provider. 170 However, a multihomed site may deploy addresses from two or more 171 Service Provider assigned IPv6 address ranges. Here, the network 172 Administrator must have awareness on where and how these ranges are 173 used on the multihomed infrastructure environment. The nature of the 174 usage of multiple prefixes may depend on the reason for multihoming 175 (e.g. resilience failover, load balancing, policy-based routing, or 176 multihoming during an IPv6 renumbering event). IPv6 introduces 177 improved support for multi-addressed hosts through the IPv6 default 178 address selection methods described in RFC3484 [10]. A multihomed 179 host may thus have two addresses, one per prefix (provider), and 180 select source and destination addresses to use as described in that 181 RFC. 183 2.2. Unique Local IPv6 Addresses 185 ULAs have replaced the originally conceived Site Local addresses in 186 the IPv6 addressing architecture, for reasons described in [17]. 187 ULAs improve on site locals by offering a high probability of the 188 global uniqueness of the prefix used, which can be beneficial in the 189 case of (deliberate or accidental) leakage, or where networks are 190 merged. ULAs are akin to the private address space [1] assigned for 191 IPv4 networks. 193 The ULA address range allows a network administrator to deploy IPv6 194 addresses on their network without asking for a globally unique 195 registered IPv6 address range. A ULA prefix is 48 bits, i.e. a /48, 196 the same as the currently recommended allocation for a site from the 197 globally routable IPv6 address space [7]. 199 ULAs provide the means to deploy a fixed addressing scheme that is 200 not affected by a change in service provider and the corresponding PA 201 global addresses. Internal operation of the network is thus 202 unaffected during renumbering events. Nevertheless, this type of 203 address must be used with caution. 205 A site using ULAs may or may not also deploy globals. In an isolated 206 network ULAs may be deployed on their own. In a connected network, 207 that also deploys global addresses, both may be deployed, such that 208 hosts become multiaddressed (one global and one ULA address) and the 209 IPv6 default address selection algorithm will pick the appropriate 210 source and destination addresses to use, e.g. ULAs will be selected 211 where both the source and destination hosts have ULA addresses. 212 Because a ULA and a global site prefix are both /48 length, an 213 administrator can choose to use the same subnetting (and host 214 addressing) plan for both prefixes. 216 As an example of the problems ULAs may cause, when using IPv6 217 multicast within the network, the IPv6 default address selection 218 algorithm prefers the ULA address as the source address for the IPv6 219 multicast streams. This is NOT a valid option when sending an IPv6 220 multicast stream to the IPv6 Internet for two reasons. For one, 221 these addresses are not globally routable so RPF checks for such 222 traffic will fail outside the internal network. The other reason is 223 that the traffic will likely not cross the network boundary due to 224 multicast domain control and perimeter security policies. 226 In principal ULAs allow easier network mergers than RFC1918 addresses 227 do for IPv4 because ULA prefixes have a high probability of 228 uniqueness, if the prefix is chosen as described in the RFC. 230 The usage of ULAs should be carefully considered even when not 231 attached to the IPv6 Internet due to the potential for added 232 complexity when connecting to the Internet at some point in the 233 future. 235 2.3. 6Bone Address Space 237 The 6Bone address space was used before the RIRs started to 238 distribute 'production' IPv6 prefixes. The 6Bone prefixes have a 239 common first 16 bits in the IPv6 Prefix of 3FFE::/16. This address 240 range is deprecated as of 6th June 2006 [15] and should be avoided on 241 any new IPv6 network deployments. Sites using 6bone address space 242 should renumber to production address space using procedures as 243 defined in [21]. 245 2.4. Network Level Design Considerations 247 IPv6 provides network administrators with a significantly larger 248 address space, enabling them to be very creative in how they can 249 define logical and practical address plans. The subneting of 250 assigned prefixes can be done based on various logical schemes that 251 involve factors such as: 252 o Geographical Boundaries - by assigning a common prefix to all 253 subnets within a geographical area. 254 o Organizational Boundaries - by assigning a common prefix to an 255 entire organization or group within a corporate infrastructure. 256 o Service Type - by reserving certain prefixes for predefined 257 services such as: VoIP, Content Distribution, wireless services, 258 Internet Access, etc. 259 Such logical addressing plans have the potential to simplify network 260 operations and service offerings, and to simplify network management 261 and troubleshooting. A very large network would also have no need to 262 consider using private address space for its infrastructure devices, 263 simplifying network management. 265 The network designer must however keep in mind several factors when 266 developing these new addressing schemes: 267 o Prefix Aggregation - The larger IPv6 addresses can lead to larger 268 routing tables unless network designers are actively pursuing 269 aggregation. While prefix aggregation will be enforced by the 270 service provider, it is beneficial for the individual 271 organizations to observe the same principles in their network 272 design process. 273 o Network growth - The allocation mechanism for flexible growth of a 274 network prefix, documented in RFC3531 [11] can be used to allow 275 the network infrastructure to grow and be numbered in a way that 276 is likely to preserve aggregation (the plan leaves 'holes' for 277 growth). 278 o ULA usage in large networks - Networks which have a large number 279 of 'sites' that each deploy a ULA prefix which will by default be 280 a 'random' /48 under fc00::/7 will have no aggregation of those 281 prefixes. Thus the end result may be cumbersome because the 282 network will have large amounts of non-aggregated ULA prefixes. 283 However, there is no rule to disallow large networks to use a 284 single ULA for all 'sites', as a ULA still provides 16 bits for 285 subnetting to be used internally. 287 2.4.1. Sizing the Network Allocation 289 We do not discuss here how a network designer sizes their application 290 for address space. By default a site will receive a /48 prefix [7]. 291 The default provider allocation via the RIRs is currently a /32 [27]. 292 These allocations are indicators for a first allocation for a 293 network. Different sizes may be obtained based on the anticipated 294 address usage [27]. There are examples of allocations as large as 295 /19 having been made from RIRs to providers at the time of writing. 297 2.4.2. Address Space Conservation 299 Despite the large IPv6 address space which enables easier subneting, 300 it still is important to ensure an efficient use of this resource. 301 Some addressing schemes, while facilitating aggregation and 302 management, could lead to significant numbers of addresses being 303 unused. Address conservation requirements are less stringent in IPv6 304 but they should still be observed. 306 The proposed HD [8] value for IPv6 is 0.94 compared to the current 307 value of 0.96 for IPv4. Note that for IPv6 HD is calculated for 308 sites, instead of based on addresses like with IPv4. 310 3. Subnet Prefix Considerations 312 This section analyzes the considerations applied to define the subnet 313 prefix of the IPv6 addresses. The boundaries of the subnet prefix 314 allocation are specified in RFC4291 [23]. In this document we 315 analyze their practical implications. Based on RFC4291 [23] it is 316 legal for any IPv6 unicast address starting with binary address '000' 317 to have a subnet prefix larger than, smaller than or of equal to 64 318 bits. Each of these three options are discussed in this document. 320 3.1. Considerations for subnet prefixes shorter then /64 322 An allocation of a prefix shorter then 64 bits to a node or interface 323 is bad practice. The shortest subnet prefix that could theoretically 324 be assigned to an interface or node is limited by the size of the 325 network prefix allocated to the organization. 327 A possible reason for choosing the subnet prefix for an interface 328 shorter then /64 is that it would allow more nodes to be attached to 329 that interface compared to a prescribed length of 64 bits. This 330 however is unnecessary considering that 2^64 provides plenty of node 331 addresses for a well designed IPv6 network. Layer two technologies 332 are unlikely to support such large numbers of nodes within a single 333 link (e.g. Ethernet limited to 48-bits of hosts) 334 The subnet prefix assignments can be made either by manual 335 configuration, by a stateful Host Configuration Protocol [9] or by a 336 stateful prefix delegation mechanism [14]. 338 3.2. Considerations for /64 prefixes 340 Based on RFC3177 [7], 64 bits is the prescribed subnet prefix length 341 to allocate to interfaces and nodes. 343 When using a /64 subnet length, the address assignment for these 344 addresses can be made either by manual configuration, by a stateful 345 Host Configuration Protocol [9] [16] or by stateless 346 autoconfiguration [2]. 348 Note that RFC3177 strongly prescribes 64 bit subnets for general 349 usage, and that stateless autoconfiguration option is only defined 350 for 64 bit subnets. 352 3.3. Considerations for subnet prefixes longer then /64 354 Address space conservation is the main motivation for using a subnet 355 prefix length longer than 64 bits. 357 The address assignment can be made either by manual configuration or 358 by a stateful Host Configuration Protocol [9]. 360 When assigning a subnet prefix of more then 80 bits, according to 361 RFC4291 [23] "u" and "g" bits (respectively the 81st and 82nd bit) 362 need to be taken into consideration and should be set correctly. In 363 currently implemented IPv6 protocol stacks, the relevance of the "u" 364 (universal/local) bit and "g" (the individual/group) bit are marginal 365 and typically will not show an issue when configured wrongly, however 366 future implementations may turn out differently. 368 When using subnet lengths longer then 64 bits, it is important to 369 avoid selecting addresses that may have a predefined use and could 370 confuse IPv6 protocol stacks. The alternate usage may not be a 371 simple unicast address in all cases. The following points should be 372 considerated when selecting a subnet length longer then 64 bits 373 subnet prefix length. 375 3.3.1. Anycast addresses 377 3.3.1.1. Subnet Router Anycast Address 379 RFC4291 [23] provides a definition for the required Subnet Router 380 Anycast Address as follows: 382 | n bits | 128-n bits | 383 +------------------------------------------------+----------------+ 384 | subnet prefix | 00000000000000 | 385 +------------------------------------------------+----------------+ 387 It is recommended to avoid allocating this IPv6 address to a device 388 which is not a router. no additional dependancy for the subnet prefix 389 with the exception of the EUI-64 and an IID dependency. These will 390 be discussed later in this document. 392 3.3.1.2. Reserved IPv6 Subnet Anycast Addresses 394 RFC2526 [4] stated that within each subnet, the highest 128 interface 395 identifier values are reserved for assignment as subnet anycast 396 addresses. 398 The construction of a reserved subnet anycast address depends on the 399 type of IPv6 addresses used within the subnet, as indicated by the 400 format prefix in the addresses. 402 The first type of Subnet Router Anycast addresses have been defined 403 as follows for EUI-64 format: 405 | 64 bits | 57 bits | 7 bits | 406 +---------------------------------+------------------+------------+ 407 | subnet prefix | 1111110111...111 | anycast ID | 408 +---------------------------------+------------------+------------+ 410 The anycast address structure implies that it is important to avoid 411 creating a subnet prefix where the bits 65 to 121 are defined as 412 "1111110111...111" (57 bits in total) so that confusion can be 413 avoided. 415 For other IPv6 address types (that is, with format prefixes other 416 than those listed above), the interface identifier is not in EUI-64 417 format and may be other than 64 bits in length; these reserved subnet 418 anycast addresses for such address types are constructed as follows: 420 | n bits | 121-n bits | 7 bits | 421 +---------------------------------+------------------+------------+ 422 | subnet prefix | 1111111...111111 | anycast ID | 423 +---------------------------------+------------------+------------+ 424 | interface identifier field | 426 In the case discussed above there is no additional dependancy for the 427 subnet prefix with the exception of the EUI-64 and an IID dependency. 428 These will be discussed later in this document. 430 3.3.2. Addresses used by Embedded-RP (RFC3956) 432 Embedded-RP [18] reflects the concept of integrating the Rendezvous 433 Point (RP) IPv6 address into the IPv6 multicast group address. Due 434 to this embedding and the fact that the length of the IPv6 address 435 AND the IPv6 multicast address are 128 bits, it is not possible to 436 have the complete IPv6 address of the multicast RP embedded as such. 438 This resulted in a restriction of 15 possible RP-addresses per prefix 439 that can be used with embedded-RP. The space assigned for the 440 embedded-RP is based on the 4 low order bits, while the remainder of 441 the Interface ID is set to all '0'. 443 [IPv6-prefix (64 bits)][60 bits all '0'][RIID] 445 Where: [RIID] = 4 bit. 447 Consequently this leads to the awareness that when when selecting 448 subnet prefixes longer then 64, where the bits beyond the 64th bit 449 are none-zero embedded-RP can not be used for that subnet. 451 In addition it is discouraged to assign a matching embedded-RP IPv6 452 address to a device that is not a real Multicast RendezVous Point. 454 3.3.3. ISATAP addresses 456 ISATAP [25] is an automatic tunneling protocol used to provide IPv6 457 connectivity over an IPv4 campus or enterprise environment. In order 458 to leverage the underlying IPv4 infrastructure, the IPv6 addresses 459 are constructed in a special format. 461 An IPv6 ISATAP [25] address has the IPv4 address embedded, based on a 462 predefined structure policy that identifies them as an ISATAP [25] 463 address. 465 [IPv6 Prefix (64 bits)][0000:5EFE][IPv4 address] 467 When using subnet prefix length longer then 64 bits it is recommended 468 that that the portion of the IPv6 prefix from bit 65 to the end of 469 the subnet prefix does not match with the welknown ISATAP [0000:5EFE] 470 address portion. 472 In its actual definition there is no multicast support on ISATAP 474 3.3.4. /126 addresses 476 The 126 bit subnet prefixes are typically used for point-to-point 477 links similar to the RFC3021 [5] recommendations for IPv4. The usage 478 of this subnet address length does not lead to any additional 479 considerations other than the ones discussed earlier in this section, 480 particularly those related to the "u" and "g" bits. 482 3.3.5. /127 addresses 484 The usage of the /127 addresses is not valid and should be strongly 485 discouraged as documented in RFC3627 [13]. 487 3.3.6. /128 addresses 489 The 128 bit address prefix may be used in those situations where we 490 know that one, and only one address is sufficient. Example usage 491 would be the offlink loopback address of a network device. 493 When choosing a 128 bit prefix, it is recommended to take the "u" and 494 "g" bits into consideration and to make sure that there is no overlap 495 with either the following well known addresses: 496 o Subnet Router Anycast Address 497 o Reserved Subnet Anycast Address 498 o Addresses used by Embedded-RP 499 o ISATAP Addresses 501 4. Allocation of the IID of an IPv6 Address 503 In order to have a complete IPv6 address, an interface must be 504 associated a prefix and an Interface Identifier (IID). Section 3 of 505 this document analyzed the prefix selection considerations. This 506 section discusses the elements that should be considered when 507 assigning the IID portion of the IPv6 address. 509 There are various ways to allocate an IPv6 address to a device or 510 interface. The option with the least amount of caveats for the 511 network administrator is that of EUI-64 [2] based addresses. For the 512 manual or dynamic options, the overlap with well known IPv6 addresses 513 should be avoided. 515 4.1. Automatic EUI-64 Format Option 517 When using this method the network administrator has to allocate a 518 valid 64 bit subnet prefix. The EUI-64 [2] allocation procedure can 519 from that moment onwards assign the remaining 64 IID bits in a 520 stateless manner. All the considerations for selecting a valid IID 521 have been incorporated in the EUI-64 methodology. 523 4.2. Using Privacy Extensions 525 The main purpose of IIDs generated based on RFC3041 [6] is to provide 526 privacy to the entity using this address. While there is no 527 particular restraints in the usage of these addresses as defined in 528 [6] there are some implications to be aware of when using privacy 529 addresses as documented in section 4 of RFC3041 [6]: 530 o The privacy extension algoritm may complicate flexibility in 531 future transport protocols 532 o These addresses may add complexity to the operational management 533 and troubleshooting of the infrastructure (i.e. which address 534 belongs to which real host) 535 o A reverse DNS lookup check may be broken when using privacy 536 extensions 538 4.3. Cryptographically Generated IPv6 Addresses 540 Cryptographically Generated Addresses (CGAs) are based upon RFC3972 541 [20] and provide a method for binding a public signature key to an 542 IPv6 address in the Secure Neighbor Discovery (SEND) protocol [19]. 544 The basic idea is to generate the interface identifier (i.e. the 545 rightmost 64 bits) of the IPv6 address by computing a cryptographic 546 hash of the public key. The resulting IPv6 address is called a 547 cryptographically generated address (CGA). The corresponding private 548 key can then be used to sign messages sent from that address. 550 Implications to be aware of when using CGA addresses are found in 551 section 7 of RFC3972 [20]: 552 o When using CGA addresses the values of the "u" and "g" bits are 553 ignored however it does not add any security or implementation 554 implications 555 o There is no mechanism for proving that an address is not a CGA 556 o When it is discovered that a node has been compromised, a new 557 signature key and a new CGA should be generated 559 Due to the fact that CGA generated addresses are almost 560 indistinguishable from a privacy address and has similar properties 561 for many purposes, the same considerations as with privacy addresses 562 are also valid for CGA generated addresses. 564 4.4. Manual/Dynamic Assignment Option 566 This section discusses those IID allocations that are not implemented 567 through stateless address configuration (Section 4.1). They are 568 applicable regardless of the prefix length used on the link. It is 569 out of scope for this section to discuss the various assignment 570 methods (e.g. manual configuration, DHCPv6, etc). 572 In this situation the actual allocation is done by human intervention 573 and consideration needs to be given to the complete IPv6 address so 574 that it does not result in overlaps with any of the well known IPv6 575 addresses: 576 o Subnet Router Anycast Address 577 o Reserved Subnet Anycast Address 578 o Addresses used by Embedded-RP 579 o ISATAP Addresses 581 When using an address assigned by human intervention it is 582 recommended to choose IPv6 addresses which are not abvious to guess 583 and/or avoid any IPv6 addresses that embed IPv4 addresses used in the 584 current infrastructure. Following these two recommendations will 585 make it more difficult for malicious third parties to guess targets 586 for attack, and thus reduce security threats to a certain extent. 588 5. Case Studies 590 tbc. 592 5.1. Enterprise Considerations 594 In this section we consider a case study of a campus network that is 595 deploying IPv6 in parallel with existing IPv4 protocols in a dual- 596 stack environment. The specific example is the University of 597 Southampton (UK). The case study is a 'work in progress' as the 598 deployment is an evolving one, currently covering around 1,500 hosts. 600 5.1.1. Obtaining general IPv6 network prefixes 602 In the case of a campus network, the site will typically take its 603 connectivity from its National Research and Education Network (NREN). 604 Southampton connects to JANET, the UK academic network. JANET 605 currently has a /32 allocation from RIPE of 2001:630::/32. The 606 current recommended practice is for sites to receive a /48 607 allocation, and on this basis Southampton has received such a prefix 608 for its own use, specifically 2001:630:d0::/48. 610 No ULA addressing is used on site. The campus does not expect to 611 change service provider, and thus does not plan to use ULAs for the 612 (perceived) benefit of easing network renumbering. Indeed, the 613 campus has renumbered following the aforementioned renumbering 614 procedure [21] on two occassions, and this has proven adequate (with 615 provisos documented in [28]. We also do not see any need to deploy 616 ULAs for in or out of band network management; there are enough IPv6 617 prefixes available in the site allocation for the infrastructure. 619 No 6bone addressing is used on site. This was phased out some time 620 ago. We note that as of 6th June 2006 transit ISPs will likely 621 filter any attempted use of such prefixes. 623 Southampton does participate in global and organisation scope IPv6 624 multicast networks. Multicast address allocations are not discussed 625 here as they are not in scope for the document. Embedded RP is in 626 use, and has been tested successfully across providers between sites. 628 5.1.2. Forming an address (subnet) allocation plan 630 The campus has a /16 prefix for IPv4 use; in principle 256 subnets of 631 256 addresses. In reality the subnetting is muddier, because of 632 concerns of IPv4 address conservation; subnets are sized to the hosts 633 within them, e.g. a /26 IPv4 prefix is used if a subnet has 35 hosts 634 in it. While this is efficient, it increases management burden when 635 physical deployments change, and IPv4 subnets require resizing (up or 636 down), even with DHCP in use. 638 The /48 IPv6 prefix is considerably larger than the IPv4 allocation 639 already in place at the site. It is loosely equivalent to a 'Class 640 A' IPv4 prefix in that it has 2^16 (over 65,000) subnets, but has an 641 effectively unlimited subnet address size (2^64) compared to 256 in 642 the IPv4 equivalent. The increased subnet size means that /64 IPv6 643 prefixes can be used on all subnets, without any requirement to 644 resize them at a later date. The increased subnet volume allows 645 subnets to be allocated more generously to schools and departments in 646 the campus. While address conservation is still important, it is no 647 longer an impediment on network management. Rather, address (subnet) 648 allocation is more about planning for future expansion. 650 In a dual-stack network, we chose to deploy our IP subnets 651 congruently for IPv4 and IPv6. This is because the systems are still 652 in the same administrative domains and the same geography. We do not 653 expect to have IPv6-only subnets in production use for a while yet, 654 outside testbeds and our early Mobile IPv6 trials. The firewall 655 would ideally be a single dual-stack device with consistent policies 656 (by host rather than IP version), however this is currently 657 implemented as a firewall per IP protocol due to vendor limitations 658 (Nokia/Checkpoint for IPv4, BSD pf tool for IPv6). 660 The subnet allocation plan required a division of the address space 661 per school or department. Here a /56 was allocated to the school 662 level of the university; there are around 30 schools currently. 663 Further allocations were made for central IT infrastructure, for the 664 network infrastructure and the server side systems. 666 5.1.3. Other considerations 668 The network uses a Demilitarized Zone (DMZ) topology for some level 669 of protection of 'public' systems. Again, this topology is congruent 670 with the IPv4 network. 672 There are no specific transition methods deployed internally to the 673 campus; everything is using the conventional dual-stack approach. 674 There is no use of tools such as ISATAP for example. 676 For the Mobile IPv6 early trails, we have allocated one prefix for 677 Home Agent (HA) use. We have not yet considered how Mobile IPv6 678 usage may grow, and whether more or even every subnet will require HA 679 support. 681 The university operates a tunnel broker service on behalf of UKERNA. 682 This uses separate address space from JANET, not the main university 683 allocation. 685 5.1.4. Node configuration considerations 687 We currently use stateless autoconfiguration on most subnets for IPv6 688 hosts. There is no DHCPv6 service deployed yet, beyond tests of 689 early code releases. We do seek a common integrated DHCP/DNS 690 management platform, even if the servers themselves are not 691 colocated. Currently we add client statelessly autoconfigured 692 addresses to the DNS manually. Our administrators would prefer the 693 use of DHCP because they believe it gives them some management 694 control. 696 Regarding the [26] implications, we note that all our hosts are dual- 697 stack, and thus are potentially exposed over both protocols anyway. 698 We publish all addresses in DNS, and do not operate a two faced DNS. 700 We have internal usage of RFC3041 privacy addresses currently, but 701 may wish to administratibely disable this (perhaps via DHCP), but we 702 need to determine the feasibility of this on all systems, e.g. for 703 WLAN guests or other user-maintained systems. Network management 704 should be simpler without RFC3041 in opeation. Note RFC3041 is only 705 an issue for outbound connections. 707 We manually configure server addresses to avoid address changes on a 708 change of network adaptor. With IPv6 you can choose to pick ::53 for 709 a DNS server, or can pick 'random' addresses for obfuscation, though 710 that's not an issue for publicly advertised addresses (dns, mx, web, 711 etc). 713 5.1.5. Observations 715 The site is not (yet) using prefix delegation tools for IPv6. 717 5.2. Service Provider Considerations 719 case studies are requested and in development. they should be added 720 for the -01 draft. 722 6. Security Considerations 724 This IPv6 addressing documents does not have any direct impact on 725 Internet infrastructure security. 727 7. Acknowledgements 729 Constructive feedback and contributions have been received from Stig 730 Venaas, Pekka Savola, John Spencer, Patrick Grossetete and Carlos 731 Garcia Braschi. 733 8. References 735 8.1. Normative References 737 8.2. Informative References 739 [1] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. 740 Lear, "Address Allocation for Private Internets", BCP 5, 741 RFC 1918, February 1996. 743 [2] Thomson, S. and T. Narten, "IPv6 Stateless Address 744 Autoconfiguration", RFC 2462, December 1998. 746 [3] Hinden, R., Fink, R., and J. Postel, "IPv6 Testing Address 747 Allocation", RFC 2471, December 1998. 749 [4] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast 750 Addresses", RFC 2526, March 1999. 752 [5] Retana, A., White, R., Fuller, V., and D. McPherson, "Using 31- 753 Bit Prefixes on IPv4 Point-to-Point Links", RFC 3021, 754 December 2000. 756 [6] Narten, T. and R. Draves, "Privacy Extensions for Stateless 757 Address Autoconfiguration in IPv6", RFC 3041, January 2001. 759 [7] IAB and IESG, "IAB/IESG Recommendations on IPv6 Address 760 Allocations to Sites", RFC 3177, September 2001. 762 [8] Durand, A. and C. Huitema, "The H-Density Ratio for Address 763 Assignment Efficiency An Update on the H ratio", RFC 3194, 764 November 2001. 766 [9] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. 767 Carney, "Dynamic Host Configuration Protocol for IPv6 768 (DHCPv6)", RFC 3315, July 2003. 770 [10] Draves, R., "Default Address Selection for Internet Protocol 771 version 6 (IPv6)", RFC 3484, February 2003. 773 [11] Blanchet, M., "A Flexible Method for Managing the Assignment of 774 Bits of an IPv6 Address Block", RFC 3531, April 2003. 776 [12] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global Unicast 777 Address Format", RFC 3587, August 2003. 779 [13] Savola, P., "Use of /127 Prefix Length Between Routers 780 Considered Harmful", RFC 3627, September 2003. 782 [14] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host 783 Configuration Protocol (DHCP) version 6", RFC 3633, 784 December 2003. 786 [15] Fink, R. and R. Hinden, "6bone (IPv6 Testing Address 787 Allocation) Phaseout", RFC 3701, March 2004. 789 [16] Droms, R., "Stateless Dynamic Host Configuration Protocol 790 (DHCP) Service for IPv6", RFC 3736, April 2004. 792 [17] Huitema, C. and B. Carpenter, "Deprecating Site Local 793 Addresses", RFC 3879, September 2004. 795 [18] Savola, P. and B. Haberman, "Embedding the Rendezvous Point 796 (RP) Address in an IPv6 Multicast Address", RFC 3956, 797 November 2004. 799 [19] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 800 Neighbor Discovery (SEND)", RFC 3971, March 2005. 802 [20] Aura, T., "Cryptographically Generated Addresses (CGA)", 803 RFC 3972, March 2005. 805 [21] Baker, F., Lear, E., and R. Droms, "Procedures for Renumbering 806 an IPv6 Network without a Flag Day", RFC 4192, September 2005. 808 [22] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 809 Addresses", RFC 4193, October 2005. 811 [23] Hinden, R. and S. Deering, "IP Version 6 Addressing 812 Architecture", RFC 4291, February 2006. 814 [24] Templin, F., Gleeson, T., Talwar, M., and D. Thaler, "Intra- 815 Site Automatic Tunnel Addressing Protocol (ISATAP)", 816 draft-ietf-ngtrans-isatap-24 (work in progress), January 2005. 818 [25] Templin, F., Gleeson, T., Talwar, M., and D. Thaler, "Intra- 819 Site Automatic Tunnel Addressing Protocol 820 (draft-ietf-ngtrans-isatap-24.txt)", July 2005. 822 [26] Chown, T., "IPv6 Implications for TCP/UDP Port Scanning (chown- 823 v6ops- port-scanning-implications-02.txt)", October 2005. 825 [27] APNIC, ARIN, RIPE NCC, "IPv6 Address Allocation and Assignment 826 Policy (www.ripe.net/ripe/docs/ipv6policy.html)", January 2003. 828 [28] Chown, T., Thompson, M., Ford, A., and S. Venaas, "Things to 829 think about when Renumbering an IPv6 network 830 (draft-chown-v6ops-renumber-thinkabout-03.txt)", July 2005. 832 Authors' Addresses 834 Gunter Van de Velde 835 Cisco Systems 836 De Kleetlaan 6a 837 Diegem 1831 838 Belgium 840 Phone: +32 2704 5473 841 Email: gunter@cisco.com 843 Ciprian Popoviciu 844 Cisco Systems 845 7025-6 Kit Creek Road 846 Research Triangle Park, North Carolina PO Box 14987 847 USA 849 Phone: +1 919 392-3723 850 Email: cpopovic@cisco.com 852 Tim Chown 853 University of Southampton 854 Highfield 855 Southampton, SO17 1BJ 856 United Kingdom 858 Phone: +44 23 8059 3257 859 Email: tjc@ecs.soton.ac.uk 861 Intellectual Property Statement 863 The IETF takes no position regarding the validity or scope of any 864 Intellectual Property Rights or other rights that might be claimed to 865 pertain to the implementation or use of the technology described in 866 this document or the extent to which any license under such rights 867 might or might not be available; nor does it represent that it has 868 made any independent effort to identify any such rights. Information 869 on the procedures with respect to rights in RFC documents can be 870 found in BCP 78 and BCP 79. 872 Copies of IPR disclosures made to the IETF Secretariat and any 873 assurances of licenses to be made available, or the result of an 874 attempt made to obtain a general license or permission for the use of 875 such proprietary rights by implementers or users of this 876 specification can be obtained from the IETF on-line IPR repository at 877 http://www.ietf.org/ipr. 879 The IETF invites any interested party to bring to its attention any 880 copyrights, patents or patent applications, or other proprietary 881 rights that may cover technology that may be required to implement 882 this standard. Please address the information to the IETF at 883 ietf-ipr@ietf.org. 885 Disclaimer of Validity 887 This document and the information contained herein are provided on an 888 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 889 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 890 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 891 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 892 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 893 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 895 Copyright Statement 897 Copyright (C) The Internet Society (2006). This document is subject 898 to the rights, licenses and restrictions contained in BCP 78, and 899 except as set forth therein, the authors retain all their rights. 901 Acknowledgment 903 Funding for the RFC Editor function is currently provided by the 904 Internet Society.