What Should a VPN Exit Address Register Actually Record?
An exit register is only useful if each entry states its meaning, its publisher and its expiry. Classification is not subscriber identification.
Exit registers sound like lists, and the list is not the hard part. The hard part is deciding what each entry asserts, who may publish it, and what happens when the assertion stops being true. Three different address roles get conflated in these proposals, and a register that mixes them cannot answer any question reliably. Walk one entry from publication to withdrawal and the design requirements appear on their own.
Start with the record, not with the list
The first question is not how many addresses to include but what a single row means. Does it describe where clients connect, which source a destination may see, or who holds an allocation in a registry? Those are three assertions with three owners and three failure modes. A register that does not state which one it records cannot be validated, corrected or expired. Getting the meaning right is the design work, and the list is only the output.
Write the row definition before writing any schema. If the definition needs the word and, it is probably two records pretending to be one.
Three address roles that look alike
The roles are easy to confuse because one deployment can use all three at once, and often does. A service can terminate connections at one address and forward traffic from another, while a registry records a third fact entirely.
| Address role | Who may publish | What it does not prove | Withdrawal trigger |
|---|---|---|---|
| Forwarded exit | The operator that forwards the traffic, or a feed it authorizes | That a subscriber is behind the address, or that all its traffic is tunnelled | The address stops forwarding for that operator, or the prefix is reassigned |
| Registered allocation | The registry, or the holder of the allocation | That the resource is used as a VPN exit, or which application uses it | The allocation is returned, transferred, or the holder changes |
| Tunnel entry | The operator that terminates the tunnel | That traffic exits from the same address, or that the client is a subscriber | The endpoint is decommissioned or its address changes |
A hosting block can contain VPN exits and unrelated workloads side by side, so a registry match says nothing about what a given address does at a given moment. An entry that does not name its role is not evidence of anything in particular. Naming the role is what makes the record falsifiable. State the address family as well, because a register that silently covers only IPv4 will mislead anyone who assumes otherwise.
Walk one entry from publication to withdrawal
Take a single hypothetical exit and follow it. An operator publishes the prefix and its role at a stated effective time, consumers fetch it, and later the address stops serving as an exit. Each step needs a rule: who may publish, what the prefix actually covers, when the entry takes effect, and how it is withdrawn. A feed without a withdrawal path accumulates stale claims that nobody can distinguish from current ones.
Separate the authority to publish from the accuracy of the label. A registry record connecting an organization to a resource proves the allocation and not the present use, and those are different claims with different evidence. Consumers need to know which of the two they are trusting.
Define correction too. An address reassigned to a customer, or an unrelated service caught by an incorrect label, needs a documented path to a fix rather than an argument in a ticket queue. The withdrawal trigger belongs in the same document as the publication rule.
What a published feed can and cannot support
Published prefix attributes are an established pattern, and the existing examples describe geography or ownership rather than behaviour. A VPN feed would need its own semantics, its own evidence rules and its own review process, and renaming a country list supplies none of them. The ARIN registry guide shows what allocation records do and do not assert, and a new feed has to earn the same clarity about its own claims. That is a specification task, not a relabelling task.
What such a feed can support is a classification decision about a network source. What it cannot do is identify a person behind a shared address, prove that all traffic from that address is tunnelled, or decide whether a particular request is abusive. Those are three separate questions with three separate evidence requirements.
Keep the legal question outside the specification
A technical specification cannot settle whether a proposed registration requirement is lawful, proportionate or wise. That assessment needs the actual legislative text, the affected rights, the jurisdiction and a legal analysis that a data format cannot supply. A format can be well designed and still support a bad policy.
What the specification can do is make the debate concrete. Define the proposed data, its limits and its failure modes first, so the policy argument is about a real mechanism rather than an undefined list that every participant imagines differently. That is the most a technical document can contribute to a legal question.