ingo2
Anmeldungsdatum: 15. Juni 2007
Beiträge: 2145
Wohnort: wo der gute Riesling wächst
|
Seit kurzem habe ich vom "rosa Riesen" einen Dualstack Internetzugang.
Es klappt soweit alles einwandfrei und viele Verbindungen ins Internet laufen über
IPv6. Das Ganze ist eigentlich eine gute Sache für das globale Internet durch den
Wergfall von NAT + PAT. Einen Wermutstropfen hat die Sache jedoch: Ich bekomme von der T-com ein dynamisches /56-Prefix zugewiesen. Davon wird ein
/64-Prefix im lokalen LAN benutzt (die estlichen 255-Subnetze sind wohl für IP-Telefonie und
WLAN-to-go vorgesehen). Wann die T-com das zugewiesene Prefix ändert, ist unbekannt - jedenfalls
nicht mehr täglich (sonst wäre es wohl mühsam, immer auch die Zuordnung zu den
IP-Telefonnummern upzudaten). Jetzt zu meinem Problem: Bisher (nur IPv4) war die Zuordnung IPv4-Adresse ←> MAC-Adresse=Interface eindeutig, entweder
über die /etc/hosts oder per DHCP. Somit war auch die Zuordnung Hostname ←> IPv4-Adresse eindeutig
über die /etc/hosts. Das trifft jetzt nicht mehr zu, eine MAC-Adresse kann jetzt sogar mit vielen IPv6-Adressen
verbunden werden, z.B. Multi-Boot (jedes System bekommt eine eigene IP) oder VM's in
VirtualBox mit "Netzwerkbrücke". Und diese IPv6-Adressen (der komplette Interface Identifier)
wechseln bei jeden Reboot, wenn die Privacy-Extensions aktiviert sind. Damit läßt sich
ein Rechner nicht mehr über seinen "privaten" Hostnamen via IPv6 ansprechen, dafür bracht man also
lokal nach wie vor IPv4 - eine Kehrseite der schönen neuen IPv6-Welt. Oder gibt es dafür eine Lösung? Würde ja eigentlich ein Job für Avahi sein? Es gibt nämlich Anwendungen, die sonst auf die Nase fallen, wie z.B. scp foo <hostname:/bar/foo>,
die holen sich dann zwar aus der /etc/hosts die IPv4-Adresse und sprechen das Ziel an, dann hängt die Kommunikation aber fest. Ich muß dann explizit scp -4 ... nutzen. Beste Grüße, Ingo
|
redknight
Moderator & Supporter
Anmeldungsdatum: 30. Oktober 2008
Beiträge: 21725
Wohnort: Lorchhausen im schönen Rheingau
|
ingo2 schrieb: Jetzt zu meinem Problem: Bisher (nur IPv4) war die Zuordnung IPv4-Adresse ←> MAC-Adresse=Interface eindeutig, entweder
über die /etc/hosts oder per DHCP. Somit war auch die Zuordnung Hostname ←> IPv4-Adresse eindeutig
über die /etc/hosts.
Ist so nicht richtig. Ein INterface kann auch mehrere IPv4-Adressen haben. Das trifft jetzt nicht mehr zu, eine MAC-Adresse kann jetzt sogar mit vielen IPv6-Adressen
verbunden werden, z.B. Multi-Boot (jedes System bekommt eine eigene IP) oder VM's in
VirtualBox mit "Netzwerkbrücke". Und diese IPv6-Adressen (der komplette Interface Identifier)
wechseln bei jeden Reboot, wenn die Privacy-Extensions aktiviert sind.
die Autoconf-Adresse sollte die selbe bleiben, die hängt nämlich von der MAC ab 😉 Damit läßt sich
ein Rechner nicht mehr über seinen "privaten" Hostnamen via IPv6 ansprechen, dafür bracht man also
lokal nach wie vor IPv4 - eine Kehrseite der schönen neuen IPv6-Welt.
Der hostname hatte damit noch nie was zu tun. Namensauflkösung egal welcher Art hat erst mal nix mit IP zu tun. Weder mit v4 noch mit v6
|
ingo2
(Themenstarter)
Anmeldungsdatum: 15. Juni 2007
Beiträge: 2145
Wohnort: wo der gute Riesling wächst
|
redknight schrieb: Ist so nicht richtig. Ein INterface kann auch mehrere IPv4-Adressen haben.
die Autoconf-Adresse sollte die selbe bleiben, die hängt nämlich von der MAC ab 😉
Da hast du in beiden Fällen natürlich Recht, hatte ich "vereinfacht". Damit läßt sich
ein Rechner nicht mehr über seinen "privaten" Hostnamen via IPv6 ansprechen, dafür bracht man also
lokal nach wie vor IPv4 - eine Kehrseite der schönen neuen IPv6-Welt.
Der hostname hatte damit noch nie was zu tun. Namensauflkösung egal welcher Art hat erst mal nix mit IP zu tun. Weder mit v4 noch mit v6
Ist zwar korrekt, aber der Sinn eines Hostnamens war und ist doch, daß man nicht mit den kryptischen IP-Adressen oder gar MAC-Adressen hantieren muß, um einen Rechner/Interface im Netzwerk anzusprechen. Ok, ich könnte die Autoconf-Adresse nutzen, aber nur so lange, bis mir die T-com ein neues Prefix zuteilt. Oder gibt es ein Tool/Dienst, den man so konfigurieren kann, daß er die Autoconf-Adresse nutzt und diese bei Zuteilung eines neuem Prefix anpaßt und das in der /etc/hosts updatet? Beste Grüße, Ingo
|
redknight
Moderator & Supporter
Anmeldungsdatum: 30. Oktober 2008
Beiträge: 21725
Wohnort: Lorchhausen im schönen Rheingau
|
Ich verstehe evtl dein Anliegen nicht genau. Ich habe zwei Sorten von feststehenden Konfigurationen, einmal im lokalen Netz (gleichbleibende fe80:: - Adresse) und einmal im Internet (feste IP). In beiden Fällen interessiert mich das Prefix meines Providers herzlich wenig. Da dein Titel auf lokales Netz hinweist, warum nutzt Du also nicht die fe80-Adressen?
|
ingo2
(Themenstarter)
Anmeldungsdatum: 15. Juni 2007
Beiträge: 2145
Wohnort: wo der gute Riesling wächst
|
redknight schrieb: Ich verstehe evtl dein Anliegen nicht genau. Ich habe zwei Sorten von feststehenden Konfigurationen, einmal im lokalen Netz (gleichbleibende fe80:: - Adresse) und einmal im Internet (feste IP). In beiden Fällen interessiert mich das Prefix meines Providers herzlich wenig. Da dein Titel auf lokales Netz hinweist, warum nutzt Du also nicht die fe80-Adressen?
Ich glaube, das könnte die Lösung sein! Sind die auch eindeutig im lokalen Netz und vor allem konstant bei jedem Gerät/Interface, d.h. hängen nur von der MAC-Adresse ab und sonst nichts? Beste Grüße, Ingo EDIT: $ ip -6 addr show
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
...
inet6 fe80::222:4dff:fe83:6441/64 scope link
valid_lft forever preferred_lft forever und
ifconfig eth0
eth0 Link encap:Ethernet Hardware Adresse 00:22:4d:83:64:41
|
ingo2
(Themenstarter)
Anmeldungsdatum: 15. Juni 2007
Beiträge: 2145
Wohnort: wo der gute Riesling wächst
|
Ach ja, du hattest gefragt, wozu das gut sein soll:
Ich möchte ganz einfach die gleiche Funktionalität/Comfort wie mit IPv4 auch unter IPv6 haben, nämlich Adressierung im lokalen Netz per Hostname. Vielleicht sollte ich noch erwähnen, daß ich lokal auf allen Rechnern fixe IPv4-Adressen vergeben habe (in /etc/network/interfaces und die Hostnamen dazu in/etc/hosts). Hier 2 Beispiele:
$ ping -c1 nas
PING nas.home (192.168.0.99) 56(84) bytes of data.
64 bytes from nas.home (192.168.0.99): icmp_req=1 ttl=64 time=0.695 ms
--- nas.home ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.695/0.695/0.695/0.000 ms
---------
$ ping6 -c1 nas
connect: Invalid argument oder:
$ scp -4 nas:/etc/hosts ./
Debian GNU/Linux 7
Running on TS-109 at home
Enter passphrase for key '/xxxx/.ssh/id_dsa':
---------
$ scp -6 nas:/etc/hosts ./
ssh: Could not resolve hostname 192.168.0.99: Address family for hostname not supported Werde das mit der Link-localen IPv6 Adresse in der /etc/hosts versuchen und sehen, ob es ein wechselndes /56-Prefix übersteht.
|
redknight
Moderator & Supporter
Anmeldungsdatum: 30. Oktober 2008
Beiträge: 21725
Wohnort: Lorchhausen im schönen Rheingau
|
Auch wenn wir jetzt die Lösung haben, vergleichst Du natürlich Äpfel mit Birnen. Statisches Setup mit Lokalen Adressen gegen dynamisches mit öffentlichen Adressen kann so im Vergleich nicht ausgehen. Denn mit einem statischen setup hättest Du auch keine Probleme gehabt 😉
|
encbladexp
Ehemaliger
Anmeldungsdatum: 16. Februar 2007
Beiträge: 17442
|
Zusätzlich gibt es auch noch ULAs, also Unique Local Addresses. Die fangen mit fc/fd* an und gehören ganz allein deinem Netzwerk. Das sieht dann z.B. so aus:
[stefan@pc2007 ~]$ ip -6 addr show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
inet6 fd07:XXXX:c4fd:8192:3c90:ff6a:XXXX:c204/64 scope global temporary dynamic
valid_lft 86211sec preferred_lft 14211sec
inet6 fd07:XXXX:c4fd:8192:21b:21ff:XXXX:6807/64 scope global mngtmpaddr dynamic
valid_lft 86211sec preferred_lft 14211sec
inet6 2003:65:c757:XXXX:3c90:ff6a:XXXX:c204/64 scope global temporary dynamic
valid_lft 86211sec preferred_lft 14211sec
inet6 2003:65:c757:XXXX:21b:21ff:XXXX:6807/64 scope global mngtmpaddr dynamic
valid_lft 86211sec preferred_lft 14211sec
inet6 fe80::21b:21ff:XXXX:6807/64 scope link
valid_lft forever preferred_lft forever Ich hab also 2 lokale ULAs, eine davon pseudo statisch über die Mac und die andere dynamisch wegen private Extension. Dann noch 2 GUs mit der gleichen Aufteilung, und dann noch die LL Adresse mit fe80. Eine der fd07 Adressen kann ich also prima in mein DNS Eintragen, ganz ohne komisches DHCP. fe80 ist auf einen Link begrenzt, also nicht mit Router und so. Die meisten Telekom Router und Speedports erzeugen auf Wunsch auch ne ULA und alles ist gut. Ansonsten gibt es auch noch Avahi. mfg Stefan Betz
|
ingo2
(Themenstarter)
Anmeldungsdatum: 15. Juni 2007
Beiträge: 2145
Wohnort: wo der gute Riesling wächst
|
encbladexp schrieb: Zusätzlich gibt es auch noch ULAs, also Unique Local Addresses. Die fangen mit fc/fd* an und gehören ganz allein deinem Netzwerk. Ich hab also 2 lokale ULAs, eine davon pseudo statisch über die Mac und die andere dynamisch wegen private Extension. Dann noch 2 GUs mit der gleichen Aufteilung, und dann noch die LL Adresse mit fe80. Eine der fd07 Adressen kann ich also prima in mein DNS Eintragen, ganz ohne komisches DHCP. fe80 ist auf einen Link begrenzt, also nicht mit Router und so. Die meisten Telekom Router und Speedports erzeugen auf Wunsch auch ne ULA und alles ist gut. Ansonsten gibt es auch noch Avahi. mfg Stefan Betz
Danke Stefan, ich glaube das war mein Problem. Mit den link-lokalen fe80-Adressen war das nicht so toll, manche Befehle wollten eigentlich nicht. Habe jetzt im Router (SP W724V) die ULA aktiviert - und siehe da, alle Hosts bekommen wie bei dir 2 ULA's zugeteilt, hier die "quasi statische":
inet6 fd29:xxxx:xxxx:1:222:4dff:fe83:6441/64 scope global dynamic
valid_lft 1814346sec preferred_lft 604746sec Jetzt stellt sich nur die Frage: sollte ich die ULA's in die /etc/hosts eintragen (statt der lokalken)? Ihre Lifetime ist ja nicht unendlich, und was passiert, wenn die T-com ein neues /56-Prefix verteilt? Beste Grüße, Ingo P.S.: also, so einfach ist die Sache mit IPv6 nun ja doch nicht. Und außer der Konfiguration fürs lokale Netz (ist ja nicht so trivial) ist auch noch die abweichende Sysntax bei einigen Befehlen zu beachten, s. z.B. hier.
|
ingo2
(Themenstarter)
Anmeldungsdatum: 15. Juni 2007
Beiträge: 2145
Wohnort: wo der gute Riesling wächst
|
So, habe jetzt mal noch weiter zu IPv6 recherchiert und bin zu folgendem Ergebnis gekommen: Die "Lösung" mit den ULA's, wie Stefan vorgeschlagen hat, ist "mit Kanonen auf Spatzen schießen". Dazu müsste dann im Lokalen Netz extra ein DHCPv6-Server laufen, der dann auch noch mit DNS für die Namensauflösung sorgt. Bei vielleicht max. 10 Netzwerkgeräten im lokalen Segment wirklich zu kompliziert. Die Lösung über die LL-Adressen ist eigentlich das was noch sinnvoll ist, hat aber auch ihre Tücken, s. hier und hier. Kurz gesagt: zusätzlich zur LL-Adresse muß noch ein sog. "Zone Index" z.B. Interface-Bezeichnung mit angegeben werden. Und offenbar können noch etliche Tools/Anwendungen damit nicht umgehen. Dafür Avahi zu nutzen ist wohl auch fraglich, es war mir bisher z.B. unmöglich, meinen Netzwerkdrucker (an IPv6-fähigem Host) über die IPv6-Adresse aufzuspüren. Wenn das schon nicht geht ...
Die Moral von der Geschicht: Habe bei der Aktion etliches über IPv6 dazugelernt.
Für mein kleines lokales Netzwerksegment bleibt es bei IPv4! Zum Spielen und Lernen ist da IPv6 ganz nett aber nicht praktikabel oder sinnvoll. Markiere den Thread daher als "gelöst". Danke dafür an Stefan und redknight! Ingo
|
encbladexp
Ehemaliger
Anmeldungsdatum: 16. Februar 2007
Beiträge: 17442
|
Die ULAs sind Pseudostatisch, wird am Router kein neues Prefix generiert bleiben diese auch. Die sind auch unabhängig vom sich ändernden Prefix deines Providers. Wenn du die in die /etc/hosts einträgst kannst du diese auch benutzen wie normale IPs. DHCPv6 ist dafür nicht nötig, normal läuft ja auch ein DHCPv4 mit und über diesen Nameserver geht auch eine v6 Namensauflösung falls erforderlich. mfg Stefan Betz
|
ingo2
(Themenstarter)
Anmeldungsdatum: 15. Juni 2007
Beiträge: 2145
Wohnort: wo der gute Riesling wächst
|
encbladexp schrieb: DHCPv6 ist dafür nicht nötig, normal läuft ja auch ein DHCPv4 mit und über diesen Nameserver geht auch eine v6 Namensauflösung falls erforderlich.
Danke für die Info. Mein Heimnetz nutzt aber statische/fixe IP's für die per Ethernet anschlossenen Hosts und die per WLAN angeschlossenen Laptops bekommen über einen MAC-Filter stets die gleichen IP's, sind also auch quasi-statisch. Mein eigentliches Problem ist ja die Zuordnung von Hostnamen bei IPv6 - also der DNS-Service. Beste Grüße, Ingo EDIT: Und die ULA's ändern sich doch spätestens, wenn ich meinen Router mal lalt rebooten muß (nie auszuschließen, mußte ich letzthin, da T-com eine SIP-Störung hatte). Und dann die /etc/hosts auf allen Geräten wieder anpassen - das kann doch nicht der Vortschritt sein 😉 EDIT #2: und wenn ich mich recht erinnere, hatten die ULA's eine ähnliche Lifetime wie meine aktuellen globalen von
$ ip -6 addr show
valid_lft 604770sec
Das sind etwa 7 Tage. Quasi-statisch ist das nicht. EDIT #3: Hier ein Link zum Thema Autoconfiguration und DNS, nicht sonderlich ermutigend. EDIT #4: Habe jetzt die Info gefunden, daß z.B. der ssh-server keine LL-Adressen akzeptiert! Deshalb ist das auch keine Lösung für die /etc/hosts ☹ EDIT #5: Hat mir doch keine Ruhe gelassen. Das ssh-login mit der globalen IPv6-Addr. klappt einwandfrei! Und meine Schätzung der Lifetime für die ULA's war richtig. Habe jetzt mal nachgeschaut auf meinem NAS (hatte ich gestern die ULA's wieder de-aktiviert):
inet6 fd05:xxxx:xxxx:1:208:xxxx:xxxx:xxxx/64 scope global dynamic
valid_lft 1723392sec preferred_lft 513792sec
Die wäre also in 6 Tagen abgelaufen. Die einzig wirklich ordentliche Lösung wäre ein DNS-Server fürs lokale Netz oder "good old IPv4"
|
ingo2
(Themenstarter)
Anmeldungsdatum: 15. Juni 2007
Beiträge: 2145
Wohnort: wo der gute Riesling wächst
|
Jetzt habe ich mir die ganze Sache noch mal in Ruhe überlegt: Meine aktuelle Problematik wird doch in der nächsten Zeit viele User hier in Germany betreffen (T-com mit Speedport W724V für IP-basierten Anschluss). Mit bind9 zu hantieren ist wirklich "Kanonen für Spatzen" und dnsmasq ist auf jedem System sowieso installiert. Der nutzt die /etc/hosts. Die simpelste Lösung wäre doch ein Script, welches die Einträge für die /etc/hosts aus dem aktuellen /64-Prefix und dem konstanten Interface Identifier (ist an die MAC gekoppelt) zusammensetzt. Dann würde es reichen, manuell eine Liste aus "Hostname" und "Interface-Identifier" zu pflegen. Ein solches Script könnte bei jeden Booten ausgeführt werden (den Prefix kann es ja mit ip -6 addr show ermitteln), der Interface-Identifier steht bereits in der /etc/hosts. Des weiteren könnte man ggf. eine Cron-Job einrichten, der Änderungen des Prefix bei Bedarf updatet (es gibt da ja eine zeitliche Überlappung bis das alte Prefix endgültig depreciated ist). Ich selbst habe da leider nicht die nötige Erfahrung, um so etwas zu schreiben, aber vielleicht findet sich hier unter den Lesern Jemand? Bei Tests bin ich gerne dabei. Viele Grüße, Ingo
|
redknight
Moderator & Supporter
Anmeldungsdatum: 30. Oktober 2008
Beiträge: 21725
Wohnort: Lorchhausen im schönen Rheingau
|
Ich verstehe nicht, warum du ein statisches setup für rein interne Adressen mit aller Gewalt an das externe dynamische prefix binden willst.
|
ingo2
(Themenstarter)
Anmeldungsdatum: 15. Juni 2007
Beiträge: 2145
Wohnort: wo der gute Riesling wächst
|
redknight schrieb: Ich verstehe nicht, warum du ein statisches setup für rein interne Adressen mit aller Gewalt an das externe dynamische prefix binden willst.
Ich habe/hatte Bedenken, daß auch die ULA's nicht konstant sind, weil die auch mit einer "valid lifetime" versehen sind. Ich will das jetzt mal in der Realität überprüfen und habe die ULA's wieder eingeschaltet. Das wäre die saubere Lösung. Leider findet man dazu kaum Dokumentation, ich werde wohl oder Übel einfach warten müssen.
Hier die liftimes nach dem Aktivieren:
fd mit privacy extensions
valid_lft 604526sec preferred_lft 85526sec
fd ohne privacy extensions
valid_lft 1814384sec preferred_lft 604784sec Falls die "quasi statische" ohne PE sich auch ändert, ist das ganze für die Katz'. Werde auf jeden Fall hier das Ergebnis berichten. Teste auch noch Reboot des Routers und Stromausfall (hard reset). Beste Grüße, Ingo
|