Summary

  • RFC 9631 defines Experimental CRH-16 and CRH-32 routing headers whose short SIDs index local CRH-FIB entries containing an IPv6 address, topological function and optional arguments.
  • A valid SID and Segments Left transition prove neither which FIB epoch supplied the meaning nor whether ACLs, uRPF, next-hop selection and packet forwarding produced the intended path.
  • A credible receipt joins the packet to every node’s exact installed entry, trust decision, destination rewrite, forwarding observation, error or onward delivery, and the destination application result.

Two routers received the same 16-bit SID. Both parsed it correctly. Both found an entry. One mapped the number to a least-cost path; the other mapped it to a specified interface left behind by an earlier controller epoch.

The compact header did not change. The path did.

That is the evidence boundary inside RFC 9631. The Experimental RFC defines CRH-16 and CRH-32 so an IPv6 source can encode a path with shorter identifiers. It does not make those identifiers self-describing. Each is an index into local state, and local state is where operational authority enters.

The packet carries an index, not its interpretation

A CRH contains a reverse-ordered SID list. During processing, the router decrements Segments Left, uses the resulting position to select the current SID and searches its CRH Forwarding Information Base. A CRH-FIB entry yields three things: an IPv6 address, a topological function and, where needed, arguments for that function.

The distinction is structural. A full IPv6 address inside a conventional route still needs forwarding state, but a compact SID deliberately moves more meaning out of the packet. The value may request least-cost forwarding to an interface address. Another entry may require a particular egress. A function can have parameters. The short number says none of that on its own.

RFC 9631 also permits node-local significance. Each SID is processed by exactly one CRH-configured router whose address matches the packet destination, so a domain-wide dictionary is optional. SID 2 at one router need not mean SID 2 at another. Even at one router, the meaning can change after CLI work, a controller transaction or a routing update.

An audit record therefore needs more than the visible header. It needs the processing node, lookup timestamp, installed CRH-FIB revision, entry, function, arguments and provisioning provenance. Without that join, “the packet followed SID 2” is a record of syntax, not a statement about a path.

Header validation is a narrow receipt

The processing rules are precise. A node rejects a header larger than it can process. It computes the minimum legal CRH length from Routing Type and Segments Left. It rejects an impossible length, a missing FIB entry and an intermediate multicast destination. The specified failures produce ICMPv6 Parameter Problem messages.

These checks matter because they bound what a conforming implementation accepts. They do not prove that accepted input caused the intended forwarding result. After lookup, the router copies the entry’s IPv6 address into the destination field and submits the packet, topological function and arguments to the IPv6 module. The next-hop decision and actual egress occur after the compact-header check.

An absent ICMPv6 error is weaker still. The error may be filtered, lost, rate-limited or observed at the wrong point. A router can accept a legal CRH and execute an unintended but locally valid entry. A downstream interface can fail after destination rewrite. The destination can receive a packet that the application discards.

The useful receipt separates validation, lookup, rewrite, next-hop selection, egress and destination arrival. One success counter cannot borrow authority from the stages after it.

Compactness creates a state-custody obligation

The CRH-FIB may be populated by an operator using a CLI, by a controller using PCEP or NETCONF, or by a distributed routing protocol. RFC 9631 deliberately leaves those mechanisms out of scope.

That freedom is consistent with a narrow interoperability contract, but it creates a custody problem for evidence. A controller may calculate one function while a node retains another. A successful NETCONF reply may precede hardware installation. A distributed update may converge at different times. A manual rollback may restore a label without restoring its arguments.

The packet contains no table version that resolves those disputes. Operators need an immutable deployment record linking controller or operator intent to candidate configuration, installed CRH-FIB state, forwarding-plane realization and packet observation. Clock alignment matters because two correct snapshots on either side of an update can tell opposite stories about one packet.

This is also why interoperability cannot end at parsing. RFC 9631 asks experimenters whether two implementations used identical topological functions and arguments and whether the semantics were identical. A shared numeric entry with different execution meaning is wire compatibility without path compatibility.

A trusted-looking source is not a trust decision

Routing headers have a history of security risk. RFC 9631 defines trust operationally: nodes operated by the same party trust one another, and a receiving node infers that relationship from the source address. It then requires ACLs to discard CRH packets arriving from an untrusted source to a local address.

Source addresses can be forged. Enhanced Feasible-Path uRPF can remove some spoofed traffic, not all of it. The RFC therefore also requires edge ACLs that reject inbound CRH packets whose source impersonates an interface on a trusted node.

The word “trusted” is consequently the end of a local verification chain, not a property printed on the source address. A defensible record preserves the ingress interface, source prefix rule, ACL revision, counter or trace, uRPF inputs and result, and the packet disposition. It also proves that every relevant edge carried the intended rule.

Authentication Header compatibility does not eliminate this obligation. AH can protect the packet under its own key and processing context. It does not sign the operator’s historical FIB snapshot, certify that an ACL was installed at the correct edge or show where the packet actually traveled.

A smaller header is not measured performance

CRH has two stated efficiency motivations. ASIC forwarders may copy headers from buffer memory into constrained on-chip memory, making longer headers more expensive. Hosts may avoid packets larger than IPv6’s 1280-byte minimum because Path MTU Discovery is not perfectly reliable, making routing-header overhead consequential.

Those are sound hypotheses for an experiment. They are not results. Actual benefit depends on parser design, header depth, path length, payload size, MTU distribution, ICMPv6 handling, hardware generation and traffic mix. A shorter encoding can still trigger a slow path or fail at an unsupported node.

Measurements need a baseline, packet-size distribution, hardware and software versions, counter definitions, loss and latency observations, and the same traffic conditions. “Sixteen bits per SID” is an encoding fact. “Lower forwarding cost” is a measured claim.

The RFC asks for the missing evidence

RFC 9631 is unusually candid about its status. It is Experimental, not Standards Track. It asks participants to publish results covering deployment effort, incremental versus network-wide rollout, configuration synchronization, hardware upgrades, SID scope, security effort, performance, ACL effectiveness and cost, FIB population, scale, interoperability and OAM.

That list is not administrative decoration. It describes what must be known before a compact header becomes an operational proposition. Ping, traceroute, tcpdump and Wireshark support help inspect the experiment, but tool recognition does not prove function parity, edge security or application delivery.

The strongest report keeps claims bounded. A parser result proves parsing. A FIB dump proves state at a time and surface. An egress capture proves one forwarding event. A destination trace proves arrival at an observation point. Only a joined record can support a statement about the intended path.

Sources