RFC compliant address selection vs. home made getaddrinfo

[Chris Hegarty]

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
>