Martin Mauve Universität Mannheim 1
7. IPv6
seit 1992 wird über eine Nachfolge Version von IP(v4) nachgedacht
Deering and Hinden. Internet Protocol Version 6 (IPv6) Specification, RFC 2460, 1998.
es gibt bereits einige „virtuelle“ Netze, die IPv6 verwenden wichtigste Vorteile:
erweiterte Adressierungsmöglichkeiten Vereinfachung des Headers verbesserte Unterstützung für Optionen und Erweiterung Kennzeichnung von Flüssen (flows) die auf besondere Art behandelt
werden sollen Optionen für die Authentifikation und Verschlüsselung von Paketen
Martin Mauve Universität Mannheim 2
IPv4 Header
identification
time to live
source IP address
version total lengthtype of service
destination IP address
header checksum
data
hlength
0 7 15 31
flags fragment offset
protocol
options (if any)
Martin Mauve Universität Mannheim 3
IPv6 Header
payload length next header
source IP address (128 bit)
version flow labeltraffic class
0 7 15 31
hop limit
destination IP address (128 bit)
data
extension headers (if any)
Martin Mauve Universität Mannheim 4
IPv6 Header Vereinfachungen
Festes Format für den Header, keine Optionalen Elemente. Optionen werden in Form von Extension Headern an den IPv6 Header angehängt. Dies vereinfacht das Parsen von Paketen (soll in Hardware möglich sein).
Header Checksumme wurde entfernt, da der Schutz meist bereits auf Schicht 2 geleistet wird. Dadurch vermindert sich die Komplexität in den Routern.
Fragmentierung im Inneren des Netzes wurde entfernt. Nun kann Fragmentierung nur von Endsystemen durchgeführt werden. Dies erfordert Path-MTU discovery, oder die Verwendung von kleinen Paketen (minimale Path-MTU in IPv6 Netzen ist 1280 Bytes).
Martin Mauve Universität Mannheim 5
IPv6 Header - Klassische Felder
payload length (statt total length): die Größe des IP Paketes ohne den 40 Byte IPv6 Header
next header (statt protocol type): der auf den IPv6 Header folgende Header (z.B. ein spezieller extension header oder TCP)
hop limit (statt time-to-live): hier wird im Namen die tatsächliche Funktion des Feldes berücksichtigt
Martin Mauve Universität Mannheim 6
IPv6 Neue Felder
flow label: dient zur Identifikation von Flüssen mit besonderen Anforderungen - dies ist noch nicht vollständig für IPv6 spezifiziert
class: dieses Feld dient der Priorisierung von IP Paketen, auch hier wird noch experimentiert!
Martin Mauve Universität Mannheim 7
IPv6 Extension Headers
die Extension Headers ersetzen die Options von IPv4
die Extension Header folgen auf den IP header:
IPv6 Headernext header=
Routing
Routing Headernext header=
Fragment
Fragment Headernext header=
TCP
FragmentTCP
Martin Mauve Universität Mannheim 8
IPv6 Extension Headers: Routing Header
reserved
routing type=0
address1 (128 bit)
next header hdr. ext. length
0 7 15 31
segments left
more addresses
Martin Mauve Universität Mannheim 9
IPv6 Extension Headers: Routing Header
next header: welcher Header kommt als nächstes (weiterer extension Header? TCP?)
hdr. ext. length: wie groß ist dieser extension header in 64 bit Vielfachen, ohne die ersten 64 bit
routing type: zur Zeit immer 0
segments left: an welcher Position befinden wir uns, d.h. welche Adresse ist als nächstes an der Reihe
die Adressen von den Systemen, die durchlaufen werden sollen, der letzte Eintrag ist der des Zielsystems an dem das Paket ankommen soll
Martin Mauve Universität Mannheim 10
Routing Header - Behandlung
In einem System wird der Routing Header nur betrachtet, wenn die IP Adresse dieses Systems als Empfängeradresse im IP Header steht.
Gibt es keine weiteren Einträge im Routing Header (die Liste ist abgearbeitet) so ist das Paket am endgültigen Ziel angekommen.
Falls weitere Einträge vorhanden sind wird die Zieladresse im IP Header durch den nächsten Eintrag ersetzt und das Paket wird an diese Adresse geschickt.
Martin Mauve Universität Mannheim 11
IPv6 Extension Headers: Fragmentation Header
fragment offset: Position des Fragmentes identification: identifiziert das Paket zu dem das
Fragment gehört M: more fragments: 0 für das letzte Fragment eines
Paketes, sonst 1 IPv6 Fragmentierung wird ausschließlich von
Endsystemen durchgeführt, d.h. Pakete die zu groß sind werden von Router automatisch so behandelt als wäre ein don’t fragment bit gesetzt.
identification
fragment offsetnext header reserved
0 7 15 31
Mres
Martin Mauve Universität Mannheim 12
Weitere IPv6 Extension Header
Destination Options Header: für die Übermittlung von Optionen vom Sender zum Empfänger. Bislang weitestgehend ungenutzt.
Hop-by-Hop Options Header: für die Übermittlung von Optionen von einem Knoten zum Nachbarknoten des Netzes. Ebenfalls weitestgehend ungenutzt.
Authentication Header: für die Authentifizierung von Paketen. Werden wir später genauer diskutieren.
Martin Mauve Universität Mannheim 13
ICMPv6 für IPv6
A. Conta, S. Deering. Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification. RFC 2463. 1998.
nicht länger benötigte Elemente wurden in ICMPv6 weggelassen
das Mitgliedschaftsprotokoll für Multicast (IGMP) wurde in ICMPv6 mit aufgenommen
die Pakete wurden an die neue Adressgröße angepasst
Martin Mauve Universität Mannheim 14
ICMPv6 - Paketformat
type: ICMP Nachrichtentyp
code: Unterteilung der Typen
checksum: über eine pseudo IPv6 Header und das gesamte ICMP Paket
message body
code
IPv6 header
type
0 7 15 31
checksum
Martin Mauve Universität Mannheim 15
ICMP Nachrichten Typen
Errors: 1: Destination Unreachable 2: Packet Too Big 3: Time Exceeded 4: Parameter Problem
Echo: 128: Echo Request 129 Echo Reply
Multicast Gruppenmitgliedschaft (130-132)
Autokonfiguration (133-137)
Martin Mauve Universität Mannheim 16
ICMPv6 Errors
parameter
code
IPv6 header
type={1,2,3,4}
0 7 15 31
checksum
verursachendes Paket (maximale Gesamtgröße des ICMPPaketes ist 576 inklusive aller Header, dann wird das Paket abgeschnitten)
Martin Mauve Universität Mannheim 17
ICMPv6 Errors
Destination Unreachable: no route to destination communication with destination administratetively prohibited address unreachable port unreachable
Packet Too Big Time Exceeded
hop limit exceeded in transit fragment reassembly time exceeded
Parameter Problem erroneous header field unrecognized next header type unrecognized IPv6 option
Martin Mauve Universität Mannheim 18
Auswirkungen auf Höhere Schichten
Neuer Pseudoheader für die Berechnung der Checksummen (ICMP, TCP, UDP, ....)
payload length
next header
source IP address (128 bit)
flow label
0 7 15 31
destination IP address (128 bit)
beim next Header Feld werden alle extension Header ignoriert, hier steht also die ID für TCP/UDP/ICMP, etc.
Martin Mauve Universität Mannheim 19
Auswirkung auf Höhere Schichten
Domain Name Service: neuer resource record: AAAA (code 28) für 128-bit IPv6
Adressen für pointer-queries gibt es einen neuen top-level Knoten:
IP6.INT (äquivalent zu in-addr.arpa) für pointer queries wird die numerische IPv6 Adresse in
eine Sequenz hexadezimaler Stellen zerlegt (je 4 bit), da es keine natürlichen Grenzen wie bei IPv4 gibt
Martin Mauve Universität Mannheim 20
IPv6 Designentscheidungen
Header Felder werden so definiert, dass jeder Wert sinnvoll ist
Beispiel: payload-length in IPv6 gibt an wie groß der Payload ist, alle
Werte sind gültig (auch 0 für keinen Payload) in IPv4 gibt das total length Feld die Größe des ganzen
Paketes an, d.h. inklusive header. Daher sind Werte kleiner als 20 ungültig
Vorteile des neuen Design: eine Verzweigung weniger im Programmcode, daher besser
für Pipelining und Optimierungen geeignet weniger Komplexität und daher weniger
Fehlermöglichkeiten
Martin Mauve Universität Mannheim 21
IPv6 Designentscheidungen
jedes Header Feld so klein wie möglich halten z.B. hop-limit kann maximal 255 sein, dies ist kontrovers
diskutiert worden! z.B. Pakete können nur 64kbyte groß sein, auch dies ist
kontrovers diskutiert worden (es gibt einen extension Header der größere Pakete ermöglicht)
Vorteil dieses Vorgehens: der Header bleibt klein und verursacht keinen übermäßigen Overhead
die einzige Ausnahme sind die Adressen, die als Kompromiss auf 128 bit ausgelegt wurden, obwohl wohl auch 64 bit gereicht hätten
Martin Mauve Universität Mannheim 22
IPv6 Designentscheidungen
Minimierung von redundanter Funktionalität: Funktionalität die an anderer Stelle des Protokollstacks durchgeführt werde sollte in IPv6 nicht verdoppelt werden Beispiel: es gibt keine Checksumme mehr für den IPv6
Header• dies beschleunigt die Handhabung von Paketen in Routern
• wird möglich, da i.d.R. auf Schicht 2 bereits eine Fehlererkennung durchgeführt wird
• auch sichern nahezu alle Schicht 4 Protokolle den IPv6 Header mit Hilfe eines pseudo Headers in ihrer Checksumme
Dieses Vorgehen verschlankt den Protokollstack und beschleunigt die Bearbeitung von Paketen
Martin Mauve Universität Mannheim 23
IPv6 Adressierung - Adressgröße
Man ging 1991 davon aus, daß im Jahr 2000 alle 10 Milliarden Menschen auf der Erde eine Internetadresse benötigen
Dann hat man weiter nachgedacht und ist zu der Annahme gekommen daß jeder Mensch mehrere IP-Adressen benötigt (eine für sein Auto, eine für seinen Kühlschrank, eine für jede Glühbirne, etc.). Daraufhin ging man von 100 Internet Adresse pro Mensch aus, d.h. 1 Billion Adressen = 10 hoch 12.
Dann wollte man nicht auf einen Sicherheitspuffer verzichten und hat IPv6 Adressen so gestaltet, daß 10 hoch 15 Endgeräte über 10 hoch 12 Sub-Netze verbunden werden können.
Martin Mauve Universität Mannheim 24
IPv6 Adressierung
ein System in IPv6 kann wie in IPv4 mehrere IP Adressen besitzen (z.B. wenn es an mehrere Sub-Netzte angeschlossen ist
es gibt drei Kategorien der Adressierung: unicast für Punkt zu Punkt Verbindungen multicast für die Adressierung von Empfängergruppen anycast zur Adressierung einer Gruppe aus welcher genau
ein System das Paket erhält
Martin Mauve Universität Mannheim 25
IPv6 Adressierung
Notation von IPv6 Adressen: FEDC:BA98:7654:3210:FEDC:BA98:7654:3210 Unsignifikante 0en dürfen in jeder einzelnen 16 Bit Einheit
weggelassen werden 0012 wir also zu 12 eine Kette von Einheiten, die 0 sind darf mittels ::
zusammengefasst werden:• 1080:0:0:0:8:800:200C:417A wird zu• 1080::8:800:200C:417A• nur ein :: ist erlaubt• beim Expandieren werden an die Stelle von :: so viele 0
Einheiten eingefügt, bis die Adresse wieder die richtige Länge hat
IPv4 Adressen sind ein Sub-Set von IPv6 Adressen, bei denen die ersten 96 bit null sind, sie werden wie folgt geschrieben:
• ::134.155.48.96
Martin Mauve Universität Mannheim 26
IPv6 Adressierung
Präfixe in IPv6: werden wie in IPv4 (Net-ID, Sub-Net ID) für das Routing
benötigt haben variable Länge werden mit folgender Notation bezeichnet:
• FEDC:BA98:7600::/40
• die unsignifikanten Bits eines Präfix sollten auf 0 gesetzt und mit :: abgekürzt werden
Martin Mauve Universität Mannheim 27
IPv6 Adressierung
der IPv6 Adressraum wird wir folgt aufgeteilt: Präfix 0000 0001: Reserved for NSAP Allocation Präfix 0000 001: Reserved for IPX Allocation Präfix 010: Aggregatable Global Unicast Addresses Präfix 100: Reserved for Geographic-based Unicast Addresses Präfix 1111 1110 10: Link Local Use Addresses Präfix 1111 1110 11: Site Local Use Addresses Präfix 1111 1111: Multicast Addresses der Rest des Adressraumes steht noch zur Verfügung (>70%)
um weitere Adresstypen zu ermöglichen
Martin Mauve Universität Mannheim 28
Aggregatable Global Unicast Addresses
man hat in IPv4 (schmerzhaft) gelernt, wie wichtig es ist Adressen aggregieren zu können (s. CIDR) um eine Explosion der Routing Tabellen zu vermeiden
daher werden in IPv6 die „normalen“ unicast Adressen so aufgebaut, daß sie gut aggregierbar sind:
001 TLA 13 Bit NLA 32 Bit SLA 16 Bit Interface IP 64 Bit
TLA: Top Level Aggregator
NLA: Next Level Aggregator
SLA: Site Local Aggregator
Interface: Identifikation des Interfaces eines Rechners
Martin Mauve Universität Mannheim 29
Aggregatable Global Unicast Addresses
Top Level Aggregator: Dies sind die Knoten in der default-freien Zone, im
Backbone des Internet, in welchem die Router keinen default Eintrag in der Routing Tabelle haben dürfen.
Insbesondere ist jeder TLA in jeder Routing Tabelle in der default-freien Zone vorhanden.
Daher gibt es auch nur maximal 8192 TLAs. TLAs werden i.d.R. nach einer Kombination von großen
Providern und regionalen Gesichtspunkten zugeordnet, z.B. könnte T-Online in Europa (fiktives Beispiel!) eine TLA IP erhalten.
Ein TLA kann auch einfach ein Konten in der default-freien Zone sein, an dem mehrere Netzwerke miteinander Verbunden sind.
Martin Mauve Universität Mannheim 30
Aggregatable Global Unicast Addresses
Next Level Aggregator: Hier kann die Verantwortlichkeit weiter delegiert werden,
z.B. T-Online Deutschland, etc. Die 32 Bit können nach Belieben weiter aufgeteilt werden
um weitere Hierarchiebenen für die Aggregation zu schaffen.
So könnten die ersten 16 Bit genutzt werden um für T-Online in Europa nach Ländern zu unterscheiden und dann die nächsten 16 Bit um in den Ländern nach Regionen zu unterscheiden.
Martin Mauve Universität Mannheim 31
Aggregatable Global Unicast Addresses
Site Local Aggregator und Interface ID: Site Local Aggregator IDs bezeichnen i.d.R. Links einer
Site, also z.B. das Ethernet für L15,16. Eine Interface ID bezeichnet ein Netzwerkinterface eines
Rechners, diese ID kann z.B. aus der ID der Ethernetkarte gewonnen werden, in dem 16 null Bits an geeigneter Position eingefügt werden.
Site Local Aggregator IDs und die Interface IDs sind unabhängig vom Rest der IP Adresse, wird z.B. der Provider gewechselt, bleiben SLA ID und Interface ID konstant.
Martin Mauve Universität Mannheim 32
Spezialadressen
unspecified address (16 null Bytes): als Absendeadresse einer Station die noch nicht eingerichtet wurde. Wird auch als Platzhalter verwendet wenn eine Adresse benötigt wird, aber keine da ist
loopback address (0:0:0:0:0:0:0:1)
IPv4 address (::u.v.w.x)
site local address (1111 1110 11/10): Adressen die nur innerhalb einer Site verwendet werden und nie ins Internet geroutet werden. Normalerweise wählt man die Adressen so, daß die letzten 80 Bit wie bei einer aggregatable global unicast address zugeordnet werden (SLA + Interface ID). Dann kann man später die Systeme schnell ins Internet einbinden.
Martin Mauve Universität Mannheim 33
Spezialadressen
link local addresses (1111 1110 10): diese Adressen sind nur auf einem Sub-Netz gültig und werden nie von Routern Weitergeleitet. Man strukturiert sie so, daß die letzten 64 bit die Interface ID beinhalten um die Adresse schnell in eine Aggregatable Global Unicast Address umwandeln zu können
Martin Mauve Universität Mannheim 34
IPv6 Exterior Gateway Routing
entweder mit BGP-4 (+IPv6 Erweiterung hierzu), oder mit dem ISO (ISO Standard 10747) Inter-
Domain Routing Protocol (IDRP) Hauptunterschiede BGP-4/IDRP:
BGP tauscht Nachrichten über TCP aus, IDRP direkt über IPv6
BGP ist für das Routen einer Adressfamilie gedacht (z.B. IPv4 oder IPv6) während IDRP für mehrere Adressfamilien gleichzeitig verwendet werden kann
BGP benutzt Autonome System IDs, IDRP identifiziert domains anhand von Adresspräfixen variabler Länge
Martin Mauve Universität Mannheim 35
Unterschiede BGP-4 vs. IDRP
TCP vs. kein TCP BGP wählte TCP, da dies das Protokoll vereinfacht aber, wenn eine Nachricht verloren geht, dann sorgt TCP
für eine Übertragungswiederholung, diese kann aufgrund von congestion control erheblich verzögert werden
während dieser Verzögerungszeit kann sich die Routing Information bereits wieder geändert haben und eine Übertragungswiederholung daher sinnlos sein
IDRP stellt daher die Zuverlässige Übertragung von Nachrichten selber sicher und ist somit effizienter aber auch komplexer
Martin Mauve Universität Mannheim 36
Unterschiede BGP-4 vs. IDRP
Adressformat: in BGP-4: length (1 Byte) + prefix (variabel) in IDRP: address family (2 Byte) + address length (2 Byte) +
address information (variabel)• address information: length (1 Byte) + Prefix (variabel)
durch dieses Format ist IDRP für mehrere Adressfamilien gleichzeitig verwendbar
Martin Mauve Universität Mannheim 37
Unterschiede BGP-4 vs. IDRP
Autonome System ID vs. Präfix variabler Länge
in BGP werden Autonome System IDs verwendet um zu identifizieren, durch welche Netze eine Route führt, dies wird benötigt um Schleifen zu vermeiden und politisches Routing zu ermöglichen
bei IDRP wird statt einer Autonomen System ID ein variabler Adresspräfix verwendet (z.B. FEDC::/16)
• da die Autonome Systeme ID auf 16 Bit beschränkt ist, kann ein BGP-4 Engpass entstehen, dies ist in IDRP nicht der Fall
• Autonome System IDs müssen von der IANA explizit vergeben werden, Adresspräfixe sind durch die IPv6 Adressen bereits bekannt
• bei der Aggregation von Routen in BGP müssen die IDs aller Autonomen Systeme mitübertragen werden, dies kann zu einem signifikanten Overhead führen, bei IDRP ist dies nicht notwendig, da die Adresspräfixe sich in natürlicher Weise aggregieren lassen
Martin Mauve Universität Mannheim 38
IDRP – Beispiel (Frei Erfunden!)
T-Online EuropeTLA-ID: FPräfix: 200F::/16
T-Online DeutschlandNLA-ID (1. Hälfte/16 Bit): 10Präfix: 200F:10::/32
Startup GMBHNLA-ID (2. Hälfte/16 Bit): FF00Präfix: 200F:10:FF00::/48
T-Online FrankreichNLA-ID (1. Hälfte/8 Bit): 10Präfix: 200F:1000::/24
Central African ExchangeTLA-ID: FEPräfix: 20FE::/16hier können weitere
Router dazwischen liegen
Router der default freien Zone. RoutingEinträge zu 20FE::/16,200F:10::/32 und200F:1000::/24
Router der untersten Ebene. Routing Einträge zu allenSub-Netzen in 20FE:10:FF00::/48,und eine default Route zu T-Online
Martin Mauve Universität Mannheim 39
IPv6 Interior Gateway Routing
OSPF für IPv6 eigene link state Datenbank für IPv6 (wird nicht kombiniert
mit der von IPv4, wenn eine vorhanden ist) Adressfelder werden auf die 128 bit Adressen von IPv6
angepasst
RIP für IPv6 Adressfelder werden auf die 128 bit Adressen von IPv6
angepasst ansonsten analog zu RIP-2
Martin Mauve Universität Mannheim 40
IPv6 Plug and Play
Autokonfiguration Adressvergabe
Adressauflösung und Nachbarerkennung Abbilden der Schicht 2 Adresse auf eine IPv6 Adresse und
umgekehrt Automatisiertes Erkennen von Routern Optimieren der Route von einem Endsystem zum ersten
Router
Martin Mauve Universität Mannheim 41
IPv6 Autokonfiguration
Autokonfiguration: Automatische Vergabe von Adressen Automatisierte Eintragung ins DNS
IPv6 soll auch von nicht-Spezialisten verwendet werden, z.B. um ein Heimnetz aufzubauen, es sollte daher möglichst automatisierbar sein.
Durch Provider-abhängige Adressen ist es notwendig, dass eine eine Renumerierung automatisiert vorgenommen werden kann.
Autokonfiguration wird in IPv6 mit Hilfe von ICMPv6 realisiert
Martin Mauve Universität Mannheim 42
Bestimmung einer Link Local Address
Sobald ein Interface initialisiert ist kann ein Host eine Link Local Address für dieses Interface bestimmen.
Dazu wird der wohlbekannte Präfix für Link Local Adresses (FE80:0:0:0/64) um ein ein eindeutiges 64-Bit Token erweitert welches i.d.R. aus der Schicht 2 Adresse der Netzwerkkarte abgeleitet wird.
Das Token kann auch auf andere Weise erstellt werden, solange „garantiert“ ist, daß es in dem Subnetz eindeutig ist.
Zum Beispiel kann eines zufällig ausgewählt werden, da eine Kollision so unwahrscheinlich ist gilt dies als „garantiert“. (sehr interessante Einstellung!!!).
Link Local Addresses lösen das Problem von autonomen Netzen, die nicht an das Internet angeschlossen werden sollen und die nur aus einem Sub-Netz bestehen. Für alle anderen Netze müssen weitere Schritte erfolgen.
Martin Mauve Universität Mannheim 43
Autokonfiguration
Zustandslos: die Adressen werden von den Endsystemen selbst konstruiert, mit Hilfe von Informationen die sie von einem der direkt am selben Sub-Netz angeschlossenen Router erhalten.
Zustandsbehaftet: die Adressen werden von einem zentralen Server vergeben. Dies nennt man zustandsbehaftet, da der Server einen Zustand halten muss (z.B., welche Adressen er bereits vergeben hat)
Martin Mauve Universität Mannheim 44
Zustandslose Autokonfiguration
Eine Solicitation Nachricht wird auf die All Routers Multicast Gruppe (FF02::2) geschickt. Dabei wird die eigene Link Local Adress als Absender verwendet. Außerdem beinhaltet die Solicitation Nachricht die Schicht 2 Adresse des Absenders.
Als Antwort schicken die Router auf diesem Subnetz eine Router Advertisement Nachricht. Diese beinhaltet die folgenden Informationen: Managed Address Configuration Bit: 0 wenn Stationen
zustandslose Autokonfiguration vornehmen dürfen, 1 wenn ein Server für Zustandsbehaftete Autokonfiguration kontaktiert werden muss (s. später).
Other Configuration Bit: 0 wenn bei der zustandslosen Autokonfiguration ein Server für Parameter angefragt werden muss, 1 wenn diese Informationen an diese Nachricht angehängt sind
Prefix Information Option: der Präfix mit dem aus dem Token eine global gültige IPv6 Adresse wird.
Martin Mauve Universität Mannheim 45
Zustandslose Autokonfiguration
Adressen haben nur eine beschränkte Lebensdauer, diese wird in der Router Advertisement Nachricht mitübertragen: Valid Lifetime: nach dieser Zeit darf die Adresse nicht mehr
verwendet werden. Preferred Lifetime (<Valid Lifetime): nach dieser Zeit sollte die
Adresse nicht mehr für den Aufbau von Verbindungen verwendet werden.
Router Advertisement Nachrichten werden periodisch auf der All Nodes Multicast Gruppe übertragen und frischen damit die beiden Werte wieder auf. Einen Timeout gibt es nur wenn der Präfix tatsächlich geändert wurde.
Entdecken von Duplikaten: da man nie ausschließen kann, dass das selbe Token zweimal in einem Subnetz vorkommt (Konfigurationsfehler) wird nach der zustandslosen Autokonfiguration eine spezielle Nachricht an die neue Adresse geschickt, kommt nach einer Sekunde keine Antwort gilt die neue Adresse als gültig.
Martin Mauve Universität Mannheim 46
Zustandsbehaftete Autokonfiguration
Die zustandsbehaftete Autokonfiguration von IPv6 erfolgt mit Hilfe einer IPv6 Version des Dynamic Host Configuration Protocol (DHCP). Dieses gibt es auch für IPv4.
Probleme: Wie lernt man als DHCP Client die Adresse eines DHCP
Servers? Wie kann man mit diesem kommunizieren, obwohl man
noch keine gültige Adresse hat? Wie werden diese beiden Probleme gelöst, wenn es nur
einen zentralen DHCP Server für eine Site geben soll?
Martin Mauve Universität Mannheim 47
DHCP für IPv6
Der erste Schritt ist das Suchen nach einem DHCP Server.
Dazu wird auf die all DHCP Servers multicast Adresse (FF02::1:2) eine Solicitation Nachricht verschickt: Protokoll: UDP. Absenderadresse: die Link Local Address des Absenders. Diese Link-Local Address steht auch noch einmal in der
Solicitation Nachricht selber.
Martin Mauve Universität Mannheim 48
DHCP für IPv6
Damit nicht in jedem Sub-Netzwerk ein DHCP Server vorhanden sein muss gibt es in jedem Sub-Netz ohne DHCP Server sogenannte DHCP Relay Agents (kurz DHCP Relays). Diese sind notwendig, da die Link Local Address des
Absenders einer Solicitation Nachricht nur in diesen einen Subnetz gültig ist.
Wenn in einem Sub-Netz keine DHCP Server sondern nur ein DHCP Relay vorhanden ist, dann leitet das DHCP Relay die Solicitation Nachricht an einen DHCP Server weiter. Bei der weitergeleiteten Nachricht ist nun das DHCP Relay der Absender. Zusätzlich trägt das DHCP Relay seine Adresse in die Nachricht ein.
Martin Mauve Universität Mannheim 49
DHCP für IPv6
Ein DHCP Server antwortet auf eine Solicitation Nachricht mit einer Advertise Nachricht.
Diese beinhaltet die Adressen des Servers und – sofern vorhanden – des DHCP Relays. Weiterhin können bereits erste Konfigurationsparameter in der Advertise Nachricht enthalten sein.
Wenn ein DHCP Relay involviert ist wird die Advertise Nachricht an das Relay geschickt, welches es dann an den DHCP Client im eigenen Sub-Netz weiterleitet. Ansonsten befinden sich DHCP Client und Server im selben Sub-Netz und der Server kann dem Client direkt antworten
Der DHCP Client wählt unter allen Advertise Nachrichten einen Server (und, falls notwendig ein DHCP Relay) aus, den er für seine Autokonfiguration verwenden möchte. Alle anderen werden ignoriert.
Martin Mauve Universität Mannheim 50
DHCP für IPv6
Der Client fragt von dem ausgewählten Server die Autokonfigurationsdaten mit Hilfe einer Request Nachricht nach.
Request Nachrichten werden direkt an den Server/DHCP Relay geschickt und nicht per multicast versandt.
Die Request Nachricht beinhaltet die Adresse des Servers, eines eventuell verwendeten DHCP Relays und die Link Local Address des Client.
Martin Mauve Universität Mannheim 51
DHCP für IPv6
Der Server antwortet auf eine Request Nachricht mit einer Reply Nachricht. Diese beinhaltet die folgenden Informationen: Die neu zugewiesene IPv6 Adresse des Clients. Den DNS Namen des Clients, insofern es einen DNS
Eintrag gibt. Preferred/Valid Lifetime der Adresse, wie bei der
Zustandslosen Autokonfiguration. Wenn der Client die Adresse über diesen Zeitraum hinaus behalten will muss er eine erneute Anfrage vor Ablauf dieser Zeit stellen. Dazu kann er in seinem Request seine bisherige Adresse angeben, die dann vom Server „verlängert“ wird. Dieses Vorgehen soll verhindern, daß ein Client der unkontrolliert das Netz verlässt die Adresse für immer belegt hält.
Martin Mauve Universität Mannheim 52
DHCP für IPv6
Braucht ein Client seine Adresse nicht mehr kann er sie auch geordnet an den Server mit einer DHCP Release Nachricht zurückgeben.
Sollte eine globale Veränderung eintreten (z.B. Providerwechsel) dann kann ein DHCP Server DHCP Reconfiguration Nachrichten verschicken: Diese werden per multicast auf die Gruppe „reconfiguration
multicast address“ geschickt. Bei Erhalt einer solchen Nachricht muss ein DHCP Client
seinen DHCP Server kontaktieren um die Veränderungen zu erfahren.
Martin Mauve Universität Mannheim 53
Automatisierte DNS Einträge
Neben einer IP Adresse braucht ein System in der Regel auch einen DNS Namen.
Dies sollte ebenfalls automatisiert erfolgen, daran wird jedoch noch gearbeitet!
Martin Mauve Universität Mannheim 54
Adressauflösung und Nachbarerkennung
IPv6 verwendet ICMP für die Adressauflösung (und nicht ARP) sowie für die automatische Erkennung benachbarter Router und Endsysteme.
Zu diesem Zweck hält jedes Endsystem 4 separate Caches: Destination Cache: hier werd die IPv6 Zieladressen gespeichert,
zu denen in letzter Zeit Pakete geschickt wurden. Zu jedem dieser Einträge wird die IPv6 Adresse desjenigen Systems gespeichert an welches das Paket zwecks Weiterleitung übergeben wurde. Dies ist entweder ein Router im selben Sub-Netz oder das Ziel selber, wenn es sich im selben Sub-Netz befindet.
Neighbor Cache: hier werden die IPv6 Adressen von Nachbarn (Systeme im selben Sub-Netz) auf Schicht 2 Adressen abgebildet.
Prefix List: die Prefixe für das eigene Sub-Netz wie sie durch Router Advertisements kennensgelernt werden.
Router List: Liste der IPv6 Link Local Adresses von Router von denen man in letzter Zeit ein Router Advertisement empfangen hat.
Martin Mauve Universität Mannheim 55
Adressauflösung und Nachbarerkennung
Als erster Schritt beim Senden eines Paketes muss ein Endsystem denjenigen Nachbarn (Nachbar = System im gleichen Sub-Netz) herausfinden an den das Paket übergeben werden soll.
Der Nachbar ist entweder der Empfänger, oder ein Router.
In der Regel wird die IPv6 Adresse des Nachbarn im Destination Cache vorhanden sein (wenn dies nicht das erste Paket zu diesem Ziel ist).
Ist dies nicht der Fall, dann wird zunächst in der Prefix List nachgesehen, ob der Empfänger ein Nachbar ist.
Ist dies nicht der Fall, so muss aus der Router List ein geeigneter Router ausgewählt werden, dem das Paket zur Weiterleitung übergeben wird.
Martin Mauve Universität Mannheim 56
Adressauflösung und Nachbarerkennung
An dieser Stelle kennt der Absender des Paketes nun die IPv6 Adresse des nächsten Systems an welches das Paket auf seinem Weg zum Empfänger weitergeleitet werden soll. Wenn der entsprechende Eintrag noch nicht im Destination Cache vorhanden ist, dann wird er neu eingetragen.
Als nächstes wird nun die zu dieser IPv6 gehörige Schicht 2 Adresse benötigt.
Martin Mauve Universität Mannheim 57
Adressauflösung und Nachbarerkennung
Dabei gibt es 4 Fälle: Wenn es keine entsprechende Eintrag im Neighbor Cache
gibt wird eine Neighbor Solicitation Nachricht versandt und ein unvollständiger Eintrag im Neighbor Cache vorgenommen. Das Paket wird aufgehoben bis ein Antwort kommt.
Wenn es einen unvollständigen Eintrag im Neighbor Cache gibt, dann wird das Paket aufgehoben bis eine Antwort kommt.
Wenn es einen vollständigen Eintrag gibt wird das Paket direkt verschickt.
Wenn es einen sehr alten Eintrag gibt wird das Paket verschickt und eine Neighbor Solicitation Nachricht versandt.
Martin Mauve Universität Mannheim 58
Adressauflösung und Nachbarerkennung
Neighbor Solicitation Nachrichten sind ICMP Nachrichten: Typ: 135 Sie beinhalten vor allem die IPv6-Adresse des Systems von
dem eine Schicht 2 Adresse gewünscht wird. Die Nachricht wird an eine multicast Adresse geschickt, die
sich aus der gesuchten IP Adresse ableitet:• Der Prefix ist: FF02:0:0:0:0:1:FF00:0/104.• Der Suffix sind die letzten 24 Bit der gesuchten IPv6 Adresse.• Dieses Vorgehen verringert die Anzahl der Neighbor
Solicitation Nachrichten, die jedes einzelne System auswerten muss.
• Jedes System muss den multicast Gruppen beitreten, die zu ihren IP Adressen gehören.
Martin Mauve Universität Mannheim 59
Adressauflösung und Nachbarerkennung
Als Antwort auf eine Neighbor Solicitation Nachricht Sendet das System mit der angesprochenen IPv6 Nachricht eine Neighbor Advertisement Nachricht: Dies ist eine ICMP Nachricht mit dem Typ 136. Sie wird direkt an das nachfragende System versandt. Sie beinhaltet die IPv6 Adresse und die gesuchte Schicht 2
Adresse, die dazu passt.
Diese Informationen werden vom Empfänger der Neighbor Advertisement Nachricht im Neighbor Cache gespeichert.
Martin Mauve Universität Mannheim 60
Adressauflösung und Nachbarerkennung
Wie lernt ein Endsystem die IP-Adressen der Router im Sub-Netz um die Router List aufzubauen?
Wie lernt ein Endsystem die Prefixe des eignen Sub-Netzes?
Antwort: Router schicken Router Advertisement Nachrichten nicht nur auf Aufforderung per unicast (habe wir unter zustandsloser Autokonfiguration besprochen) sondern auch in regelmäßigen Abständen auf der „all hosts“ multicast Gruppe. Diese Nachrichten beinhalten auch die Prefixe des eigenen Sub-Netzes.
Martin Mauve Universität Mannheim 61
Adressauflösung und Nachbarerkennung
Wenn ein Endsystem ohne weitere Informationen einfach einen Router des Sub-Netzes auswählt kann es zu folgender Situation kommen:
Router 1
Router 2
Endsystem 1
Endsystem 2
Martin Mauve Universität Mannheim 62
Adressauflösung und Nachbarerkennung
In diesem Fall schickt der Router eine ICMP Redirect Nachricht an den Absender des Paketes zurück: Diese Beinhaltet die Zieladresse des Paketes, sowie die
IPv6 Adresse des Routers, welcher besser geeignet ist das Paket weiterzuleiten.
Martin Mauve Universität Mannheim 63
IPv6 Security - IPSec
IPSec ist sowohl für IPv4 als auch für IPv6 definiert, bei IPv6 jedoch fester Bestandteil.
IPSec kann grob in 3 Funktions-Bereiche Eingeteilt werden: Authentifikation: Sicherstellen, dass ein Paket von einem gewissen
Absender kommt und unterwegs nicht verändert wurde. Verschlüsselung: Sicherstellen, dass ein Paket nur von einem
berechtigen Empfänger gelesen werden kann. Schlüssel-Austausch: Wie tauschen Sender und Empfänger die
notwendigen Informationen (z.B. Schlüssel) für Authentifikation und Verschlüsselung aus?
Wir besprechen von IPSec nur das notwendige Rahmenwerk und Protokollelemente. Die eigentlichen Algorithmen zur Authentifikation und Verschlüsselung werden getrennt spezifiziert und hier nicht besprochen (geht weit über diese Vorlesung hinaus).
Martin Mauve Universität Mannheim 64
RFCs (kleine Auswahl!)
Kent, Atkinson. Security Architecture for the Internet Protocol. RFC 2401. 1998.
Kent, Atkinson. IP Authentication Header. RFC 2402. 1998.
Kent, Atkinson. IP Encapsulating Security Payload (ESP). RFC 2406. 1998.
Maughan, et. Al. Internet Security Association and Key Management Protocol (ISAKMP). RFC 2408. 1998.
Martin Mauve Universität Mannheim 65
Security Association
Damit Sender und Empfänger Authentifikation oder Verschlüsselung verwenden können müssen sie sich auf die notwendigen Parameter einigen: Verschlüsselung/Authentifikation Algorithmen Schlüssel Lebenszeit von Schlüsseln
Die Menge der Parameter wird security association genannt. Sie wird mittels eines Security Parameter Index (SPI) identifiziert der in jedem Paket mitgeschickt wird.
Die notwendigen Parameter werden mit Hilfe von Schlüssel-Austausch Verfahren zwischen Sender und Empfänger ausgetauscht.
Martin Mauve Universität Mannheim 66
Authentication Header (AH)
Der Authentication Header ist ein IPv6 Extension Header.
security parameter index (SPI)
reservednext header length
0 7 15 31
sequence number
authentification data (variable length)
length: Größe des Authentication Headersequence number: soll replay Angriffe verhindern, bei denen aufgezeichneteOriginal-Pakete vom Angreifer wiederholt übertragen werdenAuthentification-data: digitale Signatur über das Paket
Martin Mauve Universität Mannheim 67
Authentication Header (AH)
Für die eigentliche Signatur gibt es verschieden Algorithmen, die unterschiedliche Eigenschaften besitzen.
Prinzipielles Vorgehen: Der Sender berechnet eine Signatur über das Paket und
legt diese Signatur im authentification data Feld des AH ab. Der Empfänger berechnet bei Empfang des Paketes welche
Signatur das Paket haben müsste und vergleicht dies mit dem authentification data Feld.
Zur Verständnis der hierzu verwendeten Algorithmen empfiehlt sich der Besuch einer entsprechenden Vorlesung, z.B. am LS von Prof. Krause angeboten!
Martin Mauve Universität Mannheim 68
Authentication Header (AH)
Was wird durch den AH authentifiziert? Der Sender konstruiert für die Berechnung der digitalen Signatur eine spezielle Version des Paketes, welches nur diejenigen Informationen beinhaltet, die sich auf dem Weg zum Empfänger garantiert nicht ändern (dürfen): IPv6 Header ohne die ersten 32 Bit, hop count wird für die
Authentifikation auf 0 gesetzt. Wenn die Routing Header Extension genutzt wird, dann wir
das Paket in dem Zustand authentifiziert, in dem es beim Empfänger ankommen wird.
Andere Extension Header werden auf 0 gesetzt wenn sie während der Übertragung verändert werden können.
Der eigentliche Payload des IPv6 Paketes (alles ab Schicht 4 Header aufwärts).
Martin Mauve Universität Mannheim 69
IP Encapsulating Security Payload (ESP)
AH erlaubt es festzustellen von wem ein Paket abgeschickt wurde und ob es auf dem Weg zum Empfänger verfälscht wurde, mehr nicht!
Möchte man die übertragenen Daten verschlüsseln, so verwendet man ESP und den ESP extension header.
Ein Paket mit ESP hat folgendes Format:
IPv6 Header ExtensionHeaders
ESPHeader
EncryptedData
AuthenticationData
verschlüsselte Daten
Martin Mauve Universität Mannheim 70
ESP
security parameter index (SPI)
0 7 15 31
sequence number
authentification data (variable length)
encrypted data and parameters (variable length)
sequence number: soll replay Angriffe verhindern, bei denen aufgezeichneteOriginal-Pakete vom Angreifer wiederholt übertragen werdenencrypted data: hier stehen die verschlüsselten Daten, sowie Parameter wie Größeder verschlüsselten Daten, etc.authentification data: digitale Signatur über das Paket
Martin Mauve Universität Mannheim 71
Internet Security Association and Key Management Protocol (ISAKMP) Generelles Rahmenwerk für den Austausch von
Schlüsselinformationen und anderen Parametern.
Spezielle Schlüssel-Austauschverfahren benutzen dieses Rahmenwerk. Beispiele sind:
OAKLEY IKE
Schlüssel Austausch-Verfahren sind häufig ein Ansatzpunkt für Angriffe. Es hat bereits eine ganze Reihe von Vorschlägen gegeben, die sich als unsicher herausgestellt haben.
Für eine genauere Kenntnis von Schlüssel-Austauschverfahren empfiehlt sich der Besuch einer geeigneten Vorlesung.
Martin Mauve Universität Mannheim 72
Wo wird IPSec implementiert?
Langfristig (bei Einführung von IPv6) sollen die Endsysteme selbst IPSec unterstützen.
Häufiger Ansatz heute: innerhalb von Firewalls um zwei Netze über das Internet gesichert zu verbinden. Dabei wird das ursprüngliche IP Paket von den Firewalls in ein gesichertes (AH oder ESP) IP Paket gekapselt.
Host 1 Firewall 1 Host 2Firewall 2Internet &Evil People
IP H1 -> H2 TCP Header + Data Ursprüngliche Nachricht
IP H1 -> H2 TCP Header + DataIP F1 -> F2 AH Gekapselte Nachricht
Martin Mauve Universität Mannheim 73
Sicherheit bei Autoconfiguration und Nachbarerkennung Autokonfiguration und Nachbarerkennung sind
Sicherheitssensitiv. Insbesondere sollte folgendes gewährt sein: Router Advertisements dürfen nur von den entsprechenden
Routern gesendet werden Neighbor Advertisements dürfen nur von der Station
kommen, die die entsprechende Adresse besitzt Redirect Nachrichten dürfen nur von dem Router gesendet
werden, der das Paket weitergeleitet hat
Martin Mauve Universität Mannheim 74
Router Advertisements
Werden gesichert durch eine IPSec Security Association die mindestens AH beinhaltet. Problem: wenn der Authentifikationsmechanismus
symmetrisch ist, dann kann jeder Host, der den Schlüssel hat als Router auftreten. Bei asymmetrischen Verfahren ist dies nicht der Fall!
Zur Identifikation müssen die (öffentlichen Bestandteile der) Schlüssel der Router den Endsystemen bekanntgegeben werden, dies unterläuft die Idee der Autokonfiguration.
Martin Mauve Universität Mannheim 75
Neighbor Advertisement
Problem: wie kann man eine IPSec Security Association herstellen, wenn man noch keine Pakete austauschen kann? Mögliche Lösung: Router kündigen die lokalen Präfixe nicht
an, sondern zwingen jedes System über den default Router zu kommunizieren. Dabei wird man sich darauf verlassen, daß entsprechende redirects vom Router erfolgen, wenn das Ziel im selben Sub-Netz ist.
Martin Mauve Universität Mannheim 76
Kommunikation mit den Routern (Redirect)
Hier wird zwischen den Endsystemen und den Routern eine Security Association hergestellt. In der Regel verwendet man hierzu asymmetrische Verfahren. Problem: dies erfordert, daß dem Endsystem die
öffentlichen Schlüssel der Router bekanntgegeben werden. Damit wird natürlich die Idee der Autokonfiguration unterlaufen.
Martin Mauve Universität Mannheim 77
Übergangsstrategie
Für die Periode des Überganges von IPv4 nach IPv6 wird eine sogenannte dual-stack Strategie verwendet. D.h. IPv6 wird parallel zu IPv4 verwendet und „leiht“ sich die IPv4 Infrastruktur.
Ein IPv6 Endsystem wird also zunächst sowohl IPv4 als auch IPv6 verwenden:
Anwendung
TCP
IPv6 IPv4
Ethernet
Martin Mauve Universität Mannheim 78
Anpassung der Systeme
Die folgenden Erweiterungen werden in den Endsystemen benötigt: IPv6 Basisfunktionalität: IPv6, ICMP, neighbor discovery,
autoconfiguration. Handhabung von IPv6 in TCP und UDP (pseudoheader). Interface zu DNS.
Router behandeln IPv6 wie ein weiteres Netzwerk Protokoll, davon gibt es ja neben IP schon eine ganze Menge (IPX, Appletalk, etc.).
DNS Server: müssen erweitert werden um IPv6 Adressen handhaben zu können.
Martin Mauve Universität Mannheim 79
6Bone
Es gibt ein IPv6 Testnetz, den 6Bone. In einer Organisationseinheit lässt sich IPv6 relativ
einfach installieren: Installation von IPv6 auf den Endgeräten. Einsetzten eines (oder mehrer) IPv6 fähigen Router um die
lokalen Netze miteinander zu verbinden. Problem: dadurch entstehen IPv6 Inseln. Diese sind
nicht über IPv6 miteinander verbunden, sondern nur über IPv4.
Lösung: solange das Internet noch nicht komplett umgestellt ist werden solche Inseln mit Hilfe von Tunneln verbunden.
Martin Mauve Universität Mannheim 80
Der 6Bone - Tunneling
IPv6 Domain 1
R1
IPv6 Domain 1
R1
IPv4 Netzwerk(e)
Tunnel
IPv6 Header
TransportLayerHeader
Data
IPv6 Header
TransportLayerHeader
Data
IPv4 Header
Martin Mauve Universität Mannheim 81
6Bone - Tunneling
Ein Tunnel sieht für IPv6 aus wie eine „normale“ Schicht 2 Verbindung (Ethernet/ATM, etc.).
Durch tunneling wird ein sogenanntes virtuelles overlay Netzwerk gebildet, welches das reale IPv4 Netzwerk benutzt.
Dieses virtuelle overlay Netzwerk wird 6Bone genannt. Analog dazu gibt es auch den MBone als virtuelles overlay Netzwerk für IP multicast.
Martin Mauve Universität Mannheim 82
6Bone - Tunneling
Wie jeder anderen Schicht 2 Verbindung muss auch dem Tunnel eine MTU zugewiesen werden.
Dies geschieht indem MTU discovery zwischen den beiden Endpunkten eines Tunnels durchgeführt wird, der resultierende Wert ist die MTU des Tunnels.
Dabei gilt: wenn diese MTU kleiner als die minimale MTU (1280 Bytes) für IPv6 ist, dann wird IPv4 Fragmentierung verwendet, ansonsten wird IPv4 Fragmentierung nicht verwendet.
Martin Mauve Universität Mannheim 83
6Bone – Tunneling
Für das Routing werden Tunnels wie ganz gewöhnliche Links behandelt: Liegen die Tunnelendpunkte innerhalb der selben
routing Domäne (organisationelle Einheit) wird RIP oder OSPF über diesen Link benutzt.
Wenn die Tunnelendpunkte in verschiedenen routing Domänen liegen, dann wird IDRP / BGP-4 verwendet.
Martin Mauve Universität Mannheim 84
6Bone – Tunneling
Beim Routing durch einen Tunnel gibt es jedoch ein Problem: wie sollte die Metrik eines Tunnels verglichen mit anderen Verbindungen sein? Wenn ein Tunnel nur wie ein gewöhnlicher Link gewertet
wird kann es sein, daß Verkehr durch den Tunnel geleitet wird, der besser einen anderen Weg genommen hätte.
Zur Zeit wird die Metrik (die Kosten) eines Tunnels mit der Hand eingestellt um den Kosten des Tunnels zu entsprechen. Diese sollten dem IPv4 Pfad des Tunnels entsprechen.
Problem: wenn sich der IPv4 Pfad des Tunnels ändert stimmen diese Kosten unter Umständen nicht mehr! Dies ist nicht selten, da IPv4 dynamisch routet.
Martin Mauve Universität Mannheim 85
6Bone - Tunneling
Wie wird die TTL in einem Tunnel gehandhabt? Für den IPv4 Header, der ein IPv6 Paket einkapselt wird die
TTL so eingestellt, daß das andere Ende des Tunnel auf jeden Fall erreicht wird.
Die TTL im IPv6 Header wird durch das passieren eines Tunnels um 1 verringert.
Dieses Vorgehen ist sinnvoll, da die TTL vor Routing-Schleifen schützen soll, dabei ist es nicht so wichtig wie lang oder kostspielig ein Pfad ist. Es kommt eher darauf an, daß nach einer wohldefinierten Anzahl von Hops garantiert werden kann, daß das Paket nicht mehr im Netz zirkuliert.
Martin Mauve Universität Mannheim 86
6Bone Entwicklung
Der 6Bone wurde bereits sehr frühzeitig aufgebaut und genutzt um die verschiedenen Vorschläge für IPv6 (früher auch IPng) zu testen.
Nach dem allgemeinen Vorgehen der IETF müssen zunächst Prototypen und Demonstratoren existieren, bevor etwas standardisiert wird.
Insbesondere wurden für IPv6 von verschiedenen Gruppen Implementierungen erstellt, die interoperabel sein sollten. Dies testet ob die Spezifikation ausreichend ist!
Diese erste Phase des 6Bone ist abgeschlossen, da die wesentlichen IPv6 Spezifikationen inzwischen recht stabil sind.
Martin Mauve Universität Mannheim 87
6Bone Entwicklung
Zur Zeit finden folgende Aktivitäten auf dem 6Bone statt: Implementatoren von IPv6 Endsystem/Router Software
testen diese im 6Bone. Routing Protokolle für IPv6 (IDRP oder RIPng) werden
getestet. Provider testen die Vergabe von Adressen. Forschergruppen und interessierte Einzelpersonen
experimentieren mit den neuen Aspekten von IPv6. Administratoren machen sich frühzeitig mit IPv6 vertraut.
Martin Mauve Universität Mannheim 88
6Bone - Mitmachen
Man kann dem 6Bone beitreten um selbst erste Erfahrungen mit IPv6 zu sammeln: Dazu muss man zunächst eine IPv6 Insel installieren, die
zumindest aus einem Sub-Netz, einem IPv6 fähigem Router, mehreren IPv6 fähigen Endgeräten und einem IPv6 fähigen Name-Server besteht.
Dann besorgt man sich einen Adress-Präfix und stellt sicher daß alle Stationen in der IPv6 Insel die richtigen Adressen haben (sollte dank Autokonfiguration einfach sein!).
Danach muss man wenigstens einen Tunnel schalten, um sich mit dem Rest des 6Bone zu verbinden.
Ausführliche Infos unter: www.6bone.net