If you look at the internet at the moment, from a more technical point of view, you will often find users complaining about the „new“ Internet-protocol IPv6. Most of the time the complaints are about issues with the Internet-Service-Provider ISP used.
I will focus on the issue based on my experience in Germany (things might be different in your location, feel free to leave a note in the comments). In fact the technical introduction of IPv6 went unnoticed for most of the average users. This is partly due to the fact, that in the beginning there were not so much services that were accessible via IPv6 (a typical chicken-egg-problem) and most operating systems seamlessly degrade to IPv4 if a service is not available in IPv6.
The root cause – we are out of IPv4 addresses ….
Were things got problematic was the way many providers tried to solve the issue of not having enough public IPv4 addresses to distribute among their clients. But hey, you know there is something called network address translation (NAT or as some may remember IP-Masquerading). This works quite well to kind of „stack“ or „encapsulate“ networks into each other, especially when using private (and therefore non-unique) IPv4-Ranges. Basically this is what happens inside your „Router“ which most of use nowadays use to connect their homes and offices to the internet. Taken to the next level we get CGNAT (carrier grade network address translation), basically routers are chained behind each other, once for your own private network with one single gateway (the router) and once again for a set of customers towards one public routeable IPv4-Address.
Problem solved for outgoing traffic and related traffic towards the customer, just keep track of the Connections and mangle/masquerade according to the rules. Most of the users won’t even notice that this is happening.
However it breaks with the idea of end-to-end communication and all devices being equal, when it comes to consuming and providing services. Behind a CGNAT, in contrast to your own router, you are not able to setup such things as port-forwarding anymore, as you are not in control of the router your ISP uses.
Most of the time, things were made even worse by using a technique known as DualStack Lite. While regular dual stack means that you get the best of both worlds, „lite“ implies that not all features are at your disposal. In more detail: You don’t get a set of a single IPv4 address and an IPv6 subnet for your router upon connection, but only an IPv6-Subnet and an instruction to your router to encapsulate everything that is IPv4 into IPv6-Pakets which will be unwrapped at your provider to do 6to4 CGNAT.
So now there is no way to reach your network from the outside via IPv4, which makes things quite complicated if you are used to access your home via an IPv4-Address and port-forwarding on your router. This really hurts if you like to access your smart home, your home-server, Voice-over-IP-Solutions (phone) and VPN – basically anything that runs IPv4 and relies on Port-Forwarding setup.
Most of those setups were just not ready to use IPv6 and sadly as often the recommended solution was: „Just switch of IPv6-Support in your router and everything is like it used to be ….“; problem solved, at least sort of …
On the other end of the line, things do not look much different …
Remember the „old days“ of the internet? Almost unlimited freedom, each and every endpoint connected could be a client or a server or even both at the same time. Providing a service was not much more than just run some kind of server software and anyone that wanted to reach out to you or use your service.
In order to become more efficient multiple technologies were established to run different services on the same machine at the same time. This especially holds true for HTTP (in the early days no one cared so much about encryption). The possibility to run multiple webpages (or webservices) on one single IP was top-notch. As the amount of IPv4 addresses is finite, this technique even got more elaborate: Just place a dedicated Load-Balancer (also called Reverse Proxy) at the IPv4 entrance, which will distribute the requests to a set of backend servers that are connected to a private network behind it. Sounds like Port-Forwarding? Well it does a similar thing, but is attached to a different level in the OSI-Model. Port-Forwarding is done on the transport layer (4) while HTTP(S) Reverse Proxy software is located on the Application level (7). But in the end it is always an additional step up the protocol level which breaks end-to-end communication, even if it is done with good intentions.
This technique works so well, let’s use it everywhere
We got so addicted by the idea of (port-)forwarding, NAT and reverse proxies because it and is the de facto standard for IPv4 for most of the users on the internet. It is just how you needed to work to get around the limitations of the sparse IPv4 addresses and the idea of utilizing a single server to the max.
However this also created some very strange consequences: Docker, the new and shiny way to built and package server software was introduced to the market in 2013 and got popular around 2014. It took utilizing a single machine to the max to a brand new level, and guess what was one of the nice features? Of course: The docker daemon also interacts with the firewall of the linux kernel and sets up port forwarding automatically if requested. No more headaches to fiddle around with this as and admin. Of course it could not break the basic rules of TCP/IP, „one port, one service“ still holds true. So running multiple HTTP(S)-Services on the same host as docker containers still limited the possibility to expose those services to the outside world to a single one. Of course it was still valid to run HTTP(S) an non-standard ports, but this not a common use case you want for the user – http will by default run on port 80 and https will run on port 443, under normal circumstances your browser takes care of these details for you. Even commandline tools like curl or wget integrate this without any additional work to be done.
To get around the limitation of the single port of entrance, it is common to have a dedicated reverse proxy software, nowadays running as a container as well. Common software products used here are apache (configured as a reverse proxy, mod_proxy), nginx and traefik. Especially traefik is popular because it allows for containers to auto-register with the load-balancer based on special docker-labels.
All of this is done because it is a known and well established pattern in the software architecture. There are also some additional options you get when using a reverse proxy: It is easy to distribute the incoming requests to a set of different dedicated endpoints, based on certain criteria (you may even distribute http(s) requests to different backend services based on the path (all the stuff after the hostname). One should keep in mind that forwarding inside the same machine may help to shed the load to dedicated and specialized endpoints but will not magically help to outgrow the underlying hardware – load balancing to reduce load on the machine will not work out, the hardware is the limit. Of course you get something like a failover, if the software in one of the backend containers crashes, another instance might still work properly, or you may do seamless upgrades/switchovers.
Reminder: this all is required and standard when using IPv4, and sadly docker just chimed in: Just automate the IPv4 stuff, because IPv4 is still the most used standard (although the first IPv6 drafts date back to 1998). Basically it all comes back to use Port-Forwarding, NAT and Reverse Proxies with backend networks and services hidden behind a single IPv4-address, using a private IPv4 ranges for everything internal.
IPv6 – just an increase in the version number….
With IPv6 this model may still valid, but there is no guarantee. Of course you could assign private IPv6-ranges to your docker networks and continue to use a reverse proxy setup. Nonetheless the idea of IPv6 is different: Each and every device connected to the Internet should be able to obtain a global unique address and communication between client and servers should not be required to be proxied / NATed / DNATed. In fact NAT / Masquerading was introduced as a „workaround“ as there was usually no way of assigning a complete subnet to a single dialup or DSL connections with IPv4. Of course if you were or are a large company you may could get such setups up and running but for the average internet user such a setup way out of scope on a technical level as well as from a financial perspective…
IPv6 aims to solve this exact problem: the address space now is much larger, instead of only using 32 Bits for an address, an IPv6 address is 128 Bits long meaning there is approximately 2^96 times more space. This is why usually a router or server even gets a complete subnetwork of /64 in size for free by the ISP or hosting organization. The use of the assigned range is absolutely up to the consumer, you could just use one of the addresses, under normal circumstances each device you connect to your router (no matter if its WiFi or LAN) is assigned an address from the range assigned. To prohibit unauthorized access to any of the network „inside“ the router usually is configured as firewall blocking unwanted traffic right before it can even enter the internal network. This kind of „security“ came for free with NAT, but should not be seen as „benefit“ of IPv4. It is more an undesired side-effect that made port-forwarding, reverse proxies and things alike necessary in the first place.
Conclusion
„Just switch of IPv6, no one needs it today and you will again be able to use your existing patterns of access“. This was (and sometimes still is) a common advice to be read. While it works as a hotfix and very short term solution, it is definitely no longer advisable to do so in the long run. The IPv4 space is exhausted and more and more Hosting and Cloud provides start to charge a small extra to get an external IPv4-address, so the more expensive this extra will get, the more and more services might become IPv6 native.
There is also the common misunderstanding, that IPv4 together with NAT is a very solid barrier to protect your private network. However, it’s a myth that IPv6 will make wash away this barrier. Every router you get to buy today is configured with properly preconfigured Firewall included. Remember, that the origins of NAT / IP-masquerading were in fact an extension of the firewall built into the linux kernel. Indeed: by the time you still compiled your kernels yourself, you had to make sure your kernel even supported Masquerading!
There are also some concerns out there when it comes to IPv6 that each and every device gets more trackable, as it is no longer hidden behind a single IPv4-address that may be used many different people. While this holds true if you use completely static IPv6-addresses, in reality there are some mechanism involved to mitigate those issues: By default at least in Germany you will get a „fresh“ IPv6 prefix assigned to your network each time you reconnect (most routers are also setup to do so every day by default). And there are also the Privacy Extensions which will use random IPv6 suffixes inside the given prefix (one out auf 2^64 possibilities).
On the other hand you may even desire to get a fixed IPv6 prefix. You usually get one from your hosting provider for virtual or root-servers. Having a fixed IPv6 address makes it possible to reach your services without worrying about such things as DynDNS where you would need to update the DNS-Information based on the currently assigned prefix. Taken to the next level, it may also be favorable to get a fixed prefix for your home, giving you a more convenient access to your home or office (don’t forget to setup the firewall correctly to only expose what you really want to expose).
I hope I could clarify some of the issues I usually encounter when talking about IPv6-support with friends and colleagues. There have been some issues like DS Lite which made transition much more hassle than it should have been and therefore a kind of shadow is hanging over IPv6. But if you look a bit more closely you will see the benefits and possibilities. This holds true for the client and server side as well, always remember: On the internet you do not need to be just a client, you may and you are even encouraged to became a server and offer your digital services to the world.