Die Portweiterleitungen verwenden jetzt intern eine PCP-Implementierung und müssen daher in regelmäßigen Abständen erneuert werden (ist in einem RFC geregelt und nicht im BtMG, auch wenn es eine "Abhängigkeit" geben mag). Für die fest eingerichteten ist da jetzt irgendeine Komponente der Firmware zuständig (welche, habe ich noch nicht versucht zu ermitteln, dem Augenschein nach würde ich sagen, es ist der "dsld") und diese hat hier vermutlich "versagt", als es zwischenzeitlich notwendig gewesen wäre, einen passenden MAP- oder PEER-Request zu erneuern. Wo und wie diese Komponente (also wohl der dsld) dann die Freigaben verwaltet, für die sie zuständig ist und ob ggf. zusätzliche (automatische) Freigaben oder sogar nur vergebliche Versuche, solche einzurichten, diese festen Freigaben beeinflussen können, wird sich sicherlich erst im Laufe der Zeit zeigen. [EDIT: Ich habe gerade noch einmal richtig gelesen (shame on me) ... ob tatsächlich auch die Freigabe für komplette IPv6-Präfixe über PCP implementiert ist, weiß ich gar nicht - habe ich auch noch nicht angesehen ... es gibt viel Neues zu entdecken.]
Das war jedenfalls eine Baustelle (inkl. der Verwaltung der Portweiterleitungen im GUI), an der AVM fast bis zuletzt noch Änderungen vorgenommen hat und die im Labor-Zweig zwar entwickelt und vielleicht bei vielen Kunden, aber noch nicht so richtig auf Herz und Nieren, getestet wurde. Es ist auch (m.W.) die erste umfassende PCP-Implementierung in einem CPE und schon im RFC gibt es genug Fälle, die ein PCP-Server berücksichtigen muß - angefangen beim "rapid recover", wenn er seinen vorherigen "Zustand" irgendwie verloren hat (das kann eine neue (WAN-)IP-Adresse oder ein Reboot seines Hosts, wenn es um "extern" eingerichtete Mappings von LAN-Clients geht).
Mithin ist auch die AVM-Implementierung neu und zumindest wenn ich das richtig interpretiere, hat AVM das auch so umgesetzt, daß die Box selbst ebenfalls nur ein PCP-Client unter vielen ist und sich genauso um ihre eigenen Mappings kümmern muß, wie um die "fest" per GUI eingerichteten - es sieht sogar so aus, als wäre tatsächlich jede Komponente selbst dafür verantwortlich, die benötigten Freigaben (auf die Box selbst eben auch) zu verwalten und für ihre (regelmäßige) Erneuerung zu sorgen - aber das ist nur der erste, noch unvollständige Eindruck. Da das alles in der Labor-Reihe ständig im Fluß war, machte der Versuch einer weitergehenden Analyse bisher noch keinen richtigen Sinn.
Ansehen kann man sich diese neue Art der Freigabe (inkl. einiger interessanter Details, die etwas über die "Arbeitsteilung" der Komponenten aussagen könnten) in den Support-Daten, dort sollte die Ausgabe des (neuen) Kommandos "showpcpinfo" enthalten sein und da werden die gerade aktiven Freigaben aufgelistet, inkl. ihrer jeweiligen "lifetime", vor deren Ablauf sie dann wieder erneuert werden müssen.
Sollte das Problem noch einmal auftreten, kann man sicherlich anhand der Support-Daten (auch selbst) eine genauere Einschätzung treffen als es eine Schlußfolgerung anhand der Symptome ist. Vergleicht man das dann mit der Ausgabe bei funktionierender Weiterleitung, sollte man zumindest anhand der "Differenz" genau ausmachen können, welche Weiterleitungen alles betroffen sind (es könnten ja alle IPv6-Freigaben betroffen sein, wenn man mehrere Geräte freigegeben hat oder nur die für einen einzelnen Client im LAN) und in der Ausgabe gibt es am Ende eigentlich auch eine Historie der zuletzt ausgeführten "MAP"-Requests (erneuerte Weiterleitungen werden dort m.W. nicht protokolliert), so daß man wohl auch sehen könnte, ob es zusätzliche Versuche für andere Mappings gab.
Da es m.W. keiner weiteren Autorisierung/Authentifizierung bedarf bei einem PCP-Request und dafür schon die generelle "Erlaubnis" über die Checkbox in den Netzwerkeigenschaften des Gerätes im FRITZ!OS-GUI ausreichen sollte, würde mich z.B. mal interessieren, ob auf diesem Weg nicht tatsächlich ein DoS-Angriff einer Malware im LAN (auf einem Gerät mit der PCP-Berechtigung) möglich wäre, indem diese einfach versucht, einen dieser Ports auf das eigene Gerät freizugeben. Bei fehlerfreier Implementierung (es ist aber die erste Version von AVM, wo das wirklich alles auf PCP umgestellt ist - da sollte man auch noch etwas Nachsicht walten lassen und die Chance zur Nachbesserung einräumen) müßte so ein Request fehlschlagen, egal zu welchem Zeitpunkt (ob direkt beim Start der Box oder kurz vor dem Ablauf der Lifetime eines Mappings, bei "Überlastung" des PCP-Daemons, usw. - es gibt sicherlich einiges an "corner cases" zu berücksichtigen).
Hier hat AVM nach meiner Ansicht auch deutliches "understatement" gezeigt ... das ist schon eine ziemliche Errungenschaft, das alles auf eine modernere Basis umgerüstet zu haben und - wenn es irgendwann mal Provider mit CGN und PCP-Support geben sollte (vielleicht gibt es die ja und ich kenne nur keinen, Hinweise nehme ich gerne entgegen) - dann müßte es in der Theorie sogar mit einer FRITZ!Box wieder möglich sein, auch noch bei DS-Lite über IPv4 eingehende Verbindungen zu ermöglichen (oder auch bei reinem IPv4-CGN bei kleinen Providern mit wenigen Adressen, wo so ein PCP-Server dann die Notwendigkeit der Umstellung der Kunden auf öffentliche IPv4-Adressen ersetzen kann, wenn eingehende Dienste möglich sein sollen/müssen), die keinen festen externen Port benötigen.
Zumindest das "Tunneln" bis zum Border-Gateway sollte in einer Umgebung mit kaskadierten FRITZ!Boxen schon mal funktionieren, womit dann die "Orgien" bei der Einrichtung auf mehreren Routern entfallen könnten ... wobei mir noch unklar ist, ob und wenn ja, wie eine FRITZ!Box nun ihrerseits entscheidet, ob sie bei ihr "angemeldete" Mappings an einen vorgelagerten PCP-Server weiterreichen soll oder nicht. Für solche "Ermittlungen" ist im PCP-RFC eigentlich Multicast vorgesehen und das hat ja einige "Begrenzungen" im Routing. Neben der erwähnten Zurückhaltung beim "Feiern" gibt es leider auch eine Zurückhaltung bei der Dokumentation (zumindest bei der öffentlich einsehbaren) und somit wird wohl wieder ncihts anderes bleiben, als daß die Kunden das Stück für Stück selbst ermitteln - das wird seine Zeit brauchen und im Moment ist die Version für die 7490 ja noch keine drei Wochen alt.
Warte momentan noch auf den nächsten Reboot, aber vielleicht hat sich das ja erledigt.
