https://docs.opennet-initiative.de/index.php?action=history&feed=atom&title=Benutzer%3ALeo%2FBlog%3A2015_September_20_22%3A29%3A35_CEST 2026-10-07T17:48:11Z Versionsgeschichte dieser Seite in Opennet MediaWiki 1.43.9 https://docs.opennet-initiative.de/index.php?title=Benutzer:Leo/Blog:2015_September_20_22:29:35_CEST&diff=27618&oldid=prev 2015-09-20T20:33:05Z

<p>Blogeintrag IPv6-Oni Treffen vom 20.9.2015</p> <p><b>Neue Seite</b></p><div>=== IPv6-Treffen (20.09.2015) ===<br /> Wir haben heute zu dritt (Mathias, Martin und Lars) Matthias im Opennet-Raum Gesellschaft geleistet.<br /> <br /> === Berliner Dinge ===<br /> * die Menschen in Berlin haben ihre Umstellung von olsr v1 auf olsr v2 folgendermaßen umgesetzt:<br /> ** IPv6-Verkehr wird via olsr v2 geroutet<br /> ** IPv4-Verkehr bleibt erstmal bei olsr v1 (wird wohl später umgestellt)<br /> * Desweiteren wird teilweise 802.11s als Mesh Standard genutzt. Dieser Mesh Standard benötigt keine Master/Client Beziehungen im 5GHz Bereich. Dies wäre sehr anstrebenswert für uns, weil dies auch dem ursprünglichen Gedanken eines Mesh Netzes entspricht.<br /> <br /> * Uns scheint eine parallele Infrastruktur (IPv4, IPv6) sehr sinnvoll. Somit können wir möglichst schnell IPv4 ablösen ohne das parallele IPv6 zu beeinflussen.<br /> * Bei der IPv6 Infrastruktur muss geprüft werden, ob OpenVPN sinnvoll ist.<br /> * IPv6 Einführung im gesamten Opennet besteht aus<br /> ** Routingprotokoll: Sollten wir OLSRv2 nutzen? <br /> ** Adressverteilung: Wie werden Prefixe verteilt? Über welchen Mechanismus werden IP Adressen reserviert? Wieviel Intelligenz muss auf dem Server oder den APs sein?<br /> ** Schützen des Datenverkehrs: Wie kann der Verkehr zwischen Endnutzer und dem Gateway, welches Verkehr ins Internet leitet, geschützt werden?<br /> <br /> === Gedanken zur Adressverteilung ===<br /> * eventuell lösen wir uns von der IP-Verteilung via OpenVPN (derzeit für alle Internetnutzenden). Generell basiert die IPv6 Adressvergabe auf Multicast. Dies ist in die derzeitige OpenVPN Konfiguration schwer integrierbar. Siehe auch Emailverkehr auf der crew-Mailingliste.<br /> * Generell sollten wir möglich fertige Tools nutzen und nur an Stellen eingereifen, an denen dies auch vorgesehen wird.<br /> * Um Informationen im Netz zu annoncieren (z.B. Präfix für Stateless-Auto-Configuration) kann wahrscheinlich das OONF Packet Socket Plugin (http://www.olsr.org/mediawiki/index.php/OONF_Packet_Socket_Plugin) für OLSRv2 genutzt werden. <br /> * Für zustandsbehaftete Adressbereiche scheint DHCPv6 das richtige zu sein. Hier gibt es an allen Stellen auch fertige implementierungen. Problem: Wie Multicast per OLSR verschicken?<br /> ** DHCPv6 soll auch per Unicast ansprechbar sein, laut RFC: &quot;Once the client has determined the address of a server, it may under some circumstances send messages directly to the server using unicast.&quot; http://networksorcery.com/enp/rfc/rfc3315.txt<br /> ** Nutzung von UNICAST Option im DHCPv6 Paket. Damit sollte der Server per Unicast antworten.<br /> ** Aus Server-Seite (ISC dhcpdv6, wide-dhcpv6) und Client-Seite (odhcp) testen.<br /> ** Eine Liste der DHCP Server könnte wiederum per OONF Packet Socket Plugin verbreitet werden.<br /> <br /> === IP-Bereiche ===<br /> * bisher diskustieren wir über zwei bzw. drei Bereiche:<br /> ** permanentes IP-Präfix für jeden Nutzer-AP (kann aus dem Internet heraus angesprochen werden)<br /> ** fluktuierendes IP-Präfix füe jeden Nutzer-AP (reduziert personifizierbare Datenspuren im Internet bei ausgehendem Verkehr)<br /> ** (optional) dauerhaft unveränderliches Präfix für jeden Router aus dem ULA-Bereich<br /> *** siehe auch http://tools.ietf.org/html/rfc6879#page-7: Verwendung von ULA-Adressen für interne Dienste, um Präfix-Änderungen (z.B. durch den/die ISPs) auszuweichen</div>

Leo