feat(autonatv2): Implement autonat v2 #1
Conversation
…n if we already have a listener for outgoing connections.
|
IPv6 should be handled specially because the majority of nodes do not support IPv6. Event with 50% adoption and querying 3 nodes will have a 12.5% chance of an incorrect inference. As it stands adoption on the servers is closer to 10%. This is what I observe on my kubo node, which has happy eyeballs to prefer ipv6 dialing. To make matters worse, providing a service to the network which doesn't work for IPv6 will incentivize servers to not run IPv6. A similar problem happens with UDP in some enterprise networks, but udp blocking is far less prevalent than not having IPv6 connectivity. |
|
As I understand, this is an improvement we can ship for the server later right? At the moment, the algorithm for picking addresses and choosing servers is pretty simple, at least here in What is important in my eyes is that the protocol allows us to change this later. For example, an AutoNAT client could choose to only send probes for IPv6 addresses to AutoNAT servers that it is already connected to via IPv6. Or a server could only pick an IPv6 address from a list if it has at least one IPv6 connection. I'd advocate for shipping this as an improvement later. There are probably other optimisations that people want as they start using it but you have to ship a first version at some point. |
|
I understand both arguments here. Although the guiding principal was to ship a simple, but correct version. If I could get the error matching right, I wouldn't have a problem with that. It should catch the can't dial IPv4 because I'm only IPv6 case too. |
|
I still don't understand why this is such a problem. In my eyes, it is important that AutoNAT doesn't output false-positives, i.e. reports externally reachable when we are not. That is the problem with v1. False-negatives, i.e. not detecting external reachability when we in fact are is not that big of a deal. It doesn't make it incorrect in my eyes, just not (yet) as useful as it could be. Another thing is that IPv6 doesn't require NATing necessarily. You can configure your router to just directly assign an address from the block assigned by your ISP. That means the IPv6 address you read of the local interface is publicly routable and you don't need to discover it. Whilst there is still use for an AutoNAT protocol for IPv6, I think it primarily solves a problem with IPv4 and thus I wouldn't spend much time on it now to optimise for running into less false-negatives. |
Sure! I don't want to block this. Feel free to merge. We can add this improvement later.
This makes sense. We should implement this on the client too.
AutoNAT only provides us with firewall status(We can change the name from autoNAT). Wouldn't most firewalls block both IPv6 and IPv4 incoming connections? |
Hmm, I never saw it that way. To me, it was always about testing address "candidates" like observed external addresses where we weren't sure whether or not they are reachable. We always send all listen addresses in identify so if there is no NAT with IPv6, there aren't any additional addresses that I need to test. |
Co-authored-by: Thomas Eizinger <[email protected]>
Co-authored-by: Thomas Eizinger <[email protected]>
Closes: #4524 This is the implementation of the evolved AutoNAT protocol, named AutonatV2 as defined in the [spec](https://github.com/libp2p/specs/blob/03718ef0f2dea4a756a85ba716ee33f97e4a6d6c/autonat/autonat-v2.md). The stabilization PR for the spec can be found under libp2p/specs#538. The work on the Rust implementation can be found in the PR to my fork: umgefahren#1. The implementation has been smoke-tested with the Go implementation (PR: libp2p/go-libp2p#2469). The new protocol addresses shortcomings of the original AutoNAT protocol: - Since the server now always dials back over a newly allocated port, this made #4568 necessary; the client can be sure of the reachability state for other peers, even if the connection to the server was made through a hole punch. - The server can now test addresses different from the observed address (i.e., the connection to the server was made through a `p2p-circuit`). To mitigate against DDoS attacks, the client has to send more data to the server than the dial-back costs. Pull-Request: #5526.
Closes: libp2p#4524 This is the implementation of the evolved AutoNAT protocol, named AutonatV2 as defined in the [spec](https://github.com/libp2p/specs/blob/03718ef0f2dea4a756a85ba716ee33f97e4a6d6c/autonat/autonat-v2.md). The stabilization PR for the spec can be found under libp2p/specs#538. The work on the Rust implementation can be found in the PR to my fork: umgefahren#1. The implementation has been smoke-tested with the Go implementation (PR: libp2p/go-libp2p#2469). The new protocol addresses shortcomings of the original AutoNAT protocol: - Since the server now always dials back over a newly allocated port, this made libp2p#4568 necessary; the client can be sure of the reachability state for other peers, even if the connection to the server was made through a hole punch. - The server can now test addresses different from the observed address (i.e., the connection to the server was made through a `p2p-circuit`). To mitigate against DDoS attacks, the client has to send more data to the server than the dial-back costs. Pull-Request: libp2p#5526.
Description
This is a WIP implementation of AutoNATv2.
I would appreciate feedback by @mxinden and @thomaseizinger. You don't have to go into any specifics, I just wanted to check up if the direction is correct. A complete and formal PR will follow once everything is done.
I'm sorry it took me so long to give a sign of life. I sunk a lot of hours into doing it with request-response just to discover I need to do it without it. Additionally I couldn't work on it for the last week since I had to study for a midterm.
Notes & open questions
Change checklist