[Technical Errata Reported] RFC8200 (5172)
RFC Errata System <rfc-editor@rfc-editor.org> Sun, 29 October 2017 06:57 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 5793813F6BC for <ipv6@ietfa.amsl.com>; Sat, 28 Oct 2017 23:57:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 3EJdrw3zdzND for <ipv6@ietfa.amsl.com>; Sat, 28 Oct 2017 23:57:46 -0700 (PDT)
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 C088113F6B4 for <ipv6@ietf.org>; Sat, 28 Oct 2017 23:57:46 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 634DAB8179E; Sat, 28 Oct 2017 23:57:40 -0700 (PDT)
To: none@rfc-editor.org, bob.hinden@gmail.com, suresh@kaloom.com, terry.manderson@icann.org, otroan@employees.org, bob.hinden@gmail.com
Subject: [Technical Errata Reported] RFC8200 (5172)
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: <20171029065740.634DAB8179E@rfc-editor.org>
Date: Sat, 28 Oct 2017 23:57:40 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/KbtNqeVAoipXrq5MFE4qnvdYTq8>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
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: Sun, 29 Oct 2017 06:57:48 -0000
The following errata report has been submitted for RFC8200, "Internet Protocol, Version 6 (IPv6) Specification". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5172 -------------------------------------- Type: Technical Reported by: Fernando Gont <fgont@si6networks.com> Section: 4.5 Original Text ------------- The Fragmentable Part of the reassembled packet is constructed from the fragments following the Fragment headers in each of the fragment packets. The length of each fragment is computed by subtracting from the packet's Payload Length the length of the headers between the IPv6 header and fragment itself; its relative position in Fragmentable Part is computed from its Fragment Offset value. Corrected Text -------------- The "Ext & Upper-Layer Headers" part and Fragmentable Part of the reassembled packet are constructed from the "chunks" following the Fragment headers in each of the fragment packets. The length of each chunk is computed by subtracting from the packet's Payload Length the length of the headers between the IPv6 header and chunk itself; the relative position of the chunk is computed from its Fragment Offset value. Notes ----- * The original text misses how to construct the "Ext & Upper-Layer Headers" of the packet, which in the figures is not considered to be part of the "Unfragmentable part" (it *was* considered part of it in RFC2460). * The original text does says: The length of each fragment is computed by subtracting from the packet's Payload Length the length of the headers between the IPv6 header and fragment itself Assuming "each fragment" refers to the pieces marked as "first fragment", "second fragment", etc., this does not apply for the computation of the length of the first fragment, since such computed length would otherwise include the length of the first fragment, plus the length of "Ext & Upper-Layer Headers". * The "corrected text" requires more work, and employs the (previously undefined) term "chunk" to refer to the content of a fragment (the chunk following a Fragment Header in a given packet). This is because for all fragments other than the first, "fragment" is what follows an FH, but for the first fragment (given the figures), "first fragment" is NOT everything that follows the FH (i.e., it does not include the "Ext & Upper-Layer Headers" part. * Note that in the corrected text, the phrase "its relative position in Fragmentable Part is computed from its Fragment Offset value", since the relative position is really from the "Ext & Upper-Layer Headers" part, rather than from the Unfragmentable part. 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 (5172) RFC Errata System