idnits 2.17.1 draft-iana-rfc3330bis-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 8 form feeds but 31 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 and authors 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 (January 21, 2009) is 5574 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC5156' is defined on line 314, 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: 0 errors (**), 0 flaws (~~), 6 warnings (==), 9 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) January 21, 2009 5 Intended status: Informational 6 Expires: July 25, 2009 8 Special Use IPv4 Addresses 9 draft-iana-rfc3330bis-05 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and 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 25, 2009. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. 46 Abstract 48 This document obsoletes RFC 3330. It describes the global and other 49 specialized IPv4 address blocks that have been assigned by the 50 Internet Assigned Numbers Authority (IANA). It does not address IPv4 51 address space assigned to operators and users through the Regional 52 Internet Registries. It also does not address allocations or 53 assignments of IPv6 addresses or autonomous system numbers. Special 54 IPv6 addresses are described in RFC 5156. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Differences between this document and RFC 3330 . . . . . . . . 3 61 4. Global and Other Specialized Address Blocks . . . . . . . . . . 4 62 5. Summary Table . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 6. Assignments of IPv4 Blocks for New Specialized Uses . . . . . . 6 64 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 65 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 66 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7 67 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 10.1. Normative References . . . . . . . . . . . . . . . . . . . 7 69 10.2. Informative References . . . . . . . . . . . . . . . . . . 7 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 1. Introduction 74 Throughout its history, the Internet has employed a central Internet 75 Assigned Numbers Authority (IANA) responsible for the allocation and 76 assignment of various identifiers needed for the operation of the 77 Internet [RFC1174]. In the case of the IPv4 address space, the IANA 78 allocates parts of the address space to Regional Internet Registries 79 (RIRs) according to their established needs. These Regional Internet 80 Registries are responsible for the registration of IPv4 addresses to 81 operators and users of the Internet within their regions. 83 On an ongoing basis, the IANA has been designated by the IETF to make 84 assignments in support of the Internet Standards Process [RFC2860]. 85 Section 5 of this document describes that assignment process. 87 Small portions of the IPv4 address space have been allocated or 88 assigned directly by the IANA for global or other specialized 89 purposes. These allocations and assignments have been documented in 90 a variety of RFCs and other documents. This document is intended to 91 collect these scattered references and provide a current list of 92 special use IPv4 addresses. 94 This document is a revision of RFC 3330 [RFC3330], which it 95 obsoletes; its primary purpose is to re-publish the technical content 96 of RFC 3330 mostly unchanged as a Best Current Practice RFC. 98 The terms "Specification Required", "Expert Review", "IESG Approval", 99 "IETF Consensus", and "Standards Action", are used in this memo to 100 refer to the processes described in [RFC5226]. The keywords MUST, 101 MUST NOT, MAY, OPTIONAL, REQUIRED, RECOMMENDED, SHALL, SHALL NOT, 102 SHOULD, SHOULD NOT are to be interpreted as defined in [RFC2119]. 104 2. Terminology 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in BCP 14, [RFC2119]. 110 3. Differences between this document and RFC 3330 112 Address blocks that were reserved for a special purpose in RFC 3330 113 but are no longer reserved for any special purpose and are available 114 for allocation are no longer listed in Sections 4 or 5. The 115 following blocks have become available: 117 - 14.0.0.0/8 is no longer set aside for assignments to the 118 international system of Public Data Networks [RFC1700], page 181]. 119 It is now available for allocation to RIRs in the normal way; 121 - 24.0.0.0/8 is no longer listed as the addresses in that block have 122 been managed by the American Registry for Internet Numbers (ARIN) in 123 the normal way since 2001. 125 - 39.0.0.0/8 is no longer listed as it has been subject to allocation 126 to an RIR for assignment in the normal manner since 2001; 128 - 128.0.0.0/16 is not reserved and is subject to future allocation by 129 a Regional Internet Registry for assignment in the normal manner; 131 - 191.255.0.0/16 is not reserved and is subject to future allocation 132 by a RIR for assignment in the normal manner; 134 - 223.255.255.0/24 is not reserved and is subject to future 135 allocation by an RIR for assignment in the normal manner. 137 4. Global and Other Specialized Address Blocks 139 0.0.0.0/8 - Addresses in this block refer to source hosts on "this" 140 network. Address 0.0.0.0/32 may be used as a source address for this 141 host on this network; other addresses within 0.0.0.0/8 may be used to 142 refer to specified hosts on this network [RFC1122], page 30. 144 10.0.0.0/8 - This block is set aside for use in private networks. 145 Its intended use is documented in [RFC1918]. Addresses within this 146 block should not appear on the public Internet and can be used 147 without any coordination with IANA or an Internet registry. 149 127.0.0.0/8 - This block is assigned for use as the Internet host 150 loopback address. A datagram sent by a higher level protocol to an 151 address anywhere within this block should loop back inside the host. 152 This is ordinarily implemented using only 127.0.0.1/32 for loopback, 153 but no addresses within this block should ever appear on any network 154 anywhere [RFC1122], page 31. 156 169.254.0.0/16 - This is the "link local" block. As described in 157 [RFC3927], it is allocated for communication between hosts on a 158 single link. Hosts obtain these addresses by auto-configuration, 159 such as when a DHCP server cannot be found. 161 172.16.0.0/12 - This block is set aside for use in private networks. 162 Its intended use is documented in [RFC1918]. Addresses within this 163 block should not appear on the public Internet and can be used 164 without any coordination with IANA or an Internet registry. 166 192.0.0.0/24 - This block is reserved for IETF protocol assignments. 168 192.0.2.0/24 - This block is assigned as "TEST-NET" for use in 169 documentation and example code. It is often used in conjunction with 170 domain names example.com or example.net in vendor and protocol 171 documentation. Addresses within this block SHOULD NOT appear on the 172 public Internet and can be used without any coordination with IANA or 173 an Internet registry. 175 192.88.99.0/24 - This block is allocated for use as 6to4 relay 176 anycast addresses, according to [RFC3068]. 178 192.168.0.0/16 - This block is set aside for use in private networks. 179 Its intended use is documented in [RFC1918]. Addresses within this 180 block should not appear on the public Internet and can be used 181 without any coordination with IANA or an Internet registry. 183 198.18.0.0/15 - This block has been allocated for use in benchmark 184 tests of network interconnect devices. [RFC2544] explains that this 185 range was assigned to minimize the chance of conflict in case a 186 testing device were to be accidentally connected to part of the 187 Internet. Packets with source addresses from this range are not 188 meant to be forwarded across the Internet. 190 224.0.0.0/4 - This block, formerly known as the Class D address 191 space, is allocated for use in IPv4 multicast address assignments. 192 The IANA guidelines for assignments from this space are described in 193 [RFC3171]. 195 240.0.0.0/4 - This block, formerly known as the Class E address 196 space, is reserved. The "limited broadcast" destination address 197 255.255.255.255 should never be forwarded outside the local network 198 of the source. The remainder of this space is reserved for future 199 use. [RFC1112], page 2. 201 5. Summary Table 203 Address Block Present Use Reference 204 ------------------------------------------------------------------ 205 10.0.0.0/8 Private-Use Networks RFC 1918 206 169.254.0.0/16 Link Local RFC 3927 207 172.16.0.0/12 Private-Use Networks RFC 1918 208 192.0.0.0/24 IETF Protocol Assignments 209 192.0.2.0/24 Test-Net 210 192.88.99.0/24 6to4 Relay Anycast RFC 3068 211 192.168.0.0/16 Private-Use Networks RFC 1918 212 198.18.0.0/15 Network Interconnect 213 Device Benchmark Testing RFC 2544 214 224.0.0.0/4 Multicast RFC 3171 216 6. Assignments of IPv4 Blocks for New Specialized Uses 218 The IANA has responsibility for making assignments of protocol 219 parameters used in the Internet according to the requirements of the 220 "Memorandum of Understanding Concerning the Technical Work of the 221 Internet Assigned Numbers Authority" [RFC2860]. Among other things, 222 [RFC2860] requires that protocol parameters be assigned according to 223 the criteria and procedures specified in RFCs, including Proposed, 224 Draft, and full Internet Standards and Best Current Practice 225 documents, and any other RFC that calls for IANA assignment. 227 The domain name and IP address spaces involve policy issues (in 228 addition to technical issues) so that the requirements of [RFC2860] 229 do not apply generally to those spaces. Nonetheless, the IANA is 230 responsible for ensuring assignments of IPv4 addresses as needed in 231 support of the Internet Standards Process. When a portion of the 232 IPv4 address space is specifically required by an RFC, the technical 233 requirements (e.g., size, prefix length) for the portion should be 234 described [RFC5226]. Immediately before the RFC is published, the 235 IANA will, in consultation with the Regional Internet Registries, 236 make the necessary assignment and notify the RFC Editor of the 237 particulars for inclusion in the RFC as published. 239 As required by [RFC2860], the IANA will also make necessary 240 experimental assignments of IPv4 addresses, also in consultation with 241 the Regional Internet Registries. 243 7. IANA Considerations 245 This document describes the IANA's past and current practices and 246 does not create any new requirements for assignments or allocations 247 by the IANA. 249 8. Security Considerations 251 The particular assigned values of special-use IPv4 addresses 252 cataloged in this document do not directly raise security issues. 253 However, the Internet does not inherently protect against abuse of 254 these addresses; if you expect (for instance) that all packets from 255 the 10.0.0.0/8 block originate within your subnet, all border routers 256 should filter such packets that originate from elsewhere. Attacks 257 have been mounted that depend on the unexpected use of some of these 258 addresses. 260 9. Acknowledgments 262 Many people have made comments on draft versions of this document. 263 The IANA would especially like to thank Scott Bradner, Randy Bush, 264 Leo Vegoda, Harald Alvestrand and the IESG for their constructive 265 feedback and comments. 267 10. References 269 10.1. Normative References 271 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 272 Requirement Levels", BCP 14, RFC 2119, March 1997. 274 10.2. Informative References 276 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 277 RFC 1112, August 1989. 279 [RFC1122] Braden, R., "Requirements for Internet Hosts - 280 Communication Layers", STD 3, RFC 1122, October 1989. 282 [RFC1174] Cerf, V., "IAB recommended policy on distributing internet 283 identifier assignment and IAB recommended policy change to 284 internet "connected" status", RFC 1174, August 1990. 286 [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, 287 October 1994. 289 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 290 E. Lear, "Address Allocation for Private Internets", 291 BCP 5, RFC 1918, February 1996. 293 [RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for 294 Network Interconnect Devices", RFC 2544, March 1999. 296 [RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of 297 Understanding Concerning the Technical Work of the 298 Internet Assigned Numbers Authority", RFC 2860, June 2000. 300 [RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", 301 RFC 3068, June 2001. 303 [RFC3171] Albanna, Z., Almeroth, K., Meyer, D., and M. Schipper, 304 "IANA Guidelines for IPv4 Multicast Address Assignments", 305 BCP 51, RFC 3171, August 2001. 307 [RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330, 308 September 2002. 310 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 311 Configuration of IPv4 Link-Local Addresses", RFC 3927, 312 May 2005. 314 [RFC5156] Blanchet, M., "Special-Use IPv6 Addresses", RFC 5156, 315 April 2008. 317 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 318 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 319 May 2008. 321 Author's Address 323 Michelle Cotton 324 Internet Corporation for Assigned Names and Numbers 325 4676 Admiralty Way, Suite 330 326 Marina del Rey 90292 327 United States 329 Phone: +310-823-9358 330 Email: michelle.cotton@icann.org 331 URI: http://www.iana.org/