Currently, listening on the :: address will attempt to bind on IPv4 and IPv6, whatever is available. This works most of the time but a issue arises on Linux with the ipv6.disable=1 kernel option set (which can be default on certain NAS devices). With it, listening on :: results in a EAFNOSUPPORT error. To work around and still get a IPv4 socket, one would have to apply one of these workarounds:
- Listen on
::, catch the EAFNOSUPPORT error and listen again on 0.0.0.0 on error.
- Listen on
:: and 0.0.0.0 and ignore both the EAFNOSUPPORT (can happen on ::) and EADDRINUSE (happens on the latter call when dual-stack actually works) errors.
To resolve above ugly error handling, I suggest exposing the existing UV_{TCP,UDP}_IPV6ONLY flags on server#listen and socket#bind via a new boolean option ipv6only. With the option set, one can listen on :: and 0.0.0.0 without any unexpected errors happening.
Related: nginx also features the ipv6only option, which has been enabled by default since v1.3.4.
Currently, listening on the
::address will attempt to bind on IPv4 and IPv6, whatever is available. This works most of the time but a issue arises on Linux with theipv6.disable=1kernel option set (which can be default on certain NAS devices). With it, listening on::results in aEAFNOSUPPORTerror. To work around and still get a IPv4 socket, one would have to apply one of these workarounds:::, catch theEAFNOSUPPORTerror and listen again on0.0.0.0on error.::and0.0.0.0and ignore both theEAFNOSUPPORT(can happen on::) andEADDRINUSE(happens on the latter call when dual-stack actually works) errors.To resolve above ugly error handling, I suggest exposing the existing
UV_{TCP,UDP}_IPV6ONLYflags onserver#listenandsocket#bindvia a new boolean optionipv6only. With the option set, one can listen on::and0.0.0.0without any unexpected errors happening.Related: nginx also features the
ipv6onlyoption, which has been enabled by default since v1.3.4.