[zeromq-dev] IPv6 support (was Re: Leaving my role as maintainer)

Martin Sustrik sustrik at 250bpm.com
Sun Jul 17 07:51:46 CEST 2011

On 07/12/2011 03:32 PM, Martin Lucina wrote:

Ok. Thanks! Most of it makes sense, however, connecting to IPv4 and IPv6 
in turns sounds strange.

My feeling is that, given the only problem is with resolving hostnames, 
we should probably allow hostname to be tagged either as IPv4 or IPv6:


Or something in that vein...


> Listening (bind) side
> ---------------------
> 1) If the user has specified an endpoint of '*', INADDR_ANY/AF_UNSPEC(?)
> should be used to create a dual-stack listening socket. This is the
> simplest case.
> 2) If the user has specified an endpoint using an interface name, e.g.
> 'eth0', 0MQ must determine if the interface has an IPv6 or IPv4 address,
> and bind two separate listening sockets, one to each address family.
> 3) If the user specifies a numeric IPv4 or IPv6 address then only that
> address shall be used (i.e. existing behaviour with the addition of IPv6).
> 4) For PGM endpoints, I don't know. To be discussed with Steve.
> Connecting (connect) side
> -------------------------
> 1) If the user has specified a host name, and the local machine has IPv6
> enabled at all (I forget exactly how to detect that, but it's part of the
> getaddrinfo() stuff), then 0MQ must first attempt to resolve an AF_INET6
> address for the hostname.
> 2) If the resolution fails, skip this step. Else, attempt to connect to the
> IPv6 address. If that succeeds then we are done.
> 2a) Not sure how well this is possible with the current codebase, but if
> the connection to the IPv6 address fails using a hard error that could be
> attributed to faulty IPv6 connectivity, then we should fall back to IPv4.
> Such an error could be e.g. "No route to host" or even "Connection refused".
> 3) Attempt to resolve an AF_INET address for the host. If that succeeds,
> connect to it (and assume IPv6 to that endpoint is not functional). If that
> fails, then fail.
> 4) For numeric addresses nothing changes, other than the addition of IPv6
> addressing (i.e. no fallback).
> As you can see from the above, the general idea is always to bind to all
> available address families, and then, provided the box "claims to have"
> IPv6, attempt to resolve/connect to IPv6 first, falling back to IPv4 if
> that doesn't work. Step 2a) is the complex part for us, since most normal
> TCP applications connect synchronously, and for UDP/PGM it's pratically
> impossible to tell if there's anyone at the other end so I'm not sure what
> to do there (possibly no fallback at all, since that's really only
> interesting in the simple case of users using TCP.)
> Hope this helps.
> -mato
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev

More information about the zeromq-dev mailing list