Handling modern IPv6 in programming environments
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_V6ONLYsocket 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
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.)