I have spent much of my professional life working in Internet and networking infrastructure, beginning in the early days of commercial Internet deployment. Like most engineers, I have generally viewed improvements in scalability, addressability, manageability and efficiency as progress. I have learned to value above all else, the ability of the Internet to connect people, away from government overreach, provided to us in the form of layered privacy and anonymity.

The Case for IPv6

This brings me to the topic of IPv6. Technically, the argument for IPv6 is compelling. Its implementation solved a real technical problem. IPv4 address space is exhausted, and NAT introduces undesirable complexity.IPv6, on the other hand, gives us an enormous address space with cleaner end-to-end networking.

Yet I have become increasingly concerned that, in the case of IPv6, we are evaluating the technology almost entirely from the perspective of what it allows networks to do, while giving insufficient attention to what it may allow network operators, corporations and governments to do to their users and if the benefits outweigh the risks. My primary concern is privacy, and I believe the discussion is much less settled than the networking community often presents it.

The Privacy Value of NAT

For decades, the practical limitations of IPv4 forced most homes and businesses to operate behind NAT. A household containing dozens of devices could communicate with the Internet through a single public IPv4 address. While this may have initially started as an inconvenience, it soon developed as a standard.

NAT was not designed as a privacy technology, and I am not suggesting otherwise. But its architectural consequences, when compared to the alternatives, provided the user with a level of control over their networks.

An ISP observing the public side of a typical NAT gateway does not receive a unique public IPv4 address corresponding to every television, laptop, camera, phone, printer and IoT device inside that home. Those devices exist behind a layer of addressing ambiguity.

An ISP can certainly attempt to identify them through other mechanisms: managed routers, traffic fingerprinting, application telemetry, device registration or software. But that distinction is important. It requires another mechanism, and these mechanisms can also be countered by other user-developed measures.

IPv4 scarcity and NAT created friction between the internal device and the globally routable Internet. IPv6 largely removes that friction, but perhaps we should evaluate if such removal is beneficial to the end-user.

From Architectural Constraint to Policy

The common response is that IPv6 privacy extensions, temporary addresses and stateful firewalls can reproduce many of the privacy and security properties people associate with NAT. Technically, that is true, but this is precisely where my concern begins. With IPv4, some degree of separation resulted naturally from architectural constraints and address scarcity.

With IPv6, much of that separation becomes a matter of policy and implementation.

• We are trusting ISPs to rotate prefixes appropriately.
• We are trusting operating systems to use privacy-preserving addressing.
• We are trusting router manufacturers to configure firewalls correctly.
• We are trusting providers not to require device-level registration.
• We are trusting governments not to impose retention or identification requirements that take advantage of the vastly larger address space.

Those protections can all exist, but protections that exist because an organization chooses to implement them are fundamentally different from limitations that an organization is technically constrained by.

That distinction deserves considerably more attention.

Persistent Identification

RFC 8981 itself exists because persistent IPv6 interface identifiers created obvious correlation concerns. Temporary addressing mitigates some of that risk, but it does not eliminate an upstream provider’s ability to observe subscriber traffic sources, prefixes and addressing behavior.

More importantly, nothing about IPv6 prevents an ISP from designing a system where addresses, prefixes or device registrations are persistently associated with subscriber identities. IPv6 does not require this. That is not my argument.

My concern is that IPv6 makes such systems easier to construct.

Imagine a future provider requiring every Internet-connected device on its network to be registered. The provider could maintain a database functionally equivalent to:

IPv6 address → subscriber account → individual or organization → registered device.

The identifying information does not need to be encoded directly into the IP address. The database association is enough.

With effectively unlimited address space, there is no technological scarcity preventing separate addressing of every television, vehicle, phone, camera, computer or appliance.

This creates possibilities that were far more cumbersome in an IPv4 world built around shared addressing, and that should concern privacy advocates.

The Protective Role of Ambiguity

It also has consequences for attribution. The courts have already recognized that an IP address does not necessarily identify an individual. In Cobbler Nevada, LLC v. Gonzales, the Ninth Circuit recognized that identifying the subscriber associated with an IP address was not sufficient by itself to establish who actually performed an activity because multiple people and devices may share that connection.

That ambiguity is not merely an inconvenience. In some circumstances, such as engaging in protected speech, ambiguity protects people.

As networking technology becomes increasingly capable of identifying individual endpoints, we should be careful about automatically assuming that eliminating ambiguity represents progress.

Security by Configuration

My secondary concern is security. Again, NAT is not a firewall and should not be described as one. However, the ordinary IPv4 NAT model gave consumers incidental protection: unsolicited inbound traffic generally could not directly reach an internal private address without an existing translation, port forwarding or some additional traversal mechanism.

IPv6 can absolutely provide equivalent or better protection with a properly configured stateful firewall.

The problem is the phrase “properly configured.” We are replacing an architectural side effect that ordinary users received largely automatically with protections dependent upon configuration, firmware, manufacturer defaults and provider policy.

For experienced network operators, this distinction may seem trivial, but for hundreds of millions of ordinary users who do not know what prefix delegation, SLAAC, temporary addresses or stateful IPv6 firewall rules are, it is not trivial at all.

Institutions as Part of the Threat Model

The broader issue that I believe organizations should be examining is not whether IPv6 is inherently hostile to privacy. It is not. The question is whether the transition from IPv4 to IPv6 quietly shifts privacy from architectural constraint toward administrative policy.

We should be asking:

• What happens when the party controlling that policy has incentives that conflict with the privacy of the user?
• What happens if identifying individual devices becomes commercially valuable?
• What happens if governments require providers to maintain persistent device-to-subscriber mappings?
• What happens if privacy extensions remain optional while identification becomes economically or politically advantageous?

The Internet is increasingly being combined with enormous commercial databases, location histories, cameras, financial records and artificial intelligence capable of correlating information at a scale that would have been impossible only a few years ago.

In this environment, I believe infrastructure engineers need to begin treating powerful institutions themselves as part of the threat model.

We already design systems assuming that attackers may be maliciously attempting to identify systems and users. Perhaps we should also design them assuming that a future ISP, corporation or government may also not be acting in the user’s interest.

When Friction Protects Privacy

IPv6 is an extraordinary engineering achievement, but technical elegance alone should not determine the architecture of something as fundamental as the Internet.

Privacy should not depend entirely on whether the organizations operating the infrastructure continue choosing to provide it. We should take advantage of friction and ambiguity that may help protect the end-user, providing them control.

And sometimes an architectural limitation is worth preserving precisely because nobody—not an ISP, corporation or government—can simply change the policy and make it disappear.

I believe the privacy community should be having a much deeper discussion about whether IPv6 adequately accounts for that distinction.