Hallo,
ich bin gerade dabei einen Router von Mikrotik (HAP Lite) einzurichten
und hänge mal wieder an IPv6.
Gegeben ist ein statisches /48-Netz (2001:af:31::/48). Das Gateway hat
die (2001:af:31::1).
Das WAN-Interface hat die 2001:af:31:ff00::1 und die Bridge die
2001:af:31:ff00:234:a34:34b:455/64
In der Firewall sind aktuell alle Regeln deaktiviert.
Der Router kommt per IPv6 in Internet und ist von außen anpingbar, aber
die Clients dahinter kommen nicht per v6 ins Internet.
Hier die Ausgabe, wenn die Google anpinge:
1
[user@netbook ~]$ ping -6 google.de
2
PING google.de(fra24s04-in-x03.1e100.net (2a00:1450:4001:827::2003)) 56 data bytes
3
Von netbook (2001:af:31:ff00:2344:a3c1:3b4:f555) icmp_seq=1 Ziel nicht erreichbar: Adresse nicht erreichbar
4
Von netbook (2001:af:31:ff00:2344:a3c1:3b4:f555) icmp_seq=2 Ziel nicht erreichbar: Adresse nicht erreichbar
5
Von netbook (2001:af:31:ff00:2344:a3c1:3b4:f555) icmp_seq=3 Ziel nicht erreichbar: Adresse nicht erreichbar
6
Von netbook (2001:af:31:ff00:2344:a3c1:3b4:f555) icmp_seq=4 Ziel nicht erreichbar: Adresse nicht erreichbar
7
Von netbook (2001:af:31:ff00:2344:a3c1:3b4:f555) icmp_seq=5 Ziel nicht erreichbar: Adresse nicht erreichbar
8
Von netbook (2001:af:31:ff00:2344:a3c1:3b4:f555) icmp_seq=6 Ziel nicht erreichbar: Adresse nicht erreichbar
Woher hast Du denn das Netz 2001:af:31::/48? Das ist derzeit keinem
Provider zugewiesen.
Dein Internet-Provider (wenn er IPv6 anbietet) sollte Deinem
Internetrouter ein global gültiges Netz per IPv6-Prefix-Delegation
zuweisen. Dein Internet-Router stellt dann aus diesem Netz die Adressen
für die Clients im LAN per SLAAC zur Verfügung. Alternativ auch per
DHCPv6. Je nach Konfiguration.
inet 172.30.230.31/24 brd 172.30.230.255 scope global secondary dynamic noprefixroute enp2s0
9
valid_lft 594978sec preferred_lft 519303sec
10
inet6 2001:af:31:ff00:8740:330a:bae0:f0fb/64 scope global dynamic mngtmpaddr noprefixroute
11
valid_lft 2591810sec preferred_lft 604610sec
12
inet6 fd:c0:ff:ee:f59:b461:a64b:4288/64 scope global dynamic mngtmpaddr noprefixroute
13
valid_lft 2591810sec preferred_lft 604610sec
14
inet6 2001:af:31:ff00:2225:64ff:fe34:ce08/64 scope global dynamic mngtmpaddr noprefixroute
15
valid_lft 2591809sec preferred_lft 604609sec
16
inet6 fd:c0:ff:ee:2225:64ff:fe34:ce08/64 scope global dynamic mngtmpaddr noprefixroute
17
valid_lft 2591809sec preferred_lft 604609sec
18
inet6 2001:af:31:ff00:c0:ff:ee:1/64 scope global
19
valid_lft forever preferred_lft forever
20
inet6 2001:af:31:ff00::2/64 scope global
21
valid_lft forever preferred_lft forever
22
inet6 fe80::2225:64ff:fe34:ce08/64 scope link
23
valid_lft forever preferred_lft forever
Thomas V. schrieb:> Woher hast Du denn das Netz 2001:af:31::/48? Das ist derzeit keinem> Provider zugewiesen.
Ich habe im Beitrag gewollt die IP ein bisschen verändert, weil ich
nicht die öffentliche IP veröffentlichen möchte. In der Firewall steht
die passende IP.
Thomas V. schrieb:> Dein Internet-Provider (wenn er IPv6 anbietet) sollte Deinem> Internetrouter ein global gültiges Netz per IPv6-Prefix-Delegation> zuweisen. Dein Internet-Router stellt dann aus diesem Netz die Adressen> für die Clients im LAN per SLAAC zur Verfügung. Alternativ auch per> DHCPv6. Je nach Konfiguration.
Der DHCPv6-Client bekommt nichts zugewiesen.
Bevor es mir unlängst das Ding beim Update gebrickt hatte, hatte ich
kein Problem, einen Mikrotik hAP ac² ins Netz einer Fritzbox zu hängen.
Fritz bekommt vom Provider einen /56 Prefix und vergab per DHCPv6 einen
/62 an den Mikrotik. Der wiederum machte daraus ein /64 Sekundärnetz.
Alles ziemlich automatisch.
100Ω W. schrieb:> Ich habe im Beitrag gewollt die IP ein bisschen verändert, weil ich> nicht die öffentliche IP veröffentlichen möchte. In der Firewall steht> die passende IP.
O.k.
Wollte nur sichergehen, dass Du keine Fantasieadressen verwendest.
> Der DHCPv6-Client bekommt nichts zugewiesen.
Dann vielleicht mit SLAAC versuchen?
Einfach mal einen Win10- oder Linux-Rechner in das Netz hinterm
DSL-Router bringen und IPv6 auf diesem aktivieren. Wenigstens eine
IP-Adresse sowie das default-Gateway sollte er bekommen.
Wenn das geht, kann man mit dem Mikrotik weitermachen. Der muss ja dann
nur noch bridge spielen.
100Ω W. schrieb:> Gegeben ist ein statisches /48-Netz (2001:af:31::/48). Das Gateway hat> die (2001:af:31::1).> Das WAN-Interface hat die 2001:af:31:ff00::1 und die Bridge die> 2001:af:31:ff00:234:a34:34b:455/64
Na, und wie soll das funktionieren?
Dein Router hat (mindestens) zwei physikalische Netze. Einmal in
Richtung Internet (WAN) und einmal in Dein LAN ("bridge"?!).
Beiden hast Du Adressen mit den gleichen Prefix 2001:af:31:ff00::/64
zugeteilt. Woher soll der Router denn nun wissen, was er wohin schicken
soll?
Gib dem LAN-Interface deines Routers einen anderen Prefix, z.B.
2001:af:31:ff0*1*::/64 und sorge dafür, dass der Router per SLAAC den
Prefix und sich selbst als Router annonciert.
Einer schrieb:> Gib dem LAN-Interface deines Routers einen anderen Prefix, z.B.> 2001:af:31:ff0*1*::/64 und sorge dafür, dass der Router per SLAAC den> Prefix und sich selbst als Router annonciert.
Okay, ich habe jetzt dem WAN-Interface die 2001:af:31:ff00::1 und der
Bridge die 2001:af:31:ff01::1 gegeben. Gehen tut es jetzt immer noch
nicht.
Ist SLAAC aktiviert? Wie ist die Routing-Tabelle? Poste die
Konfiguration hier so, wie sie vom Router ausgegeben wird, ohne Deine
eigene Interpretationen.
Ich bin auch recht neu zu IPv6, und mein Setup ist anders (WAN seitig
per DHCPv6 und ein mix aus prefix delegation, ULAs und NAT, je nach
Subnetz & Anwendungsfall). Vielleicht sage ich also auch kompletten
bullshit.
if2 (WAN) würde ich eigentlich ein /128 erwarten, das /48 Netz ist ja
nicht dort drüben zu finden, sondern auf die anderen Router Interfaces
verteilt.
Das 2001:af:31:ff00::/64 netz würde ich beim if3 (LAN) erwarten. Ich
denke es müsste gehen, if3 die 2001:af:31:ff00::1/64 und if2 die
2001:af:31:ff00::1/128 zu geben, aber ich bin mir nicht sicher, ich hab
sowas noch nie ausprobiert.
Bei mir bekomme ich per DHCPv6 eine IP für if2 die in einem komplett
anderem Netz liegt / nicht im Prefix das ich darüber kriege (also nicht
mal 2001:af:31:ff00::/48), damit ist es bei mir mit der default route
abgedeckt. Und diese (if2) bräuchte ich theoretisch eigentlich
vermutlich auch gar nicht, die link locale Adresse sollte fürs routing
auch ausreichen, du könntest die dort vermutlich auch nehmen, und das GW
muss es dann halt dort hin routen. Falls du eine einzelne IP /128 auf
if2 vergibst die im /64 von if3 ist, brauchen die lan clients eine route
für die /128 über die IP von if3 als GW.
Die LAN clients sollten auch noch eine default route (::/0) zu if3
haben.
Die IP von if1 (der bridge) sollte ja eigentlich keine grosse Rolle
spielen. Der Router muss eine default route (::/0) zu if0
(2001:af:31::1) haben, und if0 eine netz route für 2001:af:31::/48 zu
if2 (2001:af:31:ff00::1) (oder alternativ zumindest für netz
2001:af:31:ff00::/64, falls da noch mehr router sind). Die Bridge ist
dabei transparent, eigentlich braucht sie gar keine (ausser man will sie
irgendwie erreichen). Wenn sie eine hat, muss man eventuell dem GW und
dem Router mit einer route sagen, wo sie ist. Wenn es wie hier mit dem
subnet 2001:af:31:ff00::/64 überlappt, bräuchten die Clients eigentlich
auch noch eine route (oder alternativ, der router ein proxy ARP, oder
was auch immer das IPv6 äquivalent ist.). So oder so, erscheint mir
extra ungünstig gewählt.
Es stellt sich auch die frage, woher weiss das GW, wo das Netz
2001:af:31:ff00::/48 oder 2001:af:31:ff00::/64 liegt. Bei mir geht das
vermutlich über die DHCPv6 prefix delegation, da wird es meinem router
ja zugewiesen, aber bei dir ist es statisch. Eventuell per ICMP route
advertisement vom router, so wie man das SLAAC und die routen auch lan
seitig vergibt? Ich nehme an, dass es ohne die Route einfach bei if0 per
ICMP fragen wird, wer hat IP so und so, und keiner antwortet, weil
hinter dem Router.
Vermutlich liegt da dein Haupt Problem. Musst du halt mit tcpdump usw.
analysieren, was da abgeht.
Ich kenne mich mit RouterOS nicht wirklich aus.
Die bridge ist wohl etwas anderes, als ich dachte. Ist diese also LAN
seitig / darin hängen all die clients?
Ich würde das zwar nicht so umsetzen, aber ich denke das sieht
eigentlich gut aus, so wie es ist.
Es gibt 2 Sachen, die ich prüfen würde. Bekommen die Clients eine
default route, (::/0) via 2001:af:31:ff01::1? (Kann man auf linux
clients mit "ip -6 route" oder "route -6" anzeigen, wobei letzteres
etwas mehr anzuzeigen scheint.)
Und dann stellt sich die Frage, hat das GW eine Route zum Router. Ich
würde dafür mal auf dem Router die Packete auf ether1_wan aufzeichnen,
und dann versuchen, vom Client versuchen etwas zu Pingen, oder auf etwas
im Internet zuzugreifen. Von besonderem Interesse sind dabei die ICMP6
Nachrichten, sowie die MACs der Pakete. Das ICMP6 ersetzt quasi arp bei
IPv6. Wenn du in ether1_wan siehst, wie das GW fragt, "wer hat <client
IP>", dann fehlt ihm die Route. Falls du aber Pakete siehst, wo die Ziel
MAC die des Routers ist, und die Ziel IP die eines Clients, ist dort
alles in ordnung. Falls du keins von beiden siehst, hängt es vermutlich
schon irgendwo vorher, und die Pakete vom Client kommen vermutlich schon
gar nicht zum GW.
Daniel A. schrieb:> Es gibt 2 Sachen, die ich prüfen würde. Bekommen die Clients eine> default route, (::/0) via 2001:af:31:ff01::1? (Kann man auf linux> clients mit "ip -6 route" oder "route -6" anzeigen, wobei letzteres> etwas mehr anzuzeigen scheint.)
1
[user@netbook ~]$ ip -6 route
2
::1 dev lo proto kernel metric 256 pref medium
3
2001:af:31:ff01::/64 dev enp2s0 proto ra metric 100 expires 2591536sec pref medium
4
2001:af:31:ff01::/64 dev enp2s0 proto kernel metric 256 pref medium
5
2001:af:31:ff01::/64 dev enp2s0 proto ra metric 1002 pref medium
6
fd42:24:42::250 dev home proto kernel metric 256 pref medium
7
fe80::/64 dev br-5e227d112754 proto kernel metric 256 pref medium
8
fe80::/64 dev veth621ed6a proto kernel metric 256 pref medium
9
fe80::/64 dev veth8a5e09b proto kernel metric 256 pref medium
10
fe80::/64 dev enp2s0 proto kernel metric 256 pref medium
11
default via fe80::a55:31ff:fe37:a347 dev enp2s0 proto static metric 1024 pref medium
12
default dev enp2s0 proto static metric 1024 pref medium
Ach Router-OS...
100Ω W. schrieb:> /ipv6 address> add address=2001:af:31:ff00::1/48 advertise=no interface=ether1_wan
Naja, könnte man so machen, ist aber richtig Kacke.
Der Link zum Provider ist Point-To-Point. Man kann ein /64 für den Link
nehmen, oder ein /127. Ich mag /127.
D.h. für /127 wäre es:
Nun zum LAN:
> add address=2001:af:31:ff01::1 interface=bridge
Wie oft wurde hier im Thread geschrieben, Du sollst SLAAC bzw.
Advertising einschalten?
Gut, so wie die Schnittstelle konfiguriert ist, ist es natürlich maximal
falsch...
Richtig wäre:
Einer schrieb:> Wie oft wurde hier im Thread geschrieben, Du sollst SLAAC bzw.> Advertising einschalten?
Offenbar bekommen seine Clients ja die korrekte Route
(Beitrag "Re: Probleme beim einrichten von IPv6"), SLAAC scheint
also zu funktionieren, und die Pakete werden vom Client korrekt an den
Router und dann weiter ans GW gesendet
(Beitrag "Re: Probleme beim einrichten von IPv6").
Ich vermute eher, dass dem GW eine route zurück um Router fehlt.
🐧 DPA 🐧 schrieb:> Ich vermute eher, dass dem GW eine route zurück um Router fehlt.
Ja, dann dürfte ich von dem Router aus auch nichts mehr anpingen können,
oder habe ich da einen Denkfehler drinnen?
Einer schrieb:> 100Ω W. schrieb:>> /ipv6 address>> add address=2001:af:31:ff00::1/48 advertise=no interface=ether1_wan>> Naja, könnte man so machen, ist aber richtig Kacke.>> Der Link zum Provider ist Point-To-Point. Man kann ein /64 für den Link> nehmen, oder ein /127. Ich mag /127.
Wenn ich die /48 gegen eine /64 oder /127 austausche kan ich den Router
von außen auch nicht mehr anpingen.
100Ω W. schrieb:> 🐧 DPA 🐧 schrieb:>> Ich vermute eher, dass dem GW eine route zurück um Router fehlt.>> Ja, dann dürfte ich von dem Router aus auch nichts mehr anpingen können,> oder habe ich da einen Denkfehler drinnen?
Das kommt drauf an. WAN seitig hat der Router ja auch die
2001:af:31:ff01::1. Wenn also das GW eine Route für 2001:af:31::/48 auf
das GW Interface hat, aber die Route nicht via 2001:af:31:ff01::1 läuft,
dann sollte das GW zwar den Router finden, wenn man dieses anpingt (über
ICMPv6 Neighbor Solicitation & ICMPv6 Neighbor Advertisement), aber wenn
es etwas an die Clients im LAN senden wollte, würde es das auch
versuchen, statt die Pakete an den Router weiterzuleiten, und die LAN
Clients bekämen von all dem nichts mit.
Wie ich schon sagte, falls es das ist, bin ich mir nicht sicher, wie man
dem GW die Route bei bringt. Vielleicht könnte es über ICMPv6 Router
Advertisements gehen. Eins ohne Prefix, aber mit einer Route für
2001:af:31::/48.
https://en.wikipedia.org/wiki/Neighbor_Discovery_Protocol100Ω W. schrieb:> Wenn ich die /48 gegen eine /64 oder /127 austausche kan ich den Router> von außen auch nicht mehr anpingen.
Hier ist mir jetzt auch nicht klar, warum das passieren sollte.
Bei /64 würde ich ja noch verstehen, wenn man nicht von / zu den Clients
käme (weil auf beide Seiten eine identische gleich grosse Route, womit
der Router nicht wüste, auf welcher Seite sie sind (bei /48 gewinnt das
kleinere /64 vom LAN, bei /127 oder gar /128 sollte ja praktisch nur die
WAN addresse betroffen sein, und ohne müsste es immer noch über die
link-local addresse gehen.)).
Aber warum das das Anpingen vom Router selbst beeinflussen sollte, keine
Ahnung.
Was WAN Interface ist nicht teil der bridge, oder?
100Ω W. schrieb:> Wenn ich die /48 gegen eine /64 oder /127 austausche kan ich den Router> von außen auch nicht mehr anpingen.
Ich wette 5,- Euro, dass Du nur die Netzmaske und nicht die Adresse
geändert hast.
Folgendes ist falsch:
Einer schrieb:> Folgendes ist falsch:> add address=2001:af:31:ff00::1/127 advertise=no interface=ether1_wan>> Und das ist richtig:> add address=2001:af:31::/127 advertise=no interface=ether1_wan
Ersteres ist zwar unüblich, aber ich sehe trotzdem nicht, warum es nicht
funktionieren sollte. Anders als bei 2001:af:31::/127 und
2001:af:31:ff00::1/48 ist das GW zwar nicht in dem Subnet, aber es
müsste ja immer noch die default Route ::/0 zum GW geben, über die der
Router das GW erreichen können müsste.
Und die IP auf dem WAN interface verschwindet ja auch nicht, nur weil es
beim LAN Interface eine überlappende Route gibt.
Daniel A. schrieb:> Anders als bei 2001:af:31::/127 und> 2001:af:31:ff00::1/48 ist das GW zwar nicht in dem Subnet, aber es> müsste ja immer noch die default Route ::/0 zum GW geben, über die der> Router das GW erreichen können müsste.
Nein.
Eine Route "zeigt" nur auf eine IP-Adresse, nämlich das Gateway. Also
eine Route ordnet einem prefix/länge eine Ziel-Adresse zu.
Nun muss aber der Router noch wissen, wie er das Gateway erreichen kann.
Und das kann er nur über die Schnittstellen-Adresse inkl. ihrem Prefix.
- Gateway beim Provider sei 2001:af:31::1
- Das WAN-Interface hat 2001:af:31:ff00/127
- Es gibt eine Default-Route ::/0 auf 2001:af:31::1
Aber: Wo, auf welchem Interface ist das Gateway zu finden? Das WAN kann
es ja nicht sein, denn das geht nur von 2001:af:31:ff00::0 bis
2001:af:31:ff00::1. Dort ist die 2001:af:31::1 offensichtlich nicht
dabei. Also geht es so nicht.
(Bezüglich WAN-Adresse 2001:af:31:ff00::1/48):
> Ersteres ist zwar unüblich,
Das funktioniert ja soweit, dass er den Router pingen kann.
Aber:
Ihm (bzw. dem Router) gehört ja das komplette Netz 2001:af:31::/48. Und
wenn er jetzt ein Paket z.B. für 2001:af:31:1234::/64 hat, aber keine
Interface mit dieser Adresse, dann schickt sein Router das eigene Paket
an den Router des Providers. Und dieser Router ist hoffentlich korrekt
konfiguriert, dass er dieses Paket verwirft und nicht wieder zurück
schickt, und das solange hin und her geht bis TTL abgelaufen ist...
Darum ist /127 für Provider-Uplinks sinnvoll. Kein unerwartetes
Ping-Pong und kein Angriffsvektor um Daten abzugreifen.
Einer schrieb:> Aber: Wo, auf welchem Interface ist das Gateway zu finden? Das WAN kann> es ja nicht sein, denn das geht nur von 2001:af:31:ff00::0 bis> 2001:af:31:ff00::1. Dort ist die 2001:af:31::1 offensichtlich nicht> dabei. Also geht es so nicht.
Bei meinem linux PC ist bei "ip -6 route" das Interface bei der default
route auch noch mit dabei, damit weiss er dann, wo es ist.
Aber OK, das sind wohl eigentlich 2 Routen, in dem Scenario einmal
"2001:af:31:ff00::1/128 -> ether_wan" und einmal "::/0 ->
2001:af:31:ff00::1".
Die erste Route fehlte, und deshalb ging es nicht.
Statt dem 2001:af:31::1 könnte man vermutlich auch die link locale
Adresse des GW nehmen (sofern es eine hat), bei denen gehört das
Interface ja zwingend dazu.
Daniel A. schrieb:> Statt dem 2001:af:31::1 könnte man vermutlich auch die link locale> Adresse des GW nehmen (sofern es eine hat), bei denen gehört das> Interface ja zwingend dazu.
Ja, aber die habe ich nicht.
Ich blicke gerade nicht durch die Menge an Beiträgen, IP-Adressen etc.
durch.
Nur mal zur Sicherheit: deine Gegenseite routet aber korrekt, ja? D.h.
sie routet das gesamte /48 zu einer einzelnen IP-Adresse aus einem /64er
(Sub-)Netz?
Wir hatten das mal mit der Telekom vor einiger Zeit, an einem
Business-Anschluss. Die liefern ja bei IPv4 ein /29, welches sie aber
mehr oder weniger als direkt angeschlossenes (also per ARP auflösbares)
Netz betrachten, sodass man nicht noch irgendwelche Gateway-Netze etc.
davon abziehen muss, sondern alle 8 Adressen nutzen kann. Nun haben sie
das dummerweise standardmäßig mit IPv6 genauso gemacht, alle /48 wurden
also als lokal anliegend betrachtet und hätten am WAN per NDP aufgelöst
werden müssen. Zwar kann man auch sowas wie ein Proxy-NDP aufsetzen,
aber das ist natürlich völlig daneben, denn man will ja schließlich eine
(variable) Anzahl an /64-Netzen hinter dem Gateway/Firewall routen.
Die Lösung hier war, mit der Telekom zu verhandeln, dass sie das Setup
von "/48 direkt anliegend" auf "/64 direkt anliegend" (mit zwei
bekannten Adressen auf beiden Seiten) und "/48 darüber geroutet"
geändert haben. Danach ging alles wie erwartet.
Wie wunderbar dokumentiert warum sich IPV6 nur so zögerlich durchsetzt.
Die konfigurationsreiche Featuritis die diesen Standard begleitet kann
man doch nur als Pfusch bezeichnen. Hatte seinerzeit mal eine ganze
Woche lang versucht, meine Geräte so von außen erreichbar zu machen- und
bin schließlich doch wieder zu V4 zurückgekehrt...
Robin schrieb:> Die konfigurationsreiche Featuritis die diesen Standard begleitet kann> man doch nur als Pfusch bezeichnen.
Selten so einen Quatsch gelesen, sorry.
Wenn (wie im Falle der Telekom) ein ISP per default mit einem
Sch***-Setup daher kommt (nur, weil sie es bei IPv4 genauso gemacht
haben), dann ist wer daran Schuld? IPv6?
> Hatte seinerzeit mal eine ganze Woche lang versucht, meine Geräte so von> außen erreichbar zu machen
Ich habe es eine Stunde lang versucht – seitdem sind sie erreichbar.
IPv6 ist kein IP mit mehr Adressbits, sondern geht auch ein paar andere
Schwächen von IPv4 an. Man kann also nicht alles Wissen aus IPv4 direkt
weiternutzen. So ist die Branche eben. Ab und zu gibt's Neues, und man
hat die Wahl zwischen lernen und meckern.
Bei mir war das dynamische Präfix etwas lästig (statisch macht mein ISP
nicht, hab angerufen). Da muss ich alle Einträge auf meinem DNS Server
dynamisch updaten bei änderungen. (Und für glue records beim Registrar
kann ich das nicht machen, deshalb sind diese (und nur diese) immer noch
nur IPv4).
Aber ansonsten gieng alles recht problemlos. Den LAN Clients hab ich ein
globales prefix weitergegeben. Die Server habe ich analog zum IPv4 Netz
statisch per ULA konfiguriert, (sind bei mir fc00:4::10.60.N.X/120,
analog zu den IPv4 10.60.N.X/24), und per NAT in einem Script auf ein
globales prefix gemappt. Die Protokolle für ARP und DHCP sind zwar
andere, und ich kann im (W)LAN nicht explizit die addressen vergeben
(manche Geräte bestehen auf SLAAC), aber DNS, Routen, die meisten
Firewall regeln, etc. kann ich alles exakt analog aufbauen. Mein eigener
MITM Proxy brauchte auch noch ein paar Anpassungen (das Ding hat jetzt
ein eigenes WLAN, weil ich bei meinem iPad das IPv6 Gateway nicht
manuell setzen kann), aber das war managebar.
Ein paar neue Dinge hab ich auch noch gelernt, wie z.B. wie z.B. die
diversen ICMPv6 Nachrichten, dass in IPv6 eingebettete IPv4 Adressen von
vielen Tools nicht richtig behandelt werden, oder auch dass Server ohne
link-local adresse auskommen, aber router diese zwingend für die router
advertisements brauchen.
Das lästigste war definitiv herauszufinden, wie man all die
automagischen autokonfigurationen ausschaltet, dort, wo ich sie nicht
haben will und nicht brauche. Das, und SLAAC. Dass ich die IPs im LAN
nicht explizit vergeben kann, gefällt mir gar nicht.
Gelohnt hat es sich nicht wirklich. Meine WebRTC Konnektivität ist nun
etwas besser, und theoretisch könnte ich jetzt direkt per SSH auf alle
meine Server / Container zugreifen (frog-dmz.dpa.li, spider-dmz.dpa.li,
etc.), wenn ich an einen Ort käme, wo es auch IPv6 gibt, aber in der
Praxis sind das nur Spielereien, die mir nicht wirklich was gebracht
haben. Die Smartphones / deren Provider, z.B., hier, scheinen kein IPv6
zu haben...
Daniel A. schrieb:> Die Smartphones / deren Provider, z.B., hier, scheinen kein IPv6 zu> haben...
In D haben mindestens Telekom und O2 auch IPv6. Kann aber gut sein, dass
man das in den Einstellungen vom APN eigens aktivieren muss.
Ich habe hier Sunrise, mein Vater hat beim Arbeitstelefon Swisscom. (CH)
Edit: Danke für die Screenshots, dort musste ich es tatsächlich noch
einschalten. Jetzt gehts.
Edit edit: Zu früh gefreut. Die IPv6 test Seite geht trotzdem nicht...
Robin schrieb:> Sondern ausgesprochen ärgerlich wenn es ohne Netzwerkstudium nicht> (mehr) geht.
Auch für das Einrichten von IPv4 musste man irgendwie schon ein wenig
Ahnung haben vom zugrunde liegenden Netzwerkprotokoll. Das ist bei IPv6
nicht anders.
Daniel A. schrieb:> Gelohnt hat es sich nicht wirklich.
Lohnen tut es sich vor allem dann, wenn man vielleicht noch hie und da
VPNs aufbauen möchte. Da kann es bei diesem RFC1918-Krimskrams nämlich
ganz schnell mal passieren, dass jemand anderes dann doch irgendwo schon
die gleichen Adressen verwendet, zu dem man eigentlich eine Verbindung
gern hin bekommen möchte.
Auch ansonsten ist der Wegfall von NAT ein Segen. Hätte halt nur schon
20 Jahre früher durchgezogen werden sollen, statt überhaupt erst RFC1918
einzuführen. Da wären vielen Netzwerkern mächtig graue Haare erspart
geblieben.
> Bei mir war das dynamische Präfix etwas lästig
Kann ich mir gut vorstellen. Ist auch völlig unverständlich, wofür die
Provider das immer noch machen – natürlich abgesehen davon, dass
irgendein Marketingfritze meint, dass alles andere halt "business" sein
müsse, dem man entsprechend mehr Geld abknöpfen kann.
Thread beobachten
Seitenaufteilung abschalten