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

[improvement] Implement "IPv6 Unavaliable" Error Code #4

Open
shanoaice opened this issue Oct 8, 2023 · 2 comments
Open

[improvement] Implement "IPv6 Unavaliable" Error Code #4

shanoaice opened this issue Oct 8, 2023 · 2 comments

Comments

@shanoaice
Copy link

shanoaice commented Oct 8, 2023

This is an issue attempting to solve a real-world issue that I have encountered lately. The problem is described as follows:

  1. To enable the ECH feature of browsers, one have to enable the built-in browser DoH resolver. But this will cause proxy clients to unable to sniff and hijack DNS requests as usual.
  2. If TUN inbound is enabled and an IPv6 address is add to the TUN interface, even if the remote proxy server does not support IPv6, the browser will still attempt to send request to the resolved IPv6 address and will fail.
  3. Under existing protocols, there is no way for the server to tell its clients that either it does not support IPv6 or an IPv6 request fails, thus browser's Happy Eyeball fallback cannot be triggered (by proxy client returning an ICMP unreadable response on TUN), causing connection failure.

To address this issue, I propose that an error code representing "IPv6 connection failure" to be added, so that proxy clients can properly trigger Happy Eyeballs when TUN inbound is used.

edit: context: SagerNet/sing-box#932 (comment)

@dyhkwong
Copy link

dyhkwong commented May 2, 2024

SagerNet/sing-box#932 (comment) is to reveal its impracticability, not to motivate someone to implement it. Proxy protocols targeting the GFW, e.g. Shadowsocks 2022, are designed as 0-RTT to avoid detectable characteristic, so error code is not possible.

@shanoaice
Copy link
Author

SagerNet/sing-box#932 (comment) is to reveal its impracticability, not to motivate someone to implement it.

This comment is exactly what motivated me to make such proposal, and I have made discussions with nekohasekai and Ian Moore with this. ECH has its value in at least adding an extra layer of safety against Deep Packet Inspection technology, and if this is something that cannot be implemented it will be a great pity.

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

2 participants