idnits 2.17.1 draft-iana-rfc3330bis-11.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 15 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance 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 4 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 (August 19, 2009) is 5363 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) == Outdated reference: A later version (-02) exists of draft-iana-ipv4-examples-01 == Outdated reference: A later version (-02) exists of draft-iana-special-ipv4-registry-01 -- 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 (==), 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 L. Vegoda 4 Obsoletes: 3330 (if approved) ICANN 5 Intended status: BCP August 19, 2009 6 Expires: February 20, 2010 8 Special Use IPv4 Addresses 9 draft-iana-rfc3330bis-11 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 February 20, 2010. 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 in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 This document obsoletes RFC 3330. It describes the global and other 48 specialized IPv4 address blocks that have been assigned by the 49 Internet Assigned Numbers Authority (IANA). It does not address IPv4 50 address space assigned to operators and users through the Regional 51 Internet Registries, nor does it address IPv4 address space assigned 52 directly by IANA prior to the creation of the Regional Internet 53 Registries. It also does not address allocations or assignments of 54 IPv6 addresses or autonomous system numbers. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Global and Other Specialized Address Blocks . . . . . . . . . 3 61 4. Summary Table . . . . . . . . . . . . . . . . . . . . . . . . 6 62 5. Assignments of IPv4 Blocks for New Specialized Uses . . . . . 6 63 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 64 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 65 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 66 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 68 9.2. Informative References . . . . . . . . . . . . . . . . . . 8 69 Appendix A. Differences between this document and RFC 3330 . . . 9 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 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 RIRs are 80 responsible for the registration of IPv4 addresses to operators and 81 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 4 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 reflect the changes to the list 96 of special IPv4 assignments since the publication of RFC 3330. It is 97 a companion to [RFC5156] which describes special IPv6 addresses. 99 2. Terminology 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in BCP 14, [RFC2119]. 105 3. Global and Other Specialized Address Blocks 107 0.0.0.0/8 - Addresses in this block refer to source hosts on "this" 108 network. Address 0.0.0.0/32 may be used as a source address for this 109 host on this network; other addresses within 0.0.0.0/8 may be used to 110 refer to specified hosts on this network [RFC1122], section 3.2.1.3. 112 10.0.0.0/8 - This block is set aside for use in private networks. 113 Its intended use is documented in [RFC1918]. As described in that 114 RFC, addresses within this block do not legitimately appear on the 115 public Internet. These addresses can be used without any 116 coordination with IANA or an Internet registry. 118 127.0.0.0/8 - This block is assigned for use as the Internet host 119 loopback address. A datagram sent by a higher level protocol to an 120 address anywhere within this block loops back inside the host. This 121 is ordinarily implemented using only 127.0.0.1/32 for loopback. As 122 described in [RFC1122], Section 3.2.1.3, addresses within the entire 123 127.0.0.0/8 block do not legitimately appear on any network anywhere. 125 169.254.0.0/16 - This is the "link local" block. As described in 126 [RFC3927], it is allocated for communication between hosts on a 127 single link. Hosts obtain these addresses by auto-configuration, 128 such as when a DHCP server cannot be found. 130 172.16.0.0/12 - This block is set aside for use in private networks. 131 Its intended use is documented in [RFC1918]. As described in that 132 RFC, addresses within this block do not legitimately appear the 133 public Internet. These addresses can be used without any 134 coordination with IANA or an Internet registry. 136 192.0.0.0/24 - This block is reserved for IETF protocol assignments. 137 At the time of writing this document, there are no current 138 assignments. Allocation policy for future assignments is given in 139 [I-D.iana-special-ipv4-registry]. 141 192.0.2.0/24 - This block is assigned as "TEST-NET-1" for use in 142 documentation and example code. It is often used in conjunction with 143 domain names example.com or example.net in vendor and protocol 144 documentation. As described in [I-D.iana-ipv4-examples], addresses 145 within this block do not legitimately appear on the public Internet 146 and can be used without any coordination with IANA or an Internet 147 registry. See [RFC1166]. 149 192.88.99.0/24 - This block is allocated for use as 6to4 relay 150 anycast addresses, in to [RFC3068]. In contrast with previously 151 described blocks, packets destined to addresses from this block do 152 appear in the public Internet. [RFC3068], Section 7 describes 153 operational practices to prevent the malicious use of this block in 154 routing protocols. 156 192.168.0.0/16 - This block is set aside for use in private networks. 157 Its intended use is documented in [RFC1918]. As described in that 158 RFC, addresses within this block do not legitimately appear the 159 public Internet. These addresses can be used without any 160 coordination with IANA or an Internet registry. 162 198.18.0.0/15 - This block has been allocated for use in benchmark 163 tests of network interconnect devices. [RFC2544] explains that this 164 range was assigned to minimize the chance of conflict in case a 165 testing device were to be accidentally connected to part of the 166 Internet. Packets with source addresses from this range are not 167 meant to be forwarded across the Internet. 169 198.51.100.0/24 - This block is assigned as "TEST-NET-2" for use in 170 documentation and example code. It is often used in conjunction with 171 domain names example.com or example.net in vendor and protocol 172 documentation. As described in [I-D.iana-ipv4-examples], addresses 173 within this block do not legitimately appear on the public Internet 174 and can be used without any coordination with IANA or an Internet 175 registry. 177 203.0.113.0/24 - This block is assigned as "TEST-NET-3" for use in 178 documentation and example code. It is often used in conjunction with 179 domain names example.com or example.net in vendor and protocol 180 documentation. As described in [I-D.iana-ipv4-examples], addresses 181 within this block do not legitimately appear on the public Internet 182 and can be used without any coordination with IANA or an Internet 183 registry. 185 224.0.0.0/4 - This block, formerly known as the Class D address 186 space, is allocated for use in IPv4 multicast address assignments. 187 The IANA guidelines for assignments from this space are described in 188 [RFC3171]. 190 240.0.0.0/4 - This block, formerly known as the Class E address 191 space, is reserved for future use, see [RFC1112], section 4. 193 The one exception to this is the "limited broadcast" destination 194 address 255.255.255.255. As described in [RFC0919] and [RFC0922], 195 packets with this destination address are not forwarded at IP layer. 197 4. Summary Table 199 Address Block Present Use Reference 200 ------------------------------------------------------------------ 201 0.0.0.0/8 "This" Network RFC 1122, section 3.2.1.3 202 10.0.0.0/8 Private-Use Networks RFC 1918 203 127.0.0.0/8 Loopback RFC 1122, section 3.2.1.3 204 169.254.0.0/16 Link Local RFC 3927 205 172.16.0.0/12 Private-Use Networks RFC 1918 206 192.0.0.0/24 IETF Protocol Assignments 207 192.0.2.0/24 TEST-NET-1 draft-iana-ipv4-examples 208 192.88.99.0/24 6to4 Relay Anycast RFC 3068 209 192.168.0.0/16 Private-Use Networks RFC 1918 210 198.18.0.0/15 Network Interconnect 211 Device Benchmark Testing RFC 2544 212 198.51.100.0/24 TEST-NET-2 draft-iana-ipv4-examples 213 203.0.113.0/24 TEST-NET-3 draft-iana-ipv4-examples 214 224.0.0.0/4 Multicast RFC 3171 215 240.0.0.0/4 Reserved for Future Use RFC 1112, section 4 216 255.255.255.255/32 Limited Broadcast RFC 919, section 7 218 5. Assignments of IPv4 Blocks for New Specialized Uses 220 The IANA has responsibility for making assignments of protocol 221 parameters used in the Internet according to the requirements of the 222 "Memorandum of Understanding Concerning the Technical Work of the 223 Internet Assigned Numbers Authority" [RFC2860]. Among other things, 224 [RFC2860] requires that protocol parameters be assigned according to 225 the criteria and procedures specified in RFCs, including Proposed, 226 Draft, and full Internet Standards and Best Current Practice 227 documents, and any other RFC that calls for IANA assignment. 229 The domain name and IP address spaces involve policy issues (in 230 addition to technical issues) so that the requirements of [RFC2860] 231 do not apply generally to those spaces. Nonetheless, the IANA is 232 responsible for ensuring assignments of IPv4 addresses as needed in 233 support of the Internet Standards Process. When a portion of the 234 IPv4 address space is specifically required by an RFC, the technical 235 requirements (e.g., size, prefix length) for the portion should be 236 described [RFC5226]. Immediately before the RFC is published, the 237 IANA will, in consultation with the Regional Internet Registries, 238 make the necessary assignment and notify the RFC Editor of the 239 particulars for inclusion in the RFC as published. 241 As required by [RFC2860], the IANA will also make necessary 242 experimental assignments of IPv4 addresses, also in consultation with 243 the Regional Internet Registries. 245 6. IANA Considerations 247 This document describes the IANA's past and current practices and 248 does not create any new requirements for assignments or allocations 249 by the IANA. 251 7. Security Considerations 253 The particular assigned values of special use IPv4 addresses 254 cataloged in this document do not directly raise security issues. 255 However, the Internet does not inherently protect against abuse of 256 these addresses; if you expect (for instance) that all packets from a 257 private address space such as the 10.0.0.0/8 block or the link local 258 block 169.254.0.0/16 originate within your subnet, all routers at the 259 border of your network should filter such packets that originate from 260 outside your network. Attacks have been mounted that depend on the 261 unexpected use of some of these addresses. 263 It should also be noted that some of these address spaces may be used 264 legitimately outside of a single administrative domain, and may 265 appear on the global Internet. Security policy SHOULD NOT blindly 266 filter all of these address spaces without due consideration, and 267 network operators are encouraged to review this document, and 268 references contained therein, and determine what security policies 269 should be associated with each of these address blocks within their 270 specific operating environments. 272 8. Acknowledgments 274 Many people have made comments on draft versions of this document. 275 The authors would especially like to thank Scott Bradner, Randy Bush, 276 Harald Alvestrand, Peter Koch, Alfred Hoenes and Jari Arkko for their 277 constructive feedback and comments. They would also like to offer a 278 special note of thanks to APNIC, which nominated 198.51.100.0/24 and 279 203.0.113.0/24. 281 9. References 282 9.1. Normative References 284 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 285 Requirement Levels", BCP 14, RFC 2119, March 1997. 287 9.2. Informative References 289 [I-D.iana-ipv4-examples] 290 Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks 291 Reserved for Documentation", draft-iana-ipv4-examples-01 292 (work in progress), June 2009. 294 [I-D.iana-special-ipv4-registry] 295 Huston, G., Cotton, M., and L. Vegoda, "IANA IPv4 Special 296 Purpose Address Registry", 297 draft-iana-special-ipv4-registry-01 (work in progress), 298 February 2009. 300 [RFC0919] Mogul, J., "Broadcasting Internet Datagrams", STD 5, 301 RFC 919, October 1984. 303 [RFC0922] Mogul, J., "Broadcasting Internet datagrams in the 304 presence of subnets", STD 5, RFC 922, October 1984. 306 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 307 RFC 1112, August 1989. 309 [RFC1122] Braden, R., "Requirements for Internet Hosts - 310 Communication Layers", STD 3, RFC 1122, October 1989. 312 [RFC1166] Kirkpatrick, S., Stahl, M., and M. Recker, "Internet 313 numbers", RFC 1166, July 1990. 315 [RFC1174] Cerf, V., "IAB recommended policy on distributing internet 316 identifier assignment and IAB recommended policy change to 317 internet "connected" status", RFC 1174, August 1990. 319 [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, 320 October 1994. 322 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 323 E. Lear, "Address Allocation for Private Internets", 324 BCP 5, RFC 1918, February 1996. 326 [RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for 327 Network Interconnect Devices", RFC 2544, March 1999. 329 [RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of 330 Understanding Concerning the Technical Work of the 331 Internet Assigned Numbers Authority", RFC 2860, June 2000. 333 [RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", 334 RFC 3068, June 2001. 336 [RFC3171] Albanna, Z., Almeroth, K., Meyer, D., and M. Schipper, 337 "IANA Guidelines for IPv4 Multicast Address Assignments", 338 BCP 51, RFC 3171, August 2001. 340 [RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330, 341 September 2002. 343 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 344 Configuration of IPv4 Link-Local Addresses", RFC 3927, 345 May 2005. 347 [RFC5156] Blanchet, M., "Special-Use IPv6 Addresses", RFC 5156, 348 April 2008. 350 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 351 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 352 May 2008. 354 Appendix A. Differences between this document and RFC 3330 356 Address blocks that were reserved for a special purpose in RFC 3330 357 but are no longer reserved for any special purpose and are available 358 for allocation are no longer listed in Sections 4 or 5. The 359 following blocks have become available: 361 - 14.0.0.0/8 is no longer set aside for assignments to the 362 international system of Public Data Networks [RFC1700], page 181. It 363 is now available for allocation to RIRs in the normal way; 365 - 24.0.0.0/8 is no longer listed as the addresses in that block have 366 been managed by the American Registry for Internet Numbers (ARIN) in 367 the normal way since 2001; 369 - 39.0.0.0/8 is no longer listed as it has been subject to allocation 370 to an RIR for assignment in the normal manner since 2001; 372 - 128.0.0.0/16 is not reserved and is subject to future allocation by 373 a Regional Internet Registry for assignment in the normal manner; 375 - 191.255.0.0/16 is not reserved and is subject to future allocation 376 by a RIR for assignment in the normal manner; and 377 - 198.51.100.0/24 is assigned as "TEST-NET-2" for use in 378 documentation and example code. 380 - 203.0.113.0/24 is assigned as "TEST-NET-3" for use in documentation 381 and example code. 383 - 223.255.255.0/24 is not reserved and is subject to future 384 allocation by an RIR for assignment in the normal manner. 386 Authors' Addresses 388 Michelle Cotton 389 Internet Corporation for Assigned Names and Numbers 390 4676 Admiralty Way, Suite 330 391 Marina del Rey 90292 392 United States of America 394 Phone: +310-823-9358 395 Email: michelle.cotton@icann.org 396 URI: http://www.iana.org/ 398 Leo Vegoda 399 Internet Corporation for Assigned Names and Numbers 400 4676 Admiralty Way, Suite 330 401 Marina del Rey 90292 402 United States of America 404 Phone: +310-823-9358 405 Email: leo.vegoda@icann.org 406 URI: http://www.iana.org/