Summary

  • RFC 9837 defines an Experimental IPv6 Destination Option whose 32-bit value identifies an egress PE FIB entry; the value selects service treatment but does not authenticate its source.
  • Global carriage requires AH or ESP. A limited-domain deployment instead depends on ACLs at every edge, and the RFC expressly describes that containment as fail-open because protection exists only after explicit configuration.
  • Processing must be disabled by default. Deployment, security cost, code-point collision, scale, interoperability and OAM remain questions for published experiments, not facts created by the RFC.

The packet arrived with a perfectly formed service number. That was enough to look up a forwarding entry and nowhere near enough to admit the packet to a VPN.

RFC 9837, published in August 2025, is unusually candid about this boundary. It is an Experimental RFC, not a Standards Track specification. Its publication record establishes IETF consensus and IESG approval for examination and evaluation. It does not establish adoption, safe deployment or interoperability.

The mechanism is compact. Following RFC 8200, an ingress provider-edge router encapsulates customer data in IPv6 and places one VPN Service Option in a Destination Options header. The option type is the experimental value 0x5E; its data length is four bytes; its 32-bit data identifies a FIB entry at the egress PE. That entry determines how decapsulated customer traffic is forwarded toward a customer edge.

The field is a selector. It is not a credential.

A valid field can carry an unauthorized instruction

The difference matters because the egress action is consequential. A device that can impersonate a participating PE could choose a service value and attempt to inject traffic into a VPN. Syntactic validation would help the attacker: the option could be in the right header, have the right length and point to a real FIB entry.

RFC 9837 therefore locates the security claim outside the 32-bit value. On the global Internet, the tunnel between ingress and egress must be cryptographically protected by AH or ESP. The receipt is then not “option present” but authenticated peer, security association, algorithm policy, key lifetime and successful verification.

Inside a limited domain, the document offers a different control. Every node at the edge must maintain ACLs that discard packets which contain the option and target an interface inside the domain. The word “every” is the architecture. A partial edge inventory is a partial security boundary.

Fail-open is an operating condition

The RFC calls those mitigations fail-open. They need explicit configuration to stop packets from leaking out of, or being accepted into, the protected context. RFC 8799 explains why limited-domain mechanisms need clear boundaries; the cited Safe(r) Limited Domains draft sharpens the fail-open/fail-closed distinction but remains work in progress.

A design review that says “this runs only internally” has not supplied the missing evidence. It must enumerate all ingress points, prove the current ACL revision reached each one, test from outside each edge, and repeat the proof after topology change. Otherwise “limited” is an intention while routing creates the actual perimeter.

RFC 6169 provides the broader tunnel-security warning: encapsulation can bypass controls that inspect only the outer or inner layer, and nested tunnels complicate policy. A packet capture at egress may demonstrate that 0x5E arrived. It cannot demonstrate that no unobserved path bypassed the admission filter.

The FIB entry has another authority chain

RFC 9837 says the FIB may be populated by an operator through CLI, by a controller using PCEP or NETCONF, or by a routing protocol. The routing extensions are outside scope.

That freedom is useful and dangerous to summarize. The packet-plane value is meaningful only against the FIB state currently installed at the egress. The same number can be absent, stale or attached to a different customer context after a rollout error. RFC 8342 helps separate requested, intended and operational state. A controller transaction is not proof of hardware state; a matching FIB entry is not proof of the principal who authorized it.

Other VPN systems, including BGP/MPLS VPNs, EVPN and SRv6, carry service meaning differently. Their existence does not validate this experiment. Generic IPv6 tunnelling explains the enclosing packet mechanics; the VPN option still needs its own admission and lifecycle receipts.

The code point is deliberately not permanent

The IANA IPv6 parameters registry provides an experimental option code point. That creates collision risk: another experiment can use the same value, and an egress that interprets both contexts alike may apply the wrong meaning. RFC 9837 therefore requires processing to be disabled by default and explicitly enabled.

Disabled-by-default is not a footnote. It is the guard against silently turning an experimental parser into a production admission surface. The enablement record needs scope, owner, change approval, device inventory and rollback. A software upgrade that resets or broadens that scope changes the security claim even if the packet format is unchanged.

RFC 7841 distinguishes RFC stream and maturity information. Here the Experimental label is operational metadata. RFC 9837 asks participants to publish results within a year on incremental deployment, synchronization, hardware upgrades, security performance, ACL effectiveness and cost, FIB population, scale, interoperability and OAM visibility. PING, TRACEROUTE, Wireshark and TCPDUMP are named because observability is part of the experiment.

This is where Heng Lu's principle of a minimum initial specification and localized future decision becomes concrete. Standardize the small field and its deterministic handling; leave admission, FIB authority and rollout with the operator that bears the failure. His argument for running-code primacy makes measured results, not document status, the decisive evidence. And reality-first reporting prevents an experiment from being advertised as an estate-wide capability.

Sources