Re: [Int-area] draft-learmonth-intarea-rfc1226-bis-00

Joseph Touch <> Sat, 23 May 2020 17:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0B59A3A0CF4 for <>; Sat, 23 May 2020 10:49:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.318
X-Spam-Status: No, score=-1.318 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5mOdVA7ZbfUu for <>; Sat, 23 May 2020 10:49:42 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 985B33A0CCF for <>; Sat, 23 May 2020 10:49:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=P3yxDDxazCmlPGhrWvmY6yhHBMzDGs7vZAYx1br4skA=; b=bEJ8r27pZnlk0g6ke2o0WxRn1 LXoPzai7HgZH4a93nDcVfElcACquAMawthitkhrFFFTsejqWmIb74fzMtGqh42l160IX07cElRzEK w3vnHRc5cJPzBJJhDbDSuAoGZfJOQQfIIW6fjOdeL/kf6yZIDMipfGEEzxVLelMnJcmybFZXHsOwi 7py74m6JCnijho4O3g9wHue9roNurYvoveSdZgYrMhvwLjzcYIMfYXdCWiwq+FJYwqdKivyJVDbBX GBR/siGtGCp6tlX3grX5CF6V3QLeL1hFXFDRTkeorvVr662yF1yIJFou34XGt7oFoQ0siX+QbsJ2D HXVX7Ly7w==;
Received: from ([]:63266 helo=[]) by with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from <>) id 1jcXtI-0045LY-OQ; Sat, 23 May 2020 13:25:01 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_FC883532-C8FF-4137-B5BA-2F4B71DE996F"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
From: Joseph Touch <>
In-Reply-To: <>
Date: Sat, 23 May 2020 10:24:56 -0700
Cc: "Iain R. Learmonth" <>,
Message-Id: <>
References: <> <> <>
To: Alexandre Petrescu <>
X-Mailer: Apple Mail (2.3608.
X-OutGoing-Spam-Status: No, score=-0.5
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-Get-Message-Sender-Via: authenticated_id:
X-From-Rewrite: unmodified, already matched
Archived-At: <>
Subject: Re: [Int-area] draft-learmonth-intarea-rfc1226-bis-00
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Internet Area Mailing List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 23 May 2020 17:49:44 -0000

Hi, all,

> On May 21, 2020, at 12:30 PM, Alexandre Petrescu <> wrote:
>> For AX.25 version 2.0, the
>>   maximum frame size expected is 330 bytes and implementations MUST be
>>   prepared to handle frames of this size.  Higher frame sizes can be
>>   negotiated by AX.25 version 2.2 and so this is a minimum requirement
>>   and not a limit.
> It is ok.   For IPv6, the minimum MTU (minimum Maximum Transmission Unit) is 1280 bytes.

There are several maximums that are relevant - path MTU is only one of them, and not necessarily the one that is relevant here.

For this protocol, all you really care about is EMTU_S (as defined in RFC1122 - see draft-ietf-intarea-tunnels, which admittedly needs to be refreshed in ample spare time).

For IPv6, this is 1500; for IPv4 it is 576. Those are more than sufficient if you aren’t significantly affected by packet loss per se, which *can* be amplified by source fragmentation, but that might not be relevant in this case.

If you want to talk about performance under certain losses where fragmentation causes a known problem, you should add an additional suggestion to do path MTU discovery (PLPMTUD - which you SHOULD really build in if it isn’t there yet), because otherwise you’re stuck with the path mins of 1280 for IPv6 and (sorry, still) 64 for IPv4.

> For IPv4, it is not worth mentioning.  One, including myself, would go as far as suggesting to remove the IPv4 keyword from the draft altogether.

Although I agree all new drafts need to address IPv6, it’s naive to ignore IPv4 - especially for a protocol such as this, which is, if anything, more likely to operate using legacy equipment.