[Technical Errata Reported] RFC8754 (7081)
RFC Errata System <rfc-editor@rfc-editor.org> Thu, 11 August 2022 00:35 UTC
Return-Path: <wwwrun@rfcpa.amsl.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26585C19E0E6 for <ipv6@ietfa.amsl.com>; Wed, 10 Aug 2022 17:35:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.959
X-Spam-Level:
X-Spam-Status: No, score=-3.959 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.248, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oOZ-S3PLPJi4 for <ipv6@ietfa.amsl.com>; Wed, 10 Aug 2022 17:35:40 -0700 (PDT)
Received: from rfcpa.amsl.com (rfc-editor.org [50.223.129.200]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51375C1907DA for <ipv6@ietf.org>; Wed, 10 Aug 2022 17:35:40 -0700 (PDT)
Received: by rfcpa.amsl.com (Postfix, from userid 499) id 074C74C29D; Wed, 10 Aug 2022 17:35:39 -0700 (PDT)
To: cfilsfil@cisco.com, ddukes@cisco.com, stefano@previdi.net, john@leddy.net, satoru.matsushima@g.softbank.co.jp, daniel.voyer@bell.ca, ek.ietf@gmail.com, evyncke@cisco.com, bob.hinden@gmail.com, otroan@employees.org, furry13@gmail.com
Subject: [Technical Errata Reported] RFC8754 (7081)
From: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: zhoutianran@huawei.com, ipv6@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20220811003540.074C74C29D@rfcpa.amsl.com>
Date: Wed, 10 Aug 2022 17:35:40 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/_xyNTpmd654WTdfmgSRPDnzA7XY>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Aug 2022 00:35:44 -0000
The following errata report has been submitted for RFC8754, "IPv6 Segment Routing Header (SRH)". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid7081 -------------------------------------- Type: Technical Reported by: Tianran Zhou <zhoutianran@huawei.com> Section: 4.1.1 Original Text ------------- 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. Corrected Text -------------- 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. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC8754 (draft-ietf-6man-segment-routing-header-26) -------------------------------------- Title : IPv6 Segment Routing Header (SRH) Publication Date : March 2020 Author(s) : C. Filsfils, Ed., D. Dukes, Ed., S. Previdi, J. Leddy, S. Matsushima, D. Voyer Category : PROPOSED STANDARD Source : IPv6 Maintenance Area : Internet Stream : IETF Verifying Party : IESG
- [Technical Errata Reported] RFC8754 (7081) RFC Errata System
- Re: [Technical Errata Reported] RFC8754 (7081) Darren Dukes (ddukes)
- RE: [Technical Errata Reported] RFC8754 (7081) Tianran Zhou
- Re: [Technical Errata Reported] RFC8754 (7081) Joel Halpern
- RE: [Technical Errata Reported] RFC8754 (7081) Tianran Zhou
- Re: [Technical Errata Reported] RFC8754 (7081) Joel Halpern
- RE: [Technical Errata Reported] RFC8754 (7081) Tianran Zhou