[Softwires] [Errata Verified] RFC6333 (5847)
RFC Errata System <rfc-editor@rfc-editor.org> Mon, 17 May 2021 07:57 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 1E6753A2D52; Mon, 17 May 2021 00:57:15 -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 BIO1U5WLDX-M; Mon, 17 May 2021 00:57:10 -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 1CDC73A2D4C; Mon, 17 May 2021 00:57:09 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 649CFF4077A; Mon, 17 May 2021 00:57:08 -0700 (PDT)
To: swmike@swm.pp.se, 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: <20210517075708.649CFF4077A@rfc-editor.org>
Date: Mon, 17 May 2021 00:57:08 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/softwires/T-EzTkuH0UQDVoyoWJ2WSB5-68I>
Subject: [Softwires] [Errata Verified] RFC6333 (5847)
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 07:57:15 -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/eid5847 -------------------------------------- Status: Verified Type: Technical Reported by: Mikael Abrahamsson <swmike@swm.pp.se> Date Reported: 2019-08-26 Verified by: Eric Vyncke (IESG) Section: 5.3 Original Text ------------- However, as not all service providers will be able to increase their link MTU, the B4 element MUST perform fragmentation and reassembly if the outgoing link MTU cannot accommodate the extra IPv6 header. The original IPv4 packet is not oversized. The packet is oversized after the IPv6 encapsulation. The inner IPv4 packet MUST NOT be fragmented. Fragmentation MUST happen after the encapsulation of the IPv6 packet. Reassembly MUST happen before the decapsulation of the IPv4 packet. A detailed procedure has been specified in [RFC2473] Section 7.2. Corrected Text -------------- However, as not all service providers will be able to increase their link MTU, the B4 element MUST perform fragmentation and reassembly if the outgoing link MTU cannot accommodate the extra IPv6 header. The original IPv4 packet is not oversized. The packet is oversized after the IPv6 encapsulation. The inner IPv4 packet MUST NOT be fragmented. 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 ----- I do not have a corrected text. The above text doesn't say what RFC2473 section 7.2 says, so... what should it be? RFC2473 7.2 says to use the DF bit and decide whether to inner fragment or drop+send ICMP error. The above text seems to make normative statements that counter at least the DF=1 case in RFC2473 7.2. Also the text above says "Fragmentation MUST happen after the encapsulation of the IPv6 packet.". The IPv6 packet isn't encapsulated, so that sentence should be changed? --- Verifier note --- Following the discussion in https://mailarchive.ietf.org/arch/msg/softwires/bBQT97R7p1Ho4cUZIP2MFU5ZYJ4/ , the original intent is to avoid fragmenting the IPv4 packet before encapsulation. -------------------------------------- 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
- [Softwires] [Errata Verified] RFC6333 (5847) RFC Errata System