Primäre Domain
Internet-Infrastruktur
Innerhalb der Facette Primäre Domain bündelt Internet-Infrastruktur die Berichterstattung nach primärem Themenbereich, sodass Leser einen fokussierten Bereich der Internetinfrastruktur, Governance, Konnektivitätsmärkte oder des digitalen Kapitals verfolgen können. Die Seite führt verwandte Artikel, öffentliche Belege, Institutionen, Unternehmen, Personen, regionale Verflechtungen, operative Abhängigkeiten und Marktkontext zusammen, die sonst über verschiedene Kategorieseiten verstreut wären. Sie erläutert den Themenbereich, die wahrscheinliche Akteursgruppe, den Markt- oder Governance-Kontext und das Quellenmaterial, das Leser beim Vergleich von Signalen heranziehen sollten. Betreiber, Analysten und mit Governance befasste Leser können erkennen, wie derselbe Themenbereich in Ereignissen, Profilen, Marktveränderungen, Belegen aus öffentlichen Quellen, regionalen Abhängigkeiten und langfristigen Infrastrukturentscheidungen immer wieder auftaucht.
Geschichte
ICPv2 nach RFC 2186: Was ein HIT tatsächlich belegt — und was nicht
ICPv2 wurde für eine enge operative Entscheidung entworfen: Ein Cache kann benachbarte Caches nach einer bestimmten URL fragen und ihre Antworten bei der Wahl einer Bezugsquelle berücksichtigen. RFC 2186 macht aus diesem Signal jedoch keinen Beleg dafür, dass ein Objekt…
Geschichte
Der Tunnel war ein Hop. Seine Routen waren zwei: RFC 2185
Für einen IPv6-Router konnte ein Tunnel wie eine saubere Punkt-zu-Punkt-Verbindung aussehen, obwohl das Paket darunter ein unabhängig geroutetes IPv4-Netz durchquerte. RFC 2185 legte die daraus entstehende Pflicht offen: IPv6 musste das Paket zum richtigen Kapselungspunkt führen…
Fallakte
RFC 1644: Ein akzeptiertes SYN war noch kein Ausführungsbeleg
T/TCP durfte Anfragedaten aus dem ersten SYN an den Serverprozess weiterreichen, wenn dessen Verbindungszähler neuer als der gespeicherte Wert war. Damit wurde eine Transportentscheidung beschleunigt; die Anwendung stellte dadurch noch keinen Beleg über Ausführung oder…
IETF
Das Register ist getrennt. Der Collector muss noch beweisen, was er gelesen hat: RFC 9736
RFC 9736 gibt den Peer-Up-Informationen von BMP ein eigenes TLV-Register. Damit ist die Zuständigkeit für Erweiterungen sauber geregelt. Ob ein produktiver Sender, Parser oder Datenspeicher dieselbe Nachricht korrekt behandelt hat, bleibt eine eigenständige Beweisfrage.
Geschichte
Drei DNS-Server können einen einzigen Ausfallweg haben
Drei NS-Namen in einer Zone sind noch keine drei unabhängigen Rettungswege. Wenn alle Maschinen denselben Raum, Stromkreis, LAN-Uplink oder Providerpfad nutzen, kann ein Ereignis die gesamte sichtbare Redundanz beseitigen. RFC 2182 machte daraus 1997 eine Betriebsregel…
Geschichte
Paul Barans Überlebenskurve hatte Bedingungen
Ein Angriff entfernt mehrere Knoten. Zwei Endpunkte sind noch intakt. Gibt es zwischen ihnen weiterhin einen Pfad? Paul Baran machte aus dieser Frage ein messbares Modell. Spätere Erzählungen machten daraus häufig ein Versprechen vom unzerstörbaren Netz. In den RAND-Memoranden…
IETF
Das letzte LIE wurde akzeptiert. Der Fabric war noch nicht bewiesen: RFC 9719
Ein korrektes Signal kann zu einer falschen Entscheidung führen, wenn sein Geltungsbereich verloren geht. RFC 9719 macht den zuletzt akzeptierten LIE maschinenlesbar. Für den Zustand des gesamten RIFT-Fabrics ist er jedoch erst der Anfang der Beweiskette.
Geschichte
Das Postfach war gelöscht – und eine Sitzung las weiter: RFC 2180
Die Schwierigkeit lag nicht darin, dass ein Server keine Antwort gab. Er konnte `OK` sagen und dennoch durfte eine bereits ausgewählte Sitzung weiterhin auf den Inhalt zugreifen. RFC 2180 machte sichtbar, dass Befehlsabschluss und einheitliche Wirklichkeit nicht dasselbe sind.
Geschichte
RFC 2174: Der Eintrag war gültig, der Ausgang blieb gesperrt
Ein MAPOS-Switch konnte den besseren Weg bereits kennen, den neuen virtuellen Ursprung bestimmen und den passenden Port im Broadcast-Bitmap vormerken. Trotzdem durfte er dort noch nicht senden. RFC 2174 gab diesem Zwischenzustand eine eigene Uhr: Erst nach der Konvergenz wurde…
Geschichte
RFC 2171: Die Adresse gehörte zum Switch-Port, nicht zum Rechner
Ein Rechner konnte unverändert bleiben und im nächsten Augenblick trotzdem eine andere MAPOS-Adresse benötigen. Entscheidend war, an welchem Port sein Kabel endete. Die Link-Layer-Adresse beschrieb diesen Anschluss in der Vermittlungsstruktur — keine dauerhafte Identität des…
Berichte
Die Route fehlte in der Tabelle. Der Verkehr folgte ihr trotzdem: APNIC 62
Ein Netz kann eine ungültige Route korrekt verwerfen und Pakete dennoch an einen Nachbarn weitergeben, der den engeren Präfix annimmt. Die auf der APNIC 62 besprochene Beobachtung verlangt deshalb drei getrennte Belege: die lokale Entscheidung, die Auswahl im nächsten AS und den…
Berichte
APNIC 62: Der Widerruf war veröffentlicht, die Browser entschieden verschieden
Ein Zertifikat stand auf der Sperrliste. Ob eine Verbindung deshalb endete, war eine andere Frage. Geoff Hustons Vorführung bei APNIC 62 macht die Grenze zwischen dem Eintrag einer Zertifizierungsstelle und der tatsächlichen Entscheidung eines Clients sichtbar.
Geschichte
RFC 2167: Eine Weiterleitung fand den Verwalter, nicht die Wahrheit
Im RWhois-Entwurf konnte ein Eintrag gespeichert sein und trotzdem aus der vorgesehenen Suche verschwinden. Entscheidend war nicht allein der Serverbetrieb, sondern ob Bezeichnung und Ablagebereich zusammenpassten.
Geschichte
RFC 2143: Der SCSI-Bus war schnell, aber kein Netz gleichberechtigter Rechner
1997 war ein kurzer SCSI-Bus als Verbindung naher Workstations verlockend. Doch zwei Rechner, die am selben Kabel hängen, können einander nicht schon deshalb unaufgefordert IP-Pakete schicken. RFC 2143 beschrieb zwar ein sauberes Paketformat; die eigentliche Hürde lag in den…
IETF
Der Sammeltransport löst nicht die Frage, wer den Sicherheitsfall abschließt
Ein IETF-Entwurf soll mehrere Security Event Tokens in einem HTTPS-Aufruf befördern. Das spart Anfragen, verschiebt aber den entscheidenden Nachweis nicht: Eine Empfangsbestätigung ist kein Beleg dafür, dass ein Konto im anderen Verantwortungsbereich tatsächlich gesperrt wurde.
Geschichte
Eine TCP-Verbindung endet, ihre Messung bleibt: RFC 2140 und das Gedächtnis eines Rechnerpaars
Ein kurzer Abruf kann vorbei sein, sobald TCP eine brauchbare Laufzeit zum Gegenüber geschätzt hat. Der nächste Abruf muss deshalb nicht zwingend ohne Hinweis beginnen. RFC 2140 entwarf 1997 ein Gedächtnis für bestimmte Beobachtungen zwischen denselben Rechnern. Schwieriger als…
IETF
ACTN im Paket- und Glasfasernetz: Der Übergang braucht eine Fehlerordnung
Die Architektur kann den Weg eines Auftrags vom Koordinator zu Paket- und optischen Domänen beschreiben. Zwei Gutachten im IETF Last Call fragen nun nach dem schwierigen Rest: Wer erkennt auseinanderlaufende Zustände, wer stoppt weitere Eingriffe und wer übernimmt eine nur…
Geschichte
RFC 2133: Der Socket-Aufruf blieb, der Adressvertrag wechselte
Nach der Einführung von IPv6 konnte eine Anwendung weiterhin `connect()` aufrufen. Ob sie die übergebene Adresse richtig verstand, war eine andere Frage. RFC 2133 trennte vertraute Funktionsnamen von den neuen Datenstrukturen und Zuständen dahinter.
IETF
SAVNET im Last Call: Der Pfad ist noch kein Herkunftsbeweis
Ein vorhandener Rückweg zum Präfix sagt nicht automatisch, ob das Paket über den richtigen Nachbarn eingetroffen ist. Der IESG-Last-Call zu SAVNET prüft bis zum 1. Oktober, wie diese Lücke zwischen autonomen Systemen beschrieben und welche Anforderungen an künftige Lösungen…
Geschichte
Vier Angaben in einem DHCP-Paket ergaben noch keinen Geräteausweis
RFC 2132 gab der Herstellerklasse, dem Client-Identifier, der Wunschliste und den herstellerspezifischen Daten verschiedene Aufgaben. Wer sie zu einer einzigen gesicherten Identität verschmilzt, verwechselt eine Konfigurationsverhandlung mit dem Nachweis ihres Ergebnisses.