FidoNet over IP, Part 1 of 4

© 1998 by Lothar Behet

Part 1:
What is Fidonet over IP?

Fidonet-over-IP (later called "FIP" in this article) tries to integrate another medium as carrier-service beside the conventional telephony connectivity.

The most basic technical specification of Fidonet (FTS-1, version 15, dated Aug. 30 1990) describes the handshake procedure, as it can be used within conventional pstn environments. Foreseeing the technical development, Chapter H leaves room for future extensions:

H. Physical Layer : the Actual Connection of Two FidoNet Systems

Will one of the more hardware-oriented comm types give me some idea of what's needed here? Can we leave it open enough to allow implementation over a non-dial net? Thanks.

The internet is just one more possible physical layer in place of a direct (sometimes quite expensive) connection between two nodes.

It may be discussed, if FTS-1 handshake specification is required for a fidolike connection via the internet, but in any case the nodelist based data should be directly used for the dial attempt and the (possible) authentication of a direct session using another carrier. So the transfer of data via FTP (direct connection, but completely independant of any nodelist data) or Email based methods (just delivering something to a mailbox) are not fido-like in the direct sense of FIP.

The Nodelist:

For this connection one data is required in any case:
The replacement for the phone-number is the ip-nummber, i.e. 194.231.142.17. Furthermore the internet utilizes the DNS (Domain Name Service) for a more mnemonic presentation (FQDN, Fully Qualified Domain Name) of the same system, i.e. fido.nrh.de.
The use of DNS gives additional advantages:
- load balancing between several computers for the same service
- backup against system failure
But DNS has one real shortcoming:
It does not fit in any way in the nowadays used nodelist format, based on FTS-5 (released 5. February 1989).

This so called St.Louis-format has only one entry for a "connection point", which is basically defined as sequence of numbers, seperated by dashes. Other characters may not be used in this field, as several (older) programs can not handle other contents. But there is a solution:
Not one system using the nodelist can dial a number without a dial translation table, as the data in the nodelist is normally undiable by itself. So the utilization of an unused country code gives room for suppression of dial attempts on ip-numbers by conventional pstn users.

The selection of the country code "000" in Z2 was taken after some discussion, as this prefix is an emergency code in some countries. But any other prefix is or may be used for legal country codes at a given time and only under very rare circumstances (the sysop twit with a dial translation enabling this number) a call would by made by a modem.

Another solution is defining another field for the ip-address, which is possible by itself, as older software would in no case use it for a connection.

• Flag field: any content may be possible here, but some programs only take care of the first 32-64 characters of it (and we need this room later, as you will see :).
• Location field: it normaly gives information about the geographical position of the individual node, which is redundant to the phone number. But ip-numbers are not geographically oriented and and the fqdn may be any sequence of characters.
• System name field: it serves sometimes as an additional "human readable flag extension" and sometimes shows the "hidden ego" of the sysop.

As shown above, the system name field would be the logical decision under technical aspects, as it serves the least significant part of information of these three, while on the other hand the FQDN may be defined in a wide range (something like "mybbs.mydomain.org").

There surely are other solutions for the nodelist problem:

1. Define a completely new nodelist structure, which contains any valuable information about all connectivity variants of a given node. This might be a future project, but when will this future become reality?
2. utilize pure internet techniques for ip-connectivity, i.e. fidonet.net in eastern europe. This method is nearly completely independant from nodelist data, except that the address presentation f3000.n2.z2.fidonet.net looks like the addressing schedule for gateways in the fidonet.org domain.

The next part will contain an exerpt about actual used protocols for FIP.

What do I need for it?

Beside the direct transfer of any data via FTP (File Transfer Protocol) or Email, the internet supports the tunneling of protocol data, based on other structures, in ip-packets. This is used by FIP to establish a direct, password-secured connection between any two nodes with the internet as alternative carrier. Only for the time of this connection both nodes need to be hooked up to the internet. Depending on the actual implementation, the data may be transfered by a normal mailer or an especially for ip-transfer designed program, whereas (in future) nodelist contents will be used directly for dialing and authentication purposes.

Available Programs

1. BinkD is a pure mailer, which uses the known Binkley style outbound and expands conventional systems by an internet based access for compatible mailers.
   BinkP is the publicly available protocol specification (default port 24554), which is implemented in other programs (i.e. Argus, BBBS) in the meantime.
   BinkD is at this moment of writing available for FreeBSD, Linux, OS/2, Windows 95 and Windows NT as well as sourcecode.

2. 
   Vmodem and other device drivers
   Vmodem is a "Virtual MODEM" (comparable to cfos for ISDN cards), which emulates a comport for conventional programs. It is part of Ray Gwinn's SIO device driver package for OS/2. Beside its own Vmodem protocol (default port 3141), telnet sessions (default port 23) are possible.

3. RL-Fossil represents a similar implementation for DOS or single DOS-tasks running in another multi-tasking environment by emulting a modem on a virtual commport with Telnet and Rlogin protocol.

4. ifcico is a fidonet mailer for *nix operating systems (default port 60179).
   Beside modem connectivity it naturally supports data transfer via ip. The default port is 60179, but with an additional TX-patch it may utilize Telnet sessions to any other system beside the default port of 60177.

5. Telnet is originally a terminal program, as it may be used for internet based access to a mailbox. Via the default port 23, FTN-compatible sessions may be handled.

6. Other possibilities
   FTP and Email-based proceedings are not FIP in direct sense, but they can save some money on long distance transfers in any way.

   Features and advantages of FIP

   Basically anybody can utilize FIP, as long as he has any kind of access to the internet.
   The only condition is, that both opponents :) are actually hooked up (even as dial-in) to the internet, as long as the connection exists. A frequently called system may think of an steady connection to the internet.
   The available bandwidth for data transfer can normally not be calculated, as it relies on the smallest one in any given part of the actual connection.
   With nowadays used multitasking operating systems, FIP may the used in parallel to any other utilization of the internet (surfing, chatting, ...), without requiring another dial attempt in opposit to conventional usage.

   (In-)Compatibilities within FidoNet-over-IP

   • BinkD as pure mailer conforming to the BinkP-specification can only connect to opponets with the same protocol. It's main usage is as additional task for IP to existing other mailers, as it uses the widely spread binkley style outbound structure.
   • Vmodem is unhappily only available as device driver for OS/2, but has there the advantage of easy implementation for nearly any communication program, including a wide range of conventional mailers. The installation just requires the selection of an appropriate (virtual) commport.
   • ifcico is only available for unix-style operating systems, but with the additional TX-patch may connect to any other system via the telnet-protocol.
   • Telnet is supported on nearly any platform (including DOS by rlfossil), but may raise some problems depending on the individual installation.
   • All of these rely on an existing TCP/IP-stack, which is sometimes integral part of the operating system (*nix, OS/2 since Warp3 Connect, Windows 95, Windows NT). For DOS and Windwos 3.x additional drivers are available.
   Sources and availability:

   For an actual compilation of sources, download and other information, just take a look on
   http://home.nrh.de/~lbehet/fido/
   (The site is bi-lingual (english/german) at this moment, but volunteer translators are already busy :)

   Testing FIP all around the world:
   Beside connections to the authors system (fido.nrh.de at 194.231.142.17) with BinkP:24554, Telnet:23 and Vmodem:3141, the above mentioned website offers an ip nodelist, which is continuously growing :)

   ---

   The author:
   

   Netmail	2:2446/301 (aka 2:2/3000) and 2:2446/305
   Email	lbehet@nrh.de
   BBS	Telnet to fido.nrh.de +49-2824-922 240 (v.34+) +49-2824-922 250 (ISDN)
   Personal history (mostly communications related :)
   1980, Dez.	build first Z80-Computer
   1981, Summer	first BBS-connects with borrowed modem
   1983, Winter	build own PC on imported pcb's
   1984, Autumn	bought AT because of "need for speed"
   1985, Autumn	remote maintenance via modem
   1986, Winter	got first 80386DX20 for testing purposes
   1990, Spring	"LB Support Box" for customer support opened
   1991, Apr.	joins Fidonet as point
   1991, Dec.	Novell CNE within 1.5 hours
   1993, May	FidoNet-hub for the area of Kleve, Germany (near the dutch border)
   1996, Aug.	start ISP-business
   1997, Jan.	Fidonet-host for Net 2:2446
   1997, Jun.	utilization of ip-connections for Fidonet
   1997, Sep.	first ip-node 2:2/3000 in Z2
   1998, Jul.	FIP-site: "http://home.nrh.de/~lbehet/fido/", includes ip-nodelist, information, software, links

   Legal information
   © 1998 by Lothar Behet
   This series of articles may be distributed freely within the fidonet community.
   The distribution (partially or complete) on digital, printed or other media without explicit authorization of the author is prohibited.

   ---

   Top

   Index

   All rights reserved. © Lothar Behet 26.7.1998. /fido/docs/lbfip.shtml.en (Sunday, 26-Jul-1998 00:00:00 CEST)

   lbehet@nrh.de