[Berlin-wireless] Freifunk Vortrag fuer Fortgeschrittene

[Alexander Morlang]

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

Alina Friedrichsen schrieb:
> Hallo keks!
> 

...

>> Problem "V6-Traffic" ins internet routen:
> 
> Darueber hab ich mir mir schon einige Gedanken gemacht. Problem wir
> braeuchten dafuer erstmal ein olsrd-Modul, das noch geschrieben
> werden muss. (Koennte Dir das Konzept gern mal in der c-base
> erklaeren.)

Wenn es das gleiche konzept ist wie auf dem 25c3 und den monaten davor,
dann rate ich dir zu einem realitätsupdate.

> 
> Bis dahin wuerde ich erstmal einen IPv6-in-IPv4 Tunnel zu Deinem
> Lieblings Tunnel-Broker aufbauen um Dir die v6 Public-IPs zu holen.
> 
> (Durch NAT haben die normalerweise keine Probleme, duerfte aber
> interessant werden durch die ganze SIIT-Konstruktion)

warum?

> 
>> Später per BGP mit unseren eigenen IPv6 - Adressraum möglich, wenn
>>  tunnel vom DSL-Anschluss ( dem Internetberetsteller) auf dem BGP-
>>  Konten enden. Nur welche Tunnel sollte man hierfür verwenden?
> 
> Das waere das Problem und wuerde dem dezentralen Grundgedanken
> unseres Meshes zuwider laufen. Deswegen sollten wir finde ich an
> einem Weg arbeiten, bei der wir auf jede Form eines oder weniger
> zentraler Server fuers routen von/zum Internet verzichten koennen.

So lange nicht über einen zentralen server punkt zo punkt getunnelt wird
(wie bei openvpn), sondern dezentral, wie bei tinc (leider b0rken), n2n
(leider der supernode zentral) und es mehrere "übergabepunkte" gibt,
läuft es dem dezentralen gedanken in keinster weise zuwieder.

Das problem bei ipv6 ist, das wir /64 prefixe auf die lan-ports legen
wollen, und das möglichst öhne uns von (eigenen) tunneln abhängig zu
machen. Im moment ist es so, das man als endkunde ein /48 prefix
bekommt, das sind 65536 /64 prefixe zum verteilen. Verteile ich diese
nun in meiner nachbarschaft und announce ein 2000::/3, geht das auch alles.

Kommt dann aber in meiner nachbarschaft jemand auf die idee, auch ein
2000::/3 zu announcen, fliesst traffic von entfernteren nachbarn zu
diesem neuen uplink, trägt aber eine absendeadresse aus meinem /48.

Diese pakete werden dann vom antispoofingfilter des providers weggeworfen.

D.h., das prefix auf dem lanport muss aus einem pool des uplinks kommen
und sich im falle eines mobility events ändern (können).

Es fehlt also an einigen stellen:
* allocation von prefixen
* routing der pakete zum "richtigen" uplink

Alle lösungsansätze, die ich bisher gehört hab, haben mich nicht
überzeugt, sei es, das sie "u7nsauber" sind, diskriminierend sind oder
von einer idealen welt ausgehn.

Ausserdem ist das tunnelthema ist unabhängig von siit und 6mesh zu
betrachten.

> 
> Was wuerde das dezentralste Netz bringen, wenn aller Traffic ins
> Internet ueber einen oder wenige zentrale Server gehen wuerde? Bei
> IPv4 Public-IPs geht das leider nicht anders, aber da daemmen wir das
> Problem aber auch mit NAT ein, so das zumindest nicht aller Traffic
> ueber den VPN-Server laufen muss.
> 
> Liebe Gruesse Alina
> 

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

iEYEARECAAYFAkl6JC4ACgkQhx2RbV7T5aHM0gCfbHqfVpvt0smXbPU0SclaiXW6
XcYAn3KSXeAm6auAVbZuNLOc8mjlQAYN
=E63s
-----END PGP SIGNATURE-----