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

autonat: provide different reachability states and callbacks for IPv6 and IPv4 #2466

Open
Tracked by #10000
Jorropo opened this issue Aug 9, 2023 · 2 comments
Open
Tracked by #10000
Labels
kind/enhancement A net-new feature or improvement to an existing feature status/blocked Unable to be worked further until needs are met

Comments

@Jorropo
Copy link
Contributor

Jorropo commented Aug 9, 2023

The default IPv6 setup on buisness and home ISP is to have a statefull NAT preventing non solicited inbound IPv6 packets.
However a good share of them also support upnp but only for ipv4.

This lead to missleading autonat results that tell us:

I'm reachable !!

Even tho you are only really reachable on IPv4. This is an issue because I'm trying to get Kubo working on IPv6 networks, because the sad reality is that right now things are quite broken if you do not have an ipv4 uplink.
Likely we are gonna have to split the current DHT in an IPv4 and IPv6 section.

@Jorropo
Copy link
Contributor Author

Jorropo commented Aug 9, 2023

For the implementation it does not sounds that bad, we would duplicate the statemachine and each statemachine would only gives our observed IPv4 or IPv6 as well as establish matching connections to other autonat peers.

@marten-seemann
Copy link
Contributor

This sounds like it would be solved by the new address pipeline (and AutoNAT v2, which @sukunrt is working on right now). This will allow us to determine the reachability status for each address individually, which would reveal the different treatment of IPv4 and IPv6 you describe.

@marten-seemann marten-seemann added status/blocked Unable to be worked further until needs are met kind/enhancement A net-new feature or improvement to an existing feature labels Dec 7, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/enhancement A net-new feature or improvement to an existing feature status/blocked Unable to be worked further until needs are met
Projects
None yet
Development

No branches or pull requests

3 participants
@marten-seemann @Jorropo and others