Tücken der Freigabe von Diensten (Webserver, etc.) bei IPv6 mit der FritzBox

[Barungar]

Hallo zusammen,

ich habe hin und wieder beobachtet, dass zwei spezielle Herausforderungen dem ein oder anderen Kopfschmerzen verursachen, wenn er zeitgemäß einen Dienst nicht nur per IPv4 sondern, sehr löblich, auch per IPv6 freigeben möchte. Das sind die "korrekte IPv6-Adresse" im AAAA-Record des DynDNS und der "DNS-Rebind-Schutz" in der FritzBox. Beides passiert, weil vom Anwender eventuell noch zu sehr in (ver-)al(te)ten IPv4-Gedankenmustern gedacht wird.

Ich möchte in diesem Dokument nicht auf die Risikien oder die Sinnhaftigkeit der Freigabe eines Dienstes von daheim eingehen. Dies liegt in der Eigenverantwortung eines jeden Anwenders selbst. Mein Fokus in diesem Dokument liegt ausschließlich auf der Technik hinter den beiden häufigen Fallstricken mit IPv6.

Beginnen wir daher einfach mal auf bekannten Teritorium. Der Freigabe eines Dienstes bei IPv4.

Das Vorgehen ist immer eine Variation des folgenden "Kochrezeptes":

• DynDNS einrichten (oder eventuell DNS, wenn man eine statische IPv4 hat)
• TCP- und/oder UDP-Portweiterleitungen in der Firewall (in der FritzBox) freigeben

--> Fertig!

Der DynDNS-"Client" läuft dabei in 99% der Fälle auf der FritzBox selbst. Sei es nun, dass man MyFritz! nutzt oder einen der anderen unter Internet -> Freigabe -> DynDNS angebotenen Dienste. Für IPv4 klappt das auch wunderbar, für IPv6 aber so nicht wirklich. Das Problem an dieser Stelle ist nämlich, dass in diesem Fall dem DynDNS-Anbieter die IPv4 und die IPv6 der FritzBox selbst mitgeteilt werden.

Das die falsche IPv6, nämlich die der FritzBox, im AAAA-Record für Euren Dienst steht, erkennt ihr typischer Weise an folgendem Fehler.

Wenn Ihr den seht, könnt ihr zeimlich sicher sein, dass der AAAA-Record auf die FritzBox und nicht auf den "Server" zeigt.
Was muss ich also tun, damit es dann auch bei IPv6 funktioniert?

Das IPv6-DNS-"Problem"
In Bezug auf das DynDNS muss man entweder den kompletten DynDNS-Anteil von der FritzBox weg auf das "Server"-System verlagern, oder aber zumindest wenigstens den IPv6-Teil. Im Fall von IPv6 macht die FritzBox nämlich keine Portweiterleitung, wie bei IPv4, sondern eine Portfreischaltung. Das heißt, die FritzBox lässt im Fall von IPv6 den konfigurierten Port für die öffentliche IPv6 des "Servers" zu und nicht, wie noch bei IPv4, für ihre eigene, öffentliche IPv4.

Beispiel:
Unser FritzBox hat vom Provider die IPv4 203.0.113.46 und das IPv6-Präfix 2001:db8:364d:96ae::/56 erhalten. Für sich selbst erzeugt die FritzBox die öffentliche IPv6 2001:db8:364d:96ae:35:564:9dea:734f auf Basis des Präfixes. Unser "Server" hat intern die IPv4 192.168.178.23 sowie die IPv6 2001:db8:364d:96ae::23 von uns erhalten. Ihr erkennt hier vielleicht schon direkt den Unterschied, die IPv4 unseres "Server" ist privat, die IPv6 aber öffentlich. Die "korrekten" DNS-Einträge für unseren Services lauten somit beim A-Record 203.0.113.46 und 2001:db8:364d:96ae::23 für den AAAA-Record. Wird unser Service nun unter TCP-Port 8080 angeboten, so erteilen wir der FritzBox folgenden Auftrag (ich umschreibe!): "Anfragen auf TCP-Port 8080 an die IPv4 203.0.113.46 leitest Du in das Heimnetz an den TCP-Port 8080 der privaten IP 192.168.127.23 weiter!" Bei IPv6 heißt der Arbeitsauftrag aber: "Anfragen auf TCP-Port 8080 an die IPv6 2001:db8:364d:96ae::23 sind okay, die darfst Du ins Heimnetz reinlassen."

Würde in unserem Beispiel das DynDNS komplett auf der FritzBox laufen, so würde die FritzBox an den DynDNS-Anbieter die falsche IPv6, nämlich die eigene, melden. Wenn Ihr das mit dem Arbeitsauftrag vergleicht, erkennt ihr, dass das nicht funktionieren kann. Bei IPv4 ist das egal, da hier ein andere Art von Auftrag vorliegt.

Fazit: Bei IPv6 muss der AAAA-Record stimmen, dass tut er nicht, wenn der DynDNS-Client zu 100% auf der FritzBox läuft.


Das IPv6-Rebind-Schutz-"Problem"
Wenn nun alles eingerichtet ist und der Aufruf des eigenen Dienstes aus dem Internet per IPv6 (über den Namen) funktioniert, stellt man eventuell fest, dass es am eigenen Client nicht funktioniert. Hier schlägt dann der DNS-Rebind-Schutz der FritzBox zu. Diese Funktion der FritzBox verhindert es, dass aus öffentlichen DNS-Quellen Antworten an Euch weitergeleitet werden, deren IP-Angabe auf eine interne IP im Heimnetz zeigt. Bei IPv4 ist diese Situation eher nicht zu erwarten und wenn, dann ist sie in vielen Fällen tendenziell böswillig. Daher auch dieser Schutzmechnismus.
Bei IPv6 und der abweichenden Archtitektur hingegen ist diese Situation nicht unüblich. Im DNS AAAA-Record für unser "Server" steht ja wirklich seine öffentliche IPv6 drin und diese befindet sich auch tatsächlich in unserem Heimnetz. Es sind also alle Bedingungen erfüllt, damit der DNS-Rebind-Schutz aktiv wird.

Unter Heimnetz -> Netzwerk -> Netzwerkeinstellungen findet ihr ein Eingabefeld für den DNS-Rebindschutz. Hier tragt ihr den korrekten Namen (FQDN) Eures Dienstes ein. Anschließend lässt die FritzBox auf DNS-Anfragen für diesen Namen zu, selbst wenn sie eine IP aus dem Heimnetz liefern.

Viel Spaß!

 

[Mavalok2]

Gut geschrieben. Da bekommt man richtig Lust IPv6 einzurichten.

Wenn man dies so liesst, drängt sich allerdings der Gedanke auf, dass die Fritzbox für IPv6 noch nicht ganz fit ist, oder besser gesagt noch nicht so Endbenutzer freundlich ist wie sie sein sollte. Denn dies entspricht nicht ganz der sonstigen Bedienung der Fritzbox.

 

[Spielebernd]

Ich bin hier weiß Gott kein Profi aber ich denke das Problem liegt hier eher im IPv6 Standard statt in der FB.

Die FB teilt so wie in Ihr eingerichtet dem DynDNS Ihre IPv6 mit wie bei IPv4 auch was soll sie auch sonst übermitteln. Ergo kommst du beim Aufruf bei der FB raus. Hier kannst du auch wie bei IPv4 ne Portweiterleitung setzen aber auf die IPv6 Interface ID die mit dem IPv6 DHCP ausgehandelt wurde.

wenn ich das jetzt ab hier noch richtig zusammenbekomme reagieren die Geräte auf die „lokale IPv6“ nicht oder nicht immer von Haus aus. Ist das richtig hier bin mir nicht mehr sicher. @Barungar kann da sicher etwas Licht ins Dunkel bringen.

 

[Barungar]

@Spielebernd Eine Portweiterleitung ist in sich bereits eine "Perversität". Eine nachträgliche Mangelbeseitigung zum "schönen Normal" zu erheben, da wird mir ganz grausig.

Auch die Väter des IPv4 wollten nie, das Menschen sich mit NAT und Portweiterleitung rumärgern mussten. Im Grundgedanke sollte jedes Gerät "im Internet" seine eigene, eineindeutige IPv4 haben. Dann hätte das IPv4 genau so funktioniert, wie nun das IPv6 funktioniert. Das IPv6 schafft durch einen großen Addressraum einfach die Möglichkeit zu den Grundideen zurückzukehren und von den Irrwegen abzukehren.

Der Haken ist einfach... im IPv4 erhalte ich vom Provider nur eine IPv4. Durch diesen "Mangel" werde ich zu NAT und anschließender Portweiterleitung "gezwungen". Beim IPv6 erhalte ich vom Provider ein Subnetz ("IPv6 Präfix"). Um das vergleichen zu können, müsste der Provider Dir z.B. beim IPv4 nicht nur die IP 203.0.113.46 zuweisen sondern direkt das Netz 203.0.113.0/24 ... Dann hättest Du das gleiche Szenario. Deine FritzBox wäre 203.0.113.1 und Dein "Server" 203.0.113.23. Würde dann die FritzBox den DynDNS auf 203.0.113.1 setzen, würde Dein Service auch nicht funktionieren.

Hier kannst du auch wie bei IPv4 ne Portweiterleitung setzen aber auf die IPv6 Interface ID die mit dem IPv6 DHCP ausgehandelt wurde.

Nein, das stimmt so nicht. Da ist AVM leider sehr unscharf in der Bezeichnung. Vermutlich, weil sie denken, dass ihre Klientel mental nicht mit der Wahrheit ungehen könnte. Seit IPv4 kennt "jeder" das Prinzip eine Portweiterleitung, also nennen wir es weiterhin Portweiterleitung. Da findet aber effektiv keine Portweiterleitung statt, sondern ganz korrekt ein Routing. Die InterfaceID wird benötigt, damit die FritzBox dynamisch, bei einem Präfixwechsel, ohne Umschweife sofort die korrekte neue GA des Geräte hat. Denn die öffentliche IPv6 (GA) des Servers ist immer IPv6-Präfix + InterfaceID.

Ein guter Hinweis, dass hier verschiedene Dinge, nämlich eine "Portweiterleitung" bzw. ein Routing passieren, kann man mittels traceroute feststellen. Man braucht dazu lediglich einen Host, der im Internet steht. Man macht nach einander ein traceroute -6 meinservice.meinedomäne.de und ein traceroute -4 meinservice.meinedomäne.de

Den Unterschied erkennt man sofort. Das 4er Traceroute endet an der FritzBox, die Portweiterleitung ist transparent. Das Gegenüber kann nicht feststellen, dass hinter der FritzBox noch etwas passiert. Für ihn "terminiert" die TCP-Verbindung an der FritzBox.
Das 6er Traceroute zeigt Dir als Hop Deine FritzBox (mit deren IPv6) und danach den Hop Deines "Servers" (mit seiner IPv6). Es wird also korrekt geroutet.

wenn ich das jetzt ab hier noch richtig zusammenbekomme reagieren die Geräte auf die „lokale IPv6“ nicht oder nicht immer von Haus aus.

Ich verstehe hier leider nicht, was Du meinst.

 

[Spielebernd]

@Spielebernd Eine Portweiterleitung ist in sich bereits eine "Perversität". Eine nachträgliche Mangelbeseitigung zum "schönen Normal" zu erheben, da wird mir ganz grausig.

Punkt für dich hat sich halt irgendwie so eingebürgert.

Nein, das stimmt so nicht.

Danke für die Aufklärung das hatte ich in der Tat anders verstanden. Im Grunde bin ich sogar davon ausgegangen das hier ich nenne es mal eine pseudo private IPv6 gebastelt wird die ähnlich IPv4 auch wieder mit NAT und allem entsteht.

Damit ist auch die Frage passé . Danke für die sehr gute Beschreibung.

 

[framp]

Interessante Info. Bei mir wird sowohl die IPv4 als auch die IPv6 von der FB an meinen DynDNS Provider geschickt. Bislang habe ich noch nie Versuch auf einen freigegebenen Dienst per IPv6 zuzugreifen und deshalb nicht bemerkt, dass es nicht klappt. Und in der Tat: Nutze ich die IPv6 des Systems, welches den Dienst anbietet, komme ich sofort dran.

D.h. aber dann auch dass ich bei IPv6 immer einen Reverse Proxy brauche um per Port auf unterschiedliche Systeme zugreifen zu können. Sehe ich das richtig?

 

[Barungar]

Wieso? Wenn jedes System seine eigene IPv6 hat, kannst Du bei jedem System auf http bzw. https zugreifen.
Oder was meinst Du? Das ist eher ein IPv4 "Problem", da man nur eine IPv4 hat, kann man nach "außen" nur einmal http bzw. https freigeben und braucht dann eben einen Reverse Proxy. Bei IPv6 sehe ich da keinen Grund für.

 

[framp]

Ich registriere meine IPv4 und IPv6 bei meinem DynDNS Provider unter dem DNS Namen mein-kleines-heimnetz.de.

Jetzt kann ich dort natürlich statt der FB IPv6 die GUA meines Zielsystems mit einem Script und nicht der FB eintragen. Soweit - so gut. Aber wenn ich z.B. mehrere Systeme habe, die erreichbar sein sollen, dann muss ich nach meinem Verständnis mein-kleines-heimnetz.de, mein-kleines-heimnetz-2.de, usw entsprechend definieren lassen und die jeweiligen GUAs dort hinterlegen. Mit einem Reverse Proxy kann ich über den Port das Zielsystem steuern und brauche nur die GUA den ReversProxies in DynDNS stehen haben. Oder geht das einfacher nur mit einem DNS Eintrag?

 

[Barungar]

Wenn Du die Domäne "mein-kleines-heimnetz.de" hast, dann kannst Du (normal) beliebig viele Subdomänen anlegen. z.B. mail.mein-kleines-heimnetz.de, nas.mein-kleines-heimnetz.de, web.mein-kleines-heimnetz.de und waswasich.mein-kleines-heimnetz.de

Jede davon kann auf eine eigene IPv6 auflösen, und jede IPv6 kann dann für sich http und/oder https freigeben.

 

[framp]

Stimmt . Daran habe ich nicht gedacht .

Dann sehe ich mal bei meinem DynDNS Provider nach wie das dort geht. Aber so wie ich verstehe muss die IPv6 Registierung dann in einem Script ausserhalb der FB stattfinden. Die kann das nicht.

 

[framp]

Ich bin gerade ein paar Tage ausser Haus und nutze ein DSLite HomeLAN. Der früher konnte ich per ssh ohne Probleme auf mein Heimnetz zugreifen. Früher heisst, als noch kein IPV6 aktiviert war. Jetzt muss ich explizit dem ssh sagen, dass es IPv4 nutzen soll. Dann kann ich connecten. Ein ping auf den DNS Namen liefert jetzt auch eine IPv6 zurück - die IP der FB. Die GUA des SSH Servers ist natürlich anders.

Jetzt habe ich versucht mit der IPv6 auf den Server zu kommen. In der FB Habe ich eine Portfreigabe für IPv4 und IPv6 eingerichtet. Auch den ping. Aber weder klappt der ping6 noch ein ssh connect Versuch. was mache ich falsch?

Das sind die IPv6 des Servers:

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.8/24 brd 192.168.0.255 scope global noprefixroute eth0
       valid_lft forever preferred_lft forever
    inet6 fd00::8f54:b608:4732:e683/64 scope global temporary dynamic
       valid_lft 6750sec preferred_lft 3150sec
    inet6 fd00::f336:ce51:28ef:c442/64 scope global dynamic mngtmpaddr noprefixroute
       valid_lft 6750sec preferred_lft 3150sec
    inet6 2001:xxxx:xxxx:xxxx:xxxxc19c:66ad:e490:64ec/64 scope global temporary dynamic
       valid_lft 6750sec preferred_lft 3150sec
    inet6 2001:xxxx:xxxx:xxxx:2e9a:97fd:ce74:a446/64 scope global dynamic mngtmpaddr noprefixroute
       valid_lft 6750sec preferred_lft 3150sec
    inet6 fe80::3b29:9e7c:4b4c:869b/64 scope link noprefixroute
       valid_lft forever preferred_lft forever

Und das steht in der FB:

Wie zu sehen ist ist OpenVPN nur per IPv4 offen. Aber bei ssh2 ist der ssh Port sowohl für IPv4 als auch IPv6 offen.

Das IPv6 Artefact findet sich nicht auf dem Server. Was ist das für ein IPv6 Artefakt und warum finde ich das nicht als ULA?

 

[Barungar]

Die FritzBox hat das falsche Interface ... Wie Du selbst siehst, gibt es keine IPv6 die auf <Dein Präfix>:f5bf:c704:62d5:5c35 endet.
Also würde ich Dir empfehlen bei Deiner IPv6-Freischaltung das Inerface zu korrigieren am besten auf: ::2e9a:97fd:ce74:a446
Das sollte die stabile IPv6 Deines Servers sein. Die temporäre bringt Dir nix, die ändert sich ständig.

 

[framp]

Vielen Dank für den Hinweis. Jetzt funktioniert der Ping wie auch der ssh Zugriff per IPv6 Adresse.

Ich ging irgendwie davon aus dass die FB by IPv6 Magic automatisch die richtige IPv6 einträgt. Warum hast Du nicht die 64ec empfohlen? Und warum kann ich auch nicht eine fd00 Adresse nehmen? Das sollte doch auch gehen.

Ist die a446 eigentlich konstant? Soweit ich weiss habe ich bei mir die Privacy Extensions aktiv. Oder wird nur beim Outbound eine wechselnde IPv6 genutzt? Wie erkenne ich dann die weclhselnde IPv6 und die statisch IPv6?

Sorry für die vielleicht dummern Fragen.

Aber ich bin dank Deiner Hilfe schon wieder etwas schlauer geworden bzgl IPv6

 

[Barungar]

Vielen Dank für den Hinweis. Jetzt funktioniert der Ping wie auch der ssh Zugriff per IPv6 Adresse.

Schön... So soll es doch sein!

Ich ging irgendwie davon aus dass die FB by IPv6 Magic automatisch die richtige IPv6 einträgt. Warum hast Du nicht die 64ec empfohlen? Und warum kann ich auch nicht eine fd00 Adresse nehmen? Das sollte doch auch gehen.

Die FritzBox IPv6 Magic funktioniert in den meisten Fällen nur unter der Bedingung... dass der IPv6 Host seine InterfaceID per EUI-64 erzeugt. Ubuntu oder andere Linux weichen davon ab. In diesen Fällen muss man der FritzBox "helfen".

Weil die 64ec "temporary" ist, die ist garantiert nicht stabil.

Und die fd00 sind ULA, die werden im Internet nicht geroutet, damit kannst Du maximal einen IPv6 SSH Server im LOKALEN Netz anbieten, aber nicht im Internet, dafür braucht es eine GUA und keine ULA.

Ist die a446 eigentlich konstant? Soweit ich weiss habe ich bei mir die Privacy Extensions aktiv. Oder wird nur beim Outbound eine wechselnde IPv6 genutzt? Wie erkenne ich dann die weclhselnde IPv6 und die statisch IPv6?

Das müssen wir nochmal beobachten, ob die a446 konstant ist. Im Zweifel müsste man die Privacy Extension noch abschalten, wenn sie nicht stabil ist. Aber in den meisten Fällen sollte die stabil sein. Denn "temporäre" steht in der Zeile darüber. Der Sinn der zwei Adressen bei Privacy Extensions ist, dass man eine wechselnde Adresse hat, mit der kommuniziert der Host aktiv. Und eben eine stabilere Adresse, über die - wenn bekannt - man den Host ansprechen kann. Beides sind GUA, erkennbar an dem "global".

 

[framp]

Und die fd00 sind ULA, die werden im Internet nicht geroutet,

Stimmt. Ich ging - eben IPv4 gewohnt - davon aus dass die FB NAT macht. Aber das findet ja nicht mehr statt. Deshalb muss dort eine GUA stehen. Verstanden

Der Sinn der zwei Adressen bei Privacy Extensions ist, dass man eine wechselnde Adresse hat, mit der kommuniziert der Host aktiv. Und eben eine stabilere Adresse,

Ok. dann habe ich das richtig verstanden. Die TempIP ist die Outbound IP während die andere die statische Inbound IP ist.

Jetzt beobachte ich das mal ob sie statisch ist.

Ubuntu oder andere Linux weichen davon ab

Ist natürlich ein Linuxsystem dahinter. Bei mir gibt es kein Windows - und kommt mir auch nicht ins Haus

D.h. jetzt muss ich noch rausfinden wie ich eine Subdomainen DNS Eintrag definiere und setze bei meinem Domainhoster.

Mein DynDNS Provider geht natürlich davon aus dass sich ein dedizierter Server mit statischen IPv4 und IPv6 IPs dahinter verbirgt und nicht eine FB.

Mein OpenVPN muss ich auch noch IPV6en ... da sind noch Konfigurationsdinge notwendig. Wireguard über die FB wie auch tailscale funktioniert aber aus dem DSLite Netz gut.

 

[Barungar]

Ok. dann habe ich das richtig verstanden. Die TempIP ist die Outbound IP während die andere die statische Inbound IP ist.

Japp... genau. Für ausgehende Verbindungen nimmt er die "temporäre", man möchte ja durch die Nutzung von Pricavy Extensions bewirken, dass man nicht (oder zumindest weniger) aktiv getrackt wird über die IP.
Die andere Adresse sollte "privacy-stable" sein, also auch "verschleiernd", aber doch stabil. Ohne Privacy würde die IPv6 per EUI-64 erzeugt, die ist dann definitiv stable.

D.h. jetzt muss ich noch rausfinden wie ich eine Subdomainen DNS Eintrag definiere und setze bei meinem Domainhoster.

Jo, das wäre gut.

 

[the other]

Moinsen,
Ich hatte mal Ähnliches hier gemacht:
Ein vpn Server hinter der fritzbox. Zunächst nur per IPv4 erreichbar mit dyndns von ddnss.de als Dienstleister.
Ich habe dort dann eine 2. Dyndns Domain (3 sind kostenfrei) angelegt, nur für den AAAA Eintrag.
Beide (also der A record auf die Fritzbox, dort PWL, da IPv4, auf den VPN Server als auch der AAAA record auf den VPN server selbst mit Portfreigabe da IPv6) aktualisieren ihre jeweiligen IPs.
Funktioniert sauber...sollte also gehen.
Aktuell habe ich allerdings v6 an dieser Stelle (Zugriff von extern) wieder deaktiviert. Intern läuft in manchen VLAN dualstack und in anderen nur v4. Wo geht habe ich die Privacy extensions deaktiviert. Nervig, da zb die Androids das nicht deaktivieren lassen. Also alle in ein eigenes Netz und für die dann firewall Regeln erstellt. Denn sonst gehen die eben immer mit ihrer persönlichen privacy temporary ula los, was dann die clientbezogenen firewall Regeln auf NAS und pfsense obsolet macht, denn die pe ula ändert sich ja regelmäßig...also das gesamte subnetz freigeben...doofe IPv6 Implementierung imho. Ein weiteres Beispiel dafür, warum es v6 noch so schwer macht...aber da kann das Protokoll nix für, das ist einfach sch%@#e umgesetzt. Aber kein Grund, sich dem zu verschließen.
Von daher: viel Erfolg mit dem ddns Anbieter...

 

[framp]

Mein ddns Anbieter erlaubt keine Subdomains. Aber ich kann narürlich andere DNS Namen registrieren. Oder ich ändere DNS Einträge bei meinem Domainprovider per Rest API und curl. Ein dyndns Interface bietet der leider nicht an (Hetzner) Ist mir aber etwas unwohl da im DNS direkt rumzufuhrwerkeln. Wenn ich da was zerschießen ist u.U. meine ganze Domain incl eMail betroffen.

 

[the other]

Moinsen,
Ich habe den ddns Dienst nur wegen vpn. Dienste stelle ich nicht direkt ins Netz. Für die Variante ipv4 / 6 VPN habe ich hinter den älteren v4 dyndns Domainname einfach ne 6 gesetzt...
Für die internen Dienste nutze ich für die ssl Zertifikate (rein intern) von Letsencrypt eine eigene domain (für die dns challenge). Das sollte und wollte ich trennen voneinander.
Auch die Trennung von v4 und 6 für den Zugriff von außen ist so gewollt...zumindest erstmal.

 

[framp]

Ich habe den ddns Dienst nur wegen vpn. Dienste stelle ich nicht direkt ins Netz.

Ich eigentlich auch nur OpenVPN. Aber den zweiten externen ssh habe ich als Fallback aufgesetzt, damit ich damit im Notfall die chinesische FW überwinden kann. Der ssh ist nur offen wenn ich in China bin Oder eben jetzt mal temporär um mal den IPv6 Zugriff zu testen