Fidonet over IP, Part 3 of 4: Proposals for integration of IP-nodes in the nodelist Copyright 1998 by Lothar Behet Part 1 and 2 in last weeks FidoNews issue contained a definition of Fidonet-over-IP and the available software. As the internet can be used as additional carrier for FidoNet data exchange, there are several ways of using its addressing capabilities for direct connections between fido-nodes. 1. IP numbers (dotted quad like 194.231.142.17) 2. Fully Qualified Domain Names (like fido.nrh.de) 3. Address resolution by node number in a dedicated domain (like f301.n2446.z2.) Lets take a look at each of them: 1. IP numbers The direct use of ip numbers looks like a direct replacement for a phone number in the conventional environment. Furthermore it just contains numbers, which is in accordance to the possible format for a phone number in the St.Louis nodelist format. The dashes in the nodelist may be translated by an actual nodelist compiler without further complications, as soon as the program has an information about the real contents of the phone number field in the nodelist, which may be signified by a flag or eventually just by a special country code. This already shows the major problem for conventional nodes: There is a high risk for calling an ip number as direct phone number, if the system in question is not aware of it. As any system uses a dial translation table, the special country code for ip numbers is required anyway for safe dial suppression in that case. Furthermore this is only usable for nodes with an static ip number, but this does not imply a permanent connection. 2. Fully Qualified Domain Name (FQDN) The FQDN uses a special service in the internet, the Domain Name Service (DNS), which translates a name (i.e. fido.nrh.de) to (normally) an static ip number (194.231.142.17). Furthermore the FQDN may be resolved to a dynamic ip number, if such a service is used (i.e. dyn.ml.org, dynip.com), so that even nodes with a normal dialin connection may utilize this system. But there is no possibility for publishing a FQDN in the phone field, according to FTS-5, on which any conventional fidonet system is based for the dialing part. The FQDN has to be published in another field, i.e. system name, location or flag space in the nodelist. As ip numbers and FQDNs are not geographically organised, this (sometimes quite interesting) information should still be kept in the nodelist. Some programs just examine a part of the flag space, so this field might not be the optimal choice, as we need some of it for additional flags. So the system name seems to be the most appropriate, based on technical reasons. 3. Address resolution by node number in a dedicated domain (like f301.n2446.z2.) This schedule is already used in the domain "fidonet.org" (run by George Peace, Pennsylvania Online) for the addressing of gateways between fidonet and internet. "fidonet.net" (run by Ustinov Fyodor, Prospect Investment) uses the same schedule for addressing normal nodes, which have an MX-entry (mail exchange) pointing to their FQDN or static ip number in that domain. As domain names are not free of charge, these rely on a good willing sponsor or the community has to share the costs of it. The publication of an entry in this schedule may be done by any node, that fulfills the requirements of the domain administrator. In practice, the publication is easy, but mostly the information about stopping a certain service is forgotten by individual nodes. Normally, a network coordinator (NC) is quite informed about his networks status, but not all of them have internet connectivity for servicing this system and therefore the maintenance may fall out of the responsible *C-class within the FidoNet. Based on this considerations, i wrote a proposal for the integration of ip nodes in the nodelist after examining the results of my "ip-query-sheet" in IP_CONNECT (version 2.0, dated Jan. 4th, 1998): >-8------------------------ byte here ------------------------8-< Proposal for integration of IP-Nodes into the Nodelist by Lothar Behet, v. 2.0 1. The phone_field is used for the ip-number. This implies a special country code for ip-nodes, which might result in 000-aaa-bbb-ccc-ddd for an ip-address. The prefix "000-" may not be shortened or modified in any way by existing or future software, as a mixup with conventional phone numbers will lead to an annoying misbehaviour. Without dial-translation this prefix will normally result in undiable numbers. In special cases (pbx) a dial-translation is implemented in the nodelistcompiler or the mailer, so that no erronious dials can occure. The mostly character-based FQDN will result in an undiable number by most modems (analog and ISDN), but the usage is limited until any existing nodelist software has proven its compatibility with these entries. In the meantime the FQDN may be published in the system_name_field and nodelist compilers (or utilities) should optionally use that field for exaggeration of the FQDN. 2.1 Individual flags for ip-based handshaking protocols As there are existing flags on a wide range of leading characters (sometimes forming groups like H(st) or Z(yxel)), a special lead-in character seems reasonable for ip-flags, especially for human readability and easy utility construction. The genaral format is :: Basic transport is required. As many setups use the default ports, this part may be omitted. Handshake specification is another optional field. The construction of the flag-set is designed for nowadays available software and allows in most cases a seamless implementation on many systems. 2.1.1 basic transport The proposed flags for transport layer (includes some hansshake protocols) are: IBN BinkP (default port 24554) IFC ifcico (default port 60179) ITN telnet (default port 23) IVM Vmodem (default port 3141) IP raw tcp (anything else, which is not specified by other transport flag) These are mainly focused on the nowadays available programs and subject to expansion in the future. As intermediate option the general flag "IP" is proposed for new technologies, to allow rapid distribution until exact protocol specifications are published. Until then, the interested nodes may define their capabilities usinf the full format (2.1.1 to 2.1.3). 2.1.2 port specification (optional) Non-standard ports use a colon as delimiter behind the basic transport flag, i.e.: ITN:60177 ifcico with additonal telnet-patch (port 60177) 2.1.3 handshake session specification (optional) These follow the specifications for conventional mailers. 1 FTS-0001 Y Yohoo E EMSI B BinkP Multi-protocol capable mailers should listen to the specific default ports or use the optional port specification. Sample: IP:24555:1YEB uses raw ip on port 24555 and supports sessions according to FTS-1, Yohoo, EMSI and BinkP Additional protocols may be developed in the future and added to this list, if the specification is publicly available. 2.2 Flags for other ip-based protocols and other capabilities IEM Email-based (generally) IFT File Tranfer Protocol (FTP) ITX Transx IUC Uuencoded packet (one per message) This list may be extended in the future, too. 2.3 Additional flags/special purpose IFQ This flags advises the nodelist-compiler to use the system_name_field as "fully qualified domain name" in place of the ip-address in the phone_field 3. At least one flag of group 2.1 (including optional non-standrad ports) is required for an ip-node. Additional publication of non-handshaking-potocols (group 2.2) is allowed. 4. The minimum online-time is either CM or clearly stated through a T-flag according the known specification in the (Zone2) nodelist. ZMH-only ip-nodes are not excluded from the nodelist. >-8------------------------ byte here ------------------------8-< In return, Marco d'Itri created his own one :), which differs in some aspects: 1. He uses the "IP" as a general flag for exclusion of ip-node-dialing by conventional nodes. 2. Usage of other flag names (based on the usage in Z2 at this moment) Handshaking protocols: IBN --> BNP BinkP IFC --> RAW ifcico ITN --> TELN Telnet IVM --> VMP Vmodem Additional protocols: IEM --> IEM generally Email based IFT --> FTP FTP based ITX --> TRX TransX based IUC --> UUE uuencoded packet (one per message) In his FTA-proposal, Marco decided to prefer the location field in place of the system name as place to publish the FQDN. >-8------------------------ byte here ------------------------8-< Both actually filed complete proposals in "IP_CONNECT" try to integrate the ip nodes in the nodelist and leave room for combined entries, as the FQDN (or an ip number) is announced in another field beside the phone number. The responsibility for these entries is inside the normal *C-class within FidoNet. There were some more ideas on certain parts and additionally the proposal of "fidonet.net"-domain-service, which puts responsibilities outside the *C-class. Part 4 (next week :) will contain my considerations about policy requirements for ip-nodes, possibilities with these proposals and some additional comments. 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 tri-lingual (english/german/partly esperanto) 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.