Zusammenfassung

  • RFC 5417 definiert getrennte DHCPv4- und DHCPv6-Optionen mit geordneten Listen von CAPWAP-Access-Controllern; die konfigurierte DHCP-Serverrichtlinie liefert die Reihenfolge.
  • Ein WTP darf die Liste zur Suche verwenden und sollte die Adressen in der angegebenen Reihenfolge versuchen. Das belegt weder Erreichbarkeit noch Identität; beim Sitzungsaufbau authentifiziert DTLS die Kommunikationspartner.

Zwei DHCP-Optionen, zwei getrennte Adressfamilien: RFC 5417 ordnet IPv4- und IPv6-Controllerlisten jeweils für sich. Gerade diese Trennung wird bei einem Dual-Stack-Zugangspunkt leicht übersehen. Die Optionen geben seinem Wireless Termination Point (WTP) Kandidaten für die CAPWAP-Suche, aber keine gemeinsame Rangliste über beide Familien hinweg.

Die beiden Optionen bleiben nach Adressfamilie getrennt. DHCPv4-Option 138 trägt 32-Bit-IPv4-Adressen; die Länge der Adressdaten muss deshalb ein Vielfaches von vier Oktetten sein. DHCPv6-Option 52 trägt 128-Bit-IPv6-Adressen und verlangt ein Vielfaches von sechzehn Oktetten. Der DHCP-Client, der für ein WTP handelt, muss die jeweilige Option in seiner Parameter Request List anfordern. Der Server gibt sie zurück, wenn seine Richtlinie passend konfiguriert ist und eine AC-Adressliste vorliegt.

Die Präferenz stammt damit aus der Serverkonfiguration; sie ist keine automatische Verfügbarkeitsmessung. RFC 5417 ordnet die AC-Adressen nach ihrer Präferenz für den WTP. Das Gerät darf die Liste zur Suche verwenden und sollte die Einträge in der empfangenen Reihenfolge versuchen. Diese Vorgabe beeinflusst den Suchpfad, ist aber keine Servicezusage: Sie macht eine Adresse nicht erreichbar, misst keine Auslastung und garantiert nicht, dass der erste Controller das WTP annimmt.

Auch die beiden Adressfamilien lassen sich nicht zu einer Rangfolge zusammenziehen, die RFC 5417 gar nicht beschreibt. Die Spezifikation legt jeweils eine Reihenfolge innerhalb der IPv4- und IPv6-Option fest, aber keine gemeinsame Priorität über beide Listen hinweg. Sollen die ersten Adressen dieselbe Präferenz ausdrücken, muss die lokale Konfiguration diesen Zusammenhang sichtbar herstellen.

Ein Eintrag in der Liste macht den Controller noch nicht vertrauenswürdig. DHCP liefert einen ersten Hinweis auf das Ziel; CAPWAP-Discovery und Sitzungsaufbau erledigen andere Schritte. RFC 5415 beschreibt die Discovery-Nachrichten und den anschließenden Sitzungsablauf. RFC 5417 warnt, dass ein Angreifer, der eine DHCP-Antwort ändert oder eine eigene Antwort einschleust, ein WTP zu einem betrügerischen AC lenken könnte, der Anrufanforderungen abfängt oder einen Dienst verweigert. CAPWAP muss beim Aufbau der Sitzung DTLS zur Authentifizierung der Kommunikationspartner verwenden.

Diese Authentifizierungsgrenze macht den Bootstrap-Pfad nicht nebensächlich. RFC 5417 hält fest, dass DHCP-Optionen in den meisten Netzen vor der Netzzugangs-Authentifizierung eintreffen und weder Integritäts- noch Herkunftsschutz besitzen. In sicherheitssensiblen Umgebungen sollten sie daher nicht die einzige Methode zur Auswahl des AC sein. RFC 5415 definiert weitere Discovery-Verfahren, die ein WTP verwenden kann. Die Rollen sind gestaffelt: DHCP schlägt Kandidaten vor und ordnet sie; ein späterer authentifizierter Austausch entscheidet, ob der Partner akzeptabel ist.

IANA führt DHCPv4-Option 138 weiterhin als OPTION_CAPWAP_AC_V4 und DHCPv6-Option 52 als OPTION_CAPWAP_AC_V6, jeweils mit Verweis auf RFC 5417. Das bestätigt die Registrierung der Parameter, nicht ihre Verbreitung in heutigen Produkten oder das genaue Verhalten eines WTP nach einem fehlgeschlagenen Versuch.

Für den Betrieb zählt daher die gesamte Kette: Fordert das WTP die Option an? Welche Liste liefert der DHCP-Server für den jeweiligen Scope und die Adressfamilie? Sind alle Adressen geroutet und lauscht dort ein Dienst? Was meldet die CAPWAP-Discovery? Authentifiziert DTLS den vorgesehenen Partner? Ein Mitschnitt mit Option 138 oder 52 zeigt, was DHCP übertragen hat. Er beweist weder die Verbindung zum erwarteten AC noch eine nutzbare Steuersitzung.

Der Beitrag von RFC 5417 ist eng umrissen und dennoch relevant. Eine DHCP-Richtlinie kann beeinflussen, in welcher Reihenfolge ein Funkgerät seine Managementebene sucht, ohne aus einer konfigurierten Präferenz eine laufende Wahl oder ein Sicherheitsurteil zu machen. Bei einer Controller-Migration hilft die Trennung: Die Liste hält die Absicht fest, Discovery prüft Kandidaten, und DTLS authentifiziert den Partner, der fortfährt.

Quellen