idnits 2.17.1 draft-huston-ipv6-iana-specials-01.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 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 222. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 199. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 206. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 212. ** 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. 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 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 -- 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 (December 28, 2005) is 6684 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) No issues found here. Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Individual Submission G. Huston 3 Internet-Draft APNIC 4 Expires: July 1, 2006 December 28, 2005 6 Administration of the IANA Special Purpose Address Block 7 draft-huston-ipv6-iana-specials-01.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on July 1, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2005). 38 Abstract 40 This is a direction to IANA concerning the management of the IANA 41 Special Purpose IPv6 address assignment registry. 43 1. Introduction 45 This is a direction to IANA concerning the management of the IANA 46 Special Purpose IPv6 address assignment registry. 48 2. IANA IPv6 Special Purpose Address Block 50 [RFC2928] specified the assignment of the IPv6 address prefix to 51 IANA. The rationale for this allocation is: 52 "The block of Sub-TLA IDs assigned to the IANA (i.e., 2001: 53 0000::/29 - 2001:01F8::/29) is for assignment for testing and 54 experimental usage to support activities such as the 6bone, and 55 for new approaches like exchanges." 56 [RFC2928] 58 This address allocation to IANA was intended to support testing and 59 experimental activities. A more general view of the roles of IANA 60 with respect to address allocation functions is documented in 61 [RFC2860]: 62 "4.3. [...] Note that [...] (b) assignments of specialised 63 address blocks (such as multicast or anycast blocks), and (c) 64 experimental assignments are not considered to be policy issues, 65 and shall remain subject to the provisions of this Section 4. 66 (For purposes of this MOU, the term "assignments" includes 67 allocations.)" 68 [RFC2860] 70 The reference to section 4 here is to the general technical work for 71 the IANA: 72 "4.1. The IANA will assign and register Internet protocol 73 parameters only as directed by the criteria and procedures 74 specified in RFCs, including Proposed, Draft and full Internet 75 Standards and Best Current Practice documents, and any other RFC 76 that calls for IANA assignment." 77 [RFC2860] 79 This document directs IANA to undertake designation of special 80 purpose address blocks within the purview of direct assignments by 81 the IANA under the terms of the assignment criteria specified in RFC 82 2928. 84 This document directs IANA to open a Special Purpose IPv6 address 85 registry for the management of these IANA-designated address blocks. 86 Special Purpose registrations to be made from this registry include 87 addresses for experimental purposes, as described in [RFC2928], and 88 other special purpose cases as documented in IESG-reviewed published 89 RFCs, according to the provisions described in section 4.1. of 90 [RFC2860]. 92 3. IANA Considerations 94 IANA is directed to maintain an "IANA IPv6 Address Special Purpose 95 Registry". The registry is to record current IANA address 96 designations from the IANA-managed Special Purpose IPv6 address pool. 98 This recommendation concerns the management of the address pool 99 assigned by the IETF to the IANA in July 1999 by [RFC2928], namely 100 2001:0000::/23. Further assignments of address space to IANA for 101 subsequent designation of address prefixes for the purposes listed 102 here shall be undertaken only in response to direction to IANA 103 provided by the IETF in a IESG-reviewed RFC document. Such 104 directions for assignments of address space to augment the IANA- 105 managed special purpose address pool should, in the general course of 106 events, be consistent with prevailing IANA IPv6 address management 107 policies [IPv6-Policies]. 109 The IANA may undertake IPv6 address designations in support of 110 special purposes as requested in "IANA Considerations" sections in 111 IESG-reviewed RFCs, where a unicast address is requested with an 112 intended use of the designated address block for the purpose of 113 testing or experimental usage activities initiated by IETF, or for 114 specialised use of the address block within an anycast use context 115 associated with an Internet Standards track protocol. 117 The IANA IPv6 Special Purpose Address Registry shall record for all 118 current address designations undertaken by IANA: 119 1. The designated address prefix. 120 2. The RFC that called for the IANA address designation. 121 3. The date the designation was made. 122 4. The date the use designation is to be terminated (if specified as 123 a limited-use designation). 124 5. The nature of the purpose of the designated address (unicast 125 experiment or protocol service anycast). 126 6. If the purpose is an experimental unicast application, as 127 distinct from an anycast service address, then the registry will 128 also identify the entity and related contact details to whom the 129 address designation has been made. 130 7. The registry will also note for each designation the intended 131 routing scope of the address, indicating whether the address is 132 intended to be routable only in scoped, local or private 133 contexts, or whether the address prefix is intended to be routed 134 globally. 136 The IANA registry shall note as a general comment that address 137 prefixes listed in the Special Purpose Address Registry are not 138 guaranteed routability in any particular local or global context. 140 IANA will not maintain further sub-registries for any special purpose 141 address block designated according to this direction. 143 4. Security Considerations 145 Security of the Internet's routing system relies on the ability to 146 authenticate an assertion of unique control of an address block. 147 Measures to authenticate such assertions rely on validation that the 148 address block forms part of an existing allocated address block, and 149 that there is a trustable and unique reference in the IANA address 150 registries. 152 The proposed registry is intended to provide an authoritative source 153 of information regarding the currency and intended purpose of special 154 use IPv6 address blocks that are designated from the IANA- 155 administered Special Use registry. This is a small step towards the 156 creation of a comprehensive registry framework that can be used as a 157 trust point for commencing a chain of address validation. 158 Consideration should be given to IANA registry publication formats 159 that are machine parseable, and also the use of file signatures and 160 associated certificate mechanisms to allow applications to confirm 161 that the registry contents are current, and that they have been 162 published by the IANA. 164 5. Acknowledgements 166 The document was prepared with the assistance of Leslie Daigle, Brian 167 Haberman, Bob Hinden, David Kessens, Kurt Lindqvist, Thomas Narten 168 and Paul Wilson. 170 6. Informative References 172 [IPv6-Policies] 173 IANA, "IPv6 Allocation and Assignment Policy", June 2005. 175 [RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of 176 Understanding Concerning the Technical Work of the 177 Internet Assigned Numbers Authority", RFC 2860, June 2000. 179 [RFC2928] Hinden, R., Deering, S., Fink, R., and T. Hain, "Initial 180 IPv6 Sub-TLA ID Assignments", RFC 2928, September 2000. 182 Author's Address 184 Geoff Huston 185 Asia Pacific Network Information Centre 187 Email: gih@apnic.net 188 URI: http://www.apnic.net 190 Intellectual Property Statement 192 The IETF takes no position regarding the validity or scope of any 193 Intellectual Property Rights or other rights that might be claimed to 194 pertain to the implementation or use of the technology described in 195 this document or the extent to which any license under such rights 196 might or might not be available; nor does it represent that it has 197 made any independent effort to identify any such rights. Information 198 on the procedures with respect to rights in RFC documents can be 199 found in BCP 78 and BCP 79. 201 Copies of IPR disclosures made to the IETF Secretariat and any 202 assurances of licenses to be made available, or the result of an 203 attempt made to obtain a general license or permission for the use of 204 such proprietary rights by implementers or users of this 205 specification can be obtained from the IETF on-line IPR repository at 206 http://www.ietf.org/ipr. 208 The IETF invites any interested party to bring to its attention any 209 copyrights, patents or patent applications, or other proprietary 210 rights that may cover technology that may be required to implement 211 this standard. Please address the information to the IETF at 212 ietf-ipr@ietf.org. 214 Disclaimer of Validity 216 This document and the information contained herein are provided on an 217 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 218 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 219 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 220 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 221 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 222 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 224 Copyright Statement 226 Copyright (C) The Internet Society (2005). This document is subject 227 to the rights, licenses and restrictions contained in BCP 78, and 228 except as set forth therein, the authors retain all their rights. 230 Acknowledgment 232 Funding for the RFC Editor function is currently provided by the 233 Internet Society.