idnits 2.17.00 (12 Aug 2021) /tmp/idnits6283/draft-hinden-ipv6-global-local-addr-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** 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? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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 4 characters 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.) -- The document date (May 7, 2003) is 6954 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 2119' is mentioned on line 66, but not defined == Unused Reference: 'RFC2026' is defined on line 392, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 395, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'GLOBAL' ** Obsolete normative reference: RFC 2460 (ref. 'IPV6') (Obsoleted by RFC 8200) -- Possible downref: Non-RFC (?) normative reference: ref. 'POPUL' ** Obsolete normative reference: RFC 2462 (ref. 'ADDAUTO') (Obsoleted by RFC 4862) -- Possible downref: Non-RFC (?) normative reference: ref. 'DHCP6' Summary: 8 errors (**), 0 flaws (~~), 4 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT R. Hinden, Nokia 2 May 7, 2003 4 Globally Unique IPv6 Local Unicast Addresses 6 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet- Drafts as reference 19 material or to cite them other than as "work in progress." 21 To view the list Internet-Draft Shadow Directories, see 22 http://www.ietf.org/shadow.html. 24 This internet draft expires on November 7, 2003. 26 Abstract 28 This document defines an unicast address format that is globally 29 unique and is intended for local communications, usually inside of a 30 site. They are not expected to be routable on the global Internet 31 given current routing technology. 33 1.0 Introduction 35 This document defines an IPv6 unicast address format that is globally 36 unique and is intended for local communications [IPV6]. They are not 37 expected to be routable on the global Internet given current routing 38 technology. They are routable inside of a more limited area such as 39 a site. They may also be routed between a limited set of sites. 41 Globally unique IPv6 local addresses have the following 42 characteristics: 44 - Globally unique prefix. 45 - Well known prefix to allow for easy filtering at site 46 boundaries. 47 - Allows sites to be combined with out creating any address 48 conflicts or require renumbering of interfaces using these 49 prefixes. 50 - Internet Service Provider independent and can be used for 51 communications inside of a site without having any permanent or 52 intermittent Internet connectivity. 53 - If accidentally leaked outside of a site via routing or DNS, 54 there is no conflict with any other addresses. 55 - No requirement for applications to treat these address 56 differently from any other kind of global unicast addresses. 58 This document defines the format of Globally Unique IPv6 Local 59 addresses, how to allocate them, and usage considerations including 60 routing, site border routers, DNS, application support, VPN usage, 61 and guidelines for how to use for local communication inside a site. 63 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 64 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 65 document are to be interpreted as described in [RFC 2119]. 67 2.0 Acknowledgments 69 The underlying idea of creating globally unique IPv6 local addresses 70 describe in this document been proposed a number of times by a 71 variety of people. The author of this draft does not claim exclusive 72 credit. Credit goes to Brian Carpenter, Christian Huitema, Aidan 73 Williams, Andrew White, Michel Py, Charlie Perkins, and many others. 74 The author would also like to thank Brain Carpenter, Charlie Perkins, 75 Harald Alvestrand, Keith Moore, Margaret Wasserman, and Michel Py for 76 their comments and suggestions on this draft. 78 3.0 Globally Unique IPv6 Local Unicast Address Format 80 The globally unique IPv6 local addresses are created using a 81 centrally allocated global ID. They have the following format: 83 | n | 84 | bits | m bits | 16 bits | 64 bits | 85 +--------+------------+-----------+-----------------------------+ 86 | prefix | global ID | subnet ID | interface ID | 87 +--------+------------+-----------+-----------------------------+ 89 Where: 91 prefix prefix to identify Globally Unique IPv6 Local 92 unicast addresses. 94 global ID global identifier used to create a globally 95 unique prefix. See section 3.1 for additional 96 information. 98 subnet ID 16-bit subnet ID is an identifier of a subnet 99 within the site. 101 interface ID 64-bit IID as defined in [ADDARCH]. 103 There are a range of choices available when choosing the size of the 104 prefix and Global ID field length. There is a direct tradeoff 105 between having a Global ID field large enough to support foreseeable 106 future growth and not using too much of the IPv6 address space 107 needlessly. A reasonable way of evaluating a specific field length 108 is to compare it to a projected 2050 world population of 9.3 billion 109 [POPUL]. A range of prefix choices is shown in the following table: 111 Prefix Global ID Number Prefixes Prefixes % of IPv6 112 Length per Person Address Space 114 /11 37 137,438,953,472 15 0.049% 115 /10 38 274,877,906,944 30 0.098% 116 /9 39 549,755,813,888 59 0.195% 117 /8 40 1,099,511,627,776 118 0.391% 118 /7 41 2,199,023,255,552 236 0.781% 119 /6 42 4,398,046,511,104 473 1.563% 121 A very high utilization ratio of these allocations can be assumed 122 because no internal structure is required in the field nor is there 123 any reason to be able to aggregate the prefixes. 125 The author believes that a /7 prefix resulting in a 41 bit Global ID 126 is a good choice. It provides for a large number of assignments 127 (i.e., 2.2 trillion) and at the same time uses less than .8% of the 128 total IPv6 address space. It is unlikely that this space will be 129 exhausted. If more than this was needed, then additional IPv6 130 address space could be allocated for this purpose. 132 For the rest of this document the FC00::/7 prefix and a 41-bit Global 133 ID is used. 135 3.1 Global ID 137 The Global ID values of zero and all ones are reserved for future use 138 and must not be assigned. 140 The allocation of global IDs should be pseudo-random. They should 141 not be assigned sequentially or by locality. This to ensure that 142 there is not any relationship between allocations and to help clarify 143 that these prefixes are not intended to be routed globally. 144 Specifically, these prefixes are designed to not aggregate. 146 Global IDs should be assigned centrally by a single allocation 147 authority because they are pseudo-random and without any structure. 148 This is easiest to accomplish if there is a single source of the 149 assignments. 151 3.1.1 Global ID Allocation Requirements 153 Global ID allocations should be 155 - Available to anyone in an unbiased manner. 156 - Permanent with no periodic fees. 157 - One time non-refundable allocation fee in the order of 10 Euros 158 per allocation. 159 - The ownership of each individual allocation should be private, 160 but should be escrowed. 162 The allocation authority should permit allocations to be obtained 163 without having any sort of internet connectivity. For example in 164 addition to web based registration they should support some methods 165 like telephone, postal mail, fax, telex, etc. They should also 166 accept a variety of payment methods and currencies. 168 The reason for the one time 10 Euro charge for each prefix is to 169 provide a barrier to any hoarding of the these allocations but at the 170 same time keep the cost low enough to not create a barrier to anyone 171 needing one. The charge is non-refundable in order to keep overhead 172 low. 174 The ownership of the allocations is not needed to be public since the 175 resulting addresses are intended to be used for local communication. 176 It is escrowed to insure there are no duplicate allocations and in 177 case it is needed in the future. 179 An example of a allocation authority is a non-profit organization 180 such as the Public Internet Registry (PIR) that the Internet Society 181 has created to manage the .org domain. They already know how to 182 collect small sums efficiently and there are safeguards in place for 183 the appropriate use of any excess revenue generated. 185 Note, there are many possible ways of of creating an allocation 186 authority. It is important to keep in mind when reviewing 187 alternatives that the goal is to pick one that can do the job. It 188 doesn't have to be perfect, only good enough to do the job at hand. 189 The author believes that the PIR would satisfy this requirement. 191 3.3 Routing 193 Globally IPv6 Local address are designed to be routed inside of a 194 site in the same manner as other types of unicast addresses. They 195 can be carried in any IPv6 routing protocol without any change. 197 It is expected that they would share the same subnet IDs if provider 198 based global unicast addresses were being used concurrently [GLOBAL]. 200 Any routing protocol that is used between sites is required to filter 201 out any incoming or outgoing globally unique IPv6 local routes. The 202 exception to this is if specific /48 globally unique IPv6 local 203 routes have been configured to allow for inter-site communication. 205 If BGP is being used at the site border with an ISP, by default 206 filters MUST be installed in the BGP configuration to keep any site- 207 local prefixes from being advertised outside of the site or for site- 208 local prefixes to be learned from another site. The exception to 209 this is if there are specific /48 routes created for one or more 210 globally unique IPv6 local prefixes. 212 3.4 Renumbering and Site Merging 214 The use of globally unique IPv6 local addresses in a site results in 215 making communication using these addresses independent of renumbering 216 a site's provider based global addresses. 218 When merging multiple sites none of the addresses created with these 219 prefixes need to be renumbered because all of the addresses are 220 unique. Routes for each specific prefix would have to be configured 221 to allow routing to work correctly between the formerly separate 222 sites. 224 3.5 Site Border Router and Firewall Filtering 226 While no serious harm will be done if packets with these addresses 227 are sent outside of a site via a default route, it is recommended 228 that they be filtered to keep any packets with globally unique IPv6 229 local destination addresses from leaking outside of the site and to 230 keep any site prefixes from being advertised outside of their site. 232 Site border routers SHOULD install a black hole route for the 233 Globally Unique IPv6 Local prefix FC00::/7. This will insure that 234 packets with Globally Unique IPv6 Local destination addresses will 235 not be forwarded outside of the site via a default route. 237 Site border routers and firewalls SHOULD NOT forward any packets with 238 globally unique IPv6 local source or destination addresses outside of 239 the site unless they have been explicitly configured with routing 240 information about other globally unique IPv6 local prefixes. The 241 default behavior of these devices SHOULD be to filter them. 243 3.6 DNS Issues 245 Globally Unique IPv6 Local addresses SHOULD NOT be installed in the 246 global DNS. They may be installed in a naming system local to the 247 site or kept separate from the global DNS using techniques such as 248 "two-faced" DNS. 250 If globally unique IPv6 local address are configured in the global 251 DNS, no harm is done because they are unique and will not create any 252 confusion. The may not be reachable, but this is a property that is 253 common to all types of global IPv6 unicast addresses. 255 For future study names with globally unique IPv6 local addresses may 256 be resolved inside of the site using dynamic naming systems such as 257 Multicast DNS. 259 3.7 Application and Higher Level Protocol Issues 261 Application and other higher level protocols can treat Globally 262 Unique IPv6 Local addresses in the same manner as other types of 263 global unicast addresses. No special handling is required. This 264 type of addresses may not be reachable, but that is no different from 265 other types of IPv6 global unicast addresses. Applications need to 266 be able to handle multiple addresses that may or may not be reachable 267 any point in time. 269 3.8 Use of Globally Unique IPv6 Local Addresses for Local Communications 271 IPv6 globally unique IPv6 local addresses, like global scope unicast 272 addresses, are only assigned to nodes if their use has been enabled 273 (via IPv6 address autoconfiguration [ADDAUTO], DHCPv6 [DHCP6], or 274 manually) and configured in the DNS. They are not created 275 automatically the way that IPv6 link-local addresses are and will not 276 appear or be used unless they are purposely configured. 278 In order for hosts to autoconfigure globally unique IPv6 local 279 addresses routers have to be configured to advertise globally unique 280 IPv6 local /64 prefixes in router advertisements. Likewise, a DHCPv6 281 server must have been configured to assign them. In order for a node 282 to learn the globally unique IPv6 local address of another node, the 283 globally unique IPv6 local address must have been installed in the 284 DNS. For these reasons, it is straight forward to control their 285 usage in a site. 287 To limit the use of globally unique IPv6 local addresses the 288 following guidelines apply: 290 - Nodes that are to only be reachable inside of a site, the local 291 DNS should be configured to only include the globally unique 292 IPv6 local addresses of these nodes. Nodes with only globally 293 unique IPv6 local addresses must not be installed in the global 294 DNS. 296 - Nodes that are to be limited to only communicate with other 297 nodes in the site should be set to only autoconfigure globally 298 unique IPv6 local addresses via [ADDAUTO] or to only receive 299 globally unique IPv6 local addresses via [DHCP6]. Note: For the 300 case where both global and globally unique IPv6 local prefixes 301 are being advertised on a subnet, this will require a switch in 302 the devices to only autoconfigure globally unique IPv6 local 303 addresses. 305 - Nodes that are to be reachable from inside of the site and from 306 outside of the site, the DNS should be configured to include the 307 global addresses of these nodes. The local DNS may be 308 configured to also include the globally unique IPv6 local 309 addresses of these nodes. 311 - Nodes that can communicate with other nodes inside of the site 312 and outside of the site, should autoconfigure global addresses 313 via [ADDAUTO] or receive global address via [DHCP6]. They may 314 also obtain globally unique IPv6 local addresses via the same 315 mechanisms. 317 3.9 Use of Globally Unique IPv6 Local Addresses with VPNs 319 Globally unique IPv6 local addresses can be used for inter-site 320 Virtual Private Networks (VPN) if appropriate routes are set up. 321 Because the addresses are unique these VPNs will work reliably and 322 have the additional property that they will continue to work if the 323 individual sites are renumbered or merged. 325 4.0 Advantages and Disadvantages 327 4.1 Advantages 329 This approach has the following advantages: 331 - Provides globally unique local prefixes that can be used 332 independently of any provider based IPv6 unicast address 333 allocations. This is useful for sites not always connected to 334 the Internet or sites that wish to have a distinct prefix that 335 can be used to localize traffic inside of the site. 336 - Applications can treat these addresses in an identical manner as 337 any other type of global IPv6 unicast addresses. 338 - Sites can be merged without any renumbering of the globally 339 unique IPv6 local addresses. 340 - Sites can change their provider based IPv6 unicast address 341 without disrupting any communication using globally unique IPv6 342 local addresses. 343 - Well known prefix that allows for easy filtering at site 344 boundary. 345 - Can be used for inter-site VPNs. 346 - If accidently leaked outside of a site via routing or DNS, there 347 is no conflict with any other addresses. 349 4.2 Disadvantages 351 This approach has the following disadvantages: 353 - Not possible to route globally unique IPv6 local prefixes on the 354 global Internet with current routing technology. 355 - Requires the creation of a central allocation authority. 357 5.0 Security Considerations 359 Globally unique IPv6 local addresses do not provide any inherent 360 security to the nodes that use them. They may be used with filters 361 at site boundaries to keep globally unique IPv6 local traffic inside 362 of the site, but this is no more or less secure than filtering any 363 other type of global IPv6 unicast addresses. 365 6.0 IANA Considerations 367 The IANA should allocate the FC00::/7 prefix for Globally Unique IPv6 368 Local addresses. The Global ID values of zero and all ones are 369 reserved for future use and should not be assigned. 371 The IANA should setup a allocation authority for Globally Unique IPv6 372 Local prefixes. This allocation authority should consistent with the 373 requirements described in section 3.1 of this document. 375 REFERENCES 377 Normative 379 [ADDARCH] Hinden, R., S. Deering, S., "IP Version 6 Addressing 380 Architecture", RFC3515, April 2003. 382 [GLOBAL] Hinden, R., S. Deering, E. Nordmark, "IPv6 Global Unicast 383 Address Format", Internet Draft, , February 2003. 386 [IPV6] Deering, S., R. Hinden, "Internet Protocol, Version 6 387 (IPv6) Specification", RFC2460, December 1998. 389 [POPUL] Population Reference Bureau, "World Population Data Sheet 390 of the Population Reference Bureau 2002", August 2002. 392 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 393 3", RFC2026, BCP00009, October 1996. 395 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 396 Requirement Levels", RFC2119, BCP14, March 1997. 398 Non-Normative 400 [ADDAUTO] Thomson, S., T. Narten, "IPv6 Stateless Address 401 Autoconfiguration", RFC2462, December 1998. 403 [DHCP6] Droms, R., et. al., "Dynamic Host Configuration Protocol 404 for IPv6 (DHCPv6)", Internet Draft, , November 2002. 407 AUTHOR'S ADDRESS 409 Robert M. Hinden 410 Nokia 411 313 Fairchild Drive 412 Mountain View, CA 94043 413 USA 415 phone: +1 650 625-2004 416 email: bob.hinden@nokia.com