Zusammenfassung

  • RFC 7844 beschreibt ein Anonymitätsprofil, keine anonyme Adresse. DUID, IAID, alte Adresshinweise, Server Identifier, FQDN und Klassenoptionen müssen denselben Linkwechsel respektieren.
  • Auswahl und Reihenfolge angeforderter Optionen können eine Implementierung auch ohne Namen wiedererkennbar machen. Minimierung und wechselnde Reihenfolge verhindern, dass der Datenschutzmodus selbst zur seltenen Signatur wird.
  • Koordiniertes Vergessen kostet Kontinuität: Server behalten womöglich alte Leases, Pools und Binding-Tabellen werden stärker genutzt, und Netze mit vorregistrierten Geräten können den Zugang verweigern. Das Profil reduziert DHCP-Korrelation, nicht jede Beobachtung.

Eine frische Adresse mit altem Gedächtnis

Adresswechsel sind leicht zu demonstrieren. Zwei Mitschnitte zeigen zwei Werte, und der Bruch scheint vollständig. RFC 7824 untersuchte deshalb die übrigen Felder, die den sichtbaren Wechsel überleben können.

Im DHCPv6 steht der DUID gegenüber dem Server für den Client; der IAID trennt Identity Associations desselben Clients. Ein Client FQDN kann den Host benennen. User Class, Vendor Class und herstellerspezifische Informationen beschreiben Rolle oder Implementierung. Die Option Request Option zeigt, welche Konfiguration gewünscht wird. Eine frühere Adresse als Hint oder ein gespeicherter Server Identifier trägt alten Kontext ins neue Netz.

Kein einzelnes Merkmal muss weltweit eindeutig sein. Korrelation genügt eine seltene Kombination. Ein dauerhafter DUID zusammen mit einer charakteristischen Optionsliste kann zwei Besuche verbinden. Manche DUID-Formen enthalten sogar eine Link-Layer-Adresse und widersprechen damit der neu randomisierten Funkadresse unmittelbar.

Huitema, Tomek Mrugalski und Suresh Krishnan veröffentlichten RFC 7844 im Jahr 2016 als gemeinsames Client-Profil. Das Ziel ist begrenzt: DHCP soll weniger verraten, wenn der Nutzer diesen Modus wählt. Gemeinsames Verhalten verhindert zugleich, dass neun verschiedene Datenschutzlösungen neun neue Fingerabdrücke erzeugen.

Stabilität braucht einen Geltungsbereich

Im normalen Betrieb hilft ein stabiler DUID. Der Server erkennt Rückkehr, verlängert Leases und hält Zustand zusammen. Im Anonymitätsprofil kehrt sich der Wert derselben Eigenschaft um. Bleibt der DUID nach einer neuen Link-Identität erhalten, wird er zur Brücke zwischen beiden Auftritten.

RFC 7844 bindet deshalb die DHCP-Kennungen an den Linkübergang. Wird die Link-Layer-Adresse randomisiert, darf die zugehörige DHCP-Identität nicht unbemerkt länger leben. Für einschlägige Fälle ohne diese Randomisierung beschreibt der Text ebenfalls einen randomisierten DUID-LLT.

RFC 9915, seit 2026 die aktuelle DHCPv6-Basisspezifikation, hält an DUID-Stabilität als Regelfall fest und erkennt die Ausnahme nach RFC 7844 ausdrücklich an. Das ist kein Widerspruch. Kontinuität und bewusste Trennung sind verschiedene Betriebsverträge.

Auch ein IAID darf keine dauerhafte Maschinensignatur werden. Seine sinnvolle Stabilität gehört zur aktuellen Link-Layer-Assoziation. „Ist die Kennung stabil?“ ist daher keine vollständige Prüfungsfrage. Stabil über welchen Wechsel, sichtbar für wen und zum Nutzen welches Dienstes?

Alte Adressen zeigen den Tausch besonders klar. Die Bitte um dieselbe Adresse kann Unterbrechung vermeiden, verrät aber die frühere Verbindung. Das Profil löscht gespeicherte Adressen beim Wechsel der Link-Identität. Bequeme Wiederkehr und sauberer Bruch lassen sich nicht beide kostenlos maximieren.

Auch eine Wunschliste kann erkennen

RFC 7824 trennt direkte Identifikation von Fingerprinting. DHCP-Clients verlangen unterschiedliche Optionssätze und ordnen sie oft gleich. Set und Reihenfolge können Betriebssystem oder Implementierungsfamilie zeigen, obwohl kein Feld wie ein Name aussieht.

RFC 7844 antwortet mit Zurückhaltung: nur das notwendige Minimum anfordern, die Reihenfolge variieren, alte Cache-Werte nicht aus Gewohnheit mitsenden und Client FQDN, User Class, Vendor Class sowie Herstellerdaten vermeiden. Ein ausschließlich lokaler FQDN kann lokal nützen, soll aber kein reisender Name werden.

Die Autoren lehnen außerdem ein besonderes Anonymitäts-Flag ab. Wer seinen Wunsch nach Privatsphäre öffentlich erklärt, bildet eine kleine, leicht zu blockierende oder zu beobachtende Gruppe. Eine selten eingesetzte Temporary-Address-Option kann denselben Effekt haben. Eine schützende Bezeichnung macht ein Signal nicht automatisch unauffällig.

Das gemeinsame Minimum sagt deshalb weniger statt mehr. Es reduziert die Menge und Regelmäßigkeit der Offenlegung und lässt die Entscheidung zur Nutzung beim Client beziehungsweise Nutzer.

Außerhalb von DHCP bleibt Beobachtung möglich

RFC 7844 erklärt Funk-Fingerprinting ausdrücklich für außerhalb seines Geltungsbereichs. Hardwaremerkmale, Verkehrstakt, Anwendungskonten und andere Protokolle bleiben eigene Flächen. Die Grenze macht die tatsächliche DHCP-Wirkung überprüfbar, statt sie zu einer unscharfen Unsichtbarkeitsgarantie zu erheben.

Auch der Server trägt Kosten. Erkennt er die Rückkehr nicht, hält er den alten Lease bis zum Ablauf und erzeugt neuen Zustand. Häufige Wechsel können Pool und Binding-Tabelle belasten. Ein Netz, das nur registrierte Link-Layer-Adressen zulässt, kann die Verbindung abweisen. Stateful Services verlieren möglicherweise ihren Bezug.

Das ist nicht automatisch ein Fehler des Profils. Server wollen Zustand sparen, Zulassungssysteme wollen eine feste Handhabe, Nutzer wollen Besuche getrennt halten. Die Spezifikation lässt die Wahl beim Nutzer und beschreibt die Folgen offen.

Huitemas Beitrag war eine begrenzte Zusage

Das IETF-Profil dokumentiert Christian Huitemas lange Standardarbeit und nennt Privatsphäre sowie QUIC unter seinen späteren Themen. Seine eigene Biografie verbindet Transport, Namenssysteme und Sicherheit. RFC 7844 bleibt Gemeinschaftsarbeit: Mrugalski und Krishnan sind Mitautoren, und RFC 7824 baut auf der breiteren DHCP-Erfahrung auf.

Historisch trägt vor allem die Methode. Alle Beobachtungsflächen inventarisieren, einen gemeinsamen Wechselpunkt definieren und anschließend in der laufenden Implementierung nachweisen, was tatsächlich gesendet wurde. Die Veröffentlichung eines RFC ist kein Nachweis seiner Adoption.

Eine Kennung ist weder die Person noch Eigentum an ihr. Sie ist ein Beleg aus einer bestimmten Policy. Das Profil um Huitema verlangt, diesen Beleg im richtigen Umfang zu lesen und ihn nicht über eine Grenze mitzunehmen, an der er dem Nutzerzweck nicht mehr dient.

Quellen