Nachdem nun das OtherConfig=yes - Flag bei der FeM eingeschaltet ist, gibt es hier nun die ersten Erfahrungen.
ISC DHCP Server
Schon im statefull-Betrieb wurde ein Upgrade von 4.2.2.dfsg.1-5+deb70u6 (Debian Stable) auf 4.2.5 (Upstream vanilla Build) notwendig, da die mit Debian mitgelieferte Version sich regelmäßig mit einem SEGFAULT verabschiedete. Die neue Version läuft jedoch völlig stabil.
Die Syslog-Ausgabe des DHCP Servers ist jedoch enorm, da für jedes empfangene und gesendete DHCPv6 Paket sowie jeden Fehler eine eigene Nachricht ins Syslog geschrieben wird. Durch die Verwendung einer separaten Partition für die Logs läuft der DHCPv6 Server jedoch einfach weiter.
Client-Besonderheiten
Einige Systeme (sowohl Windows 7 als auch Linux 2.6 / 3.0) fordern neben einer Stateless-Konfiguration auch eine "Non-Temporary Address" an. Die würde der FeM-DHCPv6-Server ja sogar mitliefern, jedoch nur wenn als Client-Identifier der DUID-LLT oder DUID-LL Typ verwendet wird - also die Client-MAC-Adresse im Client-Identifier eingebettet ist - und die MAC bei der FeM angemeldet ist. Eine handvoll Computer (aktuell sind ca. 5 betroffene Systeme online) scheint mit der Antwort vom DHCPv6 Server, dass keine solche Adresse verfügbar ist, nicht zu frieden zu sein, und fragt sofort wieder nach. In der Folge entstehen je betroffenem System zwischen 40 (i.d.R. Linux Systeme) und 730 (ein Windows 7) Syslog-Nachrichten pro Minute auf dem DHCPv6 Server. Zukünftig wird man hier wohl eine ip6tables Ratenlimitierung auf dem DHCPv6 Server vorsehen müssen.
Fast alle aktuell beobachteten Clienten verwenden DUID-LLT (also MAC+Zeitstempel als Client-ID), einige wenige DUID-LL (MAC als Client-ID). Nicht alle Systeme halten sich jedoch an die Bildungsvorschriften aus dem RFC 3315 Abschnitt 9 dafür. Das fängt an bei der Länge (Ethernet MAC-Adressen haben immer 6 nie 8 Bytes Länge) und geht weiter beim Zeitstempel - der bei einigen System sehr weit (100 Jahre) in der Zukunft liegt - auch die Interpretation als Sekunden seit 1970 statt 2000 wie im RFC definiert würde daran nichts ändern.
Auch passen die Bytes der Client-ID, die sich aus der MAC-Adresse ergeben sollen, nicht immer zu der MAC-Adresse, die der Client tatsächlich verwendet. Dies führt dazu, dass eine statische Konfiguration pro-Client anhand der MAC Adresse nicht möglich ist. Für Systeme mit mehreren oder getauschten Netzwerkkarten ist jedoch RFC-konform, die gleiche Client-ID für alle Netzwerkkarten (auch über di Zeit hinweg) zu verwenden - sodass die Client-ID regelmäßig nicht zur Quell-MAC passen wird.
Trackbacks