Autonome Systeme (AS) und ihre eindeutige Bezeichnung mit Hilfe von ASNs (engl. autonomous system numbers) spielen eine ungemein wichtige Rolle in der Organisation des Internets. In diesem Artikel lernen wir die Strukturierung der ASNs kennen und schauen uns an, wie dem Engpaß, der aufgrund der 16-bittigen Notation entstanden ist, entgegen getreten werden kann.

Grundlagen

Ausgehend vom Routing, ist das Internet in zwei Hierarchien gegliedert: Domains, die eine eigene interne Routing-Architektur aufweisen (und jeweils unterschiedliche Routing-Protokolle verwenden können) und autonome Systeme, die eine homogene Routing-Architektur für das Routing zwischen autonomen Systemen ermöglichen. Domains verwenden ein Routing-Protokoll, daß speziell an die Anforderungen für das interne Routing angepaßt ist. Es existieren verschiedene Protokolle für solche Anwendungen, die als Interior Gateway Protocols (IGP) zusammgefaßt werden. Sie verwalten eine vollständige Topologie ihrer Routing-Domain und sind in der Lage, optimale Pfade zwischen zwei Punkten innerhalb der Domain zu errechnen. Zwar ist diese Technik auch für sehr große Domains geeignet, allerdings übersteigt die Dimension des Internets die Fähigkeiten solcher Protokolle, so daß für das Routing zwischen autonomen Systemen andere Technologien zum Einsatz kommen. Bekannte Vertreter der IGPs sind beispielsweise OSPF (Open Shortest Path First) und IS-IS (Intermediate System to Intermediate System).

Routing zwischen autonomen Systemen wird als Inter-Domain Routing bezeichnet und beschreibt, wie zwischen Domains geroutet werden kann, ohne jedoch Pfade durch autonome Systeme festzulegen. Ein Pfad zwischen Domains wird durch die Kennungen aller Domains definiert, die zu durchqueren sind, um die Ziel-Domain mit dem entsprechenden Adresspräfix zu erreichen. Diese Funktionalität übernimmt das in der Version 4 vorliegende Border Gateway Protocol (BGP).

Wir bezeichnen einzelne Routing-Domains als autonome Systeme, weil sie zum einen durch eine Instanz verwaltet werden und zum anderen völlig unabhängig von anderen Routing Domains sind. Damit ist eine Routing-Domain eine autonome Einheit innerhalb des Internets und aus diesem Grund ein autonomes System. Jedes AS wird durch eine sog. Autonomous System Number (ASN, autonome Systemnummer) eindeutig identifiziert. ASNs sind als 16-bittige Ganzzahlen definiert, die eine Adressierung von insgesamt 65536 autonomen Systemen erlauben. ASN 0 ist reserviert und wird beispielsweise zur Bezeichnung nicht gerouteter Netzwerke genutzt. Das gleiche gilt für die größte ASN. Die Aufteilung des ASN-Raums zeigt folgende Tabelle:

Bereich	Anwendung
0	Reserviert, identifiziert nicht geroutete Netzwerke
65.535	Reserviert
64.512 – 65.534	für private Netzwerke
23.456	wird für ASN-Pool-Übertragungen
1 – 64.511 (ohne 23.456)	verfügbar für Internet-Routing.

ASNs zusammen mit den Adresspräfixen der Domains entsteht ein Interdomain-Routing Space. Die Routing-Informationen werden verbreitet indem das ursprüngliche AS sein Adresspräfix und seine ASN angibt, so daß alle empfangenden autonomen Systeme einen Pfad zu diesem Usprungs-As ermitteln können. Immer wenn ein AS erreicht wird fügt es seine ASN und das Adresspräfix hinzu. Auf diese Weise kann an jeder Stelle im Pfad zwischen den autonomen Systemen die Sequenz der durchschrittenen autonomen Systeme genau ermittelt werden. Abbildung 1 zeigt ein einfaches Netzwerk bestehend aus 5 AS. AS 14 mit dem Präfix 10.1.2.0/24 sendet ein sog. Prrefix Advertisment (Präfixbekanntmachung) aus, daß irgendwann alle autonomen Systeme durchlaufen ist und schließlich in AS 10 mündet.

Jedes AS fügt neben seinem Adresspräfix auch seine ASN hinzu. AS 10 empfängt nun zwei Advertisments: eines für den Pfad (12, 14) und ein weiteres für den Pfad (11, 13, 14). AS 10 kann jetzt drei Dinge feststellen:

• Da es nur mit AS 12 und AS 11 verbunden ist, von beidem jedoch ein Advertisment empfangen hat, ist es nicht nötig, das Advertisment weiterzuleiten.
• Die beiden Pfade der Advertisments sind unterschiedlich lang, so daß leicht eine Metrik aufgebaut werden kann.
• Durch die Pfadinformationen kann das AS leicht erkennen, ob eine Schleife entstanden ist.

Die Metrik eines Pfades sagt aus, wie viele autonome Systeme durchlaufen werden müssen, um ein bestimmtes Adresspräfix zu erreichen. Sind mehrere Pfade für das gleiche Adresspräfix vorhanden, wählt der Algorithmus des BGP automatisch den kürzeren Pfad aus; in unserem Beispiel wäre das der Weg über AS 11, der nur ein As durchquert. Nur durch das explizite Aufzählen der autonoment System im Pfad verhindert Loops, denn wenn ein AS Advertisments empfängt, das die eigene AS enthält wird das Präfix einfach verworfen.

Nicht jedes Netzwerk im Internet benötigt eine ASN. Eine ASN wird nur benötigt, wenn das Netzwerk eigene Routing-Richtlinien erfordert, beispielsweise jene von ISPs. Ein privates Netzwerk, das im Internet geroutet werden soll, aber über eine Anbindung an einen Provider verfügt, unterliegt damit den gleichen Routing-Richtlinien wie denen des Providers, auch wenn das Netzwerk BGP für das Routing zu diesem Provider verwendet. Bei einer solchen Konstellation spricht man in der Regel von einem Upstream Provider, der nicht notwendigerweise ein ISP, sondern auch ein Betreiber eines periphären Netzwerkes mit einer öffentlichen ASN sein kann. Das private Netzwerk verwendet stattdessen eine private ASN aus dem Bereich von 64.512 – 65.534 um eine BGP-Sitzung zu ermöglichen, die beim Advertisment der Route durch den Upstream Provider entfernt wird. Anschließend tritt das Netzwerk des Upstream Providers als Ursprungs-AS des Advertisments auf. Abbildung 2 verdeutlicht diesen Vorgang:

Der Einsatz einer eigenen öffentlichen ASN macht für Netzwerke mit zwei oder mehr Transit-Verbindungen Sinn, allerdings nur, wenn sich die Routing-Richtlinien von denen des Upstream-Netzwerks unterscheiden.

Da viele autonome Systeme der gleichen Organisation oftmals räumlich voneinander getrennt sind, aber in der Regel auch von dieser administriert werden, verfügen sie gleichzeitig über die gleiche ASN. Abbildung 3 zeigt eine Beispieltopologie mit der gleichen ASN in zwei getrennten Subdomains eines autonomen Systems.

AS 10a mit der Netzwerkadresse 10.0.1.0/25 gibt seine ASN bekannt und AS 11 und 12 leiten das Advertisment weiter. Sobal AS 10b das Advertisment (12, 11, 10) von AS 12 empfängt, sieht es seine eigene ASN und verwirft das Advertisment, denn es hat ja bereits AS 10 durchlaufen. Das gleiche passiert in umgekehrter Richtung, wenn AS 10b mit der Netzwerkadresse 10.0.1.128/25 seine ASN bekanntgibt. AS 10a auf der anderen Seite lehnt das empfangene Advertisment von AS 11 (11,12,10) ab. Damit entsteht allerdings eine Lücke, denn AS 10a weiß nicht, wie es zu AS 10b routen soll. Wenn AS 10a eine statische Route zu AS 10b über AS 11 einrichtet und AS 10b eine statische Route zu AS 10a über AS 12 können sich die beiden Subdomains wieder erreichen.

ASNs werden knapp

Es stehen insgesamt etwa 64.510 ASNs zur Verfügung (siehe Tabelle 1) und bereits jetzt sind etwa 40.000 allokiert worden (weiterführende Statistiken finden Sie hier: http://www.ripe.net/docs/ripe-353.html). Ganz klar, daß wir bald eine extreme Verknappung der ASNs erleben werden, wenn nichts unternommen wird.

Aktuelle Aufstellung des ASN-Pools

Auch wenn es den Anschein haben mag, gibt es keine Korrelation zwischen der Anzahl der Internet Service Providers (ISPs) und der Anzahl der allokierten ASNs. Pro Jahr werden etwa 3.500 ASNs vergeben (siehe http://www.potaroo.net/tools/asns/), so daß bei bestehender Praxis spätestens 2010 alle RIRs ihre ASN-Pools vollständig ausgeschöpft haben werden. Ein wichtiger Faktor für das Auslaufen der ASNs ist steigende Bedarf an hochverfügbaren Verbindungen für geschäftskritische Anwendungen. Dazu bemühen Betreiber von Netzwerken oftmals mehrere Upstream-Provider und definieren mit Hilfe von eigenen ASNs und BGP unterschiedliche Routing-Richtlinien für jeden Upstream. Welche weiteren Faktoren größeren Einfluß auf die Entwicklung haben werden ist schwer vorherzusagen.

Von den 64.510 verfügbaren ASNs sind etwa 40.000 von der IANA in 1.024er-Blöcken an die Regional Internet Registries (RIRs) vergeben worden, die ihrerseits die ASNs an ISPs und Endbenutzer-Netzwerke weitergeben. Einige der vergebenen ISP-ASNs sind im Internet nicht sichtbar und werden damit auch bekanntgegeben (advertised). Auch dazu liefert http://www.potaroo.net/tools/asns/ interessante Statistiken.

Der Übergang von 16-Bit zu 32-Bit ASNs

Aktuellen Projektionen zufolge, sind 2010 keine ASNs für ISPs mehr verfügbar. Die logische Schlußfolgerung ist, daß bis dahin ein neues Interdomain-Routing-Protokoll etabliert wurde (welches vollkommen ohne ASNs auskommt) oder von 16-bittigen ASNs auf 32-Bit-ASNs umgeschwenkt wird. Letzere Option scheint die bessere Wahl zu sein, auch wenn es einige Zeit dauern wird, bis sie Verbreitung finden und die Anzahl der Netzwerke wächst weiter von Tag zu Tag.

Der Übergang zu längeren ASNs erfordert einen wohldurchdachten Plan: (a) zunächst müssen die erforderlichen Standards und Best Practices geschaffen werden. Anschließend (b) muß stablier Code für den Produktiveinsatz entwickelt werden, der die neuen Standards implementiert. Stabil heißt in diesem Zusammenhang auch, daß die neuen Spezifikation uneingeschränkt (c) rückwärtskompatibel sind, so daß 16-Bit- und 32-Bit-ASNs für eine sehr lange Zeit koexistieren können. Und letztendlich wäre es wünschenswert, wenn der Einsatz der neuen Technik beginnt, bevor (d) die ASNs vollständig aufgebraucht sind.

Der neue Weg

Im Oktober 2005 tauchte der bereits in der 12. Version befindliche Internet Draft (I-D) in den Archiven des IETF Internet Draft Repositories auf, der genau diese Problematik betrachtete: draft-ietf-idr-as4bytes-12.txt. Bei Erweiterung des ASN-Feldes in BGP-Nachrichten würde eine theoretische maximale Anzahl von 4,294,967,296 ASNs zur Verfügung stehen. Die wichtigste Frage, die sich stellt, ist: wie schaffen wir es, das alte Format bestehend aus 2 Oktetten mit dem neuen Format aus 4 Oktetten zu kombinieren?

Der Ansatz sieht vor, daß neue BGP-Speaker (im weiteren Verlauf NEW BGP genannt) über BGP Capability Advertisments in OPEN Messages (RFC2842) ihren Peers mitteilen, über welche Fähigkeiten (engl. capabilities) sie verfügen. Unterstützt ein Router die neue 4-Byte-ASN-Semantik, so wird er das NEW_AS_PATH-Attribut verwenden, das die gleiche Semantik aufweist wie das klassische AS_PATH-Attribut, mit dem Unterschied, daß die ASN als 4 Oktette kodiert ist. Von Bedeutung ist nur ein Szenario: die Kommunikation zwischen NEW BGP und OLD BGP, und zwar in beide Richtungen.

Die längere 4-Byte-ASN wird von jetzt an mit einer neuen Syntax beschrieben: .. Folglich können wir nun theoretisch ASNs von 0.0 bis 65535:65535 vergeben. Mit Hilfe dieser Notation wird der Übergang zur neuen 4-Byte-ASN erleichtert, aber die Kompatibilität zur alten Notation bewahrt, wie wir gleich sehen werden.

Während die Kommunikation zwischen zwei NEW BGP-Geräten relativ einfach ist, denn beide unterstützen 32-Bit-ASNs, bedürfen die Übergänge von OLD BGP zu NEW BGP und umgekehrt besonderer Aufmerksamkeit. Wenn ein NEW_AS_PATH-Attribut durch eine AS_PATH-Zone geleitet werden muß ist die Frage, wie wir (a) die 32-Bit-Semantik von NEW BGP durch die AS_PATH-Zone bringen und (b) wie wir Pfade rekonstruieren, wenn sie aus einer OLD BGP-Umgebung in eine NEW BGP-Umgebung überführt werden müssen. Abbildung 4 zeigt, wie es geht:

Auf der linken und rechten Seite befinden sich autonome Systeme mit Unterstützung für NEW BGP und in der Mitte finden wir zwei AS, die als Transit-Netzwerke dienen sollen. AS 0:2 sendet ein BGP Advertisment aus, AS 1:5 verarbeitet es wie gewohnt und leitet es an AS 11 weiter. AS kennt 32-Bit-ASNs nicht und antwortet mit einem Fehler auf das Capability Advertisment von AS 1:5. Dennoch nimmt es das BGP Advertisment an, denn AS 1:5 kodiert die NEW BGP-Daten als NEW_AS_PATH-Attribut und die alten Daten in das AS_PATH-Attribut. Dazu werden die NEW BGP ASNs folgendermaßen in 16-Bit-Daten übersetzt: ist die Ziffer vor dem Doppelpunkt eine 0, wird sie einfach gestrichen. Aus AS 0:2 wird beispielsweise AS 2. Ist es keine 0, wandert sie in das AS_PATH-Attribut, wird aber durch eine vordefinierte 16-Bit-ASN 23456 ersetzt, wie wir beim Übergang von AS 1:5 zu AS 11 sehen können. Der 32-Bit-ASN-Pfad bleibt erhalten, aber 2-Oktett-ASNs werden hier nicht eingetragen. Sobald das BGP Advertisment eine 16-Bit-Zone verläßt wird der ursprüngliche Pfad wieder zusammengesetzt.

Der beschriebene Ansatz ist relativ einfach umzusetzen und kann auf unbestimmte Zeit parallel mit OLD BGP-Geräten eingesetzt werden. Außerdem sichert er die Loop-Detection und die Auswahl des kürzesten AS-Pfades auch über AS_PATH- und NEW_AS_PATH-Zohnen ohne Eingriffe in bestehende Strukturen gleichermaßen zu. Die einzige Vorraussetzung dafür ist, daß sie bereitwillig die NEW_AS_PATH-Updates verbreiten, die von 32-Bit-AS emittiert werden.