Skip to content

NAT Hole Punching #8262

@AgeManning

Description

@AgeManning

Description

The consensus layer network has a fairly significant percentage of nodes behind a NAT. I've not measured the exact percentage, but pulling a number out of the air, i'd suspect like > 40%.

We can notice an after effect through the sheer number of incoming connection requests for peers that have open ports. As NAT'd peers can only connect via outbound connections, they plague the properly configured peers with inbound connection attempts.

Having an automated system of NAT hole-punching would significantly improve the connectivity of the whole network and possible alleviate the number of nodes that have correctly configured ports

Current Work

Libp2p has auto-nat and its own hole-punching mechanism. The downside of this requires libp2p relay nodes in order to facilitate the hole punch and consensus layer nodes use discv5 for discovery which doesn't identify relay nodes from others. i.e we dont actively search or find relay nodes in order to connect to new peers. If we use libp2p relay nodes to discover new peers that we can hole punch via, then in effect we are adding a new discovery technique which would add complexity imo and make it harder to reason about eclipse attacks etc.

On the other hand, we discv5 which we are actively using to discover peers and there was been work to facilitate native hole punching to discover new nodes. These feels like a more intuitive approach, where we use our discovery mechanism to find and connect to new peers (even behind a NAT).

Discv5.2

The work towards this is discv5.2. Although this is still in draft form, we have an initial implementation here. This has been tested and seems to handle UDP nat hole punching.

We could get this implementation ready for production and have UDP hole punching for discovery.

Extended Work

Discv5.2 is not sufficient for us to have NAT whole punching on our consensus network. We would need to extend it further to allow us to establish hole punching on libp2p. If we can communicate with a peer over UDP, we no longer need a relay and we can establish a TCP or QUIC connection with that peer through a NAT if both peers desired.

I will not design this extension in this issue, as this is more an informative issue for others to comment on before doing significant work. The design of the extension is left for future work.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions