3. Classless-Adressierung als Lösung
- Classless-Adressierung als Lösung
Die von der Gemeinschaft entwickelte Lösung bestand darin, das System der Klasse-A/B/C-Netzwerkadresszuweisung zugunsten der Verwendung von hierarchischen Blöcken von „classless“-IP-Adressen (bezeichnet als Präfixe) zu ersetzen. Die Präfixzuweisung soll der zugrunde liegenden Internet-Topologie ungefähr folgen, damit Aggregation genutzt werden kann, um die Skalierbarkeit des globalen Routing-Systems zu erleichtern. Eine Implikation dieser Strategie ist, dass Präfixzuweisung und -aggregation im Allgemeinen entlang der Provider-Kunden-Beziehungen erfolgen, da dies die Art und Weise ist, wie die Internet-Topologie bestimmt wird.
Als sie ursprünglich in [RFC1338] und [RFC1519] vorgeschlagen wurde, war dieser Adressierungsplan als relativ kurzfristige Antwort gedacht, mit einer Dauer von etwa drei bis fünf Jahren, in der eine dauerhaftere Adress- und Routing-Architektur entworfen und implementiert würde. Wie die Daten der ursprünglichen Dokumente vermuten lassen, hat CIDR seine erwartete Lebensdauer bei weitem überschritten und ist zur mittelfristigen Lösung für die oben beschriebenen Probleme geworden.
Beachten Sie, dass wir im Folgenden die aktuellen Richtlinien und Verfahren beschreiben, die zur Umsetzung der hier erörterten Allokationsarchitektur eingeführt wurden. Diese Beschreibung ist nicht als Anweisung an die IANA zu interpretieren.
In Kombination mit den von den Regional Internet Registries angewandten Adressverwaltungsstrategien (Einzelheiten siehe [NRO]) hat der Einsatz einer CIDR-artigen Adressierung auch die Konsumrate des IPv4-Adressraums verringert und damit eine kurz- und mittelfristige Entlastung des oben beschriebenen Problems Nr. 3 geboten.
Beachten Sie, dass dieser Plan – wie definiert – weder die Neuvergabe der Teile des alten „Klasse-C“-Bereichs verlangt noch voraussetzt, die sich nicht für die Aggregation eignen (manchmal „the swamp“ [der Sumpf] genannt). Dies würde die Größe der Routing-Tabellen etwas verringern (die aktuelle Schätzung ist, dass „the swamp“ etwa 15.000 Einträge enthält), aber um den Preis eines erheblichen Renummerierungsaufwands. Ebenso gibt es keine strikte Anforderung, dass eine beliebige Endstelle ihre Adressen neu vergeben muss, wenn sie den Transit-Dienstleister wechselt, aber Endstellen werden ermutigt, dies zu tun, um die Notwendigkeit einer expliziten Bekanntgabe ihrer Präfixe im globalen Routing-System zu beseitigen.
3.1. Grundkonzept und Präfix-Notation
In der einfachsten Form besteht der Übergang von Klasse-A/B/C-Netzwerk- nummern zu classless-Präfixen darin, explizit zu machen, welche Bits in einer 32-Bit-IPv4-Adresse als die mit einer Endstelle verbundene Netzwerknummer (oder das Präfix) interpretiert werden und welche zur Nummerierung der einzelnen Endsysteme innerhalb der Endstelle verwendet werden. In der CIDR-Notation wird ein Präfix durch eine 4-Oktett-Menge dargestellt, genau wie eine traditionelle IPv4-Adresse oder eine Netzwerkadresse, gefolgt vom Zeichen „/“ (Schrägstrich) und einem Dezimalwert zwischen 0 und 32, der die Anzahl der signifikanten Bits beschreibt.
Beispielsweise wird das ursprüngliche „Klasse-B“-Netzwerk 172.16.0.0 mit impliziter Netzwerksmaske 255.255.0.0 als Präfix 172.16.0.0/16 definiert; das „/16“ gibt an, dass die Maske zum Extrahieren des Netzwerkteils des Präfixes ein 32-Bit-Wert ist, bei dem die 16 höchstwertigen Bits Einsen und die 16 niederwertigen Bits Nullen sind. Ebenso wird die ursprüngliche „Klasse-C“-Netzwerkadresse 192.168.99.0 als Präfix 192.168.99.0/24 definiert; die 24 höchstwertigen Bits sind Einsen und die 8 niederwertigen Bits sind Nullen.
Die Verwendung von classless-Präfixen mit expliziten Präfixlängen ermöglicht eine viel flexiblere Anpassung von Adressraumblöcken an die tatsächlichen Bedürfnisse. Wo früher nur drei Netzwerkgrößen verfügbar waren, können Präfixe definiert werden, um jeden Block mit einer Zweierpotenz von einer bis 2^32 Endsystemadressen zu beschreiben. In der Praxis wird der Pool nicht zugewiesener Adressen von der Internet Assigned Numbers Authority ([IANA]) verwaltet. Die IANA nimmt Allokationen aus diesem Pool nach Bedarf an die Regional Internet Registries vor. Diese Allokationen erfolgen in Form zusammenhängender, an 2^24-Adressen-Blöcken (auch Präfixe /8 genannt) ausgerichteter Blöcke. Die Regional Internet Registries (RIRs) wiederum allokieren oder weisen kleinere Adressblöcke an Local Internet Registries (LIRs) oder Internet Service Provider (ISPs) zu. Diese Einheiten können die Zuweisung direkt nutzen (wie dies im Allgemeinen bei einem ISP der Fall ist) oder können eigene Sub-Allokationen von Adressen an ihre Kunden vornehmen. Diese Adresszuweisungen der RIRs variieren je nach Bedarf eines jeden ISP oder LIR. Beispielsweise könnte ein großer ISP einen Block von 2^17 Adressen (ein Präfix /15) zugewiesen bekommen, während ein kleinerer ISP einen Block von 2^11 Adressen (ein Präfix /21) zugewiesen bekommt.
Beachten Sie, dass die Begriffe „allocate“ (zuweisen/allokieren) und „assign“ (zuteilen) in der Internet-Adressregistratur eine genaue Bedeutung haben; „allocate“ bezieht sich auf die Delegation eines Adressraumblocks an eine Organisation, von der erwartet wird, dass sie weitere Sub-Delegationen vornimmt, und „assign“ wird für Endstellen verwendet, die den erhaltenen Adressblock direkt nutzen (d. h. einzelne Hosts nummerieren).
Die folgende Tabelle bietet eine praktische Übersicht für alle CIDR-Präfixgrößen und gibt die Anzahl der möglichen Adressen in jedem Präfix sowie die Anzahl der Präfixe dieser Größe an, die im 32-Bit- IPv4-Adressraum nummeriert werden können:
notation addrs/block # blocks
-------- ----------- ----------
n.n.n.n/32 1 4294967296 "host route"
n.n.n.x/31 2 2147483648 "p2p link"
n.n.n.x/30 4 1073741824
n.n.n.x/29 8 536870912
n.n.n.x/28 16 268435456
n.n.n.x/27 32 134217728
n.n.n.x/26 64 67108864
n.n.n.x/25 128 33554432
n.n.n.0/24 256 16777216 legacy "Class C"
n.n.x.0/23 512 8388608
n.n.x.0/22 1024 4194304
n.n.x.0/21 2048 2097152
n.n.x.0/20 4096 1048576
n.n.x.0/19 8192 524288
n.n.x.0/18 16384 262144
n.n.x.0/17 32768 131072
n.n.0.0/16 65536 65536 legacy "Class B"
n.x.0.0/15 131072 32768
n.x.0.0/14 262144 16384
n.x.0.0/13 524288 8192
n.x.0.0/12 1048576 4096
n.x.0.0/11 2097152 2048
n.x.0.0/10 4194304 1024
n.x.0.0/9 8388608 512
n.0.0.0/8 16777216 256 legacy "Class A"
x.0.0.0/7 33554432 128
x.0.0.0/6 67108864 64
x.0.0.0/5 134217728 32
x.0.0.0/4 268435456 16
x.0.0.0/3 536870912 8
x.0.0.0/2 1073741824 4
x.0.0.0/1 2147483648 2
0.0.0.0/0 4294967296 1 "default route"
n ist ein 8-Bit-Dezimalwert. Point-to-Point-Links werden in [RFC3021] detaillierter erörtert.
x ist ein 1- bis 7-Bit-Wert, basierend auf der Präfixlänge, in die höchstwertigen Bits des Oktetts verschoben und in Dezimalform umgewandelt; die niederwertigen Bits des Oktetts sind Null.
In der Praxis wurden Präfixe mit einer Länge von weniger als 8 bisher weder zugewiesen noch zugeteilt, obwohl Routen zu solchen kurzen Präfixen in Routing-Tabellen existieren können, wenn bzw. sobald aggressive Aggregation durchgeführt wird. Zum Zeitpunkt der Abfassung dieses Dokuments ist keine dieser Routen im globalen Routing-System zu beobachten, aber Bedienfehler und andere Ereignisse haben dazu geführt, dass einige davon (d. h. 128.0.0.0/1 und 192.0.0.0/2) in der Vergangenheit in bestimmten Netzen beobachtet wurden.