By even casual observation, you’ll likely have noticed that there are several IP address ranges that are special, including:

  • 10.0.0.0/8 (10.0.0.0 – 10.255.255.255)
  • 172.16.0.0/12 (172.16.0.0 – 172.31.255.255)
  • 192.168.0.0/16 (192.168.0.0 – 192.168.255.255)

Anybody can use these “private” ranges for anything they like. But there are actually several other special ranges that have other special purposes. In this article, I’ll explain what they are and the purpose they serve.

127.0.0.0/8 (127.0.0.0 – 127.255.255.255)

This is the “loopback” range. These are addresses that are assumed to be on the same device that’s sending the packet. You’ll likely never see packets with these addresses on a network, because they should be handled by the software inside the device.

Typically, the operating system itself uses the address 127.0.0.1, so you can PING this address on any system and it should respond.

C:\Users\kevin>ping 127.0.0.1

Pinging 127.0.0.1 with 32 bytes of data:
Reply from 127.0.0.1: bytes=32 time<1ms TTL=128
Reply from 127.0.0.1: bytes=32 time<1ms TTL=128
Reply from 127.0.0.1: bytes=32 time<1ms TTL=128

Ping statistics for 127.0.0.1:
    Packets: Sent = 3, Received = 3, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms
Control-C
^C
C:\Users\kevin>

If it doesn’t respond then this can be a sign that your system’s TCP/IP stack isn’t working correctly. But other addresses from this range, like 127.0.0.2, shouldn’t respond unless you have an application that’s specifically configured to listen to this IP address.

Loopback addresses are often used when you need to interact with some network application (like a web server) on the system where you’re currently connected.

169.254.0.0/16 (169.254.0.0 – 169.254.255.255)

These addresses are “link local,” which means packets with these addresses are sent out to the network, but should never be forwarded to other parts of the network. You’ll often see addresses from this range if a device is unable to get an address using DHCP. Then it simply takes an address from this range and uses it to try to at least communicate locally.

AWS (Amazon Web Services) hosts have an interesting use for link local addresses. They use 169.254.169.254 for a special web server that exists on every EC2 segment and contains locally relevant information about the instance: http://169.254.169.254/latest/meta-data/

Microsoft Azure allows the use of the same address, but it defines a unique global public address— 168.63.129.16—for the same purpose. It’s important to note that this address is actually a registered address owned by Microsoft. It should be considered an anycast address rather than a link local address.

If you put a sniffer on just about any network segment, you’ll often see 169.254.xx addresses in ARP queries. As mentioned above, when a device fails to get an address using DHCP, it can instead use a link local address to communicate with other devices on the same network. But these addresses still have to be unique—they use ARP queries to determine whether the address that they want to use is already in use. So if you see a lot of these packets on your network, it probably means that you have problems with your DHCP servers.
192.0.0.0/24 (192.0.0.0 – 192.0.0.255)

This is another small range that can be used for private purposes, exactly the same as 10.0.0.0/8 and 192.168.0.0/16. It’s not used very often because it only allows for 254 addresses. But if you’re in a pinch and need a special subnet, this could be helpful.

For example, if you have a small WAN that needs addresses, but you don’t want to use addresses from the normal private ranges, this is a good choice.

TEST Ranges

The IANA (Internet Assigned Numbers Authority) defines three special ranges that are designated as “TEST,” although they are really intended for documentation.

192.0.2.0/24 (192.0.2.1 – 192.0.2.254) TEST-NET-1
198.51.100.0/24 (198.51.100.1 – 198.51.100.254) TEST-NET-2
203.0.113.0/24 (203.0.113.1 – 203.0.113.254) TEST-NET-3

You can use these ranges in documentation. They can also be used as additional private ranges inside your network, but this isn’t recommended because they will confuse people.

224.0.0.0/4 – Multicast

The range from 224.0.0.0 to 239.255.255.255 are reserved for multicast. You must never attempt to assign these addresses to the interface of a device. Multicast is a complicated topic all its own in networking. The essential point is a packet can be sent to a multicast destination address, and can be delivered to a large number of downstream devices simultaneously.

There are many different purposes for multicast protocols. They are often used for audio and video signals over IP based cable television networks. The end user’s TV or set top box sends a special “Join” request to the network, indicating that it would like to start receiving a particular stream of packets. They are also commonly used in stock trading applications to ensure that all of the market participants receive information about transactions simultaneously.

However, because multicast is intrinsically a one-to-many (or few-to-many) stream of packets, it’s impossible to have responses and acknowledgements back from the clients to the server. For this reason, multicast is typically delivered using UDP. If the packets must be delivered in order, or if they cannot be dropped, then the application needs to take care of these features. The network won’t do so.

It’s important to note that multicast protocols are not enabled on the public internet. So, even though there are registered “public” and unregistered “private” multicast address ranges, you shouldn’t see a lot of multicast on your network unless you have specifically designed the network to support this traffic.

There are a few exceptions: Multicast addresses 224.0.0.1 and 224.0.0.2 are used to send a packet to all devices on the local segment and all routers on the local segment respectively. Other multicast addresses are used for other common network functions such as routing protocols. 224.0.1.1 is used by the NTP time protocol as an alternate way of delivering time information to many devices at once.

It can be interesting to ping some of these addresses, just to see if there are any multicast enabled devices on your network.