Summary

  • draft-ietf-grow-downgrade-bgp-community-01 proposes a well-known transitive BGP community that asks networks to give traffic for a tagged prefix lower precedence and to drop it before other traffic during congestion.
  • The route attribute is advisory. It does not prove that a receiver accepted the route, installed a classifier, placed packets in a lower-effort queue, preserved the LE DSCP, experienced congestion or left enough packets for the victim to observe the attack.
  • The strategy is less destructive than remote-triggered blackholing only where participating domains implement it and some unused capacity remains; the mitigation also needs an expiry and a verified return to ordinary service.

A black hole gives an operator a harsh but legible result. Traffic sent toward the victim is discarded. The rest of the network may recover, while the victim disappears.

The proposed DOWNGRADE community offers a more interesting bargain. Instead of asking neighbouring networks to discard every packet for a prefix, the victim asks them to treat that traffic as lower priority. When links or queues become congested, the downgraded aggregate should lose before ordinary traffic. When capacity is available, packets can continue. That surviving flow may keep services partly reachable and preserve the evidence that tells the defender whether the attack is still running.

That promise crosses two systems that operators too often report as one. BGP carries a policy signal. Forwarding hardware schedules packets. A community visible in an UPDATE is not a queue.

Revision 01, posted on 24 September 2026, is a work item of the IETF's GROW group. Its header describes an Informational document, while the Datatracker record still lists an active Internet-Draft rather than an RFC. The official announcement confirms the date and working-group status. It is a proposal, not an implementation census or evidence that a network has enabled the behavior.

The shared vocabulary is already real. After an author request, the live IANA BGP Well-known Communities registry assigned 0xFFFF000A to DOWNGRADE. Registration makes one value globally recognizable. It does not install an import policy, a forwarding class or an egress marker. Revision 01 itself shows the gap: its IANA section contains the assigned hexadecimal value, while the illustrative vendor configurations still show a TBD placeholder. Those examples are explanatory sketches, not deployable receipts.

The mechanism begins with RFC 1997. A BGP community is an optional transitive attribute that groups destinations for policy. Receivers can accept, prefer, distribute or modify communities according to local rules. DOWNGRADE therefore arrives as advice attached to a route. Each autonomous network still decides whether the neighbour may advertise the prefix, whether the community is retained and how that property enters the data plane.

Revision 01 says traffic for a tagged prefix should have lower precedence and, during congestion, should be dropped before any other traffic. It also asks operators to mark downgraded packets with the Lower-Effort DSCP 000001 when traffic exits toward another network domain. IX route servers should pass the community transparently, and operators should not remove it, because treatment closer to attack sources can conserve capacity earlier.

An exchange route server is not a packet switch in that path. RFC 7947 describes a control-plane intermediary. A route server can preserve and redistribute the attribute without ever seeing the packets whose fate the attribute is meant to change. Its successful propagation is one receipt, not the result.

RFC 8622 makes the lower-effort behavior deliberately weak. LE traffic may receive very low throughput or be starved completely. If a network has no separate LE queue, it should map the traffic to default forwarding and preserve the DSCP for a later domain. In that case the packets receive better treatment than requested and may still compete with ordinary best effort. If the marking is bleached or remapped, a later domain loses the clue. If legitimate traffic is wrongly placed in LE, the marking itself becomes a downgrade attack.

The phrase “preserve visibility” also needs a receipt. Some packets surviving an upstream queue does not prove that they crossed every later bottleneck, reached the victim's sensor, retained enough timing and source information to distinguish attack from recovery, or left an application usable. Conversely, an empty victim trace may mean the attack ended, an upstream queue starved the aggregate, a domain blackholed it, or the observation path failed. A single graph cannot resolve those causes.

The draft explicitly states its capacity condition: the approach relies on at least some unused capacity during the attack. Lower precedence cannot manufacture bandwidth. If the attack consumes every relevant link before classification, or if all surviving capacity is needed by higher-priority traffic, the downgraded aggregate can still disappear. The method does not remove the attack's root cause.

This is the decisive difference from RFC 7999 and the destination-based techniques in RFC 5635. BLACKHOLE asks a cooperating receiver to discard traffic and recommends propagation containment. DOWNGRADE asks networks to carry the signal widely and preserve a non-zero possibility of forwarding. Both are advisory and require prefix authorization. Their intended data-plane outcomes are opposite enough that one cannot be used as evidence for the other.

A useful operational record is therefore staged. First retain the victim prefix, incident owner, start time, requested duration and the BGP speaker authorized to announce it. Then record which neighbours accepted the community, which route servers passed it and where local policy mapped it into a forwarding class. Separately capture the installed FIB/classifier state, queue identity and scheduler, LE marking at each domain exit, congestion and drop counters, packet samples, victim-side arrival rate, application canaries and the withdrawal time. Finally verify that ordinary classification and delivery returned after the threat passed.

Heng Lu's running-code primacy places the packet treatment above the registry label. Reality layers prevent a route attribute, queue counter and service outcome from masquerading as one fact. Minimum initial specification and local future decision explains the right division of authority: the common layer can name the request; each network remains accountable for whether and how it acts.

The new community is valuable precisely because it refuses the false binary between normal forwarding and total disappearance. That value survives only if operators can prove the middle state. A tagged route is the beginning of the mitigation, not its result.

Sources