Migration auf IPv6: Difference between revisions

From
Jump to navigation Jump to search
Line 93: Line 93:


{| class="wikitable"
{| class="wikitable"
! style="text-align:right; width: 4em" | Name !! style="text-align:right; width: 25em" | IP-Adresse
! Name !! style="text-align:right; width: 20em" | IP-Adresse
|-
|-
| style="text-align:right" | Karow (eth0, A) || style="text-align:right" | 192.168.1.1
| style="text-align:right" | Karow (eth0, A) || style="text-align:right" | 192.168.1.1

Revision as of 13:54, 28 September 2011

Unsere Aufgabe war es ein Netzwerk einzurichten welches aus 2 Routern besteht. Diese verbinden 2 Subnetze mit jeweils zwei IPv4 PCs und zwei IPv6 PCs. Jetzt wird einer der IPv4 PCs auf IPv6 migriert. Dabei darf die Konnektivität nicht in Mitleidenschaft gezogen werden.

Unser Netzwerkaufbau

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 gleichwertig zu 1050::5:600:300c:326b, 0:0:0:0:0:0:192:1:56.10 gleichwertig zu ::192:1:56:10, ::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. Dann mussten die richtigen Interfaces bei den Routern und Subnetrechnern an- bzw. ausgeschaltet 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 an eth0 angebunden sind (marzahn, buckow, treptow, britz)
  • Subnetz 2: eth0 von lankwitz (alex, mitte, wedding, kudamm)
  • Subnetz 3: eth1 von karow / lankwitz

Die Subnetze 1 und 2 enthalten IPv4 und IPv6 Schnittstellen. Das Subnetz 3 ist ein reines IPv4 Netz.

Nun vergeben wir manuell IP-Adressen.

Temporär können diese 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 IP Adressen fest zu vergeben, werden diese in der Datei /etc/network/interfaces (eth0 / eth1) eingetragen. Wie dies im Detail auszusehen hat ist den untenstehenden Configfiles ersichtlich.

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.

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. Der Nameserver ist bind in Version 9.

Da jedes Subnetz einen Nameserver benötigt fungiert R1 sowie R2 als DNS. 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. /etc/bind/chaos.local (serial)

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

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 im IPv6-Internet 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 entstehen.

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 steht "0x29" 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 wird wie bei 6to4 das Protokoll 41 benutzt.


6in4 tunneling is also referred to as proto-41 static because the endpoints are configured statically Although 6in4 tunnels are generally manually configured, for example the utility AICCU can configure tunnel parameters automatically after retrieving information from a Tunnel Information and Control Protocol (TIC) server. There are similarly named methods, namely 6to4 or 6over4, which describe a different mechanism The 6in4 protocol has no security features, thus one can easily inject IPv6 packets by spoofing the source IPv4 address of a tunnel endpoint and sending it to the other endpoint. This problem can partially be solved by implementing network ingress filtering or with IPsec. Another solution is to use a secure protocol such as

4in6

6over4

Translation Verfahren

TRT

SIIT

NATPT

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.

Das Tunnelinterface wird erzeugt mit einem neuen Eintrag in der Datei /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. (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 bedienen wir uns wieder der gleichen Methode und richten 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.
Retrieved from "https://sarwiki.informatik.hu-berlin.de/index.php?title=Migration_auf_IPv6&oldid=9502"