[zeromq-dev] IPv6 patch

[Steven McCoy]

2010/1/25 Martin Sustrik <sustrik at 250bpm.com>:
> Hopefully, the IPv6 support will improve in the future.

Ok, I was wondering about port handling too, the de facto standard
appears to be using square brackets, e.g.

 tcp://[fe80::21e:37ff:fe34:a386]:5555

Instead of as listed in the JIRA,

 tcp://fe80::21e:37ff:fe34:a386:5555

> There's one bit I an not sure about though:
>
> - rc = ::connect (s, (sockaddr*) &addr, sizeof (sockaddr_in));
> + rc = ::connect (s, (sockaddr*) &addr, sizeof (addr));
>
> This means sockaddrlen parameter is set to sizeof(sockaddr_storage) even though actual address may be shorter. Doesn't it matter? I've  checked both POSIX documentation and Stevens' book but both are quite vague on the topic.

I've been using a convention of only using sockaddr_storage for
storage, passing sockaddr pointers about instead.  Whenever a call to
libc occurs I pass the size of sockaddr_in or sockaddr_in6 as
appropriate.


>  As for PGM I am aware that there's IPv6 support, however, I have no idea about details.

OpenPGM is fully compliant with version 2, version 1 doesn't support
scopes / zone identifiers.  The only limitations are on Solaris, as
I'm not using SIOCGLIFCONF, and the Linux platform has broken or
missing IPv6 NSS networks support.  Zone indices maybe adapter names
or indexes, names preferred on Linux, indexes on Windows.  When using
group_req or group_source_req structures about they always have an
interface index in addition to sockaddr_in6's zone identifier.  I've
also tested various configurations including multiple link-local
scopes with the same addresses.  The only difference is that you
usually have to specify a little more detail as not to pick up IPv4
interfaces and addresses instead.  Frequent mistake is not having a
IPv6 nodename.

Malo has also been testing both IPv4 and IPv6 on Windows.

I find the more demanding area is dual-stack and general 6to4 interop
which is completely different everywhere.  With PGM you can
theoretically use IPv4 and IPv6 addresses together in one transport
crossing multicast groups and families.  The code is designed to
handle this slightly Byzantine configuration but I'm not overly eager
to test the plethora of combinations actually possible.

Testing has shown the overhead of IPv6 is minimal in bandwidth and performance.

-- 
Steve-o