Kein Traffic über IPv6 möglich (Deutsche Glasfaser)

Und das sind die einzigen RAs, die ankommen? Kannst du die fe80::22 erreichen? Verlassen IPv6 Pakete ins Internet deine UDM in Richtung der MAC Adresse dieses Routers?

Zitat von frank_m

Theoretisch ist fe80::22 aber durchaus valide. Mein vServer bei Netcup hat fe80::1 als Default Gateway. Solange man das Gateway erreichen kann und es weiß, wohin mit den Daten, ist das ok.

Achtung, Link-Local-Adressen werden nicht für das Routing verwendet, die Route auf das Link-Local hat andere Gründe. Der Mechanismus ist hier erklärt:

FE80::1 is a Perfectly Valid IPv6 Default Gateway Address

This article builds upon the IPv6 newbie questions theme & covers a couple of the IPv6 addressing nuances that are often surprising. Read to learn more.

blogs.infoblox.com

"However, the link-local address in the routing table is used to map to the next-hop’s MAC address in the neighbor cache. The link-local address is not used as a destination address of any of the host’s off-net packets, but rather, is just a way for the host to learn the MAC address of the next-hop router that will forward the host’s IPv6 packets onward to the destination address."

Zitat von Elemir

The link-local address is not used as a destination address of any of the host’s off-net packets, but rather, is just a way for the host to learn the MAC address of the next-hop router that will forward the host’s IPv6 packets onward to the destination address."

Und wo ist da der Unterschied zu einem "normalen" Gateway? Kein Paket ins Internet wird an die 192.168.178.1 gesendet, sondern an die dazugehörige MAC Adresse. Die Ziel-Adresse bleibt die Adresse im Internet.

Zitat von Nische

Über einen Zeitraum von ~30 Min habe ich jetzt 3 RAs gesehen, kommen alle von fe80::22 und MAC 20:00:00:00:10:83, nur mit unterschiedlichen Link-Local-Adressen als Ziel, einmal mein Router und die anderen zwei gingen an irgendwelche AVM MACs, müssen wohl andere Kunden sein?

Merkwürdig. Eigentlich werden RAs an Multicast Adressen gesendet (ff02::1), nicht an Unicast Adressen. Gabs vorher eine Router Solicitation? Empfängt deine Box Multicasts auf dem WAN Interface?

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.

Offensichtlich fehlen die üblichen RAs komplett. Bei mir kommen die alle paar Sekunden an die Multicast Adresse.

Der Router scheint einfach nicht das zu tun, was er tun sollte.

Zitat von ::1

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?

In der UDM SE geht es seit neusten. Du benötigst OS 4.1.5 und 8.6.9

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.

Zitat von frank_m

Und wo ist da der Unterschied zu einem "normalen" Gateway? Kein Paket ins Internet wird an die 192.168.178.1 gesendet, sondern an die dazugehörige MAC Adresse. Die Ziel-Adresse bleibt die Adresse im Internet.

Vielleicht hätte ich einen Satz mehr zitieren sollen:

"The host will still send packets sourced from its own global address and destined for the global address of the target."

Der Unterschied liegt also in der Quell-IP. Eine Quell-IP von fe80::X würde keine Antwort auf ein geroutetes Paket erhalten, eine andere (routbare) Quell-IP schon.

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)

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 Elemir

Vielleicht hätte ich einen Satz mehr zitieren sollen:

"The host will still send packets sourced from its own global address and destined for the global address of the target."

Der Unterschied liegt also in der Quell-IP. Eine Quell-IP von fe80::X würde keine Antwort auf ein geroutetes Paket erhalten, eine andere (routbare) Quell-IP schon.

Ok, das ist der Unterschied zwischen IPv4 und IPv6, weil man bei IPv4 üblicherweise keine öffentliche Adresse hat am Node (Theoretisch aber genauso denkbar und möglich). Dann stelle dir vor, der Router hätte eine öffentliche IPv6 Adresse anstatt fe80::22. Was wäre der Unterschied? Auch die Adresse wäre nur dafür da, die MAC aufzulösen. Der Next Hop wird immer auf Schicht 2 angesprochen.

Zitat von Nische

Das heißt in meinem Fall sendet die Gegenstelle keine Unsolicited RAs / bzw. die kommen nicht an? Oder kann es sein das die nicht in dem Packet Capture drin sind (wüsste nicht wieso)?

Grundsätzlich empfängt dein System ja Multcasts, die sieht man ja im Trace. Das wäre der einzige Grund gewesen, wenn dein System gar keine Multicasts empfängt. Das ist aber der Fall, also gehe ich davon aus, dass sie nicht gesendet werden.

Zitat von mado82

Ja, das habe ich von Anfang an so beauftragt. Dies steht auch so im DG Portal unter Tarife + Hardware: "kundeneigener Router - Anschlussmodell FibreTwist (NT)".

Dann zeige doch mal Screenshots der Übersichtsseite, des Online-Monitors und das Ereignis-Log. Da sieht man mehr.

Zitat von frank_m

Ok, das ist der Unterschied zwischen IPv4 und IPv6, weil man bei IPv4 üblicherweise keine öffentliche Adresse hat am Node (Theoretisch aber genauso denkbar und möglich). Dann stelle dir vor, der Router hätte eine öffentliche IPv6 Adresse anstatt fe80::22. Was wäre der Unterschied? Auch die Adresse wäre nur dafür da, die MAC aufzulösen. Der Next Hop wird immer auf Schicht 2 angesprochen.

Es geht ja nicht um die IP des Router, denn der wird ja wie Du richtig schreibst über die MAC angesprochen.

Es geht um den Empfänger des Paketes (der sich bei einem gerouteten Paket in einem anderen Netzsegment aber mit gleicher link-local-Adresse befindet), welcher (bei TCP) das Antwortpaket schicken soll. Da macht es einen erheblichen Unterschied, ob das empfangene Paket eine link-local (fe80::X) oder eine öffentliche (oder ULA) Adresse enthält. An der Stelle helfen die MACs nicht mehr.

Mit nur einer link-local-Adresse auf dem Client-Interface kann es also nicht funktionieren, wenn geroutet werden soll.

Zitat von ::1

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

Wie gesagt, alle paar Sekunden.

Zitat von Elemir

Es geht um den Empfänger des Paketes (der sich bei einem gerouteten Paket in einem anderen Netzsegment aber mit gleicher link-local-Adresse befindet), welcher (bei TCP) das Antwortpaket schicken soll. Da macht es einen erheblichen Unterschied, ob das empfangene Paket eine link-local (fe80::X) oder eine öffentliche (oder ULA) Adresse enthält.

Wir reden völlig aneinander vorbei.

Der Next Hop hat doch keinen Einfluss auf die Quell- oder Ziel-Adresse des Paketes (es sei denn, wir reden über NAT). Hab ich doch schon oben geschrieben. Natürlich sendet der Node das Paket mit seiner öffentlichen IP ab, und die Ziel-Adresse ist die öffentliche IP des Empfängers.

Aber dafür ist es doch vollkommen egal, ob der Router auf dem Weg nach draußen (also der Next Hop) eine link-lokale oder eine öffentliche IP hat. Denn dessen Adresse wird nur dafür verwendet, die MAC aufzulösen, denn der Next Hop wird auf Schicht 2 erreicht.

Und so wird das Paket mit identischer Quell- und Ziel-Adresse mehrere Router passieren, und dabei ist es egal, ob sich diese Router sich gegenseitig über öffentliche oder lokale Adressen erreichen. Das gilt auch für IPv4.

Um noch mal von deinem Beitrag weiter oben zu zitieren:

Zitat von Elemir

Der Unterschied liegt also in der Quell-IP. Eine Quell-IP von fe80::X würde keine Antwort auf ein geroutetes Paket erhalten, eine andere (routbare) Quell-IP schon.

Der Unterschied liegt eben nicht in der Quell-IP, denn die ist in beiden Fällen die gleiche. Trenne dich von dem Gedanken, dass Quell-IP und Router-IP im gleichen Subnetz liegen müssen. Das war nie der Fall (auch nicht bei IPv4!), und wird auch nie der Fall sein. Ja, im klassischen IPv4 NAT-Heimnetz ist es üblicherweise so. Da haben die Endgeräte aber auch selten mehr als eine IP. Aber es reicht, wenn der Sender des Paketes den Router erreichen kann. Welche Quell-Adresse er ins Paket packt, ist davon völlig unabhängig.

Und deshalb ist der zugrundeliegende Mechanismus des Routings am Ende exakt der gleiche, egal, ob er Next Hop nun eine öffentliche oder eine link-lokale (bzw. private) Adresse hat.

Bei IPv6 ist es tatsächlich üblich, dafür die link-lokalen Adressen zu benutzen. Selbst Fritzboxen die eine öffentliche IPv6 im LAN haben, verteilen als Gateway IP ihre link-lokale Adresse.

Ja, das sieht so weit gut aus. Wenn dein Setup des PCs passt, dann liegt es nicht am Heimnetz.