<div dir="ltr"><div>Hi Alan,</div><div><br></div><div>My question basically came up when I was investigating a network issue against a dual-stack web site. In my case, there was a routing issue (somewhere) that affected only IPv4 (packet-loss -> dup-ack), but IPv6 worked fine. So tools like curl/wget, which used the system settings, just worked without any issue, but the "Java variant" always ran into that issue. It took me a bit to figure out that IPv4 is by default preferred in Java, despite the system settings (getinetaddr result). Even worse for me: the tool I used effectively prevented setting the system property 'java.net.preferIPv6Addresses=true'.</div><div><div>The crux of such network issues is that those are hard to narrow down, especially when for example CDNs are in the mix, besides that it requires networking knowledge.</div><br></div><div>The question that came up was, whether there's a way to prevent such issues from bubbling up to users.</div><br><div>Modern web browsers and curl _appear_ to prefer IPv6 over IPv4 by default. Those use "Happy Eyeballs" (RFC 8305/6555), which is likely a sign that using IPv6 is (sadly, after ~30 years, sigh) still causing issues for users [1]. Such HTTP applications probably also use other mechanisms as well [2]. "Happy Eyeballs" is fine for browsers and tools like 'curl', it sits on top of the lower level InetAddress.get*()/getinetaddr, using their own hostname resolution and leveraging recent "connection quality" (persisted history).</div><div></div><div><br></div><div>Changing the default from 'PV4 | IPV6 | IPV4_FIRST' to 'IPV4 | IPV6' in 'java.net.InetAddress' is, no doubt, a change to the observed behavior. There is certainly a risk that existing applications break with this change, when suddenly connections are made via IPv6 instead of IPv4. So a definitive "no go" for released Java versions.</div><div></div><div>OTOH there's the observed difference between the ordering of the results of InetAddress.get*() and getinetaddr. I figured that difference a bit surprising (I never cared about it in the last years TBH, because everything just worked).</div><br><div><div>Most code, not just Java, probably just takes the first element returned by InetAddress.get*()/getinetaddr, which is IMHO not a bad approach, because there's no, say, "quality metadata" about the individual entries.</div><div><br></div>I am by no means an expert on the "state of practical use and usability of IPv6", so my observation is very subjective. Things are, I am sure, different from ISP to ISP and within organizations' networks and not to forget interactions with "all the other things".</div><div><br></div><div>Options I currently see are (no particular order here):</div><div>* "Just"(TM) change the default (tempting, but devils inside).</div><div><div>* Add new InetAddress.get*() functions that allows applications to pass a lookup preference to use. That would have to 
work in all cases: v4-only, v6-only, dual-stack).</div>* Introduction of a general, inet specific name resolution API (a la Netty?) with more options.</div><div></div><div>* Have a "Happy Eyeballs" implementation, raising the questions of where and how to add it. Naively thinking: something like 'SocketChannel.connect(List<InetSocketAddress> addresses)' and/or 'Socket.connect(List<InetSocketAddress> addresses)'</div><div><br></div><div>While it is certainly possible to have a "proper" solution by implementing custom code or leveraging existing libraries, developers need to be aware of the potential IPv4/v6 issues when writing code. Having something in the core Java APIs and/or implementation could help avoiding networking issues in the broader ecosystem.</div><br><div>WDYT?<br><br></div><div>Robert</div><div><br></div><div><br></div><div>[1] RFC 8305 (<a href="https://datatracker.ietf.org/doc/html/rfc8305" target="_blank">https://datatracker.ietf.org/doc/html/rfc8305</a>) says in the abstract "Since specific addresses or address families (IPv4 or IPv6) may be blocked, broken, or sub-optimal on a network..."</div><div>[2] RFC 9460 (<a href="https://datatracker.ietf.org/doc/html/rfc9460" target="_blank">https://datatracker.ietf.org/doc/html/rfc9460</a>)</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Feb 6, 2026 at 11:45 AM Alan Bateman <<a href="mailto:alan.bateman@oracle.com" target="_blank">alan.bateman@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 06/02/2026 10:08, Robert Stupp wrote:<br>
> Hi all,<br>
><br>
> I wanted to test for the appetite to change the current default <br>
> behavior of the IP address lookup policy on dual-stack (IPv4+IPv6) <br>
> systems.<br>
><br>
> The default evaluated in InetAddress.initializePlatformLookupPolicy() <br>
> yields 'IPV4_FIRST' to return IPv4 addresses before IPv6 addresses <br>
> unless 'java.net.preferIPv6Addresses' is set to 'true'. I wonder <br>
> whether this could be changed to the system default, relying on what <br>
> 'getaddrinfo' returns?<br>
><br>
> This would make Java compliant with RFC 6724, which (strongly) <br>
> recommends to yield IPv6 addresses first.<br>
><br>
> Naively speaking, it can be confusing if something like 'curl' or <br>
> 'wget' connect via IPv6, but any Java application connects via IPv4.<br>
><br>
> Although it's a tiny code change, it would be a "big" or "surprising" <br>
> behavior change. Therefore I think, if there's appetite for such a <br>
> change, it would need to go into one of the next major releases.<br>
><br>
> WDYT?<br>
><br>
<br>
Moving to net-dev as that is where the networking APIs are maintained.<br>
<br>
As an initial comment, changing the JDK to prefer IPv6 addresses by <br>
default would be a significant and observable change. TBH, I don't see <br>
this being changed without a wide survey of configurations and a JEP <br>
that lays out the case and implications of the change.<br>
<br>
Is your motive for asking solely because curl/wget tools prefer IPv6? <br>
I'm wondering if there is more to the question, maybe HTTP protocol <br>
handler or client only using the first address?<br>
<br>
-Alan<br>
<br>
<br>
<br>
</blockquote></div>