Sollte man ULAs bei der FB besser enablen oder disablen?

framp

Active member
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
Code:
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 :unsure:
 
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. :D
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.
 
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?
 
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 :unsure:
 
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.
 
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)).
 
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!"... ;)
 
Zuletzt bearbeitet:
Moinsen,
hier:
Code:
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. ;)
 
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

Code:
    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 :unsure:

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.
 

Letzte Anleitungen

Statistik des Forums

Themen
7.696
Beiträge
75.234
Mitglieder
8.294
Neuestes Mitglied
Biomech
Zurück
Oben