diff options
Diffstat (limited to 'doc/rfc/rfc5736.txt')
-rw-r--r-- | doc/rfc/rfc5736.txt | 339 |
1 files changed, 339 insertions, 0 deletions
diff --git a/doc/rfc/rfc5736.txt b/doc/rfc/rfc5736.txt new file mode 100644 index 0000000..12b36f1 --- /dev/null +++ b/doc/rfc/rfc5736.txt @@ -0,0 +1,339 @@ + + + + + + +Internet Engineering Task Force (IETF) G. Huston +Request for Comments: 5736 APNIC +Category: Informational M. Cotton +ISSN: 2070-1721 L. Vegoda + ICANN + January 2010 + + + IANA IPv4 Special Purpose Address Registry + +Abstract + + This is a direction to IANA concerning the creation and management of + the IANA IPv4 Special Purpose Address Registry. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + 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). Not all documents + approved by the IESG are a candidate for any level of Internet + Standard; see 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/rfc5736. + +Copyright Notice + + Copyright (c) 2010 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. + + + + + + +Huston, et al. Informational [Page 1] + +RFC 5736 IPv4 Special Registry January 2010 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. IANA IPv4 Special Purpose Address Block . . . . . . . . . . . . 2 + 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 3 + 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 + 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 4 + 6. Informative References . . . . . . . . . . . . . . . . . . . . 5 + +1. Introduction + + This is a direction to [IANA] concerning the creation and management + of the IANA IPv4 Special Purpose Address Registry. The registry will + be used for recording IETF protocol assignments from 192.0.0.0/24 and + any other address prefixes allocated to the registry in the future, + as described in Section 3. + +2. IANA IPv4 Special Purpose Address Block + + [RFC5735] records the assignment of an IPv4 address prefix to IANA + for IETF protocol assignments. + + 192.0.0.0/24 - This block is reserved for IETF protocol + assignments. + + This address allocation to IANA is intended to support IETF protocol + assignments. A more general view of the roles of IANA with respect + to address allocation functions is documented in [RFC2860]: + + 4.3. [...] Note that [...] (b) assignments of specialised address + blocks (such as multicast or anycast blocks), and (c) experimental + assignments are not considered to be policy issues, and shall + remain subject to the provisions of this Section 4. (For purposes + of this MOU, the term "assignments" includes allocations.) + + The reference to Section 4 here is to the general technical work for + the IANA as described in [RFC2860]: + + 4.1. The IANA will assign and register Internet protocol + parameters only as directed by the criteria and procedures + specified in RFCs, including Proposed, Draft, and full Internet + Standards and Best Current Practice documents, and any other RFC + that calls for IANA assignment. + + This document directs IANA to designate special purpose address + blocks in compliance with [RFC2860]. + + + + + +Huston, et al. Informational [Page 2] + +RFC 5736 IPv4 Special Registry January 2010 + + + This document directs IANA to open an IPv4 Special Purpose Address + Registry for the management of these IANA-designated address blocks. + Special Purpose registrations to be made from this registry include + addresses for IETF protocol assignments and other special purpose + cases, as documented in IESG-reviewed RFCs, according to the + provisions described in Section 4.1 of [RFC2860]. + +3. IANA Considerations + + IANA maintains an "IANA IPv4 Special Purpose Address Registry". The + registry records current IANA address designations from the IANA- + managed IPv4 Special Purpose address pool. + + This recommendation concerns the management of the address pool used + for IETF protocol assignments as documented in [RFC5735] -- namely, + 192.0.0.0/24. Following the policies outlined in [RFC5226], further + assignments of address space to IANA for subsequent designation of + address prefixes for the purposes listed here shall be undertaken + only through an IETF Review action. + + IANA may make Special Purpose address designations to support testing + or experimental usage activities initiated by the IETF, or for + specialised use of a designated address block in a context (e.g., + anycast) associated with an Internet Standards Track protocol. All + such address designations must be documented in the "IANA + Considerations" section of an IESG-reviewed RFC. + + The IANA IPv4 Special Purpose Address Registry records, for all + current address designations undertaken by IANA: + + 1. The designated address prefix. + + 2. The RFC that called for the IANA address designation. + + 3. The date the designation was made. + + 4. The date the use designation is to be terminated (if specified as + a limited-use designation). + + 5. The nature of the purpose of the designated address (e.g., + unicast experiment or protocol service anycast). + + 6. For experimental unicast applications and otherwise as + appropriate, the registry will also identify the entity and + related contact details to whom the address designation has been + made. + + + + + +Huston, et al. Informational [Page 3] + +RFC 5736 IPv4 Special Registry January 2010 + + + 7. The registry will also note, for each designation, the intended + routing scope of the address, indicating whether the address is + intended to be routable only in scoped, local, or private + contexts, or whether the address prefix is intended to be routed + globally. + + 8. The date in the IANA registry is the date of the IANA action, + i.e., the day IANA records the allocation. + + The IANA registry notes, as a general comment, that address prefixes + listed in the IPv4 Special Purpose Address Registry are not + guaranteed routability in any particular local or global context. + + IANA will not maintain further sub-registries for any IPv4 Special + Purpose address block designated according to this direction. + +4. Security Considerations + + Security of the Internet's routing system relies on the ability to + authenticate an assertion of unique control of an address block. + Measures to authenticate such assertions rely on validation that the + address block forms part of an existing allocated address block, and + that there is a trustable and unique reference in the IANA address + registries. + + This registry is intended to provide an authoritative source of + information regarding the currency and intended purpose of IPv4 + Special Purpose address blocks that are designated from the IANA- + administered IPv4 Special Purpose address pool. This is a small step + towards the creation of a comprehensive registry framework that can + be used as a trust point for commencing a chain of address + validation. Consideration should be given to the use of file + signatures and associated certificate mechanisms to allow + applications to confirm that the registry contents are current, and + that they have been published by the IANA. + +5. Acknowledgements + + This document is based on [RFC4773], which was prepared with the + assistance of Leslie Daigle, Brian Haberman, Bob Hinden, David + Kessens, Kurt Lindqvist, Thomas Narten, and Paul Wilson. While all + these individuals were not explicitly consulted in the preparation of + this document, their original contribution is acknowledged here. + + + + + + + + +Huston, et al. Informational [Page 4] + +RFC 5736 IPv4 Special Registry January 2010 + + +6. Informative References + + [IANA] IANA, "IANA Matrix for Protocol Parameter Assignment/ + Registration Procedures", + <http://www.iana.org/numbers.html>. + + [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. + + [RFC4773] Huston, G., "Administration of the IANA Special Purpose + IPv6 Address Block", RFC 4773, December 2006. + + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 5226, + May 2008. + + [RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", + BCP 153, RFC 5735, January 2010. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Huston, et al. Informational [Page 5] + +RFC 5736 IPv4 Special Registry January 2010 + + +Authors' Addresses + + Geoff Huston + Asia Pacific Network Information Centre + PO Box 2131 + Milton, QLD 4064 + Australia + + Phone: +61-7-3858-3100 + EMail: gih@apnic.net + URI: http://www.apnic.net/ + + + Michelle Cotton + Internet Corporation for Assigned Names and Numbers + 4676 Admiralty Way, Suite 330 + Marina del Rey, CA 90292-6601 + USA + + Phone: +1-310-823-9358 + EMail: michelle.cotton@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-6601 + USA + + Phone: +1-310-823-9358 + EMail: leo.vegoda@icann.org + URI: http://www.iana.org/ + + + + + + + + + + + + + + + + + + +Huston, et al. Informational [Page 6] + |