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

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

Joe

— 
Joe Touch, temporal epistemologist
www.strayalpha.com

> On Dec 3, 2021, at 8:32 AM, Scharf, Michael <Michael.Scharf@hs-esslingen.de> wrote:
> 
> 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 <mailto:tcpm-bounces@ietf.org>> On Behalf Of touch@strayalpha.com <mailto:touch@strayalpha.com>
> Sent: Wednesday, December 1, 2021 5:48 AM
> To: Wes Eddy <wes@mti-systems.com <mailto:wes@mti-systems.com>>
> Cc: tcpm IETF list <tcpm@ietf.org <mailto: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 <https://www.ietf.org/mailman/listinfo/tcpm>