Arbeitsgruppe IPv6 im Mesh: Unterschied zwischen den Versionen

Aus FunkFeuer Wiki
Wechseln zu: Navigation, Suche
(Beschreibung der Ausgangssituation)
K
 
(18 dazwischenliegende Versionen von 4 Benutzern werden nicht angezeigt)
Zeile 3: Zeile 3:
 
und wenn dieses blöde Mediawiki nicht gerade meine Arbeite gefressen hätte, dann wäre hier auch schon ur viel zu lesen. *grml*
 
und wenn dieses blöde Mediawiki nicht gerade meine Arbeite gefressen hätte, dann wäre hier auch schon ur viel zu lesen. *grml*
  
−
=IPv6 im Mesh=
+
Es gibt ca. 2 Mrd. öffentliche IPv4 Adressen. Davon sind ca 74% unter der Kontrolle der USA, vom Rest hab' ich allein 5 bei Funkfeuer registriert und muss trotzdem NAT verwenden. Da dies eher unbefriedigend ist, wurde IPv6 entwickelt, das aber bisher noch nicht wirklich große Verbreitung gefunden hat. Was liegt also näher als diese neue Technologie in einem experimentellen Netz wie Funkfeuer auszuprobieren?
  
−
Es gibt ca. 2 Mrd. öffentliche IPv4 Adressen. Davon sind ca 74% unter der Kontrolle der USA, vom Rest hab' ich allein 5 bei Funkfeuer registriert und muss trotzdem NAT verwenden. Da dies eher unbefriedigend ist, wurde IPv6 entwickelt, das aber bisher noch nicht wirklich große Verbreitung gefunden hat. Was liegt also näher als diese neue Technologie in einem experiementellen Netz wie Funkfeuer auszuprobieren?
+
=Was wir schon haben=
−
 
+
−
==Probleme==
+
−
* Mittelfristig werden nicht alle Router IP6 Forwarding unterstützen
+
−
* Die Routingtabelle für jedes Protokoll extra zu berechnen macht nicht wirklich viel Sinn
+
−
* Bei Verwendung einer klassischen Tunnellösung geht interner traffic vom Mesh zu einem zentralen Server und wieder zurück ins Mesh. Das ist nicht schön.
+
−
 
+
−
==Was wir schon haben==
+
 
* Einen großen Block IP6 Adressen
 
* Einen großen Block IP6 Adressen
 
* natives IP6 im housing
 
* natives IP6 im housing
 
* öffentliche IP4 Adressen auf allen Routern
 
* öffentliche IP4 Adressen auf allen Routern
 +
 +
 +
=Probleme=
 +
* Mittelfristig werden nicht alle Mesh-Router IP6 Forwarding unterstützen
 +
* Die Routingtabelle für jedes Protokoll extra zu berechnen ergibt nicht wirklich viel Sinn
 +
* Bei Verwendung einer klassischen Tunnellösung geht interner traffic vom Mesh zu einem zentralen Server und wieder zurück ins Mesh. Das ist nicht schön. Eine Lösung dafür wären a) verteilte Tunnelserver, b) natives IPv6 möglichst bald durch Umstellung möglichst vieler Router.
 +
 +
=Lösungsvorschläge=
 +
==6to4 Tunnel==
 +
Bei IPv6 gibt es einen eigenen Prefix (2002:/16) unter dem jeder IP4 Adresse ein (ziemlich großes) IP6 Subnetz zugeornet ist. Diese Adressen sind zum Übergang zwischen IPv4 und IPv6 gedacht.
 +
 +
===Vorteile===
 +
* Es muss kein eigener IP6 Adressblock registriert/verwaltet werden
 +
* Die Infrastruktur von IPv4 kann mitbenutzt werden
 +
* Pakete zwischen Mesh Nodes gehen über den natürlichen Weg im Mesh
 +
* Es funktioniert mit allen relevanten Firmwares, sofern diese mit IPv6-Unterstützung zusammengestellt wurden.
 +
 +
===Nachteile===
 +
* Eigene IP6 Blöcke können nicht im Internat angekündigt werden
 +
* Ein 6to4 anycast server in unserer Nähe wäre fein **)
 +
* Es wird eine öffentliche IPv4 Adresse benötigt
 +
 +
 +
- **: Theoretisch kann ein 6to4 Anycast auf dafür eingerichteten Routern Mesh-intern mittels Anycast von 192.88.99.1 eingerichtet werden. Problematisch ist dies hinsichtlich des dynamischen Routings (zur Problematik siehe auch http://en.wikipedia.org/wiki/IPv6_rapid_deployment) und hinsichtlich IP Protokoll 41 - wenn letzteres nicht weitergeleitet wird (Firewalls mit DROP Policy ohne Ausnahme für Protokoll 41) ist jedweder 6to4, 6in4 oder 6rd Tunnel nicht möglich. Eine Ausnahme davon ist Teredo, das über UDP arbeitet und somit auch hinter restriktiven Firewalls arbeitet. Damit sind dynamische Tunnel auch hinter 3G-Mobilfunkroutern/mit 3G-Sticks, die zumeist private IPs und NAT verwenden, möglich.
 +
 +
===Funktionsweise beim Routen eines Pakets===
 +
Wenn wir ein IP6 Route haben: Wir benutzen diese
 +
 +
Die Zieladdresse ist eine 6to4 Adresse: Wir geben das Paket in ein 6to4 Tunnelpaket und senden dieses and die IP4 Adresse des zuständigen Gateways.
 +
 +
Die Zieladdresse ist eine andere IP6 Adresse: Wir geben das Paket in ein 6to4 Tunnelpaket und senden dieses and die 6to4 anycast Adresse (192.88.99.1).
 +
 +
===Let's do it===
 +
Zuerst müssen wir die Unterstützung für IPv6 in den Kernel laden:
 +
 +
ipkg install kmod-ipv6
 +
insmod /path/to/ipv6.o
 +
 +
Als nächstes müssen wir für unsere IP4 Adresse den 6to4 Prefix berechnen. Dazu geben wir folgenden Befehl in eine Unix Shell (die Shell von freifunkfirmware genügt leider nicht, die von kamikaze schon) ein:
 +
 +
MYIP="78.41.112.63"
 +
PREFIX=$(printf "2002:%02x%02x:%02x%02x" $(echo $MYIP | tr "." " ") )
 +
echo $PREFIX
 +
 +
Zum Beispiel für die ip 78.41.112.63 ist das Ergebnis "2002:4e29:703f".
 +
 +
Als nächstes wollen wir das ganze einmal temporär konfigurieren, um es auszuprobieren. Dazu geben wir am Router die folgenden Befehle ein:
 +
 +
ip tunnel add tun6to4 mode sit ttl 64 remote any local $MYIP
 +
ip link set dev tun6to4 up
 +
ip -6 addr add $PREFIX::1/16 dev tun6to4    # /16 ist richtig
 +
ip -6 route add default via ::192.88.99.1 dev tun6to4
 +
 +
:Bemerkung: Wir verwenden in Zeile 3 /16 anstelle der sonst üblichen /64, weil ja alle 6to4 Adressen über den Tunnel direkt erreichbar sind und nicht nur unsere eigene... Würden wir /64 verwenden, dann würden Routen zu IPs im Mesh über den anycast server gehen, also nicht mehr den "natürlichen Weg", was 6to4 irgendwie ad absurdum führen würde - da könnten wir gleich eine zentrale Tunnellösung verwenden.
 +
 +
So, nun sollte der Router unter der IP6 Addresse $PREFIX::1 erreichbar sein. Damit wir das aber auch nutzen können, müssen
 +
wir auch noch IPv6 am LAN konfigurieren. Wie das genau geht, hängt von der Firmware ab. Ich hab' bei mir folgendes gemacht.
 +
 +
Am Router:
 +
ip -6 addr add $PREFIX:1::1/64 dev vlan0
 +
 +
Und am PC:
 +
sudo ip -6 addr add $PREFIX:1::2/64 dev eth0
 +
sudo ip -6 route add default via $PREFIX:1::1
 +
 +
Anstatt am PC händisch IP und route einzutragen kann man auch die Autokonfiguration von IPv6 verwenden. Siehe dazu die Anleitung weiter [[#Adressautokonfiguration | unten]].
 +
 +
Nun sollten wir vom PC aus die IPv6 Verbindung testen können, z.B. mit:
 +
ping6 marvin.funkfeuer.at
 +
 +
Wenn das oben nicht reicht (linksys/whiterussian machte probleme) dann noch
 +
sysctl -w net.ipv6.conf.all.forwarding=1
 +
 +
Weil v6 forwarding bei mir ausgeschaltet war
 +
 +
und
 +
ip -6 route add 2000::/3  via ::192.88.99.1 dev tun6to4
 +
 +
weil das routing mit der defaultroute so nicht geklappt hat
 +
 +
===Dauerhafte Konfiguration für FFF===
 +
Folgendes Skript stellt die obige Konfiguration bei einem Neustart wieder her. Die Parameter am Beginn müssen natürlich für jeden Router angepasst werden (Mag wer ein .ipk mit einer Seite für's webinterface schreiben?). **
 +
 +
/etc/init.d/S556to4
 +
#!/bin/sh
 +
 +
MYIP="127.43.233.17"
 +
PREFIX=$(printf "2002:%02x%02x:%02x%02x" $(echo $MYIP | tr "." " ") )
 +
LANDEV="vlan0"
 +
 +
case $1 in
 +
    start)
 +
ip tunnel add tun6to4 mode sit ttl 64 remote any local $MYIP
 +
ip link set dev tun6to4 up
 +
ip -6 addr add $PREFIX::1/16 dev tun6to4
 +
ip -6 route add default via ::192.88.99.1 dev tun6to4
 +
 +
ip -6 addr add $PREFIX:1::1/64 dev $LANDEV
 +
;;
 +
 +
    stop)
 +
    ip tunnel del tun6to4
 +
    ip -6 addr del $PREFIX:1::1/64 dev $LANDEV
 +
;;
 +
 +
    *)
 +
    echo "Usage: $0 {start|stop}"
 +
exit 1
 +
;;
 +
esac
 +
 +
- ** Auf neueren Firmwares (Backfire und 0xFF-OS) sind die Pakete 6scripts (/etc/config/6tunnel) und luci-proto-6x4 dafür heranzuziehen.
 +
 +
===Offene Fragen===
 +
* Wie gut funktioniert pathmtu discovery?
 +
** Bei meinen bisherigen Tests (mit tracepath6 und ein paar Tage normale Nutzung) war's ok sowohl zu 6to4 Adressen als auch zu echten IP6 Adressen. - Tests in die andere Richtung wären aber auch noch nett.
 +
* Bisher alle Tests ganz ohne Firewall (nicht einmal IPv4)
 +
* Eigener anycast server für Funkfeuer?
 +
* DNS für IP6 Adressen?
 +
 +
=Lokale IPv6 Konfiguration=
 +
==Adressautokonfiguration==
 +
Ein nettes Feature von IPv6 ist die automatische Konfiguration der Adressen auf den Clients durch das IPv6 Protokoll selbst (also ganz ohne DHCP). Damit das funktioniert, muss am Router allerdings ein sogenannter ''router advertisement daemon (radvd)'' laufen, der den Router im Netz ankündigt.
 +
 +
===Installation des radvd===
 +
Der radvd wird sowohl von der Freifunkfirmware als auch von OpenWRT/kamikaze unterstützt. Nach einem
 +
 +
ipkg install radvd
 +
 +
befindet sich in /etc/radvd.conf eine Beispielkonfiguration, die noch an das System angepasst werden muss. Zunächst müssen wir den IPv6 Prefix, den wir am LAN-Interface (bei meinem Router ist das vlan0, bei anderen Routern heißt es vielleicht eth0, eth0.0, br0, br-lan, ...) verwenden, herausfinden:
 +
 +
root@OpenWrt:/etc# ip addr show dev vlan0
 +
4: vlan0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue
 +
    link/ether 00:16:01:92:8b:f2 brd ff:ff:ff:ff:ff:ff
 +
    inet 192.168.11.1/24 brd 192.168.11.255 scope global vlan0
 +
    inet6 fe80::216:1ff:fe92:8bf2/64 scope link
 +
    inet6 2002:c1ee:9eb2:1::1/64 scope global
 +
 +
Die globale inet6 Adresse ist das was uns interessiert. Die Adresse ist "2002:c1ee:9eb2:1::1", der Prefix ist "2002:c1ee:9eb2:1::/64" - ohne der letzten Eins in der Ausgabe von ip!
 +
 +
Diesen Prefix brauchen wir jetzt um am Router eine passende /etc/radvd.conf Datei zu erstellen. In meinem Fall sieht die Datei so aus:
 +
 +
interface vlan0
 +
{
 +
        AdvSendAdvert on;
 +
        prefix 2002:c1ee:9eb2:1::/64
 +
        {
 +
                AdvOnLink on;
 +
                AdvAutonomous on;
 +
                AdvRouterAddr off;
 +
        };
 +
};
 +
 +
Das Interface und der Prefix sind entsprechend zu ersetzen!
 +
 +
Bei kamikaze müssen wir auch noch explizit aktivieren, dass der radvd beim Booten gestartet werden soll:
 +
/etc/init.d/radvd enable
 +
 +
Jetzt muss der radvd noch gestartet werden:
 +
 +
/etc/init.d/S51radvd start    #Freifunkfirmware
 +
/etc/init.d/radvd start      #kamikaze
 +
 +
Achtung: Der radvd ist sehr sparsam, was Fehlermeldungen betrifft. Wenn es nicht funktioniert den radvd am besten mit der Hand mit Debug level 5 starten.
 +
 +
radvd -d 5
 +
 +
In der Freifunkfirmware sieht man die Ausgabe von radvd nur mit dem Befehl logread.
 +
 +
==Firewall==
 +
Leute, die ihren Usern (oder ihrem Betriebssystem) nicht vertrauen, wollen wahrscheinlich eine Firewall am Router haben. Will jemand eine passende Firewallkonfig vorschlagen?
 +
 +
=Weitere Quellen=
 +
* http://debienna.at/IPv6to4
 +
* http://wiki.debian.org/DebianIPv6
 +
* http://wiki.openwrt.org/IPv6_howto
 +
* [http://blogs.k-ita.de/~alx/?p=91|Stateless IPCM/IP Translation nach rfc2765]
 +
* [https://www.ripe.net/lir-services/training/e-learning/ipv6/transition-mechanisms|four videos on IPv6 Transition Mechanisms @ RIPE online training]

Aktuelle Version vom 2. September 2013, 01:33 Uhr

Achtung dies ist ein WoW (Maintainer: siehe Changelog)

und wenn dieses blöde Mediawiki nicht gerade meine Arbeite gefressen hätte, dann wäre hier auch schon ur viel zu lesen. *grml*

Es gibt ca. 2 Mrd. öffentliche IPv4 Adressen. Davon sind ca 74% unter der Kontrolle der USA, vom Rest hab' ich allein 5 bei Funkfeuer registriert und muss trotzdem NAT verwenden. Da dies eher unbefriedigend ist, wurde IPv6 entwickelt, das aber bisher noch nicht wirklich große Verbreitung gefunden hat. Was liegt also näher als diese neue Technologie in einem experimentellen Netz wie Funkfeuer auszuprobieren?

Was wir schon haben

  • Einen großen Block IP6 Adressen
  • natives IP6 im housing
  • öffentliche IP4 Adressen auf allen Routern


Probleme

  • Mittelfristig werden nicht alle Mesh-Router IP6 Forwarding unterstützen
  • Die Routingtabelle für jedes Protokoll extra zu berechnen ergibt nicht wirklich viel Sinn
  • Bei Verwendung einer klassischen Tunnellösung geht interner traffic vom Mesh zu einem zentralen Server und wieder zurück ins Mesh. Das ist nicht schön. Eine Lösung dafür wären a) verteilte Tunnelserver, b) natives IPv6 möglichst bald durch Umstellung möglichst vieler Router.

Lösungsvorschläge

6to4 Tunnel

Bei IPv6 gibt es einen eigenen Prefix (2002:/16) unter dem jeder IP4 Adresse ein (ziemlich großes) IP6 Subnetz zugeornet ist. Diese Adressen sind zum Übergang zwischen IPv4 und IPv6 gedacht.

Vorteile

  • Es muss kein eigener IP6 Adressblock registriert/verwaltet werden
  • Die Infrastruktur von IPv4 kann mitbenutzt werden
  • Pakete zwischen Mesh Nodes gehen über den natürlichen Weg im Mesh
  • Es funktioniert mit allen relevanten Firmwares, sofern diese mit IPv6-Unterstützung zusammengestellt wurden.

Nachteile

  • Eigene IP6 Blöcke können nicht im Internat angekündigt werden
  • Ein 6to4 anycast server in unserer Nähe wäre fein **)
  • Es wird eine öffentliche IPv4 Adresse benötigt


- **: Theoretisch kann ein 6to4 Anycast auf dafür eingerichteten Routern Mesh-intern mittels Anycast von 192.88.99.1 eingerichtet werden. Problematisch ist dies hinsichtlich des dynamischen Routings (zur Problematik siehe auch http://en.wikipedia.org/wiki/IPv6_rapid_deployment) und hinsichtlich IP Protokoll 41 - wenn letzteres nicht weitergeleitet wird (Firewalls mit DROP Policy ohne Ausnahme für Protokoll 41) ist jedweder 6to4, 6in4 oder 6rd Tunnel nicht möglich. Eine Ausnahme davon ist Teredo, das über UDP arbeitet und somit auch hinter restriktiven Firewalls arbeitet. Damit sind dynamische Tunnel auch hinter 3G-Mobilfunkroutern/mit 3G-Sticks, die zumeist private IPs und NAT verwenden, möglich.

Funktionsweise beim Routen eines Pakets

Wenn wir ein IP6 Route haben: Wir benutzen diese

Die Zieladdresse ist eine 6to4 Adresse: Wir geben das Paket in ein 6to4 Tunnelpaket und senden dieses and die IP4 Adresse des zuständigen Gateways.

Die Zieladdresse ist eine andere IP6 Adresse: Wir geben das Paket in ein 6to4 Tunnelpaket und senden dieses and die 6to4 anycast Adresse (192.88.99.1).

Let's do it

Zuerst müssen wir die Unterstützung für IPv6 in den Kernel laden: 

ipkg install kmod-ipv6
insmod /path/to/ipv6.o

Als nächstes müssen wir für unsere IP4 Adresse den 6to4 Prefix berechnen. Dazu geben wir folgenden Befehl in eine Unix Shell (die Shell von freifunkfirmware genügt leider nicht, die von kamikaze schon) ein: 

MYIP="78.41.112.63"
PREFIX=$(printf "2002:%02x%02x:%02x%02x" $(echo $MYIP | tr "." " ") )
echo $PREFIX

Zum Beispiel für die ip 78.41.112.63 ist das Ergebnis "2002:4e29:703f".

Als nächstes wollen wir das ganze einmal temporär konfigurieren, um es auszuprobieren. Dazu geben wir am Router die folgenden Befehle ein: 

ip tunnel add tun6to4 mode sit ttl 64 remote any local $MYIP
ip link set dev tun6to4 up
ip -6 addr add $PREFIX::1/16 dev tun6to4    # /16 ist richtig
ip -6 route add default via ::192.88.99.1 dev tun6to4
Bemerkung: Wir verwenden in Zeile 3 /16 anstelle der sonst üblichen /64, weil ja alle 6to4 Adressen über den Tunnel direkt erreichbar sind und nicht nur unsere eigene... Würden wir /64 verwenden, dann würden Routen zu IPs im Mesh über den anycast server gehen, also nicht mehr den "natürlichen Weg", was 6to4 irgendwie ad absurdum führen würde - da könnten wir gleich eine zentrale Tunnellösung verwenden.

So, nun sollte der Router unter der IP6 Addresse $PREFIX::1 erreichbar sein. Damit wir das aber auch nutzen können, müssen wir auch noch IPv6 am LAN konfigurieren. Wie das genau geht, hängt von der Firmware ab. Ich hab' bei mir folgendes gemacht.

Am Router: 

ip -6 addr add $PREFIX:1::1/64 dev vlan0

Und am PC: 

sudo ip -6 addr add $PREFIX:1::2/64 dev eth0
sudo ip -6 route add default via $PREFIX:1::1

Anstatt am PC händisch IP und route einzutragen kann man auch die Autokonfiguration von IPv6 verwenden. Siehe dazu die Anleitung weiter unten.

Nun sollten wir vom PC aus die IPv6 Verbindung testen können, z.B. mit: 

ping6 marvin.funkfeuer.at

Wenn das oben nicht reicht (linksys/whiterussian machte probleme) dann noch 

sysctl -w net.ipv6.conf.all.forwarding=1

Weil v6 forwarding bei mir ausgeschaltet war

und 

ip -6 route add 2000::/3  via ::192.88.99.1 dev tun6to4

weil das routing mit der defaultroute so nicht geklappt hat

Dauerhafte Konfiguration für FFF

Folgendes Skript stellt die obige Konfiguration bei einem Neustart wieder her. Die Parameter am Beginn müssen natürlich für jeden Router angepasst werden (Mag wer ein .ipk mit einer Seite für's webinterface schreiben?). **

/etc/init.d/S556to4 

#!/bin/sh

MYIP="127.43.233.17"
PREFIX=$(printf "2002:%02x%02x:%02x%02x" $(echo $MYIP | tr "." " ") )
LANDEV="vlan0"

case $1 in 
    start)
	ip tunnel add tun6to4 mode sit ttl 64 remote any local $MYIP
	ip link set dev tun6to4 up
	ip -6 addr add $PREFIX::1/16 dev tun6to4
	ip -6 route add default via ::192.88.99.1 dev tun6to4

	ip -6 addr add $PREFIX:1::1/64 dev $LANDEV
	;;

    stop)
    	ip tunnel del tun6to4
    	ip -6 addr del $PREFIX:1::1/64 dev $LANDEV
	;;

    *)
    	echo "Usage: $0 {start|stop}"
	exit 1
	;;
esac

- ** Auf neueren Firmwares (Backfire und 0xFF-OS) sind die Pakete 6scripts (/etc/config/6tunnel) und luci-proto-6x4 dafür heranzuziehen.

Offene Fragen

  • Wie gut funktioniert pathmtu discovery?
    • Bei meinen bisherigen Tests (mit tracepath6 und ein paar Tage normale Nutzung) war's ok sowohl zu 6to4 Adressen als auch zu echten IP6 Adressen. - Tests in die andere Richtung wären aber auch noch nett.
  • Bisher alle Tests ganz ohne Firewall (nicht einmal IPv4)
  • Eigener anycast server für Funkfeuer?
  • DNS für IP6 Adressen?

Lokale IPv6 Konfiguration

Adressautokonfiguration

Ein nettes Feature von IPv6 ist die automatische Konfiguration der Adressen auf den Clients durch das IPv6 Protokoll selbst (also ganz ohne DHCP). Damit das funktioniert, muss am Router allerdings ein sogenannter router advertisement daemon (radvd) laufen, der den Router im Netz ankündigt.

Installation des radvd

Der radvd wird sowohl von der Freifunkfirmware als auch von OpenWRT/kamikaze unterstützt. Nach einem 

ipkg install radvd

befindet sich in /etc/radvd.conf eine Beispielkonfiguration, die noch an das System angepasst werden muss. Zunächst müssen wir den IPv6 Prefix, den wir am LAN-Interface (bei meinem Router ist das vlan0, bei anderen Routern heißt es vielleicht eth0, eth0.0, br0, br-lan, ...) verwenden, herausfinden: 

root@OpenWrt:/etc# ip addr show dev vlan0
4: vlan0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue
   link/ether 00:16:01:92:8b:f2 brd ff:ff:ff:ff:ff:ff
   inet 192.168.11.1/24 brd 192.168.11.255 scope global vlan0
   inet6 fe80::216:1ff:fe92:8bf2/64 scope link
   inet6 2002:c1ee:9eb2:1::1/64 scope global

Die globale inet6 Adresse ist das was uns interessiert. Die Adresse ist "2002:c1ee:9eb2:1::1", der Prefix ist "2002:c1ee:9eb2:1::/64" - ohne der letzten Eins in der Ausgabe von ip!

Diesen Prefix brauchen wir jetzt um am Router eine passende /etc/radvd.conf Datei zu erstellen. In meinem Fall sieht die Datei so aus: 

interface vlan0
{
        AdvSendAdvert on;
        prefix 2002:c1ee:9eb2:1::/64
        {
                AdvOnLink on;
                AdvAutonomous on;
                AdvRouterAddr off;
        };
};

Das Interface und der Prefix sind entsprechend zu ersetzen!

Bei kamikaze müssen wir auch noch explizit aktivieren, dass der radvd beim Booten gestartet werden soll: 

/etc/init.d/radvd enable

Jetzt muss der radvd noch gestartet werden: 

/etc/init.d/S51radvd start    #Freifunkfirmware
/etc/init.d/radvd start       #kamikaze

Achtung: Der radvd ist sehr sparsam, was Fehlermeldungen betrifft. Wenn es nicht funktioniert den radvd am besten mit der Hand mit Debug level 5 starten. 

radvd -d 5

In der Freifunkfirmware sieht man die Ausgabe von radvd nur mit dem Befehl logread.

Firewall

Leute, die ihren Usern (oder ihrem Betriebssystem) nicht vertrauen, wollen wahrscheinlich eine Firewall am Router haben. Will jemand eine passende Firewallkonfig vorschlagen?

Weitere Quellen

Von „https://oldwiki.funkfeuer.at/index.php?title=Arbeitsgruppe_IPv6_im_Mesh&oldid=13744“