Summary

  • draft-ietf-rtgwg-dst-src-routing-revive-06 makes the packet's source prefix part of route identity and lookup. A destination/source route is therefore not ordinary destination routing with an optional label.
  • In a mixed deployment, an installed route does not prove that the next hop understands the source constraint. The design must preserve a capable path, prove progress through an incapable neighbor, or discard deliberately; otherwise persistent loops are possible.

Imagine two adjacent routers after a staged upgrade. Router A sees a route to service D qualified by source prefix S and chooses Router B. Router B runs the old forwarding model. It sees only D and sends the packet back toward A under its destination-only table. Both control planes may display plausible routes. The packet has found a loop between two different meanings of “best match”.

That is the most consequential boundary in Destination/Source Routing, revision 06, dated 16 September 2026. The RTGWG draft remains work in progress, not an RFC. Its purpose is to make the source address an additional qualifier in hop-by-hop IPv6 routing, particularly where multihoming, traffic engineering or selective reachability cannot be expressed safely by destination alone.

The mechanism is easy to summarize and easy to underestimate. Every route behaves as if it has a source prefix; ::/0 is the default. Route identity includes that source prefix. Lookup first selects the longest destination, then the longest matching source for exactly that destination. If no source qualifier matches, lookup continues at the next less-specific destination. Reversing the order changes the network's semantics.

The operational object is therefore not “prefix D is installed”. It is the tuple of destination, source range, selected next hop, recursion result, capable topology and forwarding action.

Two control planes can agree on D and disagree on the route

Destination-only routing assumes that D is enough to choose a next hop. Destination/source routing says that packets for the same D may require different paths depending on S. A multihomed site can use a provider-assigned source through the corresponding egress. An enterprise can distribute a narrowly scoped discard or prevent a service route from leaking to an unintended default path.

Those benefits exist only while every relevant forwarding decision preserves the qualifier. An incapable router does not necessarily reject the packet. It may process it successfully under a coarser rule. That is worse than a clean syntax error because the semantic downgrade can remain invisible.

The draft requires routing-protocol extensions to preserve loop freedom. It presents three families of response. Keep the next hop inside a destination/source-capable topology. Permit an incapable next hop only when the metric or identical next-hop relationship proves continued progress toward D. Or treat the route as unreachable and discard.

The third answer can look harsh on a dashboard, but it is honest. A deliberate blackhole bounds the failure. A persistent loop consumes capacity, obscures the decision boundary and may fail unpredictably under load.

Flooding is not forwarding capability

The evidence differs by routing architecture. In hop-by-hop distance-vector protocols, the peer that propagates a route is also the peer expected to forward along that information. Capability negotiation—or refusing to propagate a route format that is not understood—can help preserve the boundary, provided the control path and data path are congruent.

Link-state protocols are different. A router can flood information it does not use when forwarding. Participation in the database therefore does not prove that an SPF path is safe for source-qualified packets.

Revision 06 gives the capable router two stark choices. It can turn a route whose calculated path crosses an incapable node into a blackhole. Or it can calculate a separate topology containing only capable routers and keep packets inside that contiguous island. One additional capability topology can cover all source prefixes; one topology per source range is unnecessary.

This is a useful governance lesson for any automated network. A declaration that state was received is not proof that the receiver applies its semantics. A capability bit is stronger, but still does not prove correct configuration, recursion, FIB programming or packet delivery.

Upgrade first; activate second

The draft separates two changes that maintenance plans often collapse. The first installs software capable of destination/source lookup. The second introduces actual source-qualified routes.

A capable router behaves like an ordinary router while no such routes exist. That makes a safer sequence possible: deploy the capability throughout the routing domain, verify it, and only then activate the new route class. The draft highly recommends that sequence.

Inventory alone is not enough. “Version X supports the feature” is a product claim. The useful receipt identifies the running build, feature state, supported prefix lengths, resource ceiling, peer capability, active topology and a test showing equivalent forwarding semantics. Rollback needs the reverse ordering: remove or neutralize source-qualified routes before withdrawing capability. Otherwise recovery itself can break the compatibility set.

The implementation appendix reports Linux support through CONFIG_IPV6_SUBTREES, names FRRouting and babeld, and describes an experimental network plus 20 upgraded CERNET routers. Those are draft-author status statements, not independent evidence of a universal implementation or a production result. Procurement should treat them as leads for verification, not closure.

The route table is the beginning of the receipt

Revision 06 calls the route-table view the primary operational inspection surface and asks interfaces to place source-qualified routes beside related destination-only routes. That is necessary because a hidden two-dimensional route is easy to misread.

But a displayed row proves only local control-plane state. It does not prove that recursive next-hop resolution considered S correctly. It does not prove that hardware accepted the rule, that every downstream hop stays inside the capable island, or that a packet from S reaches D.

A defensible evidence chain has separate links:

  1. exact draft and route semantics;
  2. running software capability and resource limits;
  3. peer or topology capability evidence;
  4. installed destination/source route and policy epoch;
  5. recursive resolution and programmed FIB action;
  6. a contiguous capable path or intentional discard;
  7. packet observations for the intended S–D pair;
  8. bounded reachability and service outcome.

No link proves the next. Even a successful probe needs its source address recorded: testing D from the wrong S asks a different routing question.

Resource evidence matters too. Two-dimensional matching consumes more RIB, FIB or TCAM capacity. The draft warns that very long prefixes can have outsized cost while still requiring conforming systems to support valid lengths through /128. A route accepted in a lab does not prove safe scale on the smallest production platform.

Keep the common rule thin and the adoption evidence thick

Heng Lu's minimum-initial-specification and running-code framework fits this mechanism unusually well. The common layer needs deterministic semantics: source prefix is part of route identity, lookup ordering is fixed, and protocol extensions preserve loop freedom. It need not convert publication into authority over when every operator activates the feature.

Activation remains local. Compatibility, however, cannot be declared locally when packets cross several systems. Each participant must be able to prove which rule set it runs, and an operator must be able to discover where the compatible set ends.

That is why the decisive leadership question is not “was the route installed?” It is “did every hop that could receive this packet preserve the same source-qualified meaning—and what happened where that ceased to be true?”

Sources