IPV6 Konfiguration für rein interne Kommunikation zwischen zwei VLANs

  • Könnte mir bitte mal jemand für einen Noob in Punkto IPV6 aufzeigen, wie ich in zwei von mehreren VLANs ein Setup für IPV6 konfiguriere.

    Einziges Ziel ist, dass die beiden VLANs vollumfänglich über IPV6 miteinander kommunizieren können.

    Fragen, die mir dabei in den Sinn kommen:

    Reicht es, einzig in den beiden VLANs ein IPV6 Setup vorzunehmen und überall sonst (andere VLANs, WAN etc.) zu disablen?

    IPV6 statisch? Welche IPV6 Präfixe (bitte Beispiel) trage ich dann ein?

    SLAAC oder DHCPV6?

    Falls SLAAC: müssen das alle Switche im Netz (die sind in einem anderen Infrastruktur VLAN ohne IPV6-Bedarf) unterstützen?

    ...

  • Reicht es, einzig in den beiden VLANs ein IPV6 Setup vorzunehmen und überall sonst (andere VLANs, WAN etc.) zu disablen?

    Wenn Du möchtest, dass Geräte aus VLAN A und B miteinander über IPv6 sprechen, warum willst Du dann IPv6 für VLAN C abschalten? Was in C so los ist und ob es überhaupt ein C gibt, interessiert ein Gerät aus A nicht, wenn es mit B kommuniziert.

    Am WAN disablen... Grundsätzlich keine so gut Idee. Das Konzept der Präfixe hast Du ja offenbar schon mal gelesen und das Standardprinzip bei Präfixen ist, dass diese uns vom ISP geliefert werden, damit wir global eindeutige Adressen damit bilden können. Dies setzt dann voraus, dass wir IPv6 am WAN korrekt konfigurieren und unser ISP IPv6 unterstützt. Es gibt leider bis heute einige Provider, die das nicht auf die Kette bekommen (schönen Gruß an die "Vereinigte Stadtwerke"...).

    Natürlich ist IPv6-Konnektivität nicht zwangsweise an eine Internetverbindung gekoppelt, man kann auch mit Link Local-Adressen reden, die sich jedes Gerät selbst gibt, sobald IPv6 "an" ist. Diese Adressen erkennt man am "fe80" im ersten Block.

    Allerdings werden Link Local-Adressen nicht geroutet, funktionieren also nicht über VLAN-Grenzen hinweg. Letzteres ist mit ULAs möglich, allerdings werden diese so weit ich es sehe von Unifi noch nicht wirklich schön unterstützt. Fritzboxen machen an dieser Stelle einen besseren Job, da kann man sich das mal ansehen.

    Man könnte ganz simpel jedem Gerät eine IPv6-Adresse eintragen, dafür würde man den ULA-Adressraum fd00::/8 benutzen. Fängt eine Adresse also mit "fd00:" an, so kannst Du eindeutig erkennen, dass dies keine GUA (Globally Unique Adress) ist, also nicht von einem ISP stammt.

    Unter anderem weil IPv6-Adressen kompliziert, lang und schlecht lesbar sind, ist aber eines der wichtigsten Prinzipien die Automatisierung. Du willst grundsätzlich keine Adressen mehr per Hand vergeben, darum sollen sich Router/DHCP-Server kümmern. Dies ist auch ein Grund, warum sich viele altgediente Admins bis heute vor IPv6 fürchten, denn wenn man bisher noch jedes Bit in seinem Netzwerk persönlich gekannt hat, so wird dies mit IPv6 doch sehr unbequem.

    Zusätzlich sollte man sich tunlichst um ein funktionierendes DNS bemühen, denn mit Hostnames operiert es sich doch deutlich leichter als mit v6-Adressen.


    SLAAC oder DHCPV6?

    Geht prinzipiell beides. Man sollte aber wissen, dass z.B. Android aus politischen Gründen kein DHCPv6 unterstützt, in sofern ist SLAAC der kompatiblere Mechanismus.


    Falls SLAAC: müssen das alle Switche im Netz (die sind in einem anderen Infrastruktur VLAN ohne IPV6-Bedarf) unterstützen?

    Mit Switches hat das alles nicht zu tun. Bei SLAAC bekommen die Hosts von ihrem Router einen Präfix und bilden sich damit selbst eine Adresse. Bei DHCPv6 werden die Hosts vom DHCP-Server mit "ganzen" Adressen versorgt, dieser DHCP-Server wird in den seltensten Fällen ein Switch sein.

    Am Ende: Viele Geräte werden von sich aus IPv6 benutzen, wenn Du es ihnen bereitstellst. Windows priorisiert v6 über v4 seit Vista(!!). Falls es irgendwo hakt, und ein Rechner doch lieber über v4 kommuniziert, kann man oft mit manuellem Eingriff in die Schnittstellenmetrik nachhelfen.

  • Networker:

    Erstmal danke für deine ausfühlrichen Erläuterungen.

    Quote


    Wenn Du möchtest, dass Geräte aus VLAN A und B miteinander über IPv6 sprechen, warum willst Du dann IPv6 für VLAN C abschalten? Was in C so los ist und ob es überhaupt ein C gibt, interessiert ein Gerät aus A nicht, wenn es mit B kommuniziert.

    Ja, das ist mir klar. Der Kern des Problems ist dieser Thread.

    Aktueller Stand in Kürze zusammengefasst:

    Die Matter Bridge hängt in VLAN A und muss per IPV6 mit VLAN B und C kommunizieren.

    Das habe ich per Workaround hinbekommen, indem ich dem Server mit der Matter Bridge zwei zusätzliche virtuelle NICs eingerichtet habe sodass die Bridge mit den VLANs B und C per Link-Local-IP kommunizieren kann.

    Dieses Setup läuft stabil und ist im Produktivbetrieb.

    Den möchte ich erst mal nicht stören und habe deshalb im Netz eine Testumgebung geschaffen mit VLAN X (Matter Bridge) und Y (Matter HUb). Dort versuche ich nun die VLAN übergreifende Kommunikation mit IPV6 auf die Beine zu stellen ohne am restlichen (produktiven) Netz herumzukonfigurieren.

    Die Erkenntnisse daraus werden entweder mir helfen, IPV6 besser zu verstehen oder dem Entwickler der Matter Bridge (ist noch im Beta-Stadium) helfen, mögliche Bugs oder fehlende Features zu identifizieren.

    Deshalb möchte ich ein Setup erreichen, das die IPV6-Kommunikation in und zwischen diesen beiden Test-VLANs vollumfänglich unterstützt. Erst bei Erfolg würde ich das dann auf die produktiven Teile übertragen.

    Edited once, last by AlterSack (March 2, 2025 at 12:20 PM).

  • Auf Basis der hier geposteten detaillierten Anleitungen

    Content embedded from external sources will not be displayed without your consent.

    habe ich mich nochmal intensiv selbst mit der Thematik befasst und folgendes Setup erfolgreich zum Laufen gebracht:

    Ich habe in den beiden Test-VLANs folgende IPV6 Konfig vorgenommen:

    - Interface Type Static.

    - VLAN 10: fd00:0:0:a::/64

    - VLAN 11: fd00:0:0:b::/64

    - DHCPV6 (war versehentlich von vorigen Versuchen eingestellt

    Content embedded from external sources will not be displayed without your consent.

    )

    - Allow SLAAC

    Mein im anderen Thread beschriebenes Problem ist damit vermutlich gelöst. Ich muss es noch auf die produktiven VLANs transferieren und im nächsten Schritt mit Prefix Delegation testen.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!