IPSocket#addr returning "0:0:0:0:0:0:0:0" as bound ip address and not "::" when preferring IPv6

[HoneyryderChuck]

Environment Information

Provide at least:

• JRuby version: jruby 9.4.6.0 (3.1.4) 2024-02-20 576fab2 OpenJDK 64-Bit Server VM 25.402-b06 on 1.8.0_402-b06 +jit [x86_64-linux]
• Operating system and platform: docker image (jruby:9.4)

Expected Behavior

The httpx jruby suite started failing recently, when a certain proxy test would try to bind to the "0:0:0:0:0:0:0:0" address. This address was collected from here, where I confirmed that, after initiating the server with TCPServer.new(0), the call to .addr returns "0:0:0:0:0:0:0:0" in the 3rd and 4th array elements.

This seems to only happen on gitlab CI though, as locally it consistently returns "0:0:0:0"

[headius]

I suspect this is due to differences in that environment relaing to IPv6 and the Java/JDK being run.

You say that locally it's "0:0:0:0" which seems a strange address to me, given that the catch-all address for IPv6 should be "0:0:0:0:0:0:0:0" as you say it does on Gitlab CI. Do you mean "0.0.0.0"?

There are some JVM properties you can set (with -J-D<property> flag to JRuby or JAVA_OPTS=-D<property> env var) that will change how JDK decides to use IPv6 vs IPv4. Perhaps you can give some of these a try and see if it helps?

https://docs.oracle.com/javase/8/docs/technotes/guides/net/ipv6_guide/#ipv6-related

[HoneyryderChuck]

I suspect this is due to differences in that environment relaing to IPv6 and the Java/JDK being run.

I managed to reproduce this locally. This just seems to be different behaviour from jruby, i.e. returning "0:0:0:0:0:0:0:0" instead of "::" for loopback addresses:

require "socket"
server = TCPServer.new(0)
puts server.addr.inspect
#=> jruby: ["AF_INET6", 52341, "0:0:0:0:0:0:0:0", "0:0:0:0:0:0:0:0"]
#=> ruby: ["AF_INET6", 52343, "::", "::"]

bottom line, this manifested in CI because the gitlab docker executor seems to have IPv6 enabled recently for loopback, which triggered this error on the jruby job.

Either that, or it has been enabled all along, and this is therefore a regression.

[HoneyryderChuck]

@headius shall the label be readded again based on the feedback above?

[enebo]

Kind of mind-blowing with how many socket specs exist that this is not covered at all. On my machine MRI is emitting ipv4 with 0.0.0.0. JRuby is not but I think that is just as @headius said. If we do:

jruby -J-Djava.net.preferIPv4Stack=true -v -rsocket -e 'p TCPServer.new(0).addr.inspect'
jruby 9.4.8.0-SNAPSHOT (3.1.4) 2024-05-21 d7358ea8c5 OpenJDK 64-Bit Server VM 25.402-b06 on 1.8.0_402-b06 +jit [x86_64-linux]
"[\"AF_INET\", 40749, \"0.0.0.0\", \"0.0.0.0\"]"

@HoneyryderChuck your workaround for the moment would be to set that property in CI so you get ipv4.

We I guess need to add a spec and change how we emit ipv6 here. Every time I look this stuff up it is out of my mind about a day later.

[enebo]

I think in just a minute or two of perusing that for all intents and purposes "0:0:0:0:0:0:0:0" means "::". So you could argue this is a valid unspecified address in either form and should still function by anything receiving it. That said, we should just output the same thing vs making some other projects deal with accepting both.

[HoneyryderChuck]

for all intents and purposes "0:0:0:0:0:0:0:0" means "::".

Indeed, I should have been more specific about that. Thx for the patch 🙏

[enebo]

An outstanding item to this issue and likely others is we need to make some CI job which runs socket specs in both ipV4 and ipV6. It will need to get addressed later.