BGP path-attribute registry audit

This is an offline audit baseline, not a claim that every registered attribute is implemented. It keeps registry data, protocol requirements, observed behavior, and executable evidence distinct so a registry update cannot silently become a codec claim.

Provenance and refresh

• Registry: IANA BGP Path Attributes
• CSV: https://www.iana.org/assignments/bgp-parameters/bgp-parameters-2.csv
• Registry snapshot: 2026-09-22 (live-verified 2026-09-22)
• SHA-256: b04771e1948af2e2682bae76ecff9b957c7c4ccc93e32b31efcec086281005a0
• Normative anchors: RFC 4271 §§4.3, 5, RFC 7606 §§2, 3, 5.2, 7.1-7.10, 7.16, RFC 9012 §§2, 11, 13, RFC 6368 §5, RFC 9234 §5, RFC 7311, RFC 9552, and RFC 8669 §3.

Manual live comparison (never run by normal CI): download the CSV with curl -fsSL https://www.iana.org/assignments/bgp-parameters/bgp-parameters-2.csv -o /tmp/bgp-parameters-2.csv, run sha256sum /tmp/bgp-parameters-2.csv, then compare its Value and Code columns with the census below, expanding every range. A digest change requires human review before changing either the census or an observed-behavior claim.

Complete IANA census

pending follow-up audit means this tranche makes no normative or implementation claim for that row. The offline test expands the ranges and requires every octet from 0 through 255 to appear exactly once with no blank cell.

D-PATH boundary

The project treats D-PATH as an opaque optional-transitive attribute, with bounded framing validation. This is a deliberate boundary: recognizing its wire format does not enable RFC 10039 gateway procedures, domain-loop detection, or D-PATH route selection. Valid D-PATH is retained on unicast, VPNv4/VPNv6 and EVPN routes; it is re-advertised with Partial set and does not affect best-path selection. Malformed framing retains the existing RFC 7606 error handling.

RFC 10039 §§4 and 11 require supporting speakers to treat D-PATH on other families as withdrawn; §11 also describes propagation by non-supporting speakers. The project follows the latter boundary rather than claiming D-PATH semantic support from framing checks alone. domain_path_remains_opaque_on_ipv4_unicast exercises decode and validation; domain_path_remains_opaque_on_vpn_and_evpn_routes checks transport retention. The existing assigned_opaque_attributes_reach_rib_while_edge_metadata_is_absent test also verifies unicast re-advertisement bytes and Partial.

NHC boundary

NHC (39) has unsupported payload semantics. rustbgpd validates its next-hop and characteristic-TLV framing, retains a valid payload, and re-advertises it with Partial set. Import and export next-hop rewrites leave that opaque payload unchanged; rustbgpd does not construct characteristics, compare the encoded next hop with the route's next hop, or rebuild the NHC header.

draft-ietf-idr-nhc-07 §1.2 limits requirements for supporting speakers to implementations that support and enable the specification. §2.2 explicitly describes unsupported speakers propagating opaque NHC without updating it. A supporting receiver applies the encoded-next-hop comparison in §2.3 before using it. Framing validation is not NHC semantic support. This is an Internet-Draft, not a published RFC. The existing assigned_opaque_attributes_reach_rib_while_edge_metadata_is_absent test checks NHC payload retention and Partial on unicast re-advertisement.

Encapsulation boundary

Tunnel Encapsulation (23) remains framing-validated opaque transit. rustbgpd does not interpret its tunnel endpoints or select tunnels from its TLVs. RFC 9012 §11 describes transit through speakers that do not recognize it and requires default eBGP ingress and egress filtering by speakers that understand it.

The Encapsulation Extended Community (type 0x03, subtype 0x0c, carried in attribute 16) is different: rustbgpd originates VXLAN values and interprets received tunnel types for local EVPN eligibility. It retains this transitive community across eBGP without default ingress or egress filtering. That is an explicit compatibility exception for the current alpha EVPN profile, whose deployment boundary is an operator-controlled administrative domain. rustbgpd does not enforce that boundary with a default filter or provide a dedicated same-domain permission control, and does not claim RFC 9012 §11 conformance for the community. RFC 8365 §5.1.3 requires encapsulation signaling for EVPN overlays; it does not exempt the community from RFC 9012's filtering obligation. See the RFC notes for the compatibility implications.

Executable RFC 7606 core matrix

Hex values are attribute payloads; the test builds the header. empty means a zero-length payload. Each valid row must decode to one typed attribute and re-encode byte-for-byte. A changed Optional/Transitive flag pair must be treat-as-withdraw. The malformed payload must produce the exact neighbor-class disposition shown.

M100 released-receiver Partial-flag differential

M100 freezes one version-scoped receiver observation across rustbgpd 0.67.0, BIRD 2.19.2, OpenBGPD 9.2, and FRR 10.3.1. Each cell receives the exact attribute bytes shown below with flags 0xa0; a separate observer session reconstructs candidate and survivor state. This is a proof-only comparison of the named releases, not a change to rustbgpd policy, configuration, defaults, or the current-main core-behavior matrix above.

accepted means the source session stays in the same epoch and both candidate and survivor remain visible through the observer; MED is additionally pinned at 100. The two same-session withdrawal labels both mean the candidate disappears, the survivor remains, and no notification, close, or re-establishment occurs. reset requires one ordered UPDATE 3/4 notification carrying the exact attribute bytes, one close, and one re-establishment at the next source epoch; both routes are absent across that boundary. The hosted job also rejects altered flags, inverted expected outcomes, malformed command output, incomplete UPDATE attribute bounds, missing route reconstruction, and duplicate or missing rows.

Current-main receiver policy after M100

The rustbgpd 0.67.0 column of M100 remains a version-scoped observation and is not updated. M100 also runs a rustbgpd_current receiver built from the tree, which receives the same bytes and must produce the eBGP column below. Current main enforces the RFC 4271 requirement that Partial be clear on every recognized optional non-transitive attribute. The receiver action follows the existing per-attribute RFC 7606 disposition instead of adding a compatibility mode:

Attribute-discard preserves the routes in the UPDATE after removing the offending attribute. Treat-as-withdraw removes those routes while keeping the session Established. Each recoverable violation uses the existing warning, bgp_update_malformed_total{peer,disposition}, and the cause series bgp_update_malformed_causes_total{peer,type_code,reason,disposition}; there is no per-neighbor configuration knob.

Assigned class fence

This matrix audits only the registered Optional/Transitive class; bounded payload framing is documented separately below. It does not claim semantic validation, policy support, or feature negotiation. "Wrong O" toggles Optional, "wrong T" toggles Transitive, and "both" toggles both bits from the canonical class.

IPv6 Address Specific Extended Community length matrix

The type-25 payload remains opaque: only the RFC 5701/RFC 7606 cardinality boundary is enforced, and unrecognized community types or sub-types are not errors.

Community Container framing matrix

Type 34 remains an unsupported opaque attribute under a temporary live IANA assignment and a work-in-progress draft. The checks below validate only bounded framing; they do not expose a typed model or claim stable standards support.

Assigned framing matrix (23, 36-42, 128)

These checks are syntax-only. They do not implement route-family applicability, stateful lookup, policy, or attribute semantics. Unknown types and their values remain opaque.

SRv6 Service framing within Prefix-SID

RFC 9252 §§3, 7 adds a stronger disposition for recognized L3 Service (5) and L2 Service (6) TLVs. Each requires its reserved octet and an exactly framed sub-TLV stream. SID Information sub-TLV 1 requires its 21-octet fixed body and an exactly framed sub-sub-TLV stream; SID Structure sub-sub-TLV 1 has exactly six value octets. Truncated headers, enclosing-length overruns, and these known-length failures are treat-as-withdraw. Strict decoding returns DecodeError::MalformedSrv6ServiceTlv; its notification mapping is Attribute Length Error with the received attribute bytes.

Only the first Service TLV of each kind is inspected internally. Later same-kind TLVs remain in the opaque value, with their contents ignored as required by §7. Their outer framing must still allow traversal; an identifiable Service TLV with an outer overrun takes the stronger disposition. A safely framed generic Label-Index/SRGB length error cannot hide a later recognized Service error. Duplicate Prefix-SID attributes keep the existing first-attribute rule.

The wire framing checks preserve unknown types, reserved values, endpoint behaviors, SIDs, and transposition fields. Selection applies the separate service eligibility rules below. Eligible values retain their bytes through VPNv4/VPNv6 and EVPN receive/export. No-reachable-NLRI or unparseable-NLRI cases retain the existing session-reset escalation; snapshot readers reject and fuse on the stronger error instead of admitting the entry without its Prefix-SID attribute.

SRv6 service eligibility

RFC 9252 §7 separates malformed framing from semantically invalid SIDs. A route with an applicable Service TLV needs at least one valid SID Information entry in the first L3 or first L2 Service TLV, according to its service encoding. Invalid candidates stay in Adj-RIB-In with their raw attributes, but are excluded before best-path selection, Add-Path, ORR, and ECMP. An invalid-only replacement withdraws the selected advertisement without treating the received UPDATE as withdrawn. Unicast and EVPN explain report srv6_sid_invalid.

The checks bound SID Structure component sums to 128 bits, require the transposition range to fit the applicable Function or Argument component and label field, require the transposed SID bits to be zero, and require zero offset when transposition length is zero. The sum may equal offset plus length (verified erratum 7817). Global IPv4/IPv6 unicast uses L3 service without transposition; VPNv4/VPNv6 allows up to 20 Function bits. Most EVPN encodings use an applicable 24-bit label field: EAD-per-ES uses the ESI Label extended community and Argument bits; EAD-per-EVI and MAC-only use L2 Function bits; MAC+IP can use L2 or L3 service, with L3 transposition requiring its second label; IP Prefix routes use L3 Function bits. IMET uses 24 Function bits from an ingress-replication (0x06) PMSI label or the high-order 20 Function bits from an SRv6 P2MP (0x0d) PMSI label, as specified by RFC 10018 §4.1.1.1.2. Missing or other PMSI tunnel types cannot supply a transposed IMET Function. EVPN Type 4 and families outside these encodings keep their existing selection behavior.

An unknown endpoint behavior with no arguments remains eligible. Nonzero Argument Length requires an understood argument-capable behavior: End.DT2M (24) or one of its SID-list-compression flavors, End.DT2M with NEXT-CSID (68) and End.DT2M with REPLACE-CSID (124). Each of the three requires SID Structure, including the zero-SID EAD encoding specified by RFC 9819 §3. Reserved bits, unknown extensions, unused SID tail bits, and later duplicate Service TLVs remain preserved. These checks do not implement PE import, service origination, SID reconstruction, next-hop rewriting, or SRv6 forwarding.

These eligibility checks are per-route. RFC 9819 §3.2 assigns consistent Argument Length (AL) signaling to the egress PE; §3.3 assigns cross-route processing to the ingress PE constructing the service SID. When both AL values are nonzero and differ, the ingress PE must suppress BUM forwarding for the affected routes from that Ethernet Segment. That forwarding rule does not prescribe reflector best-path exclusion or withdrawal of either route.

rustbgpd retains the per-route eligibility checks above and does not automatically exclude IMET/EAD-per-ES pairs for an AL mismatch. Caller-selected pair inspection can report that conflict without changing eligibility. This read-only result is conditional on the caller selecting the applicable pair; it does not establish original egress identity or forwarding readiness.

PMSI tunnel-type matrix

PMSI Tunnel values use RFC 6514 base type and identifier semantics, the RFC 7385/IANA registry boundary, and RFC 8317 composite tunnel-type semantics. The accepted 0x0a-0x0d assignments come from RFC 9574 §11 (0x0a, Assisted Replication), RFC 8556 §5 (0x0b, BIER), and RFC 10018 §5 (0x0c, SR-MPLS P2MP Tree; 0x0d, SRv6 P2MP Tree). Assigned types without a dedicated enum variant and experimental values remain typed through opaque PmsiTunnelType::Other state; this is distinct from accepting an unassigned value. Preserving these encodings does not implement their tunnel procedures or forwarding. Local EVPN origination uses ingress replication (0x06).

For a valid RFC 8317 composite, decoding checks only the generic 3-octet receiver-label prefix framing; it does not interpret the underlying transmit identifier semantics.

The enriched fence tests separately prove all six rows' outcomes, BGP-LS opaque behavior, typed PMSI behavior and wrong-class handling, and unchanged synthetic unassigned handling. Everything outside this executable slice remains explicitly pending follow-up audit.