Privacy enhancement: enforce only allowing one border router - possible?

[flatsiedatsie]

I'm trying to create a privacy-protecting implementation of Matter.

One specific issue related to Thread is that it seems difficult if not impossible to lock down access to the internet (correct me if I'm wrong). As I understand it each additional border router means there is another potential 'on ramp' to the local network, and from there to the internet.

Can I enforce a Thread network to only ever have a single exit point? In this scenario, even if another border router gets added later, I want to somehow enforce that the new BR (who I have no control over) may only run in router mode. Even if the 'main' controller disappears for a while, the other BR may become leader, but should NOT allow internet access.

Here's a network graph of the intended situation:

Is that possible?

So far I'm experimenting with setting the leaderweight to 255.
I'm also happy to see that I can set up a BR to not allow internet access by not setting network data. But that doesn't give me any control over what the other border routers do.. right?

(This is the first issue with the word 'privacy' in the title 0_0)

[jwhui]

Hi @flatsiedatsie, thanks for opening this discussion!

Attempting to enforce internet access policies or block additional Border Routers directly within the Thread mesh protocol is generally not possible by design. The recommended and most robust approach to enforcing privacy and egress restrictions is to implement these access policies on the upstream infrastructure router (e.g., the Customer Premises Equipment / CPE or home gateway router).

Here is a breakdown of how the Thread protocol handles Border Routers, how NAT64 impacts external connectivity, and why configuring upstream enforcement (such as an infrastructure-provided NAT64 prefix) is the best practice:

1. Why leaderweight and Network Data cannot restrict other Border Routers

• Decentralized Architecture by Design: Thread is specifically architected as a resilient, self-healing mesh network without a single point of failure. Any device with valid Thread network credentials (the Active Operational Dataset) and an infrastructure link (Wi-Fi or Ethernet) can operate as a Thread Border Router (TBR) and register local or external prefixes/routes (Border Router Option, Has Route Option, Server Data Prefix) into the Thread Network Data.
• The Role of the Leader: Setting leaderweight to 255 ensures your router is preferred during Leader election, but the Thread Leader acts as a coordinator for disseminating Network Data—not as an access control gatekeeper or firewall. The Leader does not have the authority to veto, drop, or reject valid Network Data registrations submitted by other authenticated Border Routers in the mesh.
• Independent On-Ramps: Even if you configure your own Border Router without internet-bound routes or external prefixes, any third-party Border Router (such as a smart speaker or smart home hub) added to the same Thread network can independently advertise a default route (::/0) and forward native IPv6 traffic between the Thread mesh and the infrastructure link.

2. The Challenge of Local NAT64 on Border Routers

When evaluating privacy and internet isolation, you must also account for NAT64/DNS64, which is implemented by many modern Thread Border Routers (such as those running OpenThread Border Router / OTBR):

• Why NAT64 exists: Thread nodes are strictly IPv6-only devices (2000::/3, fc00::/7, fe80::/10). To enable Thread devices to communicate with IPv4-only servers, a Border Router can enable a NAT64 engine coupled with DNS64 to translate between IPv6 and IPv4.
• Local NAT64 Masking Traffic: If a Border Router runs a local NAT64 engine, it registers a local /96 NAT64 prefix into the Thread Network Data. When a Thread device sends a packet to that prefix, the Border Router intercepts it and translates it into IPv4 using its own host LAN IPv4 address via NAPT (Network Address and Port Translation).
• The Granularity Problem: Because local NAT64 masks the Thread device's original IPv6 address behind the Border Router's IPv4 address, if you simply block all outbound IPv4 traffic from the Border Router host on your upstream firewall, you also prevent the Border Router host itself (e.g., your Raspberry Pi or hub OS) from performing system updates, NTP synchronization, or local/cloud management.

3. The Better Approach: Infrastructure-Provided NAT64 & CPE Enforcement

Because any Border Router can bridge native IPv6 or translate traffic to IPv4, attempting to control egress inside the Thread mesh is impractical. All traffic must ultimately traverse the upstream home router (CPE).

To ensure Thread devices are blocked from the internet while allowing the Border Router host itself to retain internet access, the recommended architecture is:

• Configure an Infrastructure-Provided NAT64 Prefix: Instead of relying on local NAT64 translation running on individual Border Routers, configure an infrastructure-provided NAT64 prefix on your upstream router/CPE (or infrastructure IPv6 gateway). When Border Routers discover an infrastructure-provided NAT64 prefix on the wlan0/eth0 link (via Router Advertisements / DHCPv6), they can publish/utilize this prefix so that IPv6-to-IPv4 translation is handled upstream at the infrastructure gateway rather than masked locally on the BR interface.
• Precise Firewall Rules on the Upstream CPE: Because traffic routed to the infrastructure-provided NAT64 prefix arrives at the upstream router still retaining the Thread device's original IPv6 source address (from the Thread delegated prefix or subnet), your upstream CPE firewall has full visibility and can enforce granular rules:
  • Block Thread Devices: Drop any outbound WAN egress packets (::/0 for native IPv6, or packets destined for the NAT64 prefix) where the source IPv6 address belongs to the Thread subnet/delegated prefix.
  • Permit Border Router Host: Allow outbound WAN access for packets originating from the Border Router host's primary infrastructure IP address (eth0/wlan0 host address), allowing the BR OS and host services to function normally without giving the Thread mesh devices internet connectivity.