Tcp/IP Workshop ipv4 und ipv6

Vorwort

Da zum Thema IPv6 viel Un- und Halbwissen existiert, habe ich mich entschlossen, mal einen kleinen "Workshop" zu machen, wie man mit IPv6 arbeitet und z.B. IPv6-Freigaben einrichtet.

Für Lesefaule, Eilige und technisch weniger Interessierte mache ich am Ende der "Backgroundwissen"-Kapitel eine stark vereinfachende Zusammenfassung.

Wer bereits meine erste Fassung des "Kleiner IPv6-Workshop" gelesen und verstanden hat, kann sich das erneute Durchlesen der beiden ersten Grundlagen-Kapitel sparen, sie wurden nur unwesentlich verändert und teilweise etwas vereinfacht. Alle weiteren Kapitel wurden grundlegend überarbeitet.

Ich bitte darum, keine Antworten bzw. Rückfragen in diesem Thread zu (er)stellen, sondern dafür diesen Thread zu benutzen.

Inhalt

Rückblick IPv4 / Warum eigentlich IPv6? und Grundlagen zu IPv6 Kommunikation in TCP/IP-Netzen / Funktionsweise und Hindernisse Lösung Hindernis 1: Nicht zu merkende IP / DynDNS - DynDNS für IPv4-Adressen / DynDNS für IPv6-Adressen / Einrichtung von DynDNS-Diensten bei IPv6 DynDNS-Updates über MyFritz! DynDNS-Updates auf dem "klassischen" Weg Lösung Hindernis 2 (& 3): Firewalls / IPv4-NAT Einrichtung von Port-Weiterleitungen bei IPv4 Einrichtung von Port-Freigaben bei IPv6 Lösung Hindernis 4: IPv4: CGN / Carrier Grade NAT Lösung Hindernis 5: IPv4 vs. IPv6: Ein Kommunikationspartner verfügt nicht über IPv6-Konnektivität Einrichtung von IPv6-Konnektivität in Routern / Tunnel von SixXS oder über 6in4 (Hurricane Electric) Einrichtung von IPv6-Konnektivität direkt auf einem PC / Tunnel von SixXS Einrichtung von IPv6-Konnektivität auf einem Android-Smartphone / Tunnel von SixXS Lösung Hindernis 6: IPv4 vs IPv6: Ein Server bzw. Dienst ist nur für IPv4 programmiert Workarounds für Enigma2-basierende DVB-S/DVB-C/DVB-T (Sat-/Kabel-/Terrestrisches TV) Receiver Tuning: Mehrere DynDNS-Updates mit nur einem Aufruf (Hilfreich besonders dann, wenn ein Hurricane Electric 6in4-Tunnel benutzt wird)

Rückblick IPv4 / Warum eigentlich IPv6?

Als das Protokoll erfunden wurde, auf dem unser aller Internet basiert, also TCP/IP, gab es das Internet noch gar nicht. Es hieß da noch Arpanet und war ein Forschungsnetzwerk, welches unterschiedliche US-amerikanische Universitäten, die für das US-Verteidigungsministerium forschten, verband. Für diesen Zweck erschien der von TCP/IP v4 angebotene Adressraum von 4 Mrd. Adressen noch mehr als ausreichend. Zur zeitlichen Einordnung: Wir reden hier von den späten 60er und den 70er Jahren.

Adressierung in einem TCP/IP-Netzwerk

Das Protokoll TCP/IP sieht eigentlich vor, daß jedes netzwerkfähige Gerät eine eigene Adresse (IP) erhält und durch Angabe einer Port-Nummer der anzusprechende Dienst bestimmt wird. Die IP unterteilt sich noch weiter in einen Netzwerk- und einen Hostteil.

Vergleichbar ist die IP mit einer Postadresse:

Anschrift samt Nachname (Familie Mustermann, Sowiesostraße 10, 12345 Musterhausen) könnte man mit der Netzwerkadresse,
den Vornamen mit der Hostadresse
und
den Betreff eines Briefes an diese Anschrift mit dem Port vergleichen.

Somit ist jede Person in jeder Wohnung und um was es geht (Z.B. eine Zahlungsaufforderung, die Aufforderung zu einer Antwort, die Bekanntgabe einer Erbschaft, ...) eindeutig adressierbar.

Wenn ich möchte, daß Max Mustermann seine Rechnung bezahlt, dann adressiere ich auch an Max Mustermann und schreibe "Zahlungsaufforderung" in den Betreff. Das Netzwerk "Familie Mustermann" weiß dann, daß das Familienmitglied Max gemeint ist und Max weiß, daß er vergessen hat, etwas zu bezahlen.

Exakt das selbe läuft ab, wenn ich einen Web-Server aufrufe. Um http://www.heise.de aufzurufen, wird dieser Name in die IP 193.99.144.85 aufgelöst, was unseren Postboten im Netzwerk (Also den Routern) sagt, daß unser Paket ins Netzwerk 193.96.0.0/14 zum Rechner 0.3.144.85 muß. Und weil ich den Web-Server erreichen will, füge ich der Adresse noch den Port 80 hinzu, damit der Rechner weiß, daß ich eine Webseite von ihm geschickt haben möchte.

Grenzen der Adressierbarkeit mit TCP/IP v4

Solange das ArpaNet ein reines Forschungsnetz war, war dieses Schema auch ohne weiteres einzuhalten. 1990 aber wurde das Arpanet für die kommerzielle Nutzung freigegeben und 1993 kam der erste grafische Webbrowser (Mosaic). Danach begann die wachsende Verbreitung des Internets und es war klar, daß der Adressraum von 4 Mrd. Adressen auf Dauer nicht reichen würde. Deshalb begann man zum einen mit der Entwicklung von IPv6 und auf der anderen Seite mit Maßnahmen, um mit den IPv4-Adressen besser zu haushalten.

Workaround 1: Dynamische IPs

Als Folge der Adressknappheit haben private Endkunden eigentlich nie einen vollwertigen IPv4-Anschluß bekommen, sondern z.B. nur dynamische IPs. Durch dynamische IPs konnte dieselbe IP an Einwahlverbindungen für mehrere Kunden genutzt werden: War Kunde A offline, dann bekam Kunde B die freigewordene Adresse und umgekehrt. Solange die Kunden den Internetzugang nach Zeit bezahlt haben, funktionierte das auch einigermaßen.

Mit der steigenden Verbreitung von Flatrates und DSL entfiel der Kostendruck, die Verbindung zu trennen, allerdings bekam man zu Beginn i.d.R. auch nur ein DSL-/Kabel-Modem, so daß nach wie vor der angeschlossene PC die Verbindung herstellen mußte und da viele Nutzer ihren PC nicht durchlaufen lassen, hatte man so nach wie vor eine gewisse Reserve durch dynamische IPs.

Durch das Aufkommen von SOHO-(Small Office/Home Office)-Routern wurde es dann aber zunehmend zur Normalität, daß die Kunden ihre Internet-Verbindung dauerhaft aufrecht hielten. Mit dynamischen IPs kann man nun nur noch unwesentlich Adressen sparen, denn selbst bei ausgeschalteten PC ist ja der Router bzw. die Modem/Router-Kombi noch online.

Dynamische IPs und die Zwangstrennung haben nur noch den Zweck, den Betrieb von Servern an Privatkundenanschlüssen zu erschweren. Eine Sicherheitsfunktion oder Privatsphärenschutz ist mit dynamischen IPs nicht verbunden! Durch die Hinzunahme von Protokollen und Datum/Zeitpunkt des Zugriffs läßt sich problemlos jederzeit jede IP einem Anschluß zuordnen und eine genauere Zuordnung ist auch nicht nötig, da sowieso der Anschlußinhaber haftet.

Damit bleibt als wahrer Grund für dynamische IPs nur die technische Beeinträchtigung der Erreichbarkeit eines Anschlusses für Serverdienste. Noch mal am Beispiel der Postadressen: Ich weiß zwar, daß ich einen Web-Server (Port 80) bzw. einen Max erreichen will, ich kenne aber seine IP und damit Postanschrift nicht mehr, da sich diese ständig ändert. Die bekannte Krücke zur Lösung des Problems sind DynDNS-Dienste, also praktisch Nachsendeaufträge.

Workaround 2: NAT (Network Address Translation)

Adressierung im LAN mit privaten IPs

Um IPv4 einzusparen, nutzt man NAT. Statt jedem Kunden auch wirklich ein Subnet zuzuweisen, mit dem man jedem Gerät im Heimnetz seine eigene IP zuteilen könnte, bekommt man auch im Zeitalter von Routern und Zweit-PCs/Notebooks weiterhin nur eine einzige öffentlich erreichbare IP und muß seine Geräte zuhause über NAT anbinden. Dabei erhält zwar jedes Gerät eine eigene IP, die jedoch nur im heimischen Netzwerk eindeutig ist.

Um die Konsequenz klar auszusprechen: Hierbei wird das Grundprinzip der TCP/IP-Netzwerkadressierung verletzt, daß jeder Rechner seine eigene Adresse hat. Aus Sicht des Internets ist jeder solche NAT-Anschluß nur ein einziges Gerät und erst vor Ort gibt es eindeutige Adressen für alle Geräte, die aber nach außen hin nicht sichtbar sind.

Um bei unserem Beispiel zu bleiben: Max, Franz und Petra Mustermann wissen zwar voneinander und können sich auch innerhalb der eigenen Wohnung gezielt ansprechen, aber nach außen hin treten sie nur als "Familie Mustermann" in Erscheinung.

Für diesen Zweck sind die bekannten Adressen im Muster 192.168.x.y sowie die weniger bekannten Adressbereiche 10.x.y.z und 172.16.0.0 bis 172.31.255.255 reserviert und werden im Internet nicht durchgeleitet.

Kommunikation aus einem LAN mit privaten IPs ins Internet

Diese Adressen werden nur innerhalb von privaten Netzen genutzt und erst der Router "bündelt" den ausgehenden Traffic aller Geräte dieses Netzwerkes auf der einen öffentlichen IP, leitete ihn mit dieser als Absender ins Internet und sorgte dafür, daß die eingehenden Antworten auch wieder an den PC im Heimnetz gehen, der auf diese Antwort wartet.

Dieser Vorgang der Network Address Translation (NAT) ist mit der Frage "Max, hast Du was bei Amazon bestellt?" vergleichbar, die auftritt, wenn Petra Mustermann ein an "Familie Mustermann" adressiertes Paket annehmen soll, selber aber nichts damit anzufangen weiß. Eine Frage, die nicht nötig wäre, wenn schon in der Anschrift "Max Mustermann" oder eben "Franz Mustermann" stünde. Petra Mustermann ist in diesem Beispiel der Router, der versucht, das eingegangene Paket demjenigen im Netzwerk/der Familie zuzuordnen, der es auch angefordert hat.

Somit können alle angeschlossenen Geräte sich eine Internetverbindung und -adresse teilen, solange alles von außen eingehende auch von irgendeinem Rechner erwartet wird, analog unserem Paket von Amazon, das ja irgendjemand bestellt hat. Direkt von außen erreichbar sind die einzelnen Geräte aber nicht.

Genau wie ständige Nachfragerei, wer etwas bei Amazon, Bonprix, Otto, Conrad, ... bestellt hat, ist auch beim Router die Zuordnung von Antworten zu dem Gerät, welches darauf wartet, mit erheblichem (Rechen-)Aufwand verbunden.

Zugriffe vom Internet auf ein LAN mit privaten IP-Adressen

Unangeforderte Zugriffe von außen enden am Router, der nichts damit anzufangen weiß. Durch Port-Weiterleitungen kann man dem Router nun sagen, daß z.B. Zugriffe auf einen Web-Server (Erkennbar daran, daß Port 80 angesprochen wird) f einen ganz bestimmten Rechner im Heimnetz geleitet werden sollen, auf dem eben der Web-Server läuft. Das konnte man mit jedem einzelnen der 65535 Ports machen, mit jedem davon aber nur ein Mal.

Ein zweiter Web-Server ist also nicht möglich (Da der dafür benutzte Port 80 schon für den ersten Web-Server benutzt wird), bzw. der zweite Web-Server müßte dann einen anderen, nicht standardgemäßen, Port nutzen.

Beispiel: Im Heimnetz steht ein NAS mit Web-Zugriff und ein Receiver mit Web-Interface. Der NAS habe die lokale IP 192.168.1.10 und der Receiver die lokale IP 192.168.1.11. Das Heimnetz habe die öffentliche IP 176.198.22.67. Im lokalen Netzwerk kann man nun per Webbrowser durch Eingabe der o.g. lokalen IPs beide Geräte direkt ansprechen. Für den Zugriff von außen müßte man in der Fritz!Box aber Portfreigaben nach diesem Muster einrichten: Als Freigabe namens "Receiver WebInterface" leite TCP-Anfragen von Port 80 an das Gerät Receiver auf Port 80 Als Freigabe namens "NAS WebInterface" leite TCP-Anfragen von Port 81 an das Gerät NAS auf Port 80 Nun kann man von außen mittels Eingabe der Adresse 176.198.22.67 direkt auf den Receiver zugreifen, für den Zugriff auf den NAS muß man aber 176.198.22.67:81 eingeben, da Port 81 nicht der Standardport für Web-Server ist.

Am Beispiel unserer Postadresse würde das bedeuten, daß z.B. nur Max Mustermann alle Rechnungen für "Familie Mustermann" auf den Tisch gelegt bekäme. Franz hingegen könnte so keine Rechnungen bekommen, es sei denn, ich schriebe in den Betreff explizit "Rechnung Franz Mustermann" hinein.

W==orkaround 3: CGN (Carrier Grade NAT, also "Network Address Translation durch den Anbieter")==

Das bisher am Heimanschluß vorherrschende Szenario war - eine einzige öffentliche IPv4 - NAT für das lokale Heimnetz mit privaten IP-Adressen

Beim CGN kommt nun eine NAT-Ebene hinzu, d.h. die Pakete werden bereits beim Provider durch eine "Adressübersetzungen" gejagt. Vereinfacht gesagt funktioniert diese ganz genau so, wie im vorherigen Abschnitt beschrieben, nur daß in diesem Fall nicht nur die diversen Geräte im Heimnetz via NAT-Router über nur eine IP gebündelt nach außen kommunizieren, sondern zusätzlich auch mehrere Kunden bzw. Anschlüsse nur noch private IPv4-Adressen erhalten und wiederum über einen NAT-Router beim Anbieter (Das "AFTR-Gateway") über eine gemeinsame öffentliche IPv4 auf das Internet zugreifen. Als Konsequenz "sieht" das Internet hier nicht nur keine einzelnen Geräte, sondern auch den kompletten einzelnen Anschluß nicht mehr. Stattdessen scheinen alle Zugriffe aus dem CGN heraus von nur einem einzigen Rechner zu stammen.

Auf unser Beispiel mit der Postadresse übertragen bedeutet dies, das nun ein Portier alle Antwort-Pakete annimmt. Dieser kann - weil er die Bestellungen im Auftrage der Familien selber weggeschickt hat - die Pakete einer im Hause wohnenden Familie zuordnen, nicht aber einer Person aus der Familie. Letztere Zuordnung erledigt weiterhin die Person in der Familie, die immer die Pakete annimmt (Also Petra, unser Router).

Genauso wie unsere Petra/unser normaler NAT-Router zuhause ist auch der Portier/das AFTR-Gateway nicht in der Lage, unverlangt eingehende Pakete zuzuordnen. Somit kann die ganze Familie Mustermann (Genauso wie die Schmitzens, Müllers und Meiers aus demselben CGN-Haus) keine Anfragen von außen/aus dem Internet beantworten, da diese nie bei ihnen ankommen. Anders als unser NAT-Router zuhause kann das AFTR-Gateway auch nicht mit Portfreigaben dazu gebracht werden, zumindest auf bestimmte Betreffs/bestimmten Ports zu reagieren.

Ergebnis: Die Rechner bzw. Netze hinter einem AFTR-Gateway sind von außen gar nicht mehr ansprechbar, sie können nur Antworten auf Anfragen von innen heraus erhalten.

Grundlagen zu IPv6

Änderungen durch IPv6

Mit all diesem Humbug räumt IPv6 auf. Durch eine längere Adresse stehen nun nicht mehr nur 4 Mrd. (3,7 Mrd. nutzbare) IPv4-Adressen, sondern 340 Sextillionen IPv6-Adressen zur Verfügung und damit genug für alle. Dank IPv6 kann jedes Smartphone, jeder PC im Heimnetz, jede Spielkonsole, jeder Receiver, jeder NAS usw. seine eigene Adresse erhalten und ohne Umwege angesprochen werden.

Ansonsten bleibt eigentlich alles genau wie vorher, abgesehen davon, daß ich jetzt wieder mit dem ursprünglichen Adressierungskonzept arbeiten kann, welches ja nur deshalb im privaten Umfeld nicht ging, weil ich nicht genug Adressen zur Verfügung hatte.

Aufbau von IPv6-Adressen im Vergleich zu IPv4-Adressen

Während IPv4-Adressen aus 4 Blöcken a 256 Werten aufgebaut sind, also z.B. 176.198.22.67, sind es bei IPv6 8 Blöcke mit jeweils 65536 Werten. Zur Unterscheidung zu IPv4 nutzt man zum Trennen der Blöcke keine Punkte mehr, sondern Doppelpunkte. Und weil 8193:19920:65280:33837:547:4607:65044:57278 sehr unhandlich aussieht, schreibt man diese Adressen in Hexadezimal, also so: 2001:db8:affe:c0c0:223:11ff:fe14:1234. Wie bei IPv4 gibt es Subnetze und die werden auch fast genauso beschrieben.

Da man als Privatkunde bei IPv4 selten einen vollwertigen IPv4-Zugang bekommen hat, dürfte vielen nur das private Subnetz 192.168.x.y Subnetzmaske 255.255.255.0 bzw. 192.168.x.y/24 etwas sagen.

Beide Schreibweisen bezeichnen das selbe Subnetz, nämlich das, bei dem der Teil 192.168.x feststeht und die Stelle y für Hosts im Subnetz (Also die Vornamen der Familienmitglieder) vergeben werden kann. Der erste Teil hätte - wie zu Beginn beschrieben - normalerweise die Funktion der eigentlichen Postanschrift, um die Familie Mustermann an sich zu erreichen. Da es sich aber nur um einen speziell reservierten privaten Adressbereich handelt, fehlt ihm diese Aussagekraft, weil dieser Teil nur "Irgendein lokales, nicht ins Internet geroutetes LAN" beschreibt. Praktisch wie die Antwort "Zuhause" auf die Frage, wo man wohnt.

Die Maske drückt aus, welche Bits unveränderlich sind. 255 = 11111111 in Dual, d.h. alle 8 Bits sind unveränderlich. Da wir bei der Subnetzmaske 255.255.255.0 die 255 für die ersten drei Blöcke haben, heißt das, das sich an den Zahlen der ersten drei Blöcke auch nichts ändern darf, sonst wären wir in einem anderen Subnetz. Weil die Schreibweise mit Maske lang und unhandlich ist und die Bits auch immer von hinten zwischen Subnetz und Hosts verschoben wird, geht man immer mehr dazu über, einfach die Anzahl der festgelegten Bits anzugeben, also z.B. 192.168.178.0/24 für das Standard-Subnetz einer Fritz!Box, bei dem der Teil 192.168.178 (Die ersten 24 Bit) unveränderlich ist.

Innerhalb eines Subnetzes sind die erste und die letzte Adresse reserviert als Netzwerk- und Broadcastadresse, stehen also für Hosts nicht zur Verfügung. Im Netzwerk 192.168.178.0/24 sind das die 192.168.178.0 als Netzwerk- und die 192.168.178.255 als Broadcast-Adresse.

Bei Unitymedia-Business-Anschlüssen mit fester IPv4 erhält man übrigens auch Subnetze, nämlich entweder a.b.c.d/30 ("1" IPv4-Adresse) oder a.b.c.d/29 ("5" IPv4-Adressen) bzw. an zwei praktischen Beispielen: 176.198.22.64/30 entspricht dem Adressraum 176.198.22.64 bis 176.198.22.67, da von den 32 Bits nur 2 (32-30) für Hosts genutzt werden können, also die Bits für die 1 und die 2, also 64+0 (=64) , 64+1, 64+2 und als letzte 64+1+2 (= 67)

Von diesem Adressraum mit 4 Adressen ziehen wir die Netzwerk- und Broadcastadressen ab, bleiben 2 IPs, eine kriegt der Router und schon sind wir bei genau einer statischen IP für die angeschlossenen Geräte.

Ergebnis:

176.198.22.64 = Netzwerkadresse
176.198.22.65 = Für den Unitymedia-Router verwendete IP
176.198.22.66 = 1. Host-IP, zur Verwendung durch den Router/Rechner des Kunden
176.198.22.67 = Broadcast-Adresse
176.198.22.64/29
entspricht dem Adressraum 176.198.22.64 bis 176.198.22.71,
diesmal sind es 3 Host-Bits, also die für die 1, die 2 und die 4, somit also 64+0 (=64), 64+1, 64+2, 64+1+2, 64+4, 64+4+1, 64+4+2, 64+4+2+1 (=71)

Von diesem Adressraum mit 8 Adressen ziehen wir die Netzwerk- und Broadcastadressen ab, bleiben 6 IPs, eine kriegt der Router und schon sind wir bei fünf statischen IPs für die angeschlossenen Geräte:

176.198.22.64 = Netzwerkadresse
176.198.22.65 = Für den Unitymedia-Router verwendete IP
176.198.22.66-176.198.22.70 = 1. bis 5. für Hosts verwendbare IP
176.198.22.71 = Broadcast-Adresse
Subnetze funktionieren bei IPv6 genauso wie bei IPv4,
wobei hier nur die Schreibweise mit der Anzahl der feststehenden Bits (/64) üblich ist,
denn 65535:65535:65535:65535:0:0:0:0 oder FFFF:FFFF:FFFF.FFFF:0:0:0:0 sähe doch arg bescheuert aus.

Bei IPv6 ist es vorgesehen, daß jeder Endkunde mindestens ein 64er Präfix und Subnetz kriegt. Bei einem Subnetz 2001:db8:affe:c0c0::/64 haben wir den feststehenden Teil 2001:db8:affe:c0c0 (Die ersten 64 Bit) und dahinter Platz für Hostadressen von ::0 bis FFFF:FFFF:FFFF:FFFF. Ich mag das jetzt nicht vorrechnen, aber das sind 18446744073709551616 Adressen (2^64), vorerst genug auch für kleine WGs und Familien. Im Gegensatz zu unserem bekannten IPv4-Subnetz 192.168.x.y ist dieses Subnetz auch ein vollwertiges, routingfähiges Subnetz, das nicht nach außen hin durch eine andere, öffentliche IP ersetzt werden muß!

Subnetze kleiner als 64 sind bei IPv6 unüblich, weil das die Mindestgröße für die Adressvergabe per SLAAC (State-Less Address Auto Configuration bzw. zustandslose Adressautokonfiguration) ist. Zur Schreibweise (Notation) von IPv6-Adressen gibt es Vereinfachungen, um Adressen kürzer zu schreiben: Führende Nullen kann man streichen. Statt 2001:0db8:affe:0000:0000:01ff:0e14:1234 dürfte ich also schreiben: 2001:db8:affe:0:0:1ff:e14:1234 Aufeinanderfolgende Blöcke zu 0 dürften einmalig zusammengefaßt werden und werden durch zwei aufeinanderfolgende Doppelpunkte gekennzeichnet. Die o.g. Adresse dürfte ich also so schreiben: 2001:db8:affe::1ff:e14:1234 Einmalig heißt, das ich das nur ein einziges Mal in einer Adresse machen darf. Die Adresse 2001:0:0:0:01ff:0:0:0fbe darf ich also zu 2001::01ff:0:0:0fbe zusammenfassen, die hinteren zwei Blöcke mit Nullen müssen stehenbleiben, weil es ja sonst zwei Möglichkeiten gäbe, wieder auf 8 Blöcke zu kommen, nämlich vorne zwei plus hinten drei einerseits und vorne drei und hinten zwei andererseits. Wenn man also einer Adresse mit mehreren Sequenzen von 0er Blöcken begegnet, streicht man natürlich den größeren zusammen.

Spezielle Adressen IPv4 und IPv6 im Vergleich

Sowohl bei IPv4 als auch bei IPv6 gibt es einige spezielle Adressen. Die wohl bekannteste davon bei IPv4 ist die 127.0.0.1 oder "localhost". Diese adressiert sozusagen "sich selbst". Man begegnet ihr daher z.B. dann, wenn ein Dienst auf dem eigenen Rechner im Hintergrund läuft und über eine entsprechende Schnittstelle konfiguriert werden kann. Man nutzt sie auch, wenn man z.B. auf seinen eigenen FTP-Server zugreifen will, oder oder oder. Die entsprechende Adressse bei IPv6 lautet ::1/128 (Also in lang: 0:0:0:0:0:0:0:1 bzw. in ganz lang 0000:0000:0000:0000:0000:0000:0000:0001). Ansonsten gibt es noch spezielle Adressen in Form der Netzwerk-Adresse oder der Broadcast-Adresse, die ich oben bereits erwähnt hatte, die zu erklären hier aber zu weit führen würde. Vergleichbares gibt es auch bei IPv6, es ist aber zum weiteren Verständnis nicht notwendig. Eingehen möchte ich noch auf die link-local-Adressen, die mit fe80:0000:0000:0000 oder fe80::/64 beginnen. Adressen in diesem Subnet gelten nur lokal, also in einem abgeschlossenen Netzwerk und spielen hauptsächlich für die Adressvergabe eine Rolle.

Adressvergabe IPv6

DHCP vs. DHCPv6 Bei IPv4 nutzen wir vor allem DHCP zur Adressvergabe. Sei es, weil wir eine einfache Einwahlverbindung nutzen und uns der Einwahlserver so eine Adresse zuweist, oder weil wir hinter einem Heim-Router sitzen, der so den angeschlossenen Geräten eine Adresse zuweist. Auch der Router selber erhält meist auf diese Weise seine öffentliche IP.

Daneben gibt es noch die statische IP, bei der wir auf einem Gerät eine feste IP (Meist eine aus dem Heimnetz) fest eintragen, z.B. weil wir wollen, daß der Receiver oder ein Netzwerkdrucker auch immer unter der selben IP erreichbar ist. Diese Methode ist, ohne da weiter drauf eingehen zu wollen, großer Mist, da wir selber Buch darüber führen müßten, welches Gerät nun welche IP hat, damit wir z.B. nicht dieselbe IP nochmals vergeben. Bei einer Änderung des Subnetzes, z.B. bei einem Routerwechsel, stünde ein derart konfigurierter Host auch auf einmal außerhalb des angestammten Subnetzes.

Eleganter ist da die statische Adressvergabe per DHCP. Dazu sagen wir einfach dem DHCP-Server, daß er dem Gerät mit einer bestimmten Hardware-Adresse (MAC) immer eine bestimmte IP zuweisen soll. Die Adresskonfiguration erfolgt dann immer noch per DHCP, nur eben immer mit derselben Adresse. In der Fritz!Box geht das, indem man auf der Seite Heimnetz beim gewünschten Gerät einen Haken in die Box "Diesem Gerät immer dieselbe Adresse zuweisen" machen. Bei einer Änderung des Subnetzes müssen wir so wenigstens nur an einer Stelle, im Router, eingreifen. Heutzutage erfolgt meist auch die Zuweisung von DNS-Servern und die Definition des "Standard-Gateways" (Wohin angeschlossene Geräte alle Daten-Pakete hinschicken sollen, wenn sie nicht selber wissen, was damit zu tun ist) über DHCP. Auch für IPv6 kann man DHCP zur Adressvergabe verwenden, also DHCPv6. Das ist aber relativ unüblich, i.d.R. wird man SLAAC verwenden wollen. Bei SLAAC weisen sich die angeschlossenen Geräte den Host-Teil der Adresse selber zu und das bereits bevor sie eine Verbindung haben. Daher auch das "State-Less" bzw. "Zustandslos" in "StaleLess Address AutoConfiguration".

Dazu verwendet das Gerät seine Hardware-Adresse (MAC), die folgendes Format hat

AA:BB:CC:DD:EE:FF, also 48 Bit

fügt in der Mitte "FF:FE" ein (Damit haben wir die benötigten 64 Bit) und kippt das 7. Bit (Wert = 2) des ersten Blocks. Zu guter Letzt wird das ganze noch in 16 Bit-Blöcke geschrieben.

Aus der MAC 00:22:15:15:BE:7D wird also ...
... Einfügen von FF:FE -> 00:22:15:FF:FE:15:BE:7D
... Kippen des 7. Bits: -> 02:22:15:FF:FE:15:BE:7D
... in 16 Bit Blöcken -> 0222:15ff:fe15:be7d
Damit hat jedes Gerät schon einen fertigen Host-Teil für eine IPv6-Adresse.

Um die Adresskonfiguration abschließen zu können, braucht es aber noch ein Subnet. Hierzu nimmt es einfach fe80:: und fertig ist eine link-local-Adresse, also z.B. fe80::222:15ff:fe15:be7d oder in lang fe80:0:0:0:222:15ff:fe15:be7d Sobald das Gerät Informationen über das verwendete öffentliche IPv6-Präfix weiß, weist es sich dieselbe Adresse mit diesem Präfix zusätzlich als öffentliche IPv6-Adresse zu. Bei dem Präfix 2001:db8:affe:0 wäre das also die 2001:db8:affe:0:222:15ff:fe15:be7d.

Auf einer Kommandozeile kann man sich das mit "ipconfig /all" sehr schön ansehen (Vgl. die Parallelen zwischen "physikalischer Adresse" (=MAC) und IPv6, 2. Hälfte):

Beschreibung. . . . . . . . . . . : Marvell Yukon 88E8001/8003/8010 PCI Gigabit Ethernet Controller
Physikalische Adresse . . . . . . : 00-22-15-XX-XX-XX
DHCP aktiviert. . . . . . . . . . : Ja
Autokonfiguration aktiviert . . . : Ja <-- = SLAAC
IPv6-Adresse. . . . . . . . . . . : 2001:db8:affe::222:15ff:feXX:XXXX(Bevorzugt)
Verbindungslokale IPv6-Adresse  . : fe80::222:15ff:feXX:XXXX%11(Bevorzugt)

Was das Gerät auf diese Weise nicht konfigurieren kann, sind das Standardgateway und der oder die DNS-Server. Hierzu verwendet man auch weiterhin meistens DHCP bzw. DHCPv6, nur eben ohne Adressvergabe. Die Kombination aus SLAAC für die Adresskonfiguration und DHCPv6 für die Zuweisung von Gateway und DNS nennt sich auch "Stateless DHCPv6". Privacy Extension Weil es Paranoiker gibt, die die Preisgabe der MAC-Adresse für heikel halten, gibt es die sog. Privacy Extensions.

Die Adressbildung erfolgt genauso wie zuvor beschrieben bei SLAAC, es wird jedoch ein anderer konstanter Wert für die Adressbildung verwendet wird und nicht die MAC-Adresse. Zusätzlich weisen sich Geräte mit Privacy Extensions eine zweite öffentliche IP zu, bei der der Hostteil NICHT konstant ist, sondern regelmäßig gewechselt wird, also praktisch eine dynamische IPv6 (Innerhalb des zugewiesenen Subnetzes natürlich).

Ein Gerät kann auch mehrere öffentliche IPv6 haben, z.B. eine mit Privacy Extensions und gewürfeltem IP-Hostteil zum Surfen und eine mit statischem Hostteil, um Dienste/Server daran zu binden. Bei Windows ist dies übrigens der Standard. Öffentliche IP-Bereiche (Routingfähige IP-Bereiche) Als routingfähig ist Stand heute der Bereich 2000 bis 3fff definiert.

Adressen aus diesem Bereich sind "normale" öffentliche IPs, mit folgenden Spezialbereichen:
Beginnend mit 2001:0: = Übergangsmechanismus Teredo
Beginnend mit 2001:db8: = Für Dokumentationszwecke zu verwenden (Werden nicht vergeben)
Beginnend mit 2002: = Übergangsmechanismus 6to4
IPv6-Subnetze
Diese werden von den Providern wahlweise statisch (Jeder Kunde erhält immer wieder das selbe Subnetz) oder dynamisch (Das Subnetz ändert sich mit jeder Einwahl) zugewiesen.

Es ergibt sich aus der Kombination von Autokonfiguration und Subnetzvergabe, daß die resultierenden IPv6-Adressen sein können:

komplett statisch
Statisches Subnetz und SLAAC ohne Privacy Extensions
komplett dynamisch
Dynamisches Subnetz und SLAAC mit Privacy Extensions
teilweise dynamisch

Bei einem dynamischen Subnetz und SLAAC ohne Privacy Extensions bleibt der Host-Teil der Adresse immer gleich. Bei einem unveränderten und offenbar aus einer MAC generierten Hostteil ist die Wahrscheinlichkeit groß, daß es sich trotzdem um denselben Rechner handelt, auch wenn sich das Subnetz geändert hat. Noch größer ist diese Wahrscheinlichkeit, wenn beide Subnetze dem selben Provider oder gar der selben Region zugeordnet werden können. Bei einem statischen Subnetz und SLAAC mit Privacy Extensions bleibt der Subnetz-Teil der Adresse immer gleich. In diesem Fall sind alle Vorgänge mit dieser IP eindeutig immer demselben Anschluß zuzuordnen, es ist nur nicht transparent, welches Gerät im Heimnetz ihn veranlaßt hat.

Statische Subnetze wären also im Sinne eines vollwertigen Zuganges das Ideal, denn damit wäre ohne weitere Verrenkungen ein stabiler Zugriff von außen auf Geräte zuhause möglich (Z.B. NAS, Receiver, IP-Webcam, Heimautomatisierung, ...). Es ist aber abzusehen, daß die Provider uns unter dem Vorwand der "Privatsphäre" nur dynamische Subnetze geben werden. Für Zugriffe von außen werden wir also weiterhin DynDNS-Dienste benötigen, während Hinz und Kunz sowieso anhand von Subnetz und Uhrzeit vom Provider gesagt bekommen, welcher Anschluß dahintersteckt.

Zusammenfassung

IPv6 wurde nötig, um bei einer steigenden Anzahl internettauglicher Geräte jedem Gerät eine eigene IP zuweisen zu können und somit einen vollwertigen Internetzugang zu ermöglichen: Auch Endkunden erhalten nun nicht mehr nur eine einzige IPv4, die über Hilfsmechanismen mit allen Geräte im Heimnetz geteilt werden muß, sondern ein ganzes Subnetz mit Abermillionen Adressen. Bei üblichen Standardeinstellungen werden sich IPv6-taugliche Geräte im Heimnetz selbständig konfigurieren. Ob die resultierenden IP-Adressen statisch oder dynamisch sind, wird im wesentlichen dadurch beeinflußt, ob der eigene Provider ein statisches oder dynamisches Subnetz zuweist, da der Hostteil der IP durch Konfiguration am Gerät beeinflußt werden kann (statisch oder dynamisch oder beides gleichzeitig). IPv6-Adressen haben 128 Bit, die in 8 Blöcken hexadezimal geschrieben werden, z.B. 2001:db8:affe:0:0:1ff:e14:1234. Aufeinanderfolgende Doppelpunkte :: in IPv6-Adressen stehen immer für so viele Blöcke mit dem Wert 0, wie nötig sind, um die Adresse auf 8 Blöcke zu erweitern (::1 = 0:0:0:0:0:0:0:1).

Zwischen einem vollwertigen Zugang mit IPv4 und einem vollwertigen mit IPv6 besteht bezüglich der technischen Möglichkeiten kein Unterschied. Da private Endkunden in der Vergangenheit eigentlich noch nie vollwertige IPv4-Zugänge erhalten haben, hat IPv6 hier technisch betrachtet nur Vorteile. Eventuelle Nachteile bei der Benutzung von IPv6 entstehen aus der Inkompetenz diverser Hard- und Softwarehersteller und der Trantütigkeit der Internet-Provider und sollen in einem späteren Teil des Workshops beleuchtet werden.

Kommunikation in TCP/IP-Netzen, also auch dem Internet

Dieses Kapitel ist für diejenigen gedacht, die wissen wollen, wie wir über IPv6 kommunizieren können. Eigentlich stellt sich diese Frage nämlich gar nicht, da es in diesem Punkt keine Unterschiede zu IPv4 gibt.

Funktionsweise

Lassen wir einmal die bekannten Einschränkungen von Privatkunden-IPv4-Anschlüssen beiseite, dann funktioniert die Kommunikation in TCP/IP-Netzen unabhängig von IPv4 oder IPv6 nach folgendem Prinzip (Wobei ich stark vereinfache, das OSI-Schichten-Modell erspare ich Euch):

In einem TCP/IP-Netzwerk hat jedes angebundene Gerät eine IP-Adresse, durch die es eindeutig gekennzeichnet ist. Wenn Rechner A einen Server auf Rechner B erreichen möchte, dann wird ein Paket auf die Reise geschickt, das die IP-Adresse von Rechner A als Absendeadresse und die IP-Adresse von Rechner B als Zieladresse enthält. Zusätzlich enthält das Paket noch Informationen darüber, mit welchem Dienst des Zielrechners Rechner A verbunden werden möchte. Bei den Diensten gibt es einige "wohlbekannte" (well defined), definierte Dienste mit einem standardisierten Port, wodurch wir selten Ports mit angeben müssen, weil der beteiligte Client einfach den Standardport annimmt, wenn wir keinen angeben.

Beispiel:

   Rechner A habe die IP 217.45.67.13 und Rechner B die IP 173.194.70.106
   Rechner A möchte den Web-Server auf Rechner B erreichen
   Der Web-Client schickt nach Eingabe der Adresse 173.194.70.106 einen Anfrage an 173.194.70.106:80, also die IP-Adresse von Rechner B, ergänzt um den Port 80, den wohlbekannten Port für das http-Protokoll.
   Rechner B empfängt das von A geschickte Paket und erkennt anhand des angefragten Ports 80, daß er die Anfrage an den auf ihm laufenden Web-Server (Der ja an eben diesen Port 80 gebunden ist) weiterleiten soll.
   Rechner B leitet das Paket an den Web-Server weiter und dieser gibt die gewünschte Antwort raus
   Rechner B schickt nun ein an Rechner A rückadressiertes Paket mit der Antwort des Webservers
   Rechner B erhält das Antwortpaket, leitet es an den Web-Browser weiter und der kann es nun anzeigen

An diesem Beispiel ändert sich absolut gar nichts, wenn Rechner A nun nicht mehr die IPv4-Adressen 217.45.67.13 sondern die IPv6-Adresse 2001:db8:affe:c0co:27b:d0d1:675:abca und Rechner B nicht mehr die IPv4-Adresse 173.194.70.106 sondern z.B, die IPv6-Adresse 2a00:1450:4001:c02::68 hätte!

Aus diesem Grund reicht es eigentlich völlig, wenn sich ein Server sowohl an die IPv4 als auch an die IPv6 des Rechners bindet, um sowohl mit IPv4-Clients als auch mit IPv6-Clients zusammenarbeiten zu können. Ich habe das "und" gesondert markiert, weil ein IPv4-Client nicht mit einem IPv6-Server und ein IPv6-Client nicht mit einem IPv4-Server kommunizieren kann, sondern immer nur protokollgleiche Client<>Server-Kombinationen. Dazu später mehr.

Weil wir Menschen uns Zahlenkolonnen schlecht merken können, benutzen wir statt dieser numerischen IP-Adressen lieber sprechende "URL" (Uniform Ressource Locators), also z.B. http://www.google.com statt 2a00:1450:4001:c02::68 oder 173.194.70.106. Für diese "Magie" findet vor jeder neuen Verbindung zu einem Server ein vergleichbarer Zugriff auf einen anderen Server statt, den DNS-Server (Das S ist hier nicht doppelt gemoppelt, denn DNS steht für Domain-Name-System). Der DNS-Server ist der einzige Rechner, den jedes angebundene Gerät mit Nummer kennen muß, wenn es über URLs auf andere Rechner zugreifen können will.

Für das Beispiel von vorhin heißt das, wenn Rechner A den DNS 217.45.67.1 nutzt:

   Rechner A habe die IP 217.45.67.13 und Rechner B die IP 173.194.70.106
   Rechner A möchte den Web-Server auf Rechner B erreichen, kennt aber nicht dessen IP, sondern nur seinen Namen "www.google.com".
   Der Web-Client schickt nach Eingabe der Adresse http://www.google.com eine Anfrage an den Rechner 217.45.67.1 auf Port 53, also die IP-Adresse des DNS, ergänzt um den Port 53, den wohlbekannten Port für das DNS.
   Der Rechner "DNS" mit der IP 217.45.67.1 empfängt ein Paket von Rechner A und erkennt anhand des angefragten Ports 53, daß er die Anfrage an den auf ihm laufenden DNS-Server (Der ja an eben diesen Port 53 gebunden ist) weiterleiten soll.
   Rechner "DNS" leitet das Paket an den DNS-Server weiter und dieser gibt die gewünschte Antwort raus (Nämlich, welche IP(s) hinter http://www.google.com steckt/stecken, also 2a00:1450:4001:c02::68 und 173.194.70.106)
   Rechner "DNS" schickt nun ein an Rechner A rückadressiertes Paket mit der Antwort des DNS-Servers
   Rechner B erhält das Antwortpaket, leitet es an den Web-Browser weiter und der weiß nun, daß er entweder über IPv6 mit 2a00:1450:4001:c02::68 oder über IPv4 mit der 173.194.70.106 sprechen will
   Der Web-Browser schickt nun eine Anfrage an 173.194.70.106:80, also die IPv4-Adresse von Rechner B, ergänzt um den Port 80, den wohlbekannten Port für das http-Protokoll.
   Rechner B empfängt das von A geschickte Paket und erkennt anhand des angefragten Ports 80, daß er die Anfrage an den auf ihm laufenden Web-Server (Der ja an eben diesen Port 80 gebunden ist) weiterleiten soll.
   Rechner B leitet das Paket an den Web-Server weiter und dieser gibt die gewünschte Antwort raus
   Rechner B schickt nun ein an Rechner A rückadressiertes Paket mit der Antwort des Webservers
   Rechner B erhält das Antwortpaket, leitet es an den Web-Browser weiter und der kann es nun anzeigen

Wieder ändert sich absolut gar nichts, wenn der Rechner A in Schritt 8 entschieden hätte, das Paket an [2a00:1450:4001:c02::68]:80 zu schicken, statt an 173.194.70.106:80 (IPv6-Adressen schreibt man innerhalb von URLs in eckigen Klammern, damit der entsprechende Client die IP von einer eventuellen Port-Angabe unterscheiden kann, die ja ebenfalls mit Doppelpunkt abgetrennt wird). Es wäre lediglich die Antwort entsprechend an die IPv6-Adresse von Rechner A rückadressiert worden, statt an die IPv4-Adresse.

Kommunikationshindernisse

Wie im vorherigen Kapitel beschrieben, reicht es prinzipiell völlig aus, einen Server auf dem einen Rechner zu starten, damit andere Rechner auf diesen Server zugreifen können. Im Heimnetz machen wir das ständig. Hat der neue Sat-Receiver z.B. ein WebInterface, mit dem man ihn programmieren kann, brauchen wir ihn nur ins Netzwerk zu stöpseln und können von anderen Rechnern im Heimnetz direkt per Web-Browser darauf zugreifen. Ich gebe zu, daß Sat-Receiver im Unitymedia-Forum nicht das beste Beispiel sind, aber bei einem NAS, einer IP-Cam o.ä. ist das auch nicht anders ... :) Indem wir einfach die IP des Sat-Receivers im lokalen Netzwerk in die Adresszeile unseres Browsers eingeben, öffnen wir dessen Web-Interface, fertig.

Grundsätzlich würde das aus dem gesamten Internet heraus ganz genauso klappen, wenn es da nicht ein paar Hindernisse gäbe, die es auszuräumen gilt, wenn wir diesen Zugriff wünschen:

   Die Adresse ist blöd zu merken und ändert sich u.U. auch noch ständig
   Aus diesem Grund gibt es das DNS und sprechende URLs. Das Problem ist, daß wir dem DNS erst noch mitteilen müssen, unter welchem Namen wir unser Gerät zuhause ansprechen wollen, also z.B. als "enigma2.heimnetz.org". Weil es sich aufgrund der ständig ändernden IP des Heimanschlusses auch nicht lohnt, das einem DNS dauerhaft mitzuteilen, nutzen wir DynDNS-Dienste, z.B. afraid.org, no-ip.com, DynDNS.org etc. pp.
   Dies erledigt zum Glück bei den meisten Benutzern auf Wunsch die Fritz!Box gleich mit, sobald sie eine Verbindung (neu) aufbaut, so daß man relativ problemlos dieses Ziel erreicht ...

C:\>nslookup ultimo.blah.com.
[...]
Nicht autorisierende Antwort:
Name:    ultimo.blah.com
Addresses:  2001:db8:fd23:842d:21d:ecff:fe02:5df6
176.198.12.15

   ... also daß sich unser gewünschter Name jederzeit zu der aktuellen IP unseres Receivers auflösen läßt.
   Bei IPv6 haben wir hier ein kleines Problem: Die Witz!Box stellt sich etwas störrisch, dazu später mehr ...
   Firewalls
   Windows und diverse Linux-Distributionen besitzen standardmäßig eine Firewall oder der Benutzer hat selber eine (oft sogar zusätzliche ;) ) installiert.
   Eine stinknormale "gute" Firewall macht folgendes: Sie reagiert auf allen Ports und läßt alle Pakete fallen, die darauf eingehen. Sie erfüllt damit eine enoooorm wichtige Aufgabe, denn genau das selbe hätte der TCP/IP-Stack auch so gemacht, wenn auf dem entsprechenden Port kein Dienst konfiguriert ist. Eine stinknormale schlechte Firewall antwortet mit Paketen nach der Devise "Du kummst hier net rein" und verrät damit einem potentiellen Angreifer
       daß es einen Rechner mit dieser Adresse gibt
       daß dieser Rechner auch läuft und freudig auf Angriffe wartet
       das verwendete Betriebssystem und damit, auf welche potentiellen Schwachstellen man sich als Angreifer konzentrieren kann
       die verwendete Firewall-Software und damit, auf welche zusätzlichen potentiellen Schwachstellen - die es ohne die zusätzliche Software gar nicht gäbe - man sich als Angreifer konzentrieren kann
   An dieser Stelle wird der berechtigte Benutzer eine entsprechende Ausnahme zum Firewall-Regelwerk definieren, die Zugriffe von außen auf den gewünschten Dienst ermöglicht, also ein Problem lösen, das er ohne die Firewall nicht hätte. Der unbedarfte Benutzer wird übrigens genauso gut jeder Schadsoftware den Zugriff vom bzw. auf das Internet ermöglichen, weshalb Fachleute auch nichts von "Personal Firewalls" (Das sind solche Firewalls, die direkt auf dem entsprechenden Rechner laufen) halten.
   Besser als eine Personal Firewall ist es allemal, den Rechner vernünftig zu konfigurieren, also Dienste, die nicht benötigt werden, ganz abzuschalten, statt sie offen zu lassen und dann nachträglich durch eine PFW "abzuschranken". Wenn auf einem Rechner eh nur das an Diensten läuft, was auch erreichbar sein soll, dann bringt eine PFW keine zusätzliche Sicherheit mehr (Durch das zusätzliche Stück Software sogar das Gegenteil), weil der Rechner eh nur da angreifbar ist, wo er auch antwortet, diese Dienste würde man in der Firewall aber eh öffnen.
   Ich will nicht so weit gehen, jedem zu empfehlen, den bremsenden Firewall-Kram auf dem PC zu deinstallieren, dafür können einfach zu wenige Normalnutzer einen PC sicher konfigurieren, aber alles, was über die standardmäßige Windows-Firewall hinausgeht ist reine Geldschneiderei. Merkt man auch schon an der nach Aufmerksamkeit heischenden, grellbunten, peppigen Aufmachung dieser ganzen "Security Suites".

   Ausdrücklich ausgenommen von dieser Kritik sind übrigens
       Die Firewall des Routers
       und/oder
       externe, dedizierte Firewalls (Also Geräte, deren Hauptaufgabe es ist, nachgeschaltete Geräte zu schützen)
       denn diese verhindern, daß unerwünschte Pakete überhaupt bis zum Angriffsziel kommen.

       Auf jeden Fall lautet die Lösung an dieser Stelle: Wenn wir von außen mit einem Dienst auf einem lokalen Rechner kommunizieren können wollen, dann müssen wir die dazugehörigen Ports auch in der/den Firewall(s) auf dem Weg dorthin freigeben.
   IPv4: Network Address Translation (NAT) oder IPv4-Adressmangel
   Wie schon erwähnt sind IPv4-basierte Privatkunden-Internet-Zugänge selten vollwertig. Dies äußert sich darin, daß man als Endkunde nicht genug IPv4-Adressen für alle Geräte bekommt, sondern nur eine einzige für das gesamte Netzwerk.
   Als Abhilfe werden die Geräte im lokalen Netzwerk in einem vom Internet getrennten Netz betrieben und mit privaten IPv4-Adressen versehen, meistens aus dem Bereich 192.168.x.y. Das einzige Gerät, das wirklich eine öffentliche IPv4-Adresse hat, ist der Router. Alle Geräte im Heimnetz können über das Hilfsmittel NAT von innen nach außen mit dem Internet kommunizieren. Dazu muß der Router bei jedem Zugriff nach außen Buch darüber führen, welcher Rechner jetzt welche Antworten erwartet, damit Rechner A aus unserem Beispiel von oben auch wirklich die Antwort von http://www.google.com erhält, die er wollte und nicht die, die zeitgleich das Notebook 1 oder das Smartphone 1 angefordert hat. Im Beispiel aus dem ersten Abschnitt heißt das, daß sich der Router in einem zwischen Schritt 3 und 4 einzufügenden Abschnitt merken muß, daß Rechner A (Der nun nicht mehr über eine öffentliche sondern nur über eine private IP verfügt) eine Anfrage an Rechner B rausgeschickt hat und in einem Zusatzschritt zwischen Schritt 6 und 7 rausklamüsern muß, daß das empfangene Antwortpaket zu dieser Anfrage gehört.
   Der hier beschrieben Vorgang ist letztlich etwas, das auch richtige Firewalls machen: Stateful Packet Inspection (SPI), also eine "zustandsbasierte Paket-Untersuchung". Basierend darauf, daß die eingehenden Pakete zu einer offenen Verbindung (Das ist der besagte "Zustand") gehören, werden sie durchgelassen, bei NAT werden die Pakete noch anhand der Tatsache zu welcher Verbindung sie gehören, an den passenden Rechner umgeleitet.
   All dies kostet übrigens richtig Rechenpower und ist der Grund dafür, daß gerade ältere Fritz!Boxen bei vielen gleichzeitigen Zugriffen so gerne abschmieren!

Für einen Zugriff von außen nach innen, müssen wir dem Router aber weitere Informationen geben.
Aus Sicht des Internets kommuniziert ein einziger Rechner mit dem Rest des Internets, nämlich unser Router: Jeder ausgehende Traffic wird dort auf unserer einen IP gebündelt und die Antworten werden a la Müllsortierung wieder den Maschinen im Netz zugeordnet, die darauf warten.
Eingehende Pakete kann der Router aber nicht nach dem Prinzip der Mülltrennung dem entsprechenden Rechner zuordnen, an den sie weitergeleitet werden sollen. Dazu müssen wir diesem einzigen wirklich mit dem Internet verbundenen Gerät mitteilen, welches Gerät im lokalen Heimnetz diese Anfragen beantworten soll. Dazu dienen Port-Weiterleitungen, die dem Router sagen "Wenn Du eine Anfrage auf Port xx empfängst, dann leite sie zur Beantwortung an Rechner C weiter, der sie auf Port yy beantwortet". Daß hierbei zwei Ports bzw. Portbereiche angegeben werden (müssen) hängt damit zusammen, daß der Router für jeden seiner Port natürlich nur eine einzige Regel haben kann und wir somit bei mehreren gleichen Diensten auf der Außenseite unterschiedliche Ports benutzen müssen.
Heißt also: Nur ein Webserver kann auf dem Standardport 80 antworten, alle anderen müssen extern auf nicht-standardisierte verbogen werden.
IPv4: CGN / Carrier Grade NAT
Nutzt zusätzlich auch der Provider NAT, dann CGN (Carrier Grade NAT) genannt, können wir eine wie im vorherigen Abschnitt beschriebene Port-Weiterleitung nicht einrichten, da wir keinen Zugriff auf den NAT-Router des Providers (Das AFTR-Gateway) haben.

   Die unseligen Punkte NAT und CGN können wir dank IPv6 mit seinen ausreichend großen Subnetzen zunehmend aus dem Gedächtnis streichen!
   IPv4 vs IPv6: Ein Kommunikationspartner verfügt nicht über IPv6-Konnektivität
   Selbst wenn ansonsten alle Probleme ausgeräumt sind, nutzt uns ein IPv6-angebundener Server samt IPv6-tauglichem Client nichts, wenn uns an dem Anschluß, von dem aus wir auf den Server zugreifen wollen, keine IPv6-Anbindung zur Verfügung steht.
   In einem weiteren Kapitel werde ich erklären, wie man diesem Problem ganz leicht Abhilfe schafft, wenn uns der Internet-Anbieter kein IPv6 zur Verfügung stellt.
   IPv4 vs IPv6: Ein Server bzw. Dienst ist nur für IPv4 programmiert
   Ein Client und ein Server können nur dann miteinander kommunizieren, wenn beide dieselbe Sprache sprechen, also entweder beide IPv4 oder beide IPv6.
   Im Idealfall sind Server heutzutage Dual-Stack-kompatibel, funktionieren also sowohl mit IPv4- als auch über IPv6-Clients.
   Da dieser Workshop den Hintergrund IPv6 hat und die Kommunikation über IPv4 in diesem Zusammenhang wegen DS-lite meist ausfällt, werde ich in späteren Kapiteln Wege aufzeigen, wie man einige solcher Serverdienste, die von sich aus nur IPv4 können, IPv6-tauglich macht.

Zusammenfassung: TCP/IP-Kommunikation erfolgt auf Grundlage der IP-Adressen der Teilnehmer sowie auf der Angabe eines Ports, der angibt, welcher Server-Dienst (HTTP, POP3, IRC, HTTPS, TeamSpeak, ....) erreicht werden soll. Grundsätzlich funktioniert diese Kommunikation unabhängig davon, ob IP-Adressen im Format IPv4 oder im Format IPv6 verwendet werden. Für die Kommunikation von "innen nach außen" sind keine weiteren Schritte nötig, diese funktioniert notfalls auch über NAT, da sich Antworten immer ihren zugehörigen Anfragen und damit dem darauf wartenden Rechner zuordnen lassen. Um selber einen Server/Dienst zu betreiben, genügt es prinzipiell, diesen zu installieren und ihn ggf. in zwischengeschalteten Firewalls zu öffnen.

   Bei Zugriff über IPv6 sind keine weiteren Maßnahmen nötig.
   An den üblichen eingeschränkten IPv4-Zugängen muß zusätzlich eine Port-Weiterleitung eingerichtet werden, da nur der Router eine echte Internet-Verbindung hat, i.d.R. aber ein Rechner im mit lediglich privaten IP-Adressen versehenen Heimnetz statt des Routers antworten soll.
   An IPv4-Zugängen mit CGN (Carrier Grade NAT) kann eine solche Port-Weiterleitung nicht eingerichtet werden.

In den folgenden Kapiteln werde ich mich damit befassen, wie man die o.g. Kommunikationshindernisse ausräumt.