Friday, September 20, 2013

IPv6 Unique Local Address or ULA - what are they and why you shouldn't use them

I am often asked interesting questions by fellow IT professionals about IPv6. Some are worthy of a blog post or two so here it is. The subject of IPv6 Unique Local Address or ULA (which is one of the unicast IPv6 address types) seems to be getting more attention now that IT professionals are actually looking at how to deploy IPv6. I thought I would share some brief information about ULA and follow up with my thoughts about it.

ULA is a unicast address type and is limited to the fc00::/7 prefix. This means the prefix has a fixed binary value of 1111 110x with ULA having the concept of a local flag bit (x) which is the 8th bit. This means the prefix is divided into fc00::/8 and fd00::/8. The local flag value of 0 hasn't been defined and therefore should not be used at all which eliminates the fc00:/8 prefix from being used. The local flag value of 1 indicates that the prefix is locally assigned. That means the only valid ULA addresses to use today are from the fd00::/8 prefix.

There have been a few interesting efforts to coordinate ULA prefix allocations. I have no idea why you would do this but you can check it out at SixXS's site. The reality is, fd00::/8 by definition is locally assigned and there is an algorithm defined in RFC 4193 that helps in generating a unique prefix out of that range to help avoid collisions or you can put your MAC address into the SixXS site and it will generate a prefix for you. You can find how the algorithm works in Section 3.2.2 if you want more details.

So what has sparked all this interest in ULA? I think it is happening because many IT organization think deploying IPv6 should be done in the same manner as IPv4. If you spend any time around IPv6 professionals you will quickly learn that IPv4 thinking doesn't apply when designing IPv6 networks. As an example, the role of NAT and address conservation are entirely thrown out the window. I think there is still a lot of confusion around the role of NAT and many IT professionals still consider NAT a security feature. NAT never was intended to be (and never functionally was) a security solution. All NAT provides is a way to conserve the use of public IPv4 addresses. If you disagree, I'm sorry, you are wrong.

Getting back on track, the analogy is often given that ULA is like IPv4 RFC 1918 address space. I believe this triggers people to think they should use ULA in the same way they are using RFC 1918 today. In other words, assign ULA everywhere on their internal network and run a NAT solution at their edge via a firewall or router. This looks exactly like what they do in IPv4. It also turns out that this is completely WRONG for IPv6.

It actually isn't accurate to say that ULA is like RFC 1918 address space. RFC 1918 address space was specifically set aside for the purpose of running NAT because of the shortage of public IPv4 addresses. There is no shortage of IPv6 address space and there will not be any within your lifetime, your children's lifetime or your grandchildren's lifetime or, well, you get the picture. So how is ULA like RFC 1918? The design of ULA was to have an IPv6 address space that would not route on the public IPv6 Internet - ever. In that capacity, ULA and RFC 1918 addresses are the same, neither was intended to be used on the public Internet at all. ULA was designed for labs or other resources (think secure military uses or maybe internal networks at power plants for example) that NEVER need to (or should ever) talk to the global Internet.

Let me repeat that, you use ULA when you never want to talk to anything on the Internet. I have seen many IT professionals say there should be NAT solutions in IPv6. There are some limited corner cases where solutions like NPTv6 (which is network prefix translation for IPv6) might solve some problems however I am not aware of any production ready implementations of NPTv6. In fact, the NPTv6 RFC is still in experimental status, see RFC 6296 and the former solution of NAT-PT has been moved to historical status, see RFC 4966 so really you have no robust NAT solution to date outside of server load balancing solutions like SLB66.

So what do you do? Simple, you reject your IPv4 ways of thinking and adopt the IPv6 way of thinking. You deploy global unicast IPv6 addresses throughout your network and use a stateful packet inspection firewall to control traffic and enforce security rules. You build good routing policies and leverage host based firewalls to enhance your security posture. In fact, you do all the same security measures you do for IPv4, you just happen to be using global unicast IPv6 address. Why? Because we have enough IPv6 addresses that we don't need NAT anymore.

What advantage do you gain by doing this? First, you don't break protocols that tend to embed address information in their session process. NPTv6 will still break protocols requiring firewalls and other network devices to try and do "fixups" or intelligent repairs on the fly to sessions. Why are we wasting time on that when if you simply use global unicast addresses with no network address translation then the protocol doesn't require any special handling.

Finally, it is easier to manage, complies with every design recommendation you will find out there on deploying IPv6 and reduces the chance you will have breakage for a service later (assuming your firewalls aren’t blowing it up – but at least you only have to look in one place for that issue).

So there you have it. In summary, ULA is appropriate for a lab, a proof of concept, a super secure network and maybe an out-of-band control network. Even then, I would still argue you could do all of those functions with global unicast addresses and simply put the correct routing and firewalls rules in place. ULA is designed to never be routed on the public IPv6 Internet and as a result you should not be assigning ULA to hosts in your network unless you have the correct use case. Otherwise, stick with global unicast IPv6 addresses. Do IPv6 right the first time so you don't have to go back and do it again. As a final thought I give you Andrew Yourtchenko's fun NAT YouTube video.


- Ed

17 comments:

P Bover. said...

Thanks for the post. By the way, if someone has doubts about NAT read the RFC 1631. Not mentions about security at all

Ryan Ries said...

I'm glad that you ended with "ULA is appropriate for a lab, a super-secure network or a proof of concept," because I came here ready to flame, but you disarmed me at the last moment. :)

Andrew von Nagy said...

Hi Ed,
Good post. One question though. Could ULA be used internally alongside Global addressing in order to minimize the impact of renumbering in the event of an ISP change? Since IPv6 addressing is intended to be hierarchical, with ISPs aggregating their address blocks, when an organization needs to switch ISPs and hence renumber their internal networks, this could cause a significant amount of work. I'm thinking of DNS changes and the like, not really prefix aging. If the organization used ULA for internal reachability and based all their internal DNS records off ULA addresses, wouldn't this help minimize the impact of an ISP migration?

Just curious and food for thought.

Thanks,
Andrew von Nagy
@revolutionwifi on the Twitter

Anonymous said...

ULA is mentioned in RFC 6879, IPv6 Enterprise Network Renumbering Scenarios, Considerations, and Methods
tools.ietf.org/html/rfc6879

I recall hearing about how devices were going to have more than one address, local, unique unicast, multicast, etc., but also recall hearing that in order for that to work applications would have to know which address to use in which case.

Ed Horley said...

If you are dealing with more than one IPv6 address (and most of the time you will) then you need to know RFC 3484, 6555 and 6724. In addition, you need to know how your OS has implemented those in order to determine what source and destination pair matching process applies. Needless to say, it isn't going to be easy for help-desk folks to know how an application on a dual stacked network will behave and even on an all IPv6 network how it will behave. There is a lot of learning and testing that will be happening in the years to come as IPv6 become more and more common.
- Ed

Anonymous said...

Thanks for the article Ed. Okay, so we won't use ULA as an RFC1918 substitute, but then how am I going to load-balance my Internet connections? If my router has two ISP connections, my router decides which to use for any given request, so my PC doesn't know which public address to use. Do we just use NPTv6 instead ?

irf said...

Hi Ed,
My Organization is having many different sites interconnected by MPLS VPN from two different providers. Each site is having there own different internet connectivity solutions. In this case while migrating to IPv6, if i use Global unique address provided by ISPs then Since each site is having different ISP, I'll end up with different IPv6 subnets at each site. So can i use ULA in this case at all Sites and do a NAT while using Internet and No NAT for MPLS VPN inter site connection ?

Anonymous said...

I know we are supposed to stop thinking in an IPv4 mindset and believe me, I want to. I am very excited of the end-to-end connection possibilities. But as another commenter suggested that the portability of your prefix designation hinges on cash. Therefore NAT ends up being a solution to mitigate future renumbering for smaller establishments.

So for now I am using NPTv6 with my firewalls, and I ask all the IPv6 powers that be to also stop treating this new frontier like the v4 days. Reservation of a PD needs to be more accessible to smaller guys.

-Brett

MaryJohn said...
This comment has been removed by a blog administrator.
Unknown said...

Good post Ed and I think you are not wrong. However, even though ULA is similar to RFC1918 addresses they are intended for different purpose and their uses will become more obvious when you consider multihomed networks or you need to switch ISP or some segment's of your network completely isolated and you don't want to even bother with potential renumbering scenarios. Comparing ULA to RFC1918 is not exactly apples-to-apples. I would say ULA addresses have their uses and they should be used pretty much always but in context of IPv6.

corndog said...

All sounds great, but I have had to re-address my entire network three times due to ISP changes. I've had enough. I registered a ULA block with Sixxs and I'm using it side-by-side with public addresses. Any known services that I need to provide over ipv6 on the internal network, I configure static addresses in the ULA space. All systems have a ULA address and also a dynamic public address. No NAT is done, for linking to the outside, but I FINALLY have some sort of reliable addressing inside. ULA is great.

Ed Horley said...

@corndog - I understand your frustration. IPv6 does have some tools to make renumbering easier however there isn't a lot of operational information out there to help with doing that well. I typically recommend that companies obtain IPv6 provider independent space to reduce the issues with renumbering. A bit of advise with ULA. Remember, for RFC 6724 compliant OS and devices IPv4 is preferred over ULA. This means that all your hosts will prefer IPv4 for any transport internally which might cause some odd combination of behaviors you might not want. I would like to hear more on if you have seen any impact from an operations basis due to the potential mix of RFC 3484 devices compared to RFC 6724. - Ed

Unknown said...

In addition to ULA there is another type of IPv6 address called the Link-local. How would I use ULA and link-local?

From my understanding link-local traffic is confined to the link it is attached to, traffic does not exit this interface.

Does this mean I would use ULA if I had two interfaces on router (different subnets) and I needed traffic to be routed between these two subnetworks?

Anonymous said...

@comdog - What about Prefix Delegation, where you assign only the static bits of your prefix?

Chris said...

hi,

I know this post is quite old but it would be really great if you could help me with this one...

I like your post and I want to deploy Global IPv6 Unicast addresses. Having said this, the problem is that on Domain Controllers / Win DNS Server static IPs are required pointing to themselves. My ISP seems to change the IPv6 Prefix every couple of days. So I cannot use SLAAC with DHCPv6 (to provide the internal DNS Server address) when the Prefix changes...

Do you have any suggestion how this is usually solved?

Thanks

Andrew Hodel said...

If you don't have the ability to NAT a private address, then you exclude the possibility of mesh routing for a network inside of a large building or complex when multiple gateways to the Internet are considered.

Assuming you have multiple gateways, you would have to have BGP enabled with your uplink provider or next tier provider in order for nodes to roam on the mesh network. This becomes even more troublesome with multiple backbone/uplink providers because of the need to effectively publish where each node is on the network.

If you don't have the possibility of nat6, you end up with a horrible roaming situation and it should not be that way.

If setup correctly with nat6, you can easily use a mesh network with IPv6 and roaming.

Also, nat6 is in the linux kernel with ip6tables.

Darren said...

I am using a ULA on 2 devices on my lan. 1 for the router to forward packets over the lan, and 2 for a local lan service (dns among others). The reason is that my prefix is changed by my isp which involves updating config files to match the new prefix You might argue that is should not be dynamic, but it is and power outages or hardware changes trigger it.The local dns server also has a public ipv6 as well, thus it is only used for reference by the lan to compensate for the ever changing ipv6 prefix.