[jboss-jira] [JBoss JIRA] Commented: (JGRP-978) JGroups diagnostics uses hard-coded IPv4 multicast address
[
https://jira.jboss.org/jira/browse/JGRP-978?page=com.atlassian.jira.plugi...
]
Richard Achmatowicz commented on JGRP-978:
------------------------------------------
On a given host, we can have three possible cases of coexistence between IPv4 and IPv6:
IPv4 only support, IPv6 only support or dual-stack IPv4 and IPv6 support. I have read
informally that dual-stack support is not available on certain OSs (e.g. Windows XP,
Windows 2003, OpenBSD)
On dual stack machines, IPv6 has some special features for supporting the transition from
IPv4 to IPv6. One of these is IPv4-mapped addresses, where an IPv4 address can be used
together with the IPv6 API. This allows IPv4 clients to talk to IPv6 servers, for example.
It also allows managing IPv4 clients and servers from an IPv6 interface. The IPv6 API is
used at the transport level (e.g. TCP, UDP) when opening a socket. At the network level,
however, the packets are shipped using IPv4.
I don't know of (and I suspect there is not) a multicast address which is valid for
both IPv4 and IPv6.
Why isn't an IPv4 multicast address converted automatically to an IPv6 address in an
IPv6-only environment? Possibly because multicast in IPv6 is scoped and so it would be
difficult to know which scope to use for a given IPv4 multicast address.
I guess this is mainly an issue of making all the defaults for IP addresses configurable,
so the user has at least the option of implementing the workaround. It may be just a lot
of unnecessary and error prone work to try to have JGroups detect the particular case of
coexistence between IPv4 and IPv6 that it happens to be in.
JGroups diagnostics uses hard-coded IPv4 multicast address
-----------------------------------------------------------
Key: JGRP-978
URL: https://jira.jboss.org/jira/browse/JGRP-978
Project: JGroups
Issue Type: Bug
Reporter: Richard Achmatowicz
Assignee: Bela Ban
Priority: Minor
Fix For: 2.8
When running JGroups using IPv6 bind and multicast addresses, the following messages
appear on the console:
> 20:21:36,565 WARN [UDP] failed to join /224.0.75.75:7500 on vif0.0:
> java.net.SocketException: No such device
> 20:21:36,566 WARN [UDP] failed to join /224.0.75.75:7500 on peth0:
> java.net.SocketException: No such device
> 20:21:36,566 WARN [UDP] failed to join /224.0.75.75:7500 on xenbr0:
> java.net.SocketException: No such device
The multicast address 224.0.75.75 is used by the JGroups diagnostics handler (in TP.java)
to listen for incoming probe requests. Probe requests are issued from clients using
Probe.java to find out which JGroups members are using UDP in a given network.
These messages expose two issues:
(i) JGroups is trying to join a multicast group on certain Xen virtual interfaces (vif0,
peth0, xenbr0) and this is failing
(ii) JGroups is using a fixed IPv4 multicast address, despite the fact that IPv6
addresses are being used as bind_addresses and multicast addreses.
Something similar to the first issue was addressed in
https://jira.jboss.org/jira/browse/JGRP-167..
As for the second issue, shouldn't JGroups use default IP addresses which correspond
to the IP mode the JGroups instance has been started in (i.e. if JGroups instance bound to
IPv4 bind address, use IPv4 diagnostics multicast address; if JGroups bound to IPv6 global
address, use IPv6 global diagnostics multicast address, etc)
This may very likely cause problems if JGroups is run in an IPv6 only environment, where
IPv4 socket use is disallowed.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira