[Berlin-wireless] Autokonfiguration eines IPv6-Meshes

[Alexander Morlang]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Alina Friedrichsen schrieb:
> Nunja, Alex besteht sehr beharrlich auf AHCP. Da die Bundeswehr bei 
> ihren Uplinks hoechstwahrscheinlich auf ein Modell mit mehreren 
> zentralen VPN-Server setzen wird macht das auch Sinn. Wer selbst die
> Hoheit ueber seinen/ihren IP-Adressbereich hat, brauch kein
> Grassroots-Routing betreiben und kann sich den ganzen Kram mit den 
> IP-Renumbering sparen. Da wird es wohl so aussehen, das z.B. im Camp
> XYZ in Afghanistan ein festgelegter oeffentlicher IPv6- und
> IPv4-Adressbereich herein getunnelt wird, mit dem dann normales
> Routing betrieben werden kann. Fuer die Autokonfiguration ist es nun
> notwendig, das all die anderen Nodes den IPv6- und IPv4-Adressbereich
> kennen, der in das lokale Mesh hinein geroutet wird. Genau das macht
> AHCP. Es verbreitet das IPv6-Prefix und stellt zentral eine Art DHCP
> fuer die IPv4-Adressen bereit. Das funktioniert aber nur wenn so ein
> AHCP in Reichweite ist. Das ist im Camp in Afghanistan sicher der
> Fall, aber wie sieht es in Freifunk aus?
> 
> Wir haben hier nicht eine Funkwolke, sondern mehrere 
> Auseinanderdriftende. Wer also eine neue Wolke aufbauen will, muss
> also erstmal nen AHCP aufstellen und konfigurieren. Aber ist
> Autokonfiguration nicht gerade fuer AnfaengerInnen, die eine neue
> Wolke aufbauen wollen? Das die weniger Einstiegsschwierigkeiten 
> haben. Und gerade die muessten nun statt den Nodes den AHCP-Server 
> konfigurieren, also waere nichts gewonnen. Das die Bundeswehr AHCP
> gut gebrauchen kann ist klar, aber wenn wir nun unser angepeiltes
> Grassroots-Routing in Betracht ziehen? Also wir verwenden keine
> oeffentlichen IPv6-Adressen fuer das Grundrouting und tunneln uns
> stattdessen unsere Public-IPs vom Internet-Gateway. Das heisst also
> die IPv6-Adresse fuers Grundrouting kann z.B. eine Unique Local
> Address sein, was wiederum heisst das das Prefix immer gleich sein 
> kann, egal neben welchen Uplink der Node auch steht. Eine solche
> IPv6-Adresse laesst sehr einfach Autokonfigurieren. Du nimmst einfach
> das konstante Prefix und schmeisst dahinter die MAC-Adresse, oder
> eine 64-Bit Zufallszahl. Das reicht, damit es ausreichend
> unwahrscheinlich ist, das es eine IPv6-Adresse im Mesh zweimal gibt.

Also, von den netzwerken der bundeswehr hab ich keine ahnung, von daher
weiss ich auch nicht, wie ip auf den camps in afganisten aussieht.

Unabhängig davon ist es nicht sinnvoll, öffentliche ipv6 adressen per
ahcp zuzuweisen. das mag zwar in einem netz mit nur einem uplink
sinnvoll sein, ist aber für ffreifunknetze nicht sinnvoll.

Wir (Freifunk) hat ein ULA prefix (fdca:ffee:babe::), d.h. es bleiben
noch 16 bit für communitys, auf dem 26c2 würden wir also
fdca:ffee:babe:26c3::/64 verwenden.

Wenn jede stadt ein eigenes prefix verwendet, würde das v6 icercity vpn
möglich machen.

Generell ist es aber völlig egal, welche adresse man verwendet, da
multicast verwendet wird.

Die niit testfirmware generiert seit dem letzten congress die ula
adressen, neu ist der vorschlag also nicht. ;)

> Bei IPv4 sieht die Sache schon schwieriger aus. Du kriegst nicht die 
> vollstaendige MAC-Adresse in eine IPv4-Adresse, sondern nur 2 oder 3 
> Bytes davon. Wobei zu erwaehnen ist, das die ersten 3 Bytes die 
> Herstellerkennung sind und nur die letzten 3 sozusagen die
> Seriennummer des Geraets. Bei einen Mesh mit der selben Hardwaere
> wuerden sich also nur die letzten 3 Bytes unterscheiden. 2 Bytes sind
> 65 Tausend Moeglichkeiten und 3 Bytes 16 Millionen. Wenn wir uns nun
> das Konzept mit den 4to6-Tunnel angucken, wuerden wir ja die zu IPv6
> umgerechneten IPv4-Adressen als HNA ankuendigen.

Genau genommen benötigt jeder node, der v4 für die anwender bereitstellt
ein v4 subnetz.

> Nun ist es beim olsrd so, das wenn es zwei als HNA angekuendigte
> IP-Adressen im Mesh doppelt gibt, keinen Falls die Welt unter geht.
> Sie werden stattdessen als Anycast-Adressen behandelt, d.h. es wird
> zu der IP-Adresse von den beiden geroutet, die am naechsten liegt. 
> Wie hoch liegt also die Wahrscheinlichkeit, das es von der IP-Adresse
>  die Du erreichen willst, es eine doppelte gibt, die zudem in der 
> Topologie zu Dir naeher liegt? Bei 2 von 65 Tausend oder 16
> Millionen? Wenn dies wieder erwarten Eintritt, kann die IPv4-Adresse
> ja auch noch von Hand nach-konfiguriert werden.

naja, das typische netz in einer freifunk community ist ein /16, wenn du
/29 netze vergeben willst, was für heimnetze reichen kann, für WGs
definitiv nicht reicht, dann hast du noch /19 übrig, das sind 2048.
vergibst du noch adressen per wlan (dhcp splash), dann bleibt halb so
viel übrig, das währen dann 1024. Bei 100 nodes sind kollisionen dann
die regel.

Für den von dir zitierten bundeswehrfall ist das kein problem, nimm ein
/8 und mach autoconfig, das geht. zu sehen in robin. geht.

Freifunk besteht aus extrem vielen kleinen netzen und im idealfall sind
die alle unique und können im inter city vpn geroutet werden.

> 
> Ich persoenlich glaube nicht, das es viele wirkliche Anwendungsfaelle
>  dafuer geben wird, in denen wir IPv4-Routing innerhalb es Mesches 
> brauchen werden. Momentan verwenden wir im IPv4-only Mesh ja eh NAT,
> d.h. die einzigen IP-Adressen die wir Mesh-intern normalerweise
> erreichen koennen, sind die Freifunk-Nodes selber und die werden ja
> in Zukunft auch IPv6 sprechen koennen.

Das ist so nicht richtig.

Die Kiezfunker nutzen AFAIK kein, bzw möglichst wenig nat.

Ich benutze kein nat. viele andere auch nicht. das vereinfacht divere
dinge extrem.

Mein sip telefon sprich kein ipv4. Wenn die Marchlewskiwolke endlich
satt mit dem restlichlich en mesh verbunden ist, dann will ich natürlich
 auch telefonieren, ein snom für ca 270 euro will ich mir dafür nicht
leisten, mein vorhandenes muss reichen.

Wenn ich eine datei von einem IM client zu einem anderen IM verschicken
will, hilft das auch enorm.

> Ueber 99% des Traffics geht ja
> eh ins Internet und dafuer waere es ja sowieso Sinnvoller einen
> End-to-End Tunnel zu verwenden. Dieser wuerde dann die IPv4-Adressen
> mit dem Internet-Gateway aushandeln.

selbst wenn mein sip telefon nur 1 promille ist, möchte ich es natürlich
für meshinterne telefonie einsetzen. auch ohne asterisk.

> 
> Wer also kein Mesh-internes IPv4-Routing braucht, was bei den meisten
>  normalen AnwenderInnen der Fall sein sollte, kann ganz auf eine 
> IPv4-Adresse im Mesh verzichten. 

Irgendwie müssen die ipv4 geräte, die es gibt, kommunizieren können. In
dem Freifunk, das ich mir vorstelle, gibt mein nachbar seinen drucker
frei, der an einem kleinen printserver modul hängt.

Das kann er optimalerweise mit wenigen klicks im webinterface (dieses
gerät für alex freigeben).

Die realität ist, das ipv4 noch sehr lange leben wird. Nicht nur auf
userseite, viel mehr auf serverseite. Bis alle dienste v6 sprechen
werden noch viele jahre ins land gehen, ich denke da an unzählige
anwendungen, die existieren und nie ipv6 support bekommen werden, ob es
mein geliebtes civilisation ist, gameserver, etc.

> Fuer wen nicht, wuerden die Chancen
> gut stehen, das die Autokonfiguration ohne Konflikte in seinen/ihren
> Umfeld klappt. Nur wenn all das Fehlschlaegt waere noch eine manuelle
>  Konfiguration der IPv4-Adressen notwendig. Das duerfte in weit, weit
>  weniger als 0,1% der Faelle der Fall sein.

Nun, diese these haben ich ja oben bereits widerlegt.

> 
> Das wars jetzt erstmal. Auf gezielte Desinformationen seitens Alex, 
> werde ich nur noch reagieren, wenn ich das Gefuehl habe, er koennte 
> damit Erfolg haben. Ansonsten sind aber alle herzlich dazu eingeladen
>  Fragen zu stellen und *konstruktive* Kritik zu ueben.

Die fragen sind da oben. Ich folge deiner these nicht, das ipv4
interconnectivity und uplink connectivity kurz und mittelfristig
überflüssig ist.

Eine lösung zu entwerfen, die in der freifunk realität nicht brauchbar
ist, ist auch keine lösung, d.h. relativ keine subnetze pro community.

Nat auf den nodes ist abzuschaffen, also müssen relativ kleine subnetze
an die nodes verteilt werden.

Im rahmen einer konstruktiven diskussion würde mich deine meinung
interessieren.

> 
> Alina

Alex
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAksN49sACgkQhx2RbV7T5aHXNgCdHioVawkmpZeLYXV4okz3nJVj
IJoAoMiA/Ua8WqeT9RpOzX2Ryp/yarL4
=vnlE
-----END PGP SIGNATURE-----