Super Funicular

Posted on Oct 11

Is My Phone Security Camera Exposed to the Internet on IPv6? A Local-Only, No-Cloud Check for Jio and Other IPv6 Networks

#android #ipv6 #security #privacy

Yesterday we published a guide on which SIM card to leave in an old phone security camera. One of its points was that on mobile data, people outside usually cannot connect in to the phone, because operators often share one IPv4 address between many customers.

That is true for IPv4. It is not the whole story, and for a lot of readers it is not even the main story. On Reliance Jio, APNIC Labs measures about 96% of users as IPv6-capable. Across India as a whole, Google's own statistics show about 68% of its users reaching Google over IPv6 (as of 9 October 2026). Many home broadband connections now hand out IPv6 too.

IPv6 changes one assumption that most "local-only camera" advice quietly depends on. This piece explains which assumption, and gives you a two-phone test that answers the question for your own setup.

Is my phone security camera exposed to the internet on IPv6?

Maybe, and you can check in a few minutes. On IPv4 home Wi-Fi, the thing that usually keeps a phone's camera page off the internet is the router's address translation (NAT): the phone has a private address like 192.168.1.42, and nothing outside can start a connection to it unless you forward a port. On IPv6 there is normally no NAT. The phone gets an address that is valid on the whole internet. What keeps it private then is your router's IPv6 firewall, and that may or may not be switched on.

So the honest answer is not "yes" or "no". It is: find the phone's IPv6 address, then try to open the camera page on it from outside. The steps are below.

If you use Background Camera RemoteStream: it records with the screen off to the phone's own storage and serves a live view from a small web server on the phone, for browsers on your own Wi-Fi. No account, no cloud, no subscription. The test below works the same for our app as for any other camera app with a built-in viewer. It gives you an answer about your network instead of a promise from a developer.

Why "local-only" used to work without anyone thinking about it

Here is the IPv4 picture, the one most of us learned:

Your router has one public address.
Every device inside gets a private address (192.168.x.x, 10.x.x.x). These are not routable on the internet.
When the phone opens a connection out, the router remembers it so the reply can find its way back.
When someone outside tries to open a connection in, the router has nothing to match it to, and drops it.

That last step is why a camera page "only works on my Wi-Fi" without you ever touching a firewall setting. We described it in more detail in how to watch your phone's camera from outside your home network without port forwarding.

NAT was never designed as a security feature. It was designed to stretch a shortage of IPv4 addresses. The protection was a side effect.

What IPv6 changes

IPv6 was built so that address sharing would not be needed. RFC 4864, the IETF document about protecting home networks on IPv6, opens by saying so:

"IPv6 was designed with the intention of making NAT unnecessary, and this document shows how Local Network Protection (LNP) using IPv6 can provide the same or more benefits without the need for address translation."

Google's Android team said the same thing more plainly in 2025: "When every device can get global IPv6 addresses, there is no need to use NAT for address sharing!"

So on an IPv6 network, your camera phone typically has an address that is reachable, in principle, from anywhere. Whether a connection from outside actually arrives depends on one thing: does the router filter unsolicited incoming IPv6 traffic?

RFC 4864 says the router should:

"...provide a default configuration where incoming traffic is limited to return traffic resulting from outgoing packets"

That is the same "only replies come back in" behaviour you got from NAT, now done on purpose by a firewall.

Does my router block incoming IPv6 by default?

Often, but you cannot assume it. The IETF's advice for home routers, RFC 6092, says a router should by default refuse unsolicited incoming connections. But RFC 6092 is an informational document, not a rule. It also requires an easy "transparent mode" that lets everything in, and says:

"The transparent mode of operation MAY be the default configuration."

And the main requirements document for home IPv6 routers, RFC 7084, "takes no position on whether such functionality is enabled by default."

In plain English: many routers ship with the IPv6 firewall on. Some do not. Some ISPs ship a router with their own settings. Some routers have the IPv6 firewall as a separate switch from the IPv4 one, and people turn one off while fixing something else.

The phone has more than one IPv6 address

Open your phone's IPv6 addresses and you will usually see several. On stock Android, tap your connected Wi-Fi network in Settings and look for a section called "IPv6 addresses". Menus differ between manufacturers, so on some phones you may need to look under "Advanced" or "Status".

Here is how to read the list:

Starts with	What it is	Reachable from the internet?
`fe80:`	Link-local. Only works on the same Wi-Fi.	No. Routers must not forward it.
`fd` (or `fc`)	Unique local. Like a private IPv4 address.	Not expected to be routed on the internet.
`2` or `3` (for example `2405:`, `2409:`)	Global. Valid on the whole internet.	Yes, unless something filters it.

Two more details matter:

Android uses temporary "privacy" addresses for outgoing connections. In Android's own source code, IPv6 privacy addresses are switched on and preferred for connections the phone starts. RFC 8981 sets the default for these at one day of use and two days of life. They rotate. That protects you when browsing.
A temporary address does not hide a server. The phone also has a stable global address. A web server on the phone can be reached on that one. The rotating addresses are for leaving, not for being found.

And a myth to drop: "IPv6 addresses are too long to guess, so nobody will find me." RFC 7707, the IETF's own study of how IPv6 networks get scanned, admits that brute-forcing a whole /64 network is infeasible, but warns that "the search space for such attacks is typically much smaller than the one traditionally assumed." Addresses also leak through logs and apps. Don't rely on being hard to find.

The two-phone test (about five minutes)

You need the camera phone and one other phone that has mobile data.

Step 1. Note the camera page address. Open your camera app's live view address as you normally do on your Wi-Fi (for example http://192.168.1.42:8080). Write down the port number, the part after the colon. Use whatever port your app shows you; 8080 is only an example.

Step 2. Note the camera phone's global IPv6 address. In the Wi-Fi details, pick the address that starts with 2 or 3. If there are several, try them one at a time. If there is no address starting with 2 or 3, your Wi-Fi has no global IPv6 and this particular risk does not apply on Wi-Fi. Skip to the mobile data note below.

Step 3. Check the camera page on IPv6 at home first. On a laptop or phone that is on the same Wi-Fi, type the address into the browser inside square brackets, with the port after:

http://[2405:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx]:8080/

The brackets are required. RFC 3986 says an IPv6 address in a URL is "distinguished by enclosing the IP literal within square brackets." Without them the browser cannot tell where the address ends and the port begins.

If the page loads at home, the camera page answers on IPv6. Go to step 4.
If it does not load at home, the app's server is probably not reachable on that address. Step 4 will most likely also fail, but run it anyway for a clear answer.

Step 4. Make sure the second phone really has IPv6. Turn Wi-Fi off on the second phone, so it uses mobile data. Open ipv6.google.com. That name only has an IPv6 address, so it only loads over IPv6.

If it loads, the second phone can reach IPv6 sites. Continue.
If it does not load, stop. A failed test from this phone means nothing, because it could not have reached any IPv6 address. Try a phone on a different operator.

This step matters. A test that cannot succeed cannot tell you that you are safe.

Step 5. Try the camera page from outside. Still on mobile data, type the same bracketed address and port from step 3.

It loads: your camera page is reachable from the internet. Fix this before you do anything else (see below).
It times out: your router is dropping unsolicited IPv6 from outside, at least from this network. That is the result you want.

Do it again after any router reset, firmware update, or change of ISP. Those are the moments when settings return to their defaults.

If the page loaded from outside

Do these in order. Stop when the outside test times out.

Find the IPv6 firewall in your router. In the router's admin page, look for words like "IPv6 firewall", "IPv6 filter", or "inbound filtering". Turn on the option that blocks incoming connections that were not requested. Then repeat step 5.
Check for an IPv6 "pinhole" or exception. Some routers let you open a specific device and port to the internet. If there is one for the camera phone, delete it.
If you cannot reach the router settings (rented flat, shop, guesthouse, ISP-locked router), ask the person who controls it to switch IPv6 inbound filtering on. If that is not possible, consider turning IPv6 off for that Wi-Fi network on the router, if it allows it. Do not do this to a router you do not control.
Keep a password on the camera page, and change any default. This is true on IPv4 too. A password is the last line, not the first.

Mobile data is a separate question

Everything above is about your Wi-Fi router. If the camera phone itself is on mobile data, the operator's network sits in front of it instead. Mobile networks can run their own IPv6 firewalls. We could not find a reliable public source showing which operators block incoming IPv6 to phones and which do not, so we will not guess. You cannot assume either way.

This is one more reason for the advice in the dual-SIM guide: if you only watch on your own Wi-Fi, the camera phone does not need mobile data at all. If you do run it on mobile data, the same test works. Get the phone's IPv6 address from its mobile network status, and try it from a second phone on another network.

What about the link-local address?

You might think: "I'll just use the fe80: address. It can't leave the Wi-Fi." That is true of the address. But two problems:

Browsers will not open it. A link-local address needs a "zone" (which network card to use) written into the URL. The standard for that, RFC 6874, was withdrawn in 2025. The replacement, RFC 9844, says browser makers found it "impracticable to support."
Using a local address yourself does not stop the server answering on the global one. The test above is the only thing that tells you that.

For everyday viewing on your own Wi-Fi, the normal 192.168.x.x address your app shows is still the simplest choice.

Why this matters more for "no cloud" setups

A cloud camera sends its video out to a company's server, and you watch from there. Nothing needs to connect in to the camera. That is part of what you are paying for.

A local-only camera, like a phone with a built-in web viewer, does the opposite. Your browser connects straight to the phone. That is what keeps the video off other people's servers, and it is the whole point. But it also means the network around the phone has to do the job of keeping strangers out. On IPv4, NAT did that job by accident. On IPv6, a firewall does it on purpose, if it is on.

We made a similar point in the Kimwolf botnet piece: a camera should never need an open inbound port to be useful. IPv6 does not change that rule. It changes who is responsible for enforcing it.

The short version

On IPv4, NAT usually keeps a phone camera page private by accident.
On IPv6, there is usually no NAT. Your router's IPv6 firewall does that job, and it is not guaranteed to be on.
Check, don't assume: find the address starting with 2 or 3, confirm the second phone loads ipv6.google.com, then try http://[address]:port/ over mobile data.
Loads from outside? Turn on the router's IPv6 inbound filter, delete any pinhole, and keep a password on the camera page.
Watching only at home? The camera phone does not need mobile data.

Background Camera RemoteStream turns an old Android phone into a camera that records with the screen off, keeps recordings on the phone, and shows a live view in any browser on your own Wi-Fi. It can also push to YouTube Live when you want to watch from outside. No account, no cloud storage, no subscription. It is free on Google Play, and there is more at superfunicular.com.

Sources

Top comments (1)

Harun - solo dev • Oct 11

super funicular, this is a masterclass in practical, no-nonsense network security. the shift from "accidental security via NAT" to "explicit security via IPv6 firewalls" is a massive blind spot for most developers building local-first or IoT tools.

your "two-phone test" is brilliant because it replaces dangerous assumptions with actual verification. as someone building mobile-first, constraint-driven apps, this reinforces a core rule: never assume the network layer is protecting you. explicit boundaries (like proper auth, verified firewall rules, or strict local-only routing) are the only real safety net.

thanks for breaking down the RFCs and the Android privacy address nuances so clearly. this is going straight into my personal security checklist! 🐯🛡️