Projekt IPv6: Unterschied zwischen den Versionen
Leo (Diskussion | Beiträge) (→Adressen/Adressbereiche: inhaltlich erweitert) |
Leo (Diskussion | Beiträge) (→Offene Fragen: kleinere Änderungen/Erweiterungen) |
||
Zeile 17: | Zeile 17: | ||
==== OLSR-Version ==== | ==== OLSR-Version ==== | ||
− | * Soll das ganze Netz erstmal von OLSRv1 auf OLSRv2 migriert werden? | + | * Soll das ganze Netz erstmal von OLSRv1 auf OLSRv2 migriert werden oder soll es einen Parallelbetrieb von beiden Protokollen geben, sodass am Ende OLSRv1 einfach ausgeschaltet werden kann? |
** Dieses komplexe Thema wurde auf einer extra Seite diskutiert: https://systemausfall.org/wikis/spontanplanung/OLSR1-OLSR2-Migration | ** Dieses komplexe Thema wurde auf einer extra Seite diskutiert: https://systemausfall.org/wikis/spontanplanung/OLSR1-OLSR2-Migration | ||
− | ** '''Ergebnis''': Migration ist komplex und der Teufel (Routingschleife) liegt im Detail. Daher | + | ** '''Ergebnis''': Migration ist komplex und der Teufel (Routingschleife) liegt im Detail. Daher wird es einen Parallelbetrieb geben und langsam alle Knoten mit OLSRv2 ausgestattet. |
* Folgende Fragen müssen bei Einführung von '''OLSRv2''' geklärt werden: | * Folgende Fragen müssen bei Einführung von '''OLSRv2''' geklärt werden: | ||
** Wie sieht Ersatz für Nameservice Plugin aus? | ** Wie sieht Ersatz für Nameservice Plugin aus? | ||
*** Hier gibt es nichts vergleichbares. | *** Hier gibt es nichts vergleichbares. | ||
− | *** | + | *** Idee1: nameservice-Plugin selbst basierend auf den oonf-Framework implementieren und als Teil der IPv6-Einführung auch OLSRv2 einführen (vorher brauchen wir also auch einen OLSRv2-Migrationsplan) |
**** Nach Diskussion auf der OLSR ML waren sich alle einig, dass dies der "unsaubere" Weg ist. Ein Mechanismus zum Verteilen von Informationen im Netz muss unabhängig von der Routingimplementierung sein. | **** Nach Diskussion auf der OLSR ML waren sich alle einig, dass dies der "unsaubere" Weg ist. Ein Mechanismus zum Verteilen von Informationen im Netz muss unabhängig von der Routingimplementierung sein. | ||
− | ** Was ist Ersatz für | + | *** Idee2: Nutzung von HNCP (ähnlichen) Protokollen. Sie hierzu auch weiter unten bei "Prefix Announcement". |
− | *** | + | ** Was ist Ersatz für [[Ondataservice]]? Über diesen Mechanismus werden derzeit Inventarinformationen aller Knoten eingesammelt. |
+ | *** In OLSRv2 gibt es ein Netjson Plugin, welches Informationen des Knoten exportieren kann. Netjson ist jedoch nur ein Daten-Austauschformat. Es fehlt ein Mechanismus, welcher die Daten vom AP zu einem (zentralen) Ziel schickt, wo die Daten gesammelt werden. Hier selbst was schreiben? | ||
** Wie sieht eine Migrationsstrategie von v1 nach v2 aus? | ** Wie sieht eine Migrationsstrategie von v1 nach v2 aus? | ||
*** Man kann beide parallel auf einem AP laufen lassen, aber dann müssen beide in unterschiedliche Routingtabellen schreiben | *** Man kann beide parallel auf einem AP laufen lassen, aber dann müssen beide in unterschiedliche Routingtabellen schreiben | ||
*** Wenn man OLSRv1/IPv4 und OLSRv2/IPv6 macht, gibt es keinerlei Besonderheiten zu berücksichtigen. | *** Wenn man OLSRv1/IPv4 und OLSRv2/IPv6 macht, gibt es keinerlei Besonderheiten zu berücksichtigen. | ||
− | |||
Wir beginnen OLSRv2 im Opennet einzuführen. Mehr Infos sind unter [[OLSRv2]] zu finden. | Wir beginnen OLSRv2 im Opennet einzuführen. Mehr Infos sind unter [[OLSRv2]] zu finden. | ||
+ | |||
==== Adressen/Adressbereiche ==== | ==== Adressen/Adressbereiche ==== | ||
* '''Welche IPv6 Präfixe''' sollen genutzt werden für die APs? | * '''Welche IPv6 Präfixe''' sollen genutzt werden für die APs? | ||
− | ** ''Vorschlag'': | + | ** ''Vorschlag'': idealerweise würden wir statt ULA ein eigenes Provider-unabhägiges Präfix verwenden |
− | *** notfalls | + | *** notfalls nehmen wir ein ULA: fd32:d8d3:87da::/48 (wurde unter https://www.sixxs.net/tools/grh/ula/ registriert. |
− | + | *** zusätzlich haben wir einen ausreichend großen provider-dependant Adressblock, siehe [[Server/gai]] | |
* Mit welchem '''Mechanismus''' soll '''Adressvergabe''' im Mesh umgesetzt werden? | * Mit welchem '''Mechanismus''' soll '''Adressvergabe''' im Mesh umgesetzt werden? | ||
** Knoten im Mesh benötigen nur 1 routbare-IPv6 Adresse, unabhängig von der Anzahl der Interfaces. | ** Knoten im Mesh benötigen nur 1 routbare-IPv6 Adresse, unabhängig von der Anzahl der Interfaces. |
Version vom 21. April 2017, 23:08 Uhr
Team |
![]() Projekt IPv6 |
Treffen: nur bei Bedarf |
IPv6 |
Mitglieder: Lars, Martin, Mathias M |
Kontakt: admin@opennet-initiative.de |
Inhaltsverzeichnis |
IPv6 im Opennet
IPv6 wurde bereits seit 2007 im Opennet testweise betrieben. Anfangs gab es einen Tunnel zu einem IPv6 Provider (SixXS). Später gab es auch native IPv6 Adressen für einige User dank rbone. All dies war aber nur Testbetrieb und sollte eine generelle Machbarkeit zeigen. Die gewonnenen Informationen haben einen Beginn dargestellt und weitere Diskussionspunkte offengelegt (siehe Liste unten).
Auf dieser Seiten werden Informationen zur IPv6 Migration zusammengestellt. Vor allem sollen hier festgehalten was diskutiert wurde, welche Möglichkeiten zur Diskussion standen und warum wir uns für einen Weg entschieden haben. All diese Informationen sind möglicherweise auch für andere von Interesse.
Diskussionspunkte
Offene Fragen
OLSR-Version
- Soll das ganze Netz erstmal von OLSRv1 auf OLSRv2 migriert werden oder soll es einen Parallelbetrieb von beiden Protokollen geben, sodass am Ende OLSRv1 einfach ausgeschaltet werden kann?
- Dieses komplexe Thema wurde auf einer extra Seite diskutiert: https://systemausfall.org/wikis/spontanplanung/OLSR1-OLSR2-Migration
- Ergebnis: Migration ist komplex und der Teufel (Routingschleife) liegt im Detail. Daher wird es einen Parallelbetrieb geben und langsam alle Knoten mit OLSRv2 ausgestattet.
- Folgende Fragen müssen bei Einführung von OLSRv2 geklärt werden:
- Wie sieht Ersatz für Nameservice Plugin aus?
- Hier gibt es nichts vergleichbares.
- Idee1: nameservice-Plugin selbst basierend auf den oonf-Framework implementieren und als Teil der IPv6-Einführung auch OLSRv2 einführen (vorher brauchen wir also auch einen OLSRv2-Migrationsplan)
- Nach Diskussion auf der OLSR ML waren sich alle einig, dass dies der "unsaubere" Weg ist. Ein Mechanismus zum Verteilen von Informationen im Netz muss unabhängig von der Routingimplementierung sein.
- Idee2: Nutzung von HNCP (ähnlichen) Protokollen. Sie hierzu auch weiter unten bei "Prefix Announcement".
- Was ist Ersatz für Ondataservice? Über diesen Mechanismus werden derzeit Inventarinformationen aller Knoten eingesammelt.
- In OLSRv2 gibt es ein Netjson Plugin, welches Informationen des Knoten exportieren kann. Netjson ist jedoch nur ein Daten-Austauschformat. Es fehlt ein Mechanismus, welcher die Daten vom AP zu einem (zentralen) Ziel schickt, wo die Daten gesammelt werden. Hier selbst was schreiben?
- Wie sieht eine Migrationsstrategie von v1 nach v2 aus?
- Man kann beide parallel auf einem AP laufen lassen, aber dann müssen beide in unterschiedliche Routingtabellen schreiben
- Wenn man OLSRv1/IPv4 und OLSRv2/IPv6 macht, gibt es keinerlei Besonderheiten zu berücksichtigen.
- Wie sieht Ersatz für Nameservice Plugin aus?
Wir beginnen OLSRv2 im Opennet einzuführen. Mehr Infos sind unter OLSRv2 zu finden.
Adressen/Adressbereiche
- Welche IPv6 Präfixe sollen genutzt werden für die APs?
- Vorschlag: idealerweise würden wir statt ULA ein eigenes Provider-unabhägiges Präfix verwenden
- notfalls nehmen wir ein ULA: fd32:d8d3:87da::/48 (wurde unter https://www.sixxs.net/tools/grh/ula/ registriert.
- zusätzlich haben wir einen ausreichend großen provider-dependant Adressblock, siehe Server/gai
- Vorschlag: idealerweise würden wir statt ULA ein eigenes Provider-unabhägiges Präfix verwenden
- Mit welchem Mechanismus soll Adressvergabe im Mesh umgesetzt werden?
- Knoten im Mesh benötigen nur 1 routbare-IPv6 Adresse, unabhängig von der Anzahl der Interfaces.
- DHCPv6 wäre der ideale Weg. Da wir aber ein Layer3 Netz haben, ist der Multicast Mechanismus von DHCPv6 nicht förderlich.
- DHCP-Anfragen lassen sich auf konventionellem Wege (Multicast) weder zum Server leiten, noch ist deren Antwortweg mit üblichen Mitteln definierbar
- DHCP Relay mit Unicast wäre hier ein mögliche Lösung
- odhcp kann Relay, jedoch leider kein Unicast Relay (Stand Jan 2017). Es gibt hierzu ein Feature Request
- für DHCPv6-PD (Prefix Delegation) gelten die gleichen Einschränkungen
- Radvd (stateless autoconfiguration) arbeitet nur im link-local-Bereich - auch hier hätten wir also Schwierigkeiten, eine IP (oder Netze) zu ermitteln
- statischen Festlegung: wenn ein Knoten gültige Prefixe kennen würde, könnte sich der AP per EUI64 selbst ein IP geben
- Wie sollen Präfixe im Netz bekanntgemacht werden (Prefix Announcement)?
- Algo zur Ermittlung von IPs der APs?
- menschen-merkbar: Statisch durchnummeriert angefangen bei 1. Somit ist bspw. AP1.1== AP1 und AP2.1==AP256
- DNS Einträge können wie bisher vorher festgelegt werden. Zusätzlich wären die IPs für Menschen noch schreibbar. Hat evtl. Vorteil wenn DNS mal nicht funktioniert.
- menschen-nicht-merkbar: EUI64 (Prefix+MAC)
- Mechanismus zur DNS Registration wird benötigt! DDNS wäre hier eine Idee.
- Nachteil: IP ist halt nicht menschen-merkbar. Spielt das ein Rolle?
- menschen-merkbar: Statisch durchnummeriert angefangen bei 1. Somit ist bspw. AP1.1== AP1 und AP2.1==AP256
- Algo für statisches IPv6 Netz (je AP ein /64 Netz) festlegen
- Vorschlag: siehe Berechnungsvorschlag basierend auf AP-Nummer
- Mit welchem Mechanismus sollen dynamische /6x Bereiche vergeben werden?
- DHCPv6 kann auch Prefix-Delegation. Mit diesem Mechanismus kann man zusätzliche Netze beim Server anfragen.
- Wie kann man auf dem Server beeinflussen, dass ein Client nicht immer die gleichen Netze bekommt?
Verschlüsselung
- Kann man OpenVPN durch IPSec ersetzen?
- IPSec kann im tunnel mode den Verkehr anderer Netze tunnel. Hierfür wird KEIN zusätzliches Interface erstellt.
- Linux IPSec tool (racoon) kann mit PKI Infrastruktur umgehen
- Benötigen wir noch einen Mechanismus, um Aktionen beim Starten/Beenden von VPN Tunneln durchzuführen? Wenn ja, wie soll das umgesetzt werden?
- Vorschlag: Einfach mal umsetzen und schauen wie weit man kommt.
- Gibt es Performance-Unterschiede zwischen beiden Methoden?
- Einen "kleinen" Vergleich gibt es unter https://web.archive.org/web/20100107165044/http://stuff.skoberne.net/IPSec_and_OpenVPN_Performance.pdf
- Gibt es Information zu 100MBit/s und mehr?
Dieser Punkt wird ausführlich auf einer eigenen Wiki Seite diskutiert, siehe Tunnelkonzept.
UGW-AP Anbindung
- Paketweiterleitung durch UGW-AP an UGW-Server: Wenn ein User-APs einen VPN Tunnel zum UGW-Server aufbaut, müssen diese Pakete durch den UGW weitergeleitet werden. Hier gibt es mehrere Möglichkeiten.
- SNAT+DNAT (Portweiterleitung): Wie bisher, bei IPv4, werden von einem ONI Node stammende Pakete per Masquerade an den UGW-Server weitergeleitet. Im diesem Fall baut der UGW-Server einen Tunnel zwischen seiner public IP und der public IP des UGWs auf (aus Sicht des UGW Servers). Zu klären: Muss der VPN-Tunnel-Verkehr immer über diesen UGW geleitet werden? Ansonsten ändert sich auch die public IP der einen Tunnelseite.
- Vorteil: Es gibt keine doppelte Verschlüsselung, weil Verkehr durch Port-forwarding weitergeleitet wird.
- Nachteile:
- UGW ist für Dauer der VPN Verbindung festgelegt.
- Desweiteren ist eine Pflege der Ports für das Forwarding nötig.
- Zusätzlicher Verwaltungsaufwand im Vergleich zum nativen Routing (siehe unten).
- SNAT + HNA (via Routen-Announcement): die UGW-APs announcieren die öffentlichen IPs der UGW-Server. Jeder Nutzer-AP verbindet sich mit der öffentlichen IP seines gewählten UGW-Servers. Daraufhin wird die ideale Route durch das Routing-Protokoll bestimmt. Der Verkehr läuft nicht durch den Mesh-Tunnel zwischen UGW-AP und UGW-Server, sondern direkt über das WAN-Interface (so war es auch bisher - es erfolgt jedoch kein DNAT).
- Diese Option wollen wir nur mit einem besseren Routing-Protokoll (also OLSRv2) nutzen, da wir den aktuellen Routing-Entscheidungen von OLSRv1 nicht unkritisch gegenüberstehen.
- Es ist zu prüfen, ob sich auch die Verbindungsqualität zwischen UGW-AP und UGW-Server via OLSRv2 in die Metrik des Announcements einbinden lässt.
- Der UGW-Server kommt mit veränderlichen Quell-IPs und -Ports seines Clients zurecht (bei OpenVPN: --float).
- natives Routing (Tunnel-in-Tunnel): Wie Pakete vom User-AP zum UGW-Server gelangen, bestimmt hier alleinig das Routingprotokoll (OLSR). Es ist nicht von einem bestimmten UGW abhängig.
- Doppelt verschlüsselt (ein Tunnel): Hier besteht ein VPN Tunnel zwischen UGW-AP und UGW-Server. Über diesen verschlüsselten Tunnel wird jeglicher Opennet-Verkehr geschickt.
- Vorteil: Einfach einzurichten
- Nachteil: Wenn ein User-AP einen VPN Tunnel zum UGW-Server aufbaut, wird der Verkehr zwischen User-AP und UGW-Server (dedizierte VPN Tunnel) hier ein zweites Mal (zusätzlich) verschlüsselt.
- Eventuell können wir auf Verschlüsselung für den Mesh-Tunnel verzichten - Performance wäre uns hier wichtiger. Hier findet ja lediglich nicht-privater Infrastruktur-Verkehr statt, bzw. Verkehr der auch im Mesh unverschlüsselt transportiert wird.
- Vorteil:
- Das Routing findet alleinig durch Routingprotokoll statt (kein Portforwarding).
- Nachteil:
- Performance von unverschlüsselten Tunneln (oder Optimierungsmöglichkeiten) ist zu prüfen.
- MTU wird reduziert (zu klären!!!) (Sollte bei IPv6 aber keine negative Rolle spielen, da Behandlung für MTU Ermittlung in IPv6 besser integriert ist, als in IPv4.)
- Vorteil:
- Doppelt verschlüsselt (ein Tunnel): Hier besteht ein VPN Tunnel zwischen UGW-AP und UGW-Server. Über diesen verschlüsselten Tunnel wird jeglicher Opennet-Verkehr geschickt.
- SNAT+DNAT (Portweiterleitung): Wie bisher, bei IPv4, werden von einem ONI Node stammende Pakete per Masquerade an den UGW-Server weitergeleitet. Im diesem Fall baut der UGW-Server einen Tunnel zwischen seiner public IP und der public IP des UGWs auf (aus Sicht des UGW Servers). Zu klären: Muss der VPN-Tunnel-Verkehr immer über diesen UGW geleitet werden? Ansonsten ändert sich auch die public IP der einen Tunnelseite.
Bisherige Einigungen/Festlegungen
- Wieviel IPs soll ein AP bekommen?
- Festlegung: Im Gegensatz zur IPv4 Welt (jedes Interface hat eine routbare IP) soll bei IPv6 nur das Gerät selbst (per loobpack Interface) eine IP haben (ULA + Public IP).
- Eine statische Adresse für jeden AP/Knoten
- Für jeden User AP (hier ist ein Endnutzer angeschlossen) wird benötigt:
- statischer /64 Block für Dienste. Wenn ein Dienst angeboten wird, darf sich die IP nicht ändern.
- dynamischer /64 Block zum Surfen. Dieser dynamische Adressblock soll sich regelmäßig (z.B. 1x täglich) ändern. Aus unserer Sicht trägt dies erheblich zum Schutz der Privatsphäre unserer Nutzer bei. Wer keinen dynamischen Bereich nutzen will, kann alternativ eine IP aus dem statische Bereich nutzen. Hier wird dem Nutzer die Wahl gelassen.
- Festlegung: Im Gegensatz zur IPv4 Welt (jedes Interface hat eine routbare IP) soll bei IPv6 nur das Gerät selbst (per loobpack Interface) eine IP haben (ULA + Public IP).
- DHCP
- Können DHCP Server unicast-only? Ansonsten brauchen wir DHCPv6 relay auf allen Knoten.
- Nein. Das ist auch explizit verboten, siehe https://lists.isc.org/pipermail/dhcp-users/2015-November/019353.html
- DHCP dynamische "Präfix-Delegation" scheint mit ISC DHCP (nicht WIDE) zu gehen: http://unix.stackexchange.com/a/168337 (Suche nach "relatively")
- Falsch, dies ist leider ein Trugschluss. Im obigen Beispiel wird nur PrefixDelegation auf dem Server konfiguriert. Alleinig die Clients bestimmen, welche Bereich daraus genutzt wird.
- Können DHCP Server unicast-only? Ansonsten brauchen wir DHCPv6 relay auf allen Knoten.
Heimnetze
- die /64-Netze erscheinen uns spontan als nicht (Homenet hätte wohl gern ein größeres)
- /48 IP Adressbereiche bekommt man bei (nicht-Reseller) Hostern mit zusätzlicher Gebühr. Weniger kommerzielle Provider bieten /48 (oder größer) kostenlos an.
- Beispiel: Hetzner bietet /56 IPv6 Netz für 49 Euro einmalig + Flexi-Pack (12,-€/Monat) an (Stand: Oktober 2015).
- Todo: Bei Hetzner nachfragen wegen Preise für a) /44 Netz und b) PI Adressbereich routen. Weiterhin bei IN-Berlin wegen PI Adressbereich routen nachfragen.
- webtropia: /64 inbegriffen, keine Erweiterung möglich
- manitu: /64 drin, Erweiterung unklar
- ovh: /64
- contabo: /112
- bei /48 verbleiben uns (bei einer angestrebten Anzahl von ca. 4000 Knoten) wohl nur /64er-Netze, wenn wir eine gewissen Unabhängigkeit von unüblichen Angeboten der Provider bewahren wollen
- prüfen, ob dies für Homenet und allgemeine heimische Anforderungen genügt
Milestones zur Umsetzung (Vorschlag)
M1:
- ULA für alle APs
- Prefix per nameservice senden
- IP = Prefix + AP Nummer (hochgezählt - int value)
- eine public IP je AP konfigurieren
- analog ULA
- ein statisches /64 je AP festlegen (evtl. Vergabemechanismus implementieren)
- Prefix (/XXX) per nameservice
- Subnet analog ULA
- IPSec als OpenVPN Ersatz konfigurieren
M2:
- dynamische /64 Netze ermöglichen
M3:
- OLSRv2 integrieren
IP Plan (Vorschlag)
Ausgangsbasis: | a:b:c::/48 Netz |
Router IP: | a:b:c::1/64 |
dyn) dynamische Nutzernetze:
- mind. 2048 User = 11Bit - mind. 2 Netze je User wegen Subnetz-Wechsel (12Bit->/52)
stat) statisches Nutzernetz:
- genau ein Netz je User (11 Bit)
--> Das /48 in /52er Netze aufteilen. Somit sind 16x /52 Netze vorhanden a:b:c:0000::/52 0000:: /64 Subnetz von UGW Server Uplink 0001:: /64 Opennet Backbone IP space (jeder Knoten bekommt eine IP aus dem Bereich) 0002-0fff:: res. a:b:c:1000::/52 1000-1fff:: statische Netze jeweils /64. Algo STAT1 unten a:b:c:2000::/52 2000-2fff:: 4096 dynamische /64 Netze a:b:c:3000::/52 ... res. a:b:c:f000::/52
Algo STAT1:
Nehme eine Ordnung auf den Nutzer APs an. Somit bekommt der erste Nutzer-AP das Netz 0, der Zweite das Netz 1 usw. Dies führt zu folgenden Netzen:
AP1.01==AP1 - a:b:c:1001::/64 AP1.55==AP55 - a:b:c:1037::/64 AP2.01==AP256 - a:b:c:1100::/64 AP2.99==AP354 - a:b:c:1162::/64 AP3.01==AP511 - a:b:c:11ff::/64
AP$1.$2 - a:b:c:(0x1000 + ( $1 - 1 ) * 255 + $2)::/64
Der AP1.55 hätte somit folgende IPv6-Adressen:
- IP im privaten Netz hinter dem AP (mit unserem ULA-Präfix): a:b:c:1037::1/64
- Opennet-IP (main-IP für OLSR, mit unserem ULA-Präfix): a:b:c:0001::0037/64
- falls er einen Tunnel ins Internet aufgebaut hat:
- mit dem Gateway-Präfix (oder mehreren): e:f:a:1037::1/64