Beiträge von ::1

Formal sieht das gut aus!

Allerdings scheinst du mit jedem Reconnect neue IPv6-Adressen zu bekommen - nach bisherigen Erfahrungen ist das kein gutes Zeichen!

Mach bitte mal Folgendes:

• Starte einen Paketmitschnitt am WAN-Port deiner FB
• Führe an einem deiner PC im LAN folgende PING-Tests aus:
  - ping -6 google.com
  - ping -6 facebook.com
  - ping -6 wikipedia.org
• Stoppe den Paketmitschnitt und poste hier dessen Ergebnis mit dem Ansichtsfilter "icmpv6"

Ich erwarte, dass im Mitschnitt nur ausgehende Pings zu sehen sind, jedoch keine Antworten.

Na, pingen kannst du das NAS von außen natürlich nicht, weil du dafür keine ICMPv6-Freigabe eingerichtet hast (zumindest sehe ich das nicht).

Du kannst laut FB-Freigabe nur einen HTTP-Connect via 9999\tcp testen:

http://[IPv6-Adresse des NAS laut GUA - (2a00:6020: ... :f3ed)]:9999

(IPv6-Adresse muss mit [ ] umgeben werden!)

Nachtrag:

Ich gehe davon aus, dass du die FB-Freigabe für das NAS anhand dessen "IPv6-Interface-ID" und somit passen für die "IPv6-GUA" (und somit nur für diese) eingerichtet hast. Für diese "IPv6-Interface-ID" muss ferner gelten: Sie muss wirklich fest sein, darf sich nach einem Neustart des NAS oder nach der Zuweisung eines neuen IPv6-LAN-Präfix durch DG nicht ändern! Wenn diese "IPv6-Interface-ID" in der Mitte z.B. das Muster "ff:fe" aufweist, und "f3ed" auch am Ende der NAS-MAC-Adresse auftaucht, kannst du davon ausgehen, dass sie tatsächlich konstant ist.

• Ok, ICMPv6 in den RA hast du aufgeklappt -> der Inhalt ist aus meiner Sicht ok.
• Leider hast du es nicht geschafft die DHCPv6-Informationen aufzuklappen (die Protokolle davor kannst du zugeklappt lassen), so dass ich da jetzt leider nicht schlauer werden kann. ...

Aber schau mal in deiner FB unter Heimnetz | Netzwerk | Netzwerkeinstellungen | Button "IPv6-Einstellungen": Dort ganz unten: Was wird da unter "Verwendete IPv6 Präfixe:" angezeigt? Bitte Screenshot posten:

Deine Bilder sind schön aber nutzlos, du musst die Protokolle ICMPv6 bzw. DHCPv6 jeweils aufklicken - deren Inhalte sind relevant. Die reinen Hex-Ausgaben brauche ich nicht - ich bin kein Computer ...

Aber mach bitte mal einen neuen Trace, nachdem du die Voreinstellung der Prefix-Länge deaktiviert hast.

Bzw: Hast du nun ein /56 LAN-Präfix nach Neu-Verbindung zugewiesen bekommen? Dann kannst du dir all den Aufwand sparen.

Zitat von JaFr

Und "Bestimmte Länge für das LAN-Präfix anfordern" steht auf 62 Bit

Bitte deaktivieren oder auf 56 setzen.

Zitat von JaFr

Kann mir jemand beantworten, ob es hier an der Router-Konfiguration oder an der DG liegt?

Jein:

Fragen:

• Hast du die Reconnects (DHCPv6 Release, Pakete 105, 7315) aktiv ("Neu verbinden") in deiner FB ausgelöst?
• Es scheint, als hättest du die Einstellung "Rapid Commit" aktiviert - korrekt?

Es sieht soweit gut aus, die DG-Gegenstelle sendet RA (Pakete 133, 7330) und NA. Per DHCPv6 erhältst du zumindest eine IPv6-Adresse für den WAN-Port (Pakete 114, 7324), aber jeweils unterschiedliche, was verdächtig ist.

Leider kann ich nicht sehen, ob du auch einen /56-LAN-Präfix per DHCPv6-PD bekommst. Dazu müsste man in die DHCPv6-Solicits (Pakete 113, 7323) hereinschauen, ob deine FB IA_PD anfordert, bzw. in die DHCPv6-Replies (Pakete 114, 7324), ob dort IA_PD enthalten ist.

1. Zeige doch mal die aufgeklickten Inhalte der Pakete 113,114,7323,7324.
2. Auch der Inhalt der RA (Pakete 133, 7330) wäre interessant.

Zitat von ConiKost

kein "klassisches" (Keine Ahnung, welcher RFC das grad ist) Prefix Delegation

IPv6 Prefix Delegation (PD) ist ursprünglich im RFC3633 beschrieben, welcher durch Aufnahme in den aktuellen RFC für DHCPv6 (RFC8415) nun aber obsolet ist.

Zitat von ConiKost

sondern RFC7278. ::1 weiß da sicher mehr

Danke für die Blumen, jedoch bin ich im Bereich IPv6 für Mobile-Netze nicht so unterwegs.

Aber ich habe mal recherchiert (ein freundlicher Service von "RFC - für Sie gelesen"):

Wie der zitierte RFC7278 schon im ersten Absatz des Intros besagt, steht DHCPv6-PD erst ab 3GPP Release-10 zur Verfügung.

Kann DHCPv6-PD nicht genutzt werden (weil der mobile ISP es nicht unterstützt), dann beschreibt RFC7278 eine Methode, wie das mobile Endgerät den /64-Präfix, den es standardmäßig per SLAAC bezieht, an ein nachgelagertes LAN durchreichen kann, wenn es sich bei dem Gerät tatsächlich um einen LTE-Router handelt.

Kann hingegen DHCPv6-PD genutzt werden, so beschreibt RFC6653 in Section 3.3, wie das abläuft.

Ansonsten siehe noch RFC6459 als allgemeine Referenz zum Thema.

Durch einen Paketmitschnitt am LTE-Port des Routers könnte man sicherlich herausfinden, welche Methode zum Einsatz kommt (wenn man dort keine DHCPv6-Solicits/Requests mit IA_PD sieht, sondern nur RS/RA für SLAAC, dann ist es die Methode gemäß RFC7278).

Zitat von Luki

Ich weiß es nicht ob diese eine Änderung bei DG zeigt oder ist das reine Zufall.

Naja, zeigt halt die IPv4- oder IPv6-Adresse an, mit der du bei https://icanhazip.com/ aufschlägst. Im Falle von IPv4 ist das die CGNAT-Adresse, der DG, die deinem Anschluss (und anderen) aktuell zugeordnet ist. Im Falle von IPv6 (würde es funktionieren), wäre es die IPv6-Adresse deines Endgerätes.

Die Anzeige eines "leeren Blattes" würde ich so deuten, dass du die Site entweder nicht erreicht hast oder der Service zu dem Zeitpunkt gerade down war.

Zitat von UST

Habt ihr evtl. weitere Vorschläge, um der Quelle der Instabilität näher zu kommen?

Um deine beiden LAN-Kabel (das "kurze" PC <-> Router, das "lange" Router <-> ONT) in Kombination zu testen, folgende Idee:

1. Trenne das "lange" Kabel an beiden Enden vom Router-WAN-Port bzw. ONT.
2. Verbinde das eine Ende des "langen" Kabels mit einem freien LAN-Port deines Routers.
3. Nimm ein Notebook mit LAN-Buchse und verbinde diese mit dem anderen Ende (ONT-Seite) des "langen" Kabels.
4. Schalte das WLAN am Notebook ab.
5. Öffne am Notebook eine Eingabeaufforderung (Win + R | cmd) und gib das Kommando ipconfig ein. Notiere die IPv4-Adresse des Ethernet-Adapters (vermutlich 192.168.178.X).
6. Deaktiviere sicherheitshalber temporär die Windows-Firewall am Notebook: Win + R | firewall.cpl
   Linke Spalte: "Windows Defender Firewall ein- oder ausschalten" - im Folgedialog für privates und öffentliches Netzwerk jeweils "Windows Defender Firewall deaktivieren".
7. Gehe zu deinem Windows-PC am "kurzen" Kabel und öffne dort eine Eingabeaufforderung (Win + R | cmd). Gib dort das Kommando
   
   ping -t 192.168.178.X
   
   ein (ersetze X durch die konkrete, in Schritt 5 notierte IPv4-Adresse des Notebooks)

Lass ein paar Minuten laufen und schau, ob du ähnliche PING-Aussetzer wie oben hast. Falls nein, sind deine Kabel in Ordnung.

Anschließend wieder alles rückbauen - nicht vergessen, am Notebook die Windows-Firewall wieder einzuschalten.

Zitat von kingpin42

Wo ist PPPoE denn Gefrickel und fehlerträchtig ?

Das sicherlich nicht, es passt nur nicht besonders gut mit IPv6 bzw. IPv6/DS-Lite (siehe meine Argumentation in #24).

Bei DualStack ergibt sich m.E. auch eine Unklarheit, ob man IPv4 und IPv6 gemeinsam in einer PPP-Session oder jeweils in einer eigenen PPP-Session fahren möchte. Aber zu diesem Punkt fehlen mir tatsächlich Erfahrungswerte.

Zitat von mbo77

In der Konstellation erhält der primäre Router die Adresse per DHCP.

Das lese ich dort nicht heraus.

Zitat von mbo77

Ist ein 5G-Router und sticht die Adresse durch.

Wenn ich dem Link folge und dort lese, verstehe ich das so, dass der Zyxel (sekundärer Router) das PPPoE eines nachgelagerten (primären) Routers mehr (Bridge-Modus) oder weniger (IP-Passthrough-Modus) transparent durchreicht. Der nachgelagerte (primäre) Router muss dann aber trotzdem PPPoE machen, was dem OP nichts nützt, weil es sein Problem nicht löst.

Zitat von mbo77

Der Zyxel NR7302 macht genau so ein IP pass-through.

genau wie was?

Zitat von DLMttH

Ich vermute, als ISP fühlen sich historisch Viele besser damit, dass der Kunde Zugangsdaten eingeben muss.

Ja, Authentifizierung ist tatsächlich ein gewichtiges Argument, das für PPP bzw. PPPoE spricht.

Allerdings erinnere ich mich an die letzte "Innovation" seitens der Telekom bezüglich meines vormaligen VDSL-Anschlusses, in deren Folge keine Authentifizierung mehr erforderlich war. Es scheint also andere, auf der Infrastruktur beruhende Mechanismen zu geben, die hinreichend gut sicherstellen, dass der Internetzugang nur durch den berechtigten/zahlenden Anschlussinhaber genutzt werden kann.

Ich würde gerne mal eine Grundfrage zu diesem Thread stellen:

Ist es nicht ziemlich sinnfrei seitens eines ISP, DS-Lite ausgerechnet via PPPoE anzubieten?

Meine Überlegung dabei:

• PPPoE bietet nur für IPv4 mit Hilfe des in PPP verfügbaren IPCP (RFC1332) eine zu DHCPv4 analoge Methode der IPv4-Adresszusweisung nebst DNS-Serveradressen (RFC1877). Bei DS-Lite müssen dem Kunden jedoch keine IPv4-Werte zugewiesen werden. Außerdem wird IPv4 bei DS-Lite nicht direkt in PPP übertragen, sondern in IPv6 enkapsuliert (das seinerseits allerdings wieder in PPP enkapsuliert wird). Bezüglich IPv4 ist PPPoE bei DS-Lite also völlig sinnfrei.
• Bezüglich IPv6 im Kontext DS-Lite bietet PPPoE mittels IPv6CP (RFC5072) nur die sehr dürftige Möglichkeit der kollisionsfreien Aushandlung einer linklokalen IPv6-Adresse am WAN-Port des Routers. Globale IPv6-WAN-Adresse (SLAAC/DHCPv6), DNS-Serveradressen (SLAAC/DHCPv6) und PD-LAN-Präfix (DHCPv6) müssen also zusätzlich über eine der in den Klammern genannten Verfahren zugewiesen werden. Die Verwendung von DHCPv6 wäre hier naheliegend, da dies die einzige Methode zur dynamischen Zuweisung des PD-LAN-Präfix ist.

In der Folge ergibt DS-Lite für mich nur in Verbindung mit IPoE einen Sinn.

Daher die Preisfrage:

Ist die aus meiner Sicht unsinnige Kombination DS-Lite/PPPoE dadurch zu begründen, dass der ISP halt aus seiner Historie heraus nur eine PPPoE-Einwahlstruktur zur Verfügung hat und eine Umstellung auf IPoE sehr aufwendig wäre? Oder übersehe ich andere gewichtige Aspekte, die für DS-Lite/PPPoE sprechen?

Zitat von golo120

Wir brauchen die öffentliche feste IP vom ISP. Daher war der Gedanke, zwischen SachsenGigbit Modem und der UDM Pro SE ein "Modem" zu schalten, welches die PPPoE Einwahl übernimmt und dann die feste IP 1:1 via WAN an die UDM Pro Se weitergibt. Die Stichworte hierfür sind „Bridge Mode“, „IP Passthrough“, „PPPoe Passthrough“, „Routed Subnet / Routed LAN“ oder Ähnliches.

Ich kann mir nicht wirklich vorstellen, wie so ein zwischengeschaltetes "Modem" arbeiten sollte: Es würde nun mal Richtung ISP PPPoE sprechen (müssen) und hätte damit die öffentliche IPv4-Adresse für sich zugewiesen - die kann es folglich nicht mehr nach "hinten" zu deinem Router weitergeben (und dabei noch das L2-Protokoll von PPP auf Ethernet wechseln).

"Passthrough" würde bedeuten, dass dein Router zusätzlich PPPoE machen und das zwischengeschaltete "Modem" dies nur durchreichen würde. Aber dann macht dein Router ja doch wieder PPPoE mit der von dir bemängelten schlechten Performance. Zudem müsste dir dein ISP eine zweite öffentliche IPv4-Adresse spendieren, hängt vom Vertrag ab.

Nachtrag:

Im Grunde müsste das zwischengeschaltete "Modem" IPoE/DHCPv4 (was dein Router am WAN-Port sprechen würde, um nicht PPPoE machen zu müssen) auf PPPoE/IPCP umsetzen und insbesondere die via IPCP erhaltene IPv4-Adresse (nebst weiteren Optionen) via DHCPv4 an deinen Router zurückreichen. Ich habe noch nie von so einem Wundervogel gehört.

Zitat von EinEinfach

Ich habe mit Wireshark mitgeschnitten und wenn ich den 11 Post richtig interpretiere, habe ich das gleiche Problem

Ja, sieht ganz danach aus: Absolute IPv6-Funkstille bei der DG-Gegenstelle:

• 32/34: DAD (Duplicate Address Detection) für die (autokonfigurierte) linklokale IPv6-Adresse des WAN-Ports deines Routers (fe80::de15:c8ff:fe55:ef32).
• 35-1361: Dein Router sendet RS - diese werden von der DG-Gegenstelle nicht (mit RA) beantwortet.
• 1863ff: Dein Router sendet DHCPv6-Solicits - diese werden von der DG-Gegenstelle ebenfalls nicht (mit DHCPv6-Advertise bzw. DHCPv6-Reply bei unterstütztem und konfigurieren "Rapid Commit") beantwortet.

Ein ziemlich klarer Beweis, dass die DG kein IPv6 liefert ...

Dein 2. Screenshot im letzten Post zeigt, dass sowohl die IPv4- als auch die IPv6-Verbindung um 14:24:50 wegbrechen und binnen etwa 1 Minute wieder neu aufgebaut werden. Zuvor sieht man gerade noch, wie um 14:23:08 die IPv6-Verbindung wiederhergestellt wurde.

Liste doch bitte mal für den heutigem Tag die Uhrzeiten mit den folgenden beiden Meldungen auf:

"Internetverbindung wurde getrennt"
"Internetverbindung IPv6 wurde getrennt, ..."

Treten diese beiden Meldungen stets zeitgleich auf?

Sieht so aus, als hättest du ein "Blinker-Internet": AN - AUS - AN - AUS ... und das im Minutentakt.

Zitat von UST

Anbei eine Fehlermeldung, die eben aufkam als ich posten wollte.

Ja, leidiges Problem - siehe hier.

Zitat von UST

Ich würde die Wireshark-Prozedur noch versuchen, wenn das zur Klärung beitragen könnte.

Das bezog sich auf die Telefonie - die funktioniert nach dem Box-Reset ja offenbar inzwischen einwandfrei. Insofern erübrigt sich das.

Der Fokus sollte aktuell wohl eher auf der FB-Ereignisanzeige | TAB Internetverbindung liegen. Sieht man hier öfter Unterbrechungen der IPv4- und/oder IPv6-Internetverbindungen? Und falls ja, wie lange dauern jeweils diese Unterbrechungen?