Should I use IPv6 only or both IPv4 and IPv6 in my web server?

Solution 1:

Use both IPv4 and IPv6

You should use both IPv4 and IPv6 addresses.

Nearly everyone on the Internet currently has an IPv4 address, or is behind a NAT of some kind, and can access IPv4 resources.

However, at the time of writing only about 0.7% 2.3% 3.8% 6.5% 9% 12% 19% 22% 26% 32% of the Internet is IPv6 capable, but that number is steadily growing as IPv6 begins to roll out worldwide.

In a very few places, ISPs are providing primarily IPv6 or only IPv6 to residential customers and using large scale NAT, NAT64 or other such solutions for IPv4 connectivity. This number is expected to grow as IPv4 address space is finally exhausted. These users will typically have better performance over IPv6.

Where ISPs have deployed large scale NAT to solve IPv4 exhaustion, users stuck with this will suffer reduced reliability of all their Internet connections due to the connection limits inherent in the large scale NAT gateways. For instance, a web page might only load some but not all of its resources, leaving broken icons where images should be, missing styles and scripts, etc. This is similar to connection limit exhaustion on a home router, but affecting all users of the ISP intermittently and seemingly randomly. If you want your site to be reliable for these users, you must serve it via IPv6 (and the ISP must have deployed IPv6).

Since IPv6 is where the Internet is going, having your web site IPv6 enabled now puts you ahead of the game and lets you resolve any problems long before they become serious.

Configure nginx

By default with Linux and nginx, you can bind to both IPv4 and IPv6 at the same time by changing your listen directives to:

listen [::]:80;
listen 80;

Or, for SSL sites:

listen [::]:443 ssl;
listen 443 ssl;

Solution 2:

Bind to both!

We had an IIS web site whose code did an internal reference to itself, using the DNS name that the client had used. This process would always fail.

Another symptom was that a browser running locally on the server could not find the web site by the name of the server, only by the IPv4 address. That is, http://192.168.55.139 would work, but http://myhost would fail. Using ping myhost would, by default, return the IPv6 address (ping myhost -4 would return the IPv4 address).

The fix was to open IIS and change the Bindings of the web site to bind to the IPv6 address, as well as the IPv4 address.