RFC 8955 - Dissemination of Flow Specification Rules

Overview

Positive

what Ze has

Neutral

measures that are neither good news nor bad

The 8 shares marked as a part above are the whole of the 29 gated MUSTs: they add to 100%. Proven by a recorded break is a share of TAGGED UNITS, a different population, so it is not one of them.

At a glance

Enrolment

Enrolled: Dissemination of Flow Specification Rules

What the public ledger says

Status: Partial

Coverage

Positive and negative tests (21): RFC8955-4-3, RFC8955-4-4, RFC8955-4.2-1, RFC8955-4.2-2, RFC8955-4.2.1.1-2, RFC8955-4.2.1.1-3, RFC8955-4.2.1.2-1, RFC8955-4.2.2.12-2, RFC8955-6-1, RFC8955-6-3, RFC8955-7.1-1, RFC8955-7.1-2, RFC8955-7.3-1, RFC8955-7.5-1, RFC8955-5.1-1, RFC8955-5.1-2, RFC8955-8-1, RFC8955-8-2, RFC8955-3-1, RFC8955-6-5, RFC8955-7.3-2

Annotated (including scoped evidence) (8): RFC8955-4-1, RFC8955-4-2, RFC8955-4.2.1.1-1, RFC8955-4.2.2.9-1, RFC8955-4.2.2.11-1, RFC8955-4.2.2.12-1, RFC8955-12-1, RFC8955-12-2

Requirements

Gaps and untested MUSTs

Proof state

A tagged unit reads unproven where no discrimination record exists for it: nothing in this tree has been observed to break it, so the claim its tag makes is unproven.

RFC8955-4-1

Implementations wishing to exchange Flow Specification MUST use BGP's Capability Advertisement facility to exchange the Multiprotocol Extension Capability Code (Code 1) (§4)

Audit verdict: not audited: no reader has judged these tests

RFC8955-4-2

The (AFI, SAFI) pair carried in the Multiprotocol Extension Capability MUST be (AFI=1, SAFI=133) for IPv4 Flow Specification and (AFI=1, SAFI=134) for VPNv4 Flow Specification (§4)

Audit verdict: not audited: no reader has judged these tests

RFC8955-4-3

Length of the Next-Hop Network Address MUST be set to 0 (§4)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Independent source judgment of every current tagged carrier against RFC 8955 Section 4 in its full dissemination context: 'When advertising Flow Specifications, the Length of the Next-Hop Network Address MUST be set to 0.' Agree with the saved flow-vpn-final-rfc8955.pending.json for this advertisement clause only, not the distinct ignored-receipt requirement RFC8955-4-4. TestFlowSpecOriginationOmitsConfiguredNextHop drives actual config initial sync, established API batch and both queued drains to a TCP recipient; literal complete UPDATEs pin zero length, exact native NLRI, VPN RD and traffic-rate action for all four AFI 1/2 SAFI 133/134 families with absent, explicit IPv4 and explicit IPv6 configured addresses. Empty-address controls and required packet equality rule out suppression as a passing implementation. TestFlowSpecForwardingOmitsNextHop covers cached forwarding across unchanged/self/explicit-v4/explicit-v6 destination settings and empty/recipient-address/IPv6 received fields, requiring exactly one delivered rule and exact MP_REACH bytes plus action, with no legacy NLRI or MP_UNREACH. TestFlowSpecRouteServerOmitsNextHop uses negotiated TCP, registered daemon RIB and route-server ownership, real covering-route authorization and exact received native rule/RD/action for the same four families, rather than a supplied authorization callback. The mixed-UPDATE carrier additionally requires both output sections, preserves observer bytes, and retains the independent legacy NEXT_HOP announcement or peer-own-address withdrawal gate. The dedicated builder carrier pins zero length and unchanged NLRI; the full daemon flow-encode.ci frames supplement the four-family unit matrix (that fixture itself advertises only three families). These are meaningful advertised-byte assertions, not decoder-only or bare-count evidence. Read producers Family.NeedsNextHop, buildMPReachPlugin, buildBatchAnnounceUpdate, buildRIBRouteUpdate, payloadNextHop, applyNextHopFamily and mpReachNextHopHandler plus normalization placement on both forwarding rails. Origination omits the address by family; received FlowSpec addresses cannot become a forwarding gate; normalization clears MP rewrite operations or requests removal of a received nonempty field while retaining genuine legacy operations; the handler retains NLRI and emits length zero. The saved proposal's causal argument remains supported by current source. This does not certify every FlowSpec requirement, external FRR/GoBGP interoperability, or every future rail. Existing approved native observations are not rerun or newly claimed; stored producer-panic records establish only the breaks they name, and are not substituted for these semantic assertions. No build, test, mutation, stamp or freshness check was run. The row currently has no audit entry: first stamp, without mode rejudge or upgrade_reason.

RFC8955-4-4

Network Address of the Next-Hop field MUST be ignored (§4)

Audit verdict: not audited: no reader has judged these tests

RFC8955-4.2-1

Components MUST follow strict type ordering by increasing numerical order (§4.2)

Audit verdict: not audited: no reader has judged these tests

RFC8955-4.2-2

If present, it MUST precede any component of higher numeric type value. (§4.2)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged 2026-10-16 after the codec moved to internal/core/bgp/nlri/flowspec; units changed only by package qualification. RFC 8955 Section 4.2: "If present, it MUST precede any component of higher numeric type value." Positive re-parses an out-of-order build and pins the exact emitted order 1,3,5,12 (core writeComponentsSorted); negative feeds 5-then-3 and requires ErrFlowSpecTypeOrder from core parseComponents, with the same components ascending accepted, so the refusal is isolated to order.

RFC8955-4.2.1.1-1

In the first operator octet of a sequence, it MUST be encoded as unset (§4.2.1.1)

Audit verdict: enforced (the tests do what the requirement demands), fresh. single-polarity positive: a config range '>8080&<8088' encodes two ops and the test asserts the first carries AND clear (0x40) while the second carries it set, so an encoder setting AND on the first operator goes red

RFC8955-4.2.1.1-2

In the first operator octet of a sequence, it MUST be encoded as unset and MUST be treated as always unset on decoding. (§4.2.1.1)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Independent rejudge 2026-10-17, upgraded from weak because a new tagged unit closes the encode clause. RFC 8955 Section 4.2.1.1: "In the first operator octet of a sequence, it MUST be encoded as unset and MUST be treated as always unset on decoding." Decode: TestRFC8955FirstOperatorAndBitTreatedUnsetOnDecode (both tags) requires identical [[=80],[=22]] JSON with the leading AND bit clear and set. Encode: TestRFC8955TextLeadingAndEncodedUnset drives EncodeFlowSpecComponents, the live text encoder behind the registered InProcessNLRIEncoder (register.go) and OnEncodeNLRI; parseBitmaskValue sets FlowMatch.And from the '&' prefix and NewFlowTCPFlagsMatchComponent stores it unmodified, so "&syn" reaches core numericComponent.writeToAFI as a first match with And set, and only the `i > 0 && m.And` guard keeps 0x40 off. The exact 03 09 80 02 assertion goes red (0xc0) if the guard is reduced to `m.And`; the contrast case (syn &ack -> 00 02 c0 10) shows the encoder does set AND at i>0, so the assertion is about position. writeToAFI is shared by FlowSpec.WriteTo (types.go) for config-built rules too. The recorded break (whole writeToAFI panics) proves reach only; the guard-specific red is established by reading.

RFC8955-4.2.1.1-3

0: MUST be set to 0 on NLRI encoding and MUST be ignored during decoding (§4.2.1.1)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged 2026-10-16: the unit moved verbatim to core compare_rfc8955_test.go, with only the family identifier renamed. RFC 8955 Section 4.2.1.1: "0: MUST be set to 0 on NLRI encoding and MUST be ignored during decoding". Wire op 0xf9 carries the reserved bit 0x08 and a leading AND. The positive requires the exact decoded []FlowMatch{{Op: FlowOpEqual, Value: 1<<56|7}}, so the reserved bit is ignored by core parseNumericComponent's 0x07 mask. The negative requires re-encoding to the exact op 0xb1, so reserved and leading AND are cleared by writeToAFI, and a missing end-of-list bit is refused.

RFC8955-4.2.1.2-1

0 (all 0 bits): MUST be set to 0 on NLRI encoding and MUST be ignored during decoding (§4.2.1.2)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged again 2026-10-16 after a comment-only edit. The new VALIDATES claim that parseNumericComponent masks 0x0C is TRUE: core types_numeric.go computes compOp = op & 0x03 for FlowTCPFlags and FlowFragment. RFC 8955 Section 4.2.1.2: "0 (all 0 bits): MUST be set to 0 on NLRI encoding and MUST be ignored during" decoding. Encode: assert.Zero(op&0x0C) over every emitted TCP-flags operator (MATCH, NOT, AND+END) goes red if the length, AND, END, NOT or MATCH bits move into 0x0C. The inputs carry no reserved bits, so deleting the 0x03 mask in core writeToAFI alone stays green. That mask is defence in depth: no reachable producer sets 0x0C, because parseBitmaskValue (text) and parseFlowTCPFlagMatches (config) build only NOT/MATCH, and parseNumericComponent masks received ops to 0x03. Decode: op 0x8D must render exactly like 0x81 (=syn) through the plugin JSON path, with the clean render pinned first. The decode proof is at the rendered match, not at the firewall lowering.

RFC8955-4.2.2.9-1

Type 9 component bitmasks MUST be encoded as 1- or 2-octet bitmask (bitmask_op len=00 or len=01). (§4.2.2.9)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged 2026-10-16: the unit changed only in a comment path (core types_numeric.go). RFC 8955 Section 4.2.2.9: "Type 9 component bitmasks MUST be encoded as 1- or 2-octet bitmask (bitmask_op len=00 or len=01)." Single-polarity positive, as annotated: every emitted tcp-flags bitmask from the config producer (buildFlowSpecComponents with AND, NOT and OR terms) must be non-empty and at most 2 octets.

RFC8955-4.2.2.11-1

Type 11 component values MUST be encoded as single octet (numeric_op len=00). (§4.2.2.11)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged 2026-10-16: the unit changed only in a comment path. RFC 8955 Section 4.2.2.11: "Type 11 component values MUST be encoded as single octet (numeric_op len=00)." Single-polarity positive: DSCP 46, 0 and 63 through the config producer each encode as exactly one octet. Core parseNumericComponent also refuses a DSCP valueLen other than 1 on receipt.

RFC8955-4.2.2.12-1

The Type 12 component bitmask MUST be encoded as single octet bitmask (bitmask_op len=00). (§4.2.2.12)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged 2026-10-16: the unit changed only in a comment path. RFC 8955 Section 4.2.2.12: "The Type 12 component bitmask MUST be encoded as single octet bitmask (bitmask_op len=00)." Single-polarity positive: all four fragment flags through the config producer encode as exactly one-octet values. The text producer's numeric fragment operand is bounded to 255 by parseUint8, and core writeToAFI masks fragment values before choosing a width, so no wider bitmask is reachable.

RFC8955-4.2.2.12-2

0: MUST be set to 0 on NLRI encoding and MUST be ignored during decoding (§4.2.2.12)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Independent rejudge 2026-10-17, upgraded from weak because a new tagged unit drives the IPv4 mask. RFC 8955 Section 4.2.2.12, of the four high bits of the fragment bitmask: "0: MUST be set to 0 on NLRI encoding and MUST be ignored during decoding". Decode: TestRFC8955FragmentReservedBitsIgnoredOnDecode requires 0xF2 to render exactly as 0x02. Encode: TestRFC8955TextFragmentIPv4ReservedBitsCleared feeds "fragment 242" and "fragment 255" through EncodeFlowSpecComponents (the live text encoder); parseBitmaskValue/parseUint8 accept 0..255 and NewFlowFragmentMatchComponent stores the value unmodified, so the reserved nibble reaches core writeToAFI, where `m.Value &= fragmentMask(AFIIPv4)` (0x0f) is the only clearing step. The exact octets 0x02 and 0x0f go red (0xf2, 0xff) if that step is removed, and 0x0f also distinguishes the IPv4 mask from the IPv6 0x0e (DF kept). TestFlowSpecFragmentReservedHighNibbleZero stays tagged but alone cannot fail (named constants only); the row no longer depends on it. The recorded break (fragmentMask panics) proves reach; the mask-specific red is established by reading.

RFC8955-6-1

In the absence of explicit configuration, a Flow Specification NLRI MUST be validated such that it is considered feasible if and only if all of the conditions below are true: (§6, updated by RFC 9117 §4.1)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Independent semantic rejudgment: RFC8955 Section 6: "In the absence of explicit configuration, a Flow Specification NLRI MUST be validated such that it is considered feasible if and only if all of the conditions below are true: a) A destination prefix component is embedded in the Flow Specification. b) The originator of the Flow Specification matches the originator of the best-match unicast route for the destination prefix embedded in the Flow Specification (this is the unicast route with the longest possible prefix length covering the destination prefix embedded in the Flow Specification). c) There are no "more-specific" unicast routes, when compared with the flow destination prefix, that have been received from a different neighboring AS than the best-match unicast route, which has been determined in rule b." The existing receive-driven authorization units retain unique IDs, real received attributes and exact eligibility/candidate/selected-event effects. Tests separate longest-covering choice (with RFC9117 amendments), different-AFI/SAFI/RD routes, same-domain foreign-more-specific routes including a losing path, and removal-based reauthorization. Ignoring the losing foreign more-specific now incorrectly authorizes the route and fails the exact forbidden-candidate/install oracle; dropping route-domain comparison fails isolation while the valid matching-domain controls survive. This closes the specifically pending condition-c and route-domain producer counterfactuals without claiming that two faults exhaust all per-clause or dataplane behavior. The preserved broader assertions, not these two mutations alone, support the row. These are inspected scratch semantic executions, not canonical discrimination records. Current native record renewal/stamping remains parent-owned; no pending FRR carrier run, SRPM behavior, dataplane behavior, or full-RFC acceptance is inferred.

RFC8955-6-3

Therefore, a revalidation of the Flow Specification NLRI MUST be performed whenever unicast routes change. (§6)

Audit verdict: enforced (the tests do what the requirement demands), fresh. drives unicast add of a foreign more-specific, its withdraw, loss and return of the covering route, validation eligibility flips and session down, asserting a withdraw or reinstall event for the retained rule at each step without a new FlowSpec UPDATE

RFC8955-7.1-1

On encoding, the traffic-rate MUST NOT be negative. (§7.1, §7.2)

Audit verdict: enforced (the tests do what the requirement demands), fresh. positive pins the exact IEEE 754 bits for byte and packet rates; negative asserts '-1 packets' is refused. The negative input is packets only, but both subtypes share the one guard in flowspec_encode.go (rate < 0). Test doc names parseFlowSpecTrafficRateBits in route_community.go, which does not exist

RFC8955-7.1-2

On decoding, negative values MUST be treated as zero (discard all traffic). (§7.1, §7.2)

Audit verdict: enforced (the tests do what the requirement demands), fresh. positive decodes 1000.0 to rate-limit:1000; negative decodes -1000.0 to rate-limit:0 for both subtype 0x06 and 0x0c

RFC8955-7.3-1

These bits MUST be set to 0 on encoding and MUST be ignored during decoding. (§7.3)

Audit verdict: enforced (the tests do what the requirement demands), fresh. encode: config actions leave octets 2-6 zero and only 0x03 in the last octet; decode: every reserved bit set renders the same as clear for all four S/T combinations, and a pair differing only in S changes the render, so a renderer reading no bit fails; the .ci repeats it end to end to a plugin

RFC8955-7.5-1

reserved (r): MUST be set to 0 on encoding and MUST be ignored during decoding (§7.5)

Audit verdict: enforced (the tests do what the requirement demands), fresh. encode through config and EncodeRoute pins every reserved octet and the two reserved bits zero for DSCP 0, 46, 63, and refuses 64 and above; decode renders 0xEE as mark:46 and 0x40 as mark:0; the .ci carries the reserved-bit community to a plugin

RFC8955-12-1

Specifications relaxing the validation restrictions MUST contain security considerations that provide details on the required additional filtering. (§12)

Audit verdict: not audited: no reader has judged these tests

No test carries RFC8955-12-1, so no unit is bound to it.

RFC8955-5.1-1

This ordering function is such that it does not depend on the arrival order of the Flow Specification via BGP and thus is consistent in the network. (§5.1)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged 2026-10-16: the unit moved verbatim to core compare_rfc8955_test.go, with only the family identifier renamed. RFC 8955 Section 5.1: "This ordering function is such that it does not depend on the arrival order of the Flow Specification via BGP and thus is consistent in the network." Compare is required to be antisymmetric and reflexive (a<b, b>a, a==a) over type, prefix, operator-byte and width pairs. Core Compare reads only component content (no peer, time or action). The arrival-order sort itself is exercised by RFC5575-5.1-1's TestRFC5575PrecedenceIndependentOfArrival, which this row does not tag.

RFC8955-5.1-2

The relative order of two Flow Specifications is determined by comparing their respective components. The algorithm starts by comparing the left-most components (lowest component type value) of the Flow Specifications. If the types differ, the Flow Specification with lowest numeric type value has higher precedence (and thus will match before) than the Flow Specification that doesn't contain that component type. If the component types are the same, then a type- specific comparison is performed (see below). If the types are equal, the algorithm continues with the next component. For IP prefix values (IP destination or source prefix), if one of the two prefixes to compare is a more specific prefix of the other, the more specific prefix has higher precedence. Otherwise, the one with the lowest IP value has higher precedence. For all other component types, unless otherwise specified, the comparison is performed by comparing the component data as a binary string using the memcmp() function as defined by [ISO_IEC_9899]. For strings with equal lengths, the lowest string (memcmp) has higher precedence. For strings of different lengths, the common prefix is compared. If the common prefix is not equal, the string with the lowest prefix has higher precedence. If the common prefix is equal, the longest string is considered to have higher precedence than the shorter one. (§5.1)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged 2026-10-16: the compare unit moved verbatim to core and the flowspec-firewall kernel unit is unchanged. RFC 8955 Section 5.1: "The relative order of two Flow Specifications is determined by comparing their respective components." TestFlowSpecPrecedenceFromWire pins, with forward and reverse signs and self equality, each of these: a lower type first, a present-versus-absent next component, a more-specific overlapping prefix first, a lower disjoint prefix first, equal-width memcmp, and received-width bytes over numeric value. TestSelectedFlowSpecKernelPacketSemantics adds Linux packet evidence that the more-specific terminal rule wins over a covering discard in either install order. That unit needs integration+linux privileges, and a skipped run is not runtime proof. The clause "If the common prefix is equal, the longest string is considered to have higher precedence" has no pair. It is unreachable for well-formed numeric or bitmask data: the end-of-list bit sits in the operator octet, so one valid component's data can never be a proper prefix of another's.

RFC8955-8-1

The NLRI format for this address family consists of a fixed-length Route Distinguisher field (8 octets) followed by the Flow Specification NLRI value (Section 4.2). (§8)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged 2026-10-16: the unit moved verbatim to core rfc8955_vpn_test.go, with only the family identifier renamed (test-local AFI 1/SAFI 134). RFC 8955 Section 8: "The NLRI format for this address family consists of a fixed-length Route Distinguisher field (8 octets) followed by the Flow Specification NLRI value (Section 4.2)." The positive decodes RD 100:100 from the 8 octets after the length and the destination component after them, and requires the exact wire back from WriteTo. The negative requires ErrFlowSpecTruncated from core ParseFlowSpecVPN for a length too short to hold the RD.

RFC8955-8-2

The NLRI length field shall include both the 8 octets of the Route Distinguisher as well as the subsequent Flow Specification NLRI value. (§8)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged 2026-10-16: the unit moved verbatim to core, with only the family identifier renamed. RFC 8955 Section 8: "The NLRI length field shall include both the 8 octets of the Route Distinguisher as well as the subsequent Flow Specification NLRI value." The positive requires Len() and the WriteTo length octet to equal 8 plus the value length; its first assertion checks the fixture against itself, and the WriteTo assertion is the real check. The negative requires ErrFlowSpecTruncated for the same RD and value under a length that counts only the value.

RFC8955-3-1

Standard BGP policy mechanisms, such as UPDATE filtering by NLRI prefix as well as community matching, must apply to the Flow specification defined NLRI-type. (§3)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Both halves now tagged both ways. Community half: TestRFC8955CommunityPolicyAcceptsAPermittedFlowSpecRoute (ipv4/flow and ipv4/flow-vpn with 65001:100 accepted) and TestRFC8955CommunityPolicyRejectsADeniedFlowSpecRoute (denied community first-match and implicit deny reject a FlowSpec route); revert records on evaluateCommunities. Prefix half: filter_prefix flowspec_test.go pair (accept, reject, missing, mixed), no record. Both at the plugin entry point: no .ci drives a FlowSpec UPDATE through a configured community filter in the running daemon. Rejudged 2026-10-17 (independent reader) after the owner-approved 6019dd0675 change to TestPrefixPolicyFiltersFlowSpecDestination: the filter input prefix changed from nlri to mp, the section keyword the filter text now uses for MP_REACH families. The cases are unchanged: ipv4/flow and ipv4/flow-vpn destinations inside 10.0.0.0/8 ge 16 le 24 must be accepted, and /25, out-of-range, invalid and mixed destinations rejected, with no unicast rewrite. A parser that stopped reading the mp form would fail the accept cases, and a policy that stopped applying would fail the reject cases. Package re-run green 2026-10-17. RFC 8955 Section 3: "Standard BGP policy mechanisms, such as UPDATE filtering by NLRI prefix as well as community matching, must apply to the Flow specification defined NLRI-type." The community units are unchanged. Verdict stands.

RFC8955-6-5

Although the forwarding attributes of two routes for the same Flow Specification prefix may be the same, BGP is still required to perform its path selection algorithm in order to select the correct set of attributes to advertise. (§6)

Audit verdict: enforced (the tests do what the requirement demands), fresh. positive: two peers' paths for one FlowSpec NLRI publish the lower-MED path as best and hand best back to the survivor on withdraw; negative: a higher-MED second path publishes no best-change and the best keeps MED 100

RFC8955-7.3-2

The use of the Terminal Action (bit 47) may result in more than one Flow Specification matching a particular traffic flow. All the Traffic Filtering Actions from these Flow Specifications shall be collected and applied. (§7.3)

Audit verdict: enforced (the tests do what the requirement demands), fresh. RFC 8955 Section 7.3: "The use of the Terminal Action (bit 47) may result in more than one Flow Specification matching a particular traffic flow. All the Traffic Filtering Actions from these Flow Specifications shall be collected and applied." The same paragraph leaves interfering-action selection implementation-defined. TestSelectedFlowSpecKernelPacketSemantics now observes a received packet with the first rule's DSCP 10 AND exactly one increment of the later rule's sample counter; switching only the narrow rule to T-clear leaves the sample counter unchanged. Earlier controls prove T-set reaches a covering discard and that marking does not change the original DSCP used by later matching. rule_chains.go ruleChains/beforeMarkActions/markingTerms separate deferred marking and continuing action execution. Omitting the first action, the later action, or continuation fails independently, closing the earlier mark-plus-discard ambiguity. Requires a real privileged integration+linux execution; skips are not proof. Independent source rejudgment only; no test, mutation, build or gate was executed by this auditor. Native observed-red renewal is a separate parent step.

RFC8955-12-2

For a network to utilize this relaxation, the BGP policies must support additional filtering since the origin AS field is empty. (§12)

Audit verdict: not audited: no reader has judged these tests

No test carries RFC8955-12-2, so no unit is bound to it.

RFC8955-4.2.2.5-1

Type 5 component values SHOULD be encoded as 1- or 2-octet quantities (numeric_op len=00 or len=01). (§4.2.2.5)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged 2026-10-16: the emission unit changed only by package qualification (constructors and types now from core flowspec), and the reactor forwarding unit is unchanged. RFC 8955 Section 4.2.2.5: "Type 5 component values SHOULD be encoded as 1- or 2-octet quantities (numeric_op len=00 or len=01)." TestFlowSpecPreferredNumericEmission requires exact literal operator and value bytes at 0/255/256/65535 from typed, generic, registered config (ConfigRouteParserByFamily) and registered text (EncodeNLRIByFamily) producers, and from the EncodeRoute route command's MP_REACH. TestFlowSpecPreferredNumericForwarding carries the recipient TCP observation. Single-polarity as annotated, and the shortest width is Ze policy. The legal wide-reception compatibility control, which this row does not tag, moved to core numeric_wide_reception_test.go::TestFlowSpecPreferredNumericWideReception. Second re-judgement 2026-10-16: TestFlowSpecPreferredNumericEmission's typed packet-length producer is now the test helper packetLengthComponent (plugin types_test.go), which builds FlowMatch{Op: FlowOpEqual, Value: v} through NewFlowNumericComponent(FlowPacketLength, ...). That is byte-for-byte the matches that the deleted NewFlowPacketLengthComponent built at HEAD (plugin types_numeric.go:457-463). The deleted constructor had no non-test caller at HEAD, so no production producer lost coverage. The typed and generic cases now drive the same constructor, and the registered config, text and forwarding producers carry the distinct evidence.

RFC8955-4.2.2.6-1

Type 6 component values SHOULD be encoded as 1- or 2-octet quantities (numeric_op len=00 or len=01). (§4.2.2.6)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged 2026-10-16: same units and same change as RFC8955-4.2.2.5-1. RFC 8955 Section 4.2.2.6: "Type 6 component values SHOULD be encoded as 1- or 2-octet quantities (numeric_op len=00 or len=01)." Source-port emission requires exact one- and two-octet operands at 0/255/256/65535 across the typed, generic, config, text and route-command producers, plus recipient forwarding. Single-polarity as annotated. Second re-judgement 2026-10-16: TestFlowSpecPreferredNumericEmission's typed packet-length producer is now the test helper packetLengthComponent (plugin types_test.go), which builds FlowMatch{Op: FlowOpEqual, Value: v} through NewFlowNumericComponent(FlowPacketLength, ...). That is byte-for-byte the matches that the deleted NewFlowPacketLengthComponent built at HEAD (plugin types_numeric.go:457-463). The deleted constructor had no non-test caller at HEAD, so no production producer lost coverage. The typed and generic cases now drive the same constructor, and the registered config, text and forwarding producers carry the distinct evidence.

RFC8955-4.2.2.8-1

Type 8 component values SHOULD be encoded as single octet (numeric_op len=00). (§4.2.2.8)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged 2026-10-16: same units and same change as RFC8955-4.2.2.5-1. RFC 8955 Section 4.2.2.8: "Type 8 component values SHOULD be encoded as single octet (numeric_op len=00)." ICMP-code emission requires the exact single octet at 0 and 255 across the typed (NewFlowICMPCodeComponent, now exported from core), generic, config and text producers, plus recipient forwarding. The route-command grammar has no ICMP-code criterion. Single-polarity as annotated. Second re-judgement 2026-10-16: TestFlowSpecPreferredNumericEmission's typed packet-length producer is now the test helper packetLengthComponent (plugin types_test.go), which builds FlowMatch{Op: FlowOpEqual, Value: v} through NewFlowNumericComponent(FlowPacketLength, ...). That is byte-for-byte the matches that the deleted NewFlowPacketLengthComponent built at HEAD (plugin types_numeric.go:457-463). The deleted constructor had no non-test caller at HEAD, so no production producer lost coverage. The typed and generic cases now drive the same constructor, and the registered config, text and forwarding producers carry the distinct evidence.

RFC8955-4.2.2.10-1

Type 10 component values SHOULD be encoded as 1- or 2-octet quantities (numeric_op len=00 or len=01). (§4.2.2.10)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged 2026-10-16: same units and same change as RFC8955-4.2.2.5-1. RFC 8955 Section 4.2.2.10: "Type 10 component values SHOULD be encoded as 1- or 2-octet quantities (numeric_op len=00 or len=01)." Packet-length emission requires exact one- and two-octet operands at 0/255/256/65535 across the typed, generic, config and text producers, plus recipient forwarding. Single-polarity as annotated, and the shortest width is local policy. Second re-judgement 2026-10-16: TestFlowSpecPreferredNumericEmission's typed packet-length producer is now the test helper packetLengthComponent (plugin types_test.go), which builds FlowMatch{Op: FlowOpEqual, Value: v} through NewFlowNumericComponent(FlowPacketLength, ...). That is byte-for-byte the matches that the deleted NewFlowPacketLengthComponent built at HEAD (plugin types_numeric.go:457-463). The deleted constructor had no non-test caller at HEAD, so no production producer lost coverage. The typed and generic cases now drive the same constructor, and the registered config, text and forwarding producers carry the distinct evidence.

RFC8955-7.2-3

A traffic-rate-packets of 0 should result in all traffic for the particular flow to be discarded. (§7.2)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Literal packet-rate community 0x800c zero reaches the selected callback and real nft backend, with four target drops, exact four-packet/116-byte counters, unaffected-destination and positive-rate controls; the repaired sequence reinstalls zero, sends target token 7 and control token 8, requires only 8 plus a timeout, then withdraws that active discard and requires token 6 delivery, so stale zero-rate enforcement is now distinguishable from removal. Independent source judgment: FlowWidthZeroWholeReview. Current restored numeric/forwarding race observation: job-flowspec-numeric-restored-after-mutations-c672abd1.log. Width and legal-wide reception semantic negatives: 267ffab7, b0675576, 4cb46ab9, d65876fe, 73bd5cbc, 85fdc2cb, 567fcfe2, adf991fd. Packet-zero negative: job-flowspec-semantic-packet-zero-kernel-9c4ece52.log; repaired non-skipped runtime-kernel positive: job-flowspec-zero-restored-guest-path-637874ca.log. Direct selected-callback entry is not subscription-delivery proof; local IPv4 input is not VPN or transit dataplane coverage. Re-judged 2026-10-13 after 2ce54b1f91: both discard-probe checks moved from err.(net.Error) to errors.AsType[net.Error](err); ReadFromUDP returns *net.OpError, which satisfies net.Error at the top of the chain, so each timeout assertion accepts and refuses exactly the errors it did before and the verdict is unchanged.

Extraction sign-off

Sections

Excluded sentences

Superseded

No document obsoletes RFC 8955, so its obligations are stated where they were written.