Summary

  • RFC 7999 gives networks a common BLACKHOLE signal, not a remote command. A receiver may honor it only through explicit local policy, an agreed BGP relationship and proof that the peer is authorized for a covering prefix.
  • Destination-based blackholing accepts a route in order to install discard forwarding. It protects shared capacity by making attack and legitimate traffic to the selected destination disappear together.
  • Proof must connect the raw UPDATE to the authorization record, import decision, containment communities, RIB, FIB, drop counters, packet boundary, withdrawal and restored service. A registered codepoint or green BGP session proves none of that chain by itself.

The route that succeeded by ending delivery

Consider a synthetic transit customer whose public service at 203.0.113.19 is absorbing a volumetric attack. The attack saturates the customer's access circuit before an on-premises firewall can help. The customer advertises 203.0.113.19/32 to its provider with the well-known BLACKHOLE community. The provider has already enabled the service on that session and has an authorization record covering the customer's 203.0.113.0/24.

The provider accepts the /32, contains it inside the provider network and resolves it to a discard action at ingress. The attack no longer crosses the constrained circuit. Neither does legitimate traffic to the host. Other addresses in the /24 remain reachable. The target has been sacrificed to preserve the surrounding system.

Hours later, automation submits 203.0.113.91/32 instead. That address belongs to another healthy service inside the same authorized aggregate. The peer is correct. The covering prefix is correct. The community is correct. The BGP session never falls. If the service contract checks only those coarse facts, the provider executes a validly formed request whose incident intent is wrong. A second service vanishes.

The episode is invented, but the mechanism is not. It exposes the question hidden inside every blackhole route: who has authority to turn accepted reachability information into deliberate non-reachability, at which packet boundary, for which exact destination and for how long?

One shared word, no universal command

RFC 7999 defines BLACKHOLE as a well-known advisory transitive BGP community for destination-based blackholing. IANA records the four-octet value as 0xFFFF029A, commonly displayed as 65535:666. The shared value replaces a thicket of provider-specific trigger communities with one recognizable term.

Recognition is not execution. The RFC says that accepting and honoring the community, or ignoring it, is each operator's choice. In a bilateral relationship, both networks must agree before it is used. Without an explicit local directive, a network element should not discard traffic merely because the attribute is present.

That division is the architecture's most important restraint. The IETF supplied a minimum common semantic: “traffic toward this prefix is requested to be discarded.” It did not appoint the sender as sovereign over the receiver's forwarding plane. The sender attaches an advisory claim. The receiver decides whether the relationship, prefix and policy authorize an executable action.

The distinction also explains why two conforming networks may treat the same UPDATE differently. One may offer a blackhole service on a customer session and honor the signal. Another may not offer it and ignore the community. A route collector may retain the attribute without forwarding any traffic. A router may understand the named value while having no discard policy. The common codepoint coordinates; deployed policy creates reality.

Accept reachability, install non-reachability

Ordinary routing language encourages a dangerous shorthand: accepted means reachable. Destination RTBH breaks it deliberately.

RFC 5635 describes a discard route installed on participating routers, commonly with a next hop that resolves to a null or discard interface. A more-specific BGP route for the target selects that disposition. Packets entering those routers match the target prefix and are dropped before traversing the provider toward the victim.

The route can therefore be valid, selected and installed while service delivery fails exactly as intended. The control plane says, in effect, “this is the best instruction for the destination”; the forwarding plane's instruction is “do not deliver.” Loc-RIB presence is not evidence of ordinary reachability. It is not even proof of discard until the relevant FIB entry and next-hop resolution are inspected.

The operational bargain is severe but rational under the right conditions. Destination blackholing completes the outage for the target address because it drops attack and legitimate packets together. In return, it can release the access circuit, protect neighboring services and move the drop closer to the attack's ingress. “Mitigated” describes the shared capacity problem. “Unavailable” still describes the target. Both statements can be true.

Executives reviewing DDoS controls should require reports to state which objective is being measured. A falling utilization graph on the customer link may prove that traffic stopped arriving. It does not prove the customer's service survived.

The two RFC locks—and the missing third

RFC 7999 puts two locks on bilateral acceptance.

First, the blackhole prefix must be covered by an equal or shorter prefix that the neighboring network is authorized to advertise. A customer authorized for one aggregate must not be able to null-route an unrelated destination.

Second, the receiving party must have agreed to honor BLACKHOLE on that particular BGP session. Prefix authority alone does not turn every peering into a discard service. The session relationship supplies the local delegation.

Those conditions are necessary. They are not a complete incident-authorization system. A /32 can sit inside the correct customer's /24 and still identify the wrong host. A customer router can be compromised. An API can replay a stale target. An operator can use the emergency path after the incident has ended. BGP carries a prefix and attributes; it does not carry a universally verifiable ticket showing which incident commander approved which service sacrifice until which deadline.

The missing third lock must therefore live in the operational system around BGP. For every trigger, retain the requesting identity, incident identifier, approved prefix, affected service, reason, scope, activation time, expiry, and withdrawal owner. Bind that record to the exact peer, AFI/SAFI and policy version that accepted the UPDATE. The covering-prefix test answers “could this customer advertise within this space?” The incident record answers “did an authorized person intend to discard this exact destination now?”

Neither record should substitute for the other. A human approval without a deterministic prefix filter invites typo-driven outages. A prefix filter without an incident decision gives automation a standing kill privilege over every address it covers.

Precision requires an intentional exception

Blackholing works best when the announced prefix is as specific as possible. RFC 7999 identifies /32 for IPv4 and /128 for IPv6 as typical choices. Sacrificing one address is usually safer than sacrificing the aggregate containing it.

The global routing system usually treats such specifics differently. Operational filters commonly reject IPv4 routes longer than /24 and IPv6 routes longer than /48. A provider offering inter-domain RTBH must therefore create a deliberate exception: accept the customer's authorized host route for the blackhole service while preventing that route from becoming ordinary global reachability.

That exception needs four independent bounds:

  • an exact set of customer-controlled covering prefixes;
  • an allowed blackhole prefix-length range for each address family;
  • the approved trigger community on the approved session; and
  • a local action and propagation scope that cannot become ordinary transit.

“More specific is safer” is true only within those bounds. A /32 limits collateral by address count, but a wrong /32 can still remove a critical resolver, authentication endpoint or control service. A /24 may be correct during a broad attack, but it sacrifices 256 IPv4 addresses at once. Prefix length is a blast-radius decision, not clerical syntax.

This is also why maximum-prefix counters alone are weak protection. One unauthorized host route can do more service damage than thousands of ordinary routes. The control needs semantic quotas: how many simultaneous blackholes, which protected endpoints are excluded, how long a trigger may live, and which ingress regions may execute it.

Keep the destructive route inside its authority domain

RFC 7999 recommends adding NO_ADVERTISE, NO_EXPORT or a similar community according to local policy. RFC 1997 gives those values different effects. NO_ADVERTISE stops advertisement to every other BGP peer. NO_EXPORT permits internal distribution but prevents advertisement beyond the AS or confederation boundary.

The difference matters. A provider may need to distribute the blackhole route internally so multiple ingress routers discard traffic. It may need a provider-specific scope that reaches selected regions but not every edge. A route server or multilateral environment adds another policy layer. Containment must match the intended execution graph, not a slogan.

A leaked more-specific is especially dangerous because longest-prefix matching can attract traffic even where the BLACKHOLE action is ignored. Where the action is honored, the leak can recruit another network into discarding the destination. RFC 5635 consequently treats egress prefix filters as a necessary safety measure.

Implementation behavior cannot be assumed. Current FRRouting documentation says it adds NO_ADVERTISE automatically when it receives BLACKHOLE. That is useful running-code evidence for FRR, not a universal property of every platform or release. Another implementation may require an explicit route-map; a policy may replace the entire community set and accidentally remove containment; a redistribution boundary may lose the attribute while retaining a discard next hop.

For each material neighbor, capture Adj-RIB-Out or an exact advertised-route view after policy. “We configured NO_EXPORT” is an intention. The post-policy UPDATE proves what the router was prepared to send.

A minimal invariant with a deliberately local future

Heng Lu's Minimum Initial Specification provides a precise reading of RFC 7999. The common layer is narrow: a stable community value and an advisory destination-discard meaning. It does not contain the provider's commercial service, customer eligibility, device scope, incident workflow or forwarding policy. Those choices remain local because they do not need to become universal for networks to interoperate.

Localized Future Decision appears directly in the RFC: each operator chooses whether to honor or ignore the community. Refusal does not make a network invalid. Agreement creates a compatibility set between counterparties that have chosen the same operational profile.

Voluntary Adoption supplies the reality test. An RFC and IANA entry do not discard one packet. Reality begins when operators configure policy, accept the route, program the FIB and rely on the result. A coordination artifact describes a possible shared behavior; running systems decide whether it exists.

Heng Lu's distinction between symbolic and executable power is equally concrete here. 65535:666 in an UPDATE is a symbol. The import rule is delegated authority. The discard FIB entry is executable power. The missing packets are the consequence. Treating the first as proof of the last collapses four reality layers into one familiar string.

Running-code primacy does not mean “the router acted, therefore the action was legitimate.” It means legitimacy claims must survive contact with the exact behavior that code produced. The organization must show that the right counterparty requested the right prefix, the receiver applied the intended bounded policy, the correct devices discarded traffic, no unauthorized boundary propagated the route, and withdrawal restored delivery.

The shared Internet does not need a central blackhole authority. It needs a minimal common signal, locally verifiable authorization, constrained execution, portable evidence and a clean refusal path. That is how one network can ask another to destroy reachability without turning a useful emergency convention into an invisible kill switch.

Sources