Sollte man ULAs bei der FB besser enablen oder disablen?

[framp]

Wenn ich das richtig verstanden habe bedeutet die Nutzung von ULAs im lokalen Netz dass die FB NAT66 machen muss, dadurch keine direkte IPv6 Verbindung zum Server möglich ist und das gewisse Performanceeinbussen bedeutet.

Ist das richtig? Und wie kann ich unter Linux prüfen ob NAT66 von der FB gemacht wird?

Ich habe gelesen dass

traceroute -6 heise.de

dazu genutzt werden kann. Wenn die erste Hop IP eine ULA ist ist NAT66 im Spiel. Allerdings bekomme ich da immer GUAs zu sehen, egal ob ich ULAs bei der FB aktiviert oder deaktiviert habe

 

[Barungar]

Wenn ich das richtig verstanden habe bedeutet die Nutzung von ULAs im lokalen Netz dass die FB NAT66 machen muss

Nein, heißt es nicht und macht sie auch nicht. ULA sind sowas wie die "privaten IPv4"-Adressen in Deinem LAN.

Also z.B. 192.168.178.10 .... die ULA bleibt "stabil". Denn Deine IPv6-Adresse ändert sich jedes mal, wenn Du ein neues Präfix von Deinem Provider bekommst, genauso wie sich jedes mal Deine öffentliche IPv4 dann ändert.

Und es gibt halt Leute, die es uncool finden, wenn das heimische NAS jeden Tag intern unter einer anderen IPv6 erreichbar bist.
So kannst Du z.B. inden Dein NAS dann über die ULA ansprechen und das ist jeden Tag die gleiche.

NAT im IPv6 wird nicht (im Standard) gemacht. Das muss schon ein ganz besonderer und exotischer Fall sein, dass jemand dann sowas freiwillig macht.

Sieht es so...
Die GA Deines NAS ist seine öffentliche IPv6, die ändert sich.
Die ULA Deines NAS ist seine stabile IPv6 im Heimnetz, die kann im ganzen Heimnetz auch zwischen VLANs geroutet werden.
Die LLA Deines NAS ist seine stabile linklokale IPv6 im Heimnetz, die wird aber nur im gleichen Layer 2 Segment genutzt.

 

[framp]

Danke für die Erklärung. Ich habe dummerweise die Quelle vergessen zu nennen. Ist aus dem elektronik-kompendium

Unique-Local Scope: Unique-Local IPv6 Addresses (ULA)​

Für private lokale Netze gibt es in IPv6 reservierte Adressbereiche (Unique Local Adressses, ULA). Sie haben eine ähnliche Funktion, wie die privaten Adressen von IPv4. Im Vergleich zu privaten IPv4-Adressen sind sie meist sogar global eindeutig.
Mit ihnen hat man allerdings auch die selben Probleme wie bei IPv4. Um mit diesen Adressen global kommunizieren zu können benötigt man NAT66. NAT erzeugt, bevor ein Datenpaket ins Internet geroutet wird, im Datenpaket eine globale IPv6-Absender-Adresse
Es gilt die Empfehlung mit Unique Local Addresses (ULAs) gar nicht erst zu arbeiten. Eine Ausnahme ist in einem Management-Netz, bei dem man durch Renumbering den Zugriff verlieren würde. Hier machen ULAs ausnahmsweise Sinn.

D.h. also die Aussage ist falsch oder habe ich was nicht ganz richtig verstanden?

 

[framp]

Sieht es so...
Die GA Deines NAS ist seine öffentliche IPv6, die ändert sich.
Die ULA Deines NAS ist seine stabile IPv6 im Heimnetz, die kann im ganzen Heimnetz auch zwischen VLANs geroutet werden.
Die LLA Deines NAS ist seine stabile linklokale IPv6 im Heimnetz, die wird aber nur im gleichen Layer 2 Segment genutzt.

So war auch mein Verständnis - bis ich Obiges gelesen habe.

Allerdings ist mein Verständnis, dass die LLA im Netz mehrere Male auftreten kann und somit nicht eindeutig ist. Das würde konkret bedeuten, dass die LLA meines pi-holes nicht eindeutig ist und ich eine ULA nutzen muss. Und dort ist nach obiger Aussage ein NAT66 notwendig

 

[the other]

Moinsen,
nö, der Aussage würde ich so nicht zustimmen wollen, eben aus Gründen, die @Barungar oben erklärt hat.
Ich habe hier unbedingt ULAs im EInsatz, da auch VLANs und ich eben nicht will, dass Geräte a) nur im eigenen Subnetz kommunizieren (LLA) oder nicht immer dieselbe (GUA, dynamisches Präfix) IP bekommen. Deswegen ULA. Da wird auch nix übersetzt, da die Geräte (bei aktiver ULA Vergabe) mind. 3 IPv6 haben (GUA, ULA, LLA). Das ist auch ok.
Wenn deine Geräte also korrekt für und mit v6 eingerichtet sind, dann haben die (ohne NAT und Co) eine global gültige IPv6.

 

[framp]

oder nicht immer dieselbe (GUA, dynamisches Präfix) IP bekommen.

Ach so. Ohne ULA wird die GUA des Clients immer fest sein - vermutlich Praefix mit LLA zusammengesetzt. Werde ich noch mal nachlesen. Das will ich natürlich auch haben. Mich stört eben nur dieses angebliche NAT66.

 

[blurrrr]

Mahlzeit!

Wenn ich das richtig verstanden habe bedeutet die Nutzung von ULAs im lokalen Netz dass die FB NAT66 machen muss

Du meinst evtl. NPTv6 (nur Präfix-Änderung)? GUA ist doch vorhanden, also braucht da auch nichts bzgl. NAT im Spiel zu sein ("kann" ist nochmal ein ganz anderes Thema, aber sicherlich nicht "muss"). Wenn Du eine GUA und eine ULA hast und das Ziel über "beides" zu erreichen ist, sollte eigentlich die ULA bevorzugt werden. Ansonsten sollte es über die GUA laufen.

Mal so generell: RFC6724 ( Default Address Selection for Internet Protocol Version 6 (IPv6)), da hast Du unter 10.1 Default Source Address Selection auch nochmal ein paar Beispiele.

Es hilft vielleicht auch, wenn man sich - analog zu IPv4 - einfach mal ein paar IPv4-Adressen dazu denkt:

GUA = <öffentliche IPv4>
ULA = RFC1918 (192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8)
LLA = RFC3927 (169.254.0.0/16)

Daher auch die "Scopes".

Das würde konkret bedeuten, dass die LLA meines pi-holes nicht eindeutig ist

Die LLA wird eigentlich schon "nach Muster" erstellt (EUI-64, anhand der MAC). Eine ULA kannst Du aber auch einfach selbst angeben und diese dann dem Client zuweisen (so habe ich das hier gemacht, aber dann halt aus dem Bereich "fd" (lokal erzeugt)).

 

[the other]

Moinsen,
nein, da irrst du (oder ich verstehe dich falsch):
die GUA wird im ersten Teil aus dem Präfix gebildet. Diese stellt dir dein ISP zur Verfügung. Nun ist es aber so (wie bei den öffentlichen IPv4 vom ISP auch), dass diese meist nicht fest sind, sondern dynamisch.
Für IPv4 nicht soo schlimm (DDNS auf den Router, gut ist), denn im LAN sind ja die eigenen IPv4 (daher auch die NAT Notwendigkeit) aus dem privaten Adressraum, also auch fest (wenn so eingerichtet).

IPv6 GUA (die global gültigen) haben aber nun diesen ersten (meist, fest kostet extra > Business Anschluss) dynamischen Teil.
Es ist also daher doof, den Geräten, die über Netzwerke hinweg kommunizieren sollen, nur diese eine GUA zu geben. Warum? Angenommen dein NAS ist so erreichbar...dann ändert der ISP das dynamische Präfix...und weg ist das NAS.
Also muss da was her was fest ist...daher eben die ULA (wenn zB VLANs) oder oft einfach die LLA (innerhalb eines LANs ohne Subnetze). Natürlich wird ein verändertes Präfix auch mitgeteilt an alle clients...aber eben nicht innerhalb von zB Firewallregeln oder auch lokalen DNS Einträgen...es braucht am Ende was Festes zur Eindeutigkeit im Netzwerk.

Meine Geräte haben daher (zumindest die, deren VLAN v6 bedient) je eine IPv6, GUA, ULA, LLA. Die Geräte hätten sogar noch mehr, da es zusätzlich auch randomized IPv6 Adressen gibt (der hintere host Teil ist dann zufällig). Das habe ich aber aus Gründen deaktiviert.
edit: ja, die ULA habe ich hier auch zT selbst kreiert...vorderen Teil per Zufallsgenerator, dann die Subnetz ID und schließlich (vom client erstellt) der host Teil der v6.

Insgesamt: immer noch schwierig mit v6...zB Thema dhcp Server. Nicht so easy. Dann die unterschiedlichen Umsetzungen, die einen können kein dhcpv6, die anderen kein SLAAC...das Festlegen von Firewallregeln erfordert eben immer ein Umdenken. Einfacher wäre alles definitiv, gäbe es einfach so kostenfrei feste IPv6 GUAs...aber wir sind bekanntlich nicht bei "Wünsch dir was" oder "Das macht ja sogar Sinn!"...

 

[the other]

Moinsen,
hier:

inet 172.16.5.10/24 brd 172.16.5.255 scope global dynamic noprefixroute enp3s0
       valid_lft 6449sec preferred_lft 6449sec
    inet6 2003:cX:XXX:XXX5:7656:3cff:fYYY:YY3/64 scope global dynamic noprefixroute
       valid_lft 85973sec preferred_lft 13973sec
    inet6 fdXX:3XXX:cXX:5:7656:3cff:fYYY:YY3/64 scope global dynamic noprefixroute
       valid_lft 85973sec preferred_lft 13973sec
    inet6 fe80::7656:3cff:fYYY:YY3/64 scope link noprefixroute
       valid_lft forever preferred_lft forever

So bei meinem PC. Hier siehst du den dynamischen Teil der GUA mit 2003:cX:XXX:XXX gefolgt von einer 5 (meine Subnetz ID da im VLAN 5). Dahinter dann den host Teil mit 7656:3cff:fYYY:YY3 alle sind einem /64er Netz (mein ISP gibt mir ein /56, das wird dann unterteilt durch FB und pfsense).
Und schau an, der host Anteil für die ULA (fdXX:3XXX:cXX:5:7656:3cff:fYYY:YY3) und LLA ist identisch mit je 7656:3cff:fYYY:YY3...die ULA enthält ebenfalls die Subnetz ID (5), die LLA dagegen nicht...weil solche Adressen ja auch eh nicht über Netzwerke hinweg routbar sind.

 

[framp]

Du meinst evtl. NPTv6 (nur Präfix-Änderung)?

NPTv6
(Network Prefix Translation) und NAT66 sind Technologien, die IPv6-Netzwerkpräfixe übersetzen, oft um interne ULA-Adressen (Unique Local Addresses) in globale Adressen (GRA) für den Internetzugang zu wandeln. Während NPTv6 (oft als Synonym für NAT66 verwendet) zustandslos arbeitet und nur das Präfix ändert, können NAT66-Implementierungen auch statisch sein. Sie schützen die Intranet-Privatsphäre, ermöglichen einen Wechsel des Internetdienstanbieters (ISP) ohne Neukonfiguration des internen Netzes und erfordern in der Regel ein /64-Präfix.

Darunter versteht man oberflächlich gesehen das gleiche.

Es hilft vielleicht auch, wenn man sich - analog zu IPv4 - einfach mal ein paar IPv4-Adressen dazu denkt:

GUA = <öffentliche IPv4>
ULA = RFC1918 (192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8)
LLA = RFC3927 (169.254.0.0/16)

Fast genau das Mapping habe ich im Hinterkopf. Ich vergass nur das 169er Netz. Der direkte Vergleich mit den bekannten IPv4 IPs hilft sehr.

Die LLA wird eigentlich schon "nach Muster" erstellt (EUI-64, anhand der MAC). Eine ULA kannst Du aber auch einfach selbst angeben und diese dann dem Client zuweisen (so habe ich das hier gemacht, aber dann halt aus dem Bereich "fd" (lokal erzeugt)).

Es gibt ja auch EU64 Kalkulatoren. Habe das mal ausprobiert - aber bislang keinen Erfolg gehabt. Muss ich noch mal etwas nachlesen

eben die ULA (wenn zB VLANs) oder oft einfach die LLA (innerhalb eines LANs ohne Subnetze).

Ich habe keine VLANs und demnach bräuchte ich doch keine ULA. Oder ... in der Fritte habe ich die ULA des pi-hole angegeben die an alle Clients per RA verteilt wird. Sollte die RPi sterben und ich muss eine neue RPi mit dem OS Backup einsetzen - wird sich die LLA ändern, die ULA aber wohl nicht?

Die Geräte hätten sogar noch mehr, da es zusätzlich auch randomized IPv6 Adressen gibt (der hintere host Teil ist dann zufällig). Das habe ich aber aus Gründen deaktiviert.

Meinst Du da die privacy Extensions?

Und schau an, der host Anteil für die ULA (fdXX:3XXX:cXX:5:7656:3cff:fYYY:YY3) und LLA ist identisch mit je 7656:3cff:fYYY:YY3...d

    inet6 2001:x9ex:x9ax:6600:54de:956:80f2:7deb/64 scope global temporary dynamic
       valid_lft 7143sec preferred_lft 3543sec
    inet6 2001:x9ex:x9ax:6600:e61b:1cca:8752:f501/64 scope global dynamic mngtmpaddr noprefixroute
       valid_lft 7143sec preferred_lft 3543sec
    inet6 fd00::1e75:49be:c713:e8c5/64 scope global temporary dynamic
       valid_lft 7143sec preferred_lft 3543sec
    inet6 fd00::5a62:6ba9:af5b:99e/64 scope global dynamic mngtmpaddr noprefixroute
       valid_lft 7143sec preferred_lft 3543sec
    inet6 fe80::e4e7:4243:f8e3:3dec/64 scope link noprefixroute
       valid_lft forever preferred_lft forever

Bei mir nicht

Interessanterweise habe ich angeregt durch unsere Diskussion herausgefunden, dass die Privacyextensions bei Linux Mint und auch Raspberry Pi OS ausgeschaltet sind. Ich hatte immer nur eine GUA. Nachdem ich sie explizit im nmcli eingeschaltet habe sind es zwei geworden. "dynamic mngtmpaddr" weist darauf hin.

 

[the other]

Moinsen,

Sollte die RPi sterben und ich muss eine neue RPi mit dem OS Backup einsetzen - wird sich die LLA ändern, die ULA aber wohl nicht?

Wenn du die über den Router vergisst, dann mappst du diese einfach auf die neue MAC des 2. Raspi. Wäre meine Idee.
Wenn du alles fest am client einstellst, dann eben die ULA am neuen Raspi einpflegen. Das ist dann analog IPv4. Ich habe den vorderen Teil per ula Zufallsgenerator erstellt > zB https://unique-local-ipv6.com/. Den hinteren host Teil bauen bei mir die Clients selber. Ja, das ist nicht schön, aber hier läuft im Alltag alles meist über URL oder hostname und / oder Browserbookmarks. Und mit der Zeit merkt mensch sich das auch grob...

Meinst Du da die privacy Extensions?

Ja.
Ich habe die hier ausgestellt für den PC (bei den Androids geht das afaik nicht so eben) und fürs NAS. Zum einen finde ich, dass das eine falsche Umsetzung von Datenschutz ist, zum anderen nervt auch das bei manchen Verbindungen und Firewallregeln. So kommt es zb vor, dass statt mit der festen eigenen ULA dann mit der temorary dynamic ULA die Verbindung versucht wird, dafür aber natürlich keine Allow Regel vorliegt und damit dann doof. Also: die PEs deaktiviert und gut. Müssen aber natürlich alle je für sich entscheiden.

 

[framp]

Wenn du alles fest am client einstellst, dann eben die ULA am neuen Raspi einpflegen.

Raspis sind bei mir Server und die konfiguriere ich manuell auch am pi-hole vorbei.

Aber irgendwo hatte ich gelesen dass ein Vorteil der ULA wäre, dass man ein Gerät austauschen kann ohne jedwede Änderung. Aber da habe ich wohl irgendwas falsch verstanden. Ist im Moment sehr viel was in meinen Schädel zu IPv6 reinkommt und manches muss ich aus dem mittlerweile größer werdendem Wissen dank Euch noch einmal gelesen und dann auch richtig verstanden werden.

PE
...
nervt auch das bei manchen Verbindungen und Firewallregeln

Dachte ich mir schon. Habe gelesen dass manche Server das nicht gut finden wenn die IP ständig wechselt. Auch mit den FW Regeln. Ich hoffe die FB kommt damit klar dass keiner Inbound auf meine Systeme kommen kann Bislang habe ich noch keine Probleme feststellen können. Allerdings sind auch die PEs noch nicht lange aktiv. Vermutlich wird auch oft doch per IPv4 mit Servern kommuniziert so dass das nicht auffällt.

 

[blurrrr]

die ULA aber wohl nicht?

Wenn Du einem Host eine statische private IPv4 gibst und dann den Host wechselst und dem neuen Host wieder die gleiche statische IPv4 zuweist, wird sich da auch nichts dran ändern.

Ich habe keine VLANs und demnach bräuchte ich doch keine ULA.

Münz die Aussage mal um auf IPv4: "Ich habe keine VLANs und demnach bräuchte ich doch keine 192.168....". Das ist ja eigentlich auch das schöne - übersetz es einfach 1:1 auf IPv4, da klären sich dann i.d.R. schon viele Dinge.

Aber irgendwo hatte ich gelesen dass ein Vorteil der ULA wäre, dass man ein Gerät austauschen kann ohne jedwede Änderung. Aber da habe ich wohl irgendwas falsch verstanden

Eigentlich ein klares "s.o." - wie würde es sich bei einer privaten statischen IPv4 verhalten? Der "Kurs" ist halt die "statische" ULA und diese kannst Du bei einem Systemwechsel halt auch wieder nutzen, so wie eben bei IPv4 auch.

Ich hoffe die FB kommt damit klar dass keiner Inbound auf meine Systeme kommen kann

Solange Du da keine Freigaben machst, würde es erstmal eine initiierende Verbindung von innen nach aussen benötigen. Also alles beim alten

 

[framp]

Eben habe ich noch mal in mein pi-hole reingesehen und der Anteil von AAAA Queries ist gestiegen. Genau kann ich es nicht sagen um wieviel, da ich erst jetzt gesehen habe, dass beim Hoovern die exakten % Anteile des PiCharts angezeigt werden. Aber ich denke er hat sich von ca 20% auf knapp 40% erhöht. A % sind knapp 50%.

 

[framp]

Der "Kurs" ist halt die "statische" ULA und diese kannst Du bei einem Systemwechsel halt auch wieder nutzen, so wie eben bei IPv4 auch.

Ah ... ja ... die ULA habe ich nicht statisch definiert. Die wurde irgendwie generiert. D.h. die müßte ich auch noch statisch auf dem pi-hole definieren. Guter Tipp

Solange Du da keine Freigaben machst, würde es erstmal eine initiierende Verbindung von innen nach aussen benötigen. Also alles beim alten

Hm ... verstehe ich nicht. Wenn ein Server bei mir eine GUA hat könnte doch jemand, sofern er die kennt, z.B. versuchen per ssh drauf zuzugreifen. Klar sind IP Scans bei IPv6 sehr ineffizient wg der hohen Anzahl der möglichen IPv6, aber prinzipiell ist es doch möglich. Bei meinen Servern bringt es allerdings trotzdem nichts, dess Login geht nur mit keys

 

[blurrrr]

Hm ... verstehe ich nicht. Wenn ein Server bei mir eine GUA hat könnte doch jemand, sofern er die kennt, z.B. versuchen per ssh drauf zuzugreifen

Wie kommst Du auf diese Idee? Die Fritz!Box macht bei Portweiterleitungen 2 (!) Dinge:
1) DNAT (Destination-NAT - wenn an WAN-Adresse Port X was eingeht, leite weiter nach interner Host Port Y)
2) Firewall!

NAT fällt bei den GUAs halt raus, aber die Firewall-Geschichte bleibt bestehen. Ich sage daher auch gerne mal Port"weiterleitung" und Port"freigabe". Die Firewall der Fritz!Box hält nach wie vor alles draussen, was nicht rein soll. Erst wenn Du eine entsprechende (Firewall-)Freigabe erstellst, können die Pakete auch durch. Erstellst Du keine entsprechende Freigabe, können auch keine (initialen) Pakete durch

 

[framp]

Erst wenn Du eine entsprechende (Firewall-)Freigabe erstellst, können die Pakete auch durch.

Jupp. D.h. mein OpenVPN Server ist z.B. per IPv6 erreichbar, da der Port per IPv4 und IPv6 offen ist. Bei Clients ohne Portfreigabe blocked die FW. Irgendwie hatte ich noch die Portweiterleitung von IPv4 im Hinterkopf die es bei GUAs ja nicht gibt.