1und1-Glasfaser - IPv6 Prefix-Delegation nur /64?!

Zitat von ::1

Mir scheint, dass das ein Konfigurationsfehler seitens 1&1 ist. Ich schließe das aus dem Muster, nach dem täglich die IPv6-LAN-Präfixe der folgenden 1&1-Kundennetze (via DG und ehemals DG - jetzt AS8881) mit RIPE-Atlas-Probes wechseln:

• #32121: Wechselmuster: 2001:16b8:35XX:XX01:: --> täglich neuer /56 - okay
• #61286: Wechselmuster: 2001:16b8:70XX:XXXX:: --> täglich neuer /64 - nicht okay
• #1015147: Wechselmuster: 2001:16b8:39XX:XX02:: --> täglich neuer /56 - okay

Ich kann gerne ein Ticket direkt bei der Technik von 1&1 Versatel aufmachen - müsste dazu aber das Problem verstehen. Woran erkennst Du, dass bei der Ripe-Probe #61286 täglich ein /64 Netz zugeteilt wird? Dort steht etwas von 2001:16b8:6000::/35 , also ein /35-Netz?

Eine Liste der 1&1 Versatel BNGs findet sich übrigens hier:

62.214.63.0/24 CIDR Infomation AS8881 VERSATEL - 1&1 Versatel GmbH, DE | IPIP.NET

Nur ein kleiner Teil davon (Frankfurt, Düsseldorf, Hannover, Nürnberg) übernimmt den PPPoE (Layer-2) Traffic von der Deutschen Glasfaser.

Sind die /64-Fälle auf den BNG-Standort Hannover (han1901aihd002.versatel.de) beschränkt?
Mein eigener Anschluss (über Nürnberg geschaltet) erhält ein /56 Netz und mein Unifi unterteilt das wie erwartet in /64 Subnetze.

Zitat von kammann

Woran erkennst Du, dass bei der Ripe-Probe #61286 täglich ein /64 Netz zugeteilt wird?

Na, am Wechselmuster: 2001:16b8:70XX:XXXX::

Wäre es ein /56, würde sich nur XX:XX in 2001:16b8:70XX:XXPP:: ändern und PP bliebe konstant (wenn man voraussetzt, dass der Home-Router den Part PP bestimmt und bei einem Wechsel von XX:XX nicht ändert).

Zitat von kammann

Dort steht etwas von 2001:16b8:6000::/35 , also ein /35-Netz?

Gib die aktuelle IPv6-Adresse der Atlas-Probe in der RIPE-DB ein - die spuckt dir dann den übergeordneten IPv6-Block (inet6num) aus, aus dem sie stammt - eine reine Registrierungsgeschichte - bitte nicht als "Netz" interpretieren!

Zitat von kammann

Sind die /64-Fälle auf den BNG-Standort Hannover (han1901aihd002.versatel.de) beschränkt?

Der stand jetzt eigentlich nicht zur Diskussion, sondern der mit der IPv4-Adresse 62.214.63.216 - das ist das BNG, an dem die ATLAS-Probe #61286 und der Anschluss von Hankoor hängen, die beide nur einen /64 als PD-LAN-Präfix bekommen. Es taucht in deiner Liste übrigens nicht auf.

Ob sich alle Fälle nur auf dieses BNG beschränken, wissen wir nicht - es ist nur eine mögliche Vermutung.

Zitat von kammann

Ich kann gerne ein Ticket direkt bei der Technik von 1&1 Versatel aufmachen

Wieso willst du ein Ticket aufmachen, wenn du gar nicht betroffen bist?

Zitat von ::1

Der stand jetzt eigentlich nicht zur Diskussion, sondern der mit der IPv4-Adresse 62.214.63.216 - das ist das BNG, an dem die ATLAS-Probe #61286 und der Anschluss von Hankoor hängen, die beide nur einen /64 als PD-LAN-Präfix bekommen. Es taucht in deiner Liste übrigens nicht auf.

Ergänzung:

Der nächste IPv4-Hop nach dem fraglichen BNG 62.214.63.216 scheint häufig der Router mit der IPv4-Adresse 62.214.42.23 zu sein, der reverse zu han1901aihd001.versatel.de auflöst. Forward- und Reverse-Lookup passen hier allerdings nicht zusammen, denn han1901aihd001.versatel.de löst wiederum auf 62.214.64.23 auf, die ihrerseits wiederum reverse auf hhb002ip001.versatel.de auflöst.

Zitat von ::1

Das ist interessant - dass 1&1 hier für das WAN-Interface offenbar SLAAC statt DHCPv6 (IA_NA) verwendet. Ist aber auch eine zulässige Methode. Danke für diese Info!

Das ist bei mir auch so:
WAN Interface bekommt IPv6 über SLAAC.
Dann gesondert über DHCPv6-PD das 64er für die interne Vergabe.

Ich habe seit Montag 1&1 über das Netz der DG. Das ist der erste Provider, welcher meiner Fritzbox nur ein /64 Prefix zuweist, obwohl ich eingestellt habe, dass ein /56 angefordert werden soll. So kann der nachgeschaltete Unifi UCG fiber aktuell nur ein einziges Netzwerk mit IPv6 versorgen. Daher hoffe ich, dass zumindest Dual Stack weiterläuft.

Zitat von ::1

Das ist interessant - dass 1&1 hier für das WAN-Interface offenbar SLAAC statt DHCPv6 (IA_NA) verwendet. Ist aber auch eine zulässige Methode. Danke für diese Info!

Tatsächlich habe ich das auch festgestellt aber ignoriert. Ich habe in OpnSense DHCPv6 als WAN Adressierung eingestellt.

Dann bekomme ich das netz aber keine eigene WAN Adresse. Zusatzlich habe ich für WAN eingestellt dass es sich seine adresse aus einem der netze bilden soll, bei mir ff als netzanteil. Funktioniert soweit problemlos und mit 254 Netzen kann ich auch leben.

Zitat von peterfido

Ich habe seit Montag 1&1 über das Netz der DG. Das ist der erste Provider, welcher meiner Fritzbox nur ein /64 Prefix zuweist, obwohl ich eingestellt habe, dass ein /56 angefordert werden soll. So kann der nachgeschaltete Unifi UCG fiber aktuell nur ein einziges Netzwerk mit IPv6 versorgen.

Nach Adam Riese bleibt für das LAN hinter deinem Unify genau 0 übrig, da das einzige /64 doch schon für das LAN-Segment verbraten wird, das deine Fritzbox mit dem Unify verbindet ...

Aber unabhängig davon: Es gibt die Vermutung (vgl. #62), dass betroffene Anschlüsse am 1&1-BNG mit der IPv4-Adresse 62.214.63.216 bzw. der IPv6-Adresse 2001:1438::62:214:63:216 hängen. Kannst du bitte mal durch Traceroutes für IPv4 und IPv6 prüfen, ob der erste Hop nach deiner Fritzbox den genannten Adressen entspricht?

Zitat von ::1

Nach Adam Riese bleibt für das LAN hinter deinem Unify genau 0 übrig, da das einzige /64 doch schon für das LAN-Segment verbraten wird, das deine Fritzbox mit dem Unify verbindet ...

Möglicherweise hat er NAT in der UNIFI ausgeschaltet. Dann hat er es zumindest im Core-LAN.

Zitat von Phino

Möglicherweise hat er NAT in der UNIFI ausgeschaltet. Dann hat er es zumindest im Core-LAN.

🤔 - was genau hat im Kontext "kaskadierte Router" NAT bzw. ggf. noNAT (reines IPv4-Thema) mit (Sub-)Prefix-Delegation vom vorgelagerten (Fritzbox) zum nachgelagerten (Unify) Router (reines NAT-freies IPv6-Thema) zu tun?

Ich könnte mir rein theoretisch lediglich vorstellen, dass die Fritzbox das vom ISP erhaltene /64-Präfix nicht selbst konsumiert (also für das "Core"-LAN nutzt/vergibt, das Fritzbox und Unify miteinander verbindet), sondern seinerseits an den Unify-Router weiter delegiert, der daraus dann das nachgelagerte LAN-Segment mit globalem IPv6 bestückt.

Das Core-LAN hätte dann kein globales IPv6, sondern ausschließlich das linklokale IPv6-Präfix (fe80::/64) zur Verfügung, aber das würde ja ausreichen, um einerseits im Unify eine IPv6-Default-Route (next hop: linklokale IPv6-Adresse der Fritzbox im Core-LAN) und in der Fritzbox eine IPv6-Route für das weiter delegierte Präfix (next hop: linklokale IPv6-Adresse des Unify im Core-LAN) zu konfigurieren (letzteres muss die Fritzbox allerdings automatisch generieren). Ich bezweifle allerdings, dass man sowas einer Fritzbox beibringen kann - aber vielleicht unterschätze ich sie da: vielleicht hat peterfido ja genau das hinbekommen.

IPv6 habe ich in genau einem Netzwerk. Unifi unterstützt das:

1 <1 ms <1 ms <1 ms unifi [192.168.2.1]
2 1 ms <1 ms <1 ms 192.168.21.1
3 6 ms 5 ms 5 ms 62.214.63.216
4 41 ms 4 ms 4 ms han1901aihd001.versatel.de [62.214.42.23]
5 13 ms 12 ms 10 ms 72.14.217.71
6 10 ms 11 ms 10 ms 72.14.217.70
^C
C:\Users\Peter>tracert google.de

Routenverfolgung zu google.de [2a00:1450:4001:c1f::5e]
über maximal 30 Hops:

1 <1 ms <1 ms <1 ms unifi [2001:16b8:7003:acf2:..........]
2 1 ms 1 ms 1 ms 2001:16b8:7003:acf2:............
3 7 ms 6 ms 5 ms 2001:1438::62:214:63:216
4 5 ms 3 ms 4 ms 2001:1438::62:214:42:23
5 12 ms 11 ms 12 ms 2001:4860:1:1::6e9
6

Hier noch die Pings:

C:\Users\Peter>ping google.de

Ping wird ausgeführt für google.de [2a00:1450:4001:c1f::5e] mit 32 Bytes Daten:
Antwort von 2a00:1450:4001:c1f::5e: Zeit=12ms
Antwort von 2a00:1450:4001:c1f::5e: Zeit=12ms
Antwort von 2a00:1450:4001:c1f::5e: Zeit=11ms
Antwort von 2a00:1450:4001:c1f::5e: Zeit=11ms

Ping-Statistik für 2a00:1450:4001:c1f::5e:
Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
(0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 11ms, Maximum = 12ms, Mittelwert = 11ms

C:\Users\Peter>ping -4 google.de

Ping wird ausgeführt für google.de [142.251.110.94] mit 32 Bytes Daten:
Antwort von 142.251.110.94: Bytes=32 Zeit=11ms TTL=115
Antwort von 142.251.110.94: Bytes=32 Zeit=11ms TTL=115
Antwort von 142.251.110.94: Bytes=32 Zeit=10ms TTL=115
Antwort von 142.251.110.94: Bytes=32 Zeit=11ms TTL=115

Ping-Statistik für 142.251.110.94:
Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
(0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 10ms, Maximum = 11ms, Mittelwert = 10ms

Zitat von ::1

🤔 - was genau hat im Kontext "kaskadierte Router" NAT bzw. ggf. noNAT (reines IPv4-Thema) mit (Sub-)Prefix-Delegation vom vorgelagerten (Fritzbox) zum nachgelagerten (Unify) Router (reines NAT-freies IPv6-Thema) zu tun?

Wenn man NAT für "WAN" deaktiviert übernimmt Unifi für das core-netz die DHCP Ausgaben für 4 und 6 der FB. Für weitere VLAN gibt es NAT und natürlich kein IPv6 vom ISP. Wie einige schreiben haben sie dann in diesem core-Netz auch IPv6, aber gesteuert dir die FB.

Zitat von peterfido

3 6 ms 5 ms 5 ms 62.214.63.216

Zitat von peterfido

3 7 ms 6 ms 5 ms 2001:1438::62:214:63:216

Wie Hankoor (vgl. #40) und die beiden 1&1-Kundenanschlüsse mit diesen RIPE-Atlas-Probes (#61286, #1016652) hängt dein Anschluss also auch an dem BNG 62.214.63.216 bzw. 2001:1438::62:214:63:216.

IPv6-Adressen wechseln hier täglich die Werte XX:XXXX in 2001:16b8:70XX:XXXX::/64 (vgl. #62). Das stärkt die Vermutung, dass das für alle 1&1-Anschlüsse an diesem BNG gilt und dieses BNG diesbezüglich fehlkonfiguriert ist.

Zitat von kammann

Ich kann gerne ein Ticket direkt bei der Technik von 1&1 Versatel aufmachen

kammann : Falls du zur "Technik von 1&1 Versatel" einen besonderen Zugang hast, wären dir mindestens 4 Kunden dankbar, wenn du deinen Einfluss spielen lassen könntest.

Zitat von Phino

Wenn man NAT für "WAN" deaktiviert übernimmt Unifi für das core-netz die DHCP Ausgaben für 4 und 6 der FB. Für weitere VLAN gibt es NAT und natürlich kein IPv6 vom ISP. Wie einige schreiben haben sie dann in diesem core-Netz auch IPv6, aber gesteuert dir die FB.

Das heißt, Unify schaltet für ein bestimmtes nachgelagertes VLAN vom Router- in einen Bridge-Mode?

Zitat von ::1

Das heißt, Unify schaltet für ein bestimmtes nachgelagertes VLAN vom Router- in einen Bridge-Mode?

Ja, genau, wenn ich es richtig gelesen habe. Bei der Konfiguration legt man den WAN-Port mit der Vorgabe bei den Richtlinien fest und man kann ein VLAN auswählen. Des Weiteren benötigt man noch zwei Regeln für IPv4/6 bezogen auf den WAN‑Port.
Ich habe nur mal testweise einen fremden Router als WAN3 konfiguriert.

Ich kann es nicht testen. Ich habe nur direkte Fiber oder Mobil-Modem als Bridge und bekomme auch /64 Subnetze für die VLAN.

Außerdem gibt es noch die Möglichkeit, ein VLAN direkt für ein fremdes Gateway anzulegen, welches auch kein NAT macht. Aber dann sind die anderen VLANs raus.

Phino : Danke für die Erklärungen - diese sind für mich mangels Unify-Kenntnissen allerdings nicht wirklich nachvollziehbar - die Dialoge und verlinkten Referenzen erklären auch nicht, worauf (Protokoll?, Interface?, ...) sie sich gerade beziehen. Außerdem leuchtet mir nicht ein, was eine NAT-Konfiguration für IPv4 mit einem Bridging für IPv6 zu tun haben soll - zumindest wäre eine Verknüpfung solcher Funktionalitäten dann hochgradig Unify-proprietär.

Wenn ich mir die Traceroutes für IPv4 und IPv6 anschaue ...

Zitat von peterfido

1 <1 ms <1 ms <1 ms unifi [192.168.2.1]
2 1 ms <1 ms <1 ms 192.168.21.1
3 6 ms 5 ms 5 ms 62.214.63.216
:

Zitat von peterfido

1 <1 ms <1 ms <1 ms unifi [2001:16b8:7003:acf2:..........]
2 1 ms 1 ms 1 ms 2001:16b8:7003:acf2:............
3 7 ms 6 ms 5 ms 2001:1438::62:214:63:216
:

... dann scheint der Unify bezüglich IPv4 zwischen dem nachgelagerten VLAN (192.168.2.0/24) und dem Core-Netz (192.168.21.0/24) zu routen (egal ob mit oder ohne NAT, bzw. mit Traceroute allein nicht feststellbar).

Für IPv6 scheint der Unify hingegen zu bridgen (Hop1=Unfiy und Hop2=Fritzbox beide aus 2001:16b8:7003:acf2::/64) - er schafft es dabei, sich selbst bzw. seine IPv6-Bridge-Adresse als Hop1 in den Datenpfad einzupflanzen (Vermutung: RA der Fritzbox leitet er nicht in das nachgelagerte VLAN weiter, stattdessen sendet er inhaltsgleiche RA von seiner linklokalen VLAN-Adresse, die die Clients in der Folge anstelle der linklokalen Fritzbox-Adresse im VLAN als Defaultgateway-Adresse lernen).

Aber müssen wir jetzt nicht weiter vertiefen - wäre hier etwas OT.

kammann : Ein Ticket wäre prima. Bei meinen Telefonaten mit der Hotline hatte ich teilweise den Eindruck dass der Ansprechpartner das Problem nicht verstanden hatte. Das erste Gespräche wurde nach kurzer Wartezeit, wo er Rücksprache halten wollte, beendet. Das zweite Telefonat war mit mehreren Ansprechpartnern, wobei der Vorletzte sagte, er könne da nichts machen, mich dann netterweise noch weitergleitet hat, der letzte war allerdings nur für Störungen direkt im Glasfasernetz zuständig, wollte das dann aber an die richtige Stelle weitergeben.

Gateway: 62.214.63.216, Breitband-PoP: han1901aihr001, LineID: 1UND1.DEU.DGW.12xxxxx

Zitat von ::1

Phino : Danke für die Erklärungen - diese sind für mich mangels Unify-Kenntnissen allerdings nicht wirklich nachvollziehbar - die Dialoge und verlinkten Referenzen erklären auch nicht, worauf (Protokoll?, Interface?, ...) sie sich gerade beziehen. Außerdem leuchtet mir nicht ein, was eine NAT-Konfiguration für IPv4 mit einem Bridging für IPv6 zu tun haben soll - zumindest wäre eine Verknüpfung solcher Funktionalitäten dann hochgradig Unify-proprietär.

Ich gebe dir Recht und auch die Community hat da Fragezeichen. IPv6 und UNIFI ist definitiv noch nicht ausgereift, insbesondere wie oder mit den Möglichkeiten der Oberfläche.

Ich glaube, sie denken sich, wenn jemand für ein VLAN kein NAT mit IPv4 haben möchte, ist es nur schlüssig, dass man IPv6 von davor Bridge.

Aber man muss ja immerhin noch zwei getrennte Regeln für 4 und 6 anlegen. Ich kann es einfach nicht testen.

Aber der grundsätzliche Fehler /Problem liegt ja beim ISP, der das falsche Netzwerkpräfix in der Größe liefert.

Zitat von Phino

Ich gebe dir Recht und auch die Community hat da Fragezeichen. IPv6 und UNIFI ist definitiv noch nicht ausgereift, insbesondere wie oder mit den Möglichkeiten der Oberfläche.

Die wesentliche IPv6-Konfiguration ist offenbar die schon in #70 von peterfido gezeigte IPv6-Einstellung SLAAC in Verbindung mit "Single Network". Hierzu findet man zum Beispiel Diskussionen in REF1 und REF2. Eine tiefgehende Erklärung, wie "Single Network" intern genau arbeitet, finde ich allerdings nicht (bzw. habe vielleicht nicht lange genug danach gesucht). REF1 fabuliert lediglich in die Richtung, die ich mir auch denke: "Forwarding Router Advertisements or using NDP proxy so that LAN clients can directly use the delegated /64." bzw. "NDP proxy or “bridge-style” /64 handling" als Feature Request.

UNIFI agiert ja weltweit. Da scheint es wohl noch viele ISP zu geben, die IPv6 nicht optimal liefern. Und da liefert Unifi einen halbseidenen Hack.