[Berlin-wireless] public IPv6 für Clients im BBB ausschalten

[Bastian]

Hallo,

grundsätzlich +1, Detailed wall-of-text als Inline-reply

On 08/06/2016 03:28 PM, Alexander Couzens wrote:
> Da aktuell das IPv6 leider mehr recht als schlecht funktioniert würde
> ich vorschlagen es ausszuschalten.

An dieser Stelle bitte  mehr Details. Es den Eyeballs gegenüber
abzuschalten, also kein RA/DHCPv6 für Endgeräte anzubieten halte ich für
sinnvoll. Den ganzen OLSR für IPv6 abzuschießen bedeutet auch es für
alle anderen kaputt zu machen.

Alleine wegen dem nun über 1 Jahr altem
https://github.com/freifunk-berlin/firmware/issues/263 Issue, welches
AFAIK noch immer nicht gefixt ist, sind sowieso alle ungepflegten
BBB-Standorte mit broken IPv6 unterwegs.

Ich nutze unseren IPv6-BBB aktiv für Maintenance. Alleine die Tatsache,
das unsere BBB-Standorte via <node-name>.pberg.freifunk.net (Danke
Patrick!) direkt aus dem Internet erreichbar sind ist es IMHO wert das
solange weiter laufen zu lassen bis eine gleichwertige Alternative besteht.

> Wieso?
> IPv6 wird bevorzugt gegenüber IPv4 von allen Endgeräten!
> 
> In unserem Netz ist das aber genau das Gegenteil.
> IPv6 hat genau einen Exit Knoten.
> IPv4 hat viele Exit Knoten und jeder kann einen Knoten erstellen.

Es sind derzeit eigentlich 2 IPv6 Uplinks im BBB - unsere beiden FTTR
Standorte in der Luetzowstr. 105 und Stromstr. 2a. An beiden Standorten
hat unser AS44194 auch eine gute Anbindung zu AS25291 (sys11).

Wir haben inzwischen aber mehrere quasi FTTR Standorte dank der
Unterstützung durch SysEleven. An diesen Standorten gibt es schnelles
IPv4 via AS25291 aber kein IPv6. Das ist zwar in erster Linie unserer
OLSRv1 Architektur geschuldet, kann aber eigentlich mit einem Tunnel
oder VLAN zu unseren DC-Standorten umgangen werden.
Scheitern wird es wohl an der eingesetzten Technik an diesen Standorten.
Ein natives VLAN bis zum OLSRv1 Router scheint nicht möglich zu sein, da
diese Standorte mit Layer3 terminieren. (Hier lasse ich mich gerne eines
besseren belehren.) Also bleibt nur ein Layer2-Tunnel vom jeweiligen
Core-Router zu uns, dieser scheitert aber an veralteter "Kathleen
Firmware" ohne die nötigen Kernel-Module-Packages. (kmod-l2tp, kmod-gre*)

Wenn ich schon sehe das die Emma ein "kathleen 0.0.0, based OpenWRT
r42554" vom Sommer 2014 fährt oder ritter-lobeck-core gar kein OLSRv6
aktiv hat, dafür aber mit 192.168.1.1 im OLSR unterwegs ist, dann kann
ich mir nicht vorstellen das wir es jemals schaffen ein brauchbares IPv6
im BBB auszurollen...

> Zusätzlich möchte ich offen dafür aussprechen, das IPv6 nur noch mit
> olsr2 zu machen. olsr1 wird nicht mehr aktiv weiterentwickelt und
> macht uns schon immer viele Probleme. Z.B. muss der komplette Daemon
> neugestartet werden, wenn ein Interface hinzugefügt wird.

+1 (obgleich der new-Iface restart jetzt wirklich nicht schmerzt)
Ich hab ja schonmal vor einem Jahr versucht genau dieses Thema zu
pushen. Auf der Zwingli rennt deswegen seit 12 Monaten OLSRv2 für IPv6.
Das Setup ist hier auf der ML dokumentiert worden, leider hat sich aber
niemand soweit dafür interessiert um auch mal weitere Router im BBB mit
OLSRv2 auszustatten.

> Es gibt zwischen olsr1 und olsr2 auch keine Kompatiblität.

Ich hab inzwischen ein Konzept mit PoC an unseren drei DC-Standorten um
IPv6-Routen zwischen OLSRv1 und OLSRv2 auszutauschen. Einfach ist die
forward-only Migration, also nur Routen nach OLSRv2 zu pushen. Der
Rückweg ist wesentlich aufwändiger, aber ggf. auch gar nicht nötig.
Drei VMs - bbb-l105 / bbb-a36s / bbb-st2a - auf Basis von einem
aktuellen Upstream LEDE-build und frischem OONF-olsrd2 sprechen
untereinander nur OLSRv2 aber mit anderen BBB-mesh-nodes noch OLSRv1.
bbb-a36s hat noch keine anderen Mesh-Partner, könnte aber als
Tunnel-/VLAN-Endpunkt für die Sys11 Standorte dienen.

Es wäre natürlich toll wenn sich nun wirklich mal Menschen finden lassen
die IPv6 im BBB mit einem sinnvollen Konzept auf stabile Beine stellen
wollen, aber ...

Cheers, Bastian


-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 473 bytes
Beschreibung: OpenPGP digital signature
URL         : <https://lists.berlin.freifunk.net/pipermail/berlin/attachments/20160807/1f11c682/attachment.sig>