Beiträge von ::1

  • Unifi sucht Tester für DS-Lite i. V. m. PPPoE

    Zitat von kostolany25

    Ich werde verrückt! Im Destination-Cache tauchen beide IP-Adressen nicht auf 🤬

    sind wahrscheinlich nach Timeout verschwunden.

    Ist auch nicht so wichtig - wäre nur eine Bestätigung, dass Path-MTU-Discovery für IPv4 bzw. IPv6 funktioniert, und die LAN-Geräte die verkürzten MTU-Werte des Routers als PMTU für Internetziele (1452 für IPv4 und 1492 für IPv6) anstelle der üblichen 1500 lernen.

  • Unifi sucht Tester für DS-Lite i. V. m. PPPoE

    Zitat von kostolany25

    Bei IPv4 funktioniert es nur mit 1424, bei allen anderen Größen kommt der Hinweis auf die Fragmentierung.

    bei IPv6 funktioniert es nur mit 1444, bei den anderen Größen kommt die Meldung „Allgemeiner Fehler“.

    So habe ich es erwartet.

    Kannst du nach einem Ping für IPv4 bzw. IPv6 auch mal in den IPv4- bzw. IPv6-Destination-Cache des pingenden Rechners nach den Einträgen für die jeweils aufgelöste IPv4- bzw. IPv6-Adresse des Ping-Ziels (google.com?) schauen, ob für diese als Path-MTU (PMTU) jeweils 1452 bzw. 1492 eingetragen ist?

    If so: Dann ist alles gut, und wir brauchen nicht weiter das MTU-Thema zu reiten.

    Nachtrag:

    Bedeutet somit auch, dass purtel.com keine Jumbo-Frames für die WAN-Strecke verwendet.

  • Unifi sucht Tester für DS-Lite i. V. m. PPPoE

    kostolany25 : Noch ein Nachtrag zu #159:

    Du scheinst im LAN eine falsch konfigurierte IP-Route für das Zielnetz 192.168.178.0/24 (Standard LAN-Adresse einer AVM-Fritzbox) zu haben, die dazu führt, dass Pakete zu Zieladressen in diesem Netzbereich über die DS-Lite-Verbindung zum Internet (also getunnelt zum AFTR) gesendet werden.

    Man sieht (wiederholt) TCP-SYN-Pakete zum Aufbau von TCP-Verbindungen zu folgenden Adressen:Ports ...

    192.168.178.1:49000
    192.168.178.39:5001
    192.168.178.39:8443
    192.168.178.64:80
    192.168.178.61:80
    192.168.178.55:80
    192.168.178.76:2001
    192.168.178.76:8701
    192.168.178.193:8000

    ... und zahlreiche Retransmits dieser SYN-Pakete, auf die natürlich niemand antworten kann:

    Das Gute ist aber, dass diese TCP-SYN-Pakete sämtlich die MSS-Option (Maximum Segment Size) = 1412 enthalten:

    Eine TCP-Segment der maximalen Größe von MSS=1412 Bytes ergibt zusammen mit einem TCP-Header (20 Bytes) und einem IP-Header (20 Bytes) ein IP-Paket der Länge 1452 Bytes. Und das ist genau die MTU des 4-in-6-Tunnel-Interface für DS-Lite over PPPoE.

    Welcher LAN-Client diese Irrläufer auch immer gesendet hat: Er hat also per Path-MTU-Discovery offenbar schon die Längenbegrenzung von IPv4-Paketen auf maximal 1452 Bytes gelernt.

  • Unifi sucht Tester für DS-Lite i. V. m. PPPoE

    Um bzgl. MTU mal ein wenig herumzuspielen bzw. die Limits zu testen, kann man an einem LAN-PC gezielt PING-Pakete mit konfigurierbaren Paketgrößen generieren, um so herauszufinden, welche maximalen Paketgrößen zu ausgewählten Internet-Zielen "über die Leitung" gehen können.

    Z.B. an einem Windows-PC kennt das PING-Kommando die Option -l size, in der "size" die Anzahl der Bytes angibt, die man als "Nutzlast" in ein ICMP-Echo- bzw. ICMPv6-Echo-Paket stecken möchte. Da der ICMP- bzw. ICMv6-Header eines Echo-Pakets 8 Bytes, und ein IPv4- bzw. IPv6-Header 20 bzw. 40 Bytes lang sind, erzeugt man bei Angabe von -l size ...

    • ... im Fall von IPv4 ein ICMP-Echo-Paket der Gesamtlänge 20+8+size = size+28
    • ... im Fall von IPv6 ein ICMPv6-Echo-Paket der Gesamtlänge 40+8+size = size+48

    Z.B. an meinem Internetzugang (DG) habe ich eine WAN-MTU von 1500, die ich im Falle von IPv4 mit size=1500-28=1472 und im Falle von IPv6 mit size=1500-48=1452 jeweils voll ausnutzen würde. Mit size=1473 für IPv4 bzw. size=1453 für IPv6 hätte ich aber den Bogen überspannt.

    Zur Demo nehme ich mal das Internet-Ziel google.com, dass für beide Protokolle pingbar ist:

    • IPv4: google.com = 142.251.141.110
    • IPv6: google.com = 2a00:1450:4001:813::200e

    Test für IPv4 mit WAN-MTU=1500:

    Hier wird schön gezeigt, wie ein IPv4-Paket (mit gesetztem DF-Flag, erreicht über die Option -f) der Länge 1500 (size=1472) gerade noch über die Leitung geht, ein Paket mit der Länge 1501 (size=1473) aber gedropt wird.

    Der IPv4-Destination-Cache meines Windows-PC zeigt mir entsprechend eine dynamisch ermittelte Path-MTU (PMTU) von 1500 für das IPv4-Google-Ziel 142.251.141.110 an:

    Code
    C:\>netsh int ip sh dest

Schnittstelle 10: Ethernet


PMTU Zieladresse                           Adresse des n. Hops
---- --------------------------------------------- -------------------------
:    :                                             :
1500 142.251.141.110                               192.168.178.1
:    :                                             :


    Test für IPv6 mit WAN-MTU=1500:

    Analog das Ganze für IPv6:

    Und hierzu passend der IPv6-Destination-Cache meines Windows-PC:

    Code
    C:\>netsh int ipv6 sh dest

Schnittstelle 10: Ethernet


PMTU Zieladresse                           Adresse des n. Hops
---- --------------------------------------------- -------------------------
:    :                                             :
1500 2a00:1450:4001:813::200e                      fe80::e208:55ff:fe3e:b83c
:    :                                             :

    IPv6 kennt kein DF-Flag, daher kann man hier keine Option -f verwenden. Aufgrund der PMTU=1500 für die Zieladresse 2a00:1450:4001:813::200e weiß der PC aber, dass er ein IPv6-Paket der Größe 1501 fragmentieren muss. In einem parallel von mir erstellten Paket-Mitschnitt sieht man auch, dass tatsächlich zwei kleinere IPv6-Fragmente von jedem ICMPv6-Echo-Paket erzeugt werden. Die Google-Gegenstelle mag aber offensichtlich die IPv6-Fragmente eines ICMPv6-Echo-Pakets nicht wieder zusammenzusetzen und antwortet stattdessen gar nicht (was ich als "Zeitüberschreitung der Anforderung sehe").

    Test-Vorschläge für den DS-Lite over PPPoE-Anschluss:

    Interessant wäre nun mal, diese Tests an einem LAN-Rechner hinter dem DS-Lite-Router für folgende "sizes" auszuprobieren:

    IPv6:

    • size=1444 (Gesamt-Paketlänge = 1444+48=1492): ping -6 -n 4 -l 1444 google.com
    • size=1445 (Gesamt-Paketlänge = 1444+48=1493): ping -6 -n 4 -l 1445 google.com

    IPv4:

    • size=1424 (Gesamt-Paketlänge = 1424+28=1452): ping -4 -n 4 -f -l 1424 google.com
    • size=1425 (Gesamt-Paketlänge = 1425+28=1453): ping -4 -n 4 -f -l 1425 google.com
    • size=1472 (Gesamt-Paketlänge = 1472+28=1500): ping -4 -n 4 -f -l 1472 google.com

  • Unifi sucht Tester für DS-Lite i. V. m. PPPoE

    Zitat von kostolany25

    Auch die Seite U. a. auch die Seite dieses Forums oder z. B. test-ipv6.com.

    Die Seite ist nur via IPv4 zu erreichen - das bedeutet, dass dein IPv4 (zumindest partiell) nicht funktioniert.

    Zitat von kostolany25

    NAT habe ich nun komplett ausgeschaltet, ohne dass dies nachvollziehbar Auswirkungen hat.

    So soll es sein - es entlastet nur deinen Router.

    Zitat von kostolany25

    Nein, die einstellbaren Parameter sind in folgendem Bild zu sehen:

    Kannst du mit einer SSH-Session auf die Kommandozeile deines Routers gehen? Die bietet möglicherweise mehr Konfigurationsmöglichkeiten als das Web-GUI. Aber ein mögliches MTU-Problem kann man ggf. auch später analysieren. Vielleicht ist dein Router auch so schlau, an dem genannten Schnittstellen die passenden MTU automatisch zu konfigurieren. Die könnte man dann ggf. durch Anzeige der konkretem Interface-Konfigurationen an der Kommandozeile sichtbar machen.

    Mich würde interessieren, woran es bei IPv4 noch hakt. Kannst du an einem LAN-PC mal einen Dauerping ping -t test-ipv6.com starten, und am Router wieder den Traffic am WAN-Interface eth4 mitschneiden? 30 Sekunden müssten reichen.

  • Unifi sucht Tester für DS-Lite i. V. m. PPPoE

    Ja, habe ich auch gelesen. Werden Jumbos nicht unterstützt, hat man für IPv6 eine MTU von 1500, bzw. von 1492, wenn PPPoE mit im Spiel ist. Heißt aber für jedes zu tunnelnde IPv4-Paket >1452, daß der Router als Tunnel-Endpunkt auf IPv6-Ebene fragmentieren, und der AFTR als der andere Tunnel-Endpunkt die Fragmente wieder reassemblieren muss. Das wäre vermeidbar, wenn die IPv4-Sender im LAN lernen würden, keine IPv4-Pakete größer als 1452 zu senden.

  • Unifi sucht Tester für DS-Lite i. V. m. PPPoE

    M.E. ist die MTU nur für Layer-3 Protokolle (IPv4, IPv6) relevant und sagt diesen, wie groß sie ihre Pakete inkl. Header werden lassen können, damit sie ohne Fragmentierung in die direkt darunter liegende L2-Ebene (oder um Falle von Tunneln eine Pseudo-L2-Ebene) verpackt werden können. Und nur diese L3-Protokolle haben (via ICMP und ICMPv6) entsprechende Control Plane-Funktionen (Path-MTU-Discovery), um diese MTUs der next hop-Interfaces eines Datenpfades zielspezifisch zu ermitteln.

    Im DS-Lite-over PPPoE-Router ist das für des Senden/Weiterleiten von IPv6-Paketen der Wert 1492 an der Schnittstelle "PPP|PPPoe|Ethernet" und für das Senden/Weiterleiten von IPv4 der Wert 1452 am Tunnel-Interface "IPv6|PPP|PPPoe|Ethernet".

    Ich wüsste jedoch nicht, dass man diese Werte (und dies auch noch protokoll-spezifisch) an den genannten Schnittstellen in so einem Router eingeben könnte. MTUs kann man nach meiner Kenntnis immer nur für ein physisches Interface definieren, und das wäre dann hier das Ethernet-Interface eth4 der WAN-Schnittstelle. Dort wäre folglich der Minimum-Wert von 1452 zu konfigurieren.

    Aber ich lasse mich hier auch gerne eines besseren belehren:

    Falls der Router es ermöglicht, MTU=1492 für die (logische) PPP-Schnittstelle und MTU=1452 für die (logische) Tunnel-Schnittstelle zu konfigurieren, wäre das die beste Lösung.

  • Unifi sucht Tester für DS-Lite i. V. m. PPPoE

    Zitat von ::1

    Ich vermute, in deinem Router ist für IPv4 noch NAT aktiv, so dass er die Absende-Adressen aus deinem LAN durch die Tunneladresse 192.0.0.2 ersetzt. Dies widerspricht dem DS-Lite-Funktionsprinzip.

    Bitte überprüfe das, und falls aktiv, schalte NAT im Router ab.

    Was ist mit diesem Punkt?

    Zitat von ::1

    Alternativ kann ein LAN-Client die IPv4-Adresse bzw. IPv6-Adresse des LAN-Interface deines Routers als DNS-Server verwenden (die Werte werden in der Regel dynamisch zugewiesen). In diesem Fall greift die DNS-Proxy-Funktion des Routers: Er sendet einkommende DNS-Requests von LAN-Clients im Standardfall von seiner WAN6-Adresse via IPv6 an DNS1/DNS2 oder ggf. an andere von dir im Router statisch konfigurierte IPv6-DNS-Server weiter (z.B. die IPv6-DNS-Resolver von Cloudflare: 2606:4700:4700::1111 und 2606:4700:4700::1001).

    Dein Router wird zur Namensauflösung standardmäßig die dynamisch zugewiesenen ISP-Server DNS1/DNS2 verwenden. Falls dein Router es ermöglicht, würde ich evtl. stattdessen im Router statisch die beiden Cloudflare-DNS-Server 2606:4700:4700::1111 und 2606:4700:4700::1001 eintragen. Der Mitschnitt zeigte ja Probleme mit den DNS-Antworten von DNS1 - die ließen sich somit umgehen. Dazu müsstest du m.E. in der WAN-Konfiguration die Option "Automatischer DNS-Server" deaktivieren und anschließend die IPv6-Adressen der Cloudflare-DNS-Server eintippen.

    Zitat von kostolany25

    So wie es aussieht, läuft es jedoch noch immer nicht ohne Probleme.

    Und welche Probleme sind das jetzt genau?

    Nachtrag:

    Ich denke gerade noch über die MTU nach: Wegen des PPPoE+PPP-Vorspanns (8 Byte) müsste man die MTU für das WAN-Interface auf 1500-8=1492 absenken.

    Für das IPv4-in-IPv6-Tunnel-Interface müsste man noch weitere 40 Bytes für den IPv6-Header abziehen. Das ergäbe eine nur für den getunnelten IPv4-Traffic maßgebliche MTU von 1492-40=1452.

    Da die MTU für ein Interface protokollunabhängig ist, müsste man folglich das Minimum {1452, 1492} = 1452 einstellen.

    Kannst du in deinem Router für das WAN-Interface (eth4) eine MTU von 1452 konfigurieren?

  • Deutsche Glasfaser: Keine IPv6-Adresse

    Zitat von Tuffi

    Mein wireguard mitschnitt sieht wie folgt aus.

    Du meinst vermutlich "Wireshark" ...

    Ja der Mitschnitt bestätigt die Fehlermeldung "Keine Antwort vom DHCPv6-Server (SOL)": Der Router fragt per DHCPv6-Solicitation in Paket #85 nach IPv6-Parametern, der DHCPv6-Server der DG hat allerdings keine Lust zu antworten.

    Immerhin erhältst du ab Paket #350 regelmäßig IPv6-RA. Sofern in diesen eine Router lifetime >0 und das M-Flag=1 gesetzt sind, wäre die inhaltlich korrekt.

    Gegen einen nicht antwortenden DG-DHCPv6-Server kann nur DG weiterhelfen - aber das ist bekanntlich ein Trauerspiel.

  • Unifi sucht Tester für DS-Lite i. V. m. PPPoE

    kostolany25 : Ich habe mir die Paketmitschnitte angeschaut, die du mir per persönlicher Konversation hast zukommen lassen.

    Für die interessierten Mitleser zitiere ich hier deine mitgegebene Zusatzinformation:

    "ich habe den Anschluss jetzt nochmals leicht anders konfiguriert. Der UCG hat nun eine Verbindung hergestellt, jedoch mit den bekannten Problemen."

    Die Situation ist nun also eine andere als in #157 und meiner dazu gehörigen Kommentierung in #158, bei der laut meiner Analyse kein IPv4-in-IPv6-Tunnel zustande gekommen ist.

    Ich habe von dir die beiden Dateien eth4_neu.pcap und ip6tnl1_neu.pcap erhalten. Diese zeigen nun aber nicht die Initialisierung des WAN-Interface (=eth4), sondern eine spätere Betriebssituation nach Abschluss der Initialisierung bzw. Herstellung der Internetverbindung.

    • eth4_neu.pcap enthält sämtlichen outbound/inbound-Traffic am WAN-Interface, der bei DS-Lite per Definition ausschließlich aus IPv6-Traffic (gekapselt in PPPoE) besteht.
    • ip6tnl1_neu.pcap beinhaltet hingegen sämtlichen IPv4-Traffic, der outbound/inbound durch den IPv4-in-IPv6-Tunnel zwischen deinem Router und dem AFTR des ISP transferiert wird.

    ip6tnl1_neu.pcap ist im Grunde redundant, denn jedes Paket in ip6tnl1_neu.pcap ist zugleich auch in eth4_neu.pcap enthalten, dort nur eben zusätzlich mit einem IPv6/PPPoE-Header versehen, hier mal anhand von Frame #17 beispielhaft verdeutlicht:

    #17 in ip6tnl1_neu.pcap:

    Frame 17: Packet, 45 bytes on wire (360 bits), 45 bytes captured (360 bits)
    Linux cooked capture v1
    Internet Protocol Version 4, Src: 192.0.0.2, Dst: 1.1.1.1
    Internet Control Message Protocol

    #17 in eth4_neu.pcap:

    Frame 17: Packet, 95 bytes on wire (760 bits), 95 bytes captured (760 bits)
    Ethernet II, Src: Ubiquiti_8d:71:1b (28:70:4e:8d:71:1b), Dst: 42:8f:9d:22:b9:b4 (42:8f:9d:22:b9:b4)
    802.1Q Virtual LAN, PRI: 0, DEI: 0, ID: 7
    PPP-over-Ethernet Session
    Point-to-Point Protocol
    Internet Protocol Version 6, Src: 2a01:41e3:4xxx:xxxx:xxxx:xxxx:xxxx:xxx4, Dst: 2a01:41e3:ffff:cafe:face::4
    Internet Protocol Version 4, Src: 192.0.0.2, Dst: 1.1.1.1
    Internet Control Message Protocol

    Wenn du in Wireshark für die geöffnete Datei eth4_neu.pcap den Ansichtsfilter ipv6.nxt==4 eingibst, erhältst du also dieselben Frames wie in ip6tnl1_neu.pcap, nur jeweils ergänzt um den IPv6/PPPoE-Header.

    Im folgenden werde ich mich daher nur noch auf eth4_neu.pcap beziehen.

    Grundsätzlich sind die Mitschnitt-Daten leider nicht vollständig, da zu lange Frames während des Captures einfach abgeschnitten werden: "[Packet size limited during capture]"

    Hier meine Analyse:

    Die gute Nachricht vorweg:

    Es besteht nun ein funktionierender IPv4-in-IPv6-Tunnel gemäß der reinen DS-Lite-Lehre, wie in RFC6333 beschrieben.

    Während der IPv6-Initialisierung des WAN-Ports per DHCPv6 (im Mitschnitt nicht enthalten, hier daher nur indirekt geschlossen) wurden deinem Router vom ISP (indirekt: PURtel.com) mindestens folgende Parameter zugewiesen:

    • WAN-Portadresse (kurz "WAN6)": 2a01:41e3:4xxx:xxxx:xxxx:xxxx:xxxx:xxx4 (hier etwas verschleiert)
    • DNS-Resolver-Adresse 1 (kurz "DNS1"): 2a01:41e1:ffff:f001::4
    • DNS-Resolver-Adresse 2 (kurz "DNS2"): 2a01:41e0:10::6
    • AFTR-Name: aftr.fra.purtel.com

    Den AFTR-Name löst dein Router per DNS-Request (type AAAA) WAN6 -> DNS1 (Frame #2) + DNS-Reply DNS1 -> WAN6 (Frame #7) (Ansichtsfilter: udp.stream eq 0) wie folgt auf:

    • aftr.fra.purtel.com = 2a01:41e3:ffff:cafe:face::4 (kurz "AFTR")

    (im Mitschnitt ist der DNS-Reply leider abgeschnitten, aber aftr.fra.purtel.com ist über beliebige DNS-Resolver ebenfalls auflösbar)

    Somit wird sämtlicher IPv4-Traffic innerhalb des IPv4-in-IPv6-Tunnels mit den beiden Endpunkten WAN6 <-> AFTR transportiert.

    Prinzipiell können also sowohl nativ IPv6 als auch IPv4 (getunnelt zum AFTR) über die WAN-Verbindung zum ISP hin und her transportiert werden.

    Und hier nun beobachtete Auffälligkeiten:

    IPv6-LAN-Konfiguration:

    Mit dem Ansichtsfilter ipv6.nxt!=4 kann ich mir ausschließlich den nativen IPv6-Traffic anschauen (der Tunnel-Traffic ist ausgeblendet). Es mag der Kürze des Mitschnitts von nur 27 Sekunden geschuldet sein: Aber mit Ausnahme der Frames #734, #735 (und einiger MLD-Reports und Router-Solicitations) sehe ich dort ausschließlich IPv6-Traffic von und zu WAN6, wobei es sich durchgängig um DNS-Requests und -Replies zu bzw. von DNS1 und DNS2 handelt und dabei fast ausschließlich Auflösungen von IPv4-Adressen (type A) vorkommen. Bei den Ausnahme-Frames #734, #735 handelt es sich um eine Kommunikation einer LAN-Adresse (2a01:41e3:yyyy:yyyy:yyyy:yyyy:yyyy:yyf7) ungleich WAN6 zu der externen IPv6-Adresse 2a06:98c1:3200::1 (ein STUN-Paket und ein Paket einer TCP-Session).

    Da auch insgesamt fast ausschließlich DNS-Request mit type=A (Auflösung von IPv4-Adressen), jedoch extrem wenige DNS-Requests mit type=AAAA (Auflösung von IPv6-Adressen) auftreten, habe ich den Verdacht, dass möglicherweise deine LAN-Clients über keine bzw. ggf. nur unvollständige IPv6-Konfiguration verfügen:

    Überprüfe bitte an deinen Clients, ...

    1. ... ob sie jeweils (mindestens) über eine globale IPv6-Adresse verfügen, die mit "2a01:41e" beginnt, und ...
    2. ... ob sie jeweils über ein IPv6-Standardgateway verfügen, das der linklokalen (fe80...) IPv6-Adresse des LAN-Interface deines Routers entspricht.

    Teste auch, ob ein IPv6-Ping zu einem Internet-Ziel an jedem LAN-Client funktioniert.

    DNS-Namensauflösung mit DNS1 scheitert teilweise:

    Des weiteren fällt auf (Ansichtsfilter ipv6.nxt!=4 && icmpv6.type==1 ), dass dein Router fast alle DNS-Replies DNS1 -> WAN6 zu zuvor von ihm selbst gesendeten DNS-Requests WAN6 -> DNS1 verwirft und mit einer ICMPv6-Fehlermeldung "Destination unreachable / Port unreachable" an DNS1 quittiert. Wenn der Name nicht zugleich auch bei DNS2 erfragt wird, kann es hier also zu Auflösungsproblemen und in der Folge zu Zugriffsproblemen kommen. Warum dein Router den DNS1 nicht mag und dessen Antworten häufig verwirft, kann ich dir nicht beantworten.

    IPv4-NAT im Router offenbar aktiv:

    Wenn ich mir nun mit dem Ansichtsfilter ipv6.nxt==4 ausschließlich den IPv4-Tunnel-Traffic anschaue, fällt auf, dass sämtlicher Traffic ausschließlich von/zu der tunnelinternen IPv4-Adresse 192.0.0.2 des Routers ausgeht/addressiert ist. Diese Adresse sollte der Router allerdings nur verwenden, wenn er selbst IPv4-Traffic ins Internet sendet. IPv4-Traffic von LAN-Clients (in deinem Fall also von Absende-Adressen 192.168.0.0/24 bzw. 192.168.1.0/24) sollten "as is" durch den Router einfach über den Tunnel Richtung Internet weitergeleitet werden. Im Paketmitschnitt sehe ich allerdings keinerlei IPv4-Pakete aus deinen LAN-Ranges!

    Ich vermute, in deinem Router ist für IPv4 noch NAT aktiv, so dass er die Absende-Adressen aus deinem LAN durch die Tunneladresse 192.0.0.2 ersetzt. Dies widerspricht dem DS-Lite-Funktionsprinzip.

    Bitte überprüfe das, und falls aktiv, schalte NAT im Router ab.

    Verwendung von IPv4-Resolvern:

    Du solltest vermeiden, in einigen deiner LAN-Geräte statisch DNS-Server mit IPv4-Adressen zu konfigurieren (hier: 1.1.1.1), siehe Ansichtsfilter ipv6.nxt==4 && dns. Das belastet den AFTR des ISP mit unnötigen NAT-Session-States. Wenn schon, dann verwende bitte die IPv6-Adressen solcher DNS-Server.

    Alternativ kann ein LAN-Client die IPv4-Adresse bzw. IPv6-Adresse des LAN-Interface deines Routers als DNS-Server verwenden (die Werte werden in der Regel dynamisch zugewiesen). In diesem Fall greift die DNS-Proxy-Funktion des Routers: Er sendet einkommende DNS-Requests von LAN-Clients im Standardfall von seiner WAN6-Adresse via IPv6 an DNS1/DNS2 oder ggf. an andere von dir im Router statisch konfigurierte IPv6-DNS-Server weiter (z.B. die IPv6-DNS-Resolver von Cloudflare: 2606:4700:4700::1111 und 2606:4700:4700::1001).

  • Unifi sucht Tester für DS-Lite i. V. m. PPPoE

    Zitat von kostolany25

    Das sind die beiden Protokolle, welche über die Funktion "Packet Capure" aufgezeichnet wurden:

    Das hilft schon etwas, aber leider noch nicht hinreichend. Kann dein Gerät auch einen vollständigen Paketmitschnitt (inklusive des vollständigen Inhalts aller Pakete) durchführen?

    Was mir auffällt:

    Im Verlauf für eth4 (= WAN-Interface!?):

    Code
    8	0.162323	Ubiquiti_8d:71:1b	ba:c2:53:34:00:61	PPP IPCP	48	Configuration Request
10	0.164866	ba:c2:53:34:00:61	Ubiquiti_8d:71:1b	PPP LCP	    60	Protocol Reject

    Wenn der Router für "DS-Lite over PPPoE" konfiguriert ist, sollte '8' hier nicht auftauchen - entsprechend weist die Gegenstelle in '10' das auch ab. Hintergrund: Der Router versucht hier (per IPCP) IPv4 via PPP zu konfigurieren. Bei DS-Lite wird aber nur IPv6 via PPP (via IPV6CP gemäß '9', '11', '12', '13') ausgehandelt. IPv4 wird anschließend via IPv6 getunnelt.

    Code
    17	0.724223	fe80::2821:e850:e4da:304a	ff02::1:2	DHCPv6	185	Solicit XID: 0x7c5a68 CID: 000300012a704e8d7117 [Packet size limited during capture]
19	0.973240	fe80::bac2:53ff:fe34:61	fe80::2821:e850:e4da:304a	DHCPv6	228	Advertise XID: 0x7c5a68 CID: 000300012a704e8d7117 [Packet size limited during capture]
22	2.212667	fe80::2821:e850:e4da:304a	ff02::1:2	DHCPv6	213	Request XID: 0xfaa94b CID: 000300012a704e8d7117 [Packet size limited during capture]
23	2.366481	fe80::bac2:53ff:fe34:61	fe80::2821:e850:e4da:304a	DHCPv6	228	Reply XID: 0xfaa94b CID: 000300012a704e8d7117 [Packet size limited during capture]

    Hier würde ich gerne in die Pakete hinein schauen können. um zu sehen, welche Parameter (IA_NA, IA_PD, Optionen) ausgehandelt werden. Insbesondere wäre hier auch interessant zu sehen, ob die "AFTR-Name option" enthalten ist.

    Code
    14	0.302973	fe80::2821:e850:e4da:304a	ff02::16	ICMPv6	102	Multicast Listener Report Message v2
16	0.330198	fe80::2821:e850:e4da:304a	ff02::16	ICMPv6	102	Multicast Listener Report Message v2
18	0.800218	fe80::2821:e850:e4da:304a	ff02::16	ICMPv6	102	Multicast Listener Report Message v2
20	1.190204	fe80::2821:e850:e4da:304a	ff02::16	ICMPv6	102	Multicast Listener Report Message v2

    Das ist normales Verhalten (MLD-Reports senden eines frisch initialisierten IPv6-Interface). fe80::2821:e850:e4da:304a ist die per IPV6CP ausgehandelte link-lokale IPv6-Adresse für das WAN-Interface deines Routers.

    Code
    15	0.313006	fe80::2821:e850:e4da:304a	ff02::2	ICMPv6	74	Router Solicitation
21	1.366148	fe80::2821:e850:e4da:304a	ff02::2	ICMPv6	74	Router Solicitation
24	2.427327	fe80::2821:e850:e4da:304a	ff02::2	ICMPv6	74	Router Solicitation
25	4.519650	fe80::2821:e850:e4da:304a	ff02::2	ICMPv6	74	Router Solicitation
26	8.002486	fe80::2821:e850:e4da:304a	ff02::2	ICMPv6	74	Router Solicitation
31	13.480511	fe80::2821:e850:e4da:304a	ff02::2	ICMPv6	74	Router Solicitation
36	21.493585	fe80::2821:e850:e4da:304a	ff02::2	ICMPv6	74	Router Solicitation

    Hier bemüht sich dein Router, von der Gegenstelle endlich mal ein Router Advertisement (RA) zu bekommen. Was hier im Rahmen der Aufzeichnung allerdings nicht passiert. Bei fehlendem RA lernt der Router kein IPv6-Standardgateway. Da du aber von erfolgreichem IPv6-Traffic Richtung Internet sprichst, braucht dein Router offensichtlich auch keines, weil er IPv6-outbound-Traffic einfach über die PPP-Enkapsulierung raus sendet (dazu muss keine Hardware-Adresse der Gegenstelle via Hardware-Adressauflösung der Standardgateway-Adresse ermittelt werden).

    Zu ip6tnl1:

    Code
    1	0.000000	192.0.0.2	3.174.46.127	TCP	76	32998 → 443 [SYN] Seq=0 Win=42360 Len=0 MSS=1412 SACK_PERM TSval=2861564977 TSecr=0 WS=1024
2	0.347459	192.0.0.2	3.174.46.104	TCP	76	47460 → 443 [SYN] Seq=0 Win=42360 Len=0 MSS=1412 SACK_PERM TSval=1049316850 TSecr=0 WS=1024
...

    Dein Router geht hier davon aus, dass ein DS-Lite-Tunnel besteht. Das sieht man an der IPv4-Tunneladresse 192.0.0.2, die der Router verwendet, wenn er selbst mit dem Internet via IPv4 kommunizieren möchte. Deine Protokollierung zeigt aber, dass er immer nur outbound via IPv4 sendet, jedoch nie Antworten aus dem Internet erhält. De facto scheint also kein IPv4-Tunnel zu bestehen.

    Außerdem sind die zahlreichen DNS-Requests via IPv4-Transport für einen DS-Lite-Router ein No Go:

    Code
    18	12.411273	192.0.0.2	1.1.1.1	DNS	73	Standard query 0xd22b A ping.ui.com
19	12.411437	192.0.0.2	1.1.1.1	DNS	73	Standard query 0x3d86 A ping.ui.com
20	12.413018	192.0.0.2	1.1.1.1	DNS	73	Standard query 0xe576 A ping.ui.com
21	12.413138	192.0.0.2	1.1.1.1	DNS	73	Standard query 0x23a0 A ping.ui.com
22	12.413591	192.0.0.2	1.1.1.1	DNS	79	Standard query 0x9778 A www.microsoft.com
23	12.413693	192.0.0.2	1.1.1.1	DNS	79	Standard query 0x452e A www.microsoft.com
24	12.414263	192.0.0.2	1.1.1.1	DNS	72	Standard query 0x5434 A google.com
25	12.414368	192.0.0.2	1.1.1.1	DNS	72	Standard query 0x7c3d A google.com

    Der Router sollte DNS-Requests stets per IPv6 an einen IPv6-fähigen DNS-Resolver schicken (um keinen unnötigen NAT-Session-State im AFTR zu generieren), die der ISP idealerweise im Rahmen der DHCPv6-Aushandlung zuweist. Woher kommt "1.1.1.1" bei deinem Router - falls von dir statisch konfiguriert, im Falle von DS-Lite eine schlechte Wahl. Wenn schon statisch, dann wähle bitte einen IPv6-DNS-Resolver (Cloudflare: 2606:4700:4700::1111 und 2606:4700:4700::1001).

    Ohne einen vollständigen Paketmitschnitt kommen wir der Problemursache leider nicht wirklich näher.

    Nachtrag:

    Wenn ein IPv4-in-IPv6-Tunnel bestehen würde, müsste man für jedes IPv4-Paket in 'ip6tnl1' auch ein IPv6-Paket in 'eth4' sehen (mit proto=41, d.h. enkapsuliertes IPv4-Paket) - das ist offensichtlich nicht der Fall.

  • Ende 2025: ISP Vergleich: Bufferbloat & Routing

    pufferueberlauf :

    Also, wenn du an dem Thema "Erreichbarkeit des Internets" im Sinne von Traceroute-RTT für IPv4 und IPv6 aufgeschlüsselt nach Providern (Filterung nach deren ASN) interessiert bist, kann ich dir die RIPE-Atlas-Ergebnisse empfehlen.

    Hier gibt es insbesondere 4 Dauermessungen jeweils für IPv4 und IPv6, an denen weltweit so gut wie alle ATLAS Probes teilnehmen.

    Ich habe das mal für meinen Provider DG (IPv4: AS=8899, IPv6=60294) wie folgt referenziert:

    IPv4 (Filter: Search Results: 8899):

    1. Traceroute-Ziel: google.com
    2. Traceroute-Ziel: facebook.com
    3. Traceroute-Ziel: wikipedia.org
    4. Traceroute-Ziel: anycast.ninja.ihr.live

    IPv6 (Filter: Search Results: 60294):

    1. Traceroute-Ziel: google.com
    2. Traceroute-Ziel: facebook.com
    3. Traceroute-Ziel: wikipedia.org
    4. Traceroute-Ziel: anycast.ninja.ihr.live

    Du kannst entsprechend die Ergebnisse für andere Provider anzeigen, indem du im Filter "Search Results" deren AS-Nummer eingibst (die kann ggf. protokollabhängig sein, wie bei der DG: IPv4 - AS 8899, IPv6: AS 60294).

    Wenn du den Filter "Search Results" leer lässt, siehst du alle Ergebnisse (alle ISP weltweit). Du kannst dann in der Spalte "Country" (default: all) noch durch Wahl von "Germany" nur die Ergebnisse deutscher Provider anzeigen lassen.

  • Ende 2025: ISP Vergleich: Bufferbloat & Routing

    ISP: DG
    Download/Upload: (400/200)
    RTT: http://www.breitbandmessung.de (12.8; 1.2 (100)), heise.de (8.7; 2.9 (100)), dietpi.com (7.7; 1.3 (100))
    SQM: nein
    Router: FRITZ!Box 5590 Fiber
    Netz: LAN


  • Unifi sucht Tester für DS-Lite i. V. m. PPPoE

    Zitat von kostolany25

    D. h. vor dem Einstecken des Kabel auf „Packet Capture“ gehen? Reichen 30 Sekunden?

    Wie du das an deinem Unify-Router genau durchführen kannst, kann ich dir leider nicht sagen, da ich mit dem Dingens keinerlei Erfahrungen habe. Aber dein Ansatz klingt gut. 30 Sekunden oder eben mindestens so lange, bis die Internet-Verbindung steht.

    Wenn du das Ergebnis als ETH- oder PCAP-Datei speichern kannst, könnte man es mit Wireshark anschauen/auswerten. Ergänzende Log-Daten aus dem Router wären auch vorteilhaft, sofern der sowas bietet. Vorsicht mir dem Hochladen von Paketmitschnitten hier im Forum, die könnten vertrauliche Daten (z.B. PPP-Authentifizierung) enthalten. Du könntest mir das zur Auswertung per privater Konversation schicken.

    Zitat von kostolany25

    Was muss ich da wo einstellen?

    Gar nichts, das ist das Funktionsprinzip von DS-Lite, das du in RFC6333 nachlesen kannst.

  • Unifi sucht Tester für DS-Lite i. V. m. PPPoE

    Zitat von DLMttH

    Also ich habe nach wie vor keinen einzigen funktionsfähigen DS-Lite an UniFi Router mit PPPoE gesehen. Entweder funktionierte der Tunnel oder IPv6, nicht Beides.

    Wenn der Tunnel (und somit IPv4) funktioniert, muss auch eine IPv6-Verbindung bestehen, zumindest zwischen dem UniFi-Router und dem AFTR des ISP. Bzgl. IPv6 muss dann noch etwas anderes schief laufen, z.B. dass kein LAN-Präfix per DHCPv6-PD vorhanden ist. Der Router müsste bzw. sollte aber in der Lage sein, DNS-Namensauflösung per Kontaktierung der ISP-Resolver via IPv6 durchzuführen (z.B. um IPv4-Ziele aufzulösen). Der Router sollte hier als DNS-Proxy/Forwarder arbeiten, der DNS-Requests per IPv4 aus dem LAN entgegen nimmt und diese per IPv6 weiterleitet.

    Kannst du oder kostolany25 für das Szenario "DS-Lite an UniFi Router mit PPPoE" Logdaten des Routers oder gar einen Paket-Mitschnitt am WAN-Port des Routers für den Verbindungsaufbau zum ISP beisteuern?

  • Unifi sucht Tester für DS-Lite i. V. m. PPPoE

    kostolany25 : Das Problem ist, dass man von dir immer nur bruchstückhaft erfährt, was du so treibst, bzw. man nie so genau weiß, auf welchen Netzaufbau du dich gerade beziehst. Bei gezeigten Screenshots wird bspw. nicht genannt, von welchem Gerät sie stammen.

    Mit ist z.B. erst jetzt klar geworden (bzw. war das zuvor meinerseits nur eine Vermutung), dass

    • du offenbar neben deinem UCG-Ultra weiteres Unify-Equipement besitzt, z.B. den soeben erwähnten Switch,
    • der UCG-Ultra nicht direkt am Internetzugang hängt und diesen per DS-Lite over PPPoE herstellt, sondern dass dies dein vorgelagerter TP-Link tut - somit hast du eine Router-Kaskade.

    Ich weiß immer noch nicht, ob dein Ziel-Szenario diese Router-Kaskade sein soll, oder ob der TP-Link 'raus fliegen und durch den UCG-Ultra ersetzt werden soll. Nur letzteres passt übrigens zu diesem Thread "Unifi sucht Tester für DS-Lite i. V. m. PPPoE" - deine Kombi UCG-Ultra hinter TP-Link ist hier insofern deplatziert.

  • Unifi sucht Tester für DS-Lite i. V. m. PPPoE

    ... danke für die Aufklärung. Dann nochmal meine Frage: Wo ist da die Stelle in der DS-Lite-Konfiguration, bei der man Angaben zum AFTR machen muss? Oder wird danach nicht gefragt, weil der AFTR-FQDN implizit per DHCPv6-Option "DS-Lite Name" erfragt und anschießend aufgelöst wird?

    Ohne AFTR eben kein IPv4-over-IPv6-Tunnel und damit kein IPv4.