[zeromq-dev] PGM endpoint format for IPv6

[Steven McCoy]

As part of testing PGM on Windows I'm verifying how IPv4 and IPv6 adapter
naming schemes work cross platforms.  ZeroMQ manual documents the easiest
case of specifying an endpoint such as "pgm://eth0:7500".  This is perfectly
fine if you only have one address family and one address per NIC, when you
add IPv6, i.e. default configurations of modern operating systems, this
becomes a bit more complicated.

By default OpenPGM is going to try to use the nodename to find an address to
determine the default address family of the machine in order to determine
which family to use when resolving "eth0".  This is nice and easy again for
the IPv4 case but with IPv6 we have multiple scopes per interface and so it
will not work.  Then OpenPGM will use the node address as the preferred
default device but this might not be correctly configured on workstations
which might use a loop back adapter.

IPv6 address scope identifiers allow you to specify an address specific to
an index as the link-local scope is unique per adapter.  Example usage is
"pgm://[fe80::ed5e:7285:9ea0:2ece%19]:7500", but this forces you to specify
the adapter for every node on a network.  A nice alternative is to use
scoped network addresses however they are not supported by Windows but can
be manipulated outside of the stack, an example endpoint would be
"pgm://[fe80::%19/64]:7500" which demonstrates the limitations of Windows
scope naming scheme as Unix land offers a more convenient form
"pgm://[fe80::%eth0/64]:7500".  You could guarantee a particular network
name is common between all nodes but guaranteeing an interface index is
highly unlikely.

This issue is only relevant to the link-local scope, more likely in a
deployment a global scope is used then you can just use the form
"pgm://[2002/16]:7500", etc.

As of current trunk the scoped network address format is not supported but a
new API has been implemented that can be used to support it.

-- 
Steve-o
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20101014/29a8dcc0/attachment.htm>