I'm guessing its due to the NATs they use. Carrier-grade NATs with made-up IPs and symmetric NATs. You can have some kind of options for symmetric NATs. But I'm not too sure about carrier-grade NATs yet as I've never even written code for this yet.

You'll face a lot of those problems on residential ISP connections too. The bigger issue with mobile devices is that they're roaming between towers, so there are frequent changes to the network topology. But p2p networks usually require a long-ish bootstrapping step that might not even finish by the time the physical network shifts underneath it. (Tor bootstrapping takes on the order of ~30 seconds, for example.) As the linked paper notes, this is disruptive not only to the local client, but also to the rest of the network that needs to re-learn (and re-propagate) the location of mobile peers.

No it's mostly the battery limitations.

Keeping links open P2P requires keepalive because NATs will time out. Even with IPv6 there are usually stateful firewalls in the way that will time out. This means you're constantly sending little packets, and if you have a lot of links there's a lot of keep alive cycles that have to be serviced. This keeps radios and baseband hardware from being able to sleep, draining the battery faster.

Mobile devices almost always have IPv6 on cell networks these days, which makes the actual hole punching almost 100% successful.

This seems like it should be solvable by having the stateful firewall support e.g. Port Control Protocol (RFC6887). Obviously that has to be done by the network rather than the client, but what's stopping them? It can't be resource consumption, it's an efficiency measure for the network too and "we don't kill your battery life" is an advertisable feature.

Mobile carriers have less than zero incentive to do this, so it’s dead.

Middle boxes in general have to be treated like natural laws or acts of god by developers. There’s like zero chance of affecting them outside the very narrow homelab segment. Even enterprise vendors generally can’t persuade companies to alter policies there.

Expecting all networks to do this is a pipe dream because there are too many of them and a large proportion are administered by people you might not have anything charitable to say about. And then you're stuck falling back to something ugly, like tunneling over HTTPS to a device that can map that port and using it as a relay.

But you could still use it wherever it's available. Mobile devices spend a significant proportion of the time on home WiFi networks.

And there are only three major US wireless carriers. That isn't a matter of convincing a million absentee corporate firewall administrators, it's a matter of convincing three specific entities, any one of which would be a major win.

I'm half tempted to start making "enterprise firewalls" (i.e. a thin wrapper around Linux netfilter running on commodity hardware) and then enable RFC6887 by default and put a warning in the documentation not to turn it off because forcing applications to tunnel traffic over outgoing HTTPS can impair the functionality of intrusion detection systems and remove valuable information from audit logs.

Seems like you could mitigate some of that by establishing some kind of clock:

1. wake up & enable radios

2. see if peers are in range

3. gossip updates for 30 sec

4. sleep for 5 minutes

5. repeat