Summary

  • ICPv2 was defined as a lightweight cache-neighbour hint protocol whose usefulness depended on answering quickly enough to influence where an object would be retrieved.
  • Its replies, request correlation, echo results and optional RTT measurements each prove only bounded facts; they do not establish authenticated identity, HTTP freshness, origin authority or successful application delivery.
  • Object-bearing replies reveal the cost of stretching a hint toward delivery: they can avoid a later HTTP request, but they bypass HTTP authorization and age validation and expose the exchange to additional fragmentation and spoofing risk.

The Informational document published in September 1997 by D. Wessels and K. Claffy codified ICPv2 around a simple constraint: a cache deciding where to retrieve an object could not wait indefinitely for more information. A neighbour-selection protocol had to be cheap enough that asking the question did not erase the benefit of receiving the answer.

That constraint shaped both the protocol and the meaning of its evidence. A query and reply typically needed to complete within roughly one or two seconds. If a neighbour remained silent, the requester did not need to determine whether congestion, a broken path, cache failure or some other system failure was responsible before acting. Those different causes intentionally collapsed into the same immediate operational decision: do not select that neighbour now.

The protocol therefore separated diagnosis from action. Silence was useful not because it revealed why communication had failed, but because it allowed the requester to move on without waiting for certainty.

Its packet structure was equally economical. Each message contains a fixed 20-octet header plus payload, with the entire message limited to 16,384 octets. A Request Number is copied from the query into the reply, while the exact URL ties the exchange to the resource being discussed. Those fields make correlation possible. They do not authenticate the responder.

That distinction is fundamental. A matching Request Number can show that a reply carries the same opaque correlation value as a query. The URL can show which requested resource the reply refers to. Neither field proves who sent the packet, that the sender is authorized to speak for an origin, that any object is fresh or that a later transfer succeeded.

The reply vocabulary is similarly narrow.

A HIT means that the URL exists in the responding cache and that this requester is allowed to retrieve it. That is evidence about cache state and requester permission at that moment. It does not mean the object has already been delivered. In the ordinary path, a later HTTP request is still required.

A HIT therefore does not independently prove origin authority, freshness under HTTP rules, successful application receipt, safe rendering, future availability or that this neighbour is the best source. It answers a smaller question: does this cache say it has the URL and will it permit this requester to retrieve it?

A MISS means the URL is absent. Even that answer does not necessarily eliminate the neighbour from consideration. Where the relationship permits, the requester may still fetch the object through that peer. Absence from the peer's local cache is not the same as refusal to participate in retrieval.

MISS_NOFETCH is different again. It says the cache is running but does not want to handle misses at that time. Rebuilding its store is one example. The signal therefore separates application availability from willingness to perform a particular kind of work.

DENIED is scoped still more tightly. It applies to this requester, this URL and this time. A very high denial ratio can point to a likely configuration problem between neighbours, but it does not prove hostile intent. The individual reply reports a refusal; a repeated pattern can justify investigation without supplying a motive.

The addressing fields impose their own evidence limits. The Sender Host Address is explicitly not trusted over the peer address observed through the transport interface. Its purpose is ambiguous and in practice it was unused. It should not be promoted into an identity assertion.

The Requester Host Address is separate. In a query it can be all zeroes, meaning the requester address is unspecified. That all-zero value belongs to the requester-address semantics. It is not a valid identity and should not be conflated with the untrusted Sender Host Address.

Optional source RTT information is also designed as a bounded hint. A responder may supply a stored round-trip-time measurement to the host named by the URL. The value can be absent or zero, and obtaining it must not delay the reply. The protocol therefore prefers timely existing knowledge over a fresh measurement that would slow the decision.

A returned RTT can help rank options, but it does not establish current end-to-end performance, future transfer time or the best source for the object. It says only that the responder had that stored measurement available to report.

Echo operations create a similar boundary. SECHO and DECHO can provide information about reachability. But an echo service can respond while the cache software itself is down. A successful echo therefore proves that the echo mechanism worked, not that the cache application is ready to serve.

The most consequential boundary appears in HIT_OBJ. This reply can carry object bytes and can therefore avoid a later HTTP request. That convenience changes the evidence and risk model. Because the object bypasses the ordinary HTTP retrieval step, HTTP authorization and age validation are also bypassed.

That is separate from the fact that ICP replies themselves are unauthenticated. One issue concerns what HTTP checks no longer occur when object bytes are delivered inside the cache-hint exchange. The other concerns whether the ICP reply itself proves the identity of its sender. They are distinct limitations and should remain distinct in analysis.

Object-bearing replies also stress the transport assumptions. Large UDP datagrams can exceed the path MTU and fragment. For that reason the feature is not recommended and requires explicit opt-in from the query.

Even the declared object length is not self-proving. If the specified number of object bytes does not arrive completely, the receiver treats the response as an ordinary HIT. A byte count is therefore a claim to be checked against the bytes actually received, not proof that a complete object was delivered.

The security consequences follow directly from these narrow semantics. Bogus replies can manipulate neighbour selection by forcing or preventing the use of a peer. Replies to multicast queries from unconfigured neighbours must be ignored. When spoofing is combined with an object-bearing reply, the danger rises from a poor selection decision to cache poisoning because invalid object data can be introduced.

The protocol's historical value lies in the discipline of these boundaries. A timely UDP response proves that a response arrived in time. A request-number match supports correlation. An echo response proves limited reachability. A stored RTT reports a measurement the responder already had. A HIT reports bounded cache state and permission. Complete object bytes in an opted-in object-bearing reply prove that those bytes arrived in that exchange.

None of those facts, alone, proves authenticated identity, origin authority, HTTP freshness, complete application processing, safe rendering, the best possible source, future availability or a business outcome. The protocol remains instructive because its usefulness depended not on answering every question, but on answering one narrow question quickly enough to guide the next action.