IETF Logo Mail Archive

Re: [tcpm] 793bis IESG comment on NAT64 and MSS

"Scharf, Michael" <Michael.Scharf@hs-esslingen.de> Fri, 03 December 2021 16:32 UTC

Return-Path: <Michael.Scharf@hs-esslingen.de>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F47F3A0BFA for <tcpm@ietfa.amsl.com>; Fri, 3 Dec 2021 08:32:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=hs-esslingen.de
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 JZ8AeIXIlq0C for <tcpm@ietfa.amsl.com>; Fri, 3 Dec 2021 08:32:45 -0800 (PST)
Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E20943A0BDB for <tcpm@ietf.org>; Fri, 3 Dec 2021 08:32:44 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id D7A8C25A28; Fri, 3 Dec 2021 17:32:42 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1638549162; bh=S4gDyHXPL/XONQAHsgW5GoSiGQXDjcysG9+908FJJ6M=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=qlfLu5M9aytUG+HTzbcXeKoUT9g1DMfQtaWBXjjwYKEE5/cjAGD2MASk/5Zbv04qo brE716XTFlVULfWj69psGSNvTje9aaobEXKHpKwoWdV/JoxdYrkRx1vPYo8oGh06X6 PkjRqb+BBjkteVRGqFUFmREvixdG7dBwA8dSP3Tk=
X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de
Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tr4kKUNLoY8L; Fri, 3 Dec 2021 17:32:41 +0100 (CET)
Received: from rznt8202.rznt.rzdir.fht-esslingen.de (rznt8202.hs-esslingen.de [134.108.48.165]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Fri, 3 Dec 2021 17:32:41 +0100 (CET)
Received: from rznt8202.rznt.rzdir.fht-esslingen.de (134.108.48.165) by rznt8202.rznt.rzdir.fht-esslingen.de (134.108.48.165) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.14; Fri, 3 Dec 2021 17:32:41 +0100
Received: from rznt8202.rznt.rzdir.fht-esslingen.de ([fe80::aca4:171a:3ee1:57e0]) by rznt8202.rznt.rzdir.fht-esslingen.de ([fe80::aca4:171a:3ee1:57e0%3]) with mapi id 15.01.2176.014; Fri, 3 Dec 2021 17:32:41 +0100
From: "Scharf, Michael" <Michael.Scharf@hs-esslingen.de>
To: "touch@strayalpha.com" <touch@strayalpha.com>, Wes Eddy <wes@mti-systems.com>
CC: tcpm IETF list <tcpm@ietf.org>
Thread-Topic: [tcpm] 793bis IESG comment on NAT64 and MSS
Thread-Index: AQHX5lwjE6pHXjvXTEu6RuL8l8DEGawc/4yAgAAAQYCAA/kBQA==
Date: Fri, 03 Dec 2021 16:32:41 +0000
Message-ID: <483cb6c3a12945e589ee047b70c65b0d@hs-esslingen.de>
References: <78967f83-12a1-7f0c-4919-833e5120b49b@mti-systems.com> <9AAF79C1-9F0B-4CF0-9A77-13D97C0F8308@strayalpha.com> <393BB7C5-3676-4FC8-A736-C830B0F99E76@strayalpha.com>
In-Reply-To: <393BB7C5-3676-4FC8-A736-C830B0F99E76@strayalpha.com>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [134.108.140.248]
Content-Type: multipart/alternative; boundary="_000_483cb6c3a12945e589ee047b70c65b0dhsesslingende_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/NZVE5iw_7_H2XS4w4pLk-Hpt3U4>
Subject: Re: [tcpm] 793bis IESG comment on NAT64 and MSS
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Dec 2021 16:32:51 -0000

I agree. 793bis may not be the best place for fixing NAT64.

Maybe the issue could be addressed by filing an erratum to RFC 6146?

Michael (again, no hat)


From: tcpm <tcpm-bounces@ietf.org> On Behalf Of touch@strayalpha.com
Sent: Wednesday, December 1, 2021 5:48 AM
To: Wes Eddy <wes@mti-systems.com>
Cc: tcpm IETF list <tcpm@ietf.org>
Subject: Re: [tcpm] 793bis IESG comment on NAT64 and MSS

(To be clear - I am referring to the existing text as being sufficient).

—
Joe Touch, temporal epistemologist
www.strayalpha.com<http://www.strayalpha.com>


On Nov 30, 2021, at 8:47 PM, touch@strayalpha.com<mailto:touch@strayalpha.com> wrote:

Hi, Wes,

IMO, the text is clear and sufficient. There are many reasons why the MSS should be sent or why it could be asymmetric (e.g., asymmetric routes with different tunnels); it doesn’t make sense to try to list them all or highlight any.

I agree this probably should have been dealt with in RFC6146, but adding this to TCPbis is not an appropriate fix for that omission.

Joe

—
Joe Touch, temporal epistemologist
www.strayalpha.com<http://www.strayalpha.com/>


On Nov 30, 2021, at 6:35 PM, Wesley Eddy <wes@mti-systems.com<mailto:wes@mti-systems.com>> wrote:

Here is another interesting point in the IESG ballots from Erik Kline that it would be good to get list feedback on:

[S3.7.1, comment]



* In networks where NAT64 is employed, the default MSS assumed by a sender

  will differ from the default assumed by a receiver, since the address

  families sent and received will be different.



  This may bolster the case for MAY-3 being a SHOULD (or even a MUST ;-) but,

  more to the point, may be a caveat to note w.r.t. SHLD-5.



  Alas, I could find no discussion of MSS option handling in RFC 6146,

  so I wonder if that's something that we missed...
For reference, MAY-3 and SHLD-5 come from:
   TCP implementations SHOULD send an MSS option in every SYN segment
   when its receive MSS differs from the default 536 for IPv4 or 1220
   for IPv6 (SHLD-5), and MAY send it always (MAY-3).
It's not entirely clear to me whether there is something within the 793bis scope to do about this, or if it should be saved as a possible bit of "future work" for maintenance regarding NAT64 and transport notions of MSS (which should impact more than just TCP).

_______________________________________________
tcpm mailing list
tcpm@ietf.org<mailto:tcpm@ietf.org>
https://www.ietf.org/mailman/listinfo/tcpm

v2.23.0 | Report a Bug | By Email