Follow up to my IPv6 and ULA post plus some thoughts on design and IPv6 behavior

I've gotten some interesting comments and questions in regards to my IPv6 ULA (Unique Local Address) post and I wanted to outline the questions and then follow up with my thoughts and some high level design discussion.

The first question is around the situation of multiple ISP connections without using BGP and Provider Independent (PI) addresses or alternately switching from one ISP to another. The argument is pretty straightforward, you don't want to have to renumber your servers, network links and other infrastructure when changing ISP's because the IPv6 address space you have is allocated from that ISP. That IPv6 address space will no longer be yours when you change from ISP A to ISP B. So, alternately you can use ULA for your network, server and even client devices and only use that ISP IPv6 address space at the edge, similar to how you implement IPv4 today. This requires the use of some sort of NAT translation at the edge.

The second question is a bit of a refinement of the above that argues you should use ULA for all internal hosts and your LAN and WAN resources so you don't have to renumber if you change ISP's but also so you have a consistent address prefix preference for internal traffic to register with DNS.

I think those really are the main pro ULA arguments I have heard so far. Let's tackle the first part which is really all about flexibility in choosing and changing your ISP and reducing the IPv6 renumbering costs to a fractional degree. The second one I will cover in a different post.

The following diagrams shows the multiple ISP connection configuration which is no different than migrating from one ISP to another. We start with ISP A on the left and will be moving to ISP B on the right. Our initial network configuration will use ISP A's IPv6 Provider Assigned (PA) address block and our goal is the move to ISP B's IPv6 Provider Assigned (PA) address block. For a duration of time you will have both ISP A's and ISP B's IPv6 address blocks active on your network. The next diagrams (Figure 2 and 3) are what everyone thinks they want to deploy. It utilizes some sort of NAT technology at the Internet edge and assumes you will only use ULA for the "internal" network.

Figure 1. Dual connections while migrating service providers

Figure 2. ISP 1 with NAT66

Figure 3. ISP 2 with NAT66

The primary problem with the ULA solution people want is that there are no good production quality NPTv6 implementations out there to run on a firewall or edge Internet device today. This limits your ability to actually deploy that solution so you are left with NAT66 (not a good option in my opinion). Furthermore, NPTv6 still breaks many end to end features for applications relying on the underlying networking protocol not doing NAT. Application developers will still have to build NAT traversal mechanisms into their apps even though we were not supposed to need them with IPv6 at all. The only advantage you will gain is that with NPTv6 you have a stateless solution for NAT as only the prefix is actually changed. This reduces the amount of resources required on that Internet edge device greatly compared to the same solution with IPv4. An additional option is to go with NAT66 (which is available from some network manufactures) but which make IPv6 even more brittle and introduces every one of the NAT/PAT problems we have with IPv4 only on a much larger scale. I consider this solution a huge mistake and using it roles back all the progress and design work that the architects of IPv6 put into the protocol.

The slightly more difficult dual ISP PA migration (Figure 1) solution will actually work just fine without ULA. You will have to do some planning to do renumbering however depending on your design this could potentially be relatively easy. The most difficult resources to renumber would be your LAN and WAN infrastructure and your servers. Client devices should be dynamically obtaining their IP addresses (IPv4 or IPv6) and should not care greatly if their network address prefix changes over a weekend or even within the day. IPv6 has no issue with running both PA IPv6 prefixes at the same time nor does it require ULA to do this function. You might gain some time back on larger LAN and WAN networks on not having to renumber and this could be true for servers also however you will have to write additional firewall rules and you will still have to give them global unicast addresses if they need to talk to the public IPv6 Internet at all (remember, limited or no NPTv6 support today). This means you still have to touch the device to change it over from one IPv6 prefix to another. If it does not have the requirement for being able to get to the public Internet at all then there is a use case for using ULA. I see this as a secure network and I argued in the previous blog post that a secure network would be a legitimate use case for ULA.

ULA may buy you a small amount of stability in avoiding some address renumbering but I would argue that a proper DDI solution solves almost all the issues using DDNS and name to IP address resolution. What you gain from ULA to avoid renumbering you will likely have to pay back 10 fold in NAT traversal issues and pain.

A quick question, how often are people changing ISP's for small to medium sized businesses? I think some of the renumbering argument assumes this happens far more often than it does. For many medium to larger enterprise customers they will likely get Provider Independent IPv6 address space and utilize BGP to advertise to multiple ISP's at once (Figure 4). They do not require NPTv6 and even if they need local Internet hop off at a branch location they would simply deploy both PI and PA IPv6 prefixes at that site and let RFC 6724 solve the source/destination matching (Figure 5). They can gain more granular control of the routing behavior if they modify the prefix policy tables.

Figure 4. Dual homed IPv6 BGP peering

Figure 5. IPv6 PI and PA with local Internet hop off

As for those that are dual homing but not running BGP they do not require ULA or a NAT solution, simply run both IPv6 PA address space on the network (Figure 1) and let RFC 6724 solve the source/destination matching. If you want more control you can manage the prefix policy tables on your hosts or do some routing policy work within your network. Even so, if you are doing dual homed but no BGP you likely don't have a large enough network to care or bother with those efforts. Either way, I believe it is still simpler to use both service providers IPv6 PA space than to deal with ULA and NAT.

Thoughts? What other ways to you see ULA being an advantage over global unicast IPv6 addresses in your network?
- Ed

My book is available for pre-order on Amazon or you can order directly from the publisher Apress

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

Some thoughts from the 2013 North American IPv6 Summit

After spending the last few days in Denver, CO participating in the largest IPv6 event in North America (and freezing due to a cold front moving through and dumping snow - in April no less!) I have come up with some take aways.

First, there are several dilemmas in the industry affecting adoption of IPv6. Specifically, the lack of content providers having their content available via IPv6. The disparate performance differences on the public Internet for IPv6 vs. IPv4 and the fact that it is not being accurately measured or even being paid attention to by the majority of service providers. And finally the challenge that enterprises are having in deciding between DHCPv6 stateful vs. DHCPv6 stateless vs. wanting to use SLAAC w/ RFC 6106 (no thanks to Android for making that problem worse.)

Second, the lack of interest, press coverage and buzz around IPv6 is upsetting, even the home page of Network World did not have a single mention of the word IPv6 after the last day of the Summit (actually any day of the summit.) I was surprised this year by how many colleagues and friends felt it more important to attend OpenStack in Portland and ONS in San Jose rather than attend the IPv6 Summit. What is even more alarming is the fact that both those events are around technologies that MUST have robust IPv6 support or they will fail long term, in other words they will have no market if they don't have an IPv6 solution. Perhaps it was just unfortunate timing that all three events were the same week but there were some noticeable gaps in attendance and in some key luminaries who chose to attend some of the other events. Granted, the weather, American Airlines having issues which grounded its fleet and the horrible news from Boston and it's subsequent lock down likely had an impact on attendance. Even with that I still feel the messaging on how important IPv6 will be to those in the IT community can't be over emphasized and I find it alarming more people are not participating and learning about IPv6. This event is a rare opportunity to learn arguably one of the most important basic skills you will need in your career as an IT Professional regardless of role. As a side note, both OpenStack and ONS sold out but the NA IPv6 Summit still had room for more attendees. I am not sure why that is and would love to hear what others think about that.

Third, the slow realization that IPv6 is not accelerating but is actually slowing down in adoption. The application rate for Provider Independent (PI) space is slowing, the role outs of IPv6 to service provider customers is not happening at an impactful rate and because of the lack of content its use will languish until more Enterprises feel it is important to have as a transport option. There is serious case to wonder if IPv6 will make it or if everyone will decide to make horrible IPv4 NAT on NAT on NAT (NAT444) solutions and just deal with brokenness and performance problems indefinitely. Perhaps they are hoping that eventually it will be somebody else's problem to deal with.

So, in summary, while I am a huge IPv6 advocate I am getting tired of being ridiculed by manufactures, peers, industry pundits and customers whenever I bring up the topic of IPv6 and adoption and everyone's response is "isn't that dead" or "no one actually uses IPv6" or "I hope to retire before I have to learn that" as quips back to my inquiry. Honestly, I am to the point now where my response is going to be "be part of the solution or get the heck out of the way" with perhaps some expletives in the mix depending on the audience. As an anecdotal side note, I have had several long time IPv6 colleagues and industry leaders tell me they are not focusing as much on IPv6 due to the incredible frustration of it being ignored and the frightening thought that IPv6 might not actually make it as a legitimate technology solution due to the lack of interest and adoption. Apparently growth for the Internet just really isn't that important.

- Ed

Co-chair, CA IPv6 Task Force

IPv6 to IPv6 Network Prefix Translation or NPTv6

I was reading through some comments on reddit about NAT66 or RFC 6296 which is really NPTv6 and I realized that universally there seems to be a misunderstanding of why NPTv6 is needed, when you would use it and that it was intended to only address the needs of those use cases and not to emulate what is happening in IPv4 today.

Credit should be given to far smarter folks than I on this topic, specifically Dan Wing with Cisco who first explained NAT66 to a lot of folks (notice he is presenting on how to avoid having to do NAT66) and who also authored the Happy Eyeballs draft RFC which should pop out of draft here shortly. Dan is soft spoken but I'll call out that he is the co-chair of the IETF Behave (Behavior Engineering for Hindrance Avoidance) working group along with Dave Thaler from Microsoft. Obviously Fred Baker and Margaret Wasserman for authoring the RFC though I haven't been lucky enough to chat with either of them about it, though I hope to do so, opportunity permitting.

Okay, on to NPTv6.

So what is NPTv6? NPTv6 is simply rewriting IPv6 prefixes. If your current IPv6 prefix is 2001:db8:cafe::/48 then using NPTv6 it would allow you to change it to 2001:db8:fea7::/48 - that is it. It is a one for one prefix rewrite - you can't overload it, have mismatching prefix allocations sizes, re-write ports or anything else. Importantly, it doesn't touch anything other than the prefix. Your network/host portion remains intact with no changes.

So what is NPTv6 not? It is not for sharing IPv6 addresses, it is not for port overloading and it is not stateful.

Now that we have the ground rules set lets talk about the use cases that NPTv6 was brought about to address. Fundamentally NPTv6 addresses deficiencies in current host behavior and the lack of support for source address selection, next-hop route selection and split-zone DNS. The most common use case condition will be to fix source address selection issues for home and SMB's that have two providers (for whatever reason, redundancy, walled garden services like VOIP or IPTV, etc.) For almost all Enterprises this is not an issue as they will obtain Provider Independent (PI) IPv6 space and dual home properly. They might have to deal with split-zone DNS but I will address that in another post.

What happens when you have two Global Unicast Addresses (GUA) on the same interface? To clarify, not two interfaces each with a GUA. The host has to make a decision about which interface to use yet it knows nothing about how routing works within the network and therefore likely uses RFC 3484 to determine what to do. There are already many issues with host behavior outlined in RFC 5220 so go read that to get a good idea of some of the challenges.

Lets go over a sample practical use case to show where NPTv6 might help your home dual provider situation. This is an example - the prefixes are unnaturally large for an SMB or home user and I will update the diagrams later to properly reflect potential prefixes you would get in a real world situation. Regardless, it is sufficient to show the issue.

Source Address Selection Diagram - the problem:

The solution for the home user or SMB is to remove the multiple IPv6 GUA configuration and use a single IPv6 GUA address on the interface. Once this is done then you end up with proper traffic flow.

Source Address Selection Diagram - the fix case 1:

In the above diagram the host only has a single GUA to source traffic from and therefore selects it to send a request to a server, in this case 2001:db8:f000::1. Notice that the host forwards the traffic to RTR A which is it's default gateway. RTR A then forwards the traffic outbound and everything works as expected.

Source Address Selection Diagram - the fix case 2:

In the above diagram the host only has a single GUA to source traffic from and therefore selects it to send a request to a server, in this case 2001:db8:ff00::b. Notice that the host forwards the traffic to RTR A which is it's default gateway. RTR A then forwards the traffic to RTR B because a static route assignment has been entered for a longer specific prefix in this case. RTR B receives the traffic and because it has NPTv6 set up it realizes it has a prefix match and must do a prefix replacement prior to forwarding the traffic upstream. RTR B then forwards the traffic outbound and everything works as expected.

So realistically, how do we avoid all this in the first place? The only way is for the host to gain more intelligence in making decisions about what source interface address to select. Some sort of policy control would have to happen on the host OS. Alternatively, all hosts could participate in some sort of routing to determine proper paths and hold a route forwarding table. I don't really see that as a viable alternative in many environments today.

In other words, there is little a network engineers can do to fix this problem. It really is an OS host issue and if network engineers really want NAT to go away fully in IPv6 then we have to beg and plead to get a fix done in all the major OS platforms. It also brings to light one of the biggest changes between IPv4 and IPv6, a host can have multiple IPv6 addresses per interface. Somehow we need to get routing information onto the host.

So, is NPTv6 desirable from an IPv6 perspective? I would argue no, I would prefer that my host selected the correct source address and everything just worked. The problem is that it doesn't work that way today and for the foreseeable future it doesn't look promising. So NPTv6 is a necessary evil to address some of these corner case condition of getting IPv6 deployed widely on the Internet today.
- Ed