Fidonet-ber-IP, Teil 3 von 4: Vorschl„ge fr die Integration von IP-Nodes in die Nodeliste Copyright 1998 by Lothar Behet Teil 1 und 2 in der letzten FidoNews enthielten eine Definition von FidoNet-ber-IP und die derzeit verfgbare Software Wenn man das Internet als alternatives Transportmedium fr Fidonet-Daten betrachtet, dann gibt es verschiedene Wege zur Nutzung der Adressierungsm”glichkeiten fr die Fido-Verbindungen. 1. IP-Nummern ("Dotted Quad" wie z.B. 194.231.142.17) 2. Fully Qualified Domain Names (FQDN, wie z.B. fido.nrh.de) 3. Adress-Aufl”sung anhand der Nodenummer in einer speziellen Domain (wie z.B. f301.n2446.z2.) Schauen wir uns diese drei M”glichkeiten doch einmal an: 1. IP-Nummern Der direkte Gebrauch von IP-Nummern sieht fast wie ein direkter Ersatz fr die Telefon-Nummer in der konventionellen Fido-Umgebung aus. Darberhinaus enth„lt sie nur Ziffern, was dem St.Louis-Nodelisten-Format sehr gelegen kommt. Die Bindestriche im Nodelistenformat k”nnen durch einen entsprechend eingerichtetne Nodelistencompiler in Punkte umgewandelt werden, sobald das entsprechende Programm ber den eigentlichen des "Phone-Feldes" informiert ist. Dies kann ber ein Flag oder einen speziellen L„ndercode erfolgen. Dies zeigt auch gleich das Problem fr konventionell Nodes: Es besteht durchaus die Gefahr eines Anrufes bei einer IP-Nummer, falls das anrufende System dieses nicht richtig behandelt. Da normalerweise jedes Fido-System mit einer šbersetzungstabelle arbeitet, ist eine spezielle Behandlung des L„ndercodes fr diese Fehlfunktion notwendig. Darberhinaus ist diese Adressierung nur fr Nodes mit statischer IP-Nummer anwendbar, was aber nicht notwendigerweise auch eine dauernde Erreichbarkeit impliziert. 2. Fully Qualified Domain Name (FQDN) Die FQDN nutzt einen speziellen Dienst im Internet, den Domain Name Service (DNS), der die Namen (z.B. fido.nrh.de) in eine IP-Nummer (z.B. 194.231.142.17) bersetzt. Ferner kann dieser Name auch auf eine dynamische IP-Nummer aufgel”st werden, falls ein entsprechender Dienst (wie z.B. dyn.ml.org, dynip.com) genutzt wird, so daá auch Nodes mit einer normalen DialIn-Verbindung mit dynamischer IP-Nummer diese Adressierung nutzen k”nnen. Leider gibt keine M”glichkeit zur Ver”ffentlichung des FQDN im Phone-Feld der Nodeliste nach FTS-5, nach der jedes Fido-System die Anwahl ausfhrt. Der FQDN muá daher in einem anderen Feld ver”ffentlicht werden, z.B. System_Name, Standort oder im Flag-Bereich der Nodeliste. Da weder die IP-Nummern noch die FQDN nach geographischen Gesichtspunkten organisiert sind, sollte diese (manchmal interessante) Information erhalten bleiben. Einige Programme werten nur einen Teil des Flag-Bereiches aus, so daá auch dieses Feld nicht unbedingt die beste Wahl ist, zumal dort auch noch weitere Flags untergebracht werden mssen. Daher scheint der System_Name nach technischen šberlegungen am besten geeignet zu sein. 3. Adress-Aufl”sung nach der Nodenummer in einer speziellen Dom„ne (wie z.B. f301.n2446.z2.) Dieses Verfahren wird in der Dom„ne "fidonet.org" (registriert auf George Peace, Pennsylvania Online) fr die Adressierung der Gateways zwischen dem Fidonet und dem Internet verwendet. Die Dom„ne "fidonet.net" (registriert auf Ustinov Fyodor, Prospect Investment) verwendet das gleiche Verfahren fr normale IP-Nodes, wobei der MX-Pointer in dieser Dom„ne dann auf einen FQDN oder eine IP-Nummer weist. Die Dom„nennamen nicht kostenlos sind, ist die Nutzung auf einen gutwilligen Sponsor oder die Kostenumlage auf die Allgemeinheit angewiesen. Die Ver”ffentlichung eines Eintrages erfolgt in diesem Falle meist durch den Node selber, der die Anforderungen des Dom„nenverwalters erfllt. In der Praxis ist die Ver”ffentlichung einfach, aber h„ufig wird die Einstellung des Dienstes durch den Node nicht gemeldet. Normalerweise ist der Netzwerk-Koordinator (NC) eines Netzes relativ gut ber den Status seines Netzwerkes informiert, aber leider besitzen alle NCs einen Zugang zum Internet zur Pflege dieser Eintr„ge und die Wartung kann dann auáerhalb der eigentlichen Verantwortlichkeit des NC fallen. Nach diesen grunds„tzlichen šberlegungen habe ich einen Vorschlag zur Integration von IP-Nodes in die Nodeliste ausgearbeitet, bei dem ich zus„tzlich die Ergebnisse meiner Umfrage (IP Query Sheet) bercksichtigte. >-8------------------------ byte here ------------------------8-< Vorschlag fr die Integration von IP-Nodes in die Nodeliste von Lothar Behet, v. 2.0 (4. Jan. 1998) 1. Das Phone_Feld wird fr eine IP-Nummer verwendet Dies impliziert den Gebrauch eines speziellen L„ndercodes fr IP-Nodes, welcher dann zu einem Eintrag wie "000-aaa-bbb-ccc-ddd" in der Nodeliste fhrt. Das Prefix darf w„hrend der Verteilung oder Verarbeitung durch Programme nicht verkrzt oder ver„ndert werden, da ansonsten die Vermischung mit normalen Rufnummern zu unerwnschten, falschen Anrufen fhren kann. Ohne Anwahl-šbersetzung (dial translation) wird dieser Prefix normalerweise zu nicht-w„hlbaren Nummern fhren. Auch in speziellen F„llen (Nebenstellen- Anlagen) wird die vorhandene Rufnummern-Umsetzung im Nodelistcompiler oder Mailer zur Vermeidung von Fehlanrufen fhren. Der in der Regel haupts„chlich Buchstaben enthaltende FQDN kann von den meisten Modemen (analog und ISDN) nicht angew„hlt werden, aber diese Variante kann erst nach einer Kompatibilit„ts-Prfung aller derzeit benutzten Programme verwendet werden. In der Zwischenzeit kann der FQDN im Feld "System_Name" ver”ffentlicht werden, wobei dieses Feld dann von Nodelist-Compilern alternativ verwendet werden kann. 2.1 Flags fr IP-Basierte Handshking-Protokolle Da derzeit schon viele verschiedene Flags bestehen (manchmal in Gruppen wie H(st) oder Z(yxel)), scheint eine spezielle Gruppe fr IP-Flags sinnvoll zu sein. Dies erleichtert auch die Lesbarkeit fr Menschen und eine einfachere Programmierung von Hilfsprogrammen. Das grunds„tzliche Format ist: [:[:]] Die Angabe "Basic_transport" ist erforderlich. Die die meisten Systeme die Default-Ports verwenden, kann diese Angabe entfallen. Die Handshake-Spezifikation ist ein weiteres optionales Feld. Die Gestaltung dieses Flag-Satzes orientiert sich an den derzeit verfgbaren Programmen und erlaubt in praktisch allen F„llen eine problemlose Integration auf den meisten Systemn. 2.1.1 Basic_transport Die vorgeschlagenen Flags fr die Transport-Schicht (einige enthalten implizit schon den Handshake) sind: IBN BinkP (default port 24554) IFC ifcico (default port 60179) ITN telnet (default port 23) IVM Vmodem (default port 3141) IP raw tcp (alles andere, soweit nicht durch obige Flags abgedeckt) Da derzeit nur die bekannten Programme bercksichtigt werden k”nnen, ist diese Aufstellung in Zukunft anzupassen. Als šbergangsl”sung fr neue Entwicklungen ist "IP" vorgesehen, um die schnelle Nutzung bis zur eigenst„ndigen Protokoll-Definition durch die Zusatzangaben im vollen Format (2.1.2 bis 2.1.3) zu erm”glichen. 2.1.2 Port Spezifikation (optional) Abweichende Ports werden mit Hilfe einen Doppelpunkt als Trennzeichen nach der Transport-Spezifikation angebenen, z.B. : ITN:60177 ifcico with additonal telnet-patch (port 60177) 2.1.3 Handshake Session Spezifikation (optional) Diese Flags orientiren sich an den konventionellen Mailern: 1 FTS-0001 Y Yohoo E EMSI B BinkP Multi-Protokoll-Mailer sollten die entsprechenden Default-Ports beachten oder diese optional angeben: Beispiel: IP:24555:1YEB verwendet Raw Ip mit Port 24555 und untersttzt Sessions nach FTS-1, Yohoo, EMSI und BinkP Weitere Protokolle k”nnten in der Zukunft entwickelt und dieser Aufstellung angefgt werdn, wenn die Definition ”ffentlich verfgbar sind. 2.2 Flags fr andere Ip-basierte Protokolle IEM Email-based (generell) IFT File Tranfer Protocol (FTP) ITX Transx IUC Uuencoded packet (Einzeln per Nachricht) Auch diese Liste kann in Zukunft erweitert werden. 2.3 Weitere Flags fr Sonderzwecke IFQ Dieses liefert dem Nodelisten-Compiler die Information ber einen FQDN im Feld "System_Name" als Fully Qualified Domain Name anstelle der IP-Adresse im Feld "Rufnummer" 3. Zumindest ein Flag der Gruppe 2.1 (evt. um weitere Spezifikationen erg„nzt) ist fr die Listung als IP-Node erfoderlich. Darberhinaus k”nnen Flags der Gruppe 2.2 dann als Zusatz angegeben werden. 4. Die mindest-Online ist entweder CM (Continues Mail) oder eindeutig durch die T-Flag-Spezifikation (siehe Nodeliste) angegeben. ZMH-only IP-Nodes werden nicht aus der nodelsite ausgeschlossen. >-8------------------------ byte here ------------------------8-< Im Gegenzug ver”ffentlichte Marco d'Itri seinen eigenen Vorschlag, der einige Aspekte anders behandelte. 1. Er verwendet IP als generelles Flag fr die Sperrung der Anwahl von IP-Nodes durch konventionelle Systeme. 2. Verwendung anderer Flagnamen (basierened auf den derzeit in Z2 verwendeten) 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 seinem FTA-Vorschlag entschied Marco sich fr die Verwendung des Feldes "Standort" anstelle des "Systemnamens" fr die Ver”ffentlichung des FQDN. >-8------------------------ byte here ------------------------8-< Die beide vollst„ndig in "IP_CONNECT" ver”ffentlichten Vorschl„ge versuchen eine Integration der IP-Nodes in das derzeitige Nodelisten-Format und erlauben die Verwendung kombinierter Eintr„ge, da der FQDN (oder eine IP-Nummer) in einem anderen Feld als der Rufnummer erfolgt. Die Pflege der Eintr„ge fr IP-Nodes ist im Rhamen der normalen NC-Struktur gegeben. Es waren noch einige weitere Ideen zu einzelnen Teilbereichen vorgestellt worden und zus„tzlich die Verwendung des "fidonet.net"-Dom„nendienstes, der aber ggf. die Pflege auáerhalb der *C-Schiene erfordert. Teil 4 wird meine šberlegungen zu Policy-Erw„gungen fr IP-Nodes enthalten. Bezugs-Quellen: (Dieses Kapital werde ich demnaechst ergaenzen, im Moment verweise ich erstmal auf http://home.nrh.de/fido/ :) Der Autor: Der Autor ist seit 1991 Mitglied im FidoNet, davon seit 1993 als einer der fruehen ISDN-Nodes als Hub am Niederrhein und seit Januar 1997 als Host in der gleichen Region. Durch den regen Einsatz von IP-Verbindungen im weltweiten Verkehr seit 1997 ist er ab dem Herbst 1997 als 2:2/3000 der erste IP- Testnode in der Nodeliste der Zone 2 aufgefuehrt. Fragen und Anregungen koennen per Netmail an 2:2446/301 (V.34), 2:2446/305 (ISDN) oder per Email an lbehet@nrh.de geschickt werden. Unter der Adresse fido.nrh.de (194.231.142.17) koennen Test- verbindungen mit den Protokollen BinkP (Port 24554), Telnet (Port 23) und Vmodem (Port 3141) aufgebaut werden. Rechtliches: Copyright: Lothar Behet, im Juli 1998 Dieser Text darf in unveraenderter und vollstaendiger Form im Fidonet frei verteilt werden, Die Verbreitung (auch auszugsweise) auf Datentraegern, in gedruckter Form oder auf anderem Wege bedarf der ausdruecklichen schriftlichen Zustimmung des Autors. Verbesserungsvorschlaege bitte per Netmail an 2:2446/301 bzw. per Email an lbehet@nrh.de.