Allgemeine Infos zu IPv6, die grundsätzliche Konfiguration unter Linux und die Einrichtung eines SixXS-Tunnels werden bereits ausgezeichnet im IPv6-Wiki von Ralf Krüdewagen beschrieben, daher werde ich hier nicht nochmals darauf eingehen.

Stattdessen erzähle ich über ein paar Dinge zu DHCP und DNS, die mir erst heute klar geworden sind und zeige, wie die technische Umsetzung funktioniert. Mag sein, dass ich mich hier und da nicht ganz korrekt ausdrücke… Feedback ist willkommen. :-)

Zusammengefasst sind Stand heute folgende Funktionen möglich:

• IPv6-Tunnelnutzung mit SixXS
• Router Advertisement mit radvd
• DHCP-Server für IPv4 / IPv6
• DNS-Server für IPv4 / IPv6
• dynamische DNS-Updates (DDNS) für IPv4 / IPv6

Im Doppelpack

Ich bin bisher davon ausgegangen, dass man entweder “radvd” oder einen IPv6-fähigen DHCP-Server für die dynamische Zuweisung von IP’s verwendet. Richtig ist aber, dass beide Dienste als Team arbeiten. radvd verkündet im Netz lediglich das IPv6-Prefix, also das zu verwendende Subnetz und Angaben zum Router. Clients weisen sich anhand dieser Informationen selbst eine IP-Adresse zu. Wird nur radvd eingesetzt, spricht man von Stateless Address Autoconfiguration. In diesem Szenario können sich Clients bereits im Netz bewegen und mit anderen IP-Adressen/Hosts kommunizieren.

In einem typischen (Heim-)Netzwerk reicht das jedoch nur sehr selten. Das wohl wichtigste Feature ist das Zuweisen eines DNS-Servers. Hinzu kommen Optionen wie z.B. Domain-Name, Such-Suffixe, PXE oder WPAD-Angaben. Genau hier setzt der DHCP-Server auf, der den radvd sinnvoll ergänzt.

Kurz: IP-Adressen kommen vom radvd, Zusatz-Optionen vom DHCP-Server. Man spricht hier von “Stateful Address Configuration”. (siehe auch IPv6-Autokonfiguration bei Wikipedia).

Die technische Umsetzung:

Die radvd-Konfiguration wird auf ein Minimum reduziert. Wichtig ist die Option “AdvManagedFlag on”. Die Angabe eines prefix-Bereichs entfällt.

“/etc/radvd.conf”:

interface eth0
{
        AdvSendAdvert on;
        AdvManagedFlag on;
        MinRtrAdvInterval 5;
        MaxRtrAdvInterval 10;
}

Ich nutze unter openSUSE 11.4 den ISC DHCP Server (RPM-Paket “dhcp-server”), derzeit in der Version 4.2.1. Dieser Dienst besteht aus zwei Komponenten, “dhcpd” für IPv4 und “dhcpd6″ für IPv6. Ich beschäftige mich in diesem Artikel ausschließlich mit Letzterem. Die DHCP-Konfiguration wird in zwei Dateien vorgenommen:

“/etc/sysconfig/dhcpd” (Auszug):

DHCPD6_INTERFACE="eth0"

“/etc/dhcpd6.conf” (<- auf die “6″ achten!):

authoritative;
ddns-update-style interim;
ddns-updates off;

default-lease-time 2592000;
preferred-lifetime 604800;
option dhcp-renewal-time 3600;
option dhcp-rebinding-time 7200;
option dhcp6.info-refresh-time 21600;

allow leasequery;

log-facility local7;

subnet6 2001:xxxx:yyyy::/64 {

        range6 2001:xxxx:yyyy:: /64;

        option dhcp6.name-servers 2001:xxxx:yyyy::1;
        option dhcp6.domain-search "ipv6.site site";
}

(IP-Adressen wurden anonymisiert)

Wenn nun beide Dienste gestartet wurden und keine Firewall im Weg ist, sollten Clients bereits in der Lage sein, eine IPv6-Adresse inkl. Router- und DNS-Server-Adresse zu beziehen. In Kürze werde ich außerdem beschreiben, wie dynamische DNS-Updates mit IPv6 funktionieren.

Ein besonderes Feature ist “TestDrive”. Hier hat man die Möglichkeit, das vorbereitete System online, d.h. im Browser, ausgiebig zu testen, bevor der Download gestartet wird.

Fazit: Ein toller Service, den ich schon oft genutzt habe. Bei bestimmten Anforderungen ist es derzeit jedoch nötig, sich direkt mit KIWI zu beschäftigen und einen eigenen Server zum Erstellen von Images zu nutzen.

Ausschlaggebend für das Problem scheint wohl das verwendete Client-Betriebssystem, denn baue ich die Verbindung über ein System mit openSUSE 11.1 auf, funtioniert alles wie erwartet. Die Behebung des beschriebenen Problems ist durch den Aufruf dieses Befehls innerhalb der NX-Sitzung möglich:

setxkbmap -model evdev -layout $LANGUAGE

also in meinem Fall

setxkbmap -model evdev -layout de

Wird dieser Befehl in die Datei “.bashrc” im Home-Verzeichnis des Users auf dem NX-Server eingetragen, wird er direkt beim Anmelden ausgeführt. Allerdings verursacht dies bei mir wieder Probleme, wenn ich mich nicht mit dem openSUSE 11.2 Client  zum Server verbinde. :-(

UPDATE:
Wie sich herausstellte, funktioniert die Technik nun doch problemlos. Bei Remote-Installationen über SSH wird der Daemon automatisch aktiviert und in der Firewall freigeschaltet. Bei lokalen Installationen wird SSH dagegen nun standardmäßig deaktiviert. Dies lässt sich während der Installation bequem ändern, indem die entsprechende Schaltfläche (s. Screenshot) verwendet wird.

Ich würde trotzdem gerne wissen, wie viele User sich nach der Installation irritiert fragen werden, wieso der SSH-Aufruf lediglich mit “connection refused” endet… :-)

UPDATE 2:
Wenn nun das Kind bereits in den Brunnen gefallen ist, helfen die zwei folgenden Kommandos, um den SSH-Server inkl. Autostart wieder zu aktivieren:

/sbin/chkconfig -a sshd
/usr/sbin/rcsshd start

Außerdem muss SSH noch in der Firewall (falls genutzt) freigeschaltet werden. Das geht bequem über YaST oder über die Datei /etc/sysconfig/SuSEfirewall2:

FW_CONFIGURATIONS_EXT="sshd"

Mittlerweile haben sich die Mitglieder eingefunden und die Diskussionen auf der eingerichteten Mailing-Liste laufen an. Geplant ist auch ein IRC-Meeting in den nächsten Tagen. Nähere Informationen zum Thema gibt es hier.

Bereits vor einigen Tagen tauchten die ISOs auf diversen Torrent-Seiten auf. Wer hier glaubte, der Zeit ein Schnippchen schlagen zu können, wurde arg enttäuscht, da die angebotenen Images eine falsche SHA1-Checksumme enthalten, was auf eine nicht authorisierte Manipulation an den Daten hinweist. Hier ist also höchste Vorischt geboten!

Mein Download läuft, ich bin sehr gespannt!

Die offizielle openSUSE-Homepage zeigt momentan noch das Release 11.0, die aktuelle Version ist z.B. über diesen Mirror erhältlich. Generell wird empfohlen, einen der Mirror-Server aus dieser Liste zu wählen.

Have a lot of fun!