DHCPv6-Prefix-Delegation über VPN-Verbindung

[SunSeb]

Hallo,

ich benötige Hilfe bei folgendem Szenario.

Eine Zentrale ist über VPN mit der Filiale verbunden. Die Zentrale erhält vom Provider ein 48er Prefix. Einen 56er Teil davon würde ich gerne über die VPN-Verbinding an ein Netz in der Filiale delegieren.

Der DHCPv6-Client in der Filiale schickt auch ein Solicit an die ff02::1:2 auf der VPN-Verbindung. Der Multicast kommt jedoch am DHCPv6-Server der Zentrale nicht an. Die Konfiguration des DHCP-Relay-Agenten in der Filiale für eine VPN-Schnittstelle war leider auch nicht erfolgreich.

Ich bin für Hinweise dankbar.

Vielen Dank und schönen Tag,
Sebastian

[backslash]

Hi Sunbseb

kurz und knapp: das wird nicht funktionieren... zunächst einmal ist ff02:: eine linklokale Multicastadresse (https://en.wikipedia.org/wiki/IPv6_address) und kann/darf nicht geroutet werden.

Für IPv6 im VPN mußt du sog. ULAs verwenden (fc00::/7, siehe auch https://en.wikipedia.org/wiki/Unique_local_address). Nur so ist es möglich Adressen im VPN konstant zu halten um überhaupt Einträge in der Routing-Tabelle machen zu können
Da es selbst heuet noch IPv6-Stacks gibt, die mit ULAs nicht sauber umgehen können, solltest du in Richtung Internet ein NPTv6 verwenden (um die ULAs in öffentliche IP-Adressen zu mappen) - und zwar an allen Standorten

Gruß
Backslash

[Frühstücksdirektor]

Damit Multicast-Pakete überhaupt über VPN übertragen werden können, muss die VPN-Regel "Any-to-Any" sein, d.h. "::/0 <=> ::/0" sein.
Der DHCPv6-Client oder RA kann schon grundsätzlich auf einem VPN-Tunnel laufen (mit Any-to-Any Rules). Ob dein Konzept funktioniert, ist aber was Anderes...

[SunSeb]

Hallo,

vielen Dank für die Antwort(en).

@backslash: Die Filiale lief bisher sogar sauber und stabil mit ULAs. Nur da diese mittlerweile so verteufelt werden, wollte ich mal ein Szenario mit GUAs versuchen. Könnte man den DHCPv6-Relay-Agenten irgendwann mal dahin erweitern, dass dieser auch für Multicast-Adressen auf einer VPN-Verbindung einsetzbar ist? Ziel könnte ja dann die ULA des Routers in der Zentrale sein

@Frühstücksdirektor: Das habe ich noch nicht versucht. Ich werde das mal konfigurieren und dann Rückmeldung geben. Danke.

Sebasgtian

[backslash]

Hi SunSeb,

Die Filiale lief bisher sogar sauber und stabil mit ULAs. Nur da diese mittlerweile so verteufelt werden, wollte ich mal ein Szenario mit GUAs versuchen.

und wie willst du den sich "ständig" wechselnden Präfix in der Routing-Tabelle unterbringen um die Filialen zu erreichen? In der Routing-Tabelle gibt es keine Möglichkeit delegierte Präfixe als Zielnetz einzugeben. Das funktioniert mit LAN-Interfaces, weil die sich selbst dort eintragen...

Und vor allem: wie willst du in einem Netz mit sich ständig wechslenden Präfixen Server betreiben? Das mag funktionieren, wenn die Server sich nach einem Präfix-Wechsel beim DHCP-Server melden und dann auch noch ihren Hostnamen übermitteln - nur passiert das bei IPv6 eher selten

verteufelt hin verteufelt her - ohne ULAs wird das wohl nicht funktionieren...

Gruß
Backslash

[SunSeb]

Hallo backslash,

sorry - das Prefix in der Zentrale ist ein festes 48er Prefix - das in der Filiale ist dynamisch. Ich werde das ganze wohl mal statisch einrichten. Mein erster Gedanke ging an die Delegation eines Teiles dieses festen Prefixes und Ausleitung des Filialtraffics über die Zentrale...

Aber vielen Dank und entschuldige das Missverständnis

Gruss,
Sebastian

[backslash]

Hi SunSeb,

zum Thema verteufelte ULAs ist noch zu sagen: Eigentlich wären sie kein Problem, aber leider halten sich viele IP-Stack-Entwickler nicht an die RFCs und setzen ULAs mit GUAs gleich, was am Ende zu Problemen führt. Dabei sind die RFCs eindeutiug und legen genau fest, wann ein Host seine GUA, ULA bzw. LLA als Absenderadresse in ein IP-Paket setzen soll - nämlich genau dann, wenn die Zieladresse eine GUA, ULA bzw. LLA ist. Das ist eigentlich eine 1:1 Zuordnung der Adreßtypen...

Da die IP-Stacks aber oft zu simplel gestrickt sind, scheitern sie daran und nehmen im schlimmsten Fall beim Zugriff auf das Internet die ULA als Absenderadresse, wodurch keine Kommnikation möglich ist. Noch schlimmer wäre es, wenn beim Zugriff auf das VPN als Absenderadresse die GUA genommen wird, denn dann laufen die Antworten unverschlüsselt durchs Internet...

Aufgrund dieser Unzulänglichkeiten wird die Verwendung von ULAs auch gleich NPTv6 ins Spiel gebracht (damit die Hosts nur eine "global anmutende" Adresse haben) und das Ganze verteufelt...

sorry - das Prefix in der Zentrale ist ein festes 48er Prefix - das in der Filiale ist dynamisch. Ich werde das ganze wohl mal statisch einrichten.

Achtung: Wenn du das statisch konfigurierst, dann hast du in den Filialen zwei wirklich globale Prefixe und du rennst erst recht in das Problem, daß die Source-Address-Selection sauber arbeiten muß... Wenn die das schon mit ULAs nicht hinbekommt, dann wird sie in diesem Fall erst recht scheitern...

Gruß
Backslash

[SunSeb]

Hallo Frühstücksdirektor,

iIch habe versucht, die Variante umzusetzen - leider ohne Erfolg. Aber trotzdem danke für den Hinweis.

Gruss
Sebastian

[SunSeb]

Hallo backslash,

vielen Dank für die interessanten Hinweise.

Gruss
Sebastian