https://docs.opennet-initiative.de/index.php?action=history&feed=atom&title=Benutzer%3ALars%2FBlog%3A2016_June_18_00%3A33%3A33_CEST 2026-10-07T14:32:01Z Versionsgeschichte dieser Seite in Opennet MediaWiki 1.43.9 https://docs.opennet-initiative.de/index.php?title=Benutzer:Lars/Blog:2016_June_18_00:33:33_CEST&diff=28740&oldid=prev 2016-06-17T22:34:09Z

<p>init</p> <p><b>Neue Seite</b></p><div>=== Techniktreffen (17.06.2016) ===<br /> <br /> === OLSRv2 / IPv6 ===<br /> * wir haben möglicherweise eine Inkompatibilität zwischen OLSRv2 v0.11.7 und v0.12 entdeckt - sie wird berichtet<br /> * unsere Karte der beteiligten Knoten wächst (derzeit 11 Knoten): https://192.168.1.110/olsr2.html<br /> * Routing zwischen allen beteiligten Knoten funktioniert nun auch über gai (UGW Server) hinweg<br /> * wir haben eine Weile über einer Source-Address-Selection eines Routers gebrütet und dabei interessiert das RFC 6724 studiert<br /> ** wahrscheinlich müssen wir mehr (alle?) IPv6-Adressen der APs (also auch bisher als privat betrachtete) via OLSRv2 route-bar machen<br /> <br /> ==== Namensauflösung / Reverse-Auflösung ====<br /> * unsere handgepflegte Reverse-DNS-Tabelle übersetzt nun auch link-local-Adressen<br /> * wir haben über &quot;nsupdate&quot; als eventuellen Mechanismus zur (automatischen) Erzeugung von menschenfreundlichen AP-Bezeichnungen gesprochen<br /> ** Schlüssel- und Zugangskontrolle sind für unsere Zwecke dabei nicht relevant - es geht uns um den lease-Mechanismus und um die DNS-Zone<br /> <br /> === http/https-Dienste im Opennet ===<br /> * Fortsetzung des Gedankenaustauschs aus der admin-Mailingliste (&quot;Web-Dienste auf Knoten ohne öffentliche IP&quot;)<br /> * Zugänglichkeit für Nutzer ist in dem Vorschlag von Lars beschränkter Natur, da die Nutzer die Anforderung nicht selbst umsetzen können (stattdessen: Anfrage an die Admin-Gruppe)<br /> ** Automatisierung denkbar, jedoch mit deutlich erhöhtem Aufwand verbunden (für die zu erwartende Nutzungsintensität / den Bedarf)<br /> ** Lars hofft, mit der Verfügbarkeit von http/https-Diensten aus dem Opennet heraus ein Henne-Ei-Problem zu lösen (in anderen Worten: er hofft auf erhöhten Bedarf im Anschluss an die Verfügbarkeit)<br /> ** Mathias vermutet eher, dass es sich um das Bedürfnis einer sehr überschaubaren Nutzergruppe handelt und daher vielleicht nicht in der gemeinsamen Infrastruktur gelöst werden sollte<br /> * DNS-Detail: CNAMEs verweisend auf DNS-Round-Robin-Datensätze (also ein Name mit mehreren A-Einträgen) sind eventuell nicht zulässig</div>

Lars