Hacker News Reader

Comment by fdr | Hacker News Reader

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.

View on HN

> 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.)

When you say no ipv4 on regular phone plan, you mean no routable ipv4 on the internet, or no ipv4 at all?

Regular phone plans on my carrier have a private IPv4 address behind CGNAT.

Right, that makes sense and the way all providers that I've seen, work.

In the case of T-Mobile, unsolicited inbound IPv6 connections are blocked, but direct P2P is still possible. I successfully established a WireGuard tunnel over IPv6 between 2 phones. With IPv6, since the internal addresses and ports and the same end-to-end, all that is needed is a dynamic DNS service; STUN isn't necessary. I did need to set a persistent keepalive of 25 seconds on both sides of the tunnel to keep the firewall holes open.

Interestingly, Verizon Wireless blocks connections to other Verizon Wireless IPv6 addresses. T-Mobile-to-T-Mobile connections work, Verizon-to-T-Mobile connections work, but Verizon-to-Verizon connections do not work. Given the way Verizon's network has stagnated while T-Mobile's network has been rapidly improving, it may be time to move away from Verizon.

Slightly off-topic, but if you have a modern Google Pixel phone, Google includes "free" VPN service (which probably collects/sells your data). This service uses Endpoint-Independent filtering, so if you send an outbound packet with the source port you want to map, regardless of the destination IP/port, you can effectively receive unsolicited inbound connections from any host on the internet that contacts your IP:port, so long as you send a periodic keepalive packet from the source port you are using to anywhere.

This is how researchers were able to remotely hack several Chrysler models. They used a Sprint hotspot to get an IP on the cell network and were able to connect to any other Sprint device. The cellular modems on these cars were on Sprint so they just had to be on the same network. I wonder if Verizon intentionally blocks this.

https://www.kaspersky.com/blog/blackhat-jeep-cherokee-hack-e...

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.

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.

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

I kind of doubt this, as the rapidly changing nature of mobile IP addresses would mean that a periodic outbound connection would still be necessary to keep the attack up-to-date on the compromised devices current IP address. At that point, you may as well have the compromised device periodically poll an attacker-controlled server for instructions rather than jump through a bunch of hoops by getting things to work over inbound connections.

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.

In China you need a license to run a server.

I think it should vary based on the type of service being provided. Truly mobile service, I think it can make sense to not allow servers. If its being sold as a home internet solution (a more fixed kind of plan), I think it should allow servers to at least some level of hosting services.

The main difference is there's usually limited airtime capacity for clients, especially highly mobile ones. A server could easily hog quite a bit of the airtime on the network serving traffic to people not even in the area, squeezing out the usefulness of the network for all the other highly mobile people in the area. This person moves around, pretty much doing the equivalent of swinging a wrecking ball to the network performance everywhere they go.

When its being sold as a fixed endpoint though, capacity plans can be more targeted to properly support this kind of client. They're staying put, so its easier to target that particular spot for more capacity.

Being allowed to serve data from your own device should be seen as a natural human right.

If the networks don't have capacity or something then we need networks that can support that.

The idea that all of that has to go in the Fediverse on a server or something is just gatekeeping.

Wait a few years as IPV6 becomes truly ubiquitous. This will become very obvious to everyone and standard. People must be allowed to communicate directly, even if they have a lot of clients.

The opinions are slightly similar to remote work. Telecommuting was an obvious next step for a long time, it just took a certain number of decades for society to realize it.

What about hotspotting? Do the client pc's get the same IPv6 address as the mobile phone?

Mobile phones are also heavily sandboxed.

Reply on news.ycombinator.com