Comment by fdr
5 hours ago
For those of you with this handy technology, the mobile phone, in the United States: you have an IPv6 address without NAT. Some of you even exist on a network using 464XLAT to tunnel IPv4 in IPV6, because it's a pure IPV6 network (T-Mobile). These mobile phone providers do not let the gazillion consumer smartphones act as servers for obvious reasons.
This is all to underscore the author's point: NAT may necessitate stateful tracking, but firewalls without translation has been deployed at massive scale for one of the most numerous types of device in existence.
> These mobile phone providers do not let the gazillion consumer smartphones act as servers for obvious reasons.
FWIW, I was interested so I tested this on my phone here in Finland (Elisa, the largest carrier here): IPv6 inbound TCP connections work just fine, unlike IPv4 which is behind CGNAT.
On mobile broadband (no calls) plans they also offer optional free public IPv4 address, but not on the regular phone plans.
(I did the test by installing Termux from Play Store, then in it running "pkg install netcat-openbsd" and "nc -6 -l 9956" and then connecting to that port from internet using telnet, while phone was not connected to WiFi.)
What would be the obvious reasons? (I'm not being flippant here -- I'm genuinely interested in what arguments people have to not allow servers on that network)
High concentration of technically inept users with hardware that no longer receives security updates and has plenty of well known easily exploitable vulnerabilities. Which naturally is used to run banking apps and travels with users close to 24/7 while tracking their location.
From a business perspective you'd want to charge extra. Just because you can, but also because you want to discourage excess bandwidth use. The internet APs the carriers sell get deprioritized relative to phones when necessary and the fine print generally forbids hosting any services (in noticeably stronger language than the wired ISPs I've had).
> From a business perspective you'd want to charge extra. Just because you can, but also because you want to discourage excess bandwidth use
Isn't that already the case with limited plans?
For example, mine has 40 GBs and I'm pretty sure it counts both upload and download, because I generally consume very little, except for one week when I was on holiday with no other internet access and wanted to upload my pictures to my home server and didn't otherwise use the phone more than usual.
The phone providers oversell bandwidth. They also limit the use of already purchased bandwidth when it gets legitimately used.
Similar to many industries, their business model is selling monthly usage, while simultaneously restricting the actual usage. They are not in the business of being an ISP for people running software on their phones.
The most common use case for mobile data servers is probably pwned cheap/old phones forming DDoS swarms. Pure P2P over internet is very rare on mobile, no sense not blocking ingress from the perspective of ISPs.
However for that having the phone's IP not reachable has at best marginal benefits. The DDoS itself is an outgoing connection, and for command and control having the compromised phone periodically fetch instructions from a server is simpler to implement than the phone offering a port where it is reachable to receive instructions
Facebook would start listening on port X and and then their embedded SDK in other websites or app would query that IP and port, get their unique id, and track users much better.
Sounds farfetched? https://www.theregister.com/2025/06/03/meta_pauses_android_t...
This is local to the device though. Nothing to do with the WAN. Would still work even on the "serverless" ipv6 network.
Mobile phones are also heavily sandboxed.