RFC 10039 D-PATH: The New BGP Attribute That Stops EVPN/IPVPN Routing Loops

The passport that stops routes going in circles

Every time you cross an international border, an officer stamps your passport. Those stamps are a history: they prove exactly which countries you have visited, in order. If a border officer sees a stamp for the country you are currently trying to enter, they know something is wrong — you are going in circles.

RFC 10039 gives BGP routes a passport. Published in September 2026 as an Internet Standards Track document, it defines a new BGP path attribute called D-PATH (Domain Path). Every time a route crosses from one network domain into another, the gateway router stamps the route with that domain's identity. If a route ever comes back to a domain it already visited, the gateway there sees its own stamp and refuses to let it back in. The loop dies at the door instead of spinning forever in your control plane.

The loop nobody had a protocol fix for

The RFC spells out exactly how the loop forms, and it is depressingly easy to build by accident. Imagine an IPVPN domain (the classic MPLS VPN world of VPN-IPv4/VPN-IPv6 routes) connected to an EVPN domain (the modern data-center control plane) through two gateway PEs for redundancy.

Gateway PE1 picks up an IPVPN route for some tenant prefix and re-announces it into the EVPN domain as an EVPN route. Gateway PE2, sitting on the same boundary, hears that EVPN route and — doing its job, honestly and faithfully — re-announces it back into the IPVPN domain. PE1 hears it again, re-announces it again, and the route now ping-pongs between the two gateways forever. Each re-announcement looks like a fresh route. Nothing in BGP's normal machinery sees the circle, because AS-PATH (BGP's usual loop detector) tracks autonomous systems, not domains — and both gateways can easily be in the same AS.

Before September 2026, operators fought this with careful filtering, route maps, and institutional memory: write the right policy on every gateway, and pray the next engineer who touches the config knows why it is there. D-PATH replaces that fragility with a mechanism the routers enforce themselves.

What D-PATH actually carries

D-PATH is a list of segments, and each segment is a sequence of entries in the form <DOMAIN-ID:ISF_SAFI_TYPE>. Read it right to left the way the RFC's own example works: a D-PATH of {length=2, <6500:2:IPVPN>,<6500:1:EVPN>} means the route was born in EVPN domain 6500:1 and has since been re-announced into IPVPN domain 6500:2. The leftmost entry is the domain the gateway is announcing into; the rightmost is the domain of origin; anything in between is a domain the route merely transited.

Four details worth knowing before you touch a router:

1. Scope is narrow and deliberate. D-PATH only rides on inter-subnet-forwarding routes of SAFI 128 (IPVPN — the VPN-IPv4/VPN-IPv6 families) and SAFI 70 (EVPN). It must not be attached to any other route type. This is a scalpel, not a new universal attribute.
2. It is off by default. Gateway PEs do not send D-PATH unless you explicitly configure it. When you do, each domain you connect gets a DOMAIN-ID that you assign, and the gateways stamp it on the routes they re-originate.
3. Stamps are capped. A gateway prepends its own domain as the last element of the current segment; if the segment would exceed 255 domains, it starts a new segment. (If your route has crossed 255 domains, you have bigger problems than attribute encoding.)
4. It changes best-path selection. RFC 10039 updates the classic BGP best-path rules from RFC 4271 — but only for SAFI 128 and SAFI 70 routes carrying D-PATH for inter-domain connectivity. In practice, the domain path becomes part of how the router picks a winner, so expect vendor implementations to document exactly where the D-PATH comparison sits in their tie-break order before you rely on it for traffic engineering.

How a gateway PE uses the stamps

The procedures read like common sense once the metaphor clicks. An Interworking PE — the RFC's umbrella term for these boundary routers — pulls a route in from one domain, installs it in its IP-VRF, and re-originates it into the neighboring domain with the encapsulation that domain expects. When D-PATH is enabled, the gateway also prepends its own <DOMAIN-ID:SAFI> to the attribute before sending the route onward.

The loop-killing rule is one line: if the D-PATH on an incoming route already contains your domain's ID, do not re-originate it back into that domain. That is the entire trick. PE2 in our earlier example receives the EVPN route, sees domain 6500:2 — its own — already stamped, and drops it instead of re-announcing it into the IPVPN domain. The loop never starts.

Note what the mechanism does not do: it does not stop a route from legitimately transiting many domains. A route born in domain A, announced into B, then into C, accumulates <C>,<B>,<A> and forwards fine. Only a return to an already-visited domain is refused. That is precisely the behavior you want from stitched enterprise networks after an acquisition, or from a hyperscaler interconnecting regional EVPN fabrics through an IPVPN backbone.

Why this matters right now

Three trends make a September 2026 loop-prevention RFC immediately practical rather than academic. First, EVPN is no longer just a data-center thing — campus and enterprise designs increasingly run EVPN-VXLAN fabrics while the WAN side stays on classic IPVPN, which is exactly the mixed-domain topology RFC 10039 targets. Second, every acquisition stitches domains: two companies merge, two EVPN domains (or an EVPN and an IPVPN domain) get glued together at the border with redundant gateways, and the loop risk lands on day one. Third, the skill mix is shifting — network-engineering job postings increasingly expect EVPN fluency alongside automation, so understanding the current standards (not just the 2015-era EVPN RFCs) is becoming a hiring differentiator.

Practically speaking: you do not need to deploy D-PATH this week. Vendor implementations take time to ship, and both sides of a gateway pair need to speak it for the protection to work. But when you next design a domain boundary — a DC interconnect, a post-merger stitch, a regional fabric handoff — write "RFC 10039 D-PATH" into the design doc's future-proofing section. Check your vendors' roadmaps for it the way you would check for any new SAFI support. And if you run redundant gateways today, audit the route maps that are currently doing this job by hand: they are exactly the policies D-PATH is designed to replace.

You can explore the building blocks hands-on: our BGP fundamentals guide covers the path attributes D-PATH joins, BGP route reflector design covers scaling iBGP inside a domain, and the BGP toolkit lets you experiment with communities, prefix filters, and hijack detection.