Mal wieder: Kein IPv6 bei Deutsche Glasfaser

Bin auch im PLZ 648xx angeschlossen, konkret 64839.

Da ich dieses IPv6 Thema nicht so richtig verstehe als ganz normler User, mache ich immer mal wieder diesen Happy Eyballs Test (http://he.test-ipv6.com). Dabei stelle ich (laienhaft) fest, dass IPv6 zwar funktioniert (auch heute), aber anscheinend nachrangig behandelt wird. Meist liegt die Trefferquote bei 75 % IPv4 zu 25% IPv6. Sollte das das randomly nicht irgendwo bei 50:50 einpendeln?

Zitat von alpha_zulu

Meist liegt die Trefferquote bei 75 % IPv4 zu 25% IPv6

Welche "Trefferquote" meinst du?

Zitat von Schnurz

Welche "Trefferquote" meinst du?

Ob zuerst eine IPv4 Verbindung oder iene IPv6 antwortet. Hier "gewinnt" in 3/4 der Fälle IPv4. Ich hatte aber auch schon (selten) mal Tage, wo es ausgeglichener war.

Zitat von alpha_zulu

Ich hatte aber auch schon (selten) mal Tage, wo es ausgeglichener war.

Und wir erfahren damit: immer noch nicht jedes System, ob routing device oder Server unterstützt IPv6. Und da das Routing nun mal dynamisch ist, kann es schon zu Differenzen kommen.

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...

Ziemlich ähnlich zu #101.

2a00:61e0::/32 scheint jetzt das neue (Unglücks-)Präfix zu sein, aus dem man IPv6-Adressen für Anschlüsse nach neuem IPv6-Adressvergabe-Konzept vergibt, die erst mal nicht funktionieren.

Wenn es bisher funktionierte, hattest du vermutlich IPv6 nach "altem" Adresskonzept. Man scheint nun also auch Bestandsanschlüsse umzustellen, vgl. #104

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...

Zitat von kbr

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...

Ein Brief per Einschreiben. Detaillierte fehlerbeschreibung mit traceroutes und ping tests, dazu am besten einen Screenshot des packetcaptures von dem DHCPv6 Prefix Delegation von der Deutschen Glasfaser.

So habe ich es gemacht und nach einiger Zeit hat es wieder funktioniert.

Die DG reagiert am ehesten auf Briefe weil das zeigt du meinst es ernst.

Das gute ist du kannst im Kundenkonto sehen ob sie deinen brief bekommen haben. Dort findesr du dann ein Ticket mit eingangskanal Brief/Scan.

Fristsetzung nicht vergessen und Kontaktdaten (Telefon/E–Mail hinterlassen).

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

Zitat von kbr

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

Tja, Abwarten und Tee trinken. Irgendwann scheint IPv6 dann auch bei diesen Anschlüssen zu funktionieren.

Mir ist ein Rätsel, was DG da treibt - es scheint, als stecke da ein systematischer Fehler drin, bei dem Kundenanschlüsse an neu ausgerollten BNG, die bzgl. IPv6 nach neuem Adressvergabe-Konzept arbeiten sollen, erst mal nur mit funktionierendem IPv4 versorgt werden können, und IPv6 später "nachgereicht" wird.

Laut AGB zahlst du auch für IPv6, im Grunde steht dir also eine Minderung des monatlichen Beitrags um die Hälfte für nur "halbes" Internet via IPv4 zu. Nur, die Problemverursachung durch DG nachzuweisen, dürfte schwierig bis teuer werden.

Es geht ja nicht mal zwingend um die Frage, ob ihm IPv6 zusteht.

Aber das, was zugewiesen wurde, stört den Anschluss erheblich.

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...

Bei mir hat es leider nicht geholfen, das ganze mit traceroutes, router-log und wieistmeineip.de screenshot denen begreiflich zu machen.

Da hilft es auch nicht das man hinter dem ONT von denen hängt wegen besserem Support.

Das Ticket wurde dann nach ca. 4 Wochen einfach geschlossen ohne das sich was ändert.
Hoffe das es sich irgendwann von selbst erledigt, genauso wie es aufgetaucht ist.
Habe keine Lust da Ping Pong zu spielen. Das ist wirklich ein Kreuz mit dem Kundensupport.

Nur die vielen Router-Log Meldungen jede Stunde gehen mir gegen den Strich. Dabei lief es am Anfang ja, bis nach einer Wartung.

Zitat von kbr

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

schon richtig - leider kann man auf IPv4 heute noch nicht verzichten, solange noch nicht alle Internet-Services via IPv6 nutzbar sind. Ohne IPv6 ist nur unschön, ohne IPv4 ist eine Katastrophe.

Das weiß auch DG und nutzt es dreist aus - und für die Bundesnetzagentur ist das auch keine großartige Sache - da scheint man IPv6 für einen im Zweifelsfall verzichtbaren Luxus zu halten.

Zitat von kbr

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

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

dann hängen wir wahrscheinlich am gleichen Konzentrator.

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

Zitat von kbr

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

Warum sollte das nicht moeglich sein? CG-NAT wird ja nicht verwendet um Privatkunden gegen Zugriff von aussen abzusichern, sondern aus Adressmangel...

Und auch sonst ist es hilfreich, NAT nicht mit Sicherheit zu verwechseln, dafuer ist die statefull Firewall zustaendig (die oft halt das Masquerading/NAT) miterledigt.

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 kbr

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

Ja - das ist offenbar prinzipiell über die Access-Infrastruktur der DG möglich. Die BNG scheinen intern über ein Backbone-Netz (ich nenne es mal "BB") miteinander verbunden zu sein (folgt aus Traceroutes):

Kunde1 (K1) und Kunde2 (K2) am selben BNG:

K1 <---> BNG <---> K2

Kunde1 (K1) und Kunde2 (K2) an verschiedenen BNG (1/2):

K1 <---> BNG1 <--|BB|--> BNG2 <---> K2

Die in jeden BNG integrierte CGNAT-Funktion ist dabei nicht involviert, weil die IP-Zieladressen der anderen Kunden ebenfalls in 100.64.0.0/10 liegen.