Home / Blogs

RFC 1918 Address Space: Why It Was Needed then and How It Will Change in IPv6!

“The Internet has grown beyond anyone’s expectations. Sustained exponential growth continues to introduce new challenges. One challenge is a concern within the community that globally unique address space will be exhausted. A separate and far more pressing concern is that the amount of routing overhead will grow beyond the capabilities of Internet Service Providers. Efforts are in progress within the community to find long term solutions to both of these problems. Meanwhile it is necessary to revisit address allocation procedures, and their impact on the Internet routing system.” —RFC 19181

Recently, my firm has seen a lot of interest come from Enterprises seeking IPAM/DNS tools. We predicted that IPv6 adoption and the need for automation software/tools would follow the Internet ecosystem’s supply chain starting with Service Providers consisting of ISPs, I/PaaS, ASPs, then content providers (mostly a service really), then Enterprises, followed by SMBs & Consumers. While good for business, it has also forced us to revisit and think thru many TCP/IP protocol standards, why they were implemented in the first place, how they eventually were used, and then what will that mean in the transition to IPv6 in the context of not just Service Providers but Enterprises as well (their needs are truly different).

RFC 1918, or non-publicly routable IP Address space is one of those “stop-gaps”, along with NAT, that arose out of need to prolong IPv4 space and has become a de facto standard for many network operators for both security and rudimentary asset tracking purposes. In this article, we will look at the origination of RFC 1918 and how it is being used by Enterprises. We will then detail how this standard will evolve in an IPv6 world where IP Addresses are no longer managed as a finite pool, but as almost boundless resources. Then we will see how to re-visit your use of RFC 1918 in your environment today in light of network automation tools and the presence of IPv6 on your network.

RFC 19182: The need to prolong the life of IPv4 IP addresses (AGAIN)

RFC 1918 was codified in 1996 by Y. Rekhter of Cisco Systems, B. Moskowitz of Chrysler Corp., D. Karrenberg of RIPE NCC, G. J. de Groot of RIPE NCC, and E. Lear Silicon Graphics, Inc. The intent was to provide a mechanism to both prolong the use of publicly available IPv4 address space and provide Enterprises a way of spinning up private networks (recall the Internet was never envisioned beyond a Military app at the onset) without having to apply for publicly routable IP space.

RFC 1918 was originally allocated as such (I’m sure you’ve seen these numbers many times before):

In creating these designation, IANA (the Internet Assigned Numbers Authority), Enterprises (mostly) , SMBs and even home users (unknowingly) adopted the use of RFC 1918 in earnest. Coupled with Network Address Translator (NAT)3, 1918 space was deployed quickly and allowed Enterprises to continue to grow and expand their networks without having to constantly go back to their RIR to petition for more space. At that time, it was a win-win for both the Internet at large as well as Enterprises moving more of their infrastructure “online”. The unintended consequence, however, is that over 15+ years, RFC 1918 (and NAT) became a staple of network engineer’s designs within Enterprises for not only networking but security as well. Best practices emerged and standards codified that we now are forced to revisit in light of a transition to IPv6 and limitless, unique IP Addresses as well as the IPv6 concept of Unique Local Addresses (ULAs).

In this next section, we will begin to explore how this IPv6 will change the thinking of those using RFC 1918 (and NAT) extensively as we introduce ULAs.

RFC 4193: Unique Local Addresses (ULA)

RFC 41934 was codified in 2005 by R. Hinden of Nokia and B. Haberman of JHU-APL and “defines an IPv6 unicast address format that is globally unique and is intended for local communications, usually inside of a site.” The intent is to replace 1918 with a new pool of IPv6 addresses that have been reserved from this subnet: fc00::/7. This subnet is further divided into two smaller subnets consisting of the following:

fc00::/8 – as of this writing, this subnet has not been defined yet
fd00::/8 – this block is intended for use with /48 prefixes

The objectives of this more recent RFC were to enable a similar capability found in 1918 and continue to enable devices to get online and communicating without constantly petitioning for space from your RIR using new IPv6 addresses.

The characteristics of the new ULAs, as defined in RFC 4193, are as follows:

  1. Globally unique prefix (with high probability of uniqueness)
  2. Well-known prefix to allow for easy filtering at site boundaries
  3. Allow sites to be combined or privately interconnected without creating any address conflicts or requiring renumbering of interfaces that use these prefixes
  4. Internet Service Provider independent and can be used for communications inside of a site without having any permanent or intermittent Internet connectivity.
  5. If accidentally leaked outside of a site via routing or DNS, there is no conflict with any other addresses.
  6. In practice, applications may treat these addresses like global scoped addresses

So the idea of is now replaced with fc00:0:0:0:0:0:0:0:/7 and will present some challenges to organizations as they make this shift both in deployment as well as management.

To properly keep track of all of these IPs is thru the introduction of some sort of automated IP Address tool (not spreadsheets) and at the same time, it presents an opportunity to go back through existing 1918 allocations and ensure there are no overlapping addresses or subnets which are commonly found in merged organizations.

SIDE NOTE: On top of this change, which is substantial in and of itself, devices that are v6 enabled will also be able to leverage Stateless Address Auto Configuration (SLAAC) to configure themselves and not require a DHCP server—please see recent article on DHCP differences5.

SLAAC allows individual devices to communicate on a network without having to solicit for TCP/IP information as is done with DHCP today and greatly facilitates the ever increasing demand for network access by many more devices like mobile devices, physical infrastructure (think refrigerators, light bulbs, air conditioning units, etc.), and even virtual devices like virtual servers. While fantastic news for the growing Internet and an ever connected world, this will give net admins who use 1918 extensively a lot of headaches as it is an entirely new paradigm to manage with all new IPv6 Addresses and RFC 4193.

OK - now what?

If you have made it this far, and aren’t completely overwhelmed, the next logical question is now what? For starters, as you begin to evaluate your network (the first step in the transition to IPv6), you must get a handle on all devices using 1918 address space in the first place—to ensure a consistent architecture, you should not be using multiple/overlapping blocks of 1918 address space. Now that you can put a unique IP address on all devices, you should begin to plan out your network and the first step is to have a good IP Address Plan (this is what IPAM is all about).

With respect to security, if you have grown comfortable with the obfuscation that NAT and 1918 provide, then it is time to revisit security policies in light of all devices having unique IP addresses—this is a HUGE change from the v4 address scarcity mind set and, ironically, returning the Internet back to its roots of all things having a unique address (until we run out again which is not until well past 2050… maybe).

Lastly, while this change seems like a large one (and it is only one component of the migration to IPv6), it should be welcomed as it gives network operators the opportunity to get BETTER control of their network through the preliminary network audits and preparation for an IPv6 deployment. I would also suggest, with all devices having unique addresses, one can expect a greater degree of control on their network as all things will be traceable versus with NAT & 1918, one can effectively “hide” behind the gateway and make forensics rather difficult.

In the end, network automation tools can greatly increase your ability to both gain control of your IPv4 address space, both public and private, as well as help prepare you for the migration to IPv6 and ULAs. Hopefully this article has not scared you in your further adoption of IPv6 and has highlighted some of the eminent changes coming as we move from RFC 1918 (IPv4) to RFC 4193 (IPv6).

1 Full RFC 1918: http://tools.ietf.org/html/rfc1918
2 More reading on “Private Networks”: http://en.wikipedia.org/wiki/Private_network
3 See RFC 1631: http://tools.ietf.org/html/rfc1631
4 See RFC 4193: http://tools.ietf.org/html/rfc4193
5 DHCP v4 vs v6: http://www.circleid.com/posts/dhcp_for_ipv4_vs_ipv6_what_you_need_to_know/

By Richard Donaldson, CEO of 6connect

Filed Under


RFC-1493 seems to be a solution without a problem Mel Beckman  –  Jun 13, 2011 12:56 PM

The stated objective of RFC-1493, to “enable devices to get online and communicating without constantly petitioning for space from your RIR using new IPv6 addresses,” seems moot. A /48, the standard unit of IPv6 allocation to end user organizations, provides enough space so that no return to an RIR for more should ever be required. Can you describe a realistic scenario where standard global RIR space would not work just as well as yet another private addressing scheme?

Mel:You are correct - I should have Richard Donaldson  –  Jun 13, 2011 6:45 PM

Mel: You are correct - I should have been more explicit in my explanation. I've found that one of the biggest hurdles in IPv6 adoption is simply getting rid of IPv4 mind-sets, so while you are absolutely correct, I was (poorly) trying to put this in a context that those who still think in legacy might better understand. Part of the series I am trying to put together, as well, is to help people begin to make this transition from "scarce resources/IPv4" to "unlimited/IPv6" - for how you make a good IPv6 plan rests upon understanding what you have pointed out...any thoughts on more real world transitions that would make good material for upcoming pieces? rd

A better description Mel Beckman  –  Jun 13, 2011 6:59 PM

I like the treatment that blog "Thorsten on Tech" gives for ULA: http://yorickdowne.wordpress.com/2010/01/15/ipv6-addressing-renumbering/ The salient passage is: "ULA is different from RFC1918 in that ipv6 does not offer NAT ... That doesn’t mean that ULAs are useless. They are meant to allow local machines to communicate locally – combined with the idea of DHCP-PD, this can be a way to handling renumbering. RFC4864 was written specifically to address concerns about manageability of local IPv6 space."

Comment Title:

  Notify me of follow-up comments

We encourage you to post comments and engage in discussions that advance this post through relevant opinion, anecdotes, links and data. If you see a comment that you believe is irrelevant or inappropriate, you can report it using the link at the end of each comment. Views expressed in the comments do not represent those of CircleID. For more information on our comment policy, see Codes of Conduct.

CircleID Newsletter The Weekly Wrap

More and more professionals are choosing to publish critical posts on CircleID from all corners of the Internet industry. If you find it hard to keep up daily, consider subscribing to our weekly digest. We will provide you a convenient summary report once a week sent directly to your inbox. It's a quick and easy read.

I make a point of reading CircleID. There is no getting around the utility of knowing what thoughtful people are thinking and saying about our industry.

Co-designer of the TCP/IP Protocols & the Architecture of the Internet



Brand Protection

Sponsored byCSC


Sponsored byVerisign

New TLDs

Sponsored byRadix

Threat Intelligence

Sponsored byWhoisXML API

Domain Names

Sponsored byVerisign


Sponsored byDNIB.com

IPv4 Markets

Sponsored byIPv4.Global