RFC 5735
Special Use IPv4 Addresses
RFC 5735: Special Use IPv4 Addresses 🎀
Okay bestie, the title block first 📜 This is RFC 5735, called Special Use IPv4 Addresses, and it's from the IETF (Internet Engineering Task Force). It's a Best Current Practice, specifically BCP 153, with ISSN 2070-1721. It was written by M. Cotton and L. Vegoda from ICANN, and it's dated January 2010. Important bit: it obsoletes RFC 3330 🦋
Abstract 💖
So the abstract is giving "here's what this doc covers" 💅 It obsoletes RFC 3330 and describes the global and other specialized IPv4 address blocks that IANA (the Internet Assigned Numbers Authority) has assigned. It does not cover IPv4 space handed out to operators and users through the Regional Internet Registries, and it does not cover IPv4 space IANA assigned directly before the RIRs existed. It also doesn't touch IPv6 addresses or autonomous system numbers, so don't go looking for those here 🙈
Status of This Memo 📝
This memo documents an Internet Best Current Practice ✨
This is an IETF product, and it represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). If you want more on BCPs, check out Section 2 of RFC 5741 🌸
For the current status of this document, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc5735 🔥
Copyright Notice 💜
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved ©️
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, which you can find at http://trustee.ietf.org/license-info, as they stand on the publication date. Please read these carefully, because they spell out your rights and restrictions for this document 🫶 Any Code Components pulled out of this document must include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Simplified BSD License describes.
Table of Contents 🗺️
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Global and Other Specialized Address Blocks . . . . . . . . . 3
4. Summary Table . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Assignments of IPv4 Blocks for New Specialized Uses . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
9.1. Normative References . . . . . . . . . . . . . . . . . . . 7
9.2. Informative References . . . . . . . . . . . . . . . . . . 7
Appendix A. Differences between This Document and RFC 3330 . . . 101. Introduction ✨
Okay so the Internet has always had a central IANA (Internet Assigned Numbers Authority) in charge of handing out the identifiers it needs to run [RFC1174] 👑 For the IPv4 address space, IANA gives chunks to the Regional Internet Registries (RIRs) based on what each region actually needs. The RIRs then register IPv4 addresses to operators and users in their own regions 🌍
The IETF has also designated IANA to make assignments that support the Internet Standards Process, on an ongoing basis [RFC2860]. Section 4 of that document describes how that assignment process works 💅
Some small bits of IPv4 space have been allocated or assigned directly by IANA for global or other specialized purposes. Those allocations are scattered across a bunch of RFCs and other documents, and this doc is here to gather them all up and give you a current list of special use IPv4 addresses 🦋
This document is a revision of RFC 3330 [RFC3330], which it obsoletes. Its main job is to reflect the changes to the list of special IPv4 assignments made since RFC 3330 came out. It's a companion to [RFC5156], which covers special IPv6 addresses 🧚
2. Terminology 🌈
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, [RFC2119] 💜
3. Global and Other Specialized Address Blocks 🍓
Okay, this section is the main event, so let's go block by block 💖
0.0.0.0/8 - Addresses in this block refer to source hosts on "this" network. Address 0.0.0.0/32 may be used as a source address for this host on this network. Other addresses within 0.0.0.0/8 may be used to refer to specified hosts on this network ([RFC1122], Section 3.2.1.3) ✨
10.0.0.0/8 - This block is set aside for private networks. Its intended use is documented in [RFC1918]. As that RFC describes, addresses in this block do not legitimately appear on the public Internet. You can use them without any coordination with IANA or an Internet registry, no permission needed 🔥
127.0.0.0/8 - This block is assigned for use as the Internet host loopback address. A datagram that a higher-level protocol sends to any address in this block loops back inside the host. This is ordinarily implemented using only 127.0.0.1/32 for loopback. As described in [RFC1122], Section 3.2.1.3, addresses in the entire 127.0.0.0/8 block do not legitimately appear on any network anywhere 🪞
169.254.0.0/16 - This is the "link local" block. As described in [RFC3927], it's allocated for communication between hosts on a single link. Hosts get these addresses through auto-configuration, for example when a DHCP server can't be found ⭐
172.16.0.0/12 - This block is set aside for private networks too. Its intended use is documented in [RFC1918]. As that RFC describes, addresses in this block do not legitimately appear on the public Internet, and you can use them without any coordination with IANA or an Internet registry 💅
192.0.0.0/24 - This block is reserved for IETF protocol assignments. At the time this document was written, there are no current assignments. Allocation policy for future assignments is given in [RFC5736] 🎀
192.0.2.0/24 - This block is assigned as "TEST-NET-1" for use in documentation and example code. It's often used together with the domain names example.com or example.net in vendor and protocol documentation. As described in [RFC5737], addresses in this block do not legitimately appear on the public Internet, and you can use them without any coordination with IANA or an Internet registry. See also [RFC1166] 🦋
192.88.99.0/24 - This block is allocated for use as 6to4 relay anycast addresses, in [RFC3068]. Unlike the blocks we've covered so far, packets sent to addresses from this block do appear on the public Internet 👀 [RFC3068], Section 7, describes operational practices for preventing malicious use of this block in routing protocols 🛡️
192.168.0.0/16 - This block is set aside for private networks as well. Its intended use is documented in [RFC1918]. As that RFC describes, addresses in this block do not legitimately appear on the public Internet, and you can use them without any coordination with IANA or an Internet registry 🌸
198.18.0.0/15 - This block has been allocated for use in benchmark tests of network interconnect devices. [RFC2544] explains that this range was assigned to minimize the chance of conflict in case a testing device were accidentally connected to part of the Internet. Packets with source addresses from this range are not meant to be forwarded across the Internet 🧪
198.51.100.0/24 - This block is assigned as "TEST-NET-2" for use in documentation and example code. It's often used together with the domain names example.com or example.net in vendor and protocol documentation. As described in [RFC5737], addresses in this block do not legitimately appear on the public Internet, and you can use them without any coordination with IANA or an Internet registry 💖
203.0.113.0/24 - This block is assigned as "TEST-NET-3" for use in documentation and example code. It's often used together with the domain names example.com or example.net in vendor and protocol documentation. As described in [RFC5737], addresses in this block do not legitimately appear on the public Internet, and you can use them without any coordination with IANA or an Internet registry 🫧
224.0.0.0/4 - This block, formerly known as the Class D address space, is allocated for IPv4 multicast address assignments. The IANA guidelines for assignments from this space are described in [RFC3171] 📣
240.0.0.0/4 - This block, formerly known as the Class E address space, is reserved for future use; see [RFC1112], Section 4 🔮
The one exception to all of this is the "limited broadcast" destination address 255.255.255.255. As described in [RFC0919] and [RFC0922], packets with this destination address are not forwarded at the IP layer 📢
Section 4 (the Summary Table) and everything after it picks up in part 2 💅
5. Assignments of IPv4 Blocks for New Specialized Uses ✨
okay so the IANA is basically the protocol-parameter assignment queen 👑. It hands out the numbers and values the Internet runs on, and it has to follow the rules in "Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority" [RFC2860]. Under [RFC2860], parameters get assigned according to the criteria and procedures in RFCs, including Proposed, Draft, and full Internet Standards and Best Current Practice documents, plus any other RFC that asks for IANA assignment 💅
the domain name and IP address spaces are a whole different vibe because they come with policy issues on top of the technical ones 🌸 so [RFC2860] doesn't apply to them in general. the IANA still makes sure IPv4 addresses get assigned when the Internet Standards Process needs them. if an RFC needs a specific chunk of IPv4 space, the technical requirements for that chunk (like its size or prefix length) should be described [RFC5226]. right before the RFC gets published, the IANA will make the assignment in consultation with the Regional Internet Registries, then tell the RFC Editor the details so they go into the published RFC 🦋
and as [RFC2860] requires, the IANA will also make any necessary experimental assignments of IPv4 addresses, again in consultation with the Regional Internet Registries 🫶
6. IANA Considerations
this section is giving "nothing new here, just vibes" 😌 the document describes what the IANA has done in the past and what it does now. it doesn't create any new requirements for assignments or allocations by the IANA 🧚
7. Security Considerations
okay this one is SERIOUS bestie 😭 the particular assigned values of special use IPv4 addresses in this document don't directly raise security issues. BUT the Internet does not inherently protect against abuse of these addresses 💀
for example, if you expect that all packets from a private address space like 10.0.0.0/8 or the link local block 169.254.0.0/16 come from inside your subnet, then all routers at the border of your network should filter packets from those ranges that originate from outside your network. attacks have actually been mounted that depend on unexpected use of some of these addresses 🙈
some of these address spaces can be used legitimately outside a single administrative domain, and they may show up on the global Internet. so security policy SHOULD NOT blindly filter all of these address spaces without due consideration. network operators are encouraged to review this document and the references in it, and figure out what security policies belong with each address block in their own operating environment 🔥
8. Acknowledgments
so many people commented on draft versions of this document 🎀 the authors especially want to thank Scott Bradner, Randy Bush, Harald Alvestrand, Peter Koch, Alfred Hoenes, and Jari Arkko for their constructive feedback and comments 🫶 they also want to give a special shoutout to APNIC, which nominated 198.51.100.0/24 and 203.0.113.0/24 🌈
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.9.2. Informative References
[RFC0919] Mogul, J., "Broadcasting Internet Datagrams", STD 5,
RFC 919, October 1984.
[RFC0922] Mogul, J., "Broadcasting Internet datagrams in the
presence of subnets", STD 5, RFC 922, October 1984.
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5,
RFC 1112, August 1989.
[RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1166] Kirkpatrick, S., Stahl, M., and M. Recker, "Internet
numbers", RFC 1166, July 1990.
[RFC1174] Cerf, V., "IAB recommended policy on distributing internet
identifier assignment and IAB recommended policy change to
internet "connected" status", RFC 1174, August 1990.
[RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700,
October 1994.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.
[RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for
Network Interconnect Devices", RFC 2544, March 1999.
[RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of
Understanding Concerning the Technical Work of the
Internet Assigned Numbers Authority", RFC 2860, June 2000.
[RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers",
RFC 3068, June 2001.
[RFC3171] Albanna, Z., Almeroth, K., Meyer, D., and M. Schipper,
"IANA Guidelines for IPv4 Multicast Address Assignments",
BCP 51, RFC 3171, August 2001.
[RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330,
September 2002.
[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
Configuration of IPv4 Link-Local Addresses", RFC 3927,
May 2005.
[RFC5156] Blanchet, M., "Special-Use IPv6 Addresses", RFC 5156,
April 2008.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC5736] Huston, G., Cotton, M., and L. Vegoda, "IANA IPv4 Special
Purpose Address Registry", RFC 5736, January 2010.
[RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks
Reserved for Documentation", RFC 5737, January 2010.Appendix A. Differences between This Document and RFC 3330 📚
okay so some address blocks were reserved for a special purpose in RFC 3330, but they aren't reserved for any special purpose anymore and are available for allocation. so they're no longer listed in Sections 4 or 5 👀 these blocks have become available:
14.0.0.0/8is no longer set aside for assignments to the international system of Public Data Networks [RFC1700], page 181. It is now available for allocation to RIRs in the normal way.24.0.0.0/8is no longer listed, because the addresses in that block have been managed by the American Registry for Internet Numbers (ARIN) in the normal way since 2001.39.0.0.0/8is no longer listed, because it has been subject to allocation to an RIR for assignment in the normal manner since 2001.128.0.0.0/16is not reserved and is subject to future allocation by a Regional Internet Registry for assignment in the normal manner.191.255.0.0/16is not reserved and is subject to future allocation by a RIR for assignment in the normal manner.198.51.100.0/24is assigned as "TEST-NET-2" for use in documentation and example code 🧪203.0.113.0/24is assigned as "TEST-NET-3" for use in documentation and example code 🧪223.255.255.0/24is not reserved and is subject to future allocation by an RIR for assignment in the normal manner.
Authors' Addresses 🖋️
these are the two bestie authors who wrote it, both at ICANN 💜
Michelle Cotton
Internet Corporation for Assigned Names and Numbers
4676 Admiralty Way, Suite 330
Marina del Rey, CA 90292
USA
Phone: +1-310-823-9358
EMail: michelle.cotton@icann.org
URI: http://www.iana.org/
Leo Vegoda
Internet Corporation for Assigned Names and Numbers
4676 Admiralty Way, Suite 330
Marina del Rey, CA 90292
USA
Phone: +1-310-823-9358
EMail: leo.vegoda@icann.org
URI: http://www.iana.org/📦 where this page comes from
- ietf: rfc5735 2010-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms