Unitymedia Unitymedia nimmt IPv6 Prefix

[Joerg123]

Nein die IP hat sich nicht geändert, ich schrieb "die Fritzbox Push-Mail bezüglich neuer IP" mit dem Inhalt "Your FRITZ!Box 6490 Cable (lgi) [My-Router] received the following web address: 109.90.196.123."
Wobei das 123 nicht die tatsächliche IP ist, aber es ist schon so gemeint: sie hat sich nicht geändert (war schon vor dem ersten erneuern die gleiche IP).

Beim Thread-Ersteller war das Problem doch ebenfalls die IPv6 (der Tunnel) ! und es ging mir auch nur um die Bestätigung, dass ich hier ebenfalls kein lokales Problem beim Kunden sehe, dafür bestätigen kann, dass UM-seitig offensichtlich was im Argen liegt
und wie man bei mir am Log sieht: nur weil man nativ IPv4 hat wird man damit nicht glücklicher, denn Fritte trennt alleine wegen des fehlenden Tunnels die Verbindung und verbindet neu .
Wenn es so garnicht klappt (bei mir waren es ja nur ca 15 Minuten), würde wahrscheinlich helfen in den Interneteinstellungen > Verbindungstyp die IPv6 Unterstützung auszuschalten und ausschliesslich IPv4 zu nutzen (wird zumindest für fast alles reichen) - also bei der Fritte, wie das bei anderen Geräten läuft kann ich schlecht sagen.

 

[tq1199]

..., denn Fritte trennt alleine wegen des fehlenden Tunnels die Verbindung und verbindet neu .

Ich denke nicht, dass der 6in4-Tunnel die Ursache für das Trennen der Verbindung war:

12.10.18 16:06:50 Internet connection cleared.
12.10.18 16:06:50 IPv6 Internet connection was cleared; prefix no longer valid.
12.10.18 16:06:50 Cable Internet not responding (no synchronization).

Zumindest kann man das aus "Cable Internet not responding (no synchronization)" nicht ableiten bzw. nicht schlussfolgern.


M. E. ist als 1. (warum auch immer) keine IPv4-Internetverbindung zustande gekommen und als Folge dann das "IPv6 Internet connection was cleared; prefix no longer valid".

An meinem Anschluss kam nach einem eindeutigen IPv4-Problem (DHCPv4) auch die Meldung mit dem nicht mehr gültigen IPv6-Präfix:

10.10.18 12:52:23 Internetverbindung IPv6 wurde getrennt, Präfix nicht mehr gültig.
10.10.18 12:52:23 Internetverbindung ist fehlgeschlagen: Fehlergrund: 4 (DHCPv4 nak)

 

[addicted]

Beim Thread-Ersteller war das Problem doch ebenfalls die IPv6 (der Tunnel) !

Der TE hat keinen Tunnel!

 

[rv112]

Bei mir wird auch die IPv4 Verbindung nicht getrennt wenn man keine IPv6 bekommt. Wieso das Fritte macht versteh ich nicht. Wir haben doch natives Dualstack. Bei mir bricht wenn einfach der IPv6 Prefix weg und der UM Router teilt mir keinen mehr zu, bis ich die DUID ändere oder die Leasetime ablaufen lasse.

 

[Joerg123]

@rv112
in deiner Signatur steht das DS für Dual Stack ?
weil das konnte ich so nicht zuordnen (bei uns in NRW gibts das eh nicht). Wo da dick ud fett steht "Kabel BW seit 2003" hab ich mal IPv4 vorraus gesetzt.

@tq1199
dann hat das Log die von dir dazu interpretierten Probleme einfach mal für sich behalten *g*
im gesamten Log steht zwar zweimal die zugewiesene IPv4, aber nicht einmal was von IPv4 getrennt
und bei mir ist es so direkt das Log der Fritte ohne was rauszunehmen (bei rv112 scheint es ja nur der DHCP-IPv6-C(lient) Part zu sein, der in seinem Log steht (so verstehe ich den Prozessnamen)

 

[tq1199]

...
im gesamten Log steht zwar zweimal die zugewiesene IPv4, aber nicht einmal was von IPv4 getrennt
und bei mir ist es so direkt das Log der Fritte ohne was rauszunehmen ...

Doch, denn das:

<i>
</i>12.10.18	16:06:50	Internet connection cleared.
12.10.18	16:06:50	Cable Internet not responding (no synchronization).

bezieht sich auf IPv4. Du hast nur natives IPv4 (im Business-Tarif). Wenn keine IPv4-Internetverbindung vorhanden ist, ist auch eine 6in4-Tunnelverbindung nicht möglich bzw. auch kein gültiger 6in4-IPv6-Präfix vorhanden.

 

[tq1199]

... (bei uns in NRW gibts das eh nicht). ..

BTW: In BaWü gibt es DS im Business-Tarif auch nicht.

 

[rv112]

Ja DS steht für Dualstack. Das gibt es auch in NRW Ich beziehe mich also auf nativ IPv6, keinen Tunnel.

 

[rv112]

Und es ist wieder soweit! :wand:

Oct 14 21:50:30	dhcpd	Copyright 2004-2018 Internet Systems Consortium.
Oct 14 21:50:30	dhcpd	Internet Systems Consortium DHCP Server 4.3.6-P1
Oct 14 21:50:30	dhcp6c	68634	executes /var/etc/dhcp6c_wan_script.sh
Oct 14 21:50:30	dhcp6c	68634	reset a timer on igb0, state=INIT, timeo=0, retrans=557
Oct 14 21:50:30	dhcp6c	68634	remove an IA: PD-0
Oct 14 21:50:30	dhcp6c	68634	IA PD-0 is invalidated
Oct 14 21:50:30	dhcp6c	68634	status code for PD-0: no prefixes
Oct 14 21:50:30	dhcp6c	68634	make an IA: PD-0
Oct 14 21:50:30	dhcp6c	68634	nameserver[1] 2a02:908:2:b::1
Oct 14 21:50:30	dhcp6c	68634	nameserver[0] 2a02:908:2:a::1
Oct 14 21:50:30	dhcp6c	68634	dhcp6c Received REQUEST
Oct 14 21:50:30	dhcp6c	68634	preference: 255
Oct 14 21:50:30	dhcp6c	68634	get DHCP option preference, len 1
Oct 14 21:50:30	dhcp6c	68634	get DHCP option DNS, len 32
Oct 14 21:50:30	dhcp6c	68634	status code: no prefixes
Oct 14 21:50:30	dhcp6c	68634	get DHCP option status code, len 46
Oct 14 21:50:30	dhcp6c	68634	IA_PD: ID=0, T1=0, T2=0
Oct 14 21:50:30	dhcp6c	68634	get DHCP option IA_PD, len 62
Oct 14 21:50:30	dhcp6c	68634	DUID: 00:01:00:01:15:b9:82:b6:xxx
Oct 14 21:50:30	dhcp6c	68634	get DHCP option server ID, len 14
Oct 14 21:50:30	dhcp6c	68634	DUID: 00:01:00:01:23:50:57:d1:40:62:xxx
Oct 14 21:50:30	dhcp6c	68634	get DHCP option client ID, len 14
Oct 14 21:50:30	dhcp6c	68634	receive reply from fe80::201:5cff:fe6b:e046%igb0 on igb0
Oct 14 21:50:30	dhcp6c	68634	reset a timer on igb0, state=REQUEST, timeo=0, retrans=1024
Oct 14 21:50:30	dhcp6c	68634	send request to ff02::1:2%igb0
Oct 14 21:50:30	dhcp6c	68634	set IA_PD
Oct 14 21:50:30	dhcp6c	68634	set status code
Oct 14 21:50:30	dhcp6c	68634	set option request (len 4)
Oct 14 21:50:30	dhcp6c	68634	set elapsed time (len 2)
Oct 14 21:50:30	dhcp6c	68634	set server ID (len 14)
Oct 14 21:50:30	dhcp6c	68634	set client ID (len 14)
Oct 14 21:50:30	dhcp6c	68634	a new XID (8c420f) is generated
Oct 14 21:50:30	dhcp6c	68634	Sending Request

Und ein paar Minuten später mit neuer DUID:

Oct 14 22:06:25	dhcp6c	41661	add an address 2a02:8071:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx/64 on igb2
Oct 14 22:06:25	dhcp6c	41661	create a prefix 2a02:8071:xxxx:xxxx::/56 pltime=604800, vltime=1209600
Oct 14 22:06:25	dhcp6c	41661	make an IA: PD-0
Oct 14 22:06:25	dhcp6c	41661	nameserver[1] 2a02:908:2:b::1
Oct 14 22:06:25	dhcp6c	41661	nameserver[0] 2a02:908:2:a::1
Oct 14 22:06:25	dhcp6c	41661	dhcp6c Received REQUEST
Oct 14 22:06:25	dhcp6c	41661	preference: 255
Oct 14 22:06:25	dhcp6c	41661	get DHCP option preference, len 1
Oct 14 22:06:25	dhcp6c	41661	get DHCP option DNS, len 32
Oct 14 22:06:25	dhcp6c	41661	IA_PD prefix: 2a02:8071:xxxx:xxxx::/56 pltime=604800 vltime=1209600
Oct 14 22:06:25	dhcp6c	41661	get DHCP option IA_PD prefix, len 25
Oct 14 22:06:25	dhcp6c	41661	IA_PD: ID=0, T1=302400, T2=483840
Oct 14 22:06:25	dhcp6c	41661	get DHCP option IA_PD, len 41
Oct 14 22:06:25	dhcp6c	41661	DUID: 00:01:00:01:15:b9:82:xxx
Oct 14 22:06:25	dhcp6c	41661	get DHCP option server ID, len 14
Oct 14 22:06:25	dhcp6c	41661	DUID: 00:03:00:01:40:xxx
Oct 14 22:06:25	dhcp6c	41661	get DHCP option client ID, len 10
Oct 14 22:06:25	dhcp6c	41661	receive reply from fe80::201:5cff:fe6b:e046%igb0 on igb0
Oct 14 22:06:25	dhcp6c	41661	reset a timer on igb0, state=REQUEST, timeo=2, retrans=3858
Oct 14 22:06:25	dhcp6c	41661	send request to ff02::1:2%igb0
Oct 14 22:06:25	dhcp6c	41661	set IA_PD
Oct 14 22:06:25	dhcp6c	41661	set IA_PD prefix
Oct 14 22:06:25	dhcp6c	41661	set option request (len 4)
Oct 14 22:06:25	dhcp6c	41661	set elapsed time (len 2)
Oct 14 22:06:25	dhcp6c	41661	set server ID (len 14)
Oct 14 22:06:25	dhcp6c	41661	set client ID (len 10)
Oct 14 22:06:25	dhcp6c	41661	Sending Request

 

[rv112]

Heute Morgen das gleiche Spiel! Diesmal beschloss ich nichts zu machen und einfach abzuwarten. Und nach einer guten Stunde hatte ich wieder eine IPv6! Beim durchsehen der Logs fiel mir jedoch etwas Interessantes auf. Wie es scheint weißen mir zwei unterschiedliche Server Prefixe zu, bzw. werden angefordert. Die Server DUID unterscheidet sich dabei!
DUID 00:01:00:01:15:b9:82:b6:00:18:51:df:80:41 sagt mir immer No-Prefix. DUID 00:01:00:01:1a:7b:db:22:00:18:51:3b:5e:e8 weißt mir sofort das /56 zu. Nur wieso? Wie kann das sein? Wieso bricht plötzlich die Connectivität weg obwohl meine Interfaces noch die Prefixe halten?

Hier hat jemand mit komplett anderer Hardware das gleiche Problem: http://modem380.rssing.com/browser.php?indx=26038623&item=8433

Dessen Lösung lautete:

Yesterday I discovered that I now have Internet access via IPv6 and am getting a 10/10 result on website test-ipv6.com. I had not rebooted my cable modem or router. I'm assuming that Comcast made changes to their network configuration on my branch of their network to allow Internet access to IPv6 traffic whose source address contains a /64 prefix.



In summary: Initially I called Comcast support but they do not have the knowledge to resolve this type of issue. Using a non-standard router firmware known as Shibby Tomato version 131 I was able to use a DHCP IPv6 client debugger and network tool tcpdump on the router to determine that the issue was on Comcast's side of the network. For Comcast customers that are getting a 0/10 result on website test-ipv6.com and are not a networking student like me I suggest simply posting a forum entry and working with the forum experts. Many thanks to the forum experts who worked with the Comcast network folks to resolve this issue on their side.

 

[tq1199]

Wie es scheint weißen mir zwei unterschiedliche Server Prefixe zu, bzw. werden angefordert. Die Server DUID unterscheidet sich dabei!
DUID 00:01:00:01:15:b9:82:b6:00:18:51:df:80:41 sagt mir immer No-Prefix. DUID 00:01:00:01:1a:7b:db:22:00:18:51:3b:5e:e8 weißt mir sofort das /56 zu. Nur wieso? Wie kann das sein? Wieso bricht plötzlich die Connectivität weg obwohl meine Interfaces noch die Prefixe halten?

Kannst Du evtl. als Test in deinem border device, den Zugang zum DHCPv6-Server mit der DUID 00:01:00:01:15:b9:82:b6:00:18:51:df:80:41 blocken oder umleiten auf den DHCPv6-Server mit der DUID 00:01:00:01:1a:7b:db:22:00:18:51:3b:5e:e8?

 

[rv112]

Ich glaube das geht mit pfSense nicht.

 

[tq1199]

Heute Morgen das gleiche Spiel! Diesmal beschloss ich nichts zu machen und einfach abzuwarten. Und nach einer guten Stunde hatte ich wieder eine IPv6! Beim durchsehen der Logs fiel mir jedoch etwas Interessantes auf. Wie es scheint weißen mir zwei unterschiedliche Server Prefixe zu, bzw. werden angefordert. Die Server DUID unterscheidet sich dabei!

Evtl. in so einem Fall, auch die Kommunikation (dhcp6 renew, dhcp6 reply, reconfigure-accept, etc.) zwischen v6-DHCP-Client und v6-DHCP-Server mit z. B.:

<i>
</i>tcpdump -vvveni <WAN-Interface> ip6 and udp portrange 546-547

(oder gleichwertig) anschauen.

 

[rv112]

Ich hab das ja schon mal mit geschnitten. Da war alles ganz normal, außer dass mir der Router bei UM dann mitgeteilt hat dass er keine Prefixe für mich mehr hat. Werde ich beim nächsten mal noch mal machen.

 

[why_]

... (bei uns in NRW gibts das eh nicht). ..

BTW: In BaWü gibt es DS im Business-Tarif auch nicht.

Gibt es schon, muss man nur penetrant sein.

 

[tq1199]

Gibt es schon, ...

Auch wenn man als Business-Kunden schon eine (oder mehrere) statische(n) IPv4-Adresse(n) hat und diese auch behalten will?

 

[addicted]

Soweit ich weiß kann man DS aktuell nicht mit statischen Adressen machen.
UM ist für sowas echt nicht der richtige ISP.

 

[tq1199]

... mir der Router bei UM dann mitgeteilt hat dass er keine Prefixe für mich mehr hat.

Wenn dein DHCPv6-Client (auf dem border device) es unterstützt, dann versuch mal (als Test) statt der DUID eine ClientID (gemäß RFC6939) für die Identifizierung am DHCPv6-Server (Router bei UM) zu verwenden. Evtl. unterstützt der DHCPv6-Server von UM das.

 

[rv112]

Nein tut er nicht, schon versucht.

 

[why_]

Gibt es schon, ...

Auch wenn man als Business-Kunden schon eine (oder mehrere) statische(n) IPv4-Adresse(n) hat und diese auch behalten will?

Die schalten dann nicht das b2b Profil, sondern das generic oder wie das für Privatkunden heißt, aber man konnte dann feste IPs an Mac Adressen binden im Kundencenter wie bei jedem anderen Business Anschluss.

 

[rv112]

So eben Rückruf aus Köln bekommen.

TL;DR: man könnte sich vorstellen dass das Problem ist weil im UM System mein Modem als Fritte hinterlegt ist. Man würde mich daher gerne weiterleiten an die kaufmännische Abteilung dass die von Hand es als TC4400 eintragen und eben nicht als Fritte. Ich habe dann ein paar Stories bzgl. kaufmännische Abteilung erzählt und mein netter Gesprächspartner erwiderte nach einem Lachanfall dass er davon ausgeht ich möchte es lieber nicht versuchen.
Wir kamen also auf den Punkt dass man ohne die Gefahr mein Modem zu deprovisionieren nicht weiter kommt. Da auch hier vermutlich demnächst auf D3.1 ausgebaut werden soll und mein Modem ja kompatibel sei (seine Worte ) werde ich abwarten. Vielleicht passiert bis dahin dann etwas mit der Konfiguration bei UM.
Nach etwas Smalltalk kam ich dann auf meine Telekomleitung und dass es dort überhaupt keine Probleme mit IPv6 gibt. Hier wurde dann auch von seiner Seite aus empfohlen das Ticket vorerst zu schließen um keinen weiteren Schaden anzurichten.

Ich werde es demnach einfach beobachten müssen. Bisher läuft es wieder ohne Probleme, vielleicht bleibt es so ja wieder einige Monate

 

[tq1199]

... dann auf meine Telekomleitung und dass es dort überhaupt keine Probleme mit IPv6 gibt. ...

Welches border device hast Du am Telekomanschluss?

 

[rv112]

Ein Draytek Vigor 130 Modem.

 

[tq1199]

Ein Draytek Vigor 130 Modem.

Benutzt Du dieses Gerät nur als Modem? Wenn ja, ist es dann transparent und bekommt keine externe/öffentliche IP(v4)-Adresse?

 

[rv112]

Ja klar, wird nur als Modem betrieben. Die Einwahl usw. übernimmt die gleiche pfSense dahinter wie am UM Anschluss. (Dual WAN)