Beiträge von ::1

Falls du den Direktzugriff (ohne VPN, oder mit VPN-Tunnel, der am NAS terminiert) auf dein NAS via IPv6 ins Auge fasst, möchte ich zu bedenken geben, dass QNAP seit Firmware QTS 5.2.5.3145 build 20250526 (Release Notes) an der IPv6-Implementierung herum geschraubt und diese leider wie folgt "verschlimmbessert" hat:

Bei IPv6-Konfiguration des NAS-Netzwerk-Interfaces per SLAAC ("Stateless Address Autoconfiguration") wird keine permanente Interface-ID mehr generiert!

Zur Erläuterung:

Im LAN hinter einer Fritzbox an einem DG-Anschluss wird dein NAS bei Konfiguration via SLAAC eine IPv6-Adresse der Form

[PREF]:[IID]

aufweisen, wobei PREF das LAN-Präfix 2a00:6020:PQWX:YZ00 (das prinzipiell wechseln kann, bei DG aber in aller Regel quasi-statisch ist) und [IID] die schon erwähnte Interface-ID ist, die das NAS nach einem Algorithmus u.a. aus der eigenen MAC-Adresse generiert. Beide Adress-Bestandteile sind mit jeweils 64 Bits gleich lang.

Für den IPv6-Zugriff auf das NAS muss in der Fritzbox-Firewall inbound eine Freigabe für die IPv6-Adresse des NAS (+ entsprechende Ziel-Ports) eingerichtet werden. Diese Freigabe erfolgt aber ausschließlich anhand der [IID] des NAS, denn [PREF] kann sich ja prinzipiell ändern - die Fritzbox ist dann so smart, die Freigabe für das geänderte LAN-Präfix dynamisch anzupassen.

Voraussetzung dafür ist aber, dass [IID] konstant ist und sich nie ändert. Das ist aber leider seit Firmware QTS 5.2.5.3145 build 20250526 nicht mehr der Fall! Es werden nur noch temporäre [IID] mit begrenzter zeitlicher Dauer erzeugt, auch nach jedem Neustart des NAS ändert sich die [IID].

{Nachtrag: Offensichtlich haben die QNAP-System-Engineers hier nur gemäß RFC8981 implementiert und sich entsprechend dem dort enthaltenen Passus "This document does not imply or require the configuration of stable addresses; thus, implementations can now configure both stable and temporary addresses or temporary addresses only." für "temporary addresses only" entschieden. Ich vermute, sie wollten damit die Privacy des NAS "verbessern" für den Fall, dass es ständig durch irgendwelche offenen WLANs vagabundiert - ich weiß nicht so recht, was die vorher geraucht haben. Für server-like Systeme, wie einem NAS, das eigentlich permanent in einer vertrauenswürdigen Umgebung wie dem Home-LAN residiert, ist das doch jedenfalls ein ziemlicher Unsinn. Sie hätten da besser doch gemäß RFC7217 implementiert!}

Außerdem benötigst du eine stabile [IID] auch für manche DynDNS-Lösungen (z.B. DynV6), bei denen du auf deren Web-Site einen Host (hier NAS) anhand seiner [IID] konfigurieren musst. Die Fritzbox würde in einem DynDNS-Update dann nur den [PREF] liefern. Der DynDNS-Anbieter "montiert" beides zu [PREF]:[IID] zusammen und registriert die Adresse unter deinem Wunsch-FQDN im DNS.

Ein Workaround wäre daher, von SLAAC (heißt dort "Automatische Stateless-Konfiguration") für dein NAS abzusehen:

1. Du könntest die IPv6-Adressvergabe in deinem LAN in der Fritzbox auf DHCPv6 umstellen (in den IPv6-Einstellungen die Option "DNS-Server, Präfix (IA_PD) und IPv6-Adresse (IA_NA) zuweisen" aktivieren). Im NAS konfigurierst du für IPv6 den Verbindungstyp "Automatische Stateful-Adress-Konfiguration" mit "DNS-Server-Verbindung" = Automatisch.
   
   Welche IPv6-Adresse und mithin welche [IID] der DHCPv6-Server der Fritzbox dann deinem NAS zuweist, kannst du anschließend in der Fritzbox oder im NAS nachschauen. Hier musst du allerdings darauf bauen, dass der DHCPv6-Server dem NAS stets dieselbe [IID] zuweist. Ich habe diesbezüglich keinerlei Erfahrungswerte.
   
2. Ansonsten bliebe nur, dein NAS bzgl. IPv6 statisch zu konfigurieren ("Statische IP-Adresse verwenden"), d.h. selbst eine feste [IID], hier z.B. "0:0:0:1" (kurz: "::1") vorzugeben:
   
   Feste IP-Adresse: 2a00:6020:PQWX:YZ00::1
   Präfixlänge: /64
   Standardgateway: fe80:... (hier bitte die fe80-Adresse deiner Fritzbox eintragen, die wird dir z.B. unter Windows mit dem Kommando "ipconfig" unter "Standardgateway" angezeigt.
   DNS-Server: Hier entweder deine Fritzbox (siehe Ausgabe des Windows-Kommandos "ipconfig /all" und dort: "DNS-Server": fd...) oder andere DNS-Server deiner Wahl (z.B. Google: 2001:4860:4860::8888 + 2001:4860:4860::8844) eintragen.
   
   Hier hättest du nun zwar einen festen [IID] = 0:0:0:1, den du für die Freigabe-Konfiguration in der Fritzbox und ggf. auch für DynDNS verwenden kannst. Allerdings besteht hier der Nachteil, dass sich das LAN-Präfix nicht ändern darf (in diesem Fall musst du die statische IPv6-Konfiguration deines NAS manuell nachziehen - Fritzbox-Freigabe und DynDNS müssen nicht geändert werden) - aber das kommt an DG-Anschlüssen so gut wie nie vor.

Du kannst den Zugriff von außen (z.B. via Smartphone mit abgeschaltetem WLAN, sofern du von deinem Mobilfunkanbieter IPv6 bekommst) auch ohne DynDNS ausprobieren, indem du im Adressfeld anstelle eines FQDN (den du noch nicht hast) unmittelbar die IPv6-Adresse des NAS verwendest, wichtig ist dabei, dass du sie in eckige Klammern setzen musst:

[2a00:6020:PQWX:YZ00::1]

Ok, gehört also zu 2a00:6020:9c80::/41 - deine WAN-Adresse sollte dann wohl in 2a00:6020:9c80::/112 liegen, also die Form 2a00:6020:9c80::WXYZ haben - right?

Nur mal interessehalber: Liegt dein LAN-Präfix in einem der von mir gelisteten IPv6-Ranges?

Falls nein, würdest du mir den Range bis zur 11. Stelle (2a00:6020:XYZ) verraten? Ich muss für Z nur wissen, ob <8 bzw. >=8.

Zitat von olifre

Als ich noch parallel den DSL-Anschluss bei meinem Vorgängerprovider Inexio hatte, der ja inzwischen auch zur DG gehört, endeten Traces von dort zu meinem DG-Anschluss auch bei fc00::1.

Ja, alle alten Inexio-Anschlüsse scheinen in Bezug auf IPv4 zum AS8899 zu gehören, während sie in Bezug auf IPv6 im AS60294 liegen. Die CGNAT-Adressen dieser Anschlüsse scheinen nach meinen Beobachtungen stets im Range "DGW-FTTH-DYNAMIC-FRA1" = 94.31.96.0/20 zu liegen.

Bezüglich der ULA fc00::1 in Traceroutes von "außen" zu DG-Anschlüssen bin ich empirisch inzwischen zu folgender Erkenntnis gelangt:

Für neuere DG-Kundenanschlüsse mit IPv6-Adresszuweisung nach offenbar geändertem/neuen Konzept gilt augenscheinlich, dass in Traceroutes zu diesen Anschlüssen der vorletzte Hop (unmittelbar vor dem Kunden-Router, somit also der BNG) stets mit fc00::1 adressiert ist. Das gilt auch für "funktionierende" DG-Anschlüsse. Man kann aus dem Erscheinen von fc00::1 im Traceroute also nicht auf eine Fehlkonfiguration schließen.

Erstaunlich ist die Sichtbarkeit von IPv6-Paketen mit ULA-Source-Adressen im Internet (hier ICMPv6-Time-Exceeded von fc00::1) allerdings schon: Bei guter Administration des eigenen AS sollten die eigenen eBGP-Router derlei eigentlich filtern bzw. droppen.

Nach meinen Beobachtungen wird derzeit für DG-Kundenanschlüsse in folgenden IPv6-Ranges (ohne Anspruch auf Vollständigkeit) das neue IPv6-Konzept verwendet:

1. 2a00:6020:7380::/41 (PD-Präfixe: 2a00:6020:7380:100::/56 - 2a00:6020:73ff:ff00::/56); WAN-Port-Adresse in 2a00:6020:7380::/112
2. 2a00:6020:7680::/41 (PD-Präfixe: 2a00:6020:7680:100::/56 - 2a00:6020:76ff:ff00::/56); WAN-Port-Adresse in 2a00:6020:7680::/112
3. 2a00:6020:7800::/41 (PD-Präfixe: 2a00:6020:7800:100::/56 - 2a00:6020:787f:ff00::/56); WAN-Port-Adresse in 2a00:6020:7800::/112
4. 2a00:6020:7880::/41 (PD-Präfixe: 2a00:6020:7880:100::/56 - 2a00:6020:78ff:ff00::/56); WAN-Port-Adresse in 2a00:6020:7880::/112
5. 2a00:6020:8f00::/41 (PD-Präfixe: 2a00:6020:8f00:100::/56 - 2a00:6020:8f7f:ff00::/56); WAN-Port-Adresse in 2a00:6020:8f00::/112
6. 2a00:6020:bb00::/41 (PD-Präfixe: 2a00:6020:bb00:100::/56 - 2a00:6020:bb7f:ff00::/56); WAN-Port-Adresse in 2a00:6020:bb00::/112

In diesen Ranges ist der jeweils erste /56-Block ausgenommen, weil aus diesem Range die WAN-Port-Adressen der Kundenrouter gebildet werden. Diese WAN-Port-Adresse ist an funktionierenden Kundenanschlüssen der letzte Hop in Traceroutes - Fritzboxen in der Standardeinstellung liefern hier brav Antworten und sind WAN-seitig auch anpingbar.

Zitat von olifre

Der Outbound IPv6-Traffic geht korrekt zur MAC der Gegenstelle, die sich als Router announced hat. Es kommt nur Nichts zurück, und dann sieht man Retransmits.

Ok - dann ist das Problem hier anders gelagert: Die DG-Infrastruktur routet deine IPv6-Adressen nicht. Hatten wir hier im Forum auch schon.

Zitat von olifre

dass das Problem weiterhin besteht, also ping und traceroute auf die IPv6 von außen nicht gehen

Wäre es evtl. nicht erst mal naheliegender nachzuweisen, dass IPv6 outbound ebenfalls nicht funktioniert?

Möglicherweise hat das ja in deinem Fall dieselben Ursachen, die ich in #381 beschrieben habe. Falls so, wäre es aus meiner Sicht viel effizienter, die eigentliche Ursache des Problems konkret zu benennen: Nämlich, dass die Hardware-Adressauflösung für IPv6 (per NS/NA) outbound nicht funktioniert, weil die DG-Gegenstelle die von deinem Router gesendeten NS nicht per NA beantwortet.

Alles Andere (nämlich, dass IPv6 outbound und inbound nicht oder ggf. nur sporadisch funktionieren) wäre dann nur eine Folge des Kernproblems.

Freilich müsste man das für deinen Fall erst Mal durch einen Paketmitschnitt am WAN-Port verifizieren - möglicherweise liegen deinem Problem ja doch andere Ursachen zugrunde, als dem von Luki .

Es kann auch sinnvoll sein, aus Platzgründen oder weil die Editier-Möglichkeiten im Kontaktformular für die Ticket-Erfassung recht "elementar" sind, das Problem ausführlich in einem Word-Dokument zu beschreiben, das man als PDF speichert und als Attach beifügt. So kann man den Beschreibungstext des Tickets sehr kurz halten und auf die ausführliche Beschreibung im angehängten PDF verweisen.

Zitat von olifre

(Packet Captures kann man ja nicht anhängen)

müsste als komprimierte ZIP-Datei schon möglich sein.

Zitat von HubeBube

Seit wann die Telefonie ebenfalls via IPv6 möglich ist, weißt Du nicht zufällig?

Mein ältester Paketmitschnitt, in dem ich das verifiziert hatte, stammt vom 01.09.2022. Den Anschluss habe ich seit 10/2021.

Ich vermute mal, die Aussage "geht nur via IPv4" resultiert daraus, dass "dg.voip.dg-w.de" nur nach IPv4 auflöst (185.22.44.186).

Ich habe auch erst durch Paketmitschnitte mitbekommen, dass der SIP-Service via SRV-RR erfragt wird, siehe meine NSLOOKUP-Ausgabe im letzten Post, die das Verhalten der Fritzbox (wie per Paketmitschnitt ermittelt) nachbildet.

Zitat von HubeBube

Telefonie bei Deutsche Glasfaser ist nach aktuellem Kenntnisstand IPv4-only.

Das wird durch ständige Wiederholung nicht wahrer:

C:\>nslookup
Standardserver:  localhost
Address:  ::1

> set q=SRV
> _sip._udp.dg.voip.dg-w.de
Server:  localhost
Address:  ::1

Nicht autorisierende Antwort:
_sip._udp.dg.voip.dg-w.de       SRV service location:
          priority       = 20
          weight         = 1
          port           = 5060
          svr hostname   = sip20.voip.dg-w.de
_sip._udp.dg.voip.dg-w.de       SRV service location:
          priority       = 10
          weight         = 1
          port           = 5060
          svr hostname   = sip10.voip.dg-w.de
> set q=A+AAAA
> sip10.voip.dg-w.de
Server:  localhost
Address:  ::1

Nicht autorisierende Antwort:
Name:    sip10.voip.dg-w.de
Addresses:  2a00:6020:100:603::186
          185.22.44.186

> sip20.voip.dg-w.de
Server:  localhost
Address:  ::1

Nicht autorisierende Antwort:
Name:    sip20.voip.dg-w.de
Addresses:  2a00:6020:200:603::165
          185.22.45.165

Meine Fritzbox führt als SIP-Client die SIP-Registrierungen per IPv6 durch, auch die Sprachübertragung eines Telefongesprächs via RTP läuft bei mir via IPv6 - alles auch per Paketmitschnitt verifiziert.

In der Rufnummern-Konfiguration der DG-Rufnummern kann man das gewünschte Protokoll (IPv4 und oder IPv6) einstellen.

Zitat von Luki

Sehr merkwürdig - ab und zu ist die Verbindung da und ping bring zurück eine richtige und korrekte Rückmeldung, siehe Anhang - die Datei habe ich archiviert, da sie sonst zu lang ist.

Das hatte ich als Möglichkeit in #329 schon in Betracht gezogen - ich kopiere es mal:

"
Noch ein Nachtrag:

Zumindest für kurze Zeit scheint dein IPv6-Access (inbound + outbound) zu funktionieren. Ich vermute immer dann, wenn deine Fritzbox einen RA von der DG-Gegenstelle erhält und daraus die MAC-Adresse 20:00:00:00:20:38 der Gegenstelle lernt. Solange sie diese in ihrem Neighbor-Cache speichert (dürfte allerdings nur ein paar Sekunden sein), kann IPv6-Kommunikation erfolgen. Das könnte man per Dauer-Ping bei gleichzeitigem Langzeit-Paketmitschnitt (~ 2 Stunden) , der ein paar erhaltene RA umfasst, evtl. verifizieren. Zur Ansicht in Wireshark den Filter "icmpv6" setzen.

Nachtrag 2:

Gemäß deinem ersten Mitschnitt empfängst du etwa alle 30 Minuten einen RA (die Router-Lifetime im RA ist mit 4500s recht lang, deshalb auch die großen RA-Zeitabstände). Auch ohne Paketmitschnitt: Wenn Du mal einen IPv6-Dauerping machst, könnte es sein, dass du etwa alle 30 Minuten für ein paar Sekunden Antworten bekommst, wenn meine Annahme zutreffend ist.

"

Deine Datei zeigt Ping-Antworten, z.B. im Zeit-Intervall: 2025-08-12 15:51:59 - 2025-08-12 15:54:55, also für 176 Sekunden - solange hat die Fritzbox vermutlich die MAC-Adresse 20:00:00:00:20:38 der DG-Gegenstelle im Neigbor-Cache des WAN-Ports gespeichert, kurz zuvor hat sie diese wohl über ein von DG erhaltenes RA gelernt. Ich vermute, der Zeitabstand zwischen Ping-Erfolgen entspricht dem Abstand zwischen zwei erhaltenen RA:

2025-08-12 15:51:59
2025-08-12 16:21:58
2025-08-12 16:51:58
2025-08-12 17:21:57
:

Kommt ganz gut hin: RA-Empfang so etwa alle 30 Minuten.

Noch ein Nachtrag:

Ich ergänze nochmal folgenden Auszug aus #372:

"Deine Paketmitschnitte zeigten, dass dein Router outbound keinerlei IPv6-Pakete mit globalen IPv6-Zieladressen senden kann, weil die MAC-Adressauflösung (per NS/NA) der DG-Defaultgateway-Adresse (fe80::22) scheitert: Dein Router sendet ständig NS an die zu fe80::22 gehörende SNMA = ff02::1:ff00:22 ("solicited node mulitcast addess"), die von der Gegenstelle jedoch nicht per NA beantwortet werden. Ausgehende IPv6-Pakete können deshalb nicht in Ethernet-Frames eingepackt werden - dein Router muss sie verwerfen."

Somit hast du nun eine schlüssige Diagnose, die du mit einem deiner Paketmitschnitte (derjenige, der die vielen NS an ff02::1:ff00:22 zeigt, die von der DG-Gegenstelle nicht beantwortet werden) und deiner Textdatei mit dem Ping-Log technisch belegen kannst.

Schön wäre noch ein langer Paketmitschnitt (~2h) am WAN-Port, der die erfolgreichen Pings, die kurz zuvor erhaltenen RA und die dazwischen liegenden NS an ff02::1:ff00:22 bei entsprechender Filtersicht (icmpv6) zeigt.

Zitat von neisbe

... die in #1 -#3 erläuterten Verfahren nicht mehr funktionieren.

Der Link aus #3 (https://www.telekom.de/hilfe/apps-die…dresse-behalten) führt auf eine Telekom-Hilfeseite mit dem Hinweis "In den ersten 150 Tagen nach der Kündigung können Sie über die Seite "Wechsel auf Freemail" Ihre E-Mail-Adresse selbst umstellen." Der enthaltene Link führt dich dann zum Login deines Telekom-Kundencenters, wo du den "Wechsel auf Freemail" beauftragen können solltest (ich kann's nur halt nicht mehr verifizieren, weil ich nach meiner Umstellung nun in meinem Freemail-Kundencenter lande, wo mir die Meldung "Die Vertragsumstellung ist nicht mehr möglich" und weiterer Erklärungstext angezeigt wird).

neisbe :

Du könntest dich ja hier erst Mal bei Freemail registrieren und eine noch freie E-Mail-Adresse anlegen.

Dann gehst du in die Mail-Verwaltung deines noch bestehenden Telekom-Vertrags, legst dort einen Mail-Alias an und wandelst diesen in die Hauptadresse des Kontos um. Dadurch wird deine bisherige Hauptadresse ihrerseits zum Alias.

Den gibst du im Anschluss frei, und zwar mit sofortiger Wirkung (ohne Sperre!)

Jetzt wechselst du in deine Freemail-Verwaltung und legst dort die eben freigegebene Adresse sofort als Alias wieder an. Anschließend machst du sie zur Hauptadresse deines Freemail-Kontos, wodurch die bisher dort definierte Adresse zum Alias wird - den kannst du dann auch ggf. löschen.

Im Endeffekt hättest du so deine bestehende T-Online-Adresse aus dem alten Vertrag herausgelöst und in eine Freemail-Adresse umgewandelt.

Das war die Alternativ-Variante, die ich mir seinerzeit überlegt hatte, bevor ich die elegantere Methode gemäß #3 entdeckte.

Zitat von Luki

Das Problem ist, dass man auf dem FB die IPv6 (Präfix) Adresse schon sieht, nur die Anfragen von FB gehen ins Nirvana, aber DG wäscht ihren Händen mit dem "eigenen" Router Entschuldigung.

Das Problem ist, es DG zu beweisen.

Deine Paketmitschnitte zeigten, dass dein Router outbound keinerlei IPv6-Pakete mit globalen IPv6-Zieladressen senden kann, weil die MAC-Adressauflösung (per NS/NA) der DG-Defaultgateway-Adresse (fe80::22) scheitert: Dein Router sendet ständig NS an die zu fe80::22 gehörende SNMA = ff02::1:ff00:22 ("solicited node mulitcast addess"), die von der Gegenstelle jedoch nicht per NA beantwortet werden. Ausgehende IPv6-Pakete können deshalb nicht in Ethernet-Frames eingepackt werden - dein Router muss sie verwerfen.

Wenn du der DG so einen Paketmitschnitt schickst, wird der 1st-Level-Support damit allerdings nichts anfangen können, weil ... (such dir einen passenden Grund aus). Er diente vor allem dem Zweck, dass du dir sicher sein kannst, dass das Problem nicht bei deinem Router liegt.

DG muss das leisten, was in seiner Leistungsbeschreibung steht, siehe insbesondere 5.2:

Zitat

Deutsche Glasfaser richtet einen Internet-Zugang mit IPv6 IP-Ad-
ressen ein. Für IPv4 stellt Deutsche Glasfaser eine private Netz-
werkadresse bereit die von Carrier Grade Network Address Trans-
lation (CGN) auf eine öffentliche Adresse umgeschrieben wird. ...

Zitat von Phino

Ich meinte die Kombi aus Mobil IP (RFC 6275) und IPSec.

Achso - ja, da gebe ich dir Recht! Es gibt im IPv6-Bereich einige Fehlentwicklungen, die sich ein der Praxis nicht durchgesetzt haben. Mobile IPv6 scheint dazuzugehören, weshalb ich mich auch nie näher damit befasst habe.

Andere Fehlentwicklungen sind bspw. SeND und CGA - aber vielleicht wird das in den Netzen von Geheimdiensten verwendet - ich habe so etwas in freier Wildbahn jedenfalls noch nie gesehen.

Zitat von pufferueberlauf

O2 macht IPv4 via PPPoE und dann IPv6 ueber DHCPv6

Jo, liegt in der Natur der Sache: Das in PPP enthaltene NCP (Network Contol Protocol) kann nur im Falle von IPv4 (NCP = IPCP) auch eine globale IP-Adresse zuweisen, nicht jedoch im Fall von IPv6 (NCP = IPV6CP). Wozu IPV6CP gut ist, kann man hier nachlesen (in Kurzform: Es wird nur ein 64-Bit Interface-Identifer ausgehandelt, mit dem der Router dann seine eine linklokale fe80-Adresse am WAN-Port bildet).

Für die dynamische Zuweisung einer IPv6-GUA am WAN-Port des Heim-Routers braucht es dort also entweder SLAAC oder DHCPv6. Ein IPv6-Präfix für's LAN geht dynamisch ohnehin nur via DHCPv6-PD. Da man um DHCPv6 also nicht herumkommt, wird man naheliegenderweise also auch den WAN-Port per DHCPv6 mit einer IPv6-GUA beglücken, beides kann man innerhalb desselben DHCPv6-Requests durch Anforderung von IA_NA (WAN-Port) und IA_PD (LAN-Präfix) erledigen.

Zitat von pufferueberlauf

weshalb Firewalls wohl oft nur den RFC Bereich fc00::/6 fuer DHCPv6

Hä? Also fc00::/7 ist der Range für ULA, in der Praxis fd00::/8 (fc00::/8 ist "special"). Und ja, Home-Router, wie die Fritzbox, vergeben zusätzlich zum LAN-Präfix des ISP noch ULA-Adressen (per DHCPv6 oder eher SLAAC), die dann sogar bevorzugt für die LAN-interne Kommunikation genutzt werden und auch dann noch funktionieren, wenn der IPv6-Internetzugang und damit das LAN-Präfix des ISP wegbricht.

Zitat von pufferueberlauf

Anfang des Jahres als die DHCP Antwort von Prefix 0:80fe:: kam statt des erwarteten Prefix fe80:: *

Also "fe80::*" wird niemals via DHCPv6 angeboten.

Zitat von Phino

Beispiel: Ein für Firmen/Universitäten möglicherweise interessante Teil ist, dass man mit einer IPv6 Adresse aus seinem "Heimat"-Netz überall in der Welt sich in anderen IPv6-Netzen anmelden kann und damit automatisch ein verschlüsselter Tunnel ins heimische Netz aufgebaut wird, ohne weiteres dazutun, ist ja Teil des Protokolls.

Ähm - nein. Ich weiß nicht genau, wovon du bei "automatisch ein verschlüsselter Tunnel" sprichst, ich vermute du meinst IPsec-im Transport Modus. Das ginge im Übrigen prinzipiell auch mit IPv4, allerdings nicht " überall in der Welt", denn leider haben wir mit IPv4 ja kein Ende-zu-Ende.

Der Unterschied bzgl. IPsec ist hier: Bei IPv4 war IPsec nur ein optionales Addendum. Bei IPv6 ist es integraler Bestandteil der Protokoll-Definition. Die Funktionsweise von IPsec ist für beide Protokolle gleich.

Aber ich gebe dir Recht: IPsec im Transport-Modus ist "mal nicht eben einfach so" und schon gar nicht automatisch verfügbar. Man muss hier nämlich u.a. was für die gegenseitige Authentisierung der IPsec-Peers tun, und das bedeutet einigen Aufwand (unabhängig davon, ob man das für IPv4 oder IPv6 umsetzen will). Will man hier nicht "pre shared key" verwenden, gilt es, stattdessen zertifikats-basiert zu arbeiten und dafür (zumindest Unternehmens-intern) eine PKI-Struktur zu betreiben.

Generell:

IPv6 macht funktional genau dasselbe wie IPv4, nur mit verbesserten Möglichkeiten. Bei einigen Dingen, wie bspw. dynamischer Adress-Konfiguration (SLAAC gibt es bei IPv4 nicht, DHCPv6 arbeitet anders als DHCPv4, Adresszuweisungsmethoden sind bei IPv6 additiv, bei IPv4 "one of", die Existenz mehrerer IP-Adressen auf einem Netz-Interface ist bei IPv4 zumindest unüblich, temporäre IP-Adressen gibt es bei IPv4 nicht, ...) muss man halt umdenken - viele machen hier den Fehler, ihr IPv4-Wissen 1 zu 1 auf IPv6 zu übertragen und beklagen sich im Falle des Scheiterns über dessen "Komplexität".

Nachtrag zu Unterhaltung: Hier trifft "alte IPv4-Denke" auf IPv6:

Zitat von mbo77

Eingehende Verbindungen sind ebenfalls auf IPv6 angewiesen, da man nur eine private Adresse bei DG erhält.

Das machen doch nur ein paar Freaks, die sich dann in Foren wie bspw. diesem hier miteinander unterhalten. Und ISP-seitig sieht man das an Privat-Anschlüssen auch nicht so gerne, möchte man das doch lieber den hochpreisigen Business-Anschlüssen vorbehalten.

Die große Mehrheit will doch bloß Videos streamen, Social Media nutzen und online shoppen - und denen ist auch egal, ob das via IPv4 oder IPv6 (IP was ...?) erfolgt, dafür hat sie ohnehin keine Awareness.

Zitat von mbo77

Was wäre, wenn IPv6-only Dienste gäbe?

Davon sind wir zumindest in Deutschland noch einigermaßen weit entfernt:

Den zwar aktuell etwa 75% IPv6-sprechenden Clients (Link) steht service-seitig nur ein ziemlicher Flickenteppich IPv6-fähiger Web-Services (Auswahl aus Alexa-Liste) gegenüber (Link). Ein deutscher IPv6-only-Dienst wäre aktuell für 25% der deutschen Nutzer nicht erreichbar, das kann sich kein Dienste-Anbieter leisten.

Auf der Internationalen Bühne haben wir gar nur etwa 45% IPv6-sprechender Clients (Link) - ein IPv6-only-Dienst wäre folglich für 55% der Internet-nutzenden Weltbevölkerung nicht erreichbar.