RFC compliant address selection vs. home made getaddrinfo

[Alan Bateman]

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.

-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