Migration auf IPv6: Difference between revisions
(→NAT-PT) |
|||
(140 intermediate revisions by 3 users not shown) | |||
Line 1: | Line 1: | ||
Unsere Aufgabe war es ein Netzwerk einzurichten welches aus 2 Routern besteht. Diese verbinden 2 Subnetze |
Unsere Aufgabe war es ein Netzwerk einzurichten welches aus 2 Routern besteht. Diese verbinden 2 Subnetze über ein IPv4 Netzwerk. Jedes Subnetz enthält IPv4 PCs sowie IPv6 PCs. Die Kommunikation der IPv6 PCs soll zwischen den beiden Subnetzen möglich sein. Jetzt wird einer der IPv4 PCs auf IPv6 migriert. Dabei darf die Konnektivität nicht in Mitleidenschaft gezogen werden. |
||
Jetzt wird einer der IPv4 PCs auf IPv6 migriert. Dabei darf die Konnektivität nicht in Mitleidenschaft gezogen werden. |
|||
<center> |
<center> |
||
[[Image: |
[[Image:Netzwerk_Gesamt_Adressen.jpg|650px|alt=Netzwerkstruktur.|Unser Netzwerkaufbau]] |
||
Die obenstehenden Grafiken stammen von http://www.openclipart.org/ und sind unter Public Domain für die nicht kommerzielle Nutzung freigegeben (siehe: http://www.openclipart.org/policies). |
|||
Die Grafiken sind erreichbar unter: http://www.openclipart.org/detail/17665/net_switch-by-rgtaylor_csc; http://www.openclipart.org/detail/158515/generic-office-desktop-by-spylt; http://www.openclipart.org/detail/155101/server-by-saisyukusanagi. |
|||
Stand: 03.10.2011. |
|||
</center> |
</center> |
||
Line 21: | Line 25: | ||
Führende Nullen werden ebenfalls nicht dargestellt. Außerdem kann die längste Gruppe einzelner Nullen zu ''::'' zusammengefasst werden. |
Führende Nullen werden ebenfalls nicht dargestellt. Außerdem kann die längste Gruppe einzelner Nullen zu ''::'' zusammengefasst werden. |
||
<pre> |
<pre> |
||
1050:0:0:0:5:600:300c:326b |
1050:0:0:0:5:600:300c:326b = 1050::5:600:300c:326b, ::1 (localhost) |
||
</pre> |
</pre> |
||
Line 44: | Line 48: | ||
*Subnetz 1: eth0 von karow und Rechner die über Karow's eth0 angebunden sind (marzahn, buckow, treptow, britz) |
*Subnetz 1: eth0 von karow und Rechner die über Karow's eth0 angebunden sind (marzahn, buckow, treptow, britz) |
||
*Subnetz 2: eth0 von lankwitz und Rechner die über Lankwitz's eth0 angebunden sind (alex, mitte, wedding, kudamm) |
*Subnetz 2: eth0 von lankwitz und Rechner die über Lankwitz's eth0 angebunden sind (alex, mitte, wedding, kudamm) |
||
*Subnetz 3: eth1 von karow / lankwitz |
*Subnetz 3: eth1 von karow (R1) / lankwitz (R2) |
||
Die Subnetze 1 und 2 enthalten IPv4 und IPv6 Schnittstellen. |
Die Subnetze 1 und 2 enthalten IPv4 und IPv6 Schnittstellen. |
||
Line 51: | Line 55: | ||
Nun vergeben wir manuell IP-Adressen. |
Nun vergeben wir manuell IP-Adressen. |
||
Praktischerweise können diese zum Testen temporär gesetzt werden mit: |
|||
* für IPv4: ifconfig <Interfacename> add <Adresse> |
* für IPv4: ifconfig <Interfacename> add <Adresse> |
||
z.B.: ifconfig eth0 add 192.168.1.10 |
z.B.: ifconfig eth0 add 192.168.1.10 |
||
Line 57: | Line 61: | ||
z.B.: ifconfig eth0 inet6 add fc00::0:1:2c0:6cff:fe00:f010 |
z.B.: ifconfig eth0 inet6 add fc00::0:1:2c0:6cff:fe00:f010 |
||
Um IP Adressen fest zu vergeben, werden diese in der Datei [[Migration auf IPv6#/etc/network/interfaces|/etc/network/interfaces (eth0 / eth1)]] eingetragen. |
Um dann IP Adressen fest zu vergeben, werden diese in der Datei [[Migration auf IPv6#/etc/network/interfaces|/etc/network/interfaces (eth0 / eth1)]] eingetragen. |
||
Wie dies im Detail auszusehen hat ist in den untenstehenden Configfiles ersichtlich. |
Wie dies im Detail auszusehen hat ist in den untenstehenden Configfiles ersichtlich. Das Einlesen dieser Einstellungen geschieht automatisch beim Bootvorgang. Ein Aufruf von |
||
<pre> |
|||
/etc/init.d/networking resart |
|||
</pre> |
|||
wird von einer Warnung begleitet und sollte nicht eingesetzt werden da einige (oder alle) Netzwerkinterfaces dadurch eventuell nicht wieder richtig angeschaltet werden. |
|||
Zudem sollte man wissen: Jedes Gerät besitzt automatisch eine IPv6 Adresse (link-local). Diese ist jedoch nur innerhalb des eigenen Subnetzes erreichbar und somit per Definition nicht von außen verfügbar. Deswegen ist es nötig manuell eine IPv6 Adresse (global) zu vergeben. Diese wird dann auch von den Routern geroutet. |
Zudem sollte man wissen: Jedes Gerät besitzt automatisch eine IPv6 Adresse (link-local). Diese ist jedoch nur innerhalb des eigenen Subnetzes erreichbar und somit per Definition nicht von außen verfügbar. Deswegen ist es nötig manuell eine IPv6 Adresse (global) zu vergeben. Diese wird dann auch von den Routern geroutet. |
||
Die Erzeugung der link-local IPv6 Adresse eines Adapters kann man unterdrücken in dem man bei jedem zu unterdrückenden Adapter die folgende Zeile in der Datei [[Migration auf IPv6#/etc/network/interfaces|/etc/network/interfaces (letzte Zeile)]] hinzufügt: |
|||
<pre> |
|||
up ip -6 addr flush dev $IFACE || true |
|||
</pre> |
|||
===Zuordnung=== |
===Zuordnung=== |
||
Line 88: | Line 100: | ||
=Nameserver= |
=Nameserver= |
||
Da jetzt die Rechner erreichbar sind, aber die Adressen eher unhandlich erscheinen, vergeben wir Namen und lassen diese durch einen Nameserver auflösen. Durch einen Eintrag in [[Migration auf IPv6#/etc/resolv.conf|/etc/resolv.conf]] wird der Nameserver anhand seiner IP bekannt gemacht. |
Da jetzt die Rechner erreichbar sind, aber die Adressen eher unhandlich erscheinen, vergeben wir Namen und lassen diese durch einen Nameserver auflösen. Durch einen Eintrag in [[Migration auf IPv6#/etc/resolv.conf|/etc/resolv.conf]] wird der Nameserver anhand seiner IP bekannt gemacht. Um die Auflösung der Namen auf Karow und Lankwitz zu ermöglichen, wird in deren [[Migration auf IPv6#/etc/host.conf| /etc/host.conf (order)]] eine Prioritätenliste der Anlaufpunkte zur Namensauflösung hinterlegt (für Programme die gegen libc4/libc5 gelinkt sind, bei neueren die gegen glibc2 (libc6) gelinkt sind wird /etc/nsswitch.conf verwendet). |
||
Der Nameserver ist bind in Version 9. |
Der Nameserver ist bind in Version 9. |
||
Da jedes Subnetz einen Nameserver benötigt |
Da jedes Subnetz einen Nameserver benötigt fungieren R1 und R2 als DNS Server. |
||
Um nicht selbst die Einstellungen von R1 auf R2 kopieren zu müssen hat R1 die Funktion eines Master-nameservers und R2 die eines Slave-nameservers. Ändert sich jetzt eine relevante Datei auf R1 wird eine Benachrichtigung (engl. notify) an R2 gesendet. Daraufhin kann dieser die benötigten ''neuen'' Dateien kopieren und in einem temporären Verzeichnis abspeichern. |
|||
Die Aktualität der Files wird anhand einer Seriennummer entschieden. [[Migration auf IPv6#/etc/bind/chaos.local| /etc/bind/chaos.local (serial)]] |
|||
Um nicht immer alle Einstellungen auf beiden Nameservern tätigen zu müssen, besitzt R1 die Funktion eines [[Migration auf IPv6#Karow 2| Master]]-nameservers und R2 die eines [[Migration auf IPv6#Lankwitz 2| Slave]]-nameservers. Ändert sich jetzt eine relevante Datei auf R1 wird eine Benachrichtigung [[Migration auf IPv6#/etc/bind/named.conf.options| (engl. notify)]] an R2 gesendet. Daraufhin kann dieser die benötigten ''neuen'' Dateien kopieren und in einem temporären Verzeichnis abspeichern. Diese zu kopierenden Files werden Zonefiles genannt. |
|||
Ein sogenanntes A-Record beschreibt die Korrelation von IPv4 Adresse und Name. Der AAAA-Record hingegen stellt eine Verbindung zwischen IPv6 Adresse und dem Name her. |
|||
=Zonefiles= |
|||
==Übersicht Name -> IP== |
|||
==Records== |
|||
Ein sogenanntes A-Record beschreibt die Korrelation von IPv4 Adresse und Name. Der AAAA-Record hingegen stellt eine Verbindung zwischen IPv6 Adresse und dem Name her. Um den Nameserver auch auf IPv6 antworten zu lassen ist ein Eintrag in [[Migration auf IPv6#/etc/bind/named.conf.options| /etc/bind/named.conf.options (listen-on-v6)]] nötig. Es ist möglich die Auflösung der IPv4 und IPv6 Adressen in einer Datei zu kombinieren. Bei uns geschieht dies in der Datei: [[Migration auf IPv6#/etc/bind/chaos.local| /etc/bind/chaos.local (vgl. Karow IN A & Karow IN AAAA)]] - ein sogenanntes [[Migration auf IPv6#/etc/bind/1.168.192.in-addr.arpa| Zonefile]]. |
|||
==Auflösung Name -> IP== |
|||
Dieses [[Migration auf IPv6#/etc/bind/1.168.192.in-addr.arpa| Zonefile]] ist für die Auflösung Name -> IP zuständig und muss in [[Migration auf IPv6#/etc/bind/named.conf.local| /etc/bind/named.conf.local]] des Nameservers bekannt gemacht werden. Der Zonename des [[Migration auf IPv6#/etc/bind/1.168.192.in-addr.arpa| Zonefiles]] ist dabei beliebig, muss aber der Domäne des Netzwerkes entsprechen (der eigentliche Dateiname ist frei wählbar - sollte jedoch nach Möglichkeit Konventionen entsprechen). Die Domäne wird in jedem Host in [[Migration auf IPv6#/etc/resolv.conf| /etc/resolv.conf (domain)]] gesetzt. |
|||
Unsere Domänendatei [[Migration auf IPv6#/etc/bind/chaos.local| /etc/bind/chaos.local]] enthält im Wesentlichen folgende Zuordnungen: |
|||
{| class="wikitable" |
{| class="wikitable" |
||
! style="text-align:right;" | Name !! style="text-align:right; width: 14em" | IP-Adresse |
! style="text-align:right;" | Name !! style="text-align:right; width: 14em" | IP-Adresse |
||
Line 133: | Line 150: | ||
| style="text-align:right" | Kudamm || style="text-align:right" | 192.168.2.13 |
| style="text-align:right" | Kudamm || style="text-align:right" | 192.168.2.13 |
||
|} |
|} |
||
==Auflösung IP -> Name== |
|||
Desweiteren werden [[Migration auf IPv6#/etc/bind/1.168.192.in-addr.arpa| Zonefiles]] für das sogenannte "Reverse Lookup" angelegt. Dieses ermöglicht dann die Rückübersetzung der IP in einen Namen. Für jedes Subnetz, sowie für IPv4 und IPv6 wird je ein eigenes [[Migration auf IPv6#/etc/bind/1.168.192.in-addr.arpa| Zonefile]] angelegt. |
|||
Die Struktur für diese [[Migration auf IPv6#/etc/bind/1.168.192.in-addr.arpa| Zonefiles]] ist vorgegeben und ist in IPv4 ein wenig anders als in IPv6. Die Dateinamen sind beliebig, der Zonename jedoch nach einem bestimmten Muster zu vergeben. Diese Muster sind am besten verständlich und ersichtlich beim Betrachten unserer [[Migration auf IPv6#/etc/bind/1.168.192.in-addr.arpa| angelegten Zonefiles]]. |
|||
Die [[Migration auf IPv6#/etc/bind/1.168.192.in-addr.arpa| Zonefiles]] für das Reverse Lookup sind ebenfalls in [[Migration auf IPv6#/etc/bind/named.conf.local| /etc/bind/named.conf.local]] des Nameserver bekannt zu machen. |
|||
==Näheres zu den Zonefiles== |
|||
Wir erinnern uns: Die [[Migration auf IPv6#/etc/bind/1.168.192.in-addr.arpa| Zonefiles]] werden vom [[Migration auf IPv6#Karow 2| Master]]-nameserver auf den [[Migration auf IPv6#Lankwitz 2| Slave]]-nameserver übertragen und in einem temporären Verzeichnis gespeichert. |
|||
In unserem Fall ist dies |
|||
<pre> |
|||
/var/cache/bind/chaos.local |
|||
</pre> |
|||
Dieser Pfad wird in der [[Migration auf IPv6#/etc/bind/named.conf.options| /etc/bind/named.conf.options (directory)]] auf Lankwitz festgelegt. |
|||
Kopiert werden diejenigen [[Migration auf IPv6#/etc/bind/1.168.192.in-addr.arpa| Zonefiles]] die in [[Migration auf IPv6#Lankwitz_2| /etc/bind/named.conf.local]] auf unserem [[Migration auf IPv6#Lankwitz_2| Slave]]-nameserver (Lankwitz) mit "slave" gekennzeichnet sind. Diese mit "slave" markierten [[Migration auf IPv6#/etc/bind/1.168.192.in-addr.arpa| Zonefiles]] auf dem [[Migration auf IPv6#Lankwitz 2| Slave]]-nameserver enthalten einen "Masters" Eintrag, der die zugehörigen [[Migration auf IPv6#Karow 2| Master]]-nameserver enthält. Die dort hinterlegten [[Migration auf IPv6#Karow 2| Master]]-nameserver müssen allerdings den Transfer der [[Migration auf IPv6#/etc/bind/1.168.192.in-addr.arpa| Zonefiles]] explizit erlauben. |
|||
Dazu dient ein "allow transfer" bei jedem zu kopierenden [[Migration auf IPv6#/etc/bind/1.168.192.in-addr.arpa| Zonefile]] in der [[Migration auf IPv6#Karow_2| /etc/bind/named.conf.local]] des [[Migration auf IPv6#Karow 2| Master]]-nameservers. |
|||
Die Aktualität der Files wird anhand einer Seriennummer entschieden. [[Migration auf IPv6#/etc/bind/chaos.local| /etc/bind/chaos.local (serial)]] |
|||
Das Format dieser Zahl ist egal. Wir haben uns für folgende Konvention entschieden: |
|||
<pre> |
|||
YYYYMMDDII, JahrMonatTagZahl |
|||
</pre> |
|||
Bei jeder Änderung wird das "Datum" aktualisiert. Bei mehreren Änderung an einem Tag wird die Zahl am Ende inkrementiert. [http://www.zytrax.com/books/dns/ch9/serial.html How to fix this serial] |
|||
Nach einer manuellen Änderung an den Einstellungen des Namesservers muss bind9 neugestartet werden: |
|||
<pre> |
|||
/etc/init.d/bind9 restart |
|||
</pre> |
|||
Um den [[Migration auf IPv6#Lankwitz 2| Slave]]-nameserver direkt über diese Änderungen zu informieren, werden in der [[Migration auf IPv6#Lankwitz_2| /etc/bind/named.conf.local]] des [[Migration auf IPv6#Lankwitz 2| Slave]]-nameservers (Lankwitz) die zu kopierenden Zoneeinträge um ein "allow notify" erweitert. Jedes "allow notify" enthält die für dieses [[Migration auf IPv6#/etc/bind/1.168.192.in-addr.arpa| Zonefile]] autorisierten [[Migration auf IPv6#Karow 2| Master]]-nameserver. |
|||
Nun muss dem [[Migration auf IPv6#Karow 2| Master]]-nameserver (Karow) nur noch gesagt werden, dass er bei einer Änderung auch seine [[Migration auf IPv6#Lankwitz 2| Slave]]-nameserver benachrichtigen soll. Die geschieht einfach mit einem "notify yes;" Eintrag in der [[Migration auf IPv6#/etc/bind/named.conf.options| /etc/bind/named.conf.options]]. |
|||
=Migrationsmethoden= |
=Migrationsmethoden= |
||
Line 142: | Line 194: | ||
==Tunnel Verfahren== |
==Tunnel Verfahren== |
||
Bei den Tunnel Verfahren werden in der Regel IPv6-Pakete als Nutzlast in IPv4-Pakete gesteckt und zu einer Tunnelgegenstelle übertragen, welche sich |
Bei den Tunnel Verfahren werden in der Regel IPv6-Pakete als Nutzlast in IPv4-Pakete gesteckt und zu einer Tunnelgegenstelle übertragen, welche sich in einem IPv6-Netz befindet. Ähnliche Verfahren, bei denen IPv4-Pakete in die Nutzlast von IPv6-Pakete gepackt werden und über ein IPv6-Netz in ein IPv4-Netz übertragen werden, sind auch möglich. Ein solcher Tunnel funktioniert in beide Richtungen. Die Qualität der Tunnelverfahren ist abhängig vom verwendeten Protokoll. Die genutzte Route ist meist nicht optimal, da man einen Umweg über die Tunnelgegenstelle in Kauf nehmen muss. Außerdem sinkt die maximal mögliche Nutzlast, da Overhead durch zusätzliche Header Daten entsteht. |
||
===6to4=== |
===6to4=== |
||
6to4 nennt sich ein Tunnelmechanismus bei dem auf jede IPv4-Adresse ein /48 großes IPv6-Netz abgebildet wird. Hier setzt sich die resultierende |
6to4 nennt sich ein Tunnelmechanismus bei dem auf jede IPv4-Adresse ein /48 großes IPv6-Netz abgebildet wird. Hier setzt sich die resultierende IPv6-Adresse aus einem Präfix "2002" und der IPv4-Adresse, notiert in hexadezimal, zusammen. |
||
Ein lokaler Host bzw. Router packt ein IPv6-Paket mittels Protokoll 41 in ein IPv4-Paket um es dann weiter an einen 6to4-Relay zu schicken, wo das IPv6-Paket wieder ausgepackt und ans Ziel geschickt wird. Wenn ein entfernter Host bzw. Router antwortet, werden die Pakete nicht unbedingt über den selben 6to4-Relay gesendet. |
Ein lokaler Host bzw. Router packt ein IPv6-Paket mittels Protokoll 41 in ein IPv4-Paket, um es dann weiter an einen 6to4-Relay zu schicken, wo das IPv6-Paket wieder ausgepackt und ans Ziel geschickt wird. Wenn ein entfernter Host bzw. Router antwortet, werden die Pakete nicht unbedingt über den selben 6to4-Relay gesendet. |
||
Bei einem 6to4-Tunnel handelt es sich folglich nicht um eine Punkt-zu-Punkt-Verbindung! |
Bei einem 6to4-Tunnel handelt es sich folglich nicht um eine Punkt-zu-Punkt-Verbindung! |
||
Die IPv4 Kopfdaten hängen direkt an dem IPv6 |
Die IPv4 Kopfdaten hängen direkt an dem IPv6-Paket, wodurch der Overhead genau die 20Bytes des IPv4-Header ist. |
||
Im Protokollfeld des IPv4 |
Im Protokollfeld des IPv4-Headers wird "0x29" eingetragen (bzw 41 in dezimal). |
||
Es existieren öffentliche 6to4-Relays, welche eine Verbindung ins IPv6 |
Es existieren öffentliche 6to4-Relays, welche eine Verbindung ins IPv6-Internet ermöglichen ohne eine Anmeldung zu fordern. |
||
Man erreicht über die Anycast Adresse "192.88.99.1" bzw. "2002:c058:6301::" den nächsten 6to4-Relay. |
Man erreicht über die Anycast Adresse "192.88.99.1" bzw. "2002:c058:6301::" den nächsten 6to4-Relay. |
||
===6in4=== |
===6in4=== |
||
Beim 6in4 Tunnel Mechanismus wird wie bei 6to4 das Protokoll 41 benutzt. |
Beim 6in4 Tunnel Mechanismus (RFC 4213) wird wie bei 6to4 das Protokoll 41 benutzt. |
||
Die IPv4 Kopfdaten hängen also direkt an dem IPv6 Paket, wodurch der Overhead auch hier nur die 20Bytes des IPv4 Header ist. |
Die IPv4 Kopfdaten hängen also direkt an dem IPv6 Paket, wodurch der Overhead auch hier nur die 20Bytes des IPv4 Header ist. |
||
Im Protokollfeld des IPv4 Headers |
Im Protokollfeld des IPv4 Headers steht daher auch hier die "0x29" (bzw 41 in dezimal). |
||
Beim 6in4 Tunneling handelt es sich im Gegensatz zum 6to4 Tunneling um eine statische Ende-zu-Ende Verbindung. |
Beim 6in4 Tunneling handelt es sich im Gegensatz zum 6to4 Tunneling um eine statische Ende-zu-Ende Verbindung. |
||
Line 170: | Line 222: | ||
===4in6=== |
===4in6=== |
||
Der 4in6 Tunnel Mechanismus ist eine Möglichkeit IPv4 Pakete durch ein IPv6 Netz zu versenden. (RFC 2473) |
|||
Die Tunneladapter werden hierbei manuell eingerichtet oder über automatische Protokolle (Tunnel Setup Protocol) um sich zu einem Tunnel Broker zu verbinden. |
|||
Zur Zeit ist es noch nicht wirklich nötig und auch nicht immer möglich dieses Verfahren zu verwenden. |
|||
Im Protokolltypen Feld für den nächsten Header steht dann eine "4", welche für "encapsulated IPv4" steht. (RFC 1853) |
|||
===6over4=== |
===6over4=== |
||
6over4 (RFC 2529) ist ein Übergangs Mechanismus, der darauf abzielt IPv6 Pakete zwischen Dual-Stack Knoten in einem IPv4 Netz mit Multicast Möglichkeit zu verschicken. Dabei wird IPv4 als virtuelle Link Layer verwendet, auf welche IPv6 aufliegt. |
|||
Es wird mittels trivialer Methodik eine Link Local IPv6 Adresse aus einer IPv4 Adresse generiert und ein Mechanismus verwendet mittels welchem man Neighbor Discovery auf IPv4 ausführen kann. |
|||
Neighbor Discovery Protocol (NDP) ist ein Internet Protokoll für IPv6. Es arbeitet in der Link Layer und ist dafür zuständig Autokonfiguration für Knotenpunkte, Erschließung anderer Knoten im Netz, Ermittlung der Adressen anderer Knoten, Finden Erreichbarer Router und DNS Server, Informationen zur Erreichbarkeit von Wegen oder Nachbarknoten und weiteres zu bereit zu stellen (RFC 4861). |
|||
Um ICMPv6 Neighbor Discovery zu verwenden wird Multicast vorausgesetzt. Ein IPv6 Multicast wird hierbei in ein ein IPv4 Multicast Paket gepackt. |
|||
==Translation Verfahren== |
==Translation Verfahren== |
||
===TRT=== |
===TRT=== |
||
Transport Relay Translation (RFC 3142) ist ein Übersetzungsverfahren, dass in der üblichsten Form in NAT-PT/NAPT-PT (Network Address Translation-Protocol Translation/Network Address Port Translation + Protocol Translation) zum Einsatz kommt. |
|||
Es basiert auf einer DNS Übersetzung (ALG) zwischen AAAA und A records, wie beschrieben in RFC 2694. |
|||
===SIIT=== |
===SIIT=== |
||
Stateless IP/ICMP Translation übersetzt IP-Header Formate zwischen IPv6 und IPv4 in beide Richtungen und ist zustandslos. |
|||
===NATPT=== |
|||
Die Übersetzung von IPv4 nach IPv6 kann zu einer Fragmentierung führen. SIIT wird unter Anderem in NAT-PT eingesetzt. |
|||
Eine solche Übersetzung mittels SIIT kann zu Informationsverlust führen. |
|||
===NAT-PT=== |
|||
Network Adress Translation - Protocol Translation ist ein aufwändiger Mechanismus, da jedes Paket übersetzt werden muss. NAT-PT ist trotz Nutzung von SIIT zustandsbehaftet. NAT-PT nutzt zur DNS Übersetzung DNS-ALG. Es ist mit Problemen zu rechnen,wenn die Anwendung selber IP Adressen überträgt. Auch hier ist mit Informationsverlust zu rechnen. (Ein unter Linux erhältlicher DNS Proxy der NAT-PT einsetzt ist totd [http://www.digipedia.pl/man/doc/view/totd.8/]. Das Linux Programm faithd kann ebenfalls Übersetzungen zwischen den beiden Protokolle umsetzen. [http://www.digipedia.pl/man/doc/view/faithd.8/]) |
|||
=6in4 Tunnel (im Einsatz zwischen Karow und Lankwitz - Subnetz 3)= |
|||
Da die Kommunikation zwischen unseren Routern nur über IPv4 stattfindet (Subnetz 3) - war es notwendig ankommende IPv6 Pakete (die von Subnetz 1 nach Subnetz 2 müssen oder vice versa) in IPv4 Pakete zu verpacken und nach dem Senden zu entpacken (zur Erinnerung: Ein 6in4 Tunnel tut genau dieses und verwendet das Protokoll 41 um IPv6-Pakete in IPv4-Pakete zu kapseln) |
|||
Dazu werden also nun auf den Zugangs- bzw. Endpunkten des zu überbrückenden Netzwerkes Tunnelinterfaces integriert. Ein Tunnelinterface wird erzeugt mit einem neuen Eintrag in der Datei [[Migration auf IPv6#/etc/network/interfaces|/etc/network/interfaces (iface 6in4)]]. In unserem Fall besitzen also Karow und Lankwitz jeweils ein virtuellen Tunneladapter. |
|||
=6in4 Tunnel= |
|||
Ein 6in4 Tunnel verwendet das Protokoll 41 um IPv6-Pakete in IPv4-Pakte |
|||
zu kapseln. |
|||
Da die beiden Router über IPv4 kommunizieren war es notwendig die IPv6 Pakete in IPv4 Pakete zu verpacken und nach dem Senden zu entpacken. |
|||
Dabei war es wichtig darauf zu achten neben den beiden (IPv6-)Subnetzen noch ein drittes Subnetz für die virtuellen IPv6-Adressen der Tunneladapter zu benutzen um das problemlose Routing der Pakete zu ermöglichen. [[Migration auf IPv6#Zuordnung| (vgl. Zuordnung der IP-Adressen)]] |
|||
Das Tunnelinterface wird erzeugt mit einem neuen Eintrag in der Datei [[Migration auf IPv6#/etc/network/interfaces|/etc/network/interfaces (iface 6in4)]] auf beiden Seiten des Tunnels. In unserem Fall also Karow und Lankwitz, den Routern. |
|||
Dabei war es wichtig darauf zu achten neben den beiden (IPv6-)Subnetzen noch ein drittes Subnetz für die virtuellen IPv6-Adressen zu benutzen um das problemlose routing der Pakete zu ermöglichen. [[Migration auf IPv6#Zuordnung| (vgl. Zuordnung der IP-Adressen)]] |
|||
<center> |
<center> |
||
<pre> |
<pre> |
||
Line 218: | Line 292: | ||
Als letzte Hürde mussten wir noch von einem IPv4 Client auf nur unter einer IPv6 Adresse erreichbare Hosts zugreifen. |
Als letzte Hürde mussten wir noch von einem IPv4 Client auf nur unter einer IPv6 Adresse erreichbare Hosts zugreifen. |
||
Dazu |
Dazu versuchten wir uns wieder der gleichen Methode zu bedienen und richteten einen Tunnel – dieses Mal von dem IPv4 Client aus – ein. |
||
=Quelldateien= |
=Quelldateien= |
||
Line 687: | Line 761: | ||
1.0 IN PTR lankwitz.chaos.local. |
1.0 IN PTR lankwitz.chaos.local. |
||
2.1 IN PTR wedding.chaos.local.</pre> |
2.1 IN PTR wedding.chaos.local.</pre> |
||
==/etc/network/interfaces TESTFILE: Tunnel zwischen Buckow (IPv4) und Karow (IPv6)== |
|||
===buckow=== |
|||
<pre> |
|||
# This file describes the network interfaces available on your system |
|||
# and how to activate them. For more information, see interfaces(5). |
|||
# The loopback network interface |
|||
auto lo |
|||
iface lo inet loopback |
|||
# The primary network interface |
|||
allow-hotplug eth0 |
|||
iface eth0 inet static |
|||
address 192.168.1.11 |
|||
netmask 255.255.255.0 |
|||
network 192.168.1.0 |
|||
broadcast 192.168.1.255 |
|||
gateway 192.168.1.1 |
|||
# dns-* options are implemented by the resolvconf package, if installed |
|||
dns-nameservers 192.168.1.1 |
|||
dns-search chaos.local |
|||
auto 6in4 |
|||
iface 6in4 inet6 v4tunnel |
|||
address fc00::3:1:2c0:6cff:fe00:f011 |
|||
netmask 64 |
|||
endpoint 192.168.1.1 |
|||
local 192.168.1.11 |
|||
ttl 255 |
|||
gateway fc00::3:1:2c0:6cff:fe00:f001 |
|||
</pre> |
|||
===karow=== |
|||
<pre> |
|||
# This file describes the network interfaces available on your system |
|||
# and how to activate them. For more information, see interfaces(5). |
|||
# The loopback network interface |
|||
auto lo |
|||
iface lo inet loopback |
|||
# The primary network interface |
|||
allow-hotplug eth0 |
|||
iface eth0 inet static |
|||
address 192.168.1.1 |
|||
netmask 255.255.255.0 |
|||
network 192.168.1.0 |
|||
broadcast 192.168.1.255 |
|||
# dns-* options are implemented by the resolvconf package, if installed |
|||
dns-nameservers 127.0.0.1 |
|||
dns-search chaos.local |
|||
iface eth0 inet6 static |
|||
address fc00::1:2c0:6cff:fe00:f001 |
|||
netmask 64 |
|||
# dns-* options are implemented by the resolvconf package, if installed |
|||
dns-nameservers ::1 |
|||
dns-search chaos.local |
|||
auto 6in4 |
|||
iface 6in4 inet6 v4tunnel |
|||
address fc00::1:1:2c0:6cff:fe00:f001 |
|||
netmask 64 |
|||
endpoint 172.16.1.2 |
|||
local 172.16.1.1 |
|||
ttl 255 |
|||
gateway fc00::1:1:2c0:6cff:fe00:f002 |
|||
allow-hotplug eth1 |
|||
iface eth1 inet static |
|||
address 172.16.1.1 |
|||
netmask 255.255.0.0 |
|||
network 172.16.0.0 |
|||
broadcast 172.16.255.255 |
|||
gateway 172.16.1.2 |
|||
# dns-* options are implemented by the resolvconf package, if installed |
|||
dns-nameservers 127.0.0.1 |
|||
dns-search chaos.local |
|||
up ip -6 addr flush dev $IFACE || true |
|||
auto 6in4buckow |
|||
iface 6in4buckow inet6 v4tunnel |
|||
address fc00::3:1:2c0:6cff:fe00:f001 |
|||
netmask 64 |
|||
endpoint 192.16.1.11 |
|||
local 192.168.1.1 |
|||
ttl 255 |
|||
gateway fc00::3:1:2c0:6cff:fe00:f011 |
|||
</pre> |
|||
==/etc/network/interfaces TESTFILE: Tunnel 4in6 zwischen Karow & Lankwitz== |
|||
===karow=== |
|||
<pre> |
|||
# This file describes the network interfaces available on your system |
|||
# and how to activate them. For more information, see interfaces(5). |
|||
# The loopback network interface |
|||
auto lo |
|||
iface lo inet loopback |
|||
# The primary network interface |
|||
allow-hotplug eth0 |
|||
iface eth0 inet static |
|||
address 192.168.1.1 |
|||
netmask 255.255.255.0 |
|||
network 192.168.1.0 |
|||
broadcast 192.168.1.255 |
|||
# dns-* options are implemented by the resolvconf package, if installed |
|||
dns-nameservers 127.0.0.1 |
|||
dns-search chaos.local |
|||
iface eth0 inet6 static |
|||
address fc00::1:2c0:6cff:fe00:f001 |
|||
netmask 64 |
|||
# dns-* options are implemented by the resolvconf package, if installed |
|||
dns-nameservers ::1 |
|||
dns-search chaos.local |
|||
auto 4in6 |
|||
iface 4in6 inet6 ipv6ip |
|||
# unknown method ipv6ip -> IPv6 Pendant zu v4tunnel gesucht / unbekannt |
|||
address 172.16.1.1 |
|||
netmask 64 |
|||
endpoint fc00::1:1:2c0:6cff:fe00:f002 |
|||
local fc00::1:1:2c0:6cff:fe00:f001 |
|||
ttl 255 |
|||
gateway 172.16.1.2 |
|||
allow-hotplug eth1 |
|||
iface eth1 inet6 static |
|||
address fc00::1:1:2c0:6cff:fe00:f001 |
|||
netmask 64 |
|||
# dns-* options are implemented by the resolvconf package, if installed |
|||
dns-nameservers ::1 |
|||
dns-search chaos.local |
|||
</pre> |
|||
===lankwitz=== |
|||
<pre> |
|||
# This file describes the network interfaces available on your system |
|||
# and how to activate them. For more information, see interfaces(5). |
|||
# The loopback network interface |
|||
auto lo |
|||
iface lo inet loopback |
|||
# The primary network interface |
|||
allow-hotplug eth0 |
|||
iface eth0 inet static |
|||
address 192.168.2.1 |
|||
netmask 255.255.255.0 |
|||
network 192.168.2.0 |
|||
broadcast 192.168.2.255 |
|||
# dns-* options are implemented by the resolvconf package, if installed |
|||
dns-nameservers 127.0.0.1 |
|||
dns-search chaos.local |
|||
iface eth0 inet6 static |
|||
address fc00::2:1:2c0:6cff:fe00:f001 |
|||
netmask 64 |
|||
# dns-* options are implemented by the resolvconf package, if installed |
|||
dns-nameservers ::1 |
|||
dns-search chaos.local |
|||
auto 4in6 |
|||
iface 4in6 inet6 ipv6ip |
|||
# unknown method ipv6ip -> IPv6 Pendant zu v4tunnel gesucht / unbekannt |
|||
address 172.16.1.2 |
|||
netmask 64 |
|||
endpoint fc00::1:1:2c0:6cff:fe00:f001 |
|||
local fc00::1:1:2c0:6cff:fe00:f002 |
|||
ttl 255 |
|||
gateway 172.16.1.1 |
|||
allow-hotplug eth1 |
|||
iface eth1 inet6 static |
|||
address fc00::1:1:2c0:6cff:fe00:f002 |
|||
netmask 64 |
|||
# dns-* options are implemented by the resolvconf package, if installed |
|||
dns-nameservers ::1 |
|||
dns-search chaos.local |
|||
</pre> |
Latest revision as of 11:00, 8 October 2011
Unsere Aufgabe war es ein Netzwerk einzurichten welches aus 2 Routern besteht. Diese verbinden 2 Subnetze über ein IPv4 Netzwerk. Jedes Subnetz enthält IPv4 PCs sowie IPv6 PCs. Die Kommunikation der IPv6 PCs soll zwischen den beiden Subnetzen möglich sein. Jetzt wird einer der IPv4 PCs auf IPv6 migriert. Dabei darf die Konnektivität nicht in Mitleidenschaft gezogen werden.
Die obenstehenden Grafiken stammen von http://www.openclipart.org/ und sind unter Public Domain für die nicht kommerzielle Nutzung freigegeben (siehe: http://www.openclipart.org/policies). Die Grafiken sind erreichbar unter: http://www.openclipart.org/detail/17665/net_switch-by-rgtaylor_csc; http://www.openclipart.org/detail/158515/generic-office-desktop-by-spylt; http://www.openclipart.org/detail/155101/server-by-saisyukusanagi.
Stand: 03.10.2011.
Motivation (Unterschiede zwischen den IP-Versionen)
Die Version 6 des IP-Protokolls ist leider nicht abwärtskompatibel zu IPv4. Daraus ergeben sich vor allem Probleme beim Umstieg, d.h. bei der Einführung von IPv6 und gleichzeitiger Abschaltung von IPv4. Da das Nachrichtenformat überarbeitet wurde kann ein Gerät mit IPv4 Konnektivität nicht automatisch auf IPv6 Netze zugreifen und vice versa.
IPv4
Eine IPv4 Adresse hat eine Länge von 32 bit. Man schreibt sie in 4 Gruppen zu je 8 bit dezimal auf. Führende Nullen werden nicht aufgeschrieben.
z.B.: 192.168.8.1, 10.3.4.5 oder 127.0.0.1 (localhost)
Es gibt (theoretisch) verschiedene IPv4 Adressen, welche nicht der steigenden Nachfrage gerecht werden können. Deshalb musste eine neue IP-Version entstehen die deutlich mehr Adressen zur Verfügung stellt -> IPv6.
IPv6
Jede IPv6 Adresse ist 128 bit lang und stellt damit verschiedene Adressen bereit. Sie werden häufig als 8 Gruppen von 16 bit Zahlen hexadezimal aufgeschrieben um sie weniger "unhandlich" erscheinen zu lassen. Führende Nullen werden ebenfalls nicht dargestellt. Außerdem kann die längste Gruppe einzelner Nullen zu :: zusammengefasst werden.
1050:0:0:0:5:600:300c:326b = 1050::5:600:300c:326b, ::1 (localhost)
Die neue IP-Version bringt außerdem noch Änderungen im Header-Format sowie zusätzlich Sicherheitsfeatures mit, welche bei IPv4 nur durch zusätzliche Protokolle erreicht werden können.
Eine konkrete Gegenüberstellung der Unterschiede befindet sich auf der Seite von IBM.
Netzwerk einrichten
Zu Beginn haben wir auf allen Systemen Debian 6 installiert und diese wie auf obiger Grafik zu sehen ist, verkabelt. Dazu mussten wir herausfinden welcher Adapter (eth0, eth1, eth2) welcher Karte zugeordnet wurde und haben daraufhin an jedem Rechner die benötigten Interfaces an- bzw. die nicht benötigten ausgeschaltet. Dies ist nötig, da jeder Subnetzrechner 2 und jeder Router 3 Netzwerkkarten besitzt und diese initial in zufälliger Reihenfolge im Debiansystem angemeldet werden.
Ein ganzes Interface ausschalten ist mit:
- ifconfig <Interfacename> down, möglich.
z.B.: ifconfig eth1 down schaltet das ganze Interface eth1 ab.
Ein Interface wieder einschalten geht analog mit:
- ifconfig <Interfacename> up.
Unsere Subnetrechner sind alle über eth0 an das Netzwerk angeschlossen. Die eth1 Schnittstellen der Subnetrechner sind aktuell nicht weiter verwendet. Die Router sind über eth0 an ihr lokales Subnetz angebunden und haben eine direkte Verbindung zum zweiten Router über eth1. Die eth2 Schnittstellen der Router sind aktuell nicht weiter verwendet.
IP-Adressen & Subnetze
Unser Netzwerk verfügt über drei Teilnetze:
- Subnetz 1: eth0 von karow und Rechner die über Karow's eth0 angebunden sind (marzahn, buckow, treptow, britz)
- Subnetz 2: eth0 von lankwitz und Rechner die über Lankwitz's eth0 angebunden sind (alex, mitte, wedding, kudamm)
- Subnetz 3: eth1 von karow (R1) / lankwitz (R2)
Die Subnetze 1 und 2 enthalten IPv4 und IPv6 Schnittstellen. Das Subnetz 3 ist ein reines IPv4 Netz.
Nun vergeben wir manuell IP-Adressen.
Praktischerweise können diese zum Testen temporär gesetzt werden mit:
- für IPv4: ifconfig <Interfacename> add <Adresse>
z.B.: ifconfig eth0 add 192.168.1.10
- für IPv6: ifconfig <Interfacename> inet6 add <Adresse>
z.B.: ifconfig eth0 inet6 add fc00::0:1:2c0:6cff:fe00:f010
Um dann IP Adressen fest zu vergeben, werden diese in der Datei /etc/network/interfaces (eth0 / eth1) eingetragen. Wie dies im Detail auszusehen hat ist in den untenstehenden Configfiles ersichtlich. Das Einlesen dieser Einstellungen geschieht automatisch beim Bootvorgang. Ein Aufruf von
/etc/init.d/networking resart
wird von einer Warnung begleitet und sollte nicht eingesetzt werden da einige (oder alle) Netzwerkinterfaces dadurch eventuell nicht wieder richtig angeschaltet werden.
Zudem sollte man wissen: Jedes Gerät besitzt automatisch eine IPv6 Adresse (link-local). Diese ist jedoch nur innerhalb des eigenen Subnetzes erreichbar und somit per Definition nicht von außen verfügbar. Deswegen ist es nötig manuell eine IPv6 Adresse (global) zu vergeben. Diese wird dann auch von den Routern geroutet. Die Erzeugung der link-local IPv6 Adresse eines Adapters kann man unterdrücken in dem man bei jedem zu unterdrückenden Adapter die folgende Zeile in der Datei /etc/network/interfaces (letzte Zeile) hinzufügt:
up ip -6 addr flush dev $IFACE || true
Zuordnung
Wir haben uns für folgende IPv4 Adresskonfigurationen entschieden:
Subnetz 1 | Subnetz 2 | Subnetz 3 (Karow) | Subnetz 3 (Lankwitz) | |
---|---|---|---|---|
IPv4-Adresse | 192.168.1.X | 192.168.2.X | 172.16.1.1 | 172.16.1.2 |
Netzmaske | 255.255.255.0 | 255.255.255.0 | 255.255.0.0 | 255.255.0.0 |
Gateway | 192.168.1.1 | 192.168.2.1 | 172.16.1.2 | 172.16.1.1 |
Wir haben uns für folgende IPv6 Adresskonfigurationen entschieden:
Subnetz 1 | Subnetz 2 | Subnetz 3 (Karow) | Subnetz 3 (Lankwitz) | |
---|---|---|---|---|
IPv6-Adresse | fc00::0:1:2c0:6cff:fe00:f0XX | fc00::2:1:2c0:6cff:fe00:f0XX | fc00::1:1:2c0:6cff:fe00:f001 | fc00::1:1:2c0:6cff:fe00:f002 |
Netzmaske | 64 | 64 | 64 | 64 |
Gateway | fc00::0:1:2c0:6cff:fe00:f001 | fc00::2:1:2c0:6cff:fe00:f001 | fc00::1:1:2c0:6cff:fe00:f002 | fc00::1:1:2c0:6cff:fe00:f001 |
Nameserver
Da jetzt die Rechner erreichbar sind, aber die Adressen eher unhandlich erscheinen, vergeben wir Namen und lassen diese durch einen Nameserver auflösen. Durch einen Eintrag in /etc/resolv.conf wird der Nameserver anhand seiner IP bekannt gemacht. Um die Auflösung der Namen auf Karow und Lankwitz zu ermöglichen, wird in deren /etc/host.conf (order) eine Prioritätenliste der Anlaufpunkte zur Namensauflösung hinterlegt (für Programme die gegen libc4/libc5 gelinkt sind, bei neueren die gegen glibc2 (libc6) gelinkt sind wird /etc/nsswitch.conf verwendet). Der Nameserver ist bind in Version 9.
Da jedes Subnetz einen Nameserver benötigt fungieren R1 und R2 als DNS Server.
Um nicht immer alle Einstellungen auf beiden Nameservern tätigen zu müssen, besitzt R1 die Funktion eines Master-nameservers und R2 die eines Slave-nameservers. Ändert sich jetzt eine relevante Datei auf R1 wird eine Benachrichtigung (engl. notify) an R2 gesendet. Daraufhin kann dieser die benötigten neuen Dateien kopieren und in einem temporären Verzeichnis abspeichern. Diese zu kopierenden Files werden Zonefiles genannt.
Zonefiles
Records
Ein sogenanntes A-Record beschreibt die Korrelation von IPv4 Adresse und Name. Der AAAA-Record hingegen stellt eine Verbindung zwischen IPv6 Adresse und dem Name her. Um den Nameserver auch auf IPv6 antworten zu lassen ist ein Eintrag in /etc/bind/named.conf.options (listen-on-v6) nötig. Es ist möglich die Auflösung der IPv4 und IPv6 Adressen in einer Datei zu kombinieren. Bei uns geschieht dies in der Datei: /etc/bind/chaos.local (vgl. Karow IN A & Karow IN AAAA) - ein sogenanntes Zonefile.
Auflösung Name -> IP
Dieses Zonefile ist für die Auflösung Name -> IP zuständig und muss in /etc/bind/named.conf.local des Nameservers bekannt gemacht werden. Der Zonename des Zonefiles ist dabei beliebig, muss aber der Domäne des Netzwerkes entsprechen (der eigentliche Dateiname ist frei wählbar - sollte jedoch nach Möglichkeit Konventionen entsprechen). Die Domäne wird in jedem Host in /etc/resolv.conf (domain) gesetzt.
Unsere Domänendatei /etc/bind/chaos.local enthält im Wesentlichen folgende Zuordnungen:
Name | IP-Adresse |
---|---|
Karow (eth0, A) | 192.168.1.1 |
Karow (eth0, AAAA) | fc00::0:1:2c0:6cff:fe00:f001 |
Karow (eth1) | 172.16.1.1 |
Karow (6in4) | fc00::1:1:2c0:6cff:fe00:f001 |
Marzahn | 192.168.1.10 |
Buckow | 192.168.1.11 |
Treptow | fc00::0:1:2c0:6cff:fe00:f012 |
Britz | fc00::0:1:2c0:6cff:fe00:f013 |
Lankwitz (eth0, A) | 192.168.2.1 |
Lankwitz (eth0, AAAA) | fc00::2:1:2c0:6cff:fe00:f001 |
Lankwitz (eth1) | 172.16.1.2 |
Lankwitz (6in4) | fc00::1:1:2c0:6cff:fe00:f002 |
Alex | 192.168.2.10 |
Mitte | 192.168.2.11 |
Wedding | fc00::2:1:2c0:6cff:fe00:f012 |
Kudamm | 192.168.2.13 |
Auflösung IP -> Name
Desweiteren werden Zonefiles für das sogenannte "Reverse Lookup" angelegt. Dieses ermöglicht dann die Rückübersetzung der IP in einen Namen. Für jedes Subnetz, sowie für IPv4 und IPv6 wird je ein eigenes Zonefile angelegt.
Die Struktur für diese Zonefiles ist vorgegeben und ist in IPv4 ein wenig anders als in IPv6. Die Dateinamen sind beliebig, der Zonename jedoch nach einem bestimmten Muster zu vergeben. Diese Muster sind am besten verständlich und ersichtlich beim Betrachten unserer angelegten Zonefiles.
Die Zonefiles für das Reverse Lookup sind ebenfalls in /etc/bind/named.conf.local des Nameserver bekannt zu machen.
Näheres zu den Zonefiles
Wir erinnern uns: Die Zonefiles werden vom Master-nameserver auf den Slave-nameserver übertragen und in einem temporären Verzeichnis gespeichert. In unserem Fall ist dies
/var/cache/bind/chaos.local
Dieser Pfad wird in der /etc/bind/named.conf.options (directory) auf Lankwitz festgelegt. Kopiert werden diejenigen Zonefiles die in /etc/bind/named.conf.local auf unserem Slave-nameserver (Lankwitz) mit "slave" gekennzeichnet sind. Diese mit "slave" markierten Zonefiles auf dem Slave-nameserver enthalten einen "Masters" Eintrag, der die zugehörigen Master-nameserver enthält. Die dort hinterlegten Master-nameserver müssen allerdings den Transfer der Zonefiles explizit erlauben.
Dazu dient ein "allow transfer" bei jedem zu kopierenden Zonefile in der /etc/bind/named.conf.local des Master-nameservers.
Die Aktualität der Files wird anhand einer Seriennummer entschieden. /etc/bind/chaos.local (serial)
Das Format dieser Zahl ist egal. Wir haben uns für folgende Konvention entschieden:
YYYYMMDDII, JahrMonatTagZahl
Bei jeder Änderung wird das "Datum" aktualisiert. Bei mehreren Änderung an einem Tag wird die Zahl am Ende inkrementiert. How to fix this serial
Nach einer manuellen Änderung an den Einstellungen des Namesservers muss bind9 neugestartet werden:
/etc/init.d/bind9 restart
Um den Slave-nameserver direkt über diese Änderungen zu informieren, werden in der /etc/bind/named.conf.local des Slave-nameservers (Lankwitz) die zu kopierenden Zoneeinträge um ein "allow notify" erweitert. Jedes "allow notify" enthält die für dieses Zonefile autorisierten Master-nameserver.
Nun muss dem Master-nameserver (Karow) nur noch gesagt werden, dass er bei einer Änderung auch seine Slave-nameserver benachrichtigen soll. Die geschieht einfach mit einem "notify yes;" Eintrag in der /etc/bind/named.conf.options.
Migrationsmethoden
Dual-Stack
Beim Dual-Stack Betrieb wird jedem Adapter neben der IPv4-Adresse zusätzlich eine IPv6-Adresse zugewiesen. Geräte können so über beide Protokolle kommunizieren. Dieses Verfahren ist zur Zeit der Regelfall. Viele Router haben allerdings noch keine IPv6-Weiterleitung eingeschaltet oder unterstützen diese schlicht nicht.
Tunnel Verfahren
Bei den Tunnel Verfahren werden in der Regel IPv6-Pakete als Nutzlast in IPv4-Pakete gesteckt und zu einer Tunnelgegenstelle übertragen, welche sich in einem IPv6-Netz befindet. Ähnliche Verfahren, bei denen IPv4-Pakete in die Nutzlast von IPv6-Pakete gepackt werden und über ein IPv6-Netz in ein IPv4-Netz übertragen werden, sind auch möglich. Ein solcher Tunnel funktioniert in beide Richtungen. Die Qualität der Tunnelverfahren ist abhängig vom verwendeten Protokoll. Die genutzte Route ist meist nicht optimal, da man einen Umweg über die Tunnelgegenstelle in Kauf nehmen muss. Außerdem sinkt die maximal mögliche Nutzlast, da Overhead durch zusätzliche Header Daten entsteht.
6to4
6to4 nennt sich ein Tunnelmechanismus bei dem auf jede IPv4-Adresse ein /48 großes IPv6-Netz abgebildet wird. Hier setzt sich die resultierende IPv6-Adresse aus einem Präfix "2002" und der IPv4-Adresse, notiert in hexadezimal, zusammen.
Ein lokaler Host bzw. Router packt ein IPv6-Paket mittels Protokoll 41 in ein IPv4-Paket, um es dann weiter an einen 6to4-Relay zu schicken, wo das IPv6-Paket wieder ausgepackt und ans Ziel geschickt wird. Wenn ein entfernter Host bzw. Router antwortet, werden die Pakete nicht unbedingt über den selben 6to4-Relay gesendet. Bei einem 6to4-Tunnel handelt es sich folglich nicht um eine Punkt-zu-Punkt-Verbindung!
Die IPv4 Kopfdaten hängen direkt an dem IPv6-Paket, wodurch der Overhead genau die 20Bytes des IPv4-Header ist. Im Protokollfeld des IPv4-Headers wird "0x29" eingetragen (bzw 41 in dezimal).
Es existieren öffentliche 6to4-Relays, welche eine Verbindung ins IPv6-Internet ermöglichen ohne eine Anmeldung zu fordern. Man erreicht über die Anycast Adresse "192.88.99.1" bzw. "2002:c058:6301::" den nächsten 6to4-Relay.
6in4
Beim 6in4 Tunnel Mechanismus (RFC 4213) wird wie bei 6to4 das Protokoll 41 benutzt. Die IPv4 Kopfdaten hängen also direkt an dem IPv6 Paket, wodurch der Overhead auch hier nur die 20Bytes des IPv4 Header ist. Im Protokollfeld des IPv4 Headers steht daher auch hier die "0x29" (bzw 41 in dezimal).
Beim 6in4 Tunneling handelt es sich im Gegensatz zum 6to4 Tunneling um eine statische Ende-zu-Ende Verbindung. Im Regelfall werden die Tunnel mittels Tunneladaptern manuell konfiguriert. Es existieren allerdings auch Dienstprogramme (z.B. AICCU), welche die Tunnelparameter automatisch durch Erhalt von nötigen Informationen eines Tunnel Information and Control Protocol (TIC) Servers konfigurieren.
Das 6in4 Protokoll hat keine Sicherheits Features, man kann also leicht IPv6 Pakete einschleusen, die die Quelle (IPv4) des anderen Tunnelendpunkts vorgeben. Das kann teilweise durch zusätzliche Sicherheitserweiterungen gelöst werden.
4in6
Der 4in6 Tunnel Mechanismus ist eine Möglichkeit IPv4 Pakete durch ein IPv6 Netz zu versenden. (RFC 2473) Die Tunneladapter werden hierbei manuell eingerichtet oder über automatische Protokolle (Tunnel Setup Protocol) um sich zu einem Tunnel Broker zu verbinden.
Zur Zeit ist es noch nicht wirklich nötig und auch nicht immer möglich dieses Verfahren zu verwenden. Im Protokolltypen Feld für den nächsten Header steht dann eine "4", welche für "encapsulated IPv4" steht. (RFC 1853)
6over4
6over4 (RFC 2529) ist ein Übergangs Mechanismus, der darauf abzielt IPv6 Pakete zwischen Dual-Stack Knoten in einem IPv4 Netz mit Multicast Möglichkeit zu verschicken. Dabei wird IPv4 als virtuelle Link Layer verwendet, auf welche IPv6 aufliegt.
Es wird mittels trivialer Methodik eine Link Local IPv6 Adresse aus einer IPv4 Adresse generiert und ein Mechanismus verwendet mittels welchem man Neighbor Discovery auf IPv4 ausführen kann.
Neighbor Discovery Protocol (NDP) ist ein Internet Protokoll für IPv6. Es arbeitet in der Link Layer und ist dafür zuständig Autokonfiguration für Knotenpunkte, Erschließung anderer Knoten im Netz, Ermittlung der Adressen anderer Knoten, Finden Erreichbarer Router und DNS Server, Informationen zur Erreichbarkeit von Wegen oder Nachbarknoten und weiteres zu bereit zu stellen (RFC 4861).
Um ICMPv6 Neighbor Discovery zu verwenden wird Multicast vorausgesetzt. Ein IPv6 Multicast wird hierbei in ein ein IPv4 Multicast Paket gepackt.
Translation Verfahren
TRT
Transport Relay Translation (RFC 3142) ist ein Übersetzungsverfahren, dass in der üblichsten Form in NAT-PT/NAPT-PT (Network Address Translation-Protocol Translation/Network Address Port Translation + Protocol Translation) zum Einsatz kommt. Es basiert auf einer DNS Übersetzung (ALG) zwischen AAAA und A records, wie beschrieben in RFC 2694.
SIIT
Stateless IP/ICMP Translation übersetzt IP-Header Formate zwischen IPv6 und IPv4 in beide Richtungen und ist zustandslos. Die Übersetzung von IPv4 nach IPv6 kann zu einer Fragmentierung führen. SIIT wird unter Anderem in NAT-PT eingesetzt. Eine solche Übersetzung mittels SIIT kann zu Informationsverlust führen.
NAT-PT
Network Adress Translation - Protocol Translation ist ein aufwändiger Mechanismus, da jedes Paket übersetzt werden muss. NAT-PT ist trotz Nutzung von SIIT zustandsbehaftet. NAT-PT nutzt zur DNS Übersetzung DNS-ALG. Es ist mit Problemen zu rechnen,wenn die Anwendung selber IP Adressen überträgt. Auch hier ist mit Informationsverlust zu rechnen. (Ein unter Linux erhältlicher DNS Proxy der NAT-PT einsetzt ist totd [1]. Das Linux Programm faithd kann ebenfalls Übersetzungen zwischen den beiden Protokolle umsetzen. [2])
6in4 Tunnel (im Einsatz zwischen Karow und Lankwitz - Subnetz 3)
Da die Kommunikation zwischen unseren Routern nur über IPv4 stattfindet (Subnetz 3) - war es notwendig ankommende IPv6 Pakete (die von Subnetz 1 nach Subnetz 2 müssen oder vice versa) in IPv4 Pakete zu verpacken und nach dem Senden zu entpacken (zur Erinnerung: Ein 6in4 Tunnel tut genau dieses und verwendet das Protokoll 41 um IPv6-Pakete in IPv4-Pakete zu kapseln)
Dazu werden also nun auf den Zugangs- bzw. Endpunkten des zu überbrückenden Netzwerkes Tunnelinterfaces integriert. Ein Tunnelinterface wird erzeugt mit einem neuen Eintrag in der Datei /etc/network/interfaces (iface 6in4). In unserem Fall besitzen also Karow und Lankwitz jeweils ein virtuellen Tunneladapter.
Dabei war es wichtig darauf zu achten neben den beiden (IPv6-)Subnetzen noch ein drittes Subnetz für die virtuellen IPv6-Adressen der Tunneladapter zu benutzen um das problemlose Routing der Pakete zu ermöglichen. (vgl. Zuordnung der IP-Adressen)
--------- ---------- |<--------| 6in4 Tunnel |--------> | | Karow |o=====================o| Lankwitz | |-------->|------IPv4 Netz--------|<---------| --------- ---------- --------------- --------------- --------------- | | | | | | | Payload | | Payload | | Payload | | | | | | | --------------- --------------- --------------- | |<======| |<======| | | TCP/UDP Header|======>| TCP/UDP Header|======>| TCP/UDP Header| | | | | | | --------------- --------------- --------------- | | | | | | | IPv6 Header | | IPv6 Header | | IPv6 Header | | | | | | | --------------- =============== --------------- | | | IPv4 Header | | | ---------------
Als letzte Hürde mussten wir noch von einem IPv4 Client auf nur unter einer IPv6 Adresse erreichbare Hosts zugreifen. Dazu versuchten wir uns wieder der gleichen Methode zu bedienen und richteten einen Tunnel – dieses Mal von dem IPv4 Client aus – ein.
Quelldateien
/etc/host.conf
order hosts,bind multi on
/etc/resolv.conf
Karow & Lankwitz (router)
domain chaos.local search chaos.local nameserver 127.0.0.1
Subnetz 1, IPv4 (Buckow)
domain chaos.local search chaos.local nameserver 192.168.1.1
Subnetz 1, IPv6 (Britz)
domain chaos.local search chaos.local nameserver fc00::0:1:2c0:6cff:fe00:f001
Subnetz 2, IPv4 (Alex)
domain chaos.local search chaos.local nameserver 192.168.2.1
Subnetz 2, IPv6 (Wedding)
domain chaos.local search chaos.local nameserver fc00::2:1:2c0:6cff:fe00:f001
/etc/network/interfaces
Karow
# This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5). # The loopback network interface auto lo iface lo inet loopback # The primary network interface allow-hotplug eth0 iface eth0 inet static address 192.168.1.1 netmask 255.255.255.0 network 192.168.1.0 broadcast 192.168.1.255 # dns-* options are implemented by the resolvconf package, if installed dns-nameservers 127.0.0.1 dns-search chaos.local iface eth0 inet6 static address fc00::0:1:2c0:6cff:fe00:f001 netmask 64 # dns-* options are implemented by the resolvconf package, if installed dns-nameservers ::1 dns-search chaos.local auto 6in4 iface 6in4 inet6 v4tunnel address fc00::1:1:2c0:6cff:fe00:f001 netmask 64 endpoint 172.16.1.2 local 172.16.1.1 ttl 255 gateway fc00::1:1:2c0:6cff:fe00:f002 allow-hotplug eth1 iface eth1 inet static address 172.16.1.1 netmask 255.255.0.0 network 172.16.0.0 broadcast 172.16.255.255 gateway 172.16.1.2 # dns-* options are implemented by the resolvconf package, if installed dns-nameservers 127.0.0.1 dns-search chaos.local up ip -6 addr flush dev $IFACE || true
Lankwitz
# This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5). # The loopback network interface auto lo iface lo inet loopback # The primary network interface allow-hotplug eth0 iface eth0 inet static address 192.168.2.1 netmask 255.255.255.0 network 192.168.2.0 broadcast 192.168.2.255 # dns-* options are implemented by the resolvconf package, if installed dns-nameservers 127.0.0.1 dns-search chaos.local iface eth0 inet6 static address fc00::2:1:2c0:6cff:fe00:f001 netmask 64 # dns-* options are implemented by the resolvconf package, if installed dns-nameservers ::1 dns-search chaos.local auto 6in4 iface 6in4 inet6 v4tunnel address fc00::1:1:2c0:6cff:fe00:f002 netmask 64 endpoint 172.16.1.1 local 172.16.1.2 ttl 255 gateway fc00::1:1:2c0:6cff:fe00:f001 allow-hotplug eth1 iface eth1 inet static address 172.16.1.2 netmask 255.255.0.0 network 172.16.0.0 broadcast 172.16.255.255 gateway 172.16.1.1 # dns-* options are implemented by the resolvconf package, if installed dns-nameservers 127.0.0.1 dns-search chaos.local up ip -6 addr flush dev $IFACE || true
Subnetz 1, IPv4 (Buckow)
# This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5). # The loopback network interface auto lo iface lo inet loopback # The primary network interface allow-hotplug eth0 iface eth0 inet static address 192.168.1.11 netmask 255.255.255.0 network 192.168.1.0 broadcast 192.168.1.255 gateway 192.168.1.1 # dns-* options are implemented by the resolvconf package, if installed dns-nameservers 192.168.1.1 dns-search chaos.local
Subnetz 1, IPv6 (Britz)
# This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5). # The loopback network interface auto lo iface lo inet loopback # The primary network interface allow-hotplug eth0 iface eth0 inet6 static address fc00::0:1:2c0:6cff:fe00:f013 netmask 64 gateway fc00::0:1:2c0:6cff:fe00:f001 # dns-* options are implemented by the resolvconf package, if installed dns-nameservers fc00::0:1:2c0:6cff:fe00:f001 dns-search chaos.local
Subnetz 2, IPv4 (Alex)
# This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5). # The loopback network interface auto lo iface lo inet loopback # The primary network interface allow-hotplug eth0 iface eth0 inet static address 192.168.2.10 netmask 255.255.255.0 network 192.168.2.0 broadcast 192.168.2.255 gateway 192.168.2.1 # dns-* options are implemented by the resolvconf package, if installed dns-nameservers 192.168.2.1 dns-search chaos.local
Subnetz 2, IPv6 (Wedding)
# This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5). # The loopback network interface auto lo iface lo inet loopback # The primary network interface allow-hotplug eth0 iface eth0 inet6 static address fc00::2:1:2c0:6cff:fe00:f012 netmask 64 gateway fc00::2:1:2c0:6cff:fe00:f001 # dns-* options are implemented by the resolvconf package, if installed dns-nameservers fc00::2:1:2c0:6cff:fe00:f001 dns-search chaos.local
/etc/bind/chaos.local
chaos.local. IN SOA karow root.chaos.local. ( 2011092603 ; serial 1D ; refresh 2H ; retry 1W ; expiry 2D ) ; minimum IN NS karow IN NS lankwitz karow IN A 192.168.1.1 IN AAAA fc00::0:1:2c0:6cff:fe00:f001 karowtunnel IN AAAA fc00::1:1:2c0:6cff:fe00:f001 marzahn IN A 192.168.1.10 marzahn4 IN A 192.168.1.10 buckow IN A 192.168.1.11 buckow4 IN A 192.168.1.11 treptow IN AAAA fc00::0:1:2c0:6cff:fe00:f012 treptow6 IN AAAA fc00::0:1:2c0:6cff:fe00:f012 britz IN AAAA fc00::0:1:2c0:6cff:fe00:f013 britz6 IN AAAA fc00::0:1:2c0:6cff:fe00:f013 lankwitz IN A 192.168.2.1 IN AAAA fc00::2:1:2c0:6cff:fe00:f001 lankwitztunnel IN AAAA fc00::1:1:2c0:6cff:fe00:f002 alex IN A 192.168.2.10 alex4 IN A 192.168.2.10 mitte IN A 192.168.2.11 mitte4 IN A 192.168.2.11 wedding IN AAAA fc00::2:1:2c0:6cff:fe00:f012 wedding6 IN AAAA fc00::2:1:2c0:6cff:fe00:f012 kudamm IN A 192.168.2.13 kudamm4 IN A 192.168.2.13
/etc/bind/named.conf
include "/etc/bind/named.conf.options"; include "/etc/bind/named.conf.local"; include "/etc/bind/named.conf.default-zones";
/etc/bind/named.conf.options
options { directory "/var/cache/bind"; dnssec-enable no; notify yes; auth-nxdomain no; # conform to RFC1035 listen-on-v6 { any; }; };
/etc/bind/named.conf.local
Karow
zone "chaos.local" { type master; file "/etc/bind/chaos.local"; allow-transfer { 172.16.1.2; }; }; zone "1.168.192.in-addr.arpa" { type master; file "/etc/bind/1.168.192.in-addr.arpa"; allow-transfer { 172.16.1.2; }; }; zone "2.168.192.in-addr.arpa" { type master; file "/etc/bind/2.168.192.in-addr.arpa"; allow-transfer { 172.16.1.2; }; }; zone "0.f.0.0.e.f.f.f.c.6.0.c.2.0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.c.f.ip6.arpa" { type master; file "/etc/bind/0.f.0.0.e.f.f.f.c.6.0.c.2.0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.c.f.ip6.arpa"; allow-transfer { 172.16.1.2; }; }; zone "0.f.0.0.e.f.f.f.c.6.0.c.2.0.1.0.0.0.2.0.0.0.0.0.0.0.0.0.c.f.ip6.arpa" { type master; file "/etc/bind/0.f.1.0.e.f.f.f.c.6.0.c.2.0.1.0.0.0.2.0.0.0.0.0.0.0.0.0.c.f.ip6.arpa"; allow-transfer { 172.16.1.2; }; }; zone "0.f.0.0.e.f.f.f.c.6.0.c.2.0.1.0.0.0.1.0.0.0.0.0.0.0.0.0.c.f.ip6.arpa" { type master; file "/etc/bind/0.f.0.0.e.f.f.f.c.6.0.c.2.0.1.0.0.0.1.0.0.0.0.0.0.0.0.0.c.f.ip6.arpa"; allow-transfer { 172.16.1.2; }; };
Lankwitz
zone "chaos.local" { type slave; file "chaos.local.bak"; masters { 172.16.1.1; }; allow-notify { 172.16.1.1; }; }; zone "1.168.192.in-addr.arpa" { type slave; file "1.168.192.in-addr.arpa.bak"; masters { 172.16.1.1; }; allow-notify { 172.16.1.1; }; }; zone "2.168.192.in-addr.arpa" { type slave; file "2.168.192.in-addr.arpa.bak"; masters { 172.16.1.1; }; allow-notify { 172.16.1.1; }; }; zone "0.f.0.0.e.f.f.f.c.6.0.c.2.0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.c.f.ip6.arpa" { type slave; file "0.f.0.0.e.f.f.f.c.6.0.c.2.0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.c.f.ip6.arpa.bak"; masters { 172.16.1.1; }; allow-notify { 172.16.1.1; }; }; zone "0.f.0.0.e.f.f.f.c.6.0.c.2.0.1.0.0.0.2.0.0.0.0.0.0.0.0.0.c.f.ip6.arpa" { type slave; file "0.f.0.0.e.f.f.f.c.6.0.c.2.0.1.0.0.0.2.0.0.0.0.0.0.0.0.0.c.f.ip6.arpa.bak"; masters { 172.16.1.1; }; allow-notify { 172.16.1.1; }; }; zone "0.f.0.0.e.f.f.f.c.6.0.c.2.0.1.0.0.0.1.0.0.0.0.0.0.0.0.0.c.f.ip6.arpa" { type slave; file "0.f.0.0.e.f.f.f.c.6.0.c.2.0.1.0.0.0.1.0.0.0.0.0.0.0.0.0.c.f.ip6.arpa.bak"; masters { 172.16.1.1; }; allow-notify { 172.16.1.1; }; };
/etc/bind/1.168.192.in-addr.arpa
1.168.192.in-addr.arpa. IN SOA karow.chaos.local. root.chaos.local. ( 2011092204 ; serial 1D ; refresh 2H ; retry 1W ; expiry 2D ) ; minimum IN NS karow.chaos.local. IN NS lankwitz.chaos.local. 1 IN PTR karow.chaos.local. 10 IN PTR marzahn.chaos.local. 11 IN PTR buckow.chaos.local.
/etc/bind/2.168.192.in-addr.arpa
2.168.192.in-addr.arpa. IN SOA karow.chaos.local. root.chaos.local. ( 2011092204 ; serial 1D ; refresh 2H ; retry 1W ; expiry 2D ) ; minimum IN NS karow.chaos.local. IN NS lankwitz.chaos.local. 1 IN PTR lankwitz.chaos.local. 10 IN PTR alex.chaos.local. 11 IN PTR mitte.chaos.local. 13 IN PTR kudamm.chaos.local.
/etc/bind/0.f.0.0.e.f.f.f.c.6.0.c.2.0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.c.f.ip6.arpa
@ IN SOA 0.f.0.0.e.f.f.f.c.6.0.c.2.0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.c.f.ip6.arpa. root.chaos.local. ( 2011092603 ; serial 1D ; refresh 2H ; retry 1W ; expiry 2D ) ; minimum IN NS karow.chaos.local. IN NS lankwitz.chaos.local. $ORIGIN 0.f.0.0.e.f.f.f.c.6.0.c.2.0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.c.f.ip6.arpa. 1.0 IN PTR karow.chaos.local. 2.1 IN PTR treptow.chaos.local. 3.1 IN PTR britz.chaos.local.
/etc/bind/0.f.0.0.e.f.f.f.c.6.0.c.2.0.1.0.0.0.1.0.0.0.0.0.0.0.0.0.c.f.ip6.arpa
@ IN SOA 0.f.0.0.e.f.f.f.c.6.0.c.2.0.1.0.0.0.1.0.0.0.0.0.0.0.0.0.c.f.ip6.arpa. root.chaos.local. ( 2011092603 ; serial 1D ; refresh 2H ; retry 1W ; expiry 2D ) ; minimum IN NS karow.chaos.local. IN NS lankwitz.chaos.local. $ORIGIN 0.f.0.0.e.f.f.f.c.6.0.c.2.0.1.0.0.0.1.0.0.0.0.0.0.0.0.0.c.f.ip6.arpa. 1.0 IN PTR karowtunnel.chaos.local. 2.0 IN PTR lankwitztunnel.chaos.local.
/etc/bind/0.f.0.0.e.f.f.f.c.6.0.c.2.0.1.0.0.0.2.0.0.0.0.0.0.0.0.0.c.f.ip6.arpa
@ IN SOA 0.f.0.0.e.f.f.f.c.6.0.c.2.0.1.0.0.0.2.0.0.0.0.0.0.0.0.0.c.f.ip6.arpa. root.chaos.local. ( 2011092603 ; serial 1D ; refresh 2H ; retry 1W ; expiry 2D ) ; minimum IN NS karow.chaos.local. IN NS lankwitz.chaos.local. $ORIGIN 0.f.0.0.e.f.f.f.c.6.0.c.2.0.1.0.0.0.2.0.0.0.0.0.0.0.0.0.c.f.ip6.arpa. 1.0 IN PTR lankwitz.chaos.local. 2.1 IN PTR wedding.chaos.local.
/etc/network/interfaces TESTFILE: Tunnel zwischen Buckow (IPv4) und Karow (IPv6)
buckow
# This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5). # The loopback network interface auto lo iface lo inet loopback # The primary network interface allow-hotplug eth0 iface eth0 inet static address 192.168.1.11 netmask 255.255.255.0 network 192.168.1.0 broadcast 192.168.1.255 gateway 192.168.1.1 # dns-* options are implemented by the resolvconf package, if installed dns-nameservers 192.168.1.1 dns-search chaos.local auto 6in4 iface 6in4 inet6 v4tunnel address fc00::3:1:2c0:6cff:fe00:f011 netmask 64 endpoint 192.168.1.1 local 192.168.1.11 ttl 255 gateway fc00::3:1:2c0:6cff:fe00:f001
karow
# This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5). # The loopback network interface auto lo iface lo inet loopback # The primary network interface allow-hotplug eth0 iface eth0 inet static address 192.168.1.1 netmask 255.255.255.0 network 192.168.1.0 broadcast 192.168.1.255 # dns-* options are implemented by the resolvconf package, if installed dns-nameservers 127.0.0.1 dns-search chaos.local iface eth0 inet6 static address fc00::1:2c0:6cff:fe00:f001 netmask 64 # dns-* options are implemented by the resolvconf package, if installed dns-nameservers ::1 dns-search chaos.local auto 6in4 iface 6in4 inet6 v4tunnel address fc00::1:1:2c0:6cff:fe00:f001 netmask 64 endpoint 172.16.1.2 local 172.16.1.1 ttl 255 gateway fc00::1:1:2c0:6cff:fe00:f002 allow-hotplug eth1 iface eth1 inet static address 172.16.1.1 netmask 255.255.0.0 network 172.16.0.0 broadcast 172.16.255.255 gateway 172.16.1.2 # dns-* options are implemented by the resolvconf package, if installed dns-nameservers 127.0.0.1 dns-search chaos.local up ip -6 addr flush dev $IFACE || true auto 6in4buckow iface 6in4buckow inet6 v4tunnel address fc00::3:1:2c0:6cff:fe00:f001 netmask 64 endpoint 192.16.1.11 local 192.168.1.1 ttl 255 gateway fc00::3:1:2c0:6cff:fe00:f011
/etc/network/interfaces TESTFILE: Tunnel 4in6 zwischen Karow & Lankwitz
karow
# This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5). # The loopback network interface auto lo iface lo inet loopback # The primary network interface allow-hotplug eth0 iface eth0 inet static address 192.168.1.1 netmask 255.255.255.0 network 192.168.1.0 broadcast 192.168.1.255 # dns-* options are implemented by the resolvconf package, if installed dns-nameservers 127.0.0.1 dns-search chaos.local iface eth0 inet6 static address fc00::1:2c0:6cff:fe00:f001 netmask 64 # dns-* options are implemented by the resolvconf package, if installed dns-nameservers ::1 dns-search chaos.local auto 4in6 iface 4in6 inet6 ipv6ip # unknown method ipv6ip -> IPv6 Pendant zu v4tunnel gesucht / unbekannt address 172.16.1.1 netmask 64 endpoint fc00::1:1:2c0:6cff:fe00:f002 local fc00::1:1:2c0:6cff:fe00:f001 ttl 255 gateway 172.16.1.2 allow-hotplug eth1 iface eth1 inet6 static address fc00::1:1:2c0:6cff:fe00:f001 netmask 64 # dns-* options are implemented by the resolvconf package, if installed dns-nameservers ::1 dns-search chaos.local
lankwitz
# This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5). # The loopback network interface auto lo iface lo inet loopback # The primary network interface allow-hotplug eth0 iface eth0 inet static address 192.168.2.1 netmask 255.255.255.0 network 192.168.2.0 broadcast 192.168.2.255 # dns-* options are implemented by the resolvconf package, if installed dns-nameservers 127.0.0.1 dns-search chaos.local iface eth0 inet6 static address fc00::2:1:2c0:6cff:fe00:f001 netmask 64 # dns-* options are implemented by the resolvconf package, if installed dns-nameservers ::1 dns-search chaos.local auto 4in6 iface 4in6 inet6 ipv6ip # unknown method ipv6ip -> IPv6 Pendant zu v4tunnel gesucht / unbekannt address 172.16.1.2 netmask 64 endpoint fc00::1:1:2c0:6cff:fe00:f001 local fc00::1:1:2c0:6cff:fe00:f002 ttl 255 gateway 172.16.1.1 allow-hotplug eth1 iface eth1 inet6 static address fc00::1:1:2c0:6cff:fe00:f002 netmask 64 # dns-* options are implemented by the resolvconf package, if installed dns-nameservers ::1 dns-search chaos.local