rayhaan/ferrix
0
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
910dd258fbf2f476ae4e7a4ea93c085b66cef879
ferrix/docs/content/docs/reference/rfcs.md
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

317 lines
14 KiB
Markdown
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 | ✅ |
Reference in new issue View Git Blame Copy Permalink