Zum Hauptinhalt springen

2. Historie und Problembeschreibung

  1. Historie und Problembeschreibung

Das, was heute als Internet bezeichnet wird, begann in den 1970er Jahren als Forschungsprojekt zur Konzeption und Entwicklung eines Satzes von Protokollen, die mit vielen verschiedenen Netzwerktechnologien verwendbar sind, um eine transparente End-to-End-Verbindung für die Interconnectierung einer vielfältigen Menge von Endsystemen bereitzustellen.

Als festgelegt wurde, wie der 32-Bit-Adressraum genutzt werden sollte, wurden bestimmte Annahmen über die Anzahl der anzuschließenden Organisationen, die Anzahl der Endsysteme pro Organisation und die Gesamtzahl der Endsysteme im Netz getroffen. Das Endergebnis war die Festlegung (siehe [RFC791]) von drei Netzwerkklassen: Klasse A (höchstes Bitmuster „00“) mit 128 möglichen Netzwerken zu je 16777216 Endsystemen (abzüglich der für Netzwerk/Broadcast-Adressen reservierten Sonderbitwerte); Klasse B (höchstes Bitmuster „10“) mit 16384 möglichen Netzwerken zu je 65536 Endsystemen (abzüglich der reservierten Werte); und Klasse C (höchstes Bitmuster „110“) mit 2097152 möglichen Netzwerken zu je 254 Endsystemen (256 Bitkombinationen abzüglich der reservierten Muster ganz Null und ganz Eins). Der Adressbereich mit dem höchsten Bitmuster „111“ wurde für zukünftige Verwendung reserviert; ein Teil davon wurde schließlich (höchstes Bitmuster „1110“) für die Verwendung mit IPv4-Multicast definiert, und ein Teil bleibt zum Zeitpunkt der Abfassung dieses Dokuments weiterhin reserviert.

Ende der 1980er Jahre führte die Expansion und Kommerzialisierung des ehemaligen Forschungsnetzes dazu, dass viele neue Organisationen mit einem schnell wachsenden Internet verbunden wurden, und jede neue Organisation benötigte eine Adresszuweisung gemäß dem Klasse-A/B/C-Adressierungsplan.

Als die Nachfrage nach neuen Netzwerknummern (insbesondere im Klasse-B-Bereich) ein annähernd exponentielles Wachstum aufwies, begannen einige Mitglieder der Betriebs- und Engineering-Gemeinschaft, sich Sorgen um die langfristigen Skalierungseigenschaften des Klasse-A/B/C-Systems zu machen, und begannen zu überlegen, wie die Richtlinie zur Vergabe von Netzwerknummern und die Routing-Protokolle geändert werden könnten, um dieses Wachstum zu bewältigen. Im November 1991 gründete die Internet Engineering Task Force (IETF) die Arbeitsgruppe ROAD (Routing and Addressing), um die Situation zu untersuchen. Diese Gruppe trat im Januar 1992 zusammen und identifizierte drei Hauptprobleme:

  1. Erschöpfung des Klasse-B-Netzwerkadressraums. Eine grundlegende Ursache dieses Problems ist das Fehlen einer Netzwerkklasse angemessener Größe für mittelgroße Organisationen. Klasse C mit maximal 254 Host-Adressen ist zu klein, während Klasse B mit bis zu 65534 Host-Adressen für die meisten Organisationen zu groß ist, aber die beste verfügbare Option für die Nutzung von Subnetzen darstellte.

  2. Wachstum der Routing-Tabellen in Internet-Routern über die Kapazität der aktuellen Software, Hardware und Personen hinaus, sie effizient zu verwalten.

  3. Mögliche Erschöpfung des 32-Bit-IPv4-Adressraums.

    Es war klar, dass die damals aktuellen Wachstumsraten des Internets die ersten beiden Probleme zwischen 1993 und 1995 akut werden lassen würden. Die bereits laufenden Arbeiten zur topologischen Adresszuweisung für den Connectionless Network Service (CLNS), die der Gemeinschaft auf der IETF in Boulder im Dezember 1990 vorgestellt wurden, führten zu Überlegungen, wie der 32-Bit-IPv4-Adressraum umstrukturiert werden könnte, um seine Lebensdauer zu verlängern. Die Arbeiten innerhalb der ROAD-Gruppe folgten und führten schließlich zur Veröffentlichung von [RFC1338] und später von [RFC1519].

    Die Konzeption und der Einsatz von CIDR zielten darauf ab, diese Probleme durch Bereitstellung eines Mechanismus zu lösen, um das Wachstum der globalen Routing-Tabellen zu verlangsamen und die Konsumrate des IPv4-Adressraums zu verringern. Er löst nicht und versucht nicht, das dritte Problem zu lösen, das von längerfristiger Natur ist; stattdessen bemüht er sich, die Schwierigkeiten im Kurz- und Mittelfristigen ausreichend zu mildern, damit das Internet effizient weiterbetrieben werden kann, während Fortschritte bei einer langfristigeren Lösung erzielt werden.

    Zusätzliche historische Hintergründe zu dieser Bemühung und zur ROAD-Gruppe finden sich in [RFC1380] und auf [LWRD].