[Technical Errata Reported] RFC8200 (5933)
RFC Errata System <rfc-editor@rfc-editor.org> Wed, 11 December 2019 03:27 UTC
Return-Path: <wwwrun@rfc-editor.org>
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 CA2A312006B for <ipv6@ietfa.amsl.com>; Tue, 10 Dec 2019 19:27:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iG-LtCVzdag7 for <ipv6@ietfa.amsl.com>; Tue, 10 Dec 2019 19:27:35 -0800 (PST)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15194120059 for <ipv6@ietf.org>; Tue, 10 Dec 2019 19:27:35 -0800 (PST)
Received: by rfc-editor.org (Postfix, from userid 30) id 46F77F406F3; Tue, 10 Dec 2019 19:27:24 -0800 (PST)
To: none@rfc-editor.org, bob.hinden@gmail.com, suresh@kaloom.com, evyncke@cisco.com, bob.hinden@gmail.com, otroan@employees.org
Subject: [Technical Errata Reported] RFC8200 (5933)
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: fgont@si6networks.com, ipv6@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20191211032724.46F77F406F3@rfc-editor.org>
Date: Tue, 10 Dec 2019 19:27:24 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/6MPs25WvSMD6vVT0ekaMYjAwM6c>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 11 Dec 2019 03:27:37 -0000
The following errata report has been submitted for RFC8200, "Internet Protocol, Version 6 (IPv6) Specification". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid5933 -------------------------------------- Type: Technical Reported by: Fernando Gont <fgont@si6networks.com> Section: 4 Original Text ------------- Extension headers (except for the Hop-by-Hop Options header) are not processed, inserted, or deleted by any node along a packet's delivery path, until the packet reaches the node (or each of the set of nodes, in the case of multicast) identified in the Destination Address field of the IPv6 header. The Hop-by-Hop Options header is not inserted or deleted, but may be examined or processed by any node along a packet's delivery path, until the packet reaches the node (or each of the set of nodes, in the case of multicast) identified in the Destination Address field of the IPv6 header. The Hop-by-Hop Options header, when present, must immediately follow the IPv6 header. Its presence is indicated by the value zero in the Next Header field of the IPv6 header. Corrected Text -------------- Extension headers (except for the Hop-by-Hop Options header, or a Destination Options header preceding a Routing header) are not processed, inserted, or deleted by any node along a packet's delivery path, until the packet reaches the final destination node (or each of the set of final destination nodes, in the case of multicast). For packets that do not include a Routing Header, the final destination node is identified by the Destination Address field of the IPv6 header. For packets that include a Routing Header, the final destination node is identified by the Destination Address field of the IPv6 header only when the Segments Left field of the Routing Header is 0. The Hop-by-Hop Options header is not inserted or deleted, but may be examined or processed by any node along a packet's delivery path, until the packet reaches the final destination node (or each of the set of final destination nodes, in the case of multicast). The Hop-by-Hop Options header, when present, must immediately follow the IPv6 header. Its presence is indicated by the value zero in the Next Header field of the IPv6 header. A Destination Options header preceding a Routing Header is not processed, inserted, or deleted by any node along a packet's delivery path, until the packet reaches the destination node (or each of the set of destination nodes, in the case of multicast) identified by the Destination Address field of the IPv6 header. This means that a Destination Options header preceding a Routing Header will be processed by the first destination of the packet (specified by the Destination Address field of the IPv6 header at the origin node) and by each node listed in the Routing Header. Notes ----- This errata clarifies two different issues: * It clarifies that nodes other than the final destination do not insert o remove extension headers. * It clarifies that the Destination Options header preceding a routing header *is* processed along the packet delivery's path, but the node(s) identified by the Destination Address of the IPv6 header. 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. -------------------------------------- RFC8200 (draft-ietf-6man-rfc2460bis-13) -------------------------------------- Title : Internet Protocol, Version 6 (IPv6) Specification Publication Date : July 2017 Author(s) : S. Deering, R. Hinden Category : INTERNET STANDARD Source : IPv6 Maintenance Area : Internet Stream : IETF Verifying Party : IESG
- [Technical Errata Reported] RFC8200 (5933) RFC Errata System
- Re: [Technical Errata Reported] RFC8200 (5933) Fernando Gont
- Re: [Technical Errata Reported] RFC8200 (5933) Alexandre Petrescu
- Re: [Technical Errata Reported] RFC8200 (5933) Tom Herbert
- Re: [Technical Errata Reported] RFC8200 (5933) Fernando Gont
- Re: [Technical Errata Reported] RFC8200 (5933) Fernando Gont
- Re: [Technical Errata Reported] RFC8200 (5933) Brian E Carpenter
- Re: [Technical Errata Reported] RFC8200 (5933) Fernando Gont
- Re: [Technical Errata Reported] RFC8200 (5933) Brian E Carpenter
- Re: [Technical Errata Reported] RFC8200 (5933) Alexandre Petrescu
- Re: [Technical Errata Reported] RFC8200 (5933) Fernando Gont
- Re: [Technical Errata Reported] RFC8200 (5933) Fernando Gont
- Re: [Technical Errata Reported] RFC8200 (5933) Brian E Carpenter
- Re: [Technical Errata Reported] RFC8200 (5933) Brian E Carpenter
- RE: [Technical Errata Reported] RFC8200 (5933) Ron Bonica
- Re: [Technical Errata Reported] RFC8200 (5933) Loa Andersson
- Re: [Technical Errata Reported] RFC8200 (5933) Alexandre Petrescu
- Re: [Technical Errata Reported] RFC8200 (5933) Alexandre Petrescu