Found 2 records.

Status: Verified (2)

RFC 8754, "IPv6 Segment Routing Header (SRH)", March 2020

Errata ID: 7081
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Tianran Zhou
Date Reported: 2022-08-11
Verifier Name: Erik Kline
Date Verified: 2023-07-23

Section 4.1.1 says:

A reduced SRH does not contain the first segment of the related SR
Policy (the first segment is the one already in the DA of the IPv6
header), and the Last Entry field is set to n-2, where n is the
number of elements in the SR Policy.

It should say:

A reduced SRH does not contain the first segment of the related SR
Policy (the first segment is the one already in the DA of the IPv6
header), and the Last Entry field is set to n-2, where n is the
number of elements in the SR Policy.

When an SRH includes TLVs and only one 128-bit Segment, the reduced
SRH MUST NOT be used to avoid errors of SRH TLV processing defined
in section 2.1. 

Notes:

When only one single Segment is included in the SRH, the last entry will be 0 forever, so a segment endpoint node cannot specify whether the last Segment is included or removed from the SRH.

As defined in section 2.1, only when the header length of SRH larger then (0+1)*2, the TLVs will be processed.
1. When the Segment is removed, Segment Lefts = Last Entry = 0, each segment endpoint node will skip the bytes 8-16, and then process the following bytes following the TLV processing rules, which will cause errors.
2. When the segment is not removed, Segment Lefts = Last Entry = 0, each segment endpoint will process the TLVs correctly from byte 8+16.

Choosing option 2 can avoid processing error of SRH TLVs and be compatible with the current hardware implementation. Thus option 1 MUST be avoid in implementation.

Errata ID: 7102
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Darren Dukes
Date Reported: 2022-08-23
Verifier Name: Erik Kline
Date Verified: 2023-06-06

Section 2 says:

Segments Left:  Defined in [RFC8200], Section 4.4.

It should say:

Segments Left:  Defined in [RFC8200], Section 4.4.
Specifically, for the SRH, the number of unprocessed 
128-bit entries in the Segment List.

Notes:

RFC8754 describes “The encoding of IPv6 segments in the SRH” where IPv6 segments are defined in RFC8402. RFC8402 describes binding SIDs and adjacency SIDs for SRv6. Both these SID types identify more than a single explicitly listed intermediate node to be visited.

The current definition of Segments Left only indicates it is defined in RFC8200, and RFC8200 defines it as “Number of route segments remaining, i.e., number of explicitly listed intermediate nodes still to be visited before reaching the final destination”.

Previous versions of draft-ietf-6man-segment-routing-header (0-11) referenced RFC2460/RFC8200 and described the Segments Left field by use in the SRH; as an index into the Segment List. This was removed in later versions (12/13) to consolidate the use of segments left to be specific to the segment processed (now section 4.3.1). However, that removed the definition of its meaning in the SRH which led to the current issue.

The corrected text restores the meaning of Segments Left for the SRH in relation to Segment List (which is not defined in RFC8200), while still leaving its use during segment processing to the segment definition (section 4.3.1 or future documents).

Report New Errata