Let me say it straight away: I strongly disagree with section 5.3 of RFC 3493 that
IPV6_V6ONLY should be disabled by default. With this option disabled it's impossible to create a server socket in a truly protocol-independent way.
When RFC 2553 was published in 1999 it described a set of functions which can be used to enumerate and resolve socket addresses in a protocol-independent way. But with the release of RFC 3493, and its introduction of
IPV6_V6ONLY, the protocol-independent aspect of these functions has been largely lost. The following example shows why:
One of the functions described in RFC 2553 is
getaddrinfo. This function can be used to get a list of socket addresses suitable for
bind'ing a server-side socket. On dual-stacked hosts it will return two addresses: one for IPv4 and one for IPv6. But when
IPV6_V6ONLY is disabled, you can't have two sockets bound to the two addresses, the second
bind will fail with
EADDRINUSE. You can either find out which addresses of those returned are IPv6 and use only those, or you can enable
IPV6_V6ONLY. But as you see both of these solutions aren't really protocol-independent anymore.
From what I gathered most *BSD distributions have
IPV6_V6ONLY enabled by default, only Solaris and Linux don't. At least Debian is starting to break the ice and enabled
IPV6_V6ONLY in their latest netbase package (4.40). That has broken a few other packages, but as the bug headline says, those are buggy and thus need to be fixed anyway.