Projekt IPv6: Unterschied zwischen den Versionen

Version vom 14. November 2015, 23:10 Uhr

Planung zur Einführung von IPv6 im Opennet

Offene Fragen

• Soll OLSRv2 gleichzeitig mit IPv6 eingeführt werden? 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: Migration OLSRv2 nach hinten verschieben, weil Vorraussetzungen derzeit fehlen (nameservice-plugin).
• Soll OLSRv1 genutzt werden? Wenn ja, dann darf es nicht mehrere default Routen nach draußen geben (fehlendes source-based routing)
  • Vorschlag: Ja, erstmal OLSRv1 nutzen. Sollte kein Problem werden, solange weitere Netze getunnelt werden.

bekommen.

• Soll jeder AP eine ULA Adresse bekommen? Wenn ja, welches Präfix?
  • Vorschlag: Ja, damit es eine konstante IP gibt, auf welche sich auch das DNS bezieht.
  • Vorschlag: fd32:d8d3:87da::/48 (wurde unter https://www.sixxs.net/tools/grh/ula/ registriert. Macht für später Sinn, wenn man sich mit anderen Netzen, und somit anderen ULAs, verbinden will)
• Wie sollen Prefixe im Netz bekanntgemacht werden?
  • nameserviceplugin (nur OLSRv1)
    • Vorschlag: Ja, Präfixe von ULA + "ein" public Präfix publizieren. APs generieren sich selbst IP.
  • hart kodiert/konfiguriert in Firmware (wie bisher mit IPv4)
    • unschön.
• Algo zur Ermittlung von IPs der APs?
  • Mögliche Verfahren und deren spätere DNS Integration
    • 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.
      • Vorschlag: Dieses Schema nutzen.
    • Chaotisch: MAC und 16-Bit-Zufallszahl auswürfeln
      • 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.
• 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 beareitet werden kann.
• 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.
• Algo für statisches IPv6 Netz (je AP ein /64 Netz) festlegen
  • Wer ist zuständig für Zuordnung von statischen /64 Netz zu User AP bzw. wie ist der Algo hierfür?
    • Vorschlag: Algo wird global definiert und ist somit nachvollziehbar für alle. Sie unten im "IP Plan" die "statischen Netze".
• 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

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

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