Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen der Seite angezeigt.

--- ip-koordination:de.ampr.org:entwicklung [26.11.2020 11:32 Uhr] – [DNS-Server brachten Zonenkonzept] dd9qp
+++ ip-koordination:de.ampr.org:entwicklung [01.12.2020 21:29 Uhr] (aktuell) – Remove page via multiORPHANS dd9qp
@@ Zeile 1: / Zeile 1: @@
-===== Entwicklung des Regionalzonenkonzeptes =====
-==== Wie alles begann ====
-Das Regionalzonenkonzept und die Arbeit von Regionalkoordinatoren hat sich vom Grundsatz her schon in den späten 1980er Jahren entwickelt.
-Wegen der ausgeprägten "Inselstruktur" mit schlechter bis gar nicht vorhandener TCP/IP-Konnektivität wurde in Deutschland bereits unter dem ersten IP-Koordinator Ralf D. Kloth DL4TA das Regionalkoordinatorensystem auf freiwilliger Basis eingeführt. Regionalkoordinatoren mit stark variierenden Fachkenntnissen und Motivationen waren für die Vergabe von IP-Adressen in ihrem Gebiet verantwortlich.
-Diese konnten aus einem ihnen zugeteilten IP-Adresskontingent (meist ein bis zwei 44.130.xx/16 Netze) selbst die IP-Adressvergabe für ihre Region durchführen. Die Vergabe erfolgte oft völlig willkürlich und orientierte sich meist nicht an technischen Gesichtspunkten wie etwa der Unterteilbarkeit der Zone in weitere Subnetze zu Routingzwecken. Die von den Regionalkoordinatoren in der Region gepflegten Datenbestände lagen zudem in unterschiedlichen Formaten vor (flache, traditionelle "HOSTS" Datei, Domaindateien für die diversen NOS-Programmvarianten, eigene Konstrukte).
-Teilweise wurden diese Dateien der Allgemeinheit und dem nationalen IP-Koordinator über verschiedene Transportwege zugänglich gemacht. Dazu gehörten zum Beispiel die Verbreitung über die Packet-Radio-Mailboxen (Rubrik TCPIP). Auch die nicht überall in Deutschland verfügbaren Newssysteme wurden verwendet und in Einzelfällen zeitweise auch drahtgebundene Transportmechanismen.
-Die Vielfalt der verwendeten Dateiformate bedingte von der Region bis hinauf zur weltweiten Verfügbarkeit oft mehrfaches Umwandeln von einem Format ins andere. Dies geschah nicht in einem standardisierten Verfahren, sondern eher willkürlich, je nach Geschmack des gerade zuständigen Koordinators. Es geht das Gerücht, das manche sogar alles von Hand editiert haben sollen. Dem Einschleichen von Fehlern und dem Verlust von Informationen waren Tür und Tor geöffnet.
-==== DNS-Server brachten Zonenkonzept ====
-In den 1990er Jahren wurden zunehmend Linuxsysteme in Amateurfunknetzen eingesetzt. Man konnte in vielen Regionen "echte" BIND-Nameserver  betreiben, auf denen ein Regionalkoordinator zumindest die IP-Adressen der eigenen und evtl. einiger benachbarter Regionen autoritativ und maschinennutzbar pflegen konnten. Der damalige DL-IP-Koordinator Fred Baumgarten DC6IQ hat diese Entwicklung sehr gefördert, obwohl sie von Brian Kantor, dem damaligen Maintainer von "ampr.org",  und anderen bereits Ende der 1980er Jahre im Internet kontrovers diskutiert wurde:
-  * [[ip-koordination:de.ampr.org:flat_domain|Why is the ampr.org namespace flat?]]
-Zur Vielfalt der Dateiformate gesellten sich nun auch noch die BIND-Dateiformate, die ebenfalls kreuz und quer durch die Republik verteilt wurden.
-Da ein DNS aber nur für eine begrenzte Teilmenge an Adressen, nämlich die seiner lokalen Region, authoritativ sein kann, wurde in Deutschland das Regionalzonenkonzept eingeführt. Die flache Domainstruktur ampr.org wurde innerhalb Deutschlands in Regionalzonen  aufgegliedert. Auch in einigen Nachbarländern machte man diesbezüglich Versuche (Luxemburg, Belgien, Österreich). Um sich von künftigen Regionalisierungen im Ausland unterscheiden zu können, mussten die Regionalzonen national eindeutig gekennzeichnet werden.
-Die Syntax für die Bezeichnung einer Regionalzone leitet sich daher wie folgt ab:
-<code>
-<Zonenname>.<Landeskenner>.ampr.org
-</code>
-Daraus entstanden Konstrukte wie
-<code>
-rr.de.ampr.org   für die Region Rhein-Ruhr
-dd.de.ampr.org   für die Region um Dresden
-kiel.de.ampr.org für die Region um Kiel
-</code>
-und viele andere. Im April 2009 waren 79 Zonen koordiniert:
-<code>
-ac amk augsb baden bawue bln bri brsg brv bs dahme dd doi dssd eeosl
-enz erf esa goe h havel hdf hh hhm hhn hhs hi hot hrh husum in inet
-itzehoe ka kiel ks lake lg lpz luebeck mainz me mosel ms mue myk nbg
-ndh neisse nw nww oder ofr ohvl os ostbay osx owl pe pfalz pgntz rmn
-rnk ros rr rsk saar shg si ssa stgt sthur swb ual ufra wat wen
-westmfra wsx
-</code>
-Maximal sind unter 44.130/16 bis zu 255 44.130.x.x/24 Netzblöcke auf Regionalzonen in der Form von <zonenname>.de.ampr.org abbildbar. Zu beachten ist, dass einige Regionalzonen mehr als einen 44.130.x.x/24 Netzblock zugewiesen bekommen haben.
-Die Netze und ihre Koordinatoren wurden in den 1990er Jahren ursprünglich in der Datei "koord.html" von DO2KSM zusammengetragen. Diese Datenbestände hat die DL-IP-Koordination AMPRNet<sup>tm</sup> seit 2003 durch umfangreiche und langwierige Recherchen zumindest in Teilen aktualisieren können. **Diese Liste wird nicht mehr weiter gepflegt.**
-  * [[ip-koordination:koordlist|Datei "koord.html": Zonen, Netze, Koordinatoren, Digipeater]] (Archiv)
-  * [[ip-koordination:de.ampr.org:netzstruktur|Netzstrukturen und Regionalzonen in Deutschland]]
-  * [[hamnet:as-nummern#netzplanung|Netzplanung]] beschreibt den IP Range für das Netz Neuer Generation (hier im Wiki derzeit noch logisch unter AS-Nummern und BGP4 eingegliedert).
-==== Von Jägern und Sammlern ====
-Mit der für damalige Verhältnisse erheblichen Verbesserung der Netzwerkstruktur begann die Zeit des großen Sammelns.
-Jeder Sysop, der etwas auf sich hielt, wollte die Daten aller Regionalzonen möglichst aktuell auf seinem TCP/IP-Server verfügbar haben, um das TCP/IP-Netz zusammenhalten zu können. Digipeater mit eigenem DNS versuchten bei möglichst allen(!) anderen in regelmäßigen Zeitabständen die dort autoritativ vorgehaltenen Zonendaten zu bekommen. Jeder einzelne Digipeater mit eigenem Nameserver benötigte damals ca. 120 dieser Zonendateien. Ungünstig gewählte Zeitintervalle für den "Refresh" sorgten zusätzlich dafür, dass ein 120 Zonendateien auf den wichtigen, überregionalen Interlinkstrecken zig-fach am Tag hin und her transportiert wurden. Interlinkstrecken verfügten damals über Geschwindigkeiten von nur 9600 bis 19200 Baud. Manche Interlinkstrecken wurden durch diesen Automatismus unnötigerweise <del>überlastet</del> belastet. Der andauernde Überlastungszustand wichtiger Strecken wurde fast zm Dauerzustand. Das führte fast zwangsläufig zu Unzufriedenheit und Anfeindungen zwischen Anwendern, Sysops und Betreibergruppenruppen:
-  * [[ip-koordination:de.ampr.org:ip_not_wanted|Exkurs: TCP/IP ist hier unerwünscht]]
-Trotz dieser Nachteile funktionierte der technische Zonentransfer per DNS jahrelang erstaunlich stabil. Allerdings fehlte irgendwo immer etwas. Server wurden umgebaut, IP- und ARP-Adressen geändert, TCP/IP-fähige Digis kamen hinzu, andere fielen weg. Das Routing von IP-Netzen musste manuell eingestellt und gepflegt werden. Jeder Sysop musste ständig die Parameter für alle Systeme in DL kennen und in seiner Konfiguration aktuell halten, obwohl diese Parameter nie regelmäßig oder gar zentral veröffentlicht wurden.
-Die Aktualität und Authentizität der Daten konnte trotz größtem Eifer und Einsatz mancher Sysops nicht gewährleistet werden. Die Datenbestände drifteten regional auseinander und enthielten mehr und mehr Fehler. Schließlich waren sie praktisch nicht mehr bei ucsd.edu einpflegbar.
-Bei vielen Koordinatoren aller Ebenen machten sich Enttäuschung und Frustration breit. Andere verloren aus anderen Gründen das Interesse oder hatten einfach keine Zeit mehr. In einigen Regionen entstand eine Art "Wildwuchs" ("wild.de.ampr.org"), ohne Synchronisation auf ucsd.edu. Heute würde man das im Internet als "IP-Spoofing" oder "IP-Hijacking" bezeichnen!  Andernorts brach der TCP/IP Betrieb fast vollständig zusammen oder er beschränkte sich in seiner Funktionalität auf die berühmten "Inseln" der Anfangszeit: Man war froh, wenn es mit dem direkten Nachbarn klappte.
-Für moderne TCP/IP-gestützte Anwendungen ist ein funktionierendes DNS-System von essentieller Bedeutung und daher auch für den Amateurfunkdienst in DL zwingend geboten. Eng damit verknüpft ist die Koordination der IP-Adressen, deren Organisation sich an der hierarchischen Grundstruktur des DNS-Systems orientieren musste, wenn sie effektiv sein sollte.
-Mit der Einführung von HAMNET und HamCloud in Deutschland und den Nachbarländern wurde das grundsätzliche Prinzip der Regionalisierung von DNS-Daten in Subdomain-Zonen beibehalten. Routingprobleme, die seinerzeit zum Zusammenbruch des überregionalen Netzes geführt hatten, wurden durch die Einführung von automatischen Routingprotokollen (BGP) und Aufteilung des IP-Adrtessraumes auf "Autonome Systeme (AS)" gelöst. Die Zuteilung persönlicher IP-Adressen wurde obsolet und es erfolgte die Verwaltung und Anbindung von IP-Adressen in Form von IP-Subnetzen an die enstehenden AS. Der "Besitz" einer persönlichen IP-Adresse war für die Nutzung des Netzes nicht mehr zwingend erforderlich.