JDK-8231258 : (dc) DatagramChannel::connect change the local address type to IPv6 (macOS)
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.nio
  • Affected Version: 7u4
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • OS: os_x
  • Submitted: 2019-09-19
  • Updated: 2019-09-25
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.
Other
tbdUnresolved
Related Reports
Relates :  
JDK-8231261 - (dc) Write a test to check local and remote addresses after calling DatagramChannel::connect and DatagramChannel::disconnect
Relates :  
JDK-8231259 - (dc) DatagramChannel::disconnect re-binds socket to the wildcard address (macOS)
Description
If a DatagramChannel is bound to an IPv4 address, then connected to an IPv6 address, DatagramChannel::getLocalAddress() returns an IPv4-compatible IPv6 address.

java.lang.AssertionError: local address after connect should be /127.0.0.1:55179 found /0:0:0:0:0:0:7f00:1:55179
Comments
One thing that we should probably explore is having connect reject attempts to connect to an address that is a different family to the local address, e.g. if the socket has been bound to an IPv4 address then it could reject attempts to connect to an IPv6 address.
24-09-2019
I've edited the description to more clearly explain the issue. In summary, if an IPv6 socket is bound to an IPv4 local address and connected to a IPv6 address then getsockname(2) returns a socket address with an IPv4-compatible IPv6 address rather than an IPv4-mapped IPv6 address.
24-09-2019
The test shown in JDK-8231261 can be used to reproduce - and verify - the issue.
19-09-2019