Or, ‘NATs continue to be evil’, or ‘the more expensive the hotel, the stupider the captive portal system’.

TL;DR: When not at home, you realise how broken the internet access usually is.

Problem 1: Not enough addresses

Originally IPv4 addressing was designed with 2^32 addresses (some of which are reserved) which was supposed to be enough (and perhaps in the 70s and early 80s, it was good assumption).

The lack of addresses was seen as a problem and IETF designed a solution for it in the 90s - IPv6 (c.f. RFC 2460: Internet Protocol, Version 6 (IPv6) Specification). Unfortunately due to various technical reason its availability is still quite low - according to Google it is currently less than half the hosts even now ( see Google IPv6 access statistics).

NAT (and related technologies) map many local private IPv4 addresses to single global IPv4 address. This is more or less mandatory everywhere, due to the IPv4 address shortage, but the outcome is that you may actually be behind more than one NAT before your traffic actually hits the internet.

Problem 2: Captive portals (badly implemented ones)

Second quite annoying thing is that while awhile ago it was enough just to share wifi network name and password, nowadays a lot of the companies like having their own weird captive portal which provides log-in functionality to the network. This isn’t standardised, and due to that different devices behave differently when that happens. And of course doing that in automated fashion is not easy.

My recent experiences

While traveling during my summer vacation, I got to play with number of airport- and hotel WIFIs. Most of them were not particularly good. None of them offered IPv6, and all except two had some sort of captive portal system.

Some observations:

  • In the first hotel, I could not make backups of my pictures to Finland, as the backup took more than 15 minutes and some NAT device decided at that point the TCP connection needs to go, and so did the (ssh based) backup at that point.
    • Wireguard tunnel to my own VPN server solved this, but this is probably not an option for normal users. I will probably configure wireguard tunnel for my travel router for the next time so I can get this working also for the other devices I take along.
  • Some of the captive portals were quite obnoxious, resetting every few hours per device. Luckily we had a device for this ( GL-AR750S-Ext / Slate ) so we needed to do the login only once every few hours, instead N logins (we had ipads, laptop, phones, and some other devices that use wifi with us) every few hours.
  • Sometimes the bandwidth was rationed (or allegedly was). We got 1GB chunk of quota, supposedly lasting 7 days, while staying 5 days at one hotel. We used 10+GB during that so it is not obvious if the system was just broken or intentionally not enabled.
    • With Apple devices, you have to configure ‘low usage’ per device, and that was too much hassle (why can’t the wifi network state it costs something?), so most of the data was actually software updates and second biggest consumer were picture backups to the cloud.
  • In some places DNS was broken (by design, or accidentally? hard to say); luckily our travel router could in those do DNS from some place which worked.
  • At home I have 200 Mbit down and 50Mbit up; it is cheapest plan I can get from my cable modem provider. This is still 10x or more faster than network connectivity in any hotel in Australia. Singapore hotel was slightly faster but still only ~10Mbit.
  • None of the hotels we stayed in (sample size 5) had IPv6 in their guest wifi; none of the airports (I am not sure how many I tried) did either.

Final thoughts

At least some parts of the IETF seem to be driving towards moving more and more of the networking to the applications (e.g. QUIC based solutions which visible just as UDP traffic to the operating system), which is nice idea, as long as you trust the applications and their configuration. Configuring every device, not to even mention every application, correctly on this trip would have been a nightmare.

Due to that from management point of view, it would be preferable to have policy in the network, and then hosts (and applications within) implement it, as opposed to applications trying to do ‘something’ which is often undesirable. Good example are these large software downloads; I guess I could have blocked them or disabled them but I was curious to see if we would actually hit some bandwidth cap in one of the hotels we stayed in, but that did not happen.