Nein. Muss er nicht, denn der ISP baut den nicht auf. Das macht die Kundenseitige Hard- / Software.. Selbst bei einer Fritzbox. Denn auch dort wird ja eine statische Remote Address für AFTR verwendet.
Der GIF- / AFTR-Tunnel ist auch gar nicht notwendig. Hat man diesen nicht, hat an dennoch eine PPPoE-Verbindung zum ISP stehen, mit gültigem Login, etc. Läuft alles über IPv6. Man bekommt dann ganz normal Internet, kann das www nutzen, Mails über IMAP, POP3, SMTP, senden / empfangen etc eben dann alles IPv6-Only.
Nachtrag:
RFC 6333 und RFC 6334 sind die relevanten Normen
Dann braucht man aber einen NAT64 wenn man intern (also im Netzwerk des ISP) nur IPv6 fährt.
Aber genau das ist doch das AFTR, ein NAT64. Es ermöglicht Geräten in reinen IPv6-Netzwerken, mit Geräten in IPv4-Netzwerken zu kommunizieren. Ohne AFTR gibt es nur IPv6.
Falsch, dann bräuchte man den AFTR-Tunnel nicht, weil man gar keine IPv4-Addressen bräuchte. Nur der NAT64-Router/Server bräuchte eine IPv4 (bei Stateful NAT64) und alles dahinter ist dann IPv6-Only mit DNS64 usw.
Zitat: AFTR steht für Address Family Transition Router (…) DS-Lite ermöglicht es ISPs, IPv6-Infrastruktur zu nutzen, um IPv4-Dienste bereitzustellen. Ein B4-Gerät (meist im Endkunden-Router) tunnelt IPv4-Pakete als IPv6-Pakete zum AFTR-Gerät beim ISP. Das AFTR beendet diesen IPv6-Tunnel und setzt die IPv4-Pakete wieder in das IPv4-Netzwerk um. Das AFTR führt dabei oft auch Network Address Translation (NAT) durch, um IPv4-Adressen zu verwalten, da IPv4-Adressen knapp sind. Zusammenfassend lässt sich sagen, dass AFTR als Schnittstelle zwischen der IPv6-basierten Infrastruktur des ISPs und dem IPv4-Internet fungiert, indem es den Übergang von IPv4 zu IPv6 und umgekehrt ermöglicht.
Zitat zu NAT64: NAT64 ist eine Technologie, die die Kommunikation zwischen Geräten in IPv6- und IPv4-Netzwerken ermöglicht. Es übersetzt IPv6-Adressen in IPv4-Adressen (und umgekehrt), sodass Geräte in einem reinen IPv6-Netzwerk mit Geräten in einem reinen IPv4-Netzwerk kommunizieren können, ohne dass eine direkte IPv4-Unterstützung im IPv6-Netzwerk erforderlich ist.
Was ich sagen wollte: AFTR und NAT64 zwei Wege zum selben Ziel. Es gibt eigentlich nur IPv6. Damit die Kunden des ISP aber dennoch IPv4-Only Netze erreichen können muss man einen der Wege beschreiten.
Wenn man in einer pfsense das AFTR/GIF- Interface deaktiviert, hat man nur noch IPv6 Mit IPv6.
Habe mal das GIF-Interface einer pfsense an DS-Lite deaktviert:
[2.8.0-RELEASE][admin@pfSense.localdomain]/root: nslookup www.google.com
Server: 127.0.0.1
Address: 127.0.0.1#53
Non-authoritative answer:
Name: www.google.com
Address: 142.250.185.164
Name: www.google.com
Address: 2a00:1450:4001:81d::2004
[2.8.0-RELEASE][admin@pfSense.localdomain]/root:
[2.8.0-RELEASE][admin@pfSense.localdomain]/root: ping -4 www.google.com
PING www.google.com (216.58.206.68): 56 data bytes
ping: sendto: No route to host
ping: sendto: No route to host
ping: sendto: No route to host
^C
--- www.google.com ping statistics ---
3 packets transmitted, 0 packets received, 100.0% packet loss
[2.8.0-RELEASE][admin@pfSense.localdomain]/root:
[2.8.0-RELEASE][admin@pfSense.localdomain]/root: ping -6 www.google.com
PING(56=40+8+8 bytes) 2001:9e8:6037:565f:5054:ff:fee9:673d --> 2a00:1450:4001:81d::2004
16 bytes from 2a00:1450:4001:81d::2004, icmp_seq=0 hlim=120 time=14.356 ms
^C
--- www.google.com ping statistics ---
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 14.356/14.356/14.356/0.000 ms
[2.8.0-RELEASE][admin@pfSense.localdomain]/root:
Ja, es ist trotzdem nicht das Gleiche 
Und warum der ISP dann nicht einfach wenn er doch eh schon NAT macht für den v4-Traffic aus dem Tunnel, dann kann er auch direkt CG-NAT mit 100.64.0.0/10 machen. Macht für den keinen Unterschied.
Tja, mit CG-NAT haste 100% Recht. Das wäre für die Kunden viel einfacher, da transparent. Bei CG-NAT ist auf Seiten des Kunden die Konfiguration genau wie bei Dual-Stack.
So wie ich das verstehe ist DS-Lite speziell auf die Bereitstellung von IPv4-Diensten über eine IPv6-Infrastruktur ausgerichtet, während CG-NAT eine allgemeine Lösung für den IPv4-Adressmangel ist.
Aus ISP-Sicht bedeutet das, der ISP kann sich bei DS-Lite die Bereitstellung von IPv4-Diensten weitgehend sparen, während der ISP die bei CG-NAT noch vorhalten muss, denn er NATtet ja IPv4 in seinem Netz, das ansonsten genau wie bei Dual-Stack aufgebaut ist. Mutmaßlich lassen sich somit bei DS-Lite Kosten gegenüber CG-NAT einsparen, womit geringere Preise (Wettbewerbsvorteil) oder höhere Margen (Profile) möglich sind.
Nachtrag: Ein weiterer Kostenvorteil bei DS-Lite könnte daraus resultieren, dass die Auswahl an Kundenseitigen Endgeräten (Stichwort: Endgerätefreiheit für Internetanschlüsse, geregelt im TKG) stark eingeschränkt wird. Anbieter wie 1&1 und deren Reseller wie Drilisch betonen an prominenter Stelle, dass bei vorhandenem Router nur Fritzboxen, in der Lage sein sollen DS-Lite (AFTR) zu beherrschen. Somit kann der ISP bei Supportanfragen von Kunden, die keine Fritten verwenden, immer gleich sagen:
„das supporten wir nicht. An unserem Netz funktionieren nur die Gelisteten Fritzbox-Modelle“. Das spart Potentiell noch meher Geld ein. Wahrscheinlich noch mehr als mit den Einsparungen durch Verzicht auf IPv4 im Netz des ISP.
Naja, aber bei DS-Lite wird ja im Tunnel auch wieder v4 gesprochen was an der anderen Seite irgendwie nach außen übersetzt werden muss… Von daher, soviel Unterschied und Kosteneinsparung sehe ich da jetzt auch nicht.
Ich hab noch den Nachtrag geliefert Kosten im Support.