Summary

  • RFC 9511 gives Internet measurement operators a small attribution surface—most notably /.well-known/probing.txt—through which a recipient can learn what an unsolicited probe claims to be, why it was sent and whom to contact.
  • The design’s decisive limit is that attribution is not authentication. A label can lower the cost of investigation, but it cannot authorize a scan, establish benign intent or take the filtering decision away from the receiving network.

The alert arrives first

The first thing an operator sees is rarely a research question. It is a packet, an alert or a line in a flow log. A host that has no obvious reason to receive traffic gets an ICMP echo request, a TCP SYN or a packet carrying an unusual IPv6 option. The security desk has to decide whether the traffic is reconnaissance, a broken application, a measurement experiment or the beginning of something more serious.

That uncertainty has a cost. Someone retrieves a packet capture, resolves an address, searches an abuse contact, checks rate and distribution, and asks whether other systems saw the same source. Even a low-rate probe can consume attention because its recipient did not volunteer to participate. The sender may consider the packet harmless; the recipient must evaluate what is observable, not what is privately intended.

RFC 9511, published in November 2023, begins inside that asymmetry. Its authors—Eric Vyncke, Benoît Donnet and Justin Iurman—do not try to prove that active measurement is safe. They propose modest ways for a sender to identify a probe so that an operator examining it later can discover a stated purpose and a contact route. The work is Informational rather than standards-track, and it represents an IETF-reviewed proposal rather than a command to deploy.

The smallness of the proposal is its point. It does not require routers to consult a global reputation service before forwarding a packet. It does not add a trust decision to the control plane. It does not ask every firewall to understand a new entitlement. It gives the sender a place to make a claim and leaves the recipient free to test it.

A description with an address

RFC 9511 defines a “Probe Description URI.” That URI may point to a file, an email address or a telephone number. The file form lives at /.well-known/probing.txt, borrowing the field discipline of RFC 9116’s security.txt. It can provide a canonical location, a contact, an expiry time, preferred languages and a one-line description of the measurement.

Each field answers a different operational question. “Contact” says where a complaint or query can go. “Expires” makes staleness visible rather than pretending that a declaration lasts forever. “Preferred-Languages” can reduce friction when the recipient and sender do not share a default language. “Description” gives a human reviewer a short account of the activity. “Canonical” can help distinguish an authoritative copy from one found through an intermediate address.

IANA’s Well-Known URIs registry records probing.txt as a permanent suffix under IETF change control. That registration makes the rendezvous point predictable. It does not certify the contents of any file placed there. The global agreement is only about where a declaration may be found and which document defines its shape.

This is a useful division of labour. A narrow common specification creates interoperability. Meaning remains with the organization that publishes the file, and judgment remains with the organization receiving the traffic. The standard neither needs nor claims the power to settle the relationship between them.

Two paths to the same question

The RFC offers out-of-band and in-band attribution because no single placement works for every measurement.

In the out-of-band form, the recipient uses the source address and, when available, reverse DNS to derive a location for the description file. The probe packet itself need not change. An analyst can perform the lookup after the event from a capture or log. This is attractive precisely because it leaves the measurement traffic alone: there is no added payload that might change how the network handles the probe.

But an address is not always a clean expression of ownership. A source can sit behind NAT. It can be dynamic. A researcher may use devices or measurement nodes whose addresses belong to somebody else.

RFC 9511 mentions RIPE Atlas as an example of a setting in which the owner of the measurement and the owner of a probe’s source address may differ. RIPE Atlas describes itself as a global network of probes and anchors that actively measure Internet connectivity. Its distributed operating model is valuable, but it demonstrates why “the packet came from this address” and “this organization commissioned this measurement” are not identical statements.

The in-band form places the URI in the packet. It can appear at the beginning of an ICMP, UDP or TCP payload, or in an IPv6 Hop-by-Hop or Destination Options header. The attribution then travels with the observation. This helps when reverse DNS is absent, the address changes or the measurement owner cannot publish a file at the source host.

The gain is not free. Adding bytes can move a packet across a path-MTU boundary. A TCP SYN carrying data can be treated differently from an ordinary SYN. An IPv6 option that does not match implementation expectations can be discarded. The act of identifying the probe can therefore change what the probe measures.

That is why the RFC does not prescribe a single universal method. Out-of-band attribution avoids perturbing the packet but depends on an address-to-description association. In-band attribution stays close to the individual packet but risks changing its fate. Combining the two may improve corroboration, yet it still does not create a cryptographic identity.

Why there is no magic string

The document advises against a special opaque marker announcing “this is a probe.” A transit device could learn that marker and give marked packets different treatment. The measurement would then observe a path partly created by the label intended to explain it.

This is more than an implementation detail. Measurement systems operate under an observer problem: an instrument that becomes recognizable can change the environment it is meant to observe. A marker that is easy for an abuse desk to find may also be easy for a middlebox to whitelist, deprioritize or block. The cleanest identifier for human investigation can become a source of sampling bias.

RFC 9511 does not eliminate that tension. It makes the trade-off visible. A sender chooses whether the lower attribution cost is worth the possibility of different packet treatment. A recipient chooses how much weight to give the discovered information. Implementers decide which payloads and options survive. No central actor can guarantee that all three decisions align.

Attribution stops before authentication

The strongest sentence in the design is a boundary. The RFC says the information cannot be blindly trusted. Anyone can put a misleading URI in a packet, publish a false description or name an uninvolved organization as the contact. A malicious actor could use attribution itself as a way to redirect anger and investigation toward a third party.

The practical rule follows: if a recipient cannot confirm the information, or does not wish to spend the effort, it should treat the flow as if no attribution existed. The label does not create a presumption of innocence. It does not weaken normal filtering, rate limits or incident-response policy. It does not turn consent into a technical field.

This distinction rescues the proposal from an impossible ambition. Authentication would require a stronger binding among the packet, the source infrastructure, the measurement owner and an identity trusted by the recipient. Authorization would require an additional decision about whether that identity may send this traffic to this destination at this time. RFC 9511 offers neither. It provides a clue that can be corroborated.

That clue still has value. Operations work is often slowed not by total absence of evidence but by fragmented evidence. A declared purpose, a current expiry date and a monitored group address can turn an unbounded search into a focused verification. The recipient may confirm reverse and forward DNS, compare published source ranges, inspect the description and contact the stated owner. The result can be faster escalation, quicker dismissal of a false positive, or a more precise block.

The benefit is administrative before it is cryptographic. It reduces the distance between observation and a responsible human without pretending that the distance has disappeared.

NCSC: a public declaration in practice

RFC 9511 cites the United Kingdom’s National Cyber Security Centre as a similar operating example. The NCSC scanning notice publishes the addresses used for its vulnerability scanning, says they have matching forward and reverse DNS, describes an identifying HTTP header, explains safety precautions and provides an opt-out contact.

Those details create several routes for corroboration. An operator can compare a source address with the published list, inspect DNS, look for the header and contact the named mailbox. The notice also exposes the organization’s operating promise: scans are tested, frequency is limited and exclusion requests can be made.

None of those signals is self-proving. A copied header is only text. A spoofed source may be possible in some contexts. A public page can become stale. The practical strength comes from agreement among independent observations and from a reachable institution that can answer. This is exactly the distinction between a visible claim and verified authority.

The example also shows why attribution is about cost distribution. Without a declaration, the receiving organization bears nearly all of the effort of interpretation. With one, the sender accepts some continuing obligations: maintain the page, keep addresses accurate, receive complaints, honour expiry and opt-out commitments, and investigate misuse of its name. Transparency has operating costs for the party that publishes it. That cost is part of making unsolicited measurement accountable.

The person in a shared standards record

The IETF Datatracker profile for Eric Vyncke lists him as an Internet Area Director and associates him with work on IPv6, telemetry and security. It records seven RFCs, including RFC 9511. The IETF’s current IESG member page likewise lists him among the Internet Area directors.

That record supplies context, not ownership. RFC 9511 has three authors and passed through IETF review. The file format draws on earlier work. The well-known URI mechanism has its own standards history. Measurement operators, DNS administrators, vendors and recipient networks make the deployment decisions. A person profile should keep all of those boundaries intact.

Vyncke’s documented work nevertheless offers a coherent lens. RFC 7404, co-authored with Michael Behringer, examined the advantages and caveats of using only link-local addresses on IPv6 infrastructure links and declined to make a universal recommendation. RFC 9511 uses a similar discipline: offer a deployable mechanism, enumerate where it helps, describe where it breaks and leave the contextual decision with the operator.

That pattern matters more than a heroic biography. Network standards frequently become dangerous when a limited signal is promoted into a universal conclusion. A routable address is not necessarily an owner. A description is not an identity proof. An identity is not authorization. A successful probe is not permission for the next one. The value of the document lies partly in refusing those equivalences.

What the mechanism changes—and what it cannot

Probe attribution can change the response path to an ambiguous packet. It can make a contact discoverable, supply a declared purpose, provide an expiry and offer a stable place for operational updates. A recipient can use those facts alongside DNS, address ownership, traffic rate, packet structure and prior observations.

It cannot prove a sender’s intention. It cannot show that a measurement is ethical simply because its rate is low. It cannot guarantee that an in-band label reaches the destination unchanged. It cannot prevent a malicious party from borrowing another organization’s name. It cannot compel a receiving network to whitelist traffic or answer the contact.

Those limits are not defects hidden at the end of the specification. They define the control surface. The sender can improve legibility. The recipient retains authority. The protocol supplies a modest common grammar between them.

For Internet measurement, that may be the right scale of standardization. The network is too distributed for a single institution to decide which probe is legitimate everywhere. A minimal declaration can still improve the quality of local decisions, especially when it is easy to publish, easy to inspect and explicit about what it does not prove.

Evidence limits

The public record establishes the content and publication status of RFC 9511, its shared authorship, the IANA registration, the institutional descriptions of Eric Vyncke’s roles, the NCSC’s stated scanning practices and RIPE Atlas’s documented operating model. It does not establish how widely probing.txt is deployed, how often operators consult it, whether it has reduced incident workload, or whether any particular packet was benign.

No causal claim should be made from Vyncke’s name to a deployment outcome. The article also does not infer that RFC 9511 governs all active measurement, that every IETF participant endorses every probe, or that any current employer directs the decisions of receiving networks.

Sources