Einführung in IPv6

• 1. Einleitung
• 2. Die Geschichte von IP(v6)
• 3. IPv6 Adressen und Adressvergabe
• 4. Adress-Autokonfiguration

In der Übergangszeit, in der IPv6 jedoch noch nicht überall vorhanden ist und auch noch nicht alle Programme und Plattformen die neue Version von IP unterstützen, ist es aber vielleicht sogar für Laien ganz nützlich und interessant zu wissen, worin die Unterschiede zwischen IPv6 und IPv4 bestehen, warum das Internet auf IPv6 umgestellt werden muss, was eigentlich passiert, wenn man "IPv6 auf einem Host einschaltet" und wie man danach IPv6 auch tatsächlich verwenden kann. Um diese Fragen zu klären, stellen wir drei Dokumente zur Verfügung, von denen dieses das erste ist. Es folgt ein Howto zum Installieren und Anschalten von IPv6 auf diversen Plattformen und anschließend ein Howto, welches auf die eigentliche Nutzung von IPv6 (wie man globale IPv6-Konnektivität bekommen kann, welche Programme bereits wie mit IPv6 eingesetzt werden können etc.) eingeht.

Seitenanfang

1.2 Vom ARPA-NET zum Internet und "Was ist eigentlich (IP-)Routing?"

AB

Man unterschied zwischen einem Backbone und Endbenutzer-Netzen. Endbenutzer-Netze können jeweils möglicherweise wieder so groß sind, dass sie über einen eigenen (kleineren) Backbone verfügten. Ein Backbone ist ein Netz von Geräten, so genannten Routern, die für nichts anderes da sind, als Datenpakete weiterzuleiten. Innerhalb eines Backbones gibt es keine Arbeitsplatzrechner oder Server. Diese sind in so genannten Blattnetzen lokalisiert. Der Vorteil einer solchen Netzstrukturierung ist, dass Computer in Blattnetzen nicht länger wissen müssen, wie alle anderen Knoten im Netz zu erreichen sind. Sie schicken alle Datenpakete zu einem Defaultrouter, der entsprechend seiner Lokalisation in der Hierarchie der Backbones mehr Informationen über die Standorte und Wege zu anderen Netzknoten weiß. Auch dieser Router kann in seinem Netz einen weiteren Defaultrouter haben, an den alle Pakete geschickt werden, über die er keine speziellen lokalen Informationen hat, die also nicht lokal zuzustellen sind. Diese Hierarchie setzt sich bis zu einem innersten Backbone (in Abbildung B blau dargestellt) fort, der so genannten DFZ (Default Free Zone), in der es dem Namen entsprechend keine Defaultrouter mehr gibt. (Router, die an diesem innersten und wichtigsten Backbone beteiligt sind, entscheiden für jedes bei ihnen ankommende Paket neu, zu welchem anderen Router es geschickt werden muss, um sein Ziel zu erreichen. Dabei brauchen diese Router, wie alle Router, aber tasächlich nur zu wissen, wohin das Paket als nächstes muss. Für die Entscheidung des weiteren Wegs, ist dann der nächste Router zuständig.)

1.3 Hierarchie, Topologie und was IP-Adressen damit zu tun haben

Ursprünglich hatte man den IPv4-Adress-Bereich in 3 Arten von Größen unterteilt, in so genannte Klasse-A-, -B- und -C-Netze. Diese Aufteilung klassifizierte Adressblöcke verschiedener Größen, die an Firmen und Einrichtungen vergeben wurden, die sich an das Internet anschließen wollten. Auf ihr beruht noch die heutige Notierung der 32-Bit langen IPv4-Adressen als eine Folge von vier durch Punkte getrennte Zahlen jeweils von 0-255.:

C

Abbildung C zeigt (sehr vereinfacht), wie die Routing Hierarchie in einem Teil des Internets aussehen kann.

1.4 Das Kernstück des Internets, die "DFZ"

Die Router der DFZ, die quasi das globale Internet darstellen, sind genau die, bei denen es mit IPv4 seit Jahren Probleme gibt, denn die größe der auf all diesen Routern vorhandenen "globalen" Routing-Tabelle ist auf ein viel größeres Maß angewachsen als jemals angedacht war. Ursprüglich sollten in der globalen Routing-Tabelle nur sehr "kurze" Präfixe (beispielsweise nur 8-16Bit-lang) auftauchen. Das ist gleichbedeutend damit, dass entsprechend alle Netze, die Adressen aus einem dieser sehr großen Adressbereiche haben, an genau einer Stelle (oder sehr wenigen Stellen) mit der DFZ verbunden sind. Alle kleineren Adressbereiche bzw. längeren Präfixe sollten entsprechend auf den entsprechenden Anschlussroutern der DFZ unter einem kürzeren 8-16bit langen Präfix zusammengefasst (aggregiert) werden. Damit hätte die golbale Routing Tabelle maximal auf etwa 65.000 Einträge anwachsen können. Tatsächlich aber sind wir heute bei einer Größe von 160.000 Eingrträgen, einer Zahl, die von Jahr zu Jahr um mehr als 10.000 Einträge anwächst (sie z.B. http://bgp.potaroo.net/). Der Grund dafür liegt darin, dass der vorhandene IPv4-Adressraum heutzutage wesentlich besser ausgenutzt werden muss, daher sind die an Organisationen und Firmen vergebenen Adressbereiche immer kleiner und damit die Präfixe immer länger geworden und ließen sich auf die Dauer einfach nicht mehr aggregieren. Um etwas flexibler zu sein hat man dafür Mitte der 90er Jahre auch die Klassen-basierte Einteilung von IP-Adressen aufgegeben und "Classless Inter-Domain Routing" (CIDR) eingeführt. Dadurch war man nicht länger auf die Präfixlängen /8, /16 und /24 (Klassen A, B, und C) beschränkt. Heute sind auch /30-Präfixe keine Seltenheit mehr, und da entsprechende Einschränkungen fehlten, hat man bis etwa 2001 sogar solch lange Präfixe in der globalen Routing Tabelle gesehen. Es ist leicht vorstellbar, wie viel größer damit diese Tabelle noch hätte werden können doch seit Mitte 2001 existiert wenigstens eine Richtlinie keine Präfixe zuzulassen, die länger sind als /24. Aber selbst damit sind theoretisch fast 17 Millionen Einträge möglich, eine Menge, die heute selbst die performantesten Router nicht mehr verwalten könnten. Diese Tabelle muss schließlich ständig auf dem Laufenden gehalten werden, und womöglich für jedes ankommende IP-Paket nach der passenden Route durchsucht werden.

1.5 Endlich IPv6...

Es sollte nun klar geworden sein, dass IPv4 für die Zukunft des Internets grundlegend ungeeignet ist, selbst ohne weitere Funktionalitäten zu berücksichtigen. Seit langem aber schon stellt man neben der einfachen Kommunikation zwischen Komponenten auf dem Internet auch noch weitere Anforderungen an das Internet Protokoll, die zum Beispiel die Sicherheit von Datenübertragungen betreffen. Dafür wurden komplizierte Zusatz-Protokolle (z.B. IPsec) und -Optionen entwickelt, die diesen Anforderungen gerecht werden sollten. Die Einfürung und Anwendung dieser Protokollerweiterungen war aber sehr schwierig, weil sie nur als optionale Zusätze zu IP, die zunächst überall integriert und implementiert werden mussten, entwickelt werden konnten. Die Müglichkeit zur Anwendung von z.B. IPsec wurde also nicht allein dadurch gegeben, dass man selber diese Funktionalität installiert und angeschaltet hatte, sondern auch der jeweilige Kommunikationspartner.

Es war also schon früh klar, dass IPv4 durch ein leistungsfähigerers Protokoll, welches die bei IPv4 mühsam hinzudefinierten Funktionen bereits integriert hat und außerdem die Adressierung einer weitaus größen Anzahl von Rechnern erlauben würde, ersetzt werden muss. So kam es, dass man bereits Anfang der 90er Jahre Vorschläge für solch ein neues Protokoll sah, die ab 1993 in der IETF (Internet Engeniering Task Force) unter dem Namen "IPnG" (IP next Generation) zusammengefasst wurden. Nach langen Diskussionen und vielen Vorschlägen wurde in den Jahren 1995 und 1996 der Standard für IPv6 erstmals als Draft veröffentlicht und später als Draft Standard (RFC 1883) verabschiedet. Neben der Integration von beispielsweise IPsec in IPv6 selbst, wurde die Größe der Adresse für einen Host von 32 auf 128 Bit erhöht. Theoretisch erlaubt die Läge dieser Adressen die Adressierung der unvorstellbar großen Anzahl von 3,4 x 10^38 Rechnern. Grob überschlagen gibt es also damit etwa 667 Milliarden Adressen pro Quadratmillimeter Erdoberfläche oder 6,5 x 10^28; Adressen pro Person. Wie schon bei IPv4 ist diese Art der Berechnung adressierbarer Hosts natürlich auf Grund von Hierarchisierung im Routing und der Tatsache, das Adressen nach wie vor in zusammenhängenden Blöcken verschiedener Größen vergeben werden, nicht zutreffend. Bei IPv6 hat man aber auch in dieser Hinsicht direkt Sorge getragen und festgelegt, dass alleröchstens 64 Bit dieser Adressen für das Routing verwendet werden dürfen, während für die Identifizierung eines einzelnen Hosts die hinteren 64 Bit zur Verfügung stehen.

2. The History of IP(v6)

Trotzdem kommt die Einführung des neuen Protokolls nicht so recht voran. Jeder wartet ab, dass andere den ersten Schritt machen. Die Provider zögern, weil durch die Umstellung in den meisten Fällen Kosten für neue IPv6-fäge Hardware und in jedem Fall die Schulung der Mitarbeiter entstehen. Außerdem ist ihrer Meinung nach die Nachfrage seitens der Kunden noch zu gering um diesen Aufwand zu rechtfertigen. Andererseits sind die Endkunden gerade die, die IPv6 am wenigsten vermissen, weil für sie das Protokoll IP idealerweise völlig unbedeutend und transparent ist.

Aus der Einstellung der Netzbetreiber heraus resultierte auch die schleppende Integration von IPv6 in die Produkte von Router- oder Softwareherstellern. Viele beschränkten sich lange darauf, Betaversionen mit IPv6 Support herauszugeben, scheuten sich aber davor, in kommerzielle Produkte zu investieren. Auch heute ist leider das vor allem für die Betreiber großer Backbones notwendige Hardware-Forwarding nur in den Produkten weniger Hersteller integriert. Das verschlechtert die Möglichkeiten für Provider, IPv6 einzusetzen, und bietet eine weitere aus ihrer Sicht durchaus gerechtfertigte Ausrede, den Einsatz von IPv6 noch hinauszuzögern.

Es gibt auch einige Leute, die vermuten, dass Dial-In-Provider zum Teil Bedenken haben, dass durch IPv6 und die damit verbundenen neuen Anwendungen den bisherigen leitungsvermittelten Diensten das Aus droht, weil sich Internetzugänge per Kabel oder Stromleitung durchsetzen könnten. Da für jeden Nutzer ausreichend IPv6 Adressen zur Verfügung stehen, wäre es sogar möglich, dass Internettelefonie die bisherigen Techniken vollkommen überflüssig macht.

Seitenanfang

3.1 Schreibweise von IPv6-Adressen

3.2 IPv6-Adressstruktur (Präfixe und "Netzmasken")

Netzmasken im Sinne von "255.255.255.0" bei IPv4 gibt es bei IPv6 nicht mehr. Hier wird nur noch die im Zuge von CIDR eingefürte Schreibweise <Adresse>/<Präfix-Länge> verwendet. Notierungen der folgenden Art

3.3 Globale Adressverteilung

2001:0000::/23 IANA (Jul 99)
2001:0200::/23 APNIC (Jul 99)
2001:0400::/23 ARIN (Jul 99)
2001:0600::/23 RIPE NCC (Jul 99)
2001:0800::/23 RIPE NCC (Mai 02)
2001:0A00::/23 RIPE NCC (Nov 02)
2001:0C00::/23 APNIC (Mai 02)
2001:0E00::/23 APNIC (Jan 03)
2001:1000::/23 noch nicht vergeben
2001:1200::/23 LACNIC (Nov 02)
2001:1400::/23 RIPE NCC (Feb 03)
2001:1600::/23 RIPE NCC (Jul 03)
2001:1800::/23 ARIN (Apr 03)
2001:1A00::/23 RIPE NCC (Jan 04)

3.4 Spezielle Adressen

::/128 "Unspecified Address"

Weitere spezielle Adressen und Adressbereiche sind:

::1/128 Loopback
ff00::/8 Multicast
fe80::/10 Link-Local Unicast
fec0::/10 Site-Local Unicast

Der Bereich "Site-local" ist nicht so eindeutig festgelegt, weil er weniger durch physicalische Gegebenheiten hergeleitet wird als durch administrative Umstände. Man sagt, dass eine Site der Bereich eines Netzes ist, der durch eine administrative Einheit gewartet/überwacht wird. Diese administrative Einheit ist dann auch dafür verantwortlich, die Access-Router, die ihre Site vom Rest des Netzes trennen, so zu konfigurieren, dass Pakte mit Site-Lokalen Quell- oder Zieladressen nicht nach außen geroutet werden. Site-Local Adressen können u. A. auch für Inselnetze verwendet werden, die keine Anbindung an das globale Internet haben und entsprechen in vieler Hinsicht den "privaten" IPv4-Adressen.

Achtung: Die IETF ist schon seit langem dabei, den "Site-local Scope" abzuschaffen (siehe draft-ietf-ipv6-deprecate-site-local-02.txt). Eine erneute Revision der "IPv6 Addressing Architecture" (RFC3513 wird es aber erst geben, wenn man sich einen Ersatz für diese Adressen ausgedacht hat, der die Verwendungszwecke "Insel-Systeme" und "private Adressen" abdeckt. Diese Diskussion ist noch in vollem Gang.

Seitenanfang

Um den Standard für DHCPv6 hat man lange Zeit diskutiert. Tatsächlich ist das RFC dazu erst im August 2003 erschienen. Dafür ist der Mechanismus DHCPv6 allerdings auch wesentlich mächtiger als das DHCP, was man für IPv4 kennt und ist neben der einfachen Zusweisung von IPv6-Adressen u.A. auch in der Lage temporäre Adressen zu vergeben oder Adressen von Nameservern und NTP-Servern zu verteilen. Näheres dazu kann man schon mal den Folien des Vortrags von Christian Strauf auf der 39. DFN Betriebstagung entnehmen. Sobald vorhanden, werden wir auch über erste praktische Erfahrungen mit DHCPv6-Implementierungen berichten.

Weil der Standard und damit auch die Implementationen von DHCPv6 so lange hat auf sich warten lassen, wird heute in der Regel entweder die so genannte stateless address autoconfiguration (SLAAC) eingesetzt, oder man verwendet keine Autokonfiguration und konfiguriert Adressen manuell¹. Während es sicher einige berechtigte Argumente gibt, die in manchen Fällen gegen SLAAC sprechen, ist sie doch die einfachste Art und Weise ein ganzes Netz mit IPv6 zu adressieren und zu betreiben. Wir werden daher im Folgenden näher auf diesen Mechanismus eingehen, weil sie für Anfänger das Mittel der Wahl ist. Ganz abgesehen davon, wird der erste Teil dieses Mechanismus auch im Falle der Benutzung von DHCPv6 oder manueller Konfiguration von jeder IPv6-Implementierung ausgeführt:

SLAAC wird in RFC2462 beschrieben. Zur Verwendung des Mechanismus werden weder spezielle Klienten noch Server benötigt, denn SLAAC gehört zum Standard IPv6 an sich. Jede Plattform, die IPv6 implementiert verfügt über die entsprechenden Funktionen, und auf einem Host sind zur Verwendung von SLAAC noch nicht einmal irgendwelche Konfigurationen dazu notwendig. Die Verwendung von SLAAC ist vorgegeben.

SLAAC erlaubt einem Host, sich selber mit IPv6-Adressen zu konfigurieren. Dazu braucht dieser nur einige Daten von sich selber sowie wenige Informationen, die der Router in Form von so genannten Router Ankündigungen (RAs) an alle Rechner auf einem Link (s.o.) geschickt werden. RAs beziehen sich jeweils auf den angeschlossenen angeschlossenen Link (= Subnetz/Layer2 Broacast Domänen). Sie enthalten unter anderem Informationen über die ersten 64Bit der Globalen IPv6-Adresse, mit der sich die Hosts in dem Subnetz konfigurieren sollen, das Routing-Präfix sowie die IPv6-Defaultroute für das Subnetz, die in der Regel auf den Router selbst zeigt.

Wenn ein Host gebootet bzw. das IPv6-Protokoll initialisiert wird, beginnt der SLAAC-Prozess. Dabei konfiguriert der Host zuerst link-lokale-Adressen für seine Interfaces, in dem er wie folgt aus seiner MAC-Adresse (EUI-48) eine EUI-64-ID erzeugt und diese an das Präfix für link-lokale Adressen (fe80::/10) anhängt:

Bis eine solche Link-Lokale Adresse aber tatsächlich einem Interface zugewiesen wird ist sie nur tentative, d.h. provisorisch, denn es muss noch überprüft werden, ob sie auf dem Link auch eindeutig ist. Der zugehöhrige Mechanismus nennt sich Duplicate Address Detection oder kurz DAD. Dabei sendet der Host (Host A) eine so genannte Neighbor Solicitation-Nachricht (NS) mit der eigenen link-lokalen Adresse als Ziel. Wenn ein anderer Hosts (Host B) diese Adresse bereits verwendet wird er darauf mit einem Neighbor Advertisement (NA) antworten. In diesem Fall bricht der komplette SLAAC-Prozess auf Host A ab und ein manueller Eingriff ist nötig. Falls keine Antwort zurück kommt, kann Host A davon ausgehen, dass seine link-lokale Adresse auf dem Link einzigartig ist und die Adresse fest auf das Interface konfigurieren. Ab diesem Zeitpunkt besteht bereits die Möglichkeit mit anderen Hosts auf dem gleichen Link über IPv6 zu kommunizieren. Dieser erste Teil der SLAAC wird immer auf allen IPv6-Netzwerkknoten ausgeführt, egal ob Host oder Router, oder ob im Folgenden DHCPv6 für die Konfiguration weiterer Adressen verwendet werden soll. Außer der eigenen MAC-Adresse wird dazu nichts weiter benötigt, nicht einmal die Verbindung zu einem echten LAN.

Die Folgenden Schritte werden (nur) auf Hosts durchgeführt. Die Konfiguration von Routern erfordert ab dieser Stelle durch manuelles Eingreifen oder die Benutzung spezieller Funktionalitäten von DHCPv6, die in diesem Dokument nicht weiter beschrieben werden sollen.

Nach der Konfiguration von link-lokalen Adressen für seine Interfaces versucht der Host zunächst herauszufinden, ob es einen Router auf dem Link gibt, der Router Ankündigungen (RA) verschickt. Wenn entsprechend konfiguriert, verschicken Router RAs automatisch in bestimmten Zeitabständen. In der Regel will man aber so lange nicht warten. Um schneller herauszufinden, ob ein Router präsent ist, verschickt der Host eine so genannte Router Solicitation (RS) an die Multicast-Gruppe Alle Router (auf dem Link) (ff02::2), auf die jeder Router hört. Der Router wird dann (falls vorhanden) speziell an den anfragenden Host, dessen link-lokale Adresse als Quelle in der RS-Nachricht angegeben war, ein RA schicken.

RAs enthalten zunächst zwei Flags, die dem anfragenden Host mitteilen, welche Informationen er möglicherweise über stateful addres autoconfiguration (DHCPv6) beziehen soll. Dabei wird mit den Flags zwischen den Informationen über die eigenen Adressen (1. Flag) und andere Informationen (2. Flag) unterschieden. Ein Host kann beispielsweise "andere Informationen", wie Nameserver, NTP-Server, etc., über den stateful Mechanismus beziehen, seine Adressen aber per SLAAC konfigurieren. Es ist auch möglich, Adressen über beide Arten der Autokonfiguration zu konfigurieren. Dazu enthalten die im RA (optional) ebenfalls enthaltenen Präfix-Informationen jeweils ein Flag, welches angibt, ob das entsprechende Präfix zur autonomen Adresskonfiguration verwendet werden soll, oder nicht. Die vom Router verschickten Präfixe betreffen die ersten 64 Bit der Adressen, mit denen sich die Hosts ggf. konfigurieren. Die letzten 64 Bit, die Host-ID, werden vom Host selber wie bei der link-lokalen Adresse generiert und an das vom Router verschickte Präfix (welches immer genau 64 Bit lang sein muss!²), angehängt:

IPv6-Adressen auf Interfaces haben immer eine (möglicherweise unbegrenzte) Lebensdauer. Dabei unterscheidet man weiter zwischen einer vorgezogene Lebensdauer und einer gültigen Lebensdauer, die entweder gleich oder länger als die vorgezogene Lebensdauer ist. Während der vorgezogenen Lebensdauer, wird die Adresse ganz normal benutzt, und auch neue Verbindungen können über diese Adresse aufgebaut werden. Ist die vorgezogene Lebensdauer abgelaufen und die gültige Lebensdauer länger als die Vorgezogene, kann die Adresse noch bis zum Ende der gültigen Lebensdauer verwendet werden, um bereits bestehende Verbindungen mit der Adresse aufrecht zu erhalten. Läuft auch die gültige Lebensdauer einer Adresse ab, und es gibt noch bestehende Verbindungen, die mit der Adresse aufgebaut wurden, brechen diese ab und die Adresse wir ganz vom Interface entfernt.

Router Ankündigungen werden vom Router in periodischen Abständen auf dem Link verschickt. Als Zieladresse benutzt der Router bei diesen unaufgeforderten RAs die Multicast-Adresse aller Netzerkknoten auf dem Link (ff02::1), auf die IPv6-Interfaces automatisch hören. Die eben erklärten Lebensdauern sind für die Adressen, die ein Host über SLAAC konfigurieren soll, ebenfalls in den RAs enthalten. Ein Host, der ein RA erhät, frischt seine Adressen entsprechend der mitgesendeten Lebensdauer jedes mal auf, so dass selbst bei kurzen Lebensdauern aber entsprechend häufigen RAs die Adressen trotzdem nie ablaufen.

Die Möglichkeit zur Konfiguration (theoretisch) beliebig vieler IPv6-Adressen auf einem Interface sowie das Prinzip der verschiedenen Arten von Adress-Lebensdauern wurde bei IPv6 eingeführt um die automatische Re-Nummerierung eines Netzes zu vereinfachen. Will man per SLAAC ein Subnetz mit IPv6-Adressen eines neuen Präfixes re-nummerieren, löscht man es einfach aus den Router-Ankündigungen. Das hat zur Folge, dass die Lebensdauern der Adressen, die sich Hosts auf dem Netz mit diesem Präfix gegeben haben, irgendwann ablaufen, weil sie nicht mehr aufgefrischt werden. Gleichzeitig fügt man das neue Präfix in die Router-Ankündigungen ein, so das sich alle Rechner schon mal zusätzlich zur alten Adresse mit der neuen Adresse konfigurieren. Entsprechend der für das alte Präfix gesetzten bevorzugten und gültigen Lebensdauern wird die alte Adresse bald nicht mehr für neue Verbindungen genutzt und später überall ganz gelöscht. Dieser Mechanismus erlaubt eine weitestgehend reibungslose Re-Nummerierung eines Netzes, für die lediglich auf dem Router einige kleine Aänderungen vorgenommen werden müssen³.

Auch vor der endgültingen Zuweisung von globalen oder Site-lokalen Adressen an Interfaces führt der Host für jede Adresse zur Sicherheit ein DAD aus. Das gilt sowohl führ stateful autoconfiguration als auch für den stateless Mechanismus und manuelle Konfiguration von Adressen, wobei im zweiten Fall die Eindeutigkeit der aus der MAC-Adresse erzeugten Host-IDs auf dem Link zu diesem Zeitpunkt in der Regel gegeben ist. Da Präfixe in Router-Ankündigungen aus Routing-Gründen in der entsprechenden Scope (Site-lokal oder global) eindeutig sein müssen, muss bei dem SLAAC-Mechanismus diese Überprüfung eigentlich nicht mehr stattfinden.

¹Tatsächlich wird ein Teil der SLAAC immer ausgeführt, sogar dann, wenn man DHCPv6 verwendet, denn das Zuweisen von link-lokale Adressen an die Interfaces eines Rechners gehört zu diesem Prozess und wird damit bei der Initialisierung des IPv6-Protokolls auf jedem Host ausgeführt. Wenn man sagt, dass man SLAAC nicht verwendet, ist damit in der Regel nur gemeint, dass man über diesen Mechanismus keine globalen IPv6-Adressen oder weitere Informationen zuweist.

²Ein kürzeres Präfix ist theoretisch für Router-Ankündigungen denkbar, macht aber nicht viel Sinn und kommt daher in der Praxis auch nicht vor. In jedem Fall verwendet der Host die ersten 64 Bit (nicht mehr und nicht weniger) für die eigenen Adressen. ³Der Vorgang der Re-Nummerierung kann beschleunigt werden, wenn zuvor die Lebensdauern in den Router-Anköndigungen für das alte Präfix verkürzt werden, bevor es ganz gelöscht wird. Die bevorzugte Lebensdauer kann man sogar ganz auf Null setzen, wodurch die Adressen mit eintreffen der RAs auf den Hosts sofort nicht mehr für neue Verbindungen genutzt werden können. Man sollte allerdings darauf achten, die gültige Lebensdauer nie zu kurz zu wählen, um keine ungewollten Störungen in noch bestehenden Verbindungen zu verursachen. Gültige Lebensdauern sind in der Regel immer mindestens einen Tag länger als bevorzugte Lebensdauer.

Seitenanfang