RFC compliant address selection vs. home made getaddrinfo

[Bernd Eckenfels]

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
-- 
http://bernd.eckenfels.net