[api]

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.

[zrm]

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.

[api]

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.

[zrm]

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.

[__MatrixMan__]

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