diff options
Diffstat (limited to 'doc/rfc/rfc6491.txt')
| -rw-r--r-- | doc/rfc/rfc6491.txt | 675 |
1 files changed, 675 insertions, 0 deletions
diff --git a/doc/rfc/rfc6491.txt b/doc/rfc/rfc6491.txt new file mode 100644 index 0000000..a44465c --- /dev/null +++ b/doc/rfc/rfc6491.txt @@ -0,0 +1,675 @@ + + + + + + +Internet Engineering Task Force (IETF) T. Manderson +Request for Comments: 6491 L. Vegoda +Category: Standards Track ICANN +ISSN: 2070-1721 S. Kent + BBN + February 2012 + + + Resource Public Key Infrastructure (RPKI) Objects Issued by IANA + +Abstract + + This document provides specific direction to IANA as to the Resource + Public Key Infrastructure (RPKI) objects it should issue. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6491. + +Copyright Notice + + Copyright (c) 2012 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + + + + + + + +Manderson, et al. Standards Track [Page 1] + +RFC 6491 IANA RPKI Objects February 2012 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 + 3. Required Reading . . . . . . . . . . . . . . . . . . . . . . . 3 + 4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 5. Reserved Resources . . . . . . . . . . . . . . . . . . . . . . 4 + 6. Unallocated Resources . . . . . . . . . . . . . . . . . . . . 4 + 7. Special Purpose Registry Resources . . . . . . . . . . . . . . 4 + 8. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 9. Informational Objects . . . . . . . . . . . . . . . . . . . . 5 + 10. Certificates and Certificate Revocation Lists (CRLs) . . . . . 5 + 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 + 12. Security Considerations . . . . . . . . . . . . . . . . . . . 6 + 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 + 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 14.1. Normative References . . . . . . . . . . . . . . . . . . 6 + 14.2. Informative References . . . . . . . . . . . . . . . . . 7 + Appendix A. IANA Reserved IPv4 Address Blocks . . . . . . . . . . 10 + Appendix B. IANA Reserved IPv6 Address Blocks . . . . . . . . . . 11 + +1. Introduction + + "An Infrastructure to Support Secure Internet Routing" [RFC6480] + directs IANA [RFC2860] to issue Resource Public Key Infrastructure + (RPKI) objects for which it is authoritative. This document + describes the objects IANA will issue. If IANA is directed to issue + additional RPKI objects in future, this document will be revised and + a new version issued. + + The signed objects described here that IANA will issue are the + unallocated, reserved, special use IPv4 and IPv6 address blocks, and + the unallocated and reserved Autonomous System numbers. These number + resources are managed by IANA for the IETF; thus, IANA bears the + responsibility of issuing the corresponding RPKI objects. The reader + is encouraged to consider the technical effects on the public routing + system of the signed object issuance proposed for IANA in this + document. + + This document does not deal with BGP [RFC4271] routing systems, as + those are under the policy controls of the organizations that operate + them. Readers are directed to "Local Trust Anchor Management for the + Resource Public Key Infrastructure" [TA-MGMT] for a description of + how to locally override IANA issued objects, e.g., to enable use of + unallocated, reserved, and special use IPv4 and IPv6 address blocks + in a local context. + + + + + +Manderson, et al. Standards Track [Page 2] + +RFC 6491 IANA RPKI Objects February 2012 + + + The direction to IANA contained herein follows the ideal that it + should represent the ideal technical behavior for registry and + related registry actions. + +2. Requirements Notation + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + +3. Required Reading + + Readers should be familiar with the RPKI, the RPKI repository + structure, and the various RPKI objects, uses, and interpretations + described in the following: [RFC6480], [RFC6487], [RFC6482], + [RFC6493], [TA-MGMT], [RFC6483], [RPKI-USE], [RFC6484], and + [RFC6486]. + + Note: The addresses used in this document are not example addresses; + therefore, they are not compliant with [RFC3849], [RFC5735], and + [RFC5771]. This is intentional, as the practices described in this + document are directed to specific instances of real world addresses. + +4. Definitions + + Internet Number Resources (INR): The number identifiers for IPv4 + [RFC0791] and IPv6 [RFC2460] addresses, and for Autonomous Systems + (ASes). + + IANA: Internet Assigned Numbers Authority (a traditional name, used + here to refer to the technical team making and publishing the + assignments of Internet protocol technical parameters). The + technical team of IANA is currently a part of ICANN [RFC2860]. + + RPKI: Resource Public Key Infrastructure. A Public Key + Infrastructure designed to provide a secure basis for assertions + about holdings of Internet number resources. Certificates issued + under the RPKI contain additional attributes that identify IPv4, + IPv6, and Autonomous System number resources [RFC6480]. + + ROA: Route Origination Authorization. A ROA is an RPKI object that + enables the holder of the address prefix to specify an AS that is + permitted to originate (in BGP) routes for that prefix [RFC6482]. + + AS 0 ROA: A ROA containing a value of 0 in the ASID field. + "Validation of Route Origination Using the Resource Certificate + Public Key Infrastructure (PKI) and Route Origination Authorizations + (ROAs)" [RFC6483] states "A ROA with a subject of AS 0 (AS 0 ROA) is + + + +Manderson, et al. Standards Track [Page 3] + +RFC 6491 IANA RPKI Objects February 2012 + + + an attestation by the holder of a prefix that the prefix described in + the ROA, and any more specific prefix, should not be used in a + routing context." + + "Not intended to be (publicly) routed": This phrase refers to + prefixes that are not meant to be represented in the global Internet + routing table (for example 192.168/16 [RFC1918]). + +5. Reserved Resources + + Reserved IPv4 and IPv6 resources are held back for various reasons by + IETF action. Generally, such resources are not intended to be + globally routed. An example of such a reservation is 127.0.0.0/8 + [RFC5735]. See Appendixes A and B for IANA reserved resources. + + IANA SHOULD issue an AS 0 ROA for all reserved IPv4 and IPv6 + resources not intended to be routed. The selection of the [RFC2119] + terminology is intentional as there may be situations where the AS 0 + ROA is removed or not issued prior to an IANA registry action. It is + not appropriate to place IANA into a situation where, through normal + internal operations, its behavior contradicts IETF standards. + + There are a small number of reserved resources that are intended to + be routed, for example 192.88.99.0/24 [RFC3068]. See Appendixes A + and B for IANA reserved resources. + + IANA MUST NOT issue any ROAs (AS 0 or otherwise) for reserved + resources that are expected to be globally routed. + +6. Unallocated Resources + + Internet Number Resources that have not yet been allocated for + special purposes [RFC5736], to Regional Internet Registries (RIRs), + or to others are considered as not intended to be globally routed. + + IANA SHOULD issue an AS 0 ROA for all Unallocated Resources. The + selection of the [RFC2119] terminology is intentional as there may be + situations where the AS 0 ROA is removed or not issued prior to an + IANA registry action. It is not appropriate to place IANA into a + situation where, through normal internal operations, its behavior + contradicts IETF standards. + +7. Special Purpose Registry Resources + + Special Registry Resources [RFC5736] fall into one of two categories + in terms of routing. Either the resource is intended to be seen in + the global Internet routing table in some fashion, or it isn't. An + example of a Special Registry Resources INR that is intended for + + + +Manderson, et al. Standards Track [Page 4] + +RFC 6491 IANA RPKI Objects February 2012 + + + global routing is 2001::/32 [RFC4380]. An example of an INR not + intended to be seen would be 2001:002::/48 [RFC5180]. + + IANA MUST NOT issue any ROAs (AS 0 or otherwise) for Special Purpose + Registry Resources that are intended to be globally routed. + + IANA SHOULD issue an AS 0 ROA for Special Purpose Registry Resources + that are not intended to be globally routed. + +8. Multicast + + Within the IPv4 multicast [RFC5771] and IPv6 multicast [RFC4291] + registries there are a number of Multicast registrations that are not + intended to be globally routed. + + IANA MUST issue an AS 0 ROA covering the following IPv4 and IPv6 + multicast INRs: + + IPv4: + - Local Network Control Block + 224.0.0.0 - 224.0.0.255 (224.0.0/24) + - IANA Reserved portions of RESERVED + 224.1.0.0-224.1.255.255 (224.1/16) + - RESERVED + 224.5.0.0-224.251.255.255 (251 /16s) + 225.0.0.0-231.255.255.255 (7 /8s) + + IPv6: + - Node-Local Scope Multicast Addresses + - Link-Local Scope Multicast Addresses + + IANA MUST NOT issue any ROAs (AS 0 or otherwise) for any other + multicast addresses unless directed by an IESG-approved Standards + Track document with an appropriate IANA Considerations section. + +9. Informational Objects + + One informational object that can exist at a publication point of an + RPKI repository is the Ghostbusters Record [RFC6493]. + + IANA MUST issue a ghostbusters object appropriate in content for the + resources IANA maintains. + +10. Certificates and Certificate Revocation Lists (CRLs) + + Before IANA can issue a ROA, it MUST first establish an RPKI + Certification Authority (CA) that covers unallocated, reserved, and + special use INRs. A CA that covers these INRs MUST contain RFC 3379 + + + +Manderson, et al. Standards Track [Page 5] + +RFC 6491 IANA RPKI Objects February 2012 + + + extensions [RFC3779] for those corresponding number resources in its + certificate. This CA MUST issue single-use end-entity (EE) + certificates for each ROA that it generates. The EE certificate will + conform to the Resource Certificate Profile [RFC6487] and the + additional constraints specified in [RFC6482]. IANA MUST maintain a + publication point for this CA's use and MUST publish manifests + [RFC6486] (with its corresponding EE certificate) for this + publication point. IANA MUST issue a CRL under this CA certificate + for the EE certificates noted above. All objects issued by this CA + will conform to the RPKI Certificate Policy [RFC6484]. + +11. IANA Considerations + + This document directs IANA to issue, or refrain from issuing, the + specific RPKI objects described here for the current set of reserved, + unallocated, and special registry Internet Number Resources. + Further, IANA MUST notify all other INR registries that RPKI objects + have been issued for the Internet Number Resources described in this + document to avoid the potential for issuance of duplicate objects + that might confuse relying parties. + +12. Security Considerations + + This document does not alter the security profile of the RPKI from + that already discussed in SIDR WG documents. + +13. Acknowledgements + + The authors acknowledge Dave Meyer for helpful direction with regard + to multicast assignments. + +14. References + +14.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support + Secure Internet Routing", RFC 6480, February 2012. + + [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route + Origin Authorizations (ROAs)", RFC 6482, February 2012. + + [RFC6483] Huston, G. and G. Michaelson, "Validation of Route + Origination Using the Resource Certificate Public Key + Infrastructure (PKI) and Route Origin Authorizations + (ROAs)", RFC 6483, February 2012. + + + +Manderson, et al. Standards Track [Page 6] + +RFC 6491 IANA RPKI Objects February 2012 + + + [RFC6484] Kent, S., Kong, D., Seo, K., and R. Watro, "Certificate + Policy (CP) for the Resource Public Key Infrastructure + (RPKI)", BCP 173, RFC 6484, February 2012. + + [RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, + "Manifests for the Resource Public Key Infrastructure + (RPKI)", RFC 6486, February 2012. + + [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile + for X.509 PKIX Resource Certificates", RFC 6487, + February 2012. + + [RFC6493] Bush, R., "The Resource Public Key Infrastructure (RPKI) + Ghostbusters Record", RFC 6493, February 2012. + +14.2. Informative References + + [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, + September 1981. + + [RFC0919] Mogul, J., "Broadcasting Internet Datagrams", STD 5, + RFC 919, October 1984. + + [RFC0922] Mogul, J., "Broadcasting Internet datagrams in the + presence of subnets", STD 5, RFC 922, October 1984. + + [RFC1112] Deering, S., "Host extensions for IP multicasting", + STD 5, RFC 1112, August 1989. + + [RFC1122] Braden, R., "Requirements for Internet Hosts - + Communication Layers", STD 3, RFC 1122, October 1989. + + [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., + and E. Lear, "Address Allocation for Private Internets", + BCP 5, RFC 1918, February 1996. + + [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 + (IPv6) Specification", RFC 2460, December 1998. + + [RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for + Network Interconnect Devices", RFC 2544, March 1999. + + [RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of + Understanding Concerning the Technical Work of the + Internet Assigned Numbers Authority", RFC 2860, + June 2000. + + + + + +Manderson, et al. Standards Track [Page 7] + +RFC 6491 IANA RPKI Objects February 2012 + + + [RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", + RFC 3068, June 2001. + + [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP + Addresses and AS Identifiers", RFC 3779, June 2004. + + [RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix + Reserved for Documentation", RFC 3849, July 2004. + + [RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local + Addresses", RFC 3879, September 2004. + + [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic + Configuration of IPv4 Link-Local Addresses", RFC 3927, + May 2005. + + [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast + Addresses", RFC 4193, October 2005. + + [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway + Protocol 4 (BGP-4)", RFC 4271, January 2006. + + [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing + Architecture", RFC 4291, February 2006. + + [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through + Network Address Translations (NATs)", RFC 4380, + February 2006. + + [RFC4843] Nikander, P., Laganier, J., and F. Dupont, "An IPv6 + Prefix for Overlay Routable Cryptographic Hash + Identifiers (ORCHID)", RFC 4843, April 2007. + + [RFC5180] Popoviciu, C., Hamza, A., Van de Velde, G., and D. + Dugatkin, "IPv6 Benchmarking Methodology for Network + Interconnect Devices", RFC 5180, May 2008. + + [RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", + BCP 153, RFC 5735, January 2010. + + [RFC5736] Huston, G., Cotton, M., and L. Vegoda, "IANA IPv4 Special + Purpose Address Registry", RFC 5736, January 2010. + + [RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address + Blocks Reserved for Documentation", RFC 5737, + January 2010. + + + + + +Manderson, et al. Standards Track [Page 8] + +RFC 6491 IANA RPKI Objects February 2012 + + + [RFC5771] Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines + for IPv4 Multicast Address Assignments", BCP 51, + RFC 5771, March 2010. + + [RPKI-USE] Manderson, T., Sriram, K., and R. White, "Use Cases and + Interpretation of RPKI Objects for Issuers and Relying + Parties", Work in Progress, October 2011. + + [TA-MGMT] Reynolds, M. and S. Kent, "Local Trust Anchor Management + for the Resource Public Key Infrastructure", Work + in Progress, December 2011. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Manderson, et al. Standards Track [Page 9] + +RFC 6491 IANA RPKI Objects February 2012 + + +Appendix A. IANA Reserved IPv4 Address Blocks + + This list of Address Space and RFCs was correct at the time of + writing this document. + + +--------------------+------------------------------------+---------+ + | Prefix | RFC | TBR | + +--------------------+------------------------------------+---------+ + | 0.0.0.0/8 | [RFC1122], Section 3.2.1.3 | No | + | 10.0.0.0/8 | [RFC1918] | No | + | 127.0.0.0/8 | [RFC1122], Section 3.2.1.3 | No | + | 169.254.0.0/16 | [RFC3927] | No | + | 172.16.0.0/12 | [RFC1918] | No | + | 192.0.0.0/24 | [RFC5736] | Various | + | 192.0.2.0/24 | [RFC5737] | No | + | 192.88.99.0/24 | [RFC3068] | Yes | + | 192.168.0.0/16 | [RFC1918] | No | + | 198.18.0.0/15 | [RFC2544] | No | + | 198.51.100.0/24 | [RFC5737] | No | + | 203.0.113.0/24 | [RFC5737] | No | + | 224.0.0.0/4 | [RFC5771] | No | + | 240.0.0.0/4 | [RFC1112], Section 4 | No | + | 255.255.255.255/32 | [RFC0919], Section 7 and | No | + | | [RFC0922], Section 7 | | + +--------------------+------------------------------------+---------+ + + TBR: To Be Routed, the intention of the RFC pertaining to the + address block. + + Table 1: IPv4 Address Blocks and + the RFCs that Direct IANA to Reserve Them + + + + + + + + + + + + + + + + + + + + +Manderson, et al. Standards Track [Page 10] + +RFC 6491 IANA RPKI Objects February 2012 + + +Appendix B. IANA Reserved IPv6 Address Blocks + + This list of Address Space and RFCs was correct at the time of + writing this document. + + +----------------+-----------+-----+ + | Prefix | RFC | TBR | + +----------------+-----------+-----+ + | 0000::/8 | [RFC4291] | No | + | 0100::/8 | [RFC4291] | No | + | 0200::/7 | [RFC4291] | No | + | 0400::/6 | [RFC4291] | No | + | 0800::/5 | [RFC4291] | No | + | 1000::/4 | [RFC4291] | No | + | 4000::/3 | [RFC4291] | No | + | 6000::/3 | [RFC4291] | No | + | 8000::/3 | [RFC4291] | No | + | A000::/3 | [RFC4291] | No | + | C000::/3 | [RFC4291] | No | + | E000::/4 | [RFC4291] | No | + | F000::/5 | [RFC4291] | No | + | F800::/6 | [RFC4291] | No | + | FC00::/7 | [RFC4193] | No | + | FE00::/9 | [RFC4291] | No | + | FE80::/10 | [RFC4291] | No | + | FEC0::/10 | [RFC3879] | No | + | FF00::/8 | [RFC4291] | No | + | 2001:0002::/48 | [RFC5180] | No | + | 2001:10::/28 | [RFC4843] | No | + +----------------+-----------+-----+ + + TBR: To Be Routed, the intention of the RFC pertaining to the + address block. + + Table 2: IPv6 Address Blocks and + the RFCs that Direct IANA to Reserve Them + + + + + + + + + + + + + + + +Manderson, et al. Standards Track [Page 11] + +RFC 6491 IANA RPKI Objects February 2012 + + +Authors' Addresses + + Terry Manderson + Internet Corporation for Assigned Names and Numbers + 4676 Admiralty Way, Suite 330 + Marina del Rey, CA 90292 + United States of America + + Phone: +1-310-823-9358 + EMail: terry.manderson@icann.org + URI: http://www.iana.org/ + + + Leo Vegoda + Internet Corporation for Assigned Names and Numbers + 4676 Admiralty Way, Suite 330 + Marina del Rey, CA 90292 + United States of America + + Phone: +1-310-823-9358 + EMail: leo.vegoda@icann.org + URI: http://www.iana.org/ + + + Steve Kent + BBN + + EMail: kent@bbn.com + + + + + + + + + + + + + + + + + + + + + + + +Manderson, et al. Standards Track [Page 12] + |