idnits 2.17.1 draft-ietf-sidr-iana-objects-03.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 : ---------------------------------------------------------------------------- == There are 8 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 5 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 == There are 3 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. == There are 2 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 11, 2011) is 4727 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) == Unused Reference: 'RFC0919' is defined on line 337, but no explicit reference was found in the text == Unused Reference: 'RFC0922' is defined on line 340, but no explicit reference was found in the text == Unused Reference: 'RFC1112' is defined on line 343, but no explicit reference was found in the text == Unused Reference: 'RFC1122' is defined on line 346, but no explicit reference was found in the text == Unused Reference: 'RFC2544' is defined on line 359, but no explicit reference was found in the text == Unused Reference: 'RFC3879' is defined on line 375, but no explicit reference was found in the text == Unused Reference: 'RFC3927' is defined on line 378, but no explicit reference was found in the text == Unused Reference: 'RFC4843' is defined on line 392, but no explicit reference was found in the text == Unused Reference: 'RFC5737' is defined on line 406, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-sidr-arch-12 ** Downref: Normative reference to an Informational draft: draft-ietf-sidr-arch (ref. 'I-D.ietf-sidr-arch') == Outdated reference: A later version (-16) exists of draft-ietf-sidr-ghostbusters-03 ** Downref: Normative reference to an Informational draft: draft-ietf-sidr-roa-validation (ref. 'I-D.ietf-sidr-roa-validation') == Outdated reference: A later version (-16) exists of draft-ietf-sidr-rpki-manifests-11 == Outdated reference: A later version (-08) exists of draft-ietf-sidr-ltamgmt-00 == Outdated reference: A later version (-06) exists of draft-ietf-sidr-usecases-01 -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 3068 (Obsoleted by RFC 7526) -- Obsolete informational reference (is this intentional?): RFC 4843 (Obsoleted by RFC 7343) -- Obsolete informational reference (is this intentional?): RFC 5735 (Obsoleted by RFC 6890) -- Obsolete informational reference (is this intentional?): RFC 5736 (Obsoleted by RFC 6890) Summary: 2 errors (**), 0 flaws (~~), 19 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Manderson 3 Internet-Draft L. Vegoda 4 Intended status: Standards Track ICANN 5 Expires: November 12, 2011 S. Kent 6 BBN 7 May 11, 2011 9 RPKI Objects issued by IANA 10 draft-ietf-sidr-iana-objects-03.txt 12 Abstract 14 This document provides specific direction to IANA as to the Resource 15 Public Key Infrastructure (RPKI) objects it should issue. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on November 12, 2011. 34 Copyright Notice 36 Copyright (c) 2011 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 52 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 3. Required Reading . . . . . . . . . . . . . . . . . . . . . . . 5 54 4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6 55 5. Reserved Resources . . . . . . . . . . . . . . . . . . . . . . 7 56 6. Unallocated Resources . . . . . . . . . . . . . . . . . . . . 8 57 7. Special Purpose Registry Resources . . . . . . . . . . . . . . 9 58 8. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . 10 59 9. Informational Objects . . . . . . . . . . . . . . . . . . . . 11 60 10. Certificates and CRLs . . . . . . . . . . . . . . . . . . . . 12 61 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 62 12. Security Considerations . . . . . . . . . . . . . . . . . . . 14 63 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 64 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 65 14.1. Normative References . . . . . . . . . . . . . . . . . . 16 66 14.2. Informative References . . . . . . . . . . . . . . . . . 16 67 Appendix A. IANA Reserved IPv4 Address Blocks . . . . . . . . . . 19 68 Appendix B. IANA Reserved IPv6 Address Blocks . . . . . . . . . . 20 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 71 1. Requirements Notation 73 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 74 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 75 document are to be interpreted as described in [RFC2119]. 77 2. Introduction 79 An Infrastructure to Support Secure Internet Routing 80 [I-D.ietf-sidr-arch] directs IANA [RFC2860] to issue Resource Public 81 Key Infrastructure (RPKI) objects for which it is authoritative. 82 This document describes the objects IANA will issue. If IANA is 83 directed to issue additional RPKI objects in future, this document 84 will be revised and a new version issued. 86 The signed objects described here that IANA will issue are the 87 unallocated, reserved, special use IPv4 and IPv6 address blocks, and 88 the unallocated and reserved Autonomous System numbers. These number 89 resources are managed by IANA for the IETF, and thus IANA bears the 90 responsibility of issuing the corresponding RPKI objects. The reader 91 is encouraged to consider the technical effects on the public routing 92 system of the signed object issuance proposed for IANA in this 93 document. 95 This document does not deal with BGP [RFC4271] routing systems as 96 those are under the policy controls of the organizations that operate 97 them. Readers are directed to Local Trust Anchor Management for the 98 Resource Public Key Infrastructure [I-D.ietf-sidr-ltamgmt] for a 99 description of how to locally override IANA issued objects, e.g. to 100 enable use of unallocated, reserved, and special use IPv4 and IPv6 101 address blocks in a local context. 103 The direction to IANA contained herein follows the ideal that it 104 should represent the ideal technical behavior for registry, and 105 related registry, actions. 107 3. Required Reading 109 Readers should be familiar with the RPKI, the RPKI Repository 110 Structure, and the various RPKI objects, uses and interpretations 111 described in the following: [I-D.ietf-sidr-arch], 112 [I-D.ietf-sidr-res-certs], [I-D.ietf-sidr-roa-format], 113 [I-D.ietf-sidr-ghostbusters], [I-D.ietf-sidr-ltamgmt], 114 [I-D.ietf-sidr-roa-validation], [I-D.ietf-sidr-usecases], 115 [I-D.ietf-sidr-cp], and [I-D.ietf-sidr-rpki-manifests]. 117 NOTE: The addresses used in this document are not example addresses 118 therefore they are not compliant with [RFC3849], [RFC5735], and 119 [RFC5771]. This is intentional as the practices described in this 120 document are directed to specific instances of real world addresses. 122 4. Definitions 124 Internet Number Resources (INR): The number identifiers for IPv4 125 [RFC0791] and IPv6 [RFC2460] addresses, and for Autonomous Systems. 127 IANA: Internet Assigned Numbers Authority (a traditional name, used 128 here to refer to the technical team making and publishing the 129 assignments of Internet protocol technical parameters). The 130 technical team of IANA is currently a part of ICANN [RFC2860]. 132 RPKI: Resource Public Key Infrastructure. A Public Key 133 Infrastructure designed to provide a secure basis for assertions 134 about holdings of Internet numeric resources. Certificates issued 135 under the RPKI contain additional attributes that identify IPv4, 136 IPv6, and Autonomous System Number (ASN) resources 137 [I-D.ietf-sidr-arch]. 139 ROA: Route Origination Authorization. A ROA is an RPKI object that 140 enables the holder of the address prefix to specify an AS that is 141 permitted to originate (in BGP) routes for that prefix 142 [I-D.ietf-sidr-roa-format]. 144 AS0 ROA: A ROA containing a value of 0 in the ASID field. Validation 145 of Route Origination using the Resource Certificate PKI and ROAs 146 [I-D.ietf-sidr-roa-validation] states "A ROA with a subject of AS0 147 (AS0-ROA) is an attestation by the holder of a prefix that the prefix 148 described in the ROA, and any more specific prefix, should not be 149 used in a routing context." 151 "Not intended to be (publicly) routed": This phrase refers to 152 prefixes that are not meant to be represented in the global Internet 153 routing table (for example 192.168/16, [RFC1918]). 155 5. Reserved Resources 157 Reserved IPv4 and IPv6 resources are held back for various reasons by 158 IETF action. Generally such resources are not intended to be 159 globally routed. An example of such a reservation is 127.0.0.0/8 160 [RFC5735]. See Appendix A (Appendix A) and B (Appendix B) for IANA 161 reserved resources. 163 IANA SHOULD issue an AS0 ROA for all reserved IPv4 and IPv6 resources 164 not intended to be routed. The selection of the [RFC2119] 165 terminology is intentional as there may be situations where the ASO 166 ROA is removed or not issued prior to an IANA registry action. It is 167 not appropriate to place IANA into a situation where, through normal 168 interal operations, its bahavior contradicts IETF standards. 170 There are a small number of reserved resources that are intended to 171 be routed, for example 192.88.99.0/24 [RFC3068]. See Appendix A 172 (Appendix A) and B (Appendix B) for IANA reserved resources. 174 IANA MUST NOT issue any ROAs (AS0 or otherwise) for reserved 175 resources that are expected to be globally routed. 177 6. Unallocated Resources 179 Internet Number Resources that have not yet been allocated for 180 special purposes [RFC5736], to Regional Internet Registries (RIRs), 181 or to others are considered as not intended to be globally routed. 183 IANA SHOULD issue an AS0 ROA for all Unallocated Resources. The 184 selection of the [RFC2119] terminology is intentional as there may be 185 situations where the ASO ROA is removed or not issued prior to an 186 IANA registry action. It is not appropriate to place IANA into a 187 situation where, through normal interal operations, its bahavior 188 contradicts IETF standards. 190 7. Special Purpose Registry Resources 192 Special Registry Resources [RFC5736] fall into one of two categories 193 in terms of routing. Either the resource is intended to be seen in 194 the global Internet routing table in some fashion, or it isn't. An 195 example of a special purpose registry INR that is intended for global 196 routing is 2001:0000::/32 [RFC4380]. An example of an INR not 197 intended to be seen would be 2001:002::/48 [RFC5180]. 199 IANA MUST NOT issue any ROAs (AS0 or otherwise) for Special Purpose 200 Registry Resources that are intended to be globally routed. 202 IANA SHOULD issue an AS0 ROA for Special Purpose Registry Resources 203 that are not intended to be globally routed. 205 8. Multicast 207 Within the IPv4 Multicast [RFC5771] and IPv6 Multicast [RFC4291] 208 registries there are a number of Multicast registrations that are not 209 intended to be globally routed. 211 IANA MUST issue an AS0 ROA covering the following IPv4 and IPv6 212 multicast INRs: 214 IPv4: 215 - Local Network Control Block 216 224.0.0.0 - 224.0.0.255 (224.0.0/24) 217 - IANA Reserved portions of RESERVED 218 224.1.0.0-224.1.255.255 (224.1/16) 219 - RESERVED 220 224.5.0.0-224.251.255.255 (251 /16s) 221 225.0.0.0-231.255.255.255 (7 /8s) 223 IPv6: 224 - Node-Local Scope Multicast Addresses 225 - Link-Local Scope Multicast Addresses 227 IANA MUST NOT issue any ROAs (AS0 or otherwise) for any other 228 multicast addresses unless directed by an IESG approved standards 229 track document with an appropriate IANA Considerations section. 231 9. Informational Objects 233 One informational object that can exist at a publication point of an 234 RPKI repository is the Ghostbusters Record 235 [I-D.ietf-sidr-ghostbusters]. 237 IANA MUST issue a ghostbusters object appropriate in content for the 238 resources IANA maintains. 240 10. Certificates and CRLs 242 Before IANA can issue a ROA it MUST first establish an RPKI 243 Certification Authority (CA) that covers unallocated, reserved, and 244 special use INRs. A CA that covers these INRs MUST contain contain 245 RFC 3379 extensions [RFC3779] for those corresponding number 246 resources in its Certificate. This CA MUST issue single-use End 247 Entity (EE) certificates for each ROA that it generates. The EE 248 certificate will conform to the Resource Certificate Profile 249 [I-D.ietf-sidr-res-certs] and the additional constraints specified in 250 [I-D.ietf-sidr-roa-format]. IANA MUST maintain a publication point 251 for this CA's use and MIUST publish manifests 252 [I-D.ietf-sidr-rpki-manifests] (with its corresponding EE 253 certificate) for this publication point. IANA MUST issue a 254 Certificate Revocation List (CRL) under this CA certificate for the 255 EE certificates noted above. All objects issued by this CA will 256 conform to the RPKI Certificate Policy [I-D.ietf-sidr-cp]. 258 11. IANA Considerations 260 This document directs IANA to issue, or refrain from issuing, the 261 specific RPKI objects described here for the current set of reserved, 262 unallocated, and special registry Internet Number Resources. Further 263 IANA MUST notify all other INR registries that RPKI objects have been 264 issued for the Internet Number Resources described in this document 265 to avoid the potential for issuance of duplicate objects that might 266 confuse relying parties. 268 12. Security Considerations 270 This document does not alter the security profile of the RPKI from 271 that already discussed in SIDR-WG documents. 273 13. Acknowledgements 275 The authors acknowledge Dave Meyer for helpful direction with regard 276 to multicast assignments. 278 14. References 280 14.1. Normative References 282 [I-D.ietf-sidr-arch] 283 Lepinski, M. and S. Kent, "An Infrastructure to Support 284 Secure Internet Routing", draft-ietf-sidr-arch-12 (work in 285 progress), February 2011. 287 [I-D.ietf-sidr-cp] 288 Kent, S., Kong, D., Seo, K., and R. Watro, "Certificate 289 Policy (CP) for the Resource PKI (RPKI", 290 draft-ietf-sidr-cp-17 (work in progress), April 2011. 292 [I-D.ietf-sidr-ghostbusters] 293 Bush, R., "The RPKI Ghostbusters Record", 294 draft-ietf-sidr-ghostbusters-03 (work in progress), 295 March 2011. 297 [I-D.ietf-sidr-res-certs] 298 Huston, G., Michaelson, G., and R. Loomans, "A Profile for 299 X.509 PKIX Resource Certificates", 300 draft-ietf-sidr-res-certs-22 (work in progress), May 2011. 302 [I-D.ietf-sidr-roa-format] 303 Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 304 Origin Authorizations (ROAs)", 305 draft-ietf-sidr-roa-format-12 (work in progress), 306 May 2011. 308 [I-D.ietf-sidr-roa-validation] 309 Huston, G. and G. Michaelson, "Validation of Route 310 Origination using the Resource Certificate PKI and ROAs", 311 draft-ietf-sidr-roa-validation-10 (work in progress), 312 November 2010. 314 [I-D.ietf-sidr-rpki-manifests] 315 Austein, R., Huston, G., Kent, S., and M. Lepinski, 316 "Manifests for the Resource Public Key Infrastructure", 317 draft-ietf-sidr-rpki-manifests-11 (work in progress), 318 May 2011. 320 14.2. Informative References 322 [I-D.ietf-sidr-ltamgmt] 323 Kent, S. and M. Reynolds, "Local Trust Anchor Management 324 for the Resource Public Key Infrastructure", 325 draft-ietf-sidr-ltamgmt-00 (work in progress), 326 November 2010. 328 [I-D.ietf-sidr-usecases] 329 Manderson, T., Sriram, K., and R. White, "Use Cases and 330 interpretation of RPKI objects for issuers and relying 331 parties", draft-ietf-sidr-usecases-01 (work in progress), 332 December 2010. 334 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 335 September 1981. 337 [RFC0919] Mogul, J., "Broadcasting Internet Datagrams", STD 5, 338 RFC 919, October 1984. 340 [RFC0922] Mogul, J., "Broadcasting Internet datagrams in the 341 presence of subnets", STD 5, RFC 922, October 1984. 343 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 344 RFC 1112, August 1989. 346 [RFC1122] Braden, R., "Requirements for Internet Hosts - 347 Communication Layers", STD 3, RFC 1122, October 1989. 349 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 350 E. Lear, "Address Allocation for Private Internets", 351 BCP 5, RFC 1918, February 1996. 353 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 354 Requirement Levels", BCP 14, RFC 2119, March 1997. 356 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 357 (IPv6) Specification", RFC 2460, December 1998. 359 [RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for 360 Network Interconnect Devices", RFC 2544, March 1999. 362 [RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of 363 Understanding Concerning the Technical Work of the 364 Internet Assigned Numbers Authority", RFC 2860, June 2000. 366 [RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", 367 RFC 3068, June 2001. 369 [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP 370 Addresses and AS Identifiers", RFC 3779, June 2004. 372 [RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix 373 Reserved for Documentation", RFC 3849, July 2004. 375 [RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local 376 Addresses", RFC 3879, September 2004. 378 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 379 Configuration of IPv4 Link-Local Addresses", RFC 3927, 380 May 2005. 382 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 383 Protocol 4 (BGP-4)", RFC 4271, January 2006. 385 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 386 Architecture", RFC 4291, February 2006. 388 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 389 Network Address Translations (NATs)", RFC 4380, 390 February 2006. 392 [RFC4843] Nikander, P., Laganier, J., and F. Dupont, "An IPv6 Prefix 393 for Overlay Routable Cryptographic Hash Identifiers 394 (ORCHID)", RFC 4843, April 2007. 396 [RFC5180] Popoviciu, C., Hamza, A., Van de Velde, G., and D. 397 Dugatkin, "IPv6 Benchmarking Methodology for Network 398 Interconnect Devices", RFC 5180, May 2008. 400 [RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", 401 BCP 153, RFC 5735, January 2010. 403 [RFC5736] Huston, G., Cotton, M., and L. Vegoda, "IANA IPv4 Special 404 Purpose Address Registry", RFC 5736, January 2010. 406 [RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks 407 Reserved for Documentation", RFC 5737, January 2010. 409 [RFC5771] Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for 410 IPv4 Multicast Address Assignments", BCP 51, RFC 5771, 411 March 2010. 413 Appendix A. IANA Reserved IPv4 Address Blocks 415 This list of Address Space and RFCs was correct at the time of 416 writing 418 IPv4 Address Blocks and the RFCs which direct IANA to Reserve them 420 +--------------------+------------------------------------+---------+ 421 | Prefix | RFC | TBR | 422 +--------------------+------------------------------------+---------+ 423 | 0.0.0.0/8 | RFC1122, Section 3.2.1.3 | No | 424 | | | | 425 | 10.0.0.0/8 | RFC1918 | No | 426 | | | | 427 | 127.0.0.0/8 | RFC1122, Section 3.2.1.3 | No | 428 | | | | 429 | 169.254.0.0/16 | RFC3927 | No | 430 | | | | 431 | 172.16.0.0/12 | RFC1918 | No | 432 | | | | 433 | 192.0.0.0/24 | RFC5736 | Various | 434 | | | | 435 | 192.0.2.0/24 | RFC5737 | No | 436 | | | | 437 | 192.88.99.0/24 | RFC3068 | Yes | 438 | | | | 439 | 192.168.0.0/16 | RFC1918 | No | 440 | | | | 441 | 198.18.0.0/15 | RFC2544 | No | 442 | | | | 443 | 198.51.100.0/24 | RFC5737 | No | 444 | | | | 445 | 203.0.113.0/24 | RFC5737 | No | 446 | | | | 447 | 224.0.0.0/4 | RFC5771 | No | 448 | | | | 449 | 240.0.0.0/4 | RFC1112, Section 4 | No | 450 | | | | 451 | 255.255.255.255/32 | RFC919, Section 7 and RFC922, | No | 452 | | Section 7 | | 453 +--------------------+------------------------------------+---------+ 455 TBR: To Be Routed, the intention of the RFC pertaining to the address 456 block. 458 Table 1 460 Appendix B. IANA Reserved IPv6 Address Blocks 462 This list of Address Space and RFCs was correct at the time of 463 writing 465 IPv6 Address Blocks and the RFCs which direct IANA to Reserve them 467 +----------------+---------+-----+ 468 | Prefix | RFC | TBR | 469 +----------------+---------+-----+ 470 | 0000::/8 | RFC4291 | No | 471 | | | | 472 | 0100::/8 | RFC4291 | No | 473 | | | | 474 | 0200::/7 | RFC4291 | No | 475 | | | | 476 | 0400::/6 | RFC4291 | No | 477 | | | | 478 | 0800::/5 | RFC4291 | No | 479 | | | | 480 | 1000::/4 | RFC4291 | No | 481 | | | | 482 | 4000::/3 | RFC4291 | No | 483 | | | | 484 | 6000::/3 | RFC4291 | No | 485 | | | | 486 | 8000::/3 | RFC4291 | No | 487 | | | | 488 | A000::/3 | RFC4291 | No | 489 | | | | 490 | C000::/3 | RFC4291 | No | 491 | | | | 492 | E000::/4 | RFC4291 | No | 493 | | | | 494 | F000::/5 | RFC4291 | No | 495 | | | | 496 | F800::/6 | RFC4291 | No | 497 | | | | 498 | FC00::/7 | RFC4193 | No | 499 | | | | 500 | FE00::/9 | RFC4291 | No | 501 | | | | 502 | FE80::/10 | RFC4291 | No | 503 | | | | 504 | FEC0::/10 | RFC3879 | No | 505 | | | | 506 | FF00::/8 | RFC4291 | No | 507 | | | | 508 | 2001:0002::/48 | RFC5180 | No | 509 | | | | 510 | 2001:10::/28 | RFC4843 | No | 511 +----------------+---------+-----+ 513 TBR: To Be Routed, the intention of the RFC pertaining to the address 514 block. 516 Table 2 518 Authors' Addresses 520 Terry Manderson 521 ICANN 523 Email: terry.manderson@icann.org 525 Leo Vegoda 526 ICANN 528 Email: leo.vegoda@icann.org 530 Steve Kent 531 BBN 533 Email: kent@bbn.com