idnits 2.17.1 draft-ietf-ipv6-unique-local-addr-05.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 3667, Section 5.1 on line 13. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3978 Section 5.4 (updated by RFC 4748) Copyright Line. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer. ** 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: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 101, but not defined == Unused Reference: 'RFC2119' is defined on line 543, but no explicit reference was found in the text ** 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) ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. 'MD5DIG') ** Obsolete normative reference: RFC 1305 (ref. 'NTP') (Obsoleted by RFC 5905) -- Possible downref: Non-RFC (?) normative reference: ref. 'POPUL' ** Obsolete normative reference: RFC 1750 (ref. 'RANDOM') (Obsoleted by RFC 4086) -- 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 (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT R. Hinden, Nokia 2 June 23, 2004 B. Haberman, Caspian 4 Unique Local IPv6 Unicast Addresses 6 8 Status of this Memo 10 By submitting this Internet-Draft, we certify that any applicable 11 patent or other IPR claims of which I am aware have been disclosed, 12 and any of which I become aware will be disclosed, in accordance with 13 RFC 3668. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than a "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/1id-abstracts.html 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html 31 This internet draft expires on November 28, 2004. 33 Abstract 35 This document defines an IPv6 unicast address format that is globally 36 unique and is intended for local communications, usually inside of a 37 site. They are not expected to be routable on the global Internet. 39 Table of Contents 41 1.0 Introduction....................................................2 42 2.0 Acknowledgments.................................................3 43 3.0 Local IPv6 Unicast Addresses....................................3 44 3.1 Format..........................................................3 45 3.1.1 Background....................................................4 46 3.2 Global ID.......................................................4 47 3.2.1 Locally Assigned Global IDs...................................5 48 3.2.2 Sample Code for Pseudo-Random Global ID Algorithm.............6 49 3.2.3 Analysis of the Uniqueness of Global IDs......................6 50 3.3 Scope Definition................................................7 51 4.0 Routing.........................................................7 52 5.0 Renumbering and Site Merging....................................8 53 6.0 Site Border Router and Firewall Packet Filtering................8 54 7.0 DNS Issues......................................................8 55 8.0 Application and Higher Level Protocol Issues....................9 56 9.0 Use of Local IPv6 Addresses for Local Communications............9 57 10.0 Use of Local IPv6 Addresses with VPNs.........................10 58 11.0 Advantages and Disadvantages..................................11 59 12.0 Security Considerations.......................................11 60 13.0 IANA Considerations...........................................12 61 14.0 References....................................................12 62 14.1 Normative References..........................................12 63 14.2 Informative References........................................13 64 15.0 Authors' Addresses............................................13 65 16.0 Change Log....................................................14 67 1.0 Introduction 69 This document defines an IPv6 unicast address format that is globally 70 unique and is intended for local communications [IPV6]. These 71 addresses are called Unique Local IPv6 Unicast Addresses and are 72 abbreviated in this document as Local IPv6 addresses. They are not 73 expected to be routable on the global Internet. They are routable 74 inside of a more limited area such as a site. They may also be 75 routed between a limited set of sites. 77 Local IPv6 unicast addresses have the following characteristics: 79 - Globally unique prefix. 80 - Well known prefix to allow for easy filtering at site 81 boundaries. 82 - Allows sites to be combined or privately interconnected without 83 creating any address conflicts or requiring renumbering of 84 interfaces using these prefixes. 85 - Internet Service Provider independent and can be used for 86 communications inside of a site without having any permanent or 87 intermittent Internet connectivity. 88 - If accidentally leaked outside of a site via routing or DNS, 89 there is no conflict with any other addresses. 90 - In practice, applications may treat these addresses like global 91 scoped addresses. 93 This document defines the format of Local IPv6 addresses, how to 94 allocate them, and usage considerations including routing, site 95 border routers, DNS, application support, VPN usage, and guidelines 96 for how to use for local communication inside a site. 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in [RFC 2119]. 102 2.0 Acknowledgments 104 The underlying idea of creating Local IPv6 addresses described in 105 this document been proposed a number of times by a variety of people. 106 The authors of this draft do not claim exclusive credit. Credit goes 107 to Brian Carpenter, Christian Huitema, Aidan Williams, Andrew White, 108 Charlie Perkins, and many others. The authors would also like to 109 thank Brian Carpenter, Charlie Perkins, Harald Alvestrand, Keith 110 Moore, Margaret Wasserman, Shannon Behrens, Alan Beard, Hans Kruse, 111 Geoff Huston, Pekka Savola, Christian Huitema, and Tim Chown for 112 their comments and suggestions on this document. 114 3.0 Local IPv6 Unicast Addresses 116 3.1 Format 118 The Local IPv6 addresses are created using a pseudo-randomly 119 allocated global ID. They have the following format: 121 | 7 bits | 41 bits | 16 bits | 64 bits | 122 +--------+------------+-----------+-----------------------------+ 123 | prefix | global ID | subnet ID | interface ID | 124 +--------+------------+-----------+-----------------------------+ 126 Where: 128 prefix FC00::/7 prefix to identify Local IPv6 unicast 129 addresses. 131 global ID 41-bit global identifier used to create a 132 globally unique prefix. See section 3.2 for 133 additional information. 135 subnet ID 16-bit subnet ID is an identifier of a subnet 136 within the site. 138 interface ID 64-bit interface ID as defined in [ADDARCH]. 140 3.1.1 Background 142 There were a range of choices available when choosing the size of the 143 prefix and global ID field length. There is a direct tradeoff 144 between having a global ID field large enough to support foreseeable 145 future growth and not using too much of the IPv6 address space 146 needlessly. A reasonable way of evaluating a specific field length 147 is to compare it to a projected 2050 world population of 9.3 billion 148 [POPUL] and the number of resulting /48 prefixes per person. A range 149 of prefix choices is shown in the following table: 151 Prefix Global ID Number of Prefixes % of IPv6 152 Length /48 Prefixes per Person Address Space 154 /11 37 137,438,953,472 15 0.049% 155 /10 38 274,877,906,944 30 0.098% 156 /9 39 549,755,813,888 59 0.195% 157 /8 40 1,099,511,627,776 118 0.391% 158 /7 41 2,199,023,255,552 236 0.781% 159 /6 42 4,398,046,511,104 473 1.563% 161 A very high utilization ratio of these allocations can be assumed 162 because the global ID field does not require internal structure, and 163 there is no reason to be able to aggregate the prefixes. 165 The authors believe that a /7 prefix resulting in a 41 bit global ID 166 is a good choice. It provides for a large number of assignments 167 (i.e., 2.2 trillion) and at the same time uses less than .8% of the 168 total IPv6 address space. It is unlikely that this space will be 169 exhausted. If more than this were to be needed, then additional IPv6 170 address space could be allocated for this purpose. 172 3.2 Global ID 174 The allocation of global IDs should be pseudo-random [RANDOM]. They 175 should not be assigned sequentially or with well known numbers. This 176 is to ensure that there is not any relationship between allocations 177 and to help clarify that these prefixes are not intended to be routed 178 globally. Specifically, these prefixes are designed to not 179 aggregate. 181 There are two ways to allocate Global IDs. These are centrally by a 182 allocation authority and locally by the site. The Global ID is split 183 into two parts for each type of allocation. The prefixes for each 184 type are: 186 FC00::/8 Centrally assigned 187 FD00::/8 Locally assigned 189 Each results in a 40-bit space to allocate. 191 Two assignment methods are included because they have different 192 properties. The centrally assigned global IDs are uniquely assigned. 193 The local assignments are self generated and do not need any central 194 coordination or assignment, but have a lower (but still adequate) 195 probability of being unique. It is expected that large managed sites 196 will prefer central assignments and small or disconnected sites will 197 prefer local assignments. It is recommended that sites planning to 198 use Local IPv6 addresses for extensive inter-site communication, 199 initially or as a future possibility, use a centrally assigned prefix 200 as there is no possibility of assignment conflicts. Sites are free 201 to choose either approach. 203 This document only allocates the prefix (FC00::/8) for centrally 204 assigned local IPv6 addresses. The characteristics and technical 205 allocation requirements for centrally assigned Local IPv6 addresses 206 will be defined in a separate document. 208 3.2.1 Locally Assigned Global IDs 210 Global IDs can be generated locally by an individual site. This 211 makes it easy to get a prefix without the need to contact an 212 assignment authority or internet service provider. There is not as 213 high a degree of assurance that the prefix will not conflict with 214 another locally generated prefix, but the likelihood of conflict is 215 small. Sites that are not comfortable with this degree of 216 uncertainty should use a centrally assigned global ID. 218 Locally assigned global IDs MUST be generated with a pseudo-random 219 algorithm consistent with [RANDOM]. Section 3.2.2 describes a 220 suggested algorithm. It is important to ensure a reasonable 221 likelihood uniqueness that all sites generating a Global IDs use a 222 functionally similar algorithm. 224 The use of a pseudo-random algorithm to generate global IDs in the 225 locally assigned prefix gives an assurance that any network numbered 226 using such a prefix is highly unlikely to have that address space 227 clash with any other network that has another locally assigned prefix 228 allocated to it. This is a particularly useful property when 229 considering a number of scenarios including networks that merge, 230 overlapping VPN address space, or hosts mobile between such networks. 232 3.2.2 Sample Code for Pseudo-Random Global ID Algorithm 234 The algorithm described below is intended to be used for locally 235 assigned Global IDs. In each case the resulting global ID will be 236 used in the appropriate prefix as defined in section 3.2. 238 1) Obtain the current time of day in 64-bit NTP format [NTP]. 239 2) Obtain an EUI-64 identifier from the system running this 240 algorithm. If an EUI-64 does not exist, one can be created from 241 a 48-bit MAC address as specified in [ADDARCH]. If an EUI-64 242 cannot be obtained or created, a suitably unique identifier, 243 local to the node, should be used (e.g. system serial number). 244 3) Concatenate the time of day with the system-specific identifier 245 creating a key. 246 4) Compute an MD5 digest on the key as specified in [MD5DIG]. 247 5) Use the least significant 40 bits as the Global ID. 249 This algorithm will result in a global ID that is reasonably unique 250 and can be used as a Global ID. 252 3.2.3 Analysis of the Uniqueness of Global IDs 254 The selection of a pseudo random global ID is similar to the 255 selection of an SSRC identifier in RTP/RTCP defined in section 8.1 of 256 [RTP]. This analysis is adapted from that document. 258 Since the global ID is chosen randomly, it is possible that two or 259 more networks that have an inter-network connection using globally- 260 unique local addresses will chose the same global ID. The 261 probability of collision can be approximated based on the number of 262 connections between networks using globally-unique local addresses 263 and the length of the ID (40 bits). The formula 265 P = 1 - exp(-N**2 / 2**(L+1)) 267 approximates the probability of collision (where N is the number 268 connections and L is the length of the global ID). 270 The following table shows the probability of a collision for a range 271 of connections using a 40 bit global ID field. 273 Connections Probability of Collision 275 2 1.81*10^-12 276 10 4.54*10^-11 277 100 4.54*10^-09 278 1000 4.54*10^-07 279 10000 4.54*10^-05 281 Based on this analysis the uniqueness of locally generated global IDs 282 is adequate for sites planning a small to moderate amount of inter- 283 site communication using locally generated global IDs. Sites 284 planning more extensive inter-site communication should consider 285 using the centrally assigned global ID. 287 3.3 Scope Definition 289 By default, the scope of these addresses is global. That is, they 290 are not limited by ambiguity like the site-local addresses defined in 291 [ADDARCH]. Rather, these prefixes are globally unique, and as such, 292 their applicability is greater than site-local addresses. Their 293 limitation is in the routability of the prefixes, which is limited to 294 a site and any explicit routing agreements with other sites to 295 propagate them. Also, unlike site-locals, a site may have more than 296 one of these prefixes and use them at the same time. 298 4.0 Routing 300 Local IPv6 addresses are designed to be routed inside of a site in 301 the same manner as other types of unicast addresses. They can be 302 carried in any IPv6 routing protocol without any change. 304 It is expected that they would share the same subnet IDs with 305 provider based global unicast addresses if they were being used 306 concurrently [GLOBAL]. 308 Any router that is used between sites must be configured to filter 309 out any incoming or outgoing Local IPv6 unicast routes. The 310 exception to this is if specific /48 IPv6 local unicast routes have 311 been configured to allow for inter-site communication. 313 If BGP is being used at the site border with an ISP, the default BGP 314 configuration must be set to to keep any Local IPv6 address prefixes 315 from being advertised outside of the site or for these prefixes to be 316 learned from another site. The exception to this is if there are 317 specific /48 routes created for one or more Local IPv6 prefixes. 319 5.0 Renumbering and Site Merging 321 The use of Local IPv6 addresses in a site results in making 322 communication using these addresses independent of renumbering a 323 site's provider based global addresses. 325 When merging multiple sites none of the addresses created with these 326 prefixes need to be renumbered because all of the addresses are 327 unique. Routes for each specific prefix would have to be configured 328 to allow routing to work correctly between the formerly separate 329 sites. 331 6.0 Site Border Router and Firewall Packet Filtering 333 While no serious harm will be done if packets with these addresses 334 are sent outside of a site via a default route, it is recommended 335 that routers be configured by default to keep any packets with Local 336 IPv6 destination addresses from leaking outside of the site and to 337 keep any site prefixes from being advertised outside of their site. 339 Site border routers should install a "reject" route for the Local 340 IPv6 prefix FC00::/7. This will ensure that packets with Local IPv6 341 destination addresses will not be forwarded outside of the site via a 342 default route. Site border routers should respond with the 343 appropriate ICMPv6 Destination Unreachable message to inform the 344 source that the packet was not forwarded [ICMPV6]. This feedback is 345 important to avoid transport protocol timeouts. 347 Site border routers and firewalls should not forward any packets with 348 Local IPv6 source or destination addresses outside of the site unless 349 they have been explicitly configured with routing information about 350 specific /48 Local IPv6 prefixes. The default behavior of these 351 devices should be to install a "reject" route for these prefixes. 352 Site border routers should respond with the appropriate ICMPv6 353 Destination Unreachable message to inform the source that the packet 354 was not forwarded. 356 Routers that maintain peering arrangements between Autonomous Systems 357 throughout the Internet should obey the recommendations for site 358 border routers unless configured otherwise. 360 7.0 DNS Issues 362 AAAA and PTR records for Local IPv6 addresses may be installed in the 363 global DNS at the option of the site to which they are assigned. It 364 is expected that most sites will not make use of this option, but 365 some sites may find benefits in doing so. 367 If Local IPv6 address are configured in the global DNS, no harm is 368 done because they are unique and will not create any confusion. They 369 may not be reachable, but this is a property that is common to all 370 types of global IPv6 unicast addresses. 372 8.0 Application and Higher Level Protocol Issues 374 Application and other higher level protocols can treat Local IPv6 375 addresses in the same manner as other types of global unicast 376 addresses. No special handling is required. This type of addresses 377 may not be reachable, but that is no different from other types of 378 IPv6 global unicast addresses. Applications need to be able to 379 handle multiple addresses that may or may not be reachable any point 380 in time. In most cases this complexity should be hidden in APIs. 382 From a host's perspective this difference shows up as different 383 reachability than global unicast and could be handled by default that 384 way. In some cases it is better for nodes and applications to treat 385 them differently from global unicast addresses. A starting point 386 might be to give them preference over global unicast, but fall back 387 to global unicast if a particular destination is found to be 388 unreachable. Much of this behavior can be controlled by how they are 389 allocated to nodes and put into the DNS. However it is useful if a 390 host can have both types of addresses and use them appropriately. 392 Note that the address selection mechanisms of [ADDSEL], and in 393 particular the policy override mechanism replacing default address 394 selection, are expected to be used on a site where Local IPv6 395 addresses are configured. 397 9.0 Use of Local IPv6 Addresses for Local Communications 399 Local IPv6 addresses, like global scope unicast addresses, are only 400 assigned to nodes if their use has been enabled (via IPv6 address 401 autoconfiguration [ADDAUTO], DHCPv6 [DHCP6], or manually). They are 402 not created automatically the way that IPv6 link-local addresses are 403 and will not appear or be used unless they are purposely configured. 405 In order for hosts to autoconfigure Local IPv6 addresses, routers 406 have to be configured to advertise Local IPv6 /64 prefixes in router 407 advertisements, or a DHCPv6 server must have been configured to 408 assign them. In order for a node to learn the Local IPv6 address of 409 another node, the Local IPv6 address must have been installed in the 410 DNS or another naming system. For these reasons, it is straight 411 forward to control their usage in a site. 413 To limit the use of Local IPv6 addresses the following guidelines 414 apply: 416 - Nodes that are to only be reachable inside of a site: The local 417 DNS should be configured to only include the Local IPv6 418 addresses of these nodes. Nodes with only Local IPv6 addresses 419 must not be installed in the global DNS. 421 - Nodes that are to be limited to only communicate with other 422 nodes in the site: These nodes should be set to only 423 autoconfigure Local IPv6 addresses via [ADDAUTO] or to only 424 receive Local IPv6 addresses via [DHCP6]. Note: For the case 425 where both global and Local IPv6 prefixes are being advertised 426 on a subnet, this will require a switch in the devices to only 427 autoconfigure Local IPv6 addresses. 429 - Nodes that are to be reachable from inside of the site and from 430 outside of the site: The DNS should be configured to include 431 the global addresses of these nodes. The local DNS may be 432 configured to also include the Local IPv6 addresses of these 433 nodes. 435 - Nodes that can communicate with other nodes inside of the site 436 and outside of the site: These nodes should autoconfigure global 437 addresses via [ADDAUTO] or receive global address via [DHCP6]. 438 They may also obtain Local IPv6 addresses via the same 439 mechanisms. 441 10.0 Use of Local IPv6 Addresses with VPNs 443 Local IPv6 addresses can be used for inter-site Virtual Private 444 Networks (VPN) if appropriate routes are set up. Because the 445 addresses are unique these VPNs will work reliably and without the 446 need for translation. They have the additional property that they 447 will continue to work if the individual sites are renumbered or 448 merged. 450 11.0 Advantages and Disadvantages 452 11.1 Advantages 454 This approach has the following advantages: 456 - Provides Local IPv6 prefixes that can be used independently of 457 any provider based IPv6 unicast address allocations. This is 458 useful for sites not always connected to the Internet or sites 459 that wish to have a distinct prefix that can be used to localize 460 traffic inside of the site. 461 - Applications can treat these addresses in an identical manner as 462 any other type of global IPv6 unicast addresses. 463 - Sites can be merged without any renumbering of the Local IPv6 464 addresses. 465 - Sites can change their provider based IPv6 unicast address 466 without disrupting any communication using Local IPv6 addresses. 467 - Well known prefix that allows for easy filtering at site 468 boundary. 469 - Can be used for inter-site VPNs. 470 - If accidently leaked outside of a site via routing or DNS, there 471 is no conflict with any other addresses. 473 11.2 Disadvantages 475 This approach has the following disadvantages: 477 - Not possible to route Local IPv6 prefixes on the global Internet 478 with current routing technology. Consequentially, it is 479 necessary to have the default behavior of site border routers to 480 filter these addresses. 481 - There is a very low probability of non-unique locally assigned 482 global IDs being generated by the algorithm in section 3.2.3. 483 This risk can be ignored for all practical purposes, but it 484 leads to a theoretical risk of clashing address prefixes. 486 12.0 Security Considerations 488 Local IPv6 addresses do not provide any inherent security to the 489 nodes that use them. They may be used with filters at site 490 boundaries to keep Local IPv6 traffic inside of the site, but this is 491 no more or less secure than filtering any other type of global IPv6 492 unicast addresses. 494 Local IPv6 addresses do allow for address-based security mechanisms, 495 including IPSEC, across end to end VPN connections. 497 13.0 IANA Considerations 499 The IANA is instructed to assign the FC00::/7 prefix for Unique Local 500 IPv6 unicast addresses. 502 The prefix is divided in half for the following purposes: 504 FC00::/8 Centrally assigned 505 FD00::/8 Locally assigned 507 The IANA is instructed to reserve the prefix FC00::/8 for Centrally 508 assigned Unique Local IPv6 unicast addresses. 510 The FD00::/8 prefix is defined in this specification for Locally 511 assigned Unique Local IPv6 unicast addresses. 513 14.0 References 515 14.1 Normative References 517 [ADDARCH] Hinden, R., S. Deering, S., "IP Version 6 Addressing 518 Architecture", RFC 3515, April 2003. 520 [GLOBAL] Hinden, R., S. Deering, E. Nordmark, "IPv6 Global Unicast 521 Address Format", RFC 3587, August 2003. 523 [ICMPV6] Conta, A., S. Deering, "Internet Control Message Protocol 524 (ICMPv6) for the Internet Protocol Version 6 (IPv6) 525 Specification", RFC2463, December 1998. 527 [IPV6] Deering, S., R. Hinden, "Internet Protocol, Version 6 528 (IPv6) Specification", RFC 2460, December 1998. 530 [MD5DIG] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 531 April 1992. 533 [NTP] Mills, David L., "Network Time Protocol (Version 3) 534 Specification, Implementation and Analysis", RFC 1305, 535 March 1992. 537 [POPUL] Population Reference Bureau, "World Population Data Sheet 538 of the Population Reference Bureau 2002", August 2002. 540 [RANDOM] Eastlake, D. 3rd, S. Crocker, J. Schiller, "Randomness 541 Recommendations for Security", RFC 1750, December 1994. 543 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 544 Requirement Levels", RFC 2119, BCP14, March 1997. 546 14.2 Informative References 548 [ADDAUTO] Thomson, S., T. Narten, "IPv6 Stateless Address 549 Autoconfiguration", RFC 2462, December 1998. 551 [ADDSEL] Draves, R., "Default Address Selection for Internet 552 Protocol version 6 (IPv6)", RFC 3484, February 2003. 554 [DHCP6] Droms, R., et. al., "Dynamic Host Configuration Protocol 555 for IPv6 (DHCPv6)", RFC3315, July 2003. 557 [RTP] Schulzrinne, H., S. Casner, R. Frederick, V. Jacobson, 558 "RTP: A Transport Protocol for Real-Time Applications" 559 RFC3550, July 2003. 561 15.0 Authors' Addresses 563 Robert M. Hinden 564 Nokia 565 313 Fairchild Drive 566 Mountain View, CA 94043 567 USA 569 phone: +1 650 625-2004 570 email: bob.hinden@nokia.com 572 Brian Haberman 573 Caspian Networks 574 1 Park Drive, Suite 300 575 Research Triangle Park, NC 27709 576 USA 578 phone: +1-929-949-4828 579 email: brian@innovationslab.net 581 16.0 Change Log 583 Draft 584 o Removed the definition and technical requirements for centrally 585 assigned local address. The Centrally assigned local addresses 586 will be defined in a separate document. This document defines 587 the specific prefixes to be used for centrally and locally 588 assigned IPv6 local addresses, but only the locally assigned 589 local addresses are defined here. 591 Draft 593 o Clarified text in section 3.2.1 that central assigned prefixes 594 should be assigned under the authority of a single allocation 595 organization. 596 o Added step to suggested pseudo-random algorithm that in the case 597 of centrally assigned prefixes the computed global IDs should be 598 verified against the escrow. 599 o Added new text to section 3.2.2 that explains in more detail the 600 need for pseudo-random global IDs (i.e., avoid duplicate 601 allocations). 602 o Rewrote section 7.0 to describe DNS AAAA and PTR records, and 603 clarify when they might be installed in the global DNS. 604 o Various editorial changes. 606 Draft 608 o Removed requirement of a fee per central allocation and updated 609 IANA considerations to reflect this. Rewrote text to focus on 610 the requirement to avoid hoarding of allocations. 611 o Changed "filtering" and "black hole routes" to "reject" routes. 612 o Changed uppers case requirements (i.e., MUST, SHOULD, etc.) to 613 lower case in sections giving operational advice. 614 o Removed paragraph mentioning "Multicast DNS". 615 o Various editorial changes. 617 Draft 619 o Removed mention of 10 euro charge and changed text in section 620 3.2.1 and IANA considerations to restate the requirement for low 621 cost allocations and added specific requirement to prevent 622 hording. 623 o Added need to send ICMPv6 destination unreachable messages if 624 packets are filtered or dropped at site boundaries. 625 o Changed format section to list prefix sizes and definition, and 626 changed discussion of prefix sizes to new background section. 627 o Various editorial changes. 629 Draft 631 o Removed example of PIR as an example of an allocation authority 632 and clarified the text that the IANA should delegate the 633 centrally assigned prefix to an allocation authority. 634 o Changed sample code for generating pseudo random Global IDs to 635 not require any human input. Changes from using birthday to 636 unique token (e.g., EUI-64, serial number, etc.) available on 637 machine running the algorithm. 638 o Added a new section analyzing the uniqueness properties of the 639 pseudo random number algorithm. 640 o Added text to recommend that centrally assigned local addresses 641 be used for site planning extensive inter-site communication. 642 o Clarified that domain border routers should follow site border 643 router recommendations. 644 o Clarified that AAAA DNS records should not be installed in the 645 global DNS. 646 o Several editorial changes. 648 Draft 650 o Changed file name to become an IPv6 w.g. group document. 651 o Clarified language in Routing and Firewall sections. 652 o Several editorial changes. 654 Draft 656 o Changed title and name of addresses defined in this document to 657 "Unique Local IPv6 Unicast Addresses" with abbreviation of 658 "Local IPv6 addresses". 659 o Several editorial changes. 661 Draft 663 o Added section on scope definition and updated application 664 requirement section. 665 o Clarified that, by default, the scope of these addresses is 666 global. 667 o Renumbered sections and general text improvements 668 o Removed reserved global ID values 669 o Added pseudo code for local allocation submitted by Brian 670 Haberman and added him as an author. 671 o Split Global ID values into centrally assigned and local 672 assignments and added text to describe local assignments 674 Draft 676 o Initial Draft