idnits 2.17.1 draft-ietf-ipv6-unique-local-addr-08.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.a on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 732. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 4 instances of too long lines in the document, the longest one being 1 character in excess of 72. 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 2119' is mentioned on line 106, but not defined == Unused Reference: 'RFC2119' is defined on line 554, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3513 (ref. 'ADDARCH') (Obsoleted by RFC 4291) -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS' ** Downref: Normative reference to an Informational RFC: RFC 3587 (ref. 'GLOBAL') ** Obsolete normative reference: RFC 2463 (ref. 'ICMPV6') (Obsoleted by RFC 4443) ** Obsolete normative reference: RFC 2460 (ref. 'IPV6') (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 1305 (ref. 'NTP') (Obsoleted by RFC 5905) ** Obsolete normative reference: RFC 1750 (ref. 'RANDOM') (Obsoleted by RFC 4086) ** Downref: Normative reference to an Informational RFC: RFC 3174 (ref. 'SHA1') -- Obsolete informational reference (is this intentional?): RFC 2462 (ref. 'ADDAUTO') (Obsoleted by RFC 4862) -- Obsolete informational reference (is this intentional?): RFC 3484 (ref. 'ADDSEL') (Obsoleted by RFC 6724) -- Obsolete informational reference (is this intentional?): RFC 3315 (ref. 'DHCP6') (Obsoleted by RFC 8415) Summary: 16 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT R. Hinden, Nokia 2 November 16, 2004 B. Haberman, JHU-APL 4 Unique Local IPv6 Unicast Addresses 6 8 Status of this Memo 10 This document is an Internet-Draft and is subject to all provisions 11 of section 3 of RFC 3667. By submitting this Internet-Draft, each 12 author represents that any applicable patent or other IPR claims of 13 which he or she is aware have been or will be disclosed, and any of 14 which he or she become aware will be disclosed, in accordance with 15 RFC 3668. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This internet draft expires on May 21, 2005. 35 Abstract 37 This document defines an IPv6 unicast address format that is globally 38 unique and is intended for local communications, usually inside of a 39 site. They are not expected to be routable on the global Internet. 41 Table of Contents 43 1.0 Introduction....................................................2 44 2.0 Acknowledgments.................................................3 45 3.0 Local IPv6 Unicast Addresses....................................3 46 3.1 Format..........................................................3 47 3.1.1 Background....................................................4 48 3.2 Global ID.......................................................5 49 3.2.1 Locally Assigned Global IDs...................................5 50 3.2.2 Sample Code for Pseudo-Random Global ID Algorithm.............6 51 3.2.3 Analysis of the Uniqueness of Global IDs......................6 52 3.3 Scope Definition................................................7 53 4.0 Operational Guidelines..........................................7 54 4.1 Routing.........................................................7 55 4.2 Renumbering and Site Merging....................................8 56 4.3 Site Border Router and Firewall Packet Filtering................8 57 4.4 DNS Issues......................................................9 58 4.5 Application and Higher Level Protocol Issues....................9 59 4.6 Use of Local IPv6 Addresses for Local Communications...........10 60 4.7 Use of Local IPv6 Addresses with VPNs..........................11 61 5.0 Advantages and Disadvantages...................................11 62 6.0 Security Considerations........................................12 63 7.0 IANA Considerations............................................12 64 8.0 References.....................................................12 65 8.1 Normative References...........................................12 66 8.2 Informative References.........................................13 67 9.0 Authors' Addresses.............................................13 68 10.0 Change Log....................................................15 69 11.0 Disclaimer of Validity........................................17 70 12.0 Copyright Statement...........................................17 72 1.0 Introduction 74 This document defines an IPv6 unicast address format that is globally 75 unique and is intended for local communications [IPV6]. These 76 addresses are called Unique Local IPv6 Unicast Addresses and are 77 abbreviated in this document as Local IPv6 addresses. They are not 78 expected to be routable on the global Internet. They are routable 79 inside of a more limited area such as a site. They may also be 80 routed between a limited set of sites. 82 Local IPv6 unicast addresses have the following characteristics: 84 - Globally unique prefix. 85 - Well known prefix to allow for easy filtering at site 86 boundaries. 87 - Allows sites to be combined or privately interconnected without 88 creating any address conflicts or requiring renumbering of 89 interfaces using these prefixes. 90 - Internet Service Provider independent and can be used for 91 communications inside of a site without having any permanent or 92 intermittent Internet connectivity. 93 - If accidentally leaked outside of a site via routing or DNS, 94 there is no conflict with any other addresses. 95 - In practice, applications may treat these addresses like global 96 scoped addresses. 98 This document defines the format of Local IPv6 addresses, how to 99 allocate them, and usage considerations including routing, site 100 border routers, DNS, application support, VPN usage, and guidelines 101 for how to use for local communication inside a site. 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 105 document are to be interpreted as described in [RFC 2119]. 107 2.0 Acknowledgments 109 The underlying idea of creating Local IPv6 addresses described in 110 this document been proposed a number of times by a variety of people. 111 The authors of this draft do not claim exclusive credit. Credit goes 112 to Brian Carpenter, Christian Huitema, Aidan Williams, Andrew White, 113 Charlie Perkins, and many others. The authors would also like to 114 thank Brian Carpenter, Charlie Perkins, Harald Alvestrand, Keith 115 Moore, Margaret Wasserman, Shannon Behrens, Alan Beard, Hans Kruse, 116 Geoff Huston, Pekka Savola, Christian Huitema, Tim Chown, Steve 117 Bellovin, Alex Zinin, Tony Hain, and Bill Fenner for their comments 118 and suggestions on this document. 120 3.0 Local IPv6 Unicast Addresses 122 3.1 Format 124 The Local IPv6 addresses are created using a pseudo-randomly 125 allocated global ID. They have the following format: 127 | 7 bits |1| 40 bits | 16 bits | 64 bits | 128 +--------+-+------------+-----------+-----------------------------+ 129 | prefix |L| global ID | subnet ID | interface ID | 130 +--------+-+------------+-----------+-----------------------------+ 132 Where: 134 prefix FC00::/7 prefix to identify Local IPv6 unicast 135 addresses. 137 L Set to 1 if the prefix is locally assigned, 138 Set to 0 if it is centrally assigned. See 139 section 3.2 for additional information. 141 global ID 40-bit global identifier used to create a 142 globally unique prefix. See section 3.2 for 143 additional information. 145 subnet ID 16-bit subnet ID is an identifier of a subnet 146 within the site. 148 interface ID 64-bit interface ID as defined in [ADDARCH]. 150 3.1.1 Background 152 There were a range of choices available when choosing the size of the 153 prefix and global ID field length. There is a direct tradeoff 154 between having a global ID field large enough to support foreseeable 155 future growth and not using too much of the IPv6 address space 156 needlessly. A reasonable way of evaluating a specific field length 157 is to compare it to a projected 2050 world population of 9.3 billion 158 [POPUL] and the number of resulting /48 prefixes per person. A range 159 of prefix choices is shown in the following table: 161 Prefix Global ID Number of Prefixes % of IPv6 162 Length /48 Prefixes per Person Address Space 164 /11 37 137,438,953,472 15 0.049% 165 /10 38 274,877,906,944 30 0.098% 166 /9 39 549,755,813,888 59 0.195% 167 /8 40 1,099,511,627,776 118 0.391% 168 /7 41 2,199,023,255,552 236 0.781% 169 /6 42 4,398,046,511,104 473 1.563% 171 A very high utilization ratio of these allocations can be assumed 172 because the global ID field does not require internal structure, and 173 there is no reason to be able to aggregate the prefixes. 175 The authors believe that a /7 prefix resulting in a 40 bit global ID 176 is a good choice. It provides for a large number of assignments 177 (i.e., 2.2 trillion) and at the same time uses less than .8% of the 178 total IPv6 address space. It is unlikely that this space will be 179 exhausted. If more than this were to be needed, then additional IPv6 180 address space could be allocated for this purpose. 182 3.2 Global ID 184 The allocation of global IDs should be pseudo-random [RANDOM]. They 185 should not be assigned sequentially or with well known numbers. This 186 is to ensure that there is not any relationship between allocations 187 and to help clarify that these prefixes are not intended to be routed 188 globally. Specifically, these prefixes are not designed to 189 aggregate. 191 There are two ways to allocate Global IDs. These are centrally by a 192 allocation authority and locally by the site. The type of allocation 193 is distinguished by the L bit. 195 Two assignment methods are included because they have different 196 properties. The centrally assigned global IDs are uniquely assigned. 197 The local assignments are self generated and do not need any central 198 coordination or assignment, but have a lower (but still adequate) 199 probability of being unique. It is expected that large managed sites 200 will prefer central assignments and small or disconnected sites will 201 prefer local assignments. It is recommended that sites planning to 202 use Local IPv6 addresses for extensive inter-site communication, 203 initially or as a future possibility, use a centrally assigned prefix 204 as there is no possibility of assignment conflicts. Sites are free 205 to choose either approach. 207 This document only defines the allocation procedure for creating 208 global-IDs for locally assigned local IPv6 addresses (i.e., L=1). 209 The allocation procedure for centrally assigned local IPv6 addresses 210 (i.e., L=0) will be defined in a separate document. 212 3.2.1 Locally Assigned Global IDs 214 Global IDs can be generated locally by an individual site. This 215 makes it easy to get a prefix without the need to contact an 216 assignment authority or internet service provider. There is not as 217 high a degree of assurance that the prefix will not conflict with 218 another locally generated prefix, but the likelihood of conflict is 219 small. Sites that are not comfortable with this degree of 220 uncertainty should use a centrally assigned global ID. 222 Locally assigned global IDs MUST be generated with a pseudo-random 223 algorithm consistent with [RANDOM]. Section 3.2.2 describes a 224 suggested algorithm. It is important to ensure a reasonable 225 likelihood uniqueness that all sites generating a Global IDs use a 226 functionally similar algorithm. 228 The use of a pseudo-random algorithm to generate global IDs in the 229 locally assigned prefix gives an assurance that any network numbered 230 using such a prefix is highly unlikely to have that address space 231 clash with any other network that has another locally assigned prefix 232 allocated to it. This is a particularly useful property when 233 considering a number of scenarios including networks that merge, 234 overlapping VPN address space, or hosts mobile between such networks. 236 3.2.2 Sample Code for Pseudo-Random Global ID Algorithm 238 The algorithm described below is intended to be used for locally 239 assigned Global IDs. In each case the resulting global ID will be 240 used in the appropriate prefix as defined in section 3.2. 242 1) Obtain the current time of day in 64-bit NTP format [NTP]. 243 2) Obtain an EUI-64 identifier from the system running this 244 algorithm. If an EUI-64 does not exist, one can be created from 245 a 48-bit MAC address as specified in [ADDARCH]. If an EUI-64 246 cannot be obtained or created, a suitably unique identifier, 247 local to the node, should be used (e.g. system serial number). 248 3) Concatenate the time of day with the system-specific identifier 249 creating a key. 250 4) Compute an SHA-1 digest on the key as specified in [FIPS, SHA1]; 251 the resulting value is 160 bits. 252 5) Use the least significant 40 bits as the Global ID. 253 6) Concatenate FC00::/7, the L bit set to 1, and the 40 bit Global 254 ID to create a Local IPv6 address prefix. 256 This algorithm will result in a global ID that is reasonably unique 257 and can be used to create a locally assigned local IPv6 address 258 prefix. 260 3.2.3 Analysis of the Uniqueness of Global IDs 262 The selection of a pseudo random global ID is similar to the 263 selection of an SSRC identifier in RTP/RTCP defined in section 8.1 of 264 [RTP]. This analysis is adapted from that document. 266 Since global IDs are chosen randomly (and independently), it is 267 possible that separate networks have chosen the same global ID. For 268 any given network with one or more random global IDs that has inter- 269 connections to other such networks, having a total of N such IDs, the 270 probability of that two or more of these IDs will collide can be 271 approximated using the formula: 273 P = 1 - exp(-N**2 / 2**(L+1)) 275 approximates the probability of collision (where N is the number 276 connections and L is the length of the global ID). 278 The following table shows the probability of a collision for a range 279 of connections using a 40 bit global ID field. 281 Connections Probability of Collision 283 2 1.81*10^-12 284 10 4.54*10^-11 285 100 4.54*10^-09 286 1000 4.54*10^-07 287 10000 4.54*10^-05 289 Based on this analysis the uniqueness of locally generated global IDs 290 is adequate for sites planning a small to moderate amount of inter- 291 site communication using locally generated global IDs. Sites 292 planning more extensive inter-site communication should consider 293 using the centrally assigned global ID. 295 3.3 Scope Definition 297 By default, the scope of these addresses is global. That is, they 298 are not limited by ambiguity like the site-local addresses defined in 299 [ADDARCH]. Rather, these prefixes are globally unique, and as such, 300 their applicability is greater than site-local addresses. Their 301 limitation is in the routability of the prefixes, which is limited to 302 a site and any explicit routing agreements with other sites to 303 propagate them. Also, unlike site-locals, a site may have more than 304 one of these prefixes and use them at the same time. 306 4.0 Operational Guidelines 308 The guidelines in this section do not require any change to the 309 normal routing and forwarding functionality in an IPv6 host or 310 router. These are configuration and operational usage guidelines. 312 4.1 Routing 314 Local IPv6 addresses are designed to be routed inside of a site in 315 the same manner as other types of unicast addresses. They can be 316 carried in any IPv6 routing protocol without any change. 318 It is expected that they would share the same subnet IDs with 319 provider based global unicast addresses if they were being used 320 concurrently [GLOBAL]. 322 The default behavior of exterior routing protocol sessions between 323 administrative routing regions must be to ignore receipt of and not 324 advertise prefixes in the FC00::/7 block. A network operator may 325 specifically configure prefixes longer than FC00::/7 for inter-site 326 communication. 328 If BGP is being used at the site border with an ISP, the default BGP 329 configuration must filter out any Local IPv6 address prefixes, both 330 incoming and outgoing. It must be set both to keep any Local IPv6 331 address prefixes from being advertised outside of the site as well as 332 to keep these prefixes from being learned from another site. The 333 exception to this is if there are specific /48 or longer routes 334 created for one or more Local IPv6 prefixes. 336 For link-state IGPs, it is suggested that a site utilizing ULA 337 prefixes be contained either within one IGP domain or area. By 338 containing a ULA prefix to a single link-state area or domain, the 339 distribution of prefixes can be controlled. 341 4.2 Renumbering and Site Merging 343 The use of Local IPv6 addresses in a site results in making 344 communication using these addresses independent of renumbering a 345 site's provider based global addresses. 347 When merging multiple sites the addresses created with these prefixes 348 are unlikely to need to be renumbered because all of the addresses 349 have a high probability of being unique. Routes for each specific 350 prefix would have to be configured to allow routing to work correctly 351 between the formerly separate sites. 353 4.3 Site Border Router and Firewall Packet Filtering 355 While no serious harm will be done if packets with these addresses 356 are sent outside of a site via a default route, it is recommended 357 that routers be configured by default to keep any packets with Local 358 IPv6 destination addresses from leaking outside of the site and to 359 keep any site prefixes from being advertised outside of their site. 361 Site border routers should be configured to install a "reject" route 362 for the Local IPv6 prefix FC00::/7. This will ensure that packets 363 with Local IPv6 destination addresses will not be forwarded outside 364 of the site via a default route. Site border routers should respond 365 with the appropriate ICMPv6 Destination Unreachable message to inform 366 the source that the packet was not forwarded [ICMPV6]. This feedback 367 is important to avoid transport protocol timeouts. 369 Site border routers and firewalls should be configured to not forward 370 any packets with Local IPv6 source or destination addresses outside 371 of the site unless they have been explicitly configured with routing 372 information about specific /48 or longer Local IPv6 prefixes. The 373 default behavior of these devices should be to install a "reject" 374 route for these prefixes. Site border routers should respond with 375 the appropriate ICMPv6 Destination Unreachable message to inform the 376 source that the packet was not forwarded. 378 Routers that maintain peering arrangements between Autonomous Systems 379 throughout the Internet should obey the recommendations for site 380 border routers unless configured otherwise. 382 4.4 DNS Issues 384 At the present time AAAA and PTR records for locally assigned local 385 IPv6 addresses are not recommended to be installed in the global DNS. 386 The operational issues relating to this are beyond the scope of this 387 document. 389 For background on this recommendation, the concern about adding AAAA 390 and PTR records to the global DNS for locally assigned local IPv6 391 addresses stems from the lack of complete assurance that the prefixes 392 are unique. There is a small possibility that the same PTR record 393 might be registered by two different organizations. Due to this 394 concern, adding AAAA records is thought to be unwise because matching 395 PTR records can not be registered 397 4.5 Application and Higher Level Protocol Issues 399 Application and other higher level protocols can treat Local IPv6 400 addresses in the same manner as other types of global unicast 401 addresses. No special handling is required. This type of addresses 402 may not be reachable, but that is no different from other types of 403 IPv6 global unicast addresses. Applications need to be able to 404 handle multiple addresses that may or may not be reachable any point 405 in time. In most cases this complexity should be hidden in APIs. 407 From a host's perspective this difference shows up as different 408 reachability than global unicast and could be handled by default that 409 way. In some cases it is better for nodes and applications to treat 410 them differently from global unicast addresses. A starting point 411 might be to give them preference over global unicast, but fall back 412 to global unicast if a particular destination is found to be 413 unreachable. Much of this behavior can be controlled by how they are 414 allocated to nodes and put into the DNS. However it is useful if a 415 host can have both types of addresses and use them appropriately. 417 Note that the address selection mechanisms of [ADDSEL], and in 418 particular the policy override mechanism replacing default address 419 selection, are expected to be used on a site where Local IPv6 420 addresses are configured. 422 4.6 Use of Local IPv6 Addresses for Local Communication 424 Local IPv6 addresses, like global scope unicast addresses, are only 425 assigned to nodes if their use has been enabled (via IPv6 address 426 autoconfiguration [ADDAUTO], DHCPv6 [DHCP6], or manually). They are 427 not created automatically the way that IPv6 link-local addresses are 428 and will not appear or be used unless they are purposely configured. 430 In order for hosts to autoconfigure Local IPv6 addresses, routers 431 have to be configured to advertise Local IPv6 /64 prefixes in router 432 advertisements, or a DHCPv6 server must have been configured to 433 assign them. In order for a node to learn the Local IPv6 address of 434 another node, the Local IPv6 address must have been installed in the 435 DNS or another naming system. For these reasons, it is straight 436 forward to control their usage in a site. 438 To limit the use of Local IPv6 addresses the following guidelines 439 apply: 441 - Nodes that are to only be reachable inside of a site: The local 442 DNS should be configured to only include the Local IPv6 443 addresses of these nodes. Nodes with only Local IPv6 addresses 444 must not be installed in the global DNS. 446 - Nodes that are to be limited to only communicate with other 447 nodes in the site: These nodes should be set to only 448 autoconfigure Local IPv6 addresses via [ADDAUTO] or to only 449 receive Local IPv6 addresses via [DHCP6]. Note: For the case 450 where both global and Local IPv6 prefixes are being advertised 451 on a subnet, this will require a switch in the devices to only 452 autoconfigure Local IPv6 addresses. 454 - Nodes that are to be reachable from inside of the site and from 455 outside of the site: The DNS should be configured to include 456 the global addresses of these nodes. The local DNS may be 457 configured to also include the Local IPv6 addresses of these 458 nodes. 460 - Nodes that can communicate with other nodes inside of the site 461 and outside of the site: These nodes should autoconfigure global 462 addresses via [ADDAUTO] or receive global address via [DHCP6]. 463 They may also obtain Local IPv6 addresses via the same 464 mechanisms. 466 4.7 Use of Local IPv6 Addresses with VPNs 468 Local IPv6 addresses can be used for inter-site Virtual Private 469 Networks (VPN) if appropriate routes are set up. Because the 470 addresses are unique these VPNs will work reliably and without the 471 need for translation. They have the additional property that they 472 will continue to work if the individual sites are renumbered or 473 merged. 475 5.0 Advantages and Disadvantages 477 5.1 Advantages 479 This approach has the following advantages: 481 - Provides Local IPv6 prefixes that can be used independently of 482 any provider based IPv6 unicast address allocations. This is 483 useful for sites not always connected to the Internet or sites 484 that wish to have a distinct prefix that can be used to localize 485 traffic inside of the site. 486 - Applications can treat these addresses in an identical manner as 487 any other type of global IPv6 unicast addresses. 488 - Sites can be merged without any renumbering of the Local IPv6 489 addresses. 490 - Sites can change their provider based IPv6 unicast address 491 without disrupting any communication using Local IPv6 addresses. 492 - Well known prefix that allows for easy filtering at site 493 boundary. 494 - Can be used for inter-site VPNs. 495 - If accidently leaked outside of a site via routing or DNS, there 496 is no conflict with any other addresses. 498 5.2 Disadvantages 500 This approach has the following disadvantages: 502 - Not possible to route Local IPv6 prefixes on the global Internet 503 with current routing technology. Consequentially, it is 504 necessary to have the default behavior of site border routers to 505 filter these addresses. 506 - There is a very low probability of non-unique locally assigned 507 global IDs being generated by the algorithm in section 3.2.3. 508 This risk can be ignored for all practical purposes, but it 509 leads to a theoretical risk of clashing address prefixes. 511 6.0 Security Considerations 513 Local IPv6 addresses do not provide any inherent security to the 514 nodes that use them. They may be used with filters at site 515 boundaries to keep Local IPv6 traffic inside of the site, but this is 516 no more or less secure than filtering any other type of global IPv6 517 unicast addresses. 519 Local IPv6 addresses do allow for address-based security mechanisms, 520 including IPsec, across end to end VPN connections. 522 7.0 IANA Considerations 524 The IANA is instructed to assign the FC00::/7 prefix for Unique Local 525 IPv6 unicast addresses. 527 8.0 References 529 8.1 Normative References 531 [ADDARCH] Hinden, R., S. Deering, S., "IP Version 6 Addressing 532 Architecture", RFC 3513, April 2003. 534 [FIPS] "Federal Information Processing Standards Publication", 535 (FIPS PUB) 180-1, Secure Hash Standard, 17 April 1995. 537 [GLOBAL] Hinden, R., S. Deering, E. Nordmark, "IPv6 Global Unicast 538 Address Format", RFC 3587, August 2003. 540 [ICMPV6] Conta, A., S. Deering, "Internet Control Message Protocol 541 (ICMPv6) for the Internet Protocol Version 6 (IPv6) 542 Specification", RFC2463, December 1998. 544 [IPV6] Deering, S., R. Hinden, "Internet Protocol, Version 6 545 (IPv6) Specification", RFC 2460, December 1998. 547 [NTP] Mills, David L., "Network Time Protocol (Version 3) 548 Specification, Implementation and Analysis", RFC 1305, 549 March 1992. 551 [RANDOM] Eastlake, D. 3rd, S. Crocker, J. Schiller, "Randomness 552 Recommendations for Security", RFC 1750, December 1994. 554 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 555 Requirement Levels", RFC 2119, BCP14, March 1997. 557 [SHA1] D. Eastlake 3rd, P. Jones, "US Secure Hash Algorithm 1 558 (SHA1)", RFC 3174, September 2001. 560 8.2 Informative References 562 [ADDAUTO] Thomson, S., T. Narten, "IPv6 Stateless Address 563 Autoconfiguration", RFC 2462, December 1998. 565 [ADDSEL] Draves, R., "Default Address Selection for Internet 566 Protocol version 6 (IPv6)", RFC 3484, February 2003. 568 [DHCP6] Droms, R., et. al., "Dynamic Host Configuration Protocol 569 for IPv6 (DHCPv6)", RFC3315, July 2003. 571 [POPUL] Population Reference Bureau, "World Population Data Sheet 572 of the Population Reference Bureau 2002", August 2002. 574 [RTP] Schulzrinne, H., S. Casner, R. Frederick, V. Jacobson, 575 "RTP: A Transport Protocol for Real-Time Applications" 576 RFC3550, July 2003. 578 9.0 Authors' Addresses 580 Robert M. Hinden 581 Nokia 582 313 Fairchild Drive 583 Mountain View, CA 94043 584 USA 586 phone: +1 650 625-2004 587 email: bob.hinden@nokia.com 588 Brian Haberman 589 Johns Hopkins University 590 Applied Physics Lab 591 11100 Johns Hopkins Road 592 Laurel, MD 20723 593 USA 595 phone: +1 443 778 1319 596 email: brian@innovationslab.net 598 10.0 Change Log 600 Draft 601 o Moved sections 4-10, into one new section 4.0 titled 602 "operational guidelines" to clarify the their scope. 603 o Clarified routing requirements to make it clearer that these 604 prefixes should not be routed on the global Internet. 605 o Various editorial changes. 607 Draft 608 o Changed the format in section 3.1 in add a "L" (local/central) 609 bit and reduced the size of the global-ID to 40 bits. This is 610 equivalent to the previous separate prefixes and makes the 611 document clearer. 612 o Changed pseudo-random algorithm to use SHA-1 instead of MD5. 613 o Moved [POPUL] to be an informative reference. 614 o Added paragraph in Routing section to discuss the use of IGPs. 615 o Various editorial changes. 617 Draft 618 o Clarify text to permit prefixes longer than /48 to be 619 configured. 620 o Changed text in section 7.0 to recommend that locally assigned 621 ULA addresses are not installed in the global DNS and removed 622 text about consequences of if they were installed in the global 623 DNS. 624 o Clarify the text in section 5.1 to state that there is a high 625 probability that there will be no address conflict when 626 renumbering. 627 o Several minor editorial changes. 629 Draft 630 o Removed the definition and technical requirements for centrally 631 assigned local address. The Centrally assigned local addresses 632 will be defined in a separate document. This document defines 633 the specific prefixes to be used for centrally and locally 634 assigned IPv6 local addresses, but only the locally assigned 635 local addresses are defined here. 637 Draft 639 o Clarified text in section 3.2.1 that central assigned prefixes 640 should be assigned under the authority of a single allocation 641 organization. 642 o Added step to suggested pseudo-random algorithm that in the case 643 of centrally assigned prefixes the computed global IDs should be 644 verified against the escrow. 645 o Added new text to section 3.2.2 that explains in more detail the 646 need for pseudo-random global IDs (i.e., avoid duplicate 647 allocations). 648 o Rewrote section 7.0 to describe DNS AAAA and PTR records, and 649 clarify when they might be installed in the global DNS. 650 o Various editorial changes. 652 Draft 654 o Removed requirement of a fee per central allocation and updated 655 IANA considerations to reflect this. Rewrote text to focus on 656 the requirement to avoid hoarding of allocations. 657 o Changed "filtering" and "black hole routes" to "reject" routes. 658 o Changed uppers case requirements (i.e., MUST, SHOULD, etc.) to 659 lower case in sections giving operational advice. 660 o Removed paragraph mentioning "Multicast DNS". 661 o Various editorial changes. 663 Draft 665 o Removed mention of 10 euro charge and changed text in section 666 3.2.1 and IANA considerations to restate the requirement for low 667 cost allocations and added specific requirement to prevent 668 hording. 669 o Added need to send ICMPv6 destination unreachable messages if 670 packets are filtered or dropped at site boundaries. 671 o Changed format section to list prefix sizes and definition, and 672 changed discussion of prefix sizes to new background section. 673 o Various editorial changes. 675 Draft 677 o Removed example of PIR as an example of an allocation authority 678 and clarified the text that the IANA should delegate the 679 centrally assigned prefix to an allocation authority. 680 o Changed sample code for generating pseudo random Global IDs to 681 not require any human input. Changes from using birthday to 682 unique token (e.g., EUI-64, serial number, etc.) available on 683 machine running the algorithm. 684 o Added a new section analyzing the uniqueness properties of the 685 pseudo random number algorithm. 686 o Added text to recommend that centrally assigned local addresses 687 be used for site planning extensive inter-site communication. 688 o Clarified that domain border routers should follow site border 689 router recommendations. 690 o Clarified that AAAA DNS records should not be installed in the 691 global DNS. 692 o Several editorial changes. 694 Draft 696 o Changed file name to become an IPv6 w.g. group document. 697 o Clarified language in Routing and Firewall sections. 698 o Several editorial changes. 700 Draft 702 o Changed title and name of addresses defined in this document to 703 "Unique Local IPv6 Unicast Addresses" with abbreviation of 704 "Local IPv6 addresses". 705 o Several editorial changes. 707 Draft 709 o Added section on scope definition and updated application 710 requirement section. 711 o Clarified that, by default, the scope of these addresses is 712 global. 713 o Renumbered sections and general text improvements 714 o Removed reserved global ID values 715 o Added pseudo code for local allocation submitted by Brian 716 Haberman and added him as an author. 717 o Split Global ID values into centrally assigned and local 718 assignments and added text to describe local assignments 720 Draft 722 o Initial Draft 724 11. Disclaimer of Validity 726 This document and the information contained herein are provided on an 727 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 728 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 729 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 730 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 731 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 732 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 734 12. Copyright Statement 736 Copyright (C) The Internet Society (2004). This document is subject 737 to the rights, licenses and restrictions contained in BCP 78, and 738 except as set forth therein, the authors retain all their rights.