Projekt IPv6: Unterschied zwischen den Versionen

Aktuelle Version vom 29. Januar 2021, 14:36 Uhr

[Bearbeiten] 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.

[Bearbeiten] Diskussionspunkte

[Bearbeiten] Offene Fragen

[Bearbeiten] 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
    • Entscheidung: Wir nehmen OLSRv1 für IPv4 und OLSRv2 für IPv6. Dann gibt es keinerlei Besonderheiten zu berücksichtigen.

Wir beginnen OLSRv2 im Opennet einzuführen. Mehr Infos sind unter OLSRv2 zu finden.

[Bearbeiten] 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
• 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 Dez 2019). Es gibt hierzu ein Feature Request
    • Würde es immer einen Layer2-Tunnel vom Knotem zum DHCPv6 Server geben, könnte man darin DHCPv6 nutzen.
  • 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)?
  • Idee: das nameservice-Plugin-Äquivalent verteilt das Präfix.
    • hnetd (Nutzung von HNCP) erfüllt einige unserer Anforderungen, schießt aber am Ende über das Ziel hinaus.
      • Möglich wäre hier ein Anpassung von (hnetd, shncpd, pysyma) an unsere Ansprüche.
    • Das junge BIER Protokoll (https://tools.ietf.org/html/draft-ietf-bier-architecture-07) würde unseren Ansprüchen auch genügen. Derzeit gibt es nur eine Anspassung für Babel. Prinzipiell ist das Protokoll jedoch Routingprotokollunabhängig gedacht. Einer müsste es mal so auch implementieren. Derzeit (Nov 2017) scheint es keine Implementation zu geben.
• 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?

• Algo für statisches IPv6 Netz (je AP ein /64 Netz) festlegen
  • Vorschlag: siehe Berechnungsvorschlag basierend auf AP-Nummer
  • alternativ via DHCPv6-PD: siehe https://labs.ripe.net/Members/teklov/static-dhcpv6-prefix-delegation

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

[Bearbeiten] 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.

[Bearbeiten] 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.)

[Bearbeiten] Möglichkeiten von DHCPv6-PD, wenn Layer2 Verbindung vorhanden

Wir gehen hier davon aus, dass ein Node (AP eines Users) eine Layer2 Verbindung (z.B. per VPN-Tunnel) zum DHCPv6 Server hat. In diesem Fall kann DHCPv6-PD (Prefix Delegation) genutzt werden.

Im Folgenden wird diskutiert, auf welche Art und Weise das Prefix Delegation und Routing zusammenspielen kann.

[Bearbeiten] Aufbau

- DHCPv6 Server (stellt Verbindung zum Internet her)

 DHCPv6 Server hat für Prefix Delegation genau zwei Netze zu vergeben 2001:DB8:ff:f1::/64 + 2001:DB8:ff:f2::/64
 eth0: 2001:DB8:9:9::1/56   (Internetanbindung)
 tun0: fe80::9:9:9:9    (Layer2 Tunnel zu Nodes)

- Node A (z.B. AP eines Users)

 br-lan: fe80::a:a:a:1   (hier sind Endgeräte angeschlossen)
 tun0:   fe80::a:a:a:2   (Layer2 Tunnel zu DHCPv6 Server)

- Node B (z.B. AP eines Users)

 br-lan: fe80::b:b:b:1   (hier sind Endgeräte angeschlossen)
 tun0:   fe80::b:b:b:2   (Layer2 Tunnel zu DHCPv6 Server)

[Bearbeiten] Ablauf

• Node A möchte ein (oder mehrere) IPv6 Subnete für seine angeschlossenen Endgeräte (PC, Smartphone, TV, ...) haben
• Node A fragt per DHCPv6-PD (Multicast) nach Subnetzen (über tun0 Interface)
• DHCPv6 Server antwortet und übermittelt ein Netz (z.B. 2001:DB8:ff:f1::/64)
• Der DHCPv6 Server merkt sich, dass ein Node mit DUID xyz das Netz 2001:DB8:ff:f1::/64 bekommen hat. Hinweis: Der DHCPv6 Server macht keinerlei Änderungen an Routingtabellen!
• Node A: nach Erhalt fügt der Node die IP 2001:DB8:ff:f1::1 seinem br-lan Interface hinzu. Der radvd wird konfiguriert und verteilt über das br-lan Interface dann das 2001:DB8:ff:f1::/64 Netz.
• Gleich wird es spannend.
• Ein Endgeräte, welches an Node A angeschlossen ist, hat bspw. die IP 2001:DB8:ff:f1::7777/64. Dieses Gerät möchte Daten ins Internet (bspw. 2001:DB8:33:33:33::33 senden.
• Node A routet das Paket per default Route in das tun0 Interface.
• Der Server routet das Paket per default Route per eth0 ins Internet.
• "Das Internet antwortet". Die Antwort kommt per eth0 Interface beim Server an.
• Was passiert JETZT?
  • Wohin routet der Server das Antwortpacket, welches an 2001:DB8:ff:f1::7777 adressiert ist? Warum routet er es dahin?

[Bearbeiten] Möglich Lösungen

[Bearbeiten] Textuell

1. statische Routen auf dem Server für jedes neu vergebene Netz setzen. Auf dem DHCPv6 Server muss es einen Mechanismus geben, welcher bei der Vergabe eines Prefixes gleichzeitig einen neuen Routingeintrag erstellt. Bei unterschiedlichen DHCPv6 Server gibt es unterschiedliche Möglichkeiten Skripte/Trigger zu aktivieren. Damit ein Routingeintrag erstellt werden kann benötigen wir zwei Informationen, a) das vergebene Subnetz unb b) die IP des Nodes, an dem das Subnetz vergeben wird. Es folgt ein beispielhafter Aufbau:
   1. isc-dhcp-server: es gibt bspw. "on commit" Trigger, wenn ein neues Prefix vergeben wird. In dieser Funktion gibt der Dienst leider nicht die IP Adresse des anfragenden Nodes mit. ( https://jpmens.net/2011/07/06/execute-a-script-when-isc-dhcp-hands-out-a-new-lease/ ) Lediglich im Syslog ist die IP zu sehen.
   2. kea: hier kann man auch per Hooks auf Events reagieren, aber leider scheint auch hier nicht die IP des Nodes verfügbar zu sein.
   3. dhcpy6d: Hier gibt es explizit eine Option, um die link-local Adresse des Nodes zu ermitteln (siehe "route_link_local" unter https://dhcpy6d.ifw-dresden.de/documentation/config/prefixes/ ). Leider lief der dhcp6yd nicht in meiner Debian10 Installation damals nicht, weil es kein originales Debian10 Paket gab und bei der manuellen Installation Abhängigkeitsprobleme mit Python vorkamen. Mittlerweile (Jan 2021) gibt es wieder funktionierende Debian Pakete. Müsste man nochmals testen.
2. statische Route auf dem Server setzen für den ganze IP Bereich der PD Netze.
   1. hierfür wird ein NDP Proxy benötigt.
3. dynamisches Routing. Der Node könnte sein erhaltenes Netz auch per dynamischem Routingprotokoll dem Server mitteilen. Damit entstehen automatisch die richtigen Routingeinträge auf dem Server.
   1. OLSRv2:
      1. Nachteil: da link-state Protokoll wird im Netz überall propagiert, wer welche IPs gerade nutzt
   2. RIPng:
      1. Nachteil: zusätzliches Paket, http://www.makikiweb.com/ipv6/wireguard_on_openwrt.html , http://www.makikiweb.com/ipv6/ripng.html
4. was passiert, wenn Client wandert (später an anderem Server gleichen Adressbereich hat)?

[Bearbeiten] Graphische Darstellung

1. statische Routen auf dem Server für jedes neu vergebene Netz setzen.

 +--------------------------------------------------------------------+
 |        gai (ISP)                                                   |
 | -radvd announces  2a0a:4580:1010:0002::/64                         |
 | -dhcpv6 announces via prefix delegation                            |
 |   one /60 from within 2a0a:4580:1010:1000::/52,                    |
 |    e.g. 2a0a:4580:1010:19b0::1/60                                  |
 +---------+----------------------------------------------------------+
           | tap-users-v6
           | addr: 2a0a:4580:1010:2::1/64
           | route: 2a0a:4580:1010:19b0::1/60 dev tap-users-v6 via fe80::bc86:3ff:fe94:6afc
           |        (route created by some hook-possibility in dhcp6 server!?!)
           |
           | tap-on-user-v6
           | addr e.g. fe80::bc86:3ff:fe94:6afc/64
           | addr e.g. 2a0a:4580:1010:2:bc86:3ff:fe94:6afc/64 (via radvd)
           | default route via tap-on-user-v6
           |   
    +------+---------+
    |  Opennet Node  |
    +------+---------+
           | br0
           | radvd announces 2a0a:4580:1010:19b0::1/60
           |
           |
           |
        +--+--+
        | LAN | 
        +-----+

2. statische Route auf dem Server setzen für den ganze IP Bereich der PD Netze.

 +--------------------------------------------------------------------+
 |        gai (ISP)                                                   |
 | -radvd announces  2a0a:4580:1010:0002::/64                         |
 | -dhcpv6 announces via prefix delegation                            |
 |   one /60 from within 2a0a:4580:1010:1000::/52,                    |
 |    e.g. 2a0a:4580:1010:19b0::1/60                                  |
 +---------+----------------------------------------------------------+
           | tap-users-v6
           | addr: 2a0a:4580:1010:2::1/64
           | route: 2a0a:4580:1010:1000::/52 dev tap-users-v6
           |        (note: ISP assumes that network is directly connected)
           |
           | tap-on-user-v6
           | addr e.g. 2a0a:4580:1010:2:bc86:3ff:fe94:6afc/64 (via radvd)
           | default route via tap-on-user-v6
           | ndppd answers to NDP solicitations for 2a0a:4580:1010:1000::/52,
           |   
    +------+---------+
    |  Opennet Node  |
    +------+---------+
           | br0
           | radvd announces 2a0a:4580:1010:19b0::1/60
           |
           |
           |
        +--+--+
        | LAN | 
        +-----+

3. dynamisches Routing. Der Node könnte sein erhaltenes Netz auch per dynamischem Routingprotokoll dem Server mitteilen. Damit entstehen automatisch die richtigen Routingeinträge auf dem Server.

 +--------------------------------------------------------------------+
 |        gai (ISP)                                                   |
 | -radvd announces  2a0a:4580:1010:0002::/64                         |
 | -dhcpv6 announces via prefix delegation                            |
 |   one /60 from within 2a0a:4580:1010:1000::/52,                    |
 |    e.g. 2a0a:4580:1010:19b0::1/60                                  |
 +---------+----------------------------------------------------------+
           | tap-users-v6
           | addr: 2a0a:4580:1010:2::1/64
           | route: 2a0a:4580:1010:19b0::1/60 dev tap-users-v6 via fe80::bc86:3ff:fe94:6afc
           |        (route created by dynamic routing protocol)
           |
           | tap-on-user-v6
           | addr e.g. fe80::bc86:3ff:fe94:6afc/64
           | addr e.g. 2a0a:4580:1010:2:bc86:3ff:fe94:6afc/64 (via radvd)
           | default route via tap-on-user-v6
           |   
    +------+---------+
    |  Opennet Node  |
    +------+---------+
           | br0
           | radvd announces 2a0a:4580:1010:19b0::1/60
           |
           |
           |
        +--+--+
        | LAN | 
        +-----+

[Bearbeiten] 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 darauf IA_PD Prefix options genutzt wird.
      • Korrektur: IA_PD Prefix kann berücksicht werden vom Server, muss aber nicht. Siehe auch https://tools.ietf.org/html/rfc3633

[Bearbeiten] 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

[Bearbeiten] Aktuelle Tätigkeiten

Was machen wir gerade:

• Benutzer:Leo/Blog:2019_January_26_20:50:39_CET
  • OpenVPN-User-Tunnel soll per IPv6 aufgebaut werden
  • OLSRD2 auf mindestens einem der UGW-Server aktivieren
  • DNS-Eintrag für diesen Dienst erstellen (z.B. "gw.services.on" mit der IPv6-ULA-Adresse des einen UGW; später kommen weitere hinzu)
  • Firmware: falls on-olsr2 auf einem Router aktiv ist, dann sollen die Ergebnisse eines DNS-Queries (z.B. "gw.services.on") automatisch in die Liste der verfügbaren Gateway-Server aufgenommen werden

Was haben wir bereits umgesetzt:

• Firmware mit OLSRv2 und IPv6 ULA
• ...

[Bearbeiten] 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