IPv6 LAN: SLAAC und "deprecated" Adressen

[ghandmann]

Hallo Community 🙂

Seit 2-3 Wochen beobachte ich, das an meinen Linux-Maschinen die IPv6 Autokonfiguration (aka SLAAC) irgendwie aus dem Ruder läuft. Nach 1-2 Stunden Betrieb sammelt das Interface 2 IPv6 Adressen. Eine davon wird dann regelmäßg als "deprecated" geflaggt und wieder de-flaggt. Wenn die Adresse aus dem deprecated-State rauswechselt, tut sie das allerdings nur für wenige Sekunden, denn die "preffered lifetime" wird lediglich auf 1-2 Sekunden gesetzt, danach ist die Adresse wieder deprecated. Was - soweit ich das überblicke - den Specs entspricht.

Während sich dieses Schauspiel immer wieder auf der einen Adresse wiederholt, ist die andere IPv6 Adresse ordentlich konfiguriert und hat auch eine lange "preffered lifetime" (>20.000 Sekunden).

Dieses flappen des "deprecated" flag scheint dann dazu zu führen, das ich ständig "network changed" events sehe und Verbindungen immer wieder mitten drin einfach abbrechen.

Hat da jemand eine Idee, woran das liegen könnte? Fehlkonfiguration bei mir? Bei Vodafone? Im von Vodafone gestellten Router?

Ich nutze die Kabelbox von Vodafone in Version 01.04.046.15.EURO.SIP

[henky2]

Ich beobachte seit ein paar Tagen etwas Ähnliches, wir nutzen allerdings die Vodafone Station mit FW 3.0.41-IMS-KDG.

Wenn ich mich verbinde, bekomme ich zwei Adressen auf dem Interface:

4: wlp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 2a02:8108:1bc0:1fc4:4096:922:aab:c8a4/128 scope global dynamic noprefixroute 
       valid_lft 604793sec preferred_lft 604793sec
    inet6 2a02:8108:1bc0:1fc4:9508:375e:dc15:a588/64 scope global dynamic noprefixroute 
       valid_lft 300sec preferred_lft 300sec

So bekomme ich  allerdings keinerlei IPv6-Verbindung in Richtung Internet aufgebaut:

PING google.com(bc-in-f101.1e100.net (2607:f8b0:4004:c07::65)) 56 data bytes
^C
--- google.com ping statistics ---
13 packets transmitted, 0 received, 100% packet loss, time 12299ms

Erst wenn ich die Adresse mit der /128er Maske manuell lösche, funktioniert es wieder:

$ sudo ip -6 addr del 2a02:8108:1bc0:1fc4:4096:922:aab:c8a4/128 dev wlp1s0
$ ping google.com
PING google.com(bc-in-f100.1e100.net (2607:f8b0:4004:c07::64)) 56 data bytes
64 bytes from bc-in-f100.1e100.net (2607:f8b0:4004:c07::64): icmp_seq=1 ttl=104 time=96.7 ms
64 bytes from bc-in-f100.1e100.net (2607:f8b0:4004:c07::64): icmp_seq=2 ttl=104 time=99.1 ms
64 bytes from bc-in-f100.1e100.net (2607:f8b0:4004:c07::64): icmp_seq=3 ttl=104 time=104 ms
64 bytes from bc-in-f100.1e100.net (2607:f8b0:4004:c07::64): icmp_seq=4 ttl=104 time=99.6 ms
64 bytes from bc-in-f100.1e100.net (2607:f8b0:4004:c07::64): icmp_seq=5 ttl=104 time=96.6 ms
^C
--- google.com ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4003ms
rtt min/avg/max/mdev = 96.590/99.164/103.816/2.636 ms

Ich bin leider komplett ratlos, wo dieses Verhalten plötzlich herkommt und wie es sich wieder abstellen lässt... 😞

[ghandmann]

Hi henky2,

wenigstens bin ich dann schonmal nicht alleine mit diesem Verhalten. 🙂

Das "deprecated" flag entdecke ich i.d.R. auch nur, wenn ich mit watch  länger auf die Ausgabe von ip addr show $interface  schaue:

watch -n 2 ip addr show $interface 

[ghandmann]

Evtl. hilft das ja bei der Diagnose: So sah der Zustand meine IPv6 Adressen gerade aus:

2: enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether b0:25:aa:3f:16:fb brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.185/24 brd 192.168.0.255 scope global dynamic noprefixroute enp2s0
       valid_lft 594983sec preferred_lft 594983sec
    inet6 2a02:1234:1234:1234:fda8:d72d:a978:84e/64 scope global temporary deprecated dynamic 
       valid_lft 6806sec preferred_lft 0sec
    inet6 2a02:1234:1234:1234:995b:d020:4b4a:a8ee/64 scope global deprecated dynamic mngtmpaddr noprefixroute 
       valid_lft 6806sec preferred_lft 0sec
    inet6 2a02:1234:1234:1234::661/128 scope global dynamic noprefixroute 
       valid_lft 33385sec preferred_lft 33385sec
    inet6 fe80::d9ec:6b6c:a059:333d/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever

Hier hatte ich jetzt plötzlich sogar 3 IPv6 Adressen (ich habe teile meines Prefixes mit 1234 ersetzt). Die /64 Adressen sind "falsch". Die /128 Adresse meine "normale" im Sinne von die habe ich schon den ganzen Tag.

Bei den /64 Adressen beginnt jetzt das "deprecated" flag zu flappen und die "preferred_lft" zwischen 0 und 1 sekunden zu wechseln:

2: enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether b0:25:aa:3f:16:fb brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.185/24 brd 192.168.0.255 scope global dynamic noprefixroute enp2s0
       valid_lft 594930sec preferred_lft 594930sec
    inet6 2a02:1234:1234:1234:fda8:d72d:a978:84e/64 scope global temporary dynamic 
       valid_lft 6753sec preferred_lft 1sec
    inet6 2a02:1234:1234:1234:995b:d020:4b4a:a8ee/64 scope global dynamic mngtmpaddr noprefixroute 
       valid_lft 6753sec preferred_lft 1sec
    inet6 2a02:1234:1234:1234::661/128 scope global dynamic noprefixroute 
       valid_lft 33332sec preferred_lft 33332sec
    inet6 fe80::d9ec:6b6c:a059:333d/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever

Normales surfen oder sonstige Netzwerkkommunikation ist jetzt super zäh, weil ständig irgendwelche routen kommen und gehen. Die Browser quittiere das dann mit "ERR_NETWORK_CHANGED". Die Verbindung dann einmal neu herstellen (Stecker rein-raus, oder via NetworkManager verbindung trennen) behebt das Problem dann, manchmal für Stunden oder nur Minuten.

[Cable-User]

Hallo @ghandmann ,

ich kann durch den zeitlichen Verlauf nur mutmaßen, dass es mit Umstellungen am Netz in ganz BW zu tun hat.

Siehe auch IPv6 Präfix wurde von /56 auf /59 reduziert 

Da haben wohl ein paar VF-Mitarbeiter unnötig am Netz rumgefroscht. Vorher lief es im IPv6-Bereich einwandfrei.

[Robert251]

Nur um hier mal ein Update zu bringen, falls jemand ein ähnliches Problem hat:

die /128 Adressen werden vom Router per DHCPv6 vergeben und sind die Adresse die normalerweise für outbound-traffic genutzt wird.

Die /64 Adressen werden per SLAAC vergeben und solange die /128 aktiv ist, sind sie zwar erreichbar werden aber nicht präferiert.

per se hätte also das Erreichbarkeits-Problem nicht mit dem flappen der Adressen zusammen hängen dürfen, zumal es im IPv6 Standard ja vorgesehen ist, dass Adressen schnell getauscht werden können, ohne Down-State. 

Da ich gestern ebenfalls Probleme bei mir hatte und die Vodafone-station neustarten musste und es danach ging, vermute ich eher das Problem bei der Station. Würde mich wundern wenn ein Umstellen der Präfixe von VF (wtf ich hab nur ein /62) hier etwas ändert, weil selbst ein Wechsel auf Präfix mit anderer Länge (56 auf 62 z.B.) läuft bei meinem Debian ohne Disconnect ab.

[user-99911]

Hallo,

seit mehreren Wochen habe ich das gleiche Problem bei meinem lokalen Ubuntu Rechner.

Das surfen resultiert immer wieder aus Verbindungsabbrüchen mit einem "ERR_NETWORK_CHANGED".

Sobald IPv6 deaktiviert wird scheint es wieder zu laufen.

Hat jemand hierfür schon eine Lösung außer, dass man IPv6 nicht nutzen kann?

Weiß jemand was Vodafone dazu sagt oder ob bereits daran gearbeitet wird, damit man IPv6 endlich mal fehlerfrei nutzen kann?

[GerdG2]

Bei mir tritt genau das Problem ebenfalls auf und lässt sich durch den Workaround, IPv6 zu sperren, beheben.

Aber das ist doch keine Lösung...

siehe auch https://forum.vodafone.de/t5/Störungen-im-Kabel-Netz/Ständig-ERR-NETWORK-CHANGED-nach-Router-wechsel...

[ghandmann · Accepted solution]

Mal noch ein kurzes Follow up: Ich habe mittlerweile die Vodafone Station durch eine Fritz!Box 6690 ersetzt. Deprecated Adresses bekomme ich immer noch, aber die preferred_lifetime läuft einfach auf 0 sekunden runter und bleibt dann da. Was auch mit den IPv6 specs soweit im Einklang ist, wie ich das verstehe.

Daher schiebe ich das ganze Probleme auf den Hausrouter von Vodafone. 🙂

[Kurtler]

Da der Thread als gelöst markiert wurde, mache ich hier dann ein Schloss dran.

Gruß Kurt