JDK-5083013 : connecting to IPv4 server on dual stack host fails
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.net
  • Affected Version: 5.0u1
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: solaris_2.6
  • CPU: x86
  • Submitted: 2004-08-05
  • Updated: 2012-10-09
  • Resolved: 2004-08-17
Related Reports
Duplicate :  
Assume an IPv4 TCP server is running on a dual stack host (i.e., one that supports both IPv4 and IPv6).  Now, on a machine that is also dual stack, doing

  new Socket(InetAddress.getByName(host), port)

where host is a machine name (not a literal IPv4 or IPv6 address), results in a ConnectExceptin ("Connection refused").  The reason is that InetAddress.getByName(host) seems to prefer an IPv6 address over an IPv4 address for the given host.

A solution would be to have another API that defers name resolution until the actual connect(2) call is made, then trying all addresses returned by getaddrinfo(3) until one succeeds (see Stevens, Fenner, Rudoff: "Unix Network Programming, Volume 1: The Sockets Networking API, 3rd Edition", p. 359).  (I tried

  new Socket().connect(InetSocketAddress.createUnresolved(host, port))

hoping that this might do the delayed resolution, but instead it results in an UnknownHostException.)

The scenario where I encountered this problem is as follows:  StarOffice/OpenOffice is running as a server (it only supports IPv4) and you try to connect a Java client on the same machine via OpenOffice's remote UNO protocol, and the Java client uses the machine name "localhost" for the connection.  On the given machine, "localhost" can resolve to both IPv6 ::1 and IPv4 (and Java chooses the IPv6 address).  A workaround is to explicitly use "" instead of "localhost" in the client.  (See <http://www.openoffice.org/issues/show_bug.cgi?id=32281>.)

EVALUATION ###@###.### 2004-08-06 Should take a close look in Mustang. -- The current API offers the possibility to get all the addresses for a host, so it's possible to check and pick up the one with the proper family. It could be useful to have a more specific API though. Will examine for Mustang. ###@###.### 2004-08-11 ---- InetAddress.getAllByName was what I was missing (I had only been aware of InetAddress.getByName), so, yes, I can implement the corresponding loop "by hand." (Still would be great to have this available directly in the API though.) ###@###.### 2004-08-12 Actually, the real issue here is that by default Java is supposed to return IPv4 addresses ahead of IPv6 addresses for compatibility reasons, and this behavior has been broken for some time unfortunately. I'm going to close this as a dup of 5087907, because that bug describes the underlying problem and will be fixed ASAP after tiger. ###@###.### 2004-08-17