Re: [Wien] Ipv6 in Wien

[Erich N. Pekarek]

Hallo Mike!

Am 2016-01-06 um 21:47 schrieb Mike B. Kerber:
On 2016-01-06 13:23, Erich N. Pekarek wrote:
...
Am 2016-01-06 um 12:28 schrieb Mike B. Kerber:
...
Ich habe einen Nachbarknoten  zum OZW, der mittels 6er Tunnel angebunden
ist, habe nach den IPv6 vorgaben meine Knoten-IPv6 berechnet und im
Openwrt statisch zum 0xff device eingetragen.
Da kann ich nicht ganz folgen... OZW ist ja grundsätzlich ein
IPv6-Knoten... ist Dein Partnerdevice dort keines oder geht es um
einen Backup-Tunnel?
Sorry schlechter Satz; Weil OZW via tunnel angebunden ist und damit IPv6
hat, habe ich eben IPv6 statisch configuriert und keinen Tunnel gemacht.
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.
...
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.

Die "6over4 Configs" betreffen das ebenso dort beschriebene Mapping der 
0xFF-IPv4-Adressen auf den Adressraum innerhalb des zugewiesenen Prefix. 
Warum das so gemacht wurde, wenn das Mapping einer /32 Ipv4 auf ein /72 
IPv6 in diesem Fall nur einzelne IPs betrifft, verstehe ich nach wie vor 
nicht, vor allem, da sich daraus unzusammenhängende Nummerierungen 
ergeben, die Adressraum im /52 belegen. Es ergibt für mich keinen Sinn, 
ist aber so. In der Regel kannst Du das ignorieren, da das Konfigurieren 
von Aliases in LuCI sowieso nicht mehr in der damaligen Form vorgesehen 
ist (außer man macht das manuell).
Könnte man ein Manual für die annahme machen, man ist in einem
IPv6-nativ netz?
Die Anleitung hierfür ergibt sich aus dem bisherigen IPv6-Konzept und
den Anleitungen zur BFV-Firmware. Zugegeben sie ist nicht optimal, wie
meines Erachtens das bisherherige Konzept Lücken offen lässt.
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]
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.
  das könnte man auch automatisch machen indem
man das skript zur ipv6 berechnung in den redeemer frickelt, das würde
technisch nicht so versierten usern uu helfen (automatische vorgabe von
router ID, device ID)
Eine php-(serverseitig)/lua-(routerseitig) basierte DDNS-Variante (die
eben nicht nur eine Adresse aktualisieren kann) wäre vermutlich die
nutzerfreundlichste Möglichkeit dazu.
c) ist das statische IPv6/OLSRv6 ok oder soll ich den wieder deaktivieren?
Laut IPv6-Konzept hat jeder Knoten sein eigenes /52-Hostnetz u.z.
unabhängig vom Netz des Tunnels.
OLSR sollte für den Rest sorgen.

Sinnvoller wäre es freilich, wenn man für das Routing nur mit den
EUI64-Adressen (fe80::+MAC-Adresse/128; prefix fe80:(ffff)::/64)
arbeiten würde und das /52 (oder die selbst daraus den Routern
zugeteilten /64 oder größer...) per HNA ankündigte und per
radvd(+dhcpv6) im internen Netz weiter verteilte - aber das wurde
-obwohl es einfacher wäre- leider bisher nicht so gehandhabt.
das sollte mit den letzten beiden openwrts eigentlich gut gehen.
Keine Ahnung, OpenWRT habe ich momentan kaum noch in Verwendung und auch 
keine Zeit zum damit herumspielen.
Über die Bordmittel verfügen die OpenWRTs jedoch.
Nach dem Konzept solltest Du aber gemäß Umrechnungstool auf obgenannter 
Seite vorgehen.
Damit würden auch die von Dir angesprochenen Adress"konflikte"
(welches Netz nehme ich heute?) hinfällig.

d) wo gibts die Patches die offenbar in der Bubbles drinnen sind für
anzeigen der OLSR IPv6 nachbarn bzw fürs show/hide IPv6 ?
In Bubbles und Co ist das Problem, dass der Port, auf dem das
OLSR-Json, das den Status ausgibt, belegt ist. Daher funktioniert die
Anzeige in einigen Varianten nur für je ein Protokoll. Das lässt sich
meines Wissens mit einem Binding an die jeweilige Interface-IP und das
UUID-File beheben. Ich kann das momentan nicht testen.
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 ;-)
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).
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).
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.
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
<<attachment: erich.vcf>>--
Wien mailing list
Wien@lists.funkfeuer.at
https://lists.funkfeuer.at/mailman/listinfo/wien