[Berlin-wireless] Fwd: Core post from computer.ist.org at gmx.at requires approval

[Aaron Kaplan]

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



Hi!

hier ein paar erfahrungen aus Wien mit public IPs - vielleicht hilft  
es euch:

/29 fuer jeden haushalt waere schoen aber da geht uns das /22 ganz  
ganz schnell aus.
In berlin wird das sich gleich verhalten. Deswegen sind wir wieder  
auf private IPs + NAT fuer die wohnung.

Geht sehr vorsichtig mit der kostbaren ressource IPs um.
Derzeit wird hier gerade eine art "cool down/tear down time"  
ueberlegt: wenn eine IP einige zeit nicht in verwendung war, dann  
wird sie fuer einige monate auf inaktive gesetzt und dann erst wieder  
frei verfuegbar gemacht.

IP autoconfig ist ein teil des OLSR-NG programms. Loesungen immer  
willkommen!
IP autoconfig loest aber natuerlich nicht das problem, dass ein /21  
endlich ist.

BroadCastAddress kann 255.255.255.255 sein und man kann parallel  
netze in olsr fahren.
Das geht. Aber nur unter linux.


Begin forwarded message:

>
>
> Hallo Liste
>
> Folgende Sachen sind meinem Hirn entsprungen und bedürfen Kommentaren.
>
> Wir vergeben jedem Benutzer wie gehabt eine IP pro Gerät. Braucht  
> Mensch
> IP-Adressen für ein Hausnetz, so bekommt er zusätzlich ein /29 (6
> Adressen, 4 Geräte) oder /28 (12 Geräte). Damit erreichen wir, dass  
> ein
> Freifunk-Router mit einer IP dahinter ganz locker das /29 ankündigen
> kann (HNA). NAT gehört der Geschichte an.
>

> Das Routing ins GBI wird vorerst über tincVPN gehandhabt. Die tinc- 
> Wolke
> hat eine Anbindung an IN-Berlin, welche die Adressen ins GBI  
> routen. Ein
> und ausgehender Traffic läuft über die Tunnel auf den DSL-Uplinks.
>
> Die Frage ist, wie gehen wir zukünftig damit um, wenn der Traffic  
> steigt.
> a) WLAN-Anbindung direkt zum Upstream
> b) Wie können wir die DSL-NAT-Sachen benutzen (Problem outgoing- 
> incoming)
> c) ...?
>
> Außer der Frage der genauen Konnektivität steht die Migration von  
> 104/8
> auf 77.87.48.0/21 im Raum. Leider war ich letzte Woche nicht in der
> c-base und habe scheinbar Lösungsszenarien (Marek?) verpasst.
>
> a) Wir hauen mit einer neuen Firmware und dem Holzhammer auf den  
> Tisch.
> Es gibt nur noch 77.87.xx und das Netz dümpelt 1 Woche rum, bis alle
> umgestellt haben. Broadcast ist dann 77.87.55.255
>
> b) Wir bauen eine neue Firmware und packen broadcast 255.255.255.255
> (alxh) standardmäßig ein. @alx: was sagen die Tests?
>
geht und linux, nicht under *BSD , nicht unter mac, nihct unter windows

> c) Wir versuchen eine langsame Migration mit 77.87. und 104  
> parallel und
> 104 -> 77.87. NAT.
>

> Weiterhin haben wir Betätigungsfelder in den Bereichen:
> - IP-Vergabe umbauen
>
zentral? Oder IP autoconfig und DaD?

> - IP-Vergabe aufräumen (verify)
> - Dokumentation aktualisieren
>
> Freue mich auf die Kommentare.
>
> Grüße
>
> Daniel
>
>

- ---
there's no place like 127.0.0.1


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGWFcvxEgyMttZ8YwRAvrAAKCwiYo0miPi6g1MrW33JWJ/G2OtaACbBqk4
NsZEXxicGQaZ3UGyEWCv1ao=
=jsgk
-----END PGP SIGNATURE-----