Subsections

B.11 IPV6 - Anbindung ans IPv6-Internet mit Hilfe eines SixXS-Tunnels

In diesem Abschnitt wird beschrieben, wie das IPv6-Paket genutzt werden kann, um mit Hilfe eines Tunnels des Anbieters SixXS (https://www.sixxs.net/) das eigene Heimnetzwerk mit dem IPv6-Internet zu verbinden.

B.11.1 Account erstellen

Zuerst muss ein SixXS-Account unter ``Signup for new users'' beantragt werden. Hat man diese Hürde genommen, besitzt man einen Benutzernamen der Form YYYYY-SIXXS sowie ein zugehöriges Passwort. Diese Daten benötigt man später für die Tunnelkonfiguration.

B.11.2 Tunnel konfigurieren

B.11.2.1 Vorbereitungen

Doch vorher muss man den Tunnel beantragen. Dies geschieht nach der Anmeldung über den Menüpunkt ``Request tunnel''. Hier ist es wichtig, beim Tunneltyp den zweiten Eintrag, ``Dynamic IPv4 Endpoint using Heartbeat protocol'' auszuwählen, weil diese Konfiguration vom fli4l direkt unterstützt wird. Die dritte Variante, ``Static IPv4 Endpoint'', ist ebenfalls möglich, wenn man eine fest zugeordnete IPv4-Adresse sein Eigen nennt, die sich nie ändert. Die Tunnelvariante ``Dynamic NAT-traversing IPv4 Endpoint using AYIYA'' wird derzeit vom IPv6-Paket nicht unterstützt.

Sobald man in den anderen Feldern Angaben zum Ort des Routers gemacht und via ``Next step'' zur zweiten Seite gewechselt hat, stehen hier ein oder mehrere PoPs (Points of Presence) zur Auswahl, die später für den Tunnelaufbau wichtig sind. Man sollte denjenigen nehmen, der am dichtesten ist, um das Tunneln von IPv6-Paketen möglichst effizient zu gestalten.

Sind alle Angaben gemacht und via ``Place request for new Tunnel'' abgeschickt worden, kommt irgendwann darauf eine E-Mail mit den nötigen Tunneldaten an. Dazu gehören:

  1. die Identifikationsnummer des Tunnels (T...)
  2. der Name des zugeordneten PoPs
  3. die IPv4-Adresse des zugeordneten PoPs (``SixXS IPv4'')
  4. die lokale IPv6-Adresse des Tunnels inklusive Subnetzmaske (bei SixXS typischerweise /64), also die Adresse des Routers (``Your IPv6'')
  5. die entfernte IPv6-Adresse des Tunnels inklusive Subnetzmaske (die mit der Subnetzmaske der lokalen IPv6-Adresse identisch ist), d.h. die Adresse des PoPs (``SixXS IPv6'')

B.11.2.2 Konfiguration

Jetzt kann der Tunnel konfiguriert werden! Als erstes wird die Variable IPV6_TUNNEL_N auf ``1'' gesetzt, weil genau ein Tunnel aufgebaut werden soll:

IPV6_TUNNEL_N='1'

Die SixXS-Angaben werden wie folgt in der IPv6-Konfiguration vermerkt:

  1. Die Identifikationsnummer des Tunnels wird in IPV6_TUNNEL_1_TUNNELID eingetragen.
  2. entfällt (der Name des PoPs ist uninteressant)
  3. Die IPv4-Adresse des PoPs wird in der Variable IPV6_TUNNEL_1_REMOTEV4 vermerkt.
  4. Die lokale IPv6-Adresse des Tunnels landet inklusive Subnetzmaske in der Variable IPV6_TUNNEL_1_LOCALV6.
  5. Die entfernte IPv6-Adresse des Tunnels landet ohne Subnetzmaske in der Variable
    IPV6_TUNNEL_1_REMOTEV6.

Zusätzlich müssen Benutzername und Passwort in der Tunnelkonfiguration in den Variablen IPV6_TUNNEL_1_USERID und IPV6_TUNNEL_1_PASSWORD angegeben werden. Schließlich muss in der Variable IPV6_TUNNEL_1_TYPE vermerkt werden, dass der konfigurierte Tunnel ein SixXS-Tunnel ist:

IPV6_TUNNEL_1_TYPE='sixxs'

Hat man von SixXS den PoP ``deham01'' mit der IPv4-Adresse 212.224.0.188 sowie die Tunnelendpunkte 2001:db8:900:551::1/64 (entfernt) und 2001:db8:900:551::2/64 (lokal) erhalten, und lauten die Tunnel-ID ``T1234'', der Benutzername ``USER1-SIXXS'' und das Passwort ``sixxs'' (bitte dieses Passwort nicht verwenden!), dann sieht die resultierende Konfiguration so aus:

IPV6_TUNNEL_N='1'
IPV6_TUNNEL_1_LOCALV4='dynamic' # oder feste lokale IPv4-Adresse
IPV6_TUNNEL_1_REMOTEV4='212.224.0.188'
IPV6_TUNNEL_1_LOCALV6='2001:db8:900:551::2/64'
IPV6_TUNNEL_1_REMOTEV6='2001:db8:900:551::1'
IPV6_TUNNEL_1_TYPE='sixxs'
IPV6_TUNNEL_1_USERID='USER1-SIXXS'
IPV6_TUNNEL_1_PASSWORD='sixxs'
IPV6_TUNNEL_1_TUNNELID='T1234'

B.11.2.3 Test

Hat man dies geschaffft, dann kann man nach Aktualisierung der Konfiguration den fli4l-Router neu starten. Nach dem Einloggen auf dem Router (direkt oder z.B. per SSH) sollte man den Tunnelendpunkt bereits anpingen können. Das Ganze sieht dann mit den oben genannten Beispiel-Daten folgendermaßen aus:

garm 3.6.0-revXXXXX # ping -c 4 2001:db8:900:551:0:0:0:1
PING 2001:db8:900:551::1 (2001:db8:900:551::1): 56 data bytes
64 bytes from 2001:db8:900:551::1: seq=0 ttl=64 time=67.646 ms
64 bytes from 2001:db8:900:551::1: seq=1 ttl=64 time=72.001 ms
64 bytes from 2001:db8:900:551::1: seq=2 ttl=64 time=70.082 ms
64 bytes from 2001:db8:900:551::1: seq=3 ttl=64 time=67.996 ms

--- 2001:db8:900:551::1 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 67.646/69.431/72.001 ms

Wichtig ist in der vorletzten Zeile der Teil ``0% packet loss'', d.h. dass für alle PING-Pakete Antwortpakete empfangen wurden. Kommt keine Antwort vom anderen Ende des Tunnels, sieht das Ergebnis anders aus:

garm 3.6.0-revXXXXX # ping -c 4 2001:db8:900:551:0:0:0:1
PING 2001:db8:900:551::1 (2001:db8:900:551::1): 56 data bytes

--- 2001:db8:900:551::1 ping statistics ---
4 packets transmitted, 0 packets received, 100% packet loss

Hier fällt auf, dass für kein einziges PING-Paket eine Antwort empfangen wurde (``100% packet loss''). Das bedeutet, dass entweder die Konfiguration nicht korrekt ist, oder dass der Tunnel seitens SixXS noch nicht vollständig eingerichtet worden ist. Im zweiten Fall sollte man erst einige Zeit abwarten, weil die Konfiguration auf Seiten des PoPs durchaus ein paar Stunden dauern kann. Hat man die Konfiguration doppelt und dreifach geprüft und keinen Fehler entdeckt, und ist einige Zeit verstrichen, ohne dass der Tunnel funktioniert, sollte man sich per E-Mail an SixXS wenden und das Problem möglichst detailliert beschreiben.

B.11.3 Subnetz konfigurieren

B.11.3.1 Vorbereitungen

Funktioniert der Tunnel, hat man den ersten großen Punkt geschafft. Fertig ist man aber noch nicht. Denn nun hat der Router zwar die Möglichkeit, Pakete ins IPv6-Internet zu schicken und von dort zu empfangen, aber die Hosts im lokalen Netz noch nicht. Dafür muss erst ein IPv6-Subnetz konfiguriert werden, innerhalb dessen die Hosts eingebunden werden.

Hier fällt ein kleiner, aber wesentlicher Unterschied zur Konfiguration eines IPv4-Netzwerks auf: Wegen der Adressknappheit ist in der Regel nur ein Host direkt mit dem Internet verbunden. Die anderen Hosts im lokalen Netz erhalten nur netzinterne, d.h. nicht nach außen geroutete Adressen aus den Bereichen 192.168.*.*, 172.16.*.* bis 172.31.*.* sowie 10.*.*.*, je nach Größe des Subnetzes.B.2 Bei IPv6 gibt es Adressen in Hülle und Fülle, somit entfällt die Notwendigkeit, netzinterne Adressen zu verwenden. Wegen des globalen Charakters lokaler Subnetze muss jedoch sichergestellt werden, dass die Adressen lokaler Hosts nicht mit anderen Adressen im Internet kollidieren. Deshalb muss ein Subnetz vom IPv6-Anbieter zugeteilt werden, um solche Kollisionen zu vermeiden.

Bei SixXS geschieht dies mit dem Menüpunkt ``Request subnet''. Hier muss man hauptsächlich den zu verwendenden Tunnel angeben, was leicht ist, weil bisher nur einer konfiguriert worden ist. Nach dem Abschicken des Formulars via ``Place request for new subnet'' erhält man nach einiger Zeit eine E-Mail mit den folgenden Informationen:

  1. Die IPv6-Adresse des Subnetzes inklusive Subnetzmaske (``Subnet IPv6'')
  2. Die IPv6-Adresse des Routers im Tunnel, wohin das Subnetz seitens SixXS geroutet wird (``Routed to'')
  3. Die IPv4-Adresse des Routers (``Your IPv4'')B.3

Diese Daten reichen aus, beim fli4l jetzt ein eigenes IPv6-Subnetz zu konfigurieren. Allerdings muss man eines noch wissen: Das zugewiesene Subnetz ist in der Regel sehr groß. SixXS teilt für gewöhnlich /48er-Subnetze zu, d.h. innerhalb der 128 Bit langen IPv6-Adresse belegt der Anteil, der auf das Netzpräfix fällt, 48 Bit, und der Anteil, der für die Adressierung der Hosts zur Verfügung steht, beträgt 128 - 48 = 80 Bit. Ein solch großes Subnetz hat jedoch zwei große Nachteile. Der erste Nachteil ist die schiere Größe: Man kann in dem Netz 280 $ \approx$ 1209 Trilliarden Hosts unterkriegen. Das zu verwalten, ohne eine weitere Struktur auf dem Hosts-Anteil der Adresse zu nutzen, erscheint nicht ratsam. Der zweite Nachteil wiegt schwerer: Innerhalb eines solch großen Subnetzes funktioniert die so genannte IPv6-Autokonfiguration nicht mehr. Das ist ein Vorgang, bei dem ein IPv6-Host über bestimmte Protokolle das Subnetz-Präfix erhält und sich seine IPv6-Adresse mit Hilfe der MAC-Adresse seines Netzwerk-Adapters zurechtbastelt. Die MAC-Adresse besteht aus sechs Bytes, und mit Hilfe des Standards EUI-64 kann man sie auf acht Bytes strecken. Das entspricht 64 Bit, und dann ist Schluss. Für 80 Bit stehen einfach nicht genügend Informationen seitens des Hosts zur Verfügung.

Lange Rede, kurzer Sinn: Das Subnetz muss kleiner gemacht werden, und zwar muss, damit später die Autokonfiguration auch funktionieren kann, daraus ein /64er-Subnetz werden. Das ist ganz einfach: Die Subnetzmaske wird einfach zu /64 abgeändert. Wurde also von SixXS z.B. das Subnetz 2001:db8:123::/48 zugewiesen, dann ist das Subnetz, für das der fli4l konfiguriert werden soll, einfach 2001:db8:123::/64. Das bedeutet im Detail, dass das /48-Subnetz in 2(64-48) = 216 = 65536 Sub-Subnetze eingeteilt wird, von denen das erste mit der Nummer Null vom fli4l verwendet werden soll. Dazu muss man sich erinnern, dass die Kurzform 2001:db8:123:: eigentlich für die Adresse 2001:db8:123:0:0:0:0:0 steht, wobei die ersten drei Zahlen die vom IPv6-Anbieter global eindeutig vergebenen Teile des Subnetzes sind, die vierte Zahl das eigens ausgesuchte Sub-Subnetz ``Null'' darstellt,B.4 und die letzten vier Zahlen für den Host-Anteil reserviert sind. Das ergibt dann zwar immer noch ein riesiges (Sub-)Subnetz, in dem bis zu 264 $ \approx$ 18, 4 Trillionen Hosts untergebracht werden können. Dank der IPv6-Autokonfiguration kommt man aber mit den tatsächlichen Adressen nicht in Berührung. Und das ist gut so...

B.11.3.2 Konfiguration

Zurück zur Konfiguration! Als erstes wird die Variable IPV6_NET_N auf ``1'' gesetzt, weil genau ein lokales IPv6-Subnetz eingerichtet werden soll. Die IPv6-Adresse des /64-Subnetzes landet inklusive Subnetzmaske in der Variable IPV6_NET_1. Doch das ist nicht ganz richtig: Vielmehr steht hier die IPv6-Adresse des Routers innerhalb dieses Subnetzes, aber ohne das Subnetz-Präfix, das dem Tunnel zugeordnet ist. Das wird nämlich an anderer Stelle konfiguriert, und zwar in der Tunnelkonfiguration. Dort muss nun die Variable IPV6_TUNNEL_1_PREFIX auf das angoforderte Subnetz-Präfix gesetzt werden.

Hat man nun das /48er-IPv6-Subnetz 2001:db8:123::/48 von SixXS erhalten, daraus das Subnetz mit der Nummer `456' als zu verwendendes /64er-Sub-Subnetz ausgewählt und schließlich bestimmt, dass der Router innerhalb dieses Subnetzes die Adresse ``1'' erhalten soll, dann erhalten wir die folgende Konfiguration:

IPV6_NET_N='1'
IPV6_NET_1='0:0:0:456::1/64'             # IPv6-Adresse des Routers (ohne
                                         # Subnetz-Präfix) + Subnetzmaske
IPV6_TUNNEL_1_PREFIX='2001:db8:123::/48' # /48-Subnetz-Präfix

Zu beachten ist, dass die ersten drei Nullen in IPV6_NET_1 quasi den Platz für das dem Tunnel zugeordnete /48-Subnetz-Präfix freihalten. Zusammen mit dem /48-Subnetz-Präfix, der vom Tunnelanbieter zugewiesen wird, ergeben sich das /64-Subnetz 2001:db8:123:456::/64 und die IPv6-Routeradresse 2001:db8:123:456::1.

Jetzt fehlt noch der Name der Netzwerkschnittstelle, an die dieses Subnetz gebunden werden soll. Jedes Subnetz wird genau einer Netzwerkschnittstelle zugeordnet. Falls sich nur eine konfigurierte Netzwerkkarte im Router befindet, so lautet der Name der Netzwerkschnittstelle typischerweise ``eth0'' für kabelgebundene oder ``wlan0'' für drahtloses Adapter. Schauen Sie im Zweifelsfall einfach die Einstellung für IP_NET_1_DEV (``IP'' ohne ``6'') und kopieren Sie den Inhalt einfach herüber:

IPV6_NET_1_DEV='eth0' # Netzwerkschnittstelle für dieses IPv6-Subnetz

Schließlich müssen wir nur noch alle Hebel der IPv6-Autokonfiguration ziehen:

IPV6_NET_1_ADVERTISE='yes'     # /64-Subnetz-Präfix und Default-Route per RA
IPV6_NET_1_ADVERTISE_DNS='yes' # DNS-Server per RA (erfordert
                               # DNS_SUPPORT_IPV6='yes'!)
IPV6_NET_1_DHCP='yes'          # Domänen-Name und DNS-Server per DHCPv6
                               # (letzteres erfordert DNS_SUPPORT_IPV6='yes')

Die beiden letzten Einstellungen sind nicht zwingend notwendig für ein funktionierendes IPv6-Subnetz, sind aber ganz hilfreich. Sie dienen der Verbreitung zusätzlicher Informationen im IPv6-Subnetz, nämlich der IPv6-Adresse des DNS-Servers sowie der verwendeten Domäne. Den DNS-Server kann man sogar auf zweierlei Weise veröffentlichen. Weil verschiedene Systeme hier unterschiedliche Vorlieben an den Tag legen, ist es von Vorteil, beide Verfahren (RDNSS via Router Advertisements sowie DHCPv6) zu aktivieren.

B.11.3.3 Test

Die gesamte IPv6-Konfiguration dieses Beispiels (DNS_SUPPORT_IPV6='yes' wird dabei angenommen!) lautet:

IPV6_NET_N='1'
IPV6_NET_1='0:0:0:456::1/64'   # IPv6-Adresse des Routers (ohne
                               # Subnetz-Präfix) + Subnetzmaske
IPV6_NET_1_DEV='eth0'          # Netzwerkschnittstelle für dieses IPv6-Subnetz
IPV6_NET_1_ADVERTISE='yes'     # /64-Subnetz-Präfix und Default-Route per RA
IPV6_NET_1_ADVERTISE_DNS='yes' # DNS-Server per RA
IPV6_NET_1_DHCP='yes'          # Domänen-Name und DNS-Server per DHCPv6

IPV6_TUNNEL_N='1'
IPV6_TUNNEL_1_PREFIX='2001:db8:123::/48' # /48-Subnetzmaske
IPV6_TUNNEL_1_LOCALV4='dynamic' # oder feste lokale IPv4-Adresse
IPV6_TUNNEL_1_REMOTEV4='212.224.0.188'
IPV6_TUNNEL_1_LOCALV6='2001:db8:900:551::2/64'
IPV6_TUNNEL_1_REMOTEV6='2001:db8:900:551::1'
IPV6_TUNNEL_1_TYPE='sixxs'
IPV6_TUNNEL_1_USERID='USER1-SIXXS'
IPV6_TUNNEL_1_PASSWORD='sixxs'
IPV6_TUNNEL_1_TUNNELID='T1234'

Ein normal konfigurierter Windows 7-Host sollte mit einem solch konfigurierten fli4l-Router automatisch seine IPv6-Adresse sowie Default-Route, DNS-Server und Domäne konfigurieren und somit den Rechner IPv6-tauglich machen. Das kann man z.B. mit einem enfachen PING vom Windows-Rechner ins IPv6-Internet realisieren. Im folgenden Beispiel versuchen wir, vom Windows-Host aus den fli4l.de-Webserver zu erreichen (wir benutzen dabei direkt die IPv6-Adresse, um nicht von der Korrektheit der DNS-Funktionalität auszugehen):

C:\>ping 2001:bf0:c000:a::2:132

Ping wird ausgeführt für 2001:bf0:c000:a::2:132 mit 32 Bytes Daten:

Antwort von 2001:bf0:c000:a::2:132: Zeit=104ms
Antwort von 2001:bf0:c000:a::2:132: Zeit=102ms
Antwort von 2001:bf0:c000:a::2:132: Zeit=106ms
Antwort von 2001:bf0:c000:a::2:132: Zeit=106ms

Ping-Statistik für 2001:bf0:c000:a::2:132:
    Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0 (0% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 102ms, Maximum = 106ms, Mittelwert = 104ms

Schließlich kann man das Werkzeug ``traceroute'' (unter Windows: ``tracert'') verwenden, um zu untersuchen, ob ein Paket korrekt geroutet wird. Ein Beispiel aus dem lokalen Netz des Autors ist untenstehend abgebildet. Daran kann man gut erkennen, dass ein Paket erst zum fli4l-Router (erste Zeile), dann zum anderen Ende des Tunnels (zweite Zeile) und schließlich in das weltweite IPv6-Internet (ab der dritten Zeile) gelangt:

C:\>tracert 2001:bf0:c000:a::2:132

Routenverfolgung zu virtualhost.in-berlin.de [2001:bf0:c000:a::2:132]
  über maximal 30 Abschnitte:

  1    <1 ms    <1 ms    <1 ms  garm.example.org [2001:db8:13da:1::1]
  2    70 ms    79 ms    71 ms  gw-1362.ham-01.de.sixxs.net [2001:db8:900:551::1]
  3    67 ms    71 ms    76 ms  2001:db8:800:1003::209:55
  4    68 ms     *       70 ms  2001:db8:1:0:87:86:71:240
  5    69 ms     *       71 ms  2001:db8:1:0:87:86:77:67
  6    72 ms     *       71 ms  2001:db8:1:0:86:87:77:81
  7    71 ms     *       71 ms  2001:db8:1:0:87:86:77:83
  8    90 ms     *       81 ms  2001:db8:1:0:87:86:77:62
  9    84 ms     *       88 ms  2001:db8:1:0:87:86:77:71
 10    99 ms    83 ms    83 ms  2001:db8:1:0:87:86:77:249
 11    94 ms    87 ms    87 ms  20gigabitethernet4-3.core1.fra1.he.net
  [2001:7f8::1b1b:0:1]
 12    96 ms    99 ms    99 ms  10gigabitethernet1-4.core1.ams1.he.net
  [2001:470:0:47::1]
 13   105 ms   108 ms   107 ms  2001:7f8:8:5:0:73e6:0:1
 14   106 ms   107 ms   104 ms  virtualhost.in-berlin.de [2001:bf0:c000:a::2:132]

Ablaufverfolgung beendet.


Footnotes

... Subnetzes.B.2
siehe RFC 1918 (http://tools.ietf.org/html/rfc1918) für Details
... IPv4'')B.3
falls der Router die IPv4-Adresse dynamisch erhält, steht hier ``heartbeat''
... darstellt,B.4
Man kann natürlich sich für ein anderes Sub-Subnetz entscheiden!
© 2001-2016 Das fli4l-Team - February 16, 2016