Summary

  • RFC 9673 updates RFC 8200 with practical procedures for selective, locally configured IPv6 Hop-by-Hop Options processing.
  • A router may forward a packet while skipping options it cannot or is not configured to process; destination arrival is therefore not a receipt for per-hop execution.
  • A defensible record binds implementation capability, enabled option table, packet order and size, route and time, node-level observations, forwarding impact and application result without inventing one universal processing budget.

The test report began with a green result: the option-bearing probe reached the destination, its reply returned, and the paired packet without the option also completed. The conclusion beneath it said “Hop-by-Hop supported end to end.” The packets had proved less than the sentence.

They had shown that one packet construction crossed one route during one interval. They had not identified which intermediate routers examined the Hop-by-Hop Options header, which recognized the option, which executed it, which skipped it under local policy, or whether the destination alone supplied the visible effect. Under RFC 9673, that gap is not an implementation scandal. It is part of the deployment model.

RFC 9673 updates RFC 8200 to make Hop-by-Hop processing practical in modern routers and hosts. Its central compromise is not that every node must do the same work. It is that packets should remain forwardable while each router protects aggregate forwarding capacity and operators choose which options a box will process.

The specification removed a false universal promise

Early IPv6 specifications expected every node to examine and process the Hop-by-Hop header. High-speed forwarding made that expectation unreliable. Some platforms could handle selected options in a fast path; some sent exceptional packets toward slower general-purpose processing; some operators dropped extension-header traffic to protect devices or the control plane.

RFC 7045 documented the operational reality of extension headers, while RFC 7872 measured substantial loss on paths carrying several kinds of IPv6 extension headers. RFC 9098 later organized the operational implications, and RFC 9288 addressed filtering at transit routers. Those records explain why a binary command to “process everything” was not credible. They do not establish how an unnamed path behaves today.

RFC 8200 already said nodes along a path were expected to examine and process the Hop-by-Hop header only when explicitly configured. RFC 9673 turns that observation into a more usable procedure. A router that does not process the header must normally continue with the rest of the packet and must not discard it solely because the header is present. A configured exception remains for protecting downstream equipment that cannot comply safely.

This is a minimum shared rule, not a universal feature contract. The packet may survive precisely because a router did less work. Forwarding success and option execution can point in opposite evidentiary directions.

“Full forwarding rate” is a constraint, not a published number

RFC 9673 defines full forwarding rate as operation that does not adversely affect aggregate forwarding. It does not publish one limit for every router, nor one maximum count or size of options that all equipment must process. That restraint matters because the work depends on architecture, parser reach, option semantics, packet rate, traffic mix and local safeguards.

The standard says a router should not be configured to process the first option when doing so harms aggregate forwarding rate. Additional options should be processed only when they also stay within that boundary. It suggests a configurable lookup table of option types that a router can process at full rate.

Such a table is useful evidence, but it has a precise subject. It can say that model, build and policy generation X claim support for option Y under stated conditions. It does not say the table was loaded on every chassis. It does not say the matching path crossed those chassis. It does not say the parser reached the option after preceding headers. And it does not establish that the intended action occurred on one packet.

Calling the boundary a “processing budget” is operational shorthand. Leadership should resist turning that shorthand into an invented universal quota. The receipt must preserve the variables: platform, software, interface, option type, order, size, rate, traffic conditions, fast or slow path, rate policy and observation window.

Option order becomes a governance choice

A source may include one option, or allow several while limiting their total size. RFC 9673 motivates placing multiple options in decreasing order of importance because some routers may process only the first or a limited number. The choice of order therefore allocates scarce attention inside the packet.

Imagine a source placing a diagnostic option first and a service-critical option second. A router with capacity for one option can behave exactly as designed and still omit the action the application valued most. Reversing the order changes the operational priority without changing either option's registry status.

The IANA IPv6 option registry tells implementers which type values are assigned and points to defining specifications. Registration is not a statement that a router implements, enables or executes an option. Registry, implementation, configuration and observation are different reality layers.

This Article does not reopen the separate question of the high-order action bits for unknown options. RFC 9673 does modify the router behavior around unprocessed options, making discard and ICMP responses configuration-dependent in the relevant cases. But the leadership issue here is the local work decision: an option can be known in standards and still be skipped in forwarding.

Silence is not an acknowledgement

RFC 4443 defines ICMPv6 error machinery. RFC 9673 explains that an ICMP Parameter Problem received by the source can show that at least one node failed to recognize an option. The inverse does not hold. A router may not generate the message; the message may not return; policy may suppress it; or the packet may simply have been forwarded without processing the option.

No ICMP is therefore not a positive receipt. Nor is a destination reply. Stronger evidence might include a per-node counter bound to an option type, a trace from a named forwarding element, an exported policy generation, a controlled change in behavior attributable to one hop, and a paired traffic measurement showing aggregate impact. Each instrument still has a scope and clock.

Router Alert illustrates why scope must remain explicit. RFC 6398 explains the risk of sending traffic toward a router slow path. RFC 9673 treats Router Alert as a control-plane exception and requires a configured implementation to protect itself through measures such as access control and rate limiting. This does not make Router Alert the model for all options. It shows why a packet's request for attention cannot outrank the router's obligation to stay available.

A path race proves a path result, not a permanent capability

RFC 9673 recommends robust incremental deployment. An application can race a test packet carrying an option against traffic without it, wait for acknowledgement before sending more option-bearing packets, and refrain from using the feature when the path does not support it. RFC 8799 also helps distinguish controlled limited domains, where nodes can be configured together, from the open Internet.

Racing is valuable because it measures rather than assumes. Yet its result expires. Routes change. Equal-cost choices can select different nodes. A policy or software build can change between tests. A successful race demonstrates that the tested construction worked over the observed route and interval. It does not certify every intermediate router, every future packet or another destination.

The minimum useful record therefore includes both packets, exact extension-header bytes, option order and length, source and destination, flow identifiers, route evidence when available, timestamps, acknowledgement criteria, ICMP observations and any per-hop telemetry. If the service depends on a particular router acting, delivery alone is insufficient; the service needs a node-bound processing receipt or a design that remains useful when nodes skip the option.

That last design is the deeper achievement of RFC 9673. It does not restore a mythical world where every transit node promises the same work. It makes partial adoption survivable and asks new options to be simple, skippable, size-bounded and robust when the path declines them.

Sources