Zusammenfassung
- Tomoya Yoshida verfasste mit Philip Smith und Gaurab Raj Upadhaya den APNIC-Vorschlag prop-061: Netzwerkanleitungen sollten eigene AS-Nummern für Beispiele bekommen.
- Im August 2008 einigte sich die APNIC-Policy-SIG auf Bereiche für 16- und 32-Bit-ASNs. Im Dezember erschien RFC 5398, verfasst von Geoff Huston.
- IANA reserviert bis heute 64496–64511 und 65536–65551 für Dokumentation und Beispielcode. Das sind 32 Nummern, die im Lehrbuch auftreten dürfen und im produktiven BGP-Nachbarn nichts zu suchen haben.
Copy, Paste, fremder Anschluss
Eine Schulungsfolie braucht Namen für ihre Netze. Also tippt jemand eine griffige AS-Nummer in die Musterkonfiguration. Beim Vorführen macht sie genau, was sie soll. Wochen später landet dieselbe Datei auf einem Laborrouter mit Verbindung zum produktiven Netz. Der Router besitzt keinen Sinn für Anführungszeichen. Die hübsche Beispielsnummer kann längst einem echten Betreiber gehören.
Tomoya Yoshida arbeitete an genau den Stellen, an denen solche Beispiele ernst werden. Seine APNIC-Biografie von 2008 nennt Backbone-Planung bei OCN, Peering und Routing-Registry-Arbeit bei NTT und JPNIC. Gemeinsam mit Philip Smith und Gaurab Raj Upadhaya brachte er prop-061 ein. Die Bitte war überschaubar: ein paar ASNs, die man gefahrlos in Schulungen schreiben kann, statt einem fremden Netz die Rolle des Statisten aufzudrängen.
Die überarbeitete Fassung zählt die früheren Ausweichmanöver auf. Autoren nutzten private Nummern, Kennungen ihres Arbeitgebers, einprägsame öffentliche Werte oder Nummern, die gerade noch nicht vergeben waren. Letztere besitzen ein Ablaufdatum, das niemand auf die Folie schreibt. Ein später zugeteilter Wert macht aus dem alten Beispiel einen aktuellen Namensvetter. Der Vorschlag warnte außerdem vor Konfigurationen, die aus Übungen auf Geräte mit Produktionsanschluss kopiert werden. Schon der Weg von der Vorlage zum Gerät zeigt, wo der Fehler entsteht.
Ein Satz vor und einer hinter der Schwelle
Die Policy-SIG einigte sich bei APNIC 26 am 28. August 2008 auf den Vorschlag und ergänzte beide Zahlenwelten: 16 Bit und 32 Bit. Am Folgetag lag Version 2 vor. Die APNIC-Chronik dokumentiert die achtwöchige Kommentierungsphase und den Beschluss, auf einen RFC zu warten. Der kam im Dezember. RFC 5398 stammt von Geoff Huston und würdigt die APNIC-Vorarbeit von Yoshida, Smith und Upadhaya ausdrücklich.
Im aktuellen IANA-Register stehen 64496–64511 und 65536–65551 weiterhin als Dokumentations- und Beispielnummern. Der erste Block liegt unmittelbar vor dem privaten Bereich. Der zweite überschreitet die 16-Bit-Grenze, sodass sich auch vier Oktette mit passenden Beispielen erklären lassen. RFC 5398 mahnt, im operativen BGP keine Nachbarschaft mit diesen reservierten ASNs einzurichten.
Yoshida half, einen unscheinbaren Engpass zu beseitigen: Ein Fachtext braucht plausible Zahlen, aber kein echtes Netz als unfreiwilligen Mitspieler. 32 sauber beschriftete Nummern reichen dafür erstaunlich weit. Manche Infrastrukturverbesserung passt eben auf einen Spickzettel.
Originalquellen
Mitgliederbriefing
Detaillierter Profilkontext
Melden Sie sich mit der richtigen Mitgliedschaftsstufe an, um das vollständige Briefing und die Quellennotizen freizuschalten.
Nur für Strategic Circle
Strategic Circle
Offen für alle Leser. Schalten Sie Profil-Briefings nach Beitritt und Anmeldung frei.
Strategic Circle beitretenNur für Leadership Alliance
Leadership Alliance
Für qualifizierte Inhaber von IP-Assets und Management; melden Sie sich an, um Leadership-Alliance-Briefings freizuschalten.
Leadership Alliance beitreten





