Reject blackhole requests with a reason of their own

A route with the BLACKHOLE community (RFC 7999) asks for the traffic to
its prefix to be dropped. Exchange route servers pass these on as host
routes with the exchange's blackhole address as next hop, and they were
rejected as "prefix too specific", which hid what they are.

Routes from EBGP neighbors with BLACKHOLE are now rejected as "blackhole
request", whatever their length. One short enough to pass would have
been taken as an ordinary route, sending the traffic to the blackhole
next hop: the request honoured without anyone having chosen to. Acting
on blackhole requests is not supported; the import policy page and the
standards list say so.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

docs/content/docs/guides/import-policy.md

@@ -56,6 +56,23 @@ disabled.
 | Route from an EBGP neighbor whose AS path contains the local AS number | `own AS in path` |
 | Route whose next hop is unusable: unspecified, loopback, multicast, or an address of the local router | `next hop unusable` |
 | Route with the Only to Customer attribute received from the wrong direction (see [BGP Roles](@/docs/guides/roles.md)) | `route leak (Only to Customer)` |
+| Route from an EBGP neighbor with the BLACKHOLE community (RFC 7999) | `blackhole request` |
+
+### Blackhole Requests
+
+A network under a denial-of-service attack can advertise a route for the
+attacked address with the BLACKHOLE community (65535:666), to request that
+other networks discard traffic to the address. At an Internet exchange, the
+route server distributes such routes to its members with the exchange's
+blackhole address as the next hop. These routes are usually host routes
+(/32 or /128).
+
+Ferrix does not support blackhole routing. It rejects every route with the
+BLACKHOLE community from an EBGP neighbor, with the reason
+`blackhole request`, regardless of the prefix length. A route with the
+BLACKHOLE community that is accepted as an ordinary route directs traffic
+to the blackhole next hop, which discards it, so Ferrix does not accept
+these routes as ordinary routes either.
 
 ### Next Hop Check
 
@@ -105,8 +122,9 @@ Ferrix.
 
 Ferrix also applies the following checks, which the guide does not list,
 by default: the next hop must be the neighbor, routes for local prefixes
-are rejected, AS paths with an AS_SET are rejected, and the AS path must
-begin with the neighbor's AS number.
+are rejected, AS paths with an AS_SET are rejected, the AS path must begin
+with the neighbor's AS number, and routes with the BLACKHOLE community are
+rejected.
 
 > [!NOTE]
 > Ferrix does not implement the default behavior of RFC 8212 on import: it

docs/content/docs/reference/rfcs.md

@@ -173,6 +173,14 @@ The base protocol specification.
 | `LARGE_COMMUNITIES` path attribute (parse, serialise) | ✅ |
 | Attach to locally originated routes | ✅ |
 
+### RFC 7999 — BLACKHOLE Community
+<https://datatracker.ietf.org/doc/html/rfc7999>
+
+| Feature | Status |
+|---------|--------|
+| `BLACKHOLE` accepted as a community name in configuration | ✅ |
+| Routes with BLACKHOLE from EBGP neighbors rejected on import (`blackhole request`) | ✅ |
+| Blackhole routing: discarding traffic for prefixes with BLACKHOLE | ❌ |
 
 ## Other Capabilities (Wire Format Only)