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

From: "Scharf, Michael" <[email-masked]>
Date: Fri, 3 Dec 2021 16:32:41 +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 <[email-masked]> On Behalf Of [email-masked]
Sent: Wednesday, December 1, 2021 5:48 AM
To: Wes Eddy <[email-masked]>
Cc: tcpm IETF list <[email-masked]>
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, [email-masked]<mailto:[email-masked]> 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 <[email-masked]<mailto:[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]

* 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
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tcpm

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 3 Dec 2021 09:45:32 -0800

I agree with this being more appropriately an erratum to one or more of the NAT docs.

Joe

— 
www.strayalpha.com

> On Dec 3, 2021, at 8:32 AM, Scharf, Michael <[email-masked]> wrote:
> 
> From: tcpm <[email-masked] <mailto:[email-masked]>> On Behalf Of [email-masked] <mailto:[email-masked]>
> To: Wes Eddy <[email-masked] <mailto:[email-masked]>>
> Cc: tcpm IETF list <[email-masked] <mailto:[email-masked]>>
> www.strayalpha.com <http://www.strayalpha.com/>
> 
> 
> On Nov 30, 2021, at 8:47 PM, [email-masked] <mailto:[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]>
> https://www.ietf.org/mailman/listinfo/tcpm <https://www.ietf.org/mailman/listinfo/tcpm>