Am Mac ist die Option Private WLAN-Adresse deaktiviert.
Das ist gut. Es ist aber was anderes (Link), als die von mit erwähnten "privacy extensions" für IPv6. Die sind vermutlich immer noch aktiv, was du daran sehen kannst, dass du 2 IPv6-Adresse aus 2a00:xxxx:4798:b100::/64 hast. Das oben von mir Gesagte gilt also weiterhin (von den beiden ist die permanente Adresse zu bestimmen und für die Freigabe in der Fritzbox zu verwenden).
Ich nehme an, dass auf deinem MAC-Book die sog. "privacy extension" für IPv6 aktiviert ist? In diesem Fall hat das MAC-Book dann neben einer permanenten IPv6-Adresse aus 2a00:xxxx:yyyy:b101::/64 auch eine temporäre IPv6-Adresse aus 2a00:xxxx:yyyy:b101::/64 - beide unterscheiden sich in den hinteren 64-Bits, der sog. "IPv6 Interface ID". Du musst herausfinden, welche von den beiden die permanente "IPv6 Interface ID" ist. Diese muss in der Fritzbox für dein MAC-Book ebenfalls als "IPv6 Interface ID" vermerkt sein (andernfalls dort manuell überschreiben), und bei der Auswahl des MAC-Books in der Freigabe muss ebenfalls diese permanente IPv6 Interface ID angezeigt werden.
Sodann ist mir aufgefallen, dass du für das WAN das erste /64-Präfix 2a00:xxx:yyyy:b100::/64 aus deinem /56-PD-Block verwendest. Das entspricht nicht einer mustergültigen Einstellung für einen DG-Anschluss, denn an dem wird die WAN-Adresse normalerweise von der DG zugewiesen und stammt nicht aus dem /56-PD-Block. Vermutlich hast du in der Fritzbox die Option "Native IPv6-Anbindung verwenden" gewählt und dann zusätzlich die Option "Globale Adresse aus dem zugewiesenen Präfix ableiten" - so wie's der Herr Ingenieur aus dem Video gezeigt hat - nunja.
Du solltest stattdessen nur die Option "Native IPv4-Anbindung verwenden" wählen.
Leider sind auch die "Experten" bei der Dt. Glasfaser nicht wirklich gewillt oder fähig, das Problem zu analysieren.
Ich würde auf die AGB verweisen, in denen die Bereitstellung von IPv6 integraler Bestandteil des Leistungsumfangs ist. Da DG dies derzeit nicht leistet (und du kannst es technisch nachweisen - nicht dein Problem, wenn sich die Gegenseite hier dumm stellt), hilft nur die Androhung einer Halbierung der "Monatsgebühren" - das ist in solchen Fällen die einzige Sprache, die dort verstanden wird.
eigentlich wollte ich nur wissen, ob ich auch dual stackk habe.
Ja, hast du - mit öffentlicher IPv4-Adresse aus 87.0.0.0/8. Vermutlich genauer aus 87.122.0.0/15. Siehe auch hier.
weil in der fritzbox unter internet-online monitor verbindungs details sehe ich IPv4 und 6 in grün.
Dann ist es Dual Stack. Es würde ansonsten ein DS-Lite-Tunnel im Online-Monitor auftauchen.
Beides richtig. Wenn die WAN-IP-Adresse allerdings im Bereich 100.64.0.0 - 100.127.255.255 liegt, dann ist dies keine öffentliche IPv4-Adresse. Sie muss beim Provider per CGNAT nochmals auf eine öffentliche IPv4-Adresse übersetzt werden.
"Dual Stack" allein ist also nicht hinreichend - wichtig ist: Dual Stack mit öffentlicher IPv4-Adresse am WAN-Port des Routers.
Vielleicht noch folgender Hinweis:
Falls du aus der ursprünglichen Mitschnitt-Datei nur die durch den Filter icmpv6 || dhcp || dhcpv6 generierte Ansicht in einer separaten Datei speichern möchtest:
Das ergibt eine schön kleine Datei, die du neben dem Screenshot ggf. auch an das Ticket bei DG anhängen kannst.
Verstehe ich das korrekt ( Interpretation zum neuen Mitschnitt unten): In Zeile 284 sendet der ISP, ab Zeile 305 sendet meine Fritzbox?
Nein: Es sendet (bzgl. IPv6) immer nur deine Fritzbox! Paket 284 ist die sog. DAA (Duplicate Address Detection): Hier hat das WAN-Interface noch keine (linklokale) IPv6-Adresse, was durch die Quelladresse "::" (= alles Nullen) zum Ausdruck kommt. Gesendet wird ein Multicast an die eigene SNMA (Solicited Node Multicast Address = ff02::1:fff4:b68b). Diese leitet sich aus der Kandidaten-Adresse fe80::3681:c4ff:fef4:b68b ab, die sich das WAN-Interface selbst zuordnen möchte. Es wird damit getestet, ob die Kandidaten-Adresse in dem Netz, in das der Multicast gesendet wird, schon durch ein anderes Gerät genutzt wird, was einen Adresskonflikt darstellen würde (in diesem Fall würde jenes Gerät den Multicast beantworten). Ab dem nächsten Paket 305 weiß die Fritzbox, dass kein Adresskonflikt vorliegt und verwendet sie als ihre eigene Adresse.
Das ist aber nur eine linklokale Adresse - mit der kann die Box nicht ins Internet kommunizieren. Dazu müsste die DG der Box eine globale IPv6-Adresse für den WAN-Port und ein globales (/56)-Präfix für das LAN hinter der Box zuweisen, was sie per DHCPv6 tun müsste.
Die Box bemüht sich nun um zweierlei:
Ich würde sagen: Die DG-Gegenstelle ist bzgl. IPv6 mausetot!
Sollte ich den gefilterten Mitschnitt an die Deutsche Glasfaser schicken?
Es würde reichen, wenn du den Screenshot schickst - der ist absolut aussagekräftig.
Aber sei gewarnt: Im 1st-Level-Support versteht das keiner - für die ist alles ein Glasfaser-Problem mit den immer gleichen unnützen Maßnahmen, mit denen man den Kunden sinnlos beschäftigt.
Es gilt das, was oben schon gesagt wurde: Solange Tickets aufmachen, bis irgendwann dort mal jemand Erbarmen zeigt.
... na, da hat sich was überschnitten 
Mach doch bitte nochmal einen Mitschnitt, wie von mir beschrieben.
Poste dann mal die Ansicht des Ergebnisses unter dem Ansichts-Filter icmpv6 || dhcpv6.
Wireshark am WAN-Port einrichten überfordert mich derzeit noch.
Das ist vermutlich ein Missverständnis: Wireshark würdest du an einem Windows-PC installieren, um die Mitschnitt-Datei auszuwerten, die die Fritzbox völlig unabhängig von Wireshark erstellt (das ist eine Datei mit der Endung ".eth") - das eine hat mit dem anderen nichts zu tun.
Die Vorgehensweise wäre wie folgt:
An einem beliebigen Windows-PC in deinem LAN:
Um dort "den Wald vor lauter Bäumen" zu finden, solltet du in der oberen Zeile "Anzeigefilter anwenden" die folgenden Ansichtsfilter eingeben: icmpv6 || dhcpv6 || icmp || arp || dhcp. Das sollte reichen, um zum einen den IPv4-Reconnect und zum anderen die Versuche des IPv6-Verbindungsaufbaus anzuzeigen. Für IPv6 alleine wäre der Filter icmpv6 || dhcpv6 ausreichend (entsprechend für IPv4 der Filter icmp || arp || dhcp). Wahrscheinlich wirst du da nur die ausgehenden DHCPv6-Solicits sehen, die von der Gegenstelle nicht beantwortet werden. Und zusätzlich evtl. sog. ICMPv6-Router Advertisements (RA), die von der Gegenstelle gesendet werden (das wäre zumindest ein IPv6-Lebenszeichen von der Gegenstelle).
Sollte man "DHCPv6 Rapid Commit" besser deaktivieren?
Es ist an sich egal, ob man diese Option aktiviert: Wenn der DHCPv6-Server sie nicht unterstützt, kommt eben das Standardverfahren zum Einsatz (quasi ein "Slow Commit"), das du aber auch durch Deaktivierung der Option erzwingen kannst.
Gibts es noch andere Möglichkeiten ein ausführlicheres Logfile zu generieren als die Fritzbox-Ereignisse?
Ja, die Ultima Ratio wäre ein Paketmitschnitt am WAN-Port der Fritzbox, den du parallel zur Ausführung einer Neuverbindung (Internet - Online Monitor - Verbindungsdetails: Schaltfläche "Neu verbinden") durchführst. Allerdings muss man das Ergebnis des Mitschnitts (lesbar z.B. mit Wireshark) anschließend auch interpretieren können.
Muss ich zur Firewall Freischaltung für die VU folgenden Haken setzen bei
Firewall für delegierte IPv6-Präfixe dieses Gerätes öffnen
Nein, stattdessen im Feld "Freigaben" auf "Neue Freigabe" klicken und dort entweder eine der vordefinierten Anwendungen oder spezifisch für dein Endgerät Protokoll (vermutlich TCP) wählen und Port eintragen. Sodann "Internetzugriff über IPv6" wählen.
Ich weiß nicht, ob ich deine Screenshots richtig deute, aber könnte es sein, dass du für IPv4 den "falschen" WAN-Port (Secondary WAN2) konfiguriert hast, während der DG-Anschluss über "Primary WAN1" läuft (der für IPv6 verwendet wird)?
Indem es einfach auf deren Gateway erneut nattet? Oder übersehe ich etwas?
Ja, das wird wohl so sein. Andererseits: Wie differenziert Vodafone beim zentralen NATing die 192.0.0.1-Adressen verschiedene Kundenanschlüsse? Im Kontext DS-Lite wird das ja durch die "Extended Binding Table" erreicht, wie oben von mir zitiert. Haben wir hier aber nicht. Abgesehen davon, dass 192.0.0.1 bei DS-Lite für den AFTR reserviert ist (und für das B4-Element im Kundenrouter 192.0.0.2 verwendet werden sollte), würde man doch für diese Konstellation dann den "Shared Address Space" 100.64.0.0/10 verwenden, um die Kundenanschlüsse auseinander zu halten.
Achso, ich bin jetzt in meiner Naivität jetzt mal davon ausgegangen, dass Vodafone sich jetzt nicht für die Kooperation mit DG extra CGNAT-Router angeschafft hat, wenn für alle anderen Zugänge schon DS Lite am Start ist.
Mit Verlaub: Ich möchte jetzt nicht besserwisserisch 'rüber kommen, aber der mit DS-Lite beim ISP zum Einsatz kommende AFTR _ist_ ein CG-NAT-Router:
Zitat aus RFC6333-Chapter 4.1:
4.1. Access Model
Instead of relying on a cascade of NATs, the Dual-Stack Lite model is
built on IPv4-in-IPv6 tunnels to cross the network to reach a
carrier-grade IPv4-IPv4 NAT (the AFTR), where customers will share
IPv4 addresses.In seiner Rolle als CG-NAT arbeitet der AFTR sogar noch etwas aufwändiger als ein Standard-CG-NAT-Router, der nicht für DS-Lite verwendet wird (also nicht zugleich ein AFTR ist):
Zitat aus RFC6333-Chapter 6.6:
6.6. Extended Binding Table
The NAT binding table of the AFTR element is extended to include the
source IPv6 address of the incoming packets. This IPv6 address is
used to disambiguate between the overlapping IPv4 address space of
the service provider customers.
By doing a reverse lookup in the extended IPv4 NAT binding table, the
AFTR knows how to reconstruct the IPv6 encapsulation when the packets
come back from the Internet. That way, there is no need to keep a
static configuration for each tunnel.Zu 192.0.0.1:
Wenn da als Adresse 192.0.0.1 angezeigt wird, und nichts von DS-Lite steht, dann ist es auch kein DS-Lite, sondern "normales" CGNAT.
Im OpenWrt-Forum gibt es einen Log-Auszug, der eindeutig zeigt, dass diese Adresse direkt über PPPoE zugewiesen wird, ohne DS-Lite-Tunnel: https://forum.openwrt.org/t/ipv4-ipv6-vo…ermany/214381/3
Ja, wenn ich mir den verlinkten Thread im OpenWRT-Forum anschaue, scheint dort, sofern ich das richtig deute, tatsächlich eine IPv4-Kommunikation über die dem WAN-Port des Routers per PPP-IPCP zugewiesene IP-Adresse 192.0.0.1 zustande zu kommen:
Das ist tatsächlich kurios, denn der IPv4-Range 192.0.0.0/29 (also die 8 Adressen 192.0.0.0 - 192.0.0.7) ist von der IANA in seiner IPv4 Special-Purpose Address Registry als "IPv4 Service Continuity Prefix" mit der Eigenschaft "Globally Reachable = False" vermerkt. Der Range wurde ursprünglich in RFC6333-Chapter 5.7 als well-known in der dort beschriebenen Bedeutung (als Range für die Adressvergabe der Endpunkte B4+AFTR des IPv4-in IPv6-Tunnels) definiert und wurde später gemäß RFC7335 als "IPv4 Service Continuity Prefix" verallgemeinert.
Für mich heißt das: Der Range 192.0.0.0/29 ist global nicht eindeutig routebar (ähnlich dem "Shared address space" 100.64.0.0/10) - wie Vodafone hiermit eine IPv4-Kommunikation hinbekommt, erscheint vor diesem Hintergrund rätselhaft.
Ich dachte eigentlich die Hotline hat es verstanden wo das Problem liegt.
Nun ja - Zitat (Abraham Maslow): "Wer als Werkzeug nur einen Hammer hat, sieht in jedem Problem einen Nagel"
Welcher Endnutzer wird das als NAT-Problem erkennen und nicht davon ausgehen, dass die Website kaputt ist?
Ich 
, siehe #17. Aber ich bin da wohl auch eine Sonderfall.
An meinem DG-Anschluss habe ich auch deutlich bessere Latenz/RTT-Werte, hier gemessen von meiner RIPE-Atlas Probe (hängt direkt am Router) über den letzten Monat zu "well known" Zielen:
Kaufmännische Entscheidungen trifft man deshalb technologieneutral.
Das ist ein schöner Satz.
Meine Optionen als Privatmensch vor Ort sind: VDSL (Telekom), Glasfaser (DG) und LTE. Wie sähe hier deine technologieneutrale kaufmännische Entscheidung aus?
Auch im Falle der DG bleibt nur das konsequente fristlose Kündigen der Verträge und technologieneutrale Wechsel zum Wettbewerb mit funktionierendem IPv6. Letztendlich darf kein Geld mehr fließen, das ist einzige Variable, auf die der Endkunde Einfluss hat.
Dumm nur, wenn das der Glasfaser-Monopolist vor Ort ist.
Dafür ist ein Feldtechniker nicht ausgebildet und in der falschen Gehaltsgruppe. Diese Probleme (verursachen und) lösen Leute mit Hochschulabschluss, die fahren nicht raus zum Kunden.
Mag sein, dass ich hier tatsächlich zuviel erwarte.
Aber wenn dem so ist, stellt sich mir die Sinnfrage, warum man dann überhaupt einen Feldtechniker raus schickt (ach so, klar, hat der Kunde ja angefordert - erfüllen wir ihm halt den Wunsch und berechnen ihm die Service-Pauschale).
Oder anders gefragt: Wie soll der betroffene Kunde vermitteln, dass da ein komplexes Problem im Provider-Backend vorliegt, das nur durch Leute mit Hochschulabschluss begreif- und lösbar ist, wenn seine Ansprechpartner im Service selbst auch nicht besser (vermutlich sogar noch deutlich schlechter) qualifiziert sind als der Feldtechniker?
Wenn der Kunde sich dann eigeninitiativ unter Hinzunahme von Fremdhilfe, z.B. hier über das Forum (und ich helfe hier auch gerne), in die Problemanalyse begibt und diese sogar zu einer fundierten Diagnose führt, die er hernach auf dem Silbertablett servieren kann, dann kann man doch eigentlich auch von einem Service-Mitarbeiter oder eingangs angeprochenem Feldtechniker erwarten, dass er erkennt, dass hier seine Lösungsmöglichkeiten überschritten sind, und er das Problem wenigstens an einen 2nd/last-Level-Support (wo vielleicht die erwarteten Problemversacher und -löser mit Hochschulabschluss sitzen) weiterleitet. Und zwar nicht erst, nachdem der Kunde 10 Tickets aufgemacht und mit Kündigung gedroht hat.
Wähle aus, welche Kategorien Du erlaubst. Für jede Kategorie kannst Du über „Details anzeigen“ sehen, welche Cookies und Skripte konkret geladen werden, welche Empfänger beteiligt sind und wie lange gespeichert wird.
Weitere Informationen: Datenschutzerklärung · Impressum
