Beiträge von ::1

Zitat von fcc123

Das gabs mit icmpv6 als Filter. Nichts mit Source von DG...

Sieht genau so aus, wie ich's mir gedacht habe.

Um den "Erfolgsfall" idealtypisch zu testen, empfehle ich, in einem Browserfenster einen Paketmitschnitt zu starten, und in einem zweiten Browserfenster anschließend im Fritzbox-GUI unter "Internet | Online-Monitor" die Schaltfläche "Neu verbinden" zu wählen. Man sieht dann im Paketmitschnitt nach entsprechenden DHCP(v6)-Releases eine komplette Neu-Initialisierung für IPv4 und IPv6.

Nach Stopp des Mitschnitts würde ich zur Auswertung folgende Ansichtsfilter in Wireshark wählen:

• dhcp || arp für IPv4
• dhcpv6 || icmpv6 für IPv6

Dann wünsche ich lehrreiche Erkenntnisse.

Zitat von fcc123

Hi ::1 - wie kann ich prüfen, dass das bei mir so eingestellt ist?

MTU habe ich gefunden und angepasst, die anderen Parameter finde ich nicht bei der FB Config.

Im Config-Export finde ich "AdvDefaultLifetime = 1800" bei ipv6, aber die anderen Parameter findet ich nicht.

Wie frank_m schon sagte: Ich bezog mich ausschließlich auf den Paketmitschnitt und somit auf die Inhalte der Paket-Daten. Hier z.B. mal der Inhalt eines Router-Advertisements (RA) aus oben gezeigtem Mitschnitt:

Speziell sieht man hier:

• In den Flags ist das M-Flag (Managed address configuration) gesetzt.
• Router lifetime ist >0 (=1800s)
• Es ist eine Source link-layer option enthalten, die die MAC-Adresse der DG-Gegenstelle angibt (02:00:00:05:01:01)
• Es ist eine MTU option enthalten (1500)
• Cur Hop Limit: 64

Solche dynamisch vom ISP zugewiesenen Werte schreibt die Fritzbox nicht in die Config-Daten, die man als .export-Datei sichern kann. Sie werden vom Empfänger des RA gemäß der reinen Lehre (siehe RFC4861) für folgende Zwecke ausgewertet:

• Generiere (aus der Absende-Adresse des RA=fe80::...) eine IPv6-Defaultroute und versehe sie mit einem abwärts zählenden Verfalls-Timer, dessen Wert mit der Router lifetime aus dem RA zu initialisieren ist. Jedes weitere empfangene RA mit gleichem Inhalt setzt den Wert des Timers wieder auf den Anfangswert. Werden keine weiteren RA empfangen, läuft der Timer ab. In der Folge ist die IPv6-Defaultroute zu löschen.
• Trage die linklokale Adresse und die zugehörige MAC-Adresse des RA-Senders (DG-Gegenstelle) in den neigbor cache (des WAN-Interface) ein.
• Setze die MTU des empfangenden Interface (WAN-Interface) auf den im RA enthaltenen MTU-Wert.
• Initialisiere das "hop limit" im Header ausgehender (nicht gerouteter, sondern von der Fritzbox selbst generierter) IPv6-Pakete mit dem Wert 64.

All diese Datenstrukturen wird man nur im RAM bzw. volatilen Speicher der Fritzbox finden. Um sie zu sehen, müsste man sich allerdings mit TELNET oder SSH aufschalten und entsprechende Linux-Kommandos absetzen - das hat AVM ja ab einer bestimmten Fritz!OS-Version unterbunden.

Man findet einige dieser Daten aber auch in den Support-Daten, die man aus der Fritzbox via "Hilfe und Info| FRITZ!Box Support | Support-Daten speichern" herausziehen kann.

Dein Paket-Mitschnitt enthält ja nicht ein einziges RA. Wenn du den Ansichtsfilter in Wireshark mal lediglich auf icmpv6 setzt, siehst du dann noch andere ICMPv6-Pakete wie NS, NA, oder RS? Wenn die DG-Gegenstelle weder RA (wie beobachtet) noch NA oder NS sendet, würde ich sagen, dass die DG-Gegenstelle IPv6-mäßig mausetot ist.

Ich empfehle, mal einen Paket-Mitschnitt an der WAN-Schnittstelle der Fritzbox durchzuführen.

[NACHTRAG: Zuvor die Fritzbox nochmal neu durchstarten, um neue DHCPv6-Transaktionen mit kurzen Zeitabständen zu erzwingen, andernfalls sieht man evtl. nur DHCPv6-Soliticits in Stunden-Abständen]

1. An einem Desktop-PC im LAN im Web-Browser die URL https://fritz.box/html/capture.html aufrufen und an der Fritzbox anmelden.
2. Man landet auf der Seite "Paketmitschnitt". Dort den Start-Knopf neben "1. Internetverbindung" klicken und im erscheinenden Speichern-Dialog auswählen, wo die Mitschitt-Datei fritzbox-vcc0_TT.MM.JJ_NNNN.eth am Desktop-PC abgelegt werden soll.
3. Den Mitschnitt mal 1-2 Stunden laufen lassen. In der Zwischenzeit das Internet möglichst nicht nutzen. Am Desktop-PC auch alle Programme beenden, die im Hintergrund mit dem Internet reden (z.B. Dropbox).
4. Mitschnitt schließlich durch Klicken auf die Stopp-Schaltfläche neben "1. Internetverbindung" beenden (ggf. nochmals an der Fritzbox anmelden, um wieder auf die Paketmitschnitt-Seite zu gelangen)
5. Sofern nicht vorhanden, Wireshark installieren (https://www.wireshark.org/download.html), Die npcap-Komponente muss dabei nicht mitinstalliert werden.
6. Doppelklick auf die .eth-Datei sollte den Mitschnitt in Wireshark öffnen.
7. Um in der Flut der Pakete die relevanten IPv6-Informationen zu sehen, empfiehlt es sich, in der oberen Zeile "Anzeigefilter verwenden" den Filter dhcpv6 || icmpv6.type==134 einzutragen.

Man müsste nun alle IPv6-Transaktionen der Fritzbox mit der DG-Gegenstelle sehen und daran erkennen können, was schief läuft:

• Die DG-Gegenstelle (in meinem Fall die MAC-Adresse 02:00:00:05:01:01 mit der daraus abgeleiteten linklokalen Adresse fe80::ff:fe05:101) sollte in annähernd regelmäßigen Zeitabständen (Größenordnung etwa alle 10 Minuten) sog. ICMPv6 Router-Advertisments (ICMPv6-Pakete mit dem Typ 134) mit folgenden Informationen senden:
  - Absende-Adresse die eben erwähnte linklokale Adresse. Diese verwendet die Fritzbox als IPv6-Standardgateway, sofern
  - "Router lifetime" größer als 0 ist - bei DG sollte sie 1800 s betragen
  - Flags=0x80, d.h. das M-Flag "Managed Address configuration" muss gesetzt (=1) sein.
  - MTU=1500
  - PIO (Prefix Information Option) ist nicht enthalten.
• Die Fritzbox sollte wiederholt (mit immer größer werdenden Zeitabständen bis zu einem Maximalwert) sog. DHCPv6-Solicit-Pakete senden, in denen sie sog. IA-NA (Identity Association for Non-temporary address) für die IPv6-Adresse am WAN-Port und IA-PD (Identity Association for Prefix Delegation) für das LAN-Präfix anfordert.

Ein ggf. auftretendes Fehlerbild ist nun, dass die DG-Gegenstelle nicht auf die DHCPv6-Solicits antwortet - sie sollte irgendwann mal ein DHCPv6 Advertise senden. Im Fritzbox-Eventlog sieht man dann den Fehler "Keine Antwort vom DHCPv6-Server (SOL)".

Wenn alles gut geht, sollte die DG-Gegenstelle aber irgendwann mal ein DHCPv6 Advertise mit entsprechenden Adress-Angeboten (IA-NA, IA-PD) senden, woraufhin die Fritzbox einen DHCPv6-Request mit eben diesen angebotenen Adressen sendet, und dieser Request schließlich von der DG-Gegenstelle mit einem DHCPv6-Reply beantwortet werden muss, damit die Adressen als zugeteilt gelten dürfen. Sowohl für IA-NA, als auch für IA-PD sollten die Leasedauern (Preferred Lifetime + Valid Lifetime) jeweils 3600s betragen. Renew(T1)/Rebind-Timer(T2) in beiden Fällen 1800/2880s.

NACHTRAG 2:

Zur Illustration des oben Gesagten hier mal eine Aufzeichnung eines etwa 6-stündigen Kampfes meiner Fritzbox um die Zuteilung von IPv6-Adressen - ist allerdings schon eine Weile her, und ich kann leider nicht mehr sagen, ob zu diesem Zeitpunkt bei DG eine Störung oder Wartung vorlag. Meine Aufzeichnung umfasst auch kurz zuvor aufgetretene Probleme mit der Zuteilung einer IPv4-Adresse per DHCPv4, erst nach 2,5 Stunden konnte eine zugewiesen werden - das folgende Bild zeigt aber nur die IPv6-Aufzeichnung:

Es sind zwei Besonderheiten zu erwähnen:

• Im Router Advertisement Paket 73 sieht man im Gegensatz zu allen anderen Router Advertisements davor oder danach, dass das M-Flag auf 0 und die Router Lifetime auf 0s gesetzt wurden. Die DG-Gegenstelle sagt meiner Fritzbox damit: "Du kannst mich nicht mehr als IPv6-Standardgateway verwenden und hör auf, mir DHCPv6-Adress-Anforderungen zu senden". Würde sich die Fritzbox RFC-konform verhalten, müsste sie im Anschluss also eigentlich das Senden weiterer DHCPv6-Solicits einstellen. Tut sie aber nicht.
• Das DHCPv6 Advertise Paket 76 enthält kein Adressangebot, sondern lediglich einen Status Code "UnspecFail". An der Server-ID erkennt man ferner, dass es sich nicht um den DHCPv6-Server handelt, der später tatsächlich IPv6-Adressen zuweist (es handelte sich stattdessen um eine Cisco-Komponente (folgt aus der Struktur der DUID der Server-ID) - vielleicht um ein DHCPv6-Relay, aber das ist Spekulation). Die Fritzbox sendet deshalb weiter ihre DHCPv6-Solicits.

Ab Paket 81 kann die Transaktion nach etwa 6 Stunden endlich erfolgreich beendet werden. In den Router Advertisements ab Paket 84 ist das M-Flag auch wieder gesetzt und die Router Lifetime beträgt 1800s.

Zitat von alpha_zulu

Kann man/ich davon ausgehen, dass ein GF-Anschluss eine bessere und stabilere Dauerverfügbarkeit aufweist?

Ich betreibe seit etwa einem halben Jahr eine RIPE Atlas Probe an meinem DG-Anschluss (m.W. gibt's auch andere Forenteilnehmern mit einer solchen Probe). Für diesen Zeitraum habe ich eine Gesamtverfügbarkeit von 99,94%. Tatsächlich ist sie aber noch höher, denn DG hatte von allen Unterbrechungen nur 3 zu verantworten: 2x IPv6-Unterbrechung für 4-5 Minuten (DHCPv6 Lease Timeout) und 1x Störung mit 57 min ohne Internet-Access (glücklicherweise in den frühen Morgenstunden).

Das ist ganz ordentlich. Im ersten Jahr (DG-Anschluss seit 10/2021) gab es allerdings auch 2-3 Mal IPv6 und/oder IPv4-Unterbrechungen von bis zu 5 Stunden Dauer.

Noch ein Hinweis: Wenn man irgendwann mal einen Trace bekommt, in dem der Router ein DHCPv6-SOLICIT sendet, dann sollten in diesem SOLICIT in der Option Request-Liste neben IA_NA auch IA_PD angefordert werden (IA=Identity Association, NA=Non-temporary Address, PD=Prefix Delegation).

Vermutlich wird nur IA_NA für die WAN-Adresse angefordert. Zusätzliche IA_PD-Anforderung muss man dem Debian sicherlich per Zusatz-Konfiguration beibringen.

Man müsste anstelle IFDOWN zum Loswerden der vorhandenen Adresse ein Kommando eingeben, das ein DHCPv6-RELEASE auf dem WAN-Interface auslöst - gibt's so ein Kommando unter Debian?

Damit müsste man dann im Trace den Ablauf der Adresszuweisung sehen können.

Also in dem Mitschnitt passiert schlicht nichts, was anzeigt, wie das WAN-Interface zu seiner globalen Adresse 2a00:6020:1000:41::26cf gekommen ist. Nach einem IFUP wird offenbar nur versucht, die vor dem IFDOWN schon zugewiesene Adresse wiederzuverwenden und per DHCPv6-Confirm zu bestätigen, allerdings antwortet der DHCv6-Server nicht. Ansonsten sieht man nur die üblichen Pakete, die mit der Autokonfiguration der fe80-Adresse (wird aus der MAC-Adresse abgeleitet) zu tun haben.

Vielleicht hier mal ein paar Hintergrund-Informationen zu CGN für Interessierte:

Laut dieser Quelle verfügt die Deutsche Glasfaser (DG) über lediglich 54,5K IPv4-Adressen, allerdings werden da einige Ranges doppelt gezählt. Mit dieser RIPE-DB-Query komme ich lediglich auf 40K IPv4-Adressen.

Das ist eben nicht gerade viel für einen ISP der "(zu) späten Stunde". Da heißt es haushalten. Für Privatkunden-Anschlüsse bleibt dann eben nur CGN.

DG betreibt ein CGN in der Dual-Stack-Variante NAT444 - so heißt das im RFC-Universum, wenngleich NAT444 nie RFC-Status erreicht hat. Andere Provider mit knappem IPv4-Adress-Pool betreiben ihr CGN hingegen in Verbindung mit DS-Lite - die CGN-Funktion steckt dort im sog. AFTR.

CGN ist nicht unproblematisch - siehe z.B. hier oder hier.

Hallo neisbe,

genau das Problem hatte ich bei Wechsel von Telekom zu DG auch. Es war aber einfach möglich, die bestehenden T-Online-Mailadressen ohne Klimmzüge zu behalten und direkt in Freemail-Adressen umwandeln zu lassen.

Hier kann man das anstoßen: https://www.telekom.de/hilfe/festnetz…t/e-mail-erhalt

Hat zuverlässig geklappt.

Vielleicht meint IPv6 PD Interface das LAN-Interface, das einen /64 aus dem /56-PD-Block bekommen soll. Und da gäbe es 256 Möglichkeiten 0x00 - 0xFF (oder dezimal 0-255) die ID XX für das LAN zu wählen.

Also vielleicht mal LAN statt WAN auswählen und als ID z.B, die 1 probieren.

Zitat von tkuehne

ob ggf. in der FB konfiguriert ist, dass DHCPv6 IPv4 Transport benutzen soll

Laut Definition von DHCPv6 ist so etwas nicht vorgesehen. Wie sollte man also in der FB etwas konfigurieren können, für das es keine technische Spezifikation gibt?

Habe mal interessiert mitgelesen ...

Changelog müsste wohl dies sein.

Speziell die Passage

"Fehlerbehebung in der IPv6-Adresszuweisung via DHCPv6 (ER#5971) –
Im DHCPv6-Client wurden im Non-Rapid-Commit-Fall die IANA- und IAPD-
Sektion (die zuvor mit der DHCPv6-Solicit-Nachricht empfangen wurden)
nicht in die darauf folgende ausgehende DHCPv6-Request-Nachricht
umkopiert. Dies verursachte IPv6-Verbindungsprobleme bei manchen
Providern wie „Deutsche Glasfaser“."

Das passt doch ganz gut zu #25, wo auffiel, dass im Request die im Advertise angebotenen Daten fehlten.

Zitat von HubeBube

Hm, ich habe gerade in einem 8 Monate alten Thread gelesen, das die XG keine Prefix Delegation (DHCPv6-PD) beherrscht.

Zitat von alfalfa

Das wird sich auf die Weitergabe von Prefixes an Router im LAN beziehen, nicht auf die WAN-Schnittstelle.

Letzteres würde ich nicht so folgern. Wenn die erste Aussage generell richtig ist, wird die XG insbesondere auch nicht die Rolle eines "requesting routers" (siehe Definition im DHCP-PD-RFC3633 bzw. in RFC8415) erfüllen, um ein Präfix für das LAN via "option request"-Option 25 vom "delegating router" beim Provider anzufordern. Somit erhält man keine IPv6-Adressen für das LAN.

Zitat von Whiterose

Wenn ich Nur DHCP anklicke muss ich ein Gateway angeben. Welches?

Das ist schon merkwürdig, denn mit Wahl von "Nur DHCP" sollte man weder eine IPv6-Adresse (kommt via DHCPv6 als /128-Adresse), noch eine Präfix-Länge (kommt aus dem PIO-Abschnitt des RA, sofern PIO im RA vorhanden, andernfalls bleibt es bei /128), noch eine Gateway-IP (=linklokale Quelladresse erhaltener RA, sofern im RA eine Router lifetime >0 gesetzt ist) konfigurieren müssen.

Übrigens interessant: Die RA, die die DG sendet, enthalten keinen PIO-Abschnitt - hier aus einem Trace am WAN-Port meiner FB:

Die am WAN-Port gelernte IPv6-Adresse müsste folglich als /128 in der FB angezeigt werden. Tatsächlich dichtet die FB hier allerdings ein /64 dran - streng genommen ein Implementierungsfehler.

Zitat von ParanoidX

ich wüsste jetzt auch nicht wie ich eine fehlerhafte IPv6 konfiguration finden könnte

Hilfreich ist hier https://test-ipv6.com/ - wenn's da irgendwo hakt (< 10/10), gibt der Reiter "Durchgeführte Tests" weitere Hinweise.

Zitat von ParnoidX

Bei Linux hatte ich im Kernel IPv6 deaktiert, nach rausnahme und neustart bekam ich zwar wieder eine IPv6, jedoch wollten die Tests mit IPv6 nicht.

IPerf3 gibt es hier auch als Windows-Version, um es unter Windows 10 mit IPv6 zu testen.

Evtl. könnte helfen, in den Treiber-Einstellungen für den GBit-Adapter des PC unter "Geschwindigkeit und Duplex" die Standard-Einstellung "Automatische Aushandlung" auf "1,0 Gbit/s Vollduplex" umzustellen.

Nur zum Vergleich, so sieht der DG-Speedtest für meinen DG-Classic-Anschluss aus:

Die Ping-Ergebnisse für google.com sind bei mir (je etwa 20 Pings pro Protokoll):

IPv4: Minimum = 6ms, Maximum = 10ms, Mittelwert = 7ms

IPv6: Minimum = 5ms, Maximum = 9ms, Mittelwert = 6ms

Zitat von itsamedamario

ich 7.12.22 21:30 - no Email whatsoever

Vielleicht ist die Mail im Spamordner gelandet ...

Zitat von Tow3r

Habe jetzt mal den Internettraffic mitgeschnitten und mir mit WireShark angeschaut.

Das unten müsste doch eine entsprechende Anfrage für ne IP-Adresse sein oder?

Was mir auffällt, ist, das von der DG-Gegenstelle (MAC-Adresse 02:00:00:02:07:02) alle paar Sekunden "Gratuitous ARP" gesendet werden, die die IP-Adresszuordnung von

100.87.0.1 (scheint die IP-Gateway-Adresse zu sein)
100.124.1.57 (vermutlich die IP-Adresse des DHCPv4-Servers)

zu eben dieser MAC-Adresse announced.

Sowas habe ich in meinen Paket-Mitschnitten am WAN-Port der Fritzbox noch nicht gesehen.

Schadet m.E. zwar nichts, aber trotzdem ungewöhnlich.

Zitat von HubeBube

Nein, das ist sie nicht, sie ist der Client.

Ok, in dem verlinkten Text steht:

"Die praktische Erfahrung ist, dass SIP hinter CGNAT funktioniert, wenn man die Keep-Alives im Client einschaltet."

Aber das dürfte doch nur

• für SIP/RTP via IPv4 (nicht jedoch für IPv6 - da spielt CGNAT keine Rolle)
• und für SIP-Provider ungleich DG (da muss man wohl NAT-Status am CGNAT aktiv halten)

relevant sein?

Aber ok, ich bin jetzt kein VoIP-Experte. Ich kann nur sagen, dass meine Telefonie mit der FRITZ!Box als SIP-Client (mit DECT-Telefonen an der FRITZ!Box-DECT-Basis) und DG als SIP-Provider ohne aktive Option "Portweiterleitung des Internet-Routers für Telefonie aktiv halten" einwandfrei funktioniert, und zwar egal, ob ich sie nun für IPv4 oder IPv6 konfiguriere.

Nachtrag: Das sagt die Hilfeseite dazu:

Portweiterleitung des Internetrouters für Internettelefonie aktiv halten

Diese Einstellung ist nur vorhanden, wenn die FRITZ!Box über einen anderen Router ins Internet gelangt. Wenn die Einstellung aktiviert ist, sendet die FRITZ!Box in regelmäßigen Abständen IP-Pakete, damit die Portweiterleitung des Internetrouters für die Internettelefonie aktiv bleibt.

Das ist bei mir aber nicht der Fall ...

Zitat von HubeBube

Telefonie > Eigene Rufnummern > Anschlusseinstellungen -> Telefonieverbindung - "Einstellungen ändern" aufklappen

Die Option "Portweiterleitung des Internet-Routers für Telefonie aktiv halten" ist bei mir nicht aktiv.

Die Erklärung "Diese Option kann dann erforderlich werden, wenn der Internet-Router ankommende Telefonate nicht mehr an FRITZ!Box weiterleitet. FRITZ!Box hält die Portweiterleitungen des Internet-Routers für Telefonie aktiv." ist nicht besonders intuitiv.

Ich dachte immer, meine FRITZ!Box ist identisch mit dem "Internet-Router".

Kannst du bitte erklären, was die Option bewirkt?