This article focuses on the transport-layer design, not a torrent client replacement. The goal is to provide a reusable IPv6-native P2P connection layer (QUIC-based, NAT-free) that existing clients or new applications can integrate without touching their higher-level logic.

Feedback on design trade-offs is very welcome.

Global routeability doesn't automatically mean global reachability.

Many consumer and professional routers will block inbound TCP connections, and incoming UDP traffic without at least similar outbound UDP traffic preceding it, so you will still need hole punching.

Hole punching does get significantly more easy with v6, though, since there's really only one way to do "outbound connections only" firewalling (while there's several ways to port translate, some really hostile to hole punching).

Arguably one thing that's missing is a very simple, implicit standard that allows signalling a willingness to accept an inbound TCP connection from a given IP/port that such stateful firewalls can honor, similar to how they already implicitly do it for UDP, but with HTTP 3 running over UDP, the point might well be moot soon.

As with any network protocol design, the tradeoff is slighty gained from versatility over loss of privacy. So it depends on your triage of needs: security, privacy, confidentiality.

Now with the latest "quadage", unobservability (plausible deniability).