Zum Hauptinhalt springen

Governance

Governance

Governance-Analyse verfolgt die Institutionen, politischen Prozesse, Normungsgremien, Registeroperationen, Rechenschaftsstreitigkeiten und Betreibergemeinschaften, die prägen, wie das Internet regiert und betriebsfähig gehalten wird.

RIR-WächterFallakteGesellschaft für NummernressourcenICANNIETFGeschichte des InternetsNOGS
Governance Signaldarstellung
GovernanceGovernance
FokusInstitutionelle Governance

Signale für politische Kontinuität, Legitimität und Rechenschaftspflicht in Internet-Governance-Institutionen.

AktuellSieben Governance-Bereiche

RIR-Wächter, Fallakte, NRS, ICANN, IETF, Geschichte des Internets und NOG-Sitzungen

SignalHandeln statt Reden

Bei der Abdeckung liegt der Schwerpunkt auf Umsetzungsnachweisen und institutionellem Verhalten statt auf Positionsbekundungen.

Aktuelle Berichterstattung

Aktuelles zu Governance

7.749 Artikel

DHCPv6 konnte den SIP-Proxy finden, aber keinen Anruf aufbauen: RFC 3319

Geschichte

DHCPv6 konnte den SIP-Proxy finden, aber keinen Anruf aufbauen: RFC 3319

Eine DHCPv6-Antwort konnte einem SIP-Client eine geordnete Liste lokaler ausgehender Proxys übermitteln: als Domänennamen, IPv6-Adressen oder beides. Damit ließ sich der nächste Kontrollpunkt finden. Die Antwort belegte weder eine Registrierung noch abgeschlossene Signalisierung…

2. Okt. 2026
Der Router musste melden, welchen Policy-Graphen er ausführen konnte: RFC 3317

Geschichte

Der Router musste melden, welchen Policy-Graphen er ausführen konnte: RFC 3317

Die Tiefe eines Policy-Graphen war keine ästhetische Frage. Sie konnte an einer Pipeline, einem ASIC oder der zulässigen Verbindung zweier Funktionsblöcke enden.

2. Okt. 2026
Der Endpunkt erkannte Verlust nach Zeit. Die Schicht darunter wartete trotzdem.

IETF

Der Endpunkt erkannte Verlust nach Zeit. Die Schicht darunter wartete trotzdem.

Der Transport hatte gelernt, Umordnung von Verlust zu unterscheiden. Die Sicherungsschicht behandelte ihn weiter wie einen alten Empfänger und hielt sofort weiterleitbare Frames zurück. Der neue INTAREA-Entwurf zeigt damit nicht nur ein Latenzproblem, sondern eine veraltete…

2. Okt. 2026
Zwei Zähler sind noch kein Ende-zu-Ende-Beweis

IETF

Zwei Zähler sind noch kein Ende-zu-Ende-Beweis

Wenn Interface- und Flow-Daten ähnlich aussehen, ist Korrelation verlockend. Ohne stabilen Flow-Anker kann ein System jedoch zwei präzise Messungen zu einer falschen Kausalgeschichte verbinden.

2. Okt. 2026
Die Anwendung konnte belegen, dass der Router erreichbar war: RFC 3316

Geschichte

Die Anwendung konnte belegen, dass der Router erreichbar war: RFC 3316

Auf frühen Mobilfunkverbindungen mit IPv6 konnte eine Rückmeldung der Gegenstelle eine zusätzliche Funksonde ersparen – weil sie genau eine Aussage über ein kurz zuvor gesendetes Paket zuließ.

2. Okt. 2026
Der Link hatte keine MAC-Adresse. Der Host musste dennoch die Erreichbarkeit prüfen: RFC 3316

Geschichte

Der Link hatte keine MAC-Adresse. Der Host musste dennoch die Erreichbarkeit prüfen: RFC 3316

Auf einer GPRS- oder UMTS-Verbindung musste ein IPv6-Host die Link-Layer-Adresse des Routers nicht erst ermitteln. Eine solche Adresse gab es dort nicht. Trotzdem musste der Host wissen, ob der Standardrouter erreichbar blieb; manchmal konnte die Antwort eines anderen Protokolls…

2. Okt. 2026
Auch die Netzkarte braucht ein Verkehrsbudget

IETF

Auch die Netzkarte braucht ein Verkehrsbudget

Eine aktuelle Infrastrukturkarte hilft im Betrieb. Ihre Abfragen und Aktualisierungen nutzen jedoch genau das Netz, das sie beschreiben soll. Die jüngste SIMAP-Fassung macht daraus eine ausdrückliche Bedingung: Der Kartendienst darf keine anhaltende Überlastung verursachen.

2. Okt. 2026
Der Client reparierte nur den ersten Digest und geriet in eine Schleife

IETF

Der Client reparierte nur den ersten Digest und geriet in eine Schleife

Mehrere Digest- und Präferenzfelder können mehrere Diagnoseeinträge erzeugen. Deren Reihenfolge ist keine Prioritätenliste, und der erste behobene Fehler ist keine Zusage, dass der nächste Versuch zugelassen wird.

2. Okt. 2026
Der leere Finalize-Body ist kein leerer Vorgang

IETF

Der leere Finalize-Body ist kein leerer Vorgang

Im vorgeschlagenen ACME-Ablauf ohne CSR enthält die letzte Anforderung nur noch `{}`. Das wirkt wie eine Vereinfachung am Ende. Tatsächlich wurden die entscheidenden Angaben nach vorn verlegt: Zertifikatsschlüssel, exakte Auftragsbytes, Besitznachweis, Identifier-Autorisierung…

2. Okt. 2026
Die schnelle Antwort konnte eine ungenutzte Adresse hinterlassen: RFC 3315

Geschichte

Die schnelle Antwort konnte eine ungenutzte Adresse hinterlassen: RFC 3315

Der kurze DHCPv6-Pfad sparte nicht nur zwei Nachrichten: Der Server musste die Adresse festlegen, bevor er wissen konnte, ob seine Antwort den Client erreicht hatte.

2. Okt. 2026
AES kam mit zwölf Kombinationen in TLS, nicht als Einzelwahl: RFC 3268

Geschichte

AES kam mit zwölf Kombinationen in TLS, nicht als Einzelwahl: RFC 3268

2002 ergänzte TLS AES, ohne den Handshake neu zu entwerfen. Der Algorithmus kam als zwölf Cipher Suites ins Protokoll: Verschlüsselung allein konnte weder Schlüsselaustausch noch Authentisierung festlegen.

2. Okt. 2026
Der Empfänger kannte noch ein gutes Referenzbild. Der Sender hatte es bereits verworfen.

IETF

Der Empfänger kannte noch ein gutes Referenzbild. Der Sender hatte es bereits verworfen.

Eine Resynchronisationsmeldung benennt Zustand beim Empfänger. Ob daraus ein neues Bild codiert werden kann, entscheidet zusätzlich der Referenzpuffer des Senders. Erst beide Enden zusammen begründen eine belastbare Wiederanlaufentscheidung.

2. Okt. 2026
Bei TCP-AO ist „KMAC“ noch keine vollständige Rezeptur

IETF

Bei TCP-AO ist „KMAC“ noch keine vollständige Rezeptur

Zwei Gegenstellen können dieselbe kryptografische Bezeichnung anzeigen und dennoch unterschiedliche Verkehrsschlüssel berechnen. Der neue TCPM-Entwurf legt fest, welche NIST-Variante hinter seiner vorgeschlagenen KMAC-Ableitung für TCP-AO steht. Daraus folgt eine konkrete…

2. Okt. 2026
Der Zufallsschlüssel rettete nichts. Er brachte den Fehler zum Schweigen: RFC 3218

Geschichte

Der Zufallsschlüssel rettete nichts. Er brachte den Fehler zum Schweigen: RFC 3218

Ein CMS-Empfänger konnte eine verschlüsselte Nachricht ablehnen, noch bevor er deren Inhalt berührte. Eine genaue Fehlerursache wirkte wie saubere Ingenieursarbeit, bis ein Angreifer dieselbe Frage tausendfach stellen konnte. RFC 3218 verlangte deshalb etwas Widersprüchliches…

2. Okt. 2026
Die URL war keine eigene Schublade mehr: RFC 3305

Geschichte

Die URL war keine eigene Schublade mehr: RFC 3305

In der frühen Web-Zeit schien die Trennung einfach: Eine URL sagte, wohin man gelangen konnte; eine URN benannte etwas unabhängig von seinem Ort. 2002 hielt eine gemeinsame Planungsgruppe von W3C und IETF in RFC 3305 dagegen: Diese saubere Zweiteilung erschwerte zunehmend das…

2. Okt. 2026
Die Gruppe blieb gleich. Der Fünf-Tupel war schon weitergezogen.

IETF

Die Gruppe blieb gleich. Der Fünf-Tupel war schon weitergezogen.

Der Controller übersetzte eine stabile Gruppenkennung in eine konventionelle ACL. Bevor alle Durchsetzungspunkte die Regel erhielten, wechselte die Anwendung den Host und damit ihre Paketkoordinaten. Die Absicht blieb richtig, ihre Projektion wurde alt.

2. Okt. 2026
Die Bestätigung sagte, der NAK sei gehört worden – nicht, dass die Reparatur ankam: RFC 3208

Geschichte

Die Bestätigung sagte, der NAK sei gehört worden – nicht, dass die Reparatur ankam: RFC 3208

PGM verzichtete auf positive Quittungen jedes einzelnen Multicast-Empfängers. Ein Empfänger meldete eine Lücke per NAK, Netzelemente bestätigten und verdichteten die Anfragen, und Reparaturzustand begrenzte RDATA auf betroffene Zweige. Diese Skalierung machte aus dem NCF weder…

2. Okt. 2026
Eine Milliarde Nutzer hätte die Mehrheit noch ausgeschlossen: RFC 3271

Geschichte

Eine Milliarde Nutzer hätte die Mehrheit noch ausgeschlossen: RFC 3271

2002 prognostizierte Vint Cerf bis Ende 2005 mehr als eine Milliarde Internetnutzer – und stellte unmittelbar klar, dass dies nur etwa 16 Prozent der Weltbevölkerung entspräche. Dieser Abstand macht aus „Das Internet ist für alle da“ mehr als einen Wachstumsslogan: eine Prüfung…

2. Okt. 2026
RadSec verwirft die Antwort und lässt die Verbindung bestehen

IETF

RadSec verwirft die Antwort und lässt die Verbindung bestehen

Ein verspätetes RADIUS-Paket kann auf eine Kennung treffen, die bereits einem neuen Auftrag gehört. Der überarbeitete RadSec-Entwurf verlangt dann eine saubere Trennung: falsche Antwort verwerfen, geschützte Verbindung nicht allein deshalb kappen.

2. Okt. 2026
Der Cone enthielt AS-Nummern. Das nächste System las Präfixe.

IETF

Der Cone enthielt AS-Nummern. Das nächste System las Präfixe.

Die Übergabe war syntaktisch einwandfrei und semantisch unbrauchbar. Ein Team hatte mit `cone` eine Menge nachgelagerter autonomer Systeme bezeichnet; der nachfolgende Dienst behandelte denselben Wert wie eine Menge von IP-Präfixen. Ein vertrautes Wort hatte den Datentyp…

2. Okt. 2026

Sitzungsplan

Governance-Bereich

RIR-Watchdog

Fünf regionale Sitzungen befassen sich mit Zuteilungspolitik, der Legitimität des Vorstands und der institutionellen Kontinuität.

RIR-Watchdog öffnen

Fallakte

Langfristige Governance-Dossiers mit rechtlicher, wahlbezogener und institutioneller Belastungsanalyse.

Fallakte öffnen

Gesellschaft für Nummernressourcen

Mitgliedschaft, Satzung und Analysen zur Ressourcen-Governance aus dem NRS-Ökosystem.

NRS-Sitzung öffnen

ICANN

DNS-Koordination, Rechenschaftsrahmen und Dynamiken globaler Multi-Stakeholder-Prozesse.

ICANN-Sitzung öffnen

IETF

Entwicklung der Protokollstandardisierung und Interoperabilitätsrisiko unter fragmentierten politischen Bedingungen.

IETF-Sitzung öffnen

Geschichte des Internets

Langzyklische Infrastrukturgeschichte zur Interpretation von Governance und für Strukturprognosen.

Historische Sitzung öffnen

NOGs

Erkenntnisse zur Implementierung auf Betreiberebene von APRICOT sowie aus regionalen und nationalen NOG-Ökosystemen.

NOGS-Sitzung öffnen