NAT Is The Main Inhibitor For Self Hosted Cloud Services

Lots of people I talk to like the idea of having a box at home that can be accessed remotely from notebooks, smartphones and tablets to synchronize private data such as calendar and address book information. They' like it because they'd rather like to have their private data at home than to give it up to companies that store it in a country far far away and make money by analyzing their data and selling advertising in some form or shape. Sooner or later, however, there's always a sentence like 'yes, you [Martin] can do it, but I have no idea how to go about it'. At that point I'd really like to say, 'gee, no problem, just buy box 'X', connect it to your DSL or cable router at home and you are done. Unfortunately that's just not were we are today.

To make self hosted services for the masses a reality, however, it's exactly such a plug and play setup that is required. Anything less and it won't work. I have no problem to imagine how most setup steps could be automated. A company could take open source software such as Owncloud, package it on inexpensive hardware such as a Raspberry Pi or even a NAS disk station at home and write an intelligent setup software that automatically does tasks such as registering a DynDNS domain, registering an SSL certificate for the domain and coming up with really simple to configure mobile OS connectors for calendar and contact synchronization. Money can be made with all of these steps and if reasonably priced I think there's a market for this.

But there are also some technical hurdles that are a bit more tricky. The major one is Network Address Translation (NAT) in DSL and cable routers at home today. For tech savvy users it's obviously easy to configure a port forwarding rule but for the average user it is an insurmountable obstacle. The Universal Plug and Play (UPNP) protocol implemented in most residential gateways offers the means to do this automatically and is used by programs such as Skype. Unfortunately this functionality is a significant security risk and many router vendors and DSL/cable network operators have decided to disable it by default. On top, many DSL and cable networks today no longer assign public IPv4 addresses to residential connections, hence preventing even tech savy people to have their servers at home.

Basically, I can see two solutions for this: One would be to have Owncloud and other services integrated into the DSL/cable routers. That's probably the easiest way but it would limit the opportunity to the few companies working on residential routers. The other solution could be for the home cloud box to establish a VPN tunnel to an external service from which it gets a public IPv4 address. Possible, but not ideal as it would introduce a single point of failure.

So perhaps IPv6 will come to the rescue at some point!? Unfortunately, that help will not come tomorrow. In addition I can't help but wonder if DSL/cable routers will not include IPv6 firewall functionality at some point to block incoming connections for security reasons. If so, we are back to step 1 for which we need a clever, secure and standardized way to automate initial connectivity configuration.