Re: [Int-area] [Softwires] Errata on RFC 6333, "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion"

ianfarrer@gmx.com Mon, 10 May 2021 14:40 UTC

Return-Path: <ianfarrer@gmx.com>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CD873A1EF6; Mon, 10 May 2021 07:40:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net
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 6qSwRSV26HbB; Mon, 10 May 2021 07:40:05 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8ED213A1EF5; Mon, 10 May 2021 07:40:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1620657602; bh=TNQyaJf2er6HEwK3zc9QloXFJnCIP3F94JIXvGetXe0=; h=X-UI-Sender-Class:From:Subject:Date:In-Reply-To:Cc:To:References; b=HXaC60evgu8rzQ+nh8ceSCZUhYrhT8UNztwxGpsd5s7TattnoyOXOh+4Cdjk4uLsd nTCMaFUIx45sHBkuU2K+MOCU6AacV3nzInyhyfHziqxhW72xvuUo+lGTn1U15mY5uO yFj8hOudXJeCIheQFiEUiemfeoDxrnixHWoxwfbk=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from smtpclient.apple ([87.78.251.7]) by mail.gmx.net (mrgmx005 [212.227.17.184]) with ESMTPSA (Nemesis) id 1Ml6qM-1lEn5K1ZTY-00lVoH; Mon, 10 May 2021 16:40:02 +0200
From: ianfarrer@gmx.com
Message-Id: <B2A844E5-40B4-44D3-9B2A-D188695C450B@gmx.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_750EC1C2-3471-4FE8-9791-9F0E9B56C59C"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\))
Date: Mon, 10 May 2021 16:40:00 +0200
In-Reply-To: <15FCA524-D984-4A0C-9D17-8599515F0C21@cisco.com>
Cc: "softwires@ietf.org" <softwires@ietf.org>, "int-area@ietf.org" <int-area@ietf.org>
To: "Eric Vyncke (evyncke)" <evyncke=40cisco.com@dmarc.ietf.org>
References: <15FCA524-D984-4A0C-9D17-8599515F0C21@cisco.com>
X-Mailer: Apple Mail (2.3654.80.0.2.43)
X-Provags-ID: V03:K1:WjxLxRR/q0c1N9tQAnaAuw6RyQkexFvPH8yHUNnsvgFZW26uGDJ YY2RySVCoKIdZE/kS2nU76p43TEPQ5MKrOkJ3Jl3RMxcbb21vIw+fiSUm9sfs2V+q++nX+K 3fRjI2Yv+g8DuP2qaXaa6GR9vvUbnRAgTszxS23odMwgSZtFBOcKjWxuMoqmSSAeEbKnUIE 4rhIODj+WVDCZbNBg4a+g==
X-UI-Out-Filterresults: notjunk:1;V03:K0:yLu0ac5Adto=:yUgHFah28E1ZTi6qfBiKf4 wf4c9tx5hSfQr7AZ//TiUjL9yE34JU/JdWZWWKC0R3vrD0rqpQ8K4ckbhNgGBJzad/ikdtdrD LUsEL954O3EZJpQvImPwXPhqa7Dx6v9BHILnZhRz9NNrlY8PdUmTCnQj4RVJ/O72CVRvFeTrj l+aiV8XZHGJuZSgngSanMQOH4F7u6uMrRlZm+hv1GxXIP/2xVswhwbpknI1QbitBAjW8OBhao tmdzwOqH4lsEg0hvWL7PpdPkzETGbywuRjVi1rpL1KeqaSd0Qe1+AOTpX5FQAlY8TGCvFUBJz wP+WP6JXYq/9AW2hvHAWcS29HiivVMiLRp1BnKOtZrKGMp1PAeZfaFfXosLWgcbjokSIlwnB4 4W4jUcFxCZ53RR3qDwZCznrqkHms7w5g2JpNuIg92ljc2iyJ2GoHogCT3UlwhBsMOhOhnd7qR i5Gb64DQ8kkNN98CfyS/W2P/B6NFZa1b5fivl0qoxCVzkrBht6c1NoYn+v6sH/UPCCiwMm5j+ NerCWWMM/xKXY2kGPs933x4Gg0ZdRHHHt8gnKGr8VwMBWnc4K1j85T22eic+Uom9gzu1N6dLb Da3U4H9qbDs4Dw5EsgI3/F7/8c0mbGQ9XrsJ8bI/jXi3p8GJ86nj4cp2fwEtImXdu90/w1BGD JEIS9jphSO0+kMxzWQoanrPUqUqNLstp0OA8FJaJbsiZwgXd69BtUswVwxx1WhiJHpaenkMlK 7z9G3qE68uPkieqVx0ZOivIu7bNCYyQuu8x33ntv/AMjQlFkKbfPzEZQSxjgD7Pk1gXdhfQ88 31Cc47JhrBjnxXtx9wYJhisrNQ5M3uEZx9vRHpBlDoL0I6IoVDOLd6n5QyAG+b7lFIJX2YSHi qeU6ETQ9gYDLEpQcwtYkqpENfYGmk9xMtg2pW+3LDqiv9Tj509dx/v8GFIs1RNSls5LUI2uj9 rNPkxo3F78WZuxvSwHCmioBJqLJgzNjRItly6qJ2UQ8C9B/mikE1kXyEbP+h04euglkwbHL+Q ZuMpyMwCYHBB/DoFCG1X+7GvFNjXChMw7h/pmg0RVdoVxA1f7r2I4hugILmGgHmwAYPt3DERT Aqr0R//XqOWQuzNl5rWfg5dBbDqD/Qp1worL7HP/ZkNyTPMT62rQkcfFpEMmqmQ4zEOS8I914 d+M7F44xIqUxnJwBppyeo8Eu3+Fgk2PQCf+sEO6bTxtU7QYd3h7OOOaraJBRYY+qRaX2I=
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/Sfo8d_f027Jpg_-QRFAh6Mxvc8o>
Subject: Re: [Int-area] [Softwires] Errata on RFC 6333, "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion"
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 May 2021 14:40:10 -0000

Hi Éric,

My reading of the current RFC6333 text is that it is trying to highlight the importance of not fragmenting the IPv4 packet before encapsulation as this will break things. This, combined with ‘… after the encapsulation of the IPv6 packet.’ which should certainly be ‘… of the IPv4 packet.’ Is where the confusion is from.

So, as a minimum, the errata is correct regarding the encapsulated IP version.

Beyond that, I don’t find the remaining text to conflict with RFC2743 section 7.2. The text is only covering how to deal with packets that you will encapsulate and forward (DF=0) - case (b) in the RFC2473 text. Case (a) - DF=1 for received packet, so drop and send ICMP error isn’t discussed as these packets will not be encapsulated and need to be fragmented.

I do agree that this is open to misreading. How about the following wording to preserve (what I think is) the authors intention:

>    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.  For packets forwarded by the B4 element, fragmentation
          MUST happen after the encapsulation of the IPv4 packet.  Reassembly
    MUST happen before the decapsulation of the IPv4 packet.  A detailed
    procedure has been specified in [RFC2473]
> 
>    Section 7.2.



From Mikael’s comment:
"RFC2473 7.2 says to use the DF bit and decide whether to inner fragment or drop+send ICMP error."

I can’t find anything in the Section 7.2 text that would result in inner fragmentation.

Thanks,
Ian


> On 10. May 2021, at 15:36, Eric Vyncke (evyncke) <evyncke=40cisco.com@dmarc.ietf.org> wrote:
> 
> Dear ex-softwires WG, dear int-area WG,
>  
> Mikael Abrahamsson filed an erratum https://www.rfc-editor.org/errata/eid5847 <https://www.rfc-editor.org/errata/eid5847> in August 2019 (after the softwires WG closure) and, as the past responsible AD for softwires, I would like to fix this erratum but as Mikael I have no idea about the correction.
>  
> My own take is that the normative text in RFC 6333 indeed violates RFC 2473 for when the IPv4 DF is set... RFC 2473 appears to me as sensible and I would prefer to keep this behavior, i.e., see my suggestion below.
>  
> Than you in advance for your comments and suggestions,
>  
> Regards
>  
> -éric
>  
>  
> -- Existing text in RFC 6333 –
> Section 5.3 says:
> 
>    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.
>  
>  
> -- Comment by erratum submitter –
> 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?
>  
> -- Section 7.2 of RFC 2473 ---
>    When an IPv4 original packet enters a tunnel, if the original packet
>    size exceeds the tunnel MTU (i.e., the Path MTU between the tunnel
>    entry-point and the tunnel exit-point, minus the size of the tunnel
>    header(s)), it is handled as follows:
>  
>         (a)  if in the original IPv4 packet header the Don't Fragment  -
>              DF - bit flag is SET, the entry-point node discards the
>              packet and returns an ICMP message.  The ICMP message has
>              the type = "unreachable", the code = "packet too big", and
>              the recommended MTU size field set to the size of the
>              tunnel MTU - see sections 6.7 <https://datatracker.ietf.org/doc/html/rfc2473#section-6.7> and 8.3 <https://datatracker.ietf.org/doc/html/rfc2473#section-8.3>.
>  
>         (b)  if in the original packet header the Don't Fragment - DF  -
>              bit flag is CLEAR, the tunnel entry-point node encapsulates
>              the original packet, and subsequently fragments the
>              resulting IPv6 tunnel packet into IPv6 fragments that do
>              not exceed the Path MTU to the tunnel exit-point.
>  
>  
> -- Suggested new text by Éric Vyncke –
>    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 detailed procedure specified in [RFC2473]
>    Section 7.2 MUST be executed by the B4 element.
>  
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org <mailto:Softwires@ietf.org>
> https://www.ietf.org/mailman/listinfo/softwires <https://www.ietf.org/mailman/listinfo/softwires>