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

From: "Iain R. Learmonth" <[email-masked]>
Date: Thu, 21 May 2020 08:25:11 +0100

Hi All,

I have just submitted a draft containing a refresh for RFC1226, "AX.25
over IP".

URL:
https://www.ietf.org/internet-drafts/draft-learmonth-intarea-rfc1226-bis-00.txt
Status:
https://datatracker.ietf.org/doc/draft-learmonth-intarea-rfc1226-bis/
Htmlized:
https://tools.ietf.org/html/draft-learmonth-intarea-rfc1226-bis-00
Htmlized:
https://datatracker.ietf.org/doc/html/draft-learmonth-intarea-rfc1226-bis

I am happy to receive any comments you may have. This draft has been
discussed within the TAPR APRSSIG mailing list, and that thread can be
found here:

http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/2020-May/048579.html

I plan to survey existing implementations to see whether or not they are
currently interoperable, and will be producing an implementation for
HamBSD (https://hambsd.org/).

Currently this is specified for unicast IP, however I can see benefits
to enabling multicast use. I would like to have multicast use covered in
this update.

There is also the question of UDP encapsulated AX.25 which currently
seems to have been made up by every implementation. I will include that
in my survey, and see if there can be some consensus drawn there. I'm
not sure if it is appropriate to add the UDP encapsulation details to
this draft, or if it would be preferred to make that a separate draft,
maybe even in a different area/WG.

Thanks,
Iain.

-------- Forwarded Message --------
Subject: New Version Notification for
draft-learmonth-intarea-rfc1226-bis-00.txt
Date: Thu, 21 May 2020 00:14:45 -0700
From: [email-masked]
To: Iain Learmonth <[email-masked]>, Iain R. Learmonth <[email-masked]>

A new version of I-D, draft-learmonth-intarea-rfc1226-bis-00.txt
has been successfully submitted by Iain R. Learmonth and posted to the
IETF repository.

Name:		draft-learmonth-intarea-rfc1226-bis
Revision:	00
Title:		Internet Protocol Encapsulation of AX.25 Frames
Document date:	2020-05-21
Group:		Individual Submission
Pages:		6

Abstract:
   This document describes a method for the encapsulation of AX.25 Link
   Access Protocol for Amateur Packet Radio frames within IPv4 and IPv6
   packets.  Obsoletes RFC1226.

Note

   Comments are solicited and should be addressed to the author(s).

   The sources for this draft are at:

   https://github.com/irl/draft-rfc1226-bis

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 21 May 2020 21:30:53 +0200

> 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.

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

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.

Alex

Le 21/05/2020 à 09:25, Iain R. Learmonth a écrit :
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area
>

---

From: "Iain R. Learmonth" <[email-masked]>
Date: Thu, 21 May 2020 21:09:00 +0100

Hi,

> 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

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  |
+-----------------+

> 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/

---

From: Joseph Touch <[email-masked]>
Date: Sat, 23 May 2020 10:24:56 -0700

Hi, all,

> On May 21, 2020, at 12:30 PM, Alexandre Petrescu <[email-masked]> wrote:
> 
> 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.

Joe

---

From: "Iain R. Learmonth" <[email-masked]>
Date: Sat, 23 May 2020 19:43:57 +0100

Hi,

On 23/05/2020 18:24, Joseph Touch wrote:
> 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.

Right.

> 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.

Negotiation of frame size in AX.25 only occurs in certain conditions,
and unlike for IP transport protocols, the path parameters will
generally be co-ordinated, agreed and known ahead of time. AX.25 is not
used for internetworking and this draft is closer to "Ethernet-over-IP"
than it is to "IP-over-IP" in that respect.

In the event that fragmentation is required, and the link is expected to
have higher levels of loss, I would just recommend against use of this
encapsulation rather than attempting PLPMTUD.

> 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.

Agreed.

Thanks,
Iain.

-- 
https://hambsd.org/

---

From: Erik Kline <[email-masked]>
Date: Sat, 23 May 2020 14:24:26 -0700

Iain,

Overall, LGTM.

Questions and notes:

[ section 3.2 ]

* Does "IPENC" need to be officially recorded in an official registry
somewhere?  Or has this already been done and a link to it can be
included in this draft?

I wasn't able to find this word in the APRS PDF linked to in the references.

[ section 5 ]

* Can you explain more about the limitations on non-NULL encryption?

My intuition would be that ESP with non-NULL encryption provides
privacy only on the IP links between tunnel endpoints.  A packet that
failed to decrypt properly would not be transmitted over the amateur
radio link, but rather be dropped by the IP endpoint (and possibly
logged).  I don't think I follow what the intent of this section is.

* I cannot find the phrase "dead peer detection" in RFC 7926, nor is
that the IKEv2 RFC.  I think perhaps you meant RFC 7296 (numeric
transposition).

---

From: Erik Kline <[email-masked]>
Date: Sat, 23 May 2020 15:35:00 -0700

> I wasn't able to find this word in the APRS PDF linked to in the references.

Ah, I think I see now that section 17 of that PDF refers to these as
"dummy callsigns".  It mentions "TCPIP", but there doesn't seem to be
any text significantly constraining these dummy callsigns.

So, I guess: don't mind me!

---

From: "Iain R. Learmonth" <[email-masked]>
Date: Sun, 24 May 2020 20:16:31 +0100

Hi,

> any text significantly constraining these dummy callsigns.

Indeed. There is not currently a registry of these dummy callsigns. The
only restriction is that they should not be confused with real
callsigns, and this is achieved by using only alpha characters. ITU
requires that callsigns use numerals to separate the prefix from the
suffix to avoid ambiguity between countries.

>> logged).  I don't think I follow what the intent of this section is.

I think that the problem with this section is that I've not been clear
that everything relates to the path between the tunnel endpoints. The IP
packets, not just the AX.25 packets, may traverse an amateur radio link.
Microwave links using modified wifi equipment to operate in the amateur
bands are common, for example, and could carry an AX.25 tunnel over IP
between two AX.25 hosts. Encryption is forbidden on that IP microwave
link, just as it is on the AX.25 links.

I do not want to forbid the use of non-NULL encryption. This phrasing
may also be misleading as RFC4543 also provides encryption transforms
that do not provide confidentiality. Instead of talking about NULL
specifically, this could be changed to require use of a transform that
does not provide confidentiality.

Would these changes answer the question?

>> that the IKEv2 RFC.  I think perhaps you meant RFC 7296 (numeric

Well caught! I did indeed mean the IKEv2 RFC.

Thanks,
Iain.

-- 
https://hambsd.org/

---

From: Erik Kline <[email-masked]>
Date: Sun, 24 May 2020 22:19:58 -0700

> Would these changes answer the question?

I think it might be good to call out that any traffic traversing AX.25
needs to be unencrypted due to $REGULATION or something.

Separately, it could be clearly stated that encryption is RECOMMENDED
for links that can be known (or reasonably expected) to not traverse
any AX.25 links.