On 06/13/2013 10:37 AM, Alan Bateman wrote:
I agree this should be be re-examined. The original rational for the
re-ordering (and the java.net.preferIPv6Addresses property) was for
backward compatibility reasons. Even today, it is still common to
encounter applications or environments that assume IPv4 addresses. As
you note, you can configure the JDK to prefer IPv4 or IPv6 addresses but
there isn't a way to configure the default provider to not re-order.
It seems obvious, and non-controversial, to add a way to configure the
default provider to preserve the order it is given from the system.
Having this configuration on by default would be a different matter.
I'll file a bug against this to keep track of it, but hopefully we can
get the first part of this moving quite swiftly.
-Chris.
-Alan.
On 12/06/2013 22:05, Bernd Eckenfels wrote:
Hello,
I have given a (german) talk about Java and IPv6 at the largest
european IPv6 Congress last week in Frankfurt. As part of my
preparation for that talk was looking at some of the details of Java
IPv6 networking. I have some points to discuss because of that:
RFC 3484 defines the default address selection for IPv6. It is
basically defining a number of rules for ordering the result from
getaddrinfo() to observe standard behaviour (prefer ipv6 if supported,
allow administrative redefinition). Linux and Windows have elaborate
mechanisms to influence getaddrinfo (net sh int ipv6 prefixpolicy on
Windows and /etc/gai.conf on Linux).
Unfortunatelly Java is re-ordering that answer (in
Java_java_net_Inet6AddressImpl_lookupAllHostAddr based on preverIPv6).
It would be good if instead of preferIPV6=true/false there would be a
preferIPV6=true/false/donottouch, with donottouch beening the RFC 3484
compliant default.
I am talking about
http://hg.openjdk.java.net/jdk7/jdk7/jdk/file/272483f6650b/src/solaris/native/java/net/Inet6AddressImpl.c
Line 140ff
According to RFC 3493 you should instead use the AI_ADDRCONFIG to
automatically be sensitive to hosts stack configuration.
There is also another problem, the code is using the AI_CANONNAME
hint. This hint is by definition returning the canonical name in the
FIRST result. However the res[0].ai_canonname is not queried in that
code. So you can skip it. Or even better use the result, because the
InetAddress#getCanonicalHostName() is not very helpful. (For example
using getaddrinfo on "mail.google.com" will return
"googlemail.l.google.com" because it is a CNAME but Java returns
lga15s34-in-f21.1e100.net as it is the PTR for 173.194.43.21.
If you think it is not a good idea to fix this, I would vote for an
alternate name service provider which can be selected if rfc compliant
behavior is needed.
Gruss
Bernd
