Last Updated: 2012-05-17 02:58:11 UTC
by Johannes Ullrich (Version: 1)
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.
|Address Range||RFC||Suitable for Internal Network|
|0.0.0.0/8||RFC1122||no ("any" address)|
|100.64.0.0/10||RFC6598||yes (with caution: If you are a "carrier")|
|169.254.0.0/16||RFC3927||yes (with caution: zero configuration)|
|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)|
|188.8.131.52/24||RFC3068||no (6-to-4 anycast)|
|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)|
|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.