8
DHCPv6 + RA nur für Gateway verteilung?
Hallo zusammen,
wir haben bei uns im Netz für die Server IPv4 und IPv6 (statisch konfiguriert) im Einsatz. Klappt soweit wunderbar.
Es sollen nun auch bei allen Clients IPv6 Adressen verteilt werden. Dazu habe ich Windows DHCP Server mit der Verteilung der Adressen + DNS-Server Adressen begonnen. Funktioniert so weit.
Was leider nicht möglich ist, die zuweisung von Gateway und Subnetz.
Auf einem unserer Layer 3 Switche, der auch als Router eingesetzt wird, habe ich das senden von RA aktiviert.
Das funktioniert zwar auch, allerdings sehe ich dann im Client das dieser noch zwei weitere FD... IPv6 Adresse bekommen hat und als Gateway wird die FE... IPv6 Adresse des Routers verwendet statt der FD... Adresse.
Frage(n),
ist das ein Problem wenn der Client mehrere IPv6 Adressen hat?
Ist es möglich den Router so zu konfigurieren das nur seine IPv6 Adresse als Gateway versendet wird?
Switch: PowerConnect DNS4128T
Gruß
Xearo
wir haben bei uns im Netz für die Server IPv4 und IPv6 (statisch konfiguriert) im Einsatz. Klappt soweit wunderbar.
Es sollen nun auch bei allen Clients IPv6 Adressen verteilt werden. Dazu habe ich Windows DHCP Server mit der Verteilung der Adressen + DNS-Server Adressen begonnen. Funktioniert so weit.
Was leider nicht möglich ist, die zuweisung von Gateway und Subnetz.
Auf einem unserer Layer 3 Switche, der auch als Router eingesetzt wird, habe ich das senden von RA aktiviert.
Das funktioniert zwar auch, allerdings sehe ich dann im Client das dieser noch zwei weitere FD... IPv6 Adresse bekommen hat und als Gateway wird die FE... IPv6 Adresse des Routers verwendet statt der FD... Adresse.
Frage(n),
ist das ein Problem wenn der Client mehrere IPv6 Adressen hat?
Ist es möglich den Router so zu konfigurieren das nur seine IPv6 Adresse als Gateway versendet wird?
Switch: PowerConnect DNS4128T
Gruß
Xearo
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 1074433776
Url: https://administrator.de/contentid/1074433776
Ausgedruckt am: 24.11.2024 um 11:11 Uhr
8 Kommentare
Neuester Kommentar
Dass als Gateway die fe80-Adresse verwendet wird, ist by design so und die beste Lösung. Das hat keine Nachteile.
Um die Vergabe weiterer temporärer Adressen aus dem per RA advertiseten Präfix zu unterbinden, solltest du das RA so konfigurieren, dass keine autonome Adressvergabe stattfindet — dann hören die Clients auf, sich Adressen zu geben.
Zusätzlich kannst du auch das Advertisement des On-Link-Präfix unterbinden, dann wissen die Clients nichtmal, welches Präfix es gäbe.
Um die Vergabe weiterer temporärer Adressen aus dem per RA advertiseten Präfix zu unterbinden, solltest du das RA so konfigurieren, dass keine autonome Adressvergabe stattfindet — dann hören die Clients auf, sich Adressen zu geben.
Zusätzlich kannst du auch das Advertisement des On-Link-Präfix unterbinden, dann wissen die Clients nichtmal, welches Präfix es gäbe.
Das Verhalten, was du beschreibst ist ganz normal.
DHCPv4 und DHCPv6 arbeiten grundlegend anders. Bei DHCPv4 liegt alles in der Hand des Servers und dieser ist dafür verantwortlich, alle Informationen zu liefern. Bei der Entwicklung von DHCPv4 war Auto-Adressierung noch nicht vorgesehen und daher ist hier ein gesonderter DHCP-Client nötig.
IPv6 hingegen hat eine native Auto-Adressierung, SLAAC genannt. Also die Aussendung und Auswertung von RA-Nachrichten. DHCPv6 erweitert die Funktionen nur, ohne diese zu ersetzen. Vergleich einfach mal die Anzahl der Optionen, die der Windows Server per DHCPv4 und per DHCPv6 ausliefern kann. Bei v4 gehen die Optionen meine ich mittlerweile bis hoch in die 200, bei v6 sind es vielleicht zehn. Der einzige sinnvolle Zweck für DHCPv6 ist die Dokumentation der Adressen und die Auslieferung der DNS-Informationen.
In jedem Fall muss ein Client erstmal die RA auswerten und bekommt dann die Information, über das Managed-Flag, dass er sich, wenn er kann, noch beim DHCPv6-Server melden soll.
Da eine zwingende Vorgabe von SLAAC und damit aller darauf aufbauenden Techniken ein /64-Subnetz ist, ist eine abweichende Angabe nicht möglich, sondern würde die Auto-Adressierung zerstören.
Das gleiche gilt für das Gateway. Es wird aus den RA-Meldungen herausgelesen und nicht per DHCPv6 geliefert. RA-Meldungen sind immer Link-Local, daher auch zwingend die FE80-Adresse.
Zu den mehreren IP-Adressen: Ist bei IPv6 konzeptionell so vorgesehen, aber du hast auch noch die Privacy Extensions aktiv, die du auch aktiv lassen solltest, für den Fall, dass du mal eine IPv6-fähige Internetanbindung erwägen solltest (aktuell arbeitest du ja noch mit ULA). Ohne die Privacy Extensions bräuchte man keine Tracker und Cookies mehr, um deine Gewohnheiten zu erfassen.
DHCPv4 und DHCPv6 arbeiten grundlegend anders. Bei DHCPv4 liegt alles in der Hand des Servers und dieser ist dafür verantwortlich, alle Informationen zu liefern. Bei der Entwicklung von DHCPv4 war Auto-Adressierung noch nicht vorgesehen und daher ist hier ein gesonderter DHCP-Client nötig.
IPv6 hingegen hat eine native Auto-Adressierung, SLAAC genannt. Also die Aussendung und Auswertung von RA-Nachrichten. DHCPv6 erweitert die Funktionen nur, ohne diese zu ersetzen. Vergleich einfach mal die Anzahl der Optionen, die der Windows Server per DHCPv4 und per DHCPv6 ausliefern kann. Bei v4 gehen die Optionen meine ich mittlerweile bis hoch in die 200, bei v6 sind es vielleicht zehn. Der einzige sinnvolle Zweck für DHCPv6 ist die Dokumentation der Adressen und die Auslieferung der DNS-Informationen.
In jedem Fall muss ein Client erstmal die RA auswerten und bekommt dann die Information, über das Managed-Flag, dass er sich, wenn er kann, noch beim DHCPv6-Server melden soll.
Da eine zwingende Vorgabe von SLAAC und damit aller darauf aufbauenden Techniken ein /64-Subnetz ist, ist eine abweichende Angabe nicht möglich, sondern würde die Auto-Adressierung zerstören.
Das gleiche gilt für das Gateway. Es wird aus den RA-Meldungen herausgelesen und nicht per DHCPv6 geliefert. RA-Meldungen sind immer Link-Local, daher auch zwingend die FE80-Adresse.
Zu den mehreren IP-Adressen: Ist bei IPv6 konzeptionell so vorgesehen, aber du hast auch noch die Privacy Extensions aktiv, die du auch aktiv lassen solltest, für den Fall, dass du mal eine IPv6-fähige Internetanbindung erwägen solltest (aktuell arbeitest du ja noch mit ULA). Ohne die Privacy Extensions bräuchte man keine Tracker und Cookies mehr, um deine Gewohnheiten zu erfassen.
Kommt immer drauf an welches Flag deine RAs vom Switch senden. Kollege @LordGurke hat es oben schon gesagt. Leider hast du das in deinem Thread nicht erwähnt.
https://www.elektronik-kompendium.de/sites/net/1902141.htm
Die 2te Adresse sind die sog. Privacy Extensions die die Adresse anonymisieren um keinerlei Rückschlüsse auf den Client zu ermöglichen (EUI64 Format). v6 Clients haben deshalb in der Regel immer mehrere Adressen pro Interface was normal ist.
Nur mal nebenbei:
Du nutzt ULA v6 Adressen intern (fc00::/7) was nicht besonders inelligent ist, denn damit ist eine Internet Connectivity ausgeschlossen. Die v6 ULA Adressen entsprechen den v4 RFC 1918 IP Adressen und sind im Internet nicht geroutet. Da es kein NAT bei IPv6 gibt begibst du dich hier in eine adresstechnische Sackgasse die dir irgendwann ganz sicher auf die Füße fällt und du zwangsweise ändern muss. Keine gute Wahl also bei der v6 Adressierung. Normal verteilst du bei Prefix Delegation intern deinen dir vom Provider zugeteilten v6 Prefix in deine v6 Segmente mit einem lokalen /64er Prefix oder nutzt ein dir statisch zugeteiltes v6 Subnetz. Das solltest du immer auf dem Radar haben !
https://www.elektronik-kompendium.de/sites/net/1902141.htm
Die 2te Adresse sind die sog. Privacy Extensions die die Adresse anonymisieren um keinerlei Rückschlüsse auf den Client zu ermöglichen (EUI64 Format). v6 Clients haben deshalb in der Regel immer mehrere Adressen pro Interface was normal ist.
Nur mal nebenbei:
Du nutzt ULA v6 Adressen intern (fc00::/7) was nicht besonders inelligent ist, denn damit ist eine Internet Connectivity ausgeschlossen. Die v6 ULA Adressen entsprechen den v4 RFC 1918 IP Adressen und sind im Internet nicht geroutet. Da es kein NAT bei IPv6 gibt begibst du dich hier in eine adresstechnische Sackgasse die dir irgendwann ganz sicher auf die Füße fällt und du zwangsweise ändern muss. Keine gute Wahl also bei der v6 Adressierung. Normal verteilst du bei Prefix Delegation intern deinen dir vom Provider zugeteilten v6 Prefix in deine v6 Segmente mit einem lokalen /64er Prefix oder nutzt ein dir statisch zugeteiltes v6 Subnetz. Das solltest du immer auf dem Radar haben !
Danke für eure Hilfen. Mit der COnfig am Switch hat es geklappt.
ipv6 nd managed-config-flag
ipv6 nd prefix default no-advertise no-autoconfig
ipv6 nd send-ra
Wir nutzen intern keine fc Adressen, sondern fd.
So eine z.B.
fdcd:9e0c:1234:ff01::253/64
Das sollte doch i.O. sein?
ipv6 nd managed-config-flag
ipv6 nd prefix default no-advertise no-autoconfig
ipv6 nd send-ra
Wir nutzen intern keine fc Adressen, sondern fd.
So eine z.B.
fdcd:9e0c:1234:ff01::253/64
Das sollte doch i.O. sein?
Wir nutzen intern keine fc Adressen, sondern fd.
Du nutzt ULA v6 Adressen intern (fc00::/7)
@LordXearo: Du hast die Prefixlänge ignoriert. fc00::/7 geht von fc00:: bis fdff:ffff:ffff:ffff:ffff:ffff:ffff:ffff.@aqui:
Da es kein NAT bei IPv6 gibt
Es gibt mittlerweile NPT66 bzw. NAT66. Die ULA-Nutzung intern ist also kein Hindernis für einen Internetzugang. Man sollte es aber, wenn möglich, vermeiden. Leider klappt es bei Multi-Homing-Szenarien nicht so ganz, da man hier sonst auf Unterstützung des Providers angewiesen wäre (AS, LISP oder andere Techniken), um ohne Umadressierung wieder Online zu kommen, da ist dann NPT66 die einfachere Lösung. Es muss nur von der Perimeter-Hardware unterstützt werden.Wir nutzen intern keine fc Adressen, sondern fd.
Mit IP Subnetzmasken kann du umgehen und weisst auch was die bedeuten ?? Kollege @tikayevent hat es ja schon gesagt. NPT66 hat einige Nachteile das sollte man sich also gut überlegen ob man damit frickeln will. Ein Ziel von v6 war ja gerade das ungeliebte NAT endlich loszuwerden...
Ok ok. Ist jetzt verstanden. Ich hatte nur noch im Kopf das es eine Unterscheidung zwischen dem Präfix fc und fd gab.
Das die Adressen das äquivalent zu privaten IPv4 Adressen ist war mir bewusst und erstmal so vorgesehen.
Das die Adressen das äquivalent zu privaten IPv4 Adressen ist war mir bewusst und erstmal so vorgesehen.
Zitat von @aqui:
Nur mal nebenbei:
Du nutzt ULA v6 Adressen intern (fc00::/7) was nicht besonders inelligent ist, denn damit ist eine Internet Connectivity ausgeschlossen. Die v6 ULA Adressen entsprechen den v4 RFC 1918 IP Adressen und sind im Internet nicht geroutet.
Nur mal nebenbei:
Du nutzt ULA v6 Adressen intern (fc00::/7) was nicht besonders inelligent ist, denn damit ist eine Internet Connectivity ausgeschlossen. Die v6 ULA Adressen entsprechen den v4 RFC 1918 IP Adressen und sind im Internet nicht geroutet.
Das gilt aber nur, wenn man ausschlließlich ULA-Adressen nutzt. Da man bei v6 aber meist diese zusätzlich zu den Provider-Präfixes nutzt, kann es durchaus sinnvoll sein, für Intern noch ULAs zu haben.
lks
