Binding to IPv4 and IPv6 works differently than in the examples

[raek]

After some fiddling around I found that:

• binding to "0.0.0.0" accepts IPv4 connections (as expected
• binding to "" gives an error (it says that the IPv6 address is already in use)
• binding to "::" accepts both IPv4 and IPv6 connections (even more surprisingly)

When binding to "::", the IPv4 addresses are displayed as ::ffff:139.162.187.208 in the log.

Maybe we should just update the documentation to reflect this. Or is there something that should be changed in the code?

[raek]

I'm using Jetforce v0.9.1 and I'm happy to aid in debugging or digging into the code.

[makew0rld]

binding to "::" accepts both IPv4 and IPv6 connections (even more surprisingly)

This is pretty standard. This is usual behaviour for Linux in my experience, and is probably standardized somewhere. I doubt this is related to Jetforce.

[michael-lazar]

Here's what jetforce/twisted is doing under the hood with the sockets:

• host=0.0.0.0
  • Bind to 0.0.0.0 with AF_INET
• host=::
  • Bind to :: with AF_INET6
• host=""
  • Bind to 0.0.0.0 with AF_INET
  • Bind to :: with AF_INET6

This ticket describes pretty much the exact behavior that we're seeing and why it's complicated: https://github.com/twisted/twisted/pull/198

Basically it's operating system dependent. For me it works, but I'm developing on macOS and my production server only uses IPv4. I could see a couple of fixes here:

• Update the code to check if dualstack IPv6 is enabled, and if so, only bind to ::/AF_INET6 if host="" (https://docs.python.org/3/library/socket.html#socket.has_dualstack_ipv6)
• Update the jetforce documentation to point out if dualstack IPv6 is enabled on your operating system, binding to :: will also enable IPv4.

I'm open to a PR!

[nobrowser]

binding to "::" accepts both IPv4 and IPv6 connections (even more surprisingly)

This is pretty standard. This is usual behaviour for Linux in my experience, and is probably standardized somewhere. I doubt this is related to Jetforce.

I think this is controlled by the sysctl flag net.ipv6.bindv6only . Myself, I prefer to set it to 1 , in order to avoid this confusing behavior.