Beiträge von ::1

Zitat von frank_m

Wie gesagt, alle paar Sekunden.

Wie groß ist denn die Router-Lifetime in den RA? Ist die auch deutlich kleiner als 1800s (wie bei mir)? Falls ja, wundert mich, dass DG unterschiedliche Konfigurationsprofile an ansonsten technisch ähnlichen Anschlüssen fährt.

Also wenn das WAN-Interface keine RA erhält, wird es das Standardgateway nach Ablauf der Router-Lifetime (bei DG 1800s = 30 min) "vergessen", sprich aus der Routingtabelle löschen. Jedes erhaltene RA setzt den Timer für den Ablauf der Defaultroute wieder auf den Wert der Router-Lifetime im RA-Paket zurück. Deshalb sollen unsolicited RA ja auch hinreichend oft gesendet werden (lt. RFC-Standard etwa in Zeitabständen, die 1/3 der Router-Lifetime entsprechen). Siehe https://datatracker.ietf.org/doc/html/rfc4861#section-6.2.4

Zitat von frank_m

Bei mir kommen die alle paar Sekunden an die Multicast Adresse.

das wundert mich. Bei mir kommen die nur etwa alle 10 min (~ 1/3 der Router-Lifetime von 1800s)

Man muss zwischen "solicited" und "unsolicited" RA unterscheiden. Wenn ein Interface initialisiert wird, sendet es RS, weil es schnell RA-Antworten braucht. Wenn der RS als Quelladresse eine IPv6-Adresse ungleich :: enthält, wird das RA an diese Quell-Adresse zurück gesendet. Unsolicited RA sendet die Gegenstelle jedoch an die "all nodes multicast address" ff02::1 im Abstand von etwa 1/3 der Router-Lifetime (siehe Inhalt des RA), bei DG also 1/3 von 1800s=600s=10 min.

DHCPv6-Advertise und DHCPv6-Reply-Pakete werden ja auch von der Gegenstelle bzw. vom Standardgateway gesendet. Kommen diese Pakete also auch von fe80:22? Mal mindestens eine halbe Stunde einen Paketmitschnitt am WAN-Port machen, es gibt etwa alle 30 Minuten eine DHCPv6-Renew/Reply-Transaktion - da könnte man dann die korrekte fe80-Adresse der DG-Gegenstelle sehen.

Zitat von frank_m

Theoretisch ist fe80::22 aber durchaus valide

Ja, aber DG scheint die linklokalen IPv6-Adressen der Gegenstelle gemäß "modified EUI-64" aus der MAC-Adresse zu bilden, deshalb sollte darin ein "fffe" auftauchen.

Zitat von kingpin42

Nicht alle Anbieter verwenden innerhalb ihres Netzes öffentliche IP-Adressen. Technisch vollkommen in Ordnung, wirkt für den Unbeteiligten nur etwas seltsam.

Ja, schon richtig. Der Punkt ist nur, dass der Traceroute-Reply aus der Infrastruktur der DG kommt, und damit folglich auch dort das Problem liegt.

Valider Punkt: fe80::22 wirkt tatsächlich etwas "simpel". In meinem Fall sendet die DG-Gegenstelle IPv6-RA von der MAC-Adresse 02:00:00:05:01:01, zu der die abgeleitete linklokale IPv6-Adresse fe80::ff:fe05:101 als Default-Gateway gehört. Kann man am WAN-Interface einen Packet-Trace machen?

Sieht nach einen Routing-Problem in der DG-Infrastruktur aus (traceroute-Eintrag von fc00::1). frank_m scheint da mehr zu wissen, weil er so gezielt danach gefragt hat.

In der routing table (Bilder 7/8) fehlt die Default-Route ::/0.

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.