Repository navigation
ipv6only listen option #17664
Description
Activity
+1, we should have something like
net.createServer({ ipv6only: true })#9390 (comment)Putting it on
createServerseems wrong to me, it's a flag specific to the listen action, so should be on listen/bind.This makes sense on the net side, but do we need this on the dgram side? On my machine at least, I seem unable to bind a
'udp6'socket on an IPv4 address, and vice versa.unable to bind a 'udp6' socket on an IPv4 address
Yes, seems that's not possible, I get a "bind EINVAL" when attempting this, so it seems for UDP, the bound address family is dictated by the type of socket and the issue only applies to
net.- added a commit that references this issue
on Nov 21, 2018 - added a commit that references this issue
on Nov 24, 2018 - added a commit that references this issue
on Nov 28, 2018 - added a commit that references this issue
on Jan 14, 2019 - added a commit that references this issue
on Jul 27, 2026
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.