Classless Inter Domain Routing

Das Internet in seiner derzeitigen Form hat ein kleines Problem, und zwar das Problem, das bald keine IP-Adressen mehr verfügbar sind. Zwar gibt es über 2 Milliarden IP-Adressen, aber durch die Aufteilung in Adreßklassen werden eine Menge davon verschwendet.

Für die meisten Unternehmen ist ein Netz der Klasse A mit mehr als 16 Millionen Adressen zu groß, ein Netz der Klasse C mit nur 254 Adressen aber zu klein, also nehmen sie ein Netz der Klasse B mit 65534 Adressen, von dem sie dann wahrscheinlich nur 10 Prozent oder weniger nutzen.

Bis zur Einführung von IPv6 (das genug Adressen hat um jedes Molekül im bekannten Weltall zu adressieren ) behilft man sich mit dem Classless InterDomain Routing (CIDR)  das in der RFC1519 beschrieben ist.

Dabei werden die verbleibenden Netze der Klasse C in Blöcken mit variabler Länge vergeben. Braucht ein Unternehmen z.B. 2000 IP-Adressen, so erhält es einen Block von 8 aufeinanderfolgenden Klasse C-Netzen, mithin also 2048 Adressen.

Zusätzlich wurden die Regeln für die Aufteilung von Blöcken geändert. Die Welt wurde in vier Zonen aufgeteilt und jede Zone erhält einen Anteil der verbleibenden Klasse C-Netze. Die Zuteilung ist wie folgt:

Adressbereich Zone
194.0.0.0 - 195.255.255.255 Europa
198.0.0.0 - 199.255.255.255 Nordamerika
200.0.0.0 - 201.255.255.255 Mittel- und Südamerika
202.0.0.0 - 203.255.255.255 Asien und pazifischer Raum
204.0.0.0 - 223.255.255.255 reserviert für zukünftige Nutzung

Das sind 32 Millionen Adressen für jeden Bereich und und weitere 320 Millionen in Reserve. Durch die Aufteilung in geographische Bereiche weiß jetzt zum Beispiel jeder Router außerhalb Europas der ein Paket mit Zieladresse 194.x.x.x oder 195.x.x.x bekommt sofort, dass das Paket zum Gateway nach Europa muss.

In Europa sind dann natürlich wieder ausführliche Routing-Tabellen erforderlich. Jetzt könnte man natürlich für alle in Europa möglichen 131.072 Teilnetze eine Route eintragen, aber das würde zu einer Explosion der Routing-Tabellen führen. Stattdessen verwendet man hier statt der standardmäßigen, durch die Klasse benutzten Netmask zu jedem Routingeintrag eine eigene Netmask.

Beispiel: Unternehmen A braucht 2048 Adressen und erhält die Adressen 194.24.0.0 bis 194.24.7.255 mit der Netmask 255.255.248.0 Unternehmen B benötigt 4096 Adressen und erhält die Adressen 194.24.16.0 bis 194.31.255.255 mit der Netmask 255.255.255.240. Schließlich erhält noch Unternehmen C 1024 Adressen von 194.24.8.0 bis 194.24.11.255 mit der Netmask 255.255.255.252

Jetzt werden in ganz Europa die Routing-Tabellen wie folgt aktualisiert:

Unternehmen Adresse Netmask
A 11000010 00011000 00000000 00000000 11111111 11111111 11111000 00000000
B 11000010 00011000 00010000 00000000 11111111 11111111 11110000 00000000
C 11000010 00011000 00001000 00000000 11111111 11111111 11111100 00000000

Jetzt schauen wir uns einmal an was mit einem Paket passiert, das an 194.24.17.7 adressiert ist.

Zuerst wird ein boolesches AND auf die Maske von Unternehmen A ausgeführt so das sich folgendes ergibt:

  11000010 00011000 00010001 00000111
AND 11111111 11111111 11111000 00000000
  11000010 00011000 00010000 00000000

was nicht auf das Interface von Unternehmen A passt. Jetzt wird das gleiche mit der Netmask von Unternehmen B gemacht und es ergibt sich:

  11000010 00011000 00010001 00000111
AND 11111111 11111111 11110000 00000000
  11000010 00011000 00010000 00000000

und das passt auf das Interface von Unternehmen B, weshalb das Paket an dieses Interface geschickt wird.