Summary

  • Revision 05 of the IETF PROBE draft adds deployment experience saying the comparison with ping appears to have encouraged a wrong packet-format assumption and a success-shaped operator display.
  • The draft clarifies the protocol and display guidance, but a durable implementation record should bind the raw result, its rendered label and the acceptance test that proves one did not distort the other.

The line looks reassuring at a glance:

64 bytes from 192.0.2.2: icmp_seq=1 ttl=63 active=1 ipv4=0 ipv6=0

Its rhythm is familiar. An address answered. A sequence number advanced. A time-to-live value appeared. Anyone who has stared at a terminal during a network incident can recognize the visual grammar of a successful ping before reading every field.

That is precisely the problem recorded in revision 05 of the IETF’s PROBE draft. The new deployment-experience appendix says the zero values for IPv4 and IPv6 may mean the desired protocol state is absent. Yet because most of the line resembles a successful ping response, users are inclined to recognize success rather than failure. The observation is not a usability anecdote pasted onto an otherwise technical document. It exposes a governance boundary: the wire result and the operator’s decision are different objects, and a familiar presentation can silently acquire authority over both.

PROBE is not another spelling of ping

PROBE asks a different question. Ordinary ping tests bidirectional reachability between the probing and destination interfaces. PROBE sends an ICMP Extended Echo Request to a proxy interface and asks about a separate probed interface. The probed interface may sit on the proxy node or be directly connected to it. Communication is required between the probing interface and the proxy, not necessarily between the probing and probed interfaces.

The reply therefore contains more structure than a binary “answered” signal. When the query concerns a local interface, the A bit records whether the interface is active; separate bits report whether IPv4 and IPv6 are active. The draft’s own table includes five combinations. 1/0/0 means the interface is active while neither IPv4 nor IPv6 is running. Other result codes distinguish a malformed query, no such interface, no matching table entry and multiple interfaces satisfying the query.

Those distinctions matter because “a response arrived” is not the same as “the requested state exists”. A proxy can successfully process a request and truthfully return a negative or qualified result. Treating transport success as operational success collapses the measurement into the decision it is supposed to inform.

The analogy reached the packet format

The new appendix describes an earlier effect on implementation. RFC 8335, published in 2018, introduced PROBE by saying it was similar to ping. Revision 05 says that description appears to have led implementers to assume the packet format was similar too. According to the draft, initial implementations then violated the ordinary extension layout in RFC 4884.

The bis document preserves compatibility with that deployed behavior. Its ICMP Extension Structure contains exactly one Interface Identification Object, and optional data may follow outside that structure. It tells other uses of ICMP extensions not to copy this arrangement. The draft also says all known RFC 8335 implementations remain compatible and that the clarifications do not change on-the-wire behavior or require a migration.

This is not evidence that every implementer made the same mistake, nor that an analogy alone caused every design choice. It is narrower and more valuable: the specification now records that familiar language appears to have encouraged a shortcut, and the compatibility cost survived long enough to shape the replacement text.

Revision 05 makes experience part of the record

The Datatracker history records revision 05 on 6 September 2026 UTC. The document itself is dated 7 September. It moves from “Revised I-D Needed” to AD Followup, remains an Internet-Draft intended for Proposed Standard and is not an approved RFC.

The official comparison with revision 04 shows that the deployment appendix is new. The responsible Area Director had asked in May for deployment experience, including whether packets crossed the public Internet or middleboxes. The appendix now says the feature defaults off, should be tightly controlled and will generally live inside a domain where one organization controls the relevant network path. Individual experiments have crossed parts of the public Internet, but there are no broad experimental results.

That boundary is important. The revision supplies experience, not a deployment census. It also adds narrower clarifications: address objects identify unicast addresses; AFI 1 points to the ARP table, AFI 2 to the IPv6 Neighbor Cache, and other values yield no such table entry; the flow label is not specified. These changes improve the state model without turning an Internet-Draft into proof of universal behavior.

Access control cannot repair a misleading result

The draft gives substantial operational safeguards. Extended Echo is off by default. Operators should enable it only where diagnostic access is needed, restrict permitted source prefixes to authorized management networks and rate-limit requests. It warns against information leakage across network instances. These are proper controls over who may ask the question and how much information the answer may expose.

They do not solve the display problem. A perfectly authorized query can still produce a line that a hurried reader misunderstands. Authentication governs the caller. Rate limiting governs volume. Network-instance separation governs disclosure. None proves that a client rendered the protocol state without changing its practical meaning.

Bind the answer to the way it is shown

Revision 05 already points in the right direction. Appendix A.1 says a nonzero result code should be printed as a full-text error and provides explicit text for the valid A/IPv4/IPv6 combinations. That makes state more visible than a cluster of small numeric flags.

The next operational step is local, not another global registry. A release or procurement record for a PROBE client should preserve six linked items:

  1. the exact queried interface identifier and whether the query was local or adjacent;
  2. the protocol result code and raw A, IPv4 and IPv6 values;
  3. the full label and severity shown to the operator;
  4. the client and server implementation versions;
  5. an acceptance vector for each negative, ambiguous and multiple-match state; and
  6. the reviewer, decision and date for approving the rendering.

This result-to-display receipt is not required by the draft or by the IETF. It is a governance response to the evidence the draft has chosen to preserve. Its purpose is simple: let a later reviewer prove that a successful packet exchange did not become a false claim of successful service.

The deeper lesson is not that standards should avoid all analogy. Familiar language is often the fastest route into a new mechanism. But an analogy must end where the state model diverges. If the document says “like ping”, the tests must enumerate every place where it is unlike ping. If the client borrows ping’s visual shape, the negative fields must dominate the line rather than hide at its edge.

Sources

  1. IETF recent Internet-Drafts
  2. PROBE Datatracker record
  3. PROBE revision history
  4. PROBE revision 05
  5. PROBE revision 04
  6. Official revision 04–05 comparison
  7. RFC 8335
  8. RFC 4884
  9. RFC 5706
  10. RFC 2151
  11. RFC 8343
  12. PROBE source repository
  13. Responsible AD review of revision 04
  14. Lu Heng — Minimum Initial Specification, Localized Future Decision
  15. Lu Heng — Running Code Primary