[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