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

From: Wesley Eddy <[email-masked]>
Date: Tue, 30 Nov 2021 21:35:18 -0500

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).

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 30 Nov 2021 20:47:17 -0800

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

> On Nov 30, 2021, at 6:35 PM, Wesley Eddy <[email-masked]> 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]
> 
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 30 Nov 2021 20:48:11 -0800

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

—

> On Nov 30, 2021, at 8:47 PM, [email-masked] wrote:
> 
> Hi, Wes,
> 
> www.strayalpha.com <http://www.strayalpha.com/>
> 
>> On Nov 30, 2021, at 6:35 PM, Wesley Eddy <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> [email-masked] <mailto:[email-masked]>