IPv4 addresses

In times past, the IPv4 address space was split up into five classses. In modern times, using classes stopped being official address assignment policy of IANA, although there is still some relevance: Class A addresses tend to be owned by larger organizations and have public /8 block sizes, and one eighth of IPv4 addresses have been reserved by nature of being class D and class E addresses (except one address, 255.255.255.255, which has been reserved for a different use). An understanding about the classes is also considered by many to be common knowledge, so it may someday be nice to know about them. For these reasons, information about the old concept of classes is provided here, in part by breaking down information about addresses into categories based on these old classes.

IETF BCP 12: Internet Registry IP Allocation Guidelines (e.g. RFC 2050) refers to IPv4 and “describes the registry system for the distribution of globally unique Internet address space and registry operations. Particularly this document describes the rules and guidelines governing the distribution of this address space.” (The “Abstract” section at the top of that document goes into further details about what the document is and is not meant to cover.) (This BCP 12 (e.g. RFC 2050) updates RFC 1466, which itself an update of RFC 1366. RFC 1466 was referenced by RFC 1597 which was updated by RFC 1918, which became IETF BCP 5: “Address Allocation for Private Internets” (for IPv4).

A number of special-use addresses may be listed by BCP153: Special Use IPv4 Addresses.

Some details (mainly of the larger /8 networks) have been shared by IANA's list of IPv4 address space usage.

Class A
Overview
Class A represented all of the IPv4 addresses that start with a bit cleared to zero, and so this class represented half of all of the IPv4 addresses. The range of numbers are those where the first octet starts with a number of 127 or lower. Most of the first half of these addresses were not assigned to a “Regional Internet Registry”, but some of the first half (meaning addresses with first octet of 63 or lower) were and every /8 network in the entire other half is assigned to either a “Regional Internet Registry” or to IANA.
Special use addresses in the Class A range

Special use addresses in this range include the /8 network numbers of 0, 127, and 10. (This includes any IPv4 address where one of those numbers is the portion before the first period of a dotted quad.)

There are also multiple publicly usable DNS servers located at some addresses with intentionally fairly-easy-to-remember numbers (when the addresses are notated in standard dotted-quad form).

[#0s8]: 0/8
Firewall recommendations
Traffic may involve 0.0.0.0 this address when using automatic addressing. However, other than allowing traffic with that one address, and only to the minimum extent needed for any actual automatic addressing to work, traffic from 0/8 should be blocked from going to or coming from the public Internet, and consider restricting such traffic even for internal use. Although section 3.2.1.3 of RFC 1122 (page 29) (and page 30, mainly section “(a)”) refers to 0/8 as “this” network, presumably allowing traffic to reach a destination on the same subnet as long as the other bits (the host ID bits) match a system on the subnet, and although this is backed up by newer RFCs BCP 153 (section 3): Special Use IPv4 Addresses (section on “Global and Other Specialized Address Blocks”) (e.g. RFC 5735 (section 3) as well as the older version RFC 3330 (section 3)), the reality is that implementation of having 0/8 refer to “this” subnet is not a practice that is commonly supported.
0.0.0.0
Actual implemented usage

Whether any of the RFC's specify this reality or not, the most common purpose is to work similar to IPv6's :: by being an “invalid” address. So, if 32 bits must be used to represent an address for a network card which does not have another valid address, using 0.0.0.0 may indicate that the address is not valid. This usage is so entrenched that people will best be served by considering this usage to be a “de facto” standard. This is a rare example of where RFC standardized documentation is, reasonlessly, widely being not complied with (and the relevant RFC standards probably will not be getting complied with).

Documented standards

The most authoritative documentation on this would be BCP 153 (is/was RFC 5735). However, RFC 5735 references section 3.2.1.3 found on RFC 1122 (page 29) for IPv4 0/8, and is specifically referring to subsections a and b (which are on page 30). (In later subsections, the -1 refers to bit set to 1, as described by glossry: “broadcast address”.)

Some RFC documents, including Section 3.2.1.3 of RFC 1122 (page 29), may refer to this address as “{0, 0}”. That notation is described on the top of page RFC 122 (Internet Hosts Communications) Page 30, where it describes the notation (from the word “We” through “bits.”) The part before the first comma represents the “network”, and the part after the last comma represents the individual host. If there are two commas, the middle number helps to identify the subnet. So, “{0, 0}” is network number zero and host number zero: That equates to an address that is represented by all zeros. If the number -1 is provided, that represents that all the bits for that portion of the address have their value set to 1.

Section 3.2.1.3 of RFC 1122 (page 29) (and page 30, mainly section “(a)”) says this refers to “This host on this network. MUST NOT be sent, except as a source address as part of an initialization procedure by which the host learns its own IP address.” However, refering to “this” network is not commonly supported, and IPv4 0.0.0.0/32 is often treated as an “invalid” or “unassigned” address. (See also section 3.3.6 starting at RFC 1122 (page 66)).

Technically, this address would fit the description of a network ID. However, a generic network ID is described by RFC 1122 page 30 section “(b)”, so presumably the more specific RFC 1122 page 30 section “(a)” is meant to take precedence.

Other addresses in 0/8

RFC 1122 page 30 (in section 3.2.1.3) has similar text to 0.0.0.0.

[#2s8]: 2/8

WIkipedia's list of assigned /8 IPv4 address blocks lists this as RIPE-NCC. Cisco documentation is known to use 2.0.0.2.

[#10s8]: 10/8
Firewalling/routing recommendations

Traffic should not be allowed to or from the public Internet, except that outgoing traffic may be allowed IF the traffic is either:

  • getting routed to another internal device (which should also be implementing this same traffic handling), or...
  • getting translated (using some variation of NAT, possibly including PAT/NAPT).
Overview

(The following paragraph is identical, verbatim, and is also found in the section about IPv4 addresses in the 172.16/12 range and the section about IPv4 addresses in the 192.168/16 range.)

Any IPv4 address where the section of dotted quad notation is “10” is one of the addresses within this range of “private”, locally-assigned (de-centralized) addresses. Although there are objections listed in RFC 1627: “Network 10 Considered Harmful” “(Some Practices Shouldn't be Codified)” which is newer than RFC 1597, RFC 1918 is newer than RFC 1627, and usage of these addresses is both widely practiced and widely endorsed. (Although RFC 1627 is titled “Network 10 Considered Harmful”, it referenced RFC 1597 and really the arguements made by 1627 apply to the other address ranges of RFC 1597 as well). The intended usage described by RFC 1918, which is to have these addresses be “locally”/“privately”-assigned de-centralized addresses, is endorsed by newer RFC documents as well: BCP 153 (section 3): Special Use IPv4 Addresses (section on “Global and Other Specialized Address Blocks”) (e.g. RFC 5735 (section 3) as well as the older version RFC 3330 (section 3))

The IPv6 equivilent would currently be the IPv6 addresses within the fd00::/8 range. (Before RFC 3879: Deprecating Site Local Addresses, the IPv6 addresses within the fec0::/10 range, which had previously been named “Site-Local” addresses as noted by RFC 3513 section 2.5.6, were probably the most similar in nature to these IPv4 addresses.)

[#r1597cmp]: Comparing RFC 1597 to RFC 1918

Although some documentation does refer to these addresses as RFC 1918 (e.g. OpenBSD pf.conf man page), the reservation of these addresses actually existed back with RFC 1597. (RFC 1597 does have a lower RFC number than the RFC about objections to using these addresses in this way, RFC 1627. However, the other RFCs that endorse this sort of use of these addresses, RFC 1918 and 3330 and 5735, are all newer than 1627.) The differences between RFC 1597 and 1918 are fairly minor, with there being a lot of text that is copied (even if it is word-wrapped differently). The newer RFC 1918 does not seem to offer much, if anything, in regards to being a rebuttle to RFC 1627. Mainly the changes are some clarifications, including references to CIDR notation. Here is a breakdown of the changes that the updated RFC made to the body of the text.

  • Section 1: different.
  • Section 2: First paragraph is identical. Then, after the identical first paragraph, the documents differ a bit. Then, the latter part of this section again starts to be identical (except RFC 1918 has a clarifying phrase in parenthesis), starting with the text “Many applications”.
  • Also, in one case, “firewall hosts” was changed to “gateways”. A paragraph (“If two enterprises”) was removed.
  • Section 3: RFC 1918 added CIDR notations for the ranges, and refers to class A as “pre-CIDR notation”. It also documents class C as 256 contiguous networks instead of 255.
  • Added half a sentence (“or the set of enterprises”).
  • Added clarifying words “and thus could be classified as private”, and other minor changes in that paragraph.
  • Added text starting at “changes to the appropriate DNS entries”.
  • Section 4: “When such an enterprise” changed to “If such an enterprise”.
  • Added sentence “Although in principle”...
  • The last 3 paragraphs of section 4 are different. (In RFC 1597, the word “extend” probably should have been “extent”.)
  • Section 5: First word differs.
  • The second paragraph in section 5 has added sentences, one (which mentions “machine rooms”) of which is essentially from a later paragraph in RFC 1597.
  • The two paragraphs “Moving a single host” and “Changing the status” became replaced by one paragraph: “one might be tempted”.
  • The last three paragraphs differ.
  • Section numbers do not match for section numbers 6 through 9. Removed a useful note from the “Security Considerations” section.
  • Added one sentence to the paragraph called “Conclusion”. Other changes may exist in sections 6 through 9.
Misc info
Historical: RFC 953 refers to 10.0.0.51 as being related to an address called SRI-NIC.ARPA.
[#39s8]: 39/8

Some historical usage is referenced by RFC 1797 although this has now been unreserved (RFC 3330 section 2). (IANA's list of IPv4 address space usage lists this as having now been allocated to APNIC.)

[#127s8]: 127/8
Firewalling recommendations
RFC 3330 says “no addresses within this block should ever appear on any network anywhere [RFC1700, page 5].”. (However, firewalls should allow any traffic which is coming from the host and going back to the same host, so that loopback traffic is not interrupted. In Unix, this generally means blocking all 127/8 traffic on all interfaces except for all loopback interfaces. (Generally there is just one such loopback interface.))
[#127001]: 127.0.0.1

Loopback. This specific address is implemented by most TCP/IP network implementations, unlike the rest of 127/8. Note that this is not supported by every single TCP/IP implementation: a specific example of this not being supported by default would be at least some versions of the Cisco IOS environment. (The devices using that software may be configured to support 127.0.0.1, but do not support that until/unless they are configured to do so.)

127.0.53.53

There has been some proposals (which might have since started to become more widely used, after the time of this writing?) to have DNS report this IPv4 address in some cases. (This doesn't strictly violate the 127/8 reservation, because this idea isn't specifying how a client should treat the address. So, the address could still be loopback. This is simply saying that DNS servers, which typically mention IPv4 addresses in some DNS responses, may mention this particular (loopback) address in some of the DNS responses.

The idea was to use an address like this to inform people of a problem, such as a DNS name collision. The idea is that a DNS server could cause a “controlled interruption” that may be less disruptive than other approaches that might be taken by an organization that is in control of a DNS server's responses. (For example, an Internet Service Provider may do this. Then, people affected by the “controlled interruption” would likely contact their IT support, and that IT support would likely want to contact the Internet Service Provider.) This really doesn't shift power in any way: the DNS server that sends out the 127.0.53.53 address could send out a different response, like an NXDOMAIN response that indicates an invalid domain. What this approach does accomplish (whether this is a good or a bad thing) is to affect the experience of the DNS client in a different way. (At the time of this writing, on February 27 of 2014 when some news outlets like Slashdot reported this, there were some different opinions about whether the DNS clients would be having a better experience.)

Jan 8, 2014 article mentions this, and seems to be the origin of the idea of using this IPv4 address in a special way. Later, the address became mentioned by some news: Slashdot reports ICANN considering usage of 127.0.53.53 by having DNS servers return this particular IPv4 address in certain circumstances.

The latter part of the number was chosen to have similarity to the UDP port number 53 and the TCP port number 53, both of which are reserved for some sort of DNS usage.

Even if this proposal does not become widely deployed policy, the concept gathered enough attention that this address has a history behind it, notably different from other 127/8 addresses. (Even if nothing else, 127.0.53.53 now has the unique history of being heavily discussed when considering this appraoch. This history is unique enough that some people are likely to remember this address.)

Other Addresses in the 127/8 range

The address 127.0.0.0 fits the pattern of being a “network ID” of a /8 (formerly class A) network, and 127.255.255.255 represents a broadcast address for the last (subnet) network that is within the range (including sharing one or more of the boundaries) of this /8 (formerly class A) network. The address 127.0.0.1 is widely supported by most operating systems, although not all of them (such as IOS on some Cisco equipment). The most common practice for all other addresses in the 127/8 range is for all of these addresses to be just like any other unassigned addresses. The second most common implementation is for them to be considered assigned and for them to act exactly like the 127.0.0.1 loopback address.

As for RFC references, RFC 1700 page 5 (specifically section g) endorses the use of treating this entire range as loopback, while RFC 3330: Special-Use IPv4 Addresses (page 3) and its successor(s), BCP 153: Special-Use IPv4 Addresses (page 4) (RFC 5735: Special-Use IPv4 Addresses (page 4)) does document the fact of reality, which is that the intended purpose of 127/8 “is ordinarily implemented using only 127.0.0.1/32 for loopback”.

Some news articles may make the situation sound like ICANN is considering returning this address, which might sound like ICANN reserved the address for something, and then is returning the address to normal usage. Actually, that's not the case: the concept is that ICANN is considering recommending that DNS servers use this address when the DNS servers “return” an address. (When a DNS server “returns” an address, that basically just means that the address is included in the DNS server's response.)

Other addresses (with the first bit set to 1)
Class B
Overview of Class B addresses
Class B consists of all Internet addresses that start with the first bit set to one and the second bit cleared to zero, so it represents all of the IPv4 that have a first octet of 128 through 191. This range represents half of the potential IPv4 addresses which were not class A addresses. Some discussion on using addresses in this range were in RFC 1466 section 4.2.
Special use addresses in the Class B range

There's only two blocks of them listed in BCP 153: Special-Use IPv4 Addresses (RFC 5735: Special-Use IPv4 Addresses), which is a smaller amount of blocks reserved for special use than either former class A or former class C.

(A quick trivia question for anybody who may be simply reading through this: Can you name all of the special use addresses of former class A?)

[#128s8]: 128/8

One note from within this address range: RFC 5737 notes that 128.66/16 is no longer being handled specially. “The block can be used for regular address assignments with caution.” The recommended caution is simply to recognize that this address block has historically been used in some documentation.

[#16925416]: 169.254/16

RFC 3927: Dynamic Configuration of IPv4 Link-Local Addresses reserves this block. Most of this block, 169.254.1.0 through 169.254.254.255, are reserved for IPv4 link-local addresses. This is discussed by the first two paragraphs of RFC 3927: “Dynamic Configuration of IPv4 Link-Local Addresses”: section 2.1: “Link-Local Address Selection”. Those same paragraphs note that 169.254.0.0 through 169.254.0.255 and 169.254.255.0 through 169.254.255.255 “are reserved for future use and MUST NOT be selected by a host using this dynamic configuration mechanism.” RFC 3927: “Dynamic Configuration of IPv4 Link-Local Addresses”, Section 8: “IANA Considerations” notes those addresses (starting with 169.254.0 or 169.254.255) are allocated by “Standards Action”, a method of reserving numbers. That method is defined by BCP 26: Guidelines for Writing an IANA Considerations Section in RFCs.

RFC 4795: Link-Local Multicast Name Resolution (LLMNR) may also be related to usage of such addresses.

Specific implementations of assigning the addresses from the link-local range may have their own names, such as Microsoft's “APIPA” and earlier “IPAC”. For details about implementations, see the section on network addressing.

The IPv6 equivilent would be FE80::/10: IPv6 Link-Local unicast. A key difference between the IPv4 implementation and the IPv6 implementation is that while every IPv6 NIC is supposed to have a Link-Local address (as one of the requried addresses of each IPv6 node), these IPv4 the link-local addresses tend to be used instead of regular Unicast addresses. When these IPv4 addresses are seen being used, that is often an indicator that they were automatically assigned because automatic address assignment failed, and so troubleshooting of automatic addressing (and possibly network connectivity) needs to occur. Once that trouble is effectively shot, then these addresses stop being used.

[#17216s12]: 172.16/12 (172.16/16 through 172.31/16)
Firewalling recommendations
...
Usage of this address block and memorization of its boundaries

This is perhaps the least popular of the range of “private”/locally-assigned/de-centralized IPv4 addresses, and probably for two reasons. First, those who desire (and may have some real need for) the flexibility of the largest private network tend to go with IPv4 addresses in the 10/8 range, while those who need fewer addresses and prefer to be as conservative as possible may often use the IPv4 addresses in the 192.168/16 range. Secondly, the borders of this range do not match some of the octet byte boundaries of standard IPv4 dotted quad notation, and many people seem to have more trouble remembering the range of this /12 block than they do for the other blocks. (Although IPv4 addresses in the 192.168/16 range also have two dotted quads filled with specific numbers to identify the network of private addresses, repeated exposure may help to re-enforce familiarity so that this isn't as difficult for many people to recognize.)

Memory tip: In a pinch, if the address of the first “class C”-sized network block (172.16/16) is remembered, those with the correct know-how (knowledge) may be able to calculate the last block simply by remembering the following tip. The number used to write out prefix size of this /12 block (which is the number “12”) is halfway between the numbers used to write out the prefix lengths of the sizes of the other network blocks (which are /8 and /16). /8 is what is used for the prefix length for the class A block of private addresses in the 10/8 range, and /16 is the prefix length used for the class C block of private addresses in the 192.168/16 range. The number that is halfway between “8” and “16” is “12”, which is the size of this network block.

Then, applying some knowledge about making subnets, one can go through a process of doubling the subnet size each time the prefix length is decremented (or, alternatively, starting with the class A size and then halving with each incrementation). The following overview shows this:

  • 172.16/16 consists of just 172.16/16. (That is one /16 subnet.)
  • 172.16/15 consists of 172.16/16 and 172.17/16. (Those are two /16 subnets.)
  • 172.16/14 consists of 172.16/16 and 172.17/16 and 172.18/16 and 172.19/16. (Those are four /16 subnets.)
  • 172.16/13 consists of 172.16/16 through 172.23/16. (Those are eight /16 subnets.)
  • 172.16/12 consists of 172.16/16 through 172.31/16. (Those are sixteen /16 subnets.)
Overview

(The following paragraph is identical, verbatim, and is also found in the section about IPv4 addresses in the 10/8 range and the section about IPv4 addresses in the 192.168/24 range.)

Although there are objections listed in RFC 1627: “Network 10 Considered Harmful” “(Some Practices Shouldn't be Codified)” which is newer than RFC 1597, RFC 1918 is newer than RFC 1627, and usage of these addresses is both widely practiced and widely endorsed. (Although RFC 1627 is titled “Network 10 Considered Harmful”, it referenced RFC 1597 and really the arguements made by 1627 apply to the other address ranges of RFC 1597 as well). The intended usage described by RFC 1918, which is to have these addresses be “locally”/“privately”-assigned de-centralized addresses, is endorsed by newer RFC documents as well: BCP 153 (section 3): Special Use IPv4 Addresses (section on “Global and Other Specialized Address Blocks”) (e.g. RFC 5735 (section 3) as well as the older version RFC 3330 (section 3))

The section about addresses in the 10/8 range has an RFC 1597 and RFC 1918 constrast/comparison if that is of interest.

Other addresses (with the first two bits set to one)
Class C
Overview of Class C addresses
Class C consisted of all Internet addresses that start with the first bit set to one and the second bit also set to one and the third bit cleared to zero, so it represents all of the IPv4 that have a first octet of 192 through 223. This range represents half of the potential IPv4 addresses which were neither class A addresses nor class B addresses.
Special use addresses in the Class C range
[#19202s22]: 192/22 (or, more clearly: 192.0.0/22 (192.0.0.0 through 192.0.3.255)

This range of IPv4 addresses could be split into 4 distinct /24 groups.

[#19200s24]: 192/24 (192.0.0/24) : Reserved

RFC 1166 identifies 192/24 (a.k.a. 192.0.0/24, which is 192.0.0.0 through 192.0.0.255) as being assigned to Jonathan Bruce Postel.

[#19201s24]: 192.0.1/24 : Reserved

RFC 1166 identifies this as being reserved for backbone testing (Class C) network. (Specifically, the RFC says, “BBN-TEST-C”.)

[#19202s24]: 192.0.2/24 : TEST-NET-1 (Early documentation prefix)
Purpose/Overview

The purpose of these addresses is to allow documentation authors to use these addresses as examples without concern of other people, who may end up using the examples directly (before modifying the examples appropriately), potentially affecting other addresses that are in use for another purpose.

192.0.2.0/24 was called “TEST-NET-1” by RFC 5737: IPv4 Address Blocks Reserved for Documentation and BCP 153 (section 3): Special Use IPv4 Addresses (section on “Global and Other Specialized Address Blocks”) (e.g. RFC 5735 (section 3)). These were called “TEST-NET” by RFC 3330 (page 3), and “TEST” by RFC 1166 (page 47) where Jon Bruce Postel (see Wikipedia page on Jon Postel) was credited for reserving these addresses.)

In the year 2010, some IPv4 addreses have been similarly reserved by IANA for this same sort of purpose. (This seemed like interesting timing to be adding such a reservation, as noted in the information about TEST-NET-2.) These additional IPv4 addresses reserved for such use are The IPv4 address range 198.51.100/24 (“TEST-NET-2”), and 203.0.113/24 (“TEST-NET-3”). People using examples for documentation may also be interested in BCP 32: Reserved Top Level DNS Names (e.g. RFC 2606: Reserved Top Level DNS Names). Similar addresses do exist for IPv6 and those are the addresses within the IPv6 range 2001:db8::/32.

Firewall Recommendations
Block like crazy. After this block is defined as “TEST-NET-1” by RFC 5737 section 3, the next section of that RFC, RFC 5737: IPv4 Address Blocks Reserved for Documentation (section 4: Operational Implications), says “Addresses within the TEST-NET-1, TEST-NET-2, and TEST-NET-3 blocks SHOULD NOT appear on the public Internet and are used without any coordination with IANA or an Internet registry”. Then that same document states “Network operators SHOULD add these address blocks to the list of non- routeable” [sic] “address spaces, and if packet filters are deployed, then this address block SHOULD be added to packet filters.” “These blocks are not for local use, and the filters may be used in both local and public contexts.” To clarify, this means that if a machine has host-based firewall software, it would be following these recommendations for the host to block such traffic, and so unlike the addresses listed in BCP 5: (IPv4) Address Allocation for Private Internets, one should not count on addresses which are reserved for use as IPv4 documentation to work well, even for communications within a private network.
[#19201s24]: 192.0.3/24

Like the rest of 192/16 (192.0/16, which goes from 192.0.0.0 through 192.0.255.255) except for the rest of 192/22 (192.0/22, which goes from 192.0.0.0 through 192.0.3.255), this address range (192.0.3/24) is described as “Unassigned” by RFC 1166.

[#cb192001]: 192.1/16 : BBN Local Nets

This is reserved for Backbone Local Nets. RFC 1166 page 47 indentifies 192.1.0.0 through 192.1.1.255 as “BBN Local Nets”. Then, the same page (RFC 1166 page 47) goes on to assign some more specific names for many of the following networks, up through the 192.1.25/24 address block. Then, the next addresses, going through the end of 192.1/16 and even beyond through the end of 192.2/15, are identified as “BBN Local Nets”.

[#19202s15]: 192.2/15 (192.2/16 and 192.3/16) : BBN Local Nets

RFC 1166 page 47 identifies that 192.1.26/24 and even beyond through the end of 192.3/16, are identified as “BBN Local Nets”. That range of addresses is larger than this 192.2/15 network block, but ends with this entire block.

[#192c8899]: 192.88.99/24

RFC 3068 (“Anycast Prefix for 6to4 Routers”) section 2.3 identifies 192.88.99/24.

This is considered to be related to 6to4. Other addresses related to 6to4 include the IPv6 2002::/16 prefix and the IPv6 64:ff9b::/96 prefix.

[#cb192168]: 192.168/16 : Private Address Range in former Class C
Firewall/Router recommendations

(The following paragraph is identical, verbatim, and is also found in the section about IPv4 addresses in the 10/8 range and the section about IPv4 addresses in the 172.16/12 range.)

Although there are objections listed in RFC 1627: “Network 10 Considered Harmful” “(Some Practices Shouldn't be Codified)” which is newer than RFC 1597, RFC 1918 is newer than RFC 1627, and usage of these addresses is both widely practiced and widely endorsed. (Although RFC 1627 is titled “Network 10 Considered Harmful”, it referenced RFC 1597 and really the arguements made by 1627 apply to the other address ranges of RFC 1597 as well). The intended usage described by RFC 1918, which is to have these addresses be “locally”/“privately”-assigned de-centralized addresses, is endorsed by newer RFC documents as well: BCP 153 (section 3): Special Use IPv4 Addresses (section on “Global and Other Specialized Address Blocks”) (e.g. RFC 5735 (section 3) as well as the older version RFC 3330 (section 3))

The section about addresses in the 10/8 range has an RFC 1597 and RFC 1918 constrast/comparison if that is of interest.

[#19818s15]: 198.18/15 (198.18.0.0 - 198.19.255.255)
RFC 2544: Benchmarking Methodology notes the assignment, as does BCP 153: Special Use IPv4 Addresses (e.g. RFC 5735). The IETF Benchmarking Methodology Working Group (BMWG) references some additional RFC's for more information.
Purpose/Overview
...
For similar addresses with IPv6, see IPv6 Usage: section on 2001:2::/48.
[#19851h24]: 198.51.100/24 : TEST-NET-2 (A later documentation prefix)
Purpose/Overview

The purpose of these addresses is to allow documentation authors to use these addresses as examples without concern of other people, who may end up using the examples directly (before modifying the examples appropriately), potentially affecting other addresses that are in use for another purpose. These became available in January of year 2010 A.D. (That seemed like interesting timing to be adding such a reservation, as migration from IPv4 to IPv6 still was not moving very quickly at the time. Some people were concerned about the impending time when IANA would be running out of IPv4 addresses to be able to reserve, and the IPv4 Internet had been deployed for many years with just the 192.0.2/24 address range being reserved by IANA for this purpose.)

198.51.100.0/24 is called “TEST-NET-2” by RFC 5737 and BCP 153 (e.g. RFC 5735 (page 5)).

Some additional IPv4 addreses have been similarly reserved by IANA for this same sort of purpose: They are the 192.0.2/24 address range (“TEST-NET-1”, early address range for documentation), and 203.0.113/24 (“TEST-NET-3”). People using examples for documentation may also be interested in BCP 32: Reserved Top Level DNS Names (e.g. RFC 2606: Reserved Top Level DNS Names). Similar addresses do exist for IPv6 and those are the addresses within the IPv6 range 2001:db8::/32.

Firewall Recommendations
Block like crazy. After this block is defined as “TEST-NET-2” by RFC 5737 section 3, the next section of that RFC, RFC 5737: IPv4 Address Blocks Reserved for Documentation (section 4: Operational Implications), says “Addresses within the TEST-NET-1, TEST-NET-2, and TEST-NET-3 blocks SHOULD NOT appear on the public Internet and are used without any coordination with IANA or an Internet registry”. Then that same document states “Network operators SHOULD add these address blocks to the list of non- routeable” [sic] “address spaces, and if packet filters are deployed, then this address block SHOULD be added to packet filters.” “These blocks are not for local use, and the filters may be used in both local and public contexts.” To clarify, this means that if a machine has host-based firewall software, it would be following these recommendations for the host to block such traffic, and so unlike the addresses listed in BCP 5: (IPv4) Address Allocation for Private Internets, one should not count on addresses which are reserved for use as IPv4 documentation to work well, even for communications within a private network.
[#2030113s]: 203.0.113/24 : TEST-NET-3 (A later documentation prefix)
Purpose/Overview

The purpose of these addresses is to allow documentation authors to use these addresses as examples without concern of other people, who may end up using the examples directly (before modifying the examples appropriately), potentially affecting other addresses that are in use for another purpose. These became available in January of year 2010 A.D. (That seemed like interesting timing to be adding such a reservation, as migration from IPv4 to IPv6 still was not moving very quickly at the time. Some people were concerned about the impending time when IANA would be running out of IPv4 addresses to be able to reserve, and the IPv4 Internet had been deployed for many years with just the 192.0.2/24 address range being reserved by IANA for this purpose.)

203.0.113.0/24 is called “TEST-NET-3” by RFC 5737 and BCP 153 (e.g. RFC 5735 (page 5)).

Some additional IPv4 addreses have been similarly reserved by IANA for this same sort of purpose: They are the 192.0.2/24 address range (“TEST-NET-1”, early address range for documentation), and 198.51.100/24 (“TEST-NET-2”). People using examples for documentation may also be interested in BCP 32: Reserved Top Level DNS Names (e.g. RFC 2606: Reserved Top Level DNS Names). Similar addresses do exist for IPv6 and those are the addresses within the IPv6 range 2001:db8::/32.

Firewall Recommendations
Block like crazy. (In other words, this type of traffic may be wise to block when it is incoming traffic from the Internet, outgoing traffic to the Internet, and even internal traffic on the internal network. There should be no leigitmate need for this type of traffic.) After this block is defined as “TEST-NET-3” by RFC 5737 section 3, the next section of that RFC, RFC 5737: IPv4 Address Blocks Reserved for Documentation (section 4: Operational Implications), says “Addresses within the TEST-NET-1, TEST-NET-2, and TEST-NET-3 blocks SHOULD NOT appear on the public Internet and are used without any coordination with IANA or an Internet registry”. Then that same document states “Network operators SHOULD add these address blocks to the list of non- routeable” [sic] “address spaces, and if packet filters are deployed, then this address block SHOULD be added to packet filters.” “These blocks are not for local use, and the filters may be used in both local and public contexts.” To clarify, this means that if a machine has host-based firewall software, it would be following these recommendations for the host to block such traffic, and so unlike the addresses listed in BCP 5: (IPv4) Address Allocation for Private Internets, one should not count on addresses which are reserved for use as IPv4 documentation to work well, even for communications within a private network.
[#223end24]: 223.255.255/24

Once this was reserved so that it could have a special meaning. No more. The bottom of RFC 3330 (just scroll up from RFC 3330: “Special-Use IPv4 Addresses” page 4) notes that these addresses might no longer need to be reserved. RFC 5735: “Special-Use IPv4 Addresses”, Appendix A (Differences from the last simliar RFC standard document) notes, “223.255.255.0/24 is not reserved and is subject to future allocation by an RIR for assignment in the normal manner.” IANA's list of IPv4 address space usage lists 223/8 as having now been allocated to APNIC.

Other addresses (with the first three bits set to one)
[#ip4clasd]: Class D: 224/4: (Multicast addresses)

Class D consists of all Internet addresses that start with the first bit set to one and the second bit also set to one and also the third bit set to one, but which has the fourth bit cleared to zero, so class D represents all of the IPv4 that have a first octet of 224 through 239. This range represents half of the potential IPv4 addresses which were neither class A addresses, class B addresses, nor class C addresses. This entire address with 28 variable bits consists of one sixteenth of all possible IPv4 addresses and is reserved for Multicast use. (This reservation was noted by RFC 1122 (Internet Host Communication) Page 29 (second sentence of section 3.2.1.3). For IPv6 addresses with an equivilent use, one two-hundred-fifty-sixth of IPv6 address space is reserved for multicast use as noted by information on IPv6 usage: section about the FF00::/8 address range.

To see some details of the current assignments, see: IANA's (IPv4) Multicast Assignments (XML) (or the IANA's (IPv4) Multicast Assignments (text file version) which the XML file links to) or IANA's (IPv4) Multicast Assignments (text file shown when browsing directly to the multicast-addresses/ directory). (The XML version is prettiest, showing some nice tables, when it is nicely rendered by some web browsers: see information about XML files for details about what browsers support that file format.)

The lists of multi-cast addresses published by IANA, which were just referred to, reference some various technologies which don't need to be redundantly repeated here. Looking at the first couple of /24 blocks as an example, many of the addresses in the range from 224.0.0.0 through 224.0.1.185 have been allocated, some to technologies which have been seen in real-world use outside of research labs. Note that some addresses (and even address ranges) are marked as being either “Reserved” by IANA, or “Unassigned” (and credited to the now-deceased Jon Postel).

IETF's “Best Current Practices” (“BCP”) number 51 is a name applied to the latest RFC related to Multicast. RFC 1060 page 4 mentions that Class D (and E) addresses had been reserved for experimental use. However, that is widely recognized as an outdated detail, because Class D is now widely recognized as being meant for multicast.

RFC 2780 section 4.4.2: IPv4 Multicast addresses states, “IPv4 addresses that fall in the range from 224.0.0.0 through 239.255.255.255 are known as multicast addresses.” (At the time of this writing, RFC 2780 is part of IETF BCP 37, and continues to be one of the latest documents being pointed to by that BCP.) RFC 2780 section 4.4.2 continues, discussing new address assignments, and notes, “Until further work is done on multicast protocols, large-scale assignments of IPv4 multicast addresses is not recommended.” Although, that might be old: about a decade later, IETF BCP 51 - IANA Guidelines for IPv4 Multicast Address Assignments has been released.

The first two addresses
(RFC 1112 section 4 reserves 224.0.0.0 and 224.0.0.1.)
224.0.0.252
RFC 4795: Link-Local Multicast Name Resolution (LLMNR)
[#239s8]: 239/8 : Administratively Scoped IP Multicast
BCP 23 (e.g. RFC 2365)
[#ip4clase]: Class E: 240/4 addresses (with the first four bits set to one) : “Experimental”
Overview/purpose

The fifth class, Class E, consists of all Internet addresses that start with the each of the first four bits being set to one, so class E represents all of the IPv4 that have a first octet of 240 or higher. This range represents all of the potential IPv4 addresses which were neither class A addresses, class B addresses, class C addresses, nor class D addresses. Except for 255.255.255.255, this entire address range has been considered reserved, with the intention that the addresses are reserved for Experimental use. (RFC 1112 (Internet Hosts Communications) page 29, in section 3.2.1.3, specifically noted “Class E addresses are reserved for experimental use.” References to class E exist in RFC 1812, BCP 153, RFC 1112 Section 4.

It seems that IANA is no longer listing these as Experimental. IANA IPv4 Address Space Registry now documents them as “Future use”, with a footnote saying: “Reserved for future use (formerly "Class E")” Interestingly, the RFC being cited is RFC1112 (which called them experimental). BCP 153 (section 3): Special Use IPv4 Addresses (section on “Global and Other Specialized Address Blocks”) (e.g. the bottom of RFC 5735 (page 5) says “This block, formerly known as the Class E address space, is reserved for future use”.

That said, no actual “future use” is anticipated. IPv4 Address Consumption” archived page, by Cisco notes, “The class E space has 268 million addresses and would give us in the order of 18 months worth of IPv4 address use. However, many TCP/IP stacks, such as the one in Windows, do not accept addresses from class E space and will not even communicate with correspondents holding those addresses. It is probably too late now to change this behavior on the installed base before the address space would be needed.” This text is partially quoted by Tom Wijsman's comment on a page at superuser.com asking about using these addresses. Tom commented, “By the time we all support this "class E" block, we will have made big progress switching to IPv6 so it'll no longer be worth it. Developers, ISPs and consumers better invest in switching to IPv6 instead...” Perhaps a reason why the addresses were made unusable is described by another of Tom's comments: There may have been speculation that the initial bits might be given some special meaning other than just providing more usable IPv4 addresses. (There was a time when the IPv4 address space was believed to be large enough to provide addresses for anyone likely to use them. That belief was quite reasonable before Internet usage started becoming very widespread much sooner than people were initially planning.)

RFC 2780 section 4.4.3: IPv4 Reserved Addresses notes about 240.0.0.0 through 255.255.255.254 (notably not including 255.255.255.255 in this statement), “compliant IPv4 implementations will discard any packets that make use of them.”

Special address
[#ip4bdcst]: 255.255.255.255 : The broadcast address

As this is the broadcast address of the largest possible IPv4 subnet, 0/0, in theory traffic sent to this address would get sent to the entire Internet. Clearly that is not feasible, due to bandwidth consumption and security concerns. (Spammers would saturate this.) However, such traffic is not forwarded beyond a “connected physical network”, according to RFC 1122 page 30 (section c). There might be some additional documentation confirming that the traffic is not intended to be routed, possibly described by BCP 34: Changing the Default for Directed Broadcasts in Routers (RFC 2644), other RFC's about routers (RFC 1812: Requirements for IP Version 4 Routers which updates RFC 1716 which is newer than RFC 1009: Requirements for Internet Gateways, RFC 985) ), and other RFCs specific to broadcasted IPv4 traffic (RFC 922: Broadcasting Internet Datagrams In The Presense Of Subnets, perhaps RFC 919). RFC 1122 page 30 (section c) does indicate that this traffic does not get forwarded outside of a “connected physical network” (in point “(c)”).

For the IPv6 equivilent, see the IPv6 address FF02::1 (“all-nodes multicast address”), which is implemented through multicast. (For more limited IPv6 broadcasting, RFC 4291 section 2.6.1 describes the “Subnet-Router anycast” addresses, which are like the “broadcast address” at the end of an IPv4 subnet.)

For more discussion about broadcast traffic (including other broadcast addresses), see broadcast traffic, glossary: “broadcast address”.

RFC 1466 described assignments and is referenced by IANA's map of IPv4 addresses (XML file).

See also: IPv4 classes.