Kein Folientitel - pi4

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
1
IPv4 Header
0
15
7
version
hlength
type of service
identification
time to live
31
total length
flags
protocol
fragment offset
header checksum
source IP address
destination IP address
options (if any)
data
Martin Mauve
Universität Mannheim
2
IPv6 Header
0
version
15
7
31
traffic class
flow label
payload length
next header
hop limit
source IP address (128 bit)
destination IP address (128 bit)
extension headers (if any)
data
Martin Mauve
Universität Mannheim
3
IPv6 Header Vereinfachungen



Martin Mauve
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).
Universität Mannheim
4
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
5
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
6
IPv6 Extension Headers

die Extension Headers ersetzen die Options von IPv4

die Extension Header folgen auf den IP header:
IPv6 Header Routing Header Fragment Header Fragment
next header= next header=
next header=
TCP
Routing
Fragment
TCP
Martin Mauve
Universität Mannheim
7
IPv6 Extension Headers: Routing Header
0
15
7
next header
hdr. ext. length
31
routing type=0
segments left
reserved
address1 (128 bit)
more addresses
Martin Mauve
Universität Mannheim
8
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
9
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
10
IPv6 Extension Headers:
Fragmentation Header
0
15
7
next header
reserved
31
fragment offset
res M
identification




Martin Mauve
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.
Universität Mannheim
11
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
12
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
13
ICMPv6 - Paketformat
0
15
7
31
IPv6 header
type
code
checksum
message body

type: ICMP Nachrichtentyp

code: Unterteilung der Typen

checksum: über eine pseudo IPv6 Header und das
gesamte ICMP Paket
Martin Mauve
Universität Mannheim
14
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
15
ICMPv6 Errors
0
15
7
31
IPv6 header
type={1,2,3,4}
code
checksum
parameter
verursachendes Paket (maximale Gesamtgröße des ICMP
Paketes ist 576 inklusive aller Header, dann wird das Paket abgeschnitten)
Martin Mauve
Universität Mannheim
16
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
17
Auswirkungen auf Höhere Schichten

0
Neuer Pseudoheader für die Berechnung der
Checksummen (ICMP, TCP, UDP, ....)
15
7
31
source IP address (128 bit)
destination IP address (128 bit)
payload length
flow label
next header
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
18
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
19
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
20
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
21
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

Martin Mauve
Dieses Vorgehen verschlankt den Protokollstack und
beschleunigt die Bearbeitung von Paketen
Universität Mannheim
22
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 IPAdressen 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
23
IPv6 Adressierung

ein System in IPv6 kann wie in IPv4 mehrere IP
Adressen besitzen (z.B. wenn es an mehrere SubNetzte 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
24
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
25
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
26
IPv6 Adressierung

der IPv6 Adressraum wird wir folgt aufgeteilt:








Martin Mauve
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
Universität Mannheim
27
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
28
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
29
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 TOnline 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
30
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
31
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
32
Spezialadressen

Martin Mauve
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
Universität Mannheim
33
IPv6 Exterior Gateway Routing

entweder mit BGP-4 (+IPv6 Erweiterung hierzu),

oder mit dem ISO (ISO Standard 10747) InterDomain 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
34
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
35
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
36
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 BGP4 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
37
IDRP – Beispiel (Frei Erfunden!)
Router der default
T-Online Europe
Central African Exchange
freien Zone. Routing
TLA-ID: FE
Einträge zu 20FE::/16, TLA-ID: F
Präfix: 200F::/16 hier können weitere
Präfix: 20FE::/16
200F:10::/32 und
200F:1000::/24
Router dazwischen liegen
T-Online Deutschland
NLA-ID (1. Hälfte/16 Bit): 10
Präfix: 200F:10::/32
T-Online Frankreich
NLA-ID (1. Hälfte/8 Bit): 10
Präfix: 200F:1000::/24
Startup GMBH
NLA-ID (2. Hälfte/16 Bit): FF00
Präfix: 200F:10:FF00::/48
Martin Mauve
Router der untersten Ebene.
Routing Einträge zu allen
Sub-Netzen in 20FE:10:FF00::/48,
und eine default Route zu T-Online
Universität Mannheim
38
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
39
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
40
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
41
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
42
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
43
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
44
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.

Martin Mauve
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.
Universität Mannheim
45
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
46
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
47
DHCP für IPv6

Damit nicht in jedem Sub-Netzwerk ein DHCP
Server vorhanden sein muss gibt es in jedem SubNetz 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
48
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

Martin Mauve
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.
Universität Mannheim
49
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
50
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
51
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
52
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
53
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
54
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
55
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
56
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
57
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
58
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.

Martin Mauve
Diese Informationen werden vom Empfänger der
Neighbor Advertisement Nachricht im Neighbor
Cache gespeichert.
Universität Mannheim
59
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 SubNetzes?

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
60
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
Endsystem 1
Router 2
Endsystem 2
Martin Mauve
Universität Mannheim
61
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
62
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?

Martin Mauve
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).
Universität Mannheim
63
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
64
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
65
Authentication Header (AH)

Der Authentication Header ist ein IPv6 Extension
Header.
0
15
7
next header
length
31
reserved
security parameter index (SPI)
sequence number
authentification data (variable length)
length: Größe des Authentication Header
sequence number: soll replay Angriffe verhindern, bei denen aufgezeichnete
Original-Pakete vom Angreifer wiederholt übertragen werden
Authentification-data: digitale Signatur über das Paket
Martin Mauve
Universität Mannheim
66
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.

Martin Mauve
Zur Verständnis der hierzu verwendeten Algorithmen
empfiehlt sich der Besuch einer entsprechenden
Vorlesung, z.B. am LS von Prof. Krause angeboten!
Universität Mannheim
67
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
68
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 Extension ESP
Encrypted Authentication
Headers
Header Data
Data
verschlüsselte Daten
Martin Mauve
Universität Mannheim
69
ESP
0
7
15
31
security parameter index (SPI)
sequence number
encrypted data and parameters (variable length)
authentification data (variable length)
sequence number: soll replay Angriffe verhindern, bei denen aufgezeichnete
Original-Pakete vom Angreifer wiederholt übertragen werden
encrypted data: hier stehen die verschlüsselten Daten, sowie Parameter wie Größe
der verschlüsselten Daten, etc.
authentification data: digitale Signatur über das Paket
Martin Mauve
Universität Mannheim
70
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
71
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
Martin Mauve
Internet &
Evil People
Firewall 1
IP H1 -> H2
TCP Header + Data
IP F1 -> F2
AH IP H1 -> H2
Firewall 2
Host 2
Ursprüngliche Nachricht
TCP Header + Data
Universität Mannheim
Gekapselte Nachricht
72
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
73
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
74
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
75
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
76
Ü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
77
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
78
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
79
Der 6Bone - Tunneling
IPv6 Domain 1
IPv6 Domain 1
IPv4 Netzwerk(e)
R1
R1
Tunnel
IPv4 Header
Martin Mauve
IPv6 Header
IPv6 Header
Transport
Layer
Header
Transport
Layer
Header
Data
Data
Universität Mannheim
80
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
81
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
82
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
83
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
84
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 RoutingSchleifen 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
85
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
86
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
87
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.

Martin Mauve
Ausführliche Infos unter: www.6bone.net
Universität Mannheim
88