idnits 2.17.1 draft-iana-special-ipv4-registry-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 27, 2009) is 5529 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'IANA' is defined on line 192, but no explicit reference was found in the text == Unused Reference: 'RFC2928' is defined on line 200, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 4773 (Obsoleted by RFC 6890) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Huston 3 Internet-Draft APNIC 4 Intended status: Informational M. Cotton 5 Expires: August 31, 2009 L. Vegoda 6 ICANN 7 February 27, 2009 9 IANA IPv4 Special Purpose Address Registry 10 draft-iana-special-ipv4-registry-01 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and 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 August 31, 2009. 35 Copyright Notice 37 Copyright (c) 2009 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents in effect on the date of 42 publication of this document (http://trustee.ietf.org/license-info). 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. 46 Abstract 48 This is a direction to IANA concerning the creation and management of 49 the IANA IPv4 Special Purpose Address Registry. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. IANA IPv4 Special Purpose Address Block . . . . . . . . . . . . 3 55 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 56 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 57 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 58 6. Informative References . . . . . . . . . . . . . . . . . . . . 5 59 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 61 1. Introduction 63 This is a direction to IANA concerning the creation and management of 64 the IANA IPv4 Special Purpose Address Registry. The registry will be 65 used for recording IETF protocol assignments from 192.0.0.0/24 and 66 any other address prefixes allocated to the registry in the future, 67 as described in section 3. 69 2. IANA IPv4 Special Purpose Address Block 71 [rfc3330bis] records the assignment of an IPv4 address prefix to IANA 72 for IETF protocol assignments. 74 "192.0.0.0/24 - This block is reserved for IETF protocol 75 assignments." 77 This address allocation to IANA is intended to support IETF protocol 78 assignments. A more general view of the roles of IANA with respect 79 to address allocation functions is documented in [RFC2860]: 81 "4.3. [...] Note that [...] (b) assignments of specialised address 82 blocks (such as multicast or anycast blocks), and (c) experimental 83 assignments are not considered to be policy issues, and shall remain 84 subject to the provisions of this Section 4. (For purposes of this 85 MOU, the term "assignments" includes allocations.)" [RFC2860] 87 The reference to section 4 here is to the general technical work for 88 the IANA: 90 "4.1. The IANA will assign and register Internet protocol parameters 91 only as directed by the criteria and procedures specified in RFCs, 92 including Proposed, Draft, and full Internet Standards and Best 93 Current Practice documents, and any other RFC that calls for IANA 94 assignment." [RFC2860] 96 This document directs IANA to designate special purpose address 97 blocks in compliance with [RFC2860]. 99 This document directs IANA to open an IPv4 Special Purpose Address 100 Registry for the management of these IANA-designated address blocks. 101 Special Purpose registrations to be made from this registry include 102 addresses for IETF protocol assignments and other special purpose 103 cases, as documented in IESG-reviewed published RFCs, according to 104 the provisions described in section 4.1 of [RFC2860]. 106 3. IANA Considerations 108 IANA maintains an "IANA IPv4 Special Purpose Address Registry". The 109 registry records current IANA address designations from the IANA- 110 managed IPv4 Special Purpose address pool. 112 This recommendation concerns the management of the address pool used 113 for IETF protocol assignments as documented in [rfc3330bis] in 114 [date], namely 192.0.0.0/24. Following the policies outlined in 115 [RFC5226], further assignments of address space to IANA for 116 subsequent designation of address prefixes for the purposes listed 117 here shall be undertaken only through an IETF Review action. 119 IANA may make Special Purpose address designations to support testing 120 or experimental usage activities initiated by IETF, or for 121 specialised use of a designated address block in a context (e.g. 122 anycast) associated with an Internet Standards track protocol. All 123 such address designations must be documented in the "IANA 124 Considerations" section of an IESG-reviewed RFC. 126 The IANA IPv4 Special Purpose Address Registry records, for all 127 current address designations undertaken by IANA: 129 1. The designated address prefix. 131 2. The RFC that called for the IANA address designation. 133 3. The date the designation was made. 135 4. The date the use designation is to be terminated (if specified as 136 a limited-use designation). 138 5. The nature of the purpose of the designated address (e.g. unicast 139 experiment or protocol service anycast). 141 6. For experimental unicast applications and otherwise as 142 appropriate, the registry will also identify the entity and 143 related contact details to whom the address designation has been 144 made. 146 7. The registry will also note, for each designation, the intended 147 routing scope of the address, indicating whether the address is 148 intended to be routable only in scoped, local, or private 149 contexts, or whether the address prefix is intended to be routed 150 globally. 152 8. The date in the IANA registry is the date of the IANA action, 153 i.e. the day IANA records the allocation. 155 The IANA registry notes, as a general comment, that address prefixes 156 listed in the IPv4 Special Purpose Address Registry are not 157 guaranteed routability in any particular local or global context. 159 IANA will not maintain further sub-registries for any IPv4 Special 160 Purpose address block designated according to this direction. 162 4. Security Considerations 164 Security of the Internet's routing system relies on the ability to 165 authenticate an assertion of unique control of an address block. 166 Measures to authenticate such assertions rely on validation that the 167 address block forms part of an existing allocated address block, and 168 that there is a trustable and unique reference in the IANA address 169 registries. 171 This registry is intended to provide an authoritative source of 172 information regarding the currency and intended purpose of IPv4 173 Special Purpose address blocks that are designated from the IANA- 174 administered IPv4 Special Purpose address pool. This is a small step 175 towards the creation of a comprehensive registry framework that can 176 be used as a trust point for commencing a chain of address 177 validation. Consideration should be given to the use of file 178 signatures and associated certificate mechanisms to allow 179 applications to confirm that the registry contents are current, and 180 that they have been published by the IANA. 182 5. Acknowledgements 184 This document is based on [RFC4773], which was prepared with the 185 assistance of Leslie Daigle, Brian Haberman, Bob Hinden, David 186 Kessens, Kurt Lindqvist, Thomas Narten, and Paul Wilson. While all 187 these individuals were not explicitly consulted in the preparation of 188 this document, their original contribution is acknowledged here. 190 6. Informative References 192 [IANA] IANA, "IANA Matrix for Protocol Parameter Assignment/ 193 Registration Procedures", 194 . 196 [RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of 197 Understanding Concerning the Technical Work of the 198 Internet Assigned Numbers Authority", RFC 2860, June 2000. 200 [RFC2928] Hinden, R., Deering, S., Fink, R., and T. Hain, "Initial 201 IPv6 Sub-TLA ID Assignments", RFC 2928, September 2000. 203 [RFC4773] Huston, G., "Administration of the IANA Special Purpose 204 IPv6 Address Block", RFC 4773, December 2006. 206 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 207 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 208 May 2008. 210 Authors' Addresses 212 Geoff Huston 213 Asia Pacific Network Information Centre 214 PO Box 2131 215 Milton, QLD 4064 216 Australia 218 Phone: +61-7-3858-3100 219 Email: gih@apnic.net 220 URI: http://www.apnic.net/ 222 Michelle Cotton 223 Internet Corporation for Assigned Names and Numbers 224 4676 Admiralty Way, Suite 330 225 Marina del Rey, CA 90292-6601 226 USA 228 Phone: ++1-310-823-9358 229 Email: michelle.cotton@icann.org 230 URI: http://www.iana.org/ 232 Leo Vegoda 233 Internet Corporation for Assigned Names and Numbers 234 4676 Admiralty Way, Suite 330 235 Marina del Rey, CA 90292-6601 236 USA 238 Phone: ++1-310-823-9358 239 Email: leo.vegoda@icann.org 240 URI: http://www.iana.org/