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

"Iain R. Learmonth" <irl@hambsd.org> Thu, 21 May 2020 20:09 UTC

Return-Path: <irl@hambsd.org>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06A0C3A073D for <int-area@ietfa.amsl.com>; Thu, 21 May 2020 13:09:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.118
X-Spam-Level:
X-Spam-Status: No, score=-1.118 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 Yl5iomJXAYQ3 for <int-area@ietfa.amsl.com>; Thu, 21 May 2020 13:09:21 -0700 (PDT)
Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0ACDE3A0A3D for <Int-area@ietf.org>; Thu, 21 May 2020 13:09:05 -0700 (PDT)
Received: from bell.riseup.net (bell-pn.riseup.net [10.0.1.178]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.riseup.net", Issuer "Sectigo RSA Domain Validation Secure Server CA" (not verified)) by mx1.riseup.net (Postfix) with ESMTPS id 49SggP0hpBzFffF; Thu, 21 May 2020 13:09:05 -0700 (PDT)
X-Riseup-User-ID: B1419D97B7841566B38458CE5640E16A94FA5BB8CE18A5E7F78B9F86DD951B87
Received: from [127.0.0.1] (localhost [127.0.0.1]) by bell.riseup.net (Postfix) with ESMTPSA id 49SggN2jC9zJnSG; Thu, 21 May 2020 13:09:04 -0700 (PDT)
To: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Cc: Int-area@ietf.org
References: <159004528499.11433.5479167060208316355@ietfa.amsl.com> <90e3bce1-cd60-b45b-d4d9-11da99ee2093@hambsd.org> <a6da6556-a5b0-dd28-b7f7-c4298237d867@gmail.com>
From: "Iain R. Learmonth" <irl@hambsd.org>
Organization: HamBSD Project
Message-ID: <d8fd04c2-5dc5-d793-692a-4906a9a189ef@hambsd.org>
Date: Thu, 21 May 2020 21:09:00 +0100
MIME-Version: 1.0
In-Reply-To: <a6da6556-a5b0-dd28-b7f7-c4298237d867@gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/5Y2PnlDX0h_pT55NVD4NX2VvakU>
Subject: Re: [Int-area] draft-learmonth-intarea-rfc1226-bis-00
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 May 2020 20:09:23 -0000

Hi,

On 21/05/2020 20:30, 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.
> 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.

I'm happy to reword this as long as the semantic meaning does not
change, however, removing IPv4 would effectively make this process
meaningless. 100% of the current deployment (that I'm aware of) uses
IPv4. Any hope of transitioning towards IPv6 will depend on a transition
step, which requires the co-existence of the two protocol versions for a
time.

For IPv4, the minimum size that a host must accept is 576, which is
greater than the minimum MTU. 330 is less than 576 but I don't think it
is redundant to specify the size of the AX.25 frame that you end up with
after decapsulation.

> A packet dump, or an illustration diagram, showing an AX.25 carried in
> IPv6 would be helpful.

This would be a very simple diagram I guess:

+-----------------+
|   IP Header     |
+-----------------+
|  AX.25 Header   |
+-----------------+
|  AX.25 Payload  |
+-----------------+

Or, including security considerations recommendations:

+-----------------+
|   IP Header     |
+-----------------+
|   ESP Header    |
+-----------------+
|  AX.25 Header   |
+-----------------+
|  AX.25 Payload  |
+-----------------+

> AX.25 is related to X.25 but remark: X.25 might carry IP packets,
> whereas IP packets might carry AX.25.  If I understand correctly.

The relationship between AX.25 and X.25 is really of historic interest.
It is possible to put AX.25 inside IP, and it's possible to put IP
inside AX.25. There are several schemes used for encapsulating IP in
AX.25 however none of them are defined in IETF documents. As I implement
them, I may try to write up more drafts. Let's see how this one goes first.

Thanks,
Iain.

-- 
https://hambsd.org/