[tcpm] Exceeding value in MSS option?

Martin Duke <martin.h.duke@gmail.com> Mon, 19 October 2020 19:22 UTC

Return-Path: <martin.h.duke@gmail.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 7117C3A003F for <tcpm@ietfa.amsl.com>; Mon, 19 Oct 2020 12:22:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.197
X-Spam-Level:
X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 rVgXkfNVTLEd for <tcpm@ietfa.amsl.com>; Mon, 19 Oct 2020 12:22:55 -0700 (PDT)
Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 092013A0039 for <tcpm@ietf.org>; Mon, 19 Oct 2020 12:22:55 -0700 (PDT)
Received: by mail-io1-xd2e.google.com with SMTP id q25so1102678ioh.4 for <tcpm@ietf.org>; Mon, 19 Oct 2020 12:22:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=CvaN0IhOolErHg5e5RK8cLh93uCpBytFPoOC3Y6XT2w=; b=S3do2AYk2Pyb4morxiLI0xC64YX4qYGWqkp84w3Hbt/wRuTLSqMxjzOBq6zXFk5y88 /iNTxwRSPnq0ftHUcp8wNK8tcTPDzqn1FkJPy27R2UgQBACmSRGPFJZcznadcf6tD2j5 J3JiW+R3tZZ2M7GPGJTrA8cA0Bfy1NtoGCDYyjoBpUnSWElYn9+YSSJWnSqdrODDu/pT PLF6kZZRZ+EmhVeL8Gwcc25yTxGgD9SZva3rRhrvzPenTwTcFwkf+tHcz1JkB+gDS8Fs +73Mlc+wQp48bPfFv2q9MIguGj6aL3/qL9UTO127gGfCDCWB41wWQvkG9WyvOgCTKuOE AM2Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=CvaN0IhOolErHg5e5RK8cLh93uCpBytFPoOC3Y6XT2w=; b=qLZZewtm6clSElQYtVEUtLAbEtU/GajpcvRIAoLyl/hdRGOW71Es1cEoe/FM3DC9dq ExB85Wnijfjs22RvXs1MZ+sY+w5ycH3ZSTe+iGGm7Iwv5O9MLFKmqi0g40he736VFaek tmvuj3uQSZUKrBFEJUYDO36CL/bq7/3bcJDnVUzoGLOTWxHYrSMF0Pmt322sq5f3R2tx FZvfkSmuAQb/TYnvjw2eX+WFpn3U0LlUgVupO+zQaxkQy+mxydMXK9SUdmZIjolzuzhX 0NBpwiSwJhrDq/9gFmv2IdGdB9f5OJ0kxW1wrJuiwFkC5zRwIcqhVW4wn8s2CMfltIiI h8kg==
X-Gm-Message-State: AOAM533sfX//d8OfimpwXScWhgY3oLCbyVIlCWX/35RHa4vpD34R4r0p 4LxqbtJ6EacklqZ15VvBedYaEWuyA841i2QooyAavLhXKyUEXw==
X-Google-Smtp-Source: ABdhPJy1hzUIuNr0ugrxIBYEqov3EtNkrXJApjaFYZvMMSB8nUyIs6L+e2eS9FMypPe8VMuSXhTzKOOoTFuwJKWQEvI=
X-Received: by 2002:a02:b80f:: with SMTP id o15mr1216048jam.103.1603135374134; Mon, 19 Oct 2020 12:22:54 -0700 (PDT)
MIME-Version: 1.0
From: Martin Duke <martin.h.duke@gmail.com>
Date: Mon, 19 Oct 2020 12:22:43 -0700
Message-ID: <CAM4esxQzydPBTjVQvtp3766mCH5L65LdRSkFzQkdeKgUfhKacA@mail.gmail.com>
To: "tcpm@ietf.org Extensions" <tcpm@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000080927105b20b0a18"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/qJHHq1MM4xB6AA2qJGdWYQcpZpY>
Subject: [tcpm] Exceeding value in MSS option?
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: Mon, 19 Oct 2020 19:22:56 -0000

Hello tcpm,

Section 4.2.2.6 of RFC 1122
<https://datatracker.ietf.org/doc/html/rfc1122#page-85> is pretty clear
that the TCP sender MUST consider all IP and TCP options when sizing
payloads with respect to the advertised MSS option.

I'm reviewing a document
<https://datatracker.ietf.org/doc/html/draft-ietf-lwig-tcp-constrained-node-networks-11#section-4.1.1>
that advises that some endpoints may want to reduce their advertised MSS on
IPv6 connections in case the peer isn't respecting that guidance. Is
noncompliance with this provision a problem in the internet? Are there
middleboxes injecting options that cause PMTU drops or fragmentation?

I have not heard of such problems, but thought I'd check with the community
to see if this precaution makes any sense at all.

Thanks,
Martin