🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: dnet.ham
Article #207

Re: RFC1226 - Internet Protocol Encapsulation of AX.25 Frames

#207
From: uunet!samsung!swlvx2!anomaly.sbs...
Date: Fri, 17 May 1991 04:13
42 lines
2763 bytes
I generally agree with Anders' (Anders.Klemets@cs.cmu.edu) thorough reply to
my comments, but there are a few things I want to clarify.

With regard to timing, the IP bridge could take quite a long time.  There is
nothing that would prevent the establishment of an IP bridge over long
distances, even via satellite.  AX.25 fixed length timers do not allow this.
Although dynamically adjusting timers are in common use (in NOS, for example),
the formal protocol document specifies fixed length timers.  (See 2.3.5.4 of
the protocol.)

My suggestion about prohibiting digipeating across the IP bridge was meant to
encourage methods of routing other than digipeating.  In particular, if the
IP bridge acted like a NET/ROM node, the timing problem and so forth would
be solved, since the AX.25 timers would only have to run on acknowledgments
from each AX.25 user to the IP bridge, rather than end-to-end.  (Don't read
this as an endorsement of NET/ROM, but I'm making a point.)

Under no circumstances do I think that the AX.25 users should have access to
the routing information inside the IP bridge, such as the IP address of the
destination of frames travelling within the bridge.  What the AX.25 users
know can hurt them.

Again, I emphasize that digipeating is supposed to be phased out (in theory)
in favor of a more traditional ISO layer model.  Tying this RFC to the scheme
used for digipeating may cause trouble.  Here is the protocol speaking:

     These repeater stations simply extend the RF range of Amateur Radio
     stations.  Since they do not impose any flow controls, data switching,
     or routing, their inclusion at this layer does not imply any network-
     layer functions.  It is anticipated that repeater stations will be
     phased out (or at least their number greatly reduced) when a true
     network layer becomes operational.  (from Preface, "not a part of the
     protocol.")

As to the CRC issue Anders raises, it must b



e "calculated in accordance with ISO 3309".  (See 2.2.7)

-- Mike Bilow, N1BEE @ KA1RCI.RI.USA.NA  (AX.25)
               mikebw@idsvax.ids.com  (Internet)
Technical Details
Message-ID: <9105170137.AA01306@ray.com>
Path: arc1-ca.pugleaf.net!gmdzi!unido!infoac!news-mail-gateway

Show Full Headers
Complete Article Headers
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 12f11c,a6c936a51a0f492a
X-Google-Attributes: gid12f11c,public
X-Google-ArrivalTime: 1991-05-17 01:06:13 PST
Path: arc1-ca.pugleaf.net!gmdzi!unido!infoac!news-mail-gateway
From: mikebw@idsvax.ids.COM (uunet!samsung!swlvx2!anomaly.sbs.com!idsvax!mikebw
        mikebw@idsvax.ids.com)
Newsgroups: dnet.ham
Subject: Re: RFC1226 - Internet Protocol Encapsulation of AX.25 Frames
Message-ID: <9105170137.AA01306@ray.com>
Date: 17 May 91 04:13:12 GMT
Sender: daemon@infoac.rmi.de
Organization: RMI Net INFO.box Systems * Aachen * Hamburg * Flensburg
Lines: 42