- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
3 Ways to Ruin Your Future Network with IPv6 Unique Local Addresses (Part 2 of 2)
3 Ways to Ruin Your Future Network with IPv6 Unique Local Addresses (Part 2 of 2)
Last time around we looked at the first of the three ways you might ruin your future network with Unique Local Addresses. If you’re not already familiar with ULAs, you might want to take a minute to go back and read Part 1 for a quick ULA refresher.
Technique “numero uno” for shooting yourself in the foot with ULA involved using Unique Local Addresses with NAT66. To sum up, statefully translating between GUA and ULA addressing is an exercise in pointlessness for the network operator (though some vendors might be perfectly happy to sell you some additional hardware to accomplish such futility). Why would someone select this configuration? Part 1 goes into more detail but the short answer is an erroneous belief that NATs provide security. (Often this goes hand-in-hand with conflating NAT and stateful packet inspection, or SPI, at the perimeter – something no one could reasonably argue isn’t critically important.)
In this post we’ll look at two additional ways you can cause yourself much future weeping and gnashing of teeth by (mis)deploying ULAs.
Randomize or You May End Up DEAD:BEEF!
As we discussed in Part 1:
“…The 40 bits defining any ULA prefix assigned from the fd00::/8 ULA range, are supposed to be randomly defined. This is done to maximize the probability that any ULA prefix will indeed be unique, not only within the site where the prefix is assigned but also truly globally unique across the entire Internet.”
The goal of the random 40 bits is to avoid any possible potential address overlaps when two organizations connect their networks. This randomness has a few important long-term consequences. For one thing, you’re just as likely to die falling off of a ladder in front of a moving train as you are to end up with two overlapping randomly-generated ULA /48s.
This means that, should you find yourself having to manage the integration of two separate networks and routing domains following a merger, you’ll be able to route between them without any renumbering (or tricky NAT configuration). But, again, this only works if the ULA subnets have been properly generated using the recommended randomization function.
Another consequence of using proper random ULA prefixes is that you will also have a falling-off-ladder-in-front-of-train chance of ending up with contiguous /48 subnets. Recall that one of the key benefits of using IPv6 is the ability to allocate subnets on nibble boundaries. This allows for easier route summarization and security policy ACLs. But non-contiguous /48s means that you won’t be able to summarize routing or collectively define and restrict security policy for any topologies larger than a /48 (e.g., /44, /40, etc.). Most enterprise networks are simply not large enough to ever confront this limitation should they decide to try use ULAs for a very large topology or set of topologies. In any case, most if not all enterprises of that size should be using GUA (and Provider Independent) allocations anyway for end-to-end routing.
Keep in mind that you’ll still be able to summarize routing and define ACLs at the nibble boundary level (or even by individual bits as necessary) within a given ULA /48, since you’ll still have the 16 bits between the /48 and the /64 to work with. This give you 65,536 individual /64 networks to use for all your networks.
Some network administrators will feel restricted by having to stick to the rule of randomization for ULAs. IPv6 is also fairly new and the scale of it can cause one to mistake the unlimited size of the space for the necessarily restricted ways in which we can effectively manage networks over time. For example, I have little doubt that there are many of the same fd00::/48 or fd00::1/48 prefixes assigned across (and even perhaps within) organizations. The heading for this section is obviously a bit tongue-in-cheek but the same reasoning holds true for prefixes formed from such ephemerally original hexadecimal words or word combinations. ULA prefixes formed with these approaches are easy to assign and remember. The newness of IPv6 for most administrators means they’re unlikely to imagine such prefixes conflicting anytime soon with other identical prefixes. Arbitrarily picking a ULA subnet (as opposed to using the proper random method) also means you can grab contiguous subnets as needed.
But this approach is almost guaranteed to cause overlapping subnet and address conflicts in the future once IPv6 has been around a bit longer. Such conflicts leading to renumbering defeats one of the entire purposes of IPv6. So for anything other than the sparsest, most occasional use of ULA, use a randomly generated prefix. The SixXS site offers a free random ULA prefix generator. You can register your new prefix as well though there’s no guarantee that such registration will provide it any enduring uniqueness (not to mention the fact that your ULA prefix would be publicly visible and some organizations might have security requirements disallowing this).
fc00::/7 vs. fc00::/8 vs. fd00::/8
If you only read the first couple of pages of the ULA RFC 4193 (“Unique Local IPv6 Unicast Addresses”) you might be forgiven for grabbing any old /48 anywhere in the fc00::/7 range defined in the document by the 7 prefix bits of the ULA allocation. However, reading a little further in the document you would learn that the first half of the allocation, the block fc00::/8, is formally undefined. Meanwhile, the second half, fd00::/8 is the address block available for use. Again, as reasoned in the previous section, if the network is small and static and requires few ULA prefixes, guaranteed uniqueness and/or the formal validity of any prefix by RFC standards may not be critical. But from my experience anything that decreases the probability of renumbering significant amounts of infrastructure or eliminating NAT between networks is worth pursuing.
So to recap, don’t ruin your network with ULAs:
- Avoid ULA and NAT66 (and keep in mind that NPTv6 offers a special and very limited use case)
- Use a properly randomly generated ULA prefix
- Make sure that prefix is taken only from the fd00::/8 range (not the fc00::/8)
One Final Comment
As we mentioned in Part 1, ULAs are commonly viewed as the IPv6 replacement for RFC 1918, or private, addresses in IPv4. But it’s important to keep in mind that IPv6 was designed for everything to have a global unicast address (i.e., an address from a range assigned by a RIR or an ISP from the 2000::/3 allocation). ULAs should not be seen simply as a substitute for Global Unicast Addresses (GUAs), especially where they might be used merely to maintain the traditional enterprise configuration of private addressing with NAT at the edge. Since IPv6 is designed to have multiple addresses on an interface, it is very possible that we’ll eventually see deployments where ULAs coexist with GUAs on the same interface for access to different networks and network scopes – all without the hidden technical debt and false security of NAT.
PS. There's still time to register for Bloxfest, Infoblox's first-ever customer conference being held May 17th through the 19th in Boston. We promise an "intense learning and sharing experience for IT professionals committed to building world-class networks and security infrastructure" with track sessions, hands-on, and a keynote from hacker emeritus extrodinaire Kevin Mitnick. Visit the Bloxfest website for more details and to register now.
