[Berlin-wireless] PI Adressen - was nun?

[Daniel Paufler]

Hallo Gemeinde

Wir haben seit Spätsomer letzen Jahres einen eigenen IP-Berich von der
RIPE zugeteilt bekommen. Seit Winter haben wir auch ein eigenes
Autonomes System, damit wir mit anderen "peeren" können. Siehe [1]. Ich
möchte die Frage aufwerfen wie wir weitermachen wollen bzw. was die
Kommentare der Community sind.

Anregung war eine eMail von Frithjof, aus welcher ich die Fragen
zitiere. Die Antworten sollen einen ersten Einstieg verschaffen -
angereichtert mit weiteren Informationen.

Die öffentlichen Adressen werden im Moment vom IN-Berlin an uns
geroutet. Von unserem Server können sie per tincVPN [2] verteilt werden.
 Wir nennen das das CityVPN, BBBVPN oder einfach tincVPN. Man stelle
sich einen großen Layer2 Switch vor - über das VPN können wir sowohl
IPv4 als auch IPv6 fahren. Er dient als Sammelbecken und Link zum Server
und damit zur Internetwelt. Er verbindet DSL-Anschlüsse aus
Charlottenburg mit der Mesh-Wolke in Weissensee und überhaut hält er
Mesh-Inseln in der großen Topologie zusammen.

Weiterhin verbindet der Server die Freifunk-Städte miteinander - das so
genannte IntercityVPN [3]. Hier haben wir die Anbindung ans Internet
geübt und mit den Technologien gespielt - was die Grundlage für die
public IPs legte. In der Grafik im Wiki bzw. [4] könnte ihr die
momentanen verbunden Städte sehen. Das Routing wird über BGP und
weiterer Tinc-Tunnel realiseriert und funktioniert recht ok seit ~1-2
Jahren.

Ein schlechtes Webinterface vom VPN-Server befindet sich hier [5]. Dort
sind die Routen und die Topologie zu sehen.

Und nun zu den Fragen ...

> Würde sich die Fragen stellen,
> -wie könnte eine Migration für uns aussehen?
> -  man müsste ja 255.255.255.255 per olsrd broadcasten oder zumindest
ein SNAT
> (104.x.x.x => 77.87.xx.xx) auf dem VPN Gateway laufen lassen.
Die /32 subnetmask ist eine gute Vorraussetzung. Test haben hier
positive Ergebnisse gebracht - wenn auch noch nicht an einer großen
Nodezahl getestet (>30). Aber das ist imo eine gute Basis, zumal wir
damit in Zukunft die Broadcasts von der IP-Range entkoppelt hätten.

> -gibt es bereits eine Vergabestrategie für die PI Adressen?
Hier sprichst du den Kern an. Jein. Hier gibt es technische und
organisatorische Fragen

- IP-Orga: Meine Meinung muss die IP-Vergabe / eine IP-Vergabe die
Vergabe der IPs managen. (toller Satz). Die technische Lösund könnte ein
Umbauen der vorhanden Vergabe sein. Hier wäre Wulf und Marek ins Boot zu
holen. Kepp it simple wäre eine Vergabe im Wiki - a la Leipzig / Weimar.
Wie auch immer, mir wäre es lieb, wenn die Vergabe noch irgendwo anders
als im DNS passiert. (Die Namen würde ich gerne als hostnames
automatisch in den DNS eintragen ...)

- Mesh-Orga: Es gibt die verschiedenen Lösungsansätze, was die Migration
bzw. Verteilung der Adressen angeht. Fest steht: Eine Vergabe einer
public IP pro AP für das Mesh ist nicht zu bevorzugen. (ich schreibe
nicht, dass es nicht sein kann). Wien hat gezeigt, dass es a) wenig
sinnvoll und b) schnell eng mit der Anzahl wird. Weiterhin wollen wir
die publics ja eigentlich _hinter_ den nodes / mesh auf den
Client-Rechnern, damit Dienste auf diesen Rechnern erreicht werden können.

- Technik: Ich reiße hier mal die Themen an, welche mir zu Ohren
gekommen sind.
a) IP-Broadcast auf 255.255.255.255 im olsrd.conf. Damit werden bel.
Adressen im Mesh verwendbar. Damit machen wir eine langsame Mirgation,
fahren 104 und 77.87 parallel und haben das mesh irgendwann umgestellt.
Probleme: Wie sieht das routing konkret aus (77 -> 104 -> 77 -> 104 ->
77 inet ...)? Wollen wir wirklich das ganze mesh public?

b) Wir bauen Tunnel auf die Endrechner, welche durch das 104./10er mesh
Tunneln. Am Ende kommt eine 77.87. IP oder subnet /29 raus. Gut wäre,
dass die Adressen dort sind, wo wir sie wollen. Probleme?:
Tunnel-Fähigkeit der Endgeräte. Welche Technologie? openVPN, tinc, ipsec
AH. Letzeres verwendet imo Graz recht erfolgreich.

c) Wir stellen das Mesh auf IPv6 um. Damit haben wir super
Infrastruktur-Technologie, sind unabhängig von Ipv4 und ist eh cooler.
Im Ernst, das wäre imo das non-plus-ultra. Probleme: Wenig Erfahrung und
ein sehr weites Ziel. Ideen sind schon geäußert, Umsetzung im Labor / im
Kleinen steht noch aus.

Zwischen diesen Lösungsansätzen sind noch unendlich viele Variationen
und Kombinationen möglich. Diese sind so unendlich wie die Meinungen der
Leute auf der Liste - und leider reden mehr Leute theoretisch darüber
als aus Laborerfahrung.

Ich würde mir wünschen, dass wir eine Idee umreißen, und dass sich dann
ein paar Leute _echt_ zusammen tun und das ausprobieren. Mit 10-20 nodes
 können wir dann von "Erfahrung" reden und sind imo einen Schritt weiter
- und zwar einen Praktischen.


>-in der Mailingliste blieb die Frage nach Traffickosten etwas
unbeantwortet.
> > Gibt es da konkretes?
Im Moment ist das alles Labor und der Traffic wird von IN-Berlin
"gesponsort" / gedultet. Wenn wir das ausrollen, werde ich mich um eine
Klärung kümmern. Das sollte aber ein zweitrangiges Problem sein, auch
weil die Lösung nicht kompliziert scheint.

Ich freue mich auf spanndende Kommentare. Bitte lasst beim Antworten nur
die Text-Passage in der eMail, auf welche ihr euch direkt bezieht - das
erleichtert das Lesen und Verstehen euerer Antwort. Mir ist die Länge
der eMail bewußt - sorry - möchte aber nur mit Teilen des Textes eine
Diskussion anregen.

Ich würde mir wünschen, dass manch geschriebenes nicht vollens
Marketingtechnisch auseinandergenommen, durch den Dreck gezogen oder
sonstigem Flamewars unterzogen wird. Sollten hier solche Sachen
enthalten sein - ignorieren oder Hallo Gemeinde

Wir haben seit Spätsomer letzen Jahres einen eigenen IP-Berich von der
RIPE zugeteilt bekommen. Seit Winter haben wir auch ein eigenes
Autonomes System, damit wir mit anderen "peeren" können. Siehe [1]. Ich
möchte die Frage aufwerfen wie wir weitermachen wollen bzw. was die
Kommentare der Community sind.

Anregung war eine eMail von Frithjof, aus welcher ich die Fragen
zitiere. Die Antworten sollen einen ersten Einstieg verschaffen -
angereichtert mit weiteren Informationen.

Die öffentlichen Adressen werden im Moment vom IN-Berlin an uns
geroutet. Von unserem Server können sie per tincVPN [2] verteilt werden.
 Wir nennen das das CityVPN, BBBVPN oder einfach tincVPN. Man stelle
sich einen großen Layer2 Switch vor - über das VPN können wir sowohl
IPv4 als auch IPv6 fahren. Er dient als Sammelbecken und Link zum Server
und damit zur Internetwelt. Er verbindet DSL-Anschlüsse aus
Charlottenburg mit der Mesh-Wolke in Weissensee und überhaut hält er
Mesh-Inseln in der großen Topologie zusammen.

Weiterhin verbindet der Server die Freifunk-Städte miteinander - das so
genannte IntercityVPN [3]. Hier haben wir die Anbindung ans Internet
geübt und mit den Technologien gespielt - was die Grundlage für die
public IPs legte. In der Grafik im Wiki bzw. [4] könnte ihr die
momentanen verbunden Städte sehen. Das Routing wird über BGP und
weiterer Tinc-Tunnel realiseriert und funktioniert recht ok seit ~1-2
Jahren.

Und nun zu den Fragen ...

> Würde sich die Fragen stellen,
> -wie könnte eine Migration für uns aussehen?
> -  man müsste ja 255.255.255.255 per olsrd broadcasten oder zumindest
ein SNAT
> (104.x.x.x => 77.87.xx.xx) auf dem VPN Gateway laufen lassen.
Die /32 subnetmask ist eine gute Vorraussetzung. Test haben hier
positive Ergebnisse gebracht - wenn auch noch nicht an einer großen
Nodezahl getestet (>30). Aber das ist imo eine gute Basis, zumal wir
damit in Zukunft die Broadcasts von der IP-Range entkoppelt hätten.

> -gibt es bereits eine Vergabestrategie für die PI Adressen?
Hier sprichst du den Kern an. Jein. Hier gibt es technische und
organisatorische Fragen

- IP-Orga: Meine Meinung muss die IP-Vergabe / eine IP-Vergabe die
Vergabe der IPs managen. (toller Satz). Die technische Lösund könnte ein
Umbauen der vorhanden Vergabe sein. Hier wäre Wulf und Marek ins Boot zu
holen. Kepp it simple wäre eine Vergabe im Wiki - a la Leipzig / Weimar.
Wie auch immer, mir wäre es lieb, wenn die Vergabe noch irgendwo anders
als im DNS passiert. (Die Namen würde ich gerne als hostnames
automatisch in den DNS eintragen ...)

- Mesh-Orga: Es gibt die verschiedenen Lösungsansätze, was die Migration
bzw. Verteilung der Adressen angeht. Fest steht: Eine Vergabe einer
public IP pro AP für das Mesh ist nicht zu bevorzugen. (ich schreibe
nicht, dass es nicht sein kann). Wien hat gezeigt, dass es a) wenig
sinnvoll und b) schnell eng mit der Anzahl wird. Weiterhin wollen wir
die publics ja eigentlich _hinter_ den nodes / mesh auf den
Client-Rechnern, damit Dienste auf diesen Rechnern erreicht werden können.

- Technik: Ich reiße hier mal die Themen an, welche mir zu Ohren
gekommen sind.
a) IP-Broadcast auf 255.255.255.255 im olsrd.conf. Damit werden bel.
Adressen im Mesh verwendbar. Damit machen wir eine langsame Mirgation,
fahren 104 und 77.87 parallel und haben das mesh irgendwann umgestellt.
Probleme: Wie sieht das routing konkret aus (77 -> 104 -> 77 -> 104 ->
77 inet ...)? Wollen wir wirklich das ganze mesh public?

b) Wir bauen Tunnel auf die Endrechner, welche durch das 104./10er mesh
Tunneln. Am Ende kommt eine 77.87. IP oder subnet /29 raus. Gut wäre,
dass die Adressen dort sind, wo wir sie wollen. Probleme?:
Tunnel-Fähigkeit der Endgeräte. Welche Technologie? openVPN, tinc, ipsec
AH. Letzeres verwendet imo Graz recht erfolgreich.

c) Wir stellen das Mesh auf IPv6 um. Damit haben wir super
Infrastruktur-Technologie, sind unabhängig von Ipv4 und ist eh cooler.
Im Ernst, das wäre imo das non-plus-ultra. Probleme: Wenig Erfahrung und
ein sehr weites Ziel. Ideen sind schon geäußert, Umsetzung im Labor / im
Kleinen steht noch aus.

Zwischen diesen Lösungsansätzen sind noch unendlich viele Variationen
und Kombinationen möglich. Diese sind so unendlich wie die Meinungen der
Leute auf der Liste - und leider reden mehr Leute theoretisch darüber
als aus Laborerfahrung.

Ich würde mir wünschen, dass wir eine Idee umreißen, und dass sich dann
ein paar Leute _echt_ zusammen tun und das ausprobieren. Mit 10-20 nodes
 können wir dann von "Erfahrung" reden und sind imo einen Schritt weiter
- und zwar einen Praktischen.


>-in der Mailingliste blieb die Frage nach Traffickosten etwas
unbeantwortet.
> > Gibt es da konkretes?
Im Moment ist das alles Labor und der Traffic wird von IN-Berlin
"gesponsort" / gedultet. Wenn wir das ausrollen, werde ich mich um eine
Klärung kümmern. Das sollte aber ein zweitrangiges Problem sein, auch
weil die Lösung nicht kompliziert scheint.


Freue mich auf spanndende Kommentare. Bitte lasst nur die Text-Passage
in der eMail, auf welche ihr euch direkt bezieht - das erleichtert das
Lesen und verstehen euere Antwort. Mir ist die Länge der eMail bewußt -
sorry - möchte aber nur mit Teilen eine Diskussion anregen.

Ich würde mir wünschen, dass manch geschriebenes nicht vollens
Marketingtechnisch auseinandergenommen, durch den Dreck gezogen oder
sonstigem Flamewars unterzogen wird. Sollten hier solche Sachen
enthalten sein - ignorieren oder per PM an mich.

Grüße und gute Nacht

Daniel

[1]
http://ripe.net/fcgi-bin/whois?form_type=simple&full_query_string=&searchtext=77.87.49.0&submit.x=0&submit.y=0&submit=Search
[2] http://wiki.freifunk.net/TincVPNBerlin
[3] http://wiki.freifunk.net/IC-VPN
[4] http://vpn.leo34.net/images/tinc_freifunk.png ,
https://marvin.funkfeuer.at/icvpn/topo.png

-- 
Dipl. Inf. (FH) Daniel Paufler
Angewandte Informatik - Computer Aided Facility Management
per PM an mich.

Grüße und gute Nacht

Daniel

[1]
http://ripe.net/fcgi-bin/whois?form_type=simple&full_query_string=&searchtext=77.87.49.0&submit.x=0&submit.y=0&submit=Search
[2] http://wiki.freifunk.net/TincVPNBerlin
[3] http://wiki.freifunk.net/IC-VPN
[4] http://vpn.berlin.freifunk.net/images/tinc_freifunk.png ,
https://marvin.funkfeuer.at/icvpn/topo.png
[5] http://vpn.berlin.freifunk.net

-- 
Dipl. Inf. (FH) Daniel Paufler
Angewandte Informatik - Computer Aided Facility Management

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 254 bytes
Beschreibung: OpenPGP digital signature
URL         : <http://lists.berlin.freifunk.net/pipermail/berlin/attachments/20080211/58204b29/attachment.pgp>