RFC 1918 Address Space

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 1918[1]
————————————————————————————–

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 and Service Providers. 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 1918[2]: 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):

Source: Wikipedia –http://en.wikipedia.org/wiki/Private_network#Private_IPv4_address_spaces

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 4193[4] 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:

1. fc00::/8 – as of this writing, this subnet has not been defined yet
2. 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 10.0.0.0/8 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 differences[5].

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).

Related keywords: Network Automation, Network Management, Peering, Systems Administration