Benutzer:Leo/Blog:2016 February 01 06:52:44 CET

IPv6 Treffen (31.01.2016)

Auf dem Treffen wurden einerseits konkrete IPv6 Migrationsprobleme (Fehlen des nameservice-Plugins) als auch die Migration zu OLSRv2 besprochen.

Bisher annoncieren wir drei Dienste (DNS, NTP, Gatewayliste) mit dem OLSRv1 nameservice-Plugin. In OLSRv2 gibt es dieses Plugin derzeit nicht. Wie könnte man das Annoncieren der drei Dienste anders realisieren?

Aufgabe 1: DNS

Vorschlag 1: anycast

• wir definieren eine magische IP, die DNS-Dienste anbietet
• alle DNS-Server announcieren diese IP als HNA
• Nachteile:
  • bei Ausfall eines DNS-Servers (bei gleichzeitig fortbestehender HNA-Announcierung) wird die Namensauflösung für die Umgebung unlösbar gestört

Vorschlag 2: magischer IP-Bereich

• wir definieren einen IP-Bereich der DNS-Server
• alle DNS-Server werden von uns per Hand verwaltet und announcieren eine IP aus diesem Bereich via HNA
• ein Skript auf den APs sammelt regelmäßig die routebaren Adressen aus dem magischen IP-Bereich und konfiguriert damit dnsmasq
• dnsmasq fragt dann alle DNS-Server gleichzeitig
• Nachteile:
  • manuelle IP-Vergabe im magischen IP-Bereich an die DNS-Server
  • mehrfache DNS-Anfragen

Vorschlag 3: nameservice-Plugin finden/implementieren

• für OLSRv2 das Plugin implementieren, analog zu OLSRv1

Aufgabe 2: NTP

Lösung 1: ein DNS-Name

• ein DNS-Name löst auf mehrere IPs auf (mehrere A/AAAA-Einträge), z.B. ntp.on-i.de

Lösung 2: mehrere DNS-Namen

• jeder Server hat einen Namen mit Nummerierungsschema: ntp1.on-i.de, ...

Aufgabe 3: Gateway-Auswahl

Vorschlag 1: anycast

• jeder Gateway announciert eine magische Gateway-IP (als HNA)
• der Nutzer verbindet sich immer mit dieser IP
• somit wird der routing-technisch naheliegenste Gateway ausgewählt (Kombination aus Route zum UGW-AP und dessen Verbindung zum UGW-Server)
• keinerlei Konfigurationsmöglichkeiten oder -notwendigkeiten
• Nachteile:
  • Gateway announciert IP, ist jedoch kaputt -> keine Chance, automatisch einen alternativen Gateway zu wählen

Vorschlag 2: mehrere IPs via DNS ermitteln

• via DNS erhalten wir mehrere IPs (Liste von UGW Servern)
• der konkrete Gateway wird zufällig (z.B. openvpn: round-robin ohne Priorität) gewählt
• Annahme:
  • alle (oder die meisten) Spender bieten Verbindungen zu _allen_ Gateways an
    • andernfalls werden gelegentlich auch Verbindung über den nicht-nächsten Spender aufgebaut
    • seltener Fall - wohl nicht optimierungswürdig
• wir benötigen keine Überwachung und Auswahl des optimalen Gateways - dies tut der VPN-Client interaktionsfrei (z.B. openvpn)
• Nachteile:
  • der UGW-AP (also der Anschluss-Spendende) wird via Routing ermittelt und ist nicht konfigurierbar

Gesamtproblem: OLSRv2 Migration

Da unsere IPv6 Implementierung auf OLSRv2 aufsetzt, müssen wir hier auch Voraussetzungen schaffen. Derzeit ist hier noch vieles unklar.

Nach einer längeren und sehr intensiven Diskussion haben wir viele Ansätze gefunden und auch wieder verworfen. Die vielen möglichen Wege werden wir in einem Wiki (mit graphvis Plugin) dokumentieren, um dort weiter zu diskutieren. Da kommt eine spanndende Aufgabe auf uns zu :)