idnits 2.17.1 draft-hain-ipv6-ulac-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 10, 2010) is 5038 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: 'RIR-PI' is mentioned on line 313, but not defined == Unused Reference: 'FIPS' is defined on line 371, but no explicit reference was found in the text == Unused Reference: 'GLOBAL' is defined on line 375, but no explicit reference was found in the text == Unused Reference: 'ICMPv6' is defined on line 378, but no explicit reference was found in the text == Unused Reference: 'IPv6' is defined on line 382, but no explicit reference was found in the text == Unused Reference: 'NTP' is defined on line 385, but no explicit reference was found in the text == Unused Reference: 'RANDOM' is defined on line 388, but no explicit reference was found in the text == Unused Reference: 'SHA1' is defined on line 394, 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 2460 (ref. 'IPv6') (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 1305 (ref. 'NTP') (Obsoleted by RFC 5905) ** Downref: Normative reference to an Informational RFC: RFC 3174 (ref. 'SHA1') Summary: 5 errors (**), 0 flaws (~~), 10 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Hain 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track R. Hinden 5 Expires: January 11, 2011 6 G. Huston 7 APnic 8 July 10, 2010 10 Centrally Assigned IPv6 Unicast Unique Local Address Prefixes 11 draft-hain-ipv6-ulac-02 13 Abstract 15 This document defines Centrally Allocated IPv6 Unique Local address 16 prefixes. These prefixes are globally unique and are intended for 17 local communications, usually within a single network administration. 18 They are not intended to be used in place of Provider Independent 19 (PI) address prefixes available from the Regional Internet Registries 20 (RIR) , and should not appear 21 in the global routing table for the Internet. 23 The draft is being discussed on the ipv6@ietf.org list. 25 Legal 27 This documents and the information contained therein are provided on 28 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 29 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 30 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 31 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 32 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 33 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 34 FOR A PARTICULAR PURPOSE. 36 Status of this Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at http://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on January 11, 2011. 53 Copyright Notice 55 Copyright (c) 2010 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 This document may contain material from IETF Documents or IETF 69 Contributions published or made publicly available before November 70 10, 2008. The person(s) controlling the copyright in some of this 71 material may not have granted the IETF Trust the right to allow 72 modifications of such material outside the IETF Standards Process. 73 Without obtaining an adequate license from the person(s) controlling 74 the copyright in such materials, this document may not be modified 75 outside the IETF Standards Process, and derivative works of it may 76 not be created outside the IETF Standards Process, except to format 77 it for publication as an RFC or to translate it into languages other 78 than English. 80 Table of Contents 82 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 83 1.1. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 6 84 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 85 3. Centrally Assigned Local IPv6 Unicast Address prefixes . . . . 6 86 3.1. Format . . . . . . . . . . . . . . . . . . . . . . . . . . 6 87 3.2. Registration process . . . . . . . . . . . . . . . . . . . 7 88 4. Operational Guidelines . . . . . . . . . . . . . . . . . . . . 7 89 4.1. DNS Issues . . . . . . . . . . . . . . . . . . . . . . . . 7 90 4.2. Routing Considerations . . . . . . . . . . . . . . . . . . 7 91 4.2.1. From the standpoint of the Internet . . . . . . . . . 8 92 4.2.2. From the Standpoint of a local network 93 administrator . . . . . . . . . . . . . . . . . . . . 8 94 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 95 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 96 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 97 7.1. Normative References . . . . . . . . . . . . . . . . . . . 9 98 7.2. Informative References . . . . . . . . . . . . . . . . . . 10 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 101 1. Introduction 103 This document defines the characteristics, technical assignment and 104 registration requirements for Centrally Assigned Local IPv6 addresses 105 in the framework defined in [ULA]. There are organizations looking 106 for address space that is independent of the ranges used for public 107 Internet routing, yet they also need the uniqueness of central 108 assignment which the locally assigned ULA block cannot provide. A 109 stumbling block in earlier attempts at defining the Centrally 110 Allocated portion of the ULA prefix range (ULA-C) was the lack of 111 public policy at the RIR's for organizations to acquire PI address 112 prefixes, so the ULA-C effort was seen as an end-run around the 113 public policy process. As the ability to acquire PI space is now 114 resolved by assignment policy, it is time to resurrect the definition 115 for the lower half of the ULA prefix range. At the same time, this 116 document will defer as much policy as possible, and focus on 117 technical definition. To make the range useful to a wide range of 118 organizations, the requirements to register a ULA-C prefix should be 119 less stringent than the requirements to acquire a PI prefix, but non- 120 trivial and sufficient to keep them from becoming an attractive 121 nuisance to bypass PI policy. For the sake of policy continuity the 122 IAB should strongly consider organizatoinal alignment for the 123 managemnet of the ULA-C prefix with that for globally routable 124 prefixes.[NUMBERS] 126 In any case, the prefixes defined here are not expected to appear in 127 the routing system for the global Internet. A frequent question is 128 how this prefix differs from a PI assignment. The simple answer is 129 in expectation of global public routability. A PI assignment has the 130 expectation that it could appear in the global DFZ, where a ULA-C 131 registration is expected to be limited reach as service providers are 132 free to, and expected to filter the entire FC00::/7 prefix as bogon 133 space. Recognizing that this is a policy statement; the appropriate 134 use of these prefixes is within a single network administration, or 135 between privately interconnected networks that want to ensure that 136 private communications do not accidentally get routed over the public 137 Internet as might happen with PI. 139 Centrally registered Local IPv6 unicast addresses have the following 140 characteristics: 142 - Globally unique registration for each prefix. 143 - Well known designator prefix to allow for easy filtering at 144 administrative boundaries. 145 - Allows sites to be combined or privately interconnected without 146 creating any address conflicts or requiring renumbering of 147 interfaces. 148 - Internet Service Provider independent and can be used for 149 communications inside of a private network where public Internet 150 connectivity is intermittent or not available. 151 - If accidentally leaked outside of a private network via routing 152 or DNS, there is no conflict with any other addresses. 153 - In practice, applications may treat these addresses like global 154 scoped addresses. 156 Topics that are general to all Local IPv6 address can be found in the 157 following sections of [ULA]: 159 3.3 Scope Definition 160 4.0 Operational Guidelines ** 161 4.1 Routing 162 4.2 Renumbering and Site Merging 163 4.3 Site Border Router and Firewall Packet Filtering 164 4.5 Application and Higher Level Protocol Issues 165 4.6 Use of Local IPv6 Addresses for Local Communications 166 4.7 Use of Local IPv6 Addresses with VPNs 167 6.0 Advantages and Disadvantages 168 ** Operational guidelines specific to centrally assigned Local IPv6 169 addresses are in Section 4.0 of this document. 171 Where the Unique Local Address prefixes defined in [ULA]were 172 probabilistically unique, the major difference between those and the 173 Centrally Allocated local address prefixes defined in this document 174 is that the ULA-C prefixes are registered and verified unique before 175 assignment, with the registrations escrowed to resolve any disputes 176 regarding duplicate assignments. 178 It is expected that network administrators of larger organizations, 179 or those with business practice or governmental requirements to avoid 180 conflict in future mergers or acquisitions will prefer central 181 assignments, while most small or disconnected organizations will 182 prefer local assignments. It is recommended that network 183 administrations which are planning to use Local IPv6 address 184 prefixes, for extensive inter-site communication over a long period 185 of time, use a Centrally Allocated prefix as there is no possibility 186 of assignment conflicts when interconnecting or merging networks. 187 Individual administrations are free to choose either approach, and in 188 fact may choose both, with a Centrally Allocated prefix for their 189 production networks while using locally allocated prefixes in their 190 experimental or lab networks. 192 1.1. Acknowledgements 194 Robert Hinden and Brian Haberman attempted a version of this 195 specification between 2002 & 2005, followed by another attempt by 196 Geoff Huston and Thomas Narten in 2007. Both of those drafts were 197 significant resources for much of the text used in developing this 198 document, as those included comments from Alan Beard, Alex Zinin, 199 Brian Carpenter, Charlie Perkins, Christian Huitema, Hans Kruse, 200 Harald Alvestrand, Keith Moore, Leslie Daigle, Margaret Wasserman, 201 Pekka Savola, Shannon Behrens, Steve Bellovin, Tim Chown, and Bill 202 Fenner. Additional comments to this document were provided by ... 204 2. Terminology 206 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 207 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 208 document are to be interpreted as described in [RFC2119] . 210 3. Centrally Assigned Local IPv6 Unicast Address prefixes 212 3.1. Format 214 The Centrally assigned Local IPv6 addresses, based on Unique Local 215 Addresses [ULA], have the following format: 217 | 7 bits |1| 40 bits | 16 bits | 64 bits | 218 +--------+-+------------+-----------+-----------------------------+ 219 | Prefix |L| Global ID | Subnet ID | Interface ID | 220 +--------+-+------------+-----------+-----------------------------+ 222 Where: 224 Prefix FC00::/7 prefix to identify Local IPv6 unicast 225 addresses. 227 L Set to 1 if the prefix is locally assigned, 228 Set to 0 if it is centrally assigned. 230 Global ID 40-bit global identifier used to create a 231 globally unique prefix. 233 Subnet ID 16-bit Subnet ID is an identifier of a subnet 234 within the site. 236 Interface ID 64-bit Interface ID as defined in [ADDARCH]. 238 NOTE: This document defines the assignment and registration 239 procedure for creating global- IDs for Centrally Allocated local IPv6 240 address prefixes (L=0 ; FC00::/8). The assignment procedure for 241 locally allocated local IPv6 address prefixes (L=1 ; FD00::/8) is 242 defined in [ULA]. 244 3.2. Registration process 246 Global IDs MUST be allocated under a single assignment and 247 registration authority. The IAB SHOULD designate IANA as the 248 registration authority. As policies differ around the world, IANA 249 SHOULD delegate to the RIRs in a manner similar to the /12 approach 250 used for the 2000::/3 prefix. The RIRs SHOULD establish registration 251 policies which recognize that ULA-C prefixes are not a threat to the 252 global DFZ, and therefore easier to justify. Organizations that 253 don't want an ongoing relationship with the RIRs SHOULD be directed 254 to RFC 4193. 256 The requirements for ULA-C assignment and registrations are: 258 - Available to anyone in an unbiased manner. 259 - Globally Unique. 260 - When justified, available as a single prefix between /44 - /48. 262 4. Operational Guidelines 264 4.1. DNS Issues 266 Given their inherent uniqueness, AAAA and PTR records for centrally 267 assigned local IPv6 addresses may be installed and appear in the 268 global DNS. This may be useful if these addresses are being used for 269 site to site or VPN style applications, or for sites that wish to 270 avoid separate or split-DNS systems for inside and outside traffic. 271 Any operational issues relating to this are beyond the scope of this 272 document. 274 4.2. Routing Considerations 276 Section 4.1 of [ULA]provides operational guidelines that inhibit 277 default routing of local addresses between sites. During the initial 278 attempts at defining the ULA-C space, concerns were raised to the 279 IPv6 working group and to the IETF as a whole that lacking an 280 alternative, sites would attempt to use local address prefixes as 281 globally routed, provider-independent (PI) prefixes. Subsequent 282 policy changes have mitigated these concerns by allowing for PI 283 assignments. This section describes why using local addresses in 284 place of PI prefixes is unadvisable, and why existing RIR mechanisms 285 for acquiring PI prefix blocks should be used instead. 287 4.2.1. From the standpoint of the Internet 289 IPv6 unicast addresses are designed to be routed hierarchically down 290 to physical subnet (link) level and only have to be flat-routed 291 within the physical subnet prefix. Attempting to use IPv6 local 292 address prefixes publicly would result in them being flat-routed over 293 the wide area Internet, and thus a larger routing table. This 294 contravenes the operational assumption that for global public 295 routing, long prefixes will be aggregated into fewer short prefixes 296 to limit the table size and convergence time of the routing protocol. 298 Collecting all local-use prefixes under one short designator prefix 299 (FC00::/7) simplifies the development and maintenance of bogon route 300 filters. Given that everything registered under the procedures 301 defined in this document are intended for local, non-public use only, 302 it is expected to be common practice for all public service providers 303 to filter any prefixes within the entire ULA range (both centrally 304 registered and locally defined), and remove them from the public 305 global routing table. The alternative would be to enumerate every 306 prefix that should not be publicly routed, and then hope that there 307 are no operational errors that inadvertently allow a private prefix 308 to be propagated publically. 310 Entities wishing to use IPv6 Provider Independent Addresses (PI 311 Space) in such larger routing contexts should consult the Regional 312 Internet Registries policies relating to the assignment of PI Space 313 [RIR-PI]. 315 4.2.2. From the Standpoint of a local network administrator 317 The operational guidelines regarding routing of centrally allocated 318 local addresses is that such address prefixes should be readily 319 routed within a site or comparable administrative routing domain. 321 By default, such prefixes should not be announced beyond such a local 322 scope, due to the non-aggregateability of these prefixes within the 323 global routing system and the potential negative impact on the total 324 size of the routing space in large scale Internet environments. 326 5. Security Considerations 328 Local IPv6 address prefixes do not provide any inherent security to 329 the nodes that use them. They may be used with filters at site 330 boundaries to keep Local IPv6 traffic inside of the site, but this is 331 no more or less secure than filtering any other type of global IPv6 332 unicast address prefixes. 334 They should be filtered by public network operators to ensure that 335 publicly routed prefixes are publicly documented, but beyond 336 accountability there is no security aspect related to propagating the 337 route. On the other hand, the lack of a public routing entry is 338 considered by many to be one layer in a defense-in-depth strategy, so 339 widespread practice of filtering the entire ULA prefix range would 340 automatically provide that layer even for sites that don't implement 341 an explicit filter of their own. 343 Local IPv6 address prefixes do allow for address-based security 344 mechanisms, including IPSEC, across end to end VPN connections or 345 other private interconnects. 347 6. IANA Considerations 349 The IAB is expected to instruct IANA to designate an assignment 350 authority for Centrally Allocated Unique Local IPv6 unicast address 351 prefixes. This assignment authority shall comply with the 352 requirements described in Section 3.2 of this document, including in 353 particular assignment on a permanent basis and with sufficient 354 provisions to avoid hoarding of numbers. The IAB MAY instruct IANA 355 to designate itself as the assignment and registration authority, and 356 IANA in turn MAY choose to delegate the day-to-day operational 357 functions to the same organizations that handle publicly routed 358 prefixes to maintain consistency between assignment policies. 360 The designated assignment authority is required to document how they 361 will meet the requirements described in Section 3.2 of this document 362 in an RFC, which will be shepherd through the IETF by the IAB. 364 7. References 366 7.1. Normative References 368 [ADDARCH] Hinden, R. and S. Deering, "Internet Protocol Version 6 369 (IPv6) Addressing Architecture", RFC 3513, April 2003. 371 [FIPS] National Institute of Standards and Technology, "Secure 372 Hash Standard", FIPS PUB 180-1, April 1995, 373 . 375 [GLOBAL] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global 376 Unicast Address Format", RFC 3587, August 2003. 378 [ICMPv6] Conta, A., Deering, S., and M. Gupta, "Internet Control 379 Message Protocol (ICMPv6) for the Internet Protocol 380 Version 6 (IPv6) Specification", RFC 4443, March 2006. 382 [IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 383 (IPv6) Specification", RFC 2460, December 1998. 385 [NTP] Mills, D., "Network Time Protocol (Version 3) 386 Specification, Implementation", RFC 1305, March 1992. 388 [RANDOM] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 389 Requirements for Security", BCP 106, RFC 4086, June 2005. 391 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 392 Requirement Levels", BCP 14, RFC 2119, March 1997. 394 [SHA1] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 395 (SHA1)", RFC 3174, September 2001. 397 [ULA] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 398 Addresses", RFC 4193, October 2005. 400 7.2. Informative References 402 [NUMBERS] "IANA Numbers Authority", . 404 Authors' Addresses 406 Tony Hain 407 Cisco Systems 408 500 108th Ave NE 409 Bellevue, WA 98004 410 USA 412 Phone: +1 425 468-1061 413 Email: alh-ietf@tndh.net 414 Robert Hinden 415 313 Fairchild Drive 416 Mountain View, Ca 94043 417 USA 419 Phone: +1 650 625 2400 420 Email: bob.hinden@nokia.com 422 Geoff Huston 423 APnic 424 AU 426 Phone: 427 Email: gih@apnic.net