Reserved IP Address Space Reminder

Published: 2012-05-16
Last Updated: 2012-05-17 02:58:11 UTC
by Johannes Ullrich (Version: 1)
8 comment(s)

As we are running out of IPv4 address space, many networks, instead of embracing IPv6, stretch existing IPv4 space via multiple levels of NAT. NAT then uses "reserved" IP address space. However, there are more address ranges reserved then listed in RFC1918, and not all of them should be used in internal networks. Here is a (probably incomplete) list of address ranges that are reserved, and which once are usable inside your network behind a NAT gateway.

List of Reserved IPv4 Address ranges
Address Range RFC Suitable for Internal Network
0.0.0.0/8 RFC1122 no ("any" address)
10.0.0.0/8 RFC1918 yes
100.64.0.0/10 RFC6598 yes (with caution: If you are a "carrier")
127.0.0.0/8 RFC1122 no (localhost)
169.254.0.0/16 RFC3927 yes (with caution: zero configuration)
172.16.0.0/12 RFC1918 yes
192.0.0.0/24 RFC5736 no (not used now, may be used later)
192.0.2.0/24 RFC5737 yes (with caution: for use in examples)
192.88.99.0/24 RFC3068 no (6-to-4 anycast)
192.168.0.0/16 RFC1918 yes
198.18.0.0/15 RFC2544 yes (with caution: for use in benchmark tests)
198.51.100.0/24 RFC5737 yes (with caution: test-net used in examples)
203.0.113.0/24 RFC5737 yes (with caution: test-net used in examples)
224.0.0.0/4 RFC3171 no (Multicast)
240.0.0.0/4 RFC1700 no (or "unwise"? reserved for future use)

Most interesting in this context is RFC6598 (100.64.0.0/10), which was recently assigned to provide ISPs with a range for NAT that is not going to conflict with their customers NAT networks. It has been a more and more common problem that NAT'ed networks once connected with each other via for example a VPN tunnel, have conflicting assignments.

Which networks did I forget? I will update the table for a couple days as comments come in.

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

Keywords: nat rfc1918
8 comment(s)

Comments

Wikipedia has a similar list at http://en.wikipedia.org/wiki/Reserved_IP_addresses that also addresses IPv6.
See also RFC3330 and this summary-
http://www.caida.org/~youngh/bogons.html
I'm a ham, but frankly I think it's time to look very carefully at the AMPRnet, which has 44.0.0.0/8 assigned to it and is quickly being deprecated. Not saying it should go completely, but I'm quite positive there are "huge tracts of land" that could be assigned out of it.

Anyway, 44.128/16 is considered a test network for AMPRnet and not routable, much like 10/8, so it should certainly be reasonable to consider using it at least.
http://www.dynamicnet.net/2012/04/ipv4-shortage-impact-isps-data-centers-hosting-providers/ is our take.

The ugly part is that not everything is IPv6 compatible; and this needs to be as much bottom to top as top to bottom.
I'm not sure of the exact status, but 128.66.0.0/16 is still listed in alot of places as a not valid address.
128.66.0.0/16 has been assigned and is now routed by AS24608

RFC 5735 obsoleted/updates RFC 3330

44.0.0.0/8 is still considered AMPRNET according to Whois. I think the use of 44.128.0.0/16 as non-routable test net is an AMPRNET policy. I wasn't able to find an official reference to it yet.
The 239.0.0.0/8 range is assigned by RFC 2365 for private use within an organization.
Too bad that the ranges from 224/8 on up can not easily be reclaimed.. they grossly overestimated the popularity of multicast applications, which led to huge assigned but unused netblocks.
Also, I find it rather sad that the companies that were so graciously handed one or several /8 ranges can not be bothered to return at least a part of them.

Diary Archives