ernsthaftes IPv6-Freigabeproblem seit der FW 6.8x

Da Du vermutlich beim Test mit drei verschiedenen 7490 nicht jedesmal die Konfiguration von Grund auf neu gemacht haben wirst und wahrscheinlich eher eine Sicherungsdatei importiert hast, stelle ich einfach mal die Frage, ob Du das betreffende Gerät mal komplett aus der FRITZ!Box gelöscht hast (dazu darf es keine aktive Portfreigabe haben und auch nicht gerade "sichtbar" sein) und im Anschluß ggf. sogar noch die Liste der Netzwerkgeräte hast aufräumen lassen.

Dann das Gerät noch einmal "sauber" einrichten lassen (es wird der FRITZ!Box am ehesten "bekannt" - solange die keinen DHCP-Server bereitstellt -, wenn man vom Gerät irgendwie auf Layer 3 und darüber auf die FRITZ!Box selbst zugreift; sie also nicht nur als Router benutzt) und abwarten, ob das Problem erneut auftritt.

Gerade so eine ältere (link-lokale) Adresse, die es gar nicht (mehr) gibt, würde ich auf Überreste des Gerätes in der "landevices"-Sektion der "ar7.cfg" zurückführen, die dann munter mit neuen, aktuelleren "Erkenntnissen" vermischt werden, wenn es wieder einmal Zeit für die Erneuerung einer Weiterleitung per PCP ist.

:!:

Überreste des Gerätes in der "landevices"-Sektion der "ar7.cfg"

Zum Vergrößern anklicken....

Plattmachen = Fritz!Box separieren und ihr neue IP geben, bei Bedarf dann alte IP vergeben.
(Separieren: Mit nur einem Gerät verbinden, zb: 169.254.1.2)

Dann stelle halt mal die Ausgabe von "showpcpinfo" vor (findet sich auch in den Support-Daten) - einmal die "richtigen" und einmal den fehlerhaften Zustand, aber von derselben Box und aus demselben "Lauf" des Systems -, damit man sehen kann, ob es tatsächlich nur die interne Verwaltung und regelmäßige Erneuerung der PCP-Freigaben ist, die da schiefgeht oder ob nicht doch irgendein Client im LAN sich an der PCP-Steuerung versucht und damit das Chaos auslöst.

Ich kann das hier jedenfalls nicht nachstellen - habe aber auch nur ein älteres iPad als IPv6-Client hergenommen und den dort laufenden SSH-Dienst (somit auch nur einen einzelnen Service) mal testweise per IPv6 (obendrein nur per 6to4 für meine feste IPv4-Adresse) freigegeben. Das läuft seit dem 27.03.2017 stabil, als ich hier gelesen hatte, daß es ein Problem mit der Langzeitstabilität von Freigaben geben würde. Bei der täglichen "Zwangseinwahl" (ich habe noch einen T-DSL-Business mit Zwangstrennung nach 24 Stunden trotz fester IP) wird auch diese Freigabe regelmäßig (automatisch) neu eingerichtet, wie man im PCP-Log sehen kann.

Ich hatte das an anderer Stelle bereits einmal "ausgeführt" ... die PCP-Freigaben haben alle nur eine begrenzte "Lebensdauer" (sieht man auch in der o.a. Ausgabe) und für die Freigaben, die man statisch über das FRITZ!Box-GUI einstellt (und die ein LAN-Client mit PCP-Client eben nicht selbst anfordert und erneuert), sind verschiedene Prozesse im FRITZ!OS dafür verantwortlich (so jedenfalls meine Interpretation der verschiedenen "Abschnitte" mit den entsprechenden Daemons), diese Freigaben (inkl. der auf die Box selbst) zu verwalten und dazu gehört auch deren zyklische Erneuerung.

Nun habe ich selbst nur ein sehr einfaches Szenario nachgestellt ... aber bei mir klappt das eben. Es wäre ja tatsächlich nicht ausgeschlossen, daß irgendwann mal für eine Komponente so ein Trigger zur Erneuerung unter die Räder kommt (erst recht dann, wenn es wg. fehlender Zwangstrennung gar keine "regelmäßigen" Ereignisse gibt) und dann nicht rechtzeitig die Verlängerung "beantragt" wird - in der Folge fällt diese Freigabe weg (das macht der "pcpd" dann autonom) und irgendwann merkt eine Komponente dann beim Zählen der Häupter ihrer Lieben, daß da irgendetwas fehlt und richtet das neu ein.

Es wäre natürlich auch hier wieder denkbar, daß bei diesem (sicherlich eher seltenen) Problem des nachträglichen Neueinrichtens wg. verpaßter Verlängerung tatsächlich noch Fehler enthalten sind (da kann dann z.B. (rein theoretisch, ich kenne den AVM-Code auch nicht) ein "off by one" auch schon mal dazu führen, daß eine "fremde" IPv6-Adresse dem falschen Gerät zugeordnet wird - wobei das freie "Erfinden" so einer Adresse eher unwahrscheinlich ist, da müßte schon sehr viel durcheinandergeraten und daß das dann zufälligerweise auch noch eine link-lokale IPv6-Adresse ergibt, klingt zumindest befremdlich) ... aber die erste Voraussetzung für eine Reproduktion wäre hier dann wohl ein solches "Versäumnis" - schon das tritt bei mir nicht auf (womit dann das beschriebene Problem sicherlich für den Betroffenen belastend ist - es ist aber wohl nicht "allgemeingültig" und von der passenden Konfiguration abhängig).

Ehe man also nur "rät", was da nun passieren mag, sollte man vielleicht wirklich mal einen Blick in die Protokolle des "pcpd" werfen ... auch das Problem mit der zusätzlichen IPv6-Adresse würde ich (zumindest als Test) mal anders angehen. Man sieht ja in der gezeigten Windows-Konfiguration, daß der Windows-Server mit der TLD "local" arbeitet (also wohl auch der DHCP- und DNS-Server) - diese ist aber (mehr oder weniger) für mDNS reserviert und auch ohne DHCP-Server läuft natürlich auf der FRITZ!Box ein "multid" (mindestens als DNS), der sich seine Informationen zu den Geräten im Netzwerk auch aus mDNS-Annoucements zusammensucht. Um hier die verwendete TLD als mögliche Ursache auszuschließen (daß der "multid" (unsaubererweise in meinen Augen und mit weiteren Konsequenzen für die Sicherheit im LAN) die verschiedenen Namensräume von DNS und mDNS zusammenwirft, ist auch bekannt), würde ich mal auf eine andere lokale TLD umstellen. Schließlich zählt der "multid" auch zu den Komponenten im FRITZ!OS, die mit dem PCP-Daemon in Fragen der Freigaben kommunizieren bzw. anderen Komponenten die Informationen zu den Netzwerkadressen von LAN-Clients liefern.

Probleme mit IPv6 treten nicht nur bei der 7490 auf, sondern auch bei der 7580.
Die Fehler wirken sich hier evtl. anders aus, aber das IPv6 abschalten hilft zumindest bei der 7580.
Da hat AVM gewaltig Mist gebaut.

Captain-S schrieb:

Da hat AVM gewaltig Mist gebaut.

Zum Vergrößern anklicken....

Das ist zwar auch nicht generell auszuschließen, aber "Probleme mit IPv6" sind nun auch keine präzise Beschreibung und auch dieser "generelle Tipp", einfach IPv6 abzuschalten, liest sich bei AVM schon wieder ganz anders: https://avm.de/service/fritzbox/fri...funktionieren-nach-FRITZ-OS-Update-nicht-mehr - da wird tatsächlich ein Fehler "eingestanden", aber eben mit dem genau entgegengesetzten Workaround. Eine aktivierte IPv6-Konfiguration schadet der Funktion jetzt nicht wirklich, wenn der Provider kein IPv6 anbietet ... außerdem soll man ja (lt. AVM-KB) ohnehin auf einen 6to4-Tunnel schalten - was wieder dafür sprechen würde, daß das ganze Thema eben mit nativer IPv6-Unterstützung oder bei bestimmten Tunnel-Lösungen durchaus sauber arbeitet und nur andere Tunnel-Lösungen von einem Problem betroffen sind.

Meines Erachtens funktioniert nun endlich (seit 06.8x) die korrekte "Freigabe" (es geht ja eigentlich nur darum, dort eingehenden Verkehr nicht zu blockieren) für ein Segment mit einem delegierten IPv6-Präfix (u.a. auch für eine FRITZ!Box-Kaskade) - die Konstellation mit einem einzelnen Rechner mit statischer IPv6-Adresse, die obendrein gar nicht von der FRITZ!Box "verwaltet" wird und nur dann sinnvoll zu erreichen ist, wenn die Box den HE-Tunnel erfolgreich installiert hat (wo also der betreffende Server den Tunnel gar nicht selbst betreibt), der dann auch noch eine solche dauerhafte Freigabe kriegt, ist sicherlich schon etwas speziell. Obwohl das ja der Beschreibung nach auch dann nicht funktionieren soll, wenn die FRITZ!Box (allerdings wohl wieder mit HE-Tunnel) den DHCP-Server gibt (auch DHCPv6?) - wobei das bei ebenfalls statischer IPv6-Adresse des LAN-Clients ja auch nicht unbedingt eine Rolle spielt.

Es gibt aber auch so viele andere Konstellationen, die m.W. mit einer FRITZ!Box nicht funktionieren (z.B. die statische Delegierung eines kompletten IPv6-Subnetzes (aka IPv6-Präfix) an so einen Server ist wohl nirgendwo einzustellen, jedenfalls nicht so, daß die Box dann entsprechende Pakete passieren läßt - das klappt wohl nur, wenn die Box den Präfix auch selbst "delegiert" hat) und soviele "Kombinationsmöglichkeiten" (von "SLAAC" bis "Tunnel oder native"), daß man sich schon sehr bemühen muß, da wirklich alle Kombinationen auch zu "erwischen" bei entsprechenden Tests. Manchmal werden ja auch "liebgewordene Macken" als Workaround benutzt und wenn die dann als Problem erkannt und beseitigt werden, geht eben irgendetwas anderes, was bisher auf diese Umgehungslösung setzte, dann nicht mehr.

Der Betrieb eines eigenen Servers (und dafür ist hier sicherlich die statische IPv6-Adresse erforderlich, ggf. in Kombination mit einem passenden (externen) DNS-Server) hinter einem HE-Tunnel, der aber von einem ganz anderen Router bereitgestellt wird, der nun seinerseits noch die Aufgabe der "1st line of defense" übernimmt und eine Firewall anbietet, die für den Betrieb dieses Servers entsprechend konfiguriert werden muß, hat eben mit den "bread&butter"-Problemen eines Consumer-Gerätes nur noch sehr am Rande zu tun.

Ein solches muß eben (damit es auch in einem Haushalt ordnungsgemäß arbeitet, der sich viel stärker auf das "automatische Funktionieren" seines Border-Routers (als IAD) verläßt) auch versuchen, gewisse Anteile der Konfiguration automatisch zu erkennen und vorzunehmen; manchmal läuft das dann auch gegen den Willen des Besitzers. Es ist eben nicht ohne weiteres festzustellen, ob der tatsächlich weiß, was er da gerade konfiguriert und seinerseits die entsprechenden, flankierenden Maßnahmen ergreift (hier z.B. die Konfiguration der statischen IPv6-Adresse, die von der Interface-ID nach "FRITZ!Box-Geschmack" abweicht, auf dem LAN-Client) oder ob das einfach nur ein unbeholfener Benutzer ist, der z.B. auf sein NAS daheim auch vom Smartphone unterwegs per IPv6 zugreifen will - dann greift man dem wohl besser unter die Arme und richtet ihm (mit der richtigen Interface-ID und über den MyFRITZ!-Service) einen solchen Zugang ein.

Man muß auch bei seinen Ansprüchen immer im Auge behalten, an wen sich so ein Gerät (in der Breite) nun richtet ... wer etwas Besseres (auch besser/ausgefeilter zu konfigurieren) haben will, muß dann eben ein anderes Gerät wählen und i.d.R. auch tiefer in die Tasche greifen. Ich weiß aktuell gar nicht, wie weit die Einstellmöglichkeiten bei einem Speedport-Router z.B. gingen ... aber wenn der gar keine IPv6-Freigaben oder gar Tunnel-Benutzungen bieten sollte (trotz genereller IPv6-Unterstützung), wird ja auch niemand aufstehen und sich darüber erregen, daß dort eine ähnliche Konstellation ggf. auch nicht funktioniert.

Wie gesagt, die Permutationsmöglichkeiten bei einer IPv6-Konfiguration sind so groß, daß da schon mal etwas durcheinandergeraten kann und daß AVM hier mit der Einführung von PCP eine Renovierung "von Grund auf" ausgeführt hat (die durchaus im Interesse von Kunden an DS-Lite-Anschlüssen wäre, wenn deren Provider dann auch PCP unterstützt), ist sicherlich auch unstrittig.

Wenn da noch nicht alle denkbaren Kombinationen auf Anhieb funktionieren, ist das in meinen Augen eine "lässliche Sünde" ... solange entsprechende Updates mit einer Fehlerkorrektur nicht zu lange auf sich warten lassen. Wobei ich mir auch hier wieder nicht sicher bin, wieweit die "zugesicherten Eigenschaften" im Hinblick auf IPv6-Unterstützung nun wirklich gehen ... gehört da tatsächlich das reibungslose Funktionieren der Freigabe einer statischen IPv6-Adresse für einen LAN-Client unter Benutzung eines 6in4-Tunnels über HE zu dem Funktionsumfang, den man (normalerweise) von so einem Consumer-Gerät erwarten darf? Die Antwort auf diese Frage ist sicherlich auch wichtig, wenn man die Dringlichkeit eines solchen Updates einschätzen will - ich persönlich (aus meiner eigenen Sicht halt, so wie es wohl jeder andere auch aus seiner Warte beurteilt) hätte da noch ein paar andere Gründe bzw. Stellen, an denen ein (Security-)Update viel dringender wäre.

Heute im Laufe des Tages sind meine IPv6 Einträge auch hoch gelaufen:



Heute morgen waren es noch 3 - jetzt sind es 6. Die ersten 3 sind tatsächlich laut ipconfig in meinem PC vergeben. Die anderen 3 sind die alten temporären IPv6-Adressen von heute morgen. Anpingen kann ich nur die ersten 3.

Edit: 2.4.2017

Hier die Life Time der temporären IPv6 Adressen unter Windows 10.



Heute, nach Windows Start, stehen wieder nur die 3 IPv6 Adressen für den PC in der Fritzbox, die auch mit "ipconfig" unter Windows ausgelesen werden können. Der Zeitintervall für das tatsächliche Wechseln der temp. IPv6 muss aber bei 2-3 Std (geschätzt) liegen.

dg2dra schrieb:

[FONT=&amp]So, jetzt die IPv6-Adressen, die die 7490 meint an diesem Gerät SRV2012 erkannt zu haben (Heimnetzübersicht>SRV2012>Details unter IPv6-Adressen (4 Stück, ist aber FALSCH):[/FONT]
[FONT=&amp][FONT=&amp][FONT=&amp]2001:472:2f0b:112c[/FONT][/FONT]::8 -> richtige Adresse
fe80::20c:29ff:feb3:c599 -> richtige LinkLocal Adresse
fe80::560:4e9b:1a34:ee2d -> [/FONT][FONT=&amp]falsch, gibt’s nicht siehe oben[/FONT][FONT=&amp]
[/FONT][FONT=&amp][FONT=&amp][FONT=&amp]2001:472:2f0b:112c[/FONT][/FONT]:20c:29ff:feb3:c599 -> [/FONT][FONT=&amp]falsch, gibt’s auch nicht, wird wohl einfach mal so aus dem Subnetzanteil und der MAC-Adresse gebildet ohne jede Grundlage (MAC-Adresse Server/Netzwerkkarte 00:0C:29:B3:C5:99)[/FONT][FONT=&amp]
[/FONT]

Zum Vergrößern anklicken....

Verstehe Dein Problem in Teilen gar nicht.
Die Adresse [FONT=&amp]fe80::20c:29ff:feb3:c599 generiert sich das Interface als linklokale IPv6 automatisch (die hinteren 64 Bit ist ein sogenannter Interfaceidentifier,[FONT=&amp] und der kann vom Gerät selbst per modifiziertem Extended Unique Identifier (EUI-64) eindeutig festgelegt werden[/FONT]. Grundlage für den automatisch festgelegten Interface-Identifier ist die MAC-Adresse, die allerdings nur 48 Bit lang ist. Sie muss also mit 16 Bit zu dem 64 Bit langen Interfaceidentifier aufgefüllt werden. Dazu wird die MAC in der Mitte geteilt - in den vorderen Hersteller spezifischen Teil (OUI - Organizationally Unique Identifier) und den hinteren Netzwerkkarten (NIC) spezifischen Teil. Zwischen diese 24 Bitt langen Blöcken wird nun 0xFFFE eingefügt und das siebte Bit von links invertiert, um einen Interface Identifier im modified 64-bit EUI Format zu bekommen (also <OUI>FFFE<NIC> ). Hier kann man das nochmals anschaulich sehen.). Im Gegensatz zu händisch selbst gewählten Geräteidentifiern ist die EUI-64 global gültig.
Und wenn das derzeitig global gültige Präfix [FONT=&amp][FONT=&amp][FONT=&amp]2001:472:2f0b:112c[/FONT][/FONT]: ist, dann erreichst Du das Interface des Servers - unabhängig von einem händisch konfigurierten Interface-Identifier - immer auch über die IPv6 aus Präfix plus [FONT=&amp]modifiziertem Extended Unique Identifier... - d.h. diese gibt's sehr wohl, und zwar immer.[/FONT][/FONT][/FONT]

dg2dra schrieb:

eine IPv6-Funktionalität (mit der er auch wirbt)

Zum Vergrößern anklicken....

Da ich eine solche Stelle nicht kenne, frage ich einfach einmal, wo man diese Werbung findet ... vielleicht kannst Du mir ja "auf die Sprünge helfen".

Zwar wird im Handbuch (nur dort kenne ich eine einzige Fundstelle) ausdrücklich erwähnt, daß man einen IPv6-Rechner im LAN freigeben kann (sogar, daß man denselben (externen) Port mehrfach freigeben kann, weil eine solche Freigabe bei IPv6 eben mit der "externen Adresse" arbeitet und die ist für jeden Client im LAN eindeutig und muß nicht über NAT geteilt werden wie bei IPv4), aber da steht nichts davon, daß das mit einer beliebigen Adresse, die sich der Client selbst aussucht, funktionieren würde und man die nun nur in der FRITZ!Box angeben müsse.

Ich weiß auch nicht, warum die Box irgendwann auf die EUI-64 "zurückfallen" will ... wenn sie das macht (warum steht vermutlich im bereits erwähnten Protokoll) und im Anschluß diese Adresse korrekt freigegeben ist, dann ist in meinen Augen die Aussage aus dem Handbuch erfüllt (und das ist auch noch nichts, was ich als "beworbene Eigenschaft" sehen würde, aber da mag man geteilter Meinung sein).

Und Deinem Standpunkt "Entweder ich kann IPv6 mit meinem Router oder nicht." mag ich mich auch nicht so richtig anschließen ... es ist eben schon ein gewaltiger Unterschied, wie genau ich ein Gerät mit IPv6-Unterstützung beim Internet-Zugriff tatsächlich "anbiete". Was die Box per IPv6 alles kann bzw. nach dem "Herstellerwillen" können soll, steht im 7490-Handbuch im Punkt 12.9 ab Seite 85 - wenn man den Standpunkt vertritt "IPv6 heißt, daß auch alles per IPv6 genauso geht, wie bei IPv4.", macht die Liste gar keinen wirklichen Sinn und daß es da in der Tat Unterschiede in den nutzbaren Funktionen in Abhängigkeit von der Variante des IP-Protokolls gibt, "weiß" der normale FRITZ!Box-Besitzer spätestens dann, wenn er auf der Basis von IPv6 eine IPSec-Verbindung mit seiner FRITZ!Box aufbauen will.

Auch die Tatsache, daß IPv6-Unterstützung nicht gleich IPv6-Unterstützung ist, ist lange bekannt und wenn ich mich richtig erinnere, hat z.B. die c't dem Thema vor nicht ganz einem Jahr mal einen recht ausführlichen Test gewidmet, wo auch die verschiedenen "Formen" und Feinheiten von IPv6-Unterstützung (link-lokal/ULA/global, Uni-/Any-/Multicast, Router-Kaskadierung, Präfix-Delegation, "Port"-Freigaben/Erreichbarkeit/Firewalls) verschiedener Geräte ausgiebig gewürdigt wurden und lange nicht jedes Gerät auch alles fehlerfrei und in vollem Umfang (wobei hier die Erwartungen ja auch unterschiedlich sind) abbilden konnte.

Da stehe ich also mit meiner Meinung, daß es sehr wohl einen Unterschied macht, in welche "Klasse" sich so ein Gerät nun einreihen will, auch nicht so ganz alleine - das bei Dir als Konsequenz im Raum stehende "jedes Gerät muß alles können" (aus dem letzten an mich gerichteten Satz) ist ja ganz offensichtlich eine ziemlich unmögliche (und eigentlich sogar unsinnige) Forderung. Jede zusätzliche Funktion (zumindest fast jede) erfordert für ihre Benutzung eine zusätzliche Konfigurationsmöglichkeit und daß mit steigender Komplexität der Konfiguration die "usability" und damit die Tauglichkeit als "Consumer-Gerät" abnimmt, ist auch kein großes Geheimnis oder gar eine "Verschleierung" des Unwillens, irgendwelche 1%-Funktionen zu implementieren (die also von max. 1% der Kunden genutzt würden).

Da muß man sich dann so eine Frage, wie ich sie gestellt habe, tatsächlich "gefallen" lassen - ich hätte auch gerne SNMP oder "remote syslog" in den DSL-Modellen und bin trotzdem durchaus in der Lage zu verstehen, daß das nur von sehr, sehr wenigen FRITZ!Box-Besitzern überhaupt genutzt werden könnte und würde. Wenn ich so etwas also brauche und will, muß ich es selbst machen oder eben zu einem anderen Gerät greifen - das gilt (mit kleinen Abstrichen) auch für die Möglichkeit, eine einzelne, fest angegebene IPv6-Adresse statisch freizugeben (wobei ja trotzdem von der Box erwartet wird, daß die den Präfix vor der Interface-ID selbst richtig setzt) ... selbst wenn das bisher vielleicht funktionierte (auch das war ja noch lange nicht immer so).

Ich bleibe also dabei, daß Deine Anforderung der Freigabe mit einer einzigen statisch zugewiesenen IPv6-Adresse (die auch noch eine "bestimmte" sein soll, warum eigentlich genau? Willst Du sie eintippen?) schon recht "speziell" ist. Selbst wenn es für irgendwelche Zwecke vielleicht notwendig sein sollte, daß man eine solche Adresse dem Windows-Server zusätzlich zuweist (weil vielleicht nur von dieser Adresse aus irgendwelche Dienste anderer Server zu nutzen wären - was ja aber auch ausgehend wäre und gar keine Freigabe braucht), gibt es für mich keinen nachvollziehbaren Grund (überrasche mich mit einem, ich bin lernfähig), warum man dann nicht einfach noch die EUI-64 auf dem Server konfiguriert und die Freigabe-Steuerung der FRITZ!Box über diese machen läßt. Erst dann, wenn es auch dabei zu den "Verwürfelungen" von IP-Adressen kommen sollte, dann sehe ich das ggf. auch als Problem. Wenn die FRITZ!Box die Vergabe einer manuell festgelegten "Interface-ID" gar nicht erst anbieten würde (wie es andere Geräte machen, siehe c't-Artikel), dann würde sich die Frage gar nicht erst stellen (zumindest nicht so).

Ob für diese Adressen aus #1 tatsächlich ein Forwarding im PCP eingerichtet wurde, ist ja ohnehin ungeklärt, solange Du das PCP-Log nicht eingesehen hast und für die "vollkommen falsche" link-lokale Adresse stellt sich die Frage der (unerwünschten) Freigabe ohnehin nicht - spätestens da fällt für mich das "CRITICAL" aus #1 dann auch in sich zusammen, denn die einzige "zusätzliche" freigegebene Adresse ist ja die aus #1, die Du mit dem Zusatz "falsch, gibt’s auch nicht" versehen hast. Das ist aber eben die EUI-64 in den hinteren 64 Bit der IPv6-Adresse und keinesfalls das, was Du mit Deinem

dg2dra schrieb:

Das ist definitiv inakzeptabel und auch ein echtes Sicherheitsproblem, wenn ich nicht vorhersehen kann, was die Box so meint öffnen zu müssen. Nach meiner Ansicht hat das schon den Status CRITICAL.

Zum Vergrößern anklicken....

"befürchtest".

Dann, wenn die Box sich tatsächlich eine andere Adresse "auswürfeln" sollte, müßte man Dir sicherlich zustimmen (mit Einschränkungen, komme ich gleich noch mal drauf zurück) - aber die unbekannte "link-lokale" zählt hier einfach nicht (und ist ohnehin nicht wirklich freigegeben, denn per Definition eben "lokal") und Du kannst mit einiger Wahrscheinlichkeit auch nicht vollkommen ausschließen, daß diese Adresse tatsächlich mal von Deinem Server (und sei es temporär im Rahmen von NDP) in einem Paket verwendet wurde - jedenfalls solange nicht, wie Du keinen vollständigen Mitschnitt des IPv6-Verkehrs angefertigt hast. Wenn die FRITZ!Box ein Paket von Deinem Server mit dieser Absenderadresse gesehen hat, merkt sie sich diese halt (im Neighbor Cache) ... allerdings sollte sie das tatsächlich nicht "unendlich" machen und das macht sie eigentlich auch nicht, wie wieder die Erfahrungen von @Pom-Fritz! belegen.

Ich weiß aktuell gar nicht, ob die "Neighborhood"-Informationen auch noch in den Support-Daten stehen (früher taten sie das mal) ... wenn ja, sollte man da auch einmal nachsehen (da findet man dann ggf. auch die "Quelle" dieser unerwarteten link-lokalen IPv6-Adresse), wenn so eine Adresse erneut auftauchen sollte. Ist es ohnehin immer diese eine wie in #1, dann wird die halt irgendwo stehen ... daß sich das FRITZ!OS jetzt eine zufällige Adresse aus den Fingern saugt und das ist dann auch noch immer ein und dieselbe, ist ja eher unwahrscheinlich.

Es gab und gibt (denn es ist ja wohl reproduzierbar) offenbar einen Grund dafür, warum die Box bei Dir die Freigaben irgendwann mal entfernt und dann neu einrichtet (diesmal halt mit der EUI-64). Den würde ich erst einmal ermitteln ... das kann allerdings tatsächlich bereits ein "Neuverbinden" der DSL-Verbindung sein, auch wenn das eigentlich direkt daneben im Event-Log stehen sollte und da machen die verschiedenen Tunnel-Formen dann eben auch wieder einen Unterschied in der Behandlung solcher Events, weil natürlich ein 6in4-Tunnel erst wieder beim Broker angemeldet werden muß (mit der neuen IPv4-Adresse), während ein 6to4-Tunnel einfach "funktioniert" (da ist die IPv4-Adresse Teil der IPv6-Adresse und kann aus dieser abgeleitet werden, der Client muß sich also nirgendwo "registrieren" und kann sogar einfach per Anycast sein IPv6-Paket auf die Reise schicken, ohne die Adresse eines Relays kennen zu müssen - das nur als Erklärung für weitere Mitleser, die sich vielleicht damit nicht so auskennen).

Genauso gut kann es aber auch sein, daß die (m.W. AVM-eigene) Implementierung des "heartbeats" (zum Broker) oder für TIC nach der Umstellung auf PCP noch nicht richtig arbeitet ... auch das ist ja eine "Besonderheit", die nur bei der Verwendung von IPv6-Tunneln (mit Heartbeat, wobei ich nicht weiß, ob die FRITZ!Box das nur bei SixXS-Tunneln oder auch bei 6in4 unterstützt) überhaupt notwendig wird und die natürlich ebenfalls zu solchen Aktionen führen kann, wenn da die Notwendigkeit einer neuen "Anmeldung" angenommen wird (egal ob das nun stimmen mag in diesem Moment oder nicht). Insofern ist eben IPv6 nicht unbedingt gleich IPv6 und wie so etwas dann konkret arbeitet, kann wieder höchst unterschiedlich aussehen und aus dem Funktionieren des einen Modus kann man nicht automatisch das Funktionieren eines anderen herleiten (gilt umgekehrt auch für das Nichtfunktionieren, vulgo "nichts klappt bei IPv6" - es gibt eben funktionierende Konstellationen).

Wenn die Box diese Freigaben dann wieder einrichtet und dabei die EUI-64 (das ist auch der "voreingestellte" Wert in der Freigabe-Maske) verwendet, weil sie die von Dir fest vorgegebene abweichende Interface-ID für "verfallen" hält und wieder auf den "Normalfall" zurückgreift, dann mag das ein Fehler in der Implementierung sein (wenn es nicht wirklich "geplant" ist), den man irgendwann auch mal fixen sollte ... eine "kritische" Lücke kann ich darin nicht sehen (das würde voraussetzen, daß es einen anderen Client mit dieser IPv6-Adresse im "promiscuous mode" in Deinen LAN gibt, weil natürlich auch die L2-Adresse beim eingehenden Verkehr angepaßt wird und das nicht als BC/MC im LAN landet) und die Tatsache, daß es bisher immer so funktioniert hat, muß in meinen Augen auch nicht heißen, daß man da nichts mehr ändern darf. Dieses Thema (liebgewordene Workarounds, die aber eben auch nur solche sind und keine "offiziellen Funktionen") hatte ich aber auch schon weiter oben angedeutet.

Die Frage ist halt, was einem am Ende wichtiger ist ... eine funktionierende Lösung (wofür man eben die Ursache suchen muß und sich dann überlegen kann, wie man dem Problem aus dem Weg geht oder ob es nicht doch eine andere - vielleicht sogar bessere - Lösung gibt) oder daß es wieder so geht "wie früher".

Daß es in diesem Laborzweig (auch wegen der Umstellung auf PCP und der damit einhergehenden "Komplett-Renovierung" des GUI - und auch unter der Haube) an dieser Stelle Probleme gab, ist keine wirklich neue Nachricht - das wird hier diskutiert, seit es die ersten Änderungen an dieser Stelle (das war nicht gleich am Beginn der 06.69 alles auch umgesetzt, nur bereits teilweise zu sehen in den Eingeweiden) gab. Auch das von Dir nachträglich beschriebene Problem des "Verwürfelns" der IPv4-Adressen von zwei Clients war da schon dabei ... allerdings nicht mehr mit der Release-Version und bei "sauberer" Liste der "landevices" (meines Wissens jedenfalls nicht). Wenn Du also von "in einem Fall" schreibst, wäre die nächste Frage, wann und mit welcher Firmware nach welchen Konfigurationsversuchen "von Grund auf" das dann war.

Die Kombination aus einem "abgesetzten" DHCPv6-Server, der gar kein vom Provider dynamisch zugewiesenes Präfix verteilt, sondern das von HE statisch zugewiesene und wo die ganze IPv6-Funktion eigentlich nur dann benutzt werden kann, wenn die FRITZ!Box den Tunnel erfolgreich angemeldet hat (wo also Tunnel-Betrieb und Adressvergabe voneinander entkoppelt sind), ist genau das, was ich mit "speziell" meine.

Wenn die FRITZ!Box das Präfix tatsächlich selbst verwaltet mit ihrem eigenen IPv6-DHCP-Server, dann kann sich der Windows-Server z.B. ein (kleineres) Präfix delegieren lassen und dieses dann mit seinem DHCP-Server auch selbst verwalten. Kriegt der dann eine höhere Priorität, sollten auch die Clients sich ihre Adressen bei diesem DHCP-Server besorgen und nicht bei der FRITZ!Box - da schadet es auch nicht einmal unbedingt, wenn zwei Server dieselbe "Range" bedienen. Aber die FRITZ!Box "wüßte" wenigstens, daß der Windows-Server (mit seiner L2-Adresse) das potentielle Ziel für alle IPv6-Pakete mit einer Zieladresse innerhalb dieses delegierten Präfixes ist und kann die einfach 1:1 weiterreichen mit einen geänderten L2-Header. Was der Server dann damit macht (ob der seinerseits die Dinger weiterreicht an ein anderes Netz als Router oder sie alle für sich haben will), kann dem Border-Router vollkommen egal sein.

Liegt dann die gewünschte "statische" IPv6 des Servers in dem delegierten Präfix (das ist dann halt mehr als eine Adresse, die sich der Windows-Server da reserviert und davon darf er auch welche weitergeben), kann die FRITZ!Box wieder (als Alternative zur "nativen Freigabe" mit der EUI-64) das komplette delegierte Segment freigeben - die Option "exposed host" gibt m.W. auch nur die eine eingetragene Interface-ID frei (halt ohne die Beschränkung auf einen oder mehrere definierte Ports) und nicht alle "gelernten" IPv6-Adressen für diesen "host" (das wäre vermutlich auch viel zu tun, kommt halt drauf an, wie häufig der Client die Adressen wechselt - außerdem kann der Router ja nicht wissen, welches nun Adressen mit "privacy extension" sind und nur für ausgehenden Verkehr verwendet werden sollen).

Selbst wenn in diesem freigegebenen Präfix jetzt weitere LAN-Clients mit ihren IPv6-Adressen liegen sollten, die sie vom DHCPv6-Server auf dem Windows-Server erhalten haben, kriegen die durchgelassenen Pakete ja trotzdem die L2-Adresse aus der Freigabe verpaßt und erreichen damit (wieder im Normalfall und der wäre eben, daß der Client nicht im "promiscuous mode" arbeitet) nur den Windows-Server.

Eine weitere Alternative wäre es eben, den Windows-Server einfach dazu zu bringen, daß er selbst (und zwar von der "gewünschten" IPv6-Adresse aus) eine dynamische Freigabe in der FRITZ!Box einrichtet. Wenn die Behandlung solcher dynamischer Freigaben dann besser funktioniert (hier wäre der "PCP-Client" eben der Windows-Server und nicht irgendein Daemon auf der Box, der für diese statischen Freigaben zuständig ist - vermutlich ist es der "dsld"), dann wäre das Problem ebenfalls gelöst.

Auch diese Freigaben pro Host und die damit einhergehende Möglichkeit, das so fein zu "granulieren" in der Berechtigung, daß man nicht nur "allen Clients" eine solche Einrichtung gestatten kann (meinetwegen bei Game-Consolen sogar muß), sondern gezielt nur denjenigen, die es brauchen, ist am Ende in der Summe eine Verbesserung der Sicherheit - und wenn im Zuge der Integration solcher neuer Funktionen nicht gleich alles auf Anhieb funktioniert, sehe ich das solange eben nicht als Katastrophe an, solange es nicht wirklich ein Sicherheitsproblem darstellt oder das Gerät/die Funktion damit seinen/ihren Nutzen für größere Teile der Kunden/Benutzer verliert.

PCP ersetzt nun einmal den alten statischen Mechanismus mit einem dynamischen (und bietet viel mehr Möglichkeiten), da kann ich mir auch nur schwer eine (langfristige) "Koexistenz" vorstellen - wohin das hier führt (irgendein Daemon im FRITZ!OS muß die Stelle des PCP-"Clients" einnehmen und sich um die Verwaltung kümmern, wo das doch das eigentliche Ziel der Freigabe viel besser könnte und das weiß dann auch gleich noch, ob es wirklich "empfängnisbereit" ist oder nicht), sieht man (leider) auch.

Ich bin ja ebenfalls der Meinung, daß AVM längst nicht alles auch (richtig) testet, was man so veröffentlicht und ich habe auch genug Stellen gesehen (und aufgezeigt), wo das wirklich simple Probleme waren, die sofort ins Auge springen müßten, wenn man nur ein einziges Mal auch die betreffende Funktion verwenden/aufrufen will. In diese "Schublade" der allzu offensichtlichen Fehler würde ich das hier auftretende Problem nun aber auch nicht einordnen ... egal wie nervig das für den Betroffenen auch sein mag - eben genau wegen dieser "speziellen" Konfiguration, die nun garantiert keine ist, die bei der Mehrzahl der FRITZ!Box-Benutzer eine Rolle spielt.

Und ich ziehe einen Teil meiner Behauptungen zurück, weil ich tatsächlich nicht berücksichtigt habe, daß einige IPv6-Tunnel gar nicht "in Hardware" funktionieren können (ich kenne zwar die Spezifikationen dort nicht, aber ich kann mir nicht vorstellen, daß solche Network-Prozessoren dann tatsächlich auch im "offloading" ein IPv6-Paket aus einem IPv4-Paket extrahieren) und damit eben bei solchen Freigaben (ich schreibe mal "vermutlich", weil der PCP-Teil ja "closed source" ist) nicht einfach nur eine L2-Adresse in eingehenden Paketen auszutauschen ist.

Das wäre bei Dualstack so (ggf. noch bei 6to4 zumindest "möglich", weil am Inhalt nichts weiter zu ändern wäre, wenn ich das richtig sehe) ... bei den anderen Tunnelformen muß aber der IPv6-Traffic erst "ausgepackt" werden und dann an einer ganz anderen Stelle entweder ebenfalls noch mal einer "Inspektion" seitens der Firewall unterzogen werden oder er wird über irgendeinen Hook ganz weit vorne (aber sicherlich immer noch "hinter" der Hardware-Lösung) wieder injiziert und durchläuft dann den Prozess noch einmal, diesmal halt als IPv6-Paket. Aber egal, wie das auch immer realiisiert sein mag, die notwendigen Prozesse sind eben recht unterschiedlich, wenn man sie mit anderen "flows" vergleicht und damit treten solche Fehler dann immer noch bei spezifischen bzw. einzelnen Konstellationen auf.

Wenn ich das richtig sehe, dann gibt die FRITZ!Box ja auch bei Dir die EUI-64 richtig frei und das ganze AD sollte ja auch dann funktionieren, wenn es von einer IPv6-Adresse mit dieser EUI-64 "serviert" wird - meine Frage zielte ja auch mehr darauf ab, warum es denn nun unbedingt die "::8" sein soll als Interface-ID und auch wenn der Windows-Server das AD verwaltet (samt DNS und DHCP dafür), könnte er das ja mit einem delegierten Präfix "hinter" der FRITZ!Box tun. Wenn es dann irgendwo einen "glue record" für die IPv6-Adresse des DNS-Servers bei einer Registry geben sollte (das ist tatsächlich m.W. eine "Regulierungslücke", weil die NICs i.d.R. da zwar keine "dynamischen Adressen" für NS zulassen in ihren Bestimmungen, aber man einer 6to4-Adresse eben nicht (mehr) ansehen kann, ob sich dahinter ein statischer oder ein dynamischer Tunnel verbirgt), dann kann man den ja auch auf die EUI-64 anstelle der ::8 (unter dem von HE zugewiesenen Präfix) zeigen lassen.

Das sind m.E. schon mal mindestens zwei "Stellschrauben". Die erste wäre für mich die (notfalls zusätzliche) Verwendung der EUI-64 auf dem Server und das Anpassen der DNS-Server-Adresse in der entsprechenden Zonen-Delegierung - allerdings kann ich auch problemlos meine Domains an diesem Punkt selbst verwalten und betreibe den primären DNS (über IPv4 und IPv6) selbst, so daß ich da volle Kontrolle habe ... geht das über langwierige Faxe mit Änderungswünschen und DNS-TTL jenseits einer Stunde, ist das vielleicht nicht die erste Wahl. Die zweite wäre das "saubere" Delegieren eines (Sub-)Präfixes ... ob allerdings der Windows2012-Server das sauber gebacken kriegt (ohne Zusatz-Software), weiß ich nicht.

BTW ... gerade ein 6in4-Tunnel mit einer dynamischen Gegenstelle braucht eigentlich ganz dringend einen Heartbeat und sollte/muß dann auch relativ schnell "zumachen", wenn der ausbleibt. Du fändest es bestimmt auch nicht so lustig, wenn - z.B. bei einer Störung Deines DSL-Anschlusses - die für Dich per IPv6 bestimmten Daten an Deinen "Nachfolger" unter der bisher verwendeten IPv4-Adresse gesendet werden - es wäre mir jedenfalls neu, wenn so ein HE-Tunnel irgendwie die Authentizität der "Gegenstelle" prüft. Jenseits vom TIC, nicht daß wir uns da mißverstehen ... ich meine schon die "normalen Datenpakete" und nicht die Tunnelsteuerung, wobei ich nicht weiß, wie die bei HE für dynamische IPv4-Adressen arbeitet.

Das Beste (aka "die Krönung") sind dann irgendwelche URL-basierten "Tunnel-Anmeldungen", wo der reine Aufruf einer URL mit der richtigen Tunnel-ID dann zur Änderung der Gegenstelle für den Tunnel (auf die Adresse des Absenders so eines Requests) führt. Das mag noch bei Tunneln mit statischen Gegenstellen funktionieren oder wenn man allen anderen Internet-Teilnehmern nur gute Absichten unterstellt, aber ist irgendwie auch nicht mehr zeitgemäß, weil viel zu leicht zu kapern.

Wenn ich das bei Dir alles mißverstanden habe und Du mit statischen IPv4-Adressen arbeiten kannst, dann würde sich ja tatsächlich eher 6to4 anbieten für das Tunneln von IPv6 an einem Anschluß, der das nicht von sich aus als Dualstack bietet. Ich bin im Prinzip in einer solchen Situation ... mein T-DSL-Business bietet mir zwar seit langem eine feste IP-Adresse, aber die Telekom kriegt es nicht auf die Reihe, da auf Dualstack umzustellen und so muß ich (an diesem Anschluß jedenfalls) immer noch auf ein Tunneln von IPv6-Traffic zurückgreifen. Der "zweite Weg" über einen Kabel-Anschluß bietet hingegen schon seit mehreren Jahren "echtes" IPv6 über Dualstack an - ausgehender IPv6-Verkehr nimmt daher bei mir bevorzugt diesen Weg (die MTU ist wegen der fehlenden "Verpackung" einfach größer).

Ich verstehe ja auch Deinen Frust, wenn es so wie bisher bei Dir eben nicht mehr funktioniert ... trotzdem kann ich Dir nur ganz dringend dazu raten, die Aufgabe für Dich auch mit einer 06.8x zu lösen. Die 06.60 mag das zwar noch genauso machen, wie Du es brauchst und bisher verwendest ... aber sie hat eben einige Sicherheitsprobleme und man sollte sie zeitnah durch eine 06.8x ersetzen (ob 06.80, 06.81 oder 06.83, macht - an der Stelle, wo ich um Sicherheitslücken weiß - allerdings nur einen einzigen Unterschied ... aber da können natürlich noch weitere Lücken behoben sein, die ich nicht kenne).

Ich betreibe eine Fritzbox 7490 an einem DS-Lite Anschluss eines örtlichen Anbieters. Nachdem seit 6.80 endlich die Freigabe von delegierten IPv6 Prefixen in der Fritzbox Firewall klappt, konnte ich erfolgreich eine Sophos UTM dahinter betreiben welche ein /62 zugewiesen bekommen hat.

Ich habe regelmäßig (ich würde sagen alle 3-4 Wochen) das Problem das die Fritzbox auf einmal anfängt IPv6 Adressen zu würfeln, ohne das sich auf Providerseite irgendwas getan hat (der /48 Prefix ist derselbe) - Die Sophos bekommt dann auf einmal ein neues /48 Prefix und manchmal auch eine leicht geänderte IPv6 WAN Adresse (z.B. kommt zwischendrin in der IPv6 Adresse noch eine :0: mit rein)

Ich habe vor rund 2 Monaten schon ein Feedback Formulare Richtung AVM geöffnet, werde dies vermutlich auch bald nochmal wiederholen. Was IPv6 angeht muss man der Fritzbox zugestehen das es hier nach dem Lancom (die hat allerdings andere Nachteile) am Besten und zuverlässigsten funktioniert von allen Geräten die ich bisher getestet habe (Lancom, Microtik, Pfsense), auch wenn hier und da noch Macken vorhanden sind.

eine Profibox/Profimodus von AVM auf den Fritzboxen wäre toll wo man die volle Kontrolle hat. Oder von mir aus ein Router der 499,- € kostet und mehr bietet. Der Markt scheint aber wohl nicht interessant zu sein.

@Heiko: Das mag ich jetzt von vielen Faktoren abhängen, ich habe die Erfahrung gemacht dass das AC der Fritzbox 7490 auch nicht grad das gelbe vom Ei ist. Ich hab mit einem nicht-AC Gerät von Cisco Meraki in der gesamten Wohnung rund 100/100Mbit/s Durchsatz, wo die Fritzbox längst auf 10-15Mbit/s absackt. Die Trennung Richtung WLAN verschmerze ich daher gerne, sehe aber natürlich den Charme einer all-in-one Lösung. Vielleicht ja bei der nächsten Box Generation?

zur IPv6 Problematik; Es lassen sich ja manuell IPv6 Routen anlegen, dort könnte man theoretisch selbst aus dem /48 ein Subnetz einrichten. Das scheint aber nicht unbedingt so zuverlässig zu funktionieren. Hat hier jemand schon mit herumgetestet?