[Softwires] [Errata Verified] RFC6333 (6584)

RFC Errata System <rfc-editor@rfc-editor.org> Mon, 17 May 2021 08:42 UTC

Return-Path: <wwwrun@rfc-editor.org>
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5B423A2EB9; Mon, 17 May 2021 01:42:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 H6JEtIubhhcr; Mon, 17 May 2021 01:42:32 -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 7B8953A2EBB; Mon, 17 May 2021 01:42:32 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 73ED3F407D1; Mon, 17 May 2021 01:42:31 -0700 (PDT)
To: mohamed.boucadair@orange.com, adurand@juniper.net, rdroms@cisco.com, jhw@apple.com, yiu_lee@cable.comcast.com
X-PHP-Originating-Script: 1005:errata_mail_lib.php
From: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: evyncke@cisco.com, iesg@ietf.org, softwires@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20210517084231.73ED3F407D1@rfc-editor.org>
Date: Mon, 17 May 2021 01:42:31 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/softwires/Kgzeg_4Bsr5Qjqv2mSweDOJNYX0>
Subject: [Softwires] [Errata Verified] RFC6333 (6584)
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: softwires wg discussion list <softwires.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/softwires>, <mailto:softwires-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/softwires/>
List-Post: <mailto:softwires@ietf.org>
List-Help: <mailto:softwires-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/softwires>, <mailto:softwires-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 May 2021 08:42:37 -0000

The following errata report has been verified for RFC6333,
"Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion". 

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6584

--------------------------------------
Status: Verified
Type: Editorial

Reported by: Mohamed Boucadair <mohamed.boucadair@orange.com>
Date Reported: 2021-05-17
Verified by: Eric Vyncke (IESG)

Section: 6.3

Original Text
-------------
   As noted previously, fragmentation and reassembly need to be taken
   care of by the tunnel endpoints.  As such, the AFTR MUST perform
   fragmentation and reassembly if the underlying link MTU cannot
   accommodate the encapsulation overhead.  Fragmentation MUST happen
   after the encapsulation on the IPv6 packet.  Reassembly MUST happen
                           ^^^^^^^^^^^^^^^^^^
   before the decapsulation of the IPv6 header.  A detailed procedure
   has been specified in [RFC2473] Section 7.2.


Corrected Text
--------------
   As noted previously, fragmentation and reassembly need to be taken
   care of by the tunnel endpoints.  As such, the AFTR MUST perform
   fragmentation and reassembly if the underlying link MTU cannot
   accommodate the encapsulation overhead.  Fragmentation MUST happen
   after the IPv6 encapsulation.  Fragmentation MUST happen after the encapsulation of the
   IPv4 packet in the IPv6 packet.  Reassembly of the IPv6 packet MUST happen before the decapsulation of the
   IPv4 packet.  A detailed procedure has been specified in [RFC2473]
   Section 7.2 following point b) and ignoring the DF-bit setting.


Notes
-----
The original text is confusing as it seems to assume an extra encapsulation on the IPv6 packet, while this should be about adding an IPv6 header to an IPv4 packet.

-- verifier notes --
Following the discussion in https://mailarchive.ietf.org/arch/msg/softwires/bBQT97R7p1Ho4cUZIP2MFU5ZYJ4/ , the original intent is to avoid fragmenting the IPv4 packet before encapsulation.
See also errata 5874 on section 5.3 (the submitter's proposal has been updated by the verifier to be consistent with errata 5874).

--------------------------------------
RFC6333 (draft-ietf-softwire-dual-stack-lite-11)
--------------------------------------
Title               : Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion
Publication Date    : August 2011
Author(s)           : A. Durand, R. Droms, J. Woodyatt, Y. Lee
Category            : PROPOSED STANDARD
Source              : Softwires
Area                : Internet
Stream              : IETF
Verifying Party     : IESG