B.2 Opcodes

only for RuBoard - do not distribute or recompile

This section describes the nine opcodes defined by RFC 2186. Some experimental opcodes are discussed in Section B.4. The numeric (decimal) code appears in parentheses following the opcode name .

ICP_OP_QUERY (1)

A query message that asks a neighbor cache if it has the object with the URL given in the payload. A cache that receives a QUERY must respond with one of the following reply opcodes: ICP_OP_HIT, ICP_OP_MISS, ICP_OP_ERR, ICP_OP_MISS_NOFETCH, ICP_OP_DENIED, or ICP_OP_HIT_OBJ.

The payload of a QUERY message is shown in Figure B-2. The Requester Host Address is an artifact from the protocol's very early design and remains only for backwards compatibility. Originally, it was meant to hold the IPv4 address of the client that initiated the (HTTP) request. Note that this is different from the Sender Host Address . Instead, it is the address of the sender's client. Apparently, this field was meant to be used for analyzing the flow of requests through a hierarchy. In practice, it is always filled with 0's. The variable- sized URL field should be terminated with a null byte.

Figure B-2. ICP QUERY payload

ICP_OP_SECHO (10)

SECHO is short for Source Echo. This opcode is used for ICP queries sent to the UDP echo service (port 7) of origin servers. If enabled, the origin server simply sends the unchanged packet right back to the cache. Thus, ICP_OP_SECHO is also an ICP reply opcode. The SECHO payload is identical to the QUERY payload. The source echo feature can be used to tell if an origin server is closer than any parent caches. If so, the cache may want to forward the request directly to the origin server instead of a neighbor cache.

Unfortunately, many server administrators do not like to be probed in this manner. To them, the ICP messages appear as random UDP packets. The echo service is disabled on many hosts , and those who leave it enabled often misinterpret the ICP SECHO packets as hacker attacks. The use of source echo is now discouraged.

ICP_OP_DECHO (11)

This is also an ICP query opcode. DECHO is short for dumb echo, where dumb refers to a proxy cache that does not understand ICP. As with SECHO, its technique is to bounce an ICP message off the cache's UDP echo port. A DECHO reply message is treated just like a MISS . In other words, we assume the dumb proxy does not have the object cached. The primary purpose of the DECHO message is to measure network connectivity to the cache. The DECHO payload is identical to the QUERY payload.

ICP_OP_MISS (3)

The MISS reply message indicates that the neighbor cache does not have a fresh copy of the specified object. Note that the neighbor cache uses its own settings to determine whether a cached object is fresh or stale. These settings may be different from the querying cache's, and this causes problems with false hits (see Section 8.1.3.3).

In a parent-child relationship, a MISS reply implicitly grants permission for the child to request the object from the parent. This is not true, however, for a sibling relationship. An ICP MISS from a sibling means the querying cache must not forward the request there.

The payload of an ICP_OP_MISS message includes only the URL from the query, as shown in Figure B-3. Having the URL in the reply is probably unnecessary, since the request number is also the same in a query/reply pair. If the ICP_FLAG_SRC_RTT flag is set in the query message, and the proxy supports this feature, it may include a RTT measurement for the URL host in the Option Data field.

Figure B-3. ICP MISS payload

ICP_OP_MISS_NOFETCH (21)

This opcode is just like a regular MISS, with one important difference: the MISS_NOFETCH message tells the querying cache that it should not request this object from the responding cache at this time. Essentially, this allows the responding cache to act like a sibling if it wants to. The MISS_NOFETCH payload is identical to the MISS payload.

The responding cache may not want to handle the request for any number of reasons, including:

The cache may detect that upstream Internet connectivity is suboptimal. Connection timeouts and name lookup failures are good indications of this. By using the MISS_NOFETCH message, a parent cache instructs a child cache to use an alternate path , if possible.
The cache may become overloaded with requests. Thus, the MISS_NOFETCH message tells child caches to back off a little bit, if possible.
In a usage-based charging network, the cache may want to avoid serving cache misses during peak times.

ICP_OP_HIT (2)

The HIT reply indicates that the neighbor cache holds a fresh copy of the specified object. RFC 2187 recommends that a HIT be returned only if the object will be fresh for at least the next 30 seconds. The HIT message payload includes only the URL, just like the MISS payload.

ICP_OP_HIT_OBJ (23)

This is like a HIT reply, except that the cached HTTP response is also included in the ICP payload. The HIT_OBJ feature probably does not require its own opcode because the presence of content in the payload can be indicated with the ICP_FLAG_HIT_OBJ flag. However, the flag was invented after the opcode, as a means to indicate support for this feature.

The HIT_OBJ payload is shown in Figure B-4. Note that the object data does not necessarily begin on a four-octet boundary, as shown in the figure. In other words, the URL length is not necessarily a multiple of four octets. The object data begins immediately following the null byte that terminates the URL string.

Figure B-4. ICP HIT_OBJ payload

ICP_OP_ERR (4)

An ERR response indicates that the receiver was unable to process the query because of a protocol error. ICP_OP_ERR should be sent only in response to a QUERY. Squid sends this opcode only if the URL string is not really a URL. For other types of errors, such as an unknown opcode or version, the QUERY message is silently ignored. The ERR reply payload consists of only the URL, or whatever should have been the URL, just like the MISS reply.

ICP_OP_DENIED (22)

A DENIED message is sent in response to a query that is disallowed due to access controls. The DENIED message payload consists of only the URL, just like the MISS reply.

ICP queries from unknown sources should always be denied. In theory, ICP can be used to acquire sensitive information about the contents of your cache. Unfortunately, ICP has no real security features, so we can't be sure that a message is authentic . The best we can do is allow or deny based on the source IP address and trust that our hosts and routers are correctly configured to detect address spoofing.

A large percentage of DENIED messages indicates some sort of misconfiguration between a pair of caches. A cache that sends or receives a large amount of denied messages to another should try to get the administrator's attention so the situation can be remedied. Furthermore, I recommend that an implementation should stop sending DENIED messages to a neighbor after reaching a certain threshold. It is better just to ignore the queries than to continue filling the network with DENIED messages that seem to have no effect.

only for RuBoard - do not distribute or recompile