P2P Сonnection on Yggdrasil network

[mnqw95]

Sorry again for using translate.google.. It is possible to implement a direct (p2p) connection of users through the yggdrasil network. Will work just as well as BitTorrent, Syncthing, TeamViewer, Skype ... Or like an almost analogue of our Tailscale network

This method will work with most types of NAT (Full Cone, Restricted Cone, Port Restricted Cone), the only exception is Symmetric NAT, thanks that there are not many of them left (and the providers who still use it - let them burn in hell) This method will be able to work with all tcp, udp, quic protocols

Realization: Change the logic of connecting to peers, make the connection from one port for example (127.0.0.1:9001) port forwarding on the UPnP and NAT-PMP router. Each time peers connect, they share a separate external IP: the PORT that the provider issued, we remember it For example, let's take device A wants to connect to B. The scheme will be as follows: А➝ (yggdrasil network) ➝В = Sending information packet (containing the issued external IP: PORT and the protocol used to choose from (tcp, udp, quic)) B➝ (global Internet) ➝A = (B) the device sends packets to the external IP: PORT of device (A) for hole punching, route matching from the NAT provider (B), NAT (A) will most likely drop these packets. B➝ (yggdrasil network) ➝A = Sending information packet (containing the issued external IP: PORT and the protocol used to choose from (tcp, udp, quic)) А➝ (global Internet) ➝В = (A) device sends packets to external IP: device PORT (B) At this stage, p2p connection is being established. in most cases

If device A cannot establish a direct connection to device B (Symmetric NAT for example) then A➝ (yggdrasil network) ➝B = Connect as it is now.

Benefit: 1.1 Best packet routing you can implement))

1. Fast connection, speed, minimum ping.
2. Ability to use yggdrasil network for games, video - sip - telephony, remote desktops. other p2p applications and developments.
3. Reducing the load on the yggdrasil network and peers, in order to become public peers, you do not need to use a wide channel of 1 Gb / s, the entry threshold for a public peer is minimal, even 10 Mb / s.
4. The network will grow faster (new users) due to extensive use cases with the advent of p2p
5. You can distribute the ability to connect to public peers by internal ygg-ipv6 addresses

[vikulin]

@mnqw95 , what about hole punching traffic encryption? What benefits you are going to archive comparing to simple schema with hole punching and external server which does not requite Yggdrasil infrastructure at all?

[mnqw95]

@vikulin Use the same encryption as now (using the public key), which is also not entirely secure, and I hope that when the session is opened, your own will be generated, thereby increasing securit

If you know a ready-made VPN solution for server and client that can hole punching p2p between multiple connected devices without traffic to the server itself, please tell me ..

[Saiv46]

@mnqw95 There's no need to do that.

Yggdrasil already has peer-to-peer with end-to-end encryption - you only need to establish a connection using IPv6 (or public key directly, which is more secure).

[mnqw95]

@ Saiv46 Of course there is and I like it. It can be used for any actions that do not require high speed and responsiveness. Or use it as a backup communication channel. But Yggdrasil today is not able to become a full-fledged replacement for the normal Internet, if, in addition to the existing network, the real and not the p2p interpretation are not implemented.

[neilalexander]

So this feels like it overlaps somewhat with DHT peer exchange in #780 and ultimately we don't want to do that because it is changing the scope of the project entirely. Our goal is to find efficient paths using available peerings, not by adding more peerings automatically.

Right now, a node that has an outbound peering can still accept incoming Yggdrasil connections, so in that regard the entire network is effectively full-mesh.

[mnqw95]

@Neilalexander Not at all, it uses a (temporary) interaction model for example (A) visits a site (resource) (B). after which the connection can be broken or restored if necessary.

I also consider it inappropriate to use a permanent connection to many peers, at least until a list of coordinates is stored in the DHT network, as now, connecting to different peers, we actually have different coordinates, and initially knowing everything, you can choose the closest one to send packages by the best route

The project is experimental and there are many places for improvement, and I hope in the future this will be the best implementation of the decentralized Internet ever created))

[Saiv46]

@mnqw95 Any new ideas how to achieve that? Try to make a PR for that (or close this issue, there's already a multicast peer discovery feature).

[oficsu]

Yggdrasil already has peer-to-peer with end-to-end encryption - you only need to establish a connection using IPv6 (or public key directly, which is more secure).

@Saiv46, currently, Syncthing allows two peers to discover each other with UPnP (and STUN-like public server) and talk directly even if they are both behind NAT. This improves transfer speed between peers and makes the network less dependent on community relay servers, so improves network stability. This is the real p2p in my opinion. But I don't see in any documentation if Yggdrasil can really achieve the same

Am I right that in the same situation, all the traffic of two Yggdrasil's peers won't be transferred "directly" (via regular Internet), but rather over public nodes? Am I missing something?

[majestrate]

Yggdrasil already has peer-to-peer with end-to-end encryption - you only need to establish a connection using IPv6 (or public key directly, which is more secure).

@Saiv46, currently, Syncthing allows two peers to discover each other with UPnP (and STUN-like public server) and talk directly even if they are both behind NAT. This improves transfer speed between peers and makes the network less dependent on community relay servers, so improves network stability. This is the real p2p in my opinion. But I don't see in any documentation if Yggdrasil can really achieve the same

Am I right that in the same situation, all the traffic of two Yggdrasil's peers won't be transferred "directly" (via regular Internet), but rather over public nodes? Am I missing something?

if you have peers on your local network and all have multicast peer discovery enabled the peers with connect to each other and traffic will not use public peers.

yggdrasil is a routing protocol for global scope unicast ipv6. "real" or "not real" p2p is a perspective that does not make much sense here so i am unsure what is being asked.

[oficsu]

if you have peers on your local network and all have multicast peer discovery enabled the peers with connect to each other and traffic will not use public peers.

In my opinion, with "real" p2p you can do the same, but not restricted only to "local network". As mentioned above, Syncthing uses NAT traversal tricks to allow two peers to know each other's global real IP and port. Then, using "real" IP/port, instead of routing traffic over Yggdrasil network (that mostly relies on the regular Internet routing), it's possible to route traffic over the underlying Internet directly. The main benefits are in the first message:

• Fast connection, speed, minimum ping
• Reducing the load on the yggdrasil network and peers

In addition to the first message, there is also slackhq/nebula that does something similar

[majestrate]

if you have peers on your local network and all have multicast peer discovery enabled the peers with connect to each other and traffic will not use public peers.

In my opinion, with "real" p2p you can do the same, but not restricted only to "local network". As mentioned above, Syncthing uses NAT traversal tricks to allow two peers to know each other's global real IP and port. Then, using "real" IP/port, instead of routing traffic over Yggdrasil network (that mostly relies on the regular Internet routing), it's possible to route traffic over the underlying Internet directly. The main benefits are in the first message:

• Fast connection, speed, minimum ping
• Reducing the load on the yggdrasil network and peers

In addition to the first message, there is also slackhq/nebula that does something similar

this is all that yggdrasil really does in practice. the main contributing factor here is that the network topology is dictated by who is peering with who and you cannot control who other people peer with.

i run an open bittorrent tracker inside yggdrasil and so far bittorrent inside yggdrasil seems more or less viable. the real question imo is how well back pressure propagated congestion will fare. i had something similar in lokinet, a loss tolerant durable inter node message transport. the net result was a vigorous jerk in the packet order when a link was saturated causing upper layers to slow down, albeit much more sporadically. yggdrasil's ordered fair queue congestion with back pressure seems to have less jerk when a limit is hit which is a good sign, also the latency is decent considering the relatively sparse peering which could give you routes that go over the pond more than once occasionally.

you may be looking for something like valve's steam game networking library for your "real p2p". yggdrasil is a routing protocol not a nat traversal library, although it provides such implicitly by virtue of what yggdrssil actually is.

[oficsu]

the main contributing factor here is that the network topology is dictated by who is peering with who and you cannot control who other people peer with

Yes, but since the underlying Internet is bigger, has higher bandwidth and more paths, in most cases, use of its advantages would be a good optional optimization

yggdrasil is a routing protocol not a nat traversal library

I agree, but... as a particular example, Syncthing is not a nat traversal library, but instead it's a well optimized file-sharing tool. And the same optimization can be applied to yggdrasil routing. And, with the optimization, yggdrasil won't be too. So, personally, I think that this issue is not about a "feature request", it's more like about an "optimization request"

[xialvjun]

if you have peers on your local network and all have multicast peer discovery enabled the peers with connect to each other and traffic will not use public peers.

@majestrate I see the description of multicast in yggdrasil-android is "Multicast peers will be discovered on the same Wi-Fi network or via USB".

It's only local network. But what I want and I think what the issuer want is every yggdrasil node can work as a STUN/TURN server, so A -> B -> C can be changed to A -> C for higher bandwidth in a short time after the connection is created. Of course, if yggdrasil find A -> C is broken (censorship), the connection can still use A -> B -> C.

[one-d-wide]

There is a yggdrasil-jumper that handles dynamic P2P connectivity, with no modification needed to the router code.

Key insights:

• Active sessions are obtained via the router's Admin API .
• Peers exchange their external internet addresses within yggdrasil network.
• Direct (P2P) connection is being instantiated over the internet using NAT traversal.
• This connection is relayed to the router, as if it is coming from the other router.

For more information, see the project's readme.

[neilalexander]

Closing as out-of-scope.