Hier gibt noch etwas Lesestoffzu IPv6.
PrivacyExtension: IPv6 wird nie "deprecated"
Ehemalige
Anmeldungsdatum: Beiträge: 4403 Wohnort: Sachsen |
|
(Themenstarter)
Anmeldungsdatum: Beiträge: 603 |
Ja, die Seite kenne ich natürlich..... es ist eine der Seiten, die ich in den letzten 2-3 Wochen mehrfach zu diesem Thema rauf und runter gelesen habe. Darüber hinaus auch die hier:
und noch einige weitere zufällig auf dem Weg liegende beim Suchen im Web. Es ist alles eigentlich richtig gut beschrieben, fast zu viel um sich alles zu merken .... und ich muss häufig nachlesen. Aber das was fehlt ist schlicht und einfach ein schlüssiges HowTo, mit dem man das auf seiner Maschine einrichten kann. Und bedauerlicherweise haben wir derzeit in Linux eine absolute Chaos-Situation:
dpkg -l | grep dhc ii dhcpcd5 6.0.5-2 amd64 DHCPv4, IPv6RA and DHCPv6 client with IPv4LL support ii isc-dhcp-client 4.3.1-6+deb8u2 amd64 DHCP client for automatically obtaining an IP address ii isc-dhcp-common 4.3.1-6+deb8u2 amd64 common files used by all of the isc-dhcp packages cat /etc/dhcpcd.conf | grep -i slaac root@thomaspc:~ # ps -fC dhcpcd UID PID PPID C STIME TTY TIME CMD root 733 1 0 17:07 ? 00:00:00 /sbin/dhcpcd Es gibt, so wie ich das Einschätze, keinen Konflikt zwischen dhcpcd und dhcp-client. Der dhcp-client wird nicht per Service-Unit gestart und es gibt auch keinen laufenden Prozess. In der Conf /etc/systemd/network/eth0.network habe ich "dhcp=no" eingestellt, damit sollte systemd-networkd weder mit eigenem Code noch mit dem dhcp-Client eine IP anfordern. Mittlerweile glaube ich aber trotzdem, dass das vielleicht die Ursache meiner Probleme ist. Und zwar einfach nur ne falsche Einstellung im jetzt installierten dhcpcd.... *hmmm* Momentan vermute ich, dass für die lokale generische IPv6 via slaac wahrscheinlich ein DHCP notwendig ist, der bis gestern ja gar nicht installiert war, sonder nur der "client". Daraus schließe ich, es gibt offensichtlich kein Tool (wie z.B. /sbin/ip), welches man explizit dafür starten kann, um via slaac eine IPv6 zu generieren. Und systemd-networkd selber kann es anscheinend auch nicht. Also bleibt eigentlich nur, dass der dhcpcd das vielleicht leistet, wenn er denn mal richtig eingestellt ist. *hmmm*
Oh nee... das tue ich mir nicht an *lacht*. Ich habe mir gestern in einer 10GB-Partition auf meinem PC mal eben "Testing" installiert. Das hat ja nen aktuelles Systemd ... und immer noch das Standard-Setup über /etc/networking. Und die Effekte sind trotzdem die gleichen. Es wird auch dort eine temporary IPv6 generiert, aber die ist trotzdem "forever", weil auch dort der Timer-Reset erfolgt. Und es besteht der gleiche Umstand, dass ich dhcpcd wohl nicht konfiguriert habe. Also kann es soch eigentlich nur noch am dhcpcd liegen... *hmmm*... Mir ist echt unbegreiflich, dass man im Web nicht mehr dazu findet, wenn doch so große ISP wie UnityMedia und Kabel-Deutschland alle auf DS-Lite umgestellt haben. Das Problem müssten doch viele haben. Oder haben die alle mehr Glück beim Suchen und Finden im WWW? *lol* Hast Du vielliecht ne Idee, wie ich die Default-dhcpcd.conf verändern muss, damit das klappt? |
Anmeldungsdatum: Beiträge: 13893 |
Z. B.: :~ $ cat /etc/dhcpcd.conf | grep -i slaac #slaac hwaddr slaac private
Wenn Du dhcpcd hast, sollte der dhcp-client deinstalliert werden. Es gibt hier im UU-Forum schon einen Thread, betr. dhcpcd und dhcp-client. |
(Themenstarter)
Anmeldungsdatum: Beiträge: 603 |
Damit gibts ein Problem.... erstmal wieder unerklärlich: journalctl -b | grep -i "ipv6\|dhcp" Nov 14 19:40:07 thomaspc dhcpcd[573]: dhcpcd: unknown option -- slaac
dpkg -l | grep dhcpcd5 ii dhcpcd5 6.0.5-2 amd64 DHCPv4, IPv6RA and DHCPv6 client with IPv4LL support Das ist doch der Client...?... gibt es da noch einen anderen? apt-cache search dhcp | grep client dibbler-client - portabler Client für das DHCPv6-Protokoll isc-dhcp-client - DHCP-Client für automatisches Beziehen einer IP-Adresse udhcpc - Provides the busybox DHCP client implementation dhcpcd5 - DHCPv4, IPv6RA and DHCPv6 client with IPv4LL support dyndns - dynamic DNS (DDNS) update client implemented in Perl isc-dhcp-client-dbg - ISC DHCP server for automatic IP address assignment (client debug) isc-dhcp-dev - API for accessing and modifying the DHCP server and client state python-pydhcplib - Python DHCP client/server library wide-dhcpv6-client - DHCPv6 client for automatic IPv6 hosts configuration Und nu... ?.... gibts noch Möglichkeiten? |
Anmeldungsdatum: Beiträge: 13893 |
Dann schau mal in den manpages für dhcpcd und dhcpcd.conf nach. Wenn dort nichts zu finden ist, dann haben sie den dhcpcd deiner Distri, bzgl. slaac auch kastriert. |
(Themenstarter)
Anmeldungsdatum: Beiträge: 603 |
Das musste ich auch erst mal verdauen... dass dhcpcd noch lange nicht dhcpcd ist 😐 Ich habe mir jetzt aus dem Repo eine deutlich aktuellere Version als Sourcecode.tar.gz runtergeladen und dann selber kompiliert. Das schwierigste war erst mal wieder für die Service-Unit die passenden Parameter zu finden.... und wieder mal findet man da nix brauchbares im Web, und mit sysvinit-scripten fang ich nicht wieder an... also alles einzeln zusammensuchen. Und wie ist das Resultat? Keine Fehlermeldungen, kein Gemecker über falsche Parameter. Aber nachwievor im Journal kein Eintrag über die generierte temporary-Adresse. "journalctl -b | grep -i dhcp | grep adding" sagt mir nur, dass er die 'mngtmpaddr'-Adresse angelegt hat. Und weiterhin die quasi-forever-Gültigkeit beider Global-Scope-IPs, weil die Lifetime bei 900 sec zurück auf 1800 resetted wird. Ich habe ne temporary Adresse.... aber mit unbegrenzter Gültigkeit.... das kann doch alles nicht wahr sein... |
Anmeldungsdatum: Beiträge: 13893 |
Versuch mal in der dhcpcd.conf, zusätzlich auch mit den Einstellungen: noipv6rs ipv6ra_noautoconf ipv6ra_own Hast Du systemd-networkd jetzt deaktiviert? EDIT: dhcpcd is also an implementation of the IPv6 Privacy Extensions to AutoConf as specified in RFC 4941. This feature needs to be enabled in the kernel and dhcpcd will start using it. You need CONFIG_IPV6_PRIVACY to be set when building the kernel. EDIT 2: Die Ausgaben von: zcat /proc/config.gz | grep -i PRIVACY cat /boot/config-$(uname -r) | grep -i PRIVACY Z. B.: :~$ grep -i privacy /boot/config-3.2.0-115-generic CONFIG_IPV6_PRIVACY=y
:~$ grep -i privacy /boot/config-3.13.0-101-generic |
(Themenstarter)
Anmeldungsdatum: Beiträge: 603 |
"This feature needs to be enabled in the kernel and dhcpcd will start using it." Damit sind doch die Kernelvars in sysctl.conf gemeint....oder? Und die sind natürlich alle gesetzt. Mit "grep" in /boot reinsehen war nix ... *fg*... ich habe stattdessen mit nem Viewer reingeguckt und gesucht... und diese Einträge gibts nicht. Aber mir ist dabei jetzt etwas bewusst geworden.... begleitend von einem speziellen Log-Eintrag ins Journal, den ich jetzt mal über mehrere Boots geschrieben und kontrolliert habe:
Das bedeutet doch, dass es grundsätzlich funktioniert. Lediglich das mit der Lifetime der IPv6 zur Rechnerlaufzeit funktioniert überhaupt nicht. Im Grundegenommen könnte man das aber auch einfach ignorieren, dass die Lifetime-Settings nicht berücksichtigt werden. Und ich schätze mal, dass es jetzt wohl darauf hinausläuft - u.a. auch vor dem Hintergrund, dass die IPv4 führer auch nur einmal täglich zwangsgetrennt wurde. Aber dennoch empfinde ich das als unzufriedenstellend, dass man nicht das erreichen kann, was eigentlich alle Man-Pages beschreiben. Allerdings weiss ich auch nicht, ob nicht zwischenzeitlich grundsätzlich die Ziele neu definiert wurden... vielleicht haben die lifetime-Kernel-Vars überhaupt keine Wirkung mehr und ich reite nur auf alten Dokus rum.... 🙄 .... ich glaube jetzt wirklich, dass lässt sich nicht lösen. Wenn Du dem auch zustimmst,setze ich das (unbefriedigt) auf gelöst. |
Anmeldungsdatum: Beiträge: 13893 |
Nein, das hier: You need CONFIG_IPV6_PRIVACY to be set when building the kernel. ist gemeint. D. h, der Kernel muss mit: CONFIG_IPV6_PRIVACY=y kompiliert sein.
Wenn Du es genau wissen willst, solltest Du mal mit einem Kernel, der mit "CONFIG_IPV6_PRIVACY=y" kompiliert ist, versuchen. EDIT: Z. B. der Kernel 3.2 von 12.04 ist mit "CONFIG_IPV6_PRIVACY=y" kompiliert, der Kernel 3.13 von 14.04 ist nicht mit "CONFIG_IPV6_PRIVACY=y" kompiliert. EDIT 2: Auf deinem raspbian kannst Du das z. B. mit: sudo modprobe configs
# Echo the kernel .config file used to build the kernel
zcat /proc/config.gz | grep -i ipv6
sudo modprobe -rv configs ls -la /proc/config.gz und dann wirst Du feststellen, dass der Kernel nicht mit "CONFIG_IPV6_PRIVACY=y" kompiliert ist. Im Internet findest Du z. B. für raspbian auch den Hinweis: After upgrade to 3.12.20+ - ipv6 privacy extensions stopped working |
(Themenstarter)
Anmeldungsdatum: Beiträge: 603 |
Schau Dir mal diese Seite an, auf der genau das bestätigt wird, was Du sagst: http://lxr.free-electrons.com/source/net/ipv6/addrconf.c?v=3.12 Der Kernel 3.12 ist der letzte in der Ahnenreihe, der diese Einstellung noch berücksichtigt. Vor dem Hintergrund, dass auch jetzt noch bei mir eine korrekte PE-IPv6 generiert wird, kann ich mir nun nur erklären, dass es bei der Implementierung der PE eine grunsätzliche Änderung gegeben haben muss. BTW, diese Vermutung hatte ich gestern schon erwähnt, und zwar eine vielleicht mögliche "Neuausrichtung der Ziele". Ich hatte nämlich gestern die Idee, dass die Lifetime-Vars bei einer 24/7-Laufzeit einer Maschine durchaus auch Probleme verursachen könnten. Zum Beispiel dann, wenn jemand auf die Idee käme, eine kurze "preferred" und eine lange "valid" LT zu setzen. Dann hat er bei nem halben Jahr Laufzeit möglicherweise hunderte von toten oder "noch-valid" IPs , oder es wird schlichtweg nur noch die mit hwaddr genutzt. Vor der Frage, ob PE auf einem dedizierten Server nicht eher unnütz sind ... (?) die ich mit "Ja" einschätze ... komme ich zum dem Schluss, auf einem reinen Enduser-PC reicht imho der tägliche automatische Reset einer IPv6 durch die PE und beim Boot des Rechners völlig aus. Das entspricht dann prinzipiell der Funktionalität der bisherigen IPv4 mit der 24h-Zwangstrennung. Je mehr ich darüber nachdenke, scheint es mir tatsächlich auch sinnvoll zu sein, so wie es jetzt ist. Das ärgerliche ist, man reitet auf alten Man-Pages und Web-Sites rum und findet keine einfache Erklärung, warum es nicht wie gewollt funktioniert. Naja... |
Anmeldungsdatum: Beiträge: 13893 |
Nein, diese Probleme sehe ich nicht, denn man kann im source code auch einen min- und max Wert für "preferred" und "valid" programmieren bzw. vorsehen.
OK, ... aber wer die funktionierenden PEs haben will, kann ja auch den Kernel, mit der Einstellung "CONFIG_IPV6_PRIVACY=y" kompilieren. EDIT: Interessant wäre es m. E. auch zu wissen, wie es "per default" mit den PEs (oder gleichwertig) für IPv6, bei den anderen OS's (Windows, FreeBSD, Android, iOS, etc.) aussieht. |
(Themenstarter)
Anmeldungsdatum: Beiträge: 603 |
Ja, das ist wohl richtig, aber dennoch ist es nicht ganz so einfach, denn einfach nur max und min reichen imho nicht aus. Eigentlich wäre die Regel richtig "Das Wievielfache von 'valid' im Verhältnis zu 'preferred' darf min und max nicht unter- bzw. überschreiten". Das heisst, ein min und max für valid/preferred an sich ist imho unnötig.
Dieser Satz müsste aber eigentich lauten "...wer die Lifetime-Vars für die PEs haben will.....", denn ohne jeden Zweifel funktioniert ja die Generierung einer stateless-IPv6 ohne reproduzierbaren Bezug zur Hardware. Aber jetzt mal im Ernst, ich bin ziemlich sicher, dass die Mehrzahl der Internet-Nutzer die PEs haben wollten, wenn sie um die Konsequenzen wüssten. Und wenn ich nur mal gerade an die typischen Mint-Nutzer denke, die ja m.M.n. bevorzugt Windows-Migranten sind, wer soll von denen einen eigenen Kernel kompilieren können? Ich denke, ich könnte es, wenn ich mich damit befasse. Allein will ich das? Nee, eigentlich nicht! Ich will mit dem Standard-Kernel arbeiten und passe mich mit entsprechendenen Reaktionen an. Und ggf. muss man auch mal eigene Paradigmen hinterfragen.
Das weiss ich auch nicht. Aber was Windows macht.... das hat für mich keine Bedeutung mehr. Auf jeden Fall empfand ich unser Gespräch als konstruktiv, unglaublich lehrreich und äußerst anregend. Vielen Dank dafür! 👍 vg, Thomas |
(Themenstarter)
Anmeldungsdatum: Beiträge: 603 |
Nachtrag: Ich habe noch ne interessante Info für Dich. Vor der Wiederherstellung meines Systems auf den vorherigen Zustand habe ich die dhcp-Clients deinstalliert, und zwar aus Neugier alle beide. Die "/etc/systemd/network/eth0.network" enthält jetzt noch den Eintrag "dhcp=no". Nach dem Reboot hatte ich wie zuvor alle IPv6 und Verbindung ins WWW, aber keine IPv4 und kein LAN. Aber, und das ist das interessante, ich hatte genau wie zuvor mit DHCP jetzt wieder 2 IPv6 mit global scope, eine mit hwaddr und eine temporary ohne einen HW-Bezug ... und das eben auch ohne jegliche DHCP-Client-Unterstützung ... aber leider jetzt auch ohne Journaleinträge. Dann habe ich in der "/etc/systemd/network/eth0.network" wieder (nur) DHCP=v4 eingestellt und rebootet. Und siehe da, systemd-networkd besorgt sich selber eine IPv4, das LAN ist da, ebenso die ganze IPv6-Funktion. Das RA-Paket vom Router sendet nur DNS, auf meinem PC war kein DHCP-Client installiert, es werkelt systemd-networkd.... und es funktioniert per default trotzdem alles, einschließlich einer stateless IPv6. Lediglich bei den Lifetime-Vars besteht das alte Problem. Tja.... keine Ahnung, was da alles in den Tiefen des Kernels und systemd passiert. Aber es scheint jedenfalls anders zu sein, als früher. |