🚀 go-pugleaf

A very interesting idea.  A couple of points:

1.  I think the proposal to retain the AX.25 FCS within the IP datagram is
a good one.  This might seem redundant, and might even be a little tough to
implement in some cases, but it provides some security against corruption
by hardware and software along the line.

2.  How do we handle the decision about whether to use the IP bridge?  Of
course, in "real" protocols, you don't code routing info into the datagram,
but let the network handle it in accordance with the ISO layered model.  But
AX.25 specifically authorizes such things as "digipeating" on a temporary
basis (which means until something freezes over), which involves the inclusion
of routing information inside the datagram?  Put more simply, does the IP
bridge get a pseudo-callsign so that it is explicitly listed in the AX.25
frame as a pseudo-digipeater?

3.  How do we handle the AX.25 timers across the IP bridge?  Shouldn't we at
least require that the timers be adjusted dynamically from end to end on the
AX.25 circuit?  What happens if regular AX.25 people try to communicate with
each other over the IP bridge using standard fixed-length timers, especially
ones that are too short?

4.  If we want to avoid the problems of 2 and 3 above, should we prohibit the
carrying of digipeated frames across the IP bridge?  In essence, this would be
saying to the AX.25 users, "OK if you want to talk across the IP bridge, but
you have to pretend that you are connected directly and let the IP bridge do
your routing transparently."

5.  How do we handle callsign aliasing?  If W1AAA and K0ZZZ want to talk across
the IP bridge, does the IP bridge appropriate the callsign "K0ZZZ" when it
talks on its port to W1AAA, and vice versa?  This is how NET/ROM works, where
W1AAA would connect to the NET/ROM system, then via a NET/ROM circuit to the
node that services K0ZZZ, and then that node would connect to K0ZZZ using the
alias callsign W1AAA-15.  (This assumes that neither W1AAA nor K0ZZZ are
NET/ROM nodes themselves; if they were, it would be handled less stupidly.)

6.  A big question in my mind is how we handle ISO layer protocols above 2
when implemented in AX.25?  Put simply (I love that phrase), what happens when
an AMPRNET or NET/ROM circuit must use the IP bridge?  AMPRNET encapsulates
IP in AX.25 frames, so would this result in IP frames being encapsulated in
AX.25 frames which are then encapsulated in IP frames per this RFC?  And can
this go on for any number of iterations?

7.  Considering point 6 at its logical conclusion, if we have a method of
encapsulating IP within AX.25 -- which is what AMPRNET is -- would we be
better off not allowing encapsulation of AX.25 within IP?  Doing so would
eliminate all of these concerns about callsigns and timing in one fell swoop.
Would there be any loss of functionality by requiring that AX>25 users who
want to use an IP bridge encapsulate their data in IP frames, as is done on
AMPRNET, rather than the reverse as proposed by this RFC?

8.  A final point... is there anything in this proposal that creates a hidden
tie to AX.25 version 2.0?  What happens if there is a version 3.0 that allows
such things as multiple frame distribution by tree routing, or token passign,
or different acknowledgment traffic patterns?

-- Mike Bilow, N1BEE @ KA1RCI.RI.USA.NA  (AX.25)
               mikebw@idsvax.ids.com  (Internet)