[IPv6-wien] [Wien] Ipv6 in Wien

[Mike B. Kerber]

Hallo!

....
> Dann folge bitte den Anweisungen auf http://www.ipv6.wien.funkfeuer.at/.
> Ich persönlich betrachte abweichend dazu die Router ID 0 und Device ID
> 0 als "reserved" (da ich vom Mapping Anderes erwarte) und beginne bei
> beiden pro Knoten stets bei 1.
Ok, das habe ich gemacht. Hinsichtlich des IP-mappings ist das ja alles
recht klar geschrieben... ;)
>> ...
>>>> a) Die Manuals bzgl IPv6 beinhalten im wesentlichen nur Tunnelsetups.
>>>> Ich denke aber, dass es nicht sinn ist für jeden knoten einen
>>>> 6erTunnel
>>>> zu machen, wenn die nachbarn schon ipv6 sind, oder ist das der Plan?
>>> Welche Manuals sprichst Du an?
>>> Wenn es der Plan wäre, so wäre es Irrsinn ohne Methode - IMO.
>> In den Anleitungen (manuals auf
>> https://wiki.funkfeuer.at/wiki/Arbeitsgruppe_IPv6) sind nur 6over4
>> Configs.
> Jein. Die von mir obgenannte URL beinhaltet ein sechs Seiten
> umfassendes Konzept, bei dem Mesh-Nodes auf den Mesh-Interfaces ganze
> /64 nutzen von denen OLSR (v1) nur  je 1 /128 zum Routen nützen kann,
> und das intern je nur eine /128 eines gemeinsamen /64 aus dem
> Site-Prefix /52 nutzt - Begründung: Backbone-Lan... Die davor
> liegenden Seiten befassen sich mit "Enduser"-Knoten.
Das Konzept ist für jemanden mit Kenntnissen ein recht gutes
Infomaterial, für jemanden der eine IP6 Insel erweitern will und sich uu
uci commands/luci infos erhofft ist es uu wenig. Vermutlich ist aber
diese Zielgruppe, die das auch "IPv6-haben-wollen" rufen klein. 

...
>> Aus den Konzept PDFs plus openwrt Manual habe ich eben abgeleitet wie
>> ich eine statische ipv6 zum vorhandenen devices dazu eintrage (ohne über
>> die neuen wan6,...) zu gehen und den olsrd6 zu aktivieren.
>> Eine direkte beschreibung die ohne tunnel auskommt habe ich nicht
>> gefunden...
> OLSR v1 benötigt je eine Instanz für IPv4 und IPv6.
> Befindet sich auf der Gegenseite ein für IPv6 konfigurierter Router,
> so funktioniert das für IPv6 in gleicher Weise wie bei IPv4. Achte
> auch hier auf den richtigen Broadcast - pardon -  Multicast. Dann
> sollte das auch klappen
> AFAIK: FF02:0:0:0:0:0:0:6D     LL-MANET-Routers     [RFC5498]
Das hat openwrt gleich so gemacht und ich habe es überprüft. und mit den
Daten von OZW überprüft.
>>>> b) die .SIX.funkfeuer adressen scheinen mit dem Tunnel zu kommen, ist
>>>> das richtig?
>>> Da mir ein "offizieller" IPv6-Tunnelserver nicht bekannt ist, kann ich
>>> nur spekulieren.
>> dort wo tunnelxxx.six.funkfeuer.at?! ankommen ;)
> Ja, jetzt sehe ich das auch. Markit war zuletzt noch strikt gegen die
> Untertunnelung...
>> ...
>>> ...
>> ...
>>>> b1) könnte/sollte man die gewählte ipv6 für den Knoten.router.device
>>>> (bzw OLRD originator IP) auch im redeemer eintragen (können) => DNS
>>>> automatisch wie bei ipv4?
>>> Könnte man, aber es ist meines Wissens noch nicht implementiert.
>>> Es kann aber sinnvoller sein, die Zonen dem jeweiligen Node-Betreiber
>>> zu delegieren, da Hostnetze ja gerade zur Selbstverwaltung geschaffen
>>> wurden.
>> Stimmt, der Prefix bliebe aber ja zum selbstverwalten, die originator
>> ips vom olsrd aber nach dem vorgeschlagenen schema vorzugeben ist,
>> gerade für unwissende/einsteiger, eine nette idee finde ich. besonders
>> wenn es das tool gibt und ein durchdachtes schema (ich liebe logik auch
>> in der IP adressen/DNS vergabe... macht ordnung und ist super fürs
>> fehlersuchen)
> Da man im Redeemer stets auch die MAC-Adresse eines Devices
> (richtiger: Interfaces) eintragen konnte, und die MAC sich bei einer
> EUI64-Linklokalen Adresse nicht ändert (zumindest nicht ganz siehe
> reserved/lokal MAC), wäre es eigentlich noch viel naheliegender, OLSR
> mit den Link-Lokalen Adressen zu füttern und die vorhandenen Daten zu
> nützen. Zwar würde beim Austausch eines Routers die oder Interfaces
> die MAC sich ändern, was im Gegensatz zur anderen Lösung Mehraufwand
> bedeutet, aber das wäre andererseits ein Grund, die Daten dort aktuell
> zu halten.
> Die Verwendung link-lokaler Adressen in Kombination mit gerouteten
> Prefixes stellt in v6 ja keinen Widerspruch dar, man kann also
> Fähigkeiten und Funktionsumfang step by step entwickeln. Eigenes DNS
> oder Gratis-DNS-Server im Internet sind nicht das Problem. Eine
> Möglichkeit zur Delegation via Redeemer wäre jedoch wünschenswert.
> Ein Automatismus ist im gegenwärtigen Konzept nur aus dem
> v4/v6-Mapping ableitbar, aber das Konzept ist in diesem Punkt nicht
> schlüssig, denn es hat das DNS außer Acht gelassen.
Ich denke auch, das man die autoconfig möglichkeiten von ipv6 gut nützen
könnte eben auch mehrere IPs pro interface, das letzte openwrt hat da
etliche einträge im changelog und geht denke ich recht gut.
> ....
>> Das default openwrt hat nur eine olsrd status seite und die ist anders
>> als die bubbles, zumind auch in chaos calmer...
> Das Default OpenWRT hat kein Mod-Freifunk und dgl. inkludiert ;-)
Das kann man aber leicht reinbauen auch den OLSRd damit man da nicht
erst packerl installieren muss.
> Die Statusseite, die auf dem  olsrd-mod-jsoninfo basiert, tat dies
> bisher in der default-Konfiguration nur entweder über IPv4 oder IPv6.
> Txtinfo oder httpinfo sind ein anderes Thema.
> Irgendwo im Lua-Code war hat da ::1 gefehlt oder am Namen, der in der
> Hosts-Datei fehlte. Keine Ahnung mehr... Ungefähr zu der Zeit habe ich
> begonnen AirOS auf der Nanostation zu nutzen und mich nicht weiter
> damit befasst. In CC sollte die UUID das Problem lösen, aber sicher
> bin ich mir nicht.
> Joe weiß wohl wie das geht, da der 45deg den Fehler nicht hat (ist
> auch noch eine ältere Firmware).
Ja genau, ich hab nur upstream keine Patches gesehen bisher. aber ein
teil ist im javascriptcode der html-seite, nach dem kann ich suchen ;)
>>>> Wenns auf die eine oder andere Frage antworten gibt wäre ich dankbar,
>>>> besonders ein Kommentar zu c) wäre nützlich ;)
>>> Die Antwort auf "was soll ich tun" lautet: Alle Interfaces außer dem
>>> lokalen Tunnelendpoint sollten Subnetze des Dir zugewiesen /52-Range
>>> Deines Knotens benützen, eventuell benötigst Du eine IPv6-HNA hierfür,
>>> falls Bereiche des /52 nicht geroutet werden (weil OLSR[v1] ja sonst
>>> nur /128 kennt).
>> ok, das problem stellt sich mir zzt nicht aber ich denke das Konzept
>> würde zumindest mir da reichen, dieser teil ist recht ausführlich im
>> LUCI abgebildet.
> Naja, zumindest für den reinen Mesh-Knoten reicht das /64 ohnehin.
> Falls dahinter Router betrieben werden, die ihrerseits IPv6
> bereitstellen sollen, sollte jedem Nutzer eigentlich wieder ein /64
> zur Verfügung stehen. (darüber kann man streiten; Begründung pro: IoT;
> contra: Vergeudung).
/64 ist immer noch zu gross, wenn alle diese IPs genutzt werden und man
die sicherheit aller dieser devices sicher stellen muss (brrrrrrr!!!!)
ein horror gedanke ;)
Wenn ich sehe wie die Distro der Wärmepumpe gewartet wird, progfehler
dort und.... obwohl die sogar vom Konzept gut geplant ist.
Das soll besser nicht alles mit dem grossen internetz verbunden sein ;)
>>>> mlg
>>>> -mike
>>> Ich hoffe, dass Deine Fragen trotz der Unschärfe beantwortet wurden.
>> ja es war durchaus erhellend. Weil ichs vergessen habe: der knoten ist
>> nanom5.lzstr168.wien.funkfeuer.at - das fragezeichen in der ipv6 liste
>> von 45deg.ozw.wien.funkfeuer.at
> Wegen der fehlenden Namensauflösung...
> Gottfried kann Dir den Namen eintragen, wenn Du ihn bittest - oder Du
> lässt Dir eben die Zone delegieren.
> He.net Tunnelbroker bietet u.a. auch gratis-DNS-Server für solche
> Zwecke an.
> Das gute alte "host" Kommando unter Linux liefert bei Abfrage eines
> bestehenden PTR (auf v6) Eintrages übrigens das richtige Format
> (ip6.arpa) für Tippfaule und CnP-Fans.
DNS ist nicht wirklich notwendig. wenn ich unbedingt IPv6 nativ&only auf
den router will (und das ist der Spass das dies jetzt geht) dann mach
ich einen eintrag in der hosts datei und gut ists (da kann ich auch
einen kurz alias machen ;)
>>> LG
>>> Erich
>>>
>>> P.S.: CC an ipv6-Liste, da Stefan offenbar ein weiteres IPv6-Treffen
>>> einberufen hat, von dem ich erst nach der Terminvereinbarung via
>>> Doodle über die Liste erfahren habe.
>>> Eventuell kann man diese Problematik dort ansprechen.
>> OK, danke für das weiterleiten. Sonst: danke das ipv6 schon so weit
>> ist ;)
> Danke!
>>
>> mlg
>> -mike
>>
>>
> LG
> Erich
mlg
-mike


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://lists.funkfeuer.at/pipermail/ipv6-wien/attachments/20160107/8de1f475/attachment.sig>