65
IPv6 Privacy Extensions klappt nicht
Hallo,
ich experimentiere aktuell mit IPv6. Teste dabei verschiedene Konfigurationen.
Mir ist jetzt aufgefallen, das die "IPv6 Privacy Extensions" nicht zuverlässig funktioniert, ich würde sogar sagen fehlerhaft ist.
Das Problem tritt an Endkundenanschlüssen auf, wo die Lifetime des IPv6 prefix recht klein ist. ( z.b. 3600s ).
Der Router schickt regelmäßig die Router Advertisement aus, damit aktualisiert linux die valid_lft - was ok ist. Aber jetzt wird auch die preferred_lft zurückgesetzt. Damit erreicht sie nie den Wert 0 und damit wird die temp-Adresse nie erneuert. ( Windows macht es genauso ).
3: enp5s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
inet6 2a00:XXXX:XXXX:XXXX:9e67:7536:3e07:8f18/64 scope global temporary dynamic
valid_lft 3653sec preferred_lft 1792sec
kurze Zeit später
3: enp5s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
inet6 2a00:XXXX:XXXX:XXXX:9e67:7536:3e07:8f18/64 scope global temporary dynamic
valid_lft 3615sec preferred_lft 1799sec
Das ganze konnte ich in 2 verschieden Netzen nachstellen ( einmal mit Telekom Router, einmal mit eigenem Linux-Router ).
Ich hätte jetzt erwarten das man dem timer wie lange die Temp-Adresse überhaupt gültig ist niemals zurücksetzt.
Wo ist der Denkfehler?
ich experimentiere aktuell mit IPv6. Teste dabei verschiedene Konfigurationen.
Mir ist jetzt aufgefallen, das die "IPv6 Privacy Extensions" nicht zuverlässig funktioniert, ich würde sogar sagen fehlerhaft ist.
Das Problem tritt an Endkundenanschlüssen auf, wo die Lifetime des IPv6 prefix recht klein ist. ( z.b. 3600s ).
Der Router schickt regelmäßig die Router Advertisement aus, damit aktualisiert linux die valid_lft - was ok ist. Aber jetzt wird auch die preferred_lft zurückgesetzt. Damit erreicht sie nie den Wert 0 und damit wird die temp-Adresse nie erneuert. ( Windows macht es genauso ).
3: enp5s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
inet6 2a00:XXXX:XXXX:XXXX:9e67:7536:3e07:8f18/64 scope global temporary dynamic
valid_lft 3653sec preferred_lft 1792sec
kurze Zeit später
3: enp5s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
inet6 2a00:XXXX:XXXX:XXXX:9e67:7536:3e07:8f18/64 scope global temporary dynamic
valid_lft 3615sec preferred_lft 1799sec
Das ganze konnte ich in 2 verschieden Netzen nachstellen ( einmal mit Telekom Router, einmal mit eigenem Linux-Router ).
Ich hätte jetzt erwarten das man dem timer wie lange die Temp-Adresse überhaupt gültig ist niemals zurücksetzt.
Wo ist der Denkfehler?
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 2355504965
Url: https://administrator.de/contentid/2355504965
Printed on: April 26, 2024 at 14:04 o'clock
65 Comments
Latest comment
Mit dem aktuellen Debian "Bullseye" ist das nicht zu reproduzieren.
slaac private in der /etc/dhcpcd.conf angegeben und damit rennt das fehlerlos an einem Telekom Anschluss
Leider gibst du nicht an wie deine Netzwerk Konfig gemacht wird. Statisch, Network Manager etc. So kann man also nur frei rumraten. 
Siehe auch hier für andere Distros und Adressierungen:
https://wiki.archlinux.org/title/IPv6#Privacy_extensions
https://wiki.ubuntuusers.de/IPv6/Privacy_Extensions/
slaac private in der /etc/dhcpcd.conf angegeben und damit rennt das fehlerlos an einem Telekom Anschluss
# Generate SLAAC address using the Hardware Address of the interface
#slaac hwaddr
# OR generate Stable Private IPv6 Addresses based from the DUID
slaac private Siehe auch hier für andere Distros und Adressierungen:
https://wiki.archlinux.org/title/IPv6#Privacy_extensions
https://wiki.ubuntuusers.de/IPv6/Privacy_Extensions/
Das ist per Standard so — RFC4942, Abschnitt 3.3, Absatz 1 sagt, dass einmal generierte Adressen durch Empfangen neuer RAs verlängert werden sollen, sofern die Rahmenbedingungen (gleiches Präfix) noch passen.
Das vermeidet im speziellen zwei Probleme:
a) Würden dir aktive Verbindungen zusammenfallen (VPN, langsame Downloads...) wenn du alle 3600 Sekunden neue Adressen generierst und die aktive Adresse entfernst.
b) Würden einzelne Geräte irgendwann stapelweise IPv6-Adressen mit sich herumschleppen, weil sie neue Adressen generieren, aber die alten noch parallel als "non-preferred" behalten, weil da noch aktive Verbindungen drauf sind.
Qua standard (Abschnitt 5) wird die Lifetime einer generierten Adresse daher etwa eine Woche lang stetig verlängert und erst dann ausgetauscht.
Erfahrungsgemäß ist zumindest Windows rigoros und entfernt Adressen nach einer Woche, trennt auch alle aktiven Verbindungen darauf.
Vorher werden jedoch neue Adressen generiert, so dass neu Verbindungen auch die neuen Adressen benutzen.
Das vermeidet im speziellen zwei Probleme:
a) Würden dir aktive Verbindungen zusammenfallen (VPN, langsame Downloads...) wenn du alle 3600 Sekunden neue Adressen generierst und die aktive Adresse entfernst.
b) Würden einzelne Geräte irgendwann stapelweise IPv6-Adressen mit sich herumschleppen, weil sie neue Adressen generieren, aber die alten noch parallel als "non-preferred" behalten, weil da noch aktive Verbindungen drauf sind.
Qua standard (Abschnitt 5) wird die Lifetime einer generierten Adresse daher etwa eine Woche lang stetig verlängert und erst dann ausgetauscht.
Erfahrungsgemäß ist zumindest Windows rigoros und entfernt Adressen nach einer Woche, trennt auch alle aktiven Verbindungen darauf.
Vorher werden jedoch neue Adressen generiert, so dass neu Verbindungen auch die neuen Adressen benutzen.
1
Zitat von @aqui:
Mit dem aktuellen Debian "Bullseye" ist das nicht zu reproduzieren.
slaac private in der /etc/dhcpcd.conf angegeben und damit rennt das fehlerlos an einem Telekom Anschluss
Leider gibst du nicht an wie deine Netzwerk Konfig gemacht wird. Statisch, Network Manager etc. So kann man also nur frei rumraten.
Siehe auch hier für andere Distros und Adressierungen:
https://wiki.archlinux.org/title/IPv6#Privacy_extensions
https://wiki.ubuntuusers.de/IPv6/Privacy_Extensions/
Mit dem aktuellen Debian "Bullseye" ist das nicht zu reproduzieren.
slaac private in der /etc/dhcpcd.conf angegeben und damit rennt das fehlerlos an einem Telekom Anschluss
# Generate SLAAC address using the Hardware Address of the interface
#slaac hwaddr
# OR generate Stable Private IPv6 Addresses based from the DUID
slaac private Siehe auch hier für andere Distros und Adressierungen:
https://wiki.archlinux.org/title/IPv6#Privacy_extensions
https://wiki.ubuntuusers.de/IPv6/Privacy_Extensions/
Es ist ein Debian Testing. Was zeigt denn dein System bei "ip -6 ad" an?
Das ganze ist doch nur Kernel, da spielt der Netzwerkmanager keine rolle. Es ist nur acccept_ra aktiviert und use_tempaddr = 2
Hast du mal geschaut ob sich die Temp-Adresse mal ändert?
Zitat von @LordGurke:
Das ist per Standard so — RFC4942, Abschnitt 3.3, Absatz 1 sagt, dass einmal generierte Adressen durch Empfangen neuer RAs verlängert werden sollen, sofern die Rahmenbedingungen (gleiches Präfix) noch passen.
Das ist per Standard so — RFC4942, Abschnitt 3.3, Absatz 1 sagt, dass einmal generierte Adressen durch Empfangen neuer RAs verlängert werden sollen, sofern die Rahmenbedingungen (gleiches Präfix) noch passen.
Das Widerspricht aber der IPv6 Privacy Extensions. Dann dort will man ja z.b. täglich eine neue Adresse haben. Diese darf nicht verlängert werden. Dafür ist sie ja da.
Diese hat eine Maximale Lifetime und dann wird sie entsorgt.
Standard ist 86400s - dann müsste die Temp Adresse ablaufen, nur kann ich genau das nicht beobachten.
cat /proc/sys/net/ipv6/conf/enp2s0/temp_prefered_lft
Was zeigt denn dein System bei "ip -6 ad" an?
7: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
inet6 2003:xx:xxx:6e0a:9a41:ad32:972f:ef64/64 scope global dynamic mngtmpaddr noprefixroute
valid_lft 14269sec preferred_lft 1669sec
inet6 fe80::e8c:7463:d01a:f844/64 scope link
valid_lft forever preferred_lft forever 
Was komisch ist, ist die Tatsache das trotz slaac private in der /etc/dhcpcd.conf in der o.a. Anzeige das "temporary" fehlt.
Dort sollte eigentlich sowas wie:
inet6 2001:db8:ff00:8cb0:a1b5:bade:affe:cafe/64 scope global temporary dynamic
stehen, denn das temporary würde anzeigen das sie durch die Privacy Extensions erzeugt wurde. Irgendwas scheint da doch noch im Argen zu sein...
Dort sollte eigentlich sowas wie:
inet6 2001:db8:ff00:8cb0:a1b5:bade:affe:cafe/64 scope global temporary dynamic
stehen, denn das temporary würde anzeigen das sie durch die Privacy Extensions erzeugt wurde. Irgendwas scheint da doch noch im Argen zu sein...
Die Adresse wurde vermutlich einfach schlicht per RA generiert und nicht über DHCP bezogen
Das ist richtig ! In dem Segment rennt kein DHCPv6. Das ist ja böse... Bedeutet das jetzt im Umkehrschluss das Privacy v6 Adressen einzig nur mit DHCPv6 rennen ?
scheinbar ist es doch alles richtig.
jetzt sieht es so aus
inet6 2a00:XXXX:XXXX:ef03:1306:98ad:27d3:55cd/64 scope global temporary dynamic
valid_lft 3597sec preferred_lft 1797sec
inet6 2a00:XXXX:XXXX:ef03:9e67:7536:3e07:8f18/64 scope global temporary deprecated dynamic
valid_lft 3597sec preferred_lft 0sec
inet6 2a00:XXXX:XXXX:ef03:b62e:99ff:fea9:5106/64 scope global dynamic mngtmpaddr
valid_lft 3597sec preferred_lft 1797sec
ich hatte mich auf preferred_lft verlassen, aber das ist nicht die Lifetime der Temp-Adresse. Diese Ablaufzeit wird scheinbar von einen nicht sichtbaren Timer verwaltet. Die preferred_lft verlängert sich war bei jedem RA aber der unsichtbare Timer prüft wie lange die Temp-Adresse bereits im System ist. Wenn dieser abläuft dann wird sie deprecated.
Ich hatte war die Laufzeit verkürzt aber vermutlich nachdem die Adresse schon vergebene war, deswegen hat es 24 Stunden gedauert bis sie ungültig wurde.
Es scheint also zu funktionieren, aber es ist nicht direkt sichtbar wie lange die Temp-Adresse noch gültig ist - zumindest nicht mit "ip -6 addr". Eventuell hat jemand ja noch einen Tipp wo man das ablesen kann.
jetzt sieht es so aus
inet6 2a00:XXXX:XXXX:ef03:1306:98ad:27d3:55cd/64 scope global temporary dynamic
valid_lft 3597sec preferred_lft 1797sec
inet6 2a00:XXXX:XXXX:ef03:9e67:7536:3e07:8f18/64 scope global temporary deprecated dynamic
valid_lft 3597sec preferred_lft 0sec
inet6 2a00:XXXX:XXXX:ef03:b62e:99ff:fea9:5106/64 scope global dynamic mngtmpaddr
valid_lft 3597sec preferred_lft 1797sec
ich hatte mich auf preferred_lft verlassen, aber das ist nicht die Lifetime der Temp-Adresse. Diese Ablaufzeit wird scheinbar von einen nicht sichtbaren Timer verwaltet. Die preferred_lft verlängert sich war bei jedem RA aber der unsichtbare Timer prüft wie lange die Temp-Adresse bereits im System ist. Wenn dieser abläuft dann wird sie deprecated.
Ich hatte war die Laufzeit verkürzt aber vermutlich nachdem die Adresse schon vergebene war, deswegen hat es 24 Stunden gedauert bis sie ungültig wurde.
Es scheint also zu funktionieren, aber es ist nicht direkt sichtbar wie lange die Temp-Adresse noch gültig ist - zumindest nicht mit "ip -6 addr". Eventuell hat jemand ja noch einen Tipp wo man das ablesen kann.
Du machst aber dann DHCPv6, oder ?
Hier nur SLAAC und über die RAs (siehe oben). Ich war jetzt etwas erstaunt das die Privacy Extension dann (scheinbar) nicht mehr laufen was, wenn es denn stimmt, ziemlich blöd wäre.
Hier nur SLAAC und über die RAs (siehe oben). Ich war jetzt etwas erstaunt das die Privacy Extension dann (scheinbar) nicht mehr laufen was, wenn es denn stimmt, ziemlich blöd wäre.
Zitat von @aqui:
Du machst aber dann DHCPv6, oder ?
Hier nur SLAAC und über die RAs (siehe oben). Ich war jetzt etwas erstaunt das die Privacy Extension dann (scheinbar) nicht mehr laufen was, wenn es denn stimmt, ziemlich blöd wäre.
Du machst aber dann DHCPv6, oder ?
Hier nur SLAAC und über die RAs (siehe oben). Ich war jetzt etwas erstaunt das die Privacy Extension dann (scheinbar) nicht mehr laufen was, wenn es denn stimmt, ziemlich blöd wäre.
nein, keine DHCPv6. Nur RA.
Wenn du keine Temp Adresse hat schau mal was in
cat /proc/sys/net/ipv6/conf/enp5s0/use_tempaddr
steht ( interface anpassen!)
Da steht ne 0
0 ist ja erstmal nicht so gut. Und nu ??
root@server:/# cat /proc/sys/net/ipv6/conf/eth1/use_tempaddr
0 Zitat von @aqui:
Da steht ne 0
0 ist ja erstmal nicht so gut. Und nu ??
Da steht ne 0
root@server:/# cat /proc/sys/net/ipv6/conf/eth1/use_tempaddr
0 schreib eine 2 rein, schon wirst du eine Temp-Adresse haben
echo 2 > /proc/sys/net/ipv6/conf/eth1/use_tempaddr
https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt
Tadaa !! 😎
Böses Faul wenn man sich nur auf das slaac private in dhcpcd.conf verlässt, denn das scheint nicht zu greifen.
Fragt sich nur warum ?
Ein...
in der /etc/sysctl.conf ist die sicherere Bank. Damit klappt es dann fehlerfrei.
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
inet6 2003:xx:xxx:6e0a:c42a:566:8d41:1067/64 scope global temporary dynamic
valid_lft 14349sec preferred_lft 1749sec
inet6 2003:xx:xxx:6e0a:9a41:ad32:972f:ef64/64 scope global dynamic mngtmpaddr noprefixroute
valid_lft 14349sec preferred_lft 1749sec
inet6 fe80::e8c:7463:d01a:f844/64 scope link
valid_lft forever preferred_lft forever Fragt sich nur warum ?
Ein...
net.ipv6.conf.all.use_tempaddr=2
net.ipv6.conf.default.use_tempaddr=2 Zitat von @aqui:
Tadaa !! 😎
Böses Faul wenn man sich nur auf das slaac private in dhcpcd.conf verlässt, denn das scheint nicht zu greifen.
Fragt sich nur warum ?
Weil die dhcpcd.conf sich nach RFC7217 richtetTadaa !! 😎
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
inet6 2003:xx:xxx:6e0a:c42a:566:8d41:1067/64 scope global temporary dynamic
valid_lft 14349sec preferred_lft 1749sec
inet6 2003:xx:xxx:6e0a:9a41:ad32:972f:ef64/64 scope global dynamic mngtmpaddr noprefixroute
valid_lft 14349sec preferred_lft 1749sec
inet6 fe80::e8c:7463:d01a:f844/64 scope link
valid_lft forever preferred_lft forever Fragt sich nur warum ?
The resulting Interface Identifiers remain stable for each prefix used with SLAAC within each subnet for the same network interface. That is, the algorithm generates the same Interface Identifier when configuring an address (for the same interface) belonging to the same prefix within the same subnet.
1
Mmmhh, 2 RFC Standards...?!? Die Freitags Frage ist dann jetzt was best practise ist ? slaac private lassen oder die Privacy Extensions wie oben aktivieren ?
Letztlich wohl davon abhängig wie "private" RFC7217 dann ist. Seite 4 des RFC beschreibt ja die Nachteile von Temorary Privacy Adressen.
Windows und Apple Clients verhalten sich ja so wie die Privacy Settings im sysctl mit einer 2ten temporären Adresse.
Letztlich wohl davon abhängig wie "private" RFC7217 dann ist. Seite 4 des RFC beschreibt ja die Nachteile von Temorary Privacy Adressen.
Windows und Apple Clients verhalten sich ja so wie die Privacy Settings im sysctl mit einer 2ten temporären Adresse.
Zitat von @aqui:
Mmmhh, 2 RFC Standards...?!? Die Freitags Frage ist dann jetzt was best practise ist ? slaac private lassen oder die Privacy Extensions wie oben aktivieren ?
Letztlich wohl davon abhängig wie "private" RFC7217 dann ist.
Windows und Apple Clients verhalten sich ja so wie die Privacy Settings im sysctl mit einer 2ten temporären Adresse.
Mmmhh, 2 RFC Standards...?!? Die Freitags Frage ist dann jetzt was best practise ist ? slaac private lassen oder die Privacy Extensions wie oben aktivieren ?
Letztlich wohl davon abhängig wie "private" RFC7217 dann ist.
Windows und Apple Clients verhalten sich ja so wie die Privacy Settings im sysctl mit einer 2ten temporären Adresse.
Kommt drauf an was du brauchst. Wenn du echte privacy extensions brauchst dann immer über sysctl konfigurieren, die temporary addresses werden ja eh bevorzugt genutzt wenn nach aussen kommuniziert wird.
https://wiki.archlinux.org/title/IPv6#Privacy_extensions
Nen Server im Netz wird das ja nicht gerade brauchen, da sind dann meist die mngmt addresses anhand der MAC besser, aber man kann ja beides parallel nutzen ...
1Zitat von @aqui:
Macht absolut Sinn !
Dann kann der TO ja beruhigt schliessen !
How can I mark a post as solved?
Macht absolut Sinn !
Dann kann der TO ja beruhigt schliessen !
How can I mark a post as solved?
ja, aber eventuell hat ja noch jemand ein Tipp wo man die Lifetime der Temp adresse ablesen kann.
Kann man auch vorgeben in der sysctl
https://bbs.archlinux.org/viewtopic.php?id=232227
Es müssten dann die Parameter valid_lft 86396sec preferred_lft 14396sec im Output sein.
Das die RAs den Timer resetten wie im Archlinux Blog beschrieben kann nicht sein, denn damit würde man die Temporary Adressen ja ad absurdum führen. Würde das stimmen würden die ja nie austimen und dann erneuert werden.
Die Counter zählen hier zur Zeit runter und werden erwartungsgemäß NICHT von den RAs resettet. Die Adresse hat noch 1684 Sek Gültigkeit also mal ne knappe halbe Stunde warten...
https://bbs.archlinux.org/viewtopic.php?id=232227
use_tempaddr - INTEGER
Preference for Privacy Extensions (RFC3041).
<= 0 : disable Privacy Extensions
== 1 : enable Privacy Extensions, but prefer public
addresses over temporary addresses.
> 1 : enable Privacy Extensions and prefer temporary
addresses over public addresses.
Default: 0 (for most devices)
-1 (for point-to-point devices and loopback devices)
temp_valid_lft - INTEGER
valid lifetime (in seconds) for temporary addresses.
Default: 604800 (7 days)
temp_prefered_lft - INTEGER
Preferred lifetime (in seconds) for temporary addresses.
Default: 86400 (1 day) Das die RAs den Timer resetten wie im Archlinux Blog beschrieben kann nicht sein, denn damit würde man die Temporary Adressen ja ad absurdum führen. Würde das stimmen würden die ja nie austimen und dann erneuert werden.
Die Counter zählen hier zur Zeit runter und werden erwartungsgemäß NICHT von den RAs resettet. Die Adresse hat noch 1684 Sek Gültigkeit also mal ne knappe halbe Stunde warten...
Zitat von @aqui:
Das die RAs den Timer resetten wie im Archlinux Blog beschrieben kann nicht sein, denn damit würde man die Temporary Adressen ja ad absurdum führen. Würde das stimmen würden die ja nie austimen und dann erneuert werden.
Eben sehe ich genau so, kann ich hier auch nirgendwo nachstellen das sich da die prefered lifetime zurücksetzt! Auch mit epxlizit getriggertem RA. Das die RAs den Timer resetten wie im Archlinux Blog beschrieben kann nicht sein, denn damit würde man die Temporary Adressen ja ad absurdum führen. Würde das stimmen würden die ja nie austimen und dann erneuert werden.
ip -6 a zeigt die Lifetimes völlig korrekt an, da wird nüscht zurückgesetzt.Zitat von @1915348599:
Zitat von @aqui:
Das die RAs den Timer resetten wie im Archlinux Blog beschrieben kann nicht sein, denn damit würde man die Temporary Adressen ja ad absurdum führen. Würde das stimmen würden die ja nie austimen und dann erneuert werden.
Eben sehe ich genau so, kann ich hier auch nirgendwo nachstellen das sich da die prefered lifetime zurücksetzt! Auch mit epxlizit getriggertem RA. Das die RAs den Timer resetten wie im Archlinux Blog beschrieben kann nicht sein, denn damit würde man die Temporary Adressen ja ad absurdum führen. Würde das stimmen würden die ja nie austimen und dann erneuert werden.
ip -6 a zeigt die Lifetimes völlig korrekt an, da wird nüscht zurückgesetzt.da glaube ich nicht, zeige mal bitte deine Ausgabe von ip -6 a am besten im Abstand von 1-2 min.
Bei alle was man im Thread sieht, scheint es immer zurück gesetzt zu werden. Nur ist das nicht der Timer für dem ablauf der Temp-Adresse.
z.b.
inet6 2003:xx:xxx:6e0a:c42a:566:8d41:1067/64 scope global temporary dynamic
valid_lft 14349sec preferred_lft 1749sec
er wurde vermutlich 1800s zurückgesetzt.
Zitat von @Marcus78:
da glaube ich nicht, zeige mal bitte deine Ausgabe von ip -6 a am besten im Abstand von 1-2 min.
Ist aber so. Die Archlinux Maschine die ich hier habe setzt rein gar nichts zurück, schon seit Stunden ...da glaube ich nicht, zeige mal bitte deine Ausgabe von ip -6 a am besten im Abstand von 1-2 min.
Was bringt dir ein Screenshot bei dem der Timer halt 120 sekunden geringer ist also vorher
Bei alle was man im Thread sieht, scheint es immer zurück gesetzt zu werden. Nur ist das nicht der Timer für dem ablauf der Temp-Adresse.
z.b.
inet6 2003:xx:xxx:6e0a:c42a:566:8d41:1067/64 scope global temporary dynamic
valid_lft 14349sec preferred_lft 1749sec
er wurde vermutlich 1800s zurückgesetzt.
Nö ... Ist wohl ein Verständnis deinerseits. Das funktioniert alles wie vorgesehen, auch wenn du versuchst da Fehler zu finden die nicht da sind z.b.
inet6 2003:xx:xxx:6e0a:c42a:566:8d41:1067/64 scope global temporary dynamic
valid_lft 14349sec preferred_lft 1749sec
er wurde vermutlich 1800s zurückgesetzt.
. Die hätte man schon längst gefunden, du bist ja nicht der erste der IPv6 nutzt, ich tu das schon mehr als 7 Jahre ...Zitat von @1915348599:
Was bringt dir ein Screenshot bei dem der Timer halt 120 sekunden geringer ist also vorher
Zitat von @Marcus78:
da glaube ich nicht, zeige mal bitte deine Ausgabe von ip -6 a am besten im Abstand von 1-2 min.
Ist aber so. Die Archlinux Maschine die ich hier habe setzt rein gar nichts zurück, schon seit Stunden ...da glaube ich nicht, zeige mal bitte deine Ausgabe von ip -6 a am besten im Abstand von 1-2 min.
Was bringt dir ein Screenshot bei dem der Timer halt 120 sekunden geringer ist also vorher
Bei alle was man im Thread sieht, scheint es immer zurück gesetzt zu werden. Nur ist das nicht der Timer für dem ablauf der Temp-Adresse.
z.b.
inet6 2003:xx:xxx:6e0a:c42a:566:8d41:1067/64 scope global temporary dynamic
valid_lft 14349sec preferred_lft 1749sec
er wurde vermutlich 1800s zurückgesetzt.
Nö ...z.b.
inet6 2003:xx:xxx:6e0a:c42a:566:8d41:1067/64 scope global temporary dynamic
valid_lft 14349sec preferred_lft 1749sec
er wurde vermutlich 1800s zurückgesetzt.
warum zeigt du es dann nicht, wenn es bei dir anders ist? Die Adresse darfst du gerne XX verstecken.
inet6 2a00:XXXX:XXXX:ef03:1306:98ad:27d3:55cd/64 scope global temporary dynamic
valid_lft 3593sec preferred_lft 1793sec
1 min später
inet6 2a00:XXXX:XXXX:ef03:1306:98ad:27d3:55cd/64 scope global temporary dynamic
valid_lft 3596sec preferred_lft 1796sec
also ich sehe da ein zurücksetzen.
Bitte mache ich gerne, bitte warten ...
Zitat von @1915348599:
Was bringt dir ein Screenshot bei dem der Timer halt 120 sekunden geringer ist also vorher
. Die hätte man schon längst gefunden, du bist ja nicht der erste der IPv6 nutzt, ich tu das schon mehr als 7 Jahre ...
Zitat von @Marcus78:
da glaube ich nicht, zeige mal bitte deine Ausgabe von ip -6 a am besten im Abstand von 1-2 min.
Ist aber so. Die Archlinux Maschine die ich hier habe setzt rein gar nichts zurück, schon seit Stunden ...da glaube ich nicht, zeige mal bitte deine Ausgabe von ip -6 a am besten im Abstand von 1-2 min.
Was bringt dir ein Screenshot bei dem der Timer halt 120 sekunden geringer ist also vorher
Bei alle was man im Thread sieht, scheint es immer zurück gesetzt zu werden. Nur ist das nicht der Timer für dem ablauf der Temp-Adresse.
z.b.
inet6 2003:xx:xxx:6e0a:c42a:566:8d41:1067/64 scope global temporary dynamic
valid_lft 14349sec preferred_lft 1749sec
er wurde vermutlich 1800s zurückgesetzt.
Nö ... Ist wohl ein Verständnis deinerseits. Das funktioniert alles wie vorgesehen, auch wenn du versuchst da Fehler zu finden die nicht da sind z.b.
inet6 2003:xx:xxx:6e0a:c42a:566:8d41:1067/64 scope global temporary dynamic
valid_lft 14349sec preferred_lft 1749sec
er wurde vermutlich 1800s zurückgesetzt.
. Die hätte man schon längst gefunden, du bist ja nicht der erste der IPv6 nutzt, ich tu das schon mehr als 7 Jahre ...genau das habe ich bereits geschrieben - ja es funktioniert. Man kann nur nirgend sehen, wann die Adresse abläuft.
Zwischen drin habe ich 3 RAs mit meinem Mikrotik explizit nochmal getriggert ...
Zitat von @1915348599:
denn schau bitte noch mal was ich eingangs geschrieben habe
Das Problem tritt an Endkundenanschlüssen auf, wo die Lifetime des IPv6 prefix recht klein ist. ( z.b. 3600s ).
das hast du überhaupt nicht. Damit ist klar das du es nicht sehen kannst.
Das Problem tritt an Endkundenanschlüssen auf, wo die Lifetime des IPv6 prefix recht klein ist. ( z.b. 3600s ).
Das ist kein "Problem", du meinst wohl die DHCPv6 LeaseTime, die wird immer wenn die hälfte der Lease-Time Zeit abgelaufen ist erneuert bei dir also jede halbe Stunde ...https://blogs.infoblox.com/ipv6-coe/understanding-dhcpv6-lease-times/
Zitat von @1915348599:
https://blogs.infoblox.com/ipv6-coe/understanding-dhcpv6-lease-times/
Das Problem tritt an Endkundenanschlüssen auf, wo die Lifetime des IPv6 prefix recht klein ist. ( z.b. 3600s ).
Das ist kein "Problem", du meinst wohl die DHCPv6 LeaseTime, die wird immer wenn die hälfte der Lease-Time Zeit abgelaufen ist erneuert bei dir also jede halbe Stunde ...https://blogs.infoblox.com/ipv6-coe/understanding-dhcpv6-lease-times/
nein ich habe kein DHCPv6.
Und ich meine die Ausgabe von ip -6 adr
Setze die bei die lifetime im RA auf 3600 und du wirst den gleichen Effekt sehen.
Zitat von @Marcus78:
Setze die bei die lifetime im RA auf 3600 und du wirst den gleichen Effekt sehen.
Setze die bei die lifetime im RA auf 3600 und du wirst den gleichen Effekt sehen.
Habe ich, macht hier keinen Unterschied....
Zitat von @1915348599:
Habe ich, macht hier keinen Unterschied....
Zitat von @Marcus78:
Setze die bei die lifetime im RA auf 3600 und du wirst den gleichen Effekt sehen.
Setze die bei die lifetime im RA auf 3600 und du wirst den gleichen Effekt sehen.
Habe ich, macht hier keinen Unterschied....
und stand da auch die 3600 bei der Ausgabe? Denn wenn sie auch weniger als 2 Stunden verkürzt wird, dann wirkt da nicht sofort - steht in irgendeiner RFC.
Zitat von @Marcus78:
und stand da auch die 3600 bei der Ausgabe? Denn wenn sie auch weniger als 2 Stunden verkürzt wird, dann wirkt da nicht sofort - steht in irgendeiner RFC.
Joa, könnte ich ständig so weiterführen, da ändert sich nüscht ...und stand da auch die 3600 bei der Ausgabe? Denn wenn sie auch weniger als 2 Stunden verkürzt wird, dann wirkt da nicht sofort - steht in irgendeiner RFC.
Hier gehts weiter
Mehrere RAs zwischen drin angekommen ... macht keinen Unterschied ...
Mehrere RAs zwischen drin angekommen ... macht keinen Unterschied ...
Zitat von @1915348599:
Zitat von @Marcus78:
und stand da auch die 3600 bei der Ausgabe? Denn wenn sie auch weniger als 2 Stunden verkürzt wird, dann wirkt da nicht sofort - steht in irgendeiner RFC.
Joa, könnte ich ständig so weiterführen, da ändert sich nüscht ...und stand da auch die 3600 bei der Ausgabe? Denn wenn sie auch weniger als 2 Stunden verkürzt wird, dann wirkt da nicht sofort - steht in irgendeiner RFC.
genau dort ist ja das Problem. Du Hast keine LeaseTime von 3600s - der Wert wurde bei dir nicht übernommen
RFC:
If the StoredLifetime is less than or equal to 2 hours and the
received Lifetime is less than or equal to StoredLifetime,
ignore the prefix, unless the Router Advertisement from which
Wenn du es wirklich sehen willst, wirst du wohl das Interface zurücksetzen müssen -
Zitat von @Marcus78:
genau dort ist ja das Problem. Du Hast keine LeaseTime von 3600s - der Wert wurde bei dir nicht übernommen
Doch ... Die Prefered Litetime wird niemals auf 3600 stehen weil der Timer immer weiter läuft der steht nur kurz auf 3600 wenn die Adresse gerade vergeben wurde ...genau dort ist ja das Problem. Du Hast keine LeaseTime von 3600s - der Wert wurde bei dir nicht übernommen
RFC:
If the StoredLifetime is less than or equal to 2 hours and the
received Lifetime is less than or equal to StoredLifetime,
ignore the prefix, unless the Router Advertisement from which
Wenn du es wirklich sehen willst, wirst du wohl das Interface zurücksetzen müssen -
Ist es ... Du hast da ein Verständnisproblem.If the StoredLifetime is less than or equal to 2 hours and the
received Lifetime is less than or equal to StoredLifetime,
ignore the prefix, unless the Router Advertisement from which
Wenn du es wirklich sehen willst, wirst du wohl das Interface zurücksetzen müssen -
Ich bin jetzt raus wird mir ehrlich gesagt zu blöd.
🖖
Zitat von @1915348599:
Zitat von @Marcus78:
genau dort ist ja das Problem. Du Hast keine LeaseTime von 3600s - der Wert wurde bei dir nicht übernommen
Doch ... Die Prefered Litetime wird niemals auf 3600 stehen weil der Timer immer weiter läuft der steht nur auf 3600 wenn die Adresse gerade vergeben wurde ...genau dort ist ja das Problem. Du Hast keine LeaseTime von 3600s - der Wert wurde bei dir nicht übernommen
RFC:
If the StoredLifetime is less than or equal to 2 hours and the
received Lifetime is less than or equal to StoredLifetime,
ignore the prefix, unless the Router Advertisement from which
Wenn du es wirklich sehen willst, wirst du wohl das Interface zurücksetzen müssen -
Ist es ... Du hast da ein VerständnisproblemIf the StoredLifetime is less than or equal to 2 hours and the
received Lifetime is less than or equal to StoredLifetime,
ignore the prefix, unless the Router Advertisement from which
Wenn du es wirklich sehen willst, wirst du wohl das Interface zurücksetzen müssen -
nein habe ich nicht. Wenn eine Prefix-LifeTime von 3600s hat denn steht das auch dort drin. Nur bei dir wird es nicht übernommen weil du von Werten von > 2 Stunden ausgeht
Setzte also die Refix-Lifetime auf 3600s, starte neu und dann sieht du auch dort die 3600. So wie es auch bei den anderen im Thread ist.
So lange du nicht die gleichen Bedingen hast, ist es schlecht zu zeigen.
Zitat von @1915348599:
Ich bin jetzt raus wird mir ehrlich gesagt zu blöd.
Zitat von @Marcus78:
genau dort ist ja das Problem. Du Hast keine LeaseTime von 3600s - der Wert wurde bei dir nicht übernommen
Doch ... Die Prefered Litetime wird niemals auf 3600 stehen weil der Timer immer weiter läuft der steht nur kurz auf 3600 wenn die Adresse gerade vergeben wurde ...genau dort ist ja das Problem. Du Hast keine LeaseTime von 3600s - der Wert wurde bei dir nicht übernommen
RFC:
If the StoredLifetime is less than or equal to 2 hours and the
received Lifetime is less than or equal to StoredLifetime,
ignore the prefix, unless the Router Advertisement from which
Wenn du es wirklich sehen willst, wirst du wohl das Interface zurücksetzen müssen -
Ist es ... Du hast da ein Verständnisproblem.If the StoredLifetime is less than or equal to 2 hours and the
received Lifetime is less than or equal to StoredLifetime,
ignore the prefix, unless the Router Advertisement from which
Wenn du es wirklich sehen willst, wirst du wohl das Interface zurücksetzen müssen -
Ich bin jetzt raus wird mir ehrlich gesagt zu blöd.
schade, aber wenn man halt bei sich andere Bedingungen hat, dann ist es halt auch nicht nachvollziehbar.
Schau dir die Ausgaben von den anderen Personen, hat dort hat niemand die großen Zeiten wie du. Damit hast du ein anderes Setup.
Zitat von @Marcus78:
Schau dir die Ausgaben von den anderen Personen, hat dort hat niemand die großen Zeiten wie du. Damit hast du ein anderes Setup.
BlaBla, wie gesagt macht keinen Unterschied wenn ich die valid-lifetime auch auf 3600 setze .... guckst du auf die richtige Adresse nicht die mgmt, habe die mal ganz ausgeblendet ...Schau dir die Ausgaben von den anderen Personen, hat dort hat niemand die großen Zeiten wie du. Damit hast du ein anderes Setup.
Nach weiterem warten und x RAs ...
soll ich weiter machen ....
to be continued ...
Zitat von @1915348599:
Zitat von @Marcus78:
Schau dir die Ausgaben von den anderen Personen, hat dort hat niemand die großen Zeiten wie du. Damit hast du ein anderes Setup.
BlaBla, wie gesagt macht keinen Unterschied wenn ich die valid-lifetime auch auf 3600 setze .... guckst du auf die richtige Adresse nicht die mgmt, habe die mal ganz ausgeblendet ...Schau dir die Ausgaben von den anderen Personen, hat dort hat niemand die großen Zeiten wie du. Damit hast du ein anderes Setup.
Danke das du es versuchst hast.
was soll ich da jetzt sagen, das hätte ich auch nicht erwartet. Ich kann dir genauso 3 Systeme zeigen wo es zurückgesetzt wird
System1:
inet6 2a00:XXX:XXX:ef03:1306:98ad:27d3:55cd/64 scope global temporary dynamic
valid_lft 3592sec preferred_lft 1792sec
1min
inet6 2a00:XXX:XXX::ef03:1306:98ad:27d3:55cd/64 scope global temporary dynamic
valid_lft 3600sec preferred_lft 1800sec
System2
inet6 2a01:XXX:XXX:c299:bc66:a0ce:a3a8:c5dc/64 scope global temporary dynamic
valid_lft 236sec preferred_lft 56sec
1min
inet6 2a01:XXX:XXX:c299:bc66:a0ce:a3a8:c5dc/64 scope global temporary dynamic
valid_lft 300sec preferred_lft 120sec
System3
inet6 2a00xxx:xxx:8c03:8712:544:77fe:6f39/64 scope global temporary dynamic
valid_lft 3596sec preferred_lft 1796sec
1min
inet6 2a00:xxx:xxx:8c03:8712:544:77fe:6f39/64 scope global temporary dynamic
valid_lft 3597sec preferred_lft 1797sec
3 Verschiedene Linux System in 3 verschieden Netzen.
(1 Raspi, 2 mal Debian einmal 5.10 Kernel und einmal 5.16 )
alle zeigen das gleiche Verhalten.
Klar kann das sein, das ich irgendwo ein Denkfehler habe, aber ich manipuliere doch nicht die ausgaben.
Hier noch die RA dazu
interface enp5s0
{
AdvSendAdvert on;
- Note: {Min,Max}RtrAdvInterval cannot be obtained with radvdump
AdvOtherConfigFlag off;
AdvReachableTime 0;
AdvRetransTimer 0;
AdvCurHopLimit 64;
AdvDefaultLifetime 30;
AdvHomeAgentFlag off;
AdvDefaultPreference medium;
AdvSourceLLAddress on;
prefix 2a00:xxx:xxxx:ef03::/64
{
AdvValidLifetime 3600;
AdvPreferredLifetime 1800;
AdvOnLink on;
AdvAutonomous on;
AdvRouterAddr on;
}; # End of prefix definition
Markus hat teilweise Recht.
Hier (Debian Bullseye) gehen beide valid_lft und preferred_lft Counter der Temporary Address im Sekundentakt runter. Bei preferred_lft 15xy und 5 Minuten später war der Counter wieder auf 1789 und das wiederholt sich.
Sieht also doch irgendwie aus das der Counter retriggert wird durch RA's (oder was auch immer). Muss mal den tcpdump eben anschmeissen...
Hier (Debian Bullseye) gehen beide valid_lft und preferred_lft Counter der Temporary Address im Sekundentakt runter. Bei preferred_lft 15xy und 5 Minuten später war der Counter wieder auf 1789 und das wiederholt sich.
Sieht also doch irgendwie aus das der Counter retriggert wird durch RA's (oder was auch immer). Muss mal den tcpdump eben anschmeissen...
AdvPreferredLifetime 1800;
Das sollte es sein ...RFC4862 5.5.3
War das jetzt auf die Privacy sprich Temporary Address bezogen ?
Im Default steht die ja auf einem Tag (preferred) bzw. 7 Tage (valid)
cat /proc/sys/net/ipv6/conf/eth1/temp_prefered_lft
86400
cat /proc/sys/net/ipv6/conf/eth1/temp_valid_lft
604800
Muss man den Default jetzt in der sysctl.conf anpassen auf 1800 ?
Im Default steht die ja auf einem Tag (preferred) bzw. 7 Tage (valid)
cat /proc/sys/net/ipv6/conf/eth1/temp_prefered_lft
86400
cat /proc/sys/net/ipv6/conf/eth1/temp_valid_lft
604800
Muss man den Default jetzt in der sysctl.conf anpassen auf 1800 ?
Ja in Kombination mit den RAs , ließ den RFC Abschnitt mal ganz in Ruhe.
S. letztes Kommentar vom TO.
Muss man den Default jetzt in der sysctl.conf anpassen auf 1800 ?
Nein das hat er in seiner RA-Config hinterlegt.S. letztes Kommentar vom TO.
RFC Abschnitt gelesen und (hoffentlich) verstanden. 😉 Hier werkelt ein Cisco...
Vlan10 is up, line protocol is up
IPv6 is enabled, link-local address is FE80::5E71:CEF:FE5C:12A4
2003:Cx:xxx:xx0A::1, subnet is 2003:Cx:xxx:xx0A::/64 [CAL/PRE]
valid lifetime 13940 preferred lifetime 1340
Joined group address(es):
FF02::1
FF02::2
FF02::1:2
FF02::1:FF00:1
FF02::1:FF0C:12A4
FF05::1:3
MTU is 1500 bytes
ND router advertisements are sent every 200 seconds
ND router advertisements live for 1800 seconds
ND advertised default router preference is Medium
Hosts use stateless autoconfig for addresses.
Hosts use DHCP to obtain other configuration.
Bedeutet dann alle 200 Sekunden kommt ein RA und retriggert den Temporary Counter. Heisst dann ja im Umkehrschluss das der Debian Timer mit 86400 Sekunden dann nie austimen kann und man den unter die 200 Sek. des Routers schrauben müsste ?!
RA Lifetimes lassen sich auch am Router customizen:
https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipv6/command/ipv6-cr-b ...
Vlan10 is up, line protocol is up
IPv6 is enabled, link-local address is FE80::5E71:CEF:FE5C:12A4
2003:Cx:xxx:xx0A::1, subnet is 2003:Cx:xxx:xx0A::/64 [CAL/PRE]
valid lifetime 13940 preferred lifetime 1340
Joined group address(es):
FF02::1
FF02::2
FF02::1:2
FF02::1:FF00:1
FF02::1:FF0C:12A4
FF05::1:3
MTU is 1500 bytes
ND router advertisements are sent every 200 seconds
ND router advertisements live for 1800 seconds
ND advertised default router preference is Medium
Hosts use stateless autoconfig for addresses.
Hosts use DHCP to obtain other configuration.
Bedeutet dann alle 200 Sekunden kommt ein RA und retriggert den Temporary Counter. Heisst dann ja im Umkehrschluss das der Debian Timer mit 86400 Sekunden dann nie austimen kann und man den unter die 200 Sek. des Routers schrauben müsste ?!
RA Lifetimes lassen sich auch am Router customizen:
https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipv6/command/ipv6-cr-b ...
Zitat von @aqui:
RFC Abschnitt gelesen und (hoffentlich) verstanden. 😉 Hier werkelt ein Cisco...
Vlan10 is up, line protocol is up
IPv6 is enabled, link-local address is FE80::5E71:CEF:FE5C:12A4
2003:Cx:xxx:xx0A::1, subnet is 2003:Cx:xxx:xx0A::/64 [CAL/PRE]
valid lifetime 13940 preferred lifetime 1340
Joined group address(es):
FF02::1
FF02::2
FF02::1:2
FF02::1:FF00:1
FF02::1:FF0C:12A4
FF05::1:3
MTU is 1500 bytes
ND router advertisements are sent every 200 seconds
ND router advertisements live for 1800 seconds
ND advertised default router preference is Medium
Hosts use stateless autoconfig for addresses.
Hosts use DHCP to obtain other configuration.
Bedeutet dann alle 200 Sekunden kommt ein RA und retriggert den Temporary Counter. Heisst dann ja im Umkehrschluss das der Debian Timer mit 86400 Sekunden dann nie austimen kann und man den unter die 200 Sek. des Routers schrauben müsste ?!
RA Lifetimes lassen sich auch am Router customizen:
https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipv6/command/ipv6-cr-b ...
RFC Abschnitt gelesen und (hoffentlich) verstanden. 😉 Hier werkelt ein Cisco...
Vlan10 is up, line protocol is up
IPv6 is enabled, link-local address is FE80::5E71:CEF:FE5C:12A4
2003:Cx:xxx:xx0A::1, subnet is 2003:Cx:xxx:xx0A::/64 [CAL/PRE]
valid lifetime 13940 preferred lifetime 1340
Joined group address(es):
FF02::1
FF02::2
FF02::1:2
FF02::1:FF00:1
FF02::1:FF0C:12A4
FF05::1:3
MTU is 1500 bytes
ND router advertisements are sent every 200 seconds
ND router advertisements live for 1800 seconds
ND advertised default router preference is Medium
Hosts use stateless autoconfig for addresses.
Hosts use DHCP to obtain other configuration.
Bedeutet dann alle 200 Sekunden kommt ein RA und retriggert den Temporary Counter. Heisst dann ja im Umkehrschluss das der Debian Timer mit 86400 Sekunden dann nie austimen kann und man den unter die 200 Sek. des Routers schrauben müsste ?!
RA Lifetimes lassen sich auch am Router customizen:
https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipv6/command/ipv6-cr-b ...
nein. Wie schon gesagt es gibt einen (noch) nicht sichtbaren timer für die Temp-Addresse. Der sorgt dafür das sie erneuert wird, obwohl man in der Anzeige von Ip -6 a den Wert nicht auf 0 gehen sieht.
Also, habe das nochmal nachgestellt.
Wenn die preferred_lifetime des Routers im advertisement geringer ist als die die der Client in seinen Einstellungen konfiguriert hat(bei debian11 bspw. sind das ja wesentlich höhere Werte) dann wird der Zähler in ip -6 a immer wieder zurückgesetzt. Setzt man dagegen die Werte am Client über
Der Client versucht hier seine Adresse so lange wie auf ihm selbst als preferred eingestellt ist gültig zu halten, egal was das RA sagt.
Ist also Einstellungssache ...
Wenn die preferred_lifetime des Routers im advertisement geringer ist als die die der Client in seinen Einstellungen konfiguriert hat(bei debian11 bspw. sind das ja wesentlich höhere Werte) dann wird der Zähler in ip -6 a immer wieder zurückgesetzt. Setzt man dagegen die Werte am Client über
sysctl auf den gleichen Wert oder geringer wie die im Router advertisement dann passiert das Zurücksetzen nicht mehr und die Zeiten in der Anzeige stimmen wieder.Der Client versucht hier seine Adresse so lange wie auf ihm selbst als preferred eingestellt ist gültig zu halten, egal was das RA sagt.
Ist also Einstellungssache ...
Das ist richtig, der Timer geht so, ohne entspr. Anpassung an die RA Intervalle, nie auf 0 !
Die Kardinalsfrage ist nun ob der RA Intervall diesen Timer retriggert ? Laut RFC ist das ja der Fall.
Der Test des Kollegen @1915348599 von oben bestätigt ja auch genau das !
Ich sehe mir das nochmal genau an mit dem 200 Sek. Intervall und passe die Default Settings
temp_valid_lft - INTEGER
valid lifetime (in seconds) for temporary addresses.
Default: 604800 (7 days)
temp_prefered_lft - INTEGER
Preferred lifetime (in seconds) for temporary addresses.
Default: 86400 (1 day)
im Debian mal entsprechend an.
Würde man es so auf den Defaults lassen vermute ich mal das sich die Temporary Adresse dann immer nur alle 7 Tage ändert ?!
Die Kardinalsfrage ist nun ob der RA Intervall diesen Timer retriggert ? Laut RFC ist das ja der Fall.
Der Test des Kollegen @1915348599 von oben bestätigt ja auch genau das !
Ich sehe mir das nochmal genau an mit dem 200 Sek. Intervall und passe die Default Settings
temp_valid_lft - INTEGER
valid lifetime (in seconds) for temporary addresses.
Default: 604800 (7 days)
temp_prefered_lft - INTEGER
Preferred lifetime (in seconds) for temporary addresses.
Default: 86400 (1 day)
im Debian mal entsprechend an.
Würde man es so auf den Defaults lassen vermute ich mal das sich die Temporary Adresse dann immer nur alle 7 Tage ändert ?!
Zitat von @aqui:
Das ist richtig, der Timer geht nie auf 0 !
Die Kardinalsfrage ist nun ob der RA Intervall diesen Timer retriggert ? Laut RFC ist das ja der Fall.
Der test des Kollegen @1915348599 bestätigt ja auch genau das.
Ich sehe mir das nochmal genau an mit dem 200 Sek. Intervall.
Bedeutet ja bei den Defaults temp_valid_lft - INTEGER
valid lifetime (in seconds) for temporary addresses.
Default: 604800 (7 days)
temp_prefered_lft - INTEGER
Preferred lifetime (in seconds) for temporary addresses.
Default: 86400 (1 day)
dann auch das sich die Temporary Adresse dann immer nur alle 7 Tage ändert wenn man dieses Intervall nicht in der sysctl.conf anpasst ?!
Das ist richtig, der Timer geht nie auf 0 !
Die Kardinalsfrage ist nun ob der RA Intervall diesen Timer retriggert ? Laut RFC ist das ja der Fall.
Der test des Kollegen @1915348599 bestätigt ja auch genau das.
Ich sehe mir das nochmal genau an mit dem 200 Sek. Intervall.
Bedeutet ja bei den Defaults temp_valid_lft - INTEGER
valid lifetime (in seconds) for temporary addresses.
Default: 604800 (7 days)
temp_prefered_lft - INTEGER
Preferred lifetime (in seconds) for temporary addresses.
Default: 86400 (1 day)
dann auch das sich die Temporary Adresse dann immer nur alle 7 Tage ändert wenn man dieses Intervall nicht in der sysctl.conf anpasst ?!
nein, sie läuft nach 1 Tag ab, dann bekommt man eine neue. Die alte ist dann aber noch 6 Tage lang gültig.
sieht dann so aus:
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
inet6 2a01:XXX:XXX:c299:3186:c094:6c44:abfc/64 scope global temporary dynamic
valid_lft 296sec preferred_lft 116sec
inet6 2a01:XXX:XXX:c299:9831:2693:b48:bdb0/64 scope global temporary deprecated dynamic
valid_lft 296sec preferred_lft 0sec
inet6 2a01:XXX:XXX:c299:bc66:a0ce:a3a8:c5dc/64 scope global temporary deprecated dynamic
valid_lft 296sec preferred_lft 0sec
Kollege @1915348599 und der RFC haben Recht. Die RAs triggern in der Tat den preferred_lft Timer und auch den valid_lft Timer gleichzeitig.
Übrigens nicht nur für die Privacy Adresse sondern analog auch für die SLAAC Adresse.
Kommt ein RA wird der preferred_lft Timer auf 1800 zurückgesetzt.
Vor dem RA:
Eingehender RA:
Nach dem RA:
Genau 3,3 Minuten. Jetzt bleibt es nur noch spannend ob morgen um 17:30 Uhr dort eine andere Privacy Adresse steht ! 😉
Appropos: WO steht eigentlich genau das diese 24 Stunden Gültigkeit besitzt ?
Übrigens nicht nur für die Privacy Adresse sondern analog auch für die SLAAC Adresse.
Kommt ein RA wird der preferred_lft Timer auf 1800 zurückgesetzt.
Vor dem RA:
eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
inet6 2003:xx:xxx:6e0a:62a3:8ec:aad8:bf54/64 scope global temporary dynamic
valid_lft 14215sec preferred_lft 1615sec root@server:/home/# tcpdump -i eth1 "icmp6 && ip6[40] == 134"
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), snapshot length 262144 bytes
17:16:49.631551 IP6 fe80::5e71:dff:fe0c:15f4 > ip6-allnodes: ICMP6, router advertisement, length 64 eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
inet6 2003:xx:xxx:6e0a:62a3:8ec:aad8:bf54/64 scope global temporary dynamic
valid_lft 14399sec preferred_lft 1800sec Appropos: WO steht eigentlich genau das diese 24 Stunden Gültigkeit besitzt ?
Und ergänzend wie oben in meinem letzten Kommentar schon geschrieben kommt das Zurücksetzen des Zählers nur dann zustande wenn in den Client-Settings über sysctl die preferred lifetime größer ist als die des RAs.
Man sollte also die Lifetimes in den RAs etwas großzügiger wählen, der Client kann sie ja nach Bedarf selbst verwalten.
Man sollte also die Lifetimes in den RAs etwas großzügiger wählen, der Client kann sie ja nach Bedarf selbst verwalten.
Was wäre denn jetzt best Practise ? Das man diese in der sysctl immer kleiner als das RA Intervall setzt ? Hier also dann z.B. auf 199.
Zitat von @aqui:
Was wäre denn jetzt best Practise ? Das man diese immer kleiner als das RA Intervall setzt ? Hier also dann auf 199.
Die Lifetimes in den RAs etwas großzügiger wählen, der Client kann bei Bedarf ja selbst kleinere Intervalle nutzen.Was wäre denn jetzt best Practise ? Das man diese immer kleiner als das RA Intervall setzt ? Hier also dann auf 199.
Zitat von @aqui:
Kollege @1915348599 und der RFC haben Recht. Die RAs triggern in der Tat den preferred_lft Timer und auch den valid_lft Timer gleichzeitig.
Übrigens nicht nur für die Privacy Adresse sondern analog auch für die SLAAC Adresse.
Kommt ein RA wird der preferred_lft Timer auf 1800 zurückgesetzt.
Vor dem RA:
Eingehender RA:
Nach dem RA:
Genau 3,3 Minuten. Jetzt bleibt es nur noch spannend ob morgen um 17:30 Uhr dort eine andere Privacy Adresse steht ! 😉
Appropos: WO steht eigentlich genau das diese 24 Stunden Gültigkeit besitzt ?
Kollege @1915348599 und der RFC haben Recht. Die RAs triggern in der Tat den preferred_lft Timer und auch den valid_lft Timer gleichzeitig.
Übrigens nicht nur für die Privacy Adresse sondern analog auch für die SLAAC Adresse.
Kommt ein RA wird der preferred_lft Timer auf 1800 zurückgesetzt.
Vor dem RA:
eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
inet6 2003:xx:xxx:6e0a:62a3:8ec:aad8:bf54/64 scope global temporary dynamic
valid_lft 14215sec preferred_lft 1615sec root@server:/home/# tcpdump -i eth1 "icmp6 && ip6[40] == 134"
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), snapshot length 262144 bytes
17:16:49.631551 IP6 fe80::5e71:dff:fe0c:15f4 > ip6-allnodes: ICMP6, router advertisement, length 64 eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
inet6 2003:xx:xxx:6e0a:62a3:8ec:aad8:bf54/64 scope global temporary dynamic
valid_lft 14399sec preferred_lft 1800sec Appropos: WO steht eigentlich genau das diese 24 Stunden Gültigkeit besitzt ?
/proc/sys/net/ipv6/conf/enp2s0/temp_prefered_lft
Zitat von @1915348599:
Zitat von @aqui:
Was wäre denn jetzt best Practise ? Das man diese immer kleiner als das RA Intervall setzt ? Hier also dann auf 199.
Die Lifetimes in den RAs etwas großzügiger wählen, der Client kann bei Bedarf ja selbst kleinere Intervalle nutzen.Was wäre denn jetzt best Practise ? Das man diese immer kleiner als das RA Intervall setzt ? Hier also dann auf 199.
geht nur nicht so einfach, wenn der Provider von außen nur eine Livetime von 3600 vorgibt. Wenn jetzt sich wirklich mal der Prefix ändert, dauert das dann ewig bis alles wieder funktioniert.
Aus dem Grund übernehme ich die Lifetime die vom Provider übermittelt wird.
Zitat von @Marcus78:
Wenn jetzt sich wirklich mal der Prefix ändert, dauert das dann ewig bis alles wieder funktioniert.
Nein, kommt ein neuer Prefix wird dieser spätestens beim nächsten RA vom Client hinzugefügt, den der vergleicht den Prefix vom RA und seiner aktuellen Adresse, ändert sich das Prefix fügt dieser das Prefix hinzu.Wenn jetzt sich wirklich mal der Prefix ändert, dauert das dann ewig bis alles wieder funktioniert.
Zitat von @1915348599:
Zitat von @Marcus78:
Wenn jetzt sich wirklich mal der Prefix ändert, dauert das dann ewig bis alles wieder funktioniert.
Nein, kommt ein neuer Prefix wird dieser spätestens beim nächsten RA vom Client angepasst, den der vergleicht den Prefix vom RA und seiner aktuellen Adresse, ändert sich das Prefix passt auch dieser seine Adresse erneut an.Wenn jetzt sich wirklich mal der Prefix ändert, dauert das dann ewig bis alles wieder funktioniert.
Vermutung oder wissen? Das glaube ich nicht. Der Prefix wird hinzugefügt, aber der alte nicht gelöscht.
Mal schauen ob ich es nachstellen kann. ...
Zitat von @1915348599:
Zitat von @Marcus78:
Wenn jetzt sich wirklich mal der Prefix ändert, dauert das dann ewig bis alles wieder funktioniert.
Nein, kommt ein neuer Prefix wird dieser spätestens beim nächsten RA vom Client angepasst, den der vergleicht den Prefix vom RA und seiner aktuellen Adresse, ändert sich das Prefix passt auch dieser seine Adresse umgehend an.Wenn jetzt sich wirklich mal der Prefix ändert, dauert das dann ewig bis alles wieder funktioniert.
war ja zu erwarten - der alte Prefix bleibt erhalten
Vorher:
3: enp5s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
inet6 2a00:XXX:XXX:ef03:afe:90ac:b95f:f117/64 scope global temporary dynamic
valid_lft 3599sec preferred_lft 1799sec
inet6 2a00:XXX:XXX:ef03:b62e:99ff:fea9:5106/64 scope global dynamic mngtmpaddr
valid_lft 3599sec preferred_lft 1799sec
inet6 fe80::b62e:99ff:fea9:5106/64 scope link
valid_lft forever preferred_lft forever
nachher ( neuer Prefix verteilt )
3: enp5s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
inet6 2a00:XXX:XXX:ef05:52d2:9d99:16f9:2a4c/64 scope global temporary dynamic
valid_lft 3600sec preferred_lft 1800sec
inet6 2a00:XXX:XXX:ef05:b62e:99ff:fea9:5106/64 scope global dynamic mngtmpaddr
valid_lft 3600sec preferred_lft 1800sec
inet6 2a00:XXX:XXX:ef03:afe:90ac:b95f:f117/64 scope global temporary dynamic
valid_lft 3597sec preferred_lft 1797sec
inet6 2a00:XXX:XXX:ef03:b62e:99ff:fea9:5106/64 scope global dynamic mngtmpaddr
valid_lft 3597sec preferred_lft 1797sec
inet6 fe80::b62e:99ff:fea9:5106/64 scope link
valid_lft forever preferred_lft forever
Damit sind jetzt eine Zeitlang beide Prefix gültig.
Das meinte ich damit, war nicht eindeutig geschrieben sorry.
Zitat von @1915348599:
Das meinte ich damit, war nicht eindeutig geschrieben sorry.
Das meinte ich damit, war nicht eindeutig geschrieben sorry.
ja, damit ist doch aber klar das man die Lifetime nicht einfach so verlängern sollte. Man müsste sonst den alten Prefix mit 0 Lifetime verteilen und hoffen das alle Clients ihn als ungültig aufnehmen.
Einfach so den neue Prefix verteilen reicht dann nicht aus.
Zitat von @Marcus78:
ja, damit ist doch aber klar das man die Lifetime nicht einfach so verlängern sollte.
Kommt wie immer auf den Einsatzort an.ja, damit ist doch aber klar das man die Lifetime nicht einfach so verlängern sollte.
Man müsste sonst den alten Prefix mit 0 Lifetime verteilen und hoffen das alle Clients ihn als ungültig aufnehmen.
Nicht zwingend, Linux nimmt bei mehreren Prefixen auf dem selben Interface per Default die zuletzt generierte Adresse für ausgehende neue Verbindungen sollte es mehrere mit gleichen Eigenschaften geben (temporary/global).1