[Technical Errata Reported] RFC8200 (5170)

RFC Errata System <rfc-editor@rfc-editor.org> Sat, 28 October 2017 23:17 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 40E6413FDC2 for <ipv6@ietfa.amsl.com>; Sat, 28 Oct 2017 16:17:30 -0700 (PDT)
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 sDp345_l20vq for <ipv6@ietfa.amsl.com>; Sat, 28 Oct 2017 16:17:28 -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 D65F013FDBF for <ipv6@ietf.org>; Sat, 28 Oct 2017 16:17:28 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id BCBF1B8114C; Sat, 28 Oct 2017 16:17:22 -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 (5170)
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: <20171028231722.BCBF1B8114C@rfc-editor.org>
Date: Sat, 28 Oct 2017 16:17:22 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/i-3flEU-7dJQEsWuq5OYK1Hig5Q>
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: Sat, 28 Oct 2017 23:17:30 -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/eid5170

--------------------------------------
Type: Technical
Reported by: Fernando Gont <fgont@si6networks.com>

Section: 4.5

Original Text
-------------
              A Fragment Offset containing the offset of the fragment,
              in 8-octet units, relative to the start of the
              Fragmentable Part of the original packet.  The Fragment
              Offset of the first ("leftmost") fragment is 0.

Corrected Text
--------------
              A Fragment Offset containing the offset of the fragment,
              in 8-octet units, relative to the start of the
              "Extension & Upper-Layer Headers" Part of the original 
              packet. The Fragment Offset of the fragment containing
              the "Extension & Upper-Layer Headers" part is 0.

Notes
-----
Clearly, the first fragment will contain a Fragment Offset of 0.

However, given the figure:

---- cut here ----
   original packet:

   +-----------------+-----------------+--------+--------+-//-+--------+
   |  Per-Fragment   |Ext & Upper-Layer|  first | second |    |  last  |
   |    Headers      |    Headers      |fragment|fragment|....|fragment|
   +-----------------+-----------------+--------+--------+-//-+--------+

   fragment packets:

   +------------------+---------+-------------------+----------+
   |  Per-Fragment    |Fragment | Ext & Upper-Layer |  first   |
   |    Headers       | Header  |   Headers         | fragment |
   +------------------+---------+-------------------+----------+

   +------------------+--------+-------------------------------+
   |  Per-Fragment    |Fragment|    second                     |
   |    Headers       | Header |   fragment                    |
   +------------------+--------+-------------------------------+
                         o
                         o
                         o
   +------------------+--------+----------+
   |  Per-Fragment    |Fragment|   last   |
   |    Headers       | Header | fragment |
   +------------------+--------+----------+


it is the part market as "Ext & Upper-Layer Headers" the one that will have a Fragment offset of 0, rather than the part marked as "first fragment". For example, one could envision this scenario:

---- cut here ----
   original packet:

   +-----------------+-----------------+---------------+
   |  Per-Fragment   |Ext & Upper-Layer| first & last  |
   |    Headers      |    Headers      |   fragment    |
   +-----------------+-----------------+---------------+

   fragment packets:

   +------------------+---------+-------------------+
   |  Per-Fragment    |Fragment | Ext & Upper-Layer |
   |    Headers       | Header  |   Headers         |
   +------------------+---------+-------------------+

   +------------------+--------+---------------+
   |  Per-Fragment    |Fragment| first & last  |
   |    Headers       | Header |   fragment    |
   +------------------+--------+---------------+

---- cut here ----

Where the first fragment just contains the entire IPv6 header chain, and then second fragment contains the chunk marked as "first fragment" (this "first fragment" part is the only "Fragmentable" part of the packet).

Note: the text "The Fragment Offset of the first ("leftmost") fragment is 0." was re-phrased in the "corrected text", since it might confuse the reader regarding whether it refers to the actual first fragment (i.e. the first packet corresponding to the fragmented datagram), or the chunk marked as "first fragment" in the figure.

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