Menü

Explosionsartig wachsende Routing-Tabellen machen IETF nervös

vorlesen Drucken Kommentare lesen 141 Beiträge

Bei der Internet Enginering Task Force (IETF), der zentralen Standardisierungsorganisation für Internet-Protokolle, denkt man über grundlegende Änderungen in der Architektur des Internets nach. Am Routing-Protokoll BGP (Border Gateway Protocol) soll nachgebessert werden; vereinzelt gibt es sogar Stimmen, die eine Ablösung durch ein neues Protokoll fordern. Vor allem aber dachte man beim heute zu Ende gehenden IETF-Treffen in Prag laut über eine Trennung von "Identifier" und "Location" für die IP-Adressierung nach. Auslöser der gleich in mehreren IETF-Bereichen hektisch geführten Diskussion ist die rasante Zunahme der Routen, die die Routing-Tabellen allmählich zu groß werden lassen.

Der scheidende IETF-Chef Brian Carpenter spricht von einer Zunahme der Endnodes im Netz bis 2050 auf zehn Milliarden. Davon werden nach Einschätzung von Carpenter eine Milliarde "multihomed" also über verschiedene Provider ans Netz angebunden sein. Derzeit habe man etwa eine Milliarde Endnodes, und nur ein Bruchteil davon seien über mehrere Provider angebunden, sagte Carpenter. Aus Sicht der Experten ist die Mehrfachanbindung deswegen dramatisch, weil für sie providerunabhängige, direkt in die Routing-Tabellen eingetragene Adressen benötigt werden. Rund 200.000 BGP-Routen sind in die aktuellen Tabellen eingetragen; laut einer Analyse von Geoff Housten von APNIC, der IP-Registry für Asien und den Pazifik, wuchs diese Zahl allein im Jahr 2006 um 17 Prozent.

Kunden bevorzugten nicht nur für das Multihoming, sondern auch für mögliche Providerwechsel ohne aufwendige Neunummerierung der eigenen Systeme die providerunabhängigen Adressen. Die Provider auf der anderen Seite haben ein Interesse an überschaubaren Routing-Tabellen. Wachsen diese zu schnell, brauchen sie immer mächtigere, schnellere Router. Zwar gebe es noch kein "Hot-Box"-Problem: Noch für fünf bis zehn Jahre könnten Chips hergestellt werden, die den Rechenaufwand mit der heute verwendeten Technik für Versorgung und Kühlung bewältigen können. Auf jeden Fall werde aber durch den gleichzeitig wachsenden Update-Datenverkehr eine Menge Rechenleistung und Energie verbraten.

Außerdem, meinte Carpenter, habe man auch noch keine Lösung für die Beibehaltung des Ende-zu-Ende Prinzips, dem sich die IETF verpflichtet fühlt und dessen Beibehaltung ein wichtiges Ziel bei der Einführung von IPv6 ist. IPv6 bietet den dafür notwendigen großen Adressraum, die Umsetzung, um diesen ohne Address-Translation und riesige Routing-Tabellen aufs Netz zu bringen, fehlt aber noch.

Zwei Lösungswege wurden in Prag in den verschiedenen IETF-Arbeitsbereichen (der Routing- und der Internet-Area) diskutiert. Die Routing-Experten denken vor allem darüber nach, wie sie das letzte aus BGP herausholen könnten. Während die Mehrheit ganz offensichtlich an BGP festhalten will, gibt es dabei auch Stimmen, die ein ganz neues Routing-Protokoll einführen wollen, etwa aus der Routing-Forschungsgruppe RRG bei der Internet Research Task Force (IRTF), dem eher der Forschung als der Normierung zugewandten Bereich der IETF.

Die Arbeit an BGP biete zwar kurzfristige Lösungen –"das Endspiel ist das aber noch nicht," sagte einer der Area-Direktoren. Die langfristige Lösung sehen viele in der Trennung von Identifier und Locator bei der Adressierung. Multihoming ließe sich damit lösen, die Identifer blieben dem Kunden erhalten, ganz egal, ob er den Provider wechselt, verschiedene Provider habe oder mobil unterwegs sei. Allerdings müssten damit die losgelösten Identifier für die Endgeräte irgendwo per Datenbank wieder auf die Locator im Netzwerk, die IP-Adressen, abgebildet werden. Wo und wie dieses Mapping passieren soll, ist noch völlig offen. "Es kann direkt beim Host passieren, aber auch irgendwo im Netz", sagt Dave Thaler von Microsoft, der eine Reihe von Design-Überlegungen vorstellte.

Ideen schwirren eine Menge herum. Der Identifier könnte wieder eine spezielle IP-Adresse, aber auch ein Name sein. Das Mapping könnte also im DNS abgebildet werden, denn dort habe man einen stabilen Mapping-Prozess. Letztlich bedeutet der zusätzliche Mapping-Prozess aber auch nichts anderes als eine Art von ins Netz geschobene Adress-Translation. Für jede der Ideen und Standpunkte gibt es allerdings auch jemanden, der heftig die Augen verdreht. Allen ist dabei klar, dass sie an eben diese Reaktionen auch bei der Implementierung denken müssen. Nicht zuletzt kommt beispielsweise ins Spiel, ob ein zentrales Mapping nicht ein Risiko für den Datenschutz darstellen kann.

Angesichts der komplizierten Fragen gibt es daher auch Stimmen, die vor einer übergroßen Eile warnen. Daniel Karrenberg, Cheftechnologe beim RIPE, der europäischen IP-Adress-Registry in Amsterdam, erinnerte an die überhastete Entwicklung von IPv6. Einige der Features von IPv6 seien letztlich der Eile geschuldet. "Es gab eine regelrechte Panikstimmung, dass die Adressen ausgehen würden", meinte Karrenberg. "Keinen Grund zur Panik" sah dagegen Carpenter. Die Routing-Tabellen seien zwar ein ernstes Problem, aber die IETF habe genug Zeit, um es zu lösen.

Eine Reihe von IETF-Teilnehmern widersprachen da ganz heftig. "Die IETF sollte viel mutiger sein, bitte ein bisschen mehr Panik", forderte Routing-Experte Dave Meyer; der Vertreter eines deutschen Netzbetreibers empfahl ebenfalls, das Ganze doch als eher dringlich zu sehen. Wenn man "bleeding-edge" Hochleistungsmaschinen in immer kürzeren Zyklen anschaffen müsse, mache sich das im Preis bemerkbar, warnte er.

Organisatorisch hat die IETF reagiert, um das Thema rasch anzugehen. Es wurde ein eigenes Routing- und Adressing-Direktorat geschaffen, drei lange Sitzungen wurden speziell auf das Thema verwandt, im Mai soll es gar ein Interim-Treffen noch vor dem nächsten IETF-Treffen geben. Den Identifier-Locator-Split soll dann schon bald eine Arbeitsgruppe behandeln. Alle Fragen, sagen langjährige Beobachter, sind allerdings nicht wirklich neu. Auch die neue Adressierungslösung wurde schon früher diskutiert – und wieder vergessen. (Monika Ermert) / (jk)