idnits 2.17.1 draft-iana-rfc3330bis-02.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 333. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 344. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 351. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 357. 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 13 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 18 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 (May 28, 2008) is 5812 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: 'RFC1797' is defined on line 268, but no explicit reference was found in the text == Unused Reference: 'RFC2050' is defined on line 275, but no explicit reference was found in the text == Unused Reference: 'RFC3232' 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 2050 (Obsoleted by RFC 7020) -- 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 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 8 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) May 28, 2008 5 Intended status: BCP 6 Expires: November 29, 2008 8 Special Use IPv4 Addresses 9 draft-iana-rfc3330bis-02 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 November 29, 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 a companion document that will be 45 published as RFC5156. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 3. Differences between this document and RFC 3330 . . . . . . . . 3 52 4. Global and Other Specialized Address Blocks . . . . . . . . . . 4 53 5. Summary Table . . . . . . . . . . . . . . . . . . . . . . . . . 5 54 6. Assignments of IPv4 Blocks for New Specialized Uses . . . . . . 6 55 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 56 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 57 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7 58 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 59 10.1. Normative References . . . . . . . . . . . . . . . . . . . 7 60 10.2. Informative References . . . . . . . . . . . . . . . . . . 7 61 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 62 Intellectual Property and Copyright Statements . . . . . . . . . . 9 64 1. Introduction 66 Throughout its entire history, the Internet has employed a central 67 Internet Assigned Numbers Authority (IANA) responsible for the 68 allocation and assignment of various identifiers needed for the 69 operation of the Internet [RFC1174]. In the case of the IPv4 address 70 space, the IANA allocates parts of the address space to Regional 71 Internet Registries (RIRs) according to their established needs. 72 These Regional Internet Registries are responsible for the assignment 73 of IPv4 addresses to operators and users of the Internet within their 74 regions. 76 This document is a revision of RFC 3330 [RFC3330], which it 77 obsoletes; its primary purpose is to re-publish the technical content 78 of RFC 3330 mostly unchanged as a Best Current Practice RFC. 80 Minor portions of the IPv4 address space have been allocated or 81 assigned directly by the IANA for global or other specialized 82 purposes. These allocations and assignments have been documented in 83 a variety of RFCs and other documents. This document is intended to 84 collect these scattered references and provide a current list of 85 special use IPv4 addresses. 87 On an ongoing basis, the IANA has been designated by the IETF to make 88 assignments in support of the Internet Standards Process [RFC2860]. 89 Section 5 of this document describes that assignment process. 91 The terms "Specification Required", "Expert Review", "IESG Approval", 92 "IETF Consensus", and "Standards Action", are used in this memo to 93 refer to the processes described in [RFC5226]. The keywords MUST, 94 MUST NOT, MAY, OPTIONAL, REQUIRED, RECOMMENDED, SHALL, SHALL NOT, 95 SHOULD, SHOULD NOT are to be interpreted as defined in [RFC2119]. 97 2. Terminology 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in BCP 14, [RFC2119]. 103 3. Differences between this document and RFC 3330 105 Address blocks that were reserved for a special purpose in RFC 3330 106 but are no longer reserved for any special purpose and are available 107 for allocation are no longer listed in Sections 4 or 5. The 108 following blocks have changes: 14.0.0.0/8 is no longer set aside for 109 assignments to the international system of Public Data Networks 111 [RFC1700], page 181]. It is now available for allocation to RIRs in 112 the normal way. 24.0.0.0/8 is no longer listed as the addresses in 113 that block have been managed by the American Registry for Internet 114 Numbers (ARIN) in the normal way since 2001. 39.0.0.0/8 is no longer 115 listed as it has been subject to allocation to an RIR for assignment 116 in the normal manner since 2001. 128.0.0.0/16 is not reserved and is 117 subject to future allocation by a Regional Internet Registry for 118 assignment in the normal manner. 191.255.0.0/16 is not reserved and 119 is subject to future allocation by a RIR for assignment in the normal 120 manner. 192.0.0.0/24 is not reserved and is subject to future 121 allocation by a RIR for assignment in the normal manner. 122 223.255.255.0/24 is not reserved and is subject to future allocation 123 by an RIR for assignment in the normal manner. 125 4. Global and Other Specialized Address Blocks 127 0.0.0.0/8 - Addresses in this block refer to source hosts on "this" 128 network. Address 0.0.0.0/32 may be used as a source address for this 129 host on this network; other addresses within 0.0.0.0/8 may be used to 130 refer to specified hosts on this network [RFC1700], page 4. 132 10.0.0.0/8 - This block is set aside for use in private networks. 133 Its intended use is documented in [RFC1918]. Addresses within this 134 block should not appear on the public Internet. 136 127.0.0.0/8 - This block is assigned for use as the Internet host 137 loopback address. A datagram sent by a higher level protocol to an 138 address anywhere within this block should loop back inside the host. 139 This is ordinarily implemented using only 127.0.0.1/32 for loopback, 140 but no addresses within this block should ever appear on any network 141 anywhere [RFC1700], page 5. 143 128.0.0.0/16 - This block, corresponding to the numerically lowest of 144 the former Class B addresses, was initially reserved by the IANA. 145 Given the present classless nature of the IP address space, the basis 146 for the reservation no longer applies and addresses in this block are 147 subject to future allocation by a Regional Internet Registry for 148 assignment in the normal manner. 150 169.254.0.0/16 - This is the "link local" block. As described in 151 [RFC3927], it is allocated for communication between hosts on a 152 single link. Hosts obtain these addresses by auto-configuration, 153 such as when a DHCP server may not be found. 155 172.16.0.0/12 - This block is set aside for use in private networks. 156 Its intended use is documented in [RFC1918]. Addresses within this 157 block should not appear on the public Internet. 159 192.0.2.0/24 - This block is assigned as "TEST-NET" for use in 160 documentation and example code. It is often used in conjunction with 161 domain names example.com or example.net in vendor and protocol 162 documentation. Addresses within this block should not appear on the 163 public Internet. 165 192.88.99.0/24 - This block is allocated for use as 6to4 relay 166 anycast addresses, according to [RFC3068]. 168 192.168.0.0/16 - This block is set aside for use in private networks. 169 Its intended use is documented in [RFC1918]. Addresses within this 170 block should not appear on the public Internet. 172 198.18.0.0/15 - This block has been allocated for use in benchmark 173 tests of network interconnect devices. Its use is documented in 174 [RFC2544]. 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 (sub-)net of 184 the source. The remainder of this space is reserved for future use. 186 5. Summary Table 188 Address Block Present Use Reference 189 ------------------------------------------------------------------ 190 10.0.0.0/8 Private-Use Networks RFC1918 191 128.0.0.0/16 Subject to assignment 192 169.254.0.0/16 Link Local -- 193 172.16.0.0/12 Private-Use Networks RFC1918 194 192.0.2.0/24 Test-Net 195 192.88.99.0/24 6to4 Relay Anycast RFC3068 196 192.168.0.0/16 Private-Use Networks RFC1918 197 198.18.0.0/15 Network Interconnect 198 Device Benchmark Testing RFC2544 199 224.0.0.0/4 Multicast RFC3171 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 [RFC1797] Internet Assigned Numbers Authority (IANA), "Class A 269 Subnet Experiment", RFC 1797, April 1995. 271 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 272 E. Lear, "Address Allocation for Private Internets", 273 BCP 5, RFC 1918, February 1996. 275 [RFC2050] Hubbard, K., Kosters, M., Conrad, D., Karrenberg, D., and 276 J. Postel, "INTERNET REGISTRY IP ALLOCATION GUIDELINES", 277 BCP 12, RFC 2050, November 1996. 279 [RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for 280 Network Interconnect Devices", RFC 2544, March 1999. 282 [RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of 283 Understanding Concerning the Technical Work of the 284 Internet Assigned Numbers Authority", RFC 2860, June 2000. 286 [RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", 287 RFC 3068, June 2001. 289 [RFC3171] Albanna, Z., Almeroth, K., Meyer, D., and M. Schipper, 290 "IANA Guidelines for IPv4 Multicast Address Assignments", 291 BCP 51, RFC 3171, August 2001. 293 [RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by 294 an On-line Database", RFC 3232, January 2002. 296 [RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330, 297 September 2002. 299 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 300 Configuration of IPv4 Link-Local Addresses", RFC 3927, 301 May 2005. 303 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 304 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 305 May 2008. 307 Author's Address 309 Michelle Cotton 310 Internet Corporation for Assigned Names and Numbers 311 4676 Admiralty Way, Suite 330 312 Marina del Rey 90292 313 United States 315 Phone: +310-823-9358 316 Email: michelle.cotton@icann.org 317 URI: http://www.iana.org/ 319 Full Copyright Statement 321 Copyright (C) The IETF Trust (2008). 323 This document is subject to the rights, licenses and restrictions 324 contained in BCP 78, and except as set forth therein, the authors 325 retain all their rights. 327 This document and the information contained herein are provided on an 328 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 329 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 330 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 331 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 332 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 333 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 335 Intellectual Property 337 The IETF takes no position regarding the validity or scope of any 338 Intellectual Property Rights or other rights that might be claimed to 339 pertain to the implementation or use of the technology described in 340 this document or the extent to which any license under such rights 341 might or might not be available; nor does it represent that it has 342 made any independent effort to identify any such rights. Information 343 on the procedures with respect to rights in RFC documents can be 344 found in BCP 78 and BCP 79. 346 Copies of IPR disclosures made to the IETF Secretariat and any 347 assurances of licenses to be made available, or the result of an 348 attempt made to obtain a general license or permission for the use of 349 such proprietary rights by implementers or users of this 350 specification can be obtained from the IETF on-line IPR repository at 351 http://www.ietf.org/ipr. 353 The IETF invites any interested party to bring to its attention any 354 copyrights, patents or patent applications, or other proprietary 355 rights that may cover technology that may be required to implement 356 this standard. Please address the information to the IETF at 357 ietf-ipr@ietf.org.