What the network layer cannot do

A home router or a family DNS resolver is one layer. It is not a parent. It is not a device, or an account, or a service. It is one filter, on one network, for one set of signals [source: www-rfc7754-filtering].

This page is the honestest in the network-layer package. It lists the things a router cannot do, the things it does not even try to do, and the boundary that no amount of router-side configuration can move.

Why this matters

The most expensive mistake a parent can make with a network filter is to assume it covers more than it does.

The providers who operate these filters say so in their own help pages. BT: “If you’re accessing the Internet via a mobile network, BT Parental Controls cannot protect the device” [claim: saferinternet-technischer-kinderschutz]. Swisscom: “This restriction applies to Wi-Fi only. The device can still access the internet via mobile data” [claim: saferinternet-technischer-kinderschutz]. EE’s mobile Content Lock help page lists VPN, Apple iCloud Private Relay, and custom DNS as the conditions under which its filter does not apply [claim: saferinternet-technischer-kinderschutz].

Three independent providers, three independent network types, the same limit. The limit is in the architecture, not in the product [source: www-rfc9076-dns-privacy].

Definition

The network layer, in this page, is the part of the household network that the parent owns: the home router, the family DNS resolver, the Wi-Fi access points, and any ISP-supplied content filter on the home line.

A network-layer control is any setting that runs on this equipment and depends on traffic that crosses it.

Scope

This page is the closing article of the network-layer package. The other five pages cover specific gaps:

• DNS filtering and its limits
• Why router rules miss the phone
• Encrypted DNS and what parents see
• VPN and proxy on a child’s device
• MAC randomisation breaks device rules

This page collects the gaps in one place and states what the network layer, in aggregate, can and cannot do.

The network layer cannot follow the device

A router is a control point for one network. It is not a roaming endpoint-management system [source: www-rfc9076-dns-privacy].

Six documented paths leave the router behind:

• Cellular data on the SIM in the device.
• A hotspot from another phone.
• Any foreign Wi-Fi: school, friend, library, café.
• A VPN tunnel to any provider, including iCloud Private Relay.
• An encrypted DNS resolver that the home router cannot read.
• A network the router has never heard of, like a public Wi-Fi captive portal [source: saferinternet-technischer-kinderschutz].

RFC 9076 names the underlying reason: cellular, home, work, and public networks are distinct network contexts, and a filter in one context does not follow the device to another [source: www-rfc9076-dns-privacy].

The network layer cannot see into a tunnel

Once traffic enters an encrypted tunnel, the network layer sees only the tunnel. The destination, the hostname, the certificate, the content — all are inside the encrypted payload.

Three documented tunnel types:

• A consumer VPN app on the device [source: esafety-vpn-faq-2026].
• iCloud Private Relay for Safari traffic [source: saferinternet-technischer-kinderschutz].
• An enterprise VPN delivered through mobile device management.

The first two are one-tap installs. The third is not a child’s normal path, but a determined child may have access to it on a school-issued device.

In all three cases, the home router sees an encrypted flow to an endpoint it does not control [source: www-rfc7754-filtering].

The network layer cannot see the hostname in ECH

Encrypted ClientHello encrypts the Server Name Indication inside the TLS ClientHello [source: www-rfc9849-ech]. A filter that classifies by hostname loses the signal.

The router still sees the IP address. The router still sees the encrypted payload. The router no longer sees the hostname the user typed [source: rfc9490-mten].

The network layer cannot identify the device reliably

MAC randomisation is on by default on Android 10 and later, on current iOS, and on most current laptops [source: source-android-mac-randomization].

A router rule that identifies the device by MAC has three failure modes:

• A non-persistent MAC means a new address on every join.
• A persistent randomised MAC means a stable address within one network, but a different address on the next network.
• An OS update can change the randomisation behaviour [source: source-android-mac-randomization].

The rule is still in force. The rule points at nobody.

The network layer cannot classify every relay

A relay service is an intermediary that fetches and re-renders content from another site. A web proxy, a translation service that fetches the original, a reader-mode service, a web archive — each is, in principle, a proxy for blocked content [source: www-rfc7754-filtering].

There is no finite list of all such services. New services appear continuously. The filter that enumerates them is always one service behind [source: www-rfc7754-filtering].

The network layer cannot detect a VPN with certainty

Encrypted-traffic classifiers can identify some VPN protocols and some general VPN-like patterns. The accuracy drops when the network conditions differ from the training conditions [source: rfc9490-mten].

A classifier’s “VPN probability” is a signal, not a verdict. eSafety’s framing for services is the same: VPN detection is one input among several, not proof [source: esafety-vpn-faq-2026].

What the network layer can do

Three honest uses for the network layer:

• Be the broadest layer. A DNS filter on the home network catches the largest amount of accidental exposure at the lowest setup cost.
• Force SafeSearch on Google, where the family resolver still receives the query.
• Be a backstop for the device and account layers. When the device-side control fails or the account is changed, the network-side filter is the layer that still has the rule.

The network layer is one of several. It is the layer that backs the others up [source: saferinternet-technischer-kinderschutz].

What the network layer does not try to do

The network layer does not try to:

• Read the child’s mind.
• Read the child’s account.
• Read the child’s messages.
• Block content on a network it does not see.
• Identify the child across all of the child’s devices [source: www-rfc7754-filtering].

The network layer’s strength is exactly the network.

What belongs on the device instead

The rules that travel with the child live on the device or on the account:

• A Screen Time limit travels with the Apple Account.
• A Family Link content filter travels with the supervised Google Account.
• A profile PIN travels with a Netflix profile.
• A Restricted Mode lock travels with a YouTube account.

These rules do not know which network the device is on. They do not need to know [source: saferinternet-technischer-kinderschutz].

How to notice the network layer is not enough

The network layer is the layer the parent sees. When the network layer is doing its job, the parent sees a block. When the network layer is not enough, the parent sees nothing.

Three honest signals:

• The blocked page loads on cellular data. The block was the home router, not the device.
• The blocked page loads on a friend’s Wi-Fi. The home router is not on that network.
• The device asks for the blocked site at all. A router filter cannot know whether the device is the child.

In each case, the gap is the same gap: the device left the network. The fix is not a stronger router rule. The fix is a rule that travels with the device.

Talking about it

State the scope out loud. “This rule works at home. It does not work when you leave the house. That is by design, not a failure.”

State the rest of the rules. “There are also rules on your phone, on the apps you use, on your account.” The network is one layer, and the others exist because the network is not enough on its own.

Invite the report. A school research page blocked by a category classifier. A homework site flagged as adult content. These are real, and they are the reason children stop trusting the filter [source: saferinternet-technischer-kinderschutz].

Do not turn the gap into a moral test. “I see you used mobile data” is not a finding. The mobile data path is a normal path. The question to ask is “what were you looking at, and was it something we have a rule about”.

Re-check the network rules once a year. Broadband provider changes, router firmware updates, and family Wi-Fi password resets all reset the router-side configuration [source: www-rfc7754-filtering].

Related wiki pages

• The network layer: router, DNS and their limits
• DNS filtering and its limits
• Why router rules miss the phone
• Encrypted DNS and what parents see
• VPN and proxy on a child’s device
• MAC randomisation breaks device rules

Sources

• rfc9490-mten — IETF, RFC 9490, IAB M-TEN workshop. Names encrypted resolver, hostname encryption, and encrypted traffic classification as parental-control complications [source: rfc9490-mten].
• www-rfc9076-dns-privacy — IETF, RFC 9076. Network contexts and resolver privacy [source: www-rfc9076-dns-privacy].
• www-rfc7754-filtering — IETF, RFC 7754. Scope, granularity, and efficacy of blocking [source: www-rfc7754-filtering].
• saferinternet-technischer-kinderschutz — Austrian Safer Internet Centre. Documented layered-defense guidance and the source of the verbatim provider-quoted gaps [source: saferinternet-technischer-kinderschutz].
• esafety-vpn-faq-2026 — Australian eSafety Commissioner, FAQ on access to adult content. Regulator expectation that services consider VPN users when preventing workarounds [source: esafety-vpn-faq-2026].
• source-android-mac-randomization — AOSP, “Wi-Fi MAC randomization behavior”. First-party documentation of Android’s MAC randomisation modes [source: source-android-mac-randomization].

[source: rfc9490-mten] [source: www-rfc9076-dns-privacy] [source: www-rfc7754-filtering] [source: saferinternet-technischer-kinderschutz] [source: esafety-vpn-faq-2026] [source: source-android-mac-randomization]