Soni L. (Mar 23 2024 at 11:06): Soni L. (Mar 23 2024 at 11:06):hello o/ has anyone investigated using IPv6 transition technologies over WASI (and handle them in the libc/language implementation), instead of developing IPv4-specific WASI APIs?
Soni L. (Mar 25 2024 at 15:06):like why not remove this and everything related to it from wasi-socket https://github.com/WebAssembly/wasi-sockets/blob/main/wit/network.wit#L108
Chris Fallin (Mar 25 2024 at 15:53):@Soni L. I can't speak for the actual designers of wasi-sockets but I would imagine the reason here is probably that "compatible with the existing world" takes precedence over "innovate and choose the future-looking position" in this case. Also the required complexity in the runtime: a standard is less successful the more it forces an implementer to build in a ton of complexity just to meet the minimum bar (in this case: 464XLAT would require... a user-space networking stack I think? not super-reasonable)
Chris Fallin (Mar 25 2024 at 15:54):I'm personally sympathetic (playing with ipv6 personally since 2002! I even ran my home network ipv6-only for a week once) but... this isn't the place to do that innovation. wit-based WASI is innovating with sandboxing/security and capabilities, it doesn't also need to be "weird" in the way it does network addresses :-)
Soni L. (Mar 25 2024 at 16:52):it doesn't require an entire user-space networking stack, it's mostly just API call translation. we can point to https://website.peterjin.org/wiki/Universal_Relay and RFC 6535 as prior art, tho it would certainly require some tweaks before it could be done in wasi.
Soni L. (Mar 25 2024 at 16:53):we thought the whole point of WASI 0.2 and the component model was to innovate and choose the future-looking position? it's explicitly no longer coupled to POSIX, at least.
Chris Fallin (Mar 25 2024 at 18:19):@Soni L. I can offer that it would be good to try to avoid tacit assumptions and absolutisms -- innovation and forward-looking design doesn't have to mean taking stances that would create serious speedbumps and confusion with everyday adopters, and doesn't have to mean that every identifiable axis of design maximizes the innovation knob. It's not very helpful to question any pragmatic choice with "we thought the whole point was to innovate" -- deep, careful thought goes into these APIs. @Dan Gohman might be able to say more about IPv4 and design philosophy here?
Dave Bakker (badeend) (Mar 25 2024 at 18:36):instead of developing IPv4-specific WASI APIs?
Which API's are IPv4 specific?
Dave Bakker (badeend) (Mar 25 2024 at 18:37):And if those exist, why would that be a problem?
Soni L. (Mar 25 2024 at 18:40):ppl already don't bother to implement ipv6 as it is, because they think they don't/won't need it. removing the option to not implement ipv6 makes things easier.
Dave Bakker (badeend) (Mar 25 2024 at 19:01):As it stands today, wasi-sockets is already agnostic to IP versions. This can be observed by e.g. the absence of distinct IP_* and IPV6_* socket options. So, in that aspect, IPv6 support already comes along "for free".
However, regardless of what API WASI exposes, the first thing libc is going to do is translate it back into a POSIX interface. Every additional layer of abstraction we introduce is going to be an uphill battle from both ways; once for the host, and once for the guest.
In general, I think "the problem" with IPv6 is the real world, not so much how WASI exposes it.
Soni L. (Mar 25 2024 at 19:14):there is actually a lot of incentive for ipv6 in the real world nowadays, especially since aws started charging for ipv4
but for wasi, the best you can do is make it easy for the guest to use ipv6, and hard for the host to refuse ipv6
Dave Bakker (badeend) (Mar 25 2024 at 19:21):for wasi, the best you can do is make it easy for the guest to use ipv6
Agree :)
Dan Gohman (Mar 25 2024 at 20:52):Dave Bakker (badeend) said:
for wasi, the best you can do is make it easy for the guest to use ipv6
Agree :)
Agree too :)
Soni L. (Mar 25 2024 at 21:54):uh. currently the guest has to support ipv4 and ipv6 separately.
Dan Gohman (Mar 26 2024 at 00:09):WASI isn't an advantageous place to push back on guest sockets code, because a lot of guest sockets code will be written to use source languages' standard library APIs rather than wasi-sockets directly. If WASI did anything that made v4 harder to use, we'd just be creating barriers to languages supporting WASI, not motivating applications to switch from v4 to v6.
Soni L. (Mar 26 2024 at 00:15):yes, most standard libraries would just patch it over, and that's not necessarily a bad thing. we are still trying to push for ipv6-only OSes/kernels, and if you already have the ipv6-only OS support in your stdlib due to wasi, porting to these becomes trivial. (assuming you're not using the OS libc for some reason.)
Last updated: Oct 23 2024 at 20:03 UTC