Re: [tsvwg] Initial handshaking and PMTU in RFC9260 Thu, 06 April 2023 16:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D7676C152A32 for <>; Thu, 6 Apr 2023 09:52:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id M92oUiH72kbN for <>; Thu, 6 Apr 2023 09:52:46 -0700 (PDT)
Received: from ( []) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id F0043C152A38 for <>; Thu, 6 Apr 2023 09:52:44 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTPS id 4CC4620613; Thu, 6 Apr 2023 18:52:42 +0200 (CEST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: tuexen) by (Postfix) with ESMTPSA id 044941A004A; Thu, 6 Apr 2023 18:52:41 +0200 (CEST)
Content-Type: multipart/signed; boundary="Apple-Mail=_3ABF93F7-A36D-4A99-9C64-4BE8A4BADD60"; protocol="application/pkcs7-signature"; micalg="sha-256"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.500.231\))
In-Reply-To: <>
Date: Thu, 06 Apr 2023 18:52:41 +0200
Cc: tsvwg IETF list <>, Randall Stewart <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Claudio Porfiri <>
X-Mailer: Apple Mail (2.3731.500.231)
Archived-At: <>
Subject: Re: [tsvwg] Initial handshaking and PMTU in RFC9260
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 06 Apr 2023 16:52:47 -0000

> On 5. Apr 2023, at 15:03, Claudio Porfiri <> wrote:
> The SCTP protocol specifies that INIT ACK contains the State Cookie and that such State Cookie shall be kept as small as possible but it can be up to 2^16 bit.
Hi Claudio,

the INIT ACK chunk can be up to 2^16 byte and contains the state cookie as a mandatory parameter. So
the state cookie can't be 2^16 bytes, since it needs to fit into the INIT ACK chunk. But in general:
yes, this can be large and in the order of 64KB.
Although I haven't see in practice (!= testing) such large state cookies or INIT ACK chunks.
> The COOKIE ECHO shall also contain the State Cookie received in INIT ACK.
> An Implementation Note in Section 3.3.3 also specifies that
> An implementation MUST be prepared to receive an INIT ACK chunk that is quite large (more than 1500 bytes) due to the variable size of the State Cookie and the variable address list. For example, if a responder to the INIT chunk has 1000 IPv4 addresses it wishes to send, it would need at least 8,000 bytes to encode this in the INIT ACK chunk.
That is correct.
>  A large State Cookie may lead to an SCTP Packet larger than the PMTU and the recommendation doesn’t provide a description of SCTP packets containing Control Chunks for being split.
RFC 9260 describes how to fragment a user message into multiple DATA chunks and also how to do the reassembly.
However, you can't fragment control chunks. Partial chunks are explicitly not allowed. Therefore, if an SCTP
implementation needs to send a control chunk which exceeds the PMTU, this must be done by using IP level
> May be beneficial if the Implementation Note in Section 3.3.3 also recommends to set the IP “Don’t Fragment” BIT to FALSE during initial handshake?
This is left implementation dependent. For example, the sender of the packet containing an INIT chunk (which can also
be large), might set the DF flag on the transmission, but not on retransmissions. This would allow to learn the
PMTU if a PTB message is sent back (and the reflected packet contains the initiate tag) and would survive the handshake
on the first retransmission. If you prefer to finish the association setup fast and will don't want to learn about
PMTU limits, you might send also the initial transmission with the DF bit cleared. The same applies to the COOKIE ECHO.
Things are different for the INIT ACK, since you don't have an TCB. So you might send that with the DF bit cleared.
A COOKIE ACK is small... However, all this is IPv4 specific.

Right now, FreeBSD sends the INIT and INIT ACK, and the COOKIE ECHO with the DF bit cleared. But that is an implementation
choice and one might do it differently for the INIT and COOKIE ECHO.

Best regards
>  Thanks,
> Claudio Porfiri