Rayhaan JaufeerallyandClaude Fable 5.1
6d8f89e509
Before this change, a route carrying the BLACKHOLE community (65535:666,
RFC 7999) from an EBGP neighbor was always rejected with the reason
"blackhole request", and nothing discarded traffic. A customer under a
denial-of-service attack had no way to ask this router to drop traffic
to an address.
This change adds `accept_blackholes` to the import policy. When it is
set, a route with the BLACKHOLE community is accepted if:
* its prefix is a single address, a /32 or a /128 (otherwise it is
rejected with the new reason "blackhole for more than one address");
the `max_ipv4_prefix_length` and `max_ipv6_prefix_length` limits do
not apply, as RFC 7999 section 3.2 recommends;
* the address is inside a prefix the neighbor may announce, if
`prefixes` is configured, regardless of the entry's `max_length`
(new `PrefixSet::covers`); without a prefix list, an address inside
the local AS's own prefixes is rejected as before ("prefix is our
own");
* the AS path, origin and RPKI checks that apply to every route pass.
The next hop of an accepted blackhole route is not checked for
third-party addresses and is not resolved, because traffic is never
forwarded to it. The route takes part in best path selection as usual;
a host route is normally the active route for its address.
The kernel task installs the active route as a kernel blackhole route
(`RTN_BLACKHOLE`, shown by `ip route` as `blackhole PREFIX proto bgp`).
Blackhole routes left by an earlier run are adopted at startup like
other routes of ours. The route is advertised to other neighbors as the
export policy and export limits permit, with the community intact, so a
provider that honors BLACKHOLE can discard the traffic upstream.
Implementation:
* `plan::Target` becomes an enum: `Via { gateway, interface }` or
`Discard`. `plan::resolve` takes a `blackhole` flag and returns
`Discard` for such routes without looking at the next hop (the
own-network check still applies). No nexthop object is made for a
discard target.
* `AttrSet::is_blackhole` reads the community off the stored attribute
bytes, like `next_hop` and `as_path`, so the kernel task, the
revalidator and the RPKI revalidation can ask it of every route.
* `ImportPolicy::is_blackhole_request` and `check_blackhole_prefix`
carry the import side; the import flow (`routes.rs`) computes once per
UPDATE whether its routes are an accepted blackhole request and skips
the next hop checks for them.
* `Status::blackholes` and the `blackholes` field of `/api/kernel` count
the installed blackhole routes; the status page shows the count next
to the installed routes.
Not covered: a prefix this router originates with the BLACKHOLE
community is advertised but not installed as a blackhole route. The
documentation says to add a kernel blackhole route by hand for that
case.
Documentation: the "Blackhole Routes" section of the import policy
guide replaces "Blackhole Requests", the kernel guide gains a "Blackhole
Routes" section, the configuration reference describes
`accept_blackholes`, the HTTP API reference describes `blackholes`, and
the RFC 7999 rows of the standards reference are updated.
Testing: unit tests for the attribute check, the prefix checks and the
plan; integration tests that a blackhole request is refused by default
and, with `accept_blackholes`, taken for one address inside the peer's
space and refused otherwise, with the recorded reasons; a kernel test
that a blackhole request becomes a kernel blackhole route whatever its
next hop, is removed on withdrawal and is adopted after a restart. The
existing kernel tests, the interoperability lab and the workspace tests
pass.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
14 KiB
14 KiB
+++ title = "Supported Standards" description = "Lists the RFCs and Internet-Drafts that Ferrix supports, and the implementation status of each feature." weight = 5
[extra] nav = "Supported Standards" +++
This topic lists the RFCs and Internet-Drafts that Ferrix supports, and the implementation status of each feature. Table 1 describes the status values.
| Status | Meaning |
|---|---|
| ✅ | Supported. |
| 🟡 | Encoded and decoded only. Ferrix parses and generates the element but does not act on it. |
| ❌ | Not supported. |
Core BGP
RFC 4271 — A Border Gateway Protocol 4 (BGP-4)
https://datatracker.ietf.org/doc/html/rfc4271
The base protocol specification.
| Section | Description | Status |
|---|---|---|
| §4.1 | Message framing (marker, length, type) | ✅ |
| §4.2 | OPEN message | ✅ |
| §4.3 | UPDATE message (path attributes, NLRI, withdrawn routes) | ✅ |
| §4.4 | KEEPALIVE message | ✅ |
| §4.5 | NOTIFICATION message (all error codes and subcodes) | ✅ |
| §8 | FSM — passive (inbound) side: OpenSent → OpenConfirm → Established | ✅ |
| §8 | FSM — active (outbound) side: dial configured peers, exponential retry | ✅ |
| §6.2 | Bad Peer AS check against configured ASN | ✅ |
| §6.7 / RFC 4486 | Cease / Administrative Shutdown sent to every peer on SIGINT or SIGTERM | ✅ |
| §6.8 | Connection collision detection (BGP Identifier comparison, Cease / Connection Collision Resolution) | ✅ |
| §8.1.1 | Optional CollisionDetectEstablishedState (collision_detect_established_state) |
✅ |
| §6.2 | Bad BGP Identifier check (neighbor uses the local identifier, or 0.0.0.0) | ✅ |
| §9 | Decision process / best-path selection | ✅ |
| §9.1.2 | Best routes installed for forwarding (Linux kernel, over netlink) | ✅ |
| §9.1.2.1 | Routes with an unresolvable next hop excluded from selection | ✅ where routes are installed in the kernel: such a route is held out of the table until its next hop can be reached |
| §9.1.2.1 | Next hops resolved through other routes | ✅ (through the kernel's connected, static and IGP routes; not through BGP routes) |
| §9 | Adj-RIB-In (per-peer table of received routes) | ✅ |
| §9 | Locally originated routes, advertised to all established peers | ✅ |
| §9 | Advertisement of the best path for each prefix to neighbors (export.learned_routes), with the local AS prepended and the local address as next hop; MED and LOCAL_PREF not sent to EBGP neighbors; LOCAL_PREF sent to IBGP neighbors (§5.1.4, §5.1.5, §9.1.3) |
✅ |
| §9.2.1 | Routes learned from an IBGP neighbor not advertised to other IBGP neighbors, except by route reflection (RFC 4456) | ✅ |
| §9.1.3 | Routes not advertised to a neighbor whose AS is in the AS path | ✅ |
| §5 | Unknown optional transitive attributes advertised with the Partial bit set; unknown non-transitive attributes not advertised | ✅ |
| §9.2 | Hold timer reset on any received message (not only KEEPALIVE) | ✅ |
Capability and Session Extensions
RFC 6793 — BGP Support for Four-Octet Autonomous System (AS) Number Space
https://datatracker.ietf.org/doc/html/rfc6793
| Feature | Status |
|---|---|
AS_TRANS (23456) sentinel |
✅ |
FourByteAsn capability advertisement and parsing |
✅ |
4-byte AS_PATH segment encoding/decoding via ParserContext |
✅ |
| 4-byte ASN negotiation in FSM | ✅ |
| AS4_PATH from a two-octet peer merged into AS_PATH on receipt (§4.2.3); one longer than AS_PATH ignored | ✅ |
RFC 9774 — Deprecation of AS_SET and AS_CONFED_SET in BGP
https://datatracker.ietf.org/doc/html/rfc9774
| Feature | Status |
|---|---|
Routes with an AS_SET in the AS path rejected on import (configurable with accept_as_sets) |
✅ |
| AS_SET never sent | ✅ |
RFC 9072 — Extended Optional Parameters Length for BGP OPEN Message
https://datatracker.ietf.org/doc/html/rfc9072
| Feature | Status |
|---|---|
| Parsing extended-length OPEN (0xFF sentinel) | ✅ |
| Serialising extended-length OPEN when options exceed 255 bytes | ✅ |
RFC 2918 — Route Refresh Capability for BGP-4
https://datatracker.ietf.org/doc/html/rfc2918
| Feature | Status |
|---|---|
RouteRefresh capability advertisement |
✅ |
ROUTE-REFRESH message type (5) framing |
✅ |
| AFI/SAFI payload parsing | ✅ |
| Received ROUTE-REFRESH processed by readvertising all routes for the session, for all AFI/SAFIs | ✅ |
RFC 7313 — Enhanced Route Refresh Capability for BGP-4
https://datatracker.ietf.org/doc/html/rfc7313
| Feature | Status |
|---|---|
EnhancedRouteRefresh capability wire format |
🟡 |
RFC 4724 — Graceful Restart Mechanism for BGP
https://datatracker.ietf.org/doc/html/rfc4724
| Feature | Status |
|---|---|
GracefulRestart capability (parse, serialise) |
✅ |
| Receiving speaker: routes of a restarting neighbor retained as stale, and removed at its End-of-RIB or after the stale timer | ✅ |
| Restarting speaker: forwarding state preserved in the kernel over a restart (SIGUSR1); R and F bits | ✅ |
| End-of-RIB marker sent and received | ✅ |
| Route selection deferred until neighbors' End-of-RIB (for the removal of kept kernel routes and End-of-RIB markers for learned routes) | ✅ |
RFC 4456 — BGP Route Reflection
https://datatracker.ietf.org/doc/html/rfc4456
| Feature | Status |
|---|---|
| Route reflector: routes from clients to all IBGP neighbors, from other IBGP neighbors to clients | ✅ |
| ORIGINATOR_ID and CLUSTER_LIST added on reflection, not sent to EBGP neighbors | ✅ |
| Routes with the local router ID as ORIGINATOR_ID, or the local cluster ID in CLUSTER_LIST, rejected | ✅ |
| Configurable cluster ID | ✅ |
| Next hop unchanged on reflection | ❌ The route reflector sets itself as the next hop |
| ORIGINATOR_ID and CLUSTER_LIST length as best path tie breakers (§9) | ❌ |
RFC 8538 — Notification Message Support for BGP Graceful Restart
https://datatracker.ietf.org/doc/html/rfc8538
| Feature | Status |
|---|---|
| N bit advertised and negotiated | ✅ |
| Routes retained after a NOTIFICATION other than Hard Reset, and after hold timer expiry | ✅ |
| Hard Reset sent for errors and for a stop, with the original NOTIFICATION as its data | ✅ |
RFC 9494 — Long-Lived Graceful Restart for BGP
https://datatracker.ietf.org/doc/html/rfc9494
| Feature | Status |
|---|---|
LongLivedGracefulRestart capability wire format |
🟡 |
RFC 8654 — Extended Message Support for BGP
https://datatracker.ietf.org/doc/html/rfc8654
| Feature | Status |
|---|---|
ExtendedMessage capability wire format |
🟡 |
Raising BGP_MAX_MSG_LEN to 65535 when negotiated |
❌ |
Multiprotocol and NLRI
RFC 2858 — Multiprotocol Extensions for BGP-4
https://datatracker.ietf.org/doc/html/rfc2858
| Feature | Status |
|---|---|
MultiProtocol capability advertisement (IPv4 and IPv6 unicast) |
✅ |
MP_REACH_NLRI path attribute (parse, serialise) |
✅ |
MP_UNREACH_NLRI path attribute (parse, serialise) |
✅ |
| IPv4 and IPv6 next-hop encoding | ✅ |
RFC 8950 — Advertising IPv4 Network Layer Reachability Information (NLRI) with an IPv6 Next Hop
https://datatracker.ietf.org/doc/html/rfc8950
| Feature | Status |
|---|---|
ExtendedNextHop capability offered on sessions over IPv6 that carry IPv4 unicast, and used if the peer offers it |
✅ |
| IPv4 unicast routes advertised and withdrawn in MP_REACH_NLRI / MP_UNREACH_NLRI with the local IPv6 address as next hop | ✅ |
| IPv4 unicast routes received with an IPv6 next hop (global, or global and link-local) | ✅ |
| Such routes installed in the kernel (IPv4 route by way of an IPv6 neighbor) | ✅ |
| Other families than IPv4 unicast (VPN-IPv4, labelled) | ❌ |
Sessions between link-local addresses (fe80::1%eth0), with link-local next hops |
✅ |
Path Attributes and Communities
RFC 1997 — BGP Communities Attribute
https://datatracker.ietf.org/doc/html/rfc1997
| Feature | Status |
|---|---|
COMMUNITIES path attribute (parse, serialise) |
✅ |
| Attach to locally originated routes | ✅ |
| NO_EXPORT, NO_EXPORT_SUBCONFED, and NO_ADVERTISE observed when learned routes are advertised | ✅ |
| Communities added and removed by import and export policy | ✅ |
RFC 4360 — BGP Extended Communities Attribute
https://datatracker.ietf.org/doc/html/rfc4360
| Feature | Status |
|---|---|
EXTENDED_COMMUNITIES path attribute (parse, serialise) |
✅ |
| AS-specific, IPv4-address-specific, opaque, route-target, route-origin subtypes | ✅ |
RFC 8092 — BGP Large Communities Attribute
https://datatracker.ietf.org/doc/html/rfc8092
| Feature | Status |
|---|---|
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 by default (blackhole request) |
✅ |
Blackhole routes for single addresses accepted with accept_blackholes (§3.2: prefix length limits relaxed, next hop not checked) |
✅ |
| Blackhole routing: a kernel blackhole route discards traffic for the prefix | ✅ |
| Blackhole routes advertised with the community, for providers to honor (§3.3) | ✅ |
| A blackhole route for a prefix this router originates | ❌ (add a kernel blackhole route by hand) |
Other Capabilities (Wire Format Only)
The following capabilities are parsed and serialised correctly but have no functional behaviour implemented beyond that.
| RFC | Capability | Status |
|---|---|---|
| RFC 5291 | Outbound Route Filtering (ORF) | 🟡 |
| RFC 8205 | BGPsec | 🟡 |
Error Handling
RFC 9687 — BGP Send Hold Timer
https://datatracker.ietf.org/doc/html/rfc9687
| Feature | Status |
|---|---|
SendHoldTimer error code (8) defined |
✅ |
| Send hold timer enforcement (a write that makes no progress ends the session) | ✅ |
Route Security
RFC 6811 — BGP Prefix Origin Validation
https://datatracker.ietf.org/doc/html/rfc6811
| Feature | Status |
|---|---|
| Validation states (valid, invalid, not found) for routes from external peers | ✅ |
Invalid routes rejected, per neighbor (configurable with accept_rpki_invalid) |
✅ |
| Routes revalidated when the VRPs change, in both directions | ✅ |
| Validation of routes from internal peers and of originated routes | ❌ |
| Validity as a step of route selection (RFC 8097 communities) | ❌ |
draft-ietf-sidrops-aspa-verification — BGP AS_PATH Verification Based on ASPA
https://datatracker.ietf.org/doc/draft-ietf-sidrops-aspa-verification/
Implemented from version 24 of the draft.
| Feature | Status |
|---|---|
| Upstream verification (routes from customers, peers, route servers and route server clients) | ✅ |
| Downstream verification (routes from providers) | ✅ |
Per-peer role (role); paths of peers without one are not verified |
✅ |
Invalid paths rejected, per neighbor (configurable with accept_aspa_invalid) |
✅ |
| Routes revalidated when the ASPAs change, in both directions | ✅ |
| Paths with an AS_SET invalid | ✅ |
| Verification on export | ❌ (the AS paths of advertised routes are not verified) |
RFC 7947 — Internet Exchange BGP Route Server
https://datatracker.ietf.org/doc/html/rfc7947
| Feature | Status |
|---|---|
§2.2.1 / §2.2.2: to a ROUTE_SERVER_CLIENT the path is not prepended and the next hop and MED are left as they came |
✅ |
§2.2.2.2 / §4.6: communities with which a client restricts the advertisement of its routes to other clients (control_communities) |
✅ |
| Per-client best path selection (a different best route for each client) | ❌ (every client receives the same best path) |
RFC 9234 — Route Leak Prevention and Detection Using Roles in UPDATE and OPEN Messages
https://datatracker.ietf.org/doc/html/rfc9234
| Feature | Status |
|---|---|
BGP Role capability sent for peers with a configured role |
✅ |
| Role Mismatch (OPEN Message Error, subcode 11) when the neighbor's role does not correspond to the local role, or the neighbor advertises conflicting roles | ✅ |
Strict mode (require_role) |
✅ |
| Only to Customer attribute: parse, serialise, treat-as-withdraw when malformed | ✅ |
| Ingress: routes with OTC rejected from customers, route server clients, and (unless the OTC value is the peer's AS) peers | ✅ |
| Ingress: routes from providers, peers and route servers marked | ✅ |
| Egress: originated routes to customers, peers and route server clients marked | ✅ |
| Egress: marked routes not sent to providers, peers or route servers | ✅ |
RFC 8210 — The RPKI to Router Protocol, Version 1 (RFC 6810, version 0; draft-ietf-sidrops-8210bis, version 2)
https://datatracker.ietf.org/doc/html/rfc8210
Version 2 is implemented from version 23 of the draft.
| Feature | Status |
|---|---|
| Reset and serial queries, notifies, cache reset, incremental updates | ✅ |
| Refresh, retry and expire intervals; data dropped when it expires | ✅ |
| Version 2, with fallback to 1 and 0; several caches with failover | ✅ |
| ASPA PDU (version 2) | ✅ |
| Error Reports sent to the cache | ✅ |
| Version 2's ordering of PDUs enforced on what a cache sends | ❌ (PDUs are accepted in any order) |
| Transport over plain TCP | ✅ |
| Transport over SSH, TLS, TCP-MD5 or TCP-AO | ❌ |
| Router keys (BGPsec) | 🟡 read and ignored |
RFC 7911 — Advertisement of Multiple Paths in BGP (ADD-PATH)
https://datatracker.ietf.org/doc/html/rfc7911
| Feature | Status |
|---|---|
| Capability negotiation per family and direction | ✅ |
| Receiving several routes for a prefix | ✅ |
| Sending several routes for a prefix | ❌ (path identifiers are sent; one route each) |
RFC 4271 §9.1.2 / RFC 4486 / operational practice — import policy
| Feature | Status |
|---|---|
| Routes with the local AS in the AS path rejected (loop detection) | ✅ |
| Bogon prefixes and AS numbers, prefix length bounds, first-AS check | ✅ |
| Per-peer prefix and origin AS allow-lists | ✅ |
| Maximum prefixes with Cease / Maximum Number of Prefixes Reached and hold-down | ✅ |