DHCPv6-Präfix-Delegation
©2014
Masterarbeit
111 Seiten
Zusammenfassung
Mit der rasanten Entwicklung der IP-Welt und der Verbreitung der IPv6, müssen die neuen Anforderungen des Kunden in Betracht genommen werden. Deswegen begannen viele Internetanbieter natives IPv6 anzubieten und dem entsprechend auf die klassischen Übergangstechnologien wie z. B. Tunnels, zu verzichten. IPv6 an sich bietet ein einfaches Autokonfigurationsverfahren, unterstützt allerdings nicht die automatische Präfix-Zuweisung. Für die automatische Präfix-Zuweisung wird ein effizientes Verfahren benötigt. Das Verfahren soll die Zuweisung von IPv6-Präfixen von einem ISP bis hin zu den Endgeräten des Kunden automatisieren. DHCPv6 mit der Präfix-Delegation-Option stellt hierzu ein ideales Verfahren zur Verfügung. Mit diesem effizienten Verfahren wird das Leben sowohl der Internetanbieter, als auch die der Internetanwender erleichtert. Der Internetanbieter will einen effizienten automatisierten Prozess, welcher seine Kunden zufriedenstellt. Der Internetanwender möchte wiederum seine Geräte einfach und komfortabel an das Netz anschießen und sich um keinerlei Konfigurationen kümmern. Darüber hinaus möchte der Kunde seine Geräte permanent Verfügbar und gleichzeitig seine Daten geschützt wissen. Im Rahmen dieser Arbeit werden alle die oben genannten Aspekte im Verbund mit dem DHCPv6-Präfix-Delegation-Verfahren erörtert.
Leseprobe
Inhaltsverzeichnis
Abbildungsverzeichnis
X
Abbildungsverzeichnis
2.1: Präfix-Delegation-Topologie [RFC3633] ... 6
2.2: DHCPv6-Nachrichten-Format ... 7
2.3: IA-PD-Option ... 9
2.4: IA-PD-Präfix-Option ... 10
2.5: Präfix-Delegation-Nachrichtenaustausch... 12
2.6: Lifetime-Zustände einer IPv6-Adresse ... 13
2.7: Der Zeitpunkt an dem das neue Präfix zugewiesen soll ... 14
3.1: Präfix-Delegation-Anwender und Rollen der Komponenten ... 16
3.2: Anwendungsszenario Privatkunde S ... 19
3.3 Anwendungsszenario Privatkunde M ... 20
3.4: Anwendungsszenario Privatkunde L ... 21
3.5: Das Verhalten von Valid und Preferred-Lifetime wenn T1 < Preferred-Lifetime ... 25
3.6: Einfluss des T1 Parameters ... 27
3.7: Präfix-Renumbering Fälle ... 30
3.8: Testszenario S1 für Privatkunde S ... 33
3.9: Testszenario S2 für Privatkunde S ... 34
3.10: Testszenario S3 für Privatkunde S ... 34
3.11: Testszenario M1 für Privatkunde M ... 35
3.12: Testszenario M2 für Privatkunde M ... 36
3.13: Testszenario M3 für Privatkunde M ... 37
3.14: Testszenario L1 für Privatkunde L ... 38
3.15: Testszenario L2 für Privatkunde L ... 38
3.16: Flowchart des hierarchischen Konzepts ... 39
4.1: ISC-DHCPv6-Server Installation ... 49
4.2: ISC-DHCPv6-Server Konfiguration ... 49
4.3: Linux Implementierung Testszenario S1 ... 50
4.4: WIDE-DHCPv6-Client Installation ... 50
4.5: WIDE-DHCPv6-Client Konfiguration ... 50
4.6: Wireshark-Abschnitt Präfix-Delegation-Nachrichtenaustausch ... 51
4.7: Requesting-Router Subpräfix Zuweisung an das LAN-Interface ... 52
4.8: Linux Implementierung Testszenario S2 ... 52
4.9: Router-Advertisement Installation ... 52
4.10: Router-Advertisement Konfiguration ... 53
4.11: Globale IPv6-Adressen am Windows 7-PC ... 53
4.12: Linux Implementierung Testszenario S3 ... 54
4.13: Koexistenz des alten und neuen Präfixes am Windows 7-PC ... 54
4.14: Fritz!Box Implementierung Testszenario S1 ... 55
4.15: Requesting-Router-Funktionalität ... 56
4.16: Fritz!Box Implementierung Testszenario S2 ... 56
XI
4.17: Globale IPv6-Adressen am Windows 7-PC ... 57
4.18: Fritz!Box Implementierung Testszenario S3 ... 57
4.19: Das neue Präfix am Windows-7-PC ... 57
4.20: Requesting-Router erhält nur das neue Präfix ... 58
4.21: OpenWrt-Implementierung Testszenario S1 ... 58
4.22: ip6tables (OpenWrt) Installation ... 58
4.23: WIDE-DHCPv6-Client (OpenWrt) Installation ... 59
4.24: WIDE-DHCPv6-Client (OpenWrt) Konfiguration ... 59
4.25: Requesting-Router Präfix Zuweisung an das LAN-Port ... 59
4.26: OpenWrt-Implementierung Testszenario S2 ... 60
4.27: Router-Advertisement (OpenWrt) Installation ... 60
4.28: Router-Advertisement (OpenWrt) Konfiguration ... 60
4.29: Globale IPv6-Adressen am Windows-7-PC ... 61
4.30: OpenWrt Implementierung Testszenario S3 ... 61
4.31: Koexistenz des neuen und alten Präfixes am Windows 7-PC ... 62
4.32: Linux Implementierung Testszenario-M1 ... 63
4.33: WIDE-DHCPv6-Client Konfiguration ... 64
4.34: Requesting-Router Präfixe Zuweisung an LAN1 und LAN2-Interfaces ... 65
4.35: Linux Implementierung Testszenario M2 ... 66
4.36: Router-Advertisement Konfiguration ... 66
4.37: Globale IPv6 Adressen am Linux-Ubuntu 12.4 LTS-PC ... 67
4.38: Globale IPv6 Adresse am Linux-Ubuntu 12.4 LTS-PC ... 67
4.39: Linux-Implementierung Testszenario M3 ... 68
4.40: Koexistenz des neuen und alten Präfixes am Linux-Ubuntu 12.4 LTS-PC ... 68
4.41: Koexistenz des neuen und alten Präfixes am Linux-Ubuntu 12.4 LTS-PC ... 68
4.42: OpenWrt Implementierung Testszenario M1 ... 70
4.43: ASUS WL-500gP (Default Config.) [Asu14] ... 70
4.44: VLANs Konfigurationen ... 71
4.45: LAN-Interfaces Konfigurationen ... 72
4.46: WIDE-DHCPv6-Client (OpenWrt) Konfiguration ... 73
4.47: Requesting-Router Präfixe Zuweisung an LAN1 und LAN2-Interfaces ... 73
4.48: OpenWrt-Implementierung Testszenario M2... 74
4.49: Router-Advertisement (OpenWrt) Konfiguration ... 75
4.50: Globale IPv6 Adressen am Windows 7-PC ... 76
4.51: Globale IPv6 Adressen am Linux-Ubuntu 12.4 LTS-PC ... 76
4.52: OpenWrt Implementierung Testszenario M3 ... 76
4.53: Koexistenz des neuen und alten Präfixes am Linux-Ubuntu 12.4 LTS-PC ... 77
4.54: Koexistenz des neuen und alten Präfixes am Windows-7-PC ... 77
4.55: Testphase Privatkunde L ... 78
4.56: Requesting-Router 1 Subpräfix Zuweisung an das LAN-Interface ... 79
4.57: ISC-DHCPv6-Server Konfiguration ... 79
4.58: ISC-DHCPv6-Server Status ... 79
4.59: Requesting-Router-1 Fritz!Box-1 Funktionalität ... 81
XII
4.60: Wireshark-Abschnitt Requesting-Router-2 Präfix-Delegation-
Nachrichtenaustausch... 82
4.61: WIDE-DHCPv6-Client Konfiguration ... 83
4.62: Requesting-Router-2 Präfix Zuweisung an das LAN-Interface ... 83
4.63: Requesting-Router-1 Fritz!Box-1 Funktionalität ... 84
4.64: Requesting-Router-2 Fritz!Box-2 Funktionalität ... 85
4.65: Requesting-Router-1 Fritz!Box-1 Funktionalität ... 86
4.66: WIDE-DHCPv6-Client (OpenWrt) Konfiguration ... 87
4.67: Requesting-Router-2 Präfix Zuweisung an das LAN-Interface ... 87
4.68: dnsmasq-dhcpv6 Installation... 88
XIII
Tabellenverzeichnis
XIV
Tabellenverzeichnis
3.1: Rollen der Komponenten (Exemplar) ... 17
3.2: Rollen der Komponenten Privatkunde S ... 19
3.3: Rollen der Komponenten Privatkunde M ... 21
3.4: Rollen der Komponenten Privatkunde L ... 22
3.5: Vorteile und Nachteile der Präfix-Renumbering Fällen ... 31
3.6: Testkriterien ... 32
4.1: DHCPv6-Server-Funktionalität ... 43
4.2: DHCPv6-Client-Funktionalität ... 43
4.3: Implementierungen Requesting-Router ... 46
4.4: Implementierungen Sub-Delegating-Router ... 46
4.5: Testumgebung ... 48
4.6: Ergebnisse der Privatkunde S-Testphase ... 62
4.7: Ergebnisse der Privatkunde M-Testphase ... 77
4.8: Ergebnisse der Privatkunde L-Testphase ... 90
4.9: Zusammenhang zwischen den Testergebnissen und den Anwendungsszenarien ... 93
Abkürzungsverzeichnis
XV
Abkürzungsverzeichnis
DHCPv6
Dynamic Host Configuration Protocol Version 6
DUID
DHCP Unique IDentifier
IANA
Internet Assigned Numbers Authority
IA-PD
Identity Association - Prefix Delegation
ICMPv6
Internet Control Message Protocol Version 6
IETF
Internet Engineering Task Force
IPv4
Internet Protocol Version 4
IPv6
Internet Protocol Version 6
ISP
Internet Server Provider
MAC
Media Access Control
MTU
Maximum Transfer Unit
NAT
Network Address Translation
RA
Router-Advertisements
RFC
Request for Comments
SLAAC
Stateless Address Autoconfiguration
UDP
User Datagram Protocol
Einleitung
1
1
Einleitung
Mit der rasanten Entwicklung der IP-Welt und der Verbreitung der IPv6, müssen die
neuen Anforderungen des Kunden in Betracht genommen werden. Deswegen begannen
viele Internetanbieter natives IPv6 anzubieten und dem entsprechend auf die
klassischen Übergangstechnologien wie z. B. Tunnels, zu verzichten.
IPv6 an sich bietet ein einfaches Autokonfigurationsverfahren, unterstützt allerdings
nicht die automatische Präfix-Zuweisung. Für die automatische Präfix-Zuweisung wird
ein effizientes Verfahren benötigt. Das Verfahren soll die Zuweisung von IPv6-Präfixen
von einem ISP bis hin zu den Endgeräten des Kunden automatisieren.
DHCPv6 mit der Präfix-Delegation-Option stellt hierzu ein ideales Verfahren zur
Verfügung.
Mit diesem effizienten Verfahren wird das Leben sowohl der Internetanbieter, als auch
die der Internetanwender erleichtert.
Der Internetanbieter will einen effizienten automatisierten Prozess, welcher seine
Kunden zufriedenstellt. Der Internetanwender möchte wiederrum seine Geräte einfach
und komfortabel an das Netz anschießen und sich um keinerlei Konfigurationen
kümmern. Darüber hinaus möchte der Kunde seine Geräte permanent Verfügbar und
gleichzeitig seine Daten geschützt wissen.
Im Rahmen dieser Arbeit werden alle die oben genannten Aspekte im Verbund mit dem
DHCPv6-Präfix-Delegation-Verfahren erörtert.
1.1
Problemstellung
In der IPv4-Welt ist der Vorrat an IPv4-Adressen fast erschöpft. Aufgrund dessen weisen
die meisten ISPs dem Home-Router eines Kunden eine einzelne globale IPv4-Adresse zu.
Die internen Geräte, die hinter diesem Home-Router stehen können sich mittels NAT
(Network Address Translation) an das Internet verbinden [RFC2663].
In der IPv6-Welt hingegen, gibt es genügend globale IPv6-Adressen, daher wurde auf
NAT verzichtet [Klo12].
Da stellt sich nun die Frage wie sollen die internen Geräte deren globalen IPv6-Adressen
vom ISP bekommen?
Eine Lösung besteht darin, dass der Home-Router ein IPv6-Präfix von dem ISP bekommt.
Das IPv6-Präfix kann manuell am Home-Router konfiguriert werden, allerdings hat sich
die manuelle Konfiguration aus folgenden Gründen als ineffizient bewiesen:
ISPs sollen Millionen von Kunden mit dem IPv6-Internet verbinden und es wäre
unmöglich, alle diese Kunden manuell mit Präfixe zu konfigurieren. Es ist auch
unpraktisch kleine Netze wie z. B. Home-Netze von qualifizierten Administratoren
Einleitung
2
verwalten zu lassen, da diese Kunden weder die Möglichkeit noch die Zeit haben, sich
die entsprechende Technologie anzueignen, um Ihre Netze zu verwalten.
Die statischen IPv6-Präfixe sind aus Datenschutzperspektive nicht erwünscht [Don13].
Das vom Provider zugewiesene Präfix soll ständig dynamisch geändert werden, um die
Privatsphäre des Internet-Anwenders zu schützen. Hierdurch werden die Informationen
über den Internetanschluss, welche durch das Präfix nun identifizierbar ist, geschützt.
Da die IPv6-Adresse aus zwei Teilen, dem Interface-Identifier und dem Präfix besteht,
muss man an dieser Stelle zwischen diesen beiden unterscheiden. Der Interface-
Identifier wird durch die sogenannte IPv6-Privacy-Extension geschützt, mehr über
dieses Thema siehe [BKL13], während beim Präfix die Zuständigkeit beim Provider liegt.
Es wurden mehrere Verfahren vorgeschlagen und implementiert, um die Ineffizienz der
manuellen Präfix-Konfiguration zu umgehen [KJH04].
Was versteht man unter automatischer Präfix-Zuweisung?
Der Kunde soll sich um gar nichts kümmern, wenn er seine interne Geräte an das Netz
anschließen will. Die Geräte sollen automatisch ein globales Präfix bekommen, was
durch das Präfix-Delegation-Verfahren realisiert wird. Präfix-Delegation bietet ein
effizientes Verfahren, um diese Automatisierung zu verwirklichen. Präfix-Delegation
besteht aus zwei Funktionen, zum einen der automatischen Präfix-Zuweisung vom ISP
an den Home-Router und zum anderen einer automatischen Router-Advertisement vom
Home-Router an die internen Netzwerkgeräte um das Präfix intern zu verteilen [Shi04].
Sollten diese beiden Funktionen nicht zusammen synchronisieren und
erwartungsgemäß laufen, kommt es zu Verbindungsproblemen [Bie13].
Die Präfix-Delegation-Anforderungen für die automatische Präfix-Zuweisung werden in
[RFC3769] beschrieben und durch DHCPv6 standardisiert [RFC3633].
Der DHCPv6-Server weist die Präfix-Delegation-Parameter an den DHCPv6-Client, der
sich auf dem Home-Router befindet, welcher diese in Subpräfixe unterteilt um mehrere
Subnetze zu erzeugen. Hier stellt sich die Frage, ob die vorhandenen DHCPv6-Client-
Implementierungen das Präfix-Delegation-Verfahren erwartungsgemäß ohne
Einschränkungen umsetzen?
Im sogenannten Stateless-Address-Autoconfiguration Verfahren (SAALC) [RFC4862]
weist der Home-Router das Präfix mittels Router-Advertisement den internen Geräten
zu, welche diese mit den intern erzeugten Interface-Identifier verknüpfen um eine
gültige globale IPv6-Adresse zu generieren. Bis jetzt wurde das Präfix manuell in der
Router-Advertisement-Datei konfiguriert. Besteht hier die Möglichkeit, dass die Router-
Advertisement-Datei das dynamische Präfix automatisch erkennt?
Ist die Privacy-Extension in den Betriebssystemen der internen Geräte eingeschaltet,
erzeugen die Betriebssysteme mittels SAALC temporäre globale IPv6-Adressen mit
standardmäßig vorkonfigurierten Timing-Werten, Valid-Lifetime für eingehende
Verbindungen und Preferred-Lifetime für ausgehende Verbindungen, siehe [BKL13].
Einleitung
3
Allerdings verursachen diese temporäreren IPv6-Adressen Probleme. Verwirft das
Betriebssystem nach Ablauf der Valid-Lifetime die Adresse endgültig, wird die
Verbindung unterbrochen.
Um dieses Problem zu minimieren, sollen die Timing-Werte der vom Provider
zugewiesenen Präfixe an die Timing-Werte der temporären Adressen angepasst werden.
Da das Präfix sich in einem IPv6-Netzwerk ständig ändern kann, soll der Home-Router
bei einem Präfix-Wechsel neben dem alten auch das neue Präfix verteilen. Die beiden
Präfixe sollen für eine gewisse Zeit zusammen existieren. Das alte Präfix bleibt für
eingehende Daten gültig und setzt die Preferred-Lifetime auf Null, damit das alte Präfix
nicht für ausgehende Daten weiter benutzt wird. Nach Ablauf der Valid-Lifetime wird
das alte Präfix bei der SAALC vom Betriebssystem komplett verworfen [Kab12].
Hier stellt sich zusätzlich die Frage, besteht während des Präfixwechsels eventuelle
Timing-Probleme die zu Ausfällen führen können?
Präfix-Delegation kommt nicht nur für ISP in Frage. Auch Unternehmen und sogar
Home-User können von diesem eleganten Verfahren profitieren.
1.2
Zielsetzung
Das Ziel der Arbeit ist es, das Präfix-Delegation-Verfahren unter typischen
Anwendungsszenarien zu testen und zu analysieren.
Hierbei sollen die zurzeit verfügbaren Implementierungen und Betriebssysteme auf die
optimale Unterstützung des Präfix-Delegation-Verfahrens, vom Server bis hin zu den
Endgeräten, untersucht und evaluiert werden. Wobei die Hauptzielsetzung im
Kundenbereich liegt.
1.3
Methodik
Die Arbeit wird in drei Phasen aufgeteilt. Die erste Phase beginnt mit dem theoretischen
Teil, indem in den entsprechenden RFCs, Fachartikeln und Literaturen recherchiert
wird, um die Präfix-Delegation-Problematik aufzuzeigen und ein Verständnis über das
Verfahren zu bekommen.
In der zweiten Phase wird ein hierarchisches Konzept aufgebaut, wobei anhand der
gewonnen Ergebnisse aus der ersten Phase, die Anwendungsszenarien festgelegt
werden. Um die Anwendungsszenarien testen zu können werden die Präfix-Delegation-
Anforderungen spezifiziert. Anschließend werden die Testkritiken aus den Präfix-
Delegation-Anforderungen hergeleitet. Als letzter Schritt werden die Testszenarien
anhand der Testkriterien spezifiziert.
Einleitung
4
In der dritten Phase kommt der praktische Teil, indem die definierten Testszenarien der
zweiten Phase getestet werden. Um die Testszenarien testen zu können, werden die
Implementierungen ausgewählt und die Testumgebungen definiert. Anschließend
werden die praktischen Teste durchgeführt. Zum Schluss werden die daraus
gewonnenen Ergebnisse evaluiert und bewertet.
1.4
Aufbau der Arbeit
Im zweiten Kapitel werden die Präfix-Delegation-Grundlagen und deren Spezifikationen
erläutert. Die Spezifikationen der Präfix-Delegation beinhalten das Nachrichten-Format,
IA-PD, Nachrichten-Austausch und Präfix-Renumbering.
Anschließend wird in dem dritten Kapitel ein generisches Konzept entwickelt, welches
hierarchisch aufgebaut wird, indem die Anwender, die Anwendungsszenarien, die
Anforderungen, die Testkriterien und zum Schluss die Testszenarien sukzessive
voneinander spezifiziert werden.
Im vierten Kapitel werden die im dritten Kapitel genannten Testserien praktisch
umgesetzt. Zuerst werden die Implementierungen, welche getestet werden sollen,
ausgewählt. Dann werden die Testumgebungen definiert. Anschließend kommt die
praktische Testphase. Zuletzt werden die Testergebnisse bewertet und auf die
Anwendungsszenarien zurück reflektiert.
Im letzten Kapitel wird eine Zusammenfassung der gesamten Arbeit aufgestellt, gefolgt
von einem Ausblick über die mögliche zukünftige Entwicklung des Präfix-Delegation-
Verfahrens.
Präfix Delegation Grundlagen
5
2
Präfix Delegation Grundlagen
In diesem Kapitel werden die Präfix-Delegation-Grundlagen erläutert. Zuerst werden die
Präfix-Delegation-Spezifikationen allgemein vorgestellt. Anschließend wird tiefer auf
das Verfahren eingegangen, indem Nachrichten-Format, IA-PD, Nachrichten-Austausch
und Präfix-Renumbering von Präfix-Delegation explizit erläutert werden.
Präfix-Delegation ist eine DHCPv6-Option. DHCPv6 ist ein Protokoll, welches durch den
DHCPv6-Server unterschiedliche Netzparameter an den DHCPv6-Client verteilt. DHCPv6
wird auch mit ,,Stateful Address Autoconfiguration" bezeichnet. DHCPv6 wird in
[RFC3315] ,,Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" spezifiziert. Was
wichtig zu wissen ist, dass DHCPv6 nicht mit DHCPv4 kompatibel ist, daher ist es
sinnvoll, eine DHCP-Implementierung zu entwickeln, die beide Protokolle gleichzeitig
bearbeiten kann. Für eine Vertiefung mit dem Thema DHCPv6, siehe [Hag09, S. 324].
2.1
Forschungsstand
Das Präfix-Delegation-Verfahren ist noch neu im Einsatz und wurde bis her kaum in
einer wissenschaftlichen Arbeit im Detail behandelt.
Die aktuellsten RFCs und Fachartikeln wurden zwar schon ca. im Jahr 2005
veröffentlicht, jedoch seither nicht weiter verfolgt. Erst in letzter Zeit wurde das Präfix-
Delegation-Verfahren wieder zum Gesprächsthema.
Bisher war es Dank der Übergangstechniken, wie IPv6-Tunnel (Gogo6, Sixxs), möglich
mittels IPv6 ins Internet zu gelangen. Der Kunde bekommt von dem Tunnelbroker ein
statisches IPv6-Präfix, welches mittels des Routers im LAN verteilt wird [Kap08].
Es gibt den Linux-Router-OpenWRT der viele IPv6-Tools mit sich bringt und die
zufälligen erzeugten Präfixe automatisch im LAN weiterverteilt. Das Skript im OpenWRT
wurde für Präfixe, die über IPv6-Tunnel verteilt werden, geschrieben. Für nativen IPv6-
DSL-Zugang muss im Skript einiges geändert werden [Kap12].
Es wurden mehrere Verfahren vorgeschlagen und implementiert, um die Ineffizienz der
manuellen Präfix-Delegation durch die automatische Präfix-Zuweisung zu lösen [KJH04].
Präfix-Delegation-Verfahren wurde mittels DHCPv6 in einem einfachen Testszenario
umgesetzt und implementiert, mit dem Ergebnis, dass die Präfix-Delegation-Option in
DHCPv6 die Zuweisung von IPv6-Präfixen an den DHCPv6-Client unterstützt [JH05].
Um die Bereitstellung und Verwaltung von Netzwerk-Diensten z. B. (VoIP, VPN,
Streaming) in IPv6-Netzen zu vereinfachen, wurde als Lösung das Multiple-Präfix-
Präfix Delegation Grundlagen
6
Delegation-Verfahren vorgeschlagen, in dem der End-User für jeden Dienst automatisch
ein separates Präfix bekommt [Shi04].
Die großen Internet-Provider haben damit begonnen Präfix-Delegation-Verfahren
einzusetzen, in dem sie /64 oder 56/-Präfixlänge an ihre Kunden verteilen
[News12][News 13].
2.2
Präfix Delegation Terminologie
DHCPv6 bietet viele Optionen, um Netzparameter an den Netzgeräten zu verteilen.
Präfix-Delegation ist eine der DHCPv6-Optionen, welche noch neu im Einsatz ist, wobei
das IPv6-Präfix von dem DHCPv6-Server an einen DHCPv6-Client zugewiesen wird.
Präfix-Delegation in DHCPv6 ist in [RFC 3633] ,,IPv6 Prefix Options for Dynamic Host
Configuration Protocol (DHCP) version 6" spezifiziert.
Die Abbildung 2.1 zeigt ein Beispiel wie Präfix-Delegation eingesetzt werden kann.
Abbildung
2.1: Präfix-Delegation-Topologie [RFC3633]
Im RFC3633 ist der DHCPv6-Server als Delegating-Router bzw. der DHCPv6-Client als
Requesting-Router spezifiziert.
Um die Fachwörter in dieser Arbeit zu vereinigen, werden die Begriffe Delegating-
Router bzw. Requesting-Router anstatt DHCPv6-Server und DHCPv6-Client benutzt.
Präfix Delegation Grundlagen
7
Der Präfix-Delegation-Prozess beginnt erst wenn der Requesting-Router eine DHCPv6-
Nachricht an den Delegating-Router schickt, indem dieser nach
Konfigurationsinformation erfragt. Der Delegating-Router mit vorkonfigurierten
Präfixen (z. B. dynamische Zuweisung eines Pooles) antwortet auf die empfangene
Nachfrage vom Requesting-Router mit dem vorhandenen Präfix. Das zugewiesene Präfix
wird dann vom Requesting-Router in Subpräfixe unterteilt und mittels IPv6-
Autokonfiguration den internen Netzwerkgeräten zugewiesen. Für die IPv6-
Autokonfiguration gibt es zwei Verfahren.
Zum einen die sogenannte SLAAC (Stateless Address Autoconfiguration) wobei die
Autokonfiguration über eine Router-Advertisement-Nachricht unter Verzicht eines
DHCPv6-Server erfolgt. Das SLAAC-Verfahren ist in [RFC 4862] ,,IPv6 Stateless Address
Autoconfiguration" spezifiziert, mehr über das Thema siehe [Hag09, S. 124].
Beim zweiten Verfahren, die sogenannte Statefull-Address-Autoconfiguration (DHCPv6),
erfolgt die Autokonfiguration über einen DHCPv6-Server. DHCPv6 wird in [RFC3315]
,,Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" spezifiziert, mehr über das
Thema DHCPv6 (siehe [Hag09, S. 324]).
2.3
Präfix Delegation Nachrichten Format
Die Präfix-Delegation-Option wird zwischen dem Delegating-Router und dem
Requesting-Router mittel DHCPv6-Nachrichten übertragen. In dieser Arbeit wird nur auf
die DHCPv6- Nachrichten, welche der Übertragung der Präfix-Delegation-Option dienen,
eingegangen. Für ein tieferes Verständnis über die DHCPv6- Nachrichten, siehe [Hag06,
S. 226]. Alle ausgetauschten DHCPv6- Nachrichten haben ähnliche, feste Header-Felder
und Optionsfelder (siehe Abbildung 2.2).
Msg-type
Transaction-id
Options
(variable)
32 bits
Abbildung
2.2: DHCPv6-Nachrichten-Format
Optionsfelder sind dafür zuständig zusätzliche Informationen und Parameter in der
DHCPv6- Nachricht zu übertragen. Die Präfix-Delegation-Option wird in diesem
Optionsfeld übertragen.
Präfix Delegation Grundlagen
8
2.4
Identity Association für Präfix Delegation
IA-PD:
IA-PD steht für Identity Association für Präfix Delegation und ist ein Konstrukt, indem
die Präfixe zwischen dem Delegating-Router und dem Requesting-Router identifiziert,
gruppiert und verwaltet werden. Jedes IA-PD hat eine zugeordnete IAID. IAID ist eine
eindeutige Identifizierung der IA-PD. Diese sollte einzigartig von dem Requesting-
Router erzeugt und gewählt werden. Damit der Delegating-Router ein Präfix an den
Requesting-Router zuweisen kann, erstellt der Requesting-Router für jedes Interface
eine IA-PD und weist diesem eine IAID zu. Jedes Interface eines Requesting-Routers
muss mindestens über eine IA-PD verfügen, um Präfixe vom Delegating-Router
anzufordern, damit dieser die Präfixe dem Interface des Requesting-Routers zuweisen
kann.
IA-PD ist äquivalent zu der IA, welche für die Zuweisung von IPv6-Adressen zuständig
ist [Hag06, S. 234]. Der Unterschied zwischen IA und IA-PD ist, dass IA-PD nicht nur zu
einem einzelnen Requesting-Router Interface zugeordnet sein muss, sondern auch zu
mehreren Interfaces zugeordnet sein kann. Dagegen darf IA nur zu einem einzelnen
Interface zugeordnet werden.
Nachdem der Requesting-Router eine IA-PD mit einer zugewiesen IAID erstellt hat,
schickt der Requesting-Router eine Solicit-Nachricht, die eine IA-PD Option enthält,
welche die IA-PD beschreibt, wobei der Requesting-Router sein Präfixwunsch in dem IA-
PD als Hinweis dem Delegating-Router zukommen lassen kann. Der Delegating-Router
wiederrum korrespondiert mit einer Advertise-Nachricht. [RFC3633]
IA-PD-Option:
IA-PD-Option wird benutzt um die IA-PD und die damit zugeordneten Parameter und
Präfixe zu übertragen. Abbildung 2.3 zeigt das Format einer IA-PD Option.
Präfix Delegation Grundlagen
9
Option-IA-PD
Option-Length
IAID
32 bits
T1
T2
IA-PD-Options
Abbildung
2.3: IA-PD-Option
Die IA-PD-Option erscheint im Optionsfeld der DHCPv6-Nachricht. Die DHCPv6-
Nachricht kann mehrere IA-PD-Optionen enthalten.
Jedes Präfix hat eine zugeordnete Valid-Lifetime und Preferred-Lifetime, welche dazu
dienen, dem Requesting-Router mitzuteilen, wie lange er das Präfix benutzen darf. Der
Requesting-Router kann diese vom Delegating-Router zugeordnete Lebensdauer
verlängern, indem er eine Anfrage an den Delegating-Router schickt.
Das T1-Feld wird benutzt, um zu zeigen, wann der Requesting-Router den Delegating-
Router kontaktieren muss um die Lebensdauer des Präfixes zu verlängern.
T2 muss immer länger als T1 sein und wird benutzt um ein neuen verfügbaren
Delegating-Router zu kontaktieren, für den Fall, dass der erste Delegating-Router
ausgefallen ist oder nicht mehr zur Verfügung steht.
Die Werte in den T1 und T2 Feldern demonstrieren die Delegating-Router Vorgaben.
Der Delegating-Router wählt T1 und T2 Zeiten, damit der Requesting-Router die
Lebensdauer der Präfixe in der IA-PD, bevor diese ablaufen, verlängern kann. Der
Requesting-Router setzt T1 und T2 auf Null, falls keine Vorgaben vom Delegating-Router
gegeben sind. Die empfohlenen Werte sind für T1, 50% der Preferred-Lifetime und für
T2, 80% der Valid-Lifetime.
Im Fall, dass der Requesting-Router T2 < T1 empfangen hat und beide Werte > 0 sind,
ignoriert dieser die IA-PD Option und bearbeitet den Rest der DHCPv6-Nachricht.
Das IA-PD hat keine bestimmte Lebensdauer. Wenn Valid-Lifetime aller Präfixe in einer
IA-PD ablaufen ist, gilt die IA-PD auch als abgelaufen. [RFC3633]
Präfix Delegation Grundlagen
10
IA-PD-Präfix-Option:
Die IA-PD-Präfix-Option wird benutzt, um das Präfix, welches mit dem IA-PD verknüpft
ist, zu spezifizieren. Die IA-PD-Präfix-Option wird in das IA-PD-Optionsfeld eingepackt.
Abbildung 2.4 zeigt das Format einer IA-PD-Präfix-Option.
Option-IAPREFIX
32 bits
Preferred-Lifetime
Option-Length
Valid-Lifetime
Prefix-Length
IPv6 Prefix
IAprefix-Options
Abbildung
2.4: IA-PD-Präfix-Option
Die Werte in den Feldern könnten auch dazu benutzt werden, indem der Requesting-
Router dem Delegating-Router seine Wünsche mitteilt. Die Werte könnten auch Nullen
enthalten, wenn der Requesting-Router keine bestimmten Wünsche hat. Der
Requesting-Router verwirft die vom Delegating-Router gesendeten Präfixen, wenn
Preferred-Lifetime > Valid-Lifetime ist. Im Falle dass nur T1 > Preferred-Lifetime ist,
empfängt der Requesting-Router das Präfix, ignoriert jedoch T1. Dagegen ignoriert der
Delegating-Router die vom Requesting-Router erfragte Lebensdauer, wenn Preferred-
Lifetime > Valid-Lifetime ist oder der erfragte Wert für T1 > Preferred-Lifetime ist.
Wenn Valid-Lifetime eines Präfixes den Wert Null erreicht hat, schickt der Requesting-
Router dem Delegating-Router eine neue Anfrage um ein neues Präfix anzufordern.
[RFC3633]
Präfix Delegation Grundlagen
11
2.5
Präfix Delegation Nachrichtenaustausch
Jeder Requesting-Router und Delegating-Router hat eine DUID (DHCP Unique Identifier).
Diese wird von den beiden Seiten benutzt um die DHCPv6-Nachrichten zwischen dem
Requesting-Router und dem Delegating-Router zu kennzeichnen und zu identifizieren.
Die DUID wird im Optionsfeld einer DHCPv6-Nachricht übertragen [Hag06, S. 234].
Die Kommunikation zwischen dem Requesting-Router und dem Delegating-Router
findet mittels DHCPv6-Nachrichten statt. Die DHCPv6-Nachrichten werden mit dem
Transportprotokoll UDP übertragen.
Der Requesting-Router sendet über seine Link-Lokale-Adresse eine Solicit-Nachricht mit
einer IA-PD-Option an die Server-Multicast Adresse (ff02::1:2), um den verfügbaren
Server bzw. Delegating-Router zu finden.
Der Delegating-Router, der die Anforderungen des Requesting-Routers erfüllen kann
und in der Lage ist das IPv6-Präfix zuzuweisen, antwortet mit einer Advertise-Nachricht
mit der IA-PD Option.
Der Requesting-Router kann mehrere Advertise-Nachrichten von mehreren Delegating-
Routeren empfangen und sucht den passenden Delegating-Router nach folgenden
Kriterien aus [Hag06, S. 235]:
x Die Nachricht mit der höchsten Server-Präferenz (Delegating-Router).
x Bekommt der Requesting-Router mehrere Advertise-Nachrichten, die dieselbe
Delegating-Router-Präferenz haben, wählt der Requesting-Router die Nachricht,
die die bevorzugten Konfigurationen enthält.
x Es ist auch möglich, dass der Requesting-Router einen Delegating-Router mit
niedriger Präferenz wählt, wenn der Server die passenden Konfigurationen
enthält.
Die Delegating-Router-Informationen werden bei dem Requesting-Router
abgespeichert. Für den Fall, dass ein Delegating-Router nicht korrespondiert, wird der
Requesting-Router mittels Rebind-Nachricht einen anderen Delegating-Router
auswählen.
Der Delegating-Router wählt die Präfixe aus, die er dem Requesting-Router zuweisen
möchte. Es gibt unterschiedliche Mechanismen wie der Delegating-Router die Präfixe
auswählt, z. B. mittels eines Pooles oder durch einen externen autorisierten Server. Der
Delegating-Router kann die Informationen in der IA-PD-Option der Solicit- Nachricht
vom Requesting-Router benutzen, um Präfixe auszuwählen. Wenn der Requesting-
Router den Delegating-Router identifiziert hat, schickt der Requesting-Router eine
Request-Nachricht, die eine oder mehrere IA-PD-Optionen enthält. Der Delegating-
Router antwortet zuletzt mit einer Reply-Nachricht, welche die Präfixe in den IA-PA-
Optionen enthält (siehe Abbildung 2.5).
Präfix Delegation Grundlagen
12
Delegating
Router
Requesting
Router
Delegating
Router
Delegating
Router
Solicit Message (IA-PD)
Solicit Message (IA-PD)
Solicit Message (IA-PD)
Advertise Messgae (IA-PD)
Advertise Messgae (IA-PD)
Advertise Messgae (IA-PD)
Request Message (IA-PD)
Reply Mesaage (IA-PD(
Prefix
))
Renew Message (IA-PD(
Prefix
))
Reply Mesaage (IA-PD(
Prefix
))
Timer Expiring
Prefix Assigned
Abbildung
2.5: Präfix-Delegation-Nachrichtenaustausch
Bevor die Lebensdauer des Präfixes endet, schickt der Requesting-Router das Präfix in
einer IA-PD-Option mit einer Renew- oder Rebind-Nachricht an den Delegating-Router.
Der Delegating-Router sendet das Präfix mit einer aktualisierten Lebensdauer zurück.
Unter bestimmten Umständen überprüft der Requesting-Router mit einer Rebind-
/Reply-Nachricht, ob der Delegating-Router über eine gültige Bindung zu dem
Requesting-Router hat. [RFC3633]
Präfix Delegation Grundlagen
13
2.6
Präfix Renumbering
Präfix-Renumbering bezeichnet den Prozess des Präfixwechsels in einem IPv6-
Netzwerk, indem alle Netzgeräte das alte Präfix durch ein neues Präfix ersetzt
bekommen. Präfix-Renumbering ist in [RFC4192] "Procedures for Renumbering an IPv6
Network without a Flag Day" definiert.
Für einen im LAN problemlosen Präfixwechsel spielt Router-Advertisement eine
wichtige Rolle. SLAAC mittels Router-Advertisement wird im Vergleich zu den anderen
Methoden als die meist effiziente Methode für den Präfixwechsel im LAN angesehen,
wobei die Timing-Parameter (Preferred-Lifetime, Valid-Lifetime, T1, RA-Interval)
berücksichtigt werden müssen [Des03, Chapter 3].
Um ein besseres Verständnis über die Präfix-Renumbering zu bekommen, werden
zunächst die Lifetime-Zustände einer IPv6-Adresse, die mittels SLAAC generiert werden,
verdeutlicht (siehe Abbildung 2.6).
Valid
Preferred
Deprecated
Invalid
Preferred Lifetime
Valid Lifetime
Abbildung
2.6: Lifetime-Zustände einer IPv6-Adresse
Eine IPv6-Adresse nimmt entweder den Valid-Zustand oder den Invalid-Zustand ein. Der
Valid-Zustand wird wiederrum in die beiden Zustände, Preferred-Zustand und
Deprecatde-Zustand unterteilt.
Im Preferred-Zustand ist das Präfix im normalen Zustand und wird für die existierenden
und neuen Verbindungen benutzt. Die Preferred-Lifetime eines Präfixes wird im
Preferred-Lifetime Feld in der IA-PD-Präfix-Option verwaltet. So lange das Präfix im LAN
im Preferred-Zustand ist, bleibt die IPv6-Adresse für die existierenden und neuen
Verbindungen aktiv. Läuft das Preferred-Lifetime eines Präfixes ab, erreicht das Präfix
den Deprecated-Zustand, in der das Präfix nur für existierende Verbindungen benutzt
Präfix Delegation Grundlagen
14
wird, für die neuen Verbindungen aber das Präfix nicht mehr benutzt werden darf. So
lange das Präfix im LAN im Deprecated-Zustand ist, bleibt die IPv6-Adresse nur für
existierende Verbindungen aktiv. Preferred-Zustand und Deprecated-Zustand
zusammen bilden den Valid-Zustand. Das Valid-Lifetime eines Präfixes wird im Valid-
Lifetime Feld in der IA-PD-Präfix-Option verwaltet. Läuft das Valid-Lifetime eines
Präfixes ab, erreicht das Präfix dem Invalid-Zustand, in der das Präfix weder für
existierende noch für neue Verbindungen benutzt werden darf. Das Interface hat dem
entsprechend kein Präfix bzw. keine IPv6-Adresse mehr.
In dem Präfix-Delegation-Verfahren handelt es sich um dynamische Präfixe die sich
periodisch ändern, wobei der Wechsel von einem alten Präfix auf ein neues Präfix
automatisch und unterbrechungslos stattfinden soll. [Bov12]
Im [RFC4192] ,,Procedures for Renumbering an IPv6 Network without a Flag Day", ist der
Präfix-Renumbering Prozess nur sehr allgemein und oberflächlich definiert und geht
nicht auf die spezifischen Anforderungen unterschiedlicher IPv6-Netzwerkbereiche ein.
Bei einem Präfixwechsel (Renumbering) sollen die Endgeräte ihre Verbindungen nicht
verlieren, der Übergang vom alten zum neuen Präfix soll automatisch und ohne Ausfälle
erfolgen.
Das Prinzip von dem Präfix-Renumbering, wird in den folgenden Schritten erklärt
[Bov12]:
1- Wenn die Preferred-Lifetime des alten Präfixes den Wert Null erreicht, soll ein neues
Präfix mit normaler Preferred-Lifetime zugewiesen werden. Die Abbildung 2.7 zeigt,
wann das neue Präfix zugewiesen werden soll.
Deprecated
Preferred Lifetime
Valid Lifetime
Preferred Lifetime
Valid Lifetime
Neues Präfix
Altes Präfix
Deprecated
Abbildung
2.7: Der Zeitpunkt an dem das neue Präfix zugewiesen soll
Präfix Delegation Grundlagen
15
2- Die LAN-Geräte erhalten dem entsprechend das neue Präfix zusätzlich zum alten
vorhandenen Präfix.
3- Das alte Präfix wird nach Ablauf der Preferred-Lifetime als Deprecated vermerkt und
ist damit nur für existierende Verbindungen aktiv.
4- Das neu Präfix, welches sich in dem Preferred-Zustand befindet, ist für neue
Verbindungen zuständig.
5- Nach einer gewissen Zeit, wenn die Valid-Lifetime des alten Präfixes abläuft, werden
alle Verbindungen zum neuen Präfix wechseln und das alte Präfix erreicht den Invalid-
Zustand.
Generisches Konzept
16
3
Generisches Konzept
In diesem Kapitel wird ein Konzept aufgebaut, um das Präfix-Delegation-Verfahren auf
seine Funktionalität testen zu können.
Dazu werden die Präfix-Delegation-Anwender und die Rollen deren Komponenten
aufgeführt. Hieraus werden die typischen Präfix-Delegation-Anwendungsszenarien
definiert. Anschließend werden die Präfix-Delegation-Anforderungen spezifiziert.
Anhand der spezifizierten Anforderungen werden die Testkriterien hergeleitet. Zuletzt
werden die Testszenarien anhand der festgelegten Testkriterien aufgestellt.
3.1
Präfix Delegation Anwender
Das Konzept basiert auf zwei Fragestellungen:
1- Für wen ist das Präfix-Delegation-Verfahren relevant bzw. wer benötigt Präfix-
Delegation?
2- Wie unterscheiden sich die Rollen der einzelnen Komponenten, welche Präfix-
Delegation durchführen?
Die Präfix-Delegation-Anwender können in zwei Bereiche klassifiziert werden. Der ISP-
Bereich und der Kundenbereich. In jedem Bereich gibt es Komponenten, welche
spezifische Teile des Präfix-Delegation-Verfahrens übernehmen (siehe Abbildung 3.1).
ISP
Kunde
Geschäftskunde
Privatkunde
Hosts
Delegating-Router
Requesting-Router
delegate
request
distribute
delegate
autoconfiguration
WAN
LAN
Rollen
----------------------
Rollen
-----------------------------
Rollen
----------------------
subnetting
Abbildung
3.1: Präfix-Delegation-Anwender und Rollen der Komponenten
Generisches Konzept
17
ISP-Bereich: Die Hauptverantwortung eines ISP ist, seine Kunden mit Netzparamenten
und IP-Adressen zu vorsorgen. In dem ISP-Bereich gibt es den Delegating-Router,
welcher die folgende einzige Rolle übernimmt:
o delegate: Mit der, der Delegating-Router Präfixe dem Requesting-Router
zuweist.
Kundenbereich: In dem Kundenbereich gibt es den Requesting-Router, welcher
mehrere Rollen übernimmt. Deswegen gibt es auch in diesem Bereich mehrere
Herausforderungen. Die Rollen, die der Requesting-Router übernimmt sind wie folgt:
o request: Mit der, der Requesting-Router das Präfix vom Delegating-Router
anfordert.
o subnetting: Mit der, der Requesting-Router das erhaltene Präfix in Subpräfixe
unterteilt.
o distribute: Mit der, der Requesting-Router das Subpräfix im LAN verteilt.
o delegate: Die Rolle delegate wird zur zweistufigen Präfix-Delegation benutzt. Der
Requesting-Router übernimmt die Rollen eines Delegating-Routers und wird
somit zu einem Sub-Delegating-Router.
Im LAN-Bereich übernehmen die Endgeräte die Rolle "autoconfiguration" in dem sie
globale IPv6-Adressen generieren.
Die Rollen der einzelnen Komponenten werden in jedem Anwendungsszenario in einer
Tabelle präsentiert.
Tabelle 3.1 zeigt ein Exemplar, wobei eine aktive Rolle mit einem Plus markiert und eine
passive Rolle mit einem Minus markiert wird.
ISP-Bereich
Æ
Æ
Å
Å Kundenbereich Æ
Æ
Å
Å LAN
Delegating-Router
Rolle
Requesting-Router
Rolle
Endgerät
Rolle
delegate
+
Request
+
autoconfiguration
+
Subnetting
+
distribute
-
delegate
-
Tabelle
3.1: Rollen der Komponenten (Exemplar)
In dem Kundenbereich gibt es zwei Arten von Kunden:
x Privatkunde: Der Begriff ,,Privatkunde" wird für den Home-User benutzt. Der
Privatkunde hat bestimmte Anforderungen, die in Betracht genommen werden
müssen. Der Privatkunde verlangt das sogenannte ,,Plug & Play", in dem er seine
Geräte an das Netz anschließt und sich um keinerlei Konfigurationen kümmern
muss. Der Privatkunde verlangt das sogenannte ,,Always ON", in dem die Geräte
des Kunden permanent und ohne jegliche Verbindungsstörungen online
Details
- Seiten
- Erscheinungsform
- Erstausgabe
- Jahr
- 2014
- ISBN (PDF)
- 9783958209978
- ISBN (Paperback)
- 9783958204973
- Dateigröße
- 2.9 MB
- Sprache
- Deutsch
- Institution / Hochschule
- Technische Hochschule Köln, ehem. Fachhochschule Köln
- Erscheinungsdatum
- 2015 (September)
- Schlagworte
- dhcpv6-präfix-delegation
