idnits 2.17.1 draft-iana-rfc3330bis-03.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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 326. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 337. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 344. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 350. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 9 form feeds but 12 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 17 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 2 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 7 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. -- 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 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 (June 2, 2008) is 5800 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC5156' is defined on line 293, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 1700 (Obsoleted by RFC 3232) -- Obsolete informational reference (is this intentional?): RFC 3068 (Obsoleted by RFC 7526) -- Obsolete informational reference (is this intentional?): RFC 3171 (Obsoleted by RFC 5771) -- Obsolete informational reference (is this intentional?): RFC 3330 (Obsoleted by RFC 5735) -- Obsolete informational reference (is this intentional?): RFC 5156 (Obsoleted by RFC 6890) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Cotton 3 Internet-Draft ICANN 4 Obsoletes: 3330 (if approved) June 2, 2008 5 Intended status: BCP 6 Expires: December 4, 2008 8 Special Use IPv4 Addresses 9 draft-iana-rfc3330bis-03 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on December 4, 2008. 36 Abstract 38 This document obsoletes RFC 3330. It describes the global and other 39 specialized IPv4 address blocks that have been assigned by the 40 Internet Assigned Numbers Authority (IANA). It does not address IPv4 41 address space assigned to operators and users through the Regional 42 Internet Registries. It also does not address allocations or 43 assignments of IPv6 addresses or autonomous system numbers. Special 44 IPv6 addresses are described in RFC 5156. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 3. Differences between this document and RFC 3330 . . . . . . . . 3 51 4. Global and Other Specialized Address Blocks . . . . . . . . . . 4 52 5. Summary Table . . . . . . . . . . . . . . . . . . . . . . . . . 5 53 6. Assignments of IPv4 Blocks for New Specialized Uses . . . . . . 6 54 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 55 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 56 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7 57 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 58 10.1. Normative References . . . . . . . . . . . . . . . . . . . 7 59 10.2. Informative References . . . . . . . . . . . . . . . . . . 7 60 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 61 Intellectual Property and Copyright Statements . . . . . . . . . . 9 63 1. Introduction 65 Throughout its history, the Internet has employed a central Internet 66 Assigned Numbers Authority (IANA) responsible for the allocation and 67 assignment of various identifiers needed for the operation of the 68 Internet [RFC1174]. In the case of the IPv4 address space, the IANA 69 allocates parts of the address space to Regional Internet Registries 70 (RIRs) according to their established needs. These Regional Internet 71 Registries are responsible for the registration of IPv4 addresses to 72 operators and users of the Internet within their regions. 74 On an ongoing basis, the IANA has been designated by the IETF to make 75 assignments in support of the Internet Standards Process [RFC2860]. 76 Section 5 of this document describes that assignment process. 78 Small portions of the IPv4 address space have been allocated or 79 assigned directly by the IANA for global or other specialized 80 purposes. These allocations and assignments have been documented in 81 a variety of RFCs and other documents. This document is intended to 82 collect these scattered references and provide a current list of 83 special use IPv4 addresses. 85 This document is a revision of RFC 3330 [RFC3330], which it 86 obsoletes; its primary purpose is to re-publish the technical content 87 of RFC 3330 mostly unchanged as a Best Current Practice RFC. 89 The terms "Specification Required", "Expert Review", "IESG Approval", 90 "IETF Consensus", and "Standards Action", are used in this memo to 91 refer to the processes described in [RFC5226]. The keywords MUST, 92 MUST NOT, MAY, OPTIONAL, REQUIRED, RECOMMENDED, SHALL, SHALL NOT, 93 SHOULD, SHOULD NOT are to be interpreted as defined in [RFC2119]. 95 2. Terminology 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in BCP 14, [RFC2119]. 101 3. Differences between this document and RFC 3330 103 Address blocks that were reserved for a special purpose in RFC 3330 104 but are no longer reserved for any special purpose and are available 105 for allocation are no longer listed in Sections 4 or 5. The 106 following blocks have changes: 14.0.0.0/8 is no longer set aside for 107 assignments to the international system of Public Data Networks 108 [RFC1700], page 181]. It is now available for allocation to RIRs in 109 the normal way. 24.0.0.0/8 is no longer listed as the addresses in 110 that block have been managed by the American Registry for Internet 111 Numbers (ARIN) in the normal way since 2001. 39.0.0.0/8 is no longer 112 listed as it has been subject to allocation to an RIR for assignment 113 in the normal manner since 2001. 128.0.0.0/16 is not reserved and is 114 subject to future allocation by a Regional Internet Registry for 115 assignment in the normal manner. 191.255.0.0/16 is not reserved and 116 is subject to future allocation by a RIR for assignment in the normal 117 manner. 192.0.0.0/24 is not reserved and is subject to future 118 allocation by a RIR for assignment in the normal manner. 119 223.255.255.0/24 is not reserved and is subject to future allocation 120 by an RIR for assignment in the normal manner. 122 4. Global and Other Specialized Address Blocks 124 0.0.0.0/8 - Addresses in this block refer to source hosts on "this" 125 network. Address 0.0.0.0/32 may be used as a source address for this 126 host on this network; other addresses within 0.0.0.0/8 may be used to 127 refer to specified hosts on this network [RFC1700], page 4. 129 10.0.0.0/8 - This block is set aside for use in private networks. 130 Its intended use is documented in [RFC1918]. Addresses within this 131 block should not appear on the public Internet. 133 127.0.0.0/8 - This block is assigned for use as the Internet host 134 loopback address. A datagram sent by a higher level protocol to an 135 address anywhere within this block should loop back inside the host. 136 This is ordinarily implemented using only 127.0.0.1/32 for loopback, 137 but no addresses within this block should ever appear on any network 138 anywhere [RFC1700], page 5. 140 128.0.0.0/16 - This block, corresponding to the numerically lowest of 141 the former Class B addresses, was initially reserved by the IANA. 142 Given the present classless nature of the IP address space, the basis 143 for the reservation no longer applies and addresses in this block are 144 subject to future allocation by a Regional Internet Registry for 145 assignment in the normal manner. 147 169.254.0.0/16 - This is the "link local" block. As described in 148 [RFC3927], it is allocated for communication between hosts on a 149 single link. Hosts obtain these addresses by auto-configuration, 150 such as when a DHCP server may not be found. 152 172.16.0.0/12 - This block is set aside for use in private networks. 153 Its intended use is documented in [RFC1918]. Addresses within this 154 block should not appear on the public Internet. 156 192.0.2.0/24 - This block is assigned as "TEST-NET" for use in 157 documentation and example code. It is often used in conjunction with 158 domain names example.com or example.net in vendor and protocol 159 documentation. Addresses within this block should not appear on the 160 public Internet. 162 192.88.99.0/24 - This block is allocated for use as 6to4 relay 163 anycast addresses, according to [RFC3068]. 165 192.168.0.0/16 - This block is set aside for use in private networks. 166 Its intended use is documented in [RFC1918]. Addresses within this 167 block should not appear on the public Internet. 169 198.18.0.0/15 - This block has been allocated for use in benchmark 170 tests of network interconnect devices. [RFC2544] explains that this 171 range was assigned to minimize the chance of conflict in case a 172 testing device were to be accidentally connected to part of the 173 Internet. Packets with source addresses from this range are not 174 meant to be forwarded across the Internet. 176 224.0.0.0/4 - This block, formerly known as the Class D address 177 space, is allocated for use in IPv4 multicast address assignments. 178 The IANA guidelines for assignments from this space are described in 179 [RFC3171]. 181 240.0.0.0/4 - This block, formerly known as the Class E address 182 space, is reserved. The "limited broadcast" destination address 183 255.255.255.255 should never be forwarded outside the local network 184 of the source. The remainder of this space is reserved for future 185 use. [RFC1700], page 4. 187 5. Summary Table 189 Address Block Present Use Reference 190 ------------------------------------------------------------------ 191 10.0.0.0/8 Private-Use Networks RFC 1918 192 169.254.0.0/16 Link Local RFC 3927 193 172.16.0.0/12 Private-Use Networks RFC 1918 194 192.0.2.0/24 Test-Net 195 192.88.99.0/24 6to4 Relay Anycast RFC 3068 196 192.168.0.0/16 Private-Use Networks RFC 1918 197 198.18.0.0/15 Network Interconnect 198 Device Benchmark Testing RFC 2544 199 224.0.0.0/4 Multicast RFC 3171 201 6. Assignments of IPv4 Blocks for New Specialized Uses 203 The IANA has responsibility for making assignments of protocol 204 parameters used in the Internet according to the requirements of the 205 "Memorandum of Understanding Concerning the Technical Work of the 206 Internet Assigned Numbers Authority" [RFC2860]. Among other things, 207 [RFC2860] requires that protocol parameters be assigned according to 208 the criteria and procedures specified in RFCs, including Proposed, 209 Draft, and full Internet Standards and Best Current Practice 210 documents, and any other RFC that calls for IANA assignment. 212 The domain name and IP address spaces involve policy issues (in 213 addition to technical issues) so that the requirements of [RFC2860] 214 do not apply generally to those spaces. Nonetheless, the IANA is 215 responsible for ensuring assignments of IPv4 addresses as needed in 216 support of the Internet Standards Process. When a portion of the 217 IPv4 address space is specifically required by an RFC, the technical 218 requirements (e.g., size, prefix length) for the portion should be 219 described [RFC5226]. Immediately before the RFC is published, the 220 IANA will, in consultation with the Regional Internet Registries, 221 make the necessary assignment and notify the RFC Editor of the 222 particulars for inclusion in the RFC as published. 224 As required by [RFC2860], the IANA will also make necessary 225 experimental assignments of IPv4 addresses, also in consultation with 226 the Regional Internet Registries. 228 7. IANA Considerations 230 This document describes the IANA's past and current practices and 231 does not create any new requirements for assignments or allocations 232 by the IANA. 234 8. Security Considerations 236 The particular assigned values of special-use IPv4 addresses 237 cataloged in this document do not directly raise security issues. 238 However, the Internet does not inherently protect against abuse of 239 these addresses; if you expect (for instance) that all packets from 240 the 10.0.0.0/8 block originate within your subnet, all border routers 241 should filter such packets that originate from elsewhere. Attacks 242 have been mounted that depend on the unexpected use of some of these 243 addresses. 245 9. Acknowledgments 247 Many people have made comments on draft versions of this document. 248 The IANA would especially like to thank Scott Bradner, Randy Bush, 249 Leo Vegoda, and Harald Alvestrand for their constructive feedback and 250 comments. 252 10. References 254 10.1. Normative References 256 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 257 Requirement Levels", BCP 14, RFC 2119, March 1997. 259 10.2. Informative References 261 [RFC1174] Cerf, V., "IAB recommended policy on distributing internet 262 identifier assignment and IAB recommended policy change to 263 internet "connected" status", RFC 1174, August 1990. 265 [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, 266 October 1994. 268 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 269 E. Lear, "Address Allocation for Private Internets", 270 BCP 5, RFC 1918, February 1996. 272 [RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for 273 Network Interconnect Devices", RFC 2544, March 1999. 275 [RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of 276 Understanding Concerning the Technical Work of the 277 Internet Assigned Numbers Authority", RFC 2860, June 2000. 279 [RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", 280 RFC 3068, June 2001. 282 [RFC3171] Albanna, Z., Almeroth, K., Meyer, D., and M. Schipper, 283 "IANA Guidelines for IPv4 Multicast Address Assignments", 284 BCP 51, RFC 3171, August 2001. 286 [RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330, 287 September 2002. 289 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 290 Configuration of IPv4 Link-Local Addresses", RFC 3927, 291 May 2005. 293 [RFC5156] Blanchet, M., "Special-Use IPv6 Addresses", RFC 5156, 294 April 2008. 296 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 297 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 298 May 2008. 300 Author's Address 302 Michelle Cotton 303 Internet Corporation for Assigned Names and Numbers 304 4676 Admiralty Way, Suite 330 305 Marina del Rey 90292 306 United States 308 Phone: +310-823-9358 309 Email: michelle.cotton@icann.org 310 URI: http://www.iana.org/ 312 Full Copyright Statement 314 Copyright (C) The IETF Trust (2008). 316 This document is subject to the rights, licenses and restrictions 317 contained in BCP 78, and except as set forth therein, the authors 318 retain all their rights. 320 This document and the information contained herein are provided on an 321 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 322 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 323 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 324 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 325 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 326 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 328 Intellectual Property 330 The IETF takes no position regarding the validity or scope of any 331 Intellectual Property Rights or other rights that might be claimed to 332 pertain to the implementation or use of the technology described in 333 this document or the extent to which any license under such rights 334 might or might not be available; nor does it represent that it has 335 made any independent effort to identify any such rights. Information 336 on the procedures with respect to rights in RFC documents can be 337 found in BCP 78 and BCP 79. 339 Copies of IPR disclosures made to the IETF Secretariat and any 340 assurances of licenses to be made available, or the result of an 341 attempt made to obtain a general license or permission for the use of 342 such proprietary rights by implementers or users of this 343 specification can be obtained from the IETF on-line IPR repository at 344 http://www.ietf.org/ipr. 346 The IETF invites any interested party to bring to its attention any 347 copyrights, patents or patent applications, or other proprietary 348 rights that may cover technology that may be required to implement 349 this standard. Please address the information to the IETF at 350 ietf-ipr@ietf.org.