> UDP-based protocols are well suited for P2P, since hole punching is straightforward if you have predictable port mapping, you cannot disallow it.

"Cannot" is a strong word:

> UDP hole punching will not work with symmetric NAT devices (also known as bi-directional NAT) which tend to be found in large corporate networks. In symmetric NAT, the NAT's mapping associated with the connection to the known STUN server is restricted to receiving data from the known server, and therefore the NAT mapping the known server sees is not useful information to the endpoint.

* https://en.wikipedia.org/wiki/UDP_hole_punching#Overview

I've also heard lots of people complain about how they're stuck behind CG-NAT and various P2P things do not work.

the https://github.com/qh-project/qh link doesn't work for what its worth.

> and https://github.com/qh-project/qh

This link is 404.

QOTP looks really cool. Like what QUIC would be if DJB were in charge of it.

> UDP-based protocols are well suited for P2P, since hole punching is straightforward if you have predictable port mapping, you cannot disallow it.

... how does that work when the network disallows UDP altogether?

Why not? Doesn't it depend on the type of NAT used?

As I understand it, most consumer devices will set up a port mapping which is completely independent of the destination's IP and port. It's just "incoming packet for $wanip:567 goes to $internal:123, outgoing packet from $internal:123 get rewritten to appear from $wanip:567". This allows any packet towards $wanip:567 to reach the internal host - both the original server the client initiated the connection to, and any other random host on the internet. Do this on two clients, have the server tell them each other's mappings, and they can do P2P comms: basic hole punching. I believe this is usually called "Full Cone NAT".

However, nothing is stopping you from setting up destination-dependent mapping, where it becomes "incoming packet from $server:443 to $wanip:456 goes to $internal:123, outgoing packet from $internal:123 to $server:443 gets rewritten to appear from $wanip:567". This would still work totally fine for regular client-to-server communication, but that mapping would only work for that specific server. A packet heading towards $wanip:456 would get dropped because the source isn't $server:443 - or it could even get forwarded to another host on the NATed network. This would block traditional hole punching. I believe this is called "Address Restricted Cone NAT" if it filters only on source IP, or "Port Restricted Cone NAT" if it filters on both source IP and source port.

> You can't disallow hole punching.

Try doing it over a network that only allows connections through a SOCKS/Squid proxy, or on a network that uses CG-NAT (i.e., double-NAT).

See also:

> UDP hole punching will not work with symmetric NAT devices (also known as bi-directional NAT) which tend to be found in large corporate networks. In symmetric NAT, the NAT's mapping associated with the connection to the known STUN server is restricted to receiving data from the known server, and therefore the NAT mapping the known server sees is not useful information to the endpoint.

* https://en.wikipedia.org/wiki/UDP_hole_punching#Overview

From TFA:

"Unfortunately, no matter how hard you try, there is a certain percentage of nodes for whom hole punching will never work. This is because their NAT behaves in an unpredictable way. While most NATs are well-behaved, some aren’t. This is one of the sad facts of life that network engineers have to deal with."

In this scenario, the article goes on to describe a convention relay-based approach.

I would guess that most consumer routers are very cooperative as far as hole punching because it's pretty critical functionality for bittorrent and many online games. Corporate firewalls wouldn't be as motivated to care about those use-cases or may want to actively block them.

The story here is a bit complicated. WebTransport is, in some sense, an evolution of RTCQuicTransport API, which was originally meant to solve the issues people had with SCTP/DTLS stack used by RTCDataChannel. At some point, the focus switched to client-server use cases, with an agreement that we can come back to the P2P scenario after we solve the client-server one.

Superceded? No. Webtransport already was well on its way to approval when p2p-webtransport was created.

Webtransport as a protocol certainly could be used for p2p, but the browser APIs aren't there: hence p2p-webtransport was created, to allow its use beyond traditional server<->client.

> where both sides believe they are the dialer.

First time I've heard about this, and went looking for more. Came across https://news.ycombinator.com/item?id=5969030 (95 points - July 1, 2013 - 49 comments) that had bunch of background info + useful discussions.

It can be done, but it's less reliable and also requires the ability to forge packets that is not allowed on all platforms. So it's hard to use in any production application if you want it to run in user space, on Windows, or on mobile.

Just as long as you statically build and ship your application. Because I guarantee the QUIC libs in $distro are not going to be compiled with the experimental flags to make this possible. You're going to be fighting QUIC all the way to get this to work. It's the wrong choice for the job. Google did not design QUIC for human use cases and the protocol design reflects this.