dass das AVM VPN IPv6 fähig wird.
Wobei das schon etwas komplizierter sein dürfte, als das nur in irgendein anderes Transportprotokoll zu packen. Künftig ausschließlich IPv6 für das VPN zu verwenden, dürfte sich von selbst verbieten (siehe #5) und bei einem "Mischbetrieb" ergeben sich schon aus den unterschiedlichen Fähigkeiten von Endpunkten dann weitere Probleme.
Das geht beim Ermitteln der Adresse des Peers los. Eigentlich DÜRFTE das AVM-VPN ja auch nicht funktionieren (zumindest nicht mit dynamischen Adressen) ... das ist nur der Tatsache geschuldet, daß AVM in sehr kurzen Abständen die DNS-Adresse erneut abfragt und bei einer Änderung dann die Verbindung zur neuen Adresse aufbaut, während die alte verworfen wird. Hier sieht man schon die enge Verquickung von zwei (unterschiedlichen) Diensten im AVM-VPN ... es müßte also nicht nur der Transportteil überarbeitet werden, sondern auch der Teil, der den Peer erst einmal lokalisiert in den Weiten des Internets. Wie man dann die Peers behandelt, die weiterhin mit "echtem" Dualstack unterwegs sind und daher sowohl einen A- als auch einen AAAA-Eintrag im DNS haben, wäre die nächste zu beantwortende Frage.
Je nach IPv6-Anbindung (Tunnel oder nicht, wenn ja, welches Verfahren) ergeben sich dann unterschiedliche MTUs und da bei einer VPN-Verbindung nun mal die Integrität auf Paketebene sichergestellt werden muß, muß das auch von jedem Peer bereits selbst organisiert werden, daß nur Pakete auf die Reise gehen, die keiner weiteren Segmentierung bedürfen. Solche Verfahren wie "NAT-Traversal" bei IPSec mit IPv4 (wo die Pakete extra so verpackt werden - quasi noch mal in einer gesonderten Umverpackung - daß ein Router diese auch ändern kann) sind bei IPv6 auch nicht üblich - schon NAT an sich ist bei IPv6 ja eher ungewöhnlich.
Wenn es tatsächlich nur darauf hinauslaufen würde, das einfach in ein anderes Protokoll zu verpacken (und dabei die Kompatibilität zu wahren), dann hätte AVM das vermutlich auch schon in Angriff genommen.
Immerhin scheint es ja in der Frage "Initiator vs. Responder" in den letzten Versionen Bewegung gegeben zu haben, denn das dürfte der Hintergrund für das
- Verbesserung VPN LAN-LAN Kopplung einer FRITZ!Box am DS-Lite-Anschluss zu IPv4-Gegenstellen ermöglicht
(in der 07.11) bei AVM sein, wo nun wohl nicht mehr die SAs für beide Richtungen abgeräumt werden, wenn die eine einen Fehler hervorbringt.
-----------------------------------------------------------------------------------------
Und bisher wird PCP dem Kunden auch nicht viel weiterhelfen ... zwar kann damit ein Client eine "Portfreigabe" auf einer öffentlich erreichbaren Adresse einrichten, aber die Natur der IP-Protokolle (also TCP und UDP mit ihren 16-bittigen Portnummern) gestattet nun mal pro IP-Adresse nur eine einzige Nutzung einer speziellen Portnummer und im PCP ist ausdrücklich vorgesehen, daß der PCP-Server dem Client auch einen anderen externen Port "zuweisen" kann.
Macht er das, hat ein Benutzer dieses Services (also der Portfreigabe) aber gar keine Ahnung, auf welchem Port er diesen erreichen kann. Das DNS ist ja - eigentlich - nur dazu da, den DNS-Namen in eine IP-Adresse zu verwandeln ... aber nicht direkt in eine zugehörige Portnummer.
Zwar gibt es auch im DNS die Möglichkeit, mittels spezieller Einträge (SRV-RRs) noch die zu verwendende Portnummer für einen Dienst zu publizieren, nur tauchen da die nächsten Hürden auf:
- fast kein DynDNS-Anbieter unterstützt die Änderung von SRV-RRs, m.W. auch myfritz.net bisher nicht
- der DynDNS-Client von AVM bietet von sich aus keine Möglichkeit, die tatsächlich zugewiesene Portnummer bei einer Aktualisierung zu übergeben - ohnehin funktionieren die "Client-Freigaben" ja bisher nur über den MyFRITZ!-Service von AVM selbst und das ist dann wieder ein SPOF (und eine proprietäre Lösung obendrein)
- es gibt praktisch keine Clients (mal abgesehen vom Teamspeak-Client - das ist ein Client für eine Art Voice-Conference-Server), die sich so eine Portnummer dann auch dynamisch durch Abfrage von SRV-Records besorgen ... bei einigen SIP-Clients mag man da noch Glück haben, weil SIP-Provider auch gerne mit SRV-Records arbeiten
Von einem Browser, der für eine URL "
https://www.ip-phone-forum.de" erst mal eine Abfrage nach "_https._tcp.ip-phone-forum.de" als SRV-RR macht (oder spätestens dann, wenn auf dem Standard-Port 443 keine Antwort kommt, was schon lange genug dauern würde bei einer FRITZ!Box im "black-hole mode"), habe ich jedenfalls noch nichts gehört oder gelesen.
Beim PCP braucht also der Server noch eine (gängige) Methode, nicht nur die IP-Adresse (des Gateways) zu publizieren, sondern auch noch die zugewiesene Portnummer und die ist keineswegs statisch. Die eingesetzten Clients müssen dann auch noch in der Lage sein, diesen "Verzeichnisdienst" auszulesen.
Damit kann man mit PCP zwar in der Theorie eingehende Verbindungen an den (PCP-)Client weiterreichen, nur nutzt das auch nichts, wenn "die Leute" im Internet (und dazu gehört auch der Besitzer der Box mit seinen Apps auf dem Tablet oder Smartphone) nicht auf anderen Wegen darüber informiert werden, wo dieser Endpunkt nun eigentlich zu finden ist. Ein IP-Endpunkt besteht eben immer aus der Adresse UND der Portnummer.
