IPv6 mit IP-basiertem Anschluss

[#1]

Ist das eigentlich eine Hardwareversion, oder ist das "nur" ein Softwarestand?

Unter https://docs.google.com/spreadsheet/ccc?key=0AkJ_mfvBdnTgdEhLekZqU0VQanpCQ2EwODF1cnRzSEE#gid=0 gibt es eine Hardware-Liste. Demnach kommt bei 164.37 die LineCard von Broadcom und der DSLAM von Adtran. Bei 164.95/97 ist der DSLAM von Alcatel-Lucent und somit wohl andere Hardware.
Vielleicht wäre es noch interessant zu sehen, ob andere Adtran-DSLAMs auch betroffen sind, diese gibt es laut der Liste auf auf Infineon-Linecards als 164.98, 164.101 und 176.83. Falls das nicht schon auf den vorigen Seiten behandelt wurde - so langsam verliere ich den Überblick.

[#2]

Ist das eigentlich eine Hardwareversion, oder ist das "nur" ein Softwarestand? Mir ist klar, dass man auch das nicht mal eben umflasht, aber wenn die Version anderswo schon läuft ...

Ich bin absolut kein Kenner der Telekom VDSL Infrastruktur und lernte nur aus diesem Forum, dass der Broadcom 164.37 DSLAM von der Firma Adtran hergestellt wird. Die von nightreider erwähnten DSLAMs 164.95/97, die auch Vectoring beherrschen, stammen meiner Ansicht nach von Alcatel Lucent - und daher vermute ich, auch der Typ 164.98, der offensichtlich KEINEN Ipv6 Bug hat. Der Austausch .37 durch .98 würde also den Einsatz einer kompletten neuen Hard- und Software bedeuten. Das einzige, was vielleicht passen könnte, wären die 19-Zoll Gehäuse (die "grauen Outdoor Kästen"), aber wahrscheinlich sind auch diese herstellerspezifisch.

Viel eleganter als einen kompletten, neuen "grauen Kasten" setzen zu müssen, wäre es natürlich, den offensichtlich bekannten IPv6 Bug des .37 durch Adtran beseitigen zu lassen und die Hardware beizubehalten. Vermutlich arbeitet Telekom bereits in dieser Richtung. Ich testete einen anderen VDSL Anschluss mit einem älteren Broadcom 147.159 DSLAM - und dieser konnte mit meinen Fritz Routern problemlos IPv6 Verbindungen herstellen. Adtran wird es daher wohl hoffentlich schaffen, das in vielen Telekom VDSL-Ausbaugebieten verwendete neue Produkt 164.37 hinsichtlich IPv6 in endlicher Zeit ebenfalls funktionsfähig zu machen - und am besten ohne Hardwareänderungen!!! Dann würde uns Betroffene (und die Telekom Finanzleute) schon "umflashen" glücklich machen...

[#3]

@rmueller83
@nightreider
Die Hardware Liste ist Klasse!!! Sie entlarft meine Vermutung, dass auch der IPv6 taugliche DSLAM (Linecard/Chipsatz mit der Firmware 164.98) von Alcatel hergestellt wird als Irrtum:

Ich interpretiere die mich interessierenden drei Fälle mit Hilfe der Liste so:

1) Der NICHT IPv6 taugliche DSLAM vom Hersteller Adtran hat einen Linecard Chipsatz von Broadcom mit der Firmware 164.37. Den gleichen Chipsatz verwenden die von Alcatel Lucent hergestellen DSLAMs, aber mit anderer Firmware 164.95 und 164.97. Es wäre zu klären, ob diese DSLAMs IPv6 Verbindungen herstellen können. Nightreiders Beitrag bestätigt das nicht explizit, sondern verweist nur auf die Tauglichkeit für Vectoring und den Ipv6 Bug des Adtran DSLAMs mit dem Broadcom Chipsatz auf der Line Card, der die Firmware 164.37 verwendet.

2) Der in dem anderen Forum erwähnte DSLAM mit der Chipsatz/Linecard Firmware 164.98 kann (lt. einem User) IPv6 problemlos. Ziemlich unten in der Hardware Liste findet man, dass dieser DSLAM auch von Adtran hergestellt wird, aber einen Linecard Chipsatz von Infineon und NICHT von Broadcom verwendet.

3) Der IPv6 taugliche VDSL Anschluss, den ich erfolgreich testete, hängt an einem von Ericsson EDA hergestellten DSLAM, der einen Broadcom Linecard Chipsatz und die Firmware 147.159 verwendet.

Facit: Adtran kann offensichtlich auch IPv6 taugliche DSLAMs bauen - aber mit Infineon Linecard Chipsatz und der Firmware 164.98. Adtrans DSLAM mit Broadcom Linecard Chipsatz und der Firmware 164.37 hat wohl den uns Betroffene im Forum "nervenden" IPv6 Bug - aber ob's am Broadcom Chipsatz liegt ist fraglich, denn dieser funktioniert in dem Ericsson DSLAM mit der Linecard/Chipsatz Firmware 147.159 einwandfrei. Ohne genaue Kenntnis der DSL Infrastruktur, konkrete Messungen und Fehlersuche auf Paketebene ist die am IPv6 Versagen "schuldige Komponente" in einem der Adtran DSLAMs vermutlich nicht zu ermitteln. Langsam wird mir klarer, warum vom Telekom Team konkrete technische Antworten und Ergebnisse noch nicht vorliegen...

[#4]

Mal blöd in die Runde gefragt: Hat einer der betroffenen an seinem Anschluss schonmal testweise die FritzBox in den "Modem only Mode" (sofern in aktuellen Modellen noch vorhanden?!?) geschaltet und den Windows eigenen PPPoE Client o.Ä. die PPPoE Einwahl durchführen lassen? Wenn ja: kam dann die vollständige IPv6 Konnektivität zustande?

Wenn nicht, dann wäre das Resultat dieses Tests sicherlich einmal aufschlussreich und erspart den testweisen Kauf eines Speedports oder dergleichen.

Hinweis: Bei VDSL Anschlüssen muss ggf. das VLAN Tagging am Ethernet Adapter (VLAN ID=7) eingeschaltet werden - sofern sich die FritzBox im "Modem Only Mode" tatsächlich wie ein transparentes Modem verhält.

Gruß

rambozambo

[#5]

Hallo in die Runde,

vor meinem Urlaub (für dessen Dauer ich natürlich die weitere Betreuung dieses Threads sicherstelle  ) möchte ich Ihnen heute einen Zwischenstand geben:

Ohne genaue Kenntnis der DSL Infrastruktur, konkrete Messungen und Fehlersuche auf Paketebene ist die am IPv6 Versagen "schuldige Komponente" in einem der Adtran DSLAMs vermutlich nicht zu ermitteln.
Langsam wird mir klarer, warum vom Telekom Team konkrete technische Antworten und Ergebnisse noch nicht vorliegen...

in der Tat: unsere Kollegen in den Fach-Teams sind bereits sehr engagiert bei der Sache: die Köpfe rauchen, und die Analyse ist in Schwung gekommen - aber noch haben wir als Telekom hilft-Team keine Rückmeldung erhalten, woran es in den jeweiligen Fällen *konkret* liegt und wie eine nachhaltige Lösung hergestellt wird.

Sprich: wir alle sind uns über die Symptome einig, aber die Ursachenforschung läuft weiterhin.

Wir bleiben für Sie dran!


beste Grüße
von
Helge.

[#6]

Sprich: wir alle sind uns über die Symptome einig, aber die Ursachenforschung läuft weiterhin.

Wir bleiben für Sie dran!
Helge.

Na, dann bin ich ja frohen Mutes, das mein Anschluss (Störung seit Oktober 2013) auch nach einem Jahr noch nicht wieder mit IPv6 funktionieren wird!

Glückwunsch und schönen Urlaub!

[#7]

Hallo,

Ohne genaue Kenntnis der DSL Infrastruktur, konkrete Messungen und Fehlersuche auf Paketebene ist die am IPv6 Versagen "schuldige Komponente" in einem der Adtran DSLAMs vermutlich nicht zu ermitteln.
Langsam wird mir klarer, warum vom Telekom Team konkrete technische Antworten und Ergebnisse noch nicht vorliegen...

in der Tat: unsere Kollegen in den Fach-Teams sind bereits sehr engagiert bei der Sache: die Köpfe rauchen, und die Analyse ist in Schwung gekommenDas klingt so ein wenig wie dieses "war stets bemüht" in einem miesem Zeugnis was letztendlich bedeutet "bemüht aber trotzdem gescheitert". Werter Helge, wollen Sie uns wirklich erklären das Ihre Kollegen aus der "Technik" so extrem unfähig sind das sie nach einem halben Jahr immer noch nichts vorzuweisen haben? Es fällt mir wirklich extrem schwer das zu glauben. Ich verstehe ja das IPv6 noch echtes Neuland ist (aus diesem Grund ist schließlich forum.telekom.de auch noch immer IPv4-only) aber trotzdem müsste es nach mehr als einem halben Jahr doch wohl wenigstens erste Zwischenergebnisse von dieser Analyse geben.
Bis jetzt wurden alle technischen Details in diesem Thread von den betroffenen selber zusammengesucht, nichts davon kam von einem Mitarbeiter der Telekom. Das ist in meinen Augen ein echt beschämendes Armutszeugnis.

Sprich: wir alle sind uns über die Symptome einig, aber die Ursachenforschung läuft weiterhin.

Ja, und wie lange denken die Techniker werden sie noch brauchen bis sie wenigstens vermuten (von wissen will ich hier noch gar nicht schreiben) wo die Problemursache wohl liegt?

Hat einer der betroffenen an seinem Anschluss schonmal testweise die FritzBox in den "Modem only Mode" (sofern in aktuellen Modellen noch vorhanden?!?)

Diesen Modus gibt es in sämtlichen Produkten der Firma AVM schon seit Jahren nicht mehr, einige Speedports haben dieses Feature aber noch. Die Einwahl mit einem PPPoE-Treiber eines klassischen OS dürfte eventuell tatsächlich klappen, weil diese vermutlich kein DHCPv6 benutzen (der PPPoE-Treiber von Linux kommt auch gänzlich ohne DHCP aus), aber ob dann per IPv6 auch wirklich Kommunikation möglich ist bleibt fraglich und sollte eigentlich wirklich mal von jemanden, der an einen der betroffenen Anschlüsse hängt, geprüft werden. Wenn es stimmt das die Telekom-Hardware Probleme mit IPv6-Unicasts hat, das wurde hier in diesem Thread vor einiger Zeit mal diagnostiziert, dann kommt leider auch mit einer alternativen PPPoE-Einwahl keine IPv6-Kommunikation zustande.
Wenn es in der Umgebung von Nürnberg einen betroffenen Anschluss gibt würde ich ja fast anbieten mal mit meiner Technik vorbei zu kommen, ich habe auf jeden Fall geeignete Ausrüstung und genug Ahnung von IP um das Problem vielleicht ein wenig enger einzugrenzen (soweit das eben vom äußersten Ende der DSL-Leitung aus möglich ist), und es würde mich mal interessieren wie meine eigene PPPoE-Implementierung mit derartigen Fehlern umgeht (wie oft bekommt man schon die Gelegenheit seine Sachen an einer bekannt fehlerhaften Gegenstelle zu testen).

Grüße
Erik

[#8]

Hallo zusammen,

Bomben und Granaten! (Exkurs: Werde ich jetzt von der NSA beobachtet?)

Nach einer ganzen Reihe von Resyncs in den letzten 2 Stunden leuchtet in den Einstellungen meines Routers plötzlich die Lampe für IPv6 grün! Die DSL-Vermittlungsstelle ist dabei gleich geblieben (Broadcom 164.37!).

Hat noch jemand eine Veränderung bemerkt?

Viele Grüße

nightreider

[#9]

Nach einer ganzen Reihe von Resyncs in den letzten 2 Stunden leuchtet in den Einstellungen meines Routers plötzlich die Lampe für IPv6 grün! Die DSL-Vermittlungsstelle ist dabei gleich geblieben (Broadcom 164.37!).
Hat noch jemand eine Veränderung bemerkt?
nightreider

WOW - Glückwunsch!!! Darauf warte ich auch seit April 2014 - also weniger lange als nightreider. Vielleicht arbeitet Telekom die gemeldeten Störfälle in der Reihenfolge des Eingangs ab. Es kommt langsam etwas Hoffung auf...

Auch mit dem neuen Fritz!OS 6.20 gibt es bei mir KEINE Änderung und KEINE grüne Anzeige, sondern alles ist wie bisher: Internet, IPv6 nicht verbunden, Keine Antwort vom DHCPv6-Server (SOL), Kein Prefix usw. usw.

Neightriders Mitteilung ist dennoch höchst interessant: Er ist der ERSTE User von dem ich höre/lese, dass IPv6 an der DSL-Vermittlungsstelle Broadcom 164.37 funktioniert!!!

[#10]

Auch mit dem neuen Fritz!OS 6.20 gibt es bei mir KEINE Änderung und KEINE grüne Anzeige, sondern alles ist wie bisher: Internet, IPv6 nicht verbunden, Keine Antwort vom DHCPv6-Server (SOL), Kein Prefix usw. usw.
Neightriders Mitteilung ist dennoch höchst interessant: Er ist der ERSTE User von dem ich höre/lese, dass IPv6 an der DSL-Vermittlungsstelle Broadcom 164.37 funktioniert!!!

Aus diesem Grund erwähnte ich die neue Firmware für meine Fritzbox 7490:
Neues in FRITZ!OS ab 6.20
DSL:
NEU - Verbesserungen der Interoperabilität mit DSLAMs bei ADSL und VDSL
NEU - Verbesserte Interoperabilität für VDSL2-Vectoring der Deutschen Telekom

Daher Rückfrage an nightreider:
Haben Sie vielleicht die Firmware auf 6.20 upgedatet und DANACH funktioniere plötzlich IPv6??? Erfolgten die zahlreichen Resynchs heute ohne Ihr Zutun? Falls ja, dann muss ja wohl Telekom heute an Ihrem Anschluss erfolgreich gearbeitet haben!

[#11]

Ich benutze schon länger die Labor-Firmware und seit sie raus ist die 6.20.Das hat keinen Einfluss auf das Problem.

[#12]

Daher Rückfrage an nightreider:
Haben Sie vielleicht die Firmware auf 6.20 upgedatet und DANACH funktioniere plötzlich IPv6??? Erfolgten die zahlreichen Resynchs heute ohne Ihr Zutun? Falls ja, dann muss ja wohl Telekom heute an Ihrem Anschluss erfolgreich gearbeitet haben!

Hallo gebatau,

nein, die Firmware 6.20 hat nichts damit zu tun. Hatte sie gleich nach dem Erscheinen aufgespielt. Die zahlreichen Resyncs erfolgen ohne mein Zutun. Auch heute Nachmittag gab es noch noch 3 Resyncs. Vor 15 Minuten erst wieder.
Da scheint jemand Einstellungen auszuprobieren. Das einzige, was mir in den DSL-Informationen auffällt ist, daß dort unter dem Punkt "Trägertausch (Bitswap)" die Einstellung für die Empfangsrichtung nun auf "aus" steht, "Senderichtung"=ein. Vorher stand beides auf ein.
Bsp. System/Ereignisse (IP-Adresse geändert):
19.08.14 18:58:24 IPv6-Präfix wurde erfolgreich aktualisiert. Neues Präfix: 2003:xx:xxxx:xxxx::/56
19.08.14 18:43:24 IPv6-Präfix wurde erfolgreich bezogen. Neues Präfix: 2003:xx:xxxx:xxxx::/56
19.08.14 18:43:24 Internetverbindung IPv6 wurde erfolgreich hergestellt. IP-Adresse: 2003:xx:xxxx:xxxx:xxx:xxxx:xxxx:xxxx
19.08.14 18:43:24 Internetverbindung wurde erfolgreich hergestellt. IP-Adresse: xx.xxx.xxx.xxx, DNS-Server: 217.237.149.142 und 217.237.150.205, Gateway: 217.0.117.161, Breitband-PoP: HNOR29-se800-B226E1010E01MA
19.08.14 18:42:22 PPPoE-Fehler: Zeitüberschreitung.
19.08.14 18:41:57 DSL ist verfügbar (DSL-Synchronisierung besteht mit 51391/10047 kbit/s).
19.08.14 18:41:24 Zeitüberschreitung bei der PPP-Aushandlung.
19.08.14 18:41:24 Internetverbindung IPv6 wurde getrennt, Präfix nicht mehr gültig.
19.08.14 18:41:24 Internetverbindung wurde getrennt.

Gruß nightreider

[#13]

Hallo nochmal,

wie ich bereits sagte, da wird wohl getestet, denn die gerade erwähnte Einstellung "Trägertausch (Bitswap)" steht jetzt wieder für beide Richtungen auf "an".

Gruß nightreider

[#14]

denn die gerade erwähnte Einstellung "Trägertausch (Bitswap)" steht jetzt wieder für beide Richtungen auf "an".

Die steht erst auf "an", nachdem ein Bitswap stattgefunden hat, unmittelbar nach der Synchronisation steht die immer auf "aus".

[#15]

@nightreider
Danke für die Antworten! Das Log sieht (bis auf den kurzen PPPoE-Fehler Zeitüberschreitung) doch perfekt aus, inkl. Präfix Vergabe und Aktualisierung! Hoffe, dass es langfristig so bleibt und das leidige IPv6 Thema für Sie endgültig erledigt ist!
Diese PPPoE Fehler habe ich zuweilen an meinem VDSL2 Anschluss auch, allerdings meist über längere Zeitperioden (einige Minuten).

@nightreider @Gelöschter Nutzer
Mein DSL: Trägertausch (Bitswap) Empfangsrichtung aus, Senderichtung an. Etwas anderes sah ich bewußt noch nie. Da ich eine relativ hohe Störabstandsmarge (19/15 dB) habe und meine Fehlerzähler in allen Positionen immer auf 0 stehen, vermute ich, dass gar keine Notwendigkeit für einen Trägertausch besteht - aber ich habe keine Ahnung, ob der Tausch bei Übersteigen einer bestimmten Fehlerrate bei der Übertragung oder durch andere Dinge getriggert wird. Werde die Einstellungen mal weiter beobachten. Derzeit ist die DSL Verbindung erst seit 8 Stunden aktiv, da ich heute Mittag den Firmware 6.20 Update durchführte und damit einen Neustart erzwang.

[#16]

@gebatau

meine Verbindungseigenschaften lt. Fritzbox:

Empfangsrichtung Senderichtung
DSLAM-Datenrate Max. kbit/s 51392 10048
DSLAM-Datenrate Min. kbit/s 27968 2784
Leitungskapazität kbit/s 61523 22979
Aktuelle Datenrate kbit/s 51391 10047
Nahtlose Ratenadaption aus aus

Latenz 8 ms 4 ms
Impulsstörungsschutz 2 2
G.INP aus aus

Störabstandsmarge dB 8 14
Trägertausch (Bitswap) an an
Leitungsdämpfung dB 18 23

Profil 17a
G.Vector aus aus

Trägersatz B43c B43c

Ob sich die Einstellung beim Trägertausch direkt nach einem Resync ändert, weiß ich nicht. Mal sehen, ob die Tage noch mehr Resyncs von der Telekom ausgelöst werden und ich es früh genug merke, schaue ich mal nach. Ich lasse es jetzt erst mal so laufen, solange eine IPv6-Verbindung besteht. :-)

Gruß nightreider

[#17]

Hallo,

das war' ja wohl erst mal. Nach mehrfachem Resyncs heute Morgen wieder der gleiche Käse!!! Kein IPV6 mit der üblichen Fehlermeldung.

Gruß nightreider

[#18]

Hallo,
das war' ja wohl erst mal. Nach mehrfachem Resyncs heute Morgen wieder der gleiche Käse!!! Kein IPV6 mit der üblichen Fehlermeldung.

Traurig und frustrierend! Der temporäre IPv6 Erfolg erscheint mir nach dieser Info eher durch Versuche der Fritz!Box, mit einer instabilen Telekom-Infrastruktur (welche die Resynchs auslöste) zurecht zu kommen, als durch gezielte Entstörversuche an Ihrem Anschluss begründet zu sein! Telekom protokolliert Entstörarbeiten inkl. der Zeiten genau. Als Anschlussinhaber kann man erfahren, welche Arbeiten wann durchgeführt wurden. Ich würde "nachbohren"...

Übrigens: Heute Nacht hat meine Einstellung für Bitswap in Empfangsrichtung auf "an" gewechselt. Einen DSL Resynch gab es nicht und auch der Fehlerzähler zeigt überall 0.

Meine DSL Daten zur Info und zum Vergleich:
Ausgehandelte Verbindungseigenschaften Empfangsrichtung Senderichtung
DSLAM-Datenrate Max. kbit/s 51392 10048
DSLAM-Datenrate Min. kbit/s 27968 2784
Leitungskapazität kbit/s 102404 25512
Aktuelle Datenrate kbit/s 51390 10047
Nahtlose Ratenadaption aus aus
Latenz 8 ms 4 ms
Impulsstörungsschutz 3 2
G.INP aus aus
Störabstandsmarge dB 19 15
Trägertausch (Bitswap) an an
Leitungsdämpfung dB 12 11
Profil 17a
G.Vector aus aus
Trägersatz B43 B43

[#19]

Hallo,

es freut mich das endlich mal Bewegung in die Sache kommt, offensichtlich hat die Telekom den Ball vom Spielfeld aufgehoben und nimmt wieder aktiv am Geschehen teil.

Ich könnte mir vorstellen das in den DSLAM (oder welche Komponente auch immer die Ursache sein mag) versuchsweise eine experimentelle Firmware (vermutlich direkt von einem Programmierer des Herstellers kommend) eingespielt wurde um zu sehen ob die Leute beim Hersteller auf dem richtigen Weg sind aber nach erfolgreichem Test wieder die reguläre Firmware eingespielt wurde (wegen Gewährleistung usw.).
Falls dem so ist dürfte es sicher noch einige Wochen dauern bis diese neue Firmware den nötigen Qualitätssicherungsprozess (beim Hersteller ebenso wie bei der Telekom) durchlaufen hat um offiziell eingespielt zu werden, aber es ist zumindest ein Signal das Hoffnung macht.
Falls es wirklich nur ein Firmwareupdate ist dürfte das auch die Schweißperlen auf den Stirnen der Telekom-Einkäufer trocknen, zumindest etwas denn auch das deutschlandweite Einspielen von Updates kostet Zeit und Geld aber eine Hardwareneuanschaffung würde sicher deutlich mehr Zeit und Geld kosten.

Bin ja mal gespannt wann die Forenbetreuer dazu mal etwas konkretes melden.

@nightreider
Bitte wirklich "nachbohren", für beide Wartungsarbeiten (als IPv6 kam und als es wieder verschwand)! Ja das kostet Zeit und Nerven aber Bitte nicht abwimmeln lassen.

Grüße
Erik

[#20]

Hallo zusammen,

ein wenig anders als ursprünglich ist die Situation schon. Nur wie u. warum kann ich nicht einordnen.
Einstellung immer beibehalten: Dual Stack
Die ursprüngliche Fehlermeldung in den System/Ereignissen ist gleich geblieben:
(20.08.14 18:07:01 Internetverbindung IPv6 konnte nicht aufgebaut werden: Keine Antwort vom DHCPv6-Server (SOL)
20.08.14 18:06:44 Internetverbindung IPv6 wurde erfolgreich hergestellt. IP-Adresse: 2003:xx:xxxx:xxxx:xxx:xxxx:xxxx:xxxx)

ABER:
In den Einstellungen Internet/Online-Monitor ist die IPv6-Lampe nunmehr grün (!). Daneben steht folgendes:
verbunden seit 20.08.2014, 18:06 Uhr, Telekom,
IPv6-Adresse: 2003:xx:xxxx:xxxx:xxx:xxxx:xxxx:xxxx, Gültigkeit: 13994/1394s,
IPv6-Präfix: , Gültigkeit: 0/0s

ALSO besteht wohl eine IPv6-Verbindung, aber es ist kein gültiger Präfix da bzw. es ist einer da, nur nicht gültig?! Jedenfalls war das grüne Lämpchen bis gestern durchgängig AUS.

Gruß nightreider

[#21]

Hallo nightreider,

der BRAS weist jedem Teilnehmer immer zwei Prefixe zu, das erste Prefix kommt per Router-Advertisement und hat immer 64 signifikante Bits und das zweite Prefix wird per DHCPv6-Prefix-Delegation geholt und hat bei der Telekom 56 signifikante Bits (können bei anderen Provider auch mehr oder weniger signifikante Bits sein). Das erste Prefix dient der Kommunikation des Heim-Routers selber mit der Provider-Infrastruktur (z.B. für TR-069) aber kann auch auf das echte Internet zugreifen (ist auch vom Internet aus anpingbar). Da der Heim-Router sich aus dem ersten Prefix selber mindestens eine IP-Adresse für sein WAN-Interface generiert kann dieses Prefix nicht mehr an ein lokales Netzwerk weitergereicht werden (Prefixe mit mehr als 64 signifikanten Bits, also wo weniger als 64 Bits für die Hosts übrig bleiben, sind bei IPv6 grundsätzlich nicht zulässig so das dieses erste Prefix auch nicht in Sub-Netze geteilt werden kann). Das zweite Prefix von der Telekom hat weniger signifikante Bits und wird vom Heim-Router ins lokale Netzwerk durchgereicht (meistens nachdem es in kleinere Subnetze zerlegt wurde).

Für das erste Prefix ist keine bidirektionale Kommunikation erforderlich, es reicht wenn der Heim-Router das Router-Advertisement (ist immer BroadCast an FF02::1) des BRAS empfängt damit er davon ausgeht echte IPv6-Konnektivität zu haben (selbst wenn die Verbindung in Wirklichkeit gestört ist). Da mit dem ersten Prefix allein bei einem typischen Heim-Router aber keine Kommunikation der lokalen Hosts mit dem Internet möglich ist sollte der Heim-Router nur allein mit dem ersten Prefix keine funktionsfähige IPv6-Internet-Anbindung melden, sondern erst wenn auch das zweite Prefix erfolgreich geholt wurde.

Wenn DHCPv6 nach der letzten Änderung am DSLAM wieder nicht mehr funktioniert sollte die Fritzbox auch wieder den selben Zustand wie vorher melden.
Bist Du sicher dass das nicht doch an einer neuen Firmware in der Fritzbox liegt?
Kannst Du zu Testzwecken noch mal die alte Firmware einspielen?
Nur um sicher zu gehen ob es an der Fritzbox liegt oder nicht.

Schau Dir doch Bitte einen aktuellen Mitschnitt des Verbinungsaufbaus am WAN-Interface an, vielleicht siehst Du ja dort einen Unterschied zu früher.

Grüße
Erik

[#22]

Hallo Erik,

an der neuen Version 6.20 liegt es sicher nicht. Die hatte ich gleich nach Verfügbarkeit aufgespielt. War wohl ´ne knappe Woche vor diesen Resyncs vorgestern.

Das andere versuche ich mal am Wochenende zu testen.

Gruß nightreider

[#23]

Seit der Umstellung auf VDSL 50 (vorher ATM-Plattform) vor ein paar Wochen habe ich auch das Problem, dass IPv6 nicht mehr funktioniert. Ich nutze eine FritzBox 7490 mit aktueller Firmware 06.20 mit einem Broadcom 164.37 auf der Gegenseite. Fehlerbild ist auch hier, dass kurz eine IP-Adresse bezogen wird und dann eine Fehlermeldung protokolliert wird: Internetverbindung IPv6 konnte nicht aufgebaut werden: Keine Antwort vom DHCPv6-Server (SOL).

Die zuerst kurzzeitig zugewiesene IP-Adresse wird mir auch per E-Mail zugeschickt - kann man ja einstellen.

Falls noch weitere Beispiele Telekom-seitig benötigt werden, kann ich natürlich gerne eine E-Mail mit weiteren Daten schicken. Die letzte Bitte diesbezüglich ist ja aber schon paar Tage alt, von daher wollte ich erst mal auf Feedback warten.

[#24]

Hallo Moderatoren,

nach ein paar Stunden IPv6-Verbindung - siehe meine folgende Meldung - vom Mittag 19.08.2014 bis früh morgens am 20.08.2014 wäre ein Zwischenbericht Ihrerseits über die Gründe wohl fällig und möglich, denn bei meinem System hat sich doch gezeigt, daß IPv6 mit dem Broadcom 164.37 doch möglich ist!

Nach einer ganzen Reihe von Resyncs in den letzten 2 Stunden leuchtet in den Einstellungen meines Routers plötzlich die Lampe für IPv6 grün! Die DSL-Vermittlungsstelle ist dabei gleich geblieben (Broadcom 164.37!).

Hat noch jemand eine Veränderung bemerkt?

Viele Grüße

nightreider

Ein Durchfragen meinerseits an der Hotline sehe ich für wenig erfolgreich an...

Eine Ursachenforschung bei mir führte bisher zu keinem Ergebnis.

Gruß nightreider

[#25]

Leider habe ich das selbe Problem:


25.08.14 12:17:27 Internetverbindung IPv6 konnte nicht aufgebaut werden: Keine Antwort vom DHCPv6-Server (SOL)
25.08.14 12:17:11 Internetverbindung IPv6 wurde erfolgreich hergestellt. IP-Adresse: 2003:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX


DSL-Vermittlungsstelle
Broadcom
164.37
B5004244434D
7631302E
00

Ich hoffe dass es auch hier gefixt wird.

P.S: nach nun fast mehr als 3 Jahren warten, endlich VDSL 50 ;o)