Projekt IPv6: Unterschied zwischen den Versionen

Version vom 12. Februar 2016, 20:56 Uhr

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 OLSRv2 gleichzeitig mit IPv6 eingeführt werden? Wenn nein, dann darf es nicht mehrere default Routen nach draußen geben (fehlendes source-based routing). Wenn ja, dann bitte folgende Probleme klären:
  • Wie sieht Ersatz für Nameservice Plugin aus?
  • Was ist Ersatz für ondataservice?
  • 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
  • Vorschlag: 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)

Adressen/Adressbereiche

• Welche IPv6 Präfixe sollen genutzt werden für die APs?
  • Vorschlag: sofern möglich wollen wir statt ULA ein eigenes Provider-unabhägiges Präfix verwenden oder ein Präfix aus dem Freifunk-Bereich
    • notfalls (falls beides nicht klappt) nehmen wir ein ULA: fd32:d8d3:87da::/48 (wurde unter https://www.sixxs.net/tools/grh/ula/ registriert.

• Mit welchem Mechanismus soll Adressvergabe im Mesh umgesetzt werden?
  • DHCPv6 scheint nicht für unsere Zwecke geeignet zu sein, da wir kein Layer-2-Routing-Netz verwenden
    • DHCP-Anfragen lassen sich also auf konventionellem Wege weder zum Server leiten, noch ist deren Antwortweg mit üblichen Mitteln definierbar
  • da die Prefix Delegation ebenfalls Teil eines DHCP-Setups wäre, ist auch diese nicht verwendbar
  • Radvd (stateless autoconfiguration) arbeitet nur im link-local-Bereich - auch hier hätten wir also Schwierigkeiten, eine IP (oder Netze) zu ermitteln
  • somit scheint es für uns keine Variante außer der statischen Festlegung aufgrund zu definierender Kriterien zu geben
    • aktuell würden wir den jetzigen Zustand fortschreiben und die Adressvergabe basierend auf einer manuellen Reservierung vornehmen
    • automatisierte Verfahren (Vergabe via API oder ähnlichem) lassen sich im Nachhinein umsetzen
    • für den Nutzer bleibt somit freundlicherweise die Erreichbarkeit via fester IP bzw. festem Namen möglich
  • das Ergebnis der Adressvergabe ist der Einfachheit halber eine Ganzzahl (die AP-Nummer)

• Wie sollen Präfixe im Netz bekanntgemacht werden (Prefix Announcement)?
  • Vorschlag: das nameservice-Plugin-Äquivalent verteilt das Präfix

• Algo zur Ermittlung von IPs der APs?
  • Vorschlag: Systematisch: 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.
  • chaotisch: MAC und 16-Bit-Zufallszahl auswürfeln; unerwünscht (Vorteile sind nicht erkennbar)
    • • Mechanismus zur DNS Registration wird benötigt! Aber wie? DDNS würde man mit DHCP nutzen. Mit DHCP würde der DHCP Server die DUID benötigen. Diese wird bei jeder Neuinstallation neu erstellt. Das ist anders als bei DHCPv4, wo der Client eine eindeutige ID (MAC Adresse) hat.

• Algo für statisches IPv6 Netz (je AP ein /64 Netz) festlegen
  • Vorschlag: siehe Berechnungsvorschlag basierend auf AP-Nummer
• IP Plan entwerfen mit der Annahme, dass wir mind. /48 bekommen. Dies wird bspw. bei IN-Berlin zugesichert und ist für später auch realistisch.
  • Vorschlag: siehe unten

• Mit welchem Mechanismus sollen dynamische /64 Bereiche vergeben werden?
  • DHCP kann nur Prefix-Delegation. Hier bestimmt alleinig der Client, welchen Teil des Prefixes er nutzt. Hier müssen sich also alle Clients absprechen. Daher ist DHCP hier unpassend.
  • Im Prinzip brauchen wir eine Art DHCP mit Vergabe von /64 Netzen und Unicast-only Unterstützung.
    • Vorschlag: TODO später, weil größere Baustelle, welche aber parallel zu anderen Problemen bearbeitet werden kann.

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?
• Wenn OpenVPN genutzt werden soll, welche Adressen sollen als interne Tunnelendpunkte genutzt werden für:
  • UGW-Tunnel-Endpunkte: ???
  • User-Tunnel-Endpunkte: ???

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.)

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.
• 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.

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)

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