For the example of a network enabled sensor, there is a good chance that you would be running so little code that there would be no cookie, session ID or any of the other elements that you would find in a conventional web app.

a little more reading;
http://en.wikipedia.org/wiki/Network_address_translation#Drawbacks
http://en.wikipedia.org/wiki/NAT_traversal#The_NAT_traversal_problem

There is no debate that a NAT solves a lot of problems, but it will also introduce a couple of new issues for you as well in specific scenarios.

If you want an easier way of thinking about it, try this… for any technology that you want to scale up for use by a potential multiple billions of people, the simpler you can make it the better.

It feels a bit like the old times except with me now seriously outgunned. I’ve been responsible for quite a few web applications and never made a single one of them NAT-aware.

> Part of that NAT hygene involves keeping
> the connection alive

Isn’t the idea of a connection that it doesn’t need to be alive? This sounds more like someone trying to keep a session alive, which is a different thing that’s wholly and acceptably up to the application. New ports every time is fine for a connection, unless someone has done some daft things with the application’s security.

You don’t have to rely on an IP address to guarantee who you are, and pretty much no sensible application does. Nor does your solar-powered gadget need to post crap through NAT to keep a session going. It just sends a cookie, a session ID, or whatever you want to use instead, next time something needs to go across the network.

Or am I, apparently like the rest of your world, missing the point?

Applications needs to be NAT aware, it isn’t hard to do but it is an overhead. In a few high volume research environments the overhead starts to become significant, when you should be focusing on moving data between nodes you find yourself focusing a percentage of your bandwidth on NAT related hygine issues.

Part of that NAT hygene involves keeping the connection alive, which needs data to be send at some timed interval to ensure that your NAT enabled port stays enabled. For mobile devices this would mean that you would have to keep the radio turned on and sending data that has no real user value – draining the battery for the sake of the network rather than for the sake of your application.

That is an issue for a mobile phone, but imagine a sensor device running off a small bit of captured sunlight and you start to have real limitations introduced by a lack of avaiable running time and power. Part of the IPv6 dream is to network enable millions of devices, and for that we need direct connect (read non NAT) connect to help with the power questions.

Several of the big routing vendors are being pushed to look at “carrier grade NATs”, technology that is similar to your $100 home router but capable of managing several hundreds of thousands of NAT enabled connections. While that would provide a comprehensive answer to how much address space each ISV or carrier required for their users, it would introduce several restrictions for those users around how they use the bandwidth that they buy from the service.

NATs are a clever answer to a complex problem, but come with their own costs… they also limit the scenarios that we can build and deploy devices to support.