F I D O N E W S
Volume 15, Number 30
27 July 1998

Articles

back to main table of contents
back to fidonews.org

FidoNet over IP,
Part 1 of 4

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

The ip-number normally contains points in place of dashes, but that conversion would only be a small problem for actual suppor- ted software.


Older programs cannot see the difference between a phone number and an ip-number in this field, so they have to examine the flag field for this differentiation.

This leaves room for any twit-sysop, to dial an ip-number with his modem, which is at least annoying for the opponent side of the connection and may cost some bucks of dollar for the unexperienced sysop.

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 circum- stances (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 geo- graphical 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.

The usage of any of these three fields leaves room for another intention:

Definition of a "combined entry", which includes one ip connectivity and one conventional in a single entry in the nodelist. Furthermore all may carry either characters or numbers, so ip numbers or FQDN may be used to the actual sysops intention. Just the locally used nodelist compiler has to know, which field to use for the preparation of ip connections.

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.

After 5 months of discussion in IP_CONNECT several proposals were defined (part 3).

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

The author:
Netmail : 2:2446/301 aka 2:2/3000
Email : lbehet@nrh.de

Apr. 1991: gets member of FidoNet
May 1993: Hub for the area of Kleve, Germany (near the dutch border)
Jan. 1997: Host for Net 2:2446
Jun. 1997: utilization of ip-connections for Fidonet
Sep. 1997: First ip-node 2:2/3000 in Z2
Jul. 1998: FIP-site: http://home.nrh.de/~lbehet/fido/, includes ip-nodelist, information, software

Legal information:
Copyright 1998 by Lothar Behet
This series of articles may be distributed freely within the fidonet community.

The distribution (partially or complete) on digital or printed media without explicit authorization of the author is prohibited.

### 30 ###

back to articles table of contents
back to main table of contents
back to fidonews.org

FidoNet over IP,
Part 2: What do I need for it?

Copyright 1998 by Lothar Behet

FidoNet over IP - What's that?

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 alter- native 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
    BinkD is a pure ip-mailer, which uses the known Binkley style out- bound and expands conventional systems by an internet based access. 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.
    RL-Fossil represents a similar implementation for DOS or single DOS-tasks running in another multi-tasking environment.
  3. ifcico
    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 (default port 60177).
  4. Telnet
    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.
  5. 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) comport.
  • 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 rlfossil for DOS), 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, downloads 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 :)

Legal information:
Copyright 1998 by Lothar Behet
This series of articles may be distributed freely within the fidonet community.

The distribution (partially or complete) on digital or printed media without explicit authorization of the author is prohibited.

### 30 ###

back to articles table of contents
back to main table of contents
back to fidonews.org