ferrix/docs/content/docs/reference/rfcs.md at 4e945b278fe024d2f33df6728277e9a35551b35b

0 Fork 0

Files

T

Rayhaan JaufeerallyandClaude Opus 5.5 65f136048e Graceful restart (RFC 4724, RFC 8538)

A peer that restarts keeps its routes with us, and we keep ours with our
peers while we restart, so that a restart withdraws nothing across the
network and the machine goes on forwarding. On by default for every
peer; `graceful_restart` sets the restart time we give, caps how long a
peer's routes are kept, or turns it off.

When a peer restarts: its routes are marked stale in the routing table,
and chosen as before, for at most its restart time. When it is back, what
it sends again is fresh, and the stale routes of a family go at its
End-of-RIB marker, or after the cap; at once for a family whose
forwarding it did not keep. Only a connection that failed counts as a
restart, and, with RFC 8538 agreed, an expired hold timer or a
NOTIFICATION other than a Hard Reset. The stale mark is a bit of the
route's word that selection never looks at.

When we restart: SIGUSR1 leaves the kernel's routes where they are,
closes the sessions without a word where graceful restart is agreed, and
exits with status 75, on which the systemd unit starts us again. The next
start finds the routes in the kernel, says so in its OPENs (R, and F where
forwarding was kept), and has them go once every peer has sent its
End-of-RIB. Our own End-of-RIB markers for learned routes wait for that
too. SIGTERM still stops for good, now with a Hard Reset where RFC 8538 is
agreed, as are errors of ours.

The status page and API show what was agreed with each peer, the routes
kept while a peer restarts, and which routes are stale. Tested against
FRR and BIRD in a new phase of the interoperability lab, and with routes
kept in a real kernel over a restart.

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

2026-10-04 22:43:47 +02:00

13 KiB

Raw Blame History

+++ 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), where the next hop is directly connected	✅
§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	❌ (only next hops that are neighbors count as reachable)
§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 (no route reflection)	✅
§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 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 (`blackhole request`)	✅
Blackhole routing: discarding traffic for prefixes with BLACKHOLE	❌

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	✅

13 KiB Raw Blame History