Re: [IPv6] Adoption call for draft-bctb-6man-rfc6296-bis

[Simon Hobson <[e-mail]>]

On 23 March 2024 06:19:36 GMT+00:00, Ole Troan <otroan=[e-mail]> wrote:

>30 years in, someone must have built this application by now, if it’s nothing more than mosh.

I'd suggest two that were written "many" years ago but broken by NAPT44.

First, Bittorrent. Still uses peer-peer but every implementation has to jump through some hoops to work. "Work" is a bit fluid as there's normally plenty of redundancy in any torrent swarm so a few peers not working well doesn't stop things working - just lowers efficiency.

Secondly, SIP. As designed, the central control server only manages call setup/teardown and some admin functions. Actual call content (RTP stream) was designed to be sent direct between endpoints.
My experience is that with some manual config and/stun, a good SIP implementation, and a sane NAPT implementation it could work. But in general it was so hard to get working that every SIP VoIP provider has been forced to provide a proxy server to mangle SIP packets and route calls through it - and that means routing the RTP stream for a call between phones on neighbouring desks out to an internet proxy and back.
In principle, NPT66 shouldn't be hard to work with - but it still means each client performing some STUN-like process to determine what external GUA address to use.
This is subject to some of the same problems with SIP and NAPT44. The main one is that call control and content transmission is different depending on where the clients are located. In particular, if a client successfully determines the NAPT translation, calls will fail to other clients behind the same NAPT gateway - unless the gateway can trombone packets between two internal devices talking to each other's public (external) address(es) and ports.
Without any translation, the only problem is firewall traversal. For UDP that generally only needs each device to send packets to the other - the first outbound packet will result in reply packets being admitted, and bi-directional traffic should flow.
So without translation, things should "just work" whether clients are on the same location or not. With translation, things become complicated to the point that routing via a central proxy would be the norm.

That's two existing applications broken by translation - who knows what decentralised applications someone will come up with when a translation-free network becomes the norm again.

Simon