Rayhaan JaufeerallyandClaude Fable 5.1
bdaf226a16
With rpki { caches { ... } } in the configuration the server keeps the
validated ROA payloads of a validator and validates every route from a
peer outside its own AS (RFC 6811). An invalid route is refused, unless
its peer has accept_rpki_invalid. Valid and not-found routes are taken;
validity does not otherwise enter route selection.
Validity is not settled when a route arrives: the data changes every few
minutes. The routes follow, without the peer sending anything again.
- A route refused as invalid is held by its session, out of the table.
When the data changes the session looks at what it holds, and what is
no longer invalid goes into the table. A held route is the peer's to
withdraw or replace like any other.
- A route in the table that becomes invalid is found by a task that
looks through the table when the data changes, at the prefixes the
changed VRPs cover, and is taken out and held by its session.
- If the data expires because no cache confirms it, nothing is invalid
any more and everything held is taken.
- A session holds at most 200,000 routes; past that it asks the peer for
a route refresh when the data changes.
So that the table can be looked through without parsing attributes, an
attribute set's key now has the route's origin AS. Memory per route is
unchanged at 52 bytes on the real table.
Shown: /api/rpki and a section of the status page with the cache, its
state and the age of the data; each route's validity; each peer's count
of held routes. Refusals are recorded under "RPKI invalid". Metrics:
bgp_rpki_vrps and bgp_rpki_updates_total.
Also: Negotiated says whether the peer supports route refresh, and
docs/RFCs.md is brought up to date.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
7.5 KiB
7.5 KiB
RFCs
Tracks which RFCs are implemented, partially implemented, or only represented in the wire format layer.
Legend
- ✅ Implemented — functional end-to-end
- 🟡 Wire format only — parsed and serialised correctly, but not yet acted on
- ❌ Not implemented
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 (peer using our identifier, or 0.0.0.0) | ✅ |
| §9 | Decision process / best-path selection | ❌ |
| §9 | Adj-RIB-In (per-peer table of received routes) | ✅ |
| §9 | Locally originated routes, advertised to all established peers | ✅ |
| §9 | Loc-RIB / Adj-RIB-Out for routes learned from peers (re-advertisement) | ❌ |
| §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 | ✅ |
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 | ❌ |
| Acting on received ROUTE-REFRESH (re-advertising all local routes, regardless of the AFI/SAFI asked for) | ✅ |
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 wire format |
🟡 |
| Restart state and forwarding preserved across sessions | ❌ |
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 wire format |
🟡 |
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 | ✅ |
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 | ✅ |
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 refused, per peer (accept_rpki_invalid to take them) |
✅ |
| 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) | ❌ |
RFC 8210 — The RPKI to Router Protocol, Version 1 (and RFC 6810, version 0)
https://datatracker.ietf.org/doc/html/rfc8210
| Feature | Status |
|---|---|
| Reset and serial queries, notifies, cache reset, incremental updates | ✅ |
| Refresh, retry and expire intervals; data dropped when it expires | ✅ |
| Fallback to version 0; several caches with failover | ✅ |
| 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 |
|---|---|
| Own AS in path refused (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 | ✅ |