Deutsche Glasfaser IPv6 mit FritzBox 7590 und Erreichbarkeit des internen Servers über Port 30000

Unter macos (gestestet mit 15.5) kann man die IPv6 auch manuell setzen, dann verschwinden allerdings die privacy extension Adressen sofort, und ich habe nicht getestet was bei einem Praefix-Wechsel passiert.

Zitat von mbo77

Hä? Tieferer Sinn?

Tja, ich habe auch nur gestaunt. Leider kann ich den Hinweistext des Popups in den NAS-Logs nicht mehr finden, um den genauen Wortlaut wiederzugeben. In den Release Notes der Firmware heißt es zu den IPv6-Änderungen - Zitat:

Network & Virtual Switch

• Optimized the user interface for configuring interfaces, virtual switches, VLAN, WiFi, and IPv4 and IPv6 settings. The IPv4 and IPv6 configuration pages now include DNS settings.
• When configuring the IPv6 connection type with "Auto-Configuration (Stateless)", users can now select "Generate a SLAAC address with a secret key" for a more secure way to generate the IPv6 address.

Die Erwähnung eines "secret key" deute ich als Hinweis, dass man die Generierung von IPv6-IIDs für temporary addresses (privacy extensions) RFC8981 implementiert hat. Einen nahezu identischen Algorithmus mit einem "secret key" enthält auch RFC7217 für die Generierung von stable IIDs, aber das hat man offenbar nicht gemeint bzw. implementiert.

Nur die Interface-ID kann man unter macos nicht statisch setzen? Muss es immer die ganze Adresse sein?

Die Meldung des NAS finde ich auch ... grenzwertig.

In der GUI kann man nur die ganze IPv6 Adresse manipulieren. Ob das Praefix beim Renumbering automatisch angepasst wird habe ich nicht ausprobiert, der Rest meiner Familie ist kein Fan von vermeidbaren Netzwerkunterbrechungen waehrend des WEs

Persoenlich bin ich kein Fan von RFC7217 zumindest nicht im Kontext von Heimnetzwerken mit haeufigem Prefix-Wechsel, aber vielleicht ist mir nur nicht klar welches Bedrohungsmodell dem RFC zugrunde liegt.

Zitat von pufferueberlauf

Persoenlich bin ich kein Fan von RFC7217 zumindest nicht im Kontext von Heimnetzwerken mit haeufigem Prefix-Wechsel, aber vielleicht ist mir nur nicht klar welches Bedrohungsmodell dem RFC zugrunde liegt.

Nunja, das bescheibt die "Introduction" von RFC7217 doch ziemlich ausführlich:

Wichtigste Passage daraus:

   In scenarios in which temporary addresses are deliberately not used
   (possibly for any of the aforementioned reasons), all a host is left
   with is the stable addresses that have typically been generated from
   the underlying hardware addresses.  In such scenarios, it may still
   be desirable to have addresses that mitigate address-scanning attacks
   and that, at the very least, do not reveal the host's identity when
   roaming from one network to another -- without complicating the
   operation of the corresponding networks.

Sinngemaß: Dort, wo man IPv6 privacy extensions bei einer Konfiguration mit SLAAC aus vorgenannten Gründen nicht nutzen möchte, will man nun halt ersatzweise die Privacy von "stable addresses" verbessern bzw. "address-scanning attacks" erschweren.

Aber auch, wenn IPv6 privacy extensions weiterhin verwendet werden, sieht man folgenden Verbesserungsbedarf für die parallel vorhandenen "stable addresses":

   However, even with temporary addresses in place, a number of issues
   remain to be mitigated.  Namely,

   o  since temporary addresses [RFC4941] do not eliminate the use of
      fixed identifiers for server-like functions, they only partially
      mitigate host-tracking and activity correlation across networks
      (see [ADDR-GEN-PRIVACY] for some example attacks that are still
      possible with temporary addresses).

   o  since temporary addresses [RFC4941] do not replace the traditional
      SLAAC addresses, an attacker can still leverage patterns in SLAAC
      addresses to greatly reduce the search space for "alive" nodes
      [GONT-DEEPSEC2011] [CPNI-IPV6] [IPV6-RECON].
      
   Hence, there is a motivation to improve the properties of "stable"
   addresses regardless of whether or not temporary addresses are
   employed.

Ich war wohl zu subtil und vorsichtig, ich bin kein Fan von RFC7217 weil ich nicht glaube, dass es richtige Problem loest...

Zitat

since temporary addresses [RFC4941] do not eliminate the use of fixed identifiers for server-like functions, they only partially mitigate host-tracking and activity correlation across networks

Das ist fuer den Fall um den es hier geht ein "stabiles" Netz mit haeufig wechselndem Prefix halt nicht die richtige Loesung... die Grundannahme ist, wenn das Prefix wechselt, wechselt das Netz und das macht in Heimnetzen halt fuer Serverdienste nur wenig Sinn.

Was die IETF damit foerdert ist dass Endnutzer GUAs ignorieren, lokal mit stabilen ULAs arbeiten und diese dann mit NET66 mit dem jeweils aktivem Prefix versehen... Aber gerade bei den IPv6 RFC sehe schon mal Bike-Shedding und Versuche Nutzer umzuerziehen.

Zitat von pufferueberlauf

Das ist fuer den Fall um den es hier geht ein "stabiles" Netz mit haeufig wechselndem Prefix halt nicht die richtige Loesung... die Grundannahme ist, wenn das Prefix wechselt, wechselt das Netz und das macht in Heimnetzen halt fier Serverdienste nur wenig Sinn.

Das sehe ich auch so.

Zitat von pufferueberlauf

Was die IETF damit foerdert ist dass Endnutzer GUAs ignorieren, lokal mit stabilen ULAs arbeiten und diese dann mit NET66 mit dem jeweils aktivem Prefix versehen... Aber gerade bei den IPv6 RFC sehe schon mal Bike-Shedding und versuch Nutzer umzuerziehen.

Das sehe ich nicht so. Ich unterstelle der IETF keine (durch welche Zielvorstellungen auch immer begründete) Agenda, mit der sie "Nutzer umerziehen" will. Schon gar nicht die Idee, ULA am CPE-Router via NPTv6 (RFC6296, falls du das mit "NET66" gemeint hast) auf GUA zu übersetzen. Btw.: Die Bedeutung des mir bisher unbekannten Begriffs "Bike-Shedding" musste ich erst mal nachlesen, danke für das Schließen dieser meiner Bildungslücke.

Ich sehe die Summe aller RFC als riesigen Baustein-Kasten, aus dem man sich bedienen kann, um für die Anwendung sinnvolle und standardisierte Lösungen zu bauen. Es liegt, wie auch schon von HubeBube festgestellt, also vor allem an den Implementierern von IPv6 in die jeweiligen Betriebssysteme, um für ein darunter betriebenes System/Gerät sinnvolle Konfigurationsoptionen zu ermöglichen.

Bezüglich IPv6-Konfiguration per SLAAC sollte es für den Nutzer eines Gerätes also idealerweise folgende Einstell-Möglichkeiten geben, weil nur der Nutzer (bzw. dessen Netz-Admin) am besten weiß, wofür er das Gerät benutzen will:

• Es sollen nur temporäre IPv6-Adressen (IPv6 privacy extensions) gemäß RFC8981 verwendet werden, weil das Gerät keine Services anbietet, also ausschließlich als Client genutzt wird. Eine permanente/stable IPv6-Adresse wird nicht benötigt. Zielgruppe: Vor allem mobile, drahtlose Endgeräte, die sich zu wechselnden WLANs verbinden.
• Man möchte ausschließlich oder zusätzlich zu temporären Adressen auch permanente/stable IPv6-Adressen verwenden (muss einstellbar sein), weil das Endgerät auch (bzw. hauptsächlich) Services anbietet. Hier sollte man dann wählen können, welche Methode zu ihrer Generierung zum Einsatz kommen soll: Man sollte die moderne Methode gemäß RFC7217 wählen können (Zielgruppe: Server in IPv6-Netz mit festem IPv6-Präfix) oder auch weiterhin auf die Ur-Methode "Modified EUI-64" (Anhang A in RFC4291) zurückgreifen können (Zielgruppe: Server in IPv6-Netz mit wechselndem ISP-Präfix).

Die Motivation, Serverdienste in SOHO-Netzen an ISP-Privatanschlüssen möglichst zu unterbinden, liegt eher bei den ISP. Denn die möchten dafür gerne ihre deutlich höherpreisigen Business-Tarife mit festem IPv6-Präfix verkaufen.

Schließlich noch zu "lokal mit stabilen ULAs arbeiten": Das nutze ich zusätzlich in meinem LAN seit eh und je, ist doch sehr sinnvoll, sich für die rein LAN-interne Kommunikation wenigsten darauf verlassen zu können, wenn der ISP mal wieder den GUA-Präfix wechselt oder ggf. auch mal gar keinen liefert (das soll bei DG ja ab und zu mal vorkommen).

Zitat von ::1

Das sehe ich nicht so. Ich unterstelle der IETF keine (durch welche Zielvorstellungen auch immer begründete) Agenda, mit der sie "Nutzer umerziehen" will. Schon gar nicht die Idee, ULA am CPE-Router via NPTv6 (RFC6296, falls du das mit "NET66" gemeint hast) auf GUA zu übersetzen. Btw.: Die Bedeutung des mir bisher unbekannten Begriffs "Bike-Shedding" musste ich erst mal nachlesen, danke für das Schließen dieser meiner Bildungslücke.

Oh, ich lese die IPv6 discussions listen der IETF (zumindest einige) Nutzer umerziehen ist da sehr wohl ein Bestreben zumindest von einigen (unter anderem dem Autor von RFC7217), manchmal aus guten Gruenden, manchmal aus weniger guten Gruenden.

Na ja, ich meint den Austausch des Prefixes per NAT, fuer mich ist das ein Spezialfall von generellem NAPT. Und nein diese Form von NAT66 ist nichts was die IETF sehen moechte, IMHO ist das eine Konsequenz daraus, dass die IETF seit Jahren einige (ihr selbst) offensichtliche IPv6 Probleme nicht ordentlich geloest hat (Hotfail zwischen verschiedenen IPv6 Uplinks, bei denen die IPv6 Routen eines ploetzlich verschwundenen Links noch lange in den Endpunkten aktiv bleiben und genutzt werden was zu Konnektibvitaetsproblemen fuehrt, NAT66 ist da eine echte Loesung wenn auch weder elegant noch im Geiste von IPv6).

Zitat von ::1

Es sollen nur temporäre IPv6-Adressen (IPv6 privacy extensions) gemäß RFC8981 verwendet werden, weil das Gerät keine Services anbietet, also ausschließlich als Client genutzt wird. Eine permanente/stable IPv6-Adresse wird nicht benötigt. Zielgruppe: Vor allem mobile, drahtlose Endgeräte, die sich zu wechselnden WLANs verbinden.

Jai, eine ULA waere schon schoen da stimmen wir ueber ein... aber hier geht es um ULAs?

Zitat von ::1

Man möchte ausschließlich oder zusätzlich zu temporären Adressen auch permanente/stable IPv6-Adressen verwenden (muss einstellbar sein), weil das Endgerät auch (bzw. hauptsächlich) Services anbietet. Hier sollte man dann wählen können, welche Methode zu ihrer Generierung zum Einsatz kommen soll: Man sollte die moderne Methode gemäß RFC7217 wählen können (Zielgruppe: Server in IPv6-Netz mit festem IPv6-Präfix) oder auch weiterhin auf die Ur-Methode "Modified EUI-64" (Anhang A in RFC4291) zurückgreifen können (Zielgruppe: Server in IPv6-Netz mit wechselndem ISP-Präfix).

Auch hier Jain...ich bin da mehr ein ein Fan von https://datatracker.ietf.org/doc/id/draft-c…ntifiers-02.txt RFC7217 und Modified EUI-64 sind IMHO beide fuer Heimnetze nicht gut geeignet.

Zitat

Die Motivation, Serverdienste in SOHO-Netzen an ISP-Privatanschlüssen möglichst zu unterbinden, liegt eher bei den ISP. Denn die möchten dafür gerne ihre deutlich höherpreisigen Business-Tarife mit festem IPv6-Präfix verkaufen.

Das werfe ich der IETF auch gar nicht vor, deren Ziel ist da echte end2end Kommunikation, also natuerlich auch das Anbieten von Diensten/Servern.

Zitat von ::1

Schließlich noch zu "lokal mit stabilen ULAs arbeiten": Das nutze ich zusätzlich in meinem LAN seit eh und je, ist doch sehr sinnvoll, sich für die rein LAN-interne Kommunikation wenigsten darauf verlassen zu können, wenn der ISP mal wieder den GUA-Präfix wechselt oder ggf. auch mal gar keinen liefert (das soll bei DG ja ab und zu mal vorkommen).

+1

Zitat von pufferueberlauf

Das ist fuer den Fall um den es hier geht ein "stabiles" Netz mit haeufig wechselndem Prefix halt nicht die richtige Loesung... die Grundannahme ist, wenn das Prefix wechselt, wechselt das Netz und das macht in Heimnetzen halt fuer Serverdienste nur wenig Sinn.

Das ist doch nicht anders als bei IPv4-Netze bei den deutschen ISP. Da trenne ja auch immer noch sehr viele täglich. Und da betreiben auch viele Server, sei es Gaming oder Tor. War natürlich nie eine Lösung für Business.

Ich sehe da kein Unterschied vom Ansatz her. Wobei ich eher zu NAT64 tendieren würde, um im privaten Umfeld etwas anzubieten.

Zitat von pufferueberlauf

Auch hier Jain...ich bin da mehr ein ein Fan von https://datatracker.ietf.org/doc/id/draft-c…ntifiers-02.txt RFC7217 und Modified EUI-64 sind IMHO beide fuer Heimnetze nicht gut geeignet.

Ah, danke. Jetzt weiß ich auch endlich, was du vormals mit "Tokenised Identifiers" meintest - den Draft kannte ich noch nicht. Stimme zu, wäre eine gute Lösung. Vielleicht wird daraus ja noch ein RFC ...

Jain, bei IPv4 ist NAT44 die Regel nicht die Ausnahme, d.h. die Firewall-Freigabe fuer interner Server-IPs und Ports bleibt unberuehrt von IP-Renumbering... Klar dynamisches DNS funktioniert sowohl bei IPv4 als auch bei IPv6, aber dann muss man jedesmal nach Prefixchange die IPv6 Freigabe fuer die Server GUA anpassen* und das ist IMHO Gruetze. Die "Loesung" die F. Gont da vorschwebt ist PCP also dem Server erlauben selber neue Loecher in die Firewall zu machen, aber IMHO ist PCP (und UPNP) eine schlechte Idee fuer IPv4 oder IPv6...

*) OpenWrt kann Freigaben anhand der IID festlegen, so dass das Prefix ignoriert wird und solche Freigaben daher Renumbering einfach ueberleben.

Ach ja, auch wenn es bisher kein RFC geworden ist, Ubuntu/Linux unterstuetzt das natuerlich:

Ubuntu Manpage: ip-token - tokenized interface identifier support

Zitat von pufferueberlauf

Na ja, ich meint den Austausch des Prefixes per NAT, fuer mich ist das ein Spezialfall von generellem NAPT. Und nein diese Form von NAT66 ist nichts was die IETF sehen moechte, IMHO ist das eine Konsequenz daraus, dass die IETF seit Jahren einige (ihr selbst) offensichtliche IPv6 Probleme nicht ordentlich geloest hat (Hotfail zwischen verschiedenen IPv6 Uplinks, bei denen die IPv6 Routen eines ploetzlich verschwundenen Links noch lange in den Endpunkten aktiv bleiben und genutzt werden was zu Konnektibvitaetsproblemen fuehrt, NAT66 ist da eine echte Loesung wenn auch weder elegant noch im Geiste von IPv6).

Du meinst hier vermutlich "IPv6 Multihoming"- das ist ja auch bei IPv4 ein Problem, mit dem Unterschied, dass NAT als Lösungsoption dort akzeptiert ist. Bei IPv6 gibt's wohl nat-freie Lösungsansätze, siehe z.B. RFC7157, habe mich damit aber noch nicht befasst, um hierzu wirklich etwas sagen zu können. Ich kenne hier nur die Mercedes-Lösung mit provider-unabhängigem IPv4/IPv6-Space in Verbindung mit BGP - aber das ist natürlich nichts für das KMU-Umfeld.

Zitat von pufferueberlauf

Das ist fuer den Fall um den es hier geht ein "stabiles" Netz mit haeufig wechselndem Prefix halt nicht die richtige Loesung... die Grundannahme ist, wenn das Prefix wechselt, wechselt das Netz und das macht in Heimnetzen halt fuer Serverdienste nur wenig Sinn.

Bei wechselndem Präfix wird eh neu nummeriert, was für einen Unterschied macht es da, wenn der Interface-Identifier dann sich auch ändert?

Discovery läuft eh über mDNS, DynDNS o. ä. und mit zufällig abbrechenden Sessions muss jeder Dienst für Privatkunden sowieso klar kommen.

Zitat von pufferueberlauf

Die "Loesung" die F. Gont da vorschwebt ist PCP also dem Server erlauben selber neue Loecher in die Firewall zu machen

Mit Zero Trust networking macht niemand "Löcher in die Firewall". Und wer noch ein anderes Modell als Zero Trust hat, hat eh viel größere Probleme.

Zitat von wandler

Bei wechselndem Präfix wird eh neu nummeriert, was für einen Unterschied macht es da, wenn der Interface-Identifier dann sich auch ändert?

Host-Einträge anhand der Interface-ID bei einem DynDNS-Anbieter und IPv6-Freigaben in der Fritzbox müssen bei Präfixwechsel nicht angepasst werden, wenn der Interface-Identifier dabei konstant bleibt. Andernfalls muss man leider beides anpassen.

Zitat von wandler

Mit Zero Trust networking macht niemand "Löcher in die Firewall". Und wer noch ein anderes Modell als Zero Trust hat, hat eh viel größere Probleme.

Zero Trust Networking ist also die Begründung, dass der Server selber entscheidet, welche Ports er öffnen will? Ich will eigentlich auf der Firewall kontrollieren, was der Server darf und das nicht dem Server überlassen.

Ansonsten viel Spaß, wenn doch mal einer den Server übernimmt und Du das nicht mitbekommst.

Zitat von wandler

Bei wechselndem Präfix wird eh neu nummeriert, was für einen Unterschied macht es da, wenn der Interface-Identifier dann sich auch ändert?

Easy, ich meine ich hatte das bereits erwaehnt, ich moechte nicht alle 224 Stunden meine Firewallregeln anpassen, und schon gleich gar nicht will Gruetze wie UPNP/PCP auf meiner Firewall aktivieren.

Zitat von wandler

Discovery läuft eh über mDNS, DynDNS o. ä. und mit zufällig abbrechenden Sessions muss jeder Dienst für Privatkunden sowieso klar kommen.

Ja, aber das ist nicht mein Problem.

Zitat von wandler

Mit Zero Trust networking macht niemand "Löcher in die Firewall". Und wer noch ein anderes Modell als Zero Trust hat, hat eh viel größere Probleme.

Mei, Dein Netz, Deine Regeln, mein Netz meine Regeln... Ich gehe nicht davon aus, dass mein Heimnetz ein sicherer Ort ist und aktiviere bei allen System die individuellen Firewalls, dennoch betreibe ich auch eine Firewall im Internetgateway... Zwiebelprinzip und so. Musst Du weder gut finden noch nachvollziehen koennen...

Zur Info und passend zum Thema:

Es ist soeben RFC9797 erschienen: "Randomized and Changing Media Access Control (MAC) Addresses: Context, Network Impacts, and Use Cases". Es behandelt unter dem Kürzel RCM (Randomized and Changing MAC addresses) das, was hier im Thread in Apple's Implementierung als "Private WLAN-Adressen" referenziert wurde und dessen Charakteristika vermutlich durch Appendix A3 des RFC abgedeckt sind.

Insbesondere behandelt Chapter 6 in Bezug auf Network Services die damit einher gehenden Probleme ("loss of device identification" bei Wechsel der MAC-Adresse).

Es geht in dem RFC allerdings _nicht_ um IPv6-Interface-IDs (IID) - bezügliche RFC (RFC7217 und RFC8981) werden zwar als Informative References benannt, im RFC-Text jedoch in einem Kontext zitiert, der nichts mit dem in diesem Thread behandelten Problem zu tun hat, nämlich dass ein stable IID laut RFC7217 vom LAN-Präfix abhängt, für das er generiert wird.

Oder anders formuliert:

RCM verschärfen das Problem mit daraus abgeleiteten stable IPv6 IIDs zwar, die Abschaltung von RCM (aka "Private WMAN-Adressen" bei Apple) löst es allein aber nicht, da es zusätzlich durch die Abhängigkeit des Generierungs-Algorithmus von stable IIDs vom LAN-Präfix (mit-) verursacht wird.