On modern Unix systems, there are four different IPv6 environments:

• Some systems do not have IPv6 enabled at all. These systems will reject attempts to create IPv6 sockets and then your code can stop worrying about the rest of this.

• Some systems have dual binding permanently disabled (the example I know of is OpenBSD). These systems will reject attempts to turn the IPV6_V6ONLY socket option off.

• Some systems support dual binding but have it turned off by default.
• Some systems support dual binding but have it turned on by default. I believe that this is the default state of the Linux kernel.

(I believe that both Microsoft Windows and Mac OS X also fall into one of these four categories, but I don't know for sure. Also, notice the corollary of this split; if you intend to be portable to OpenBSD, it is stupid to claim that Linux systems with dual binding off are crazy and do not need to be supported.)

You can detect whether a system allows dual binding at all by seeing if you can turn the IPV6_ONLY socket option off on an IPv6 socket. You can detect the default state of dual binding by creating an IPv6 socket and then trying to connect it to an IPv4 address (or vice versa). Note that the inability to connect a default IPv6 socket to an IPv4 address does not mean that dual binding is impossible; it just means that it is not the default.

(I believe that any system that defaults to dual binding on will let you turn it off with IPV6_ONLY, ie that there are no systems that force it to always be on. The cautious will want to write code that explicitly checks this.)

The most reliable and portable way to use IPv6 is thus to always explicitly turn dual binding off on all of your IPv6 sockets. As covered in ModernSocketsListening, if you really do need to listen for both IPv4 and IPv6 connections you should use two separate sockets. Among other reasons, doing otherwise can uncover subtle bad assumptions in your code.

(If your code never touches IPV6_ONLY itself and runs on a system with dual binding off, it will behave equivalently to this. However, it will not be portable; the same code running on a system with dual binding on will behave quite differently.)

If you're writing some sort of general networking environment or support library where people can ask you 'create a generic connection to <X>', it is my strong opinion that you want to avoid dual binding as much as possible. If people specify the address family of either the source (including a general wildcard listening address) or the destination, you should use that address family, and this covers almost all situations. I will reluctantly concede that you can rationally create a dual bound IPv6 listening socket if you are asked to listen completely generically, because such a socket is the only truly generic 'listen to any TCP (or UDP)' option. I still think it's unwise and it's clearly not completely portable; the program will either fail or only listen for IPv6 on OpenBSD.

(Thus, if portability is a strong concern you should reject such attempts as impossible, since there is no single portable socket that will accept both IPv4 and IPv6 connections. You may wish to instead default to IPv4 as a matter of pragmatics.)

If you write generic networking support code that works with IPv6 sockets and does not explicitly control IPV6_ONLY as much as possible, you are giving your users enough rope to hang themselves. They will get different results on different machines for both listening sockets and directly connected sockets, depending on whether or not dual binding is enabled on each machine. In specific, their code will behave one way on probably the great majority of Linux systems and another way on all OpenBSD systems and a minority of Linux systems. Since one case is rare, it is easy to miss the unportability.

(I have circled around this issue before in GoIpv6MyDesire but not laid things out this clearly, even in my own head. I wound up thinking about this again because the Go people have been overhauling their net package a lot recently, including making it compatible with OpenBSD, and their changes had me confused about whether I still needed to patch it myself and if so, how I should be patching it.)