Re: [jgroups-dev] JGroups preference for IPv6

On 04/12/2010 02:47 AM, Bela Ban wrote:
> This won't work: even though you *could* have a dual stack, unless you
> set one of the java.net.preferXXX flags, the JVM picks an IPv6 stack by
> default !
>
> So a class D IPv4 address, e.g. 239.5.5.5, will fail the creation of the
> MulticastSocket in UDP (cannot bind to 239.5.5.5), and we're back to
> having promiscuous traffic.
>

Hmm. That maybe explains why this is suddenly showing up as a problem on 
Macs??? On a Mac you don't try to bind the MulticastSocket to the 
multicast address; you use new MulticastSocket(int port) and it's bound 
to IN_ADDR_ANY. So the IPv4 multicast addresses JBoss shipped with 
worked with JGroups 2.5.x. Now with the 2.10 upgrade the JGRP-1152 check 
causes a failure.

> However, what could be done to solve the problem of using IPv4 class D
> addresses within an IPv6 stack is to map the IPv4 multicast addresses to
> IPv6 multicast addresses by prepending an IPv6 /96 prefix, e.g.
>
> 239.5.5.5 --> FF0e::239.5.5.5, as outlined in [1]. The prefix <FF0e::>
> could be hard coded, for instance.
>
> I might want to issue a warning though because the transformation might
> not end up resulting in an IPv6 multicast address of the type a user
> wants... OTOH, this is already done for unicast addresses...
>
> WDYT ?
>
>
> [1]
> http://www.6net.org/publications/standards/draft-venaas-mboned-v4v6mcastgw-00.txt
>
> [2] http://www.faqs.org/rfcs/rfc2529.html
>
>
>
> Brian Stansberry wrote:
>> This is somewhat related to previous discussion at [1] and related
>> JGRP-1152 [2].
>>
>> Since we've upgraded JBoss AS trunk to JGroups 2.10.0.Alpha3, it will
>> no longer start on a machine that supports both IPv4 and IPv6. This is
>> because we don't specify java.net.preferIPv4Stack in our startup
>> scripts, so Util.getIpStackType() returns StackType.IPv6. But we
>> configure IPv4 multicast addresses by default so the JGRP-1152 check
>> fails the startup.
>>
>> Since we're specifying IPv4 addresses by default, perhaps our startup
>> scripts could set -Djava.net.preferIPv4Stack=true. Jason can comment
>> if he likes; it may be necessary although I don't really like it (yet
>> another config in an obscure location).
>>
>> I'm wondering if JGroups can handle this situation more flexibly. I've
>> attached an *untested* patch that shows what I was thinking:
>>
>> 1) Add a new StackType.Either which Util.getIpStackType() returns if
>> the OS supports both stack types and no java.net.preferXXX property is
>> set.
>>
>> 2) Configurator.setupProtocolStack() recognizes StackType.Either and
>> when it's analyzing the InetAddresses it's seeing, it uses the first
>> one it sees to switch to either StackType.IPv4 or StackType.IPv6. So
>> in this case the users choice of addresses controls the behavior.
>>
>> 3) Thereafter, the normal JGRP-1152 checks apply, so illegal
>> inconsistencies are caught and rejected.
>>
>> I checked for other uses of Util.getIpStackType() and tweaked the one
>> that needed it to deal with a return value of StackType.Either. I
>> haven't checked *all* uses of StackType though; wanted to get some
>> feedback first.
>


-- 
Brian Stansberry
Lead, AS Clustering
JBoss by Red Hat

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Javagroups-development mailing list