Summary

  • IPv4's ICMP Parameter Problem separated rejection from explanation: the bad packet was discarded, while an eight-bit pointer identified the offending octet in its header.
  • ICMPv6 widened the pointer to 32 bits and distinguished an erroneous field, an unknown Next Header and an unknown option. The offset could reach along an extension-header chain even when the returned quotation could not.
  • A precise pointer is bounded evidence, not authenticated truth. It can identify where one node stopped, but not prove sender intent, root cause, current product behavior or safe access beyond the quoted bytes.

A failure with an address

Most packet loss is mute. A sender transmits; no useful response comes back. The absence may mean congestion, filtering, a bad destination, a broken path or merely another lost packet. In September 1981, RFC 792 defined a narrower failure that could speak. When an IPv4 gateway or host found a header parameter so wrong that it could not continue, it had to discard the datagram. It could also return ICMP Type 12, Parameter Problem.

The distinctive field was not a sentence. It was an eight-bit Pointer. With Code 0, the value identified the octet in the original IPv4 header where the error had been detected. Offset 1 meant the Type of Service octet. If options were present, offset 20 could name the first option's type. The pointer could land in the middle of an option. It described a location in the bytes the receiver had actually tried to parse.

That small number changed the quality of the failure. A generic error says that a packet did not work. A pointer lets the source compare the report with the serializer, configuration or packet capture that produced the bytes. The rejecting node still owned the decision to discard. The source gained evidence with which to repair its own output.

The message also quoted the original Internet header and the first 64 payload bits. In early TCP or UDP traffic, those first eight octets often included ports, allowing the host to associate the error with a process. The quote and pointer served different purposes: the quote supplied context; the pointer located the detected defect.

Neither made IP reliable. RFC 792 expressly described ICMP as feedback, not a guarantee that every discarded datagram would be reported. Errors were not recursively generated about ICMP errors, and fragmented traffic had its own restrictions. Silence remained ambiguous.

From a field error to a host obligation

RFC 1122 turned the early format into host behavior. A useful stack had to receive Parameter Problem information and expose it upward when it could identify the originating process. For TCP, a parameter problem was to be reported rather than treated as a universal instruction to abort the connection. The error belonged in the evidence available to the transport and application; its mere arrival did not decide every response.

The same host-requirements document placed diagnostics under a resource constraint. Implementations should record enough of a strange packet to support investigation, but error logging must not consume prohibitive memory, storage or processing. That operational balance already foreshadowed the later wire rule: return useful context, but put a hard boundary around the cost of explaining another machine's malformed input.

RFC 1812 applied the discipline to IPv4 routers. An invalid datagram still had to be discarded. In certain partially readable cases, a router could send Parameter Problem pointing specifically to Internet Header Length or Total Length. The distinction mattered because the receiver might be looking at a truncated frame, a corrupted header, another IP version or a packet constructed illegally by the sender. A byte offset identified where validation failed; it did not settle which of those histories produced the bytes.

The router requirements also allowed an ICMP error to quote as much of the invoking datagram as possible without taking the response beyond IPv4's 576-byte minimum reassembly buffer. The evidence package could grow beyond RFC 792's original eight payload octets, but it remained bounded. A diagnostic reply was not permission to amplify an arbitrary packet into an unlimited response.

IPv6 made the pointer follow the chain

IPv4's Pointer occupied one octet because the IPv4 header, options included, could not exceed 60 bytes. IPv6 changed the shape of optional information. A fixed 40-byte base header could be followed by an ordered chain of extension headers before an upper-layer protocol appeared. A location mechanism restricted to the first header would be too small in both reach and meaning.

RFC 2463's 1998 ICMPv6 specification gave Parameter Problem Type 4 a 32-bit Pointer. The value became an octet offset within the invoking packet. Three codes divided the cause: Code 0 for an erroneous header field, Code 1 for an unrecognized Next Header, and Code 2 for an unrecognized IPv6 option. RFC 4443 preserved that architecture in 2006.

An example in the standard makes the change tangible. Pointer 40 with Code 1 names the Next Header value at the transition immediately after the 40-byte IPv6 base header. The number is not a count of routers, a protocol identifier or an error severity. It is the location of the field at which one parser could no longer choose what came next.

RFC 8200 ties that evidence to ordered processing. A destination does not scan ahead, find a familiar header and pretend the earlier unknown transition never existed. If it must proceed but does not recognize the current Next Header value, it discards and points to that value. IPv6 option types can separately require Code 2 and a pointer to the unrecognized Option Type. That option-action design is its own mechanism; here it matters only as another use of the shared location contract.

The pointer therefore records a boundary of understanding. It says: processing reached this byte and could not lawfully continue under the applicable rule. It says nothing about bytes the node never reached. A packet may contain further defects; the first reported stopping point is not a certificate for the rest of the chain.

The location can exceed the evidence returned

ICMPv6 error messages must include as much of the invoking packet as possible without making the response exceed IPv6's minimum MTU. That protects the network from unbounded error traffic and gives upper layers a reasonable chance to recover identifying context. Long extension chains create a hard case: the field in error may lie after the portion that fits.

RFC 4443 handles the case without falsifying either side. The 32-bit pointer can point beyond the end of the invoking-packet bytes contained in the ICMPv6 message. The receiver knows the reporter's offset even though the response does not carry the octet at that offset.

This is an unusually honest evidence model. It does not clamp the pointer to the last returned byte, which would accuse the wrong field. It does not expand the response past its size bound, which would make diagnosis an amplification mechanism. It preserves a precise claim—where the reporter stopped—alongside an explicit absence—the named byte is not present here.

The absence has consequences. Software must not treat the pointer as an automatically safe array index. It must first test whether the quoted invoking-packet buffer actually reaches that offset. A number may be valid in the protocol's coordinate space while invalid in the receiver's local memory buffer.

The quote may also be too short to expose the upper-layer protocol. RFC 4443 says such an error can be dropped after IPv6-layer processing when the relevant upper-layer process cannot be identified. A precise network-layer location does not guarantee delivery to the application that could use it.

When the packet is well formed but the parser is full

RFC 8883 extended the same vocabulary in 2020. Its new ICMPv6 Parameter Problem codes cover an unrecognized Next Header at an intermediate node and local limits on extension-header size, total chain length, number of headers, number of options or individual option size. The pointer names the value, first excessive octet, first header beyond a count or first option beyond a local limit, depending on the code.

This changed what Parameter Problem could truthfully mean. The packet need not contain malformed syntax. It may be structured correctly yet demand more parsing work than a node is prepared to perform. The code communicates the class of local boundary; the pointer locates where that boundary was crossed.

The distinction prevents a local implementation limit from masquerading as universal invalidity. Another node may accept the same chain. Conversely, a standards-compliant format does not compel every forwarding device to allocate unlimited parsing resources. Interoperability depends on making the refusal legible without pretending that one node's capacity is a global property of the packet.

RFC 8883 makes the memory-safety lesson explicit: before using a pointer to read the returned invoking-packet data, an implementation must verify that the offset is smaller than the available quoted length. Precision on the wire is not ownership of bytes in memory.

Evidence without automatic authority

An ICMP error is an assertion by a reporting node. By default it is not authenticated. RFC 4443 discusses forged sources, altered message fields, denial-of-service and attacks against upper-layer reactions. It recommends that upper layers validate the quoted context before acting. Correlation can ask whether addresses, protocol fields, ports and recent traffic match something actually sent. It still cannot turn the message into a complete account of the path.

Rate limiting adds another asymmetry. IPv6 nodes must limit the errors they originate, because a stream of bad packets could otherwise consume bandwidth and processing. Multicast and source-address rules suppress other responses. Middleboxes may filter ICMP. The Parameter Problem message can therefore prove that some reporter produced it; its absence cannot prove that every node parsed the packet successfully.

The historical achievement was not perfect diagnosis. It was a disciplined separation of action, cause, location and context. The packet was discarded. A code classified why processing stopped. A pointer located the detected boundary. A quotation returned only the context that fit. Each fact had a different owner and a different limit.

That architecture still offers a general lesson for distributed systems. When work must be rejected, report the smallest coordinate that lets the origin find the failure. Keep the returned evidence within a stated resource boundary. Never turn a precise number into a claim of complete knowledge.

Sources