[Berlin-wireless] IPv6 + Multi Gateway + Mesh + Groß = ?

[Martin Garbe]

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

On 10/01/2015 10:53 PM, Philipp Borgers wrote:
> On Thu, Oct 01, 2015 at 10:14:19PM +0200, Martin Garbe wrote:
>> Hallo Bastian,
>> 
>> der Wechsel zu OLSRv2 klingt sinnvoll und das sollte auch machbar
>> sein.
> 
> Es gibt auch noch andere Protokolle, die source-specific routing
> implementieren. Ev. macht es Sinn, die auch mal zu untersuchen. Ein
> Beispiel ist babel.

Hat jemand Babel großflächig im Einsatz? Wenn ja, was sind die Gründe
für babel (und gegen olsr)?

> 
>> Bisher haben wir kein eigenes öffentliches IPv6 Prefix. Hierfür
>> haben wir bisher keine Notwendigkeit gesehen. Wir gehen noch
>> davon aus, dass ein ULA Prefix anfangs reicht und dann die
>> Provider-dependent IPv6 Adressen dazu kommen.
> 
> Die ULA-Pr?fixe kann man bei uns auch nutzen mit der Einschr?nkung,
> dass der Router dann nicht ?ffentlich erreichbar ist.
> 
> Das ULA-Mesh ist ev. interessant um eine erste Kommunikation
> zwischen Node und Gateway herzustellen. Gateways k?nnten ja
> ank?ndigen, dass sie noch freie Pr?fixe haben. Nodes k?nnten dann
> f?r eine gewissen Zeit diese Pr?fixe anfragen und konfigurieren.
> Wenn das Gateway nicht mehr erreichbar ist, k?nnte man den Pr?fix
> z.B. freigeben.

Ja, genau das dachten wir uns auch.

> 
>> Habt ihr auch schon mal über DHCPv6 nachgedacht? Mit gewissem
>> Aufwand könnte man das auch ins Mesh integrieren.
> 
> Wie k?nnte das aussehen?

Bisher entscheidet immer der Client, welche IP er hat. Entweder weil
er eine statische IP hat oder sich bei IPv6 selbst ein Prefix-Bereich
sucht. Mit DHCPv6 hätte man auf Server-Seite mehr Kontrolle. Hier kann
man auch mehrere unterschiedliche Prefixe vom Server bekommen, so weit
ich das überblicke. Das Problem hier ist der Weg auf dem die Anfragen
im Mesh geleitet werden sollen, also der Weg vom client zum Server.
Normalerweise sind DHCP Anfragen Multicast. Und dass passt mit Layer3
Mesh Netzen nicht ganz.

> 
>> Am Ende bleibt neben dem statischen Konfigurieren von Prefixen
>> (z.B. mit ULA-Prefix oder anderem statischen IPv6 Prefix) nur
>> noch das Verbreiten von Prefixen durch RAs. Bei mehreren Gateways
>> im Mesh ist dann das Border-Router-Discovery-Protocol sehr
>> ansprechend, weil dies viele unserer Probleme lösen würde. Hierzu
>> scheint es aber noch keine Implementierung zu geben, richtig?
> 
> Ich habe das BRDP noch nicht gelesen/verstanden. Gibt es da eine
> gute Zusammenfassung?

http://www.olsr.org/files/multi-smart-gateway.pdf

> 
>> Wollt ihr bei eurer ein-Prefix Strategie langfristig bleiben oder
>> habt ihr die Dinge bisher so implementiert, weil es die Tool
>> hergeben?
> 
> Wir wollen eigentlich mehr als einen Pr?fix im Netzwerk nutzen.
> Bisher haben wir OLSRv1 f?r IPv6 genutzt und das kann kein
> source-specific routing. Deshalb k?nnen wir auch nicht sinnvoll
> mehr als einen Pr?fix im Mesh deployen.

Wie macht ihr eigentlich die Migration von olsrv1 zu v2?

> 
> Ich sehe zwei gro?e Themenbereiche:
> 
> * Source-Specific Routing einf?hren]
> http://www.olsr.org/files/multi-smart-gateway.pdf * Pr?fix
> Verteilung implementieren
> 
> Ich f?nde es sinnvoll, wenn man Ans?tze mal in einem Pad/Wiki
> festhalten w?rde.

Ja, finde ich auch.

Gruß,
Martin

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQIcBAEBAgAGBQJWDtFrAAoJECpYDDXtBv6x3IYP/iMcCbp6eACxjtjXLg7/tpEC
oHHpxaqT1+0SUlilLwQHwsZgoEEDXjGsIe2DvWJZFtyRDXDM5c2vEzvZwZYxzESW
vayIa509nwn2kqae2UIwvkxETaZLbeHGzcMsiKONxpZjJXDTvTSQnvGR8g7lgHRt
bt4oU1HtpJgaZGytqN2qkTTZjzpO7JKDR5QsgG/li1EDOkm2apzBZIpW94HHXZ9e
hzL3PwBw2DDOPZlRuRhJhfESvhPqH28KxD35o4MZXj1E2OOsMH0M2cTHpRYdwC/p
LoicJDmDiCSgowD//AtVaQNuFhewvyhcOeR3JeOdPFbsbQ26M4gahJuIs/ygeQWQ
ZNQrov0gkTTkaNboxifSE1cYi1+y8530rpQw0vYUjBCvHGsu8qsKQFdCAMJ7tz+b
/0RgD6aefKXkve481db6q/PVIXNoGl+A40dWwYLE5+spztmCtoHFtER08PtdmKcX
iL9JvbCry8oe4kVvg7BZ9u1z3quNUcsUTQOnL/VDwC5F6h+75aNHUdJLuq39na6c
dCaQkmYGVDCbIyu/dpVGRs/IEe+JgDfOpHyVxgSPORQ+bgIck1BW6JxGRv2yaBgt
ZhyHVtFKaZl687LTpFjECOyZkv51rJnuySA20YITNBVAtYba3Zk/iVs7LmKSa+AQ
4r3AK7Q7HGHDyPARa0Zp
=NUBs
-----END PGP SIGNATURE-----