Automatic Firewall/NAT Detection #271
Merged
+549
−260
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Symmetric NATs and IPv6 are currently a pain point in discovery. Discv5 has a mechanism to discover its external IP and port (
socket
from now on). We use a majority voting system based onPONG
responses.The problem is that full-cone NATs can be included in the IP address discovery. Furthermore, with ipv6, all connections are likely not NAT'd and the external IP discovery is going to return our IPv6 address.
Currently we are assuming that if our external address is discoverable, that we are contactable (as we get discovered when a correct port forward is established in ipv4). However this will generally not be the case for full-cone NATs and IPv6. In fact, if we default to dual-stack, all ipv6 nodes will update their ENR to their ipv6 address, rendering them non-contactable (as ipv6 is the default connection for ipv6-compatible nodes) if their firewall still prevents ipv6 traffic.
We therefore need a way to determine if we are contactable or not to avoid incorrectly advertising our ipv6 or ipv4 discovered addresses.
This PR proposes the following:
I have done some preliminary testing on this PR and it seems to function as I expect.
However with these added complexity more eyes are always helpful :)