idnits 2.17.1 draft-ietf-ipv6-unique-local-addr-06.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. 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 537, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3513 (ref. 'ADDARCH') (Obsoleted by RFC 4291) ** 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: 18 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 September 24, 2004 B. Haberman, JHU-APL 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 March 29, 2005. 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......................................................9 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..................................10 59 12.0 Security Considerations.......................................11 60 13.0 IANA Considerations...........................................11 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 or longer IPv6 local unicast 311 routes have 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 or longer routes created for one or more Local IPv6 318 prefixes. 320 5.0 Renumbering and Site Merging 322 The use of Local IPv6 addresses in a site results in making 323 communication using these addresses independent of renumbering a 324 site's provider based global addresses. 326 When merging multiple sites the addresses created with these prefixes 327 are unlikely to need to be renumbered because all of the addresses 328 have a high probability of being unique. Routes for each specific 329 prefix would have to be configured to allow routing to work correctly 330 between the formerly separate sites. 332 6.0 Site Border Router and Firewall Packet Filtering 334 While no serious harm will be done if packets with these addresses 335 are sent outside of a site via a default route, it is recommended 336 that routers be configured by default to keep any packets with Local 337 IPv6 destination addresses from leaking outside of the site and to 338 keep any site prefixes from being advertised outside of their site. 340 Site border routers should install a "reject" route for the Local 341 IPv6 prefix FC00::/7. This will ensure that packets with Local IPv6 342 destination addresses will not be forwarded outside of the site via a 343 default route. Site border routers should respond with the 344 appropriate ICMPv6 Destination Unreachable message to inform the 345 source that the packet was not forwarded [ICMPV6]. This feedback is 346 important to avoid transport protocol timeouts. 348 Site border routers and firewalls should not forward any packets with 349 Local IPv6 source or destination addresses outside of the site unless 350 they have been explicitly configured with routing information about 351 specific /48 or longer Local IPv6 prefixes. The default behavior of 352 these devices should be to install a "reject" route for these 353 prefixes. Site border routers should respond with the appropriate 354 ICMPv6 Destination Unreachable message to inform the source that the 355 packet was not forwarded. 357 Routers that maintain peering arrangements between Autonomous Systems 358 throughout the Internet should obey the recommendations for site 359 border routers unless configured otherwise. 361 7.0 DNS Issues 363 AAAA and PTR records for locally assigned local IPv6 addresses are 364 not recommended to be installed in the global DNS. 366 8.0 Application and Higher Level Protocol Issues 368 Application and other higher level protocols can treat Local IPv6 369 addresses in the same manner as other types of global unicast 370 addresses. No special handling is required. This type of addresses 371 may not be reachable, but that is no different from other types of 372 IPv6 global unicast addresses. Applications need to be able to 373 handle multiple addresses that may or may not be reachable any point 374 in time. In most cases this complexity should be hidden in APIs. 376 From a host's perspective this difference shows up as different 377 reachability than global unicast and could be handled by default that 378 way. In some cases it is better for nodes and applications to treat 379 them differently from global unicast addresses. A starting point 380 might be to give them preference over global unicast, but fall back 381 to global unicast if a particular destination is found to be 382 unreachable. Much of this behavior can be controlled by how they are 383 allocated to nodes and put into the DNS. However it is useful if a 384 host can have both types of addresses and use them appropriately. 386 Note that the address selection mechanisms of [ADDSEL], and in 387 particular the policy override mechanism replacing default address 388 selection, are expected to be used on a site where Local IPv6 389 addresses are configured. 391 9.0 Use of Local IPv6 Addresses for Local Communications 393 Local IPv6 addresses, like global scope unicast addresses, are only 394 assigned to nodes if their use has been enabled (via IPv6 address 395 autoconfiguration [ADDAUTO], DHCPv6 [DHCP6], or manually). They are 396 not created automatically the way that IPv6 link-local addresses are 397 and will not appear or be used unless they are purposely configured. 399 In order for hosts to autoconfigure Local IPv6 addresses, routers 400 have to be configured to advertise Local IPv6 /64 prefixes in router 401 advertisements, or a DHCPv6 server must have been configured to 402 assign them. In order for a node to learn the Local IPv6 address of 403 another node, the Local IPv6 address must have been installed in the 404 DNS or another naming system. For these reasons, it is straight 405 forward to control their usage in a site. 407 To limit the use of Local IPv6 addresses the following guidelines 408 apply: 410 - Nodes that are to only be reachable inside of a site: The local 411 DNS should be configured to only include the Local IPv6 412 addresses of these nodes. Nodes with only Local IPv6 addresses 413 must not be installed in the global DNS. 415 - Nodes that are to be limited to only communicate with other 416 nodes in the site: These nodes should be set to only 417 autoconfigure Local IPv6 addresses via [ADDAUTO] or to only 418 receive Local IPv6 addresses via [DHCP6]. Note: For the case 419 where both global and Local IPv6 prefixes are being advertised 420 on a subnet, this will require a switch in the devices to only 421 autoconfigure Local IPv6 addresses. 423 - Nodes that are to be reachable from inside of the site and from 424 outside of the site: The DNS should be configured to include 425 the global addresses of these nodes. The local DNS may be 426 configured to also include the Local IPv6 addresses of these 427 nodes. 429 - Nodes that can communicate with other nodes inside of the site 430 and outside of the site: These nodes should autoconfigure global 431 addresses via [ADDAUTO] or receive global address via [DHCP6]. 432 They may also obtain Local IPv6 addresses via the same 433 mechanisms. 435 10.0 Use of Local IPv6 Addresses with VPNs 437 Local IPv6 addresses can be used for inter-site Virtual Private 438 Networks (VPN) if appropriate routes are set up. Because the 439 addresses are unique these VPNs will work reliably and without the 440 need for translation. They have the additional property that they 441 will continue to work if the individual sites are renumbered or 442 merged. 444 11.0 Advantages and Disadvantages 446 11.1 Advantages 448 This approach has the following advantages: 450 - Provides Local IPv6 prefixes that can be used independently of 451 any provider based IPv6 unicast address allocations. This is 452 useful for sites not always connected to the Internet or sites 453 that wish to have a distinct prefix that can be used to localize 454 traffic inside of the site. 455 - Applications can treat these addresses in an identical manner as 456 any other type of global IPv6 unicast addresses. 457 - Sites can be merged without any renumbering of the Local IPv6 458 addresses. 459 - Sites can change their provider based IPv6 unicast address 460 without disrupting any communication using Local IPv6 addresses. 461 - Well known prefix that allows for easy filtering at site 462 boundary. 463 - Can be used for inter-site VPNs. 464 - If accidently leaked outside of a site via routing or DNS, there 465 is no conflict with any other addresses. 467 11.2 Disadvantages 469 This approach has the following disadvantages: 471 - Not possible to route Local IPv6 prefixes on the global Internet 472 with current routing technology. Consequentially, it is 473 necessary to have the default behavior of site border routers to 474 filter these addresses. 475 - There is a very low probability of non-unique locally assigned 476 global IDs being generated by the algorithm in section 3.2.3. 477 This risk can be ignored for all practical purposes, but it 478 leads to a theoretical risk of clashing address prefixes. 480 12.0 Security Considerations 482 Local IPv6 addresses do not provide any inherent security to the 483 nodes that use them. They may be used with filters at site 484 boundaries to keep Local IPv6 traffic inside of the site, but this is 485 no more or less secure than filtering any other type of global IPv6 486 unicast addresses. 488 Local IPv6 addresses do allow for address-based security mechanisms, 489 including IPSEC, across end to end VPN connections. 491 13.0 IANA Considerations 493 The IANA is instructed to assign the FC00::/7 prefix for Unique Local 494 IPv6 unicast addresses. 496 The prefix is divided in half for the following purposes: 498 FC00::/8 Centrally assigned 499 FD00::/8 Locally assigned 501 The IANA is instructed to reserve the prefix FC00::/8 for Centrally 502 assigned Unique Local IPv6 unicast addresses. 504 The FD00::/8 prefix is defined in this specification for Locally 505 assigned Unique Local IPv6 unicast addresses. 507 14.0 References 509 14.1 Normative References 511 [ADDARCH] Hinden, R., S. Deering, S., "IP Version 6 Addressing 512 Architecture", RFC 3513, April 2003. 514 [GLOBAL] Hinden, R., S. Deering, E. Nordmark, "IPv6 Global Unicast 515 Address Format", RFC 3587, August 2003. 517 [ICMPV6] Conta, A., S. Deering, "Internet Control Message Protocol 518 (ICMPv6) for the Internet Protocol Version 6 (IPv6) 519 Specification", RFC2463, December 1998. 521 [IPV6] Deering, S., R. Hinden, "Internet Protocol, Version 6 522 (IPv6) Specification", RFC 2460, December 1998. 524 [MD5DIG] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 525 April 1992. 527 [NTP] Mills, David L., "Network Time Protocol (Version 3) 528 Specification, Implementation and Analysis", RFC 1305, 529 March 1992. 531 [POPUL] Population Reference Bureau, "World Population Data Sheet 532 of the Population Reference Bureau 2002", August 2002. 534 [RANDOM] Eastlake, D. 3rd, S. Crocker, J. Schiller, "Randomness 535 Recommendations for Security", RFC 1750, December 1994. 537 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 538 Requirement Levels", RFC 2119, BCP14, March 1997. 540 14.2 Informative References 542 [ADDAUTO] Thomson, S., T. Narten, "IPv6 Stateless Address 543 Autoconfiguration", RFC 2462, December 1998. 545 [ADDSEL] Draves, R., "Default Address Selection for Internet 546 Protocol version 6 (IPv6)", RFC 3484, February 2003. 548 [DHCP6] Droms, R., et. al., "Dynamic Host Configuration Protocol 549 for IPv6 (DHCPv6)", RFC3315, July 2003. 551 [RTP] Schulzrinne, H., S. Casner, R. Frederick, V. Jacobson, 552 "RTP: A Transport Protocol for Real-Time Applications" 553 RFC3550, July 2003. 555 15.0 Authors' Addresses 557 Robert M. Hinden 558 Nokia 559 313 Fairchild Drive 560 Mountain View, CA 94043 561 USA 563 phone: +1 650 625-2004 564 email: bob.hinden@nokia.com 566 Brian Haberman 567 Johns Hopkins University 568 Applied Physics Lab 569 11100 Johns Hopkins Road 570 Laurel, MD 20723 571 USA 573 phone: +1 443 778 1319 574 email: brian@innovationslab.net 576 16.0 Change Log 578 Draft 579 o Clarify text to permit prefixes longer than /48 to be 580 configured. 581 o Changed text in section 7.0 to recommend that locally assigned 582 ULA addresses are not installed in the global DNS and removed 583 text about consequences of if they were installed in the global 584 DNS. 585 o Clarify the text in section 5.1 to state that there is a high 586 probability that there will be no address conflict when 587 renumbering. 588 o Several minor editorial changes. 590 Draft 591 o Removed the definition and technical requirements for centrally 592 assigned local address. The Centrally assigned local addresses 593 will be defined in a separate document. This document defines 594 the specific prefixes to be used for centrally and locally 595 assigned IPv6 local addresses, but only the locally assigned 596 local addresses are defined here. 598 Draft 600 o Clarified text in section 3.2.1 that central assigned prefixes 601 should be assigned under the authority of a single allocation 602 organization. 603 o Added step to suggested pseudo-random algorithm that in the case 604 of centrally assigned prefixes the computed global IDs should be 605 verified against the escrow. 606 o Added new text to section 3.2.2 that explains in more detail the 607 need for pseudo-random global IDs (i.e., avoid duplicate 608 allocations). 609 o Rewrote section 7.0 to describe DNS AAAA and PTR records, and 610 clarify when they might be installed in the global DNS. 611 o Various editorial changes. 613 Draft 615 o Removed requirement of a fee per central allocation and updated 616 IANA considerations to reflect this. Rewrote text to focus on 617 the requirement to avoid hoarding of allocations. 618 o Changed "filtering" and "black hole routes" to "reject" routes. 619 o Changed uppers case requirements (i.e., MUST, SHOULD, etc.) to 620 lower case in sections giving operational advice. 621 o Removed paragraph mentioning "Multicast DNS". 622 o Various editorial changes. 624 Draft 626 o Removed mention of 10 euro charge and changed text in section 627 3.2.1 and IANA considerations to restate the requirement for low 628 cost allocations and added specific requirement to prevent 629 hording. 630 o Added need to send ICMPv6 destination unreachable messages if 631 packets are filtered or dropped at site boundaries. 632 o Changed format section to list prefix sizes and definition, and 633 changed discussion of prefix sizes to new background section. 634 o Various editorial changes. 636 Draft 638 o Removed example of PIR as an example of an allocation authority 639 and clarified the text that the IANA should delegate the 640 centrally assigned prefix to an allocation authority. 641 o Changed sample code for generating pseudo random Global IDs to 642 not require any human input. Changes from using birthday to 643 unique token (e.g., EUI-64, serial number, etc.) available on 644 machine running the algorithm. 645 o Added a new section analyzing the uniqueness properties of the 646 pseudo random number algorithm. 647 o Added text to recommend that centrally assigned local addresses 648 be used for site planning extensive inter-site communication. 649 o Clarified that domain border routers should follow site border 650 router recommendations. 651 o Clarified that AAAA DNS records should not be installed in the 652 global DNS. 653 o Several editorial changes. 655 Draft 657 o Changed file name to become an IPv6 w.g. group document. 658 o Clarified language in Routing and Firewall sections. 659 o Several editorial changes. 661 Draft 663 o Changed title and name of addresses defined in this document to 664 "Unique Local IPv6 Unicast Addresses" with abbreviation of 665 "Local IPv6 addresses". 666 o Several editorial changes. 668 Draft 670 o Added section on scope definition and updated application 671 requirement section. 673 o Clarified that, by default, the scope of these addresses is 674 global. 675 o Renumbered sections and general text improvements 676 o Removed reserved global ID values 677 o Added pseudo code for local allocation submitted by Brian 678 Haberman and added him as an author. 679 o Split Global ID values into centrally assigned and local 680 assignments and added text to describe local assignments 682 Draft 684 o Initial Draft