Whether you’re traveling for business or pleasure, one of the great wonders of the modern age is hotels that offer Wi-Fi.
OK, I’ll grant you it’s not as wondrous as organ transplants or using a crane to lower a robot onto the surface of Mars. But when you get to your room and find that you can log in ok and will be able to check your maps, dinner plans and maybe call you loved ones, it’s a comforting thing.
So, it’s equally uncomfortable when you’re sitting in your hotel room one evening, open up your iPad and find the previously-working wireless isn’t working. The nature of the Wi-Fi in this hotel was that you connect to their access point (no password required) and it pops up a login page asking you to enter a username & password. Once entered, you’re good for the next 12 hours or so.
My initial thought was the wifi authentication had timed out, however there was no sign of the login page. Further investigation, and cross-checking on my laptop soon gave me the answer. All I had was a self-assigned IP address. Clearly, the hotel’s DHCP server had crashed (or maxed out, which also happens often in large hotels.)
I was about to give up, resolving to call the front desk the next day, when my iPad alerted me that someone had liked one of my Facebook posts. That’s a rarity in itself, but what was even more unusual was how my device, without an IP address, had known that.
So, with my curiosity piqued, I delved into the iPad’s settings once more, and that’s when I saw it. I had no IP address, no default gateway and no router. But I had two DNS servers listed, and they were both IPv6 addresses.
For those unfamiliar, the next generation IPv6 is very good at self-configuration. It will discover routers and DNS servers by itself, and can assign a unique but fully routable IP address. It would appear that the hotel’s internet service (provided by Comcast) supports IPv6 on the router so I was magically visiting an “IPv6 Only” world.
I could load up Google and search, but rarely could I open a page from the results. Facebook was mostly operational, and YouTube-hosted videos in my timeline would play on request. My email (provided by GMail) would work, but messages with embedded images would not.
I checked against http://www.whatismyip.com (wouldn’t load) and my newly discovered http://www.whatismyipv6.com (which did). Definitely still on the IPv6 world. So, it occurred to me that all I really needed was a proxy server. There are plenty of free web proxies and VPNs out on the internet, but virtually all of the ones I use are for IPv4 services. You typically don’t use them in IPv6 since every address is, or should be, globally routable without the need for a proxy or NAT. I did find one over at http://sixxs.net which is an excellent IPv6 resource. They incorporate a service called IPv6Gate where you can enter any web address, appending .sixxs.org to the server name, and it will reverse-proxy the v4 server to v6. And it works well. It won’t do https sites, which is true of most public proxies and you shouldn’t trust any that do.
Of course, by the next morning, some IPv4 luddite had called the helpdesk and they’d fixed the DHCP server. I was a little disheartened, but only a little because in truth whilst my email and web browsing had worked, most of the apps on my iPad and phone hadn’t.
So, some of my key lessons learned from this are:
- IPv6 is around and it works. It works well, and where it doesn’t there are fairly easy work-arounds to get where you want to go. For example, I’d assume that if I configured an IPv6-accessible SOCKS proxy somewhere on the internet, I could have dropped that into my configuration and my apps would all have worked.
- Under the hood, iOS does support IPv6 – even if the user interface doesn’t make it clear.
- When you’re building apps, you really should make sure your hosts are IPv6 accessible. IPv6 has kind-of been a chicken-and-egg problem of who will adopt it first. But the time is here. Incidentally, if you’re hosting on an Amazon AWS instance and are using their Elastic Load Balancer, you already have IPv6 ready to roll with a simple DNS change.
- When doing number 3, you should also make sure your host-based firewalls are IPv6 aware and the rules are consistent between them. As I said above, IPv6 is globally routable, so locking down your IPv4 firewall but leaving v6 open is a huge risk.
which leads me to the big one:
5. At no point in this adventure did the hotel’s systems prompt me to log in. Their access and billing system was entirely geared towards capturing and proxying IPv4. If I’d asked, my guess would be that they had no idea their router supported IPv6 traffic and certainly it wouldn’t occur to them that someone could – by accident or design – bypass their authentication by switching to IPv6 only.
And that’s why what you don’t know really can hurt you.