Found 2 records.

Status: Verified (1)

RFC 8955, "Dissemination of Flow Specification Rules", December 2020

Note: This RFC has been updated by RFC 8956, RFC 9117, RFC 9184

Errata ID: 7654
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: John Scudder
Date Reported: 2023-09-22
Verifier Name: Jim Guichard
Date Verified: 2024-10-09

Section 4 says:

   This NLRI information is encoded using MP_REACH_NLRI and
   MP_UNREACH_NLRI attributes, as defined in [RFC4760].  When
   advertising Flow Specifications, the Length of the Next-Hop Network
   Address MUST be set to 0.  The Network Address of the Next-Hop field
   MUST be ignored.

It should say:

   This NLRI information is encoded using MP_REACH_NLRI and
   MP_UNREACH_NLRI attributes, as defined in [RFC4760].  When
   advertising Flow Specifications, the "Length of Next Hop Network 
   Address" field MUST be set to 0.  The "Network Address of Next Hop" 
   field MUST be ignored.

Notes:

The fields are named incorrectly in the original text -- they don't match the field names they're referencing in RFC 4760. Most importantly there's no hyphen in the RFC 4760 field definitions, but there are other differences too.

Status: Rejected (1)

RFC 8955, "Dissemination of Flow Specification Rules", December 2020

Note: This RFC has been updated by RFC 8956, RFC 9117, RFC 9184

Errata ID: 8400
Status: Rejected
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Jeffrey Haas
Date Reported: 2025-04-30
Rejected by: Ketan Talaulikar
Date Rejected: 2025-05-09

Section 4.2.2, 5.1 says:

4.2.2.1. Type 1 - Destination Prefix

Encoding: <type (1 octet), length (1 octet), prefix (variable)>
Defines the destination prefix to match. The length and prefix fields
are encoded as in BGP UPDATE messages [RFC4271].

4.2.2.2. Type 2 - Source Prefix

Encoding: <type (1 octet), length (1 octet), prefix (variable)>
Defines the source prefix to match. The length and prefix fields are 
encoded as in BGP UPDATE messages [RFC4271].
[...]

5.1. Ordering of Flow Specifications 
[...]
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.

It should say:

No correction offered, see notes.

Notes:

No corrected text is supplied since the resolution of this issue is somewhat ambiguous.
In RFC 4271 Section 4.3, the definition of a prefix is:
b) Prefix:

The Prefix field contains an IP address prefix, followed by
the minimum number of trailing bits needed to make the end
of the field fall on an octet boundary. Note that the value
of trailing bits is irrelevant.

RFC 8955 doesn't quite address the "trailing bits" consideration. Following the advice from RFC 4271, irrelevant would primarily impact ignoring the trailing bits for purposes of installing firewall rules generated from flowspec routes. For the ordering procedures, comparing two equivalent prefixes that differ in trailing bits should result in them being considered equal.

Implementations of flowspec that don't ignore trailing bits may treat routes with components that differ only in trailing bits for their source or destination prefixes as different flowspec routes.

For updates to RFC 8955, including the upcoming flowspec v2, more normative text to zero out the trailing bits should be considered.
--VERIFIER NOTES--
Following is a summary of the discussion thread on IDR WG and my reading of RFC8955:
1) RFC8955 removes the opaqueness aspect of FSv1 components encoded in the NLRI.
2) Drawing upon the prefix encoding of RFC4271, implies that the trailing bits of the prefix beyond what is indicated by the prefix length are ignored. And since there is no opaqueness, there is technically no issue in creating a correct entry in the BGP RIB (and as an extension the firewall rules that are downloaded).
3) If some implementation of RFC8955 has erred on this, then it seems like an implementation issue.
4) Prudent software engineering dictates that the "to be ignored" parts are set to zero and putting that into a spec would only improve it. John has captured this well and I am not repeating.
5) In summary, this is not a bug in RFC8955 but there is scope for clarity and improvement in this aspect.

After discussions on the WG mailer, this erratum is rejected and the WG participants may pursue improvements via document actions that have WG consensus.

For further details, refer the discussion thread here: https://mailarchive.ietf.org/arch/msg/idr/0BhDnIq-ZrqNu5D8_lAP3R7BvQU/

Report New Errata