JDK-6458027 : Disabling IPv6 on a specific network interface causes problems
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.net
  • Affected Version: 6,7,8
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_vista
  • CPU: generic,x86
  • Submitted: 2006-08-08
  • Updated: 2019-12-20
  • Resolved: 2013-09-16
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7 JDK 8
7u76Fixed 8 b108Fixed
Related Reports
Duplicate :  
JDK-6658085 - MulticastSocket.setNetworkInterface() doesn't work as expected on vista
Duplicate :  
JDK-8062249 - java.net.MulticastSocket.setInterface throws SocketException
Duplicate :  
JDK-8065575 - MulticastSocket Exception on non-default ethernet port/ new to 7.71
Relates :  
JDK-8065575 - MulticastSocket Exception on non-default ethernet port/ new to 7.71
Relates :  
JDK-8236441 - Bound MulticastSocket fails when setting outbound interface on Windows
Relates :  
JDK-6404473 - VISTA: MulticastSocket.setInterface fails to set Interface (ipv4)
Description
On windows vista IPv6 is enabled out of the box, and infact you cannot completely disable it. You can however disable it on a per interface basis. If you do this then you may encounter the following problems:

1) Incorrect NetworkInterface index.
   Retrieve the NetworkInterface instance for the interface that has IPv6 disabled.
   The index is not directly exposed by the API, but can be retrieved from 
   toString(). The index is however critical as it is used internally by
   NetworkInterface to help identify the particular interface to perform an 
   action on, e.g. isLoopback, ipUp. These method may not work correctly in 
   this case.

2) MulticastSocket.get/setInterface & get/setNetworkInterface
   These methods may throw a SocketException or return an empty InetAddress
   (0.0.0.0) or a NetworkInterface instance with no name, no addrs, and an index 
   of -1.
Comments
Nightly status is GREEN. So, SQE is ok to take the fix into PSU15_01.
12-11-2014
executing the test with the -Djava.net.preferIPv4Stack=true reveals broken behaviour -- looking into this also. Looking at this further, the isUp() state under IPV4 is different to that under IPv6. In the former the isUp() returns true on a nearly all interfaces. The majority of these don't have an IP address binding, and this causes an exception to be thrown in the MulticastSocket.setNetworkInterface(). So, it is fundamentally an issue with the sample test. It needs to be IPv4 aware and to test that the NetworkInterface to be set has an IP address binding, and if not then don't invoke setNetworkInterface. When in IPV4 mode, an IP address is required in order to invoke the setsockopt. When this is not the case, getInetAddrFromIf will throw an exception. The way to handle this scenario is for the invoking application to test that they are in IPv4 mode and to then ensure that the NetworkInterface under consideration has an IP address bound and then to call the MulticastSocket.setNetworkInterface() method. We won't pursue this any further.
12-09-2013
As part of the MulticastSocket.getNetworkInterface processing flow, the current code in getMulticastInterface call the getsockopt and then tests the index > 0, the else part is to return a NetworkInterface,with null data, However, if we take of the semantics for an interface index == 0 http://msdn.microsoft.com/en-us/library/windows/desktop/aa366058%28v=vs.85%29.aspx Ipv6IfIndex Type: DWORD *** The interface index for the IPv6 IP address. This member is zero if IPv6 is not available on the interface. *** Then if the getsockopt returned index == 0, is interpreted as meaning IPv6 is not enabled for the set interface, for which we then retrieve the IPV4 information, then the correct NetworkInterface will be returned. This raises some questions on the semantics of the MulticastSocket setNetworkInterface and getNetworkIntreface, but also on the NetworkInterface abstraction and its encapsulation of some of the extended details available on windows. In any case I think we have the basis for a solution to the current issue. some code refactoring and tests now required prior to webrev.
10-09-2013
the MulticastSocket.setNetworkInterface part of the problem can be solved by adding an additional network interface specific test to determine that the interface being set is IPV6 enabled. The current test is at the OS or platform level. The logic for MulticastSocket.getNetworkInterface will determine that IPV6 is enabled, and will perform a getsockopt call. However, when the IPv6 was not enabled for the setNetworkInterface, this getsockopt becomes a redundant call, and will return the default IPv6 interface for sending multicast When getting this option, the optval returns the current default interface index for sending multicast IPv6 traffic in host byte order. c.f. http://msdn.microsoft.com/en-us/library/windows/desktop/ms738574%28v=vs.85%29.aspx However, this returns an index of -1, which in trun results in a new NetworkInterface object being create, with null data. In this scenario, the getsockopt for IPPROTO_IPV6, IPV6_MULTICAST_IF is not what is required, but rather the IPPROTO_IP, IP_MULTICAST_IF. As such, either some help is required when the setNetworkInterface is invoked to retain the index for the NetworkInterface that has been set, and then to use this index in retrieving the associated NetworkInterface OR the to treat the case where the returned index from getsockopt is not > 0 as being one that we try to retrieve the IPv4 NetworkInterface instead. we'll try the latter, as it will not result in any amendment to the Java NetworkInterface class.
09-09-2013
deep diving as they say into this part of the problem is that an NetworkInterface is being set on the MulticastSocket. Various checks indicate that IPV6 is supported, but this is at the platform level or at OS level, and may not be at the adapter level. The setMulicastInterface function when processing the IPV6 condition expects to set both an IPv6 interface and an IPv4 interface. As indicated above the IPv6 may not be available for that particular adapter, so the code needs to check first that the interface currently has IPv6 available. we'll see how we go with this.
06-09-2013
EVALUATION This is not Vista specific issue. The Network Connection Properties in XP SP2 with IPv6 installed allows the same configuration, disabling IPv6 on an interface basis. The 2 jck tests will fail on XP with this network configuration. This is not a regression or change in behavior between XP and Vista.
14-08-2006
WORK AROUND 1) Enable IPv6 on the interface. or 2) Set -Djava.net.preferIPv4Stack=true property
11-08-2006
EVALUATION There is an assumption in the windows multicasting native code that if IPv6 is available on the machine then it is enabled on all interfaces.
11-08-2006