Trust-by-Wire in paketvermittelnden IP

Universität Rostock
Fakultät für Informatik und Elektrotechnik
Institut für Angewandte Mikroelektronik und Datentechnik
Großer Beleg
Trust-by-Wire in paketvermittelnden
IP-Netzen: Migration des
IPclip-Mechanismus von IPv4 nach
IPv6
Bearbeiter:
cand. ing. Grit Rhinow
8. September 2008
Betreuer
Dipl.-Ing. Jens Rohrbeck
Prof. Dr. Dirk Timmermann
Inhaltsverzeichnis
Abbildungsverzeichnis
IV
Abkürzungsverzeichnis
VI
Literaturverzeichnis
VII
1 Einleitung
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Aufbau der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1
1
2 Grundlagen
2.1 IPv6 - das neue Internet Protokoll . . . .
2.1.1 Optionen in Erweiterungsheadern
2.2 Der IPclip Mechanismus . . . . . . . . .
2.3 Vorbereitende Aufgaben . . . . . . . . .
.
.
.
.
3
3
4
6
8
3 MTU Adaptation Module
3.1 Konzept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 Umsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3 Verifikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
9
13
14
4 PPPoE MTU Adaptation Module
4.1 Konzept und Umsetzung . . . . . . . . . . . . . . . . . . . . . . . . .
4.2 Verifikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
16
17
5 Parser
5.1 Konzept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2 Umsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3 Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
19
21
21
6 Option Verification Module
6.1 Konzept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2 Umsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.3 Verifikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
22
25
27
7 Additional Information Adder
28
II
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Inhaltsverzeichnis
7.1
Konzept und Umsetzung . . . . . . . . . . . . . . . . . . . . . . . . .
28
8 Additional Information Remover
8.1 Konzept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
32
9 Zusammenfassung und Ausblick
9.1 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
34
III
Abbildungsverzeichnis
2.1
2.2
2.3
2.4
Struktur des IPv6 Headers . . . . .
Aufbau einer IP-Option . . . . . .
Zieloptionsheader mit IPclip-Option
IPclip Modul . . . . . . . . . . . .
.
.
.
.
4
5
6
7
3.1
3.2
3.3
Syntaxdiagramm MAM . . . . . . . . . . . . . . . . . . . . . . . . . .
ICMP Fehlernachricht . . . . . . . . . . . . . . . . . . . . . . . . . .
Pseudoheader zur Berechnung der ICMP Prüfsumme . . . . . . . . .
10
11
12
4.1
4.2
4.3
Syntaxdiagramm PAM . . . . . . . . . . . . . . . . . . . . . . . . . .
Aufbau der PPPoE Session Phase Nachricht . . . . . . . . . . . . . .
Aufbau und Blockschaltbild des PAM . . . . . . . . . . . . . . . . . .
16
17
17
5.1
5.2
5.3
Blockschaltbild des Parsers . . . . . . . . . . . . . . . . . . . . . . . .
Syntaxdiagramm des Parsers . . . . . . . . . . . . . . . . . . . . . . .
Aufbau des Parsers . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
19
20
6.1
6.2
6.3
6.4
Syntaxdiagramm des OVM . . . . . . . . . . . . . . . . . . . . . .
Zustandsautomat des OVM - Suche nach einem Zieloptionsheader
Aufbau des OVM . . . . . . . . . . . . . . . . . . . . . . . . . . .
Von IPclip unterstützte Ortsinformationen . . . . . . . . . . . . .
.
.
.
.
23
24
25
27
7.1
7.2
7.3
. . . . . . . .
. . . . . . . .
Ortsinforma. . . . . . . .
. . . . . . . .
28
29
7.4
Blockschaltbild von AIA . . . . . . .
Syntaxdiagramm AIA . . . . . . . .
Zustandsautomat für das Hinzufügen
tionen . . . . . . . . . . . . . . . . .
Aufbau des AIA . . . . . . . . . . . .
30
31
8.1
8.2
Syntaxdiagramm des AIR . . . . . . . . . . . . . . . . . . . . . . . .
Aufbau des AIR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
33
IV
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. . . . . . . . . .
. . . . . . . . . .
von zusätzlichen
. . . . . . . . . .
. . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Abkürzungsverzeichnis
ADSL . . . . . . . . .
AIA . . . . . . . . . . .
AIR . . . . . . . . . . .
BRAS . . . . . . . . .
DSLAM . . . . . . .
EOF . . . . . . . . . . .
FIFO . . . . . . . . . .
FPGA . . . . . . . . .
FSM . . . . . . . . . . .
GPS . . . . . . . . . . .
IANA . . . . . . . . .
ICMP . . . . . . . . .
IP . . . . . . . . . . . . .
IPclip . . . . . . . . . .
IPoE . . . . . . . . . .
IPv4 . . . . . . . . . . .
IPv6 . . . . . . . . . . .
IPv6CP . . . . . . . .
LAN . . . . . . . . . . .
LCP . . . . . . . . . . .
MAC . . . . . . . . . .
MAM . . . . . . . . . .
MRU . . . . . . . . . .
MTU . . . . . . . . . .
NSN . . . . . . . . . . .
OVM . . . . . . . . . .
PAM . . . . . . . . . .
PMTUD . . . . . . .
PPP . . . . . . . . . . .
PPPoE . . . . . . . .
RFC . . . . . . . . . . .
RSM . . . . . . . . . .
SOF . . . . . . . . . . .
SSM . . . . . . . . . . .
TCP/IP . . . . . . .
Asymmetric Digital Subscriber Line
Additional Information Adder
Additional Information Remover
Broadband Remote Access Server
DSL Access Multiplexer
End of Frame
First In First Out
Field Programmable Gate Array
FIFO State Machine
Global Positioning System
Internet Assigned Numbers Authority
Internet Control Message Protocol
Internet Protocol
Internet Protocol Calling Line Identification Presentation
Internet Protocol over Ethernet
Internet Protocol Version 4
Internet Protocol Version 6
IPv6 Control Protocol
Local Area Network
Link Control Protocol
Medium Access Control
MTU Adaptation Module
Maximum Receive Unit
Maximum Transfer Unit
Nokia Siemens Networks
Option Verification Module
PPPoE MTU Adaptation Module
Path MTU Discovery
Point to Point Protocol
PPP over Ethernet
Request For Comment
Read State Machine
Start of Frame
Send State Machine
Transmission Control Protocol/Internet Protocol
V
TLV . . . . . . . . . . .
UDP . . . . . . . . . .
VLAN . . . . . . . . .
VoIP . . . . . . . . . .
Type - Length - Value
User Data Protocol
Virtual LAN
Voice over IP
VI
Literaturverzeichnis
[1] RFC 1332 - IPCP, 1992.
[2] RFC 2460 - IPv6 Specification, 1998.
[3] RFC 2472 - IPv6 over PPP, 1998.
[4] RFC 4443 - ICMPv6 für IPv6, 2006.
[5] Hans Peter Dittler. IPv6 - das neue Internet-Protokoll Technik, Anwendung,
Migration. dpunkt - Verlag, 1998.
[6] Grit Rhinow. Trust-by-Wire in paketvermittelnden IP-Netzen: Analyse und Konzept zur Migration des IPclip Mechanismus von ipv4 nach ipv6. Technical Report,
Universität Rostock, Institut für Angewandte Mikroelektronik und Datentechnik,
2008.
[7] Harald Widiger, Stephan Kubisch, Peter Danielis, Jens Schulz, and Universität
Rostock. Ip-clip. Technical Report, Universität Rostock, Fakultät für Informatik
und Elektrotechnik, Institut für Angewandte Mikroelektronik und Datentechnik,
2007.
VII
1 Einleitung
Das Internet, wie es heute genutzt wird, hat sich in den vergangenen Jahren zu einem
Massenmedium entwickelt. Bei dem heute gebräuchlichen Internet Protokoll Version
4, kurz IPv4, werden 32-Bit Adressen verwendet, mit dem etwas mehr als 4 Milliarden
logische Adressen vergeben werden können. Doch es zeigte sich sehr schnell, dass
durch den Zuwachs des Internets diese 4 Milliarden Adressen bald ausgeschöpft sein
werden. Ein weiterer Gesichtspunkt ist, dass diese Adressen innerhalb eines Netzwerks
sehr willkürlich vergeben werden. Eine IP-Adresse ist keine eindeutige Adresse wie
zum Beispiel eine Telefonnummer, die für einen Benutzer immer gleich bleibt. Bedingt
durch die Adressen-Knappheit des IPv4 werden Adressen deswegen in einem Netz
dynamisch vergeben. Dies betrifft hauptsächlich die privaten Anwender, der seine
IP-Adresse vom Provider zugeteilt bekommt. Deswegen wurde in den vergangenen
Jahren an einem neuen Internet-Protokoll mit einem größeren Adressbereich und
erweiterten Funktionen gearbeitet, dem Internet Protokoll Version 6. Mit diesem
neuen Protokoll ist es möglich, etwas mehr als 340 Sextillionen, also 340·1036 , logische
Adressen zu vergeben. In einigen Ländern der Welt, vor allem im asiatischen Raum,
wurde das Internet bereits auf IPv6 umgestellt.
1.1 Motivation
Zur Erhaltung der Sicherheit im Internet wurde an der Universität Rostock in Zusammenarbeit mit Nokia Siemens Networks (NSN) ein IPclip (Internet Protocol Calling
Line Identification Presentation) Mechanismus entwickelt, der Internet-Paketen eine
zusätzliche Ortsinformation hinzufügt oder eine bestehende Ortsinformation auswertet, um dem Empfänger des Datenpakets eine Bestätigung über die Vertrauenswürdigkeit des Paketes zu liefern. Dieser IPclip Mechanismus ist bereits für IPv4 implementiert. Da ein Wechsel von IPv4 auf IPv6 in den nächsten Jahren stattfinden wird,
wurde im Rahmen eines Kleinen Beleges [6] eine Analyse zur Migration durchgeführt.
Im Rahmen dieser Arbeit soll das Konzept entsprechend umgesetzt und verifiziert
werden.
1.2 Aufbau der Arbeit
Dieser Beleg baut auf der Arbeit des Kleinen Beleges von mir und erläutert zunächst
die Grundlagen von IPv6 und die wesentlichen Neuerungen, die Einfluß auf das Kon-
1
zept dieser Arbeit haben. Dabei wird auf die Verwendung von Erweiterungsheadern
hingewiesen und wie Optionen unter IPv6 integriert werden können.
Danach wird das System IPclip vorgestellt und das Zusammenwirken der einzelnen Module kurz vorgestellt. Nach dieser kurzen Einführung werden in den Kapiteln
die Module einzeln vorgestellt. Dabei wird zunächst die prinzipielle Wirkungsweise
der Module erklärt und im Anschluss werden die Änderungen von IPv4 auf IPv6
vorgestellt. Am Ende jeden Kapitels soll eine Auswertung für die einzelnen Module
erfolgen.
Nachdem alle Module erarbeitet wurden, erfolgt eine kurze Zusammenfassung der
Ergebnisse und es erfolgt ein Ausblick auf die Anwendbarkeit des Systems für die
Zukunft.
2
2 Grundlagen
2.1 IPv6 - das neue Internet Protokoll
Durch die explosionsartige Verbreitung des Internets als Massenmedium werden die
IPv4-Adressen in wenigen Jahren nicht mehr ausreichen. Doch die Adressen-Knappheit
ist nicht der einzige ausschlaggebende Punkt, der zur Einführung des neuen InternetProtokolls IPv6 geführt hat. Zunehmend wurden neue Sicherheitsaspekte interessant
oder Funktionen des alten IPv4 erwiesen sich als unpraktisch und zu überladen. So
wurde der ursprüngliche IPv4 Header überarbeitet.
Während der IPv4 Header aufgrund von Optionen noch eine variable Größe besaß,
zeichnet sich der IPv6 Header nun durch eine feste Länge aus. Die IP-Optionen dienen zur Steuerung oder Priorisierung eines IP-Frames. Da viele Optionen allerdings
nicht verwendet wurden, da die Frames durch ihre Sonderbehandlung in den Routern
mitunter nicht schnell genug verarbeitet werden konnten, wurde das Optionsfeld des
alten IPv4 Headers nicht mehr in IPv6 implementiert. Da aber die Verwendung von
Optionen nicht vollständig außen vorgelassen werden sollte, wurden Erweiterungsheader eingeführt. Diese Erweiterungsheader übernehmen einige der wichtigsten Optionen. So gibt es z.B. unter IPv6 einen Routingheader, der die Routingoption von
IPv4 übernimmt und die Route des Frames genau vorgibt. Weiterhin gibt es einen
Fragmentierungsheader, der bei übergroßen IP-Frames vorgibt, an welcher Stelle der
Frame in kleinere Abschnitte geteilt werden soll. Gibt es weitere Benutzer spezifische Optionen, können diese in einen Optionsheader gepackt werden. Es gibt zwei
Arten von Optionsheadern. Den Hop-by-Hop-Optionsheader und den Zieloptionsheader. Beim Hop-by-Hop-Optionsheader sind die Optionen in jedem Router, den sie
passieren von Bedeutung und müssen auch in jedem Router angewandt werden. Jedoch in einen Zieloptionsheader direkt vor den Nutzdaten verpackt, sind die Optionen
nur für den letzten Router von Bedeutung. Zunächst folgt eine genauere Betrachtung
des IPv6-Headers.
3
Abbildung 2.1: Struktur des IPv6 Headers
Das einzige Feld, mit der gleichen Position und Bedeutung wie im IPv4-Header,
ist das Versionsfeld. Bei IPv6 steht hier eine 6. Danach folgt ein 8 Bit breites Klassen
Feld, in dem die Priorisierung des IP-Paketes angegeben wird. Dieses Feld hat die
gleiche Bedeutung wie das Traffic Class Feld bei IPv4. Im Anschluss an das Klassenfeld folgt das Flusslabelfeld, welches 20 Bit breit ist. Dieses Feld dient der Identifizierung von mehreren IP-Paketen, wenn diese IP-Pakete zusammengehören und an
einen Empfänger gesendet werden. Dies findet vor allem in der Übertragung von Videostreams Anwendung. Danach folgt die 16 Bit breite Nutzdatenlänge. Im Vergleich
zu IPv4 wird hier nur die Länge der Nutzdaten angegeben und nicht die Länge des
gesamten Pakets, da bei IPv6 bereits die Header Länge bekannt ist. Die Nutzdatenlänge ergibt sich aus der Länge aller Erweiterungsheader und dem Folgeprotokoll. Im
Next Header Feld wird angezeigt, ob dem IPv6 Header Erweiterungsheader oder das
Folgeprotokoll folgen. Das letzte Feld vor den 128-Bit Adressen ist die Hop-Grenze.
Dieser Wert zeigt an, nach wie vielen Hops das IPv6-Paket von einem Router gelöscht
werden kann. In jedem Router wird dieser Wert um eins dekrementiert, damit das
Paket bei zu langer Verweildauer im Netzwerk verworfen werden kann. Damit soll
vor allem der Überlastung des Kanals vorgebeugt werden.
2.1.1 Optionen in Erweiterungsheadern
Wie bereits in Abschnitt 2.1 erwähnt, werden Optionen aus IPv4 unter IPv6 in Erweiterungsheader gepackt. Das hat zum einen den Vorteil, dass der Header unabhängig
4
von den Optionen immer die gleiche Länge hat. Als nächster Vorteil sei erwähnt,
dass die Optionen mehr Platz haben als im IPv4 Header, wo die Optionen in 40
Byte rein passen mussten. Doch der wahrscheinlich wichtigste Aspekt ist, dass die
Optionen im Zweifelsfall vom Router nicht beachtet werden müssen. Dabei spielt
auch die Reihenfolge der Erweiterungsheader eine wichtige Rolle. Laut Spezifikation
ist die Reihenfolge der Erweiterungsheader frei vom Sender wählbar, es wird jedoch
eine Reihenfolge empfohlen.
1. IPv6 Header
2. Hop-by-Hop Optionsheader
3. Zieloptionsheader (1)
4. Routingheader
5. Fragmentheader
6. Authentifizierungsheader
7. Zieloptionsheader (2)
8. Header der höheren Schicht, z.B. TCP oder UDP
Der Zieloptionsheader ist dabei der einzige Header, der mehr als einmal in einem
IP-Paket vorkommen kann. Die Position des Zieloptionsheaders gibt dabei vor, welche
Router die Erweiterungsheader beachten müssen. Befindet sich der Zieloptionsheader zum Beispiel direkt vor den Nutzdaten, so soll nur der letzte Router vor dem
Empfänger die Optionen bearbeiten, während die Optionen in einem Hop-by-HopOptionsheader von jedem Router, also bei jedem Hop, die Optionen verwerten muss.
Für das Einbringen von bereits bekannten Optionen dienen der Hop-by-Hop-Optionsheader
und der Zieloptionsheader. Der Aufbau der Optionen kann auf zwei Arten erfolgen.
Bei der ersten Art der Option handelt es sich um 1 Byte und dieses Byte stellt die
gesamte Option dar. Die jedoch weiter verbreitete Art ist nach dem Type-LengthValue-Format (TLV) aufgebaut.
Abbildung 2.2: Aufbau einer IP-Option
In Abbildung 2.2 ist der Aufbau solch einer Option dargestellt. Das erste Byte ist
das Type Feld und gibt Auskunft über die Art von IP-Option. Im nächsten Byte
befindet sich die Länge der IP-Option und wird in Byte angegeben. Danach folgen
5
dann die Optionsdaten. Für IPclip werden die Ortsinformationen in einen Zieloptionsheader nach dem TLV-Format untergebracht. Eine genau Diskussion über die
Auswahl eines geeigneten Erweiterungsheaders bietet in [6]. Der Aufbau eines Zieloptionsheaders mit der IPclip-Option ist in Abbildung 2.3 dargestellt.
Abbildung 2.3: Zieloptionsheader mit IPclip-Option
Im Abschnitt 2.2 soll der IPclip Mechanismus erklärt werden.
2.2 Der IPclip Mechanismus
Der IPclip Mechanismus wurde entwickelt, um IP-Paketen, die ins Internet gesendet werden, eine Ortsinformation hinzuzufügen oder bestehende Ortsinformationen
auszuwerten. Unter IPv4 geben die IP-Adressen keinen Aufschluss darüber, wo das
Paket herkommt. Bedingt durch die Adressen-Knappheit werden IP-Adressen durch
den Provider dynamisch vergeben. Der Internetbenutzer bekommt somit keine feste
Nummer, wie er z.B. eine feste Telefonnummer besitzt. Damit kann der Empfänger
nichteindeutig feststellen, woher das Paket kommt. Der IPclip Mechanismus soll dem
IP-Paket eine feste Ortsinformation hinzufügen. Somit weiß der Empfänger genau,
wo das Paket herkommt. Einsatzmöglichkeiten für IPclip gibt es mehrere. So sollen
z.B. bei Notrufen über das Internet jedem versendeten Paket eine feste GPS Ortsinformation hinzugefügt werden, damit der Rettungsdienst die genauen Koordinaten
des Hilferufenden erhält und somit schnellstmöglich am Einsatzort eintreffen kann.
Eine andere Möglichkeit für den Einsatz ist die Verhinderung vom sogenannten Phishing oder Spam. Damit der Empfänger weiß, ob er wirklich von seiner Bank Daten
erhält oder vielleicht von einem Hacker, der seine Bankdaten ausspionieren möchte,
kann IPclip eine Aussage über den Aufenthaltsort des Senders geben. Der Empfänger bekommt die Bestätigung, dass sich der Empfänger wirklich dort befindet, wo
er vorgibt zu sein oder dass das Paket nicht vertrauenswürdig ist. Somit kann der
Empfänger entscheiden, ob er diesem Paket vertrauen möchte.
6
Das IPclip-System befindet sich direkt am Zugangspunkt des Nutzers für das Zugangsnetzwerk, das ist in den meisten Fällen auf den Linecards eines DSLAM (Digital Subscriber Line Access Multiplexer), weil diese genauere Angaben über Access-ID
und Port der jeweils angeschlossenen Teilnehmer besitzen. Dargestellt wird das Gesamtsystem in der Abbildung 2.4.
Abbildung 2.4: IPclip Modul
Das IPclip Modul setzt sich zusammen aus dem MTU Adaptation Module, welches
überprüft, ob die Maximale Transfer Unit (MTU) eines Ethernet-Netzwerkes durch
das Hinzufügen von zusätzlichen Informationen überschritten wird. MAM hat die
Aufgabe, die MTU bei einer IP over Ethernet (IPoE) Verbindung anzupassen. Soll
das Internet-Paket über eine Point-to-Point-Protocol Verbindung über Ethernet, also PPPoE, verschickt werden, übernimmt das PPPoE MTU Adaptation Module die
Anpassung der MTU eines Datenpakets. Nachdem die MTU des Datenpakets angepasst wurde, wird der Frame an den Parser übergeben, der aus dem Internet-Paket
eine Schlüsselinformation herausfiltert. Die Schlüsselinformation setzt sich aus einem
VLAN-Tag und der Quelladresse des IP-Pakets zusammen. Das VLAN-Tag ist 12Bit lang und markiert die Zugehörigkeit eines Teilnehmers zu einem virtuellen lokalen
Netzwerk innerhalb eines größeren Netzwerkes. Der Parser sucht im Datenframe nach
solchen VLAN-Tags, wovon es bis zu 2 Stück geben kann. Findet der Parser mehr
als 1 VLAN-Tag, so benutzt der Parser das erste VLAN-Tag. Aufgrund der 128Bit breiten Quelladresse des IPv6-Headers und des 12-Bit breiten VLAN-Tags ergibt
sich eine Schlüsselinformation von 140 Bit. Diese 140-Bit breite Schlüsselinformation wird im Parser mit einem bestehenden Schlüsselsatz aus einem Speicher, der
aus RAM-Blöcken besteht, verglichen. Wenn ein Schlüssel mit einem Schlüssel aus
dem Speicher identifiziert werden kann, so wird eine 16-Bit breite Portinformation an
den Additional Information Adder (AIA) übergeben. Danach wird der Frame an das
Option Verification and Identification Module weiter gegeben. Das OVM durchsucht
dann den Frame nach IP-Optionen mit Ortsinformationen und kennzeichnet diese
als vertrauenswürdig oder nicht vertrauenswürdig. Die Position der letzten gültigen
Ortsinformation wird in der Variablen Valid IP Option gespeichert. Wenn in ein IPPaket keine weiteren Optionen hinzugefügt werden können, dann setzt das OVM
das discard-Signal, welches dem AIA mitteilt, dass dieser Frame verworfen werden
7
kann. Der Additional Information Adder soll dem Paket, sofern keine gültige Ortsinformation vorhanden ist, eine IPclip Option hinzufügen und ungültige Optionen
löschen. Danach kann das IP-Paket versendet werden. Im Downstream soll IPclip
bestehende Ortsinformationen gegebenenfalls entfernen. Der Empfänger bekommt
danach nur eine Bestätigung, ob dieses Paket vertrauenswürdig ist oder nicht. Die
reine Ortsinformation ist meist jedoch für den Empfänger uninteressant. Der Additional Information Remover (AIR) entfernt alle IPclip Orstinformationen, sofern er
in das System integriert ist.
2.3 Vorbereitende Aufgaben
Bevor die einzelnen Module angepasst werden konnten, musst zu Testzwecken die
utils pack.vhd an IPv6 angepasst werden. In dieser Datei wurde eine Prozedur entwickelt, mit der für die Simulation der einzelnen Module ein IPv6-Frame generiert
werden sollte. In dieser Datei wird ein IPv6-Frame generiert und der Nutzer soll
in der Testbench vorgeben können, ob dieser Frame die MTU erreicht und ob dieser
Frame bereits Erweiterungsheader mit Optionen besitzt. Dazu musste auch die Funktion generate frame() an IPv6 angepaßt werden. Dafür wurden die neue Variablen
num ext, zo vec und opt zo hd eingeführt. Die Variable num ext gibt die Anzahl
der vorhandenen Erweiterungsheader an und der Vektor zo hd gibt an, welcher der
Erweiterungsheader ein Zieloptionsheader ist. Die Variable opt zo hd gibt dann an,
welcher der Zieloptionsheader für den Fall, dass es mehrere Zieloptionsheader gibt,
die IPclip Optionen enthält.
8
3 MTU Adaptation Module
Das MTU Adaptation Module (MAM) ist für die Anpassung der Maximum Transfer
Unit an das zu übertragende Netzwerk verantwortlich. Bei einer Ethernet Verbindung
soll MAM überprüfen, ob durch das Hinzufügen einer zusätzlichen Ortsinformation
die MTU des Ethernet-Netzwerkes durch die Größe des Pakets überschritten wird.
Dabei wird das Datenpaket zunächst eingelesen. Sobald MAM die Größe der Nutzdaten hat, berechnet MAM die neue Paketgröße. Diese neue Paketgröße ergibt sich
aus 40 Byte für den Header, die Nutzdatenlänge und die hinzugefügten Ortsinformationen. Stellt MAM fest, dass durch die neue Paketgröße die MTU überschritten
wird, so soll das Datenpaket nicht weitergeleitet werden und MAM generiert eine
ICMP-Fehlernachricht an den Absender mit der neuen MTU für das Paket.
3.1 Konzept
Durch die Umstellung auf IPv6 muss zunächst sichergestellt werden, dass MAM ankommende IPv6 Pakete im Upstream und ICMP Fehlernachrichten im Downstream
erkennt. Abbildung 3.1 zeigt das Syntaxdiagramm des Programmablaufs von MAM
für den Upstream. Der Ethertype für IPv6 Pakete ist 0x86DD. Es ändert sich auch
die Versionsnummer im IP-Paket von 4 auf 6.
Nachdem sichergestellt ist, dass die ankommenden Pakete IPv6 Pakete sind, muss
die Struktur des Headers untersucht werden. Da sich der IPv6 Header zum IPv4
Header wesentlich geändert hat, werden auch die Zustände für die State Machines
anders definiert. Dies ist vor allem für die Generierung des ICMP-Frames wichtig,
da MAM nun einen anderen IP-Header zusammenstellen muss. Der Aufbau des IPv6
Headers wurde bereits unter Abschnitt 2.1 in Abbildung 2.1 dargestellt.
Besonders wichtig zu beachten ist, dass bei IPv6 nicht mehr die Gesamtlänge des
Paketes angezeigt wird, sondern die Länge der Nutzdaten. Dazu zählen auch die
Erweiterungsheader. Weiterhin wird keine Header Länge mehr angegeben, da dies
aufgrund der festen IPv6 Headergröße unnötig geworden ist. Unter IPclip sollen die
Ortsinformationen in einen Zieloptionsheader verpackt werden. So wird unter IPv6
die Länge der Optionen nicht mehr im IP-Header deklariert. Die Länge der einzelnen Erweiterungsheader befindet sich jeweils im 2. Byte des Erweiterungsheader,
ausgenommen dabei ist der Fragmentierungsheader. Die Nutzdatenlänge eines IPv6Paketes wird im 5. und 6. Byte des IP-Headers angezeigt.
9
Abbildung 3.1: Syntaxdiagramm MAM
Nachdem die Länge der Nutzdaten eingelesen wurde, muss MAM überprüfen, ob
durch das Hinzufügen der zusätzlichen Informationen die MTU des Netzwerkes überschritten wird. Ist dies der Fall, so soll MAM die IPv6 Nachricht nicht weiter senden,
sondern eine ICMP Fehlernachricht generieren und diese an den Sender zurückschicken mit der neuen zulässigen MTU. Die neue MTU berechnet sich aus der Summe der
Nutzdatenlänge, 40 Byte für den IPv6-Header und der zusätzlichen Ortsinformation.
Die zusätzliche Ortsinformation ist in einem Zieloptionsheader untergebracht, dessen
Länge immer ein Vielfaches von 8 Bytes sein muss. Nachdem die Nutzdatenlänge aus
dem IP-Header eingelesen wurde, kann MAM eine ICMP-Nachricht generieren, falls
die MTU durch das Hinzufügen der Orstinformation überschritten wird. Der Aufbau
dieser ICMP-Nachricht ist in Abbildung 3.2 dargestellt.
10
Abbildung 3.2: ICMP Fehlernachricht
Bei der Generierung einer ICMP-Nachricht wird der Header des IPv6 Paketes teilweise übernommen, da der ICMP-Nachricht ein IPv6-Header vorangestellt wird. Das
Klassenfeld des IPv6-Headers wird mit 0 deklariert und die Quelladresse wird zur Zieladresse, sowie die ursprüngliche Zieladresse die neue Quelladresse des Fehlerpaketes
wird. Das Flusslabel hat den gleichen Wert wie das urspüngliche IPv6-Paket, damit
der eigentliche Sender das IP Paket anhand des Labels erkennt. Dem IPv6 Header
des Fehlerpaketes folgt die eigentliche ICMP Nachricht, welche im Next Header Feld
des IPv6-Headers durch den Wert 58 gekennzeichnet wird. Die ICMP Nchricht hat
im Type Feld den Wert 2, das Code Feld wird mit 0 deklariert. Zur Berechnung der
Prüfsumme muss das Prüfsummenfeld auf 0 gesetzt und ein Pseudoheader generiert
werden, der nicht mitgesendet wird, aber der Prüfsummenberechnung von ICMP zusätzliche Sicherheit gewährleistet. Die Prüfsumme einer ICMP-Nachricht beschränkt
sich auf die gesamte ICMP-Nachricht, die allerdings keine Quell- und Zieladressen
angibt. Ein Pseudoheader enthält eine Quell- und eine Zieladresse, welche dem IPv6
Header entnommen werden, die Länge der ICMP Nachricht und ein Next Header
Feld, welches identisch dem Next Header Feld der vorangestellten IPv6-Nachricht
ist, also den Wert 58 besitzt. Die Prüfsumme ist das Einerkomplement der Summe
aller Einerkomplemente der gesamten ICMP-Nachricht. Der Pseudoheader ist in der
unten stehenden Abbildung 3.3 dargestellt.
11
Abbildung 3.3: Pseudoheader zur Berechnung der ICMP Prüfsumme
Ab dem 5. Byte der ICMP Nachricht wird die 4 Byte lange neue MTU eingetragen.
Die neue MTU wird die alte MTU plus die Ortsinformation plus zwei obligatorischen
Byte für einen zu generierenden Zieloptionsheader sein, da die zusätzlichen Optionen
unter IPv6 in einen Zieloptionsheader untergebracht werden und MAM nicht gesondert nach einem Zieloptionsheader sucht. Ab dem 9. Byte der ICMP Nachricht soll
soviel wie möglich des fehlerhaften IP-Pakets versendet werden. Dabei muss beachtet werden, dass die ICMP Nachricht nach der neuen IPv6 Spezifikation [2] nicht
größer als die Minimale Link MTU von IPv6 ist. Das heißt, dass die gesamte ICMP
Nachricht nicht größer als 1280 Byte sein darf.
Minimum Link MTU Die minimale Link MTU ergibt sich aus dem kleinsten gemeinsamen Nenner aller Netzwerke, die IPv6 übertragen können. Dabei soll die Minimum Link MTU sicherstellen, dass keins der betreffenden Netzwerke nicht in der
Lage ist, eine MTU von mindestens 1280 Byte zu gewährleisten. Da der Header der
ICMP Nachricht bereits 8 Byte beträgt, werden vom IP-Paket die ersten 1272 Byte
der IPv6 Nachricht in die ICMP Nachricht übernommen. Dadurch, dass 1272 Byte
der ursprünglichen IP Nachricht zwischengespeichert werden müssen, muss die Puffer
FIFO auf eine Größe von 2048 Byte angepasst werden.
12
3.2 Umsetzung
Für die Umstellung des MAM von IPv4 nach IPv6 muss die gesamte Header Struktur
an IPv6 angepasst werden. Zunächst werden die Zustände für den Ethernet Header
und die VLAN Tags definiert. Hier ändert sich zunächst einmal nicht viel, außer
dass MAM nun nach IPv6-Paketen suchen soll. Dafür ändert sich nur der Ethertype von 0x0800 auf 0x86DD. Danach müssen sich aber die Zustände für IPv6, die
von der Puffer-FIFO eingelesen werden, ändern. Nachdem der Header vollständig
eingelesen ist, sollen noch 1232 Byte Daten eingelesen werden, damit MAM eine
ICMP Nachricht generieren kann, falls die MTU durch das Einfügen von Ortsinformationen überschritten wird. Die zusätzlichen Daten werden in einer zusätzlichen
Puffer-FIFO eingelesen. Die Daten sollen nun nicht mehr geschaufelt werden, sondern mit der FIFO eingelesen und bei Bedarf ausgelesen werden. Nach dem Einlesen
der Daten wird überprüft, ob die Nutzdatenlänge plus 40 Byte für den Header plus
der Ortsinformationen die MTU überschreiten. Dabei wurde aus Effizienzgründen
darauf verzichtet, bereits bei MAM nach einem Zieloptionsheader zu suchen. Es ist
anzunehmen, dass bei jeder Überprüfung der einzelnen Erweiterungsheader die Geschwindigkeit abnimmt. So sollen von vornherein 2 Byte für einen Zieloptionsheader
reserviert werden und die Optionslänge um die 2 Byte vergrößert werden.
Weiterhin muss die Länge der Ortsinformationen so geändert werden, dass die
Länge der zusätzlichen Informationen im Zieloptionsheader an einer 8 Byte Grenze
enden. Das heißt, die Länge der Ortsinformationen, das können auch mehrere sein,
wird nun auf ein 8-faches erweitert. Von diesem achtfachen Wert werden noch 2 Byte
für die ersten beiden Byte des Zieloptionsheader abgezogen. So ergibt sich die neue
Größe der IP-Optionen.
Noch während der Frame eingelesen wird, wird entschieden, ob der Frame durch
die Send State Machine weitergelassen wird, oder ob der Frame verworfen werden
soll und der Absender eine ICMP Nachricht bekommen soll. Nachdem die Payload
Length in die Read State Machine eingelesen wurde, soll nun überprüft werden, ob
der Frame nach dem Hinzufügen der IPclip Option die MTU überschreitet. Dafür
muss die Summe aus der Payload Length, 40 Byte für den Header und die Größe der
IPclip Option innerhalb eines neu generierten Zieloptionsheaders ermittelt werden.
Wenn diese Summe die MTU überschreitet, soll die Send State Machine das Auslesen
des Frames aus der FIFO stoppen und statt dessen eine ICMP Nachricht generieren,
welche dann an den Sender zurück geschickt wird.
13
3.3 Verifikation
Das Modul konnte bei der Synthese eine Geschwindigkeit von 172 MHz erreicht werden und somit eine Verwendung im GigaByte Betrieb ermöglicht werden. Das MAM
verwendet derzeit 504 Slices. MAM arbeitet derzeit nur im Upstream, für die Verwendung im Downstream müssen noch weitere Änderungen an diesem Modul vorgenommen werden.
14
4 PPPoE MTU Adaptation Module
Das PPPoE MTU Adaptation Module hat die Funktion, beim Verbindungsaufbau einer Point-to-Point-Protokoll Verbindung die Maximum Receive Unit mit dem Broadband Remote Access Server, BRAS, auszuhandeln. Damit die MRU durch das zusätzliche Einbringen der Optionen nicht überschritten wird, soll PAM die ursprüngliche
MRU um die IP-Option vergrößern bzw. im Downstream von der MRU die IP-Option
abziehen. Beim Verbindungsaufbau soll mit Hilfe des Link Control Protocols LCP die
Verbindung zwischen dem Rechner und dem BRAS ausgehandelt werden. Das PPPoE
ist in 3 Verbindungsphasen eingeteilt. In der PPPoE Discovery Phase werden die ersten Verbindungsparameter einer Verbindung zwischen dem Client und einem Server
ausgehandelt. Hier werden die MAC Adressen ausgetauscht und dem Verbindungspartner eine Identifikation zugeteilt. In der PPPoE Session Phase werden dann die
wichtigsten Paramter zur Übermittlung von Datenpaketen, wie die Aushandlung der
MRU oder die Authentifizierung des Nutzers, ausgehandelt. Diese Phase ist besonders
wichtig für die Implementierung des PAM Moduls auf IPclip, da zur Aushandlung
der MRU der Rechner eine PPPoE Session Phase Nachricht sendet, in der ein LCP
Configure Request eingebaut ist. In dieser LCP Configure Request Nachricht wird die
MRU mitgesendet. Hier soll PAM der MRU die Größe der IPclip Option hinzuaddieren. Danach wartet PAM auf eine LCP Acknowledge oder eine LCP Not Acknowledge
Antwort des BRAS. Das Syntaxdiagramm für PAM wird in Abbildung 4.1 dargestellt.
15
Abbildung 4.1: Syntaxdiagramm PAM
Sendet der BRAS nun eine LCP Acknowledge oder LCP Not Acknowledge zurück,
so muss PAM der vom BRAS übermittelten MRU die Größe der Option abziehen.
Der Empfänger erhält nun die ihm zur Verfügung stehende MRU.
4.1 Konzept und Umsetzung
Durch den Umstieg auf IPv6 ändert sich am LCP Verbindungsaufbau nichts. Zur
Aushandlung der MRU bleibt die Prozedur des LCPs erhalten. Dem LCP wird lediglich eine weiteres Protokoll, also IPv6, zugeordnet. Dementsprechend muss die Größe
der IP-Optionen auf ein Vielfaches von 8 Byte vergrößert werden, wovon 2 Byte für
den Zieloptionsheader reserviert werden müssen. Der Aufbau einer PPPoE Session
Phase Nachricht ist in Abbildung 4.2 zu sehen. Für IPv6 muss die neue MRU als
Summe der Größe des IPv6-Headers, die Payload Länge und die IPclip Option gebildet werden. Wie bei MAM, 3.1, muss auch bei PAM die IPclip Option in einen
Zieloptionsheader untergebracht werden, wofür 2 Byte für den Zieloptionsheader reserviert werden müssen. Für die Aushandlung von IPv6 Optionen ist dann das IPv6
Control Protocol, [3] verantwortlich, welches hier aber keine Anwendung findet und
analog dem IP Control Protocol von IPv4 ([1]) entspricht.
16
Abbildung 4.2: Aufbau der PPPoE Session Phase Nachricht
4.2 Verifikation
Anhand des Aufbau und des Blockschaltbildes von PAM wird ersichtlich, dass sich
an der Struktur von PAM im Vergleich zu IPv4 nichts geändert hat.
(a) Aufbau
(b) Blockschaltbild
Abbildung 4.3: Aufbau und Blockschaltbild des PAM
Nach der Synthese des Moduls kann eine Geschwindigkeit von 177 MHz erreicht
werden. Mit dieser Geschwindigkeit kann auch der Betrieb im GBit-Ethernet garantiert werden, wofür nur 125 MHz benötigt werden. Das PAM benötigt 163 Slices. Bei
funktionalen Test, tauschte PAM die alte MRU gegen die neu berechnete MRU aus.
PAM arbeitet sowohl im Upstream als auch im Downstream.
17
5 Parser
Der Parser dient dem Extrahieren der Schlüsselinformationen aus einem IP-Paket.
Das Blockschaltbild des Parsers ist in Abbildung 5.1 dargestellt.
Abbildung 5.1: Blockschaltbild des Parsers
Anhand eines VLAN-Tags und der IP-Adresse des Senders kann der Parser eine Schlüsselinformation zusammensetzen, welche mit einem Schlüsselsatz im Parser
verglichen wird. Findet der Parser einen bekannten Schlüssel, so wird eine Portinformation an den Additional Information Adder übergeben. Ein Überblick über den
Programmablauf bietet das Syntaxdiagramm in Abbildung 5.2.
18
Abbildung 5.2: Syntaxdiagramm des Parsers
5.1 Konzept
Um den Parser für IPv6 zu implementieren, muss zunächst gesagt sein, dass der
Schlüssel sich wesentlich geändert hat. Bei IPv4 war der Schlüssel 44 Bit groß und
er setzte sich aus der 12-Bit großen Information des VLAN-Tags und der 32-Bit
Adresse der Quell-IP zusammen. Da bei der Umstellung auf IPv6 sich die Größe der
IP-Adressen auf 128 Bit vergrößert hat, die Größe des VLAN-Tags jedoch nicht, wird
sich die Schlüsselinformation auf 140 Bit vergrößern. Wie unter IPv4 wird im Falle, dass zwei VLAN-Tags existieren, das erste VLAN-Tag zur Schlüsselinformation
verwendet. Findet der Parser dagegen keinen VLAN-Tag, so sollen die 12 Bits für
das VLAN-Tag mit Nullen gefüllt werden. Weiterhin befindet sich die Quell-IP bei
IPv6 an anderer Stelle als bei IPv4. Bei IPv4 begann die Quell-IP beim 97. Bit und
daher begann der Parser ab dem 26. Byte des Datenframes die Adresse einzulesen.
Unter IPv6 befindet sich die Quelladresse schon ab dem 65. Bit im IPv6-Header. Somit ergibt sich im Ethernet-Frame eine Startposition für die IP-Quelladresse ab dem
22. Byte. Dies lässt sich durch eine Betrachtung des neuen IP-Headers, siehe Abbildung 2.1, begründen und die Startposition ergibt sich aus dem Ethernet-Datenframe
ohne PPPoE und ohne VLAN-Tag. Je nachdem, ob der Ethernetframe ein VLANTag besitzt, verschiebt sich die Startposition um 4 Byte, da pro VLAN-Tag 4 Byte
im Ethernetframe reserviert werden. Befinden sich zwei VLAN-Tags im Ethernetframe verschiebt sich somit die Startposition der IPv6 Quelladresse um 8 Byte. Soll
das Internet-Paket über PPPoE übertragen werden, verschiebt sich die Position der
19
IP-Adresse ebenfalls um 8 Byte, da sich zwischen dem Ethernet-Header und dem
IPv6-Header noch ein PPPoE-Header befindet.
Abbildung 5.3: Aufbau des Parsers
Ein kurzer Überblick über den Aufbau des Parser ist in Abbildung 5.3 zu sehen.
Für die Umstellung auf IPv6 müssen jeweils auch die einzelnen Komponenten des
Parsers überarbeitet werden. Zunächst soll der Framebuffer betrachtet werden. Der
Framebuffer liest den Frame bei einem SOF=’1’ ein und extrahiert hier bereits die
Schlüsselinformation mittels eines Data Parsers. Der Data Parser bekommt die Information, ob es sich um eine PPPoE Übertragung handelt und ob und wie viele
VLAN-Tags vorhanden sind. Anhand dieser Information berechnet der Data Parser
die genaue Startposition der IPv6 Quelladresse. Nachdem die neue Startposition zum
Herauslesen der Informationen bekannt ist, muss noch die Größe der Parsebreite festgelegt werden. Die Parsebreite gibt die Größe der Schlüsselinformation in Byte an
und unter IPv4 war diese Parsebreite 6 Byte groß. Aufgrund der größeren Quelladresse muss die Parsebreite unter IPv6 auf 18 Byte vergrößert werden.
Nachdem die Information eingelesen wurde, wird die Schlüsselinformation an einen
Memory Arbiter übergeben, der die Information an den Memory weitergibt. Im Memory befindet sich ein Schlüsselsatz, der aus RAM-Speicherblöcken besteht. Hier
wird die herausgelesene Schlüsselinformation mit dem Schlüsselsatz verglichen. Befindet sich zu der Schlüsselinformation ein passender Schlüsselsatz, so wird eine 16-Bit
breite Portinformation an den Additional Information Adder übergeben.
20
5.2 Umsetzung
Wie bereits in Abbildung 5.3 zu sehen ist, ist der Parser ein Modul, welches sich
aus mehreren Einzelkomponenten zusammensetzt. In allen Einzelmodulen muss die
Größe der Schlüsselinformation an IPv6 angepasst werden, so dass die Schlüsselinformation nicht mehr 44 Bit sondern 140 Bit groß ist.
Im Framebuffer wird zunächst die Größe der Schlüsselinformation angepasst. Danach wird eine neue Startposition für den Data Parser festgelegt, da sich, wie unter
5.1 bereits erwähnt wurde, die Startposition für das Herauslesen der Schlüsselinformation anhand des neuen IP-Headers geändert hat. Bei IPv6 soll der Data Parser
nun ab dem 22. Byte beginnen, die Daten heraus zu lesen. Diese Daten werden dann
an den Memory Arbiter übergeben. Gibt es kein VLAN-Tag, so werden die ersten 12
Bit des Schlüssel mit Nullen definiert. Bei zwei VLAN-Tags soll der Parser das erste
VLAN-Tag zur Auswertung der Schlüsselinformation nutzen.
Desweiteren wurden im Memory Arbiter und im Memory die Größe der Schlüsselinformation an IPv6 angepasst. Die Datenbreite, die vom Parser eingelesen wird,
bleibt 16 Bit groß. Unter Ipv4 musste die Größe mit 16 Bit definiert werden, da der
Parser sonst nicht im G-Bit Ethernet hätte arbeiten können.
5.3 Verification
Der Parser erreicht bei der Synthese eine Geschwindigkeit von 139 MHz, sodass die
Datenbreite von 16 Bit nicht geändert werden muss. Der Parser verwendet derzeit
einen 140 Bit Schlüssel zur Generierung der Schlüsselinformationen.
21
6 Option Verification Module
6.1 Konzept
Das Option Verification Module dient zur Überprüfung, bereits vorhandener Ortsinformationen in einem IPv6 Frame. Das OVM erhält die Portinformation vom Parser
und untersucht einen eingehenden IP-Frame auf Ortsinformationen. Abbildung 6.1
zeigt das Syntaxdiagramm des OVM. In der IPv6 Version muss das OVM zunächst
prüfen, ob der Frame zusätzliche Erweiterungsheader besitzt. Die Information dazu
findet der OVM im Next Header Feld des IP-Headers. Steht dort nur eine ’6’, so weiß
OVM, dass dem IP-Header das TCP Protokoll folgt. In diesem Fall besitzt der Frame
keine zusätzlichen Optionen und das OVM kann den Frame durchlassen.
22
Abbildung 6.1: Syntaxdiagramm des OVM
Wenn das OVM einen Erweiterungsheader gefunden hat, so soll OVM überprüfen,
ob es sich um einen Zieloptionsheader handelt. Beim ersten überhaupt vorhandenen Erweiterungsheader, findet das OVM die nötige Information im IPv6-Header.
Der Wert des Next Headers muss dementsprechend zwischengespeichert werden. Der
Zieloptionsheader hat den Wert 60. Handelt es sich also um einen anderen Erwei-
23
terungsheader, so kann OVM diesen Header überspringen. Das kann das OVM wie
folgt tun. Der Wert des nächsten Erweiterungsheader wird in eine Registervariable
r.nxt gespeichert. Im nächsten Byte befindet sich die Längenangabe dieses Erweiterungsheaders. Ein zusätzliche Zählvariable soll nun die entsprechende Länge an
Bytes durchlassen. Da die Zählvariable sich aber schon um 2. Byte befindet, müssen
von der Länge des Headers 2 Byte abgezogen werden. Wurde der Erweiterungsheader übersprungen, so soll noch mal geschaut werden, ob im vorangegangenen Header
bereits ein Zieloptionsheader angezeigt wird. Ist dies nicht der Fall, so soll OVM
weiter nach einem Zieloptionsheader suchen. Die Prozedur für die Suche nach einem
Zieloptionsheader wird in einem Zustandsautomaten in Abbildung 6.2 dargestellt.
Abbildung 6.2: Zustandsautomat des OVM - Suche nach einem Zieloptionsheader
Der Wert des nächsten Headers wird wieder gespeichert, da es sich auch beim
nächsten Erweiterungsheader um einen Zieloptionsheader handeln kann. Sobald ein
Zieloptionsheader gefunden wurde, soll OVM den Erweiterungsheader auf Ortsinformationen zu durchsuchen. Dafür wird die Länge des Zieloptionsheaders wieder
24
genommen als Zähler. Es wird jedes Byte durchsucht. Da sich an dem Aufbau der
IP-Optionen nichts geändert hat, wird die Prozedur zum Durchsuchen der Optionen
so ähnlich sein, wie bei IPv4. Das OVM überprüft alle Optionen im Header auf Ortsinformationen. Die jeweils letzte wird in der Variablen valid ip option gespeichert,
die für IPv6 von 5 Bit auf 11 Bit vergrößert wurde. Diese Vergrößerung kommt dadurch zustande, da unter IPv6 rein theoretisch nach dem IP-Header nur ein einziger
Erweiterungsheader mit maximaler Länge stehen kann. Bei IPv6 kann dieser Erweiterungsheader durchaus eine Länge von 1460 Byte annehmen. Aber damit die MTU
nicht überschritten wird, der Zieloptionsheader aber noch eine gültige Länge mit dem
Vielfachen von 8 Byte hat, kann der Zieloptionsheader maximal 1456 Byte groß sein.
Nachdem noch 2 Byte für die Zieloptionsheader Kopfdaten abgezogen wurden, erhält man eine maximale Größe von 1454 Bytes. Da es auch 1 Byte IP-Optionen gibt,
können theoretisch 1454 IP-Optionen existieren, die in einem IPv6 Paket vorhanden
sind. So ermittelt sich die Größe der Variablen valid ip option wie folgt:
valid ip option = log 1456/ log 2
Da der IP-Frame allerdings mehr als einen Zieloptionsheader besitzen kann, soll
OVM auch die folgenden Erweiterungsheader untersuchen, bis keine mehr gefunden
werden und TCP oder UDP als nächstes Protokoll angezeigt werden.
6.2 Umsetzung
Wie unter MAM, müssen auch bei OVM die Zustände für die Header Daten neu
definiert werden. Die Kernstruktur des OVM bleibt unter IPv6 weitgehend erhalten.
Der Aufbau des OVM ist in Abbildung 6.3 zu sehen.
Abbildung 6.3: Aufbau des OVM
25
Bei OVM werden die Werte des Headers nicht gespeichert. Die Ausnahme dabei
bildet allerdings der Next Header Wert. Dieser Wert wird in einem Register gespeichert, da OVM die Erweiterungsheader durchsuchen muss. Nachdem der Header
eingelesen wurde, entscheidet sich, ob der Frame vom OVM durchgelassen werden
kann oder nicht. Steht im Next Header Feld nämlich eine 6 für TCP oder eine 17 für
UDP, so kann das OVM den Frame durchlassen und die Variable valid ip opt erhält
den Wert ’00000000000’. Befinden sich jedoch Erweiterungsheader im Datenframe, so
muss OVM in den Zustand NXT gehen. In diesem Zustand wird der neue Wert des
nächsten Headers gespeichert. Im nächsten Byte steht die Länge des Erweiterungsheaders. Dieser Wert muss auch in der Registervariablen r.len zwischengespeichert
werden, damit OVM die entsprechende Länge des Headers überspringen bzw. durchsuchen kann. Dabei ist zu beachten, dass die Länge in einem Erweiterungsheader
die Anzahl der 8 Byte Wörter angibt und der Wert 0 deklariert immer die ersten
8 Bytes eines solchen Headers. Das heißt, dass das OVM solange in einem Header
suchen muss, bis die Länge erreicht wurde. Da das OVM aber an dieser Stelle bereits
im 2. Byte des Headers ist, müssen jeweils 2 Byte von der noch zu zählenden Länge
abgezogen wird. Die Abbruchsbedingung in einem Zustand ergibt sich wie folgt:
r.rsm cnt = (r.len + 1) ∗ 8 − 2
Der Wert r.len+1 gibt dabei den realen Wert der Länge an, da wie bereits oben
erwähnt, der Wert 0 die ersten 8 Byte eines Erweiterungsheaders angibt. Diese Abbruchbedingung muss nach jedem Byte ausgeführt werden. Findet OVM keine IPclipOptionen und es können jedoch keine Optionen mehr hinzugefügt werden, da die
Header bereits das gesamte Datenpaket ausfüllen, so muss OVM das ’discard’-Signal
für den AIA setzen, damit AIA den Frame verwerfen kann. Sobald aber noch Platz
für weitere Optionen besteht und keine Ortsinformationen vorhanden sind, so soll
OVM das ’add’-Signal setzen. Dieses Signal wird ebenfalls an AIA übergeben. Findet OVM jedoch gültige Ortsinformationen, so wird nach jeder Option die Variable
valid ip opt um 1 erhöht. Diese Variable gibt an, welche Option die letzte gültige
Ortsinformation besitzt.
Weiterhin müssen die Variablen r.total opt length, r.rsm cnt und r.good li an IPv6
angepasst werden. Die Variablen r.total opt length und r.rsm cnt müssen nun mindestens 1460 sein, damit im worst case 1460 Byte gelesen werden können. Die Variable
r.good li wird wie der Wert valid ip opt von 5 auf 11 Bit vergrößert.
Wie unter IPv4 soll das OVM nach den Ortsinformationen suchen, die in den
folgenden Abbildungen dargestellt sind.
26
(a) GPS Ortsinformation
(b) GPS Ortsinformation mit Access-Node und Port-ID
(c) Ortsinformation nach RFC 3825
(d) Ortsinformation nach RFC 3825 mit Access-Node/Port-ID
(e) Ortsinformation nach RFC 4776
Abbildung 6.4: Von IPclip unterstützte Ortsinformationen
6.3 Verifikation
Der OVM ist bislang noch nicht funktional lauffähig, da die Zählervariable r.rsm cnt
weit aus ihrem Definitionsbereich läuft. Wahrscheinlich liegt hier noch ein Fehler
in der Abbruchbedingung vor, so dass die Zählvariable unkontrolliert weiter zählt.
Der Fehler tritt im Zustand IP OPT Type auf. Somit kann auch keine Aussage über
die Laufzeitgeschwindigkeit und die Ressourcen Auslastung auf dem Chip getroffen
werden. Es läßt sich jedoch vermuten, dass der OVM knapp die Grenze zum G-Bit
Betrieb erreichen wird.
27
7 Additional Information Adder
7.1 Konzept und Umsetzung
Der Additional Information Adder soll dem IP-Datenpaket zusätzliche Ortsinformationen hinzufügen, sofern das Paket keine gültigen Ortsinformationen besitzt.
Abbildung 7.1: Blockschaltbild von AIA
Der AIA erhält vom OVM die Signale ’discard’, ’add’ und die Variable valid ip opt.
Mit diesen Werten soll AIA herausfinden, ob ein Frame verworfen werden kann (’discard’ = 1), zusätzliche Informationen hinzugefügt werden sollen (’add’ = 1) und
an welcher Stelle sich die letzte gültige Ortsinformation befindet (valid ip opt). Ein
genauer Programmablauf befindet sich im Syntaxdiagramm 7.2.
28
Abbildung 7.2: Syntaxdiagramm AIA
Für IPv6 muss die Variable valid ip opt daher auch bei AIA von 5 Bit auf 11 Bit
vergrößert werden. Weiterhin muss eine Prozedur zum Auffinden des richtigen Erweiterungsheaders eingeführt werden bzw. es muss ein zusätzlicher Zieloptionsheader
generiert werden, für den Fall, dass es bislang im IP-Paket keinen Zieloptionsheader
gibt, AIA jedoch zusätzliche Ortsinformationen hinzufügen soll. Ein grober Ablauf
dieser Prozedur ist im Zustandsautomaten 7.3 dargestellt.
29
Abbildung 7.3: Zustandsautomat
Ortsinformationen
für
das
Hinzufügen
von
zusätzlichen
Der Zustandsautomat beschreibt, unter welchen Bedingungen lediglich Informationen hinzugefügt werden sollen oder wann ein kompletter Erweiterungsheader generiert werden muss. Dafür müssen einige Werte neu definiert werden. Zum Weitersenden des Frames nach dem Hinzufügen wurde eine Value-FIFO eingefügt, die die
Werte, die sich im AIA ändern, zwischenspeichert und im Anschluss daran, die neuen
Werte anstelle der alten Werte im Frame einfügt. Zu den Werten, die in die ValueFIFO eingefügt werden sollen, gehört die neue Payload Length des IPv6 Header, das
neue Nxt Hd des IPv6 Headers für den Fall, dass sich vorher gar kein Erweiterungsheader im Frame befand (der alte Wert darf jedoch nicht verworfen werden, da der
neue Header auf das alte Folgeprotokoll verweisen soll) und die neuen Zählerstände.
30
Abbildung 7.4: Aufbau des AIA
Abbildung 7.4 zeigt das Zusammenspiel der einzelnen Komponenten im AIA. Aufgrund der neu definierten Werte, muss die Datenbreite der Value-FIFO angeglichen
werden.
Weiterhin soll AIA ungültige Ortsinformationen löschen. Dies kann AIA auf ähnliche Weise vornehmen wie das Hinzufügen. Dafür muss sich AIA die alten Zählerstände, die Länge der IPv6 Payload und die Länge des Erweiterungsheaders merken.
Fällt ein Zieloptionsheader vollständig aus, muss der Wert des Nxt Feldes in das Nxt
Feld des vorherigen Erweiterungsheaders bzw. des IPv6-Headers eingegliedert werden.
Für den AIA wurden bereits erste Änderungen im Header Aufbau vorgenommen,
aber es gibt bislang noch keinen funktionierenden Prototypen.
31
8 Additional Information Remover
8.1 Konzept
Der Additional Information Remover soll im Downstream von ankommenden IPFrames die zusätzlichen Ortsinformationen entfernen, damit der Absender diese Ortsinformationen nicht erhält. Wenn eine zusätzliche Information gelöscht wurde, gibt
AIR die Information, dass das Paket vertrauenswürdig ist oder nicht, an den Empfänger weiter. Nach welchem Schema AIR dabei vorgehen muss, ist in Abbildung 8.1
dargestellt.
Abbildung 8.1: Syntaxdiagramm des AIR
Genau wie AIA benötigt der AIR eine Value-FIFO zum Zwischenspeichern von
32
kritischen Werten, die beim Löschen der Informationen abhanden kommen könnten
und somit das Paket unbrauchbar machen würden. Auch hier muss die neue Payload
Length und die Next Header Werte zwischengespeichert werden. Abbildung ?? zeigt
hier deutlich, dass die Struktur des AIR der Struktur des AIA sehr ähnlich ist.
Abbildung 8.2: Aufbau des AIR
An AIR konnten bislang noch keine Änderungen vorgenommen werden, der Programmablauf des AIR sollte aber ähnlich dem Programmablauf des AIA sein.
33
9 Zusammenfassung und Ausblick
Während dieser Arbeit wurde ein Konzept zur Migration des IPclip Mechanismus
von IPv4 nach IPv6 entworfen und teilweise konnten die Änderungen an den Modulen vorgenommen werden. Bislang sind MAM, PAM und der Parser lauffähig. Um
das OVM lauffähig zu bekommen, benötigt es einer genaueren Fehleranalyse bei der
Simulation, da es bislang noch einen Fehler mit den Zählvariablen gibt. Sobald OVM
fertiggestellt ist, kann an AIA weitergearbeitet werden. Bei AIA wurden die ersten
Änderungen vorgenommen, aber es fehlen noch wichtige Zustände zur Generierung
von zusätzlichen Zieloptionsheader.
Für MAM muss noch eine Prozedur zur Verwendung im Downstream erarbeitet
werden, weiterhin bedarf es bei allen Modulen, die die Auswertung der Erweiterungsheader vornehmen, also OVM, AIA und AIR einer genaueren Betrachtung der
jeweiligen Erweiterungsheader. Der Bis jetzt folgen sie dem Aufbau eines normalen
Erweiterungsheaders mit Next Header Feld und Länge des aktuellen Erweiterungsheaders. Aber nicht alle Folgeprotokolle weisen die gleiche Struktur auf. Es muss
auf alle unterschiedlichen Folgeprotokolle genau eingegangen werden. Besonders soll
auf die Verwendung eines Fragmentierungsheaders eingegangen werden. Dieser Erweiterungsheader hat eine feste Länge und somit wird keine Länge dieses Headers
vorgegeben. Der aktuelle Stand des Konzepts sieht diese Ausnahme bis jetzt nicht
vor.
9.1 Ausblick
Die Verwendung eines IPclip Mechanismus ist vielversprechend. Durch die eindeutige Zuweisung von Ortsinformationen kann der Absender eines Datenpaketes genau ermittelt werden. Besonders wichtig erscheint dieser Vorteil bei Notrufen über
Internet-Telefonie. Es gibt immer mehr Angebote von Providern, die ihren Kunden
nicht nur einen Internetanschluss bereit stellen, sondern auch die Möglichkeit von
Internet-Telefonie anbieten. Viele Kunden schätzen dieses Angebot und wählen es
als Alternative zum herkömmlichen Telefonanschluss der Telekom. Durch die Verwendung von IPclip könnte den Teilnehmern der Internet-Telefonie eine feste Ortsinformation anbieten. Für Notrufe über das Internet ist dies klar von Vorteil.
Bei der Verwendung gegen Phishing und Spam ist der IPclip Mechanismus genauso
34
überzeugend wie bei der Verwendung bei Notrufen. Die Empfänger von InternetPaketen erhalten eine zusätzliche Absicherung darüber, ob das Paket manipuliert
wurde. Da bereits IPv6 mehrere Sicherheitsaspekte aufweist, wie die Verwendung
eines Authentifizierungsheaders, wird sich zeigen, inwieweit sich IPclip in Bezug auf
Phishing und Spam Vorbeugung behaupten kann. Es bietet jedoch eine vernünftige
Alternative zu bekannten Mechanismen und kann dem Nutzer so zusätzlich Sicherheit
bieten.
35
Erklärung
Hiermit erkläre ich, Grit Rhinow (Matrikelnummer 3202581), dass der vorliegende
Große Beleg mit dem Thema “Trust-by-Wire in paketvermittelnden IP-Netzen:
Migration des IPclip-Mechanismus von IPv4 nach IPv6”von mir in allen Teilen
selbstständig verfasst wurde. Dafür wurden keine anderen als die angegebenen
Quellen und Hilfsmittel benutzt. Alle wörtlich oder sinngemäß übernommenen
Textstellen habe ich als solche kenntlich gemacht.
Rostock, 8. September 2008
cand. ing. Grit Rhinow