Build the Next-Generation Data Center
6 week online course starting in spring 2017

To ULA or not to ULA, That’s the Question

Ed Horley, an awesome IPv6 geek I had the privilege to meet at NFD6, wrote an interesting blog post arguing against IPv6 ULA usage (particularly when combined with NPT66). We would all love to get rid of NAT, however ...

Meanwhile in the SMB world

It makes perfect sense to use public IPv6 addressing in your private network and get rid of NAT forever if and only if:

  • You’re big enough to have your own PI address space;
  • You’re willing to buy high-end business-class Internet connection for every single remote site (to persuade the upstream ISP to route a /48 prefix belonging to your PI address space);

... or if you have a single L3 device (which also acts as a simple firewall) in your network.

In other words, if you’re a residential user with a single SOHO router/CPE or a Fortune 500 company, you’ll do just fine and you really shouldn’t use ULAs. Unfortunately, these are the only two markets most vendors and ISPs care about; in most other cases, you’ll end up with a total operational nightmare:

  • Remote sites having IPv6 prefixes (somewhat) randomly assigned by their ISPs (which will do wonders to your VPN routing);
  • Widespread renumbering every time you change an ISP.

Do I have to mention that although renumbering a single IPv6 segment works really well (for residential users that don’t mind a short outage), and renumbering multiple segments connected to a single router is still manageable (assuming the router is running Cisco IOS, most other vendors start sucking at this point), renumbering anything beyond that becomes an exercise in futility.

Of course you can decide to pay €50/year and have your own PI address space. Good for you, but it sucks for everyone else.

Add access lists and firewall rules into the mix and you’ll quickly discover the huge gap between rainbow-colored IPv6 heavens promoted by IPv6 evangelists and operational reality. I could hack around the access list issues by marking high-order bits in the IPv6 prefix as don’t-care-bits (so renumbering wouldn’t affect them) ... but that’s not how you configure IPv6 access lists in Cisco IOS – the don’t care bits are gone; all you can specify is the prefix length.

Oh, and then there’s the small site IPv6 multihoming with PA space problem, where it took five years to get to the stage of having an Internet draft that's implemented in the latest Linux kernel. Who knows how long we’ll have to wait for the first commercial products to appear.

Just for the record – I’m not a NAT hugger. I would love to get rid of NAT as much as everyone else, but the sad reality of IPv6 is that the academic theories started meeting the real-life operational needs only a few years ago, and we still have a very long way to go to get the protocol suite we need. In the meantime, we’ll have to use kludges like NAT66 and ULAs in mid-market IPv6 implementations, not because we love them, but because they’re the best tools we have at our disposal.

Unfortunately, the following two quotes from Randy Bush (replying to another IPv6 architectural beauty contest) still apply to most IPv6 conversations we have:

It is cheering to see that the IPv6 ivory tower still stands despite years of attack by reality.
And how much of good people's time do you plan to waste on this windmill?

Just in case you’re new to the IPv6 world

Need to know more about IPv6? Start with my Enterprise IPv6 – the first steps webinar (there’s also a service provider version) or one of the more-advanced IPv6 webinars that cover IPv6 network design, IPv6 security and IPv6 transition mechanisms.


  1. Hi Ivan,

    correct me if I’m wrong, but thanks to RFC 6724 we can have a single ULA space in the VPN and ISP PA addresses at each site. No need for NAT, and no need for including the ISP PA in the VPN.

    1. Of course that's the right way to do it ... but it needs ULA (which was my point).

  2. RA supports sending multiple prefixes, routing and DNS resolver information including seperate TTL for prefixes.

    So why not:
    - send prefix for ULA
    - send prefix for ISP1 before and during transition
    - send prefix for ISP2 during and after transition
    - configure firewall on the outside to only let traffic out
    - put hosts in DNS with ULA-addresses
    - firewall the servers to only allow for ULA-traffic

    I didn't see a need for NAT.

    Linux supports all of this, I believe. So if your hosts use Linux you could be done, right ? SEND would be interesting too but let's talk about one problem at a time.

    So RA has everything that you need, right ? This breaks down if you know that at least Windows doesn't support the DNS RA-option. So you'll need DHCPv6 too.

    1. Would this help?

    2. OK, I like a challenge. ;-)

      The setup below isn't perfect, my comment was about replacing one ISP with an other. Not permanent multihoming.

      Here is an attempt: you make sure the traffic of both ISP prefixes is send to the same router connected to both ISPs.

      Traffic that arrives at the router can just source route the traffic to the right ISP. I do at home with 2 tunnel providers, works pretty good.

      The router is a PC-router and pings the other endpoint of the tunnel. And I do use the short TTL and remove the prefix from the RA when a tunnel is down.

  3. We have a problem that we can´t fix easy in IPv6.

    We provide outsourcing.

    We have 94.x.x.x for external addressing and 10.x.x.x for internal addressing.

    Our network mangement system creates access-list to isolate each customer in a /24. By default customers are no allowed to talk to eash other. But it can be opened.
    Still each customer is able to connect to other customers on external IP because of firewall u-turn policy´s.

    How do you do this in IPv6? We don´t want run dedicated firewalls for every customer and or vlan based firewalls.

    The only solution i see is ULA?


  4. For the mid-size organisations another option is to use a LISP based ISP for your addresses and one or more 'normal' ISPs just for the uplinks. Packets between multiple sites will even automatically use the normal routing path between the CPEs :-)

  5. €50/year per RIR object
    AS# + IPv6 = 100€
    + taxes

  6. The tablegroth won't be a problem because theres LISP, everywhere! It's more common than IPv6 I've been told.

    1. Yeah, I know that approach. "LISP is the answer ... what exactly is the problem?"

      Assuming you're not totally trolling us, do check the IPv6 stats

      When you find something remotely similar for LISP, do let me know. I'm waiting ... ;)

  7. The refusal of IETF to implement NAT66 will result in large amount of incompatible proprietary NAT66 implementations, there will be high demand for sure. Nobody mentioned here that source NAT is used quite extensively in corporate networks to ensure traffic is routed back to the source appropriately if there are multiple entrances and traffic crosses firewalls, load balancers, etc.
    I suspect that financial organizations paranoid about security will not like idea deploying internal servers on globally routable IPv6 ip-s and put them on ULA. Companies merge quite often and there will be possibility of ULA conflict since all people think similarly and everybody will use fd00:0:0:0::/64 similar to :-)

  8. well, not sure why i said about incompatible nat66 implementations, there will be just proprietary implementations...

  9. I don't understand the issue with ULA. Without it, you are essentially addressing hosts on a LAN by their internet addresses, which is a bit stupid. Imagine your computer trying to print to a printer or get some files from a NAS. In addition, imagine a dead internet service. All your hosts on the LAN are unreachable because the addresses are tied to the Internet.
    I'm not old enough how people set up their LANs prior to the advent of NAT, just I imagine that it involved making some host addresses (ex. printer) non-routable.


You don't have to log in to post a comment, but please do provide your real name/URL. Anonymous comments might get deleted.