dualstack

[spongebob888]

I‘m considering adding dual stack support feature. And there are two ways:

The common way using [::]:443

Most implementation create a dual stack socket by binding to [::]:port and set socket option with set_ipv6_only(false). From user's
perspective, it looks like one socket. Using one accept function call, you can accept both ipv4 and ipv6 traffic.
The drawback is:

1. The ipv4 address is mapped into ipv6. For example 127.0.0.1 is mapped to ::ffff:127.0.0.1. This address can be used for another dual stack socket as destination but can't be used for a normal ipv4 socket. So conversion is needed for compatibility. function to_canonical can do this.
2. You can only bind to [::]:port for dualstack socket. You can't bind 127.0.0.1 and [::1] the same time.

Create two listeners

Another way I prefer is to create two listeners for ipv4 and ipv6. It doesn't has drawbacks above. And allow-lan:false logic can be simplified by binding to localhost [::1] and 127.0.0.1

The implementation is also easy. You just push two listeners.

[ibigbug]

Is the idea to support applications connecting to proxy via v6 addresses?

I'm not sure how much benefit that would add.

And if we do it,the question about option one is, if it's binding ::1 does it still work to connect via 127.1:port ?

Also when it comes to dual stack, we also need to consider cases of mixed v4/v6, such as apps connecting to v6 for v4 remotes and vice versa.

The current implementation is v4 proxy server for both v4 and v6 remotes.

[spongebob888]

Since socks and http supports ipv6 traffic even if it only listens on a v4 socket. So for such inbounds, the benefit is marginal.

However for tproxy and redir, ipv6 traffic can't be proxied if it only listens on a v4 port. So dualstack is a must.

If you bind to ::1, certainly you can't connect via 127.0.0.1:port. So you need two inbound/listener instance binding to to 127.0.0.1 and ::1.

[spongebob888]

I can give a draft PR on socks first, it may be more clear

[ibigbug]

yeah absolutely nice to have it for tproxy inbounds I think @VendettaReborn mentioned it here too #719

i think this might be a bit helpful for this too #862

[spongebob888]

I also has another question:
I noticed that allow-lan:false is implemented by explicitly checking peer_address. Why not binding to localhost like 127.0.0.1

[ibigbug]

it's more flexible to change it without restart the socket

[spongebob888]

That makes sense