Is IPV6 Dual-Stack really a best method for IPv6 design ?

There are mainly three IPv6 transition methods; Dual-Stack, Tunnelling, and Translation. Careful engineers can understand the difference between IPv6 migration and IPv6 transition.

All of these three technologies are used to bring IPv6 protocol capabilities in addition to IPv4, they are not migration mechanisms. Migration means removing IPv4 completely and running only IPv6 only in the network which might not be the case at least for the next decade.

In this post, I will explain why IPv6 dual-stack unlike most people believe is not the best transition approach.  

There is a saying, Dual-stack where you can, tunnel when you must, translate if you have a gun in your head.

Vendor materials and many industry experts also recommend dual-stack as the best approach, but it is definitely misleading. They shouldn’t do this and you should think at least three times when you listen to vendor engineers! In order to understand why the above statement is not true (dual-stack is not the best approach for IPv6 design), we have to understand what is IPv6 dual-stack in the first place.  

What does IPv6 Dual-stack mean?

Dual stack refers to running IPv6 and IPv4 in the network together. But not only on the routers and switches but also on all the links, host operating systems and most importantly on the applications. In the Enterprise networks, this can be local area network, wide area network, and the datacenters but in the service provider networks, it will be access nodes, pre-aggregation, aggregation, edge, and core networks, also datacenters, and the RAN (Radio Access Network) network, mobile handset and the applications inside the handset, CPE modem and many other devices.

As you can see, it is not just about network routers that are IPv6 capable but everything in the network that needs to support IPv6. Actually, the easiest part is to enable IPv6 dual-stack on the routers. The hardest two parts of the IPv6 dual-stack deployment are the applications and the CPEs. CPE is a term used in the Service Provider networks which define the devices in the customer location.

For example, an ADSL modem is a CPE for broadband service. Since there might be millions of ADSL modems that need to support IPv6, imagine the size of the deployment, and the time to complete these types of deployments, especially if the hardware needs to be replaced.

Also with Dual-Stack, in addition to IPv4, you will have IPv6 as well, memory and CPU requirements will be much more compared to IPv6-only networks or other IPv6 transition technologies. Thus you change the routers with the bigger ones (Scale-UP) generally which is good for the networking vendors (Juniper, Alcatel, Cisco, etc). It wouldn’t be wrong if I say that this is one of the reasons they are advertising that dual-stack is the best approach for IPv6 design. If you think that dual-stack is hard if not impossible for many of these networks just because of the scale of the deployment, you are wrong. There are other things.  

IPv4 addresses exhaustion and common solutions:

As you know public IPv4 addresses have been exhausted. Most of the RIRs (Regional Internet Registry) already assigned their last IPv4 address blocks to the Service Providers. So if you go to the RIPE, ARIN, or any other RIR today and ask IPv4 address, you might not get anything. IPv4 is done. This doesn’t mean Service Providers ran out of IPv4 addresses as well.

So as an Enterprise customer, if you ask your Service Provider to assign an IPv4 address, you might still get a small block, but many of my customers recently tried to get a new address block (Very small, /25, /26) and their service providers asked justifications and wanted the customer to pay them a lot of money. But how can service providers solve their IPv4 issue if they cannot receive an IPv4 address from the Regional Registries?

The very common answer is CGN (Carrier Grade NAT). Most of the Service Providers today implement Carrier Grade NAT.

CGN is also known as LSN (Large Scale NAT). And in my opinion, it should be called LSN since there is nothing for CGN to be a carrier grade. It is just a NAT.

CGN Double NAT

With CGN, Service Providers do NAT44 on the CPE from private address to another private address (Well known /10 prefix which is allocated by IANA) and another NAT44 on the Service Provider network. That’s why you can hear CGN, LSN, Double NAT or NAT444. All of them refer to the same thing.

But with CGN you are not enabling IPv6.

You are just trying to solve the IPv4 depletion problem in a very problematic way. I won’t talk about the problems of NAT in this post though.

Companies are also using trade-market to purchase IPv4 public addresses. Average cost per IPv4 address is around 8-10$ currently. This might increase by the time. And it would be wise to expect to see much bigger DFZ space by the time because of de-aggregation.

With CGN, IPv4 private addresses are shared among many customers and those shared addresses are NATed at the CGN node twice.

So far in the post the size of the deployment and IPv4 exhaustion problems are mentioned to explain why dual-stack is very hard to deploy. But wait there are others.

There will be always some applications which run IPv4 only, in this case you have to use a Translator. I am talking about IPv6 to IPv4 translator and vice versa. So dual-stack may not be possible because fancy – free a lot of applications don’t support IPv6 today. (Most common example is Skype and some VOIP applications) Common solution for translating IPv6 to IPv4 is NAT 64 + DNS 64. NAT-PT was the early version of Ipv6 to IPv4 translator but there were security problems such as DNSSEC thus NAT-PT is obsolete now.  

NAT 64 + DNS 64 is good for translating v6 to v4 so IPv6 only host can reach IPv4 only host but wait, that’s not all yet either.

How you will support an application which doesn’t rely on DNS?

For example, Skype? Skype is very common applications which uses hard coded IPv4 addresses and doesn’t rely on DNS. NAT 64 + DNS 64 cannot be a solution for that. Just because of these type of applications, companies which enabled dual-stack everywhere place a translation at the host device. For example, Mobile operators uses 464XLAT on the handheld devices to support IPv4 application.  

NAT46 is performed at the handset (Smart phone, tablet, etc.) by providing dummy IPv4 address to the application, and performing 4 to 6 NAT at the handset.For example T-Mobile in U.S deployed 464XLAT to support IPv6 only devices to run over IPv6 only network.

What about IPv6 tunneling? When it might be needed?

Tunneling is necessary if the company cannot enable IPv6 on some part of the network. For example if Broadband Service Providers DSLAM doesn’t support IPv6, it is hard if not impossible to replace those until the hardware refresh cycle.

Most common tunnelling technology by these type of companies is 6rd (6 Rapid Deployment). Or Enterprise network which wants to enable IPv6 in their LAB environment, need tunnelling over the IPv4 network until all the links and routers support dual-stack.

IPv6 6rd can be used as a router to router IPv6 over IPv4 environment for this type of deployment, as well as host to host or host to router tunnelling technologies such as ISATAP can be used.

Conclusion:

Tunnelling is a solution to support IPv6 over IPv4 network and can be the interim solution until dual-stack is enabled on all the nodes and links. Our end goal shouldn’t be IPv6 dual-stack! Our goal is to have an IPv6 only network and remove IPv4 completely. This can be only achieved with networking vendors, Service Providers, Operating System manufacturer, application developers, website owners, CDN companies and many others.

Otherwise CGN or Trade-market (Buying IPv4 public address from the other companies) type of interim solution only buy a time and those solutions will be expensive for the companies day by day without IPv6.

There are companies who has IPv6 only network today!