idnits 2.17.1 draft-ietf-ipv6-ula-central-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 407. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 418. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 425. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 431. 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 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The allocation of Global IDs should be pseudo-random [RANDOM]. They MUST not be assigned sequentially. They MUST not be allocated in a manner where there is a relationship between allocations that would make it easy to aggregate the resulting prefixes. This is done to make clear that these prefixes are not intended to be routed globally. -- 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS' ** Obsolete normative reference: RFC 1305 (ref. 'NTP') (Obsoleted by RFC 5905) ** Downref: Normative reference to an Informational RFC: RFC 3174 (ref. 'SHA1') Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT R. Hinden, Nokia 2 June 15, 2007 G. Huston, APNIC 3 Intended status: Proposed Standard T. Narten, IBM 5 Centrally Assigned 6 Unique Local IPv6 Unicast Addresses 8 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on December 21, 2007. 35 Abstract 37 This document defines Centrally allocated IPv6 Unique Local 38 addresses. These addresses are globally unique and are intended for 39 local communications, usually inside of a site. They are not 40 expected to be routable on the global Internet. 42 Table of Contents 44 1.0 Introduction....................................................2 45 2.0 Acknowledgments.................................................3 46 3.0 Local IPv6 Unicast Addresses....................................3 47 3.1 Format..........................................................3 48 3.2 Global ID.......................................................4 49 3.2.1 Allocation of Centrally Assigned Global IDs...................5 50 3.2.2 Sample Code for Pseudo-Random Global ID Algorithm.............5 51 3.3 Public Registration Services....................................6 52 4.0 Operational Guideliens..........................................6 53 5.0 Global Routing Considerations...................................7 54 6.0 Security Considerations.........................................7 55 7.0 IANA Considerations.............................................7 56 8.0 References......................................................8 57 8.1 Normative References............................................8 58 8.2 Informative References..........................................8 59 9.0 Authors' Addresses..............................................9 60 10.0 Change Log....................................................10 61 11.0 Full Copyright................................................10 62 12.0 Intellectual Property.........................................10 64 1.0 Introduction 66 This document defines the characteristics and technical allocation 67 requirements for centrally assigned Local IPv6 addresses in the 68 framework defined in [ULA]. They are not expected to be routable on 69 the global Internet. They are routable inside of a more limited area 70 such as a site. They may also be routed between a limited set of 71 sites. 73 Local IPv6 unicast addresses, as defined in [ULA], have the following 74 characteristics: 76 - Globally unique prefix. 77 - Well known prefix to allow for easy filtering at site 78 boundaries. 79 - Internet Service Provider independent and can be used for 80 communications inside of a site without having any permanent or 81 intermittent Internet connectivity. 82 - In practice, applications may treat these addresses like global 83 scoped addresses. 85 It is a highly desirable property of ULAs that they are unique, as 86 ULA uniqueness would allow sites to be combined or privately 87 interconnected without creating any address conflicts. 89 Topics that are general to all Local IPv6 address can be found in the 90 following sections of [ULA]: 92 3.3 Scope Definition 93 4.0 Operational Guidelines ** 94 4.1 Routing 95 4.2 Renumbering and Site Merging 96 4.3 Site Border Router and Firewall Packet Filtering 97 4.5 Application and Higher Level Protocol Issues 98 4.6 Use of Local IPv6 Addresses for Local Communications 99 4.7 Use of Local IPv6 Addresses with VPNs 100 5.0 Global Routing Concerns 101 6.0 Advantages and Disadvantages 103 ** Note: Operational guidelines specific to centrally assigned Local 104 IPv6 addresses are in Section 4.0 of this document. 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in [RFC2119]. 110 2.0 Acknowledgments 112 The authors would like to thank Alan Beard, Alex Zinin, Bill Fenner, 113 Brian Carpenter, Brian Haberman Charlie Perkins, Christian Huitema, 114 Hans Kruse, Harald Alvestrand, Keith Moore, Leslie Daigle, Margaret 115 Wasserman, Pekka Savola, Shannon Behrens, Steve Bellovin, Tim Chown, 116 and Tony Hain for their comments and suggestions on this document. 118 3.0 Centrally Assigned Local IPv6 Unicast Addresses 120 3.1 Format 122 The Centrally assigned Local IPv6 addresses, based on Unique Local 123 Addresses [ULA], have the following format: 125 | 7 bits |1| 40 bits | 16 bits | 64 bits | 126 +--------+-+------------+-----------+----------------------------+ 127 | Prefix |L| Global ID | Subnet ID | Interface ID | 128 +--------+-+------------+-----------+----------------------------+ 130 Where: 132 Prefix FC00::/7 prefix to identify Local IPv6 unicast 133 addresses. 135 L Set to 0 if the prefix is centrally assigned, 136 Note: [ULA] defined L=1 for locally assigned 137 ULAs. This document defines L=0 for centrally 138 assigned ULA addresses. See Section 3.2 for 139 additional information. 141 Global ID 40-bit global identifier used to create a 142 globally unique prefix. See Section 3.2 for 143 additional information. 145 Subnet ID 16-bit Subnet ID is an identifier of a subnet 146 within the site. 148 Interface ID 64-bit Interface ID as defined in [ADDARCH]. 150 3.2 Global ID 152 The allocation of Global IDs should be pseudo-random [RANDOM]. They 153 MUST not be assigned sequentially. They MUST not be allocated in a 154 manner where there is a relationship between allocations that would 155 make it easy to aggregate the resulting prefixes. This is done to 156 make clear that these prefixes are not intended to be routed 157 globally. 159 The major difference between the locally assigned Unique Local 160 Addresses defined in [ULA] and the centrally assigned Unique Local 161 Addresses, as defined in this document, is that they are uniquely 162 assigned and the assignments are registered in a public database. 164 It is expected that large managed sites will prefer central 165 assignments and small or disconnected sites will prefer local 166 assignments. It is recommended that sites planning to use Local IPv6 167 addresses for extensive inter-site communication, initially or as a 168 future possibility, use a centrally assigned prefix as there is no 169 possibility of assignment conflicts. Sites are free to choose either 170 approach. 172 This document defines the allocation procedure for creating global- 173 IDs for centrally assigned local IPv6 addresses (i.e., L=0). The 174 allocation procedure for locally assigned local IPv6 addresses (i.e., 175 L=1) is defined in [ULA]. 177 3.2.1 Allocation of Centrally Assigned Global IDs 179 Global IDs should be allocated by a new registry function such that 180 each allocation is unique and that the assignment is recorded and 181 published in a public database to verify that that allocation was 182 unique. 184 Global IDs may be assigned under the authority of a single allocation 185 organization or by multiple organizations. If there are multiple 186 organizations, there MUST be an operating procedure that ensures that 187 the entire allocation space maintains it property of uniqueness and 188 that the allocations are recorded in a single public database. 190 The requirements for centrally assigned Global ID allocations are: 192 - Globally unique. 193 - Available to anyone in an unbiased manner. 195 The allocation function must include the ability to make an 196 allocation on a permanent basis, without any need for renewal and 197 without any procedure for de-allocation. Other forms of allocation, 198 including periodic renewable allocations and explicit provision for 199 de-allocation may also be provided. 201 The allocation service should include sufficient provisions to 202 mitigate attempts to artificially reduce the number pool through 203 hoarding of numbers. The mechanism used by the registration 204 authority should not include onerous provisions that reduce the 205 intent that these allocations should be available to anyone in an 206 unbiased manner, and should not attempt to perform rationing or 207 impose quotas upon allocations. 209 The registration authority may covers its costs through registration 210 fees and may also use registration agreements to clearly set forth 211 the terms conditions and liabilities associated with registration of 212 such allocations. The payments and conditions associated with this 213 function should not be unreasonably onerous to the extent that the 214 availability of allocations is impaired. 216 3.2.2 Sample Code for Pseudo-Random Global ID Algorithm 218 The algorithm described below is intended to be used for centrally 219 assigned Global IDs. In each case the resulting global ID will be 220 used in the appropriate prefix as defined in Section 3.2. 222 1) Obtain the current time of day in 64-bit NTP format [NTP]. 223 2) Obtain an EUI-64 identifier from the system running this 224 algorithm. If an EUI-64 does not exist, one can be created from 225 a 48-bit MAC address as specified in [ADDARCH]. If an EUI-64 226 cannot be obtained or created, a suitably unique identifier, 227 local to the node, should be used (e.g. system serial number). 229 3) Concatenate the time of day with the system-specific identifier 230 creating a key. 231 4) Compute an SHA-1 digest on the key as specified in [FIPS, SHA1]; 232 the resulting value is 160 bits. 233 5) Use the least significant 40 bits as the Global ID. 234 6) Verify that the computed Global ID is not already assigned. If 235 it is, discard the value and rerun the algorithm. 236 7) Concatenate FC00::/7, the L bit set to 0, and the 40 bit Global 237 ID to create a centrally assigned Local IPv6 address prefix. 239 This algorithm will result in a Global ID that is unique and can be 240 used to create a centrally assigned local IPv6 address prefix. 242 3.3 Public Registration Services 244 The registration of centrally assigned ULAs should be available in a 245 public database. This function should support a query of a specific 246 ULA prefix and then return the registrant's provided detail. 247 Information should be provided in a robust fashion, consistent with 248 the current state of similar registration services provided by 249 address and domain name registration authorities. 251 4.0 Operational Guidelines 253 4.1 DNS Issues 255 AAAA and PTR records for centrally assigned local IPv6 addresses may 256 be installed in the global DNS. This may be useful if these 257 addresses are being used for site to site or VPN style applications, 258 or for sites that wish to avoid separate DNS systems for inside and 259 outside traffic. 261 The operational issues relating to this are beyond the scope of this 262 document. 264 5.0 Global Routing Considerations 266 Since [ULA] was first published, the Regional Internet Address 267 Registries (RIR) created a new policy to allocate IPv6 Provider 268 Independent Addresses [RIR-PI]. Given the availability of RIR 269 allocated provider-independent addresses the authors believe that 270 there is considerably less concern that ULAs of either type will be 271 used as IPv6 provider-independent addresses. 273 The operational guidelines regarding routing of centrally assigned 274 local addresses is that such address prefixes should be readily 275 routed within a site or comparable administrative routing domain. 277 By default, such prefixes should not be announced beyond such a local 278 scope, due to the non-aggregateability of these prefixes within the 279 routing system and the potential negative impact on the total size of 280 the routing space in large scale internet environments. 282 Entities wishing to use IPv6 Provider Independent Addresses (PI 283 Space) in such larger routing contexts should consult the Regional 284 Internet Registries policies relating to the allocation of PI Space 285 [RIR-PI]. 287 6.0 Security Considerations 289 Local IPv6 addresses do not provide any inherent security to the 290 nodes that use them. They may be used with filters at site 291 boundaries to keep Local IPv6 traffic inside of the site, but this is 292 no more or less secure than filtering any other type of global IPv6 293 unicast addresses. 295 Local IPv6 addresses do allow for address-based security mechanisms, 296 including IPSEC, across end to end VPN connections. 298 7.0 IANA Considerations 300 The IANA is instructed to designate an allocation authority for 301 centrally assigned Unique Local IPv6 unicast addresses. This 302 allocation authority shall comply with the requirements described in 303 Section 3.2 of this document, including in particular allocation on a 304 permanent basis and with sufficient provisions to avoid hoarding of 305 numbers. If deemed appropriate, the authority may also consist of 306 multiple organizations performing the allocation authority duties. 308 The Regional Internet Address registries are expected to be the 309 allocation authority for centrally assigned Unique Local IPv6 310 addresses. 312 The designated allocation authority is required to document how they 313 will meet the requirements described in Section 3.2 of this document 314 in an RFC. 316 8.0 References 318 8.1 Normative References 320 [ADDARCH] Hinden, R., S. Deering, S., "IP Version 6 Addressing 321 Architecture", RFC 3515, April 2003. 323 [FIPS] "Federal Information Processing Standards Publication", 324 (FIPS PUB) 180-1, Secure Hash Standard, 17 April 1995. 326 [NTP] Mills, David L., "Network Time Protocol (Version 3) 327 Specification, Implementation and Analysis", RFC 1305, 328 March 1992. 330 [RANDOM] Eastlake, D. 3rd, J. Schiller, S. Crocker, "Randomness 331 Recommendations for Security", RFC 4086, June 2005. 333 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 334 Requirement Levels", RFC 2119, BCP14, March 1997. 336 [SHA1] D. Eastlake 3rd, P. Jones, "US Secure Hash Algorithm 1 337 (SHA1)", RFC 3174, September 2001. 339 [ULA] Hinden, R., B. Haberman, "Unique Local IPv6 Unicast 340 Addresses", RFC-4193, October 2005. 342 8.2 Informative References 344 [RIR-PI] O. DeLong, K. Loch, A. Dul, "Policy Proposal 2005-1: 345 Provider-independent IPv6 Assignments for End Sites", 346 http://www.arin.net/policy/proposals/2005_1.html, May 2006. 348 9.0 Authors' Addresses 350 Robert M. Hinden 351 Nokia 352 313 Fairchild Drive 353 Mountain View, CA 94043 354 USA 356 phone: +1 650 625-2004 357 email: bob.hinden@nokia.com 359 Geoff Huston 360 APNIC 362 Thomas Narten 363 IBM Corporation 364 3039 Cornwallis Ave. 365 PO Box 12195 - BRQA/502 366 Research Triangle Park, NC 27709-2195 368 Phone: +1 919 254 7798 369 email: narten@us.ibm.com 371 10.0 Change Log 373 Draft 374 o Major revision based on experience to date with [ULA] and later 375 input from the RIR community 377 Draft 379 o Revised to keep consistent with [ULA]. This includes single 380 prefix, L bit, change to SHA-1 algorithm, and clarifications to 381 suggested algorithm. 382 o Revised IANA considerations section based on feedback from the 383 IAB. 384 o Added new DNS operational guidelines sections specific to 385 centrally assigned local IPv6 addresses. 386 o Editorial changes. 388 Draft 390 o Initial Draft created from [ULA]. This draft defines the 391 centrally assigned Local IPv6 addresses. 393 11. Full Copyright Statement 395 Copyright (C) The IETF Trust (2007). 397 This document is subject to the rights, licenses and restrictions 398 contained in BCP 78, and except as set forth therein, the authors 399 retain all their rights. 401 This document and the information contained herein are provided on an 402 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 403 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 404 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 405 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 406 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 407 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 409 12. Intellectual Property 411 The IETF takes no position regarding the validity or scope of any 412 Intellectual Property Rights or other rights that might be claimed to 413 pertain to the implementation or use of the technology described in 414 this document or the extent to which any license under such rights 415 might or might not be available; nor does it represent that it has 416 made any independent effort to identify any such rights. Information 417 on the procedures with respect to rights in RFC documents can be 418 found in BCP 78 and BCP 79. 420 Copies of IPR disclosures made to the IETF Secretariat and any 421 assurances of licenses to be made available, or the result of an 422 attempt made to obtain a general license or permission for the use of 423 such proprietary rights by implementers or users of this 424 specification can be obtained from the IETF on-line IPR repository at 425 http://www.ietf.org/ipr. 427 The IETF invites any interested party to bring to its attention any 428 copyrights, patents or patent applications, or other proprietary 429 rights that may cover technology that may be required to implement 430 this standard. Please address the information to the IETF at ietf- 431 ipr@ietf.org. 433 Acknowledgment 435 Funding for the RFC Editor function is provided by the IETF 436 Administrative Support Activity (IASA).