Marco Hogewoning

50 Shades of NAT

Marco Hogewoning
0 You have liked this article 0 times.

As a friend once told me, “there's a fine line between pleasure and pain.”* There's a vast body of literature to corroborate that story, not including the 100+ million copies of the book referred to in the title of this piece. But what does that have to do with Network Address Translation (NAT)? Could the reason we all love our NATs be that they're the network engineer’s guilty pleasure? How long before we permanently cross the threshold and are confronted with the painful reality of NAT's dark downsides?

So why are pain and pleasure such good friends? It's all about endorphin, a neurotransmitter released by the human body to supress pain. Once released, endorphins can cause a feeling of euphoria (not unlike opiates such as morphine), and it's this that is responsible for the “runners' high” and similar effects in endurance sports or physical activity that pushes the body to its limits. So as far as biochemical evidence goes, there is indeed a very fine line between pleasure and pain.

Then there's the related theory on how we humans seek pleasure (comfort) and how we tend to behave once we've established ourselves in feeling comfortable. While subject to many environmental parameters, humans are generally willing to endure a little bit of pain, knowing there is some reward (pleasure) in return. Whether the prickles while picking blackberries or the recognition of completing a marathon, the model is roughly the same. In economic terms, the pain becomes an investment: no pain, no gain.

So what about Network Address Translators (NAT)? Invented a long time ago as a form of network pain relief, they were originally conceived to provide a workaround to renumbering your network, which back in the day meant visiting and reconfiguring every machine connected to that network.

As this provided some comfort (pleasure), we soon wanted more – we started to “chemically enhance” our NATs with the addition of RFC1918 private IP addresses; in further evolutions, we cranked it up to eleven by introducing NAPT or “overload-NAT”, where we share a single address between a (large) number of devices.

“No pain, no gain!" And the pain of NAT has been very well documented! The list of annoyances and things that break is long and often stems from one issue: address sharing, which breaks the end-to-end model of the Internet. For traffic to be successfully forwarded by the NAT, there needs to be a (pre-existing) mapping of the public IP address to one of the private addresses behind it. That means that any connection needs to be initiated from “inside” the NAT, leaving you with something that can be described as a client-server model. We forfeited the end-to-end in the safe comfort of knowing there is content (servers) and eyeballs (clients).

In addition, there's the comfort that the NAT serves as a form of a firewall - no unannounced or unauthorised outside traffic will make it through to the inside of the network, or at least that is what everybody is betting on. Of course, the careful observer will immediately notice that this model has some significant flaws, especially since many of today’s threats hide inside other protocols (such as email) and are triggered by client action such as clicking on a link. Clearly it's advisable to prevent unauthorised traffic to enter your network by means of a firewall, but that certainly shouldn't be your only line of defence.

Meanwhile, with the countless developments and innovations in applications and services happening under the umbrella of the Internet of Things (IoT), the general client/server model may already be shifting. More and more data generated inside the customer domain needs to find a way out, with more applications and devices dependent on external signals to perform a certain action at a given moment (like switching on the light as you make your way home).

Such a model is achievable under NAT, as push notifications on your mobile show, but the question is how much pain such a model will inflict, especially in the longer term. Not only does this put a strain on the NAT itself (since such a model relies on having permanent connections to an outside platform), but the role of the platform provider in relaying such "pushes" becomes ever more critical.

NATs have certainly provided us with some comfort, but maybe it is time to let go. Let go of them, before we find ourselves with no way out and having done permanent damage.

Maybe the little pain of deploying IPv6 isn’t so bad after all, certainly not when you realise the big pleasurable award that lies at the finish line: recognition and most of all an Internet that functions as it was originally designed.

* ...actually, it might have been the Divinyls!

0 You have liked this article 0 times.

You may also like

View more

About the author

Marco Hogewoning is acting Manager Public Policy and Internet Governance with the RIPE NCC. As part of the External Relations department, he helps lead the RIPE NCC's engagement with membership, the RIPE community, government, law enforcement and other Internet stakeholders. Marco joined the RIPE NCC in 2011, working for two years in the Training Services team. Prior to joining the RIPE NCC, he worked as a Network Engineer for various Dutch Internet Service Providers. As well as designing and operating the networks, he was also involved in running the Local Internet Registries. During 2009 and 2010, Marco worked on introducing native IPv6 as a standard service on the XS4ALL DSL network. In November 2010, this project was awarded a Dutch IPv6 award. More recently, he has contributed to the MENOG / RIPE NCC IPv6 Roadshow, a hands-on training initiative in the Middle East. Marco has been involved with the RIPE community since 2001 and was involved with various policy proposals over that period. In February 2010, he was appointed by the RIPE community as one of the RIPE IPv6 Working Group Co-Chairs.

Comments 0