ferrix/docs/content/docs/reference/rfcs.md at 724bb99f1160f9bed4b774141a6e08967202a718

0 Fork 0

Files

T

Rayhaan JaufeerallyandClaude Opus 5.5 b16227c51f Route reflection, with ourselves as next hop

A route learned from one router of our AS went to no other (RFC 4271
§9.2.1), so every router needed a session with every other. A router at
the end of a single link, with one session to its neighbour inside the AS,
heard only of what that neighbour learned itself, and nothing of what the
neighbour had from the routers behind it.

A peer in our own AS can now be made a route reflector client
(`route_reflector_client`, RFC 4456). What a client sends goes to all our
routers; what the others send goes to the clients. A reflected route gets
ORIGINATOR_ID (where it started, if it does not say) and our cluster ID at
the front of CLUSTER_LIST; it is not sent back to the router it started
at, nor round to a cluster it has been through, and one that comes back
anyway is refused as "route reflected back to us". The cluster ID is the
router ID unless `cluster_id` says otherwise. The two attributes are now
decoded as such rather than kept as bytes, and are never sent to other
networks.

Unlike a standard reflector, this one is the next hop of what it reflects,
as it is of everything it announces: there is no resolving a next hop
that is not a neighbour, so a client reaches what lies behind another
router through the reflector.

Only peers in our own AS can be clients; the configuration refuses the
setting for any other. Nothing changes in what other networks are told:
Only to Customer marks go along with reflected routes, and every
receiving session keeps its own max_prefixes.

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

2026-10-05 18:10:35 +02:00

14 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, 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 is the next hop: next hops that are not directly connected are not resolved
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 (`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	✅

14 KiB Raw Blame History