Beiträge von kbr

Ist ja hervorragend, bei DG hat man im Kundencenter jetzt nur noch die Möglichkeit, über einen Messenger Nachrichten zu schreiben, und da landet man erstmal bei einer KI 🤮

Doch, weiß nicht obs das noch gibt, aber über Teredo wurde man einfach durchgetunnelt, und das hatten einige Betriebssysteme per Default aktiviert.

Zitat von mattes

Mich hats jetzt auch erwischt in 41xxx. Ich habe hinter dem Modem eine Fritzbox 7690, und erhalte keine IPv6-Adresse mehr (vermutlich seit Freitag). Ist mir erst aufgefallen, weil mein VPN ins Heimnetz nicht mehr läuft...

Die Box zeigt zwei Meldungen an:

Die DG schreibt wieder nur Anleitungen, dass das Modem neugestartet werden soll und mein Router ja das Problem ist, da sie ja eine IPv6 per DHCP verteilen würden. Allerdings erhalte ich von der DG ja keine.

Gibts da Stichwörter mit denen ich zu einem kompetenterem Servicelevel weiter komme oder muss ich es einfach immer wieder versuchen?

keine Adresse bekommen ist aber ein anderes Problem, hier geht es eigentlich ausschließlich darum, daß wir sehr wohl eine Adresse bekommen, aber der Zugriff trotzdem nicht funktioniert.

IPv6 ist Teufelszeug, einmal nicht aufgepasst, und ruck zuck ist dein Rechner aus dem Internet erreichbar

Zitat von frank_m

Falls das nicht klar geworden ist: Die Kommunikationsmöglichkeit der Anschlüsse untereinander ist ein Feature, kein Bug. Spätestens mit öffentlichen IPv6 Adressen sollte das selbstverständlich sein

jetzt verstehe ich

Ich versteh es immer noch nicht, der BNG bräuchte doch überhaupt nicht auf ARP-Anfragen zu anderen Adressen, außer sich selbst, zu antworten...

Mir ist aufgefallen, daß Kunden bei der Deutschen Glasfaser sich gegenseitig über die private IPv4-Adresse pingen können:

firewall# ping 100.123.98.90 
PING 100.123.98.90 (100.123.98.90): 56 data bytes
64 bytes from 100.123.98.90: icmp_seq=0 ttl=63 time=4.852 ms
64 bytes from 100.123.98.90: icmp_seq=1 ttl=63 time=5.563 ms

Interessanterweise haben die die gleiche MAC-Adresse, als das Gateway:

100.123.96.1                         20:00:12:13:40:93     em1 2m49s     
100.123.98.90                        20:00:12:13:40:93     em1 19m5s     

Da sich die Adressen aber im gleichen Netz befinden

inet 100.123.96.XX netmask 0xfffff000 broadcast 100.123.111.255

muß das Gateway hier doch eine Art proxy-arp machen. Da kann man sich schon fragen, warum und wozu?

Wir machen dazu wohl besser ein eigenes Thema auf...

Mir gehts doch genauso, und ich seh das über den Support absolut hoffnungslos, die wollen das Problem gar nicht verstehen, sind vermutlich drauf geschult, wie man Kunden am besten abwimmelt. Ich muß so aufpassen, daß ich mich hier nicht im Ton vergreife...

Meine Tickets wurden immer mit ähnlichen Aussagen sofort wieder geschlossen. Ich denke, man kommt wirklich nur per Brief weiter, oder wir müssen uns irgendwie zusammentun, scheinen ja doch einige das gleiche Problem zu haben.

Ich hätte jetzt schon erwartet, daß Zugriffe von Kunde zu Kunde unterbunden werden...

Andererseits eröffnen sich da ganz neue Möglichkeiten, wäre mal interessant, ob die Bandbreitenbegrenzung da intern auch schon greift

Zitat von Bernd_R

Interessant, ich bin aus dem gleichen PLZ Bereich und habe auch Probleme mit IPv6...

Deutsche Glasfaser, das ist jetzt nicht euer Ernst, ich kann deine Adresse anpingen:

firewall# ping 100.123.98.90                  
PING 100.123.98.90 (100.123.98.90): 56 data bytes
64 bytes from 100.123.98.90: icmp_seq=0 ttl=63 time=6.570 ms
64 bytes from 100.123.98.90: icmp_seq=1 ttl=63 time=4.456 ms

dann hängen wir wahrscheinlich am gleichen Konzentrator.

Nur 1/3, da man per IPv4 ja genattet wird, und nicht von Außen erreichbar ist

Früher hatte ich noch ein anderes Problem, daß UDPEncap(ESP)-Pakete oftmals in falscher Reihenfolge angekommen sind, das scheint jetzt besser geworden zu sein. Aber das gehört jetzt eigentlich nicht hier her...

Hast du dann jetzt auch wieder einen /56er Prefix?

Ja richtig, ich kann mich erinnern, daß ich früher auch einen Bereich aus 2a00:6020... hatte.

Schöne Sch...ße, was ist das beste Vorgehen in dem Fall? Über den Support kommt man offensichtlich nicht weiter...

Nun hat es mich auch erwischt, komme aus PLZ 86xxx, und bekomme keine Antwort mehr auf IPv6-Pakete aus dem Netz der prefix delegation.

Ich bekomme nur noch einen /64er Prefix zugewiesen, aktuell 2a00:61e0:aac0:55c/64, wobei sich der letzte Block 55c inkrementell sehr häufig ändert.

traceroute6 gibt mir überhaupt keine Antwort, wobei ich die Pakete aber ausgehend sehen kann:

14:23:19.704717 00:30:18:0b:8f:64 20:00:12:13:40:93 86dd 74: 2a00:61e0:aac0:55c:230:18ff:fe0b:8f63 > 2a00:1450:4001:c21::5e: icmp6: echo request [hlim 1]

Als default gateway habe ich fe80::22%em1 bekommen, und das kann ich auch anpingen:

14:27:06.656005 00:30:18:0b:8f:64 20:00:12:13:40:93 86dd 118: fe80::230:18ff:fe0b:8f64 > fe80::22: icmp6: echo request
14:27:06.657916 20:00:12:13:40:93 00:30:18:0b:8f:64 86dd 118: fe80::22 > fe80::230:18ff:fe0b:8f64: icmp6: echo reply

Mit der MAC-Adresse und dem Routing scheint bei mir also alles zu stimmen so weit. Mein Router ist ein Gerät auf OpenBSD Basis.

Ich kann nicht genau sagen, wie lange der Zustand schon besteht, da ich meist noch auf IPv4 unterwegs bin. Aber es hat sich auch vor einigen Wochen plötzlich die IPv4-Adresse geändert, das war sonst bislang immer die gleiche. Möglicherweise trifft das zeitlich zusammen. Früher hat dies definitiv alles funktioniert seit ca. 3 Jahren, seit ich diesen Anschluß habe.

Vom Support nur das Übliche, man wird aufgrund "eigenem Router" abgewimmelt, am Anschluß wäre alles in Ordnung...