The experiment that exposed a silent rewrite
On 24 July, two Cloudflare engineers published the result of a deliberately noisy experiment. Iliana Xygkou and Bryton Herdes announced IPv4 and IPv6 prefixes from Cloudflare's own network, AS13335, each carrying a different value in an old BGP field called ORIGIN. They then withdrew the prefixes to force the internet into path hunting, read what came back out of the RIPE RIS and RouteViews collectors and Cloudflare's own BMP feeds using the BGPKIT tooling, and compared the value they had sent with the value the rest of the world saw.
The values did not match. ORIGIN is one of the oldest attributes in BGP and records how a route entered the protocol: IGP, EGP or INCOMPLETE, in that order of preference. About 70% of the IPv4 paths they observed, and 67% of the IPv6 paths, arrived with ORIGIN reset to IGP, the most preferred value. Roughly 10% of their 352 direct IPv4 peers were doing the rewriting, with a similar share across 315 IPv6 peers.
The mechanism explains the motive. ORIGIN is consulted during best-path selection when two routes tie on Local Preference and on AS_PATH length, and the lower ORIGIN wins. Rewriting it to IGP promotes a path past its competitors without touching AS_PATH, which is the field everyone watches. Today 89.8% of routes carry IGP, 3.5% carry EGP and 6.7% carry INCOMPLETE, a distribution that looks tidy largely because so much of it is manufactured in transit.
The numbers point at the biggest networks
Prevalence is not the interesting part. Concentration is. Cloudflare found that 26% of the top 50 autonomous systems by AS Rank manipulate ORIGIN, along with 20% of the top 100, and that 20.3% of all the rewriting networks sit inside that top 50. Six of the sixteen Tier-1 networks do it. The networks with the most capacity to pull traffic onto their own paths are disproportionately the networks bending the field that decides close calls.
One detail reads as commercial rather than accidental. A single Tier-1 rewrites ORIGIN on routes it learns from peers while preserving it on routes it learns from customers. That is not the signature of a stale template on a router somewhere; it is a rule that treats paid traffic and settlement-free traffic differently.
The payoff was measurable in the test itself. Rewriting networks gained 12 additional IPv4 paths through themselves, an 18% increase, and 33 additional IPv6 paths, a 40% increase. That is the whole point: a single attribute rewrite, invisible to the network that set it, moved a material share of candidate paths onto the rewriter.
Cloudflare's assessment is blunt. It found no valid technical justification for the practice, and it names two harms: RFC-compliant networks are placed at a disadvantage against networks that are not, and traffic is pulled away from alternative providers that would otherwise have won the tiebreak. Its proposal is to deprecate the attribute's influence on route selection altogether, starting with implementations setting every received and advertised route to IGP.
Where a resilience claim quietly fails
The operator consequence is not really about ORIGIN. It is about what "we are multi-homed" proves. Multi-homing buys you more than one physical way out, and that part is real. What it does not buy is control over which way traffic actually returns to you, because most of the attributes that express preference are advisory once they leave your edge. Local Preference is the exception that matters: you set it on your own routers, it sits above ORIGIN in the decision process, and it never crosses an eBGP boundary, which is precisely why it is the only preference nobody else can overwrite.
That distinction has started to matter in writing. Under NIS2, network resilience is something you evidence rather than assert, and route diversity is one of the easier things to claim in a supplier questionnaire. If a single central network can move a measurable share of candidate paths onto itself by resetting one attribute, then a diversity claim built on announcements rather than on contracts and on Local Preference is a claim you cannot substantiate when someone asks.
The standards direction should also change how long you wait. An IETF draft, "Scrubbing BGP ORIGIN Attribute", published on 3 November 2025, updates RFC 4271 and RFC 7606 to make the attribute half-optional and to permit scrubbing it to IGP explicitly. Its own measurement of the default-free zone in September 2025 found roughly 9% of routes carrying INCOMPLETE and under 1% carrying EGP. Read the direction honestly: the standards process is moving toward legitimising the rewrite rather than policing it, so the behaviour will not be fixed on your behalf.
Three checks before your next transit renewal
Ask the question the measurement makes answerable. First, ask each transit provider in writing what it does to the BGP attributes on your announcements, and whether it treats peer-learned and customer-learned routes differently. Second, stop using ORIGIN as a steering signal anywhere in your own policy, because the measurement shows it does not survive the first few hops. Third, move your real preference expression onto Local Preference at your own edge and into communities you have confirmed your provider honours, then test it rather than assuming it.
Then price the answer. Transit contracts in Europe are usually quoted in EUR per Mbps committed, or in GBP in the UK, and route handling is almost never mentioned in them. If you are paying a premium for a second or third provider specifically to hold path diversity, that diversity is worth writing into the contract as a route-handling commitment. A provider unwilling to say what it does to your attributes has told you something useful about which paths you actually own.
Read next: A Single Message Reached the Host's SSH Keys | An AI Escaped Its Sandbox to Cheat on a Test
