Beiträge von Phino

Zitat von HubeBube

Hm, hast Du in Port 10 ein SFP-Modul (GPON Modul) und Port 11 ein SFP+ Modul (z.B 10 Gbps) ?

In der UDM ist es nicht statthaft Module mit unterschiedlichen Standards/Synchronisierungstakten in Slot 10 und 11 zu verwenden. Entweder 2x SFP (maximal 1 Gbps, gilt auch für GPON) oder 2x SFP+ (Bandbreiten größer 1 Gbps, z.B 2,5;5;10).

Dir und allen Mitgliedern wünsche ich ebenfalks ein schönes, friedliches und gesegnetes Weihnachtsfest!

Also bei mir funktioniert dies mit der UDM Pro SE so von Anfang an (Dez. 2021).
Port 11 SFP+ mit 10 GB per DAC zum nachfolgenden Switch/LAN.

Port 10 ein SFP-Modul zu Ethernet mit 1 GB an dem zurzeit der Vigor/VDSL hängt.
Am Port 9 hängt mein LTE Modem als Fallback mit 100 MB.

Nicht durch die Device-Angaben irritieren lassen, damit hat die aktuelle Beta, genau wie mit der Topologie ein großes Problem.

Zitat von murphaph

Phino wie sieht's aus in deiner Straße? DNS was verlegt schon?

Nö. Es gab ein böses Erwachen. Bevor es sehr kalt wurde (Ende Nov.), saßen die Techniker von GeoDuct ja in den kleinen Zelten an den Verteilerkästen und sorgten für den Feinschliff. Ich kommunizierte mit ihnen (sehr gutes Englisch) als sie an der Vorholz/Fontane arbeiten. Dabei kam raus, dass sie verzweifelt die Pipe´s suchten, die zu uns in die Straße führen. Sind aktuell 12 Anschlüsse (von 22 Häuser) in der Rilkestr. nach ihren Unterlagen verlegt.
Ups. Sie sind nicht da. Anruf beim Bauherrnservice DNS:NET. Ja, hier bei uns sollen nach den Unterlagen die Pipes schon bis zu den Häuser/Grundstücke liegen. Also müssen wir warten, bis der Tiefbau frühesten im Feb./März wieder aktive wird. Wir hatten ja schon eine Termin im Briefkasten.

Glasfaserausbau-Straße-Termin.pdf

Zitat von OleB123

Die UDM Pro erkennt nichts auf dem SFP WAN (beide physischen Slots probiert) und es kommt keine Verbindung zustande.

Hierzu die Frage, ist damit gemeint, dass die Module nicht erkannt werden oder wird kein Signal auf der Glasfaser "gesehen" durch die Module.
Beim ersten Punkt hat deine UDM auf SPF ein Problem, eher unwahrscheinlich.
Beim Punkt 2 würde ich tatsächlich auf ein Übertragungsproblem auf den letzten Teil der GF-Strecke schließen. Da kann dann das neue Patch-"Kabel" helfen, weniger Steckverbindungen sind immer von Vorteil. Vielleicht hat auch dein anderes Patchkabel LC auf SC ein Kabelbruch/Produktionsfehler, GF-Kabel sind deutlich empfindlicher als die Kupfer-Teile.
Die UDM ist extrem bescheiden, wenn es um Informationen zu den Schnittstellen auf der Oberfläche geht. Für notwendige Information muss man leider unter die Haube per SSH, da sollte man weitere Information zu den Modulen und dem Verbindungsaufbau finden.
Wenn du eine SE hast, ist unter der Haube jetzt* schon Debian, du kannst grundsätzlich alle an Tools nachinstallieren.
Ein sehr gutes Werkzeug ist der Midnigth Commander. Installieren auf der ssh - Konsole mit

sudo apt-get install mc 

Danach einfach mc eingeben. Damit kann man gut suchen, Dateien/Logfile betrachten, aber auch Dateien anlegen/editieren. Weitere Informationen zum System und wie man ihn installiert, dass er Firmware-Update übersteht, findest du im deutschen Ubiquiti Forum.

* bei der Pro erst in der Beta 2.x

Zitat von Bit

Ja, ich werde gerne mal ein paar "Messdaten" posten, wenn es soweit ist. Ich hoffe, in ein paar Wochen, wenn alles klappt. Der Glasfaserring liegt im Haus am Installationsplatz. Er ist aber noch nicht gespleißt.

Bisher habe ich mich zur Übertragungsrate an den Diagrammen der Unifi Dream Maschine Pro orientiert. Ich bilde mir ein, man konnte den Test-Host dort mal konfigurieren.

Zum rechtlichen: Vielleicht lässt sich ein Nachlass in den Beiträgen rausschlagen, wenn nun weniger Durchsatz garantiert ist, als beim Abschluss zugesichert. Immerhin verweist ja auch das ursprüngliche Produktdatenblatt auf §1 TK-Transparenzverordnung?

Die Messung aus der UDM (einfach/pro/SE) kannst du vergessen. Bei allem, was schneller als 250 Mbps ist, sind die Messzyklen zu kurz und/oder die Server zu langsam, die eingetragen sind. Lieber ein externes Tool nutzen (BNetzA).

Die Eintragungen von 10/2020 in deinem Eröffnungsartikel erscheinen sinnfrei gewesen, da hat wohl jemand nicht richtig Korrektur gelesen. Bei mir im Vertrag standen jedenfalls die anderen Werte.

@alfalfa 
Da habe ich wohl den Ausgangspunkt etwas aus den Augen verloren.
Ich ärgere mich schon seit mehr als 10 Jahren mit den nachlässigen Eintragungen* zu den IP-Adressen der ISP auf der Arbeit herum, sodass ich da etwas viel gemault habe. Sehe ja fast jeden 2. Tag das Problem bei meinen eigenen IPs.

* PS: selbe Problem auch bei Domains

Zitat von alfalfa

Kannst du bitte die konkrete Verpflichtung belegen, dass ISPs den Einsatzort von IP-Adressen dokumentieren müssen? M.W. wurde erst vor wenigen Jahren der Status Quo in der Hinsicht bestätigt, und der ist, dass die Interpretation der Country Angabe zu den Adresszuteilungen dem ISP freisteht. Selbst wenn es eine Verpflichtung gäbe, den Einsatzort der Adressen gegenüber RIPE anzugeben, bestünde diese Verpflichtung nicht gegenüber den GeoIP- oder Streaming-Anbietern. Im übrigen ist zuverlässige Geolokalisierung auf der Basis von IP-Adressen ein endnutzerfeindliches Konzept, das man nicht auch noch unterstützen sollte.

Die Verpflichtung besteht darin, die Zuordnung des IP-Adressblockes zu dem neuen Verantwortlichen zu hinterlegen. Z.B. um Netzprobleme (DOS-Angriffe) möglichst schnell kommunizieren zu können.
Diese Datenbankänderungen werden durch die GeoIP-Anbieter registriert, was diese veranlasst, die Adressen neu zu tracen, um sie zu lokalisieren. So z.B. nutzen Sie auch auf Datenbanken von Shop-Systeme, mit dehnen sie Verträge haben. So kommen ja auch die typischen Sicherheitsmails von Amazon und Co. zustanden: "Sie haben sich auf einem neuen Geräte aus Berlin angemeldet." Was natürlich manchmal amüsant ist, wenn man gerade sich in Spain befindet und per VPN übers Handy sich anmeldet.

Zitat von kingpin42

Genau dieses Vorgehen von AVM verwirrte den BNG, das ist auch sehr gut hier beschrieben:

Da hat aber scheinbar AVM genau im Jahre 2019 reagiert, als die Telekom mit BNG begann.

Es geht ja nicht per seh um die Lokalisierung durch Whois / Ripe-Datenbank. Aber sofern sich in diesen Datenbanken keine Änderung ergibt, gibt es ja für MaxMind & Co. wenig Grund ihre Informationen zu aktualisieren. Wobei dort auch andere Informationsquellen genutzt werden. So werden IP-Adressen von Käufen bei Amazon abgeglichen hinsichtlich Bestelladressen. In der Masse schon recht gute Möglichkeit.
So gesehen sind schon die ISP gefordert ihre Eintragungen aktuell zu halten, insbesondere das es ja Teil der Verträge mit dem Ripe und den 4 NIC ist.
Ich brauchte im beruflichen Umfeld genau diese Informationen und daher weiß ich seit ca. 10 Jahren um die Genauigkeit. Es ist halt so, dass nach eigenen Statistiken bei selber entwickelten Software zu Lokalisierungen bei über 99 % liegt. Dabei wurde unter anderen MaxMind genutzt. Und dabei ging es nicht um Länder, sondern Regionen.
Daher werden auch die Streaming-Dienste kein mehr an Anstrengungen unternehmen, um auf höhere Trefferzahlen zu kommen.

Zitat von alfalfa

Wo siehst du die Provider in der Pflicht? Sollen die wirklich jeden Geolokalisierungsdienst ausfindig machen, um deren Datensammelalgorithmen zu debuggen? Ich habe sowas schonmal entwickelt, aber mich hat noch kein Provider deswegen kontaktiert, weder ein kleiner noch ein großer. Wie sollten sie auch?

Gerade hier sehe ich viele Nachlässigkeiten bei den Providern. Beispiel mein Provider DNS:NET. Ich habe regelmäßig IP-Adressen, die in der Ripe Daten der Firma Airdata AG* zuzuordnen sind. Hinsichtlich Streaming unproblematisch, da die Firma ja auch in Deutschland ihren Sitz seit 2004 hat. Aber es zeigt, wie nachlässig in der Ripe-Datenbank eingetragen wird. Wie soll da den Geo IP funktionieren?

*Ich kenne AirData schon seit 2004, wir waren Erst-Kontakt und haben über dessen Funkversorgung unsere Filialen angebunden, wo es noch kein gutes DSL gab.

Zitat von alfalfa

Die Antwort rettet ein wenig, dass jemand wirklich auf das Problem eingegangen ist und die Zusammenhänge kurz erläutert hat. Vom Anbieter-Kunde Verhältnis her ist die Antwort trotzdem eine Frechheit. Die Geolokalisierung ist nicht das Problem des Kunden. Wie der Streaminganbieter seine Regionenbeschränkungen umsetzt, ist allein seine Sache. Fehler dabei gehen ganz klar zu Lasten des Streaminganbieters. Der Kunde muss keine falsche Sperre dulden. Ich sehe da nicht einmal eine Mitwirkungspflicht.

Haha, dazu musst du mal die AGB von Joyn lesen. Von 16 §§ der AGB gibt es nur einen sehr, sehr kurzen § 11. Verfügbarkeit, Leistungstörungen der die Rechte der User ein wenig stärkt, sonst alles nur was die User zu tun oder zu lassen haben. Jedenfalls ist man diesem Anbieter ausgeliefert und ich glaube bei den Anderen wird es nicht viel besser sein.

So gesehen, ist der Kundendienst ist es ja schon fast über ihren Schatten gesprungen.

Zitat von frank_m

Was einen aber nicht davon befreit, seinen vertraglichen Pflichten nachzukommen. Sowohl gegenüber den Endkunden, als auch gegenüber den Rechteinhabern. Wenn das Verfahren fehlerbehaftet ist: Nun ja.

Das Verfahren ist nicht fehlerbehaftet, sondern nur die, die es mit Daten füttern.

Zitat von kingpin42

Fritzboxen haben bis zu einer bestimmten FW-Version z.B. gleichzeitig versucht, via SLAAC und DHCPv6 eine Adresse zu beziehen.

Also die FB/AVM unterstützen seit 2011 IPv6. Da gab es, glaube ich, eigentlich noch keinen großen Provider, der auch nur über IPv6 nachgedacht hat. Daher hatten sie erst einmal beides eingebaut.

Als es dann konkreter wurde, haben sie laut IPv6_Technical_Note_de.pdf aus 2019 dieses umgestellt, dies müsse so mit Firmware 6.80, spätestens 7.10 gewesen sein. Wer dies noch nicht auf seiner FB hat, hat andere Probleme, IPS-eigene FB werden bestimmt richtig eingestellt sein.

Zitat von frank_m

Oh, dann schau dich mal im Telekom Hilft Forum um, wie viele da exakt das gleiche Problem haben.

Es mag ja sein, dass die Anbieter von den Rechteinhabern gegängelt werden. Die Frage ist, inwieweit sich das mit EU Recht vereinen lässt. Wie dem auch sei: Durch den Trend zu CGNAT ist das Verfahren einfach obsolet. Wenn sie auf die Position ihrer Kunden angewiesen sind, dann müssen sie ein Verfahren entwickeln, die zuverlässig herauszufinden. Mittels Geo-IP wird es nicht funktionieren, denn genau dieses Verfahren kann dann ja auch dazu führen, dass Inhalte im falschen Land wiedergegeben werden können. Damit bringen sich die Anbieter nur selbst in Bedrängnis.

Das Problem taucht ja, je nach Anbieter, nicht auf, wenn die IP innerhalb der EU sind. So wie hier beschrieben ist die IP noch in afrikanischen Raum hinterlegt und dies ist dann vollkommen rechtens den Nutzer zu sperren.
Und eins sei gesagt. Man muss das Streaming ja nicht nutzen, man kann ja auch ins Kino gehen.
Ich habe gerade nachgeschaut, bei WOW und Disney+ wird sogar explizit darauf hingewiesen, dass sie mit Geo IP arbeiten. Und alles in der Welt der Technik ist fehlerbehaftet, wenn der Mensch (Verwaltung) eine Rolle spielt.

Zitat von frank_m

Die Mail von Joyn ist eine Frechheit. Die haben ein Vertragsverhältnis mit den "spezialisierten Unternehmen", aber die Internetanbieter sollen die IPs freischalten? Sie sperren die Kunden unrechtmäßig vom Zugang zu ihren Leistungen aus, das haben sie noch nicht verstanden, aber die Internetanbieter sollen aufwendig herausfinden, wer da IP Adressen falsch zuordnet und sie "freischalten lassen"? Was für eine verquere Wahrnehmung der Realität.

Kannst du ihm noch antworten? Dann schreib ihm zurück: Wenn da kein Umdenken stattfindet, dann ist bald Ende mit Joyn. Die IP Knappheit wird nämlich dazu führen, dass sie nach und nah ihre gesamte Kundschaft aussperren. Offenbar wollen sie es auf die harte Tour lernen.

Also das mit "eine Frechheit" finde ich etwas sehr übertrieben.
Joyn hat doch alles für seinen Kunden gemacht, sprich IP freigeschaltet. Dass Geo IP-Datenbanken immer hinterherhinken, ist halt so.
Anderseits sind die Streaming-Dienste extrem gegängelt durch die Produktionsfirmen. Da sind die Vertragsstrafen in Millionenhöhe, wenn sie Filme in "falsche" Länder verbreiten. Also unrechtmäßig sind solche Sperrungen ganz bestimmt nicht. Steht bestimmt in den AGB´s. Somit sind ihnen ein paar unzufriedene Kunden egal.
Bei den meisten klappt es ja, bis auf die paar Exoten bei kleinen ISP. Und da fragt man sich, ob diese kleinen ISP vielleicht ihre Hausaufgaben hinsichtlich IP-Adressverwaltung nicht optimal machen. Von Firmen wie Telekom, Vodafone, etc. hört man so etwas extrem selten.

Und ich finde gerade die Hintergrundinformationen in der Mail von Joyn für den Kunden extrem hilfreich, weil die meisten gar nicht wissen, wie solche Abläufe/Fehler zustande kommen.

Zitat von Danman

Laut Facebook rät Herr Salman den Leuten mittlerweile bei DNS:NET zu unterschreiben. Ist das nicht irgendwie geschäftsschädigend?

Das ist Hören-Sagen aus FB:

CorGoa JuLe: Ibrahim Salman hat mir auch vor ein paar Wochen auf Nachfrage mitgeteilt das Fuxx erstmal nicht ausbaut.

Zitat von frank_m

Ich hab von HE auch ein /48 Prefix bekommen. Gibt es das heute nicht mehr? Das ist einige Jahre her, dass ich die benutzt habe.

Habe mal einen Test-Tunnel angelegt. Nutze Tunnelbroker seit 2012. Ich hatte immer /64.
Gibt es da eine 2-Klassengesellschaft. Wobei ich 5 Tunnel einrichten kann.

Zitat von ConiKost

Es ist üblich, dass /56 via PD bei den gängingen Internetanbietern angeboten wird. Kann man dann bequem auf /64 aufteilen..

Ich habe meine von Tunnelbroker (Hurricane Electric Free IPv6), da gibt es nur /64 Netze, ich kann aber bis zu 5 konfigurieren. Dies funktioniert IPS unabhängig.
Man benötigt eine öffentliche IPv4-Adresse, kann auch dynamisch sein.
Konfig-Beispiele sind dann gleich mit den eigen Daten für 15 OS/Router hinterlegt. Funktioniert auch mit Fritz!Box*.

Mein ISP DNS:NET will bald IPv6 einführen. Das Unbekannte ist, in welcher Art und Umfang.

* in der FB nimmt man den Bereich dDNSzum Einrichten bei dynamischen IPv4.

Zitat von frank_m

Doch, klar. Wofür hab ich denn ein /56 Netz?

Ich habe nur /64 (18.446.744.073.709.551.616).

Da hast du /56 (4.722.366.482.869.645.213.696) ein paar mehr.

Zitat von frank_m

Was meinst du denn damit? Wo ist IPv6 beim Provider nicht richtig implementiert, und warum erzeugt das Probleme mit Wireguard?

z.B. DS-Lite ohne Port Control Protocol! Das Ubiqiti-Forum ist voll mit Problemen.

Zitat von frank_m

Setze Mobile IP nicht mit VPN gleich. Mobile IP hat erst mal nur den Zweck, dass ein Gerät unter seiner bekannten IP mobil erreichbar bleibt. Abgehend kommuniziert es im Gastnetz, nicht mit seiner Heim-IP.

Dies stimmt nur zum Teil, es kommuniziert immer auch mit dem Home Agent, das funktioniert sogar, wenn sich Änderungen des Präfixes der Heimnetze ergeben. Und er ist durch IPSec-Kommunikation Teil vom Heimnetzes. RFC 3776"Using IPsec to Protect Mobile IPv6 Signaling between Mobile Nodes and Home Agents".
Da würde ich keine VPN mehr nach Hause benötigen.

Zitat von frank_m

Das wäre mir neu, und kann ich auf meinen Endgeräten auch nicht nachvollziehen. Ich habs gerade auf einem Android Tablet ausprobiert, das hatte vor der Nutzung von Prime Video seine statische und eine temporäre Adresse, und danach genau so.

Wo hast du das beobachtet?

Mit netstat.

Hier die hübsche Ausgabe für PowerShell, in dem auch die Prozesse/Anwendungen gezeigt werden.

Get-NetTCPConnection | Where-Object state -ne Bound | Select-Object LocalAddress,LocalPort,RemoteAddress,RemotePort,State,OwningProcess, @{n="ProzessName"; e={( Get-Process -Id $_.OwningProcess).ProcessName}} | Out-GridView

Da sieht man dann die IPv6-Adressen die nur von Anwendungen (Dropbox, Google Drive etc.) genutzt werden und dann verschwinden, wenn die Prozesse gekillt werde. Alles in einem reinem v6 Netz.

Zitat von frank_m

Deshalb schrieb ich "in gewissen Grenzen" kann SLAAC DHCP ersetzen. Für ein einfaches mobiles Endgerät reicht es. Aber auch im Heimnetz werden viele Informationen zu DNS auch so schon per DHCPv6 ausgetauscht, und spätestens bei Prefix Delegation ist man mit SLAAC raus.

An der Stelle sind wir aber nicht mehr im Heimnetz. Dies mit Prefix Delegation ist ja die Weitergabe-Methode zur Konfiguration für einen nachgelagerten Router.

Insgesamt ist aber gerade dieser Bereich für DNS bei IPv6 heiß diskutiert.

Die Unterstützung für die automatische DNS-Konfiguration in IPv6 wurde am Ende zum Gegenstand einer erbitterten Auseinandersetzung in bestimmten Kreisen der Internet Engineering Task Force zwischen Befürwortern von SLAAC und DHCPv6. Die SLAAC-Anhänger (zum Beispiel Googles Android) weigerten sich, DHCPv6 zu implementieren, während sich die DHCPv6-Anhänger (zum Beispiel Microsoft) weigerten, die DNS-Optionen von SLAAC zu implementieren.

Der Streit wirkte sich nicht nur auf Host-Implementierungen aus, sondern betraf ebenso Router- und Serverimplementierungen. Beispielsweise implementieren einige Router SLAAC, setzen die DNS-bezogenen Optionen für SLAAC aber nicht um. Ähnlich verzichten einige Netzwerkgeräte, die Informationen zur Netzwerkkonfiguration liefern sollen, auf die Implementierung von DHCPv6 – selbst die grundlegende DHCPv6-Serverfunktionalität fehlt, die es ihnen erlauben würde, DNS-bezogene Informationen via DHCPv6 zu übermitteln.

Insgesamt sollten wir das Thema hier beerdigen, passt nicht so ganz wie @alfalfa schon feststellte zum Thema und geht wohl über die meisten Heimkonfigurationen hinaus.

Zitat von trunkzs

Puuh, der Kabenkanal geht einmal Quer vom Keller bis in die 4te Etage und endet an sich auf dem Dachboden

Welchen Anschluss bräuchte ich denn dann genau ? LC/APC auf LC/APC ?

Na ja, ich dachte nur an den Teil in der Wohnung oben ab Wohnungstür ohne ein neues Kabel.
Ganz wichtig, wenn du die Steckverbindung löst in der Box, um das Kabel zu verlegen, unbedingt eine Staubschutzkappe aufsetzen. Da sind Glasfaserkabel grundsätzlich zickig.

Insgesamt war meine Aussage in Richtung Admin eines IPS gemeint, nicht zu Hause.
Ich fand NAT nie kompliziert, schon meine erste DSL-Leitung vor 30 Jahren kam mit NAT. Vorher SLIP über Modem und ISDN-Card.

Zitat von frank_m

Nur weil es optionale Zusatzfeatures gibt, die aktuell praktisch keine Relevanz haben, weil es einfach keine Anwendungsfälle dafür gibt, kann man ebenfalls keinen Nachteil von IPv6 argumentieren. Niemand muss Mobile IP aufsetzen, weil es aktuell niemand vermisst. Das kann man in Ruhe machen, wenn alles andere funktioniert.

Übrigens: In modernen Mobilfunknetzen funktioniert es für das Mobility Management schon sehr gut. So gut, dass es niemand bemerkt.

Ich glaube schon, dass der Bedarf dabei sehr hoch ist. Warum geht es überall aktuelle um Wiregard etc. und die Probleme, weil IPv6 nicht richtig implementiert ist beim Provider.
Aber dies würde ja den ganzen VPN-Anbieter ihr Geschäft verhageln, wenn einfach so ein Gerät von ausserhalb geschützt ins heimische/firmen Netz kommt.

Zitat von frank_m

Neighbor Discovery ersetzt nicht DHCP, sondern ARP. SLAAC kann DHCP in gewissen Grenzen ersetzen, aber eigentlich sollte man sagen: ergänzen.

Doch Ich benötige in einem IPv6 Netz kein DHCP, neue Geräte bekommen alle notwendigen Daten über das ND-Protokoll, um sich ins Netz einzubringen und den nächsten Router zu nutzen, wenn er IPv6 kann.

Zitat von frank_m

Man spürt momentan eine hohe Skepsis gegenüber IPv6. Ein Großteil dieser Skepsis ist auf so - sorry - Panik-Beiträgen wie diesen zurückzuführen, die jeder technischen Grundlage entbehren. Und steht es erst mal in einem Forum, dann wird es zigfach gelesen, und es gibt tatsächlich Leute, die das auch noch glauben. Wo könnten wir heute sein, wenn es so einen Unsinn nicht gäbe?

Ich bin damit jetzt mit dem Thema seit 10 Jahren beschäftigt und nutze, weil zu Hause noch nie IPv6 bekommen habe, dort den Tunnelbroker (HE). Ich bin voll Pro IPv6.
Ich verstehe aber schon Admin bei ISP, nachdem ich @work reine IPv6 - Netze betrieben habe.
Eins konnten wir durch Messungen feststellen, dass IPv6 durch die großen Dienstanbieter stark bevorzugt wird, der Verbindungsaufbau ist dabei zu Google etc. deutlich schneller. Ein Android-Handy versucht immer erstmal IPv6, es seiden man schaltet es explizit ab.

Zitat von frank_m

Der Stapel von IP-Adressen wird durch Privacy Extensions erzeugt, nicht durch die Apps. Und der Router hat damit gar nichts zu tun, denn diese Adressen sind explizit nicht dafür vorgesehen, Gegenstand von Firewall Regeln zu sein. Wenn Geräte Portöffnungen in der Firewall brauchen, dann macht man das auf den statischen Host-IDs, also z.B. denen per EUI-64 zugewiesenen, aber nicht auf temporären Adressen.

Das habe ich wohl nicht genau beschrieben, du hast da die Sache von einer anderen Seite betrachtet.
Ja, die Adressen werden meist durch Privacy Extensions erzeugt. Aber die Anforderung nach einer IPv6 Adresse kommt von den Anwendungen selber, wenn man sich z.B. mit Google Foto verbindet oder mit Amazon Prime Video. Jeder bekommt eine eigene IP. Woher soll die Funktion PE im Netzkartentreiber selber wissen, welcher Anwendung er eine neue Adresse zuweisen soll? Letztendlich ist es eine Vereinfachung gegenüber der Vergabe von Portadressen in IPv4 für ausgehenden Verkehr.

Und das Problem ist dann zum Beispiel für die FW, wenn sie AD- oder Kids-Filter sinnvoll einsetzen soll.
Schau mal warum es diese Art von Filterung bei den Herstellern in den FW eigentlich nur für IPv4 angeboten wird.
Die Port-Öffnungen für eingehenden Verkehr habe ich gar nicht gemeint/betrachte.
Server-Dienste erhalten grundsätzlich statische Adressen bei mir, um sie in der FW zu nutzen.