Carrier Grade NAT is controversial but that hasn't stopped it from becoming the backstop response some carriers have to IPv4 shortage

Bruce Sinclair

October 30, 2013

7 Min Read
The Dark Side of IPv6

What started out as a lowly technology found in the home has sprung up in large-scale strength in service provider networks all over the world. The technology is Carrier Grade NAT, and it generates high emotions, no matter whether you are for it or against it.

Network Address Translation (NAT) technology is one approach to dealing with the depleting supply of IPv4 addresses. Simply put, NAT enables multiple devices to share a single IPv4 address. In your home you share your IPv4 address with all your connected devices -- computer, TV, laptop, game system, PVR, phone, mobile phone, and so on.

Carrier Grade NAT (CGN) takes this sharing to a whole new level. The purpose of CGN is to share an IPv4 address with multiple connected end nodes to squeeze a little more time out of v4 addresses we have today. By moving the tech from the home into the carrier network, a single IPv4 address can now be shared with hundreds of homes and all their respective connected devices.

The good, the bad, the ugly
To better understand Carrier Grade NAT we recently questioned the gogoNET community and received 906 responses to our poll. gogoNET comprises 95,000 networking professionals who are in the process of migrating their networks, services, or products to IPv6. Since they’re the ones doing the work they provide a unique perspective on this divisive issue.

To understand market sentiment we first asked: What is your opinion on Carrier Grade NAT (CGN)?

  • Good: I plan on deploying it and am happy to do so.

  • Bad: I will not consider this evil technology.

  • Ugly but necessary: I have no other choice but to deploy CGN, but I am not happy about it.

  • Don't know: I still need to do more research to have an opinion, or it is not relevant to me.

A full 76 percent of those with opinions considered CGN as being Bad and the technology evil. This was distantly followed by 16 percent who considered it Ugly but necessary and only 8 percent who considered it Good. Given that transition mechanisms require IPv4, another way to interpret this is that over three-quarters of the market either has plenty of IPv4 addresses or is planning to go IPv6 native or is living in denial.

Why the hate?
The answer lies somewhere between ideology, technology, and good ol’ money. Perhaps Tina Tsou, head of IPv6 Research at Huawei, summed up the ideological debate best by asking, “Is it for IPv4 life extension or IPv4 service continuity?” Jeff Doyle, IPv6 Forum Fellow and VP of engineering at TorryPoint, whom I interviewed for The IPv6 Show podcast, concurred, stating there are many intrepid IPv6 proponents who think, “Let’s not do anything that’s going to allow people to stick to IPv4 any longer than they have to.”

On the other hand, he says CGN can make the transition smoother by providing organizations the time they need to make informed transition decisions that could have high operational and cost ramifications. Paul Nicholson, director of product marketing at A10, also looks at it pragmatically, "CGNAT solves a real issue today -- helping to enable IPv6 transition as part of other transition technologies. There’s a bigger trend then just a quick IPv4 address shortage fix."

But if chosen as a transition strategy, CGN is not without its own costs. First, these stop-gap systems, whether upgrades or separate boxes, must be purchased. Most CGN architectures must establish and maintain a bi-directional state, which makes the systems inefficient and thus expensive from the perspective of scalability and performance.

But the biggest technical resentment emanates from the fact that Carrier Grade NAT will break things, as explained here in RFC 6269, Issues with IP Address Sharing. Select applications and services will stop running properly. Case in point, consider the backlash BT faced recently from its customers when its CGN deployment broke Microsoft Live.

Or maybe the hate is really self-loathing in disguise.

Transition mechanisms – the real ones
Transition mechanisms have been around for more than 10 years to avoid the exact situation we find ourselves in, and most of us know it. Dual stack and tunneling were not designed with address shortages in mind -- they require IPv4 for a soft landing on IPv6. But the economics didn’t compute. Spend money now to avoid a problem later? Nah, paychecks, bonuses, and stock options reward present results, not those that may occur in the future. So now, in the future, we find ourselves using CGN as a transition mechanism, something for which it was never intended.

And according to the market, we are well along our way. We asked those who were planning to deploy CGN (Good, Ugly) when they would start, and the answer came back in almost perfect thirds:

Approximately one-third said they already have deployed CGN, one-third said they will do it this year, and one-third said they will do it in two-to-five years. There was an outlier group -- 4 percent said they would deploy CGN in six or more years. When asked how long they thought this new tech would live in their networks, the answers were across the board, however a pliurality of 34 percent said it would most likely be there forever.

The standards path to CGN is fraught with casualties. We limited our look at the CGN forerunners du jour and asked the question, "What architecture do you plan to use to deploy CGN?" The following table displays the deployment of each CGN flavor and vendor support.

Figure 1:

To the chagrin of most, NAT444 is currently the most popular architecture and even more so when the data is segmented by those who have already deployed. Sixty-eight percent of the Carrier Grade NATs deployed today are NAT444. By most accounts, this is not good; in fact it’s the worst-case scenario. Not only is NAT444 stateful, it does nothing to move the needle on IPv6 deployment since, in contrast to the other four choices, it all works over IPv4.

Advice for the wary
Jeff Doyle has two pieces of advice for those deploying CGN. By far the most important is on testing. Create a test network and test CGN with the typical apps and services that will run over your network. Things will break (remember BT), so identify and isolate the issues, and then go to work patching them up with ALGs and perhaps other workarounds. If they are not fixable, at least you have the information you need to put together communication and support plans to deal with angry customers.

Secondly, Doyle says to keep in mind the tech's temporary nature and frame your architecture and planning with that in mind. Although 34 percent say they will leave the CGNs in their networks, probably forever, that is wrong thinking. Eventually the cost of maintaining IPv4 with CGN will cost more than getting rid of it… and the tipping point will have been found.

Dave Thaler, partner architect at Microsoft and previous lead of its IPv6 development, suggests that when buying a CGN to make sure that it conforms to RFC6888, which discusses the common requirements for Carrier Grade NATs. Global lead of Cisco’s IPv6 High Impact Project, Alain Fiocco, strongly recommends that you deploy IPv6 natively to your customer alongside of CGN, kind of like a hybrid dual stack environment: “Simply because about half of the sessions (that's about the amount of content available on IPv6 today) will bypass the CGN and do IPv6 end-to-end.”

In the end you need to decide good, bad, or ugly for yourself, but if you do deploy be aware of the consequences.

Need more?
To shine a light on the dark side of IPv6 check out the gogoNET Live! IPv6 Conference where Jeff Doyle, Dave Thaler, and other IPv6 experts will be on the discussion panel, “Carrier Grade NAT – Good, Bad, or Ugly and Necessary?” alongside leading vendors hashing out this important issue. For a more detailed account listen to an extensive interview on CGN with Jeff on The IPv6 Show podcast, and visit the gogoNET community to see the original poll data.

—Bruce Sinclair, CEO, gogo6

About the Author(s)

Bruce Sinclair

Bruce Sinclair has been in the IPv6 business since 2006 and is CEO of gogo6, provider of IPv6 products, the gogoNET community and the Freenet6 IPv6 connectivity service. Original market data for his blogs are gathered from the gogoNET social network that has over 95,000 registered members who use the community as a resource to transition to IPv6.  Bruce hosts "The IPv6 Show" podcast on iTunes and writes an IPv6 Market Intelligence newsletter for vendors selling into the IPv6 market.

Subscribe and receive the latest news from the industry.
Join 62,000+ members. Yes it's completely free.

You May Also Like