Summary

  • RFC 7999 defines the well-known BLACKHOLE community, registered as 65535:666, so an origin network can ask a neighbor to discard traffic destined for a tagged prefix.
  • The tag is advisory rather than self-authorizing: the receiver should honor it only under prior agreement, for address space the neighbor is authorized to announce, through explicit local policy and bounded propagation.

The signal asks for a deliberate failure

Most routing signals seek reachability. BLACKHOLE asks for the opposite. During a DDoS attack, continuing to carry traffic toward one targeted address can fill an upstream link and degrade service for a wider network. A victim or its provider may therefore prefer to make the attacked destination unreachable so that the unwanted traffic is discarded before it consumes the constrained link.

RFC 7999 gives that request a common BGP community. IANA registers BLACKHOLE as hexadecimal 0xFFFF029A, conventionally written 65535:666. An origin AS can attach it to a prefix that covers the victim address. A participating neighbor may then interpret the tag as advice to discard packets destined for that prefix.

The apparent simplicity hides a consequential allocation of power. The sender identifies the destination whose reachability may be sacrificed. The receiver owns the equipment that performs the discard. If the tag were treated as an unconditional command, a peer could turn ordinary route propagation into remote control over packet loss. RFC 7999 does not grant that authority.

Agreement comes before activation

In a bilateral peering relationship, the networks must agree to use BLACKHOLE before it is advertised. The receiver must also explicitly configure its network elements to honor the community. Without that operator directive, the equipment should not discard traffic merely because the tag is present.

That is the first authorization boundary: recognition of a standardized value is not consent to execute it. The receiving network decides on which sessions the capability exists, which policy invokes it, and what local action follows. In a multilateral setting, the same decision belongs to the operator's routing policy.

The second boundary is address authority. A receiver must only honor a tagged announcement when the announced prefix is covered by an equal or shorter prefix that the neighbor is authorized to advertise. Prior agreement does not give a customer, peer or route-server participant permission to blackhole arbitrary address space. The request must stay inside the sender's established routing authority.

Specificity limits who pays

The blackhole prefix should be as specific as possible. RFC 7999 notes the typical use of /32 for IPv4 or /128 for IPv6. This is not cosmetic precision. Discarding a broad aggregate can make innocent destinations unreachable along with the attacked host. A maximally specific prefix narrows the intentional outage to the smallest practical target.

The beneficiary is not only the victim. Upstream links and neighboring services may remain usable when attack traffic is dropped before a bottleneck. Unaffected addresses benefit when the discard scope is narrow. Yet the cost is real: the selected destination loses legitimate traffic as well as attack traffic. BLACKHOLE is mitigation by controlled sacrifice, not restoration of service.

The standard does not quantify how much capacity any deployment saves, how long a blackhole remains active, or whether a named operator honors the community. Those are operational facts that require local evidence. Nor does the community authenticate the maintenance or attack story attached to a request. Authorization comes from the BGP session, prefix controls and receiver policy—not from the number 65535:666 itself.

Propagation must remain local unless policy says otherwise

A receiver should attach NO_ADVERTISE, NO_EXPORT, or a comparable community chosen under its policy so the blackhole does not escape the intended routing domain. Purposefully leaking a more-specific discard route can affect networks that never agreed to the capability and may apply different validation or filtering rules.

This creates a second proof obligation after authorization. Operators need evidence that the route was accepted only where intended and was not propagated farther. RFC 7999 encourages storing BGP updates carrying BLACKHOLE for long-term analysis or audit. A useful record links the requesting peer, prefix, covering authorization, session agreement, policy action, propagation control, activation time and withdrawal.

Evidence and limits

The normative case is bounded. RFC 7999 defines the advisory community, the bilateral agreement requirement, the covering-prefix test, the recommendation for explicit configuration, maximum practical specificity, local-scope controls and update retention. RFC 1997 supplies the surrounding community semantics, while RFC 4271 supplies the BGP context. The IANA registry supplies the assigned value.

The leadership conclusion is an inference from those controls: BLACKHOLE should be treated as a narrowly delegated emergency capability. It does not prove that any operator deployed the feature correctly, that a discarded prefix was under attack, or that mitigation succeeded. No allegation about a network or vendor follows from the standard.

Sources