Mal wieder: Kein IPv6 bei Deutsche Glasfaser

DaSokas : Ich möchte nochmals auf folgende Passage eingehen:

Zitat von ::1

Ein erhaltenes RA enthält als Option ja auch die zur (linklokalen) DG-Gateway-Adresse gehörende MAC-Adresse - sie sollte daher auf diesem Wege auch im Neighbor-Cache des WAN-Ports deiner Palo landen. Allerdings wird sie nach Ablauf der maximalen Cachedauer dort gelöscht. Schlecht, wenn die Cachedauer < mittlere Zeitdauer zwischen dem Erhalt zweier RA ist. Kannst du evtl. die Cachezeit des Neighbor-Caches hochdrehen? Z.B. auf die Router-Lifetime (siehe im RA, default: 1800s). Aber das wäre auch nur ein Workaround, nur etwas besser als ein statischer Eintrag im Neighbor-Cache.

In dem Packet Capture sendet das DG-Gateway RA mit folgendem Inhalt:

• Quell-Adresse (=Default-Gateway: fe80::ff:fe04:201)
• Router lifetime: 1800s
• Reachable Time: 0
• Retrans Timer: 0
• Source link-layer address option: 02:00:00:04:02:01

Chapter 6.3.4 in RFC4861 informiert:

6.3.4.  Processing Received Router Advertisements
   
   ...
   
   After extracting information from the fixed part of the Router
   Advertisement message, the advertisement is scanned for valid
   options.  If the advertisement contains a Source Link-Layer Address
   option, the link-layer address SHOULD be recorded in the Neighbor
   Cache entry for the router (creating an entry if necessary) and the
   IsRouter flag in the Neighbor Cache entry MUST be set to TRUE.
   
   ...
   
   If a Neighbor Cache entry is created
   for the router, its reachability state MUST be set to STALE as
   specified in Section 7.3.3.  If a cache entry already exists and is
   updated with a different link-layer address, the reachability state
   MUST also be set to STALE.
   
   ...

Aus Quelladresse fe80::ff:fe04:201 und Link-layer-Adresse 02:00:00:04:02:01 sollte ("SHOULD") deine Palo also tatsächlich einen Neighbor-Cache-Eintrag generieren (wenn auch im Status "STALE"), wobei wegen "Reachable Time" = 0 lokale Voreinstellungen der Palo für die Cache-Dauer gelten.

Falls also tatsächlich ein Eintrag generiert wird (wird er?) und du die Cache-Dauer manuell auf signifikant > 1800/3=600s (mittlere Dauer zwischen zwei RA) einstellen kannst, müsstest du den Cache-Eintrag dauerhaft halten, mithin einen statischen Eintrag vermeiden können.

Andererseits: Die MAC-Adresse 02:00:00:04:02:01 ist ja wegen der eingefärbten 2 keine global gültige, sondern administrativ generiert. Diese und die daraus nach "modified EUI64" abgeleitete Gateway-Adresse fe80::ff:fe04:201 ändern sich nach Beobachtungen an meinem Anschluss niemals (aber man soll ja nie "nie" sagen...).

Zitat von ::1

Falls also tatsächlich ein Eintrag generiert wird (wird er?) und du die Cache-Dauer manuell auf signifikant > 1800/3=600s (mittlere Dauer zwischen zwei RA) einstellen kannst, müsstest du den Cache-Eintrag dauerhaft halten, mithin einen statischen Eintrag vermeiden können.

Der Standard-Wert für die Reachable Time der Palo beträgt 30s. Ich habe die Reachable Time manuell auf 1800s gestellt um sicherzustellen, dass ich nicht zu langsam bin und den Eintrag in der ND-Table einfach verpasst habe. Die Palo erstellt anscheinend keinen Eintrag in der ND-Table.

Der RFC formuliert diesbezüglich auch nur "SHOULD", nicht "MUST". Wenn die Palo einen Eintrag erzeugt, müsstest du ihn nach Erhalt eines RA sehen.

Noch eine andere Frage:

In deinem Packet Capture habe ich keinerlei NS gesehen, die vom DG-Gateway an die Palo gesendet werden. War das nur in diesem Capture der Fall, oder sieht man auch keine ankommenden NS bei längeren Laufzeiten? Ein NS von der Gegenstelle enthält ja ebenfalls eine "Source link-layer address option", mit der die Palo einen Neighbor-Cache-Eintrag generieren könnte bzw. würde.

Übrigens: In diesem Post zu einem ähnlichen Problem (erhält IPv6-Adressen, kann aber dennoch nicht via IPv6 mit dem Internet kommunizieren) habe ich nach Auswertung eines Packet Capture die folgende Beobachtung festgehalten:

"Die IPv6-Kommunikation beschränkt sich auf den Austausch von ND-Paketen (NS, NA, RA) mit der DG-Gegenstelle (fe80::22). Auch hier auffällig: Du erhältst unzählige Neighbor-Advertisments (NA) als Unicasts an linklokale IPv6-Adressen, die vermutlich nicht zu deinem Anschluss gehören, und die als "solicited reply" geflagt sind, obwohl von deinem Router zuvor keine dazu passenden Neighbor-Solicit (NS) gesendet wurden."

Ich hatte dann mal näher anhand der OUI der Ziel-MAC-Adressen der fehlgeleiteten NA festgestellt, dass sie alle zu AVM bzw. SAGEMCOM (von denen ist der einfachere DG-Mietrouter) gehören.

Vielleicht werden die NA zu den von deiner Palo gesendeten NS ja auch zu anderen Kundenanschlüssen fehlgeleitet ...

Ich bin über den Klassik Roter von DG mit dem Netz verbunden. Diese Seite

https://ipv4.ipv6-test.netcologne.de/index.html.de_…%20(via%20IPv4).

zeigt mir konsequent eine ipv6 Verbindung an. Wenn ich allerdings über VPN ins Netz gehe habe ich nur ipv4 und das bei mehreren Servern.

Ich bin Laie, kenne mich mit den Zusammenhängen nicht aus, aber eventuell erklärt dies warum einige keine ipv6 Konnektivität haben.

Zitat von Hotte

Wenn ich allerdings über VPN ins Netz gehe habe ich nur ipv4 und das bei mehreren Servern.

Wenn die VPN Verbindung nur IPv4 zur Verfügung stellt, dann ist das nicht überraschend. Das ist einer der Gründe, warum ich bei solchen Fragen auch immer nach Screenshots von "ipconfig /all" und "route print" frage. Da sieht man solche Sachen relativ schnell.

Nur werde ich bei solchen Fragen gerne mal attackiert und man sucht im TKG nach Paragraphen, um den Internetanbieter verklagen zu können, anstatt einfach mal einen Blick auf die Netzwerkverbindungen zu werfen.

Zitat von frank_m

Nur werde ich bei solchen Fragen gerne mal attackiert und man sucht im TKG nach Paragraphen, um den Internetanbieter verklagen zu können

Fang doch nicht wieder mit dem Blödsinn an.

Zitat von ::1

In deinem Packet Capture habe ich keinerlei NS gesehen, die vom DG-Gateway an die Palo gesendet werden. War das nur in diesem Capture der Fall, oder sieht man auch keine ankommenden NS bei längeren Laufzeiten?

Da ich das selbst nicht mehr im Kopf hatte, habe ich einen längeren Packet Capture durchgeführt. Die Palo erhält keine NS Nachrichten, weder vom DG Gateway, noch von anderen Routern.

Zitat von ::1

Vielleicht werden die NA zu den von deiner Palo gesendeten NS ja auch zu anderen Kundenanschlüssen fehlgeleitet ...

Wenn dem wenigstens so wäre, allerdings wurde ein Routing-Problem von Anfang an von der DG ausgeschlossen. Ich wüsste nicht, wie ich das auf meiner Seite überprüfen könnte.

Noch ein Update: Ich habe eine weitere Antwort von der DG erhalten, dass das Problem auf meiner Seite liegen würde und ich bitte mit dem Hersteller der Firewall in Kontakt treten soll, da dieser - und ich zitiere - "da dieser direkten Zugriff auf das Gerät hat und Ihnen gezielt bei der Fehlerbehebung weiterhelfen kann.".

Ich habe jetzt erneut eine Rückfrage gestellt, wie die Techniker zu dem Entschluss gekommen sind, dass das Problem bei mir liegen würde, in der Hoffnung, dass die "Techniker" konkret erklären, was das Problem ist..

Zitat von Hotte

Wenn ich allerdings über VPN ins Netz gehe habe ich nur ipv4 und das bei mehreren Servern.

Ruf doch mal wasistmeineip auf, wenn du über VPN ins Netz gehst. Dort wirst du wahrscheinlich nur eine IPv4-Adresse sehen, die nicht dir, sondern dem VPN-Anbieter gehört (deshalb nutzt du ja auch VPN).

Zitat von DaSokas

Wenn dem wenigstens so wäre, allerdings wurde ein Routing-Problem von Anfang an von der DG ausgeschlossen. Ich wüsste nicht, wie ich das auf meiner Seite überprüfen könnte.

NS/NA-Kommunikation erfolgt ja stets nur link-lokal. Wenn sie also nicht funktioniert, kann das nicht an einem Routing-Problem liegen. Ein solches liegt ja auch nicht vor, denn IPv6 funktioniert problemlos mit dem statischen Neighbor-Cache-Eintrag. (Nachtrag: Entschuldigung, deine Aussage bezog sich ja auf die von mir zitierten fehlgeleiteten NA-Antworten zu anderen Kundenanschlüssen als dem, aus dem das anfordernde NS kam - ja, insofern ein "Fehlrouting", obwohl es streng genommen kein "Routing" ist, sondern ein Konfigurationsfehler des BNG)

Ich würde nochmal ein Packet-Capture von einem DG-Connect, beginnend mit der WAN-Interface-Initialisierung erstellen, das alle relevanten Pakete (Raw-Daten geeignet filtern: icmpv6 || dhcpv6) enthält. Hinweis: Dein gezeigter Packet Capture bestand aus zwei getrennten Traces für beide Richtungen. Diese kannst du in Wireshark wie folgt mergen: Öffne erst eine der beiden Dateien. Wähle dann "Datei | Zusammenführen...". Aktiviere im Dateiauswahl-Dialog die Option "Chronologisch zusammenführen" und wähle anschließend die andere Datei aus. Anschließend den Merge unter separatem Namen speichern.

Wie auch schon mehrfach hier im Forum empfohlen, verwende unbedingt das DG-Kundenportal und mache dort unter "Service | Kontaktformular" ein Ticket auf. Dort hast du genügend Raum, das Problem möglichst präzise zu beschreiben. Füge auch einen Screenshot des Packet Capture bei, das allein ist schon sehr aussagekräftig. Die Capture-Datei solltest du natürlich als Attach mit anhängen. Du kannst ja auch noch gerne deinen Einstiegs-Post in diesem Thread mit verlinken.

Da deine technische Argumentation ziemlich schlüssig ist, kannst du auch etwas tougher auftreten und durchaus Regress-Ansprüche andeuten. Ich habe gelernt, dass bei DG letzteres tatsächlich weiterhelfen kann (leider, ich würde mir das auch anders wünschen).

Zitat von ::1

NS/NA-Kommunikation erfolgt ja stets nur link-lokal. Wenn sie also nicht funktioniert, kann das nicht an einem Routing-Problem liegen. Ein solches liegt ja auch nicht vor, denn IPv6 funktioniert problemlos mit dem statischen Neighbor-Cache-Eintrag.

Das habe ich nicht ganz klar kommuniziert, genau darum beanstande ich es auch nicht.

Zitat von ::1

Ich würde nochmal ein Packet-Capture von einem DG-Connect, beginnend mit der WAN-Interface-Initialisierung erstellen, das alle relevanten Paket (Raw-Daten geeignet filtern: icmpv6 dhcpv6) enthält. Hinweis: Dein gezeigter Packet Capture bestand aus zwei getrennten Traces für beide Richtungen. Diese kannst du in Wireshark wie folgt mergen: Öffne erst eine der beiden Dateien. Wähle dann "Datei | Zusammenführen...". Aktiviere im Dateiauswahl-Dialog die Option "Chronologisch zusammenführen" und wähle anschließend die andere Datei aus. Anschließend den Merge unter separatem Namen speichern.

Das habe ich die letzten vier Tickets schon gemacht, der einzige Unterschied zwischen deinem Vorschlag und dem was ich gemacht habe ist, dass ich keine Filter für ICMPv6 und DHCPv6 erstellt habe.

Zur Erklärung: Ich führe alle meine Tests ausschließlich auf der Palo durch. Solange ich nicht sicher bin, dass das Problem seitens der DG nicht behoben ist, möchte ich kein IPv6 Prefix in meinem Netzwerk bekannt geben, damit ich wenigstens keine Timeouts habe.

Zitat von ::1

Wie auch schon mehrfach hier im Forum empfohlen, verwende unbedingt das DG-Kundenportal und mache dort unter "Service | Kontaktformular" ein Ticket auf. Dort hast du genügend Raum, das Problem möglichst präzise zu beschreiben. Füge auch einen Screenshot des Packet Capture bei, das allein ist schon sehr aussagekräftig. Die Capture-Datei solltest du natürlich als Attach mit anhängen. Du kannst ja auch noch gerne deinen Einstiegs-Post in diesem Thread mit verlinken.

Genau so eröffne ich meine Tickets. Ich stimme der Aussage, dass dort "genügend Raum" sei, allerdings nicht zu. Die Zeichengrenze liegt bei 2,000 Zeichen, was zwar viel klingen mag, aber für eine technische Problemschilderung unzureichend ist.

Zitat von ::1

Da deine technische Argumentation ziemlich schlüssig ist, kannst du auch etwas tougher auftreten und durchaus Regress-Ansprüche andeuten. Ich habe gelernt, dass bei DG letzteres tatsächlich weiterhelfen kann (leider, ich würde mir das auch anders wünschen).

Der Teil interessiert mich, besonders weil ich die BNetzA eingeschaltet hatte und man mich dort, nachdem man mir unterstellt hat, dass ich keine Ahnung von der Materie hätte, darüber informiert, dass es keine gesetzliche Grundlage für diesen Fall gäbe.

Ich habe eine funktionierende Internetverbindung, damit sei der Internetzugang im Sinne des TKG nicht gestört. Das TKG macht keine Vorgaben, dass eine Konnektivität via IPv4 oder IPv6 gegeben sein müsse. Damit weigert sich die BNetzA diesen Fall zu bearbeiten.

Zitat von DaSokas

Ich habe eine funktionierende Internetverbindung, damit sei der Internetzugang im Sinne des TKG nicht gestört. Das TKG macht keine Vorgaben, dass eine Konnektivität via IPv4 oder IPv6 gegeben sein müsse. Damit weigert sich die BNetzA diesen Fall zu bearbeiten.

Die BNetzA halt, manchmal kommt die sich mit ihrer dualen Persoenlichkeit ("Vertreter der Endkunden", "Partner der ISPs") selber in die Quere...

Dabei ist der Umstand eigentlich relativ einfach:

es gibt Bereiche des INternets die nicht per IPv4 erreicht werden koennen

es gibt Bereiche des Internet die nicht per IPv6 errreicht werden koennen.

Daher sollte es selbstverstaendlichn sein, dass ein ISP dafuer sorgt, dass alle Bereiche des Internets fuer siene Kunden erreichbar sind. Das Produkt heisst ja Internetzugang, nicht IPv4-oder IPv6-Internetzugang. IMHO ist das eine haltbare Interpretation der gesetzlichen Ausgangslage, die die BNetzA durchaus selber treffen koennte, wenn sie den wollte. Hier will sie IMHO nicht, weil zu sehr Partner der ISPs.

Zitat von DaSokas

Ich habe eine funktionierende Internetverbindung, damit sei der Internetzugang im Sinne des TKG nicht gestört.

Bei fehlendem IPv6 kann man das anders sehen, da nur mit IPv4 dein Anschluss nicht von außen erreichbar ist, was gemäß der EU Vorgaben aber der Fall sein müsste - auch wenn es sich so explizit im TKG nicht wieder findet. Von daher führt meines Erachtens an Anschlüssen mit CGNAT IPv4 kein Weg an einer funktionierenden IPv6 Verbindung vorbei.

Zitat von DaSokas

Ich stimme der Aussage, dass dort "genügend Raum" sei, allerdings nicht zu.

Dann würde ich die fundierte Problembeschreibung in ein separates Dokument auslagern und dieses als PDF-Attach anhängen.

Zitat von DaSokas

Das TKG macht keine Vorgaben, dass eine Konnektivität via IPv4 oder IPv6 gegeben sein müsse.

Das wäre ja ziemlich sinnfrei!?

Aber ja, das Problem ist herausfordernd, du kannst nur hoffen, bei DG einen last-level-Techie zu finden, der es versteht und in die richtigen Bahnen leiten kann. Und genau das passiert aber leider häufig erst nach Regress- oder Kündigungsandrohungen.

Eine Unsicherheit in der technischen Analyse habe ich noch: Welchen View zeigen deine Captures?

1. Den Traffic, bevor (outbound) eine Firewall-Regel greift, die das Paket dann doch verwirft, und (inbound), nachdem zuvor schon eine Firewall-Regel gegriffen und ein Paket verworfen hat, so dass du es im Capture gar nicht mehr siehst?
2. Den Traffic so, wie er (nach Berücksichtigung von FW-Regeln) outbound die Firewall verlässt, bzw. inbound, bevor eine FW-Regel greift?

Im Fall (1) würdest du genau die Captures sehen, die du durchgeführt hast - tatsächlich hätte deine Firewall aber ausgehend und einkommend NS/NA gedroppt.

Die Palo ist schon ein ziemliches Monster. Die Doku zu PAN-OS wirkt erschlagend - was ich dort suchte, fand ich jedenfalls nicht.

Zitat von pufferueberlauf

Dabei ist der Umstand eigentlich relativ einfach:

es gibt Bereiche des INternets die nicht per IPv4 erreicht werden koennen

es gibt Bereiche des Internet die nicht per IPv6 errreicht werden koennen.

Daher sollte es selbstverstaendlichn sein, dass ein ISP dafuer sorgt, dass alle Bereiche des Internets fuer siene Kunden erreichbar sind.

Der Meinung bin ich auch, allerdings habe ich in meiner jetzigen Position keine weiteren Möglichkeiten eine Problemlösung zu erzwingen.

Da ich hier in einem relativ kleinen Dorf wohne habe ich auch keine wirklichen alternativen zur DG, da diese hier nicht existieren. Die DG ist leider der einzige Glasfaser-Anbieter, alternativ könnte ich bei der Telekom einen DSL Tarif buchen bis maximal 175 MBit/s. Dafür würde ich dann monatlich "nur" 5,00€ mehr bezahlen, allerdings weniger als die Hälfte meiner jetzigen Bandbreite erhalten..

Ach, noch eine Idee: Um die Palo als Ursache wirklich auszuschließen, klemm doch einfach mal einen PC direkt an den Anschluss (aber erst mal 1 Stunde warten!). In deinem Packet Capture dort solltest du dann auch keine NS/NA-Kommunikation sehen, wenn es tatsächlich an DG liegt.

Zitat von DaSokas

Der Meinung bin ich auch, allerdings habe ich in meiner jetzigen Position keine weiteren Möglichkeiten eine Problemlösung zu erzwingen.

Das verstehe ich, ich habe nur meiner Frustration ob der Position der BNetzA Luft gemacht.

Allerdings vermute ich, dass die DG eigentlich vorhat funktionierendes IPv6 zu liefern und es hier kein Kampf gegen den ISP ist, sondern gegen die Prozesse des ISP die Techniker von Endkunden trennen, denn eigentlich habt ihr das selbe Interesse und IMHO waere es vielleicht hilfreich wenn die DG Technik mit Dir Kontakt aufnaehme, nicht dass meine Meinung da igendetwas aendern koennte...

Zitat von DaSokas

Da ich hier in einem relativ kleinen Dorf wohne habe ich auch keine wirklichen alternativen zur DG, da diese hier nicht existieren. Die DG ist leider der einzige Glasfaser-Anbieter, alternativ könnte ich bei der Telekom einen DSL Tarif buchen bis maximal 175 MBit/s. Dafür würde ich dann monatlich "nur" 5,00€ mehr bezahlen, allerdings weniger als die Hälfte meiner jetzigen Bandbreite erhalten..

Ich wuerde da schon weiter mit der DG arbeiten... DSL ist letztlich keine dauerhafte Loesung. Aus eigener Erfahrung mit Problemen bei O2 muss ich sagen, dass manche Loesungen Monate in Anspruch nehmen und Endkunden wie wir meist nicht/kaum mit Zustandsupdates versorgt werden. Ich hoffe mal die Techniker der DG arbeiten still und heimlich an einer Loesung.

Du kannst dir mit Hilfe eines VPS für 1 €/Monat eine Krücke bauen. Darüber und mit Hilfe von Tunneln kannst du deine Erreichbarkeit via IPv4 und IPv6 sicherstellen.

Ist natürlich nicht die beste Lösung, aber pragmatisch.

Zitat von ::1

Eine Unsicherheit in der technischen Analyse habe ich noch: Welchen View zeigen deine Captures?

Das ist eine berechtigte Frage.

Die Palo kann Pakete in vier Stages aufzeichnen:

• Receive (zeichnet alle erhaltenen Pakete auf)
• Transmit (zeichnet alle gesendeten Pakete auf)
• Firewall (zeichnet alle von der Firewall zu verarbeitenden Pakete auf)
• Drop (zeichnet alle gedroppten Pakete auf)

Den Packet Capture selbst kann man dann noch mit insgesamt vier Filter-Regeln eingrenzen.

Ich habe meine Packet Captures grundsätzlich so konfiguriert, dass ich alle IPv6 Pakete am WAN Interface für alle vier Stages aufzeichne. Wenn keine Pakete in einer Stage aufgezeichnet werden, dann erstellt die Palo auch keine Datei.

Alle meine Packet Captures benenne ich entsprechend ihrer Stage und schicke alle erstellten Dateien an die DG, damit den Technikern keine Informationen fehlen.

Zitat von ::1

Die Palo ist schon ein ziemliches Monster. Die Doku zu PAN-OS wirkt erschlagend - was ich dort suchte, fand ich jedenfalls nicht.

Ich vermute mal, dass du sowas gesucht hast?

(Das ist noch das alte Interface von PAN-OS. Die GUI sieht inzwischen etwas anders aus, aber die Quintessenz ist die Gleiche)

Zitat von ::1

Ruf doch mal wasistmeineip auf, wenn du über VPN ins Netz gehst. Dort wirst du wahrscheinlich nur eine IPv4-Adresse sehen, die nicht dir, sondern dem VPN-Anbieter gehört (deshalb nutzt du ja auch VPN).

Das ist mir klar, aber wenn jemand, der ähnlich wie ich keine Ahnung hat, ständig VPN anhat und die Verbindung auf IPv6 überprüft könnte vermuten das sein System kein VIp6 kann.

War nur mein Gedanke als ich heute selbst mal getestet hab.