Zusammenfassung

  • Können Kunden den Dienst eines Unternehmens plötzlich nicht erreichen, muss das Unternehmen wissen, welches Netz den Fehler untersuchen kann. Eine AS-Nummer weist auf eine Routingpolitik-Grenze hin, benennt aber weder alle beteiligten Anbieter noch die Ausfallursache.
  • RFC 1930 erklärte 1996, dass die Nummer eine Routingpolitik-Grenze kennzeichnet; die RIPE-Antragsform von 1994 trennte Verwaltungs- und Technikangaben.

Analyse

Ein anschauliches, ausdrücklich hypothetisches Beispiel: Kunden eines Onlinehändlers können die Bezahlseite nicht öffnen; abgebrochene Bestellungen kosten das Geschäft Umsatz, und der Support muss schnell den richtigen Ansprechpartner finden. Ist die Seite über einen Internetanbieter unerreichbar, über einen anderen aber erreichbar, können die beteiligten Netze ihre angekündigten Routen prüfen. Eine AS-Nummer weist dabei auf eine Grenze der Routingpolitik hin. Sie beweist jedoch nicht, welcher Anbieter den Fehler verursacht hat, wer den Verkehr tatsächlich weiterleitete oder ob das Problem an anderer Stelle lag.

Wer den Nummerninhaber vorschnell für den verantwortlichen Diensteanbieter hält, kann Zeit bei der falschen Stelle verlieren. Genau deshalb ist die Unterscheidung praktisch relevant. RFC 1930 zog 1996 die Grenze ausdrücklich: Ein autonomes System umfasst IP-Adressbereiche, die unter einer einzigen, klar festgelegten Routingpolitik betrieben werden.

Bei einem Kunden mit nur einem Anbieter hat das eine konkrete Folge. Folgen seine Routen der Politik des Anbieters, ist ein eigenes AS laut RFC 1930 gewöhnlich unnötig; die Präfixe können im AS des Anbieters bleiben. Ein mehrfach angebundener Standort ist anders gelagert, wenn er eigene Präferenzen gegenüber mehreren Anbietern ausdrücken muss. Entscheidend sind nicht einfach mehr Kabel, Router oder Verträge, sondern eigenständige Routingentscheidungen, die andere Netze in den Ankündigungen erkennen sollen.

Das Antragsverfahren hatte diese Unterscheidung bereits sichtbar gemacht. RIPE-109 vom 1. März 1994 teilte einen AS-Antrag in einen administrativen und einen technischen Teil. Der erste war verpflichtend; technische Angaben durften anfangs fehlen, sollten aber nachgereicht werden. Das Formular enthielt ein AS-Objekt mit as-in- und as-out-Ausdrücken, um zu beschreiben, welche Routen ein Betreiber von Peers annimmt und welche er ihnen ankündigt. RFC 1930 sagt ausdrücklich, dass seine weiter gefasste Leitlinie auf diesem regionalen RIPE-Dokument beruht.

Die BCP korrigierte damit auch einen Kategorienfehler. Die klassische Definition verband ein AS mit einer einzigen technischen Verwaltung und einem gemeinsamen internen Routingprotokoll. RFC 1930 hielt dagegen fest, dass ein AS mehrere interne Protokolle und Metriken einsetzen und nach außen trotzdem einen kohärenten Routingplan zeigen kann. Umgekehrt kann ein Unternehmen mehrere Routingpolitiken enthalten. Die Grenze verläuft dort, wo andere Netze die Politik sehen, nicht entlang des Organigramms oder der Geräteliste.

Die Genauigkeit war auch wegen des begrenzten Nummernraums wichtig. RFC 1930 beschrieb die AS-Nummer damals als 16-Bit-Feld und nannte rund 5.100 zugeteilte Nummern, von denen 1996 weniger als 600 aktiv im globalen Routing waren. Das sind historische Angaben der Autoren, keine aktuellen Zählwerte. Das Dokument warnte vor AS-Anträgen aus bloßer Gewohnheit und reservierte 64512 bis 65535 für private Nutzung. RFC 4893 führte 2007 einen schrittweisen Übergang zu vier Oktetten in BGP samt Kompatibilitätsmechanismen ein; RFC 6793 löste diese Spezifikation später ab.

Diese Geschichte handelt nicht nur von Knappheit, sondern davon, was eine Nummer abbilden soll. Eine ASN kann in einem öffentlichen Register oder BGP-Pfad eine Grenze der Routingpolitik markieren. Sie beweist allein weder, wer jeden Router betreibt, noch ob eine Route angenommen wird oder wo ein Dienst verfügbar ist. Antrag, Protokoll und Netzbeobachtung sind verschiedene Belege. Wer sie gleichsetzt, überlädt einen nützlichen Bezeichner mit einer Aussage, die er nicht tragen kann.

Quellen