idnits 2.17.1 draft-huston-ip6-iana-registry-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 474. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 451. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 458. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 464. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** 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: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 10 instances of too long lines in the document, the longest one being 4 characters in excess of 72. == There are 2 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 395 has weird spacing: '...rovided helpf...' -- 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 (January 31, 2005) is 7024 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) -- Looks like a reference, but probably isn't: '1' on line 293 -- Looks like a reference, but probably isn't: '2' on line 297 -- Looks like a reference, but probably isn't: '3' on line 300 -- Looks like a reference, but probably isn't: '4' on line 302 -- Looks like a reference, but probably isn't: '0' on line 287 == Missing Reference: 'RFC1881' is mentioned on line 151, but not defined == Missing Reference: 'RFC1888' is mentioned on line 154, but not defined ** Obsolete undefined reference: RFC 1888 (Obsoleted by RFC 4048) == Missing Reference: 'RFCxxxx' is mentioned on line 162, but not defined == Missing Reference: 'RFC3879' is mentioned on line 159, but not defined == Missing Reference: 'RFC2928' is mentioned on line 311, but not defined == Missing Reference: 'RFC3849' is mentioned on line 324, but not defined == Missing Reference: 'RFC3056' is mentioned on line 314, but not defined == Missing Reference: 'RFC2471' is mentioned on line 308, but not defined ** Obsolete undefined reference: RFC 2471 (Obsoleted by RFC 3701) == Missing Reference: 'RFC3701' is mentioned on line 321, but not defined ** Obsolete normative reference: RFC 3513 (Obsoleted by RFC 4291) Summary: 9 errors (**), 0 flaws (~~), 13 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Individual Submission G. Huston 2 Internet-Draft APNIC 3 Expires: August 1, 2005 January 31, 2005 5 Proposed changes to the format of the IANA IPv6 Registry 6 draft-huston-ip6-iana-registry-05.txt 8 Status of this Memo 10 This document is an Internet-Draft and is subject to all provisions 11 of section 3 of RFC 3667. By submitting this Internet-Draft, each 12 author represents that any applicable patent or other IPR claims of 13 which he or she is aware have been or will be disclosed, and any of 14 which he or she become aware will be disclosed, in accordance with 15 RFC 3668. 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 20 Internet-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 August 1, 2005. 35 Copyright Notice 37 Copyright (C) The Internet Society (2005). 39 Abstract 41 This document proposes a revised format for the IANA IPv6 address 42 registries. Rather than a formal definition of the format, it is 43 described by giving examples of the (current as of publication of 44 this document) contents of the registries in the proposed format. 45 The proposed format would bring the IANA IPv6 address registries into 46 alignment with the current IPv6 Address Architecture specification, 47 as well as updating it to a more useful and generally accepted 48 format. 50 1. Introduction 52 This document proposes a revised format for the IANA IPv6 address 53 registries. The proposed format would bring the IANA IPv6 address 54 registries into alignment with the current IPv6 Address Architecture 55 specification, as well as updating it to a more useful and generally 56 accepted format. 58 The current (as of publication of this document) IANA IPv6 registries 59 [iana-ipv6-registry][iana-ipv6-tla] are based on a now-deprecated 60 address architecture that used the concept of Top Level Aggregation 61 Identifiers (TLAs) and sub-TLAs. The current IPv6 Address 62 Architecture [RFC3513] uses the terminology of Global Identifiers 63 instead of TLAs and sub-TLAs. 65 2. IPv6 Address Registry 67 The proposed registry format for the IPv6 address registry is 68 indicated by example, using the registry state current as of 69 preparation of this document, in Figure 1. The registry explicitly 70 notes which entity is placing a reservation on an address block and 71 notes the defining RFC document for each allocation. 73 The proposed format of the registry is a title line, the date of the 74 last change to the registry, the registry in a tabular format, notes 75 and references. 77 The table uses 4 columns. Within the table, the first column is an 78 IPv6 address prefix, using a hexadecimal notation of the address 79 prefix and a prefix length. There are no overlapping address blocks 80 in the first column, and the set of address blocks in the registry 81 span the entire IPv6 address space. The second column denotes the 82 current disposition of each address block, using notation as derived 83 from the defining RFC document. The third column is a reference to 84 the RFC that describes the current disposition of the address block. 85 The fourth column uses numeric footnote notation to reference any 86 additional text associated with the address block. 88 The notes in the registry may include a summary of previous 89 disposition status values associated with an address block, as this 90 summary is specifically not included in the registry table. The 91 notes are numbered sequentially. 93 The reference section uses a conventional citation format. The 94 references include documents referenced in the registry table and 95 documents referenced in the notes. 97 ----------------------------------------------------- 98 INTERNET PROTOCOL VERSION 6 ADDRESS SPACE 100 [last updated 13 January 2005] 102 IPv6 Prefix Allocation Reference Note 103 ----------- ---------- --------- ---- 104 0000::/8 Reserved by IETF RFC3513 [1] 105 0100::/8 Reserved by IETF RFC3513 106 0200::/7 Reserved by IETF RFCxxxx [2] 107 0400::/6 Reserved by IETF RFC3513 108 0800::/5 Reserved by IETF RFC3513 109 1000::/4 Reserved by IETF RFC3513 110 2000::/3 Global Unicast RFC3513 [3] 111 4000::/3 Reserved by IETF RFC3513 112 6000::/3 Reserved by IETF RFC3513 113 8000::/3 Reserved by IETF RFC3513 114 A000::/3 Reserved by IETF RFC3513 115 C000::/3 Reserved by IETF RFC3513 116 E000::/4 Reserved by IETF RFC3513 117 F000::/5 Reserved by IETF RFC3513 118 F800::/6 Reserved by IETF RFC3513 119 FA00::/7 Reserved by IETF RFC3513 120 FC00::/7 Reserved by IETF RFC3513 121 FE00::/9 Reserved by IETF RFC3513 122 FE80::/10 Link Local Unicast RFC3513 123 FEC0::/10 Reserved by IETF RFC3879 [4] 124 FF00::/8 Multicast RFC3513 126 Notes: 128 [0] The IPv6 address management function was formally delegated to 129 IANA in December 1995 [RFC1881]. 131 [1] The "unspecified address", the "loopback address", and the IPv6 132 Addresses with Embedded IPv4 Addresses are assigned out of the 133 0000::/8 address block. 135 [2] 0200::/7 was previously defined as an OSI NSAP-mapped prefix set 136 [RFC1888]. This definition has been deprecated as of December 137 2004 [RFCxxxx]. 139 [3] The IPv6 Unicast space encompasses the entire IPv6 address range 140 with the exception of FF00::/8. [RFC3513] IANA unicast address 141 assignments are currently limited to the IPv6 unicast address 142 range of 2000::/3. IANA assignments from this block are registered 143 in the IANA registry: iana-ipv6-unicast-address-assignments 145 [4] FEC0::/10 was previously defined as a Site-Local scoped address 146 prefix. This definition has been deprecated as of September 2004 147 [RFC3879]. 149 References: 151 [RFC1881] The IAB and IESG, "IPv6 Address Allocation Management", 152 RFC1881, December 1995. 154 [RFC1888] J. Bound et al, "OSI NSAPs and IPv6", RFC1888, August 1996. 156 [RFC3513] R. Hinden and S. Deering, "IP Version 6 Addressing 157 Architecture", RFC 3513, April 2003. 159 [RFC3879] C. Huitema and B. Carpenter, "Deprecating Site Local 160 Addresses", RFC 3879, September 2004. 162 [RFCxxxx] B. Carpenter, "RFC1888 is obsolete", RFC xxxx (work 163 in progress: draft-carpenter-obsolete-1888-01.txt). 165 ----------------------------------------------------- 167 Figure 1 169 2.1 Notes on Proposed Format Changes to the Registry 171 o The textual preamble at the start of the registry has been 172 removed, in deference to the use of standard IPv6 prefix notation 173 in the registry. 175 o Binary prefix notation has been replaced by standard IPv6 prefix 176 hexadecimal notation, and the fraction of address space column has 177 been replaced with the reference to the relevant RFC that defines 178 the disposition of the address block. Footnote references are 179 also displayed in a consistent fashion. 181 o The terminology "Unassigned" has been replaced by the more precise 182 phrase "Reserved by IETF", indicating the body that has the token 183 to permit reassignment of the status of this address block. 185 o The "Formerly Site-Local" entry in the body of the registry has 186 been replaced with an explicit reference to deprecation. A 187 similar treatment is proposed for 0200::/8, although the RFC 188 number for the deprecation document has yet to be assigned. There 189 is a distinction drawn between the current status of a registry 190 and the set of registry actions that have lead to the current 191 state. The registry table describes the current status of the 192 registry, while the text footnotes are used to describe the set of 193 transactions leading to the current state, including any former 194 states. 196 o Annotations that are references to footnotes are included in the 197 registry in its own column 199 o The text commentary on unicast, multicast and anycast addresses 200 has been removed as there is no distinction between anycast and 201 unicast addresses and multicast addresses are explicitly flagged 202 in the registry. 204 o A note and a corresponding reference to RFC1881 was added to 205 record the formal delegation of the IPv6 address management 206 function to IANA. 208 3. Global Unicast IPv6 Address Registry 210 The proposed registry format for Global Unicast IPv6 address block 211 allocations is indicated by example, using the registry state current 212 as of preparation of this document, in Figure 2. The registry notes 213 the current allocations, and does not include any notation of 214 intended future allocations or reservations. All address space not 215 listed in this registry forms the IANA unallocated address pool, to 216 be allocated by IANA as per the prevailing address allocation 217 policies. 219 The proposed format of the registry is a title line, the date of the 220 last change to the registry, the registry in a tabular format, notes 221 and references. 223 The table uses 4 columns. Within the table, the first column is an 224 IPv6 address prefix, using a hexadecimal notation of the address 225 prefix and a prefix length. There are no overlapping address blocks 226 in the first column. The entries here describe only IANA allocations 227 of address blocks. Temporary IANA reservations for future 228 allocations, allocation expansion windows and any other internal IANA 229 states are not described in this registry. The second column 230 describes the current disposition of the address block, either by 231 noting the RIR to whom the address block was assigned, or the 232 intended use of the address block. The third column is the date of 233 the IANA allocation, including the day of the month. The fourth 234 column uses numeric footnote notation to reference any additional 235 text associated with the address block. 237 The notes in the registry may include a summary of previous 238 disposition status values associated with an address block, as this 239 summary is specifically not included in the registry table. The 240 notes are numbered sequentially. 242 The reference section uses a conventional citation format. The 243 references include documents referenced in the registry table and 244 documents referenced in the notes. 246 ----------------------------------------------------- 248 IPV6 GLOBAL UNICAST ADDRESS ASSIGNMENTS 250 [last updated 13 January 2005] 252 Global Unicast Prefix Assignment Date Note 253 --------------------- ---------- ------ ---- 254 2001:0000::/23 IANA 01 Jul 99 [1] 255 2001:0200::/23 APNIC 01 Jul 99 256 2001:0400::/23 ARIN 01 Jul 99 257 2001:0600::/23 RIPE NCC 01 Jul 99 258 2001:0800::/23 RIPE NCC 01 May 02 259 2001:0A00::/23 RIPE NCC 02 Nov 02 260 2001:0C00::/23 APNIC 01 May 02 [2] 261 2001:0E00::/23 APNIC 01 Jan 03 262 2001:1200::/23 LACNIC 01 Nov 02 263 2001:1400::/23 RIPE NCC 01 Feb 03 264 2001:1600::/23 RIPE NCC 01 Jul 03 265 2001:1800::/23 ARIN 01 Apr 03 266 2001:1A00::/23 RIPE NCC 01 Jan 04 267 2001:1C00::/22 RIPE NCC 01 May 04 268 2001:2000::/20 RIPE NCC 01 May 04 269 2001:3000::/21 RIPE NCC 01 May 04 270 2001:3800::/22 RIPE NCC 01 May 04 271 2001:4000::/23 RIPE NCC 11 Jun 04 272 2001:4200::/23 ARIN 01 Jun 04 273 2001:4400::/23 APNIC 11 Jun 04 274 2001:4600::/23 RIPE NCC 17 Aug 04 275 2001:4800::/23 ARIN 24 Aug 04 276 2001:4A00::/23 RIPE NCC 15 Oct 04 277 2001:4C00::/23 RIPE NCC 17 Dec 04 278 2001:5000::/20 RIPE NCC 10 Sep 04 279 2001:8000::/19 APNIC 30 Nov 04 280 2001:A000::/20 APNIC 30 Nov 04 281 2002::/16 6to4 01 Feb 01 [3] 282 2003:0000::/18 RIPE NCC 12 Jan 05 283 3FFE::/16 6BONE 01 Dec 98 [4] 285 Notes: 287 [0] The assignable Global Unicast Address space is defined 288 in [RFC3513] as being the address block defined by the 289 prefix 2000::/3. All address space in this block not 290 listed in the table above is reserved by IANA for 291 future allocation. 293 [1] The prefix assigned to the IANA, 2001:0000::/23, is for 294 assignment for testing, experimental and trial usage by IANA 295 [RFC2928]. 297 [2] 2001:0DB8::/32 has been assigned as a NON-ROUTABLE 298 range to be used for documentation purpose [RFC3849]. 300 [3] 2002::/16 is reserved for use in 6to4 deployments [RFC3056] 302 [4] 3FFE::/16 is an experimental allocation to the 6BONE [RFC2471]. 303 This prefix will be returned to the unassigned address pool on 304 the 6th June 2006 [RFC3701]. 306 References: 308 [RFC2471] Hinden, R., R. Fink, J. Postel, "IPv6 Testing Address 309 Allocation", RFC2471, December 1998. 311 [RFC2928] Hinden, R., Deering, S., Fink, R., Hain, T., , "Initial 312 IPv6 Sub-TLA ID Assignments", RFC2928, September 2000. 314 [RFC3056] Carpenter, B., K. Moore, "Connection of IPv6 Domains via 315 IPv4 Clouds without Explicit Tunnels", RFC 3056, February 316 2001. 318 [RFC3513] Hinden, R., "IP Version 6 Addressing Architecture", 319 RFC3513, April 2003. 321 [RFC3701] Fink, R., "6Bone (IPv6 Testing Address Allocation) 322 Phaseout", RFC 3701, March 2004. 324 [RFC3849] Huston, G., A. Lord, P. Smith, "IPv6 Address Prefix 325 Reserved for Documentation", RFC 3849, July 2004. 327 ----------------------------------------------------- 329 Figure 2 331 3.1 Notes on Proposed Format Changes to the Registry 333 o The current registry name "iana-ipv6-tla-assignments" should be 334 renamed to "iana-ipv6-unicast-address-assignments". 336 o The title of the registry has been altered to remove the reference 337 to "TOP LEVEL AGGREGATION IDENTIFIER". 339 o The TLA and Sub-TLA identifier assignments have been rolled into a 340 single set of address prefixes and their assignment. 342 o The text commentary at the start of the registry contents has been 343 removed. 345 o Binary value notation of the address prefixes has been removed. 347 o Further commentary on assignments, such as the planned phase out 348 of the 6BONE, is placed in a footnote. 350 o The registry continuation lines using ellipsis notation have been 351 removed. 353 o Only assigned addresses are listed. All unassigned addresses, 354 marked in the original IANA registry with the assignment note of 355 "(future assignment)" have been removed, as has the entry marked 356 as "reserved *)". 358 o Address assignments are listed using prefix size notation of the 359 actual allocation, rather than reporting the allocation in 360 sub-units of /23 prefixes. 362 o The date of the IANA action includes the day of the month as well 363 as the month and year. 365 4. IANA Considerations 367 IANA is advised to adopt these formats for the IPv6 address registry 368 and the IPv6 Global Unicast address registry. 370 5. Security Considerations 372 Security of the Internet's routing system relies on the ability to 373 authenticate an assertion of unique control of an address block. 374 Measures to authenticate such assertions rely on validation that the 375 address block forms part of an existing allocated address block, and 376 that there is a trustable reference from the IANA address registry to 377 the references Regional Internet Registry (RIR), and a trustable 378 reference from the RIR's registry to a Local Internet Registry or end 379 user Internet Service Provider. 381 The proposed format for the IANA registry is a small step towards the 382 creation of a registry that can be used as a trust point for 383 commencing a chain of address validation. Consideration should be 384 given to IANA registry publication formats that are machine 385 parseable, and also the use of file signatures and associated 386 certificate mechanisms to allow applications to confirm that the 387 registry contents are current, and that they have been published by 388 the IANA. 390 6. Acknowledgements 392 This document was prepared with the assistance of Kurt Lindqvist, 393 Thomas Narten, Paul Wilson, David Kessens, Bob Hinden and Brian 394 Haberman. Pekka Savola, Brian Carpenter, Christian Huitema and 395 Michael Patton provided helpful review comments. 397 7. References 399 7.1 Normative References 401 [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 402 (IPv6) Addressing Architecture", RFC 3513, April 2003. 404 7.2 Informative References 406 [iana-ipv6-registry] 407 IANA, "IANA IPv6 Address Registry", December 2004. 409 [iana-ipv6-tla] 410 IANA, "IANA Registry of IPv6 Top Level Aggregation 411 Identifier Assignments", December 2004. 413 Author's Address 415 Geoff Huston 416 Asia Pacific Network Information Centre 418 EMail: gih@apnic.net 419 URI: http://www.apnic.net 421 Appendix A. Draft Notes 423 [This section not for RFC publication] 425 This memo has been prepared as part of the activities of an ad hoc 426 advisory committee to advise the IAB on a number of matters relating 427 to IPv6. It is proposed that the note be published as an Internet 428 Standards action for IPv6 as a BCP. 430 As noted in the Security Considerations Section this is a step in the 431 direction of updating the IANA address registry to be a seed trust 432 point in the operation of validating addresses. It is noted that 433 further study is appropriate to determine what forms of additional 434 information and formats should be published to allow systems to use 435 this data in a trustworthy manner. 437 The format provided here could be provided through the use of a base 438 registry format using an XML scheme. Such an XML scheme for IPv6 439 registry specification is not considered in this document, but is a 440 topic that is recommended for further study. 442 Intellectual Property Statement 444 The IETF takes no position regarding the validity or scope of any 445 Intellectual Property Rights or other rights that might be claimed to 446 pertain to the implementation or use of the technology described in 447 this document or the extent to which any license under such rights 448 might or might not be available; nor does it represent that it has 449 made any independent effort to identify any such rights. Information 450 on the procedures with respect to rights in RFC documents can be 451 found in BCP 78 and BCP 79. 453 Copies of IPR disclosures made to the IETF Secretariat and any 454 assurances of licenses to be made available, or the result of an 455 attempt made to obtain a general license or permission for the use of 456 such proprietary rights by implementers or users of this 457 specification can be obtained from the IETF on-line IPR repository at 458 http://www.ietf.org/ipr. 460 The IETF invites any interested party to bring to its attention any 461 copyrights, patents or patent applications, or other proprietary 462 rights that may cover technology that may be required to implement 463 this standard. Please address the information to the IETF at 464 ietf-ipr@ietf.org. 466 Disclaimer of Validity 468 This document and the information contained herein are provided on an 469 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 470 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 471 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 472 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 473 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 474 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 476 Copyright Statement 478 Copyright (C) The Internet Society (2005). This document is subject 479 to the rights, licenses and restrictions contained in BCP 78, and 480 except as set forth therein, the authors retain all their rights. 482 Acknowledgment 484 Funding for the RFC Editor function is currently provided by the 485 Internet Society.