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 conven- tional 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 presen- tation 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.