HAMNET Integration ins AMPRNet

Aus Amateurfunk Wiki

Wechseln zu: Navigation, Suche

Nach der Definition des AMPRNet bzw. Network 44 (Nutzer des IP-Adressraums 44.0.0.0/8) ist das HAMNET bereits Teil des AMPRNet. Wie aber kann für wirkliche Konnektivität im AMPRNet gesorgt werden?

Das klassische Verfahren TCP/IP-Pakete innerhalb des Amateurfunks von A nach B zu transportieren, ist die Verwendung von AX.25. Dabei werden die TCP/IP-Pakete in AX.25-Frames eingepackt und über das Packet Radio Netz an ihr Ziel gebracht. Da das Packet Radio Netz nicht die ganze Welt umspannt, nutzt man Tunnel im Internet, um die einzelnen TCP/IP-Aktivitätszentren der Funkamateure miteinander zu verbinden. Diese sogenannten IPIP-Tunnel packen dabei die TCP/IP-Pakete wiederum in IP-Pakete (statt in AX.25-Pakete wie im klassischen Verfahren) ein und „tunneln“ diese an ihr Ziel über das Internet. Mit dem HAMNET steht uns jetzt eine Funktechnik zur Verfügung, welche ganz ohne Einpacken von TCP/IP-Paketen auskommt.

Das AMPRNet möchte alle TCP/IP-Aktivitäten unter Funkamateuren zu einem gemeinsamen Netz ausbauen. Unsere Hauptziele sind daher:

  • Integration aller Teilnetze (IP über AX.25, IPIP, HAMNET) zu einem Netz
  • Einfache Nutzung des Netzes sowohl für User als auch für Sysops
  • Bestandssicherung des Network-44 gegenüber kommerzieller Interessen

Diese Ziele wurden an DB0FHN (Hochschule Nürnberg) und dem zentralen Packet Radio Knoten IGATE mit Augenmerk auf Nutzbarkeit versucht umzusetzen. Mit der Integration des HAMNET wird eine saubere Implementierung der Idee des TCP/IP-Routings unerlässlich. Dies erfordert die Umstrukturierung der bisherigen Infrastruktur und kann sich für TCP/IP-Knotenbetreiber innerhalb des AX.25-Netzes und dessen Nutzer auswirken. Die geplante Umsetzung soll nachfolgend erläutert werden.

Die zentrale Idee ist es, dass jeder Teilnehmer des AMPRNet seine lokalen IP-Netze dem Gesamtnetz bekannt macht:

IP-Netze über eine Mailingsliste (E-Mail) täglich verteilt. In den vergangenen Monaten sind neue Entwicklungen wie die Nutzung des RIPProtokolls (http://de.wikipedia.org/wiki/Routing_Information_Protocol) zu beobachten.

  • Im AX.25-Netz sind keine Projekte zur Verteilung von

Routinginformationen bekannt. Das INP3-Protokoll (http://dl6mpg.net/nordlink/ftp/pub/documentation/INP/inp3.pdf) hätte Potential zur Verteilung der IP-Netze.

Die Tatsache, dass jeder Knoten seinen eigenen (oder mehrere) IP-Adressraum besitzt, lässt beim User die nomadische Nutzung von IP-Adressen nicht mehr zu. D.h. ein User muss am Knoten A eine vorgesehene IP-Adresse aus dem vom Sysop festgelegten IP-Adressraum für Knoten A nutzen und kann nicht eine IP-Adresse von Knoten B nutzen. Für den eventuellen Verlust an Komfort beim User muss durch technische Mittel eine Alternative gefunden werden (z.B. durch DHCP over AX.25).

Ein automatisches Routing (Vermitteln von IP-Netzen an Nachbarn) ist Voraussetzung für ein wartungsarmes und funktionierendes Netzwerk. Wichtig ist es, dass die Routinginformationen aktuell gehalten werden. Im HAMNET erledigt das BGP4-Protokoll diese Aufgabe in nahezu Echtzeit. Die Routen vom IPIP-Netz werden derzeit maximal einmal pro Tag aktualisiert. Leider lesen viele Gatewaybetreiber die Routinginformationen nur unregelmäßig manuell ein. Im AX.25-Netz werden die Routen sogar komplett manuell gesetzt. Leider hängt die Qualität der Routinginformationen stark von der Pflege selbiger ab.

Das neue HAMNET bringt von Anfang an mit dem BGP4-Routingprotokoll alles Notwendige für die Zusammenschaltung anderer Netze mit. Auf die Gegebenheiten des internationalen IPIP-Routings haben wir nur begrenzten Einfluss. Neuentwicklungen gehen nur langsam voran. Im AX.25-Netz haben wir die notwendigen Administrationsarbeiten an Packet Radio Knoten durch Einführung des IP-Routings über IGATE minimiert.

Zunächst ist eine zentrale Zusammenschaltung der Netze an DB0FHN und IGATE geplant.

HAMNET <-> IPIP-Netz: Es werden die bekannten Routen des IPIP-Netzes über das BGP4-Protokoll in das HAMNET eingespeist. Eine automatische Bekanntgabe der aktiven IP-Netze aus dem HAMNET an das IPIP-Netz ist zur Zeit nicht möglich. Derzeit wird aber sämtlicher Datenverkehr für die IP-Netze 44.130.0.0/16 (Deutschland), 44.142.0.0/16 (Schweiz), 44.143.0.0/16 (Österreich), 44.151.0.0/16 (Frankreich) und 44.161.0.0/16 (Luxemburg) innerhalb des IPIP-Netzes an uns geschickt. Somit ist das Routing zwischen dem HAMNET und dem IPIP-Netz für genannte Netzbereiche komplett funktionsfähig. Auf längere Sicht ist es aber wünschenswert, wenn ein kompletter Austausch der Routen in Echtzeit erfolgen kann.

HAMNET <-> AX.25-Netz: Momentan findet noch kein Austausch der Routen statt. Im IP-Router des AX.25-Knotens IGATE sind derzeit manuell die Routen zum HAMNET gesetzt (44.130.192.0/19 und 44.130.224.0/20 für Deutschland und 44.143.0.0/16 für Österreich). Ein Tool zum periodischen Einlesen der HAMNET-Routen in den IGATE-Knoten muss erst noch entwickelt werden. Dem HAMNET wird aktuell das gesamte deutsche IP-Netz 44.130.0.0/16 bekanntgegeben. Daher funktioniert ein bidirektionales Routing auch in dieses Netz bereits. Die Situation ist aber nicht zufriedenstellend, da nur die tatsächlich genutzten IP-Netze aus dem AX.25-Netz per BGP4 in das HAMNET eingespeist werden sollen.

Um später volle Flexibilität im Routing haben zu können, ist es notwendig, die genutzten IP-Netzbereiche so genau wie möglich angeben und verteilen zu können. Früher wurde an jedem TCP/IP-fähigen AX.25-Knoten alle Routen mit Zielrufzeichen und IP-Netzen händisch gepflegt. Da die Bereitschaft solche Routen händisch zu pflegen und damit die Funktionalität des Netzes masiv abgenommen hat, wurde der IGATE-Knoten TCP/IP-fähig gemacht. Jeder TCP/IPKnotenbetreiber hat daher die Möglichkeit, einfach die Defaultroute nach IGATE zu definieren. Die Routinginformationen zu den einzelnen IP-Netzen im AX.25-Netz müssen dann nur noch zentral auf IGATE gepflegt werden. Daher ist es nötig, dass die Betreiber von TCP/IP-Knoten im AX.25-Netz ihre eigenen IP-Netze an die Betreiber von IGATE melden. Diese IP-Netze sollen dann später per BGP4 im HAMNET verteilt werden.

Unter der Prämisse, dass jeder TCP/IP-Knoten (egal welchen Netzes) immer nur seine eigenen IP-Netze „announced“, ist eine Dezentralisierung des Übergangs in die verschiedenen Netze möglich. Möchte z.B. ein Betreiber eines HAMNET-Knotens auch einen TCP/IP-over-AX.25-Einstieg für Endnutzer bereitstellen, so kann er den geplanten Netzbereich auch selbst im HAMNET über BGP4 bekanntmachen oder auch gleich aus dem IP-Adressbereich für HAMNET herausbrechen. Er hat dann nur dafür zu sorgen, dass das lokale Routing auch funktioniert, und kann danach den IGATE-Administratoren mitteilen, dass das entsprechende IP-Netz nun selbst „announced“ wird und im IGATE-System entfernt werden soll.

Vor einiger Zeit wurde das Projekt „IP over IGATE“ (http://db0fhn.efi.fh-nuernberg.de/doku.php?id=projects:igate:ipoverigate) vorgestellt. Die beschriebene Konfiguration für XNet-Knoten bleibt mit einer Ausnahme erhalten. Mit der Version 1.39 Beta 04.03.2006 wurde folgende Option eingeführt: „Priorisierung gelernter IP-Routen: Bei vielen Knoten sind die IP-Routen nicht gepflegt - deshalb priorisiert diese Betaversion die ARP-Einträge (gelernte oder statische) vor den IP-Routing-Einträgen. Damit sollte das IP-Routing in den meisten Fällen besser funktionieren. Mithilfe der neuen Befehlsfolge "ipr prio 1" kann der alte Zustand wiederhergestellt werden. Dann haben die IP-Routing-Einträge die Priorität.“

Um die nomadische Nutzung von IP-Adressen und folglich manipulierter Routingtabellen vorzubeugen, muss „ipr prio 1“ in der Konfiguration gesetzt werden. Die User können dann nur noch eine IP-Adresse aus dem von euch vorgesehenen Bereich nutzen. Für jeden TCP/IP-fähigen Digipeater (XNet, TNN, Wampes) ist dabei ein eigenes IP-Netz vorzusehen. IP-Adressen sollten an die Nutzer dynamisch vergeben werden. XNet kennt hierzu den Befehl GETIP. Nähere Konfigurationsbeschreibungen sind noch zu veröffentlichen.

Seit einigen Jahren kommen immer mal wieder Überlegung zur Nutzung von DHCP für IP-über-AX.25 auf. Mit der Einführung von dynamisch vergebenen Adressen für Endnutzer erscheint dies immer notwendiger. Auf der Knotenseite wäre zunächst eine entsprechende Erweiterung von Xnet/TNN und auf der Nutzerseite eine passende Erweiterung für PC/Flexnet32 sinnvoll.


Ausblick

Aus den Medien haben wir bereits erfahren, dass der gesamte IPv4-Adressraum zuneige geht. Das Privileg, ein Klasse A Netzwerk nur für den Amateurfunk nutzen zu können, sollte durch Zeigen von Bedarf auch verteidigt werden. Vereinzelnd sind Kopplungen zwischen dem Internet und dem Network 44 eingerichtet. Diese sind aber auf Experimente mit Amateurfunkcharakter und schmalbandiger Nutzung beschränkt. Ausgehende Verbindungen zum Internet wird der IGATE-Knoten auch nach der Neukonfiguration ermöglichen. Außerdem wird IGATE ein IP-Netz für Endnutzer bekommen, damit ein Betrieb auch auf Einstiegen möglich ist, welche keine direkte TCP/IP-Unterstützung anbieten.

Weitere Experimente können im IT-Bereich gemacht werden. Dem Einsatz von IPv6 auch im HAMNET spricht nichts entgegen. Hier können wertvolle Praxiserfahrungen für die Zukunft gesammelt werden. Experimente mit Multicasting oder Source Routing könnten auch spannend sein.

Direkte schnelle IP-basierte Usereinstiege in das HAMNET sind eine große Herausforderung für die Zukunft. Alternativ können Funkamateure auch über VPN-Zugänge (Authentifizierung nötig) über das Internet die Dienste des HAMNET nutzen. An DB0FHN und DB0RES ist dies bereits unter Nutzung des PPTP-Zugangs möglich.

Im HAMNET können auch Bild- und Sprachverbindungen aufgebaut werden. So kann ein Bild- oder Sprachnetz als Nutzlast innerhalb des HAMNET entstehen. Wie auch beim S&F (Store and Forward) verschiedener Mailboxen in Packet Radio kann dabei das Internet als Fallbacklösung konfiguriert werden.

Ein großes Thema, vermutlich für die IPRT 2011, wird die Ausarbeitung einer unverbindlichen „Policy“ für das HAMNET sein. Neben den gesetzlichen Einschränkungen (kein kommerzieller Einsatz) gilt es die Frage zu stellen, ob alles technisch Machbare auch wirklich sinnvoll ist. Ich halte die IPRT für eine geeignete Veranstaltung für demokratische Abstimmungen über den Inhalt einer solchen Policy. Ein Thema könnte sein, wie man mit Internetlinkstrecken zur Vernetzung von HAMNET-Zentren umgehen sollte. Der Sinn einer Policy sollte auf der IPRT 2010 diskutiert werden.

Persönliche Werkzeuge