Warum kann man IPv6 link local Adresen nicht nutzen?

[ingo2]

Ich habe mich jetzt mal in IPv6 eingelesen. Meine lokale Namensauflösung über einen "unbound" DNS-Server klappt auch bestens unter Verwendung von ULA's. Das mußte ich leider so machen, da die Telekom ja kein fixes Prefix spendiert.

Jetzt habe ich gefunden, daß es bei IPv6 verschiedene "Scopes" (Gültigkeitsbereiche) der verschiedenen Prefixe gibt. Danach sind eigentlich ULA's völlig überdimensioniert und es würde mir bei nur einem einzigen Router für das lokale Netzerk auch ein "Link Local scope" genügen, da er alle Knoten im lokalen Netzwerk umfasst.
Zitat von https://en.wikipedia.org/wiki/Private_network:

Another type of private networking uses the link-local address range. The validity of link-local addresses is limited to a single link; e.g. to all computers connected to a switch, or to one wireless network. Hosts on different sides of a network bridge are also on the same link, whereas hosts on different sides of a network router are on different links.

Oder von https://tools.ietf.org/html/rfc4291:

Link-Local addresses are designed to be used for addressing on a
single link for purposes such as automatic address configuration,
neighbor discovery, or when no routers are present.

Routers must not forward any packets with Link-Local source or
destination addresses to other links.

Wenn ich das aber probiere mit Adressen der Form

Code: Alles auswählen

fe80::<interface identifier>

bekomme ich nur Fehlermeldungen der Art:
ping: -> Der Name oder der Dienst ist nicht bekannt
ssh: -> Invalid argument
usw. habe auch schon probiert, die Interfacebezeichnung (z.B. mit "%eno1") anzuhängen - geht dennoch nicht.

Ist das jetzt Debian-spezifisch oder allgemeingültig, dass Link-Local Adressen nicht für Anwendungen nutzbar sind?

Beste Grüße,
Ingo

[DeletedUserReAsG]

Zumindest bei ping sollte man ping6 nehmen, afair.

[ingo2]

Zumindest bei ping sollte man ping6 nehmen, afair.

Sorry, schlampig verfaßt - habe natürlich ping6 probiert, genau wie bei ssh mit "ssh -6"

[TomL]

LinkLocal-Adressen sind nicht internettauglich. Deren Zweck ist es, innerhalb eines lokalen Netzes Basis-Netzfunktionen zur Verfügung zu stellen, damit anschließend auf dem Client eine Stateless Address Autoconfiguration durchgeführt werden kann - wenn z.b. über das Router-Advertisement der ISP-Prefix (meistens ein 56-Bit-Anteil der künftigen Client-IPv6) gesendet wurde. Das heisst, der Client bildet sich selber seine internettaugliche IPv6 als Global Unicast Adress mit dem Prefix als Basis. Das heisst, alle Clients im LAN haben den gleiche 56-Bit-Prefix in ihrer GUA-IPv6. 56 Bit sind es nicht zwigend, es können auch 59 Bit sein, oder 48, oder was auch immer.... ist eine Sache des Vertrags mit dem ISP. Die ersten 64 Bits sind der Netz-Anteil der IPv6, für alle Clients gleich, die Bits ab 65 sind der Geräte-Anteil, also alle unterschiedlich. Ist also prinzipiell nicht anders als bei IPv4. Für eine Link-Local-Adresse gibts keine Garantie, dass die tatsächlich einmalig ist, insofern kann sie nicht im Internet verwendet werden.
Wenn Du sowas wie ein Intranet aufbauen willst, ohne das die Clients ins Internet können, kannst Du Unique Local Unicast-Adressen verwenden, das sind rein lokale Adressen, die möglichweise weltweit tatsächlich auch einmalig sein könnten, aber auch für die gibts keine Garantie.

Ums kurz zu sagen, wenn die Clients ins Internet wollen und Du willst nicht den Wahnsinn begehen, ein IPv6-NAT einzurichten, geht kein Weg an den GUA-Adressen dran vorbei. Ganz nebenbeibemerkt, mit GUA's ist überhaupt nix überdimensioniert, dass sind einfach nur völlg normale IPv6-Adressen, so wie alle anderen auch. Die haben ganz einfach nur einen reservierten Adressbereich, eben diese 2000'er/16 Adressen. Das ist nix anderes, als es auch schon bei IPv4 gab, wo z.B. 192/24'er, 172/16'er und 10/8'er Netze reservierte "Zahlen" für private Netze waren, für Class C-Netze, Class-B-Netze und Class-A-Netze.

Das einfachste ist, einfach die GUA's zu nehmen und darauf zu achten, dass die Clients via Privacy Extensions regelmäßig ihre IP ändern. SLAAC würde nämlich hingehen und bei gleichbleibenden Prefix unter Verwendung der MAC immer die gleiche IPv6 generieren. Damit wäre eine IPV6 resp. der Rechner über einen längeren Zeitraum eindeutig identifizierbar. Das sollte man also abschalten.

[ingo2]

LinkLocal-Adressen sind nicht internettauglich. Deren Zweck ist es, innerhalb eines lokalen Netzes Basis-Netzfunktionen zur Verfügung zu stellen, damit anschließend auf dem Client eine Stateless Address Autoconfiguration durchgeführt werden kann - wenn z.b. über das Router-Advertisement der ISP-Prefix (meistens ein 56-Bit-Anteil der künftigen Client-IPv6) gesendet wurde.
....
Das einfachste ist, einfach die GUA's zu nehmen und darauf zu achten, dass die Clients via Privacy Extensions regelmäßig ihre IP ändern. SLAAC würde nämlich hingehen und bei gleichbleibenden Prefix unter Verwendung der MAC immer die gleiche IPv6 generieren. Damit wäre eine IPV6 resp. der Rechner über einen längeren Zeitraum eindeutig identifizierbar. Das sollte man also abschalten.

Was ich möchte, ist ganz einfach beschrieben:
Im lokalen Netzsegment (hinter dem Router, also link-local scope) meine Gräte via IPv6 mit ihrem Hostnamen ansprechen. Dazu läuft hier ein unbound als DNS-Server, in dem ich

Code: Alles auswählen

hostname und IPv6

eintrage, damit ich die Rechner/Geräte mit Namen ansprechen kann statt der unmöglich zu merkenden IPv6-Adresse. Und die Pflege der /etc/hosts dafür auf allen Geräten ist damit entfallen. Das geht im Moment mit ULA's, sollte aber eigentlich auch mit Link-Local Adressen fe80::/10 gehen. Meine GUA's sind leider nicht konstant - den Luxus bietet der rosa Riese Privatkunden nicht.

[TomL]

Was ich möchte, ist ganz einfach beschrieben:
Im lokalen Netzsegment (hinter dem Router, also link-local scope) meine Gräte via IPv6 mit ihrem Hostnamen ansprechen.

Ja, klar... das würde ich auch wollen... aber ich frage mich jetzt, warum das nicht automatisch bei Dir passiert. Bei mir ist der Name-Server in die resolv.conf eingetragen, und zwar mit seiner LLA. Damit finde ich alle Clients über ihren Hostnamen. Wenns das nicht ist, dann sorry... dann kann ich leider nicht zur Lösung beitragen.

[bluestar]

Also bei mir funktionieren die link-local Adressen mit %Interface am Ende ohne Probleme, egal ob bei ssh -6 oder bei ping6, hast du evtl. ne Firewall am Start, die IPv6 blockt?

[TomL]

ping6 geht bei mir auch mit der LLA, aber wie machst Du das mit SSH? Der SSH-Client sieht ja eigentlich nicht vor, ein NIC vorzugeben, sondern überlässt das dem Kernel. SSH -6 funktioniert bei mir auf die schnelle nicht mit der LLA.

[bluestar]

Ich starte SSH z.B. wie folgt:

Code: Alles auswählen

ssh -l root fe80::3e4a:92ff:fe49:17e1%eno2

[ingo2]

Das ist ja das verrückte:

Habe jetzt mehrfach probiert und 1x hat es auch mit SSH und der LLA%IF funktioniert - scheint Zufall zu sein???

@TomL:
Du sagtest, du hast deinen DNS-Server in der resolv.conf eingetragen - habe ich auch.
Wie machst du dann die Zuordnung "hostname <-> IPv6 Adresse"? Welche Adresse hast du beim DNS eingetragen?

Tja, sdelbst, wenn das mit dem angehängten Interface klappen sollt, dann ist das aber keine Lösung, weil ga dann die DNS-Einträge unterschiedlich sein müssen - je nachdem wie gerade das Interface bezeichnet wurde. Da war die alte Nomenklatur ethX wenistens brauchbar. Die Clients selbst sollten das optimalerweise selbst anhängen, denn sie wissen ja, welches Interface sie nutzen.

Also artet das in Frickelei aus und ULA's sind die einzige vernünftige Lösung.

[bluestar]

Tja, sdelbst, wenn das mit dem angehängten Interface klappen sollt, dann ist das aber keine Lösung, weil ga dann die DNS-Einträge unterschiedlich sein müssen - je nachdem wie gerade das Interface bezeichnet wurde. Da war die alte Nomenklatur ethX wenistens brauchbar. Die Clients selbst sollten das optimalerweise selbst anhängen, denn sie wissen ja, welches Interface sie nutzen.

Genau dafür sind Link-Local Adressen nicht gemacht, als Bespiel unser Router - der hat insgesamt 14 LAN Interfaces (je Abt. ein VLAN) und auf all diesen 14 Interfaces hat er die LL-Adresse: fe80::1/64.

Also artet das in Frickelei aus und ULA's sind die einzige vernünftige Lösung.

ULAs sind ja auch genau dafür geschaffen ... Letztendlich ist es Schade, das dir dein Provider kein festes IPv6 Prefix vergibt, dann wäre der ganze Kram mit "privaten Adressen" vom Tisch.

[TomL]

Du sagtest, du hast deinen DNS-Server in der resolv.conf eingetragen - habe ich auch.
Wie machst du dann die Zuordnung "hostname <-> IPv6 Adresse"? Welche Adresse hast du beim DNS eingetragen?

Das macht bei mir meine Fritzbox... eigentlich muss ich da nix eintragen... das geht völlig automatisch, wenn sich die Clients via DHCP eine IPv4 holen. Wenn Du aber einen eigenen DNS-Server installiert hast, wirst Du wahrscheinlich den Clients auch noch eine Unique Local Unicast-Adresse als Static-IPv6 vergeben müssen. Dann hat das NIC nachher 4 IPv6-Adressen:
1. Eine GUA aus Privacy Extensions (wird bevorzugt ins Internet geroutet)
2. Eine GUA basierend auf der MAC (ist halt da, könnte auch ins Web geroutet werden, tut aber von alleine nix)
3. Eine LLA z.B. für das Router-Advertisement
4. Eine ULA für das lokale LAN (werden eigentlich nicht ins Internet geroutet)

Die ULA trägst Du dann in Dein DNS ein und imho sollte es damit dann gehen.

1.PC

Code: Alles auswählen

ip addr add  fd00:1::1/64 dev eth0

2.PC

Code: Alles auswählen

ip addr add  fd00:1::2/64 dev eth0

3.PC

Code: Alles auswählen

ip addr add  fd00:1::3/64 dev eth0

usw.

[TomL]

Ich starte SSH z.B. wie folgt: .....

Tatsächlich, das geht ja wirklich... sachen gibts....

Danke

[ingo2]

4. Eine ULA für das lokale LAN (werden eigentlich nicht ins Internet geroutet)

Das hoffe ich stark, kontrollieren allein kann ich es nicht. Das war ja mein Gedanke, deshalb auf LLA's umzustellen - die werden garanziert nicht geroutet.

Die ULA trägst Du dann in Dein DNS ein und imho sollte es damit dann gehen.

Klar, das läuft hier bestens schon eine ganze Weile.
Den FritzBox-DHCPv6-Server habe ich komplett deaktiviert, dessen Port 547 steht nämlich offen auf dem WAN-Interface der FB!

Die IPv6-Konfiguration mache ich komplett über SLAAC und verteile so auch meinen RDNSS (unbound) - kann man in der FB einschalten. Nur eine alte Win7-Installation kommt damit nicht zurecht - was soll's, brauch ich nur um mein TomTom upzudaten.

EDIT:
Hier der Portscanner für IPv6 UDP: http://ipv6tech.ch/?udpportscan

[TomL]

Den FritzBox-DHCPv6-Server habe ich komplett deaktiviert, dessen Port 547 steht nämlich offen auf dem WAN-Interface der FB!

Port 547 auf dem Router ist per default definitiv nicht offen zum Internet. Und eigentlich hat der Port imho auch gar nix mit WAN-IPs zu tun. Ich habe das jedenfalls nicht deaktiviert.... vielleicht ist das auch der Grund, warum das bei Dir via IPv6-DNS nicht funktioniert:

Code: Alles auswählen

DHCPv6-Server im Heimnetz:
[X]  DHCPv6-Server in der FRITZ!Box für das Heimnetz aktivieren:
   [x]  Nur DNS-Server zuweisen
   [ ]  DNS-Server und IPv6-Präfix (IA_PD)zuweisen
   [ ]  DNS-Server, Präfix (IA_PD) und IPv6-Adresse (IA_NA) zuweisen 

BTW, hast Du für den Portscan die WAN-IPv6 des Routers genommen? Das ist zwar auch eine GUA, aber nicht die, die sich der Router via SLAAC aus dem ISP-Prefix selber ermittelt. Aber auch die via SLAAC ermittelte ist ja eh dicht. Bei mir sind jedenfalls beide nicht offen... ohne das ich da was gemacht hätte.

[ingo2]

Hi Thomas,

habe oben den Link zum Scanner nachgetragen.
Und natürlich habe ich die WAN-IP der FritzBox gescannt, zeigt er ja schon auf der Übersicht-Seite an. Und die (der Interface Idetifier) ist auch aus der MAC-Adresse abgeleitet, vergleiche mit den LAN-Interfaces.

Gruß,
Ingo

[schorsch_76]

4. Eine ULA für das lokale LAN (werden eigentlich nicht ins Internet geroutet)

Das hoffe ich stark, kontrollieren allein kann ich es nicht. Das war ja mein Gedanke, deshalb auf LLA's umzustellen - die werden garanziert nicht geroutet.

ULAs werden wie 192.168.x.x / 10.x.x.x und 172.16.x.x nicht geroutet.

Siehe Wikipedia unter ipv6 [1]

Diese Site-ID ist bei den ULA mit dem Präfix fd zufällig zu generieren.

Auch ich die oben genannte ULA so nicht verwenden da sie vermutlich nicht eindeutig ist. Ich hab 1000 Bytes aus /dev/urandom genommen durch sha256 gejagt und dann die ersten Bytes genommen bis ich beim /64 Netz war.

[1] https://de.wikipedia.org/wiki/IPv6#Unique_Local_Unicast

[ingo2]

Auch ich die oben genannte ULA so nicht verwenden da sie vermutlich nicht eindeutig ist. Ich hab 1000 Bytes aus /dev/urandom genommen durch sha256 gejagt und dann die ersten Bytes genommen bis ich beim /64 Netz war.

Der Grund dafür leuchtet mir absolut nicht ein:
a) wenn sie nicht geroutet werden, können sie auch niemals mit anderen (nicht von mir kontrollierten) kollidieren.
c) theoretisch hat doch jedes x-beliebige einzelne ULA-Prefix die gleiche Wahrscheinlichkeit, einzigartig zu sein - auch ein "fd00::0001/64" könnte "durch Zufall" generiert werden - oder?

[TomL]

Diese Site-ID ist bei den ULA mit dem Präfix fd zufällig zu generieren.

Auch ich die oben genannte ULA so nicht verwenden da sie vermutlich nicht eindeutig ist. Ich hab 1000 Bytes aus /dev/urandom genommen durch sha256 gejagt und dann die ersten Bytes genommen bis ich beim /64 Netz war.

Warum muss das so kompliziert sein? Warum eine eher unwichtige zusätzliche ULA generisch erzeugen, wenn man die doch einfach Static durchnummeriert vorgeben kann. Bei einem großen Netz mit viel Hardwarebewegung würde ich das ja noch verstehen, aber zuhause und wenn's nur um DNS geht...?... und die eh nicht geroutet werden. Ich finde, dass durchnummeriert durchaus eindeutig ist.

Oder gibt es dabei andere technische Gründe?

[ingo2]

Oder gibt es dabei andere technische Gründe?

Ich könnte mir höchstens vorstellen, dass es relevant werden könnte, wenn sich 2 große Firmen (die sich voher nicht kannten) übers Internet z.B. per "dicken VPN" zusammegeschlossen werden sollen. Dann gäbe es die gleiche Konstellation wie heute schon mit IPv4 wenn beide Seiten das gleiche private Subnetz verwenden.

Aber dafür ist ja dann das Prefix "fc::" vorgesehen, welches wirklich "unique" ist, da es zentral vergeben wird.

Ich glaube, da wurde einfach mit doppeltem oder dreifachem Boden gearbeitet ohne zu überblicken, ob das wirklich nötig ist.

[schorsch_76]

Diese Site-ID ist bei den ULA mit dem Präfix fd zufällig zu generieren.

Auch ich die oben genannte ULA so nicht verwenden da sie vermutlich nicht eindeutig ist. Ich hab 1000 Bytes aus /dev/urandom genommen durch sha256 gejagt und dann die ersten Bytes genommen bis ich beim /64 Netz war.

Warum muss das so kompliziert sein? Warum eine eher unwichtige zusätzliche ULA generisch erzeugen, wenn man die doch einfach Static durchnummeriert vorgeben kann. Bei einem großen Netz mit viel Hardwarebewegung würde ich das ja noch verstehen, aber zuhause und wenn's nur um DNS geht...?... und die eh nicht geroutet werden. Ich finde, dass durchnummeriert durchaus eindeutig ist.

Oder gibt es dabei andere technische Gründe?

Eine Beispiel-ULA wäre fd9e:21a7:a92c:2323::1. Hierbei ist fd das Präfix für lokal generierte ULAs, 9e:21a7:a92c ein einmalig zufällig erzeugter 40-Bit-Wert und 2323 eine willkürlich gewählte Subnet-ID.

Die Verwendung von wahrscheinlich eindeutigen Site-IDs hat den Vorteil, dass zum Beispiel beim Einrichten eines Tunnels zwischen getrennt voneinander konfigurierten Netzwerken Adresskollisionen sehr unwahrscheinlich sind. Weiterhin wird erreicht, dass Pakete, welche an eine nicht erreichbare Site gesendet werden, mit großer Wahrscheinlichkeit ins Leere laufen, anstatt an einen lokalen Host gesendet zu werden, der zufällig die gleiche Adresse hat.

[TomL]

Ja klar, das habe ich jetzt verstanden. Die Voraussetzung ist, dass es mehrere Site-IDs gibt, die sich"sehen" könnten. Das habe ich hier nicht. Und selbst wenn, für mein privates Umfeld würde ich dann kurzerhand auch die Site-ID vorgeben, um eben die notwendige Eindeutigkeit zu gewährleisten.... halt so einfach wie möglich, so kompliziert wie nötig. Und da die nicht ins Web geroutet werden, wäre das für mich ok.

Bei mir sähe das dann für 3 theoretische Netze so aus:
fd00:1::/64
fd00:2::/64
fd00:3::/64

[TomL]

habe oben den Link zum Scanner nachgetragen.
Und natürlich habe ich die WAN-IP der FritzBox gescannt, zeigt er ja schon auf der Übersicht-Seite an. Und die (der Interface Idetifier) ist auch aus der MAC-Adresse abgeleitet, vergleiche mit den LAN-Interfaces.

Ich habs jetzt aus Neugier auch noch mal kontrolliert... und es ist tatsächlich so... dieser Port 547 ist nicht offen.

[ingo2]

Ich habs jetzt aus Neugier auch noch mal kontrolliert... und es ist tatsächlich so... dieser Port 547 ist nicht offen.

Vertehe ich nicht.
Bie mir sind alle UDP-Ports "CLOSED" bis auf

Code: Alles auswählen

UDP6 Port 547 	dhcpv6-server 	REACHABLE 
UDP6 Port 5060 	sip 	REACHABLE

wobei 5060 ja klar ist, will ja per VoIP erreichbar sein.
Und "REACHABLE" bedeutet

... kommt kein Packet innerhalb einer gewissen Zeit zurück so ist der Port entweder offen (reachable) oder ICMPv6 Fehlermeldungen werden durch eine Firewall blockiert (filtered)

Und "offen" ist ein Port entweder, weil ein Server darauf lauscht, oder weil eine Anwendung von innen darauf nach extern sendet, also Daten überträgt und ggf. auf Antwort wartet.
Warum ist der Port nicht "CLOSED" oder wenigstens "FILTERED", d.h von einer Firewall blockiert?

Gruß,
Ingo

[BenutzerGa4gooPh]

UDP6 Port 547 dhcpv6-server REACHABLE

DHCPv6 uses UDP port number 546 for clients and port number 547 for servers.

https://en.wikipedia.org/wiki/DHCPv6

Unbedingt benötigt man einen DHCP-Server bei IPv6 nicht: https://www.elektronik-kompendium.de/si ... 902141.htm
Wie scannst du die Fritzbox? (WAN-Anschluss ist ja xDSL oder LWL, da würde ich zum Portscan einen LAN-Port zum WAN umkonfigurieren, man will ja die Sicherheit von außen wissen. Oder man nutzt den Anschluss eines Bekannten.)
Oder scannst du einen LAN-Port?
Was dein ISP auf dem WAN macht (DHCPv6?), sein/dein "Netzabschlussgeraet" tun muss, weiß ich nicht, bei mir ist die Welt noch in Ordnung - also hinter dem Mond ohne Glas, ohne xDSL, mit IPv4 per "Dorf-WLAN".