Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Emulate dualstack sockets in userspace #1

Open
badeend opened this issue Mar 1, 2022 · 6 comments
Open

Emulate dualstack sockets in userspace #1

badeend opened this issue Mar 1, 2022 · 6 comments

Comments

@badeend
Copy link
Collaborator

badeend commented Mar 1, 2022

Dualstack support per platform according to the internet: (Not verified)

  • OpenBSD: Not supported.
  • FreeBSD: Not supported by default, but support can be manually toggled with a system-wide config change.
  • Windows: Supported. Disabled by default. Can be enabled on a per-socket basis.
  • Linux: Supported. Generally enabled by default, but some distros disable it by default.
  • POSIX & RFC3493: Specifies IPv6 sockets should be dualstack by default.

On the *BSD's: Can dualstack sockets be emulated efficiently and transparently in userspace by creating two sockets?

@tschneidereit
Copy link
Member

@badeend in your assessment, do you think this needs to be part of an MVP? Given that not all OSs support this, maybe we can punt on it and let the emulation happen entirely in userspace, even above libc?

@sunfishcode
Copy link
Member

I suggest saying it's "nondeterministic" whether dual-stack is enabled by default or not. This effectively represents the reality most portable socket code today faces, where dual-stack support may or may not be enabled in ways that are outside the application's control or visibility.

Beyond that, it'd be nice (but not necessarily critical for an MVP) to have a way to set IPV6_V6ONLY.

@badeend
Copy link
Collaborator Author

badeend commented Apr 6, 2022

@tschneidereit You're correct in that it doesn't need to be part of the MVP. It currently isn't.

@sunfishcode That's certainly the most pragmatic option. Let me start by saying that I too am on the fence on this one.

The things that made me swing slightly towards IPv6-only by default versus just choosing the underlying platform's default:

  • In the latter case you'd also need a way to query IPV6_V6ONLY on a socket.
  • It would open the WASI API up to the idiosyncrasies of the underlying platforms. Unlike for example case sensitivity of the file system, this can be abstracted away.
  • Ideologically, dualstack sockets are just a compatibility hack. I think it's reasonable to say hacks should be opt-in, rather than opt-out when possible. As mentioned in the explainer, this opt-in feature can be added post-MVP or sooner if you'd prefer.
  • Either way, the interface keeps its promise. You ask for an IPv6 socket; you get an IPv6 socket.

@sunfishcode
Copy link
Member

That also sounds reasonable to me.

@badeend
Copy link
Collaborator Author

badeend commented Aug 21, 2022

In #13 I've added the option to get and set the ipv6-only option. In the documentation of the method I've clarified that dual-stack support is not required from the host.

@rwally1986
Copy link

The underlying commercial operating systems use "prefer IPv6, fail-over to IPv4 by default". The current security best practices with many security teams is "prefer IPv4, fail-over to IPv4 by default". So how does this impact existing software?

badeend referenced this issue in badeend/wasi-sockets Feb 25, 2023
…off of wit-bindgen - previous ones fail (#1)

Signed-off-by: danbugs <[email protected]>

Signed-off-by: danbugs <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants
@tschneidereit @badeend @sunfishcode @rwally1986 and others