[gelöst] Lebenszeit lokaler IPv6 (fd00::/16)

[bluestar]

Wo kommt denn das dritte Netz her?

2000::/3

Das ist deine Default-Route ins Internet

[TomL]

Wo kommt denn das dritte Netz her?

2000::/3

Das ist deine Default-Route ins Internet

Nein, ist es nicht. Jeder Client hat eine öffentliche IPv6 aus diesem Netz und ist natürlich damit selber direkt im Internet als Client unterwegs, ohne NAT, Netz und doppelten Boden. Ich denke, das Problem ist gelöst. Danke für Deinen Hinweis über die Ursache.... das macht es mir leichter, jetzt eine Entscheidung zu treffen. Ich setz das mal auf gelöst.

[mat6937]

Das musst du deine Fritzbox fragen

Das muss ich nicht, denn ich weiß es ja (... von meiner FritzBox). Der TE muss evtl. seine FritzBox fragen oder die RA von der FRitzBox sniffen (oder gleichwertig).

[bluestar]

2000::/3

Das ist deine Default-Route ins Internet

Nein, ist es nicht. Jeder Client hat eine öffentliche IPv6 aus diesem Netz und ist natürlich damit selber direkt im Internet als Client unterwegs, ohne NAT, Netz und doppelten Boden.

Die von dir genannte Netz-Adresse ist KEINE, du du von deinem Provider zugewiesen bekommst. Du bekommst ein /48 oder kleiner vom Provider, ergo kannst du 2000::/3 nicht frei nutzen, sondern nur dein dir zugewiesenes Subnetz.

Du hast dann logischerweise je Gerät mind. 2 IPv6-Adressen (einmal privater ULA und einmal globaler ULA), ggfs. kommen durch Privacy-Ext noch weitere temporäre Adressen hinzu.

[TomL]

Mannoman, das weiss ich doch... 2000::/3 sagt doch nur aus, dass das auf den Clients eine Addresse aus einem von der IANA vorgebenen Bereich für Global-Unicast-Adressen ist. Mein ISP-Prefix ist ein /56'er Netz natürlich ebenfalls aus dem Bereich 2000::/3... und selbstverständlich bekomme ich diesen Prefix von meinem DSL-Provicer zugewiesen. Mit der hier bestehenden Site-ID/64 ist das dann das dritte Netz. Wir sollten das jetzt wirklich beenden.

Und ich habe auch nicht 1 GUA, sondern wegen Privacy Extensions immer zwei... und wenn ich wollte, könnte ich fünf, sechs, oder zwanzig pro NIC anlegen.

https://www.iana.org/assignments/ipv6-a ... pace.xhtml

[bluestar]

Und dein drittes IPv6-Netz sehe ich nicht als notwenig an, du brauchst nur zwei v6-Netze

[TomL]

Und dein drittes IPv6-Netz sehe ich nicht als notwenig an, du brauchst nur zwei v6-Netze

Ja, wenn man trotz IPv6 sowas dummes wie NAT machen will... was man bei IPv6 gsd nicht mehr braucht.

[bluestar]

Ja, wenn man trotz IPv6 sowas dummes wie NAT machen will... was man bei IPv6 gsd nicht mehr braucht.

Jetzt zähl doch mal bitte die drei IPv6-Netze auf von denen du hier sprichst.

[TomL]

Ich habe nur von 3 Netzen gesprochen... ich weiss nicht, wie Du auf 3 mal IPv6 kommst.

Das sind:
- IPv4/24 lokal (erfordert NAT)
- fc00::/7 lokal (ULA, erfordert ebenfalls NAT (nach meinem Kenntnisstand wird die nicht ins Internet geroutet))
- 2000::/3 öffentlich (GUA)

Und das lokale IPv6 will ich nicht. Ich brauche das nur an einer Stelle, zwischen zwei Geräten, aber eben nicht für alle Clients, also werde ich das auch nicht via RA verteilen. Wenn alle Stricke reissen, werde ich einfach testen, ob ich stattdessen einfach LLA verwenden kann... denn die sind eh obligatorisch. Ich denke, hier sind keine weiteren Erkenntnisse zu gewinnen... wir sollten das jetzt beenden.

[mat6937]

Das heisst, ich habe das so eingestellt, dass ULA's nicht automatisch zugewiesen werden. Es handelt sich um eine FB 7490.

Hast Du den default-ULA-Präfix fd00:0.0.0/64 deiner FritzBox geändert? Wenn nicht, dann wird es auch keine Kollision mit deinem manuell konfigurierten ULA-Präfix fd00:172:10:100/64 (oder gleichwertig) geben.
M. E. ist das Problem, dass das Interface down geht, in Folge der täglichen Zwangstrennung.

[TomL]

Hast Du den default-ULA-Präfix fd00:0.0.0/64 deiner FritzBox geändert? Wenn nicht, dann wird es auch keine Kollision mit deinem manuell konfigurierten ULA-Präfix fd00:172:10:100/64 (oder gleichwertig) geben.

Ja, ich habe den geändert, das passt auch alles zueinander. Der Prefix/64 ist optisch (!) passend zu meinem IPv4/24-Netz. Ich habe nur eingestellt, dass von der Fritte kein lokales Netz via RA 'verteilt' wird, wenn ein 2000/3'er verfügbar ist. Ich brauch diese ULA auch nur an dieser einen Stelle zu dieser einen VM, weil ich den DNS der Fritte global verbogen habe, was natürlich nur auf eine Static-IP sinnvoll ist.... Du wirst Dir vermutlich denken können, warum.

M. E. ist das Problem, dass das Interface down geht, in Folge der täglichen Zwangstrennung.

Ja, das denke ich auch, dass die Zwangstrennung (oder vermutlich eher die Aktivierung von SLAAC) dafür verantwortlich ist. Das Interface geht imho aber nicht down, die alten IP könnten ja noch offene Verbindungen haben. Die alten IPs werden deshalb nur auf deprecated gestellt und können keine neuen Verbindungen mehr aufbauen. Und sobald alte und noch bestehende Verbindungen geschlossen sind, werden die wohl einfach stillschweigend entfernt. Und mit der Aktivierung von SLAAC erfährt die ULA anscheinend eine Einstellungsänderung, von forever auf preferred time... denn die lebt ja nach der Trennung auch noch.... und zwar ab jetzt nur noch solange, bis deren eigene preferred-Sekunden abgelaufen sind.... dann isses auch weg. Ich betrachte das mittlerweile fast als Kollateralschaden durch die Zwangstrennung

Und morgen prüfe ich Deine noch offene Frage, welche Lifetime im RA enthalten ist... sofern ich das da überhaupt herauslesen kann.... mal abwarten.

[TomL]

Welche "valid_time" und "preferred_time" wird via RA für den "Prefix fd00::/64" mitgeteilt?

Gar keinen... weil ich ja keinen lokalen fd00-Prefix verteile. Ich habe das ja -wie schon erwähnt- im Router deaktiviert. Das ist mir jetzt gerade auch erst bewusst geworden, als ich mir das RA-Paket angesehen habe... das ist natürlich nur der Prefix für das Netz 2000::/3 enthalten. Und für diesen Prefix sind es exakt die Werte, die auch via 'ip a' berichtet werden, 7200 und 3600. Also kann man sagen, alles korrekt. Ich würde jetzt davon ausgehen, dass die Werte die gleichen bleiben, wenn ich fd00:: verteilen würde.

Dummerweise ist mein fd00-Lifetime-Test in der Testsystem-VM gestorben, also die Prüfung der Abhängigkeit von der Zwangstrennung. Sowas beklopptes, ich habe unbemerkt der VM die IP meines Druckers verpasst.... weil der bei der Kontrolle gerade nicht in der Router-Liste mit oben stand und ich schlichtweg nicht meh dran gedacht habe. Na ja, und heute morgen gingen weder Drucker noch VM via IPv4. Reichlich stümperhaft.... *grrr*

[TomL]

Moin

Noch'n Nachtrag zum Thema.... die Adresse bleibt bestehen, wenn die PE deaktiviert sind. Die Zwangstrennung führt allerdings dazu, dass zur manuell eingetragenen statischen fd00:: (lft=forever) noch (unerwünscht und auch unnötig) eine weitere auf der MAC basierend (lft=mit RA-Limits) erzeugt wird. Irgendwie ist das Handling resp. das Geschehen unbefriedigend....

[TomL]

Im Zusammenhang mit dem zweiten zu meinem (jetzt gelösten) Problem gehörenden Thread gibts jetzt nach einigen Tagen Beobachtung abschließende Erkenntnisse.

• Eine Macvtap-Bridge ist (bei Verzicht auf die üblichen Netzwerk-Programme wie NWM, ifup, networkd, DHCPD) deutlich einfacher einzurichten und funktioniert oberflächlich betrachtet sofort. In reinen IPv4-Netzen wäre das wohl meine erste Wahl.
• Das Verhalten bei gleicher IPv6-Konfiguration ist allerdings unterschiedlich zwischen Macvtap-Device im Bridge-Mode und einer 'traditionellen' Bridge.
• Ganz offensichtlich gibt es für einen reibungslosen Netzbetrieb durchaus relevante konzeptionelle Unterschiede hinsichtlich IPv6 zwischen diesen 2 Devices. Ich vermeide hier von Bugs zu reden, weil ich nicht glaube, dass das Bugs sind, sondern konzeptionelle Ursachen hat.

Das aktuelle System-Verhalten in den KVM-VM's mit einer normalen Bridge ist jetzt auch mit IPv6 Netzwerk-Funktionalität-Erwartungsgemäß:
1. SLAAC und PE funktionieren nach der täglichen Zwangstrennung fehlerfrei
2. Die jeweilig gültige PE-Adresse wird immer bevorzugt verwendet
3. Die einmalig beim Boot manuell eingestellte ULA (lt forever) lebt jetzt wirklich unendlich

4. Ein wenig merkwürdig ist, dass nach der Zwangstrennung (und dem folgenden RA) via SLAAC zur bestehenden ULA zwei weitere ULA's (MAC-Based + temp) erzeugt werden, die aber beide nach Ablauf der initialen Lifetime wieder entfernt werden. Das ist jetzt aber nix, was mich als Problem beunruhigt, das stört mich einfach nicht.

Vielleicht hilft das dem einen oder anderen bei der Entscheidung des Bridge-Devices.....