SANS ISC: Reserved IP Address Space Reminder - SANS Internet Storm Center

• SANS Site Network
  • Current Site
  • Internet Storm Center
  • Other SANS Sites Help
  • Graduate Degree Programs
  • Security Training
  • Security Certification
  • Security Awareness Training
  • Penetration Testing
  • Industrial Control Systems
  • Cyber Defense Foundations
  • DFIR
  • Software Security
  • Government OnSite Training

SANS ISC InfoSec Forums

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

Defending Web Applications Security Essentials - Secure DevOps Summit & Training 2018

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.