Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I'm glad my new Linode hosted server offers an IPv4 and an IPv6 address as well.
And default DNS records, when using Linode as NS, shows both A and AAAA records

example.com 86400 IN A    203.0.113.4
example.com 86400 IN AAAA 2001:db8::ff00:1111:2222:3333

which is good, web applications are available from both v4 and v6.
However, I realize many ISPs (at least where I am) do not offer IPv6 connectivity yet.

Thus an access from a browser via IPv6 from such an area will perform a AAAA (v6) request successfully. However the http(s) connection using that v6 address will fail.

Do I have reasons to worry of such thing happening with recent browsers?
Should I remove the IPv6 addresses from the DNS zone to ensure IPv4 only accesses?

--

Note: this is not the same question as this one which focuses on DNS resolution problems

share|improve this question
2  
The classic approach was to straight-up prefer IPv6 but now approaches like en.wikipedia.org/wiki/Happy_Eyeballs are rather common. –  Håkan Lindqvist Aug 2 at 11:33

2 Answers 2

up vote 8 down vote accepted

The problem you are asking about was a major concern 4-5 years ago. It probably delayed IPv6 adoption by a couple of years. Nobody wanted to go first because they feared their website may appear unstable, and users would move to competing sites without IPv6 support.

Many companies put an effort into resolving the problems. Arguably, the Happy Eyballs approach, which @HåkanLindqvist linked to was the most significant contribution to getting the problem resolved.

In 2011 there was sufficient confidence that the problem was resolved, that major websites made a coordinated 24 hour test run called World IPv6 Day. The coordinated test run was intended to ensure any users still having a problem would not incorrectly jump to the conclusion, that the problem was with one specific site rather than their own connection.

The results were successful enough, that one year later major websites switched on IPv6 permanently in World IPv6 Launch.

We are close to the tipping point, where the problems caused by NAT will get larger than the problems caused by broken IPv6. At the moment both are small enough, that it is difficult to measure, if we have already crossed that tipping point.

My recommendation would be to configure dual stack DNS records as soon as you have working native dual stack connectivity. The sooner you start, the longer time you'll have to resolve any issues it may have. You want it to be stable by the time it becomes truly mission-critical.

Don't deploy servers on 6to4 or Teredo addresses, if those had been your only options to get IPv6 on your server I would have recommended switching to a better provider.

However I do recommend configuring 6to4 and Teredo relays directly on your own server, if your server has a public IPv4 address. Deploying those relays will give a more reliable connection to your server for clients using either 6to4 or Teredo.

Occasionally there will still be clients with broken IPv6 connectivity. But for the last two years, those clients would experience problems with major sites, so you can expect those to resolve their own problem somehow. They are unlikely to see a problem with your site only.

You do however have to pay attention to the IPv6 connectivity of your own site. Should your site have an outage on the IPv6 connection, you may affect a small number of users with working IPv6 connectivity and a pre-happy-eyeballs browser. Those would see a problem with your site only, but everything else would be working.

Just because IPv6 has fewer users at the time being, it doesn't mean it can safely be deployed with less monitoring than IPv4. If anything, I say you need more monitoring for the IPv6 connectivity because you are more likely to not notice any problems.

share|improve this answer
3  
Two notes: All of my monitoring covers every IPv6 service. I wouldn't put up a service without monitoring, of course. And, Happy Eyeballs was meant to work around the situation where a client has broken IPv6. –  Michael Hampton Aug 2 at 14:36
1  
@MichaelHampton Happy Eyeballs helps regardless of whether the brokenness is on the client or the server side. In some cases it isn't even clear on which side the brokenness is (for example if the root cause happens to be a peering dispute). If the server is dual stack, but IPv6 connectivity to the server fails, you will not notice simply by browsing the site if your browser uses the Happy Eyeballs approach. But in that case you could still affect users with less reliable browsers. But of course only users with working IPv6 connectivity would see a difference. –  kasperd Aug 2 at 15:59

To add something to the other answer and comment:

I realize many ISPs (at least where I am) do not offer IPv6 connectivity yet. Thus an access from a browser via IPv6 from such an area will perform a AAAA (v6) request successfully. However the http(s) connection using that v6 address will fail.

No, it will (almost) never try to make an IPv6 connection. The system knows it doesn't have an IPv6 connection. getaddrinfo() won't return any IPv6 addresses to the application. (The reason that it will make AAAA queries anyway is because the website could have an AAAA record that genuinely works, such as the localhost IP address, ::1.)

This is only an issue for a vanishingly small percentage of systems: those that incorrectly think they have IPv6 connectivity and are running a browser several years old. As mentioned above, thanks to World IPv6 Day and World IPv6 Launch, most of them have already been fixed, since there's blood in the streets when Facebook and Google go down, and browsers have implemented Happy Eyeballs, so a failed connection only costs a couple hundred milliseconds.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.