I Say ULA, You Hear NAT

Ed Horley wrote another great post arguing you don’t need Unique Local Addresses in an IPv6 network … and I couldn’t figure out what the problem was until I got the underlying context: it seems many engineers try to transplant their IPv4 mentality into IPv6 world and see ULAs as a nice replacement for RFC1918 with NAT66 or NPT66 on the private network edge. No wonder Ed argues against that.

While we still cannot escape the throes of NAT66/NPT66, you shouldn’t use ULAs as 1:1 RFC1918 replacement. Remember that every IPv6 host has more than one IPv6 address per interface. One of those addresses might be an ULA address (for intra-company communication), another one a public (PI or PA) IPv6 address (for global connectivity).

Using ULAs in combination with public IPv6 addresses is identical to the solutions Ed proposed in his blog post (see Figure 5 in his post), with a crucial difference: Ed’s solution requires you to modify IPv6 source address selection prefix policy entries, while ULA+global combination (usually) works with the default settings of most operating systems.

Need to Get Started with IPv6?

My IPv6 webinars should bring your IPv6 networking skills up to speed:

If you need help in your IPv6 design or deployment, I’m just a WebEx call away.


  1. How many IP addresses we will see on server's NIC, One for link local, one Global unicast range, one ULA and one IPv4 address for backward comaptibility. It is operational nighmare.
  2. I suspect that having multiple ULA for internal company communication and global for communication with the Intenet will cause lots of issues with application guys since now application has to bind to specific ip for internal communications and another ip to go to the internet. I see many server guys now have very fuzzy understanding of the windows or unix/linux networking so ULA and global will make life a nightmare.

    many companies use NAT for traffic engineering purposes (especially customer/vendor extranets) and it's easier to NAT traffic to make it going the way you want than setting up PBR all over the place.

    We all know about dark messy corners of the corporate networks, NAT may be the simplest solution to make things done (adding more mess though but that's another story, we need to get things done and may not have time to redesign existing infrastructure.

    I am sure that customers will push vendors to implement NAT66 because they need/want it and it will be done regardless if IETF thinks it's ok or not.
  3. Ivan, great blog post. I agree with your thoughts on ULA and Global Unicast and you could certainly run ULA for your corporate connection requirements and use Global Unicast from either PI or PA for each site. I was trying to address more of the BGP multihomed corporate office with a remote branch off that doesn't do BGP. I think both solutions would work, yours might be a better design long term - go figure, you are smarter than me ;)
    In regards to Dmitriy's comments about application guys having to bind to specific IP's for internal. If the OS is following RFC 6724 then applications will benefit from being passed the correct information for source/destination selection and will get an ordered list. This problem is no different for IPv4 hosts that have multiple IPv4 addresses, there has to be some sort of logic to pick one verse the other. Someone has to make a decision about what IP address to bind to or just bind to them all and reserve a port instead. I disagree with his comments about NAT and PBR. I believe the current IPv4 solution puts many artificial restrictions on redundancy, path selection and artificially imposes restrictions on having to pass through stateful devices. IPv6 gives companies enough addresses but also network prefixes to not have to worry about NAT. This allows you to truly have global and universal firewall rules that are not concerned with things like did the source traffic come as RFC 1918 or the real IPv4 address etc.
    Finally, I guess we also need to decide, is it NPT66 or NPTv6 - I was using the name from the RFC (http://tools.ietf.org/html/rfc6296) but I have seen you and several others say NPT66 instead. I guess I will update my post to tell folks you might see it referenced either way for now.
    - Ed
Add comment