Unitymedia IPv6 Konfiguration und Präfix bei der ConnectBox

[monster]

Ich könnte auch mal versuchen auf dem Orbi ein 6to4 Tunnel einzurichten. Die Option gibt es ....

Das halte ich für überhaupt keine gute Idee :traurig:
Das wäre ja Tunnel in Tunnel, wenn es denn überhaupt funktioniert.
Der gesamte V6 Traffic würde ja dann auch noch getunnelt über's AFTR laufen :wand:

Ich meinte das auch eher in hinsicht für v4 traffic. Brauchen tu ich das nicht. Es funzt so.

Bezüglich der Sicherheitsbedenken.

Ich kann die oben angegebene v6 Adresse nicht pingen und der traceroute endet an der CB!
Da scheint die v6 FW der CB doch einzugreifen. (oder der Orbi).

 

[Andreas1969]

Diese Schrottbox beherrscht einfach keine Prefix Delegation :traurig:
Was sagt denn eigentlich die Hotline dazu :kratz:

 

[monster]

Hast du es schonmal ausprobiert?

 

[Andreas1969]

Hast du es schonmal ausprobiert?

Ich hab mittlerweile keine ConnectBox mehr, daher kann ich es nicht mehr testen.
Bit der Fritzbox funktioniert das aber. :winken:

 

[#DiRK]

Diese Schrottbox beherrscht einfach keine Prefix Delegation :traurig:
Was sagt denn eigentlich die Hotline dazu :kratz:

Die Hotline weiß erst mal nicht was PD ist.

Irgendwann kommt nur noch die Aussage "da müssen Sie leider die Dienste eines professionellen IT-Dienstleister in Anspruch nehmen" und es wird aufgelegt.

Wenn man da nicht zu einem Techniker durchgestellt wird ist das aussichtslos.

 

[#DiRK]

Ich kann die oben angegebene v6 Adresse nicht pingen und der traceroute endet an der CB!
Da scheint die v6 FW der CB doch einzugreifen. (oder der Orbi).

Sorry, war mein Fehler. Natürlich greift die FW der CB.

Ich habe diese bei mir ausgeschaltet, daher die falsche Aussage. Mir wäre es lieber wenn alles an meinem Router terminiert. Daher auch der Wunsch nach PD.

 

[Andreas1969]

Irgendwann kommt nur noch die Aussage "da müssen Sie leider die Dienste eines professionellen IT-Dienstleister in Anspruch nehmen" und es wird aufgelegt.

Das bringt aber auch nichts, wenn die Connectbox das nicht kann.
Der "professionellen IT-Dienstleister" kann ja auch nicht zaubern, wenn da seitens der Connectbox nichts kommt. :winken:

 

[monster]

Ich kann die oben angegebene v6 Adresse nicht pingen und der traceroute endet an der CB!
Da scheint die v6 FW der CB doch einzugreifen. (oder der Orbi).

Sorry, war mein Fehler. Natürlich greift die FW der CB.

Ich habe diese bei mir ausgeschaltet, daher die falsche Aussage. Mir wäre es lieber wenn alles an meinem Router terminiert. Daher auch der Wunsch nach PD.

Kein Problem, lieber einmal mehr geschaut im Sinne der Sicherheit :smile:

Ja, wäre schon schön wenn das Providergerät völlig transparent wäre, am besten nur Layer 2. Für meinen Teil ist das schon so ok wie ich es habe. Ich sehe das für mich als eine 2 stufige "Firewall". :zwinker:

Und bevor der spruch kommt mit eigenem Gerät. Ich will keine Fritzbox und ich kann mir nicht mal eben so ein Kabelmodem in Deutschland kaufen (ja, TC4400, aber den gibt es nunmal nicht frei verkäuflich).

 

[Andreas1969]

ich kann mir nicht mal eben so ein Kabelmodem in Deutschland kaufen (ja, TC4400, aber den gibt es nunmal nicht frei verkäuflich).

Hätt'st ja eins über die Sammelbestellung kaufen können :winken:

 

[monster]

ich kann mir nicht.
das bedeutet für mich das ich es bei nicht funktion/gefallen/whatever auch wieder zurück schicken kann.
deshalb hab ich u.a. nicht an der sammelbestellung mitgemacht.

 

[Andreas1969]

:mussweg:

ich kann mir nicht.
das bedeutet für mich das ich es bei nicht funktion/gefallen/whatever auch wieder zurück schicken kann.
deshalb hab ich u.a. nicht an der sammelbestellung mitgemacht.

Hättest es ja dann bei Nichtgefallen ohne Verlust weiterverkaufen können. :winken:
Ein Käufer hätte sich sicherlich gefunden

 

[Evil.2000]

So. Mein v6 rennt nun auch genau wie ich mir das vorgestellt habe.
Allerdings musste ich meinen WRT160NL vom alten DD-WRT v24sp2pre aktualisieren auf die aktuelle OpenWRT Version ziehen. Dann versteht er auch IPv6 PD von der CB.

Jetzt bin ich glücklich. Mal sehen wwelche Endgeräte bei mir hier IPv6 können. :smile:

 

[#DiRK]

So. Mein v6 rennt nun auch genau wie ich mir das vorgestellt habe.
Allerdings musste ich meinen WRT160NL vom alten DD-WRT v24sp2pre aktualisieren auf die aktuelle OpenWRT Version ziehen. Dann versteht er auch IPv6 PD von der CB.

Jetzt bin ich glücklich. Mal sehen wwelche Endgeräte bei mir hier IPv6 können. :smile:

Vllt. kannst du mal ein paar Details von deiner Konfig posten?
1) ifconfig vom OpenWRT-Router (d.h.IP-Adresse und Präfixgröße vom LAN und WAN Interface)
2) Routen vom OpenWRT-Router (ip -6 route show)
2) Settings vom /etc/config/network (sowie ggfs. DHCPv6 Konfig)
3) Settings von der ConnectBox in Bezug auf DHCPv6 / SLAAC

 

[Evil.2000]

Is pretty much standard
DHCPv6 auf der CB ist stateless, rest ist default.
Ansonsten hab ich auf der CB alles auf aus was geht: kein DCHPv4, kein WLAN, keine v6 Firewall, kein UPnP, nix.

Auf dem WRT ist eth0 und wlan0 gebrückt als br-lan das LAN Netz, eth1 ist WAN zur CB.
Die unwichtigen Dinge hab ich mal entfernt:

ifconfig
br-lan Link encap:Ethernet HWaddr 00:11:22:33:44:55 inet addr:192.168.xxx.1 Bcast:192.168.xxx.255 Mask:255.255.255.0 inet6 addr: 2a02:908:xxxx:xxxx::1/62 Scope:Global inet6 addr: fda5:cef3:9db::1/60 Scope:Global inet6 addr: fe80::211:22ff:fe33:4455/64 Scope:Link
eth0 Link encap:Ethernet HWaddr 00:11:22:33:44:55
eth1 Link encap:Ethernet HWaddr CA:D7:19:DB:D3:49 inet addr:192.168.100.2 Bcast:192.168.100.255 Mask:255.255.255.0 inet6 addr: 2a02:908:xxxx:xxxx:xxxx:xxxx:xxx:4e82/128 Scope:Global inet6 addr: 2a02:908:xxxx:xxxx:c8d7:19ff:fedb:d349/64 Scope:Global inet6 addr: fe80::c8d7:19ff:fedb:d349/64 Scope:Link
wlan0 Link encap:Ethernet HWaddr C8:D7:19:DB:D3:49 inet6 addr: fe80::cad7:19ff:fedb:d349/64 Scope:Link

ip -6 route show
default from 2a02:908:xxxx:xxxx:2084:2baf:6365:4e82 via fe80::925c:44ff:fe24:65a7 dev eth1 metric 384
default from 2a02:908:xxxx:xxxx::/64 via fe80::925c:44ff:fe24:65a7 dev eth1 metric 384
default from 2a02:908:xxxx:xxxx::/62 via fe80::925c:44ff:fe24:65a7 dev eth1 metric 384
2a02:908:xxxx:xxxx::/64 dev eth1 metric 256
2a02:908:xxxx:xxxx::/64 via fe80::925c:44ff:fe24:65a7 dev eth1 metric 512
2a02:908:xxxx:xxxx::/64 dev br-lan metric 1024
unreachable 2a02:908:xxxx:xxxx::/62 dev lo metric 2147483647 error -148
fda5:cef3:9db::/64 dev br-lan metric 1024
unreachable fda5:cef3:9db::/48 dev lo metric 2147483647 error -148
fe80::/64 dev br-lan metric 256
fe80::/64 dev eth1 metric 256
fe80::/64 dev wlan0 metric 256
unreachable default dev lo metric -1 error -128
ff00::/8 dev br-lan metric 256
ff00::/8 dev eth1 metric 256
ff00::/8 dev wlan0 metric 256
unreachable default dev lo metric -1 error -128

/etc/config/network
config globals 'globals'	option ula_prefix 'fda5:cef3:09db::/48'
config interface 'lan'	option type 'bridge'	option ifname 'eth0'	option proto 'static'	option netmask '255.255.255.0'	option ip6assign '60'	option ipaddr '192.168.xxx.1'
config interface 'wan'	option ifname 'eth1'	option proto 'static'	option ipaddr '192.168.100.2'	option netmask '255.255.255.0'	option gateway '192.168.100.1'	option broadcast '192.168.100.255'	option dns '192.168.100.1'
config interface 'wan6'	option ifname 'eth1'	option proto 'dhcpv6'

/etc/config/dhcp
config dhcp 'lan'	option interface 'lan'	option dhcpv6 'server'	option ra 'server'	option ra_management '1'

 

[#DiRK]

Is pretty much standard
DHCPv6 auf der CB ist stateless, rest ist default.
Ansonsten hab ich auf der CB alles auf aus was geht: kein DCHPv4, kein WLAN, keine v6 Firewall, kein UPnP, nix.

Ich heul gleich: das ist genau die Konfig (mit kleinen Abweichungen), die ich gerne hätte aber die bei mir nicht lief.
Was ist da nur anders?????

Dennoch sind mir bei deinem Beitrag ein paar Kleinigkeiten aufgefallen:

- Grundsätzlich: Prefix Delegation geht meines Wissens ausschließlich über DHCPv6 und nicht über SLAAC. Also wenn bei dir stateless eingestellt ist sollten keine DHCPv6 Nachrichten aus der CB kommen. Zumindest bei mir ist es so.

- br-lan hat einen /62er Präfix - das ist das, was lt. anderen Beiträgen hier von UM verteilt wird. Müsste also rechnerisch 4 x /64er Netze ergeben. Was mich wiederum wundert, denn der 62er Präfix sollte dann "alle anderen" 64er Präfixe enthalten, was dann beim Routing Probleme verursachen sollte. Ich hätte erwartet, dass auf br-lan ebenfalls ein 64er Präfix anliegt (und zwar ungleich von dem bei der CB).

- eth1 hat eine /128 IP. Die kommt üblicherweise von einem DHCPv6 und wenn (nach deiner Aussage) keiner da ist, dann "baut" sich Openwrt einen alten /eigenen Eintrag. Ich würde das auf jeden Fall in den Interface Settings ausschalten - bei mir hat es unter OpenVPN bspw. Probleme verursacht. Also, in der GUI unter WAN6-Interface "Request IPv6-address = disabled"

- Routing: alle default Einträge zeigen auf die Link-local Adresse der CB (fe80::925c:44ff:fe24:65a7) - das ist gut. Der zweitoberste default Eintrag zeigt vermutlich auf das 64er Netz von der CB das sieht auch gut aus. Extrem verwunderlich finde ich jedoch den Eintrag

default from 2a02:908:xxxx:xxxx::/62 via fe80::925c:44ff:fe24:65a7 dev eth1 metric 384

Der zeigt nämlich auch auf die CB und sollte meines Erachtens da nicht hin, weil das Präfix ja eigentlich bei br-lan anliegt. Keine Ahnung wie das Routing gehen soll. Insbesondere weil die Zeile

 "unreachable 2a02:908:xxxx:xxxx::/62 dev lo metric 2147483647 error -148"

zeigt, dass etwas mit dem Routing für diesen Präfix nicht in Ordnung ist

- Routing: die weiteren unreachable Einträge sind m.E. unschön aber auch unproblematisch

- config lan: ip6assign = 60??? Soll das heißen, dass da ein 60er Präfix vergeben werden soll? Wird schwierig, wenn du nur ein 62er Präfix erhältst?!?!?

- config wan: dns = "192.168.100.1" also, DNS Server bei der CB??? Die macht auch nur ein Forward, d.h. du gewinnst Performance, wenn du gleich einen UM (oder sonstigen) DNS-Server einträgst. Am besten die IPv6 UM Server, denn die sind RICHTIG schnell (kein Umweg über AFTR).

Was mir fehlt, ist ein traceroute von einem Gerät im LAN, also Routing über 2 64er Netze raus und zurück.

Wie immer bleibe ich skeptisch.... "Gelöst" für den Thread würde ich nicht so sehen.

Dennoch danke für deine Unterstützung und wenn du das weiter analysieren möchtest, dann gerne PM.

 

[Evil.2000]

Ich heul gleich: das ist genau die Konfig (mit kleinen Abweichungen), die ich gerne hätte aber die bei mir nicht lief.
Was ist da nur anders?????

Das kann ich dir leider nicht sagen :-/
Ich muss zugeben, daß ich euer Gespräch nicht verfolgt hab und Dein Problem nicht kenne.

- Grundsätzlich: Prefix Delegation geht meines Wissens ausschließlich über DHCPv6 und nicht über SLAAC. Also wenn bei dir stateless eingestellt ist sollten keine DHCPv6 Nachrichten aus der CB kommen. Zumindest bei mir ist es so.

Mich wundert diese Einstellung auf der CB auch, denn m.E. bedeutet "stateless" SLAAC. Die Einstellung steht in der CB aber unter der Überschrift DHCPv6. Zumindest müssten die Einstellungen welche darunter stehen für lease time (oder so) deaktiviert werden.
Ich denke mal die Einstellung spielt keine Rolle.
Ich würde ja gern mal nen Sniffer zwischen CB und WRT hängen, aber ich hab kein TAP device da, welches 1000BaseT Ethernet kann. Vielleicht hast du ja ne Idee wie man mit einem Raspberry Pi oder mit anderer Low cost Hardware was bauen kann.

- br-lan hat einen /62er Präfix - das ist das, was lt. anderen Beiträgen hier von UM verteilt wird. Müsste also rechnerisch 4 x /64er Netze ergeben. Was mich wiederum wundert, denn der 62er Präfix sollte dann "alle anderen" 64er Präfixe enthalten, was dann beim Routing Probleme verursachen sollte. Ich hätte erwartet, dass auf br-lan ebenfalls ein 64er Präfix anliegt (und zwar ungleich von dem bei der CB).

Ich würde jetzt mal plump behaupten, 2a02:908:xxxx:xxxx::1/62 ist nicht aufgeteilt in 4 Netze sondern ein großes Netz von 2a02:908:xxxx:xxx0 bis 2a02:908:xxxx:xxx3. Jedenfalls laut http://www.gestioip.net/cgi-bin/subnet_calculator.cgi wenn ich mal 2a02:908:1:1:: eingebe und /62 einstelle.
Heißt: wenn ich tatsächlich jetzt 4 Netze aufspannen wollen würde müsste ich folgende Notationen verwenden:
2a02:0908:0001:0000::/64
2a02:0908:0001:0001::/64
2a02:0908:0001:0002::/64
2a02:0908:0001:0003::/64

- eth1 hat eine /128 IP. Die kommt üblicherweise von einem DHCPv6 und wenn (nach deiner Aussage) keiner da ist, dann "baut" sich Openwrt einen alten /eigenen Eintrag. Ich würde das auf jeden Fall in den Interface Settings ausschalten - bei mir hat es unter OpenVPN bspw. Probleme verursacht. Also, in der GUI unter WAN6-Interface "Request IPv6-address = disabled"

Da der Host Part nicht der MAC Adresse entspricht ist die 2a02:908:xxxx:xxxx:2084:2baf:6365:4e82/128 entweder vom DHCP entstanden (was meiner Vermutung mit der unwirksamen "stateless" Einstellung auf der CB entspricht) oder sie wurde durch die v6 PE erstellt.
ip -6 addr show sagt dazu "dynamic":

<i>
</i>ip -6 addr show
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000 inet6 2a02:908:xxxx:xxxx:c8d7:19ff:fedb:d349/64 scope global dynamic valid_lft 470166sec preferred_lft 167766sec inet6 2a02:908:xxxx:xxxx:2084:2baf:6365:4e82/128 scope global dynamic valid_lft 470036sec preferred_lft 167636sec inet6 fe80::c8d7:19ff:fedb:d349/64 scope link valid_lft forever preferred_lft forever

was auch meiner Sicht für DHCP spricht. Vetos?

- Routing: alle default Einträge zeigen auf die Link-local Adresse der CB (fe80::925c:44ff:fe24:65a7) - das ist gut. Der zweitoberste default Eintrag zeigt vermutlich auf das 64er Netz von der CB das sieht auch gut aus. Extrem verwunderlich finde ich jedoch den Eintrag

default from 2a02:908:xxxx:xxxx::/62 via fe80::925c:44ff:fe24:65a7 dev eth1 metric 384

Der zeigt nämlich auch auf die CB und sollte meines Erachtens da nicht hin, weil das Präfix ja eigentlich bei br-lan anliegt. Keine Ahnung wie das Routing gehen soll. Insbesondere weil die Zeile

 "unreachable 2a02:908:xxxx:xxxx::/62 dev lo metric 2147483647 error -148"

zeigt, dass etwas mit dem Routing für diesen Präfix nicht in Ordnung ist

Ja, gut aufgemerkt
Ich denke ich kann deine Verwunderung hiermit aufklären:

<i>
</i>default from 2a02:908:xxxx:xxx0:2084:2baf:6365:4e82 via fe80::925c:44ff:fe24:65a7 dev eth1 metric 384
default from 2a02:908:xxxx:xxx0::/64 via fe80::925c:44ff:fe24:65a7 dev eth1 metric 384
default from 2a02:908:xxxx:xxxc::/62 via fe80::925c:44ff:fe24:65a7 dev eth1 metric 384
2a02:908:xxxx:xxx0::/64 dev eth1 metric 256
2a02:908:xxxx:xxx0::/64 via fe80::925c:44ff:fe24:65a7 dev eth1 metric 512
2a02:908:xxxx:xxxc::/64 dev br-lan metric 1024

- config lan: ip6assign = 60??? Soll das heißen, dass da ein 60er Präfix vergeben werden soll? Wird schwierig, wenn du nur ein 62er Präfix erhältst?!?!?

Stimmt. Aber im LAN nutzen die Systeme SLAAC und ihren Gateway bekommen sie per RA. Und DNS weiß ich grad nicht ausm Kopf ob ich den static hab. Fakt ist das beim WRT keine vergebenen Leases eingetragen sind. Also nix statefull DHCP im LAN.

- config wan: dns = "192.168.100.1" also, DNS Server bei der CB??? Die macht auch nur ein Forward, d.h. du gewinnst Performance, wenn du gleich einen UM (oder sonstigen) DNS-Server einträgst. Am besten die IPv6 UM Server, denn die sind RICHTIG schnell (kein Umweg über AFTR).

Ja meine DNS forwardings sind recht vielfältig weil ich noch ein VPN habe in dem sich ein eigener DNS befindet und ich mit verschiedenen Regeln den anderen DNS ansprechen muss. Aber im Grunde hast du recht. Muss ich ändern.

Was mir fehlt, ist ein traceroute von einem Gerät im LAN, also Routing über 2 64er Netze raus und zurück.

Liefere ich Dir noch nach wenn ich zu Hause bin.

 

[#DiRK]

Ich heul gleich: das ist genau die Konfig (mit kleinen Abweichungen), die ich gerne hätte aber die bei mir nicht lief.
Was ist da nur anders?????

Das kann ich dir leider nicht sagen :-/
Ich muss zugeben, daß ich euer Gespräch nicht verfolgt hab und Dein Problem nicht kenne.

Ich kriege PD nicht zum Laufen und habe seither auch schon lange und viel probiert. Nun behaupte ich, dass kein PD seitens UM gemacht wird (zumindest für meinen Vertrag / Lokation).

- Grundsätzlich: Prefix Delegation geht meines Wissens ausschließlich über DHCPv6 und nicht über SLAAC. Also wenn bei dir stateless eingestellt ist sollten keine DHCPv6 Nachrichten aus der CB kommen. Zumindest bei mir ist es so.

Mich wundert diese Einstellung auf der CB auch, denn m.E. bedeutet "stateless" SLAAC. Die Einstellung steht in der CB aber unter der Überschrift DHCPv6. Zumindest müssten die Einstellungen welche darunter stehen für lease time (oder so) deaktiviert werden.
Ich denke mal die Einstellung spielt keine Rolle.

Ja und nein.
Wenn du DHCPv6 (stateful) auf der CB am Laufen hast, dann setzt die Box in den RAs das M und O Flag und weist den Geräten eine IPv6 (im Format Präfix::Zahl) zu. D.h. der Host-Teil ist weder Privacy Extensions noch EUI64.
Wenn du DHCPv6 auf der CB ausschaltest (stateless) dann vermutete ich, wie auch du, dass gar keine DHCPv6 Pakete verschickt werden. Nun habe ich aber mal mehrere Tage gesniffed und in der Tat kommen DHCPv6 Pakete an. D.h. die RAs haben nur das Flag O und in den DHCPv6 Paketen stecken Infos über DNS und anderes - aber leider kein PD :wand:

Ich würde ja gern mal nen Sniffer zwischen CB und WRT hängen, aber ich hab kein TAP device da, welches 1000BaseT Ethernet kann. Vielleicht hast du ja ne Idee wie man mit einem Raspberry Pi oder mit anderer Low cost Hardware was bauen kann.

Ich sniffe eigentlich immer über Shell mittels tcpdump und speichere das File ab. Dann analysiere ich es entweder mit tcpdump oder lade es in Wireshark.
Zum Sniffen von DHCPv6 und RA funktioniert

tcpdump -i eth1 -v -U -w RA+DHCPv6.pcap '(ip6 && icmp6 && (ip6[40] == 134)) or (udp and (port 546 or port 547))'

Das File wird dann auch nicht so groß, paar Megabytes in mehreren Tagen und kann auch gut analysiert werden. Damit ich die Session schließen kann, nutze ich tmux (oder alternativ screen). Beide Tools (tcpdump + tmux) sind über die Paketverwaltung erhältich und von der Größe her unproblematisch. Performance ist auch egal, da du ja sowieso 99% der Pakete über den Filter ignorierst.

- br-lan hat einen /62er Präfix - das ist das, was lt. anderen Beiträgen hier von UM verteilt wird. Müsste also rechnerisch 4 x /64er Netze ergeben. Was mich wiederum wundert, denn der 62er Präfix sollte dann "alle anderen" 64er Präfixe enthalten, was dann beim Routing Probleme verursachen sollte. Ich hätte erwartet, dass auf br-lan ebenfalls ein 64er Präfix anliegt (und zwar ungleich von dem bei der CB).

Ich würde jetzt mal plump behaupten, 2a02:908:xxxx:xxxx::1/62 ist nicht aufgeteilt in 4 Netze sondern ein großes Netz von 2a02:908:xxxx:xxx0 bis 2a02:908:xxxx:xxx3. Jedenfalls laut http://www.gestioip.net/cgi-bin/subnet_calculator.cgi wenn ich mal 2a02:908:1:1:: eingebe und /62 einstelle.
Heißt: wenn ich tatsächlich jetzt 4 Netze aufspannen wollen würde müsste ich folgende Notationen verwenden:
2a02:0908:0001:0000::/64
2a02:0908:0001:0001::/64
2a02:0908:0001:0002::/64
2a02:0908:0001:0003::/64

Sehe ich auch so! Bzw. da haben wir keinen Widerspruch.

- eth1 hat eine /128 IP. Die kommt üblicherweise von einem DHCPv6 und wenn (nach deiner Aussage) keiner da ist, dann "baut" sich Openwrt einen alten /eigenen Eintrag. Ich würde das auf jeden Fall in den Interface Settings ausschalten - bei mir hat es unter OpenVPN bspw. Probleme verursacht. Also, in der GUI unter WAN6-Interface "Request IPv6-address = disabled"

Da der Host Part nicht der MAC Adresse entspricht ist die 2a02:908:xxxx:xxxx:2084:2baf:6365:4e82/128 entweder vom DHCP entstanden (was meiner Vermutung mit der unwirksamen "stateless" Einstellung auf der CB entspricht) oder sie wurde durch die v6 PE erstellt.
ip -6 addr show sagt dazu "dynamic":

<i>
</i>ip -6 addr show
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000 inet6 2a02:908:xxxx:xxxx:c8d7:19ff:fedb:d349/64 scope global dynamic valid_lft 470166sec preferred_lft 167766sec inet6 2a02:908:xxxx:xxxx:2084:2baf:6365:4e82/128 scope global dynamic valid_lft 470036sec preferred_lft 167636sec inet6 fe80::c8d7:19ff:fedb:d349/64 scope link valid_lft forever preferred_lft forever

was auch meiner Sicht für DHCP spricht. Vetos?

Ja, ich. ;-)

Wie oben angesprochen, sieht mir das nicht nach eine CB vergebenen IPv6 Adresse aus. /128 deutet meines Wissens aber auch nicht auf Privacy Extensions hin, denn die haben den gleiche Präfix wie in den RAs versandt wurde.
Letztendlich hilft nur, wenn wir in das gesniffte File rein schauen. Ich kann dir meins mal uppen, wenn du schauen möchtest. Will das aber nicht der Community geben.

- Routing: alle default Einträge zeigen auf die Link-local Adresse der CB (fe80::925c:44ff:fe24:65a7) - das ist gut. Der zweitoberste default Eintrag zeigt vermutlich auf das 64er Netz von der CB das sieht auch gut aus. Extrem verwunderlich finde ich jedoch den Eintrag

default from 2a02:908:xxxx:xxxx::/62 via fe80::925c:44ff:fe24:65a7 dev eth1 metric 384

Der zeigt nämlich auch auf die CB und sollte meines Erachtens da nicht hin, weil das Präfix ja eigentlich bei br-lan anliegt. Keine Ahnung wie das Routing gehen soll. Insbesondere weil die Zeile

 "unreachable 2a02:908:xxxx:xxxx::/62 dev lo metric 2147483647 error -148"

zeigt, dass etwas mit dem Routing für diesen Präfix nicht in Ordnung ist

Ja, gut aufgemerkt
Ich denke ich kann deine Verwunderung hiermit aufklären:

<i>
</i>default from 2a02:908:xxxx:xxx0:2084:2baf:6365:4e82 via fe80::925c:44ff:fe24:65a7 dev eth1 metric 384
default from 2a02:908:xxxx:xxx0::/64 via fe80::925c:44ff:fe24:65a7 dev eth1 metric 384
default from 2a02:908:xxxx:xxxc::/62 via fe80::925c:44ff:fe24:65a7 dev eth1 metric 384
2a02:908:xxxx:xxx0::/64 dev eth1 metric 256
2a02:908:xxxx:xxx0::/64 via fe80::925c:44ff:fe24:65a7 dev eth1 metric 512
2a02:908:xxxx:xxxc::/64 dev br-lan metric 1024

Ja und nein. Jetzt wird es richtig spannend... (Obwohl ich nun wahrlich nicht der V6-Routing-Gott bin)

Warum ist das 2a02:908:xxxx:xxxc Netz mit /62 mit der default Route 3 über eth1, sprich Gateway CB eingetragen? Und warum ist das gleiche Netz mit /64 über br-lan sprich LAN eingetragen? Was passiert, wenn der Router ein Paket an das Netz routen möchte? Ich vermute, dass da eine der beiden Routen falsch oder ungenutzt ist.
Oder eine andere Vermutung: die hast einen RA Proxy am Laufen der die RAs/62 von der ConnectBox auf RAs/64 im LAN schickt?????!!!

- config lan: ip6assign = 60??? Soll das heißen, dass da ein 60er Präfix vergeben werden soll? Wird schwierig, wenn du nur ein 62er Präfix erhältst?!?!?

Stimmt. Aber im LAN nutzen die Systeme SLAAC und ihren Gateway bekommen sie per RA. Und DNS weiß ich grad nicht ausm Kopf ob ich den static hab. Fakt ist das beim WRT keine vergebenen Leases eingetragen sind. Also nix statefull DHCP im LAN.

Lol. Vermutlich hast du keine Windoof Büchsen am Laufen, denn die "lieben" statefull DHCPv6. DNS stecken oftmals in den RAs mit drin. Auch hier hilft sniffen. ;-)

 

[Andreas1969]

Nun behaupte ich, dass kein PD seitens UM gemacht wird (zumindest für meinen Vertrag / Lokation).

Kann ich mir absolut nicht vorstellen :traurig:
Wenn Du anstatt der Connectbox eine Fritzbox am DSLITE Anschluß laufen hast, funktioniert PD ja auch :winken:

 

[addicted]

<i>
</i>default from 2a02:908:xxxx:xxx0:2084:2baf:6365:4e82 via fe80::925c:44ff:fe24:65a7 dev eth1 metric 384
default from 2a02:908:xxxx:xxx0::/64 via fe80::925c:44ff:fe24:65a7 dev eth1 metric 384
default from 2a02:908:xxxx:xxxc::/62 via fe80::925c:44ff:fe24:65a7 dev eth1 metric 384
2a02:908:xxxx:xxx0::/64 dev eth1 metric 256
2a02:908:xxxx:xxx0::/64 via fe80::925c:44ff:fe24:65a7 dev eth1 metric 512
2a02:908:xxxx:xxxc::/64 dev br-lan metric 1024

Ja und nein. Jetzt wird es richtig spannend... (Obwohl ich nun wahrlich nicht der V6-Routing-Gott bin)

Warum ist das 2a02:908:xxxx:xxxc Netz mit /62 mit der default Route 3 über eth1, sprich Gateway CB eingetragen? Und warum ist das gleiche Netz mit /64 über br-lan sprich LAN eingetragen? Was passiert, wenn der Router ein Paket an das Netz routen möchte? Ich vermute, dass da eine der beiden Routen falsch oder ungenutzt ist.

Erstmal Vorsicht: Die default-Routen haben einen "from"-Match, hier wird also Source-/Policy-Routing gemacht. Ich kenne das Featureset des Routers nicht, daher kann ich nicht beurteilen wozu das in diesem Fall notwendig ist. Normalerweise macht man Policy-Routing etwas anders (mit mehreren Routing-Tabellen und entsprechenden Matches über `ip rule`).

Falls es aber wirklich zwei Routen für das selbe Ziel gäbe, die sich nur in der Länge des Präfix unterscheiden, dann würde die mit dem längeren Präfix ausgewählt (also wird /64 über /62 bevorzugt). Das kann man auch gut an der Default-Route nachvollziehen, diese hat nämlich die Präfixlänge Null (die Route ist eigentlich "0.0.0.0/0" bzw. "::/0"). In der Regel haben alle anderen Routen ein längeres Präfix (z.B. /24 bei v4 oder /64 bei v6) und werden daher bevorzugt.
Falls es mehrere Einträge mit der gleichen Präfixlänge gibt, nimmt man die beste "Metric", danach ist die Auswahl unbestimmt.

 

[#DiRK]

<i>
</i>default from 2a02:908:xxxx:xxx0:2084:2baf:6365:4e82 via fe80::925c:44ff:fe24:65a7 dev eth1 metric 384
default from 2a02:908:xxxx:xxx0::/64 via fe80::925c:44ff:fe24:65a7 dev eth1 metric 384
default from 2a02:908:xxxx:xxxc::/62 via fe80::925c:44ff:fe24:65a7 dev eth1 metric 384
2a02:908:xxxx:xxx0::/64 dev eth1 metric 256
2a02:908:xxxx:xxx0::/64 via fe80::925c:44ff:fe24:65a7 dev eth1 metric 512
2a02:908:xxxx:xxxc::/64 dev br-lan metric 1024

Ja und nein. Jetzt wird es richtig spannend... (Obwohl ich nun wahrlich nicht der V6-Routing-Gott bin)

Warum ist das 2a02:908:xxxx:xxxc Netz mit /62 mit der default Route 3 über eth1, sprich Gateway CB eingetragen? Und warum ist das gleiche Netz mit /64 über br-lan sprich LAN eingetragen? Was passiert, wenn der Router ein Paket an das Netz routen möchte? Ich vermute, dass da eine der beiden Routen falsch oder ungenutzt ist.

Erstmal Vorsicht: Die default-Routen haben einen "from"-Match, hier wird also Source-/Policy-Routing gemacht. Ich kenne das Featureset des Routers nicht, daher kann ich nicht beurteilen wozu das in diesem Fall notwendig ist. Normalerweise macht man Policy-Routing etwas anders (mit mehreren Routing-Tabellen und entsprechenden Matches über `ip rule`).

Falls es aber wirklich zwei Routen für das selbe Ziel gäbe, die sich nur in der Länge des Präfix unterscheiden, dann würde die mit dem längeren Präfix ausgewählt (also wird /64 über /62 bevorzugt). Das kann man auch gut an der Default-Route nachvollziehen, diese hat nämlich die Präfixlänge Null (die Route ist eigentlich "0.0.0.0/0" bzw. "::/0"). In der Regel haben alle anderen Routen ein längeres Präfix (z.B. /24 bei v4 oder /64 bei v6) und werden daher bevorzugt.
Falls es mehrere Einträge mit der gleichen Präfixlänge gibt, nimmt man die beste "Metric", danach ist die Auswahl unbestimmt.

Wieder was gelernt. Das war mir so nicht bewusst. Danke, addicted.

 

[Evil.2000]

Erstmal Vorsicht: Die default-Routen haben einen "from"-Match, hier wird also Source-/Policy-Routing gemacht. Ich kenne das Featureset des Routers nicht, daher kann ich nicht beurteilen wozu das in diesem Fall notwendig ist. Normalerweise macht man Policy-Routing etwas anders (mit mehreren Routing-Tabellen und entsprechenden Matches über `ip rule`).

Falls es aber wirklich zwei Routen für das selbe Ziel gäbe, die sich nur in der Länge des Präfix unterscheiden, dann würde die mit dem längeren Präfix ausgewählt (also wird /64 über /62 bevorzugt). Das kann man auch gut an der Default-Route nachvollziehen, diese hat nämlich die Präfixlänge Null (die Route ist eigentlich "0.0.0.0/0" bzw. "::/0"). In der Regel haben alle anderen Routen ein längeres Präfix (z.B. /24 bei v4 oder /64 bei v6) und werden daher bevorzugt.
Falls es mehrere Einträge mit der gleichen Präfixlänge gibt, nimmt man die beste "Metric", danach ist die Auswahl unbestimmt.

Das wollte ich auch anmerken. Danke addicted
Hier noch ein Screenshot des LuCI das diese These bekräftigt:

 

[Evil.2000]

So, einen traceroute hab ich nicht aber vielleicht hilft dir das weiter:

03:55:57,238 fe80::925c:44ff:fe24:65a7 fe80::c8d7:19ff:fedb:d349 DHCPv6 292 Advertise XID: 0x7d9a39 IAA: 2a02:908:xxxx:xxx0:2084:2baf:6365:4e82 CID: 00030001cad719dbd349
Frame 350: 292 bytes on wire (2336 bits), 292 bytes captured (2336 bits)
Ethernet II, Src: CompalBr_24:65:a7 (90:5c:44:24:65:a7), Dst: ca:d7:19:db:d3:49 (ca:d7:19:db:d3:49)
Internet Protocol Version 6, Src: fe80::925c:44ff:fe24:65a7, Dst: fe80::c8d7:19ff:fedb:d349
User Datagram Protocol, Src Port: 547, Dst Port: 546
DHCPv6 Message type: Advertise (2) Transaction ID: 0x7d9a39 Identity Association for Non-temporary Address Option: Identity Association for Non-temporary Address (3) Length: 66 Value: 000000010001a5e10002a302000500182a0209080xxxxxxx0... IAID: 00000001 T1: 108001 T2: 172802 IA Address Option: IA Address (5) Length: 24 Value: 2a0209080xxxxxxx020842baf63654e8200034bc30007e903 IPv6 address: 2a02:908:xxxx:xxx0:2084:2baf:6365:4e82 Preferred lifetime: 216003 Valid lifetime: 518403 Status code Option: Status code (13) Length: 22 Value: 000041737369676e656420616e20616464726573732e Status Code: Success (0) Status Message: Assigned an address. Identity Association for Prefix Delegation Option: Identity Association for Prefix Delegation (25) Length: 69 Value: 000000010001a5e10002a302001a001900034bc30007e903... IAID: 00000001 T1: 108001 T2: 172802 IA Prefix Option: IA Prefix (26) Length: 25 Value: 00034bc30007e9033e2a0209080xxxxxxxc00000000000000... Preferred lifetime: 216003 Valid lifetime: 518403 Prefix length: 62 Prefix address: 2a02:908:xxxx:xxxc:: Status code Option: Status code (13) Length: 24 Value: 000041737369676e6564203120707265666978286573292e Status Code: Success (0) Status Message: Assigned 1 prefix(es). Server Identifier Option: Server Identifier (2) Length: 24 Value: 00010301222a35fb2a02090806000007583d98b037e9d99e DUID: 00010301222a35fb2a02090806000007583d98b037e9d99e DUID Type: link-layer address plus time (1) Hardware type: Unknown (769) DUID Time: Mar 1, 2018 04:54:35.000000000 CET Link-layer address: 2a02090806000007583d98b037e9d99e Client Identifier Option: Client Identifier (1) Length: 10 Value: 00030001cad719dbd349 DUID: 00030001cad719dbd349 DUID Type: link-layer address (3) Hardware type: Ethernet (1) Link-layer address: ca:d7:19:db:d3:49 Preference Option: Preference (7) Length: 1 Value: 00 Pref-value: 0 DNS recursive name server Option: DNS recursive name server (23) Length: 32 Value: 2a0209080002000a00000000000000012a0209080002000b... 1 DNS server address: 2a02:908:2:a::1 2 DNS server address: 2a02:908:2:b::1

 

[#DiRK]

So, einen traceroute hab ich nicht aber vielleicht hilft dir das weiter:

03:55:57,238 fe80::925c:44ff:fe24:65a7 fe80::c8d7:19ff:fedb:d349 DHCPv6 292 Advertise XID: 0x7d9a39 IAA: 2a02:908:xxxx:xxx0:2084:2baf:6365:4e82 CID: 00030001cad719dbd349
Frame 350: 292 bytes on wire (2336 bits), 292 bytes captured (2336 bits)
Ethernet II, Src: CompalBr_24:65:a7 (90:5c:44:24:65:a7), Dst: ca:d7:19:db:d3:49 (ca:d7:19:db:d3:49)
Internet Protocol Version 6, Src: fe80::925c:44ff:fe24:65a7, Dst: fe80::c8d7:19ff:fedb:d349
User Datagram Protocol, Src Port: 547, Dst Port: 546
DHCPv6 Message type: Advertise (2) Transaction ID: 0x7d9a39 Identity Association for Non-temporary Address Option: Identity Association for Non-temporary Address (3) Length: 66 Value: 000000010001a5e10002a302000500182a0209080xxxxxxx0... IAID: 00000001 T1: 108001 T2: 172802 IA Address Option: IA Address (5) Length: 24 Value: 2a0209080xxxxxxx020842baf63654e8200034bc30007e903 IPv6 address: 2a02:908:xxxx:xxx0:2084:2baf:6365:4e82 Preferred lifetime: 216003 Valid lifetime: 518403 Status code Option: Status code (13) Length: 22 Value: 000041737369676e656420616e20616464726573732e Status Code: Success (0) Status Message: Assigned an address. Identity Association for Prefix Delegation Option: Identity Association for Prefix Delegation (25) Length: 69 Value: 000000010001a5e10002a302001a001900034bc30007e903... IAID: 00000001 T1: 108001 T2: 172802 IA Prefix Option: IA Prefix (26) Length: 25 Value: 00034bc30007e9033e2a0209080xxxxxxxc00000000000000... Preferred lifetime: 216003 Valid lifetime: 518403 Prefix length: 62 Prefix address: 2a02:908:xxxx:xxxc:: Status code Option: Status code (13) Length: 24 Value: 000041737369676e6564203120707265666978286573292e Status Code: Success (0) Status Message: Assigned 1 prefix(es). Server Identifier Option: Server Identifier (2) Length: 24 Value: 00010301222a35fb2a02090806000007583d98b037e9d99e DUID: 00010301222a35fb2a02090806000007583d98b037e9d99e DUID Type: link-layer address plus time (1) Hardware type: Unknown (769) DUID Time: Mar 1, 2018 04:54:35.000000000 CET Link-layer address: 2a02090806000007583d98b037e9d99e Client Identifier Option: Client Identifier (1) Length: 10 Value: 00030001cad719dbd349 DUID: 00030001cad719dbd349 DUID Type: link-layer address (3) Hardware type: Ethernet (1) Link-layer address: ca:d7:19:db:d3:49 Preference Option: Preference (7) Length: 1 Value: 00 Pref-value: 0 DNS recursive name server Option: DNS recursive name server (23) Length: 32 Value: 2a0209080002000a00000000000000012a0209080002000b... 1 DNS server address: 2a02:908:2:a::1 2 DNS server address: 2a02:908:2:b::1

Ja, das hilft und ist auch ein unmissverständlicher Nachweis, dass die CB ein Präfix /62 vergibt.

 

[#DiRK]

Um den Thread nochmals kurz zu reaktivieren, habe ich News bzgl. meines Problems der Prefix Delelgation mit ConnectBox.

Denn entscheidenden Hinweise hat mir @Dillkr geliefert: einfach mal Werksreset bei der CB durchführen und beim nächsten Reboot gibts auch ein /62er Präfix. Das tut zwischenzeitlich auch sehr sicher und regelmäßig bei mir.

Ein (etwas dumme) Einschränkung gibt es noch: wenn die CB zwischenzeitlich mal neu gestartet wird, wird das Präfix nicht mehr delegiert und die CB gibt aus "No Prefix available". Also muss es immer ein Werksreset sein.

Dumm ist nur, dass ich nächtlich die ConnectBox mit einer Zeitschaltuhr ca. 20 Minuten vom Strom getrennt habe, um andere seltsame Symptome (Stichwort: Memory Leak) zu beseitigen. Somit habe ich nun die Wahl zwischen Pest und Cholera.

Anyway, bald ist bei mir die Schweine-Box sowie Geschichte und ein TC4400 wird seinen Dienst aufnehmen. Dann gehören die Probleme endlich der Vergangenheit an und vielleicht läuft dann mein Internet so gut wie bei meinem vorherigen Provider, Deutsche Telekom. Dort hatte ich zwar nur die Hälfte an Speed, dafür auch die Hälfte an Ping Zeiten und insbesondere ein Vielfaches an Qualität in der technischen Bereitstellung.

 

[Andreas1969]

Anyway, bald ist bei mir die Schweine-Box sowie Geschichte und ein TC4400 wird seinen Dienst aufnehmen. Dann gehören die Probleme endlich der Vergangenheit an und vielleicht läuft dann mein Internet so gut wie bei meinem vorherigen Provider, Deutsche Telekom.

Ja, wird es tun, da bin ich mir sicher :zwinker:
Bei mir haben sich sämtliche Probleme, die ich vorher hatte, mit dem TC4400 in Luft aufgelöst :super: