Beiträge von ::1

Zitat von UschiM

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.

Zitat von UschiM

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.

Zitat von jelich

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)?

Zitat von mbo77

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.

Zitat von DLMttH

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:

Zitat von jan

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.

Zitat von dgfeuer

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"

Zitat von pufferueberlauf

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:

Zitat von wandler

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?

Zitat von wandler

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.

Zitat von wandler

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.

Ich würde ihm durchaus die gestern ausgewerteten Paketmitschnitte zeigen. Geeignete Ansichtsfilter siehst du ja in den von mir beigefügten Screenshots. Diese zeigen optimal das wichtigste Problem (neben anderen) mit deinem Anschluss.

Wenn er wirklich "vom Fach" ist und nicht nur "die Leitung durchmessen" kann, muss er das Problem erkennen und bestätigen. Vor Ort wird er es allerdings wohl nicht lösen können - es liegt ja in der DG-Infrastruktur.

dgfeuer :

Ok, hier noch die nachträgliche Analyse zu deinem zweiten Mitschnitt:

IPv6-Ping-Test zu google.de und heise.de:

Die IPv6-Adressen können nur über IPv4 (DG-DNS-Resolver 185.22.44.50) aufgelöst werden. Die ICMPv6 echo-Pakete (Type 128) werden auf Ethernet-Ebene ausgehend korrekt an die MAC-Adresse 20:00:00:00:28:25 des DG-Gateways gesendet. Antworten bleiben jedoch aus (no response found!)

DNS-Queries zu den IPv6-DNS-Resolvern der DG:

Dieses Ergebnis war auch schon im ersten Paketmitschnitt zu sehen: DNS-Queries zu 2a00:6020:100::1 und 2a00:6020:100::2 gehen ordnungsgemäß raus (auf Ethernet-Ebene korrekt an die MAC-Adresse 20:00:00:00:28:25 des DG-Gateways) - es kommen aber keine Antworten zurück.

TCP-Verbindungen zu IPv6-Zielen:

Man sieht nur ausgehende SYN (ggf. mit Retransmissions), die auf Ethernet-Ebene korrekt an die MAC-Adresse 20:00:00:00:28:25 des DG-Gateways gesendet werden. Es kommen jedoch nie SYN/ACK von den angesprochenen Zieladressen zurück.

Zusammenfassung:

Keine wirklich neue Erkenntnis, IPv6 funktioniert nur outbound (dein Router macht alles richtig) - nun aber durch hinreichend viele Beispiele belegt.

Der Fehler liegt klar bei DG.

Dein Router scheint vermutlich auch jede Stunde neue IPv6-Adressen zu bekommen, nachdem die jeweils aktuellen nicht verlängert werden und in einen DHCPv6-Timeout der Leasedauer laufen?

Zitat von ::1

Frage:

Kann die Fritzbox diese IPv6-Werte nach Ablauf von T1 per DHCPv6 Renew bzw. spätestens nach Ablauf von T2 per DHCPv6 Rebind verlängern? Falls nicht, müsstest du spätestens nach 3600 Sekunden einen DHCPv6-Fehler in der Ereignisanzeige der FB wegen DHCPv6-Timeout sehen. Im besten Fall würde die FB sofort eine neue DHCPv6-Lease anfordern, was ebenfalls der Ereignisanzeige zu entnehmen wäre. Falls dem so ist, müsstest du jede Stunde entsprechende Log-Einträge sehen. Und hier wäre dann die Preisfrage, ob du jedes Mal andere IPv6-Werte bekommst (ich vermute mal: Ja)?

dgfeuer : Kannst du bitte diese Frage beantworten? Deinen zweiten Trace habe ich kurz angeschaut. Reiche eine Analyse später noch nach. Es sieht aber so aus, als hättest du jetzt nochmal andere IPv6-Adressen bekommen.

Zitat von frank_m

Es ist bekannt, dass sich die Kundenanschlüsse bei der DG gegenseitig erreichen können. Ich sehe bei mir im Log auch Broad- oder Multicastscasts anderer Kundenrouter.

Die hier beobachteten Leaks sind Multicasts an ff02::..., haben also link scope und können sich somit nur vom Sender in dessen WAN-Uplink ausbreiten. Es sind ja NS, also ND-Pakete zur MAC-Adressauflösung (hier der DG-Routeradresse). Wenn die in anderen Netzen als dem eigenen WAN-Uplink auftauchen, ist das ein Fehler.

Ja, die Kundenanschlüsse können sich gegenseitig (per Unicast) erreichen, aber sicherlich nur ordentlich geroutet über die BNG und ggf. die dahinter liegende Infrastruktur (Kundenanschlüsse an verschiedenen BNG).

So, hier nun meine erste Analyse deines Paketmitschnitts:

Das Interessante beginnt im Paket 241 mit einem DHCP Release und in Paket 242 mit einem DHCPv6 Release (Drücken auf den Knopf "Neu verbinden").

Unmittelbar danach (Pakete 244-247) fordert deine FB per DHCP erfolgreich eine IPv4-Adresse für den WAN-Port der FB an (Leasedauer: 1 Stunde).

Auffällig hier: Du bekommst eine andere IPv4-Adresse aus 100.64.0.0/10 als die, die gerade per DHCP Release zurück gegeben wurde. Normalerweise erhält man wieder dieselbe Adresse.

Du bekommst per DHCP-Option das IPv4-Standardgateway der DG mitgeteilt: 100.102.64.1. Deine FB löst in der Folge via ARP (Pakete 255, 258) dessen MAC-Adresse auf: 20:00:00:00:28:25

Bzgl. IPv6 führt die FB zunächst eine DAD (duplicate address detection) für die linklokale Adresse fe80::[...] aus (Pakete 248, 256). Anschließend schickt die FB im Abstand von 4 Sekunden 4x Router Solicitations (RS) (Pakete 257, 294, 320, 351) raus, die aber erst nach 16 Sekunden (gemessen vom ersten RS) vom DG-Gateway (fe80::22, MAC: 20:00:00:00:28:25 wie oben) mit einem RA (Paket 384) beantwortet werden.

Der Inhalt des RA ist soweit ok:

• Cur Hop Limit: 64
• M-Flag gesetzt
• Router lifetime > 0: 4500 Sekunden
• MTU: 1500
• Source link-layer address: 20:00:00:00:28:25

Endlich kann per DHCPv6 (Pakete 379, 380 mit Rapid Commit) erfolgreich IPv6 angefordert werden. Du bekommst eine IPv6-Adresse für den WAN-Port (IA_NA) und ein /56-Präfix für das LAN (IA_PD), beides mit einer Lease-Dauer von 3600 Sekunden und den Renew- bzw. Rebind-Timern (T1, T2) von 1800 bzw. 2880 Sekunden.

Auffällig auch hier: Sowohl die WAN-Port-Adresse, als auch dein LAN-Präfix weichen von den Werten ab, die du vorher zugewiesen bekommen hast (vgl. Werte im DHCPv6-Release, s.o.). Normalerweise bekommt man stets dieselben Werte zugewiesen.

Frage: Kann die Fritzbox diese IPv6-Werte nach Ablauf von T1 per DHCPv6 Renew bzw. spätestens nach Ablauf von T2 per DHCPv6 Rebind verlängern? Falls nicht, müsstest du spätestens nach 3600 Sekunden einen DHCPv6-Fehler in der Ereignisanzeige der FB wegen DHCPv6-Timeout sehen. Im besten Fall würde die FB sofort eine neue DHCPv6-Lease anfordern, was ebenfalls der Ereignisanzeige zu entnehmen wäre. Falls dem so ist, müsstest du jede Stunde entsprechende Log-Einträge sehen. Und hier wäre dann die Preisfrage, ob du jedes Mal andere IPv6-Werte bekommst (ich vermute mal: Ja)?

Sichtbar (Filter ipv6 && ipv6.addr != ff02::1:ff00:22) ist nun folgende Problematik bzgl. outbound bzw. inbound IPv6-Kommunikation zu/von globalen IPv6-Zielen:

Man sieht einzig ausgehende DNS-Requests (nach ipv64.net) von der WAN-Port-Adresse deiner FB (die ist ja DNS-Forwarder für die Clients in deinem LAN) zu den DNS-Resolvern der DG (2a00:6020:100::1 und 2a00:6020:100::1), die auf Ethernet-Ebene auch korrekt an die MAC-Adresse 20:00:00:00:28:25 des DG-Gateway gesendet werden. Gleichwohl sieht man keinerlei IPv6-Inbound-Traffic, insbesondere werden die DNS-Requests an die IPv6-DNS-Resolver der DG nie von diesen beantwortet.

Sämtliche DNS-Auflösungen funktionieren nur über die IPv4-DNS-Resolver der DG (185.22.44.50 und 185.22.45.50), diese liefern dir auch die IPv6-Adressen angefragter Ziele (z.B. www.google.de) zurück. Allerdings sehe ich keine ausgehenden ICMPv6 Echo-Pakete (Ping) zur IPv6-Adresse von www.google.de oder zu irgendwelchen anderen IPv6-Zielen. Aber egal: die DNS-Requests zu den IPv6-DNS-Resolvern der DG, die von denen nicht beantwortet werden, sind hinreichende Indizien, dass es da ein IPv6-Problem seitens DG gibt.

Dann ist mir noch folgende Merkwürdigkeit aufgefallen:

Zu deinem Kundenanschluss werden Fremdpakete (Neigbor Solicitations) von Fremdroutern anderer Kundenanschlüsse "geleakt":

Es werden etwa in Sekunden-Abständen "Neighbor Solicitations" an die aus der Adresse fe80::22 des DG-Gateways abgeleitete SNMA (Solicited Node Mulitast Address) ff02::1:ff00:22 (MAC: 33:33:ff:00:00:22) an deinem Kundenanschluss (Paketmitschnitt im "promiscuous mode" am WAN-Port deiner FB) mitgeschnitten (Filter: icmpv6.type==135 && ipv6.addr==ff02::1:ff00:22). Die haben sich da verirrt und dort nichts verloren!

Ich habe Leaks von insgesamt 14 AVM- und 15 Sagemcom Broadband SAS-Routern gefunden. Eine Liste von deren linklokalen- und MAC-Adressen habe ich dir zugeschickt.

Gerade das letzte Phänomen ist ein gutes Indiz einer DG-seitigen Fehlkonfiguration deines Anschlusses - damit kannst du dort "Druck" aufbauen! Und alles mit Daten belegen.

Mich erinnert das an einen ähnlichen Fall von gordrin , siehe #89. Ich weiß da aber gar nicht, ob dessen Problem inzwischen gelöst ist.

Auch auffällig:

Dein Anschluss liegt im Block 2a00:6020:8f00::/41. Das ist offenbar einer der Ranges, in denen die DG ein neues IPv6-Adressierungskonzept einführt, und in denen es deshalb gelegentlich Probleme mit IPv6 gibt. Andere Beispiele von ähnlich gelagerten und hier im Forum diskutierten Problemfällen liegen in den Ranges 2a00:6020:7380::/41, 2a00:6020:7680::/41 und 2a00:6020:7880::/41 - dort kommt ebenfalls das neue Adressierungskonzept zum Einsatz. Siehe #152 bzw. #10.

Ergänzung:

Die fehlenden (also im Paketmitschnitt nicht gefundenen) IPv6-Pings zu IPv6-Zielen im Internet sind vermutlich nur als IPv4-Pings (ICMP echo request) rausgegangen, weil du nur

ping [Ziel]

verwendet hast. Dummerweise sehe ich die IPv4-Pings nicht, weil der Ansichtsfilter nicht icmp enthält.

Es wäre aber gut, doch noch anhand von Beispielen zu belegen, dass IPv6 nur outbound funktioniert (Forwarding zur MAC-Adresse des DG-Gateways), von dort aber aber nie Antworten zurück kommen.

Mach dazu bitte nochmal einen Paketmitschnitt an der FB, während du an einem Windows-PC im LAN explizit für ein paar Ziele mit IPv6-Adressen

ping -6 [Ziel]

ausführst. Z.B. google.de, heise.de, facebook.com, wikipedia.org 

Bitte anschließend den Trace in Wireshark mittels icmpv6 || icmp || dns || arp filtern+exportieren und mir zur Nachanalyse schicken.

Zitat von dgfeuer

so wie du beschrieben hast. Von der FritzBox. Reconnect und nochmal einen ipv6 test von einem laptop aus

wundert mich halt, weil der letzte Stand doch war, dass du an der FB noch gar kein IPv6 bekommen hast. Aber ich schaue mir mal deinen Capture an ...

Zitat von dgfeuer

Sollte ich den ONT auch nochmal zurück setzen ?

Also wenn da alles "grün" leuchtet (falls du den Nokia hast), sehe ich dafür keine Notwendigkeit. Anderseits schadet es auch nicht.

Zitat von dgfeuer

Datei kommt gleich.

Kannst du gerne schicken, nur was hast du denn da genau mitgeschnitten?

Zitat von dgfeuer

durchgeführt. Würde dir das gerne senden aber erlaubt ist nur bis 1 MB.

Du kannst den Mitschnitt verkleinern, indem du in Wireshark nur die relevanten Pakete filterst:

icmpv6 || dhcpv6 || dns || dhcp || arp

Gefilterte Ansicht anschließend speichern: "Datei | Ausgewählte Pakete exportieren..." und unter "Paketbereich" die Default-Einstellungen (Alle Pakete + Angezeigt) belassen. Die PCAP-Datei kannst du anschließend noch zippen, sollte aber auch plain schon klein genug sein.

Zitat von dgfeuer

die aktivierungsseite funktionierte auch nicht

Um die Sache nicht unnötig kompliziert zu machen, würde ich nicht gleich mit Fiber anschließen. Probier doch erst Mal via WAN-Uplink-Port und ONT.

Zitat von frank_m

Aber im Heimnetz zu Hause immer noch eher unüblich.

naja, ob dem so ist, wäre ich mir nicht so sicher - in der Fritzbox würde Adressvergabe per DHCPv6 (IA_NA) statt SLAAC mit der folgenden Einstellung bewirkt:

Aber gut, Default-Einstellung ist m.W. seit Fritz-OS V8.03 die zweite Option (DNS-Server und IPv6-Präfix (IA_PD) zuweisen), bei früheren Versionen war es wohl die erste Option (Nur DNS-Server zuweisen).

Wer da DHCPv6 für LAN/WLAN-Geräte wollte, musste schon überhaupt zu diesen Einstellungen vordringen und dann auch noch die Wirkungsweise der einzelnen Optionen verstanden haben.