ICVPN - Ein neuer Versuch als Education-Umgebung

Mitmachecke
1

Hier eine Mail, die über die ICVPN-Mailinglist gekommen ist.
Ich sehe das ICVPN für uns im Münsterland als zweite Spielwiese um sich Wissen im Bereich BGP/Routing anzueignen. (zusätzlich zu unserem int. Routing) Ich habe im Moment leider keine Zeit. aber wenn jemand anderes hier einsteigen möchte, dann ist er herzlich willkommen.

Besonders gut ist die Entscheidung IPv6-Only \o/

Hallo folks,

wir haben uns auf dem 33c3 getroffen um über die Möglichkeit eines DNS-Service im ICVPN und das ICVPN zu beraten. Das zugh. Pad liegt hier:
Freifunk.net Pad.

Wir waren uns so ungefähr einig, dass wir das ICVPN nicht nutzen wollen, um produktive Daten zu übertragen - stattdessen ist es eine Edu-Projekt / eine Spielwiese um BGP und andere Techniken zu verstehen. (*)

Die Idee, eine .freifunk-TLD zu starten - anycast-DNS, Idee etwas wie bei OpenNIC - finden wir soweit gut; die Nachdiskussion auf dem Flur ergab, dass sich einige vorstellen mitzumachen.
Ich nahm’ das Todo die Diskussion nochmal aufzugreifen, eine Mail an die Communitiy zu schreiben und die die Diskussion auf die ICVPN-Mailingliste (icvpn@lists.funkfeuer.at) zu schieben.
→ Done

Ich hab’ inzwischen ein ICVPN-Meta-File für den Anycast-Range angelegt
(GitHub - yanosz/icvpn-meta at master+anycast)

Die Idee ist:

  • Es gibt 3 DNS-Server (anycast), die jede Community hosten kann, wenn sie mag. Die Server hosten die .freifunk-Zone und die ULA-Root-Zone für reverse lookups. Die delegieren an andere Zonen entsprechend ICVPN meta.
  • Die Communities, die you-name-it.freifunk haben möchten, tragen die Domain wie gewohnt in icvpn-meta ein. Gleiches gilt für das Reverse-Mapping

→ Da das Setup IPv6 only ist, wär’ es cool, wenn die DNS-Server aller
existierenden Communities via IPv6/ULA erreichbar sind. ←

Wenn’s es soweit keine Einbinde gibt, können wir das anycast-File merge’n und dann geht’s ans Nameserver-Betreiben.

Gruß, yanosz

(*)
Es scheint wohl einige Communities zu geben, die eine Default-Route für delegierte Prefixes über das ICVPN announce’n. Das Setup führte bei uns zu etwas Verwirrung, da es einerseits funktioniert, aber andererseits eine default route für delegierte prefixes idR source specific routing braucht, was BGP’s destiniations based forwarding Paradigma widerspricht.
Da wir kein Interesse daran haben, die Verwirrung mit Bürokratie aufzulösen oder gar die Nachwirkung zu erfahren, zuckten wir mit den Achseln und dachten über andere Dinge nach.

–
For those of you without hope, we have rooms with color TV, cable and air conditioning

icvpn mailing list
icvpn@lists.funkfeuer.at
icvpn Info Page

1 „Gefällt mir“
2

Gab’s da nochmal Bestrebungen zu ein ICVPN 2.0 zu bauen oder ist das Eingeschlafen?

3

V4 ist glaube ich offiziell abgekündigt. V6 gibt es wohl noch. Ich halte das trotzdem nicht wirklich den Aufwand wert.

Kann man aber gerne machen, wenn jemand aus dem @Adminteam sich mal mit BGP beschäftigen möchte. Wäre vllt. ein tolles Projekt für @wurmi, @P4w und @fll. Ich unterstütze gerne, mich reizt es aber selbst nicht so.

Viele Grüße
Matthias

4

Ne da IPv6 eh Global ist sehe ich da auch nicht so den Nutzen drin… Hätte mich nur interessiert was daraus geworden ist.

5

Der Nutzen wäre halt, für jemanden, der das noch nicht gemacht hat, mal ein paar BGP-Sitzungen aufzubauen. Wir beiden haben das glaube ich oft genug gemacht :wink:

Vom Datenverkehr her, der da durchgeht nicht so interessant.

Das einzig coole wäre halt, dass man Statusseiten von Communitys öffnen kann, die keine öffentlichen IP-Adressen haben. Also diese fd-irgendwas. Die könnte man dann aus dem FF-Netz erreichen.

6

Alternativ wollen wir das FFNW BB daran anbinden, und könnten euch die Routen via Communitys in Bird übergeben :wink:

7

Sehr ihr denn irgendeinen praktischen Nutzen, oder ist das auch eher weil es geht?

8

Eher weil es geht :grin:

1 „Gefällt mir“
9

Huch, welche Mail ist mir da entgangen? AFAIK hat sich am ICVPN-Setup nichts grundlegend geändert (Adressevergabe via github, Zu­sam­men­schalt­ung per tinc, Announcement von v4- & v6-Ranges per BGP). Für v4 halte ich es für zweckfrei (Adresskoordinierungsaufwand vs. real existierender, den Aufwand rechtfertigender, »Dienste«), für public v6 ist es über und bei private v6 (ULA) greift das gleiche Argument wie bei v4 RFC1918.

Quasi. Wenn denn das Routing in beide Richtungen klappt, was bei öff­ent­lich­en IPv6-Adressen auf der einen und privaten auf der anderen Seite nicht zwing­end gegeben sein muß.

IMHO kann man mit vergleichbarer Erfolgs- zu Miserfolgsquote auch bei DN42 mitmachen für erste Schritte mit BGP :wink:

1 „Gefällt mir“