NTT DOCOMO BUSINESS und AS4713: Was eine Netzidentität nach einer

Zusammenfassung

Nach Angaben von NTT DOCOMO BUSINESS wurde NTT Communications Corporation am 1. Juli 2025 in NTT DOCOMO BUSINESS, Inc. umbenannt. Aktuelle Einträge von APNIC, RIPEstat und JPNAP verbinden den neuen Firmennamen, die Bezeichnung OCN und AS4713 auf unterschiedlichen Dokumentationsebenen. PeeringDB zeigt dagegen weiterhin einen älteren Namen. Diese Mischung weist auf getrennt gepflegte Datensätze hin; sie erlaubt nicht, jede Bezeichnung wie einen einheitlichen Rechtsnachweis zu behandeln.
AS4713 stützt klar begrenzte Aussagen über eine registrierte Netzidentität, zu einem bestimmten Zeitpunkt beobachtete Routen, eine einzeln geprüfte Routenursprungs-Autorisierung und produktspezifische Routingkontrollen. Daraus folgen weder das Eigentum an allen beobachteten Präfixen noch ein lückenloser Betrieb während der Umbenennung, weltweite Erreichbarkeit, kurze Latenz oder eine bestimmte Dienstqualität.

Verzeichniseintrag: NTT DOCOMO Business, Inc

Bildhinweis: Das begleitende Foto ist eine synthetische redaktionelle Rekonstruktion. Zu sehen ist eine erfundene, unabhängige Fachperson, die unbeschriftete Unterlagen neben einem neutralen Glasfaserkabel vergleicht. Das Bild zeigt weder Beschäftigte, Standorte, Geräte oder Kundendaten von NTT DOCOMO BUSINESS, NTT Communications, OCN, APNIC oder JPNAP noch eine echte Routentabelle oder eine Live-Ansicht von AS4713. Die Papiere und die Karte dienen nur der Illustration und belegen weder Firmenidentität noch Präfixeigentum, Routengültigkeit, Leistung oder Dienstkontinuität.

Analyse

Ein Name änderte sich, die einzelnen Datensätze folgten ihrem eigenen Takt

NTT DOCOMO BUSINESS verwendet auf seinem öffentlichen Unternehmensprofil den heutigen Firmennamen. Dort heißt es, NTT Communications Corporation habe den Namen zum 1. Juli 2025 in NTT DOCOMO BUSINESS, Inc. geändert. Eine zuvor veröffentlichte Mitteilung der NTT Group hatte die geplante Umbenennung angekündigt. Gemeinsam stützen diese Angaben eine präzise, aber begrenzte Aussage: Das Unternehmen erklärt, dass die angekündigte Namensänderung an diesem Datum wirksam wurde.

Mehr sollte aus diesen beiden Veröffentlichungen nicht herausgelesen werden. Die betrachteten Quellen enthalten beispielsweise keinen unabhängigen Auszug aus einem staatlichen Handelsregister, der sämtliche rechtlichen Folgen dokumentiert. Sie belegen nicht, dass alle Verträge, technischen Datenbanken, Konten oder Netzobjekte in derselben Minute umgestellt wurden. Ebenso wenig beschreiben sie eine Übernahme, eine Fusion, die Übertragung aller Vermögenswerte oder eine Neugründung.

Verantwortungsvolle Formulierungen sprechen deshalb von der vom Unternehmen mitgeteilten Umbenennung und nicht von weitergehenden Rechtsvorgängen, für die hier kein Beleg vorliegt.

Die öffentlich sichtbaren Register des Internets funktionieren nicht wie eine einzige, gleichzeitig aktualisierte Datenbank. Die aktuelle APNIC-zu-JPNIC-RDAP-Antwort für die autonome Systemnummer 4713 führt den Namen OCN und verweist in ihren Angaben auf NTT DOCOMO BUSINESS, Inc. RIPEstat verbindet in seiner Inhaberbezeichnung ebenfalls OCN mit dem neuen Firmennamen. In der Teilnehmerliste von JPNAP stehen NTT DOCOMO BUSINESS, OCN und AS4713 für die Standorte Tokio und Osaka zusammen. Das Profil bei PeeringDB verwendet hingegen weiterhin „NTT Communications Corporation (OCN)“.

Solche Unterschiede machen einen Eintrag nicht automatisch falsch oder wertlos. Jede Stelle erfüllt einen anderen Zweck, hat eigene Verantwortliche, Aktualisierungsrhythmen und Begriffe. Ein Unternehmensprofil beschreibt die aktuelle Identität aus Sicht des Herausgebers. Ein regionales Internetregister dokumentiert Nummernressourcen. Ein Routing-Beobachtungsdienst zeigt, was seine Messpunkte zu einer bestimmten Zeit gesehen haben. Ein Internetknoten veröffentlicht eine Teilnehmerliste. Ein Verzeichnis für Zusammenschaltungen unterstützt die Kontaktaufnahme zwischen Netzen und enthält teils von den Betreibern selbst gepflegte Felder.

Die richtige Frage lautet deshalb nicht: „Welche Seite besitzt die alleinige Wahrheit?“ Besser ist: „Welche Frage soll dieser Datensatz beantworten, wann wurde er beobachtet und wer muss Abweichungen zu anderen Datensätzen klären?“

Für den Alltag ist diese Trennung wichtig. Der Einkauf braucht die genaue Vertragspartei. Die Netztechnik benötigt das autonome System, erlaubte Präfixe und Routingregeln. Die IT-Sicherheit braucht aktuelle Kontakte, Autorisierungen für Routenursprünge und Filtervorgaben. Die Einsatzleitung bei einer Störung muss wissen, wer Änderungen freigeben und wieder zurücknehmen darf. Wenn alle Beteiligten nur „NTT“ speichern, zeigt eine Umbenennung, wie wenig diese Sammelbezeichnung tatsächlich aussagt.

Was eine autonome Systemnummer in einfachen Worten bedeutet

Eine autonome Systemnummer, kurz ASN, ist eine öffentliche Nummer für ein Netz, das Routinginformationen mit anderen Netzen austauscht. AS4713 ist eine solche Nummer. In den untersuchten Datensätzen steht sie in Verbindung mit OCN und NTT DOCOMO BUSINESS. Sie ist keine Handelsregisternummer, kein Kundenkonto, keine IP-Adresse, keine Seriennummer eines Routers und kein Gütesiegel für einen Dienst.

Das Internet besteht aus vielen unabhängig betriebenen Netzen. Sie müssen einander mitteilen können, über welche Wege bestimmte Adressbereiche erreichbar sind. Dafür dient das Border Gateway Protocol, kurz BGP. Stark vereinfacht lautet eine Ankündigung: „Dieser Adressblock ist über dieses autonome System erreichbar.“ Andere Netze erhalten viele solcher Meldungen, wenden ihre eigenen Regeln an und wählen daraus Pfade.

Die ASN schafft dabei eine relativ stabile Referenz. Menschen, Produkte, Marken und Firmennamen können sich ändern, ohne dass jedes Mal eine neue Routingnummer und eine weltweit gleichzeitige Umstellung nötig wird. Das senkt den Betriebsaufwand und das Risiko eines unnötigen Bruchs. Die Nummer kann als wiedererkennbarer Bezugspunkt für Richtlinien, Register und Beobachtungen bestehen bleiben, während Verwaltungsdaten angepasst werden.

Stabilität ist jedoch kein Beweis für lückenlose Kontinuität. Dass AS4713 heute in einem Register und gestern in Routendaten erscheint, zeigt nicht, dass jedes Paket eines jeden Kunden während der Umbenennung im Juli 2025 ohne Unterbrechung zugestellt wurde. Es zeigt auch nicht, dass interne Systeme den neuen Namen rechtzeitig übernommen haben oder stets dasselbe Team jede Route freigab. Belegt ist nur eine fortbestehende öffentliche Routingidentität im Rahmen der jeweiligen Quelle und ihres Zeitpunkts.

Ein Vergleich macht die Grenze verständlicher. Die Nummer einer Bahnlinie kann gleich bleiben, obwohl der Betreiber seinen Firmennamen ändert. Die Liniennummer hilft Fahrgästen und Leitsystemen, die Verbindung zu erkennen. Sie beweist nicht, wem jedes Gleis gehört, ob jeder Zug pünktlich fuhr oder ob alle Verträge angepasst wurden. Für diese Fragen braucht es andere Unterlagen. Eine ASN erfüllt im Austausch zwischen Netzen eine ähnlich begrenzte Aufgabe.

Der APNIC-zu-JPNIC-RDAP-Eintrag ist ein Nachweisbuch, aber keine vollständige Eigentumskarte

APNIC ist das regionale Internetregister für den asiatisch-pazifischen Raum. Bei der untersuchten japanischen Ressource leitet der APNIC-Endpunkt die Abfrage an den RDAP-Dienst von JPNIC weiter. RDAP bedeutet Registration Data Access Protocol. Der Standard stellt Registrierungsdaten zu Internet-Nummernressourcen in strukturierter Form bereit, sodass Menschen und Software keine frei gestaltete Webseite auslesen müssen.

Das geprüfte APNIC-zu-JPNIC-RDAP-Objekt identifiziert AS4713, nennt OCN, ordnet den Eintrag Japan zu, führt das Registerobjekt als aktiv und enthält eine Beschreibung mit NTT DOCOMO BUSINESS, Inc. Das ist ein starker Primärbeleg für eine eng umrissene Feststellung: Die aktuelle RIR-Registerebene verbindet diese Bezeichnungen mit AS4713.

Der Eintrag ist keine Erklärung, dass das Unternehmen jeden jemals hinter AS4713 beobachteten IP-Adressblock rechtlich besitzt. Netze können im Rahmen dokumentierter Vereinbarungen Adressen von Kunden ankündigen. Ein Anbieter kann Routing für Adressraum übernehmen, dessen Registrierung bei einer anderen Organisation liegt. Während Migrationen, Abwehrmaßnahmen oder Produktänderungen kann sich der Ursprung eines Präfixes verändern. Zudem können Verwaltungs- und Betriebskontakte voneinander abweichen.

Auch „aktiv“ hat einen engen Sinn. Der Begriff bezeichnet den Zustand des Registerobjekts. Er ist keine Verfügbarkeitsmessung. Ein aktiver Eintrag kann gleichzeitig mit einer Routingstörung, einer defekten Anschlussleitung, einem DNS-Problem, einem Ausfall einer Anwendung oder einer fehlerhaften Kundenkonfiguration bestehen. Umgekehrt würde eine vorübergehend nicht erreichbare Registerseite nicht bedeuten, dass das laufende Netz verschwunden ist.

Ein Register ist deshalb vor allem ein Verzeichnis und Nachweisbuch. Es hilft, Nummern eindeutig zu halten, Bezeichnungen und Kontakte zu dokumentieren sowie Änderungen nachvollziehbar zu machen. Das unterstützt Verantwortung und Koordination. Es ersetzt weder das tatsächlich laufende Netz noch Verträge oder Messungen, mit denen ein Kunde die Erreichbarkeit seiner Anwendung prüft.

Was die Routenbeobachtungen vom 5. August zeigen

RIPEstat bündelt Informationen aus Registern und aus der Beobachtung von Internet-Routen. Für AS4713 wurde ein Datensatz für den 5. August 2026 zwischen 00:00 und 16:00 Uhr UTC betrachtet. Darin fanden sich 187 beobachtete Präfixeinträge: 181 für IPv4 und sechs für IPv6.

Diese Zahl ist nur zusammen mit der Methode aussagekräftig. Der Dienst weist darauf hin, dass Routen ausgeschlossen werden, die von weniger als zehn vollständigen RIPE-RIS-Datenlieferanten gesehen wurden. Das Ergebnis ist daher keine Liste jeder Route, die irgendwo im Internet existieren könnte. Es ist eine gefilterte Ansicht dessen, was die verwendeten Beobachter unter der genannten Regel empfangen haben.

Der Routing-Status für den zurückgegebenen Schnappschuss um 16:00 Uhr UTC zeigte AS4713 bei 326 von 326 einbezogenen IPv4-Beobachtungspartnern und 322 von 322 einbezogenen IPv6-Partnern. Außerdem meldete die Antwort 181 IPv4-Präfixe, sechs IPv6-Präfixe und 122 beobachtete Nachbarn. Der Dienst warnte zugleich, dass die angeforderte Abfragezeit angepasst wurde, weil sie nach dem jüngsten verfügbaren Datenstand lag. Wer das Ergebnis dokumentiert, sollte daher den tatsächlich zurückgegebenen Zeitpunkt und die Warnung festhalten.

Es wäre falsch, aus der vollständigen Sichtbarkeit innerhalb dieser Auswahl eine weltweite Erreichbarkeit abzuleiten. Die Nenner 326 und 322 stehen für die in dieser RIPE-RIS-Ansicht enthaltenen Partner, nicht für jedes Netz, jedes Gerät und jeden Nutzer. Ein Routenbeobachter kann eine Ankündigung empfangen, obwohl ein bestimmter Kunde seinen Dienst wegen einer lokalen Zugangsstörung, eines Filters, einer Überlastung, eines DNS-Fehlers, einer Firewallregel oder eines Anwendungsproblems nicht erreicht.

Auch die 122 Nachbarn sind nicht automatisch 122 zahlende Kunden, Transitlieferanten oder direkte Peeringpartner. Sichtbare Beziehungen können je nach Datendienst unterschiedlich eingeordnet werden. Manche Pfade erscheinen nur bei bestimmten Beobachtern. Die Werte ändern sich zudem mit Routingregeln und Abdeckung.

Die 187 Präfixeinträge sind somit ein Beleg für beobachtete Routingaktivität, aber weder ein Grundbuch noch eine Qualitätsnote. Sie beantworten die Frage, welche Einträge während des angegebenen Fensters die Methode dieses Beobachters für AS4713 erfüllten. Sie beantworten nicht, wem jeder Adressblock gehört, wer ihn verwendet, wie schnell er reagiert oder ob jede Route korrekt autorisiert war.

Ein gültiges RPKI-Ergebnis gilt für genau ein geprüftes Paar

Zum Material gehört außerdem die Prüfung einer einzelnen Beziehung zwischen Routenursprung und Präfix über die Resource Public Key Infrastructure, kurz RPKI. Damit kann ein Halter von Adressressourcen eine signierte Route Origin Authorisation, eine ROA, veröffentlichen. Darin steht, welches autonome System ein bestimmtes Präfix ankündigen darf und gegebenenfalls bis zu welcher maximalen Präfixlänge.

Geprüft wurde das Paar AS4713 und 61.207.0.0/16. RIPEstat gab dafür mit dem Validator Routinator den Status „valid“ zurück. Die passende ROA nannte den Ursprung 4713 und eine maximale Länge von 16. Für genau diese Abfrage ist das eine aussagekräftige Sicherheitsinformation.

Es ist kein Zertifikat für alle mit AS4713 verbundenen Routen. Ein Netz mit vielen Präfixen kann unterschiedliche ROAs, verschiedene Maximallängen oder für einzelne Routen keine abdeckende ROA besitzen. Autorisierungen können erstellt, geändert und zurückgezogen werden. Schon ein anderes Präfix oder ein anderer Ursprung würde eine neue Prüfung verlangen.

Die Ursprungsvalidierung hat noch eine weitere Grenze: Sie prüft die Verbindung zwischen Präfix und ASN am Ursprung der Route. Sie authentifiziert nicht jedes autonome System auf dem gesamten Pfad. Sie belegt nicht, dass Glasfaser und Geräte funktionieren, dass ein Pfad kurze Laufzeiten hat, dass keine Pakete verloren gehen oder dass die Zielanwendung antwortet.

Eine saubere Darstellung lautet deshalb: „Dieses Ursprung-Präfix-Paar war bei dieser Abfrage gültig.“ Dazu gehören Zeitpunkt, Abfrage und Validator. Die pauschale Aussage „AS4713 ist durch RPKI abgesichert“ wäre dagegen viel weiter, als ein einzelner Befund trägt.

Für den Betrieb bleibt die vollständige Pflege entscheidend: Adressbestände, Kundenberechtigungen, Routingobjekte, ROAs, Maximallängen, beabsichtigte Ursprünge, Filter und Überwachung müssen zusammenpassen. Eine gültige Stichprobe zeigt, dass diese Beziehung kontrollierbar ist; sie macht Bestandsführung und Aufsicht nicht überflüssig.

Produktunterlagen beschreiben Kontrollen, keine gemessenen Ergebnisse

Die Routingdokumentation zu Super OCN Flexible Connect liefert eine weitere Ebene. Für das dort beschriebene Produkt verwendet die OCN-Seite AS4713. Die Seite erläutert statisches Routing und BGP-Varianten sowie Möglichkeiten für eine eigene Kundennummer und für qualifizierten, vom Kunden bereitgestellten IP-Adressraum.

Sie nennt auch konkrete Vorgaben für diesen Dienst. Das BGP-Profil verlangt ein MD5-Passwort zur Authentisierung, setzt eine maximale Präfixzahl von 1.000 und eine minimale Hold Time von 30 Sekunden und beschreibt BGP-Communities zur Steuerung von Prioritäten. Zugleich erklärt die Seite ausdrücklich, dass LFS und BFD nicht unterstützt werden.

Solche Details zeigen die Arbeit hinter einer scheinbar einfachen Verbindung. Jemand muss prüfen, ob eine Kunden-ASN zulässig ist. Vom Kunden eingebrachter Adressraum muss kontrolliert werden. Präfixgrenzen müssen festgelegt und überwacht, Authentisierungsdaten sicher ausgetauscht und Community-Regeln freigegeben werden. Änderungen brauchen Tests, Beobachtung und einen Rückweg.

Die Zahlen dürfen nicht verallgemeinert werden. Eine Obergrenze von 1.000 Präfixen ist nicht die Größe von AS4713, sondern eine Schutzvorgabe für eine Sitzung unter den beschriebenen Produktbedingungen. Eine minimale Hold Time von 30 Sekunden ist keine zugesicherte Wiederherstellungszeit. MD5 schützt einen bestimmten Mechanismus einer BGP-Sitzung; es macht nicht den gesamten Dienst gegen Fehler oder Angriffe immun.

BFD, Bidirectional Forwarding Detection, wird häufig zur schnellen Erkennung von Pfadausfällen eingesetzt. Dass die zitierte Produktseite BFD als nicht unterstützt nennt, ist kein Beweis für schlechte Dienstqualität. Es bedeutet, dass Kontinuitätspläne mit den tatsächlich vorhandenen Funktionen, Zeitgebern, Messungen und Eskalationswegen arbeiten müssen.

Eine Herausgeberdokumentation belegt beabsichtigtes Produktverhalten und veröffentlichte Möglichkeiten. Sie beweist nicht unabhängig, dass jeder Kunde alles richtig konfiguriert hat, jede Änderung kontrolliert wurde oder ein bestimmter Vorfall eine vertragliche Zielgröße einhielt. Dafür braucht der Kunde seine Konfigurationen, Protokolle, Messungen, Tickets und Tests.

Warum der Unterschied zwischen PeeringDB und RIPEstat nützlich ist

PeeringDB ist ein von Netzbetreibern gepflegtes Verzeichnis für Zusammenschaltungen. Das betrachtete Profil mit der Nummer 826 verwendet die ältere Bezeichnung „NTT Communications Corporation (OCN)“, nennt ASN 4713 und beschreibt einen regionalen Netzdienstleister. Es führt Zusammenschaltungspunkte und weitere Felder, deren Aktualisierungsstand unterschiedlich sein kann.

In der erfassten Ansicht standen die Zähler für IPv4- und IPv6-Präfixe auf null. Daneben liegt die datierte RIPEstat-Beobachtung von 181 IPv4- und sechs IPv6-Präfixeinträgen. Daraus folgt weder, dass PeeringDB einen Ausfall entdeckt hat, noch dass RIPEstat Routen erfunden hat.

Die Dienste beantworten verschiedene Fragen. PeeringDB ist ein freiwilliges Betriebsverzeichnis. Einzelne Felder können ungepflegt sein oder der Kontaktaufnahme statt einer Live-Zählung dienen. Die RIPEstat-Zahlen stammen aus einer Methode zur Routenbeobachtung und aus einem bestimmten Zeitfenster. Eine Null in einem Verzeichnisfeld kann „hier nicht gepflegt“ bedeuten und nicht „im Netz existiert nichts“.

Das Beispiel zeigt, warum automatische Auswertungen neben Werten auch deren Bedeutung benötigen. Werden beide Zahlen ungeprüft in eine Spalte namens „Präfixzahl“ kopiert, entsteht möglicherweise ein Fehlalarm. Ein besseres System speichert Quelle, Felddefinition, Beobachtungszeit, Pflegeart und Vertrauensniveau. Dann kann es die Abweichung zur Prüfung markieren, ohne eine der Quellen pauschal für falsch zu erklären.

Der Namenswechsel bringt eine zusätzliche Dimension hinein. Ein alter Firmenname kann neben weiterhin nützlichen Daten zu Zusammenschaltungen stehen. Ein neuer Name kann neben einem alten Betriebsfeld erscheinen. Der Abgleich sollte deshalb Feld für Feld erfolgen. Wer alle alten Begriffe blind ersetzt, verliert Herkunft und Historie. Wer sie alle als aktuell stehen lässt, kann Leser und Systeme irreführen.

JPNAP verbindet die Bezeichnungen am Internetknoten – nicht darüber hinaus

In der aktuellen Teilnehmerliste von JPNAP stehen NTT DOCOMO BUSINESS, OCN und AS4713 für die Internetknoten in Tokio und Osaka zusammen. Damit gibt es einen heutigen Bezug zwischen dem aktuellen Firmennamen, der Netz- oder Dienstbezeichnung und der ASN im Zusammenhang eines Internetknotens.

Ein Internet Exchange, kurz IX, ist eine Infrastruktur und Dienstleistung, über die Netze Datenverkehr untereinander austauschen können. Eine Teilnahme erleichtert Zusammenschaltungen und schafft einen sichtbaren betrieblichen Kontaktpunkt. Aus einem Listeneintrag gehen jedoch nicht alle privaten Vereinbarungen, Verkehrsmengen, bevorzugten Wege oder Leistungswerte hervor.

Auch eine Präsenz in Tokio und Osaka beweist nicht, dass ein bestimmter Kunde zwei vollständig getrennte Pfade erhält. Zwei logische Sitzungen können sich einen Gebäudeeingang, eine Transportleitung, die Stromversorgung, Geräte oder ein Betriebsteam teilen. Wer Ausfallsicherheit kauft, muss deshalb die eigenen gemeinsamen Fehlerquellen untersuchen.

Der JPNAP-Eintrag ist am stärksten, wenn er genau für seine sichtbare Aussage genutzt wird: Zum Prüfzeitpunkt verband die Liste diese Bezeichnungen und AS4713 an den genannten Austauschpunkten. Er ersetzt weder einen Vertrag noch eine physische Topologie oder eine Live-Messung.

AS4713 steht nicht für jedes Netz mit einem NTT-Namen

Zwei weitere Quellen helfen, einen häufigen Benennungsfehler zu vermeiden. Ein technischer APNIC-Beitrag aus dem Jahr 2023 unterscheidet das inländische OCN-Netz AS4713 vom Mobilfunknetz AS9605 und vom globalen GIN-Netz AS2914. Eine ältere Produktseite des Herausgebers trennt ebenfalls GIN AS2914 und OCN AS4713 in der Beschreibung eines Dienstes mit zwei autonomen Systemen.

Der APNIC-Beitrag ist eine historische Analyse. Frühere Aussagen über Topologie oder Nutzeranteile sollten daher nicht als aktuelle Tatsachen wiederholt werden. Die Produktseite trägt kein sichtbares Veröffentlichungsdatum und ist werblich geprägt. Sie stützt keine heutigen Behauptungen über Größe, Qualität oder Marktstellung. Für den engeren Punkt sind beide dennoch hilfreich: „NTT“ bezeichnet nicht automatisch eine einzige Routingnummer.

Das ist bei Störungen und Prüfungen entscheidend. Eine Pfadanalyse, in der AS2914 vorkommt, sollte nicht ohne Weiteres AS4713 zugeschrieben werden. Eine Beobachtung aus einem Mobilfunknetz mit AS9605 gehört nicht automatisch zu OCN. Auch ein Konzernname sagt noch nicht, welches Netz, Produkt oder Vertragsverhältnis betroffen ist.

Genaue ASN-Bezeichnungen verringern Fehlzuordnungen. Ein Alarm kann an das Team für das tatsächlich beobachtete Netz gehen statt an eine allgemeine Firmenadresse. Eine Änderungsprüfung kann den passenden Präfixbestand untersuchen. Ein Kunde kann klären, ob sein Ersatzpfad wirklich durch ein anderes Netz führt.

Was eine Umbenennung im Betrieb ins Stolpern bringen kann

Eine Namensänderung wirkt zunächst verwaltungstechnisch. Im Netzbetrieb tauchen Namen jedoch in vielen Systemen auf. Öffentlich sichtbar ist nur ein Teil davon. Intern können dieselben Identitäten in Verträgen, Rechnungsdaten, Zertifikatsunterlagen, Positivlisten, Routingregeln, Überwachungsansichten, Störungskontakten, Lieferantenportalen und Prüfbelegen vorkommen.

Mehrere typische Fehler sind möglich.

Erstens kann eine Kontaktsuche den alten Firmennamen liefern und von einer Person abgelehnt werden, die nur den neuen Namen erwartet. Selbst wenn Telefonnummer und Postfach weiter funktionieren, kostet das während einer Störung Zeit.

Zweitens kann eine automatische Compliance-Regel Namen buchstabengetreu vergleichen. Dann erscheinen „NTT Communications Corporation“ und „NTT DOCOMO BUSINESS, Inc.“ fälschlich als zwei unverbundene Firmen. Das Gegenteil ist ebenso gefährlich: Eine zu grobe Regel kann jedes Netz mit NTT-Bezeichnung zu einer einzigen Einheit zusammenfassen und einen zu großen Geltungsbereich freigeben.

Drittens kann eine Routingdokumentation den Produktnamen OCN verwenden, während im Vertrag der Firmenname und in Messdaten die ASN steht. Fehlt eine gepflegte Zuordnung, kann eine prüfende Person die falsche Präfixliste freigeben oder das falsche Team ansprechen.

Viertens kann vom Kunden bereitgestellter Adressraum falsch einsortiert werden. Ein von AS4713 angekündigtes Präfix kann eine Kundenressource sein, die für diesen Dienst autorisiert wurde. Wer beobachtete Ursprünge ungeprüft in ein Anlagenverzeichnis des Anbieters übernimmt, erzeugt möglicherweise einen falschen Eigentumsanspruch.

Fünftens können Sicherheitsinformationen auseinanderlaufen. ROAs, Routingobjekte, Filter und Kontaktdaten werden häufig von verschiedenen Personen gepflegt. Der Firmenname kann in einer Oberfläche schon aktualisiert sein, obwohl die betriebliche Autorisierung unverändert bleibt. Das kann korrekt sein, muss aber verstanden und nachvollziehbar dokumentiert werden.

Sechstens können Übersichten eine harmlose Datenabweichung als Störung melden oder ein echtes Problem verdecken. Der Präfixwert null bei PeeringDB und die von RIPEstat beobachteten Routen zeigen, warum jede Kennzahl eine genaue Herkunft und Definition braucht. Ein Alarm sollte zunächst fragen, ob der Unterschied erwartbar ist, bevor er einen Netzausfall behauptet.

Die Lösung besteht nicht darin, in jedem System dieselbe Zeichenfolge zu erzwingen. Sinnvoller ist eine gepflegte Zuordnungstabelle mit aktuellem Firmennamen, früherem Namen, Dienstbezeichnung, ASN, Registerkennungen, relevanten Präfixen, Produkt, Vertragspartei und Eskalationsverantwortlichen. Jede Verbindung braucht eine Quelle und ein Prüfdatum.

Automatisierung verteilt Arbeit, sie beseitigt Verantwortung nicht

BGP automatisiert den Austausch von Erreichbarkeitsinformationen. Routenfilter können Ankündigungen außerhalb einer genehmigten Regel automatisch abweisen. RPKI-Prüfprogramme können Ursprung-Präfix-Beziehungen einordnen. Überwachungssysteme erkennen Änderungen in kurzer Zeit. Dadurch sinkt der Aufwand für viele wiederkehrende Einzelschritte.

Gleichzeitig entsteht Aufsichtsarbeit. Jemand definiert die Regeln, genehmigt Ausnahmen, hält den Bestand aktuell und beurteilt, ob eine zurückgewiesene Route auf einen Angriff, eine abgelaufene Autorisierung oder eine legitime Notfalländerung zurückgeht. Änderungen und Rücknahmen müssen getestet werden.

Bei einer Firmenumbenennung wird diese Arbeitsteilung besonders sichtbar. Kommunikation und Recht pflegen die Unternehmensidentität. Registerfachleute betreuen Nummernressourcen und Kontakte. Netztechniker verwalten BGP-Sitzungen und Filter. Sicherheitsteams beobachten RPKI und unerwartete Ursprünge. Kundenteams klären Vertrag und Präfixumfang. Einkauf und Revision halten die Beweiskette zusammen.

Wird Erfolg nur an der Zahl automatisch verarbeiteter Routen gemessen, verschwinden diese menschlichen Kosten aus der Übersicht. Bessere Kennzahlen berücksichtigen Ausnahmen, Fehlalarme, die Zeit bis zur richtigen verantwortlichen Person, erfolgreiche Rücknahmen, veraltete Einträge und den Aufwand für den Abgleich nach einer Firmen- oder Produktänderung.

Automatisierung ist nicht das Problem. Sie führt hinterlegte Annahmen in großem Maßstab aus. Genaue Kennungen und klar begrenzte Datensätze machen diese Annahmen sicherer. Eine unklare Identität kann dagegen aus einem kleinen Datenfehler viele wiederholte Regelverstöße erzeugen.

So können auch Nichtfachleute eine Dienstaussage prüfen

Ein Unternehmen muss keine BGP-Spezialisten aus jedem Einkaufsteam machen. Schon einige klare Fragen trennen belastbare Nachweise von zu großen Versprechen.

Am Anfang steht die Identität: Welche konkrete Gesellschaft ist Vertragspartner? Ist NTT DOCOMO BUSINESS die aktuelle Partei oder liefert eine andere Konzerngesellschaft den Dienst? Welche früheren Namen dürfen noch in technischen Unterlagen erscheinen? Wer bestätigt Änderungen?

Danach folgt das Netz: Welche ASN wird für den Dienst erwartet? Ist es AS4713, AS2914, AS9605 oder eine andere Nummer? Ändert sich die Antwort nach Produkt, Region oder Richtung des Datenverkehrs?

Als Nächstes kommen die Adressen: Wer hält die für das Unternehmen wichtigen Präfixe? Welches System darf sie ankündigen? Wird vom Kunden bereitgestellter Adressraum verwendet? Wo liegen ROAs, Routingobjekte und Freigaben?

Zu den Routingkontrollen gehören weitere Fragen. Nutzt der Dienst statisches Routing oder BGP? Welche Präfixgrenzen gelten? Wie wird die Sitzung authentisiert? Welche Communities werden unterstützt? Welche Methoden zur schnellen Fehlererkennung fehlen? Wer darf Einstellungen ändern, und wer prüft die Änderung?

Auch die Erfolgsmessung muss passen. Öffentliche Routensichtbarkeit kann zeigen, dass ausgewählte Beobachter eine ASN sehen. Sie beweist keine Anwendungsleistung. Der Kunde sollte von relevanten Standorten zu den tatsächlich genutzten Zielen testen und Zeit, Verlust, Latenz, DNS-Auflösung, Anwendungsantwort, Routenkontext und Fehlerquote festhalten.

Zuletzt braucht es einen Kontinuitätstest. Was geschieht, wenn die Hauptleitung, ein Gerät, ein Standort oder eine Route ausfällt? Wechselt der Verkehr auf einen wirklich getrennten Weg? Wie lange dauert die Erholung der Anwendung? Wer entscheidet über eine Rücknahme? Ein Planspiel ist hilfreich, ein kontrollierter technischer Test ist stärker.

So bleibt jeder Nachweis in seinem angemessenen Rahmen. Ein Register belegt einen Registereintrag. Ein Routenbeobachter belegt eine Beobachtung. Eine Produktunterlage belegt eine veröffentlichte Auslegung. Ein Kundentest belegt ein Ergebnis innerhalb seiner Methode und seines Zeitfensters.

Was aus den öffentlichen Angaben nicht hervorgeht

Die betrachteten Quellen belegen keine Verfügbarkeit, Latenz, Paketverlustrate, Kundenzahl oder Marktstellung von AS4713. Sie zeigen nicht, dass NTT DOCOMO BUSINESS alle 187 beobachteten Präfixe hält. Ebenso wenig zeigen sie, dass jede Ankündigung von AS4713 eine gültige ROA besitzt.

Sie beweisen keinen ununterbrochenen Betrieb vor, während und nach der Umbenennung im Juli 2025. Die Datensätze stammen aus verschiedenen Zeitpunkten und dienen unterschiedlichen Zwecken. Eine fortbestehende Kennung und aktuelle Beobachtungen stützen die Kontinuität einer Identität, aber keine vollständige Ausfallchronik.

Die APNIC-Beschreibung ist kein hoheitlicher Eigentumsnachweis. PeeringDB ist kein Live-Inventar aller Präfixe. Eine JPNAP-Teilnahme ist keine Messung von Verkehr oder Leistung. Unterlagen des Anbieters sind keine unabhängige Bestätigung des tatsächlichen Betriebs.

Auch ein Netto-Zeitgewinn durch Routingautomatisierung lässt sich daraus nicht beziffern. Die Werkzeuge automatisieren sichtbar wiederkehrende Schritte. Die Quellen messen aber nicht die Stunden für Richtlinienentwurf, Ausnahmen, Abgleich, Überwachung, Störungen oder Kundenbetreuung.

Diese Nichtaussagen gehören zum Ergebnis. Sie verhindern, dass ein nützlicher technischer Datensatz versehentlich zu einem viel größeren rechtlichen oder kommerziellen Versprechen wird.

Welche Nachweise den Namenswechsel überdauern

Wer die Ebenen getrennt hält, erhält dennoch ein schlüssiges Bild.

Das Unternehmen erklärt, NTT Communications Corporation habe am 1. Juli 2025 den Namen in NTT DOCOMO BUSINESS, Inc. geändert. Die aktuelle APNIC-zu-JPNIC-Registerantwort führt AS4713 als aktives Objekt mit OCN und verweist auf den neuen Firmennamen. Die erfasste RIPEstat-Ansicht zeigt AS4713 als angekündigt und dokumentiert eine begrenzte Zahl von Präfixen und Nachbarn. Ein geprüftes Ursprung-Präfix-Paar war nach RPKI gültig. Produktunterlagen nennen AS4713 für die OCN-Seite eines beschriebenen Dienstes und führen konkrete Routingkontrollen auf. JPNAP verbindet den aktuellen Firmennamen, OCN und AS4713 in Tokio und Osaka.

PeeringDB bewahrt eine ältere Firmenbezeichnung sowie Felder, die nicht mit einem aktuellen Netzinventar verwechselt werden dürfen.

Diese Kette erklärt, warum eine ASN eine dauerhafte betriebliche Identität sein kann, ohne zum universellen Zertifikat zu werden. Die Nummer erlaubt Registern, Netzen und Beobachtern, sich auf eine Routingdomäne zu beziehen. Ihr praktischer Wert hängt davon ab, dass Menschen Kontakte, Autorisierungen, Regeln und Zuordnungen korrekt halten. Die tatsächlich laufende Technik bleibt die Wirklichkeitsebene; verständlich und steuerbar wird sie nur, wenn Unterlagen ihren Geltungsbereich und ihre Herkunft bewahren.

Für Leser bleibt eine bescheidene, aber belastbare Schlussfolgerung: AS4713 belegt im Rahmen der genannten Methoden eine wiedererkennbare, registrierte und beobachtete OCN-Routingidentität. Es belegt nicht automatisch jede rechtliche, kommerzielle oder leistungsbezogene Aussage, die neben dem Namen NTT stehen könnte.

NTT DOCOMO BUSINESS und AS4713: Was eine Netzidentität nach einer Firmenumbenennung noch belegt

Warum es wichtig ist