IETF Logo Mail Archive

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

"touch@strayalpha.com" <touch@strayalpha.com> Wed, 01 December 2021 04:48 UTC

Return-Path: <touch@strayalpha.com>
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 912403A0A7E for <tcpm@ietfa.amsl.com>; Tue, 30 Nov 2021 20:48:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.318
X-Spam-Level:
X-Spam-Status: No, score=-1.318 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, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com
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 21hP3gOcXvOg for <tcpm@ietfa.amsl.com>; Tue, 30 Nov 2021 20:48:17 -0800 (PST)
Received: from server217-1.web-hosting.com (server217-1.web-hosting.com [198.54.114.226]) (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 0841C3A0A81 for <tcpm@ietf.org>; Tue, 30 Nov 2021 20:48:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=PBuzzLJI4CApoL6PckL44g8d0OdwLraafwPsH7XKahg=; b=o6xRxQhOSQkASKSq2nOIVEkVGX 71l4wS8GarDA4uIjHhLjT0OWwmENH2mxy13MuG0Lp4csj8U4AvziD8CeYzKmqWjJFYICx87AHyppk Yj7MP9hQLl/GUUYMrMjbaph+5ySVyWgW7bt10L9TKbTTyt957Ko+1713c24GeqT9RRtOsHSbA/aqX v3I+xbHI096ArAYbVAdbYUjhbK2qKHO5IPxZosOsbVq4mRXH3xAlHbHi6dZ6evo/qquRwwn6dJcHK wcOZv17a8ir5VP5P+FcPGY4lGdh363Bqoh3cFeEPcX95hUpdfhcgWRbFP3Pcedz9vHOm6EeBA8HGh mPs3P7hA==;
Received: from cpe-172-114-237-88.socal.res.rr.com ([172.114.237.88]:59720 helo=smtpclient.apple) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <touch@strayalpha.com>) id 1msHXP-0037OW-Un; Tue, 30 Nov 2021 23:48:16 -0500
Content-Type: multipart/alternative; boundary="Apple-Mail=_4223C1FB-F7F0-4D43-ADA4-5651911DA980"
Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.20.0.1.32\))
From: "touch@strayalpha.com" <touch@strayalpha.com>
In-Reply-To: <9AAF79C1-9F0B-4CF0-9A77-13D97C0F8308@strayalpha.com>
Date: Tue, 30 Nov 2021 20:48:11 -0800
Cc: tcpm IETF list <tcpm@ietf.org>
Message-Id: <393BB7C5-3676-4FC8-A736-C830B0F99E76@strayalpha.com>
References: <78967f83-12a1-7f0c-4919-833e5120b49b@mti-systems.com> <9AAF79C1-9F0B-4CF0-9A77-13D97C0F8308@strayalpha.com>
To: Wes Eddy <wes@mti-systems.com>
X-Mailer: Apple Mail (2.3693.20.0.1.32)
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server217.web-hosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - strayalpha.com
X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com
X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com
X-Source:
X-Source-Args:
X-Source-Dir:
X-From-Rewrite: unmodified, already matched
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/JpzMxDcaGDpcgsCdhZzjaglxfcA>
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: Wed, 01 Dec 2021 04:48:22 -0000

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

—
Joe Touch, temporal epistemologist
www.strayalpha.com

> On Nov 30, 2021, at 8:47 PM, 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