idnits 2.17.1 draft-ietf-v6ops-addcon-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1559. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1570. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1577. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1583. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 22, 2008) is 5657 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 3177 (Obsoleted by RFC 6177) -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3484 (Obsoleted by RFC 6724) -- Obsolete informational reference (is this intentional?): RFC 3627 (Obsoleted by RFC 6547) -- Obsolete informational reference (is this intentional?): RFC 3633 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3736 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) -- Obsolete informational reference (is this intentional?): RFC 5157 (Obsoleted by RFC 7707) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 16 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Operations G. Van de Velde 3 Internet-Draft C. Popoviciu 4 Intended status: Informational Cisco Systems 5 Expires: March 26, 2009 T. Chown 6 University of Southampton 7 O. Bonness 8 C. Hahn 9 T-Systems Enterprise Services GmbH 10 September 22, 2008 12 IPv6 Unicast Address Assignment Considerations 13 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on March 26, 2009. 40 Abstract 42 One fundamental aspect of any IP communications infrastructure is its 43 addressing plan. With its new address architecture and allocation 44 policies, the introduction of IPv6 into a network means that network 45 designers and operators need to reconsider their existing approaches 46 to network addressing. Lack of guidelines on handling this aspect of 47 network design could slow down the deployment and integration of 48 IPv6. This document aims to provide the information and 49 recommendations relevant to planning the addressing aspects of IPv6 50 deployments. The document also provides IPv6 addressing case studies 51 for both an enterprise and an ISP network. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2. Network Level Addressing Design Considerations . . . . . . . . 5 57 2.1. Globally Unique Addresses . . . . . . . . . . . . . . . . 5 58 2.2. Unique Local IPv6 Addresses . . . . . . . . . . . . . . . 5 59 2.3. 6Bone Address Space . . . . . . . . . . . . . . . . . . . 7 60 2.4. Network Level Design Considerations . . . . . . . . . . . 7 61 2.4.1. Sizing the Network Allocation . . . . . . . . . . . . 8 62 2.4.2. Address Space Conservation . . . . . . . . . . . . . . 9 63 3. Subnet Prefix Considerations . . . . . . . . . . . . . . . . . 9 64 3.1. Considerations for /64 Prefixes . . . . . . . . . . . . . 10 65 3.2. Allocation of the IID of an IPv6 Address . . . . . . . . . 10 66 3.2.1. Automatic EUI-64 Format Option . . . . . . . . . . . . 11 67 3.2.2. Using Privacy Extensions . . . . . . . . . . . . . . . 11 68 3.2.3. Manual/Dynamic Assignment Option . . . . . . . . . . . 11 69 3.3. IANA Considerations . . . . . . . . . . . . . . . . . . . 12 70 3.4. Security Considerations . . . . . . . . . . . . . . . . . 12 71 3.5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 12 72 4. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 73 4.1. Normative References . . . . . . . . . . . . . . . . . . . 12 74 4.2. Informative References . . . . . . . . . . . . . . . . . . 12 75 Appendix A. Case Studies . . . . . . . . . . . . . . . . . . . . 15 76 A.1. Enterprise Considerations . . . . . . . . . . . . . . . . 15 77 A.1.1. Obtaining General IPv6 Network Prefixes . . . . . . . 16 78 A.1.2. Forming an Address (subnet) Allocation Plan . . . . . 16 79 A.1.3. Other Considerations . . . . . . . . . . . . . . . . . 17 80 A.1.4. Node Configuration Considerations . . . . . . . . . . 18 81 A.2. Service Provider Considerations . . . . . . . . . . . . . 18 82 A.2.1. Investigation of objective Requirements for an 83 IPv6 addressing schema of a Service Provider . . . . 19 84 A.2.2. Exemplary IPv6 Address Allocation Plan for a 85 Service Provider . . . . . . . . . . . . . . . . . . . 22 86 A.2.3. Additional Remarks . . . . . . . . . . . . . . . . . . 26 87 Appendix B. Considerations for Subnet Prefixes Different then 88 /64 . . . . . . . . . . . . . . . . . . . . . . . . . 29 89 B.1. Considerations for Subnet Prefixes Shorter then /64 . . . 29 90 B.2. Considerations for Subnet Prefixes Longer then /64 . . . . 29 91 B.2.1. /126 Addresses . . . . . . . . . . . . . . . . . . . . 29 92 B.2.2. /127 Addresses . . . . . . . . . . . . . . . . . . . . 29 93 B.2.3. /128 Addresses . . . . . . . . . . . . . . . . . . . . 29 94 B.2.4. EUI-64 'u' and 'g' bits . . . . . . . . . . . . . . . 30 95 B.2.5. Anycast Addresses . . . . . . . . . . . . . . . . . . 31 96 B.2.6. Addresses Used by Embedded-RP (RFC3956) . . . . . . . 32 97 B.2.7. ISATAP Addresses . . . . . . . . . . . . . . . . . . . 33 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 99 Intellectual Property and Copyright Statements . . . . . . . . . . 35 101 1. Introduction 103 The Internet Protocol Version 6 (IPv6) Addressing Architecture 104 [RFC4291] defines three main types of addresses: unicast, anycast and 105 multicast. This document focuses on unicast addresses, for which 106 there are currently two principal allocated types: Globally Unique 107 Addresses [RFC3587] ('globals') and Unique Local IPv6 Addresses 108 [RFC4193] (ULAs). In addition until recently there has been 109 'experimental' 6bone address space [RFC3701], though its use has been 110 deprecated since June 2006 [RFC3701]. 112 The document covers aspects that should be considered during IPv6 113 deployment for the design and planning of an addressing scheme for an 114 IPv6 network. The network's IPv6 addressing plan may be for an IPv6- 115 only network, or for a dual-stack infrastructure where some or all 116 devices have addresses in both protocols. These considerations will 117 help an IPv6 network designer to efficiently and prudently assign the 118 IPv6 address space that has been allocated to their organization. 120 The address assignment considerations are analyzed separately for the 121 two major components of the IPv6 unicast addresses, namely 'Network 122 Level Addressing' (the allocation of subnets) and the 'interface-id' 123 (the identification of the interface within a subnet). Thus the 124 document includes a discussion of aspects of address assignment to 125 nodes and interfaces in an IPv6 network. Finally the document 126 provides two examples of deployed address plans in a service provider 127 (ISP) and an enterprise network. 129 Parts of this document highlight the differences that an experienced 130 IPv4 network designer should consider when planning an IPv6 131 deployment, for example: 133 o IPv6 devices will more likely be multi-addressed in comparison 134 with their IPv4 counterparts 135 o The practically unlimited size of an IPv6 subnet (2^64 bits) 136 reduces the requirement to size subnets to device counts for the 137 purposes of (IPv4) address conservation 138 o The implications of the vastly increased subnet size on the threat 139 of address-based host scanning and other scanning techniques, as 140 discussed in [RFC5157]. 142 We do not discuss here how a site or ISP should proceed with 143 acquiring its globally routable IPv6 address prefix. In each case 144 the prefix received is either provider assigned (PA) or provider 145 independent (PI). 147 We do not discuss PI policy here. The observations and 148 recommendations of this text are largely independent of the PA or PI 149 nature of the address block being used. At this time we assume that 150 most commonly an IPv6 network which changes provider will need to 151 undergo a renumbering process, as described in [RFC4192]. A separate 152 document [THINKABOUT] makes recommendations to ease the IPv6 153 renumbering process. 155 This document does not discuss implementation aspects related to the 156 transition between the ULA addresses and the now obsoleted site-local 157 addresses. Some implementations know about Site-local addresses even 158 though they are deprecated, and do not know about ULAs - even though 159 they represent current specification. As result transitioning 160 between these types of addresses may cause difficulties. 162 2. Network Level Addressing Design Considerations 164 This section discusses the kind of IPv6 addresses used at the network 165 level for the IPv6 infrastructure. The kind of addresses that can be 166 considered are Globally Unique Addresses and ULAs. We also comment 167 here on the deprecated 6bone address space. 169 2.1. Globally Unique Addresses 171 The most commonly used unicast addresses will be Globally Unique 172 Addresses ('globals'). No significant considerations are necessary 173 if the organization has an address space assignment and a single 174 prefix is deployed through a single upstream provider. 176 However, a multihomed site may deploy addresses from two or more 177 Service Provider assigned IPv6 address ranges. Here, the network 178 Administrator must have awareness on where and how these ranges are 179 used on the multihomed infrastructure environment. The nature of the 180 usage of multiple prefixes may depend on the reason for multihoming 181 (e.g. resilience failover, load balancing, policy-based routing, or 182 multihoming during an IPv6 renumbering event). IPv6 introduces 183 improved support for multi-addressed hosts through the IPv6 default 184 address selection methods described in RFC3484 [RFC3484]. A 185 multihomed host may thus have two or more addresses, one per prefix 186 (provider), and select source and destination addresses to use as 187 described in that RFC. However multihoming also has some operational 188 and administrative burdens besides chosing multiple addresses per 189 interface [RFC4219][RFC4218]. 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 [RFC3879]. 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 [RFC1918] 199 assigned for IPv4 networks, except that in IPv6 networks we may 200 expect to see ULAs used alongside global addresses, with ULAs used 201 internally and globals used externally. Thus use of ULAs does not 202 imply use of NAT for IPv6. 204 The ULA address range allows network administrators to deploy IPv6 205 addresses on their network without asking for a globally unique 206 registered IPv6 address range. A ULA prefix is 48 bits, i.e. a /48, 207 the same as the currently recommended allocation for a site from the 208 globally routable IPv6 address space [RFC3177]. 210 A site willing to use ULA address space can have either (a) multiple 211 /48 prefixes (e.g. a /44) and wishes to use ULAs, or (b) has one /48 212 and wishes to use ULAs or (c) a site has a less-than-/48 prefix (e.g. 213 a /56 or /64) and wishes to use ULAs. In all above cases the ULA 214 addresses can be randomly chosen according the principles specified 215 in [RFC4193]. However, in case (a) the use of randomly chosen ULA 216 addresses will provide suboptimal aggregation capabilities. 218 ULAs provide the means to deploy a fixed addressing scheme that is 219 not affected by a change in service provider and the corresponding PA 220 global addresses. Internal operation of the network is thus 221 unaffected during renumbering events. Nevertheless, this type of 222 address must be used with caution. 224 A site using ULAs may or may not also deploy global addresses. In an 225 isolated network ULAs may be deployed on their own. In a connected 226 network, that also deploys global addresses, both may be deployed, 227 such that hosts become multiaddressed (one global and one ULA 228 address) and the IPv6 default address selection algorithm will pick 229 the appropriate source and destination addresses to use, e.g. ULAs 230 will be selected where both the source and destination hosts have ULA 231 addresses. Because a ULA and a global site prefix are both /48 232 length, an administrator can choose to use the same subnetting (and 233 host addressing) plan for both prefixes. 235 As an example of the problems ULAs may cause, when using IPv6 236 multicast within the network, the IPv6 default address selection 237 algorithm prefers the ULA address as the source address for the IPv6 238 multicast streams. This is NOT a valid option when sending an IPv6 239 multicast stream to the IPv6 Internet for two reasons. For one, 240 these addresses are not globally routable so Reverse Path Forwarding 241 checks for such traffic will fail outside the internal network. The 242 other reason is that the traffic will likely not cross the network 243 boundary due to multicast domain control and perimeter security 244 policies. 246 In principle ULAs allow easier network mergers than RFC1918 addresses 247 do for IPv4 because ULA prefixes have a high probability of 248 uniqueness, if the prefix is chosen as described in the RFC. 250 2.3. 6Bone Address Space 252 The 6Bone address space was used before the Regional Internet 253 Registries (RIRs) started to distribute 'production' IPv6 prefixes. 254 The 6Bone prefixes have a common first 16 bits in the IPv6 Prefix of 255 3FFE::/16. This address range is deprecated as of 6th June 2006 256 [RFC3701] and must not be used on any new IPv6 network deployments. 257 Sites using 6bone address space should renumber to production address 258 space using procedures as defined in [RFC4192]. 260 2.4. Network Level Design Considerations 262 IPv6 provides network administrators with a significantly larger 263 address space, enabling them to be very creative in how they can 264 define logical and practical address plans. The subnetting of 265 assigned prefixes can be done based on various logical schemes that 266 involve factors such as: 267 o Using existing systems 268 * translate the existing subnet number into IPv6 subnet id 269 * translate the VLAN id into IPv6 subnet id 270 o Redesign 271 * allocate according to your need 272 o Aggregation 273 * Geographical Boundaries - by assigning a common prefix to all 274 subnets within a geographical area 275 * Organizational Boundaries - by assigning a common prefix to an 276 entire organization or group within a corporate infrastructure 277 * Service Type - by reserving certain prefixes for predefined 278 services such as: VoIP, Content Distribution, wireless 279 services, Internet Access, Security areas etc. This type of 280 addressing may create dependencies on IP addresses that can 281 make renumbering harder if the nodes or interfaces supporting 282 those services on the network are sparse within the topology. 283 Such logical addressing plans have the potential to simplify network 284 operations and service offerings, and to simplify network management 285 and troubleshooting. A very large network would also have no need to 286 consider using private address space for its infrastructure devices, 287 simplifying network management. 289 The network designer must however keep in mind several factors when 290 developing these new addressing schemes for networks with and without 291 global connectivity: 293 o Prefix Aggregation - The larger IPv6 addresses can lead to larger 294 routing tables unless network designers are actively pursuing 295 aggregation. While prefix aggregation will be enforced by the 296 service provider, it is beneficial for the individual 297 organizations to observe the same principles in their network 298 design process 299 o Network growth - The allocation mechanism for flexible growth of a 300 network prefix, documented in RFC3531 [RFC3531] can be used to 301 allow the network infrastructure to grow and be numbered in a way 302 that is likely to preserve aggregation (the plan leaves 'holes' 303 for growth) 304 o ULA usage in large networks - Networks which have a large number 305 of 'sites' that each deploy a ULA prefix which will by default be 306 a 'random' /48 under fc00::/7 will have no aggregation of those 307 prefixes. Thus the end result may be cumbersome because the 308 network will have large amounts of non-aggregated ULA prefixes. 309 However, there is no rule to disallow large networks to use a 310 single ULA prefix for all 'sites', as a ULA still provides 16 bits 311 for subnetting to be used internally 312 o It is possible that as registry policies evolve, a small site may 313 experience an increase in prefix length when renumbering, e.g. 314 from /48 to /56. For this reason, the best practice is number 315 subnets compactly rather than sparsely, and to use low-order bits 316 as much as possible when numbering subnets. In other words, even 317 if a /48 is allocated, act as though only a /56 is available. 318 Clearly, this advice does not apply to large sites and enterprises 319 that have an intrinsic need for a /48 prefix. 320 o A small site may want to enable routing amongst interfaces 321 connected to a gateway device. For example, a residential gateway 322 which receives a /48, is situated in a home with multiple LANs of 323 different media types (sensor network, wired, wifi, etc.), or has 324 a need for traffic segmentation (home, work, kids, etc.) and could 325 benefit greatly from multiple subnets and routing in IPv6. 326 Ideally, residential networks would be given an address range of a 327 /48 or /56 [reference2] such that multiple /64 subnets could be 328 used within the residence. 330 2.4.1. Sizing the Network Allocation 332 We do not discuss here how a network designer sizes their application 333 for address space. By default a site will receive a /48 prefix 334 [RFC3177] , however different RIR service regions policies may 335 suggest alternative default assignments or let the ISPs to decide on 336 what they believe is more appropriate for their specific case [ARIN]. 337 The default provider allocation via the RIRs is currently a /32 338 [reference2]. These allocations are indicators for a first 339 allocation for a network. Different sizes may be obtained based on 340 the anticipated address usage [reference2]. There are examples of 341 allocations as large as /19 having been made from RIRs to providers 342 at the time of writing. 344 2.4.2. Address Space Conservation 346 Despite the large IPv6 address space which enables easier subnetting, 347 it still is important to ensure an efficient use of this resource. 348 Some addressing schemes, while facilitating aggregation and 349 management, could lead to significant numbers of addresses being 350 unused. Address conservation requirements are less stringent in IPv6 351 but they should still be observed. 353 The proposed Host-Density (HD) [RFC3194] value for IPv6 is 0.94 354 compared to the current value of 0.96 for IPv4. Note that for IPv6 355 HD is calculated for sites (e.g. on a basis of /48), instead of based 356 on addresses like with IPv4. 358 3. Subnet Prefix Considerations 360 An important part of an IPv4 addressing plan is deciding the length 361 of each subnet prefix. Unlike in IPv4, the IPv6 addressing 362 architecture [RFC4291] specifies that all subnets using Globally 363 Unique Addresses and ULAs always have the same prefix length of 64 364 bits. (This applies also to the deprecated 6Bone and Site Local 365 addresses.) 367 The only exception to this rule are special addresses starting with 368 the binary value 000, such as IPv4-Compatible IPv6 Addresses. These 369 exceptions are largely beyond the scope of this document. 371 Using a subnet prefix length other than a /64 will break many 372 features of IPv6, amongst other things Neighbor Discovery (ND), 373 Secure Neighborship Discovery (SEND) [RFC3971], privacy extensions 374 [RFC4941], parts of Mobile IPv6 [RFC4866], PIM-SM with Embedded-RP 375 [RFC3956], and SHIM6 [SHIM6]. A number of other features currently 376 in development, or being proposed, also rely on /64 subnet prefixes. 378 Nevertheless, many IPv6 implementations do not prevent the 379 administrator from configuring a subnet prefix length shorter or 380 longer than 64 bits. Using subnet prefixes shorter than /64 would 381 rarely be useful; see Appendix B.1 for discussion. 383 However, some network administrators have used prefixes longer than 384 /64 for links connecting routers, usually just two routers on a 385 point-to-point link. On links where all the addresses are assigned 386 by manual configuration, and all nodes on the link are routers (not 387 end hosts) that are known by the network administrators do not need 388 any of the IPv6 features that rely on /64 subnet prefixes, this can 389 work. Using subnet prefixes longer than /64 are not recommended for 390 general use, and using them for links containing end hosts would be 391 an especially bad idea, as it is difficult to predict what IPv6 392 features the hosts will use in the future. 394 Appendix B.2 describes some practical considerations that need to be 395 taken into account when using prefixes longer than /64 in limited 396 cases. In particular, a number of IPv6 features use interface 397 identifiers that have a special form (such as a certain fixed value 398 in some bit positions). When using prefixes longer than /64, it is 399 prudent to avoid certain subnet prefix values so that nodes who 400 assume that the prefix is /64 will not incorrectly identify the 401 addresses in that subnet as having a special form. Appendix B.2 402 describes the subnet prefix values that are currently believed to be 403 potentially problematic; however, the list is not exhaustive and can 404 be expected to grow in the future. 406 Using /64 subnets is strongly recommended, also for links connecting 407 only routers. A deployment compliant with the current IPv6 408 specifications cannot use other prefix lengths. However, the V6OPS 409 WG believes that despite the drawbacks (and a potentially expensive 410 network redesign, if IPv6 features relying on /64 subnets are needed 411 in the future), that some networks administrators will use prefixes 412 longer than /64. 414 3.1. Considerations for /64 Prefixes 416 Based on RFC3177 [RFC3177], 64 bits is the prescribed subnet prefix 417 length to allocate to interfaces and nodes. 419 When using a /64 subnet length, the address assignment for these 420 addresses can be made either by manual configuration, by a stateful 421 Host Configuration Protocol [RFC3315] [RFC3736] or by stateless 422 autoconfiguration [RFC4862]. 424 Note that RFC3177 strongly prescribes 64 bit subnets for general 425 usage, and that stateless autoconfiguration option is only defined 426 for 64 bit subnets. While in theory it might be possible that some 427 future autoconfiguration mechanisms would allow longer than 64 bit 428 prefix lengths to be used, the use of such prefixes is not 429 recommended at this time. 431 3.2. Allocation of the IID of an IPv6 Address 433 In order to have a complete IPv6 address, an interface must be 434 associated a prefix and an Interface Identifier (IID). Section 3 of 435 this document analyzed the prefix selection considerations. This 436 section discusses the elements that should be considered when 437 assigning the IID portion of the IPv6 address. 439 There are various ways to allocate an IPv6 address to a device or 440 interface. The option with the least amount of caveats for the 441 network administrator is that of EUI-64 [RFC4862] based addresses. 442 For the manual or dynamic options, the overlap with well known IPv6 443 addresses should be avoided. 445 3.2.1. Automatic EUI-64 Format Option 447 When using this method the network administrator has to allocate a 448 valid 64 bit subnet prefix. The EUI-64 [RFC4862] allocation 449 procedure can from that moment onward assign the remaining 64 IID 450 bits in a stateless manner. All the considerations for selecting a 451 valid IID have been incorporated in the EUI-64 methodology. 453 3.2.2. Using Privacy Extensions 455 The main purpose of IIDs generated based on RFC4941 [RFC4941] is to 456 provide privacy to the entity using this address. While there are no 457 particular constraints in the usage of these addresses as defined in 458 [RFC4941] there are some implications to be aware of when using 459 privacy addresses as documented in section 4 of RFC4941 [RFC4941] 461 3.2.3. Manual/Dynamic Assignment Option 463 This section discusses those IID allocations that are not implemented 464 through stateless address configuration (Section 4.1). They are 465 applicable regardless of the prefix length used on the link. It is 466 out of scope for this section to discuss the various assignment 467 methods (e.g. manual configuration, DHCPv6, etc). 469 In this situation the actual allocation is done by human intervention 470 and consideration needs to be given to the complete IPv6 address so 471 that it does not result in overlaps with any of the well known IPv6 472 addresses: 473 o Subnet Router Anycast Address (Appendix B.2.5.1.) 474 o Reserved Subnet Anycast Address (Appendix B.2.5.2.) 475 o Addresses used by Embedded-RP (Appendix B.2.6.) 476 o ISATAP Addresses (Appendix B.2.7.) 478 When using an address assigned by human intervention it is 479 recommended to choose IPv6 addresses which are not obvious to guess 480 and/or avoid any IPv6 addresses that embed IPv4 addresses used in the 481 current infrastructure. Following these two recommendations will 482 make it more difficult for malicious third parties to guess targets 483 for attack, and thus reduce security threats to a certain extent. 485 3.3. IANA Considerations 487 There are no extra IANA consideration for this document. 489 3.4. Security Considerations 491 This document doesn't add any new security considerations that aren't 492 already outlined in the security considerations of the references. 494 It must be noted that using subnet prefixes other than /64 breaks 495 security mechanisms such as Cryptographically Generated Addresses 496 (CGAs) and Hash Based Addresses (HBAs), and thus makes it impossible 497 to use protocols that depend on them. 499 3.5. Acknowledgements 501 Constructive feedback and contributions have been received during 502 IESG review cycle and from Marla Azinger, Stig Venaas, Pekka Savola, 503 John Spence, Patrick Grossetete, Carlos Garcia Braschi, Brian 504 Carpenter, Mark Smith, Janos Mohacsi, Jim Bound, Fred Templin, Ginny 505 Listman, Salman Assadullah, Krishnan Thirukonda and the IESG. 507 4. References 509 4.1. Normative References 511 4.2. Informative References 513 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 514 E. Lear, "Address Allocation for Private Internets", 515 BCP 5, RFC 1918, February 1996. 517 [RFC2526] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast 518 Addresses", RFC 2526, March 1999. 520 [RFC3021] Retana, A., White, R., Fuller, V., and D. McPherson, 521 "Using 31-Bit Prefixes on IPv4 Point-to-Point Links", 522 RFC 3021, December 2000. 524 [RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 525 Tunnel Broker", RFC 3053, January 2001. 527 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 528 via IPv4 Clouds", RFC 3056, February 2001. 530 [RFC3177] IAB and IESG, "IAB/IESG Recommendations on IPv6 Address 531 Allocations to Sites", RFC 3177, September 2001. 533 [RFC3180] Meyer, D. and P. Lothberg, "GLOP Addressing in 233/8", 534 BCP 53, RFC 3180, September 2001. 536 [RFC3194] Durand, A. and C. Huitema, "The H-Density Ratio for 537 Address Assignment Efficiency An Update on the H ratio", 538 RFC 3194, November 2001. 540 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 541 and M. Carney, "Dynamic Host Configuration Protocol for 542 IPv6 (DHCPv6)", RFC 3315, July 2003. 544 [RFC3484] Draves, R., "Default Address Selection for Internet 545 Protocol version 6 (IPv6)", RFC 3484, February 2003. 547 [RFC3531] Blanchet, M., "A Flexible Method for Managing the 548 Assignment of Bits of an IPv6 Address Block", RFC 3531, 549 April 2003. 551 [RFC3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global 552 Unicast Address Format", RFC 3587, August 2003. 554 [RFC3627] Savola, P., "Use of /127 Prefix Length Between Routers 555 Considered Harmful", RFC 3627, September 2003. 557 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 558 Host Configuration Protocol (DHCP) version 6", RFC 3633, 559 December 2003. 561 [RFC3701] Fink, R. and R. Hinden, "6bone (IPv6 Testing Address 562 Allocation) Phaseout", RFC 3701, March 2004. 564 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 565 (DHCP) Service for IPv6", RFC 3736, April 2004. 567 [RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local 568 Addresses", RFC 3879, September 2004. 570 [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous 571 Point (RP) Address in an IPv6 Multicast Address", 572 RFC 3956, November 2004. 574 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 575 Neighbor Discovery (SEND)", RFC 3971, March 2005. 577 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 578 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 579 September 2005. 581 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 582 Addresses", RFC 4193, October 2005. 584 [RFC4218] Nordmark, E. and T. Li, "Threats Relating to IPv6 585 Multihoming Solutions", RFC 4218, October 2005. 587 [RFC4219] Lear, E., "Things Multihoming in IPv6 (MULTI6) Developers 588 Should Think About", RFC 4219, October 2005. 590 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 591 Protocol 4 (BGP-4)", RFC 4271, January 2006. 593 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 594 Architecture", RFC 4291, February 2006. 596 [RFC4477] Chown, T., Venaas, S., and C. Strauf, "Dynamic Host 597 Configuration Protocol (DHCP): IPv4 and IPv6 Dual-Stack 598 Issues", RFC 4477, May 2006. 600 [RFC4798] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur, 601 "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 602 Provider Edge Routers (6PE)", RFC 4798, February 2007. 604 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 605 Address Autoconfiguration", RFC 4862, September 2007. 607 [RFC4866] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route 608 Optimization for Mobile IPv6", RFC 4866, May 2007. 610 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 611 Extensions for Stateless Address Autoconfiguration in 612 IPv6", RFC 4941, September 2007. 614 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 615 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 616 March 2008. 618 [RFC5157] Chown, T., "IPv6 Implications for Network Scanning", 619 RFC 5157, March 2008. 621 [SHIM6] IETF, 622 "http://www.ietf.org/html.charters/shim6-charter.html". 624 [ARIN] ARIN, "http://www.arin.net/policy/nrpm.html#six54". 626 [reference2] 627 APNIC, ARIN, RIPE NCC, "www.ripe.net/ripe/docs/ 628 ipv6policy.html", July 2007. 630 [reference3] 631 APNIC, ARIN, RIPE NCC, 632 "http://www.ripe.net/ripe/docs/ripe-412.html", July 2007. 634 [reference4] 635 ARIN, "http://www.arin.net/policy/nrpm.html#ipv6", 636 March 2008. 638 [reference5] 639 APNIC, 640 "http://www.apnic.net/policy/ipv6-address-policy.html", 641 March 2007. 643 [reference6] 644 LACNIC, "http://lacnic.net/en/politicas/ipv6.html". 646 [reference7] 647 AFRINIC, "http://www.afrinic.net/docs/policies/ 648 afpol-v6200407-000.htm", March 2004. 650 [THINKABOUT] 651 Chown, T., Thompson, M., Ford, A., and S. Venaas, "Things 652 to think about when Renumbering an IPv6 network 653 (draft-chown-v6ops-renumber-thinkabout-05.txt)", 654 March 2007. 656 Appendix A. Case Studies 658 This appendix contains two case studies for IPv6 addressing schemas 659 that have been based on the statements and considerations of this 660 draft. These case studies illustrate how this draft has been used in 661 two specific network scenarios. The case studies may serve as basic 662 considerations for an administrator who designs the IPv6 addressing 663 schema for an enterprise or ISP network, but are not intended to 664 serve as general design proposal for every kind of IPv6 network. All 665 subnet sizes used in this appendix are for practical visualization 666 and do not dictate RIR policy. 668 A.1. Enterprise Considerations 670 In this section one considers a case study of a campus network that 671 is deploying IPv6 in parallel with existing IPv4 protocols in a dual- 672 stack environment. The specific example is the University of 673 Southampton (UK), focusing on a large department within that network. 674 The deployment currently spans around 1,000 hosts and over 1,500 675 users. 677 A.1.1. Obtaining General IPv6 Network Prefixes 679 In the case of a campus network, the site will typically take its 680 connectivity from its National Research and Education Network (NREN). 681 Southampton connects to JANET, the UK academic network, via its local 682 regional network LeNSE. JANET currently has a /32 allocation from 683 RIPE NCC. The current recommended practice is for sites to receive a 684 /48 allocation, and on this basis Southampton has received such a 685 prefix for its own use. The regional network also uses its own 686 allocation from the NREN provider. 688 No ULA addressing is used on site. The campus is not multihomed 689 (JANET is the sole provider), nor does it expect to change service 690 provider, and thus does not plan to use ULAs for the (perceived) 691 benefit of easing network renumbering. Indeed, the campus has 692 renumbered following the aforementioned renumbering procedure 693 [RFC4192] on two occasions, and this has proven adequate (with 694 provisos documented in [THINKABOUT]. The campus do not see any need 695 to deploy ULAs for in or out of band network management; there are 696 enough IPv6 prefixes available in the site allocation for the 697 infrastructure. In some cases, use of private IP address space in 698 IPv4 creates problems, so University of Southampton believe that the 699 availability of ample global IPv6 address space for infrastructure 700 may be a benefit for many sites. 702 No 6bone addressing is used on site any more. Since the 6bone 703 phaseout of June 2006 [RFC3701] most transit ISPs have begun 704 filtering attempted use of such prefixes. 706 Southampton does participate in global and organization scope IPv6 707 multicast networks. Multicast address allocations are not discussed 708 here as they are not in scope for the document. It is noted that 709 IPv6 has advantages for multicast group address allocation. In IPv4 710 a site needs to use techniques like GLOP [RFC3180] to pick a globally 711 unique multicast group to use. This is problematic if the site does 712 not use Border Gateway Protocol (BGP) [RFC4271] and have an 713 Autonomous System Number (ASN). In IPv6 unicast-prefix-based IPv6 714 multicast addresses empower a site to pick a globally unique group 715 address based on its unicast own site or link prefix. Embedded RP is 716 also in use, is seen as a potential advantage for IPv6 and multicast, 717 and has been tested successfully across providers between sites 718 (including paths to/from the US and UK). 720 A.1.2. Forming an Address (subnet) Allocation Plan 722 The campus has a /16 prefix for IPv4 use; in principle 256 subnets of 723 256 addresses. In reality the subnetting is muddier, because of 724 concerns of IPv4 address conservation; subnets are sized to the hosts 725 within them, e.g. a /26 IPv4 prefix is used if a subnet has 35 hosts 726 in it. While this is efficient, it increases management burden when 727 physical deployments change, and IPv4 subnets require resizing (up or 728 down), even with DHCP in use. 730 The /48 IPv6 prefix is considerably larger than the IPv4 allocation 731 already in place at the site. It is loosely equivalent to a 'Class 732 A' IPv4 prefix in that it has 2^16 (over 65,000) subnets, but has an 733 effectively unlimited subnet address size (2^64) compared to 256 in 734 the IPv4 equivalent. The increased subnet size means that /64 IPv6 735 prefixes can be used on all subnets, without any requirement to 736 resize them at a later date. The increased subnet volume allows 737 subnets to be allocated more generously to schools and departments in 738 the campus. While address conservation is still important, it is no 739 longer an impediment on network management. Rather, address (subnet) 740 allocation is more about embracing the available address space and 741 planning for future expansion. 743 In a dual-stack network, it was chosen to deploy our IP subnets 744 congruently for IPv4 and IPv6. This is because the systems are still 745 in the same administrative domains and the same geography. It is not 746 expected to have IPv6-only subnets in production use for a while yet, 747 outside the test beds and some early Mobile IPv6 trials. With 748 congruent addressing, our firewall policies are also aligned for IPv4 749 and IPv6 traffic at the site border. 751 The subnet allocation plan required a division of the address space 752 per school or department. Here a /56 was allocated to the school 753 level of the university; there are around 30 schools currently. A 754 /56 of IPv6 address space equates to 256 /64 size subnet allocations. 755 Further /56 allocations were made for central IT infrastructure, for 756 the network infrastructure and the server side systems. 758 A.1.3. Other Considerations 760 The network uses a Demilitarized Zone (DMZ) topology for some level 761 of protection of 'public' systems. Again, this topology is congruent 762 with the IPv4 network. 764 There are no specific transition methods deployed internally to the 765 campus; everything is using the conventional dual-stack approach. 766 There is no use of ISATAP [RFC5214] for example. 768 For the Mobile IPv6 early trials there is one allocated prefix for 769 Home Agent (HA) use. However there has been no detailed 770 consideration yet how Mobile IPv6 usage may grow, and whether more or 771 even every subnet will require HA support. 773 The university operates a tunnel broker [RFC3053] service on behalf 774 of UKERNA for JANET sites. This uses separate address space from 775 JANET, not our university site allocation. 777 A.1.4. Node Configuration Considerations 779 Currently stateless autoconfiguration is used on most subnets for 780 IPv6 hosts. There is no DHCPv6 service deployed yet, beyond tests of 781 early code releases. It is planned to deploy DHCPv6 for address 782 assignment when robust client and server code is available (at the 783 time of writing the potential for this looks good, e.g. via the ISC 784 implementation). University of Southampton is also investigating a 785 common integrated DHCP/DNS management platform, even if the servers 786 themselves are not co-located, including integrated DHCPv4 and DHCPv6 787 server configuration, as discussed in [RFC4477]. Currently clients 788 with statelessly autoconfigured addresses are added to the DNS 789 manually, though dynamic DNS is an option. The network 790 administrators would prefer the use of DHCP because they believe it 791 gives them more management control. 793 Regarding the implications of the larger IPv6 subnet address space on 794 scanning attacks [RFC5157], it is noted that all the hosts are dual- 795 stack, and thus are potentially exposed over both protocols anyway. 796 All addresses or published in DNS, and hence do not operate a two 797 faced DNS. 799 There is internal usage of RFC4941 privacy addresses [RFC4941] 800 currently (certain platforms currently ship with it on by default), 801 but may desire to administratively disable this (perhaps via DHCP) to 802 ease management complexity. However, it is desired to determine the 803 feasibility of this on all systems, e.g. for guests on wireless LAN 804 or other user-maintained systems. Network management and monitoring 805 should be simpler without RFC4941 in operation, in terms of 806 identifying which physical hosts are using which addresses. Note 807 that RFC4941 is only an issue for outbound connections, and that 808 there is potential to assign privacy addresses via DHCPv6. 810 Manually configured server addresses are used to avoid address 811 changes based upon change of network adaptor. With IPv6 you can 812 choose to pick ::53 for a DNS server, or can pick 'random' addresses 813 for obfuscation, though that's not an issue for publicly advertised 814 addresses (dns, mx, web, etc). 816 A.2. Service Provider Considerations 818 In this section an IPv6 addressing schema is sketched that could 819 serve as an example for an Internet Service Provider. 821 Sub-section A.2.1 starts with some thoughts regarding objective 822 requirements of such an addressing schema and derives a few general 823 rules of thumb that have to be kept in mind when designing an ISP 824 IPv6 addressing plan. 826 Sub-section A.2.2 illustrates these findings of A.2.1 with an 827 exemplary IPv6 addressing schema for an MPLS-based ISP offering 828 Internet Services as well as Network Access services to several 829 millions of customers. 831 A.2.1. Investigation of objective Requirements for an IPv6 addressing 832 schema of a Service Provider 834 The first step of the IPv6 addressing plan design for a Service 835 provider should identify all technical, operational, political and 836 business requirements that have to be satisfied by the services 837 supported by this addressing schema. 839 According to the different technical constraints and business models 840 as well as the different weights of these requirements (from the 841 point of view of the corresponding Service Provider) it is very 842 likely that different addressing schemas will be developed and 843 deployed by different ISPs. Nevertheless the addressing schema of 844 sub-section A.2.2 is one possible example. 846 For this document it is assumed that our exemplary ISP has to fulfill 847 several roles for its customers as there are: 849 o Local Internet Registry 850 o Network Access Provider 851 o Internet Service Provider 853 A.2.1.1. Recommendations for an IPv6 Addressing Schema from the LIR 854 Perspective of the Service Provider 856 In their role as Local Internet Registry (LIR) the Service Providers 857 have to care about the policy constraints of the RIRs and the 858 standards of the IETF regarding IPv6 addressing. In this context, 859 the following basic recommendations have to be considered and should 860 be satisfied by the IPv6 address allocation plan of a Service 861 Provider: 862 o As recommended in RFC 3177 [RFC3177] and in several RIR policies 863 "Common" customers sites (normally private customers) should 864 receive a /48 prefix from the aggregate of the Service Provider. 865 (Note: The addressing plan must be flexible enough and take into 866 account the possible change of the minimum allocation size for end 867 users currently under definition by the RIRs.) 869 o "Big customers" (like big enterprises, governmental agencies etc.) 870 may receive shorter prefixes according to their needs when this 871 need could be documented and justified to the RIR. 872 o The IPv6 address allocation schema has to be able to meet the HD- 873 ratio that is proposed for IPv6. This requirement corresponds to 874 the demand for an efficient usage of the IPv6 address aggregate by 875 the Service Provider. (Note: The currently valid IPv6 HD-ratio of 876 0.94 means an effective usage of about 31% of a /20 prefix of the 877 Service Provider on the basis of /48 assignments.) 878 o All assignments to customers have to be documented and stored into 879 a database that can also be queried by the RIR. 880 o The LIR has to make available means for supporting the reverse DNS 881 mapping of the customer prefixes. 882 o IPv6 Address Allocation and Assignment Policies can be found at 883 RIRs and are similar in many aspects: 884 [reference2][reference3][reference4] [reference5][reference6] 886 A.2.1.2. IPv6 Addressing Schema Recommendations from the ISP 887 Perspective of the Service Provider 889 From ISP perspective the following basic requirements could be 890 identified: 891 o The IPv6 address allocation schema must be able to realize a 892 maximal aggregation of all IPv6 address delegations to customers 893 into the address aggregate of the Service Provider. Only this 894 provider aggregate will be routed and injected into the global 895 routing table (DFZ). This strong aggregation keeps the routing 896 tables of the DFZ small and eases filtering and access control 897 very much. 898 o The IPv6 addressing schema of the SP should contain optimal 899 flexibility since the infrastructure of the SP will change over 900 the time with new customers, transport technologies and business 901 cases. The requirement of optimal flexibility is contrary to the 902 recommendation of strong IPv6 address aggregation and efficient 903 address usage, but at this point each SP has to decide which of 904 these requirements to prioritize. 905 o Keeping the multilevel network hierarchy of an ISP in mind, due to 906 addressing efficiency reasons not all hierarchy levels can and 907 should be mapped into the IPv6 addressing schema of an ISP. 908 Sometimes it is much better to implement a more "flat" addressing 909 for the ISP network than to loose big chunks of the IPv6 address 910 aggregate in addressing each level of network hierarchy. (Note: 911 In special cases it is even recommendable for really "small" ISPs 912 to design and implement a totally flat IPv6 addressing schema 913 without any level of hierarchy.) 914 o Besides that a decoupling of provider network addressing and 915 customer addressing is recommended. (Note: A strong aggregation 916 e.g. on POP, aggregation router or Label Edge Router (LER) level 917 limits the numbers of customer routes that are visible within the 918 ISP network but brings also down the efficiency of the IPv6 919 addressing schema. That's why each ISP has to decide how many 920 internal aggregation levels it wants to deploy.) 922 A.2.1.3. IPv6 Addressing Schema Recommendations from the Network Access 923 provider Perspective of the Service Provider 925 As already done for the LIR and the ISP roles of the SP it is also 926 necessary to identify requirements that come from its Network Access 927 Provider role. Some of the basic requirements are: 928 o The IPv6 addressing schema of the SP must be chosen in a way that 929 it can handle new requirements that are triggered from customer 930 side. This can be for instance the growing needs of the customers 931 regarding IPv6 addresses as well as customer driven modifications 932 within the access network topology (e.g. when the customer moves 933 from one point of network attachment (POP) to another). (See 934 section A.2.3.4 "Changing Point of Network Attachment".) 935 o For each IPv6 address assignment to customers a "buffer zone" 936 should be reserved that allows the customer to grow in its 937 addressing range without renumbering or assignment of additional 938 prefixes. 939 o The IPv6 addressing schema of the SP must deal with multiple- 940 attachments of a single customer to the SP network infrastructure 941 (i.e. multi-homed network access with the same SP). 943 These few requirements are only part of all the requirements a 944 Service Provider has to investigate and keep in mind during the 945 definition phase of its addressing architecture. Each SP will most 946 likely add more constraints to this list. 948 A.2.1.4. A Few Rules of Thumb for Designing an IPv6 ISP Addressing 949 Architecture 951 As outcome of the above enumeration of requirements regarding an ISP 952 IPv6 addressing plan the following design "rules of thumb" have been 953 derived: 954 o No "One size fits all". Each ISP must develop its own IPv6 955 address allocation schema depending on its concrete business 956 needs. It is not practicable to design one addressing plan that 957 fits for all kinds of ISPs (Small / big, Routed / MPLS-based, 958 access / transit, LIR / No-LIR, etc.). 959 o The levels of IPv6 address aggregation within the ISP addressing 960 schema should strongly correspond to the implemented network 961 structure and their number should be minimized because of 962 efficiency reasons. It is assumed that the SPs own infrastructure 963 will be addressed in a fairly flat way whereas the part of the 964 customer addressing architecture should contain several levels of 965 aggregation. 966 o Keep the number of IPv6 customer routes inside your network as 967 small as necessary. A totally flat customer IPv6 addressing 968 architecture without any intermediate aggregation level will lead 969 to lots of customer routes inside the SP network. A fair trade- 970 off between address aggregation levels (and hence the size of the 971 internal routing table of the SP) and address conservation of the 972 addressing architecture has to be found. 973 o The ISP IPv6 addressing schema should provide maximal flexibility. 974 This has to be realized for supporting different sizes of customer 975 IPv6 address aggregates ("big" customers vs. "small" customers) as 976 well as to allow future growing rates (e.g. of customer 977 aggregates) and possible topological or infrastructural changes. 978 o A limited number of aggregation levels and sizes of customer 979 aggregates will ease the management of the addressing schema. 980 This has to be weighed against the previous "thumb rule" - 981 flexibility. 983 A.2.2. Exemplary IPv6 Address Allocation Plan for a Service Provider 985 In this example, the Service Provider is assumed to operate an MPLS 986 based backbone and implements 6PE [RFC4798] to provide IPv6 backbone 987 transport between the different locations (POPs) of a fully dual- 988 stacked network access and aggregation area. 990 Besides that it is assumed that the Service Provider: 991 o has received a /20 from its RIR 992 o operates its own LIR 993 o has to address its own IPv6 infrastructure 994 o delegates prefixes from this aggregate to its customers 996 This addressing schema should illustrate how the /20 IPv6 prefix of 997 the SP can be used to address the SP-own infrastructure and to 998 delegate IPv6 prefixes to its customers following the above mentioned 999 requirements and rules of thumb as far as possible. 1001 The below figure summarizes the device types in a SP network and the 1002 typical network design of a MPLS-based service provider. The network 1003 hierarchy of the SP has to be taken into account for the design of an 1004 IPv6 addressing schema and defines its basic shape and the various 1005 levels of aggregation. 1007 +------------------------------------------------------------------+ 1008 | LSRs of the MPLS Backbone of the SP | 1009 +------------------------------------------------------------------+ 1010 | | | | | 1011 | | | | | 1012 +-----+ +-----+ +--------+ +--------+ +--------+ 1013 | LER | | LER | | LER-BB | | LER-BB | | LER-BB | 1014 +-----+ +-----+ +--------+ +--------+ +--------+ 1015 | | | | | | / | | | 1016 | | | | | | / | | | 1017 | | | | +------+ +------+ +------+ | | 1018 | | | | |BB-RAR| |BB-RAR| | AG | | | 1019 | | | | +------+ +------+ +------+ | | 1020 | | | | | | | | | | | | 1021 | | | | | | | | | | | | 1022 | | | | | | | | +-----+ +-----+ +-----+ +-----+ 1023 | | | | | | | | | RAR | | RAR | | RAR | | RAR | 1024 | | | | | | | | +-----+ +-----+ +-----+ +-----+ 1025 | | | | | | | | | | | | | | | | 1026 | | | | | | | | | | | | | | | | 1027 +-------------------------------------------------------------------+ 1028 | Customer networks | 1029 +-------------------------------------------------------------------+ 1030 Figure: Exemplary Service Provider Network 1032 LSR ... Label Switch Router 1033 LER ... Label Edge Router 1034 LER-BB ... Broadband Label Edge Router 1035 RAR ... Remote Access Router 1036 BB-RAR ... Broadband Remote Access Router 1037 AG ... Aggregation Router 1039 Basic design decisions for the exemplary Service Provider IPv6 1040 address plan regarding customer prefixes take into consideration: 1041 o The prefixes assigned to all customers behind the same LER (e.g. 1042 LER or LER-BB) are aggregated under one LER prefix. This ensures 1043 that the number of labels that have to be used for 6PE is limited 1044 and hence provides a strong MPLS label conservation. 1045 o The /20 prefix of the SP is separated into 3 different pools that 1046 are used to allocate IPv6 prefixes to the customers of the SP: 1047 * A pool (e.g. /24) for satisfying the addressing needs of really 1048 "big" customers (as defined in A.2.2.1 sub-section A.) that 1049 need IPv6 prefixes larger than /48 (e.g. /32). These customers 1050 are assumed to be connected to several POPs of the access 1051 network, so that this customer prefix will be visible in each 1052 of these POPs. 1054 * A pool (e.g. /24) for the LERs with direct customer connections 1055 (e.g. dedicated line access) and without an additional 1056 aggregation area between the customer and the LER. (These LERs 1057 are mostly connected to a limited number of customers because 1058 of the limited number of interfaces/ports.) 1059 * A larger pool (e.g. 14*/24) for LERs (e.g. LER-BB) that serve 1060 a high number of customers that are normally connected via some 1061 kind of aggregation network (e.g. DSL customers behind a BB- 1062 RAR or Dial-In customers behind a RAR). 1063 * The IPv6 address delegation within each Pool (end customer 1064 delegation or also the aggregates that are dedicated to the 1065 LERs itself) should be chosen with an additional buffer zone of 1066 100% - 300% for future growth. I.e. 1 or 2 additional prefix 1067 bits should be reserved according to the expected future growth 1068 rate of the corresponding customer / the corresponding network 1069 device aggregate. 1071 A.2.2.1. Defining an IPv6 Address Allocation Plan for Customers of the 1072 Service Provider 1074 A.2.2.1.1. 'Big' Customers 1076 SP's "big" customers receive their prefix from the /24 IPv6 address 1077 aggregate that has been reserved for their "big" customers. A 1078 customer is considered as "big" customer if it has a very complex 1079 network infrastructure and/or huge IPv6 address needs (e.g. because 1080 of very large customer numbers) and/or several uplinks to different 1081 POPs of the SP network. 1083 The assigned IPv6 address prefixes can have a prefix length in the 1084 range 32-48 and for each assignment a 100 or 300% future growing zone 1085 is marked as "reserved" for this customer. This means for instance 1086 that with a delegation of a /34 to a customer the corresponding /32 1087 prefix (which contains this /34) is reserved for the customers future 1088 usage. 1090 The prefixes for the "big" customers can be chosen from the 1091 corresponding "big customer" pool by either using an equidistant 1092 algorithm or using mechanisms similar to the Sparse Allocation 1093 Algorithm (SAA) [reference2]. 1095 A.2.2.1.2. 'Common' Customers 1097 All customers that are not "big" customers are considered as "common" 1098 customers. They represent the majority of customers hence they 1099 receive a /48 out of the IPv6 customer address pool of the LER where 1100 they are directly connected or aggregated. 1102 Again a 100 - 300% future growing IPv6 address range is reserved for 1103 each customer, so that a "common" customer receives a /48 allocation 1104 but has a /47 or /46 reserved. 1106 (Note: If it is obvious that the likelyhood of needing a /47 or /46 1107 in the future is very small for a "common" customer, than no growing 1108 buffer should be reserved for it and only a /48 will be assigned 1109 without any growing buffer.) 1111 In the network access scenarios where the customer is directly 1112 connected to the LER the customer prefix is directly taken out of the 1113 customer IPv6 address aggregate (e.g. /38) of the corresponding LER. 1115 In all other cases (e.g. the customer is attached to a RAR that is 1116 themselves aggregated to an AG or to a LER-BB) at least 2 different 1117 approaches are possible. 1119 1) Mapping of Aggregation Network Hierarchy into Customer IPv6 1120 Addressing Schema. The aggregation network hierarchy could be mapped 1121 into the design of the customer prefix pools of each network level in 1122 order to achieve a maximal aggregation at the LER level as well as at 1123 the intermediate levels. (Example: Customer - /48, RAR - /38, AG - 1124 /32, LER-BB - /30). At each network level an adequate growing zone 1125 should be reserved. (Note: This approach requires of course some 1126 "fine tuning" of the addressing schema based on a very good knowledge 1127 of the Service Provider network topology including actual growing 1128 ranges and rates.) 1130 When the IPv6 customer address pool of a LER (or another device of 1131 the aggregation network - AG or RAR) is exhausted, the related LER 1132 (or AG or RAR) prefix is shortened by 1 or 2 bits (e.g. from /38 to 1133 /37 or /36) so that the originally reserved growing zone can be used 1134 for further IPv6 address allocations to customers. In the case where 1135 this growing zone is exhausted as well a new prefix range from the 1136 corresponding pool of the next higher hierarchy level can be 1137 requested. 1139 2) "Flat" Customer IPv6 Addressing Schema. The other option is to 1140 allocate all the customer prefixes directly out of the customer IPv6 1141 address pool of the LER where the customers are attached and 1142 aggregated and to ignore the intermediate aggregation network 1143 infrastructure. This approach leads of course to a higher amount of 1144 customer routes at LER and aggregation network level but takes a 1145 great amount of complexity out of the addressing schema. 1146 Nevertheless the aggregation of the customer prefixes to one prefix 1147 at LER level is realized as required above. 1149 (Note: The handling of (e.g. technically triggered) changes within 1150 the ISP access network is shortly discussed in section A.2.3.5.) 1152 If the actual observed growing rates show that the reserved growing 1153 zones are not needed than these growing areas can be freed and used 1154 for assignments for prefix pools to other devices at the same level 1155 of the network hierarchy. 1157 A.2.2.2. Defining an IPv6 Address Allocation Plan for the Service 1158 Provider Network Infrastructure 1160 For the IPv6 addressing of SPs own network infrastructure a /32 (or 1161 /40) from the "big" customers address pool can be chosen. 1163 This SP infrastructure prefix is used to code the network 1164 infrastructure of the SP by assigning a /48 to every POP/location and 1165 using for instance a /56 for coding the corresponding router within 1166 this POP. Each SP internal link behind a router interface could be 1167 coded using a /64 prefix. (Note: While it is suggested to choose a 1168 /48 for addressing the POP/location of the SP network it is left to 1169 each SP to decide what prefix length to assign to the routers and 1170 links within this POP.) 1172 The IIDs of the router interfaces may be generated by using EUI-64 or 1173 through plain manual configuration e.g. for coding additional network 1174 or operational information into the IID. 1176 It is assumed that again 100 - 300% growing zones for each level of 1177 network hierarchy and additional prefix bits may be assigned to POPs 1178 and/or routers if needed. 1180 Loopback interfaces of routers may be chosen from the first /64 of 1181 the /56 router prefix (in the example above). 1183 (Note: The /32 (or /40) prefix that has been chosen for addressing 1184 SPs own IPv6 network infrastructure gives enough place to code 1185 additional functionalities like security levels or private and test 1186 infrastructure although such approaches haven't been considered in 1187 more detail for the above described SP until now.) 1189 Point-to-point links to customers (e.g. PPP links, dedicated line 1190 etc.) may be addressed using /126 prefixes out of the first /64 of 1191 the access routers that could be reserved for this reason. 1193 A.2.3. Additional Remarks 1194 A.2.3.1. ULA 1196 From the actual view point of SP there is no compelling reason why 1197 ULAs should be used from a SP. Look at section 2.2. 1199 ULAs could be used inside the SP network in order to have an 1200 additional "site-local scoped" IPv6 address for SPs own 1201 infrastructure for instance for network management reasons and maybe 1202 also in order to have an addressing schema that couldn't be reached 1203 from outside the SP network. 1205 In the case when ULAs are used it is possible to map the proposed 1206 internal IPv6 addressing of SPs own network infrastructure as 1207 described in A.2.2.2 above directly to the ULA addressing schema by 1208 substituting the /48 POP prefix with a /48 ULA site prefix. 1210 A.2.3.2. Multicast 1212 IPv6 Multicast-related addressing issues are out of the scope of this 1213 document. 1215 A.2.3.3. POP Multi-homing 1217 POP (or better LER) Multi-homing of customers with the same SP can be 1218 realized within the proposed IPv6 addressing schema of the SP by 1219 assigning multiple LER-dependent prefixes to this customer (i.e. 1220 considering each customer location as a single-standing customer) or 1221 by choosing a customer prefix out of the pool of "big" customers. 1222 The second solution has the disadvantage that in every LER where the 1223 customer is attached this prefix will appear inside the IGP routing 1224 table requiring an explicit MPLS label. 1226 (Note: The described negative POP/LER Multi-homing effects to the 1227 addressing architecture in the SP access network are not tackled by 1228 implementing the Shim6 Site Multi-homing approach since this approach 1229 targets only on a mechanism for dealing with multiple prefixes in end 1230 systems -- the SP will nevertheless have unaggregated customer 1231 prefixes in its internal routing tables.) 1233 A.2.3.4. Changing Point of Network Attachement 1235 In the possible case that a customer has to change its point of 1236 network attachment to another POP/LER within the ISP access network 1237 two different approaches can be applied assuming that the customer 1238 uses PA addresses out of the SP aggregate: 1240 1.) The customer has to renumber its network with an adequate 1241 customer prefix out of the aggregate of the corresponding LER/RAR of 1242 its new network attachement. To minimise the administrative burden 1243 for the customer the prefix should be of the same size as the former. 1244 This conserves the IPv6 address aggregation within the SP network 1245 (and the MPLS label space) but adds additional burden to the 1246 customer. Hence this approach will most likely only be chosen in the 1247 case of "small customers" with temporary addressing needs and/or 1248 prefix delegation with address auto-configuration. 1250 2.) The customer does not need to renumber its network and keeps its 1251 address aggregate. 1253 This apporach leads to additional more-specific routing entries 1254 within the IGP routing table of the LER and will hence consume 1255 additional MPLS labels - but it is totally transparent to the 1256 customer. Because this results in additional administrative effort 1257 and will stress the router resources (label space, memory) of the ISP 1258 this solution will only be offered to the most valuable customers of 1259 an ISP (like e.g. "big customers" or "enterprise customers"). 1261 Nevertheless the ISP has again to find a fair trade-off between 1262 customer renumbering and sub-optimal address aggregation (i.e. the 1263 generation of additional more-specific routing entries within the IGP 1264 and the waste of MPLS Label space). 1266 A.2.3.5. Restructuring of SP (access) Network and Renumbering 1268 A technically triggered restructuring of the SP (access) network (for 1269 instance because of split of equipment or installation of new 1270 equipment) should not lead to a customer network renumbering. This 1271 challenge should be handled in advance by an intelligent network 1272 design and IPv6 address planing. 1274 In the worst case the customer network renumbering could be avoided 1275 through the implementation of more specific customer routes. (Note: 1276 Since this kind of network restructuring will mostly happen within 1277 the access network (at the level) below the LER, the LER aggregation 1278 level will not be harmed and the more-specific routes will not 1279 consume additional MPLS label space.) 1281 A.2.3.6. Extensions Needed for the Later IPv6 Migration Phases 1283 The proposed IPv6 addressing schema for a SP needs some slight 1284 enhancements / modifications for the later phases of IPv6 1285 integration, for instance in the case when the whole MPLS backbone 1286 infrastructure (LDP, IGP etc.) is realized over IPv6 transport and an 1287 IPv6 addressing of the LSRs is needed. Other changes may be 1288 necessary as well but should not be explained at this point. 1290 Appendix B. Considerations for Subnet Prefixes Different then /64 1292 B.1. Considerations for Subnet Prefixes Shorter then /64 1294 An allocation of a prefix shorter then 64 bits to a node or interface 1295 is considered bad practice. One exception to this statement is when 1296 using 6to4 technology where a /16 prefix is utilized for the pseudo- 1297 interface [RFC3056]. The shortest subnet prefix that could 1298 theoretically be assigned to an interface or node is limited by the 1299 size of the network prefix allocated to the organization. 1301 A possible reason for choosing the subnet prefix for an interface 1302 shorter then /64 is that it would allow more nodes to be attached to 1303 that interface compared to a prescribed length of 64 bits. This 1304 however is unnecessary for most networks considering that 2^64 1305 provides plenty of node addresses. 1307 The subnet prefix assignments can be made either by manual 1308 configuration, by a stateful Host Configuration Protocol [RFC3315], 1309 by a stateful prefix delegation mechanism [RFC3633] or implied by 1310 stateless autoconfiguration from prefix RAs. 1312 B.2. Considerations for Subnet Prefixes Longer then /64 1314 The following subsections describe subnet prefix values that should 1315 be avoided in deployments, because nodes who assume that the subnet 1316 prefix is /64 could treat them incorrectly. 1318 B.2.1. /126 Addresses 1320 126 bit subnet prefixes are typically used for point-to-point links 1321 similar to a the IPv4 address conservative /30 allocation for point- 1322 to-point links. The usage of this subnet address length does not 1323 lead to any additional considerations other than the ones discussed 1324 earlier in this section, particularly those related to the "u" and 1325 "g" bits. 1327 B.2.2. /127 Addresses 1329 The usage of the /127 addresses, the equivalent of IPv4's RFC3021 1330 [RFC3021] is not valid and should be strongly discouraged as 1331 documented in RFC3627 [RFC3627]. 1333 B.2.3. /128 Addresses 1335 The 128 bit address prefix may be used in those situations where we 1336 know that one, and only one address is sufficient. Example usage 1337 would be the off-link loopback address of a network device. 1339 When choosing a 128 bit prefix, it is recommended to take the "u" and 1340 "g" bits into consideration and to make sure that there is no overlap 1341 with either the following well-known addresses: 1342 o Subnet Router Anycast Address 1343 o Reserved Subnet Anycast Address 1344 o Addresses used by Embedded-RP 1345 o ISATAP Addresses 1347 B.2.4. EUI-64 'u' and 'g' bits 1349 When using subnet prefix lengths other than /64, the interface 1350 identifier cannot be in Modified EUI-64 format as required by 1351 [RFC4291]. However, nodes not aware that a prefix length other than 1352 /64 is used might still think it's an EUI-64; therefore, it's prudent 1353 to take the next considerations to set the bits into account. 1355 Address space conservation is the main motivation for using a subnet 1356 prefix length longer than 64 bits, however this kind of address 1357 conservation is of little benefit compared with the additional 1358 considerations one must make when creating and maintain an IPv6 1359 address plan. 1361 The address assignment can be made either by manual configuration or 1362 by a stateful Host Configuration Protocol [RFC3315]. 1364 When assigning a subnet prefix of more then 70 bits, according to 1365 RFC4291 [RFC4291] 'u' and 'g' bits (respectively the 71st and 72nd 1366 bit) need to be taken into consideration and should be set correct. 1368 The 'u' (universal/local) bit is the 71st bit of IPv6 address and is 1369 used to determine whether the address is universally or locally 1370 administered. If 0, the IEEE, through the designation of a unique 1371 company ID, has administered the address. If 1, the address is 1372 locally administered. The network administrator has overridden the 1373 manufactured address and specified a different address. 1375 The 'g' (the individual/group) bit is the 72st bit and is used to 1376 determine whether the address is an individual address (unicast) or a 1377 group address (multicast). If '0', the address is a unicast address. 1378 If '1', the address is a multicast address. 1380 In current IPv6 protocol stacks, the relevance of the 'u' and 'g' bit 1381 is marginal and typically will not show an issue when configured 1382 wrongly, however future implementations may turn out differently if 1383 they would be processing the 'u' and 'g' bit in IEEE like behavior. 1385 When using subnet lengths longer then 64 bits, it is important to 1386 avoid selecting addresses that may have a predefined use and could 1387 confuse IPv6 protocol stacks. The alternate usage may not be a 1388 simple unicast address in all cases. The following points should be 1389 considered when selecting a subnet length longer then 64 bits. 1391 B.2.5. Anycast Addresses 1393 B.2.5.1. Subnet Router Anycast Address 1395 RFC4291 [RFC4291] provides a definition for the required Subnet 1396 Router Anycast Address as follows: 1398 | n bits | 128-n bits | 1399 +--------------------------------------------+----------------+ 1400 | subnet prefix | 00000000000000 | 1401 +--------------------------------------------+----------------+ 1403 It is recommended to avoid allocating this IPv6 address to a device 1404 which expects to have a normal unicast address. There is no 1405 additional dependency for the subnet prefix with the exception of the 1406 64-bit extended unique identifier (EUI-64) and an Interface 1407 Identifier (IID) dependency. These will be discussed later in this 1408 document. 1410 B.2.5.2. Reserved IPv6 Subnet Anycast Addresses 1412 RFC2526 [RFC2526] stated that within each subnet, the highest 128 1413 interface identifier values are reserved for assignment as subnet 1414 anycast addresses. 1416 The construction of a reserved subnet anycast address depends on the 1417 type of IPv6 addresses used within the subnet, as indicated by the 1418 format prefix in the addresses. 1420 The first type of Subnet Anycast addresses have been defined as 1421 follows for EUI-64 format: 1423 | 64 bits | 57 bits | 7 bits | 1424 +------------------------------+------------------+------------+ 1425 | subnet prefix | 1111110111...111 | anycast ID | 1426 +------------------------------+------------------+------------+ 1428 The anycast address structure implies that it is important to avoid 1429 creating a subnet prefix where the bits 65 to 121 are defined as 1430 "1111110111...111" (57 bits in total) so that confusion can be 1431 avoided. 1433 For other IPv6 address types (that is, with format prefixes other 1434 than those listed above), the interface identifier is not in 64-bit 1435 extended unique identifier (EUI-64) format and may be other than 64 1436 bits in length; these reserved subnet anycast addresses for such 1437 address types are constructed as follows: 1439 | n bits | 121-n bits | 7 bits | 1440 +------------------------------+------------------+------------+ 1441 | subnet prefix | 1111111...111111 | anycast ID | 1442 +------------------------------+------------------+------------+ 1443 | interface identifier field | 1445 It is recommended to avoid allocating this IPv6 address to a device 1446 which expects to have a normal unicast address. There is no 1447 additional dependency for the subnet prefix with the exception of the 1448 EUI-64 and an Interface Identifier (IID) dependency. These will be 1449 discussed later in this document. 1451 B.2.6. Addresses Used by Embedded-RP (RFC3956) 1453 Embedded-RP [RFC3956] reflects the concept of integrating the 1454 Rendezvous Point (RP) IPv6 address into the IPv6 multicast group 1455 address. Due to this embedding and the fact that the length of the 1456 IPv6 address AND the IPv6 multicast address are 128 bits, it is not 1457 possible to have the complete IPv6 address of the multicast RP 1458 embedded as such. 1460 This resulted in a restriction of 15 possible RP-addresses per prefix 1461 that can be used with embedded-RP. The space assigned for the 1462 embedded-RP is based on the 4 low order bits, while the remainder of 1463 the Interface ID (RIID) is set to all '0'. 1465 (IPv6-prefix (64 bits))(60 bits all '0')(RIID) 1467 Where: (RIID) = 4 bit. 1469 This format implies that when selecting subnet prefixes longer then 1470 64, and the bits beyond the 64th one are non-zero, the subnet can not 1471 use embedded-RP. 1473 In addition it is discouraged to assign a matching embedded-RP IPv6 1474 address to a device that is not a real Multicast Rendezvous Point, 1475 even though it would not generate major problems. 1477 B.2.7. ISATAP Addresses 1479 ISATAP [RFC5214] is an experimental automatic tunneling protocol used 1480 to provide IPv6 connectivity over an IPv4 campus or enterprise 1481 environment. In order to leverage the underlying IPv4 1482 infrastructure, the IPv6 addresses are constructed in a special 1483 format. 1485 An IPv6 ISATAP address has the IPv4 address embedded, based on a 1486 predefined structure policy that identifies them as an ISATAP 1487 address. 1489 [IPv6 Prefix (64 bits)][0000:5EFE][IPv4 address] 1491 When using subnet prefix length longer then 64 bits it is good 1492 engineering practice that the portion of the IPv6 prefix from bit 65 1493 to the end of the host-id does not match with the well-known ISATAP 1494 [0000:5EFE] address when assigning an IPv6 address to a non-ISATAP 1495 interface. 1497 Note that the definition of ISATAP does not support multicast. 1499 Authors' Addresses 1501 Gunter Van de Velde 1502 Cisco Systems 1503 De Kleetlaan 6a 1504 Diegem 1831 1505 Belgium 1507 Phone: +32 2704 5473 1508 Email: gunter@cisco.com 1509 Ciprian Popoviciu 1510 Cisco Systems 1511 7025-6 Kit Creek Road 1512 Research Triangle Park, North Carolina PO Box 14987 1513 USA 1515 Phone: +1 919 392-3723 1516 Email: cpopovic@cisco.com 1518 Tim Chown 1519 University of Southampton 1520 Highfield 1521 Southampton, SO17 1BJ 1522 United Kingdom 1524 Phone: +44 23 8059 3257 1525 Email: tjc@ecs.soton.ac.uk 1527 Olaf Bonness 1528 T-Systems Enterprise Services GmbH 1529 Goslarer Ufer 35 1530 Berlin, 10589 1531 Germany 1533 Phone: +49 30 3497 3124 1534 Email: Olaf.Bonness@t-systems.com 1536 Christian Hahn 1537 T-Systems Enterprise Services GmbH 1538 Goslarer Ufer 35 1539 Berlin, 10589 1540 Germany 1542 Phone: +49 30 3497 3164 1543 Email: HahnC@t-systems.com 1545 Full Copyright Statement 1547 Copyright (C) The IETF Trust (2008). 1549 This document is subject to the rights, licenses and restrictions 1550 contained in BCP 78, and except as set forth therein, the authors 1551 retain all their rights. 1553 This document and the information contained herein are provided on an 1554 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1555 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1556 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1557 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1558 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1559 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1561 Intellectual Property 1563 The IETF takes no position regarding the validity or scope of any 1564 Intellectual Property Rights or other rights that might be claimed to 1565 pertain to the implementation or use of the technology described in 1566 this document or the extent to which any license under such rights 1567 might or might not be available; nor does it represent that it has 1568 made any independent effort to identify any such rights. Information 1569 on the procedures with respect to rights in RFC documents can be 1570 found in BCP 78 and BCP 79. 1572 Copies of IPR disclosures made to the IETF Secretariat and any 1573 assurances of licenses to be made available, or the result of an 1574 attempt made to obtain a general license or permission for the use of 1575 such proprietary rights by implementers or users of this 1576 specification can be obtained from the IETF on-line IPR repository at 1577 http://www.ietf.org/ipr. 1579 The IETF invites any interested party to bring to its attention any 1580 copyrights, patents or patent applications, or other proprietary 1581 rights that may cover technology that may be required to implement 1582 this standard. Please address the information to the IETF at 1583 ietf-ipr@ietf.org.