Beiträge von ::1

Zitat von DrFroeschle

Alle diese Pakete gehen mit der 2a00:6020:7380::1735 als Source IP ab.

Also, wenn ich für diese WAN-Port-Adresse deiner Fritzbox dieselben Traceroute-Tests durchführe, die ich hier bezogen auf das Problem von gordrin durchgeführt habe, dann erhalte ich auch dieselben (negativen) Ergebnisse, wie dort beschrieben:

• Ein heise online-Traceroute endet in Position 5 bei 2a00:6020:0:d::2, kommt also über den Übergangspunkt zur DG im DE-CIX Frankfurt nicht hinaus.
• Ein Traceroute von meinem Desktop-PC am DG-Kundenanschluss endet in Position 3 bei der ominösen ULA-Adresse fc00::1 (bzw. kommen danach nur noch Timeouts).

Mit fällt auf, dass deine WAN-Port-Adresse "ungewöhnlich ist": In allen Fällen, die ich bisher gesehen habe, liegen die WAN-Port-Adressen von DG-Anschlüssen im Range 2a00:6020:1000::/48

Ergänzung:

Zitat

Tscha, und was soll ich sagen, hängt am gleichen Hop wie wenn ich die dedizierte FB IPv6 Adresse verwende. Und wie ich in meinem eigenen Forumsthread schon geschrieben hatte: Wenn ich einen Webserver im "Heimnetz" einrichte und diesen per IPv6 an der Fritzbox freischalte, dann kann ich auf diesen zugreifen. Nur die Rückrouten direkt für die Fritzbox-Services werden am DG Router geblockt (meine Vermutung).

Aus deinen Angaben reime ich mir trotz "Obfuskierung" zusammen:

Dein PD-Block ist 2a00:6020:73d7:5900::/56. Und egal, ob es in diesem Block einen nach außen freigeschalteten Webservice gibt oder nicht, sollte ein Traceroute von außen für jede beliebige Adresse von 2a00:6020:73d7:5900:0:0:0:0 bis 2a00:6020:73d7:59ff:ffff:ffff:ffff:ffff als letzte Etappe vor deinem Router eine Adresse aus 2a00:6020:ffff:ffff::/48 aufweisen, so zumindest das Ergebnis meiner Traceroute-Analysen zu vielen anderen DG-Kundenanschlüssen. Das sehe ich für den PD-Block deines Anschlusses allerdings nie: Egal, welche beliebige Adresse aus dem Block ich wähle, das Traceroute-Ergebnis ist stets so, wie für deine WAN-Port-Adresse 2a00:6020:7380::1735 oben beschrieben.

Aber gut, vielleicht ist es unzulässig, meine Beobachtungen zu verallgemeinern, und für neuere Anschlüsse mögen sie nicht mehr zutreffen.

Nur noch eine Idee:

Ist in deiner Fritzbox der "Stealth Mode" (Diagnose | Sicherheit | Filter) aktiv? Falls ja, könnte es helfen, den mal zu deaktivieren. Dann könnte man evtl. auch die WAN-Port-Adresse deiner Fritzbox in Traceroutes sehen.

Zitat von DrFroeschle

Bis zum 2a00:6020:0:b::2 kommen traceroutes bei mir auch. Aber der Hop danach ist für mich unsichtbar, vermutlich weil der Nachbarrouter zu dem ...ffff::58 falsch konfiguriert ist.

Ähnliches Problem auch hier. Da können sich du und gordrin zusammentun.

gordrin :

Hi again,

ich habe mal, auch weil es mich selbst interessiert, Traceroutes zu diversen DG-IPv6-Zielen an anderen Kundenanschlüssen durchgeführt, und zwar ...

1. ... aus dem Internet von heise online Traceroute
2. ... von meinem Desktop-PC hinter meinem Router am DG-Anschluss.

Als Kandidatenliste von IPv6-Zielen an Kundenanschlüssen habe ich mir RIPE-ATLAS-Probes ausgewählt (solche mit Eintrag 60294 in der Spalte "ASN v6", dann dem Link in der Spalte "ID" folgen, um im "Network"-Tab der probe-site deren IPv6-Adresse zu erfahren, manche sind sogar von außen anpingbar).

Ergebnisse:

Im Fall 1 (heise online-Traceroutes aus dem Internet) sehe ich stets ...

• ... an Position 5 des Traceroutes eine Adresse aus 2a00:6020::/48 (z.B. 2a00:6020:0:c::2 oder 2a00:6020:0:d::2). Dies dürfte der Übergangspunkt zu DG im DE-CIX Frankfurt sein. In der RIPE-DB wird dieser Block als "InfrastructureGermany" bezeichnet.
• ... an Position 6 des Traceroutes eine Adresse aus 2a00:6020:ffff:ffff::/64 (z.B. 2a00:6020:ffff:ffff::23, 2a00:6020:ffff:ffff::41, 2a00:6020:ffff:ffff::58). In der RIPE-DB wird dieser Block als "BNG-Cluster-DHCPv6-Link-Address" bezeichnet. BNG steht hier vermutlich für "Broadband Network Gateway"

Im Fall 2 (Traceroute von meinem Desktop-PC am DG-Kundenanschluss) sehe ich stets ...

• ... an Position 3 jeweils dieselbe Adresse aus dem Block "BNG-Cluster-DHCPv6-Link-Address", die beim Traceroute von heise online an Position 6 auftaucht, s.o.

Wenn ich nun die beiden Traceroute-Varianten für deine IPv6-Adresse am WAN-Port deiner Fritzbox durchführe (wie in einem früheren Post erwähnt, kann ich die jeweils aktuelle ermitteln), komme ich abweichend zu folgenden Ergebnissen:

Im Fall 1 (heise online-Traceroutes aus dem Internet) sehe ich ...

• ... der Trace endet in Position 5 bei 2a00:6020:0:c::2, kommt also über den Übergangspunkt zur DG im DE-CIX Frankfurt nicht hinaus.

Im Fall 2 (Traceroute von meinem Desktop-PC am DG-Kundenanschluss) sehe ich ...

• ... in Position 3 anstelle einer Adresse aus dem Block "BNG-Cluster-DHCPv6-Link-Address" nur die ominöse ULA-Adresse fc00::1, an dem der Trace endet (bzw. kommen danach nur noch Timeouts)

Das betätigt nochmals aus einer weiteren Perspektive, dass in der DG-Netzinfrastruktur (zumindest) das Rückwärts-Routing zu den IPv6-Adressen an deinem DG-Anschluss nicht funktioniert.

Zitat von gordrin

Vielleicht müsste DG einfach mal meine Geräte aus deren Infrastruktur reseten?

Ich denke nicht, dass die DG pro Kunde dedizierte "Geräte in ihrer Infrastrukur" betreibt. Auch der "letzte" Router Richtung Kunden-Access-Struktur wird vermutlich mehrere Kundenanschlüsse aggregieren. Es ist vermutlich eher ein Konfigurationsproblem in deren Infrastruktur, wie ich's oben schon mal formuliert habe:

Zitat von ::1

Meine Interpretation: DG schafft es nicht, für deinem Anschluss feste (oder sagen wir: "quasistatische", denn echt "fest" ist nicht garantiert) IPv6-Adressen (IA_NA, IA_PD) zu reservieren, geschweige denn, in der DG-Netzinfrastruktur für den jeweils zugewiesenen PD-Block bzw. die WAN-Port-Adresse eine (Rückwärts-)Route über deine WAN-Leitung zu deinem Router zu generieren.

Das ist zumindest das, was man aus dem bei dir sicht- und analysierbaren Verhalten an deinem Anschluss folgern kann.

Das Problem wird sein, den DG-Support davon zu überzeugen, dass die Problemlösung in deren Infrastruktur zu suchen und zu beheben ist.

gordrin: In deiner aktuell vorliegenden Konstellation wird deinen LAN-Clients vorgegaukelt, sie könnten neben IPv4 auch vollwertig IPv6 nutzen. Dort, wo "Happy Eyeballs" nicht greift, wird sich ggf. eine schlechte User Experience einstellen, nämlich immer dann, wenn zunächst bevorzugt versucht wird, eine IPv6-Verbindung aufzubauen, um nach dem zwangsläufigen Scheitern dieses Versuchs es mit einer IPv4-Verbindung zu versuchen - Ergebnis: Eine als zu lang empfundene Aufrufdauer. Bezogen auf einen Webbrowser an einem Client kann man das Verhalten bzgl. "Happy Eyeballs" hier mal testen.

Es wäre aktuell ggf. empfehlenswert, in der Fritzbox die IPv6-Unterstützung vorerst zu deaktivieren und sie von Zeit zu Zeit nur zu Testzwecken anzuschalten. um zu prüfen, ob das Problem auf DG-Seite denn nun gelöst wurde, bevor sie dann wieder dauerhaft aktiviert bleiben kann. Das aus meiner Sicht derzeit beste Testwerkzeug für IPv6 am Client: https://test-ipv6.com/

Noch ein Nachtrag:

Die eben erwähnte Testseite https://test-ipv6.com/ enthält oben rechts noch den schönen Link "Für den Helpdesk". Klickt man den, dann gelangt man auf eine Seite, auf der unten ein Link auf das Testergebnis angegeben ist. Den könntest du z.B. auch dem DG-Support zukommen lassen. Vielleicht hilft es ...

Zitat von gordrin

Danke schon jetzt für eure Unterstützung. Anbei hab ich den WAN-Port mitschnitt. In diesen ist auch ein dhcpv6 rebind gefallen. Soweit ich das sehe ist die RA gut, die Router Lifetime sitzt auf 4500.

Hier ist der FritzBox WAN Mitschnitt:

Zitat von ::1

Ein Grund für den DHCPv6 Lease-Timeout ist vermutlich, dass die bestehende Lease seitens DG nicht mehr zu verlängern war, weil dein Anschluss andere IPv6-Adressen bekommen sollte: Die neue WAN-Port-Adresse hat als letzte Ziffer anstelle einer 2 nun eine 7. Im LAN-Prefix hat sich eine Ziffer von 5 auf a geändert. In der Regel bekommt man an stabil funktionierenden Anschlüssen stets dieselben Adressen zugewiesen. Bei meinem Anschluss haben die sich bisher nur nach einer DG-Wartung einmal geändert.

Wäre mal interessant zu beobachten, ob dein Router nach jedem Lease-Timeout mit anschließender Neuaushandlung einer Lease geänderte IPv6-Adressen bekommt.

gordrin: Deinem Mitschnitt konnte ich eine Information entnehmen (keine Sorge: die vergesse ich auch wieder), die es mir ermöglicht, die aktuell deinem WAN-Port zugeordnete Adresse zu ermitteln und damit meine noch offene Frage selbst zu beantworten:

Demnach weist DG deinem Anschluss eine DHCPv6-Lease (WAN-Adresse + /56-PD-Block für's LAN) mit der Leasedauer 1h zu, die aber per DHCPv6-Renew/Rebind nicht verlängert wird. Nach einer Stunde, also Ablauf der Leasedauer, bezieht die Fritzbox eine neue Lease und erhält dabei jedes Mal eine andere WAN-Port-Adresse (und ich gehe davon aus, auch einen anderen PD-Block). Das Ganze wiederholt sich jede Stunde (etwa um XX:09 Uhr) - müsste im Eventlog des Routers auch angezeigt werden.

Meine Interpretation: DG schafft es nicht, für deinem Anschluss feste (oder sagen wir: "quasistatische", denn echt "fest" ist nicht garantiert) IPv6-Adressen (IA_NA, IA_PD) zu reservieren, geschweige denn, in der DG-Netzinfrastruktur für den jeweils zugewiesenen PD-Block bzw. die WAN-Port-Adresse eine (Rückwärts-)Route über deine WAN-Leitung zu deinem Router zu generieren.

Ich nehme mal an, der vom DG-Support vorgeschlagene ONT-Reset hat nichts gebracht?

Das Problem ist hier doch partiell auf Layer 3 (IPv4, IPv6) des Netzwerk-Stacks zu verorten, und IPv4 funktioniert ja einwandfrei. Wofür nun eine Maßnahme auf Layer 1+2 (Optik <-> Elektronik + Ethernet), nämlich ein Reset des ONT, gut sein soll, weiß wohl nur der Support auf Layer 8. Oder anders: Läge dort das Problem, würde IPv4 auch nicht funktionieren. Aber ich lasse mich hier gerne eines Besseren belehren.

ONT-Reset habe ich auch schon mal gemacht. Ging immer gut und war auch nie Ursache des Problems (hatte zeitweise auch schon IPv4 und/oder IPv6-Konnektivitätsausfälle - allerdings maximal nur für ein paar Stunden - inzwischen läuft mein Anschluss sehr stabil).

Ich habe mal einen Blick auf den Mitschnitt geworfen. Zu DHCPv6 (Ansichtsfilter "dhcpv6" setzen): Ja, man sieht mehrere Rebind-Requests, die von der DG-Gegenstelle jedoch ignoriert werden. Am Ende (also nach Ablauf der Leasedauer) leitet die Fritzbox (fe80::d624:ddff:febd:b46b) dann mit einer DHCPv6-Solicitatation eine neue Transaktion (neue XID) zum Bezug einer neuen Lease ein, die erfolgreich von der Gegenstelle mit einem Reply abgeschlossen wird (Rapid Commit aktiv). Das stimmt mit dem oben gezeigten Eventlog überein.

Was aber bzgl. RA merkwürdig ist: Diese sollten normalerweise von der DG-Gegenstelle an die Multicast-Adresse ff02::1 gesendet werden. In deinem Trace sieht man (Filter icmpv6.type==134 setzen) jedoch ausschließlich unzählige RA-Unicasts an einzelne linklokale Ziele (fe80::...), bei denen die Adresse deiner Fritzbox (s.o.) auch zweimal dabei ist. RA-Unicasts werden normalerweise nur als Reaktion auf vorausgegangene Router-Solicits (RS) gesendet, solche (Filter icmpv6.type==133) sind in dem Mitschnitt aber nicht zu finden. Überhaupt sollten am LAN1-Port, der hier ja als Ersatz-WAN-Port fungiert, nur genau eine MAC-Adresse bzw. die dazu gehörige linklokale IPv6-Adresse sichtbar sein. Es sieht irgendwie so aus, als würdest du auf deiner WAN-Leitung lauter RA sehen, die für andere DG-Kundenanschlüsse gedacht sind.

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. Korrekt sind dabei nur die NS/NA-Transaktionen, die dein Router initiiert hat (Filter "(icmpv6.type==135 || icmpv6.type==136) && ipv6.addr==fe80::d624:ddff:febd:b46b" <-- alles zwischen "" kopieren).

Sieht mir irgendwie nach einem Problem auf DG-Seite aus.

Noch zwei Ergänzungen:

Ein Grund für den DHCPv6 Lease-Timeout ist vermutlich, dass die bestehende Lease seitens DG nicht mehr zu verlängern war, weil dein Anschluss andere IPv6-Adressen bekommen sollte: Die neue WAN-Port-Adresse hat als letzte Ziffer anstelle einer 2 nun eine 7. Im LAN-Prefix hat sich eine Ziffer von 5 auf a geändert. In der Regel bekommt man an stabil funktionierenden Anschlüssen stets dieselben Adressen zugewiesen. Bei meinem Anschluss haben die sich bisher nur nach einer DG-Wartung einmal geändert.

Wäre mal interessant zu beobachten, ob dein Router nach jedem Lease-Timeout mit anschließender Neuaushandlung einer Lease geänderte IPv6-Adressen bekommt.

Man sieht ferner, dass dein Router ausgehenden IPv6-Traffic korrekt zur MAC-Adresse 20:00:00:00:10:82 der DG-Gegenstelle routet, nur kommt von da nie was zurück (Ansichtsfilter eth.addr==d4:24:dd:bd:b4:6b && ipv6). Externe IPv6-Zieladressen wurden dabei zuvor über IPv4 aufgelöst. Ausgehende TCP-Verbindungen kommen so über SYN nicht hinaus, DNS- und NTP-Queries bleiben unbeantwortet. Dies ist ein weiteres Indiz für ein Problem auf der DG-Seite.

Und noch eine Ergänzung:

Aus den Ziel-MAC-Adressen der am WAN-Anschluss erhaltenen NA- und RA-Unicast-Pakete lassen sich ja die OUI-Anteile (die ersten 24 Bits, z.B. d4:24:dd) und somit die Hersteller der Geräte, an die das jeweilige Paket gerichtet ist, ablesen (Wireshark zeigt das zweckmäßigerweise gleich mit an). Dabei sind alle RA-Zieladressen (die seltener auftauchen) eine Teilmenge der NA-Zieladressen. Wenn ich letztere auszähle kommen ich auf 55 AVM-Router und 37 Sagemcom-Router (die man von DG als Homerouter beziehen kann). Abzüglich dem eignen (AVM-Router) sieht man hier also fehlgeleitete Pakete von 91 fremden Kundenanschlüssen auf der WAN-Leitung, sofern meine Deutung richtig ist. Dass man die im Trace überhaupt sieht, liegt vermutlich daran, dass das WAN-Interface während des Mitschnitts in den "promiscuous mode" gesetzt wird.

Wenn zwar per DHCPv6 IPv6-Adressen (WAN-Port + LAN-Präfix) zugewiesen werden (auch wenn es offenbar nicht klappt, eine bestehende Lease per DHCPv6-Renew bzw. ggf. auch DHCPv6-Rebind zu verlängern; nach dem Ablauf der Lease wird ja erfolgreich sofort eine neue Lease angefordert), man dann aber nicht auf das Internet via IPv6 zugreifen kann, könnte es daran liegen, dass die DG-Gegenstelle keine Router-Adversements (RA) sendet. Oder es werden zwar RA gesendet, im RA ist die Router-Lifetime jedoch auf "0" gesetzt.

Ein Paket-Mitschnitt am WAN-Port der Fritzbox könnte hier weiterhelfen.

Length: 48 ist hier die Länge der IA_PD-Option und nicht die angeforderte Prefix-Länge - die war 56. Aber vielleicht stören die angeforderten Preferred lifetime: infinity und Valid lifetime: infinity. Denn die wird der DHCPv6-Server ablehnen.

Nachträge:

Immerhin hat es ja geklappt, die beiden DNS-Serveradressen zu bekommen. Wenn ich aber das DHCPv6-Solicit-Paket anschaue und mit meinen Solicit-Paketen (am WAN-Port einer Fritzbox 7590) vergleiche, sind folgende Unterschiede festzustellen:

• Es fehlt eine IA_NA-Option, mit der eine IPv6-Adresse für das WAN-Interface angefordert wird.
• In der "Option Request Option" fehlen die "Request Option Codes" für IA_NA (3) und IA_PD (25)
• Im "IA Prefix"-Teil der IA_PD-Option sollten valid und preferred lifetime auf "0" stehen und nicht auf "infinity", siehe oben.

Mir scheint, dass die Konfiguration nachgebessert werden muss.

Nachtrag 2;

Der folgende Teil der Konfiguration fordert vermutlich eine IPv6-Adresse via SLAAC für das WAN-Interface an:

     ipv6 {
         address {
             autoconf
         }
         dup-addr-detect-transmits 1
     }

DG ordnet die WAN-Adresse jedoch per DHCPv6 zu.

Vermutlich wäre stattdessen folgende Konfiguration richtiger:

ethernet eth0 {
     address dhcp
     address dhcpv6
     ...

Ich kenne Ubiquiti jedoch nicht und weiß daher nicht, ob das Kommando "address dhcpv6" in dieser Form existiert.

Das würde die fehlende IA_NA-Option im DHCPv6-Solicit erklären.

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.