Skript zur Vorlesung - Vorlesungen

Rechnernetze
Vorlesungsskript SS 2002
Jürgen Schönwälder
Version vom 11. Juli 2002
Fachbereich Mathematik/Informatik
Universität Osnabrück
Vorwort
Die Vorlesung Rechnernetze vermittelt grundlegendes Wissen aus dem Bereich der rechnergestützten Kommunikation. Dabei werden schwerpunktmäßig Datenkommunikationsnetze betrachtet und
insbesondere die heutzutage weit verbreiteten Internet-Technologien und die IEEE 802.x Standards
für lokale Netze.
Die Auswahl des Stoffes orientiert sich bewusst an derzeit weit verbreiteten Technologien und Protokollen. Dies geht natürlich zu Lasten von einigen durchaus technisch interessanten alternativen
Ansätzen, die sich aus verschiedenen Gründen aber nicht durchgesetzt haben. Die bewusste Beschränkung auf ausgewählte Technologien und Protokolle erlaubt es, die vorgestellten Verfahren
mehr im Detail zu behandeln. Durch die Auswahl von allgemein verfügbaren Technologien wird es
möglich, im begleitenden Übungsbetrieb praktische Erfahrungen zu sammeln, was einerseits hilft
den Stoff besser zu verstehen und andererseits sich positiv auf die allgemeine Motivation auswirkt.
Einige Teile des Skripts stammen aus der Vorlesung Einführung in Betriebssysteme und Netze“,
”
die ich im Wechsel mit Prof. Dr. M. Zitterbart an der TU Braunschweig gehalten habe. Andere Teile
basieren auf der umfangreichen Literatur, die zum Thema Rechnernetze verfügbar ist und in den
einzelnen Kapiteln referenziert wird. Für eine tiefer gehende Auseinandersetzung mit dem Stoff
ist es jedoch oftmals notwendig, sich mit den Standards selbst auseinander zusetzen. Daher gibt in
jedem Abschnitt auf die entsprechenden Standards.
Interessant ist vielleicht noch zu erwähnen, dass dieses Skript unter massivem Einsatz von Datenkommunikationsnetzen entstanden ist. Während ich in Osnabrück an diesem Skript arbeite, liegen
viele der Texte und Abbildung auf Rechnern in Braunschweig und fast schon natürlich wandern alle
Daten ständig zwischen diesen Orten und diversen Druckern und Web-Servern hin und her. Diese
Arbeitsweise wäre vor zwanzig Jahren kaum praktikabel gewesen. Vor zehn Jahren wäre es wohl
prinzipiell schon gegangen, aber man hätte sicher einiges an zusätzlichem Aufwand leisten und
an Geduld mitbringen müssen. Man darf also gespannt sein, wie sich unsere Arbeitsweisen in den
nächsten zehn oder zwanzig Jahren aufgrund der sich weiter entwickelnden Rechnernetze ändern
werden.
Bedanken möchte ich mich an dieser Stelle bei allen Studenten, die durch kritische Fragen dazu beigetragen haben, dass dieses Skript etwas weniger Fehler enthält und hoffentlich besser verständlich
geworden ist.
Jürgen Schönwälder
Inhaltsverzeichnis
1
Grundlagen
1.1 Topologien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Übertragungsmedien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.1 Einfache Leitungen . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.2 Verdrillte Kupferleitungen . . . . . . . . . . . . . . . . . . . . . . .
1.2.3 Koaxialkabel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.4 Lichtwellenleiter . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.5 Funkwellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3 Codierung digitaler Daten . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3.1 Return-to-Zero (RZ) Codierung . . . . . . . . . . . . . . . . . . . .
1.3.2 Non-Return-to-Zero (NRZ) Codierung . . . . . . . . . . . . . . . . .
1.3.3 Differentielle Codierung . . . . . . . . . . . . . . . . . . . . . . . .
1.3.4 Manchester Codierung . . . . . . . . . . . . . . . . . . . . . . . . .
1.3.5 Alternate Mark Inversion (AMI) Codierung . . . . . . . . . . . . . .
1.4 Fehlererkennung und -korrektur . . . . . . . . . . . . . . . . . . . . . . . .
1.4.1 Fehlererkennende Codes . . . . . . . . . . . . . . . . . . . . . . . .
1.4.2 Fehlerkorrigierende Codes . . . . . . . . . . . . . . . . . . . . . . .
1.5 Medienzugang und Medienzuteilung . . . . . . . . . . . . . . . . . . . . . .
1.5.1 Frequenzmultiplex . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.2 Zeitmultiplex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.3 Aloha . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.4 Carrier Sense Multiple Access (CSMA) . . . . . . . . . . . . . . . .
1.5.5 Carrier Sense Multiple Access with Collision Detection (CSMA/CD)
1.5.6 Multiple Access with Collision Avoidance (MACA) . . . . . . . . .
1.5.7 Tokenverfahren . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.6 Zusammenhangsbesonderheiten . . . . . . . . . . . . . . . . . . . . . . . .
1.6.1 Sequenznummern . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.6.2 Quittungen und Sendewiederholungen . . . . . . . . . . . . . . . . .
1.6.3 Zeitüberwachung . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.6.4 Flusskontrolle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.6.5 Staukontrolle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.7 Netzwerk-Architekturen . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.7.1 Dienste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.7.2 Protokolle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.7.3 Namen und Adressen . . . . . . . . . . . . . . . . . . . . . . . . . .
1.7.4 ISO/OSI Schichtenmodell . . . . . . . . . . . . . . . . . . . . . . .
1.7.5 Internet Schichtenmodell . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
2
5
7
7
8
8
9
11
12
12
13
13
14
15
15
18
19
19
20
21
21
22
23
23
25
25
26
27
27
29
30
30
30
31
33
35
INHALTSVERZEICHNIS
1.8
2
3
4
Standardisierung . . . . . . . .
1.8.1 ISO Standardisierung . .
1.8.2 Internet Standardisierung
1.8.3 IEEE Standardisierung .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
36
36
37
38
Lokale Netze nach IEEE 802
2.1 Logical Link Control (IEEE 802.2) . . . . . .
2.2 Ethernet (IEEE 802.3) . . . . . . . . . . . .
2.2.1 Physikalische Schicht . . . . . . . . .
2.2.2 MAC-Schicht . . . . . . . . . . . . .
2.3 Fast-Ethernet (IEEE 802.3U) . . . . . . . . .
2.4 Gigabit-Ethernet (IEEE 802.3Z) . . . . . . .
2.5 10 Gigabit-Ethernet (IEEE 802.AE) . . . . .
2.6 Wireless LANs (IEEE 802.11) . . . . . . . .
2.7 Brücken . . . . . . . . . . . . . . . . . . . .
2.7.1 Transparente Brücken (IEEE 802.1D)
2.8 Virtuelle LANs (IEEE 802.1Q, IEEE 802.1P)
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
39
40
40
40
41
44
44
44
44
45
47
49
Internet Netzwerkschicht
3.1 Grundlagen . . . . . . . . . . . . . . . . . . .
3.1.1 Entwicklung des Internets . . . . . . .
3.1.2 Internet Prinzipien . . . . . . . . . . .
3.1.3 Terminologie . . . . . . . . . . . . . .
3.1.4 Autonome Systeme . . . . . . . . . . .
3.1.5 Geltungsbereiche von Internet Adressen
3.2 Internet Protokoll Version 4 . . . . . . . . . . .
3.2.1 IPv4 Adressen . . . . . . . . . . . . .
3.2.2 IPv4 Paketformat . . . . . . . . . . . .
3.2.3 IPv4 Weiterleitung . . . . . . . . . . .
3.2.4 IPv4 Fehlerbehandlung (ICMPv4) . . .
3.2.5 MTU Path Discovery . . . . . . . . . .
3.2.6 IPv4 über IEEE 802.3 . . . . . . . . .
3.2.7 Adressumsetzung (ARP, RARP) . . . .
3.2.8 Automatische Konfiguration (DHCP) .
3.3 Internet Protokoll Version 6 . . . . . . . . . . .
3.3.1 IPv6 Adressen . . . . . . . . . . . . .
3.3.2 IPv6 Paketformat . . . . . . . . . . . .
3.3.3 IPv6 Erweiterungen . . . . . . . . . .
3.3.4 IPv6 Weiterleitung . . . . . . . . . . .
3.3.5 IPv6 Fehlerbehandlung (ICMPv6) . . .
3.3.6 IPv6 über IEEE 802.3 . . . . . . . . .
3.3.7 IPv6 Neighbor Discovery . . . . . . . .
3.4 Wegwahlverfahren . . . . . . . . . . . . . . .
3.4.1 Routing Information Protocol (RIP) . .
3.4.2 Open Shortest Path First (OSPF) . . . .
3.4.3 Border Gateway Protocol (BGP) . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
53
53
53
54
54
55
55
56
56
57
58
59
61
61
62
62
65
65
65
66
70
70
71
71
76
76
78
81
Internet Transportschicht
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
83
INHALTSVERZEICHNIS
4.1
4.2
4.3
4.4
5
Pseudo-Header . . . . . . . . . . . . . . . . .
User Datagram Protocol (UDP) . . . . . . . . .
Transmission Control Protocol (TCP) . . . . .
4.3.1 Verbindungsaufbau . . . . . . . . . . .
4.3.2 Verbindungsabbau . . . . . . . . . . .
4.3.3 Zustandsmaschine . . . . . . . . . . .
4.3.4 Flusskontrolle . . . . . . . . . . . . . .
4.3.5 Staukontrolle . . . . . . . . . . . . . .
4.3.6 Optionen . . . . . . . . . . . . . . . .
Stream Control Transmission Protocol (SCTP) .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Internet Anwendungsschicht
5.1 Domain Name System (DNS) . . . . . . . . . . . . .
5.1.1 Format von Domain Namen . . . . . . . . . .
5.1.2 Resource Records . . . . . . . . . . . . . . . .
5.1.3 DNS Nachrichtenformat . . . . . . . . . . . .
5.2 Abstract Syntax Notation One (ASN.1) . . . . . . . .
5.2.1 Grundlagen . . . . . . . . . . . . . . . . . . .
5.2.2 ISO-Registrationsbaum . . . . . . . . . . . . .
5.2.3 Primitive ASN.1 Datentypen . . . . . . . . . .
5.2.4 Zusammengesetzte ASN.1 Datentypen . . . .
5.2.5 Einschränkungen von Datentypen . . . . . . .
5.2.6 ASN.1 Tags . . . . . . . . . . . . . . . . . . .
5.2.7 Beispiel für eine ASN.1 Definition . . . . . . .
5.2.8 Basic Encoding Rules (BER) . . . . . . . . . .
5.3 Simple Network Mangement Protocol (SNMP) . . . .
5.3.1 Grundlagen . . . . . . . . . . . . . . . . . . .
5.3.2 Structure of Management Information (SMIv2)
5.3.3 Grundlegende MIB Module . . . . . . . . . .
5.3.4 Protokollarchitektur . . . . . . . . . . . . . .
5.3.5 Nachrichtenformat . . . . . . . . . . . . . . .
5.4 Lightweight Directory Access Protocol (LDAP) . . . .
5.5 Augmented Backus-Naur Form (ABNF) . . . . . . . .
5.5.1 Regelnamen und Terminalsymbole . . . . . . .
5.5.2 Operatoren . . . . . . . . . . . . . . . . . . .
5.5.3 Kerndefinitionen . . . . . . . . . . . . . . . .
5.5.4 ABNF in ABNF . . . . . . . . . . . . . . . .
5.6 Simple Mail Transfer Protocol (SMTP) . . . . . . . .
5.6.1 Grundlagen . . . . . . . . . . . . . . . . . . .
5.6.2 Kommandos und Antworten . . . . . . . . . .
5.6.3 Nachrichtenköpfe . . . . . . . . . . . . . . . .
5.6.4 Multipurpose Internet Mail Extensions (MIME)
5.7 Internet Message Access Protocol (IMAP) . . . . . . .
5.7.1 Identifikation und Zustände . . . . . . . . . .
5.7.2 Zustände . . . . . . . . . . . . . . . . . . . .
5.7.3 Kommandos . . . . . . . . . . . . . . . . . .
5.7.4 Tagging . . . . . . . . . . . . . . . . . . . . .
5.7.5 Nachrichtenformat . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
84
84
85
86
87
87
88
88
88
88
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
89
89
90
91
91
95
95
96
96
97
97
97
98
101
104
104
107
111
113
116
122
123
123
123
124
125
127
127
128
131
131
134
134
134
135
136
137
INHALTSVERZEICHNIS
5.8
5.9
Hypertext Transfer Protocol (HTTP) . . . . . . . . . . . . . . . . . . . . . . . . . 138
File Transfer Protocol (FTP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
A Packet Capturing
141
A.1 BSD Packet Filter (BPF) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
A.2 libpcap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
A.3 jpcap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
B Fragen zur Selbstkontrolle
147
Kapitel 1
Grundlagen
Kommunikationsnetze haben sich in den letzten Jahren zu einer allgegenwärtigen Schlüsseltechnologie entwickelt und bilden die Grundlage der in der Entstehung befindlichen Informationsgesellschaft. Entsprechend hat sich die Telematik (Telekommunikation und Informatik) als ein Teilgebiet
der Informatik entwickelt, das sich mit der Kommunikation von Daten unter der Nutzung technischer Mittel über räumliche Entfernungen befasst.
Geschichte der Kommunikations- und Datennetze:
• Fackeltelegraphie (5. Jhdt v. Chr. Griechenland)
• Drahtgebundene elektrische Telegraphie (ca. 1840, Morse, USA)
• Unterseekabel London - New York (1866)
• Telefon (Bell 1876, Edison 1877)
• Öffentliche Telefonnetze (ab 1880)
• Drahtlose Telegraphie (ab 1895)
• ARPANET (vorläufer des Internet, ab 1969)
• Ethernet als erstes lokales Netz (ab 1976)
• World-Wide-Web (ab 1990)
Da es eine sehr große Vielfalt von Kommunikationsnetzen gibt, die nicht alle in einer Vorlesung
behandelt werden können, beschränkt sich dieses Skript bewusst auf die klassischen Rechnernetze (computer networks) zur Datenkommunikation. Unter Datenkommunikation versteht man den
Austausch von Daten zwischen datenverarbeitenden Geräten. Die Telekommunikation, d.h. der
Austausch von Informationen (z.B. Sprache, Video) zwischen Menschen, wird bewusst hier nicht
schwerpunktmäßig behandelt. Das Ziel dieser Vorlesung ist vielmehr die Vermittlung von grundlegendem Wissen aus dem Bereich der rechnergestützten Kommunikation.
Rechnernetze werden in der Regel konstruiert um ein oder mehrere der folgenden Ziele zu erreichen:
• Lastverbund: Ziel ist die gleichmäßige Auslastung verschiedener Betriebsmittel. Typischerweise werden dazu Spitzenlasten auf mehrere Rechner verteilt.
1
2
KAPITEL 1. GRUNDLAGEN
• Leistungsverbund: Ziel ist die Verringerung von Antwortzeiten. Dazu werden komplexe Aufgaben in wenige komplexe Teilaufgaben zerlegt, die von mehreren Rechnern bearbeitet werden können.
¨
• Kommunikationsverbund: Ziel ist die ”Ubertragung
von Informationen an verschiedene räumlich getrennte Orte. Typischerweise werden dazu elektronische Postsysteme und verteilte Informationssysteme eingesetzt.
• Datenverbund: Ziel ist der Austausch von logisch zusammenhängenden Daten zwischen örtlich getrennten Systemen. Typische Methoden sind verteilte Dateisysteme und verteilte Datenbanken.
• Wartungsverbund: Ziel ist die schnellere und billigere Wartung verschiedener Rechner. Eine
typische Realisierung ist ein zentrale und entsprechend qualifizierte Störungserkennung und
-behebung.
• Funktionsverbund: Ziel ist die Bereitstellung von speziellen Funktionen an verschiedenen
Orten. Dabei handelt es sich typischerweise um den Einsatz von Spezialrechnern.
• Kapazitätsverbund: Ziel des Kapazitätsverbunds ist die effiziente Nutzung von verfügbaren
Betriebsmitteln. Die bedeutet typischerweise die gemeinsame Nutzung von spezieller Hardund Software und die Verteilung von Aufgaben an momentan freie Rechenkapazitäten.
1.1
Topologien
Stern
Ring
Vermaschtes Netz
Bus
Liniennetz
Abbildung 1.1: Grundlegende Netztopologien
Für das Verständnis von Rechnernetzen ist normalerweise Wissen über die verwendete Topologie
notwendig. Man unterscheidet folgende grundlegende Topologien (Abbildung 1.1):
• Stern: Alle Knoten sind direkt an einem zentralen Knoten angeschlossen. Stern-Topologien
vereinfachen die Wegwahl und besitzen eine gute Ausfallsicherheit sofern der zentrale Knoten hinreichend zuverlässig ist.
3
1.1. TOPOLOGIEN
• Ring: Alle Knoten sind ringförmig miteinander verbunden. Sehr einfache Wegwahl, allerdings geringe Ausfallsicherheit und hoher Aufwand bei eventuell notwendigen Rekonfigurationen.
• Vermaschtes Netz: Jeder Knoten ist mit jedem anderen Knoten direkt verbunden. Gute Ausfallsicherheit und keine Vermittlung notwendig. Allerdings sind n(n−1)
Verbindungen bei n
2
Knoten notwendig.
• Bus: Alle Knoten sind an einem gemeinsamen Medium (Bus) angeschlossen. Insgesamt gute
Ausfallsicherheit solange der Bus funktionsbereit ist.
• Liniennetz: Konzeptionell einfache Topologie mit mittlerer Ausfallsicherheit. Die Position
im Netz beeinflusst Übertragungszeiten. Liniennetze spielen für den Spezialfall von n = 2
Knoten eine große Rolle (Punkt-zu-Punkt Verbindungen).
Aus diesen grundlegenden Topologien werden in der Regel komplexere Strukturen zusammengesetzt. Man spricht dann von gekoppelten Netzen oder einem Internet1 . Typische Realisierungen sind
sogenannte Backbone-Netze, bei denen mehrere Teilnetze durch einen Backbone miteinander verbunden werden.
Abbildung 1.2: Backbone-Netze
Typischerweise sind Backbone-Netze hierarchisch organisiert. Insbesondere in Bürogebäuden hat
sich eine strukturierte Verkabelung (structured cabling) durchgesetzt, bei der auf jeder Etage ein
(ggf. komplexes) Netzsegment realisiert wird und die einzelnen Segmente der Etagen durch ein
Backbone-Netz miteinander verbunden werden. Auf den Etagen findet man in der Regel sternförmige Netze. Müssen mehrere Gebäude miteinander vernetzt werden, so wird ein zusätzliches Netz als
Verbindung zwischen den Gebäuden realisiert. Wesentlich bei der strukturierten Verkabelung ist
die genormte Verkabelung möglichst unabhängig von der zum Einsatz kommenden Netztechnik
(anwendungsneutrale Verkabelung).
1
Im Englischen unterscheidet man zwischen einem internet (beliebiger Zusammenschluss von Netzen) und dem Internet (Zusammenschluss von Netzen unter Verwendung der Internet-Protokolle). Im deutschen ist diese feine Unterscheidung leider nicht so einfach umzusetzen.
4
KAPITEL 1. GRUNDLAGEN
Abbildung 1.3: Struktur des Hochschulnetzes der Universität Onabrück
1.2. ÜBERTRAGUNGSMEDIEN
5
Man geht derzeit von folgenden Lebensdauern aus:
• Verteilerräume und Kabelwege (20-40 Jahre)
• Lichtwellenleiter (ca. 15 Jahre)
• Kupferverkabelung (ca. 8 Jahre)
• Verkabelung sollte drei Generationen von aktiven Netzkomponenten überleben
Weitere Details finden sich in der DIN Norm EN 50173:2000 beziehungsweise in dem internationalen Standard ISO/IEC 11801.
Die Verbindung der Netzsegmente geschieht durch Koppelelemente. Man unterscheidet die folgenden Koppelelemente:
• Verstärker (Repeater) sind Koppelelemente, die im wesentlichen nur das Signal verstärken
um dadurch die Überbrückung größerer Distanzen erlauben.
• Brücken (Bridges) können Rahmen einer Familie von verwandten Netzen umwandeln und
weiterleiten.
• Router versuchen Pakete in Richtung des Ziel weiterzuleiten, wobei man sich in der Regel
innerhalb eines logischen Netzes befindet und die Weiterleitung aufgrund einer Auswertung
der Adresse realisiert ist.
• Switche leiten ebenfalls Pakete in Richtung des Ziels weiter. Im Vergleich zu Routern werden
spezielle Datenfelder des Pakets direkt zur Ermittlung der ausgehenden Netz-Schnittstelle
benutzt und es findet keine Auswertung der Adresse statt.
• Protokollkonverter (Gateways) verbinden Netze, die ähnliche Dienste mit sehr unterschiedlichen Protokollen bereitstellen. Ein Gateway versucht die Nachrichten eines Protokolls in die
Nachrichten eines anderen Protokolls zu konvertieren.
Koppelelemente können nicht strikt klassifiziert werden, da die Übergänge fließend sind. Insbesondere von Herstellern wird gern der Begriff Switch verwandt — auch wenn der für eine bestimmte
Technologie korrekte Term Bridge oder Router wäre.
Neben der physikalischen Topologie, die durch die Art der Vernetzung gegeben ist, gibt es in der
Regel weitere logische Topologien. Beispielsweise kann auf einem physikalischen Bus ein logischer
Ring existieren oder auf einem physikalischen Stern ein logisch vollständig vermaschtes Netz. Es
ist daher immer wichtig, sich über die aktuelle Betrachtungsart bewusst zu sein.
1.2
Übertragungsmedien
Die Übertragung von Daten erfolgt in einem nachrichtentechnischen Kanal wie er in Abbildung 1.4
dargestellt ist. Ein nachrichtentechnischer Kanal besteht aus einem Umformer, einem Rückformer,
einem physikalischen Medium und einer Störquelle. Das Medium überbrückt die räumliche Distanz
zwischen Quelle und Senke. Das beim Rückformer eintreffende Signal y 0 (t) ist durch den zeitlichen
Verlauf von x0 (t) und der Störgröße z 0 (t) bestimmt.
6
KAPITEL 1. GRUNDLAGEN
Quelle
Senke
Prim"ares Signal x(t)
Prim"ares Signal y(t)
Umformer
R"uckformer
Signal x’(t)
Signal y’(t)
Physikalisches Medium
St"orquelle z’(t)
Abbildung 1.4: Nachrichtentechnischer Kanal
Signale werden in einem nachrichtentechnischen Kanal durch folgende Effekte gestört:
• Dämpfung (attenuation):
Bei der Ausbreitung eines Signals nimmt die Signalstärke (Amplitude) abhängig von der
Frequenz des Signals ab. Entsprechend sind Übertragungsmedien in ihrer Länge begrenzt und
man benötigt Signalverstärker (amplifier, repeater) um die Signale über größere Strecken zu
transportieren. Die Dämpfung wird in Dezibel (dB) gemessen - das logarithmische Verhältnis
der gesendeten und empfangenen Signalstärke.
• Bandbreite (bandwidth):
Die Bandbreite eines Kanals ist in der Regel durch die Eigenschaften des Mediums oder durch
die diskrete Abtastung eines analogen Signals beschränkt. Gelegentlich wird die Bandbreite
auch künstlich beschränkt (klassische Telefone übertragen nur Schallwellen im Bereich 300600 Hz).
• Verzögerungsverzerrung (delay distortion):
Die verschiedenen Komponenten eines komplexen Signals breiten sich nicht alle mit derselben Geschwindigkeit aus. Entsprechend kommt es beim Empfänger zu einer Verzerrung
und ggf. sogar zu einer Interferenz der Signalanteile verschiedener aufeinanderfolgender Bits
(intersymbol interference).
• Rauschen (noise):
In Übertragungsmedien existiert ein Rauschen, auch wenn keine Signale gesendet werden.
Diese Rauschen wird durch verschiedene physikalische Effekte erzeugt, kann aber auch durch
die Verlegung der Leitungen bewirkt werden (z.B. Übersprechen durch elektromagnetische
Einstrahlung von anderen Leitungen, Reflektionen am Leitungsende). Nach Shannon-Hartley
gilt für die Datenrate C
S
C = W log2 1 +
N
wobei W die Bandbreite ist, S die mittlere Signalstärke und N die mittlere Rauschstärke.
Das logarithmische Verhältnis der Signalstärken
S
N
wird auch als Signal-Rausch-Abstand (signal-to-noise ratio) bezeichnet.
SN R = 10 log10
7
1.2. ÜBERTRAGUNGSMEDIEN
Die typischen Kenngrößen eines nachrichtentechnischen Kanals sind:
• Die Datenrate (Bitrate) beschreibt die übertragbare Datenmenge pro Zeiteinheit (z.B. 100
Mbit/s). Oftmals handelt es sich um theoretische Werte, die im aktuellen Betrieb nicht erreicht
werden.
• Mit dem Begriff Bitbreite bezeichnet man die Zeit, die zur Übertragung eines Bits benötigt
wird (ca. 1 Mikrosekunde für 1 Mbit/s).
• Die Verzögerung (delay) oder auch die Transferzeit ist die Zeit, die benötigt wird, um eine
Nachricht von der Quelle komplett zur Senke zu übertragen. Sie besteht wiederum aus der
Signallaufzeit (propagation delay) und der Übertragungszeit (transmission delay).
1. Bit
letztes Bit
Transferzeit
Signallaufzeit
Abbildung 1.5: Verzögerungen in einem nachrichtentechnischen Kanal
Mit diesen nachrichtentechnischen Grundlagen im Hintergrund sollen nun einige wichtige Übertragungsmedien betrachtet werden. Der Typ des Mediums ist wichtig, da dadurch die maximale
Anzahl von Bits festlegt wird, die pro Sekunde übertragen werden kann (bits per second, bps).
1.2.1
Einfache Leitungen
Einfache Leitungen bestehen aus Kupferadern, die in der Regel mit einem festen Abstand zueinander in einem Plastikmantel untergebracht sind. Derartige Leitungen eignen sich zum Anschluss
von Geräten über kurze Entfernungen (bis zu 50 Meter) und mit einer geringen Datenrate. Einfache
Leitungen sind relativ störanfällig (z.B. durch Übersprechen).
1.2.2
Verdrillte Kupferleitungen
Verdrillte Kupferleitungen (twisted pair) bestehen aus einem Adernpaar, das in sich selbst verdreht
ist. Durch das verdrillen der Leitungen verringert man die Störungsempfindlichkeit und insbesondere das Übersprechen.
Abbildung 1.6: Verdrillte Kupferleitungen (twised pair)
8
KAPITEL 1. GRUNDLAGEN
Das Telefonnetz besteht im Anschlussbereich aus verdrillten Kupferleitungen, die Frequenzen bis
zu 4 kHz über mehrere Kilometer übertragen können. Auf kürzeren Entfernung können auch Datenraten im Bereich von mehreren Millionen bps (mbps) erreicht werden. Bei Telefonleitungen liegt
die Fehlerwahrscheinlichkeit bei ca. 10−5 .
Nicht-abgeschirmte verdrillte Kupferkabel (unshielded twisted pair, UTP) der Kategorie 3 bestehen aus vier Paaren von verdrillten Leitungen, die durch einen Plastikmantel zusammengehalten
werden. Bis 1988 war eine Verkabelung von Gebäuden mit UTP Kategorie 3 Standard. Heutzutage
verwendet man UTP der Kategorie 5, bei denen die Leitungspaare öfter mitaneinander verdreht sind
und die daher eine bessere Qualität bieten.
Es existieren auch abgeschirmte verdrillte Kupferkabel (shielded twisted pair, STP), bei denen eine Abschirmung Störeinflüsse reduziert. Allerdings spielen STP-Kabel bisher eine untergeordnete
Rolle.
1.2.3
Koaxialkabel
Ein generelles Problem bei verdrillten Leitungen ist die hohe Dämpfung bei hohen Frequenzen.
Dieses Problem bekommt man durch Koaxialkabel (coaxial cable) in den Griff. Sie bestehen aus einer dicken inneren Kupferader, die von einer Isolierung und einem Metallgeflecht umgeben ist. Das
Metallgeflecht hält äußere Störungen von der inneren Leitung fern und ermöglicht die Übertragung
von hohen Frequenzen.
Isolation
Leiter
Abschirmung
Schutzmantel
Abbildung 1.7: Koaxialkabel (coaxial cable)
Mit Koaxialkabeln lassen sich Datenraten bis zu 500 mbps über einige Kilometer mit einer Fehlerwahrscheinlichkeit von 10−7 erreichen. Typische Anwendungen sind das Kabelfernsehen und
lokale Netze.
1.2.4
Lichtwellenleiter
Wesentlich höhere Datenraten als Koaxialkabel bei geringeren Fehlerwahrscheinlichkeiten liefern
Lichtwellenleiter (fibre optics) in denen Lichtwellen übertragen werden. Lichtwellenleiter beruhen
auf dem physikalischen Prinzip der Totalreflexion bzw. der Brechung des Lichts an der Grenzschicht
zweier optisch transparenter Medien mit verschiedenen Brechungszahlen.
Mantel
Kern
H"ulle
Schutzmantel
Abbildung 1.8: Lichtwellenleiter (optical fiber)
1.2. ÜBERTRAGUNGSMEDIEN
9
Ein Lichtwellenleiter besteht aus einem Kern (typischerweise Quarzglas) und einem Mantel mit
einer geringeren Brechungszahl. Ein Lichtstrahl, der auf die Stirnfläche des Faserkerns trifft, wird
entweder exakt entlang der Faserachse geführt oder beim Auftreffen auf die Grenzschicht zwischen
dem Kern und dem Mantel gebrochen und ggf. reflektiert.
Bei den Lichtwellenleitern unterscheidet man zwischen Monomode-Fasern und Multimode-Fasern:
• Multimode-Fasern haben einen relativ dicken Kern (20-50 Mikrometer Durchmesser) und
bewirken eine fortlaufende Brechung und Reflexion des Lichtsignals, was natürlich den Ausgangsimpuls verschlechtert.
• Durch eine graduelle Änderung der Brechungszahl in einer Multimode-Faser kann der Verlust
etwas verringert werden.
• Bei Monomode-Fasern ist der Kern dünner (2-10 Mikrometer) und das Signal breitet sich
entlang des Kerns aus.
Lichtwellenleiter bieten viele Vorteile:
• Lichtwellenleiter ermöglichen extrem hohe Datenraten, die derzeit in der Regel nur durch die
Wandler begrenzt sind, die elektrische Signale in optische Signale umwandeln.
• Die Dämpfung ist gering wodurch relativ große Distanzen ohne Verstärker überbrückt werden
können.
• Lichtwellenleiter sind immun gegen elektromagnetische Störungen und können daher ohne
Probleme in Umgebungen betrieben werden, in denen starke elektromagnetische Störungen
auftreten können..
• Das Abhören bzw. Anzapfen eines Lichtwellenleiters ist relativ aufwendig.
• Der Anschluss von optischen Kabel erfolgt entweder über optische Steckverbindungen oder
durch ein sauberes Trennen und Verschmelzen der Faserkerne. Die zweite Methode erzeugt
weniger Signalverluste, erfordert aber sehr viel Übung und spezielle Werkzeuge.
• Lichtwellenleiter sind sehr dünn (ein Kern hat ungefähr den Durchmesser eines menschlichen Haares). Im Vergleich zu Kupferkabeln sind Lichtwellenleiter sehr platzsparend und
wesentlich leichter.
Lichtwellenleiter werden grundsätzlich als uni-direktionale Leiter betrieben. Entsprechend werden
für einen bi-direktionalen Kanal zwei Lichtwellenleiter benötigt.
Obwohl sich Lichtwellenleiter bei großen Netzen durchgesetzt haben, werden im Zugangsbereich
weiterhin elektrische Leitungen verwendet. Der Grund hierfür ist die billigere Anschlusstechnik, da
Umwandlungen von elektrischen Signalen in optische Signale und zurück vermieden werden.
1.2.5
Funkwellen
Die drahtlose Datenübertragung hat in den letzten Jahren stark an Bedeutung zugenommen. Drahtlose Systeme sind immer dann sinnvoll, wenn die Verlegung von Kabeln unmöglich oder sehr teuer
ist oder wenn besondere Kommunikationsbedürfnisse existieren (z.B. jederzeit erreichbar zu sein).
10
KAPITEL 1. GRUNDLAGEN
f(Hz) 10 0
10 2
10 4
10 6
Radiowellen
10 8
10 10
Mikrowellen
10 12
10 14
Infrarotwellen
10 16
10 18
UV
10 20
10 22
R"ontgenwellen
10 24
Gammawellen
Lichtwellen
f(Hz)
10
4
10
6
10
8
Twisted Pair
10
10
10
12
Satelliten
10
14
10
LWL
Koaxialkabel
AM
Radio
FM
Radio
Mikrowellen
TV
Abbildung 1.9: Elektromagnetisches Spektrum nach [2]
Abbildung 1.9 zeigt die für eine Datenübertragung zur Verfügung stehenden Frequenzen des elektromagnetischen Spektrums. Nur wenige der verfügbaren Frequenzen können ohne Genehmigung
genutzt werden. Lediglich die Frequenzen im Industrial/Scientific/Medical (ISM) Band (2400-2484
GHz) können ohne Lizenzen weltweit allgemein benutzt werden.
Radiowellen
Die Eigenschaften von Radiowellen sind frequenzabhängig.
• Radiowellen mit niedrigen Frequenzen durchdringen Hindernisse relativ gut, verlieren aber
stark an Signalstärke. Niederfrequente Radiowellen folgen der Krümmung der Erde.
• Radiowellen mit höherer Frequenz sind besser gebündelt, werden aber von Hindernissen reflektiert und von Wasser (Regen) absorbiert. Höherfrequente Radiowellen verbreiten sich geradlinig, werden aber von der Ionosphere reflektiert.
• Generell müssen die verwendeten Frequenzen gut auf den Einsatzzweck abgestimmt sein, da
sonst massive Störungen auftreten können.
Mikrowellen
Mikrowellen breiten sich geradlinig aus. Mit Hilfe von Parabolantennen lassen sich die Strahlen
mit einem guten Signal-Rausch-Abstand bündeln.
• Sende und Empfangsantennen müssen genau ausgerichtet sein. Durch die Erdkrümmung sind
bei größeren Distanzen Umsetzer erforderlich.
• Mit Mikrowellen lassen sich sog. Richtfunkstrecken (line of sight) relativ billig realisieren.
• Hindernisse führen zu merkbaren Signalverlusten. Die Signalstärken sind außerdem stark
abhängig vom Wetter (Nebel/Regen absorbiert Mikrowellen).
16
1.3. CODIERUNG DIGITALER DATEN
11
Infrarotwellen
Infrarotwellen werden erfolgreich zur Kommunikation über sehr kurze Distanzen eingesetzt (Fernsteuerungen).
• Sender und Empfänger sind einfach und billig.
• Eine direkte Sicht zwischen Sender und Empfänger ist notwendig, da Hindernisse Infrarotwellen fast komplett absorbieren.
• Es sind keine Lizenzen notwendig, da Infrarotwellen Hindernisse kaum durchdringen und
dadurch automatisch in der Ausbreitung begrenzt sind.
Lichtwellen
Stark gebündelte Lichtwellen eignen sich ebenfalls zur Datenübertragung. Sie werden meist von
einem Laser erzeugt.
• Erfordern eine extrem genaue Ausrichtung von Sender und Empfänger.
• Qualität abhängig vom Wetter.
• Erfordern aufgrund der starken Fokussierung keine Lizenzen.
1.3 Codierung digitaler Daten
Die Übertragung von digitalen Daten kann entweder parallel oder seriell erfolgen. Bei der parallelen Übertragung wird ein Datenwort (in der Regel ein Byte) in einem Schritt übertragen. Dazu
müssen zwischen Quelle und Senke mehrere Verbindungen parallel geschaltet werden. Bei der seriellen Übertragung wird ein Datenwort in einzelne Bits zerlegt, die nacheinander übertragen werden.
Entsprechend wird nur eine Verbindung zwischen Quelle und Senke benötigt.
Die Anzahl der Signalparameterwechsel pro Sekunde wird als Schrittgeschwindigkeit bezeichnet
und in Baud gemessen (nach Jean Marc Baudot). Bei einem isochronen Takt entspricht die Schrittgeschwindigkeit der Taktrate. Üblich ist auch der Begriff Baudrate für die Schrittgeschwindigkeit.
Die Übertragungsgeschwindigkeit ist im Gegensatz dazu die Anzahl der übertragenen Bits pro Zeiteinheit, gemessen in Bit pro Sekunde (bps). Offenbar ist die Schrittgeschwindigkeit genau dann
gleich der Übertragungsgeschwindigkeit, wenn in jedem Schritt genau ein Bit dargestellt wird.
Es gibt verschiedene Verfahren zur Kodierung von digitalen Daten (sogenannte Leitungskodes),
wobei die folgenden Eigenschaften ein wichtige Rolle spielen:
• Taktrückgewinnung
Den Signalwerten kann neben den Daten auch der Takt des Senders entnommen werden. Die
Taktrückgewinnung ist erforderlich, wenn keine separate Taktleitung zur Verfügung steht.
Der Taktgehalt eines Codes sollte möglichst unabhängig vom Inhalt der übertragenen Daten
sein.
12
KAPITEL 1. GRUNDLAGEN
• Gleichstromanteil
Auf manchen Übertragungsstrecken darf wegen der angeschlossenen Geräte kein Gleichstrom auftreten. Diese Eigenschaft kann meist nicht absolut sondern nur im statistischen Mittel erfüllt werden.
• Resynchronisation
Der Anfang und das Ende einer Übertragung findet häufig asynchron statt. Entsprechend
muss beim Beginn bzw. Ende einer Übertragung der Anfang bzw. das Ende des Datenstroms
identifiziert werden können.
Zur Codierung der digitalen Daten finden binäre Leitungscodes (zwei verschiedene Signalwerte),
ternäre Leitungscodes (drei Signalwerte) oder Blockcodes Verwendung. Bei Blockcodes werden m
Bits als Block zusammengefasst und zu einem neuen Block der Länge n codiert.
1.3.1
Return-to-Zero (RZ) Codierung
Das Return-to-Zero Verfahren ist ein binärer Code, bei dem eine ‘1’ durch einen hohen Signalwert
und eine ‘0’ durch einen niedrigen Signalwert dargestellt wird. Eine ‘1’ wird durch einen Rechteckimpuls in der ersten Hälfte des Bitintervalls dargestellt. Danach wird in der zweiten Hälfte auf
den Grundzustand (zero) zurückgegangen.
0
1
0
0
0
1
1
high
low
Abbildung 1.10: Return-to-Zero Leitungscode
• Baudrate ist im Extremfall doppelt so hoch wie die Bitrate.
• Keine Taktgewinnung möglich bei einer Folge von ‘0’-Werten.
• Der Gleichstromanteil kann relativ hoch sein.
1.3.2
Non-Return-to-Zero (NRZ) Codierung
Das Non-Return-to-Zero Verfahren ist ebenfalls ein binärer Code, bei dem eine ‘1’ durch einen
hohen Signalwert und eine ‘0’ durch einen niedrigen Signalwert dargestellt wird. Im Gegensatz
zum Return-to-Zero Verfahren wird eine ‘1’ bzw. eine ‘0’ durch einen festen Pegelwert während
des Bitintervalls dargestellt. Signalwechsel treten nur an den Intervallgrenzen auf.
• Sehr einfach zu implementieren.
• Keine Taktrückgewinnung möglich.
• Der Gleichstromanteil kann relativ hoch sein.
13
1.3. CODIERUNG DIGITALER DATEN
0
1
0
0
0
1
1
high
low
Abbildung 1.11: Non-Return-to-Zero Leitungscode
1.3.3
Differentielle Codierung
Bei der differentiellen Codierung wird nicht der absolute Signalwert verwendet sondern der Signalwert in Abhängigkeit von der Polarität des vorhergehenden Signalwerts. Beim Non-Return-toZero Inverse (NRZ-I) Verfahren wird der jeweils entgegengesetzte Signalwert zur Darstellung einer
‘1’ verwendet. Eine ‘0’ bewirkt keinen Signalwechsel. Beim Non-Return-to-Zero Space (NRZ-S)
Verfahren findet der Signalwechsel bei einer ‘0’ statt während die ‘1’ keine Signalwertänderung
bewirkt.
0
1
0
0
0
1
1
high
low
0
1
0
0
0
1
1
high
low
Abbildung 1.12: NRZ-I und NRZ-S Leitungscodes
• Signalwechsel sind insbesondere bei Störungen einfacher zu erkennen als Signalpegel.
• Keine Taktrückgewinnung möglich.
• Der Gleichstromanteil kann relativ hoch sein.
1.3.4
Manchester Codierung
Bei der Manchester Codierung wird eine ‘1’ durch einen Signalübergang vom hohen Pegel zum
niedrigen Pegel in der Mitte des Bitintervalls dargestellt. Eine ‘0’ wird durch einen Signalübergang
vom niedrigen Pegel zum hohen Pegel in der Mitte des Bitintervalls dargestellt.
• Kombination aus NRZ codierten Daten mit einem Taktsignal.
• Mindestens ein Signalwechsel pro Bitintervall (Taktrückgewinnung).
• Erfordert eine im Verhältnis zur Bitrate doppelte Baudrate.
14
KAPITEL 1. GRUNDLAGEN
0
1
0
0
0
1
1
high
low
Abbildung 1.13: Manchester Leitungscode
• Keine Gleichstromkomponente.
• Fehlererkennung auf Signalebene (Fehlen eines erwarteten Übergangs).
• Manchester Codierung wird bei lokalen Netzen verwendet.
1.3.5
Alternate Mark Inversion (AMI) Codierung
Bei der Alternate Mark Inversion Codierung (AMI) wird eine ternäre Codierung verwendet. Eine
‘1’ wird abwechselnd durch einen positiven (+) oder einen negativen Impuls (-) dargestellt (Wechselregel). Eine ‘0’ wird durch Null-Pegel (=) dargestellt wird.
0
1
0
0
0
1
1
high
zero
low
Abbildung 1.14: AMI Leitungscode
• Keine Gleichstromkomponente.
• Taktrückgewinnung bei längeren Folgen von Nullen nicht möglich.
• AMI Codierung verwendet die Norm G.703 für die europäischen 2 Mbit/s ISDN Anschlüsse.
Als Lösung für die Taktrückgewinnung kann man für jede vierte Null ein Signal übertragen, dass
die Wechselregel verletzt. Das führt allerdings zu einer Gleichstromkomponente bei langen Folgen
von Nullen. Falls ein ’-’ zuviel gesendet wurde und die nächste Verletzung wieder ein ’-’ ergeben
würde, so wird stattdessen für vier Nullen ’+==+’ kodiert. Analog für den Fall von zu vielen ’+’
Verletzungen. Da die Verletzung der Wechselregel in diesen Fällen schon nach zwei ’==’ auftritt
kann der Empfänger den Bitstrom rekonstruieren.
15
1.4. FEHLERERKENNUNG UND -KORREKTUR
1.4 Fehlererkennung und -korrektur
Bei der Datenübertragung können verschiedene Fehler auftreten. Wir betrachten zunächst Bitfehler,
die während der Übertragung durch Störungen des Signals auftreten können.
1.4.1
Fehlererkennende Codes
Paritätsbits
Die einfachste Form der Fehlererkennung sind sogenannte Paritätsbits, die zusätzlich übertragen
werden. Bei gerader (ungerader) Parität wird die Anzahl der Einsen durch das Paritätsbit auf eine
gerade (ungerade) Anzahl ergänzt. Offensichtlich kann jede ungerade Anzahl von Bitfehlern durch
Paritätsbits erkannt werden.
Zyklische Blocksicherung
Bei der zyklischen Blocksicherung wird eine Prüfsumme über eine Bitfolge (Block) berechnet. Es
werden redundante Prüfbits am Ende eines Blocks übertragen. Zwischen Sender und Empfänger
wird vereinbart, wie diese Blockprüfzeichen zu berechnen sind. Die zyklische Blocksicherung basiert auf folgender Überlegung:
• Eine zu sendende Bitfolge bn bn−1 . . . b1 b0 wird als Polynom B(x) = bn xn + bn−1 xn−1 +
. . . + b1 x + b0 über dem Körper {0, 1} dargestellt.
• Rechenregeln: 0 + 0 = 1 + 1 = 0, 1 + 0 = 0 + 1 = 1 und 1 · 1 = 1, 0 · 0 = 0 · 1 = 1 · 0 = 0
• Ein Generatorpolynom G(x) = gr xr + . . . g1 x + g0 mit gr = 1 und g0 = 1 wird zwischen
Sender und Empfänger vereinbart.
• Übertragen wird U (x) = xr · B(x) + t(x) mit t(x) =
xr · B(x)
mod G(x).
G(x)
• Der Empfänger prüft, ob die gesamte empfangene Bitfolge durch G(x) ohne Rest teilbar ist.
• Das Verfahren ist bei geeigneter Wahl der Generatorpolynome sehr leistungsfähig.
• Grundsätzlich können Fehler, die durch G(x) ohne Rest teilbar sind, nicht erkannt werden.
• Eine effiziente Implementierung ist mit Hilfe von Schieberegistern möglich.
Beispiel für die effiziente CRC-Berechnung durch bitweise exklusiv-oder Verknüpfungen:
• Generatorpolynom G(x) = x3 + x2 + 1 (entspricht der Bitfolge 1101) und die Nachricht
M = 1001 1010 (entspricht dem Polynom B(x) = x7 + x4 + x3 + x).
• Berechnung:
16
KAPITEL 1. GRUNDLAGEN
1001 1010 000 : 1101 = 1111 1001
1101
---100 1
110 1
----10 00
11 01
----1 011
1 101
----1100
1101
---1 000
1 101
----101
• Übertragen wird die Bitfolge 1001 1010 101.
• Der Empfänger prüft die Übertragung durch folgende Berechnung:
1001 1010 101 : 1101 = 1111 1001
1101
---100 1
110 1
----10 00
11 01
----1 011
1 101
----1100
1101
---1 101
1 101
----0
• Das Ergebnis 0 zeigt an, dass kein Fehler erkannt wurde.
Beispiele für gebräuchliche Generatorpolynome:
• Das HEC Polynom G(x) = x8 + x2 + x + 1 findet im ATM Zellenkopf Verwendung.
1.4. FEHLERERKENNUNG UND -KORREKTUR
17
• Das CRC-16 Polynom G(x) = x16 + x15 + x2 + 1 entdeckt alle Einzel- und Doppelfehler,
alle Fehler mit ungerader Bitzahl, alle Fehlerbündel mit 16 oder weniger Bits und über 99%
aller Fehlerbündel mit 17 oder mehr Bits.
• Das CRC-CCITT Polynom G(x) = x16 + x15 + x5 + 1 findet im HDLC Protokoll Verwendung.
• G(x) = x32 + x26 + x23 + x22 + x16 + x12 + x11 + x10 + x8 + x7 + x5 + x4 + x2 + x + 1
ist unter dem Namen CRC-32 bekannt und findet im Ethernet Verwendung.
Internet Prüfsumme
Im Internet findet eine andere Prüfsumme Verwendung (RFC 1071 [5], RFC 1141 [6], RFC 1624
[7]), die insbesondere für die effiziente Implementation in Software geeignet ist. Die Prüfsumme
wird über einen Datenpuffer berechnet, der aus einer geraden Anzahl von Bytes besteht. (Bei ungerader Anzahl von Bytes wird am Ende ein 0x00 Byte angefügt.) Das Prinzip des Algorithmus zeigt
folgendes Programmfragment:
uint16_t
checksum(uint16_t *buf, int count)
{
uint32_t sum = 0;
while (count--) {
sum += *buf++;
if (sum & 0xffff0000) {
sum &= 0xffff;
sum++;
}
}
return ˜(sum & 0xffff);
}
Eigenschaften der Internet Prüfsumme:
• Die Summation ist kommutativ und assoziativ und kann daher in beliebiger Reihenfolge und
in beliebigen Gruppen erfolgen.
• Die Berechnung der Prüfsumme ist unabhängig von der Byte-Ordnung (wobei allerdings die
Prüfsumme bei vertauschter“ Byte-Ordnung ebenso vertauscht ist).
”
• Auf Maschinen mit einer Wortgröße von mehr als 16 Bit kann die Berechnung parallelisiert
werden.
• Das Verfahren kann in einen Kopiervorgang der Daten integriert werden.
• Einzelne Datenfelder können aktualisiert werden, ohne die Prüfsumme komplett neu berechnen zu müssen.
• Das Verfahren ist heutzutage häufig in Assembler oder sogar in Hardware implementiert.
18
KAPITEL 1. GRUNDLAGEN
1.4.2
Fehlerkorrigierende Codes
Um Fehler nicht nur erkennen sonder auch korrigieren zu können, sind mehr redundante Informationen notwendig.
• Der Hamming-Abstand d(c1 , c2 ) zweiter Codewörter c1 ∈ C, c2 ∈ C und c1 6= c2 eines
Codes C ist definiert als die Anzahl der Bitpositionen, in denen sich die Codewörter c1 und
c2 unterscheiden.
• Der Hamming-Abstand D(C) eines Codes C ist das Minimum über die Hamming-Abstände
der Codewörter:
D(C) = min{d(c1 , c2 )|c1 ∈ C, c2 ∈ C, c1 6= c2 }
• Zur Erkennung und Korrektur von 1-Bitfehlern bei einer Wortlänge von b Bits sind r redundante Prüfbits erforderlich, wobei die Ungleichung (b + r + 1) ≤ 2r erfüllt sein muß.
Konstruktion eines Hamming-Codes:
• Die erforderlichen r Prüfbits werden an den Positionen 2i mit i ∈ {0, . . . , r − 1} untergebracht. Die Werte der Prüfbits ergeben sich aus einer exklusiv-oder Verknüpfung von jeweils
r Datenbits.
• Zur Bestimmung der Datenbits trägt man die binäre Darstellung der Bitpositionen zeilenweise in einer Matrix ein und liest diese Matrix anschließend spaltenweise aus und erhält so die
Nummern der Datenbits, aus denen sich die Prüfbits errechnen.
• Der Empfänger testet auf Fehler durch die lokale Berechnung der Prüfbits aus den Datenbits
und einem Vergleich mit den empfangenen Prüfbits.
• Weichen die Prüfbits voneinander ab, so liefert die exklusiv-oder Verknüpfung des berechneten Prüfbits mit den im Codewort enthaltenen Prüfbits die binäre Darstellung der Bitposition,
an der sich das fehlerhafte Bit befindet.
Beispiel:
c1 = d1 xor d2 xor d4
d1 an Position 3 = 011
c2 = d1 xor d3 xor d4
d2 an Position 5 = 101
c3 = d2 xor d3 xor d4
d3 an Position 6 = 110
d4 an Position 7 = 111
Abbildung 1.15: Konstruktion eines Hamming-Codes
• Wir betrachten m = 4 Datenbits d1 , d2 , d3 , d4 und r = 3 Prüfbits c1 , c2 , c3 . Das Codewort
hat entsprechend die Form c1 c2 d1 c3 d2 d3 d4 an den Bitpositionen 1 bis 7.
19
1.5. MEDIENZUGANG UND MEDIENZUTEILUNG
• Gegeben sind die Datenbits 10102 , d.h. d1 = 1, d2 = 0, d3 = 1, d4 = 0.
• Es ergeben sich die Prüfbits c1 = 1, c2 = 0, c3 = 1 und damit das Codewort 10110102 .
• Empfangen wird das Codewort 10111102 , d.h. d1 = 1, d2 = 1, d3 = 1, d4 = 0.
• Es ergeben sich die Prüfbits c1 = 0, c2 = 0, c3 = 0.
• Die Position des fehlerhaften Bits erhält man aus den Prüfbits: 1012 ⊕ 0002 = 1012 = 510 .
1.5
Medienzugang und Medienzuteilung
Oftmals werden physikalische Übertragungsmedien von mehreren Systemen gemeinsam benutzt.
In diesen Fällen ist es notwendig, den Zugang zum Medium zu regeln.
Medienzuteilung
Zeitmultiplex
vorgegebenes Raster
Frequenzmultiplex
nach Bedarf
dezentral
konkurrierend
zentral
geordnet
Abbildung 1.16: Formen der Medienzuteilung
Abbildung 1.16 zeigt verschiedene Möglichkeiten. Neben der Ausnutzung verschiedener Frequenzen besteht insbesondere die Möglichkeit, das Übertragungsmedium zeitgesteuert den einzelnen
Systemen zuzuordnen. Dies kann nach einem fest vorgegebenen Raster geschehen oder aber bedarfsgesteuert.
1.5.1
Frequenzmultiplex
Bei breitbandigen Übertragungswegen können mehrere getrennte Übertragungskanäle in unterschiedlichen Frequenzbereichen (Frequenzbändern) untergebracht werden (frequency division multiplexing, FDM).
• Die Frequenzbänder müssen nicht unbedingt gleichbreit sein.
• Zwischen den Frequenzbändern sind Schutzbänder untergebracht.
• Jeder Kanal besitzt eine bekannte feste Bandbreite (wichtig für Sprachübertragungen).
• Realisiert wird ein Frequenzmultiplex indem Bitströme auf verschiedene Trägerfrequenzen
moduliert werden, die zusammen über das gemeinsame Medium übertragen werden. Auf
Empfängerseite werden die Frequenzen getrennt und die einzelnen Bitströme rekonstruiert
(demodulation).
20
KAPITEL 1. GRUNDLAGEN
Frequenz
Kanal 1
Kanal 2
Kanal 3
Kanal 4
Kanal 5
Zeit
Abbildung 1.17: Frequenzmultiplex (frequency devision multiplexing)
• Im Zusammenhang mit optischen Leitern spricht man auch von Wellenlängenmultiplex (wave
division multiplexing, WDM), wobei hier passive optische Systeme (Prismen) zur Trennung
der Lichtwellen benutzt werden können.
1.5.2
Zeitmultiplex
Beim starren Zeitmultiplex (time division multiplexing, TDM) wird das Übertragungsmedium den
einzelnen Systemen zeitgesteuert zugeteilt.
Frequenz
Kanal 1
Kanal n
Kanal ...
Kanal 3
Kanal 2
Kanal 1
Kanal n
Kanal ...
Kanal 3
Kanal 2
Zeit
Abbildung 1.18: Zeitmultiplex (time devision multiplexing)
• Die Zeitschlitze müssen nicht unbedingt gleichbreit sein, obwohl sie das oftmals sind.
• Zwischen den zugeteilten Zeitschlitzen sind sogenannte Schutzzeiten.
• Werden die Zeitschlitze nach einer festen Reihenfolge zugeteilt, so bekommt jeder Kanal eine
bekannte feste Bandbreite mit bekannten Verzögerungen (wichtig für Sprachübertragungen).
• Realisiert wird ein starres Zeitmultiplex indem Sender und Empfänger über einen gemeinsamen Takt gesteuert Daten senden und empfangen. Kritisch ist hierbei die Stabilität des
Zeittakts.
• Als Variante kann man ein anforderungsgesteuertes Zeitmultiplex betrachten, bei dem Zeitschlitze nach Bedarf zugeteilt werden (statistical time division multiplexing, STDM). Erfordert im allgemeinen eine Übertragung einer Systemkennung in jedem Zeitschlitz.
21
1.5. MEDIENZUGANG UND MEDIENZUTEILUNG
1.5.3
Aloha
Das Aloha-Verfahren wurde in den 70er Jahren an der Universität von Hawaii entwickelt (was den
Namen erklärt). Die ursprüngliche Version (pure aloha) ist relativ einfach und für Übertragungssysteme geeignet, bei denen alle Stationen der Übertragung mithören und Kollisionen erkennen
können.
Station A:
Station B:
Station C:
Zeit
Abbildung 1.19: Pure Aloha
• Sender übertragen Daten sobald sie möchten.
• Kollisionen sind unvermeidbar, werden aber vom Sender erkannt, da er das Medium während
der Übertragung abhören kann.
• Wenn die Übertragung gestört war, dann wartet der Sender einen zufälligen Zeitraum und
wiederholt dann die Übertragung.
• Die Leistungsfähigkeit ist relativ begrenzt (in der Größenordnung von 18 % der Kanalkapazität). Grund hierfür sind mögliche Ketten von sich teilüberlagernden Datenblöcken.
Etwas bessere Auslastung erreicht man, indem man feste Zeitschlitze einführt (slotted aloha). Sender müssen den Beginn eines Zeitschlitzes abwarten, bevor sie mit der Übertragung beginnen.
Station A:
Station B:
Station C:
Zeit
Abbildung 1.20: Slotted Aloha
• Die Synchronisation lässt sich ggf. durch ein kurzes Kontrollsignal realisieren.
• Durch die Modifikation können Kollisionen nur noch beim Start einer Übertragung auftreten
und Ketten von sich teilüberlagernden Datenblöcken sind nicht mehr möglich.
• Die Leistungsfähigkeit von slotted aloha liegt bei 37 % der Kanalkapazität (deutlich besser
als pure aloha, aber immer noch nicht besonders gut).
1.5.4
Carrier Sense Multiple Access (CSMA)
Eine weitere deutliche Verbesserung von Aloha erhält man durch das Abhören des Mediums bevor eine Station zu senden beginnt. Ziel ist es, nur dann eine Übertragung zu beginnen, wenn das
Medium vermutlich frei ist.
22
KAPITEL 1. GRUNDLAGEN
Station A:
Station B:
Station C:
Zeit
Abbildung 1.21: Carrier Sense Multiple Access
• Bei einem CSMA-Verfahren besteht weiterhin die Möglichkeit einer Kollision, da sich Signale nur entsprechend der Ausbreitungsgeschwindigkeit ausbreiten und daher mehrere Stationen einen freien Kanal vorfinden können und sich dann gegenseitig behindern.
• Kollisionen ergeben sich auch, wenn sendebereite Stationen auf einen freien Kanal warten
und quasi gleichzeitig zu senden beginnen sobald der Kanal frei wird.
• Im Fall einer Kollision wird der Übertragungsversuch nach einer zufälligen Pause wiederholt.
• Bei einem 1-persistenten (1-persistent) CSMA-Verfahren sendet eine sendebereite Station
mit der Wahrscheinlichkeit 1 (also immer) wenn das Medium frei ist.
• Bei einem nicht-persistenten (non-persistent) CSMA-Verfahren warten Stationen bei einem
belegten Kanal ein zufälliges Zeitintervall bevor sie erneut prüfen, ob der Kanal frei ist.
• Bei einem p-persistenten (p-persistent) CSMA-Verfahren sendet eine sendebereite Station
nur mit der Wahrscheinlichkeit p wenn der Kanal frei ist. Mit der Wahrscheinlichkeit 1 − p
wird auf einen weiteren freien Zeitschlitz gewartet (erfordert eine Taktung des Mediums).
1.5.5
Carrier Sense Multiple Access with Collision Detection (CSMA/CD)
Eine weitere Verbesserung kann man erreichen, indem eine Station sofort beim Erkennen einer
Kollision die Übertragung abbricht.
Station A:
Station B:
Station C:
Zeit
Abbildung 1.22: Carrier Sense Multiple Access Collision Detection
• Sei τ die Zeit, die ein Signal aufgrund der Ausbreitungsgeschwindigkeit zwischen zwei maximal entfernten Stationen benötigt. Dann benötigt der Sender im schlechtesten Fall eine Zeit
von 2 · τ um sicher zu sein, dass die Übertragung kollisionsfrei abläuft.
• Im Fall einer Kollision wird der Übertragungsversuch nach einer zufälligen Pause wiederholt.
• Das CSMA/CD-Verfahren ist die Grundlage des IEEE 802.3 Protokolls (Ethernet).
23
1.5. MEDIENZUGANG UND MEDIENZUTEILUNG
1.5.6
Multiple Access with Collision Avoidance (MACA)
In einem Funknetz besteht die Möglichkeit, dass nicht alle Stationen in einer Funkzelle sich gegenseitig erreichen können. Die Verwendung von CSMA in diesem Fall ist problematisch:
• Es seien A, B und C drei Stationen in einer Funkzelle, wobei das Paar A und B miteinander
kommunizieren kann und das Paar B und C. Wenn A Daten an B überträgt, dann kann C
dies nicht beobachten und wird ausgehend von einem freien Kanal ebenfalls Daten an B
übertragen. Die Kollision findet dann beim Empfänger B statt (hidden station problem).
• Erweitert man das Beispiel um eine Station D, wobei D nur in der Reichweite von C ist.
Sendet nun Station B, so entdecken A und C einen belegten Kanal. Die Station C wird daher
nicht an Station D senden, auch wenn dies kein Problem hervorrufen würde (exposed station
problem).
Das grundlegende Problem hier ist, dass eigentlich Informationen benötigt werden, ob der Kanal
in der Umgebung des Empfängers frei ist. Ein CSMA-Verfahren liefert aber nur lokale Informationen. Das MACA-Verfahren löst dieses Problem, indem der Empfänger zunächst zu einer kurzen
Übertragung stimuliert wird.
RTS
CTS
Station A:
Station B:
Station C:
Zeit
Abbildung 1.23: Multiple Access with Collision Avoidance
• Eine sendebereite Station sendet zunächst eine kurze RTS (ready to send) Nachricht an den
Empfänger. Der Empfänger sendet daraufhin eine CTS (clear to send) Nachricht zurück an
die sendebereite Station. Alle Stationen, die entweder RTS oder CTS empfangen, dürfen für
die Dauer der folgenden Übertragung das Medium nicht benutzen.
• Kollisionen können weiterhin auftreten wenn mehrere Stationen gleichzeitig ein RTS senden.
• Im Fall einer Kollision wird der Übertragungsversuch nach einer zufälligen Pause wiederholt.
• Das MACA-Verfahren ist die Grundlage des IEEE 802.11 Protokolls (Wireless LANs).
1.5.7
Tokenverfahren
Als Alternative zu den probabilistischen Verfahren können Tokenverfahren benutzt werden, bei
denen das Senderecht durch ein spezielles umlaufendes Bitmuster (Token) weitergereicht wird.
• Tokenverfahren lassen sich sehr einfach auf einer Ring-Topologie realisieren, da die Umlaufreihenfolge durch den Ring festgelegt ist (Token Ring).
• Auf einer Bus-Topologie kann man einen logischen Ring etablieren auf dem das Token kreist
(Token Bus).
24
KAPITEL 1. GRUNDLAGEN
Station A:
Station B:
Station C:
Zeit
Abbildung 1.24: Tokenverfahren
• Prinzipieller Vorteil von Token-Verfahren ist die Garantie von Tokenumlaufzeiten und damit
ein deterministischer Zugriff auf das Medium.
• Generell ist bei Tokenverfahren darauf zu achten, dass genau ein Token im Umlauf ist. Durch
Ausfälle, Störungen oder die Inbetriebnahme von neuen Stationen darf das Token nicht verloren gehen bzw. verdoppelt werden.
• Tokenverfahren sind die Grundlage des IEEE 802.4 Protokolls (Token Bus) und des IEEE
802.5 Protokolls (Token Ring).
25
1.6. ZUSAMMENHANGSBESONDERHEITEN
1.6 Zusammenhangsbesonderheiten
Neben Bitfehlern können auch Zusammenhangsbesonderheiten zwischen Datenblöcken auftreten:
• Verlust ganzer Datenblöcke
• Ungewollte Duplizierung ganzer Datenblöcke.
• Eintreffen von Phantom-Datenblöcken.
• Vertauschung der Reihenfolge ganzer Datenblöcke während der Übertragung.
1.6.1
Sequenznummern
Die Erkennung von verlorenen oder duplizierten Datenblöcken kann durch die Einführung von
Sequenznummern erfolgen.
Sender
Empf"anger
1
1
2
3
3
4
4
5
6
6
7
5
7
8
4
8
Abbildung 1.25: Sequenznummern
• Alle Datenblöcke werden durch aufsteigende Sequenznummern nummeriert, die mit den Datenblöcken übertragen werden.
• Der Empfänger überprüft die empfangene Sequenznummer und kann dadurch Abweichungen
von der Sendereihenfolge (Überholungen, Vertauschungen, Duplikate) erkennen.
• Der Verlust einer Nachricht kann vermutet werden, wenn die Differenz der Sequenznummer der zuletzt empfangenen Nachricht zu einer noch ausstehenden so groß ist, dass eine
Verzögerung unwahrscheinlich ist.
• Problem: Die Sequenznummern können schnell wachsen und unter Umständen bei zu kleinen
Nummernbereichen schnell überlaufen.
26
KAPITEL 1. GRUNDLAGEN
1.6.2
Quittungen und Sendewiederholungen
Verluste von Datenblöcken können durch Wiederholung der Übertragung korrigiert werden, wenn
man den Sender über den Verlust informieren kann:
Sender
Empf"anger
n
n
ACK n
ACK n
n+1
n+1 (Fehler)
NACK n+1
NACK n+1
n+1
n+1
ACK n+1
ACK n+1
Abbildung 1.26: Quittungen und Sendewiederholungen
• Zur Fehlerbehebung muß der Sender über einen erkannten Fehler informiert werden, damit
der Sender eine Sendewiederholung (retransmission) veranlassen kann.
• Quittungen sind ein Nachrichtenaustausch in Gegenrichtung, um entweder den Sender über
den korrekten Empfang einer Nachricht zu informieren (positive Quittung, acknowledgement, ACK), oder um den Sender über die Entdeckung eines Fehlers zu unterrichten (negative
Quittung, negative acknowledgement, NACK).
• Selektive positive Quittungen (selective acknowledgements, SACKs) beziehen sich auf genau
eine Nachricht oder eine konkrete Menge von Nachrichten. Kumulative Quittungen beziehen
sich in der Regel auf alle Nachrichten bis zu einer angegebenen Sequenznummer.
• Selektive negative Quittungen (selective negative acknowledgements, SNACKs) beziehen
sich auf genau eine Nachricht oder eine konkrete Menge von Nachrichten. Kumulative negative Quittungen beziehen sich in der Regel auf alle Nachrichten ab einer angegebenen Sequenznummer.
• Ein Protokoll, bei dem ein Datenblock nur dann übertragen wird, wenn die Übertragung des
vorherigen Datenblocks bestätigt wurde, nennt man stop-and-go Protokoll.
• Problem: Offensichtlich ist ein stop-and-go Protokoll nicht sehr effizient bezüglich der Leitungsausnutzung wenn die Umlaufzeiten relativ lang sind.
• Problem: Quittungen können verloren gehen, was zu einer Verklemmung führen kann.
27
1.6. ZUSAMMENHANGSBESONDERHEITEN
1.6.3
Zeitüberwachung
Potentielle Verklemmungen kann man durch die Einführung einer Zeitüberwachung (timer) verhindern.
Sender
Empf"anger
n
n
ACK n
n
n
ACK n
ACK n
n+1
n+1
n+1
ACK n+1
ACK n+1
Abbildung 1.27: Zeitüberwachung
• Der Verlust von Nachrichten oder Quittungen kann nicht erkannt werden, wenn der Sender
auf die Quittung des letzten Blocks wartet, bevor er den nächsten sendet, oder wenn der
Empfänger nicht das Ende der Übertragung kennt.
• Eine Zeitüberwachung (timer) beim Sender veranlasst automatisch die Wiederholung der
letzten Nachricht, falls in einem bestimmten Zeitintervall keine Quittung eingetroffen ist.
• Prinzipiell kann auch der Empfänger eine Zeitüberwachung implementieren, die die Wiederholung der letzten Quittung einleitet, wenn bis zum Ablauf der Zeitüberwachung kein
weiterer Datenblock eingetroffen ist.
• Problem: Die Zeitüberwachung muss sich an die aktuelle Verzögerung im Netz anpassen
um einerseits unnötige Wiederholungen zu vermeiden und andererseits Verluste möglichst
schnell zu entdecken.
1.6.4
Flusskontrolle
Man kann in der Regel einen Übertragungskanal besser ausnutzen, wenn der Sender mehrere Datenblöcke senden kann bevor er auf Quittungen wartet. Dabei entsteht aber das grundlegende Problem,
dass der Sender die Sendegeschwindigkeit der Geschwindigkeit des Empfängers anpassen muss,
um einen effizienten Datenfluss zu erreichen. Idealerweise sollte der Datenfluss so gleichmäßig wie
möglich ablaufen.
28
KAPITEL 1. GRUNDLAGEN
Sender
Empf"anger
n+0
n+1
n+2
ACK n+0
n+3
ACK n+1
n+4
ACK n+2
n+5
ACK n+3
n+6
n+4
ACK n+5
n+7
n+6
ACK n+4
n+8
ACK n+7
n+9
ACK n+6
ACK n+8
n+0
ACK n+0
n+1
ACK n+1
n+2
ACK n+2
n+3
ACK n+3
n+5
ACK n+5
n+6
ACK n+6
n+4
ACK n+4
n+7
ACK n+7
n+6
ACK n+6
n+8
ACK n+8
n+9
ACK n+9
ACK n+9
Abbildung 1.28: Unbestätigte Datenblöcke erfordern Sende- und Empfangspuffer
• Wenn der Sender schneller Datenblöcke sendet als der Empfänger Datenblöcke verarbeiten
kann, dann werden beim Empfänger Empfangspuffer überlaufen und dadurch ganze Datenblöcke verloren gehen.
• Analog kann der Sender nur soviele unbestätigte Pakete versenden, wie er in seinem Sendepuffer speichern kann, da beim Ablauf einer Zeitüberwachung die Daten zur Wiederholung
verfügbar sein müssen.
Fenstertechnik
Bei der Fenstertechnik (sliding window) legt der Sender und der Empfänger ein Fenster (window)
über den zur Verfügung stehenden Sequenznummernbereich.
• Der Sender darf nur die Datenblöcke versenden, deren Sequenznummern in dem Sendefenster
liegen. Danach muss auf Quittungen gewartet werden.
• Beim Eintreffen von aufsteigenden Quittungen wird das Fenster auf dem Sequenznummernbereich verschoben (sliding).
• Der Empfänger nimmt nur Datenblöcke entgegen (und puffert sie gegebenenfalls), deren Sequenznummern in dem Empfangsfenster liegen.
• Beim Vorliegen von Datenblöcken mit aufsteigenden Sequenznummern werden die Daten zugestellt und das Empfangsfenster wird auf dem Sequenznummernbereich entsprechend verschoben.
1.6. ZUSAMMENHANGSBESONDERHEITEN
29
• Durch das Aushandeln der Fenstergrößen kann die Senderate auf die Pufferkapazität des
Empfängers eingestellt werden.
• Implementation auf der Senderseite:
– SWS (send window size):
Maximale Anzahl ausstehender Quittungen
– LAR (last ack received):
Sequenznummer des letzten in aufsteigender Reihenfolge quittierten Datenblocks
– LFS (last frame send):
Sequenznummer des letzten gesendeten Datenblocks
Offenbar gilt die Invariante LFS - LAR + 1 ≤ SWS.
• Implementation auf der Empfängerseite:
– RWS (receiver window size):
Maximale Anzahl nicht in Reihenfolge empfangener Datenblöcke
– LFA (last frame acceptable):
Sequenznummer des letzten empfangbaren Datenblocks
– NFE (next frame expected):
Sequenznummer des nächsten in Reihenfolge erwarteten Datenblocks
Offenbar gilt die Invariante LFA - NFE + 1 ≤ RWS.
Ratenbasierte Flusskontrolle
Bei der ratenbasierten Flusskontrolle darf der Sender die Datenblöcke nur mit einer nach oben
begrenzten Rate senden.
• Es existiert ein minimales Zeitintervall zwischen aufeinanderfolgenden Datenblöcken das
nicht unterschritten werden darf.
• Eine ratenbasierte Flusskontrolle vermeidet Büschel (bursts) von schnell aufeinanderfolgenden Datenpaketen.
• Sender und Empfänger müssen das minimale Zeitintervall abhängig von der maximalen
Größe der Datenblöcke und den zur Verfügung stehenden Puffern bestimmen und aushandeln.
1.6.5
Staukontrolle
Die Flusskontrolle regelt den Datenfluss zwischen Sender und Empfänger (end-to-end flow control). Innerhalb des Netzes kann es aber auch auf Zwischensystemen zu Überlastsituationen kommen, sogenannte Staus (congestion). Prinzipiell gibt es folgende Verfahren, um mit Staussituationen
umzugehen:
• Um Staus zu vermeiden können Sender und Empfänger vor dem eigentlichen Datenaustausch
auf dem Weg zwischen Sender und Empfänger genügend Pufferkapazität und Bandbreite
reservieren.
30
KAPITEL 1. GRUNDLAGEN
• Benutzt man keine Reservierungen, so können alternativ Zwischensysteme einfach Pakete
verwerfen, wobei Sender und Empfänger durch entsprechendes Quittungsspiel und Zeitüberwachungen sinnvoll reagieren müssen.
• Ein überlastetes Zwischensystem schickt spezielle Nachrichten (choke pakets), um die Überlastung anzuzeigen und den Sender um eine Reduktion der Sendegeschwindigkeit zu bitten.
1.7 Netzwerk-Architekturen
In diesem Abschnitt werden prinzipielle Architekturkonzepte von Netzwerken eingeführt. Grundlegend ist dabei die Zerlegung von komplexen Kommunikationssysteme in einfachere Teilsysteme
mit wohl definierten Schnittstellen. Die Bildung geschichteter System ist ein grundlegendes Prinzip
zur Strukturierung von Kommunikationssystemen.
1.7.1
Dienste
Die von einem Netz bereitgestellten Funktionen werden zusammen abstrakt als Dienst (service)
bezeichnet.
• Ein Dienst wird über eine Menge von Dienstprimitive (service primitives) in Anspruch genommen. Typische ISO/OSI Dienstprimitive sind:
– Anforderung eines Dienstes (request)
– Anzeige eines Dienstaufrufs (indication)
– Reaktion auf die Dienstanzeige (response)
– Bestätigung über die Erbringung eines Dienstes (confirmation)
• Die Schnittstelle, über die die Dienstprimitive in Anspruch genommen werden können, wird
als Dienstzugangspunkt (service access point, SAP) bezeichnet.
• Die Dienste werden durch sogenannte Instanzen realisiert. Instanzen auf der Schicht N eines
geschichteten Systems werden auch als N -Instanzen bezeichnet.
• Eine strikte Schichtung erfordert, dass N -Instanzen nur Dienste, die von (N − 1)-Instanzen
erbracht werden, für die Realisierung der eigenen Dienste in Anspruch nehmen.
1.7.2
Protokolle
Ein Protokoll (protocol) ist ein Satz von Funktionen, die einen definierten Kommunikationsdienst
erbringen (z.B. fehlerfreie ordnungserhaltende Übertragung von Daten zwischen zwei Stationen).
• Protokolle definieren die Formate und die Bedeutung der ausgetauschten Dateneinheiten
(protocol data units, PDUs).
• Protokolle definieren auch die Regeln nach denen die Dateneinheiten generiert bzw. verarbeitet werden müssen.
1.7. NETZWERK-ARCHITEKTUREN
31
• Die Instanziierung eines Protokolls zur Laufzeit nennt man eine Protokollinstanz. Auf einem
System können mehrere Protokollinstanzen gleichzeitig existieren.
• Für verschiedene Aufgaben stehen jeweils spezialisierte Protokolle bereit. Prinzipiell kann
auch derselbe Dienst durch verschiedene Protokolle realisiert werden.
• Die Spezifikation von Protokollen kann informal (plain english) oder formalisiert durch formale Spezifikationssprachen (Lotos, Estelle, SDL) erfolgen.
1.7.3
Namen und Adressen
Zur Identifikation von Stationen in einem Rechnernetz werden oftmals Namen und Adressen verwendet.
• Ein Name ist eine für Menschen relativ leicht lesbare Kennung eines Systems, wie z.B.
www.informatik.uni-osnabrueck.de.
• Namen sind in der Regel variabel lang und oftmals hierarchisch strukturiert.
• Eine Adresse ist eine für Maschinen relativ gut verarbeitbare Kennung eines Systems, wie
z.B. 134.169.34.192.
• Adressen haben in der Regel eine feste Länge und sind relativ kompakt.
Adressen im ISDN-Telefonnetz
Adressen im ISDN-Telefonnetz sind nach dem Standard E.164 der ITU strukturiert:
• Eine internationale ISDN-Telefonnummer besteht aus maximal 15 Ziffern, wobei die ersten
Ziffern die Länderkennzahl enthalten, gefolgt von dem nationalen Zielcode und schließlich
der Teilnehmernummer.
• An eine internationale ISDN-Telefonnummer kann sich eine bis zu 40 Ziffern lange Unternummer anschließen.
• Die Notation für internationale ISDN-Telefonnummern erfolgt durch ein + Symbol gefolgt
von den Ziffern, die durch Leerzeichen in einzelne Blöcke getrennt werden, wie z.B. die
Nummer +49 541 9692483.
Adressen im Internet
Netzwerkadressen im Internet haben abhängig vom verwendeten Protokoll (IPv4 oder IPv6) entweder eine Länge von 4 Byte oder eine Länge von 16 Byte.
• 4-Byte IPv4 Adressen werden byteweise als Dezimalzahlen notiert, wobei die einzelnen Zahlen durch Punkte voneinander getrennt sind (z.B. 134.169.34.123).
32
KAPITEL 1. GRUNDLAGEN
• 16-Byte IPv6 Adressen werden byteweise als Hexadezimalzahlen notiert, wobei die einzelnen Zahlen durch Doppelpunkte voneinander getrennt sind. Führende Nullen können weggelassen werden, z.B. 1080:0:0:0:8:800:200C:417A. Mit der speziellen Notation ::
kann eine Gruppe von aufeinanderfolgenden 0x0000 Bytepaaren abgekürzt werden, z.B.
1080::8:800:200C:417A. Für den besonderen Fall, dass eine IPv6 Adresse eine IPv4
Adresse enthält, gibt es auch noch eine gemischte Notation, bei der die IPv4 Adresse in
normaler IPv4 Notation in den letzten 4 Bytes des IPv6 Adresse untergebracht wird, z.B.
::13.1.68.3 anstatt 0:0:0:0:0:0:0D01:4403 bzw. ::0D01:4403.
Für weitere Details siehe RFC 1884 [8]. Eine weitere noch kompaktere Notation ist in RFC
1924 [9] beschrieben (lesenswert).
Adressen in IEEE 802 Netzen
Adressen in IEEE 802 Netzen, gelegentlich auch MAC-Adressen genannt, bestehen im allgemeinen
aus 6 Bytes. (Es gibt auch 2 Byte IEEE 802 Adressen, die aber wenig verbreitet sind.)
• Die übliche Notation von IEEE 802 Adressen ist eine Folge von Hexadezimalzahlen (eine
Zahl für jedes Byte der Adresse), wobei die Zahlen durch Doppelpunkte oder Bindestriche
voneinander getrennt sind, z.B. 00:D0:59:5C:03:8A oder 00-D0-59-5C-03-8A.
• Das höchste Bit einer IEEE 802 Adresse zeigt an, ob es sich um eine normale unicast Adresse (0) oder eine multicast Adresse (1) handelt. Eine broadcast Adresse, unter der sich alle
Stationen einer Domain angesprochen fühlen, besteht aus 48 gesetzten Bits.
• Das zweithöchste Bit einer IEEE 802 Adresse bestimmt, ob es sich um eine lokale Adresse
(1) oder eine globale Adresse (0) handelt. Eine lokale Adresse wird administrativ zugewiesen
und ist nur in diesem administrativen Bereich eindeutig während globale Adressen global
eindeutig sind.
• Globale IEEE 802 Adressen werden erzeugt indem die IEEE Nummernbereiche an Hersteller vergibt (identifiziert durch die ersten drei Bytes). Die Hersteller weisen dann von diesen
Nummernbereichen für jede produzierte Netzwerkkarte eine eindeutige Nummer zu.
Namen im Internet
Internet Adressen sind optimiert für technische Systeme und nicht sonderlich geeignet für Menschen. Darum werden zusätzlich Namen eingeführt, die besser an die Bedürfnisse von Menschen
angepasst sind.
• Das Domain Name System (DNS) definiert einen verteilt realisierten hierarchischen Namensraum, der insbesondere die Delegation der Namenszuweisung unterstützt.
• Oftmals spiegelt der DNS-Namensraum die organisatorische Struktur von Organisationen
wieder.
• Bei der Benutzung von Namen findet grundsätzlich eine Namensauflösung statt, bei der zu
einem Namen eine passende IP Adresse gesucht wird.
• Frage: Ist eine Internationalisierung der DNS-Namen sinnvoll? Wie könnte man das technisch
realisieren?
33
1.7. NETZWERK-ARCHITEKTUREN
virtual Root
nl
de
edu
org
net
com
biz
Toplevel
uni−osnabrueck
2nd Level
informatik
3rd Level
www
4th Level
Abbildung 1.29: Struktur der Domain Name System (DNS) Namen
1.7.4
ISO/OSI Schichtenmodell
Anwendungsprozess
Application Process
Endsystem
End System
Application
Darstellung
Presentation
Sitzung
Session
Transportsystem
Transport
Transitsystem
Netzwerk
Network
Network
Sicherung
Data Link
Data Link
Bit"ubertragung
Physical
Physical
Medium
Transport
Media
Abbildung 1.30: ISO/OSI Referenzmodell
Bitübertragungsschicht (physical layer)
• Übertragung einer Folge von Bits über ein Medium.
• Festlegung von Eigenschaften des benutzten Mediums.
• Darstellung der Werte 0 und 1 (z.B. Spannungswerte, Frequenzen).
• Synchronisation zwischen Sender und Empfänger.
Transport System
Anwendungssystem
Anwendung
Aplication System
Das ISO/OSI Schichtenmodell ist das klassische Schichtenmodell. Es wird oft als Referenz benutzt,
daher auch die Bezeichnung OSI Referenzmodell. Reale Datennetze haben in den seltensten Fällen
genau die im Referenzmodell vorgesehenen sieben Schichten.
34
KAPITEL 1. GRUNDLAGEN
• Festlegungen von Steckernormen.
Sicherungsschicht (data link layer)
• Übertragung von Bitfolgen in Rahmen (frames).
• Datenübertragung zwischen Systemen die ein gemeinsames Medium besitzen.
• Erkennung und ggf. Behebung von Übertragungsfehlern.
• Flusssteuerung zur Behandlung von Überlastsituationen.
• Realisierung meist in Hardware auf Adapterkarten.
Vermittlungsschicht (network layer)
• Bestimmung von Wegen durch das Kommunikationsnetz.
• Multiplexen von Endsystemverbindungen über eine Zwischenverbindung.
• Fehlererkennung und -behebung zwischen Endsystemen.
• Flusssteuerung zwischen Endsystemen.
• Aufteilung eines Pakets (packet) in Rahmen (frames).
Transportschicht (transport layer)
• Ende-zu-Ende Kommunikationskanäle zwischen Applikationen.
• Virtuelle Verbindungen über verbindungslose Datagrammdienste.
• Fehlererkennung und -behebung zwischen Transport-Endpunkten.
• Flusssteuerung zwischen Transport-Endpunkten.
• Unter Umständen Unterstützung verschiedener Dienstgüten.
Sitzungsschicht (session layer)
• Synchronisation und Koordination von kommunizierenden Prozessen.
• Interaktionssteuerung (Sicherungspunkte).
Darstellungsschicht (presentation layer)
• Transformation und Anpassung von unterschiedlichen Datendarstellungen.
• Serialisierung von komplexen Datenstrukturen zum Zweck der Übertragung.
• Datenkompression.
35
1.7. NETZWERK-ARCHITEKTUREN
Anwendungsschicht (application layer)
• Bereitstellung von grundlegenden anwendungsnahen Diensten.
• Beispiele: Terminalemulationen, Namensraumverwaltung, Datenbankzugriff, Netzmanagement, elektronische Nachrichtensysteme, Prozess- und Maschinensteuerung, . . .
1.7.5
Internet Schichtenmodell
Anwendungsprozess
Application Process
Endsystem
End System
Anwendung
Application
Transport
Transport
Transitsystem
Internet
Network
Internet
Subnetzwerk
Subnetwork
Subnetwork
Medium
Media
Abbildung 1.31: Internet Schichtenmodell
• Das Internet ist als Netz konzipiert, das über nahezu beliebige Kommunikationsnetze gelegt
werden kann (siehe auch insbesonders RFC 1149 [10]). Entsprechend ist die Schicht unterhalb der Internet Schicht (die im wesentlichen der ISO/OSI Netzwerkschicht entspricht)
einfach ein beliebiges Subnetzwerk.
• Das Internet-Protokoll (IP) schafft eine gemeinsame Basis auf der man über die Grenzen der
verschiedenen Netztechnologien hinweg kommunizieren kann.
• Natürlich kann auch das Internet-Protokoll selbst als Subnetzwerk fungieren — man bekommt dann sogenannte IP-Tunnel.
• Auf der Internet-Schicht gibt es im wesentlichen zwei Protokolle. Derzeit am weitesten verbreitete ist IP Version 4 (IPv4), wobei der Nachfolger IP Version 6 (IPv6) langsam an Bedeutung gewinnt.
• Bei den Internet-Protokollen steht immer auch der Wunsch nach einfacher Implementierbarkeit (ursprünglich meist in Software) im Vordergrund.
• Die Internet-Protokolle unterstützen primär Datenkommunikation (asynchron, in der Regel
nicht isochron).
• Implementationen der Internet-Protokolle sind in der Regel frei zugänglich, was deren Verbreitung unterstützt.
36
KAPITEL 1. GRUNDLAGEN
1.8 Standardisierung
Die Standardisierung von Protokollen schafft einheitliche Netzwerk-Architekturen, die eine offene (d.h. herstellerunabhängige) Kommunikation ermöglichen. Herstellerspezifische Protokolle und
Netzwerk-Architekturen (z.B. SNA, DECnet) haben an Bedeutung verloren.
Activity
Time for Standardization
Research
Investment
Time
Abbildung 1.32: Theorie der Standardisierung
Die Standardisierung selbst ist ein kritischer und in der Regel aufwendiger Prozess.
• Der Erfolg eines Standards muss man in der Anzahl der in Betrieb befindlichen interoperablen
Implementationen messen.
• Standards müssen es Geräteherstellern erlauben, ihre Produkte zu differenzieren.
• Erfolgreiche Standards erzeugen einen Markt für Produkte.
• Der richtige Zeitpunkt ist ein wichtiger Faktor für den Erfolg eines Standards.
Es gibt viele verschiedene Organisationen die Standards im Bereich der Kommunikationsnetze beschließen. Die für diese Vorlesung wichtigsten werden nun kurz vorgestellt.
1.8.1
ISO Standardisierung
• Die International Organization for Standardization (ISO) ist eine freiwillige, nicht per Staatsvertrag geregelte Organisation zur internationalen Normung.
• Die Mitglieder der ISO setzen sich aus den Normungsinstituten der einzelnen Mitgliedsländer
zusammen (ANSI für die USA, DIN für Deutschland).
• ISO-Standardisierungsmodell:
1. Entwurfsvorschlag (Draft Proposal, DP)
2. Entwurf (Draft International Standard, DIS)
3. Standard (International Standard, IS)
Die jeweiligen Übergänge bedürfen Mehrheiten bei Abstimmungen und können sich ggf.
mehrmals zyklisch wiederholen.
37
1.8. STANDARDISIERUNG
• Standards werden durch Nummern identifiziert, wobei verschiedene Revisionen durch das
Anhängen von Jahreszahlen unterschieden werden.
• Die Open Systems Interconnection (OSI) umfasst den Teil der ISO Standards, der sich mit
der Kommunikation in offenen (Kommunikations-) Systemen befasst.
1.8.2
Internet Standardisierung
Historic
Working Group
Document
(Internet Draft)
Proposed Standard
(RFC)
Historic
Draft Standard
(RFC)
Historic
Internet Standard
(RFC)
Abbildung 1.33: Prozessmodell der Internet-Standardisierung
• Die Standardisierung der Internet-Protokolle wird durch die Internet Engineering Task Force
(IETF) durchgeführt (RFC 3233 [11], RFC 2026 [12]).
• Internet-Standards werden in der Regel durch Arbeitsgruppen (working groups, WGs) ausgearbeitet, die in verschiedenen Bereichen (areas) organisiert sind.
• Jeder Bereich hat in der Regel zwei Leiter (area directors, ADs). Die Leiter aller Bereiche
zusammen bilden zusammen die Internet Engineering Steering Group (IESG), die alle Standards verabschieden muss.
• IETF-Standardisierungsmodell:
1. Vorgeschlagener Standard (Proposed Standard)
2. Vorläufiger Standard (Draft Standard)
3. Internet Standard (Standard)
Die jeweiligen Übergänge erfordern rough consensus and running code“, d.h. mehrere un”
abhängige interoperable Implementationen.
• Standards werden als Request for Comments (RFCs) publiziert. Jeder RFC hat eine eindeutige Nummer und wird nach der Publikation nie verändert. Verschiedene Versionen eines
Standards haben also verschiedene RFC Nummern. Achtung: Nicht alle RFCs sind auch
Standards!
• Das Internet Architecture Board (IAB) ist ein übergeordnetes Gremium, das sich mit längerfristigen Architekturfragen befasst.
• Parallel zur IETF existiert die Internet Research Task Force (IRTF), die sich Forschungsfragen widmet, die eventuell zukünftig zu einer Standardisierung in der IETF führen. Die IRTF
ist wiederum in Arbeitsgruppen organisiert, wobei die Leiter der Arbeitsgruppen zusammen
die Internet Research Steering Group (IRSG) bilden.
38
KAPITEL 1. GRUNDLAGEN
1.8.3
IEEE Standardisierung
Für die Standardisierung innerhalb der IEEE ist das IEEE-SA Standards Board verantwortlich. Die
bei der Arbeit an Standards generierten Dokumente werden folgenden Kategorieren zugeordnet:
• Ein Standard ist ein Dokument, das einen IEEE Standard festlegt.
• Prozeduren können in Recommended Practices beschrieben werden.
• In Guides können alternative Ansätze und zusätzliche Informationen beschrieben werden.
• Ein Trial-Use Document existiert nach der Publikation nur für einen begrenzten Zeitraum.
Ein IEEE Standardisierungsprojekt kann verschiedene Klassen von Dokumenten produzieren:
• Ein neues Dokument (New) legt einen neuen Standard fest, der keine Revision eines existierenden Standards ist.
• Ein existierender Standard kann durch ein neues Dokument (Revision) aktualisiert oder ersetzt werden.
• In einem existierenden Standard können durch ein Dokument substantielle Korrekturen vorgenommen werden (Corrigenda).
• Ein existierender Standard kann durch ein Dokument erweitert werden, wobei auch substantielle Korrekturen angebracht werden können (Amendment).
In der IEEE ist ein sogenannter Sponsor für die Durchführung und Abwicklung einer Standardisierung verantwortlich. Zunächst muss ein konkretes Projekt durch ein Project Authorization Request
(PAR) beantragt werden. Das IEEE-SA Standards Board ist das Gremium, das über die Annahme
von PARs entscheidet. Zur Begutachtung von PARs existiert ein New Standards Committee (NesCom).
Die technische Arbeit wird durch ein Abstimmungsverfahren (Ballot) abgeschlossen. Prinzipiell
sollen negative Stimmen durch entsprechende Bemühungen um Konsens vermieden werden. Nach
der Abstimmung wird der Entwurf eines Standards dem IEEE-SA Standards Board zur Verabschiedung weitergeleitet, das ihrerseits wiederum das Review Committee (RevCom) zur Begutachtung
heranzieht.
Kapitel 2
Lokale Netze nach IEEE 802
Die IEEE Standards der Serie 802.x werden seit Mitte der 80er Jahre entwickelt und dominieren seit
vielen Jahren den Bereich der lokalen Netze (local area networks, LANs) und breiten sich derzeit
auch in den Bereich der Nahbereichsnetze (metropolitan area networks, MANs) aus. Einige der
IEEE 802.x Standards wurden auch von der ISO als offizielle ISO Standards übernommen.
802.1 Management
802 Overview and Architecture
802.2 Logical Link Control
802.1 Bridging
802.3
Medium
Access
802.4
Medium
Access
802.5
Medium
Access
802.6
Medium
Access
Ethernet
Token Bus
Token Ring
DQDB
802.3
Physical
802.4
Physical
802.5
Physical
802.6
Physical
802.9
Medium
Access
802.11
Medium
Access
802.12
Medium
Access
WaveLan
802.9
Physical
802.11
Physical
802.12
Physical
Abbildung 2.1: Übersicht über die IEEE 802 Standards
Die wohl derzeit bekanntesten Standards sind das Ethernet (IEEE 802.3) und WaveLANs (IEEE
802.11). Bluetooth wurde im März 2002 als IEEE 802.15 verabschiedet.
Die IEEE 802.x Standards decken funktional die beiden untersten Schichten des ISO/OSI-Referenzmodells ab, wobei sie selbst jedoch eine weitergehende Schichteneinteilung besitzen:
• Die Logical Link Control (LLC) Schicht stellt eine Schnittstelle bereit, die für alle IEEE 802
Protokolle gleich ist. Protokolle auf der Netzwerk-Schicht (z.B. das Internet Protokoll IP)
nutzen die Dienste der LLC-Schicht.
• Die Medium Access Control (MAC) Schicht definiert das Zugriffsverfahren auf das verwendete Medium.
• Die Physikalische (PHY) Schicht beschreibt die physikalischen Eigenschaften der Übertragungsmedien.
39
40
KAPITEL 2. LOKALE NETZE NACH IEEE 802
Anwendungsprozess
Endsystem
Anwendungssystem
Anwendung
Darstellung
Sitzung
Transport
Logical Link Control (LLC)
Sicherung
Media Access Control (MAC)
Bit"ubertragung
IEEE 802
Transportsystem
Netzwerk
Physical (PHY)
Abbildung 2.2: IEEE 802 Schichten im ISO/OSI Referenzmodell
• Effektiv wurde die ISO/OSI Sicherungsschicht in zwei Schichten (LLC, MAC) unterteilt, um
verschiedenen Zugriffsverfahren mit einer gemeinsamen Schnittstelle definieren zu können.
2.1
Logical Link Control (IEEE 802.2)
...
2.2
Ethernet (IEEE 802.3)
Der IEEE 802.3 Standard ist allgemein als Ethernet1 bekannt. Die Technologie wurde in den 70er
Jahren am XEROX PARC entwickelt [?] und später mit kleinen Änderungen von der IEEE standardisiert [13]. Das klassische IEEE 802.3 Netz ist ein 1-persistentes CSMA/CD Netz mit einer
Geschwindigkeit von 1-10 Mbps. Später wurden Erweiterungen für 100 Mbps und 1000 Mbps (1
Gbps) entwickelt. Im Juni 2002 wurde eine Standard für 10 Gbps Ethernet verabschiedet.
2.2.1
Physikalische Schicht
In der Physikalischen Schicht werden die übertragungstechnischen Aspekte festgelegt. Es gibt verschiedene Übertragungsmedien:
1
Der Begriff Ethernet wird heutzutage fast synonym für die IEEE 802.3 Standards und CSMA/CD benutzt, obwohl
dies nicht wirklich korrekt ist.
41
2.2. ETHERNET (IEEE 802.3)
Name
10Base2
10Base5
10BaseT
10BaseF
2.2.2
Medium
Koaxialkabel
Koaxialkabel
Twisted Pair
Lichtwellenleiter
max. Länge
200 m
500 m
100 m
2000 m
max. Stationen
30
100
1024
1024
Bemerkungen
Bustopologie, o=0.25 in
Bustopologie, o=0.5 in
Sterntopologie
Sterntopologie
MAC-Schicht
preamble
7 Byte
start−of−frame delimiter (SFD)
1 Byte
destination MAC address
6 Byte
source MAC address
6 Byte
length / type field
2 Byte
data
(network layer packet)
64−1518 Byte
Das Ethernet-Rahmenformat ist relativ einfach:
46−1500 Byte
padding (if required)
frame check sequence (FCS)
4 Byte
Abbildung 2.3: IEEE 802.3 Rahmenformat
• Die sieben Byte lange Präambel (preamble) besteht aus dem Bitmuster 10101010. Durch die
Manchester Codierung ergibt sich eine periodische Wellenform auf die sich die Empfänger
synchronisieren.
• Das Startbyte (start-of-frame delimiter, SFD) hat das Bitmuster 10101011 und zeigt durch
die Unregelmäßigkeit den Anfang des eigentlichen Rahmen an.
• Die Ziel- und Quelladressen sind 6 Byte lange IEEE MAC-Adressen.
• Das 2-Byte Type/Length-Feld enthält entweder die Länge des Rahmens (Wert kleiner als
0x600) oder aber die Identifikation des in den Daten enthaltenen Protokolls (Wert größer
oder gleich 0x600). Die Typnummern werden von der IEEE vergeben.
• Der Datenbereich enthält die eigentlichen Daten, in der Regel ein Paket der Netzwerkschicht.
Gegebenenfalls wird das Paket noch mit Füllbytes auf die erforderliche Minimallänge gebracht.
• Am Ende des Paket befindet sich eine 4 Byte lange CRC Prüfsumme (CRC-32).
42
KAPITEL 2. LOKALE NETZE NACH IEEE 802
wait for frame to transmit
format frame for transmission
carrier sense signal on?
Y
N
wait interframe gap time
start transmission
collision detected?
Y
N
complete transmission and
set status transmission done
transmit jam sequence and
increment # attempts
attempt limit reached?
set status attempt limit exceeded
Y
N
compute and wait backoff time
Abbildung 2.4: IEEE 802.3 MAC Ablaufslogik beim Senden eines Rahmens
Bei der Übertragung eines IEEE 802.3 Rahmen wird das CSMA/CD Verfahren eingesetzt. Dabei
spielen für ein klassisches 10 Mbps LAN folgende Parameter eine Rolle:
• Die Slot-Zeit (slot time) von 512 Bitzeiten ergibt sich aus der doppelten maximale Ausbreitungsverzögerung plus etwas Sicherheit.
• Zwischen zwei aufeinanderfolgenden Rahmen muss eine Pause von 9.6 µs eingehalten werden (interframe gap).
• Die minimale Länge eines Rahmens ist 64 Byte; die maximale Länge ist 1518 Byte.
• Nach einer Kollision wird für die Dauer von 32 Bit ein Jam-Signal gesendet.
• Die Übertragung eines Rahmens wird bei Kollisionen maximal 16 mal versucht.
• Nach jeder Kollision wird eine zufällige Anzahl von Slotzeiten gewartet, bevor der Übertragungsversuch wiederholt wird. Beim n-ten Versuch wird eine gleichverteilte Zahl aus dem
Bereich 0 ≤ R < 2k gezogen, wobei sich k aus k = min(n, b) ergibt mit dem bake-off-limit
b = 10.
43
2.2. ETHERNET (IEEE 802.3)
incoming signal detected?
N
Y
set carrier sense signal on
obtain bit sync and wait for SFD
receive frame
FCS and frame size OK?
N
Y
destination address matches
own or group address?
N
Y
pass data to higher-layer
protocol entity for processing
discard frame
Abbildung 2.5: IEEE 802.3 MAC Ablaufslogik beim Empfangen eines Rahmens
Es gibt eine Reihe definierter Fehlersituationen, die von der MAC-Schicht erkannt werden sollten:
• alignment errors: Rahmen, die nicht eine integrale Anzahl von Bytes sind und den CRC-Test
nicht bestehen.
• FCS errors: Rahmen mit einer gültigen Länge, die den CRC-Test nicht bestehen.
• deferred transmissions: Rahmen, die nicht sofort übertragen werden konnten, da das Medium
belegt ist.
• single collision frames: Rahmen, die nach einer Kollision erfolgreich übertragen werden
konnten.
• multiple collision frames: Rahmen, die nach mehreren Kollisionen erfolgreich übertragen
werden konnten.
• excessive collisions: Rahmen, die nicht übertragen werden konnten, da alle Versuche zu einer
Kollision führten.
• late collisions: Kollisionen, die nach der Slotzeit nach dem Start der Übertragung erkannt
werden. Dies ist typischerweise ein Hinweis auf Kabel, die die in den Spezifikationen definierten maximalen Längen überschreiten.
• internal MAC transmit errors: Nicht näher definierte MAC-interne Fehler beim Senden.
44
KAPITEL 2. LOKALE NETZE NACH IEEE 802
• internal MAC receive errors: Nicht näher definierte MAC-interne Fehler beim Empfangen.
• carrier sense errors: Probleme beim Abhören des Carrier-Signals während einer Übertragung.
• frame too long errors: Rahmen, die die maximal erlaubte Länge der Rahmen überschreiten.
2.3
Fast-Ethernet (IEEE 802.3U)
Das klassische 10 Mbps Ethernet erlaubt eine maximale Kabellänge (inklusive möglicher Repeater)
von 2.5km, woraus sich eine maximale Ausbreitungsverzögerung (inklusive Verzögerung in den
Repeatern) von 50µs ergibt. Daraus leitet sich dann eine minimale Paketlänge von 512 Bit ab.
• Ziel bei der Entwicklung von Fast-Ethernet war eine Datenrate von 100 Mbps ohne Änderungen am Medienzugangsverfahren. Mit einer höheren Bitrate muss man entsprechend die
maximale Kabellänge reduzieren.
• Die maximale Kabellänge ist bei Fast-Ethernet auf 100m begrenzt. Diese relativ kurze Länge
ist durchaus akzeptabel, da man von einer Verkabelung durch verdrillte Kupferkabel mit
Sterntopologie ausgeht.
Da man sowohl UTP Kategorie 3 und 5 Kabel erlauben wollte, ergeben sich auf der physikalischen
Schicht einige Besonderheiten.
100Base4T
100BaseTX
100BaseFX
Twisted Pair
Twisted Pair
Fiber
?m
?m
?m
?
?
?
xxx
xxx
xxx
2.4 Gigabit-Ethernet (IEEE 802.3Z)
1000BaseL
1000BaseC
1000BaseT
Fiber
Coax
Twisted Pair
?m
?m
?m
?
?
?
xxx
xxx
xxx
2.5 10 Gigabit-Ethernet (IEEE 802.AE)
...
2.6 Wireless LANs (IEEE 802.11)
...
45
2.7. BRÜCKEN
2.7 Brücken
Mehrere IEEE 802 LANs können mit Hilfe von Brücken (bridges) verbunden werden. Dabei spielt
prinzipiell die in den jeweiligen Segmenten verwendete IEEE 802 Technologie keine Rolle.
802.11
B3
10Base5
B1
B2
10Base2
100BaseT
10Base2
802.5
Abbildung 2.6: Brücken zur Kopplung von verschiedenen LAN Segmenten
Brücken bieten einige wichtige Vorteile:
1. Verschiedene IEEE 802 LAN-Technologien können durch Brücken miteinander verbunden
werden.
2. LANs, die geographisch verteilt sind, können durch Brücken verbunden werden.
3. Die Aufteilung von überlasteten LANs in kleinere LANs kann die Leistungsfähigkeit verbessern.
4. Mit Hilfe von Brücken können Entfernungen überwunden werden, die mit einzelnen LANTechnologien nicht realisierbar wären.
5. Brücken verbessern die Robustheit, da viele Ausfälle sich nur lokal auf ein LAN auswirken.
6. Brücken können die Sicherheit verbessern, da sie einen Großteil des Verkehr auf die notwendigen LAN Segmente beschränken können.
46
KAPITEL 2. LOKALE NETZE NACH IEEE 802
Brücken arbeiten auf der IEEE 802 LLC-Schicht und können dadurch verschiedene IEEE 802 LANTechnologien überbrücken.
Network
Network
Bridge
IEEE 802.2 LLC
IEEE 802.2 LLC
IEEE 802.2 LLC
IEEE 802.3 MAC
IEEE 802.3 MAC
IEEE 802.11 MAC
IEEE 802.11 MAC
IEEE 802.3 PHY
IEEE 802.3 PHY
IEEE 802.11 PHY
IEEE 802.11 PHY
Abbildung 2.7: IEEE 802 Brücken
Obwohl konzeptionell einfach, gibt es trotzdem einige Dinge zu beachten:
• Die verschiedenen LANs werden im allgemeinen unterschiedliche Datenraten haben und entsprechend muss eine Brücke Daten puffern, wobei die Pufferkapazität natürlich endlich ist.
• Die verschiedenen LANs können unterschiedliche maximale Paketgrößen haben. Trifft nun
ein Paket an einer Brücke ein, dessen Länge die Paketgröße des Ziel-LANs übersteigt, kann
die Brücke das Paket nicht weiterleiten.
• Durch unterschiedliche Geschwindigkeiten auf verschiedenen LANs kann u.U. die Zeitüberwachung auf höheren Protokollschichten verwirrt werden, was zu vorzeitigen Wiederholungen führen kann.
• Einige LAN-Technologien unterstützen Prioritäten, die in anderen Technologien nicht vorhanden sind.
• Einige LAN-Technologien signalisieren die erfolgte Zustellung von Rahmen, was aber bei
anderen Technologien nicht als Ereignis signalisiert wird.
Es gibt zwei verschiedene Arten von Brücken.
• Transparente Brücken (transparent bridges, spanning tree bridges) benötigen keine Konfiguration und passen sich automatisch ihrer Umgebung an. Sie sind sowohl aus der Sicht der
LANs als auch aus der Sicht der Netzbetreiber vollkommen transparent. Der Preis dafür ist
jedoch, dass die zur Verfügung stehende Bandbreite nicht unbedingt optimal ausgenutzt wird.
• Source Routing Bridges erfordern, dass die sendenden Stationen zwischen Stationen am lokalen LAN und entfernten LANs unterscheiden kann. Wenn ein Paket an ein entferntes LAN
geschickt wird, muss die sendende Station den Weg ermitteln, die der Rahmen nehmen soll.
Der Vorteil hierbei ist, dass man die Bandbreite besser ausnutzen kann (unterschiedliche Wege von einem LAN zu einem anderen). Der Preis ist jedoch wesentlich höhere Komplexität
bei allen beteiligten Komponenten.
47
2.7. BRÜCKEN
Letztlich haben sich transparente Brücken durchgesetzt, so dass im folgenden nur transparente
Brücken betrachtet werden.
2.7.1
Transparente Brücken (IEEE 802.1D)
LAN-Segmente werden durch sogenannte Ports an eine transparente Brücke angeschlossen. Im einfachsten Fall hat eine Brücke genau zwei Ports — in der Regel haben heutige Brücken jedoch viele
Ports (bis zu mehreren hundert), wobei viele Brückenmodelle durch Erweiterungsmodule relativ
einfach vergrößert werden können (stackable bridges).
Forwarding
database
Port
management
software
MAC
chipset
Port 1
Station
Port
address number
Bridge
protocol
entity
Memory
buffers
MAC
chipset
Port 2
Abbildung 2.8: Interne Struktur von transparenten Brücken
Brücken können auf mehreren Ports gleichzeitig Rahmen empfangen, die dann im Speicher gepuffert werden. Generell arbeiten die Ports von transparenten Brücken im promiscuous Modus, bei dem
all Rahmen gelesen und gepuffert werden (und nicht nur die für die Brücke bestimmten Rahmen).
Intern verwaltet eine transparente Brücke eine Weiterleitungstabelle (forwarding table) von MACAdressen mit zugehörigen Portnummern.
• Wenn ein Rahmen empfangen worden ist, dann wird in der Tabelle nach einem Eintrag für
die Zieladresse gesucht.
• Wird ein passender Eintrag gefunden und die Portnummer unterscheidet sich von der Portnummer über die der Rahmen empfangen wurde, so wird der Rahmen über den im Eintrag
vermerkten Port weitergeleitet. Ist die im Eintrag vermerkte Portnummer identisch mit der
Portnummer über die der Rahmen empfangen wurde, so wird der Rahmen verworfen.
• Wird kein passender Eintrag gefunden, so wird der Rahmen an alle Ports weitergeleitet (flooding), wobei der Port über den der Rahmen empfangen wurde ausgenommen wird.
• Zusätzlich kann man in vielen Brücken spezielle Einträge in der Tabelle konfigurieren, die
eine Weiterleitung von bestimmten Adressen generell unterbinden.
48
KAPITEL 2. LOKALE NETZE NACH IEEE 802
Backward Learning
Die Weiterleitungstabelle (forwarding database) muss natürlich irgendwann erstellt werden und sich
auch dynamisch an Änderungen der Topologie anpassen können. Man löst dieses Problem, indem
eine Brücke die aktuelle Konfiguration aus den ankommenden Paketen lernt und einmal gelerntes
regelmäßig wieder vergessen wird.
• Bei der Initialisierung einer Brücke wird die Weiterleitungstabelle gelöscht.
• Empfängt eine Brücke einen Rahmen, so wird die darin enthaltene Quelladresse und die
Nummer des Ports, über den das Paket empfangen wurde, in der Weiterleitungstabelle abgelegt. Das Paket wird dann an alle anderen Ports weitergeleitet (wodurch auch die anderen
Brücken die Quelladresse kennen lernen).
• Zu jedem Eintrag in der Weiterleitungstabelle gibt es eine Zeitüberwachung. Wird ein Eintrag
für eine gewisse Zeit nicht durch neue empfangene Rahmen bestätigt, so wird der Eintrag
gelöscht (soft state).
• Das Löschen von unbenutzten Einträgen verringert die Größe der Weiterleitungstabelle und
erlaubt es auf Topologieänderungen (mit einer gewissen Verzögerung) dynamisch zu reagieren.
• Das Lernverfahren funktioniert nur dann, wenn die Topologie ein einfacher Baum ist. Existieren mehrere Pfade zwischen LAN-Segmenten, dann werden u.U. Einträge in der Weiterleitungstabelle periodisch wieder überschrieben und das Verhalten des Netzes ist nicht stabil.
Spanning Trees
Für Netze, die keine Baum-Topologie besitzen, kann mit Hilfe des Spanning Tree Protokolls ein
aufspannender Baum konstruiert werden, der dann zur Weiterleitung von Rahmen benutzt werden
kann. Zur Identifikation der Brücken werden die MAC-Adressen der Brücken zusammen mit der
Priorität der jeweiligen Brücke benutzt (bridge identifier, 8 Byte).
Das Verfahren läuft nach folgendem Schema ab:
1. Zunächst wird die Wurzel (root bridge) des aufspannenden Baums ermittelt. Die Wurzel ist
die Brücke mit der höchsten Priorität und der kleinsten Adresse. Die Wurzel wird regelmäßig
neu bestimmt/bestätigt.
2. Im nächsten Schritt werden die Kosten für alle Wege von der Wurzel zu den einzelnen Ports
auf den Brücken ermittelt (root path cost). Jeder Brücke bestimmt dann, über welchen Port
die Wurzel mit den geringsten Kosten erreicht wird (root port).
3. Sobald der root port bekannt ist, wird für jedes Segment ein Port bestimmt, über den der Verkehr in das Segment geleitet wird. Der Port und die zugehörige Brücke werden als designated
port und designated bridge bezeichnet. Die Auswahl basiert wiederum auf den Pfadkosten,
wobei die Bridge Adressen benutzt werden falls mehre Pfade mit denselben Kosten existieren.
4. Schließlich werden alle Ports blockiert, die nicht designated ports sind. Dadurch entsteht eine
aktive Topologie, die dem aufspannenden Baum entspricht.
2.8. VIRTUELLE LANS (IEEE 802.1Q, IEEE 802.1P)
49
2.8 Virtuelle LANs (IEEE 802.1Q, IEEE 802.1P)
Virtuelle LANs (virtual bridged lans, VLANs) emulieren ein virtuelles LAN auf einem komplexen
IEEE 802 Netzwerk, das durch Brücken verbunden ist.
B1
B2
B0
Abbildung 2.9: Virtuelle LANs
Mit VLANs ist es möglich, den Verkehr im IEEE 802 Netz logisch zu trennen, was folgende Vorteile
bietet:
• Eine Station in einem bestimmten VLAN sieht nur die Rahmen, die zu dem entsprechenden
VLAN gehören.
• Durch die VLANs wird die Last reduziert, insbesondere werden Rahmen an alle Stationen
(broadcasts) nur noch an die Stationen in einem gegebenen VLAN zugestellt.
• Stationen können Mitglieder in mehreren VLANs sein, was insbesondere die gemeinsame
Nutzung von Servern erlaubt.
• Durch Zuweisung zu den VLANs können Stationen unabhängig von der physikalischen Topologie in einem logisch getrennten LAN zusammenarbeiten.
Ein VLAN wird durch einen VLAN Identifier (1..4094) eindeutig identifiziert und mit Hilfe von
Brücken realisiert. Die Zuweisung von Ports zu VLANs kann auf verschiedene Arten erfolgen:
• Port-basierte VLANs: Die Ports einer Brücke werden den einzelnen VLANs administrativ
zugeordnet. Ein Port kann in der Regel an mehreren VLANs teilnehmen.
• MAC-Adressen-basierte VLANs: Die MAC-Adressen der Stationen werden den einzelnen
VLANs zugeordnet. Es ist dann egal, über welchen Port eine Station tatsächlich angeschlossen ist.
50
KAPITEL 2. LOKALE NETZE NACH IEEE 802
• Protokoll-basierte VLANs: Die von den Stationen erzeugten Rahmen werden über die nächsthöheren Protokolle den VLANs zugeordnet. Dadurch lassen sich relativ einfach VLANs für
Appletalk, IPX und IP Netze realisieren.
• Multicastgruppen-basierte VLANs: Die VLANs werden durch die Mitglieder einer IP-Multicastgruppe definiert.
7 Byte
start−of−frame delimiter (SFD)
1 Byte
destination MAC address
6 Byte
source MAC address
6 Byte
tag protocol identifier
2 Byte
priority
CFI
preamble
vlan identifier
length / type field
2 Byte
64−1522 Byte
Wenn auf einer Verbindung zwischen zwei Stationen Pakete ausgetauscht werden, die zu unterschiedlichen VLANs gehören, ist eine Kennzeichnung im Rahmen erforderlich (tagging). Dazu
wird im Fall von Ethernet-Rahmen nach den Ziel- und Quelladressen ein sogenanntes Tag (tag
header) eingefügt.
data
(network layer packet)
46−1500 Byte
padding (if required)
frame check sequence (FCS)
4 Byte
Abbildung 2.10: IEEE 802.3 Tagged Rahmenformat
• Rahmen, die von Brücken mit Tags gekennzeichnet werden, können plötzlich die maximale
Rahmenlänge überschreiten.
• Generell müssen Rahmen, die die maximale MAC Länge überschreiten, nach IEEE 802.1Q
vernichtet werden.
• Für den Fall von IEEE 802.3 Rahmen ist eine Verlängerung der Rahmen um vier Bytes erlaubt
(was die max. Rahmenlänge von 1518 Bytes auf 1522 Bytes erhöht).
2.8. VIRTUELLE LANS (IEEE 802.1Q, IEEE 802.1P)
51
• Als Ergänzung zum IEEE 802.1Q Standard für VLANs beschreibt der IEEE 802.1P Standard, wie Prioritäten durch die VLAN-Mitgliedschaft signalisiert werden können, die auch
im Ethernet benutzt werden können. Die Prioritäten werden im 3-bit Prioritätsfeld des Tags
untergebracht.
Der IEEE 802.1Q Standard definiert zusätzlich ein Generic Attribute Registration Protocol (GARP),
mit dem unter anderem Informationen über VLAN Mitgliedschaften der einzelnen Ports propagiert
werden können. Dadurch können VLAN-fähige Endsysteme Verkehr für VLANs unterdrücken, die
derzeit keine Mitglieder haben.
52
KAPITEL 2. LOKALE NETZE NACH IEEE 802
Kapitel 3
Internet Netzwerkschicht
Die Internetprotokolle haben sich auf der Netzwerkschicht im Zusammenhang mit der Datenkommunikation durchgesetzt. Die am weitesten verbreitete Version ist IP Version 4 (IPv4), während IP
Version 6 (IPv6) langsam auch praktisch an Bedeutung gewinnt. In diesem Kapitel werden beide
Protokolle vorgestellt.
3.1 Grundlagen
Zunächst einige Grundlagen, die generell zum Verständnis der Internet-Protokolle notwendig sind.
3.1.1
Entwicklung des Internets
• Die Defense Advanced Research Project Agency (DARPA) der USA startete in der Mitte der
70er Jahre Projekte zur Entwicklung von Internetworking-Technologien.
• Es entsteht das ARPANET, ein auf gemieteten Leitungen realisiertes Datagramm-Netz.
• Das ARPANET wird später zum Backbone-Netzwerk zwischen den großen amerikanischen
Universitäten.
• Anfang der 80er Jahre wird eine Implementierung der Internet-Protokolle als Teil des BSDUNIX-Betriebssystems allgemein verfügbar.
• Das BSD-UNIX definiert die Socket-Programmierschnittstelle, mit der sich relativ einfach
netzwerkfähige Applikationen entwickeln lassen.
• 1983 wird das ARPANET in das Forschungsnetz ARPANET und das militärisch genutzte
MILNET aufgeteilt.
• 1986 wird von der National Science Foundation der USA das NFSNET realisiert, was das
ARPANET ablöst.
• 1990 geht das NSFNET in das ANSNET über, das von MERIT, MCI und IBM betrieben
wird.
• Anfang der 90er Jahre wird am CERN in der Schweiz das World-Wide-Web geboren.
• Weitere Details zur Entwicklung des Internets findet man unter http://www.isoc.org/.
53
54
KAPITEL 3. INTERNET NETZWERKSCHICHT
3.1.2
Internet Prinzipien
Es gibt eine Reihe von Prinzipien, die bei der Entwicklung von Internet-Protokollen angewendet
werden [14]:
• Das erste grundlegende Prinzip ist Konnektivität (connectivity is its own reward). Konnektivität über verschiedene Übertragungstechniken hinweg ist wertvoller als die Dienste einer
bestimmten Anwendung. Erreicht wird Konnektivität durch möglichst wenige Protokolle auf
der Internet-Schicht, die möglichst wenig Anforderungen an die Übertragungstechnologien
stellen.
• Funktionen, die Wissen und Hilfe der Anwendungen erfordern, sollten an den Endpunkten
des Kommunikationsnetzes erbracht werden und nicht im Kommunikationsnetz (end-to-end
argument).
• Es gibt keine zentrale Kontrollinstanzen für das Internet.
• Adressen sollten global eindeutig Endpunkte identifizieren. Dynamische Änderungen der
Wege im Netz sollten jederzeit möglich sein ohne das sich die Identifikation der Endsysteme
ändert.
• Zwischensysteme sollten möglichst zustandslos sein. Wenn Zustandsinformationen notwendig sind, dann sollte der Zustand mit einer Zeitüberwachung versehen und nicht statisch sein
(soft state).
• Zur Sicherung der Interoperabilität sollten Implementationen liberal sein indem was sie akzeptieren und strikt indem was sie generieren. Interoperabilität ist wichtiger als Korrektheit.
3.1.3
Terminologie
Im folgenden wird die aktuelle Terminologie verwendet, wie sie in RFC 2460 [15] definiert wird.
Ältere Bücher und Dokumente verwenden nicht unbedingt diese Terminologie und entsprechend
sind unter Umständen beim Lesen von anderen Materialen mentale Abbildungen“ notwendig.
”
• Ein Node ist ein Gerät, das ein Internetprotokoll (IPv4 oder IPv6) implementiert.
• Ein Router (router) ist ein Node, der Pakete weiterleitet, die nicht an ihn selbst adressiert sind.
• Ein Host ist jeder Node, der nicht ein Router ist.
• Ein Link ist eine Kommunikationskanal, über den Nodes miteinander kommunizieren können
(z.B. Ethernet).
• Die Neighbors sind alle Nodes, die an demselben Link angeschlossen sind.
• Ein Interface ist die Schnittstelle, über die ein Node an einen Link angeschlossen ist.
• Eine IP-Adresse identifiziert ein Interface oder eine Menge von Interfaces.
• Ein IP-Paket ist eine Bitfolge bestehend aus dem IP Protokollkopf (IP header) und den Nutzdaten (payload).
3.1. GRUNDLAGEN
55
• Die Link MTU ist die maximale Paketgröße auf einem Link (link maximum transmission unit,
link MTU).
• Die Path MTU ist die maximale Paketgröße auf einem Pfad zwischen einen Quell-Node und
einem Ziel-Node (path maximum transmission unit, path MTU).
3.1.4
Autonome Systeme
Das globale Internet besteht aus einer Menge von autonomen Systemen, die miteinander verbunden
sind.
• Ein autonomes System wird durch eine Nummer (AS number) identifiziert. Der Nummernbereich ist derzeit noch auf 16 Bit begrenzt.
• Zwischen den autonomen Systemen werden IP-Pakete auf Wegen übertragen, die durch ein
Exterior Gateway Protocol etabliert werden. Die innere Struktur eines autonomen Systems
ist dafür irrelevant.
• Innerhalb eines autonomen Systems werden IP-Pakete auf Wegen übertragen, die durch ein
Interior Gateway Protocol etabliert werden.
• Praktisch bedeutete die Einführung von autonomen Systemen ein zweistufiges Routing im
Internet.
3.1.5
Geltungsbereiche von Internet Adressen
...
--------------------------------------------------------------| a node
|
|
|
|
|
|
|
|
|
|
|
| /--------------------site1--------------------\ /--site2--\ |
|
|
| /--link1--\ /--------link2--------\ /--link3--\ /--link4--\ |
|
|
| /--intf1--\ /--intf2--\ /--intf3--\ /--intf4--\ /--intf5--\ |
--------------------------------------------------------------:
|
|
|
|
:
|
|
|
|
:
|
|
|
|
(imaginary
=================
a pointa
loopback
an Ethernet
to-point
tunnel
link)
link
56
KAPITEL 3. INTERNET NETZWERKSCHICHT
3.2 Internet Protokoll Version 4
Das Internet Protokoll Version 4 (IPv4) wurde 1981 in RFC 791 [16] standardisiert und ist die Basis
des heutigen Internets. Die Spezifikation wurde in vielen Aspekten im Lauf der letzten 20 Jahre den
Erfordernissen angepasst. Die folgende Darstellung beschreibt die aktuelle Interpretation von IPv4.
3.2.1
IPv4 Adressen
Der prinzipielle Aufbau und die Darstellung von IPv4-Adressen wurde bereits im Kapitel 1 erläutert.
• IPv4-Adressen werden für die Wegewahl in einen Teil aufgeteilt, der das Netzwerk identifiziert (netid) und einen Teil, der einen Knoten im Netzwerk identifiziert (hostid).
• Die Anzahl der Bits einer IPv4-Adresse, die das Netzwerk identifiziert, wird als Adresspräfix
bezeichnet. Die heute übliche Darstellung ist als Dezimalzahl, die durch einen Schrägstrich
getrennt an die IPv4-Adresse angefügt wird (z.B. 192.0.2.0/24).
• Ältere Darstellungen benutzen eine sogenannte Netzmaske, die bitweise logisch-und verknüpft mit der Adresse den Netzwerkanteil ergibt (z.B. 192.0.2.0 & 255.255.255.0).
Nicht alle IPv4 Adressen stehen der uneingeschränkten Nutzung zur Verfügung. Einige Adressen
haben besondere Semantik oder sind für spezielle Zwecke reserviert:
Adressbereich
0.0.0.0/8
10.0.0.0/8
14.0.0.0/8
24.0.0.0/8
127.0.0.0/8
169.254.0.0/16
172.16.0.0/12
192.0.2.0/24
192.88.99.0/24
192.168.0.0/16
198.18.0.0/15
224.0.0.0/4
Aktuelle Nutzung
ThisNetwork
Private-Use Networks
Public-Data Networks
Cable Television Networks
Loopback
Link Local
Private-Use Networks
Test-Net / Documentation
6to4 Relay Anycast
Private-Use Networks
Network Interconnect / Device Benchmark Testing
Multicast
Referenz
[RFC1700]
[RFC1918]
[RFC1700]
[RFC1700]
[RFC1918]
[RFC3068]
[RFC1918]
[RFC2544]
[RFC3171]
• Adressen für private Netze, die nicht im globalen Internet benutzt werden, können nach RFC
1918 [17] aus den Bereichen 10.0.0.0/8 und 192.168.0.0/16 gewählt werden.
• Test-Adressen bzw. Adressen, die in Dokumentationen verwendet werden, können aus dem
Bereich 192.0.2.0/24 entnommen werden.
• Die spezielle Adresse 0.0.0.0 identifiziert einen Sender, der noch nicht vollständig konfiguriert ist.
• Die spezielle Adresse 127.0.0.1 identifiziert den lokalen Knoten selbst (loopback).
• Die spezielle Adresse 255.255.255.255 erzeugt einen lokalen Broadcast.
3.2. INTERNET PROTOKOLL VERSION 4
3.2.2
57
IPv4 Paketformat
IPv4-Pakete haben nach RFC 791 [16] folgenden Aufbau:
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL |Type of Service|
Total Length
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Identification
|Flags|
Fragment Offset
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live |
Protocol
|
Header Checksum
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Source Address
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Destination Address
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Options
|
Padding
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
• Das Feld Version enthält die Versionsnummer (4).
• Die Länge des Protokollkopfs ist im Feld Internet Header Length (IHL) vermerkt.
Die Länge wird in der Anzahl von 4 Byte Worten gezählt. Die minimale Länge ist 5 (entspricht 20 Byte), die maximale Länge ist 15 (entspricht 60 Byte).
• Die Interpretation des Type of Service (TOS) Felds hat sich im Lauf der Zeit verändert. Nach der aktuellen Interpretation enthält das TOS-Byte einen Differentiated Services
Code Point (DSCP) sowie Bits zur expliziten Benachrichtigung über Stausituationen (explicit
congestion notification, ECN) [18, 19, 20].
0
1
2
3
4
5
6
7
+-----+-----+-----+-----+-----+-----+-----+-----+
|
DS FIELD, DSCP
| ECN FIELD |
+-----+-----+-----+-----+-----+-----+-----+-----+
• Die Länge des gesamten IP-Pakets (inklusive Protokollkopf) in Bytes ist im Feld Total
Length untergebracht. IPv4-Pakete können entsprechend maximal 65535 Byte lang sein.
• Die Felder Identification, Flags und Fragment Offset unterstützen die Fragmentierung und Reassemblierung von IPv4-Paketen. Das Feld Identification enthält
für alle Fragmente eines IP-Pakets denselben Wert. Das Feld Fragment Offset enthält
die relative Position eines Fragments (gemessen in 64 Bit Worten) des originalen IPv4-Pakets.
Die Flagge More Fragements (MF) ist gesetzt, wenn weitere Fragmente folgen. Mit der
Flagge Don’t Fragment (DF) kann angezeigt werden, das ein IPv4-Paket nicht fragmentiert werden darf. Man beachte, dass Fragmente weiter fragmentiert werden können.
• Das Feld Time to Live (TTL) wird benutzt, um die Lebensdauer eines IPv4-Pakets zu
begrenzen. Praktisch wird das Feld von jedem Router decrementiert und beim Erreichen von
0 wird das Paket vernichtet.
58
KAPITEL 3. INTERNET NETZWERKSCHICHT
• Das Feld Protocol enthält die Identifikation des nächsthöheren Protokolls.
• Die Header Checksum enthält eine Internet-Prüfsumme, gebildet über den Protokollkopf.
• Die Felder Source Address und Destination Address enthalten die Quell- und
Zieladresse.
• Es gibt eine Reihe von Optionen, mit der die Weiterleitung von Paketen beeinflusst oder die
Weiterleitung protokolliert werden kann. Praktisch sind die meisten Optionen von geringer
Bedeutung, da der verfügbare Platz von 40 Byte für Optionen in der Regel zu klein ist.
3.2.3
IPv4 Weiterleitung
Jeder Node hat eine Tabelle, nach der IPv4-Pakete zum Ziel weitergeleitet werden (forwarding
table, forwarding information base) [21].
• Die Weiterleitungstabelle realisiert eine Abbildung des Netzwerkpräfix auf den nächsten Node (next hop) und auf das zu benutzende Interface.
• Weiterleitungstabellen können sehr groß werden.
• Für jedes IP-Paket muss der Eintrag mit dem längsten übereinstimmenden Netzwerkpräfix
ermittelt werden (longest matching network prefix).
• Durch geeignete Darstellungen der Weiterleitungstabellen als Bäume kann die Suchzeit begrenzt werden.
Das folgende Beispiel zeigt an einem einfachen Netz den Aufbau und Inhalt von Weiterleitungstabellen:
R1
Prefix
0.0.0.0/0
134.169.34.0/24
134.169.0.0/16
H1
134.169.2.1
Next Hop
134.169.2.1
134.169.246.34
134.169.9.10
Interface
eth0
eth0
eth0
134.169.9.10
134.169.0.0/16
134.169.246.34
Prefix
0.0.0.0/0
134.169.0.0/16
134.169.34.0/24
Next Hop
134.169.2.1
134.169.246.34
134.169.34.12
Interface
eth0
eth0
eth1
H2
R2
134.169.34.12
Prefix
0.0.0.0/0
134.169.34.0/24
Next Hop
134.169.34.12
134.169.34.1
Interface
eth0
eth0
134.169.34.1
134.169.34.0/24
Abbildung 3.1: Beispiel für IPv4 Weiterleitung
Variationen und Erweiterungen des grundlegenden Modells:
• Jeder Knoten besitzt mehrere Weiterleitungstabellen wobei Informationen aus dem empfangenden IP Paket benutzt werden, um die eigentliche Weiterleitungstabelle auszuwählen (z.B.
TOS).
3.2. INTERNET PROTOKOLL VERSION 4
59
• Die Weiterleitungstabellen werden nicht zentral in einem Router gehalten, sondern in jedem
Interface. Mit diesem Ansatz ist es möglich, das Suchen in der Tabelle zu parallelisieren.
• Eine andere Maßnahme zur Leistungssteigerung ist die Verwaltung von Caches für häufig
genutzte Zieladressen.
• Bei sehr großen Tabellen ist eine Implementierung der Tabelle durch eine Baumstruktur sinnvoll, damit der Aufwand im wesentlichen nur noch von der Verteilung und Länge der Präfixe
abhängt und nicht von der Tabellengröße [22].
3.2.4
IPv4 Fehlerbehandlung (ICMPv4)
Das Internet Control Message Protocol (ICMP) ist in RFC 792 [23] definiert und hat die Aufgabe,
sendende Knoten über aufgetretene Fehler zu unterrichten. Es definiert außerdem Nachrichten, mit
denen einfache Tests realisiert werden können. Die ICMP-Nachrichten werden in der Nutzlast eines
IP Datagramms transportiert.
Im folgenden wird eine Auswahl der ICMP Nachrichtenformate dargestellt. Generell werden ICMPNachrichten durch eine eigene Prüfsumme über die ICMP-Nachricht gegen Fehler gesichert.
Echo Request/Reply
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Type
|
Code
|
Checksum
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Identifier
|
Sequence Number
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Data ...
+-+-+-+-+• Ein Echo-Request (Type = 8, Code = 0) fordert den Zielrechner auf, ein Echo-Reply (Type =
0, Code = 0) zu schicken.
• Die Felder Identifier und Sequence Number werden vom Sender benutzt, um eintreffende Antworten den vorausgegangenen Anfragen zuordnen zu können.
• Im Datenteil können Daten abgelegt werden, die zusätzliche Statusinformationen beinhalten
oder das Paket auf eine bestimmte Größe bringen.
Unreachable Destinations
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Type
|
Code
|
Checksum
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
60
KAPITEL 3. INTERNET NETZWERKSCHICHT
|
unused
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Internet Header + 64 bits of Original Data Datagram
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
• Das Feld Type hat bei allen Nachrichten den Wert 3.
• Das Feld Code bestimmt näher, warum das Ziel nicht erreicht werden kann:
0
Net Unreachable
1
Host Unreachable
2
Protocol Unreachable
3
Port Unreachable
4
Fragmentation Needed and Don’t Fragment was Set
5
Source Route Failed
6
Destination Network Unknown
7
Destination Host Unknown
8
Source Host Isolated
9
Communication with Destination Network is Administratively Prohibited
10 Communication with Destination Host is Administratively Prohibited
11 Destination Network Unreachable for Type of Service
12 Destination Host Unreachable for Type of Service
13 Communication Administratively Prohibited
14 Host Precedence Violation
15 Precedence cutoff in effect
• Der Datenteil enthält den Anfang des verursachenden Pakets.
Redirect
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Type
|
Code
|
Checksum
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Router Internet Address
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Internet Header + 64 bits of Original Data Datagram
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
• Das Feld Type hat bei allen Nachrichten den Wert 5.
• Das Feld Code bestimmt näher, welche Datagramme umgeleitet werden sollen:
0
1
2
3
Redirect datagrams for the Network.
Redirect datagrams for the Host.
Redirect datagrams for the Type of Service and Network.
Redirect datagrams for the Type of Service and Host.
• Das Feld Router Internet Address enthält die Adresse des Routers, zu dem Pakete
umgeleitet werden sollen.
3.2. INTERNET PROTOKOLL VERSION 4
3.2.5
61
MTU Path Discovery
Die Fragmentierung von IPv4-Paketen ist aus verschiedenen Gründen problematisch.
• Der Empfänger muss Fragmente puffern bis alle Fragmente empfangen worden sind. Dies
wird erreicht, indem das TTL-Feld der gepufferten Pakete jede Sekunde decrementiert wird
und Fragmente gelöscht werden, wenn der Wert 0 erreicht wird.
• Beim Verlust eines Fragments wird in den meisten Fällen das Original-Paket irgendwann
vom Sender wiederholt und wieder fragmentiert. Bei verlustreichen Netzen sinkt damit die
Wahrscheinlichkeit einer korrekten Übertragung eines großen Pakets.
• Da das Identification-Feld zusammengehörende Fragmente identifiziert und der Nummernvorrat begrenzt ist, können nicht beliebig viele Datagramme fragmentiert werden.
Eine offensichtliche Lösung ist die Erzeugung von IPv4-Paketen auf der Seite des Senders, die der
Path MTU entsprechen und daher niemals fragmentiert werden müssen [24]. Zum Erlernen der Path
MTU wird folgendes Verfahren benutzt:
• Der Sender sendet IPv4-Pakete mit gesetzter DF-Flagge.
• Ein Router, der das Paket fragmentieren müsste, schickt eine ICMP-Nachricht, in der die
lokal maximal mögliche MTU vermerkt ist.
• Der Sender passt daraufhin die Schätzung für die Path MTU an.
• Da sich die Path MTU dynamisch verändern kann, sollte die einmal gelernte Path MTU
periodisch überprüft und ggf. aktualisiert werden.
• Nicht alle Router schicken notwendigerweise die lokal maximal mögliche MTU. In diesen
Fällen muss der Sender eine typische Liste von MTU-Werten ausprobieren“ (in der Regel
”
effizienter als eine binäre Suche).
3.2.6
IPv4 über IEEE 802.3
IPv4 Datagramme werden als Nutzdaten in IEEE 802.3 Rahmen übertragen [25].
• Die Kennzeichnung von IPv4 Datagrammen erfolgt durch den Wert 0x800 im Ethernet Typfeld.
• Entsprechend der maximalen IEEE 802.3 Rahmengröße ist die Link MTU 1500 Byte.
• Die Abbildung von IPv4 Adressen auf IEEE 802.3 Adressen erfolgt durch Umsetzungstabellen. Einträge in den Umsetzungstabellen können entweder statisch konfiguriert oder dynamisch gelernt werden.
62
KAPITEL 3. INTERNET NETZWERKSCHICHT
3.2.7
Adressumsetzung (ARP, RARP)
Umsetzungstabellen können mit Hilfe der Protokolle ARP [26] und RARP [27] automatisch gelernt
werden. Das grundlegende Prinzip ist dabei, eine Nachricht mit einer Frage nach einer unbekannten
Adresse an alle Rechner eines LANs (Broadcast) zu verschicken. Da so auch der Rechner erreicht
wird, der die gewünschte Information besitzt, kann dieser Rechner die entsprechende Information
an den anfragenden Rechner schicken.
Im Fall von IPv4 und IEEE 802.3 Adressen ergibt sich folgendes Protokollformat:
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Hardware Type
|
Protocol Type
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
HLEN
|
PLEN
|
Operation
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Sender Hardware Address (SHA)
=
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
= Sender Hardware Address (SHA) |
Sender IP Address (SIP)
=
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=
Sender IP Address (SIP)
| Target Hardware Address (THA) =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=
Target Hardware Address (THA)
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Target IP Address
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
• Das ARP-Paketformat ist im Fall von IPv4-Adressen und IEEE 802 MAC-Adressen nicht an
32-Bit Wortgrenzen ausgerichtet und dadurch etwas schwieriger zu lesen.
• Das Feld Hardware Type hat für Ethernet den Wert 1 und kennzeichnet den Adreßtyp auf
dem Link.
• Das Feld Protocol Type hat für IPv4 den Wert 0x800.
• ARP-Pakete haben den Typ 0x806 im Ethernet Rahmen.
• In dem Feld Operation wird der Nachrichtentyp kodiert: ARP Request (1), ARP Response
(2), RARP Request (3), RARP Response (4).
• Der Sender füllt je nach Anfrage nur das Feld Target Hardware Address (RARP)
oder das Feld Target IP Address (ARP) aus.
• Die antwortende Station vertauscht die Sender/Target Felder und füllt das leere Feld aus.
3.2.8
Automatische Konfiguration (DHCP)
Mit dem Dynamic Host Configuration Protocol (DHCP) [28] können Hosts die notwendigen Konfigurationsparameter von einem zentralen Server beziehen.
3.2. INTERNET PROTOKOLL VERSION 4
63
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
op (1)
|
htype (1)
|
hlen (1)
|
hops (1)
|
+---------------+---------------+---------------+---------------+
|
xid (4)
|
+-------------------------------+-------------------------------+
|
secs (2)
|
flags (2)
|
+-------------------------------+-------------------------------+
|
ciaddr (4)
|
+---------------------------------------------------------------+
|
yiaddr (4)
|
+---------------------------------------------------------------+
|
siaddr (4)
|
+---------------------------------------------------------------+
|
giaddr (4)
|
+---------------------------------------------------------------+
|
|
|
chaddr (16)
|
|
|
|
|
+---------------------------------------------------------------+
|
|
|
sname
(64)
|
+---------------------------------------------------------------+
|
|
|
file
(128)
|
+---------------------------------------------------------------+
|
|
|
options (variable)
|
+---------------------------------------------------------------+
Nachrichtentypen:
• DHCPDISCOVER: Ein Broadcast, mit dem ein DHCP-Client verfügbare DHCP-Server lokalisiert.
• DHCPOFFER: Nachricht von einem DHCP-Server an einen DHCP-Client mit dem Angebot
von Konfigurationsparametern.
• DHCPREQUEST: Nachricht von einem DHCP-Client an die DHCP-Server mit der ein Angebot ausgewählt oder bestätigt wird.
• DHCPACK: Positive Bestätigung mit weiteren Parametern vom DHCP-Server an den DHCPClient.
• DHCPNAK: Negative Bestätigung vom DHCP-Server an den DHCP-Client.
• DHCPDECLINE: Nachricht vom DHCP-Client an den DHCP-Server, das Parameter nicht
verwendet werden können.
64
KAPITEL 3. INTERNET NETZWERKSCHICHT
• DHCPRELEASE: Nachricht vom DHCP-Client an den DHCP-Server, das ausgegebene Konfigurationsparameter nicht mehr benötigt werden.
• DHCPINFORM: Nachricht vom DHCP-Client an den DHCP-Server, das nur lokale Konfigurationsparameter benötigt werden.
Server
(not selected)
Client
Server
(selected)
v
v
v
|
|
|
|
Begins initialization
|
|
|
|
| _____________/|\____________ |
|/DHCPDISCOVER | DHCPDISCOVER \|
|
|
|
Determines
|
Determines
configuration
|
configuration
|
|
|
|\
| ____________/ |
| \________
| /DHCPOFFER
|
| DHCPOFFER\
|/
|
|
\ |
|
|
Collects replies
|
|
\|
|
|
Selects configuration
|
|
|
|
| _____________/|\____________ |
|/ DHCPREQUEST | DHCPREQUEST\ |
|
|
|
|
|
Commits configuration
|
|
|
|
| _____________/|
|
|/ DHCPACK
|
|
|
|
|
Initialization complete
|
|
|
|
.
.
.
.
.
.
|
|
|
|
Graceful shutdown
|
|
|
|
|
|\ ____________ |
|
| DHCPRELEASE \|
|
|
|
|
|
Discards lease
|
|
|
v
v
v
3.3. INTERNET PROTOKOLL VERSION 6
65
3.3 Internet Protokoll Version 6
Das Internet Protokoll Version 6 (IPv6) [15] wurde ab 1994 entwickelt. IPv6 ist seit 1998 ein Draft Standard
und auf fast allen wichtigen Plattformen verfügbar. Die wesentlichen Ziele bei der Entwicklung von IPv6
waren:
• Vergrößerung des Adressraums von 32 Bit auf 128 Bit.
• Vereinfachung der Protokollköpfe um im Normalfallbessere Effizienz zu erreichen.
• Bessere Unterstützung von Protokollerweiterungen und Optionen.
• Unterstützung für die Markierung von Verkehrsflüssen (flows).
• Authentifizierung und Verschlüsselung von Datagrammen.
• Verbesserte automatische Konfiguration von Endsystemen.
3.3.1
IPv6 Adressen
...
3.3.2
IPv6 Paketformat
IPv6-Pakete haben nach RFC 2460 [15] folgenden Aufbau:
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Traffic Class |
Flow Label
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Payload Length
| Next Header |
Hop Limit
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
+
+
|
|
+
Source Address
+
|
|
+
+
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
+
+
|
|
+
Destination Address
+
|
|
+
+
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
• Das Feld Version enthält die Versionsnummer (6).
• Das Feld Traffic Class enthält nach der aktuellen Interpretation einen Differentiated Services
Code Point (DSCP) sowie Bits zur expliziten Benachrichtigung über Stausituationen (explicit congestion notification, ECN) [18, 19, 20].
66
KAPITEL 3. INTERNET NETZWERKSCHICHT
0
1
2
3
4
5
6
7
+-----+-----+-----+-----+-----+-----+-----+-----+
|
DS FIELD, DSCP
| ECN FIELD |
+-----+-----+-----+-----+-----+-----+-----+-----+
• In dem Feld Flow Label können Pakete von einer Quelle zu einer Senke markiert werden, die zu
demselben Verkehrsfluß (traffic flow) gehören und besonders behandelt werden sollen.
• Die Länge der Nutzlast hinter dem IPv6 Protokollkopf. Man beachte das dies von dem Feld Total
Length im IPv4 Protokollkopf verschieden ist.
• Das Feld Next Header identifiziert den Typ der in der Nutzlast enthaltenen Nachricht. Entspricht
dem IPv4 Protocol Feld.
• Das Feld Hop Limit wird benutzt, um die Lebensdauer von IPv6-Paketen zu begrenzen. Jeder Router decrementiert dieses Feld und beim Erreichen von 0 wird das Paket vernichtet.
• Die Felder Source Address und Destination Address enthalten die 128 Bit Quell- und
Zieladresse.
3.3.3
IPv6 Erweiterungen
Das IPv6 Paketformat ist gemessen am IPv4 Paketformat wesentlich einfacher. Erreicht wird dies durch die
Verlagerung von Funktionen in sogenannte Erweiterungsprotokollköpfe, die zwischen dem IPv6 Protokollkopf und der eigentlichen Nutzlast enthalten sein können.
Unbekannte Erweiterungsprotokollköpfe können nicht von einer Implementation ignoriert werden sondern
führen zum Verwerfen des Datagramms. Zusätzliche Parameter, die von Implementationen ignoriert werden können, werden als Optionen bezeichnet und in speziellen Erweiterungsprotokollköpfen für Optionen
übertragen.
Routing Extension Header
Der Routing Extension Header (RH) Erweiterungsprotokollkopf erlaubt es, den Weg eines Datagramms vorzubestimmen [15]. Der RH-Erweiterungsprotokollkopf hat folgendes Format:
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | Routing Type | Segments Left |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
.
.
.
Type-Specific Data
.
.
.
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
• Das Feld Next Header identifiziert den Typ der in der Nutzlast hinter dem RH-Erweiterungsprotokollkopf enthaltenen Nachricht.
• Das Feld Hdr Ext Len spezifiziert die Länge des RH gemessen in der Anzahl von 64 Bit Worten
minus 1.
• Das Feld Routing Type identifiziert eine bestimmte Variante des RH und die Bedeutung des Felds
Type-Specific Data.
3.3. INTERNET PROTOKOLL VERSION 6
67
• Das Feld Segments Left identifiziert die Anzahl der verbleibender Routing-Segmente.
• Derzeit ist nur eine Variante definiert (Routing Type 0) bei der die ersten 32 Bit des Felds
Type-Specific Data unbenutzt sind und die folgenden 128 Bit Felder jeweils eine IPv6 Adresse
enthalten. Kommt ein IPv6 Paket an der Zieladresse an und ist ein RH mit verbleibenden Segmenten
vorhanden, dann wird die nächste verbleibende Zieladresse in die Zieladresse kopiert, die Anzahl der
verbleibenden Segmente decrementiert und das Paket an die neue Zieladresse weitergeleitet.
Fragment Extension Header
IPv6 setzt voraus, daß jeder Link eine MTU von mindestens 1280 Byte besitzt [15]. Entsprechend müssen
Links, die eine kleinere MTU besitzen, Fragmentierung und Reassemblierung unterhalb von IPv6 realisieren.
Einfache Implementationen, die kein MTU Path Discovery unterstützen, müssen sich auf Pakete mit einer
maximalen Länge von 1280 Byte beschränken. Pakete, die größer sind als die Path MTU, können mit Hilfe
des Fragment Extension Header (FH) Erweiterungsprotokollkopfs fragmentiert und versendet werden. Der
FH-Erweiterungsprotokollkopf hat folgendes Format:
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header |
Reserved
|
Fragment Offset
|Res|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Identification
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
• Fragmentierung erfolgt ausschließlich beim Erzeuger eines IPv6 Datagramms und niemals innerhalb
eines Routers.
• Das Feld Next Header identifiziert den Typ der in der Nutzlast hinter dem FH-Erweiterungsprotokollkopf enthaltenen Nachricht.
• Das Feld Fragment Offset definiert die relative Position eines Fragments (gemessen in 64 Bit
Worten) des original IPv6-Pakets.
• Die Flagge M ist gesetzt, wenn weitere Fragmente folgen. Die Bits Res sind nicht benutzt.
• Das Feld Identification enthält für alle Fragmente eines IPv6-Pakets denselben Wert.
Authentication Extension Header
Der Authentication Header (AH) Erweiterungsprotokollkopf realisiert für IPv6 Pakete die grundlegenden Sicherheitsdienste Authentifikation und Datenintegrität [29]. Der AH-Erweiterungsprotokollkopf hat folgendes
Format:
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header
| Payload Len |
RESERVED
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Security Parameters Index (SPI)
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Sequence Number
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
+
Authentication Data (variable)
|
68
KAPITEL 3. INTERNET NETZWERKSCHICHT
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
• Das Feld Next Header identifiziert den Typ der in der Nutzlast hinter dem AH-Erweiterungsprotokollkopf enthaltenen Nachricht.
• Das Feld Payload Len spezifiziert die Länge des AH-Erweiterungsprotokollkopfs gemessen in der
Anzahl von 32 Bit Worten minus 2.
• Das Feld Security Parameters Index enthält einen Wert, der zusammen mit der Zieladresse
eindeutig eine Security Association (SA) identifiziert.
• Das Feld Sequence Number enthält eine streng monoton wachsende Sequenznummer. Das erste
Paket, das nach der Einrichtung einer SA gesendet wird, hat den Sequenznummernwert 1. Erreicht die
Sequenznummer den Wert 232 , so muss in der Regel eine neue SA eingerichtet werden.
• Das Feld Authentication Data enthält eine Integritätsprüfsumme (integrity check value, ICV).
Die Länge dieses Felds hängt von der verwendeten Authentifizierungsfunktion ab.
Encapsulating Security Payload Extension Header
Der Encapsulating Security Payload (ESP) Erweiterungsprotokollkopf realisiert Sicherheitsdienste wie Vertraulichkeit, Authentifikation, Datenintegrität, Schutz vor Wiederholungen und eingeschränkte Sicherung gegen Verkehrsflußanalysen [30]. Der ESP-Erweiterungsprotokollkopf hat folgendes Format:
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Security Parameters Index (SPI)
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Sequence Number
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Payload Data* (variable)
|
˜
˜
|
|
+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
Padding (0-255 bytes)
|
+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
| Pad Length
| Next Header
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Authentication Data (variable)
|
˜
˜
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
---ˆAuth.
|Cov|erage
| ---|
ˆ
|
|
|Conf.
|Cov|erage*
|
|
v
v
------
• Das Feld Security Parameters Index enthält einen Wert, der zusammen mit der Zieladresse
eindeutig eine Security Association (SA) identifiziert.
• Das Feld Sequence Number enthält eine streng monoton wachsende Sequenznummer. Das erste
Paket, das nach der Einrichtung einer SA gesendet wird, hat den Sequenznummernwert 1. Erreicht die
Sequenznummer den Wert 232 , so muss in der Regel eine neue SA eingerichtet werden.
• Die verschlüsselte Nutzlast (inklusive etwaiger Initialisierungsvektoren) ist im Feld Payload Data
untergebracht.
3.3. INTERNET PROTOKOLL VERSION 6
69
• Das Feld Padding kann benutzt werden, um durch Füllbytes eine Ausrichtung der verschlüsselten
Daten zu erreichen oder um eine passende Eingabelänge für ein gegebenes Verschlüsselungsverfahren
bereitzustellen. Durch das Anfügen von Füllbytes kann auch die ursprüngliche Länge der Nutzlast
verschleiert werden.
• Das Feld Pad Length enthält die Anzahl der Füllbytes.
• Das Feld Next Header identifiziert den Typ der in der Nutzlast enthaltenen Nachricht.
• Das Feld Authentication Data enthält eine Integritätsprüfsumme (integrity check value, ICV).
Die Länge dieses Felds hängt von der verwendeten Authentifizierungsfunktion ab.
• Eine Fragmentierung kann nur nach einer Verschlüsselung erfolgen, d.h. ESP wird nie auf ein Fragment angewendet.
Hop-by-Hop Options Extension Header
Der Hop-by-Hop Options Extension Header (HO) Erweiterungsprotokollkopf enthält eine Liste von Optionen, die von jedem Node auf dem Weg untersucht werden müssen [15]. Der HO-Erweiterungsprotokollkopf
hat folgendes Format:
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len |
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
|
|
.
.
.
Options
.
.
.
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
• Das Feld Next Header identifiziert den Typ der in der Nutzlast hinter dem HO-Erweiterungsprotokollkopf enthaltenen Nachricht.
• Das Feld Hdr Ext Len spezifiziert die Länge des HO gemessen in der Anzahl von 64 Bit Worten
minus 1.
• Das Feld Options enthält die einzelnen Optionen, die jeweils als Typ-Länge-Wert Tripel (tag-lengthvalue, TLV) kodiert sind:
0
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - | Option Type | Opt Data Len | Option Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - Das Feld Option Type definiert den Typ der Option und das Feld Option Data Len die Länge
der Daten gemessen in Bytes. Generell werden Optionen in der Reihenfolge des Auftretens im Paket
verarbeitet.
70
KAPITEL 3. INTERNET NETZWERKSCHICHT
Destination Options Extension Header
Der Destination Options Extension Header (DO) Erweiterungsprotokollkopf enthält eine Liste von Optionen, die nur von den Zielknoten untersucht werden müssen [15]. Der DO-Erweiterungsprotokollkopf hat
folgendes Format:
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len |
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
|
|
.
.
.
Options
.
.
.
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
• Die Felder Next Header, Hdr Ext Len und Options sind analog zum HO-Erweiterungsprotollkopf
definiert.
3.3.4
IPv6 Weiterleitung
Die Weiterleitung von IPv6-Paketen erfolgt prinzipiell analog zu der Weiterleitung von IPv4-Paketen. Lediglich die Länge der Adressen und Präfixe hat sich verändert, was effiziente Implementationen der Weiterleitungstabellen erfordert.
3.3.5
IPv6 Fehlerbehandlung (ICMPv6)
Die IPv6-Fehlerbehandlung erfolgt durch das Internet Control Message Protocol Version 6 (ICMPv6). ICMPv6Nachrichten haben nach RFC 2463 [31] folgendes grundlegendes Format:
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Type
|
Code
|
Checksum
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
+
Message Body
+
|
|
• Das Feld Type identifiziert den Typ einer ICMPv6-Nachricht. ICMPv6-Nachrichten können in Fehlermeldungen (Typ 0-127) und Informationsnachrichten (Typ 128-255) eingeteilt werden.
1
Destination Unreachable RFC 2463
2
Packet Too Big
RFC 2463
3
Time Exceeded
RFC 2463
4
Parameter Problem
RFC 2463
128 Echo Request
RFC 2463
129 Echo Reply
RFC 2463
133 Router Solicitation
RFC 2461
134 Router Advertisement
RFC 2461
135 Neighbor Solicitation
RFC 2461
136 Neighbor Advertisement RFC 2461
137 Redirect
RFC 2461
3.3. INTERNET PROTOKOLL VERSION 6
71
• Das Feld Code kann den Nachrichtentyp weiter klassifizieren. Die Bedeutung des Felds Code ist
abhängig vom Feld Type.
• Das Feld Checksum enthält eine Internet-Prüfsumme gebildet über die ICMPv6-Nachricht und Teile
des IPv6-Protokollkopfs.
• Der Inhalt des Felds Message Body ist abhängig vom ICMPv6-Nachrichtentyp.
3.3.6
IPv6 über IEEE 802.3
IPv6 Datagramme werden als Nutzdaten in IEEE 802.3 Rahmen übertragen [32]:
• Die Kennzeichnung von IPv6 Datagrammen erfolgt durch den Wert 0x86dd im Ethernet Typfeld.
• Entsprechend der maximalen IEEE 802.3 Rahmengröße ist die Link MTU 1500 Byte.
• Die Abbildung von IPv6 Adressen auf IEEE 802.3 Adressen erfolgt durch Umsetzungstabellen. Einträge in den Umsetzungstabellen können entweder statisch konfiguriert oder dynamisch gelernt werden.
3.3.7
IPv6 Neighbor Discovery
IPv6 unterstützt die automatische grundlegende Konfiguration von Hosts durch ein Neighbor Discovery
(ND), das auch die Funktionalität der Addressauflösung bereitstellt [33]:
• Erkennung von lokalen Routern, die am Link angeschlossen sind (router discovery).
• Erkennung der Präfixe, mit denen entschieden werden kann, welche Ziele lokal erreicht werden können
(prefix discovery).
• Erkennung von Parametern wie der MTU des Links oder des Hop Limits für ausgehende Pakete (parameter discovery).
• Automatische Konfiguration von IPv6-Adressen (address autoconfiguration).
• Auflösung von IPv6-Adressen zu Adressen auf dem Link-Layer (address resolution).
• Abbildung von IPv6-Zieladressen auf die Adresse des nächsten Nodes (next-hop determination).
• Erkennung von nicht mehr erreichbaren Nodes, die am Link angeschlossen sind (neighbor unreachability detection).
• Erkennung von Konflikten bei der Generierung von Adressen (duplicate address detection).
• Erlernen von besseren Alternativen für die Weiterleitung (redirect).
Neighbor Discovery verwendet spezielle IPv6-Adressen:
• all-nodes: Die Multicastadresse FF02::1 mit link-lokalem Scope, über die alle Nodes eines Links
erreicht werden können.
• all-routers: Die Multicastadresse FF02::2 mit link-lokalem Scope, über die alle Router eines Links
erreicht werden können.
• solicited-node: Eine Multicastadresse mit link-lokalem Scope, die sich aus der Zieladresse eines Nodes ableitet: Die ersten 96 Bit sind FF02:0:0:0:0:1, und die restlichen 32 Bit ergeben sich aus den
letzten 32 Bit einer IPv6-Addresse.
• link-local: Eine Unicastadresse mit link-lokalem Scope, die sich in der Regel aus der IEEE 802 MAC
Adresse ableitet.
72
KAPITEL 3. INTERNET NETZWERKSCHICHT
Das ND-Protokoll ist als Teil des ICMPv6-Protokolls realisiert und definiert fünf neue Nachrichtenformate. Um potentielle Angriffe durch falsche Neighbor Discovery Nachrichten einzuschränken wird das Hop
Limit der IPv6 Protokollköpfe auf den Wert 255 gesetzt. Empfänger einer Neighbor Discovery Nachricht
müssen Nachrichten verwerfen, deren Hop Limit nicht den Wert 255 enthält. Dies kann nur bei Nachrichten der Fall sein, die durch einen Router weitergeleitet worden sind, was einen potentiellen Angriff von
außerhalb des Links bedeutet.
Router Solicitation
Hosts können durch Router durch Solicitation Nachrichten Router auffordern, ein Router Advertisement zu
generieren.
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Type
|
Code
|
Checksum
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Reserved
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Options ...
+-+-+-+-+-+-+-+-+-+-+-+• Das Feld Type hat den Wert 133 und das Feld Code den Wert 0.
• Das Feld Checksum enthält die normale ICMPv6-Prüfsumme.
• Die Nachricht wird an die all-routers Multicastgruppe geschickt.
• Wenn die Quelladresse bekannt ist, dann kann in den Optionen die entsprechende Adresse auf dem
Link-Layer mitgeschickt werden.
Router Advertisement
Router senden periodisch oder als Reaktion auf eine Router Solicitation Nachricht eine Router Advertisement
Nachricht.
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Type
|
Code
|
Checksum
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cur Hop Limit |M|O| Reserved |
Router Lifetime
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Reachable Time
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Retrans Timer
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Options ...
+-+-+-+-+-+-+-+-+-+-+-+• Das Feld Type hat den Wert 134 und das Feld Code den Wert 0.
• Das Feld Checksum enthält die normale ICMPv6-Prüfsumme.
• Die Nachricht wird an die all-nodes Multicastgruppe geschickt.
3.3. INTERNET PROTOKOLL VERSION 6
73
• Das Feld Cur Hop Limit enthält einen vorgeschlagenen Wert, der von Hosts im Hop Limit
Feld von ausgehenden IPv6-Paketen eingesetzt werden soll.
• Mit der Flagge M kann angezeigt werden, dass Hosts zusätzlich einen anderen Mechanismus (DHCPv6) zur Autokonfiguration von Adressen benutzen sollen (managed address configuration).
• Mit der Flagge O kann angezeigt werden, dass Hosts einen anderen Mechanismus (DHCPv6) zur
Autokonfiguration der übrigen Parameter benutzen sollen (other stateful configuration).
• Das Feld Router Lifetime definiert den Zeitraum in Sekunden, indem der Router als DefaultRouter benutzt werden darf.
• Das Feld Reachable Time definiert die Zeit in Millisekunden, während der ein Node erreichbar
sein wird, nachdem der Node seine Link-Layer Adresse bekannt gegeben hat.
• Das Feld Retrans Timer definiert den Abstand in Millisekunden zwischen aufeinanderfolgenden
Neighbor Solicitation Nachrichten, die nicht durch Neighbor Advertisements beantwortet werden.
• In den Optionen können weitere Parameter enthalten sein, wie z.B. die Link-Layer Adresse des sendenden Routers, die MTU des Links oder Informationen über die auf dem Link gültigen Präfix.
Neighbor Solicitation
Hosts können durch Neighbor Solicitation Nachrichten andere Hosts auffordern, ein Neighbor Advertisement
zu generieren.
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Type
|
Code
|
Checksum
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Reserved
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
+
+
|
|
+
Target Address
+
|
|
+
+
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Options ...
+-+-+-+-+-+-+-+-+-+-+-+• Das Feld Type hat den Wert 135 und das Feld Code den Wert 0.
• Das Feld Checksum enthält die normale ICMPv6-Prüfsumme.
• Die Nachricht wird an die solicited-node Multicastgruppe geschickt.
• Das Feld Target Address enthält die Zieladresse, über die Informationen benötigt werden.
• Wenn die Quelladresse bekannt ist, dann kann in den Optionen die entsprechende Adresse auf dem
Link-Layer mitgeschickt werden.
74
KAPITEL 3. INTERNET NETZWERKSCHICHT
Neighbor Advertisement
Hosts senden als Reaktion auf eine Neighbor Solicitation Nachricht eine Neighbor Advertisement Nachricht.
Neighbor Advertisement Nachrichten können auch unaufgefordert generiert werden, um Änderungen schnell
zu propagieren.
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Type
|
Code
|
Checksum
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|S|O|
Reserved
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
+
+
|
|
+
Target Address
+
|
|
+
+
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Options ...
+-+-+-+-+-+-+-+-+-+-+-+• Das Feld Type hat den Wert 136 und das Feld Code den Wert 0.
• Das Feld Checksum enthält die normale ICMPv6-Prüfsumme.
• Die Nachricht wird an die in der Anfrage enthaltene IPv6-Adresse geschickt oder an die all-nodes
Multicastgruppe.
• Die Flagge R zeigt an, dass der Sender ein Router ist. Die Flagge S signalisiert, dass die Nachricht
eine Reaktion auf eine vorherige Anfrage ist und die Flagge O zeigt an, dass die enthaltene Information
eventuell vorhandene Cache-Einträge überschreiben soll.
• In den Optionen wird die Adresse des Senders auf dem Link-Layer mitgeteilt.
Redirect
Router können Redirect Nachrichten verschicken, um Hosts über bessere Pfade zu unterrichten.
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Type
|
Code
|
Checksum
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Reserved
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
+
+
|
|
+
Target Address
+
|
|
+
+
|
|
3.3. INTERNET PROTOKOLL VERSION 6
75
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
+
+
|
|
+
Destination Address
+
|
|
+
+
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Options ...
+-+-+-+-+-+-+-+-+-+-+-+• Das Feld Type hat den Wert 137 und das Feld Code den Wert 0.
• Das Feld Checksum enthält die normale ICMPv6-Prüfsumme.
• Das Feld Target Address enthält die IPv6-Adresse, über die ein besserer Weg zur Zieladresse
Destination Address erreicht wird.
• Das Feld Destination Address enthält die IPv6 Adresse, für die die Target Address ein
besserer Weg ist.
• In den Optionen kann die Link-Layer Adresse der Target Address mitgeteilt werden, sofern
sie bekannt ist. Außerdem sollte in den Optionen soviel wie möglich vom IPv6-Paket untergebracht
werden, das die Redirect Nachricht ausgelöst hat.
76
KAPITEL 3. INTERNET NETZWERKSCHICHT
3.4 Wegwahlverfahren
Die Weiterleitung von Paketen geschieht im Internet durch Weiterleitungstabellen. Diese Tabellen bestimmen
die Wege der Datagramme durch das Internet und müssen ständig angepasst werden. Da dies manuell nicht
machbar ist, wurden spezielle Wegwahlverfahren (routing protocols) entwickelt.
• Grundlegend für die Wegwahl ist die Einteilung des Internets in autonome Systeme (autonomous
systems, AS). Ein AS ist eine Menge von Netzen, die von einer Organisation verwaltet und betrieben
werden.
• Die Wegwahlverfahren innerhalb eines AS sind unabhängig von den Wegwahlverfahren in anderen
AS. Man bezeichnet ein Wegwahlverfahren in einem AS auch als Interior Gateway Protocol (IGP).
Weit verbreitete IGPs sind das Routing Information Protocol (RIP) und das Open Shortest Path First
(OSPF) Protokoll.
• Die Wegwahlverfahren zwischen mehreren AS bezeichnet man auch als Exterior Gateway Protocol
(EGP). Ein weit verbreitetes EGP ist das Border Gateway Protocol (BGP).
3.4.1
Routing Information Protocol (RIP)
Das Routing Information Protocol Version 2 (RIP-2) [34] ist ein einfaches Wegwahlverfahren innerhalb autonomer Systeme und basiert auf dem Austausch von Distanzvektoren (distance vector routing). Die Grundlage
ist der Bellman-Ford Algorithmus zur Ermittlung kürzester Wege in einem Graphen.
Bellman-Ford Algorithmus zur Ermittlung der kürzesten Wege
• Sei G = (V, E) ein Graph mit den Kanten V , den Knoten E und m = |V | und n = |E|.
• Sei D eine N × N Distanzmatrix in der D(i, j) die Distanz vom Knoten i zum Knoten j beschreibt.
• Sei H eine N × N Matrix in der H(i, j) die Kante bestimmt, auf der ein Knoten i eine Nachricht in
Richtung des Knoten j weiterleitet.
• Sei M ein Vektor mit den Link Metriken, S ein Vektor mit den Startknoten der Links und D ein Vektor
mit den Endknoten der Links.
1. Setze D(i, j) = ∞ für i 6= j und D(i, j) = 0 für i = j.
2. Für alle Kanten l und für alle Knoten k berechne: Sei i = S[l] und j = D[l] und berechne d =
M [l] + D(j, k).
3. Falls d < D(i, k), setze D(i, k) = d und H(i, k) = l.
4. Falls mindestens ein D(i, k) verändert wurde, wiederhole ab Schritt 2. Anderenfalls ist die Berechnung beendet.
Eigenschaften
• In einfachen Distanzvektorprotokollen wie RIP breiten sich gute Nachrichten in der Regel schnell aus,
während schlechte Nachrichten sich relativ langsam verbreiten.
• Speziell bei Ausfällen von Links ist zu beobachten, dass sich die schlechte Nachricht durch ein langsames Hochzählen der Kosten verbreitet (count to infinity).
• Beim RIP ist infinity als 16 Hops definiert. Entsprechend kann RIP auch nur in Netzen verwendet
werden, deren längsten Wege (network diameter) kleiner als 16 Hops sind.
• RIP ist beschränkt sich auf die Anzahl der Hops als einzige Metrik.
3.4. WEGWAHLVERFAHREN
77
Protokoll
RIP-2 wird über das User Datagram Protocol (UDP) abgewickelt und benutzt normalerweise die Portnummer
520. Alle RIP-2 Nachrichten haben folgenden Aufbau:
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Command
|
Version
|
must be zero
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
˜
RIP Entries
˜
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
• Das Feld Command zeigt an, ob es sich um eine Anfrage (request) oder eine Antwort (response)
handelt. Antworten können auch unaufgefordert geschickt werden (unsolicited response).
• Das Feld Version enthält die Versionsnummer.
• Nach den ersten 32 Bit folgt eine Liste von sogenannten RIP Entries, die jeweils 20 Byte lang
sind.
Ein RIP-2 RIP Entry hat folgende Struktur:
0
1
2
3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Address Family Identifier
|
Route Tag
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
IP Address
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Subnet Mask
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Next Hop
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Metric
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
• Das Feld Address Family Identifier identifiziert eine Adreßfamilie. Ursprünglich wurde
RIP für Netzwerke mit verschiedenen Adreßformaten entwickelt.
• Das Feld Route Tag markiert RIP Entries, die externe Routen enthalten, die beispielsweise von
einem EGP etabliert wurden.
• Das Feld IP Address enthält eine IPv4-Zieladresse.
• Das Feld Subnet Mask identifiziert zur Zieladresse den Netzwerk-Präfix.
• Das Feld Next Hop enthält die IPv4-Adresse des Routers, über den Pakete weitergeleitet werden
sollen. Enthält das Feld den speziellen Wert 0.0.0.0, so wird Quelladresse der RIP-Nachricht benutzt.
• Das Feld Metric enthält einen Wert zwischen 1 und 15 inklusive. Der Wert 16 wird benutzt, wenn
ein Ziel nicht erreichbar ist (infinity).
Zur Authentifikation kann der erste RIP Entry folgendes Format besitzen:
78
KAPITEL 3. INTERNET NETZWERKSCHICHT
0
1
2
3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
0xFFFF
|
Authentication Type
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
+
+
|
|
+
Authentication
+
|
|
+
+
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
• Die Konstante 0xFFFF unterscheidet einen Authentifizierungseintrag von anderen RIP Entries.
• Das Feld Authentication Type identifiziert ein Authentifizierungsverfahren.
• Das Feld Authentication enthält Daten, die vom Empfänger zur Authentifikation der Nachricht
benutzt werden.
• Neben dem trivialen Authentifizierungsverfahren durch Klartext-Passworte ist ein Verfahren auf der
Basis von MD5 definiert [35], wobei ein zusätzlicher Trailer am Ende einer RIP-2 Nachricht eingeführt
wird.
3.4.2
Open Shortest Path First (OSPF)
Das Open Shortest Path First (OSPF) Protokoll [36] ist ein Wegwahlverfahren innerhalb autonomer Systeme
und basiert auf der Idee, dass allen Knoten der Zustand der Kanten (link state) bekannt ist. Jeder Knoten berechnet dann aufgrund dieser Datenbasis (link state database) die jeweils kürzesten Wege unter Verwendung
des Dijkstra Algorithmus (link state routing). Die Aktualisierung der Datenbasis erfolgt durch das Fluten von
Nachrichten.
Dijkstra Algorithmus zur Ermittlung der kürzesten Wege
1. Alle Knoten werden mit den Kosten unendlich beschriftet und als vorläufig“ markiert.
”
2. Der Startknoten bekommt die Kosten 0 zugewiesen und wird zum aktuellen Knoten.
3. Der aktuelle Knoten wird als permanent“ markiert.
”
4. Vom aktuellen Knoten aus werden alle direkten Nachfolger betrachtet. Ist die Summer der Kosten für
den aktuellen Knoten und der Kosten zum Erreichen des Nachfolgers kleiner als die bisher bekannten
Kosten des Nachfolgers, so werden die Kosten des Nachfolgers aktualisiert und der aktuelle Knoten
vermerkt.
5. Sind noch vorläufige“ Knoten vorhanden, so wird einer mit minimalen Kosten ausgewählt und zum
”
neuen aktuellen Knoten.
6. Wiederhole ab Schritt 3 falls ein neuer Knoten ausgewählt werden konnte.
OSPF Areas
• Eine OSPF Area gruppiert eine Menge von Netzen eines Autonomen Systems.
• Die Topologie einer OSPF Area ist für andere OSPF Areas unsichtbar. Entsprechend ist das Routing
innerhalb einer Area (intra-area routing) beschränkt auf diese Area.
3.4. WEGWAHLVERFAHREN
79
• Die einzelnen OSPF Areas werden über den OSPF Backbone (OSPF Area 0) miteinander verbunden.
Das Routing zwischen Areas (inter-area routing) erfolgt in drei Teilabschnitten:
1. Ein intra-area Pfad von der Quelle zu einem Area Border Router.
2. Ein Pfad in der Backbone Area vom Area Border Router der Quell-Area zu einem Area Border
Router der Ziel-Area.
3. Ein intra-area Pfad vom Area Border Router zum Ziel.
• Entsprechend der Einteilung in Areas unterscheidet man zwischen verschiedenen Routern:
1. Internal Router: Ein Router, dessen Interfaces alle zu derselben OSPF Area gehören.
2. Area Border Router: Ein Router, der mehrere OSPF Areas miteinander verbindet. Diese Router
müssen für jede OSPF Area eine eigene Kopie des grundlegenden OSPF-Algorithmus ausführen.
3. Backbone Router: Ein Router mit einem Interface zu der Backbone Area. Jeder Area Border
Router ist automatisch ein Backbone Router.
4. AS Boundary Router: Ein Router, der Informationen mit Routern austauscht, die zu anderen
autonomen Systemen gehören.
• In sogenannten Stub Areas mit einem einzigen Area Border Router kann das Routing durch default
Routen vereinfacht und der Aufwand reduziert werden.
Protokoll
OSPF-Nachrichten werden direkt in IP Datagrammen transportiert. Der Wert im Feld Protocol bzw. Next
Header ist 89. Alle OSPF-Nachrichten haben denselben Protokollkopf:
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Version #
|
Type
|
Packet Length
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Router ID
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Area ID
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Checksum
|
AuType
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Authentication
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Authentication
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
• Das Feld Version enthält die Versionsnummer (2).
• Das Feld Type enthält die Identifikation des Nachrichtentyps.
• Das Feld Packet Length enhält die Länge der gesamten OSPF-Nachricht gemessen in Bytes.
• Das Feld Router ID identifiziert den Router, der das Paket gesendet hat.
• Das Feld Area ID identifiziert die OSPF Area. Die Area ID für den OSPF Backbone ist 0, oftmals
geschrieben in der Notation 0.0.0.0.
• Das Feld Checksum enthält eine Internet-Prüfsumme gebildet über die gesamte OSPF-Nachricht
ohne das Authentication Feld.
• Das Feld AuType identifiziert die verwendete Authentifizierungsprozedur.
• Das Feld Authentication wird von den Authentifizierungsprozeduren in unterschiedlicher Art
und Weise benutzt.
80
KAPITEL 3. INTERNET NETZWERKSCHICHT
Hello
Das Hello-Protokoll hat die Aufgabe, die Funktionsbereitschaft von Links festzustellen und bei broadcast
und non-broadcast Netzen einen Designated Router und einen Backup Designated Router zu bestimmen.
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Version #
|
Type = 1
|
Packet length
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Router ID
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Area ID
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Checksum
|
AuType
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Authentication
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Authentication
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Network Mask
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
HelloInterval
|
Options
|
Rtr Pri
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
RouterDeadInterval
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Designated Router
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Backup Designated Router
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Neighbor
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
...
|
• Der ersten Felder enthalten den normalen OSPF-Nachrichtenkopf, wobei das Feld Type den Wert 1
hat.
• Das Feld Network Mask enthält die Netzmaske für das Interface.
• Das Feld HelloInterval enthält das Zeitintervall in Sekunden zwischen aufeinanderfolgende
Hello-Nachrichten.
• Das Feld Rtr Pri enthält die Priorität des Routers, die für die Auswahl des Designated bzw. Backup
Designated Routers verwendet wird. Router mit der Priorität 0 nehmen nicht an der Auswahl teil.
• Das Feld RouterDeadInterval definiert das Zeitintervall in Sekunden, nachdem ein Router als
nicht mehr erreichbar betrachtet wird.
• Das Feld Designated Router enthält die Identität des Designated Routers bzw. 0 falls noch kein
Designated Router bekannt ist.
• Das Feld Backup Designated Router enthält die Identität des Backup Designated Router bzw.
0 falls noch kein Backup Designated Router bekannt ist.
• Am Ende der Nachricht befindet sich eine Liste von Neighbor Feldern, wobei jedes Neighbor
Feld die Identität eines Routers anzeigt, von dem im letzten RouterDeadInterval eine HelloNachrichten empfangen wurde.
3.4. WEGWAHLVERFAHREN
81
• Ein Link wird als verfügbar betrachtet, wenn Hello-Nachrichten in beide Richtungen ausgetauscht
werden können. Bei direkten Verbindungen (point-to-point links, virtual links) kann, sobald der Link
als verfügbar erkannt wurde, mit dem Austausch der Datenbasis begonnen werden.
• Bei Netzwerk-Verbindungen (broadcast links, non-broadcast links) wird zunächst der Designated
Router und der Backup Designated Router bestimmt:
1. Zunächst verhält sich ein Router für ein RouterDeadInterval passiv indem er eingehende
Hello-Nachrichten sammelt und eigene Hello-Nachrichten generiert, in denen er sich nicht zu
Wahl stellt. Anschließend werden nur die Nachbarn betrachtet, für die der Link in beide Richtungen verfügbar ist.
2. Wenn einer oder mehrere Router sich als Backup Designated Router angeboten haben, wird der
Router mit der höchsten Priorität ausgewählt. Sollte die Priorität nicht eindeutig sein, wird aus
den Kandidaten der Router mit der größten Identifikationsnummer ausgewählt.
3. Wenn kein Router sich als Backup Designated Router angeboten hat, wird der Router mit der
höchsten Priorität (und der größten Identifikationsnummer) ausgewählt.
4. Wenn einer oder mehrere Router sich als Designated Router angeboten haben, wird der Router
mit der höchsten Priorität ausgewählt. Sollte die Priorität nicht eindeutig sein, wird aus den
Kandidaten der Router mit der größten Identifikationsnummer ausgewählt.
5. Wenn kein Router sich als Designated Router angeboten hat, wird der Router mit der höchsten
Priorität (und der größten Identifikationsnummer) ausgewählt.
Ein Router kann nicht zugleich Designated Router und Backup Designated Router sein. Daher müssen
nach dem Schritt 5 die Schritte 2 und 3 wiederholt werden.
Exchange
Das Exchange-Protokoll hat die Aufgabe die Datenbasis initial zu synchronisieren.
...
Flooding
...
3.4.3
...
Border Gateway Protocol (BGP)
82
KAPITEL 3. INTERNET NETZWERKSCHICHT
Kapitel 4
Internet Transportschicht
Die Transportschicht hat die Aufgabe, Anwendungsprotokollen eine geeignete Transportschnittstelle zur
Verfügung zu stellen.
• IP-Adressen identifizieren Netzwerkendpunkte und besitzen daher eine Host-to-Host-Signifikanz.
• Transportendpunkte identifizieren kommunizierende Anwendungsprozesse und werden im Internet
durch eine Kombination von IP-Adresse und einer 16-Bit Portnummer gebildet. Transportadressen
besitzen End-to-End-Signifikanz.
• Für Standardanwendungsprotokolle sind Portnummern fest definiert (well-known ports).
• Mit Hilfe der Portnummern erfolgt ein Multiplexen auf Transportebene:
SMTP
HTTP
FTP
IP Address + Portnummer
Transport Layer
IP Adresse
IP Layer
Abbildung 4.1: Multiplexen mit Hilfe von Portnummern
Derzeit existieren im wesentlichen vier Transportprotokolle im Internet:
1. Das User Datagram Protocol (UDP) realisiert einen einfachen unzuverlässigen Datagrammdienst.
2. Das Transmission Control Protocol (TCP) realisiert einen zuverlässigen, verbindungsorientierten Datenstrom.
3. Das Stream Control Transmission Protocol (SCTP) realisiert einen zuverlässigen Transportdienst, bei
dem mehrere unabhängige Nachrichtenströme über eine Verbindung gemultiplext werden können.
SCTP erhält die Grenzen von Nachrichten (framing) und unterstützt insbesondere Signalisierungsprotokolle.
4. Das Real-Time Transport Protocol (RTP) realisiert eine Transportdienst für Realzeit-Datenübertragungen wie z.B. Audio und Video. RTP basiert in der Regel auf UDP.
83
84
KAPITEL 4. INTERNET TRANSPORTSCHICHT
4.1 Pseudo-Header
Viele Transportprotokolle beinhalten eine Internet-Prüfsumme, die in der Regel über den Transportprotokollkopf und einen Pseudo-Header berechnet wird.
Der IPv4 Pseudo-Header besteht aus der Quell- und Zieladresse plus der Protokollnummer und der Länge
der Nutzdaten:
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Source Address
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Destination Address
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| unused (0)
|
Protocol
|
Length
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Der IPv6 Pseudo-Header besteht aus der Quell- und Zieladresse plus der Nutzdatenlänge und des Next
Header Felds:
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
+
+
|
|
+
Source Address
+
|
|
+
+
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
+
+
|
|
+
Destination Address
+
|
|
+
+
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Upper-Layer Packet Length
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
zero
| Next Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.2
User Datagram Protocol (UDP)
Das User Datagram Protocol (UDP) ist in RFC 768 [37] definiert und stellt einen einfachen unbestätigten
Datagrammdienst zur Verfügung. Im wesentlichen erweitert UDP den IP Datagrammdienst um Portnummern und eine zusätzliche Prüfsumme. Der Wert im Feld Protocol des IPv4-Protokollkopfs bzw. Next
Header des IPv6-Protokollkopfs ist 17.
Der UDP-Protokollkopf hat folgendes Format:
4.3. TRANSMISSION CONTROL PROTOCOL (TCP)
85
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Source Port
|
Destination Port
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Length
|
Checksum
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
• Das Feld Source Port identifiziert die Portnummer des sendenden Prozesses.
• Das Feld Destination Port identifiziert die Portnummer des empfangenden Prozesses.
• Das Feld Length enthält die Länge des UDP-Datagramms inklusive des UDP-Protokollkopfs gemessen in Bytes.
• Das Feld Checksum enthält eine Internet-Prüfsumme gebildet über den Pseudo-Header, den UDPProtokollkopf und die im Datagramm enthaltenen Daten.
4.3
Transmission Control Protocol (TCP)
Das Transmission Control Protocol (TCP) ist in RFC 793 [38] definiert und stellt einen zuverlässigen verbindungsorientierten Transportdienst über einem unzuverlässigen verbindungslosen Netzwerkprotokoll zur
Verfügung. Endsysteme tauschen einen unstrukturierten Bytestrom aus, wobei eine TCP-Verbindung bidirektional oder unidirektional betrieben werden kann. TCP realisiert eine Ende-zu-Ende-Flusskontrolle durch
eine Fenstertechnik mit adaptiven Timeouts und einer automatischen Anpassung an Stausituationen.
Zur Übertragung zerlegt TCP einen Datenstrom in sogenannte Segmente. Jedes Segment wird mit einem
eigenen TCP-Protokollkopf versehen und übertragen. Der TCP-Protokollkopf hat folgendes Format:
0
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Source Port
|
Destination Port
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Sequence Number
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Acknowledgment Number
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offset| Reserved |
Flags
|
Window
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Checksum
|
Urgent Pointer
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
Options
|
Padding
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
• Das Feld Source Port identifiziert die Portnummer des sendenden Prozesses.
• Das Feld Destination Port identifiziert die Portnummer des empfangenden Prozesses.
• Das Feld Sequence Number enthält nach dem Verbindungsaufbau die Sequenznummer des ersten
Datenbytes im Segment. Beim Verbindungsaufbau wird das Feld zum Etablieren der Sequenznummer
benutzt.
• Das Feld Acknowledgment Number enthält die nächste Sequenznummer, die der Sender des Acknowledgments erwartet.
86
KAPITEL 4. INTERNET TRANSPORTSCHICHT
• Das Feld Offset enthält die Länge des TCP-Protokollkopfes inklusive der Optionen gemessen in 32
Bit Worten.
• Das Feld Flags enthält eine Menge von Flaggen:
– URG: Das Feld Urgent Pointer ist signifikant.
– ACK: Das Feld Acknowledgment Number ist signifikant.
– PSH: Daten werden möglichst direkt dem Empfänger zugestellt.
– RST: Rücksetzen der Verbindung.
– SYN: Synchronisation der Sequenznummern.
– FIN: Keine weitere Daten vom Sender.
• Das Feld Window zeigt die Anzahl der Datenbytes an, die der Sender des Segments bereit ist zu
empfangen.
• Das Feld Checksum enthält eine Internet-Prüfsumme, gebildet über den Pseudo-Header, den TCPProtokollkopf und die im Segment enthaltenen Daten.
• Das Feld Urgent Pointer zeigt relativ zur aktuellen Segmentnummer auf wichtige Daten wenn
das URG-Bit gesetzt ist.
• Das Feld Options kann weitere Optionen aufnehmen.
4.3.1
Verbindungsaufbau
Der Verbindungsaufbau erfolgt durch einen sogenannten three-way handshake. Das Verfahren garantiert
einen korrekten Verbindungsaufbau, selbst wenn TCP-Pakete verloren gehen oder dupliziert werden. Im
Normalfall (d.h. keine Probleme durch etwaige Paketverluste) läuft das Verfahren nach folgendem Schema
ab:
Active Open
Passive Open
SYN x
SYN x
ACK x+1, SYN y
ACK x+1, SYN y
ACK y+1
ACK y+1
Abbildung 4.2: TCP Verbindungsaufbau
• Eine TCP-Protokollmaschine wartet zunächst passiv auf eine Verbindung (passive open).
• Eine zweite TCP-Protokollmaschine startet den Verbindungsaufbau (active open).
• Zunächst wird eine initiale Sequenznummer in einem SYN-Paket übertragen. Die initiale Sequenznummer wird durch einen Zähler bestimmt, der ungefähr alle 4 Mikrosekunden inkrementiert wird.
Dieses Verfahren garantiert, dass eine initiale Sequenznummer nicht wiederbenutzt wird, solange sich
noch potentiell Pakete einer alten Verbindung im Netz befinden.
87
4.3. TRANSMISSION CONTROL PROTOCOL (TCP)
• Die passive Seite merkt sich die Sequenznummer und sendet ihre eigene zufällig gewählte Sequenznummer. Dabei wird der Empfang des ersten SYN-Pakets quittiert.
• Die aktive Seite merkt sich nun ebenfalls die Sequenznummer und bestätigt den Empfang durch das
Senden einer Quittung.
4.3.2
Verbindungsabbau
TCP stellt zunächst nach dem Verbindungsaufbau immer zwei unabhängige Datenströme bereit. Durch den
Abbau eines Datenstroms wird aus einer bidirektionalen Verbindung eine unidirektionale Verbindung. Wenn
beide Datenströme abgebaut werden, ist die TCP-Verbindung beendet. Im Normalfall (d.h. keine Probleme
durch etwaige Paketverluste) läuft das Verfahren nach folgendem Schema ab:
Active Open
Passive Open
FIN x
FIN x
ACK x+1
ACK x+1
ACK x+1, FIN y
ACK x+1, FIN y
ACK y+1
ACK y+1
Abbildung 4.3: TCP Verbindungsaufbau und -abbau
• Der Verbindungsabbau wird durch das Setzen des FIN-Bits eingeleitet.
• Dem Empfänger bestätigt zunächst den Empfang des TCP-Pakets.
• Anschließend informiert der Empfänger die betroffene Applikation über den Abbau der Verbindung.
• Nachdem die Applikation bereit ist, die Verbindung abzubauen, wird ein TCP-Paket mit gesetztem
FIN-Bit übertragen, wobei die Quittung wiederholt wird.
• Der Empfang des zweiten FIN-Pakets wird durch eine Quittung bestätigt.
Sollte es zu einem abrupten Ausfall des Senders oder des Empfängers kommen, so verlangt der TCP-Standard
eine Ruhezeit von 120 Sekunden bevor neue TCP-Verbindungen etabliert werden können (maximum segment lifetime, MSL). Diese Ruhezeit ist dadurch motiviert, dass nach 120 Sekunden Segmente von alten
Verbindungen aus dem Netz verschwunden sein sollten.
4.3.3
Zustandsmaschine
Die Schritte zum Verbindungsauf- und abbau lassen sich am einfachsten durch einen endlichen Automaten
beschreiben. Der TCP-Automat hat folgende Zustände:
88
KAPITEL 4. INTERNET TRANSPORTSCHICHT
CLOSED:
LISTEN:
SYN-RCVD:
SYN-SENT:
ESTABLISHED:
FIN-WAIT-1:
FIN-WAIT-2:
TIMED-WAIT:
CLOSING:
CLOSE-WAIT:
LAST-ACK:
4.3.4
Startzustand
Server wartet auf Verbindungswünsche (passive open)
Server hat Verbindungswunsch empfangen
Client hat Verbindungsaufbau gestartet
Verbindung ist etabliert und betriebsbereit
Server/Client hat den Verbindungsabbau eingeleitet
Client/Server hat den Verbindungsabbau bestätigt
Warten bis alle Segmente verschwunden sind
Endpunkte beenden die Verbindung gleichzeitig
Entferntes System hat einen Verbindungsabbau gestartet
Warten bis alle Segmente verschwunden sind
Flusskontrolle
Nagle Algorithmus
Silly Window Syndrome
4.3.5
Staukontrolle
Timer
Karn Algorithmus
4.3.6
4.4
[39, 40]
Optionen
Stream Control Transmission Protocol (SCTP)
Kapitel 5
Internet Anwendungsschicht
Das Anwendungssystem im Internet ist nicht besonders strukturiert. Viele Protokolle setzen direkt auf den
Transportprotokollen auf und es ist nicht unüblich, daß die einzelnen Protokolle wiederkehrende gleichartige
Probleme (z.B. maschinenunabhängige Datenkodierung) auf verschiedene Weisen lösen. Obwohl dies global
betrachtet nicht besonders effizient zu sein scheint, sind diese vielen spezialisierten Einzellösungen praktisch
sehr erfolgreich gewesen.
Die im Internet verwendeten Anwendungsprotokolle sind sehr vielfältig. Im folgenden werden nur diejenigen
vorgestellt, die entweder besonders wichtige Kerndienste realisieren (z.B. DNS), einen Großteil des Verkehrs
ausmachen (z.B. HTTP, FTP, SMTP) oder durch spezielle Besonderheiten interessant sind (z.B. SNMP).
5.1 Domain Name System (DNS)
Das Internet verwendet zur Adressierung Bitfolgen (IPv4/IPv6 Adressen und Portnummern), die maschinell effizient verarbeitet werden können aber für Menschen nur schwer zu merken sind. Das Domain Name
System [41, 42] ist die Infrastruktur, die nutzerfreundliche Namen in entsprechende Adressen abbildet.
virtual Root
nl
de
edu
org
net
com
biz
Toplevel
uni−osnabrueck
2nd Level
informatik
3rd Level
www
4th Level
Abbildung 5.1: Struktur der Domain Name System (DNS) Namen
• Das Domain Name System stellt einen hierarchischen Namensraum mit einer virtuellen Wurzel zur
Verfügung. Die Administration des Namensraums kann entlang der Pfade von der virtuellen Wurzel
aus delegiert werden.
• Die Auflösung von Namen erfolgt durch sogenannten DNS-Server, die jeweils einen Teil des globalen
Namensraums und ihre Position in der Hierarchie kennen.
• Anfragen können quasi an beliebige DNS-Server gestellt werden. Bei sogenannten rekursiven Anfragen wird der befragte DNS-Server gegebenenfalls andere DNS-Server kontaktieren um eine Antwort
auf eine Anfrage zu bekommen. Alternativ kann aber auch iterativ vorgegangen werden, wobei der
Anfrager sich iterativ durch eine Menge von DNS-Server durchfragen muß.
89
90
KAPITEL 5. INTERNET ANWENDUNGSSCHICHT
• In den letzten Jahren wird verstärkt versucht, eine Sicherheitsinfrastruktur für DNS-Server zu etablieren. Einerseits ist es durchaus sinnvoll, Namensauflösungen so abzusichern, daß man den Antworten auch vertrauen kann. (Verbirgt sich hinter www.meine-bank.de wirklich meine Bank?)
Andererseits könnte eine sichere DNS-Infrastruktur auch zur Verteilung von Zertifikaten für andere
Sicherheitsmechanismen dienen.
• Da wohlklingende DNS-Namen in den letzten Jahren ein Handelsgut geworden sind, gibt es sehr viel
politisches Tauziehen um die Frage, wer eigentlich die Toplevel-Domains definiert.
Cache
Umfassender
Nameserver
API
RR DB
DNS
Anwendung
Resolver
Cache
Lokal auf einer Maschine
DNS
Primaerer
Nameserver
RR DB
Cache
Verschiedene DNS Server
Abbildung 5.2: Rekursive Namensauflösung mit zwei DNS Servern
Das gesamte Domain Name System besteht im wesentlichen aus drei Komponenten:
• Der hierarchische Namensraum und die sogenannten Resource Records (RRs), die die für einen Namen bekannten typisierten Informationen beinhalten. Es gibt verschiedene standardisierte Resource
Records und es können neue Resource Records definiert werden um zusätzliche Informationen im
DNS abzulegen.
• Eine Menge von Servern, die mit Hilf des DNS-Protokolls Zugriff auf die verwalteten Informationen
ermöglichen und in der Regel lokale Cache-Speicher verwalten. Die an einem DNS-Server administrativ konfigurierten Informationen werden in sogenannte Zonen eingeteilt. Man spricht in diesem
Zusammenhang auch davon, daß ein DNS-Server authorität über die lokalen Zonen besitzt.
• Resolver sind Programme oder Bibliotheken, die in der Regel für Anwendungsprogramme Namensauflösungen durchführen.
5.1.1
Format von Domain Namen
Im RFC 1034 [41] finden sich genauere Details über das Format von Domain Namen. Zu beachten ist hierbei,
daß derzeit Bemühungen unterwegs sind, auch internationale Zeichen in Domain Namen zuzulassen.
• Die Namen (labels) auf einer Ebene der Hierarchie müssen eindeutig und dürfen nicht länger als 63
Byte lang sein. Der Zeichensatz ist 7-Bit ASCII, wobei Großkleinschreibung bei Vergleichen nicht
relevant ist.
• Die Namen auf einer Ebene müssen mit einem Buchstaben beginnen und einem Buchstaben oder einer
Ziffer enden. Zwischen dem ersten und lezten Zeichen dürfen nur Buchstaben, Ziffern und Bindestriche vorkommen.
5.1. DOMAIN NAME SYSTEM (DNS)
91
• Die Namen der verschiedenen Ebenen können mit Hilfe eines Punkts konkateniert werden. Man erhält
auf diese Art und Weise Pfade im Namensraum. Absolute Pfade, die an der virtuellen Wurzel enden,
enden entsprechend mit einem Punkt. Alle anderen Pfade die nicht mit einem Punkt enden werden als
relative Pfade betrachtet.
• Die Gesamtlänge eines Domain Namens ist auf 255 Byte begrenzt.
5.1.2
Resource Records
Die zu einem Namen gehörenden Informationen werden in sogenannten Resource Records (RRs) gehalten.
Jeder RR hat folgende Attribute:
• Der Besitzer (owner) ist der Domain Name der einen Resource Record identifiziert.
• Der Typ (type) definiert die Art der Informationen im Resource Record. Die wichtigsten Typen sind
[41, 43, 44, 45]:
Typ
Beschreibung
A
IPv4 Adresse
AAAA
IPv6 Adresse (erster Versuch)
A6
IPv6 Adresse (zweiter Versuch)
CNAME Alias für einen anderen Namen
HINFO Identifikation der CPU und des Betriebssystems
MX
(mail exchanger)
Identifikation eines authoritativen Servers für eine Domain
NS
PTR
Verweis auf einen anderen Teil des Namensraums
SOA
Beschreibt den Anfang und Parameter einer Zone
Öffentlicher Schlüssel der mit einem Domain Namen assoziiert ist
KEY
SIG
Signatur über die RRs eines Domain Namens
• Die Klasse (class) definiert einen protokollspezifischen Namensraum. Ursprünglich wurde das Domain Name System nicht nur im Internet benutzt. Entsprechend unterscheidet man zwischen IN (Internet) und CH (Chaos System).
• Die Lebensdauer (TTL) bestimmt, wieviele Sekunden die Informationen aus einem RR in einem Cache gehalten werden können.
• Das Datenformat (RDATA) eines RRs ist abhängig vom Typ des RRs.
5.1.3
DNS Nachrichtenformat
Alle DNS Nachrichten haben die gleiche Struktur und bestehen aus fünf Abschnitten:
1. Eine DNS Nachricht beginnt mit einem Protokollkopf (header). Er legt fest, welche der im folgenden
beschriebenen Elemente vorhanden sind und ob es sich um bei einer Nachricht um eine Anfrage oder
eine Antwort handelt.
2. Eine Liste von Anfragen (questions).
3. Eine Liste von RRs mit Antworten (answers).
4. Eine Liste von RRs mit Verweisen auf Authoritäten (authorities).
5. Eine Liste von weiteren RRs die weitere nützliche Informationen enthalten (additional).
Als Transport für Anfragen wird normalerweise UDP verwendet. Beim Austausch von größeren Datenmengen (zone transfers) wird zumeist TCP eingesetzt. Die Standardportnummer ist für beide Transportprotokolle
53.
92
KAPITEL 5. INTERNET ANWENDUNGSSCHICHT
DNS Protokollkopf
0
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|
ID
|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QR|
Opcode |AA|TC|RD|RA| Z|AD|CD|
RCODE
|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|
QDCOUNT
|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|
ANCOUNT
|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|
NSCOUNT
|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|
ARCOUNT
|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
• Das Feld ID enhält eine Nummer, mit der Antworten vorausgegangenen Fragen zugeordnet werden
können.
• Das Bit QR ist 0 bei einer Anfrage und 1 bei einer Antwort.
• Das Feld OPCODE beschreibt die Art der Anfrage. Es ist 0 für eine Standardanfrage (QUERY) und 1
für eine inverse Anfrage (IQUERY).
• Das Bit AA ist gesetzt, wenn es sich um eine authoritative Antwort handelt.
• Das Bit TC signalisiert, daß die Nachricht aufgrund von Begrenzungen des Transportsystems unvollständig ist (truncated).
• Das Bit RD ist gesetzt, wenn eine rekursive Anfrage gestellt wird (recursion desired).
• Das Bit Z ist derzeit nicht benutzt.
• Das Bit AD ist gesetzt, wenn eine Antwort authentifizierte Daten enthält (authentic data).
• Das Bit CD ist gesetzt, wenn ein resolver nicht-authentifizierte Daten bereit ist zu akzeptieren (checking
disabled).
• Das Feld RCODE enthält einen Fehlercode, der natürlich nur bei Antworten relevant ist.
• Das Feld QDCOUNT enthält die Anzahl der Anfragen in der Liste von Anfragen.
• Das Feld ANCOUNT enthält die Anzahl der Antworten in der Liste der Antworten.
• Das Feld NSCOUNT enthält die Anzahl der authoritativen Nameserver in der Liste der Authoritäten.
• Das Feld ARCOUNT enthält die Anzahl der Elemente in der Liste der weiteren Informationen.
DNS Anfrageformat
Die Einträge in der Anfrageliste haben folgendes Format:
0
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|
|
/
QNAME
/
/
/
5.1. DOMAIN NAME SYSTEM (DNS)
93
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|
QTYPE
|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|
QCLASS
|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
• Das Feld QNAME enthält den Domain Namen, auf den sich die Anfrage bezieht.
• Das 16-Bit Feld QTYPE bestimmt die Art der Anfrage. Einige definierte Werte sind: 1 (A), 2 (NS), 5
(CNAME), 6 (SOA), 12 (PTR), 13 (HINFO), 15 (MX), 24 (SIG), 25 (KEY), 38 (A6)
• Das 16-Bit Feld QCLASS bestimmt die Klasse — in der Regel ist dies der Wert 1 für das Internet (IN).
DNS Antwortformat
Die Einträge in den Listen der Antworten, die Verweise auf Authoritäten und die sonstigen Informationen
haben alle die folgende Struktur:
0
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|
|
/
/
/
NAME
/
|
|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|
TYPE
|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|
CLASS
|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|
TTL
|
|
|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|
RDLENGTH
|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
/
RDATA
/
/
/
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
• Das Feld NAME enthält den Domain Namen, auf den sich ein Resource Record bezieht.
• Das 16-Bit Feld TYPE identifiziert den Typ des Resource Records und damit das Format des Felds
RDATA.
• Das 16-Bit Feld CLASS bestimmt die Klasse — in der Regel ist dies der Wert 1 für das Internet (IN).
• Das 16-Bit Feld TTL beschreibt die Lebenszeit des Resource Records in Sekunden.
• Das 16-Bit Feld RDLENGTH enthält die Länge des Felds RDATA.
• Das Feld RDATA enthält die eigentlichen Informationen. Das Format dieses Felds ist abhängig vom
Typ des Resource Records.
94
KAPITEL 5. INTERNET ANWENDUNGSSCHICHT
DNS Formate für Resource Records
Nach dem Protokollkopf folgen die Listen von Resource Records. Die verschiedenen RRs haben folgende
Formate:
• Ein A RR wird als 4-Byte IPv4 Adresse kodiert.
• Ein AAAA RR wird als 16-Byte IPv6 Adresse kodiert.
• Ein A6 RR besteht aus zwei oder drei Feldern. Das erste Feld ist ein Byte lang und enthält die Länge
des Adreßpräfixes. Das zweite Feld enthält einen passenden Adreßsuffix, wobei ggf. 0-7 führende
0-Bits eingefügt werden um die Bitfolge auf eine Bytegrenze auszurichten. Das dritte Feld enthält
eine Zeichenkette mit vorangestellter Länge die den Domain Namen kennzeichnet, der den Präfix
identifiziert. Das Format trennt bewußt den Präfix, um ein mögliches Umbenennen beim Ändern eines
Providers einfach wird. Natürlich sind zwei verschiedene Formate für IPv6-Adressen keine gute Idee
und daher wurde im July 2002 das A6-Format als experimentell klassifiziert.
• Ein CNAME RR wird als Zeichenkette mit vorangestellter Länge kodiert. Das erste Byte enthält die
Länge der sich daran anschließenden Zeichenfolge.
• Ein HINFO RR wird durch zwei Zeichenketten (jeweils mit vorangestellter Länge) kodiert. Die erste
Zeichkette beschreibt die CPU und die zweite das Betriebssystem.
• Ein MX RR wird durch eine 16-Bit Zahl (Präferenz) und eine Zeichenkette mit vorangestellter Länge
(Mail-Exchanger) kodiert.
• Ein NS RR wird als Zeichenkette mit vorangestellter Länge kodiert, die den Domain Namen eines
authoritativen Servers enthält.
• Ein PTR RR wird als Zeichenkette mit vorangestellter Länge kodiert, die den Domain Namen eines
anderen Domain Name Servers enthält.
• Ein SOA RR besteht aus zwei Zeichenketten (jeweils mit vorangestellter Länge) und vier 32-Bit Zahlen. Die erste Zeichenkette enthält den Domain Namen des Servers, der für eine Zone verantwortlich
ist. Die zweite Zeichenkette enthält die email-Adresse über die ein verantwortlicher Administrator erreicht werden kann. Die erste vorzeichenlose 32-Bit Zahl enthält eine Seriennummer (SERIAL), die
immer bei Änderungen inkrementiert werden sollte. Die zweite 32-Bit Zahl beschreibt die Zeit, bevor
eine Zone aktualisiert werden sollte (REFRESH). Die dritte 32-Bit Zahl beschreibt die obere Grenze,
nach der eine Zone nicht mehr verbindlich ist (EXPIRE). Die vierte 32-Bit Zahl enthält die minimale
Lebenszeit, die RRs enthalten sollten (MINIMUM).
• Das relativ komplexe Format der KEY und SIG RRs ist im RFC 2535 [44] beschrieben.
95
5.2. ABSTRACT SYNTAX NOTATION ONE (ASN.1)
5.2 Abstract Syntax Notation One (ASN.1)
Die Abstract Syntax Notation One (ASN.1) [46, 47, 48] ist eine Sprache zur Definition von Datenstrukturen
und Nachrichtenformaten, die in den 80er Jahren entwickelt und von der ITU standardisiert wurde. Ziele bei
der Entwicklung von ASN.1:
• Austausch von Informationen zwischen Maschinen mit unterschiedlichen Hardwarearchitekturen.
• Unabhängigkeit von existierenden Programmiersprachen (Neutralität).
• Kodierung der Daten während der Übertragung soll zwischen Sender und Empfänger wählbar sein.
Abstrakte Syntax (ASN.1)
Lokale Syntax
Lokale Syntax
Genormter
Datenaustausch
Kodierer
Kodierer
System A
System B
Transfersyntax (ASN.1 Encoding Rules)
Abbildung 5.3: Abtrakte Syntax, lokale Syntax und Transfersyntax
Daraus folgt die Trennung der Datendarstellung während der Übertragung von der Beschreibung der applikationsspezifischen Datenstrukturen:
• Die abstrakte Syntax definiert die Datenstrukturen. Die abstrakte Syntax wird zu Implementationszwecken auf die lokale Syntax abgebildet, die an die jeweilige Programmiersprache angelehnt ist.
Prinzipiell kann diese Abbildung durch Compiler automatisiert werden.
• Die Transfersyntax definiert, in welcher Form Datenstrukturen seriell über ein Netzwerk übertragen
werden. Ein Transfersyntax wird durch sogenannte Encoding Rules definiert. Es existieren viele verschiedene Encoding Rules für ASN.1 und es ist daher notwendig sich auf die zu verwendende Transfersyntax zu einigen. Die Erzeugung eines Kodierers kann durch Compiler automatisiert werden.
5.2.1
Grundlagen
• Namen von ASN.1 Datentypen beginnen grundsätzlich mit Großbuchstaben.
• Namen von ASN.1 Werten (Konstanten) beginnen grundsätzlich mir einem Kleinbuchstaben.
• ASN.1 Schlüsselworte und Makronamen bestehen nur aus Großbuchstaben.
• Kommentare werden durch -- eingeleitet und enden am Zeilenende oder am nächsten --.
96
KAPITEL 5. INTERNET ANWENDUNGSSCHICHT
5.2.2
ISO-Registrationsbaum
itu−t(0) / ccitt(0)
standard(0)
iso(1)
joint−iso−itu−t(2) / joint−iso−ccitt(2)
registration−authority(1)
member−body(2)
identified−organization(3)
dod(6)
internet(1)
directory(1)
mgmt(2)
experimental(3)
mib−2(1)
system(1)
interfaces(2)
ip(4)
icmp(5)
private(4)
security(5)
snmpDomains(1)
tcp(6)
udp(7)
x25(5)
transmission(10)
snmpV2(6)
snmpProxy(2)
snmp(11) ...
dot3(7) dot5(9) fddi(15) lapb(16)
snmpModules(3)
snmpMIB(1)
snmpFrameworkMIB(10)
...
...
Abbildung 5.4: ISO-Registrationsbaum
5.2.3
Primitive ASN.1 Datentypen
• Der Datentyp BOOLEAN kann nur die vordefinierten Werte TRUE und FALSE annehmen.
• Der Datentyp INTEGER umfaßt alle ganzen Zahlen. Es gibt keine Begrenzung bezüglich des Zahlenbereichs.
• Der Datentyp BIT STRING definiert eine Folge von Bits. Die Länge eines BIT STRINGs muß nicht
durch 8 teilbar sein.
• Der Datentyp OCTET STRING ist eine Folge von Octets (Bytes). Der OCTET STRING ist ein
Basistyp für Zeichenketten in verschiedenen Zeichensätzen oder andere abgeleitete Typen wie z.B.
GeneralizedTime oder UTCTime.
• Der Datentyp ENUMERATED ist ein Aufzählungstyp. Mögliche Werte müssen bei der Definition abgeleiteter Datentypen festgelegt werden.
• Der Datentyp OBJECT IDENTIFIER liefert eine eindeutige Identifikation eines Knotens im ISORegistrationsbaum. Ein OBJECT IDENTIFIER Wert identifiziert den Pfad von der Wurzel des Baums
zum Zielknoten.
• Der Datentyp ObjectDescriptor enthält eine Zeichenkette zur Identifikation eines Knotens im
ISO-Registrationsbaum. Ein Wert dieses Typs ist nicht unbedingt eindeutig.
• Der Datentyp ANY steht für einen beliebigen ASN.1 Datentyp (Vereinigung aller ASN.1 Datentypen).
• Der Datentyp EXTERNAL steht für Daten, die nicht mit Hilfe von ASN.1 Definitione beschrieben
werden.
• Der Datentyp NULL ist ein Platzhalter, um in einem zusammengesetzten Datentyp das Fehlen eines
Wertes zu kennzeichnen.
5.2. ABSTRACT SYNTAX NOTATION ONE (ASN.1)
5.2.4
97
Zusammengesetzte ASN.1 Datentypen
• Der Datentyp SEQUENCE entspricht Strukturen in C bzw. Records in Modula. Die Reihenfolge der
Elemente in einer SEQUENCE ist fest definiert.
• Der Datentyp SET ist analog zu einer SEQUENCE, wobei die Reihenfolge der Elemente nicht festgelegt ist.
• Der Datentyp SEQUENCE OF liefert eine geordnete Menge (Liste) von gleichartigen Daten.
• Der Datentyp SET OF liefert eine ungeordnete Liste von gleichartigen Daten.
• Der Datentyp CHOICE ist ein Auswahltyp und entspricht Unions in C bzw. varianten Records in
Modula.
• Der Datentyp REAL ist ein aus dem Datentyp INTEGER konstruierter Datentyp bestehend aus Mantisse und Exponent.
5.2.5
Einschränkungen von Datentypen
ASN.1 Datentypen können weiter eingeschränkt werden.
Beispiele:
LottoZahl
MD5Key
InetAddress
Unsigned32
Integer32
Unsigned64
::=
::=
::=
::=
::=
::=
INTEGER (1..49)
OCTET STRING (SIZE (16))
OCTET STRING (SIZE (4|6))
INTEGER (0..4294967295)
INTEGER (-2147483648..2147483647)
INTEGER (0..18446744073709551615)
• Die genaue Syntax der Einschränkungen ist abhängig vom zugrundeliegenden primitiven Datentyp.
• Einschränkungen des Wertebereichs werden an abgeleitete Datentypen vererbt.
• Sinnvoll ist grundsätzlich die Einschränkung des Datentyps INTEGER, da heutige Rechner intern
meist mit 32 bzw. 64 Bit rechnen.
5.2.6
ASN.1 Tags
• Datentypen werden mit Hilfe von Tags bei der Übertragung identifiziert.
• Tags bestehen aus einer Tag-Nummer und einer Tag-Klasse. Es gibt vier verschiedene Tag-Klassen:
1. UNIVERSAL: Weltweit eindeutig Identifizierung (Benutzung nur im ASN.1 Standard zulässig).
2. APPLICATION: Eindeutige Identifikation innerhalb einer Applikation.
3. PRIVATE: Für herstellerspezifische, nicht allgemein benutzte Identifikationen.
4. CONTEXT-SPECIFIC: Typkennung tritt ohne Klassenangabe aus (z.B. beim Auswahltyp).
• Die folgende Tabelle gibt eine Übersicht über die universellen Tags für grundlegende ASN.1 Datentypen, wie sie im ASN.1 Standard definiert sind.
98
KAPITEL 5. INTERNET ANWENDUNGSSCHICHT
Datentyp
BOOLEAN
INTEGER
BIT STRING
OCTET STRING
NULL
OBJECT IDENTIFIER
ObjectDescriptor
EXTERNAL
REAL
ENUMERATED
...
SEQUENCE, SEQUENCE OF
SET, SET OF
NumericString
PrintableString
TeletexString
VideotextString
IA5String
UTCTime
GeneralizedType
GraphicsString
VisibleString
GeneralString
CharacterString
...
5.2.7
Tag (dezimal)
1
2
3
4
5
6
7
8
9
10
...
16
17
18
19
20
21
22
23
24
25
26
27
28
...
Beispiel für eine ASN.1 Definition
Das folgende Beispiel zeigt eine Definition des SNMPv1 Protocols [49, 50] in einem einzigen ASN.1 Modul.
Die Definition entspricht dem typischerweise implementierten SNMPv1 Protokoll, weicht aber in den Details
der Notation deutlich von den RFCs ab.
HYPOTHETICAL-SNMPv1 DEFINITIONS ::= BEGIN
-- object names and types
ObjectName ::= OBJECT IDENTIFIER
ObjectSyntax ::= CHOICE {
simple
SimpleSyntax,
application-wide ApplicationSyntax
}
SimpleSyntax ::= CHOICE {
integer-value INTEGER (-2147483648..2147483647),
string-value
OCTET STRING (SIZE (0..65535)),
oid-value
OBJECT IDENTIFIER,
empty
NULL
}
ApplicationSyntax ::= CHOICE {
address-value
NetworkAddress,
99
5.2. ABSTRACT SYNTAX NOTATION ONE (ASN.1)
counter-value
gauge-value
timeticks-value
arbitrary-value
Counter32,
Gauge32,
TimeTicks,
Opaque
}
NetworkAddress ::= CHOICE {
internet
IpAddress
}
IpAddress
Counter32
Gauge32
TimeTicks
Opaque
::=
::=
::=
::=
::=
[APPLICATION
[APPLICATION
[APPLICATION
[APPLICATION
[APPLICATION
0]
1]
2]
3]
4]
IMPLICIT
IMPLICIT
IMPLICIT
IMPLICIT
IMPLICIT
OCTET STRING (SIZE (4))
INTEGER (0..4294967295)
INTEGER (0..4294967295)
INTEGER (0..4294967295)
OCTET STRING
-- protocol data units
Message ::= SEQUENCE {
version
INTEGER { version-1(0) },
community OCTET STRING,
data
ANY
-- PDUs if trivial authentication
}
PDUs ::= CHOICE {
get-request
get-next-request
get-response
set-request
trap
}
GetRequest-PDU
GetNextRequest-PDU
GetResponse-PDU
SetRequest-PDU
Trap-PDU
GetRequest-PDU,
GetNextRequest-PDU,
GetResponse-PDU,
SetRequest-PDU,
Trap-PDU
::=
::=
::=
::=
::=
[0]
[1]
[2]
[3]
[4]
IMPLICIT
IMPLICIT
IMPLICIT
IMPLICIT
IMPLICIT
PDU
PDU
PDU
PDU
TrapPDU
max-bindings INTEGER ::= 2147483647
RequestID
::= INTEGER (-214783648..214783647)
ErrorIndex ::= INTEGER (0..max-bindings)
ErrorStatus ::= INTEGER { noError(0), tooBig(1), noSuchName(2),
badValue(3), readOnly(4), genErr(5) }
VarBind ::= SEQUENCE {
name
ObjectName,
value ObjectSyntax
}
VarBindList ::= SEQUENCE (SIZE (0..max-bindings)) OF VarBind
PDU ::= SEQUENCE {
request-id
RequestID,
100
KAPITEL 5. INTERNET ANWENDUNGSSCHICHT
error-status
ErrorStatus,
error-index
ErrorIndex,
variable-bindings VarBindList
}
TrapPDU ::= SEQUENCE {
enterprise
OBJECT IDENTIFIER,
agent-addr
NetworkAddress,
generic-trap
INTEGER { coldStart(0), warmStart(1),
linkDown(2), linkUp(3),
authenticationFailure(4),
egpNeighborLoss(5),
enterpriseSpecific(6) },
specific-trap
INTEGER (0..214783647),
time-stamp
TimeTicks,
variable-bindings VarBindList
}
END
101
5.2. ABSTRACT SYNTAX NOTATION ONE (ASN.1)
5.2.8
Basic Encoding Rules (BER)
Die Basic Encoding Rules (BER) basieren auf einer Tag/Length/Value (TLV) Kodierung, bei der jedes Datenelement durch ein identifizierendes Tag, die Länge der Daten und die Daten selbst kodiert wird. Die
TLV-Kodierung erlaubt es einem Empfänger, den Typ einer Nachricht aus dem empfangenen Bytestrom zu
rekonstruieren bzw. Typfehler zu erkennen. (Inwieweit dies nützlich ist und ob der Preis in Form von zusätzlichen Bytes gerechtfertigt ist kann man natürlich diskutieren.)
BER Kodierung der Tags
8 7 6 5 4 3 2 1
tag number (< 31)
tag type { primitive(0), constructed(1) }
tag class { universal (00), application(01), context(10), private(11) }
8 7 6 5 4 3 2 1
1 1 1 1 1
8 7 6 5 4 3 2 1
...
1
8 7 6 5 4 3 2 1
8 7 6 5 4 3 2 1
1
0
tag number (> 31)
tag type { primitive(0), constructed(1) }
tag class { universal (00), application(01), context(10), private(11) }
Abbildung 5.5: BER Kodierung von Tags
• In den meisten Fällen sind Tag-Nummern kleiner als 31 und entsprechend lassen sich die meisten Tags
in einem Byte kodieren.
• Anhand des primitive / constructed Bits kann ein Empfänger entscheiden, ob der Wert selbst
wieder Daten im BER Format enthält. (Durch einen einfachen rekursiven Abstieg können also beliebige BER-kodierte Daten analysiert werden.)
BER Kodierung der Längen
8 7 6 5 4 3 2 1
0
length (< 128)
8 7 6 5 4 3 2 1
1
8 7 6 5 4 3 2 1
8 7 6 5 4 3 2 1
...
length (> 127)
number of bytes encoding length
Abbildung 5.6: BER Kodierung der Längen
102
KAPITEL 5. INTERNET ANWENDUNGSSCHICHT
BER Kodierung von BOOLEAN
• Ein BOOLEAN Wert wird durch ein Byte kodiert. Der Wert true wird durch das Byte 0xff und der
Wert false durch das Byte 0x00 dargestellt.
BER Kodierung von INTEGER
• Ein INTEGER Wert wird einfach als binäre Zahl kodiert, wobei negative Werte durch das Zweierkomplement dargestellt werden.
• Bei abgeleiteten vorzeichenlosen Typen ist also darauf zu achten, daß unter Umständen ein führendes
0x00 Byte erforderlich sein kann.
BER Kodierung von BIT STRING
8 7 6 5 4 3 2 1
8 7 6 5 4 3 2 1
b0 b1 b2 b3 b4 b5 b6 b7
8 7 6 5 4 3 2 1
...
bits
unused bits in last byte
Abbildung 5.7: BER Kodierung von BIT STRING Werten
• Ein BIT STRING Wert wird durch eine Folge von Bytes kodiert, die die Bits enthalten. Vorangestellt
wird ein Byte, das die im letzten Byte der Folge unbenutzten Bits beschreibt.
BER Kodierung von OCTET STRING
• Ein OCTET STRING Wert wird einfach durch die Folge von Octets (Bytes) kodiert.
BER Kodierung von NULL
• Der NULL Wert wird immer durch 0 Bytes kodiert.
BER Kodierung von OBJECT IDENTIFIER
8 7 6 5 4 3 2 1
0
sub−identifier (< 128)
8 7 6 5 4 3 2 1
1
...
8 7 6 5 4 3 2 1
8 7 6 5 4 3 2 1
1
0
sub−identifier (> 127)
Abbildung 5.8: BER Kodierung von OBJECT IDENTIFIER Werten
• Ein OBJECT IDENTIFIER Wert wird durch eine Folge von sub-identifiern kodiert.
103
5.2. ABSTRACT SYNTAX NOTATION ONE (ASN.1)
• Die ersten beiden Komponenten X und Y eines OBJECT IDENTIFIER Werts werden gemäß (X ·
40) + Y zu einem sub-identifier zusammengefaßt. (Dies ist möglich, da X nur die Werte 0, 1
und 2 annehmen kann.)
BER Kodierung von SEQUENCE / SEQUENCE OF / SET / SET OF
• Zusammengesetzte Werte werden einfach durch die Kodierung der einzelnen Elemente dargestellt.
BER Kodierung von CHOICE
• Bei CHOICE-Konstrukten wird lediglich der tatsächlich vorhandene Wert kodiert, der daher mit einem
Tag eindeutig identifizierbar sein muß.
Beispiel
Das folgende Beispiel zeigt die BER-Kodierung einer SNMPv1 Nachricht.
Bytes
Tag
30:1b
SEQUENCE {
02:01:00
INTEGER
04:06:70:75:62:6C:69:63
OCTET STRING
a1:0e
GetNextRequest-PDU {
02:04:36:a2:8f:07
INTEGER
02:01:00
INTEGER
02:01:00
INTEGER
30:00
SEQUENCE OF {}
}
}
Length Value
27
1
6
14
4
1
1
0
0
"public"
916623111
0
0
Bemerkungen
• Offensichtlich muß die Länge der BER-Kodierung eines Wertes bekannt sein, bevor man das Längenfeld kodieren kann.
• Eine effiziente Kodierung erhält man daher, indem man die Nachrichten “von innen nach außen”
kodiert und den Puffer “von hinten nach vorne” füllt.
• Offensichtlich ist ein nachträgliches Ändern von Werten problematisch, wenn durch die Änderungen
plötzlich größere Längenfelder erforderlich werden.
104
KAPITEL 5. INTERNET ANWENDUNGSSCHICHT
5.3 Simple Network Mangement Protocol (SNMP)
Das Simple Network Management Protocol (SNMP) wurde Ende der 80er Jahre entwickelt, um den Betrieb
des Internets durch den standardisierten Zugriff auf möglichst standardisierte Managementinformationen zu
vereinfachen.
5.3.1
Grundlagen
Zunächst ein paar generelle Grundlagen, die noch nicht SNMP spezifisch sind und eine allgemein akzeptierte
Terminologie definieren.
Funktionsbereiche
Die Dienste, die von einem Managementsystem erbracht werden, lassen sich in fünf Funktionsbereiche einteilen (FCAPS):
1. Fehlermanagement (fault management)
Umfaßt die Fehlererkennung, die Fehlerisolation und die Fehlerbehebung.
2. Konfigurationsmanagement (configuration management)
Umfaßt die Erzeugung und Verwaltung von Konfigurationsinformationen, die Namensverwaltung sowie Start, Kontrolle und Beendigung von Diensten.
3. Abrechnungsmanagement (account management)
Umfaßt die Erfassung von Verbrauchsdaten, die Verteilung und Überwachung von Kontingenten sowie
das Führen von Verbrauchsstatistiken.
4. Leistungsmanagement (performance management)
Umfaßt das Sammeln von statistischen Daten, die Ermittlung der Systemleistung und etwaige Veränderungen zur Leistungsoptimierung
5. Sicherheitsmanagement (security management)
Umfaßt die Erzeugung und Kontrolle von Sicherheitsdiensten, die Schlüsselgenerierung und -verteilung
und die Meldung und Analyse von sicherheitsrelevanten Ereignissen.
Managed Object (MO)
Warning: Coffee machine
switched on but no coffee
in the machine.
Management Application
Attributes
Operations
Behaviour
Events
Managed Object
Resource
Abbildung 5.9: Managed Objects (MOs)
• Die Managementinformationen werden analog zur ISO-Terminologie durch Managed Objects (MOs)
realisiert.
• Ein Managed Object ist eine abtrakte Sicht auf ein Betriebsmittel die die Eigenschaften des Betriebsmittels für die Zwecke des Managements darstellt.
105
5.3. SIMPLE NETWORK MANGEMENT PROTOCOL (SNMP)
• Die Grenze (boundary) eines MOs definiert den Grad an Details, die einem Managementsystem
zugänglich sind.
• Die Attribute (attributes) eines MOs beschreiben den typischerweise den aktuellen Zustand bzw. die
Konfiguration eines Betriebsmittels. Attribute können gezielt durch Management-Operationen manipuliert werden.
• Die Operationen (operations) ermöglichen den Zugriff auf ein MO. Typische Operationen sind lesen (get), schreiben (set), erzeugen (create) und löschen (delete). SNMP unterstützt nur get und set
explizit.
• Das Verhalten (behaviour) bestimmt die Semantik eines MOs und die Interaktion mit dem realen
Betriebsmittel. Das Verhalten wird normalerweise verbal definiert.
• Ein MO kann selbständig asynchrone Meldungen (notifications) generieren, wenn bestimmte Ereignisse eintreten.
Management Information Base (MIB)
MO
MO
MO
Layer 7
MO
Layer 6
MO
MO
MO
Layer 5
MO
Layer 4
MO
MO
MO
Layer 3
Layer 2
Management Information Base
Layer 1
Protocols
Resources
Abbildung 5.10: Management Information Base (MIB)
• Mehrere MOs werden zu sogenannten Management Information Bases zusammengefaßt.
• Achtung: Es gibt zwei verschiedenen Interpretation des Begriffs MIB:
1. Die Zusammenfassung aller MOs auf einem Gerät.
2. Die Zusammenfassung logisch zusammengehörender Definitionen von MOs.
Zur Unterscheidung spricht man im zweiten Fall in der Regel von sogenannten MIB Modulen, da
logisch zusammengehörende MO Definitionen typischerweise in einem oder wenigen Modulen einer
Datendefinitionssprache festgeschrieben werden.
106
KAPITEL 5. INTERNET ANWENDUNGSSCHICHT
Manager, Agenten und Managementprotokolle
Algorithm for solving
a management problem
MIB−Model of
a resource
Management Protocol
Management Protocol
Manager (Client)
Agent (Server)
Abbildung 5.11: Manager, Agenten und Managementprotokolle
1. Ein Managementprotokoll realisert den Zugriff auf entfernte MOs.
2. Ein Agent (agent) nimmt Anfragen von Managern entgegen, bearbeitet sie und sendet entsprechende
Antworten.
3. Ein Agent versendet unaufgefordert Nachrichten bei entsprechenden Ereignissen (in der Regel Zustandsänderungen in der MIB).
4. Ein Agent realisiert die MOs seiner MIB durch Zugriffe auf die realen Betriebsmittel. Die MOs sind
keine Datenbank sondern existieren meist nur virtuell.
5. Ein Agent sollte die MOs vor unberechtigten Zugriffen durch die Anwendung von Zugriffskontrollregeln und die Authentifizierung der Manager schützen.
6. Ein Manager (manager) übt Kontroll- und Steuerungsfunktionen aus und ist die entscheidende Instanz.
7. Ein Manager initiiert Management-Operationen durch entsprechende Protokoll-Operationen zur Manipulation von MOs. Eine Management-Operationen kann eine komplexe Folge von Protokoll-Operationen
beinhalten.
8. Ein Manager nimmt Meldungen von Agenten entgegen und leitet sie zur weiteren Bearbeitung an
entsprechende Applikationen weiter.
Entwurfsziele von SNMP
Entwurfsziele bei der Entwicklung von SNMP [50]. Man darf natürlich Fragen, inwieweit diese Ziele auch
heute noch relevant sind.
• Minimierung der Anzahl und der Komplexität der Managemenfunktionen innerhalb der Agenten. Dadurch sollen folgende Teilziele erreicht werden:
– Reduktion der Entwicklungskosten auf der Seite des Agenten
– Instrumentierung von beliebigen Geräten (HUBs und CRAYs)
– Entwicklung von verbesserten Managementfunktionen im Laufe der Zeit ohne ständige Änderungen der Agenten
5.3. SIMPLE NETWORK MANGEMENT PROTOCOL (SNMP)
107
• Erweiterbarkeit durch die Definition neuer MIB Module.
• Unabhängigkeit von existierenden Rechner- oder Routerarchitekturen.
• Robustheit (auch im Fall von Fehlern im Netz)
• Unabhängigkeit von anderen Netzdiensten (z.B. Verzeichnissen)
5.3.2
Structure of Management Information (SMIv2)
Die Definition von MOs in der SNMP-Welt geschieht durch eine eigene Datendefinitionssprache mit dem Namen Structure of Management Information (SMI). Die aktuelle Version dieser Sprache ist Version 2 (SMIv2)
[51, 52, 53]. (An einem Nachfolger wird derzeit in der IETF gearbeitet.)
Grundlegende SMIv2 Konzepte
Die Datendefinitionssprache SMIv2 basiert auf einer adaptierten Teilmenge von ASN.1 (1988). Im Klartext
bedeutet dies, daß man eine noch nicht offizielle Version von ASN.1 genommen hat, davon eine Teilmenge
benutzt, die man anschließend noch modifiziert hat.
Das der SMIv2 zugrundeliegende Modell ist sehr einfach (und vielleicht zu einfach):
• Managementinformationen werden in einfachen typisierten Variablen gehalten (keine zusammengesetzten Datentypen).
• Alle SMIv2 Datentypen lösen sich letztlich zu den drei primitiven ASN.1 Datentypen INTEGER,
OCTET STRING und OBJECT IDENTIFIER auf.
• Variablen treten entweder als Skalare auf (genau eine Instanz) oder als Spalten einer konzeptuellen
Tabelle (null oder mehrere Instanzen).
• Variablen können mit Hilfe von SNMP gelesen und geschrieben werden. Das Protokoll erlaubt in der
Tat die Manipulation beliebiger Listen von Variablen in einer atomaren Transaktion, wobei durch das
jeweilige Transportprotokoll die Listen letztlich doch begrenzt sind.
Neben den Basisdatentypen gibt es eine Reihe abgeleiteter Datentypen mit speziellen Semantiken. Die folgende Tabelle gibt einen Überblick:
SMIv2 Type
INTEGER
OCTET STRING
OBJECT IDENTIFIER
Integer32
Unsigned32
Gauge32
Counter32
Counter64
TimeTicks
IpAddress
Opaque
BITS
—
SMIv1 Type
INTEGER
OCTET STRING
OBJECT IDENTIFIER
INTEGER
—
Gauge
Counter
—
TimeTicks
IpAddress
Opaque
—
NetworkAddress
Description
enumerations (signed integer)
sequence of arbitrary bytes
unique identifier
signed integer (-2147483648..2147483647)
unsigned integer (0..4294967295)
gauge (0..4294967295)
counter (0..4294967295)
counter (0..18446744073709551615)
elapsed time in hundredths of a second
four byte IP version 4 address
wrapper for arbitrary ASN.1 types
labeled bits
union of network address types
108
KAPITEL 5. INTERNET ANWENDUNGSSCHICHT
Namensraum und Instanzidentifikation (Naming)
Die einzelnen Instanzen der Variablen müssen eindeutig identifiziert werden können. Dazu muß ein geeigneter Namensraum existieren. In klassischen imperativen Programmiersprachen werden Variablen letztlich
durch Speicheradressen eindeutig identifiziert. Im Fall der SMI benutzt man als Namensraum den ISORegistrationsbaum und daher OBJECT IDENTIFIER zur Identifikation.
Das folgende Beispiel zeigt einen sehr simplen Agenten, der für einen Router agiert der einen Namen hat
(name), eine Laufzeit (uptime) und der Agent hat eine Adresse (address).
name
Manager
uptime
Manager
Agent
(HP/OV)
Router
MIB
address
Abbildung 5.12: Beispiel für einen sehr trivialen Router
Die drei skalaren Variablen könnten beispielsweise folgendermaßen im ISO-Registrationsbaum registriert
worden sein:
(1)
address (1)
info (2)
name (1)
uptime (2)
Abbildung 5.13: Registrationsbaum für einen sehr trivialen Router
• Durch die Registration eines Variablentyps (object type) wird dem Variablentyp ein global eindeutiger Name (OID) zugewiesen.
• Konkrete Instanzen des Variablentyps werden zusätzlich durch eine Instanzidentifikation (instance
identifier) voneinander unterschieden. Die Instanzidentifikation wird als OID-Fragment kodiert und
an den OID angehängt.
• Skalare Variablen haben per Definition immer die Instanzidentifikation 0. Die Instanzidentifikation
von Variablen (Zellen) einer konzeptionellen Tabelle wird aus den Schlüsselwerten einer konzeptionellen Zeile der Tabelle gebildet.
Für den Registrationsbaum aus dem obigen Beispiel ergibt sich somit:
Object Identifier
1.1
1.2.1
1.2.2
Instance Identifier
0
0
0
Type
IpAddress
OCTET STRING
TimeTicks
Value
10.1.2.1
“ACME Router”
54321
Der SNMP Agent in dem Beispiel soll nun so erweitert werden, daß auch Informationen über die Weiterleitungstabelle (forwarding table) des Routers geliefert wird.
109
5.3. SIMPLE NETWORK MANGEMENT PROTOCOL (SNMP)
(1)
address (1)
info (2)
name (1)
fwdTable (3)
uptime (2)
fwdEntry (1)
fwdIndex (1)
2
1
7
5
3
9
8
fwdDest (2)
fwdNext (3)
1
2
2
2
3
3
3
5
2
4
7
2
5
8
3
6
9
3
Abbildung 5.14: Erweiterter Registrationsbaum für einen sehr trivialen Router
Die Weiterleitungstabelle (fwdTable) besteht aus drei Spalten (fwdIndex, fwdDest, fwdNext), wobei die Spalte fwdIndex Schlüsseleigenschaft besitzt. Die abgebildete Ausprägung der Tabelle stellt die
Weiterleitungsinformation für das angegebene Netz aus Sicht des Knoten mit der Nummer 1 dar.
• Konzeptionelle Tabellen werden immer mit zwei Hilfsknoten registiert:
– Der erste Knoten (fwdTable) repräsentiert die konzeptionelle Tabelle und ist syntaktisch
vom ASN.1 Typ SEQUENCE OF. Der Name dieses Knotens endet per Konvention immer mit
Table.
– Der Knoten unter dem ersten Knoten (fwdEntry) repräsentiert eine konzeptionelle Tabelle und
ist syntaktisch vom ASN.1 Typ SEQUENCE. Der Name dieses Knotens endet per Konvention
immer mit Entry.
– Die Knoten unter dem zweiten Knoten repräsentieren die konzeptionellen Spalten der Tabelle.
• Der primäre Schlüssel der Tabelle (die Menge der Spalten, die zusammen einen Zeile eindeutig identifizieren), werden als Index bezeichnet und zur Konstruktion der Instanzidentifikation benutzt.
Im Beispiel kann der Wert des Schlüsselelements einfach als Komponente an den OID einer Spalte angehängt
werden. Damit identifiziert der Wert 1.3.1.2.4 die Zelle in der zweiten Spalte und der vierten Zeile mit dem
Wert 7.
Etwas aufwendiger wird das Verfahren, wenn die Datentypen nicht trivial als Komponente an einen OID
angehängt werden können. In dem Fall sind gegebenenfalls Umwandlungen notwendig. Dazu existieren die
folgenden Regeln:
1. Wenn ein Index-Element vom Typ INTEGER ist, dann wird der Wert als Komponente an den OID
angehängt. (Das funktioniert natürlich nur, wenn keine negativen Zahlen vorkommen.)
2. Wenn ein Index-Element vom Typ OCTET STRING ist und die Bytefolge eine feste Länge besitzt,
dann wird jedes Byte des OCTET STRING Werts als einzelne Komponente an den OID angehängt.
3. Wenn ein Index-Element vom Typ OCTET STRING ist und die Bytefolge eine variable Länge besitzt,
dann wird zunächst eine Komponenten mit dem Längenbyte an den OID angehängt und anschließend
werden die Bytes des OCTET STRING Werts als einzelne Komponenten an den OID angehängt.
4. Wenn ein Index-Element vom Type OBJECT IDENTIFIER ist, dann wird zunächst eine Komponenten mit der Länge des Werts angehängt gefolgt von den Komponenten des Werts.
110
KAPITEL 5. INTERNET ANWENDUNGSSCHICHT
In einigen Fällen kann durch Benutzung eines speziellen Schlüsselwortes (IMPLIED) das Längenbyte unterdrückt werden, was sich aber nachträglich nicht als eine gute Idee herausgestellt hat. Wichtig ist, daß OIDs
nach den SMIv2 Regeln auf 128 Komponenten begrenzt sind, weshalb Tabellen nicht beliebig komplex indiziert werden können.
Erweitert man das Beispiel auf richtige IPv4 Adressen und benutzt man als Schlüssel (Index) das Paar
(fwdDest, fwdMask), so ergibt sich folgende Situation:
(1)
address (1)
info (2)
name (1)
fwdTable (3)
uptime (2)
fwdEntry (1)
fwdDest (1)
fwdMask (2)
fwdNext (3)
134.169.34.1
0.0.0.0
255.255.255.0
127.0.0.1
255.0.0.0
127.0.0.1
134.169.34.0
255.255.255.0
134.169.34.15
134.169.35.1
255.255.255.0
134.169.34.18
134.169.35.2
255.255.255.0
134.169.34.18
Abbildung 5.15: Registrationsbaum für einen trivialen IPv4 Router
Die Zelle für den nächsten Router auf dem Weg zum Netz 134.169.34/24 (mit dem Wert 134.169.34.15) hat
nun den OID Namen 1.3.1.3.134.169.34.0.255.255.255.0.
SMIv2 Module und Makros
SMIv2 Module werden durch einen Namen identifiziert. In den Modulen können zunächst Definitionen von
anderen Modulen importiert werden. Die eigentliche Definition von Skalaren, konzeptionellen Tabellen etc.
erfolgt durch die Anwendung von ASN.1 Makros (die in aktuellen Versionen von ASN.1 durch andere Mechanismen ersetzt worden sind).
Das MODULE-IDENTITY Makro wird benutzt, um Verwaltungsinformationen für SMIv2 Module zu definieren:
<Descriptor> MODULE-IDENTITY
LAST-UPDATED <ExtUTCTime>
ORGANIZATION <Text>
CONTACT-INFO <Text>
DESCRIPTION
<Text>
[ REVISION
<ExtUTCTime>
DESCRIPTION
<Text>
]∗
::= <ObjectIdentifier>
Das OBJECT-IDENTITY Makro wird benutzt, um eine Konstante mit einem festen OID zu registrieren:
<Descriptor> OBJECT-IDENTITY
STATUS
<Status>
DESCRIPTION
<Text>
5.3. SIMPLE NETWORK MANGEMENT PROTOCOL (SNMP)
[ REFERENCE
<Text>
::= <ObjectIdentifier>
111
]
Das OBJECT-TYPE Makro dient zur Definition von Skalaren, konzeptionellen Spalten, Zeilen und Tabellen:
<Descriptor> OBJECT-TYPE
SYNTAX
<Syntax>
[ UNITS
<Text>
MAX-ACCESS
<Access>
STATUS
<Status>
DESCRIPTION
<Text>
[ REFERENCE
<Text>
[ INDEX
<Index>
[ AUGMENTS
<Index>
[ DEFVAL
<Value>
::= <ObjectIdentifier>
]
]
]
]
]
Das NOTIFICATION-TYPE Makro dient zur Definition von Benachrichtungen, die asynchron vom Agenten verschickt werden können:
<Descriptor> NOTATION-TYPE
[ OBJECTS
<Objects> ]
STATUS
<Status>
DESCRIPTION
<Text>
[ REFERENCE
<Text>
]
::= <ObjectIdentifier>
Mit Hilfe des TEXTUAL-CONVENTION Makros können eingeschränkt abgeleitete Typen definiert werden:
<TypeDescriptor> ::= TEXTUAL-CONVENTION
[ DISPLAY-HINT <Text>
]
STATUS
<Status>
DESCRIPTION
<Text>
[ REFERENCE
<Text>
]
SYNTAX
<Syntax>
Weitere Makros erlauben die formale Beschreibung von Implementierungsanforderungen (conformance statements). Für die Details diesbezüglich sei an dieser Stelle auf den RFC 2580 [53] verwiesen.
5.3.3
Grundlegende MIB Module
Die IF-MIB [54] ist das wohl grundlegendste MIB Modul. Es definiert das Konzept einer Netzwerkschnittstelle (interface), wobei Schnittstellen übereinander gestapelt werden können. Die folgende Abbildung zeigt
das zugrundeliegende Modell in einem adaptierten UML-Diagramm [55]:
112
KAPITEL 5. INTERNET ANWENDUNGSSCHICHT
«smi mib class»
ifStackEntry
+ifStackLastChange: TimeTicks
-ifStackHigherLayer: InterfaceIndexOrZero {index}
-ifStackLowerLayer: InterfaceIndexOrZero {index}
+ifStackStatus: RowStatus
1
is stacked on
reorders
1
«smi mib class»
lower layer
0..1
«smi mib class»
ifInvStackEntry
higher layer
0..1
ifEntry
+ifNumber: Integer32
+ifLastChange: TimeTicks
+ifIndex: InterfaceIndex {index}
+ifDescr: DisplayString
+ifType: IANAifType
+ifMtu: Integer32
+ifSpeed: Gauge32
+ifPhysAddress: PhysAddress
+ifAdminStatus: Enumeration
+ifOperStatus: Enumeration
+ifLastChange: TimeTicks
+ifInOctets: Counter32
+ifInUcastPkts: Counter32
+ifInDiscards: Counter32
+ifInErrors: Counter32
+ifInUnknownProtos: Counter32
+ifOutOctets: Counter32
+ifOutUcastPkts: Counter32
+ifOutDiscards: Counter32
+ifOutErrors: Counter32
-linkDown(ifIndex,ifAdminStatus,ifOperStatus)
-linkUp(ifIndex,ifAdminStatus,ifOperStatus)
1
expands
-ifStackLowerLayer: InterfaceIndexOrZero {index}
-ifStackHigherLayer: InterfaceIndexOrZero {index}
+ifInvStackStatus: RowStatus
augments
«smi mib class»
ifXEntry
-ifIndex: InterfaceIndex {index}
+ifName: DisplayString
+ifInMulticastPkts: Counter32
+ifInBroadcastPkts: Counter32
+ifOutMulticastPkts: Counter32
+ifOutBroadcastPkts: Counter32
+ifHCInOctets: Counter64
+ifHCInUcastPkts: Counter64
+ifHCInMulticastPkts: Counter64
+ifHCInBroadcastPkts: Counter64
+ifHCOutOctets: Counter64
+ifHCOutUcastPkts: Counter64
+ifHCOutMulticastPkts: Counter64
+ifHCOutBroadcastPkts: Counter64
+ifLinkUpDownTrapEnable: Enumeration
+ifHighSpeed: Gauge32
+ifPromiscuousMode: TruthValue
+ifConnectorPresent: TruthValue
+ifAlias: DisplayString
+ifCounterDiscontinuityTime: TimeStamp
0..*
«smi mib class»
ifRcvAddressEntry
-ifIndex: InterfaceIndex {index}
-ifRcvAddressAddress: PhysAddress {index}
+ifRcvAddressStatus: RowStatus
+ifRcvAddressType: Enumeration
Abbildung 5.16: Konzeptionelles Modell der IF-MIB
Die IF-MIB ist auf fast allen Geräten im Internet implementiert und liefert Kernstatistiken über die empfangenen und gesendeten Pakete und Bytes.
Die ENTITY-MIB [56] beschreibt die physikalischen Komponenten eines Systems und welche Komponenten in anderen enthalten sind.
«smi mib class»
entLogicalEntry
-entLogicalIndex: Integer32 {index}
+entLogicalDescr: SnmpAdminString
+entLogicalType: AutonomousType
+entLogicalCommunity: OctetString
+entLogicalTAddress: TAddress
+entLogicalTDomain: TDomain
+entLogicalContextEngineID: SnmpEngineIdOrNone
+entLogicalContextName: SnmpAdminString
0..n
«smi mib class»
entLPMappingEntry
-entLogicalIndex: Integer32 {index}
+entLPPhysicalIndex: PhysicalIndex {index}
accessible via
«smi mib 0..n
class»
expands
entPhysicalEntry
«smi mib class»
entAliasMappingEntry
-entPhysicalIndex: PhysicalIndex {index}
+entPhysicalDescr: SnmpAdminString
+entPhysicalVendorType: AutonomousType
+entPhysicalContainedIn: Integer32
+entPhysicalClass: PhysicalClass
+entPhysicalParentRelPos: Integer32
+entPhysicalName: SnmpAdminString
+entPhysicalHardwareRev: SnmpAdminString
+entPhysicalFirmwareRev: SnmpAdminString
+entPhysicalSoftwareRev: SnmpAdminString
+entPhysicalSerialNum: SnmpAdminString
+entPhysicalMfgName: SnmpAdminString
+entPhysicalModelName: SnmpAdminString
+entPhysicalAlias: SnmpAdminString
+entPhysicalAssetID: SnmpAdminString
+entPhysicalIsFRU: TruthValue
container
1
-entPhysicalIndex: PhysicalIndex {index}
-entAliasLogicalIndexOrZero: Integer32 {index}
+entAliasMappingIdentifier: RowPointer
«smi mib class»
entityGeneral
+entLastChangeTime: TimeStamp
element
0..n
«smi mib class»
entPhysicalContainsEntry
-entPhysicalIndex: PhysicalIndex {index}
+entPhysicalChildIndex: PhysicalIndex {index}
is contained in
Abbildung 5.17: Konzeptionelles Modell der ENTITY-MIB
Die ENTITY-MIB ist noch nicht so alt wie die IF-MIB, entwickelt sich aber langsam zu einem weiteren
113
5.3. SIMPLE NETWORK MANGEMENT PROTOCOL (SNMP)
wichtigen Kernmodul. Es sind bereits Erweiterungen in Arbeit, die allgemein Sensoren beschreiben, die aus
betrieblicher Sicht ebenfalls elementare Komponenten sind (z.B. Temperatursensoren).
Die HOST-RESROUCES-MIB [57] beschreibt die grundlegenden Komponenten eines Rechensystems.
«smi mib class»
«smi mib class»
hrSystem
hrSWInstalledEntry
+hrSystemUptime: TimeTicks
+hrSystemDate: DateAndTime
+hrSystemInitialLoadDevice: Integer32
+hrSystemInitialLoadParameters: InternationalDisplayString
+hrSystemNumUsers: Gauge32
+hrSystemProcesses: Gauge32
+hrSystemMaxProcesses: Integer32
+hrMemorySize: KBytes
+hrSWInstalledLastChange: TimeTicks
+hrSWInstalledLastUpdateTime: TimeTicks
+hrSWInstalledIndex: Integer32 {index}
+hrSWInstalledName: InternationalDisplayString
+hrSWInstalledID: ProductID
+hrSWInstalledType: Enumeration
+hrSWInstalledDate: DateAndTime
«smi mib class»
«smi mib class»
hrSWRunEntry
hrSWRunPerfEntry
augments
+hrSWOSIndex: Integer32
+hrSWRunIndex: Integer32 {index}
+hrSWRunName: InternationalDisplayString
+hrSWRunID: ProductID
+hrSWRunPath: InternationalDisplayString
+hrSWRunParameters: InternationalDisplayString
+hrSWRunType: Enumeration
+hrSWRunStatus: Enumeration
+hrSWRunIndex: Integer32 {index}
+hrSWRunPerfCPU: Integer32
+hrSWRunPerfMem: KBytes
«smi mib class»
extends
hrProcessorEntry
+hrDeviceIndex: Integer32 {index}
+hrProcessorFrwID: ProductID
+hrProcessorLoad: Integer32
«smi mib class»
hrDeviceEntry
extends
+hrDeviceIndex: Integer32 {index}
+hrDeviceType: AutonomousType
+hrDeviceDescr: DisplayString
+hrDeviceID: ProductID
+hrDeviceStatus: Enumeration
+hrDeviceErrors: Counter32
«smi mib class»
hrNetworkEntry
0..1
+hrDeviceIndex: Integer32 {index}
+hrNetworkIfIndex: InterfaceIndexOrZero
implements
0..1
«smi mib class»
IF-MIB::ifEntry
1
extends
«smi mib class»
hrPrinterEntry
+hrDeviceIndex: Integer32 {index}
+hrPrinterStatus: Enumeration
+hrPrinterDetectedErrorState: OctetString
exists on
extends
0..*
«smi mib class»
hrPartitionEntry
«smi mib class»
hrDiskStorageEntry
+hrDeviceIndex: Integer32 {index}
+hrPartitionIndex: Integer32 {index}
+hrPartitionLabel: InternationalDisplayString
+hrPartitionID: OctetString
+hrPartitionSize: KBytes
+hrPartitionFSIndex: Integer32
+hrDeviceIndex: Integer32 {index}
+hrDiskStorageAccess: Enumeration
+hrDiskStorageMedia: Enumeration
+hrDiskStorageRemoveble: TruthValue
+hrDiskStorageCapacity: KBytes
0..*
0..1
«smi mib class»
hrFSEntry
+hrFSIndex: Integer32 {index}
+hrFSMountPoint: InternationalDisplayString
+hrFSRemoteMountPoint: InternationalDisplayString
+hrFSType: AutonomousType
+hrFSAccess: Enumeration
+hrFSBootable: TruthValue
+hrFSStorageIndex: Integer32
+hrFSLastFullBackupDate: DateAndTime
+hrFSLastPartialBackupDate: DateAndTime
resides on
«smi mib class»
0..1
hrStorageEntry
0..*
+hrStorageIndex: Integer32 {index}
+hrStorageType: AutonomousType
+hrStorageDescr: DisplayString
+hrStorageAllocationUnits: Integer32
+hrStorageSize: Integer32
+hrStorageUsed: Integer32
+hrStorageAllocationFailures: Counter32
Abbildung 5.18: Konzeptionelles Modell der HOST-RESROUCES-MIB
Auch die HOST-RESROUCES-MIB hat sich im Lauf der Jahre relativ weit etabliert und es finden sich in
neueren MIBs zunehmend Verweise auf Elemente der HOST-RESROUCES-MIB. Ein Rechensystem besteht
in der HOST-RESROUCES-MIB aus einer Menge von Komponenten (devices), wobei es für verschiedene
häufig vorkommende Komponententypen Verfeinerungen (z.B. Prozessoren, Speicher, Netzwerkschnittstellen) gibt. Man erkennt also deutlich eine objekt-orientierte Modellierung, auch wenn die Datendefinition in
RFC 2790 [57] davon nicht viel direkt erkennen läßt.
5.3.4
Protokollarchitektur
Die dritte Version des Simple Network Management Protocols (SNMPv3) ist aus Sicht der Protokollentwickler die aktuelle Version von SNMP [58]. Ziele bei der Entwicklung von SNMPv3 waren:
• Sicherheit (Authentifikation und Verschlüsselung)
• Definition einer stabilen Architektur, die langfristig bei der Weiterentwicklung von SNMP hilft.
• Unterstützung von minimalen konformen Implementationen in Systemen mit begrenzten Betriebsmitteln.
• Unterstützung von komplexeren konformen Implementationen in leistungsstärkeren Systemen.
• Modularität und verschiedene Geschwindigkeiten bei der Standardisierung der einzelnen Module
114
KAPITEL 5. INTERNET ANWENDUNGSSCHICHT
• Wiederverwendung von möglichst viel existierendem Material.
• SNMP soll so einfach wie möglich sein. (KISS = keep it simple and stupid)
Architekturmodell
Bei der Entwicklung von SNMPv3 konnten viele Teilprobleme erst befriedigend gelöst werden, nachdem
man sich auf ein Architekturmodell für SNMP verständigt hatte. Ziel war die Modularisierung und die Definition von abstrakten Schnittstellen zwischen den einzelnen Komponenten und Teilsystemen.
Traditional Agent
MIB Instrumentation
Traditional Manager
Access Control Subsystem
Command
Notification
Notification
Command
View-based
Notification
Proxy
Generator
Receiver
Originator
Responder
Access Control
Originator
Forwarder
Message Processing
PDU
Security Subsystem
Message Processing
Subsystem
PDU
Dispatcher
Dispatcher
v1MP
Community
v1MP
Security Model
Dispatcher
v2cMP
User-based
Message
Security Model
Dispatcher
v3MP
User-based
Security Model
v3MP
Other
Transport
other MP
Community
Security Model
v2cMP
Message
Other
Security Model
Transport
Mappings
UDP
Security Subsystem
Subsystem
other MP
Security Model
Mappings
IPX
UDP
IPX
Communication Network
Abbildung 5.19: Manager und Agent im SNMPv3 Architekturmodell
• Ein Teilsystem (subsystem) kann mehrere verschiedenen Komponenten (models) mit derselben Schnittstelle beinhalten.
• Trennung der eigentlichen Protokollfunktionalität (Nachrichtenbearbeitung, Sicherheit und Zugriffskontrolle) von der Schnittstelle zu Applikationen, die Protokolloperationen aufrufen oder ausführen.
• Der dispatcher ist eine zentrale Komponente, der den Ablauf zwischen den verschiedenen Komponenten einer Protokollimplementation steuert.
• Neben dem traditionellen Manager und dem traditionellen Agenten sind auch andere Konfigurationen
vorstellbar.
Kontext (context)
• Ein Kontext (context) ist eine Menge von Variablen, die über eine SNMP Entität zugreifbar sind.
Eine SNMP Entität hat potentiell Zugriff zu mehreren Kontexten und eine bestimmte Variable kann in
mehreren Kontexten existieren.
• Innerhalt einer Domäne wird eine Variable durch ein 4-Tupel (e, c, t, i) eindeutig identifiziert, wobei e
eine Protokollmaschine identifiziert, c einen Kontext innerhalb der Protokollmaschine, t den Typ einer
Variablen und i die Instanz einer Variablen.
• Ein Beispiel wäre (engine4, ”board1”, ÏF-MIB::ifDescr”, 3).
115
5.3. SIMPLE NETWORK MANGEMENT PROTOCOL (SNMP)
Lexikographische Ordnung (lexicographic order)
• Geben seien zwei Vektoren von natürlichen Zahlen x = (x1 , . . . , xn ) und y = (y1 , . . . , ym ) mit n ≤
m. Der Vektor x ist lexikographisch kleiner als y genau dann wenn eine der folgenden Bedingungen
wahr ist:
(a) xj = yj für 1 ≤ j ≤ k und xk < yk mit k ≤ n and k ≤ m
(b) xj = yj für 1 ≤ j ≤ n und n < m
• Alle OIDs, die instantiierte Variablen identifizieren, können lexikographisch geordnet werden.
• Durch die lexikographische Ordnung werden bei einer konzeptionellen Tabelle zunächst die Variablen
einer ganzen Spalte hintereinander angeordenet bevor die Variablen der nächsten Spalte kommen.
• Das Protokoll operiert nur auf dieser lexikographisch geordneten Liste von Variablen und nicht etwa
auf dem Baumstruktur oder den konzeptionellen Tabellen.
Protokolloperationen
SNMPv3 stellt Applikationen insgesamt sechs Protokolloperationen zur Verfügung [59]. Es existiert eine
weitere Operation (Report), die aber nur intern zur Fehlerbenachrichtigung oder zur Uhrensynchronisation
zwischen Protokollmaschinen benutzt wird.
command
generator
command
responder
Get
command
generator
command
responder
notification
originator
notification
receiver
GetNext
Trap
Response
command
generator
command
responder
Set
Response
command
generator
command
responder
GetBulk
Response
notification
originator
notification
receiver
Inform
Response
Response
Abbildung 5.20: SNMPv3 Protokolloperationen
• Die Get-Operation wird benutzt, um Werte von Variablen zu lesen. Es können die Fehler tooBig
und genErr auftreten. Der Zugriff auf nicht lesbare Variablen führt zu Ausnahmen (exceptions) für
die betroffenen Variablen (noSuchObject, noSuchInstance, endOfMibView).
• Die Set-Operation wird benutzt, um Werte von Variablen zu ändern. Es können die Fehler wrongValue,
wrongEncoding, wrongType, wrongLength, inconsistentValue, noAccess, notWritable,
noCreation, inconsistentName, resourceUnavailable, commitFailed und undoFailed
auftreten. Die Set-Operation ist atomar (bis auf den undoFailed-Fehler). Es gibt keine Möglichkeit, kontextabhängige Fehlermeldungen zu liefern.
• Die GetNext-Operation wird benutzt, um die Werte der direkt nachfolgenden Variablen in lexikographischer Ordnung zu lesen. Es können die Fehler tooBig und genErr auftreten. Der Zugriff
auf das Ende der lesbaren Variablen führt zu einer endOfMibView Ausnahme. Durch wiederholte
Anwendung der GetNext-Operation können ganze Teile einer MIB gelesen werden, ohne die MIB
Struktur oder die Namen der Instanzen zu kennen.
116
KAPITEL 5. INTERNET ANWENDUNGSSCHICHT
• Die GetBulk-Operation ist eine Verallgemeinerung der GetNext-Operation, bei der konzeptionell
lokal mehrere GetNext-Operationen durchgeführt werden.
– Die ersten N Elemente (non-repeaters) der Variablenlisten werden wie bei einer GetNextOperation behandelt.
– Für die übrigen R Elemente der Variablenlisten werden wiederholt lokal konzeptionell GetNextOperationen ausgeführt und in der Antwortnachricht gesammelt.
– Der Parameter M (max-repetitions) definiert eine obere Grenze für die Anzahl der Wiederholungen.
Die GetBulk-Operation operiert wie alle anderen Operationen lediglich auf einer lexikographisch
geordneten Liste von Variablen und respektiert daher auch nicht Grenzen von konzeptionellen Tabellen.
• Die Trap-Operation wird benutzt, um Benachrichtigungen über das Eintreten von Ereignissen zu
versenden. Der Typ des Ereignisses sowie die notwendigen Informationen zu dem Ereignis werden in
der Variablenliste abgelegt. Die Trap-Operation ist nicht bestätigt und somit kann der Sender nicht
entscheiden, ob die Benachrichtigung angekommen ist oder nicht. Zu beachten ist auch, daß es beim
Ausfall von zentralen Systemen oder Netzen oder auch beim Wiederanlaufen zu sehr vielen Traps
kommen kann (trap storms).
• Die Inform-Operation wird ebenfalls benutzt, um Benachrichtigungen über das Eintreten von Ereignissen zu versenden. Im Gegensatz zur Trap-Operation ist eine Inform-Operation bestätigt. Allerdings wird nur die Zustellung der Benachrichtigung bestätigt und nicht etwa das der Empfänger die
Nachricht verstanden hat.
5.3.5
Nachrichtenformat
Das Nachrichtenformat von SNMPv3 ist in ASN.1 definiert. Die unten angegebene Version weicht in einigen
Details von den RFCs ab, ist aber semantisch äquivalent und integriert die Definitionen für das aktuelle
Sicherheitsmodell (user-based security model).
HYPOTHETICAL-SNMPv2c-SNMPv3 DEFINITIONS ::= BEGIN
-- object names and types
ObjectName ::= OBJECT IDENTIFIER
ObjectSyntax ::= CHOICE {
simple
SimpleSyntax,
application-wide ApplicationSyntax
}
SimpleSyntax ::= CHOICE {
integer-value INTEGER (-2147483648..2147483647),
string-value
OCTET STRING (SIZE (0..65535)),
objectID-value OBJECT IDENTIFIER
}
ApplicationSyntax ::= CHOICE {
ipAddress-value
IpAddress,
counter-value
Counter32,
timeticks-value
TimeTicks,
arbitrary-value
Opaque,
5.3. SIMPLE NETWORK MANGEMENT PROTOCOL (SNMP)
117
big-counter-value
Counter64,
unsigned-integer-value Unsigned32
}
IpAddress
Counter32
Unsigned32
Gauge32
TimeTicks
Opaque
Counter64
::=
::=
::=
::=
::=
::=
::=
[APPLICATION
[APPLICATION
[APPLICATION
Unsigned32
[APPLICATION
[APPLICATION
[APPLICATION
0] IMPLICIT OCTET STRING (SIZE (4))
1] IMPLICIT INTEGER (0..4294967295)
2] IMPLICIT INTEGER (0..4294967295)
3] IMPLICIT INTEGER (0..4294967295)
4] IMPLICIT OCTET STRING
6] IMPLICIT INTEGER (0..18446744073709551615)
-- message header
SNMPv3Message ::= SEQUENCE {
msgVersion
INTEGER (0..2147483647),
msgGlobalData
HeaderData,
msgSecurityParameters OCTET STRING,
msgData
ScopedPduData
}
HeaderData ::= SEQUENCE {
msgID
INTEGER (0..2147483647),
msgMaxSize
INTEGER (484..2147483647),
msgFlags
OCTET STRING (SIZE(1)),
msgSecurityModel INTEGER (1..2147483647)
}
ScopedPduData ::= CHOICE {
plaintext
ScopedPDU,
encryptedPDU OCTET STRING
}
-- encrypted scopedPDU value
ScopedPDU ::= SEQUENCE {
contextEngineID OCTET STRING,
contextName
OCTET STRING,
data
ANY
-- e.g., PDUs
}
-- user-based security model
UsmSecurityParameters ::= SEQUENCE {
msgAuthoritativeEngineID
OCTET STRING,
msgAuthoritativeEngineBoots INTEGER (0..2147483647),
msgAuthoritativeEngineTime
INTEGER (0..2147483647),
msgUserName
OCTET STRING (SIZE(0..32)),
msgAuthenticationParameters OCTET STRING,
msgPrivacyParameters
OCTET STRING
}
-- protocol data units
PDUs ::= CHOICE {
get-request
GetRequest-PDU,
118
KAPITEL 5. INTERNET ANWENDUNGSSCHICHT
get-next-request
get-bulk-request
response
set-request
trap
inform
report
GetNextRequest-PDU,
GetBulkRequest-PDU,
Response-PDU,
SetRequest-PDU,
Trap-PDU,
Inform-PDU,
Report-PDU
}
GetRequest-PDU
GetNextRequest-PDU
Response-PDU
SetRequest-PDU
-- [4] is obsolete
GetBulkRequest-PDU
Inform-PDU
Trap-PDU
Report-PDU
::=
::=
::=
::=
[0]
[1]
[2]
[3]
IMPLICIT
IMPLICIT
IMPLICIT
IMPLICIT
PDU
PDU
PDU
PDU
::=
::=
::=
::=
[5]
[6]
[7]
[8]
IMPLICIT
IMPLICIT
IMPLICIT
IMPLICIT
BulkPDU
PDU
PDU
PDU
max-bindings INTEGER ::= 2147483647
RequestID
::= INTEGER (-214783648..214783647)
ErrorIndex ::= INTEGER (0..max-bindings)
ErrorStatus ::= INTEGER { noError(0), tooBig(1), noSuchName(2),
badValue(3), readOnly(4), genErr(5),
noAccess(6), wrongType(7), wrongLength(8),
wrongEncoding(9), wrongValue(10),
noCreation(11), inconsistentValue(12),
resourceUnavailable(13), commitFailed(14),
undoFailed(15), authorizationError(16),
notWritable(17), inconsistentName(18) }
VarBind ::= SEQUENCE {
name
ObjectName,
CHOICE {
value
ObjectSyntax,
unSpecified
NULL,
noSuchObject
[0] IMPLICIT NULL,
noSuchInstance [1] IMPLICIT NULL,
endOfMibView
[2] IMPLICIT NULL
}
}
VarBindList ::= SEQUENCE (SIZE (0..max-bindings)) OF VarBind
PDU ::= SEQUENCE {
request-id
error-status
error-index
variable-bindings
}
RequestID,
ErrorStatus,
ErrorIndex,
VarBindList
BulkPDU ::= SEQUENCE {
request-id
RequestID,
119
5.3. SIMPLE NETWORK MANGEMENT PROTOCOL (SNMP)
non-repeaters
INTEGER (0..max-bindings),
max-repetitions
INTEGER (0..max-bindings),
variable-bindings VarBindList
}
END
Die Kodierung mit Hilfe der Basic Encoding Rules liefert das folgende Paketformat.
0x30 - sequence
tag len
0x02 - integer
0x30 - sequence
tag len msgVersion
0x02 - integer
tag len
0x04 - octet string
tag len msgAuthEngineID
msgID
0x02 - integer
tag len
0x02 - integer
tag len
tag len
0x04 - octet string
msgGlobalData
0x04 - octet string
msgMaxSize
tag len msgAuthEngBoots
SNMPv3Message
msgFlags
0x02 - integer
tag len
0x02 - integer
tag len
0x04 - octet string
tag len msgAuthParam
tag len msgPrivParam
0x04 - octet string
0x04 - octet string
tag len contextEngineID
0x02 - integer
tag len
request-id
0x02 - integer
tag len
msgData
UsmSecurityParameters
0x04 - octet string
tag len msgUserName
tag len
0x30 - sequence
tag len msgSecurityModel
0x04 - octet string
tag len msgAuthEngTime
0x30 or 0x04 - sequence or octet string
msgSecurityParameters
tag len
contextName
depends on PDU type
tag len
0x02 - integer
error-status / non-repeaters
0x30 - sequence
tag len error-index / max-repetitions
tag len variable-bindings
0x30 - sequence
tag len
0x08 - object identifier
tag len
name
0x30 - sequence
VarBind
tag len
depends on type of value
tag len value / exception
PDU
0x08 - object identifier
tag len
name
VarBind
depends on type of value
tag len value / exception
Abbildung 5.21: SNMPv3 (USM) Kodierung
Sicherheit (USM/VACM)
Folgende Sicherheitsfragen müssen beantwortet werden:
1. Ist die Nachricht die eine Operation spezifiziert authentisch?
2. Wer möchte eine Operation ausgeführt bekommen?
3. Welche Variablen sind von der Operationen betroffen?
4. Welche Rechte hat der Aufrufer der Operation im Hinblick auf die betroffenen Variablen?
Die Fragen 1 und 2 werden mit Hilfe von Sicherheitsmechanismen im Protokoll gelöst während die Fragen
3 und 4 durch eine Zugriffskontrollinstanz beantwortet werden.
120
KAPITEL 5. INTERNET ANWENDUNGSSCHICHT
msgVersion
msgID
msgMaxSize
msgFlags
message
header
(SNMPv3)
msgSecurityModel
msgAuthoritativeEngineID
scope of authentication
msgAuthoritativeEngineBoots
msgAuthoritativeEngineTime
msgUserName
security
parameters
(USM)
msgAuthenticationParameters
msgPrivacyParameters
contextEngineID
scope of encryption
contextName
context
selector
(scope)
request-id
error-status / non-repeaters
error-index / max-repetitions
protocol
operation
(PDU)
variable-bindings
Abbildung 5.22: SNMPv3 (USM) Nachrichtenformat
Nachrichtensicherheit
• Das User-based Security Model (USM) [60] garantiert Datenintegrität und die Authentifikation des
Nachrichtensenders durch sogenannte Message Authentication Codes (MACs), die mit Hilfe von
kryptographisch starken Einweghashfunktionen über die Nachrichten und symmetrischen Schlüssel
gebildet werden (HMAC-MD5-96, HMAC-SHA-96).
• Die Vertraulichkeit der Daten kann optional durch Verschlüsselung der ScopedPDU mit einem symmetrischen Verschlüsselungsverfahren erreicht werden (CBC-DES).
• Der Schutz gegen Nachrichtenwiederholungen basiert auf loose synchronisierten Uhren. Bei jedem
Nachrichtenaustausch werden die jeweiligen Uhren der Kommunikationspartner abgeglichen.
• Die notwendigen Schlüssel können algorithmisch aus Paßworten generiert werden, wobei die Schlüssel
lokalisiert werden, so daß sie nur auf einer Protokollmaschine gültig sind:
– Erzeuge durch wiederholte Konkatenation eines Paßwortes eine Zeichenkette S der Länge 220 =
1048576 Bytes.
– Berechne den Schlüssel Ku des Benutzers u durch entweder Ku = H(S).
– Für eine Protokollmaschine E berechne Kue = H(Ku ||E||Ku )
– Als Hashfunktion H wird entweder MD5 oder SHA-1 benutzt.
Zugriffskontrolle
• Ein View ist eine Teilmenge der existierenden MIB Variablen. Ein View wird wie folgt definiert:
– Ein view subtree ist die Menge der MIB Variablen mit einem gemeinsamen OID Präfix.
121
5.3. SIMPLE NETWORK MANGEMENT PROTOCOL (SNMP)
– Eine view tree family ist die Kombination von einem OID Präfix mit einer Bitmaske.
– Jedes Bit der Bitmaske entscheidet, ob die entsprechende Komponenten im OID Präfix signifikant ist oder nicht (wild-carding).
– Ein view ist eine geordnete Menge von view tree families.
– Für Zugriffskontrollzwecke wird zwischen einem read view, einem write view und einem notify
view unterschieden.
12
1.1.2.1.*.1
-.
/0
+,
#$
1
'(
1
%&
1
1
1
1.2.1.2.*
2
)* !"
2
2
1
1
2
1
2
2
3
1
2
1
2
1
3
2
2
Abbildung 5.23: Views
• Durch geschicktes Wählen der Bitmask können view tree families ganze Zeilen oder ganze Spalten
beschreiben.
• Bei der Zusammenfassung von view tree families wird unterschieden, ob die view tree family eingeschlosse (included) oder ausgeschlossen (excluded) ist.
Die prinzipielle Logik der Zugriffskontrolle wird an folgendem Bild deutlich:
securityModel
who
groupName
securityName
where
contextName
securityModel
how
viewName
securityLevel
why
viewType
what
object type
yes/no
variableName
which
object instance
Abbildung 5.24: SNMP View-based Access Control Model (VACM)
122
KAPITEL 5. INTERNET ANWENDUNGSSCHICHT
5.4 Lightweight Directory Access Protocol (LDAP)
Dieser Abschnitt wurde dem Vizeweltmeister im Fußball geopfert.
5.5. AUGMENTED BACKUS-NAUR FORM (ABNF)
123
5.5 Augmented Backus-Naur Form (ABNF)
Neben den rein binären Nachrichtenformaten, die entweder informell durch Diagramme und Text oder durch
formale Definitionssprachen festgelegt werden, gibt es eine Vielzahl von Anwendungsprotokollen im Internet
die auf textuellen Formaten beruhen, in der Regel Kommandos (commands) die von einem Server interpretiert werden und der seinerseits Antworten (replies) erzeugt. Zur genaueren Definition derartiger Protokolle
dient die Augmented Backus-Naur Form (ABNF) [61].
5.5.1
Regelnamen und Terminalsymbole
• Wie jede BNF besteht auch eine Definition in der ABNF aus einer Menge von Regel (Produktionen).
Jede Regel hat einen Namen hat wobei die Großkleinschreibung nicht signifikant ist.
• Eine Regel hat den Aufbau
name = elements crlf
wobei name der Name der Regel ist, elements eine Folge von Regelnamen oder Terminalsymbolen
ist und crlf das Zeilenende markiert (cr = carriage return, lf = line feed).
• Terminalsymbole sind nicht-negative Zahlen. Die Basis der Zahlen kann entweder binär sein (b),
dezimal (d) oder hexadezimal (x).
CR
CR
= %d13
= %x0D
Mehrere Werte können durch einen Punkt konkateniert werden:
CRLF = %d13.10
Zeichenketten bestehen aus druckbaren US-ASCII Zeichen können literal in Anführungszeichen angegeben werden, wobei allerdings Zeichenketten nicht sensitiv bezüglich der Großkleinschreibung
sind.
5.5.2
Operatoren
In den ABNF-Regeln können verschiedene Operatoren auftreten, die im folgenden einzeln beschrieben sind.
Konkatenation
Der einfachste Operator ist die Konkatenation. Das Operatorsymbol ist das leere Wort (Leerzeichen in der
ABNF-Definition sind nicht signifikant). Eine Produktion der Form mumble = foo bar foo mit foo
= %x61 und bar = %x62 liefert die Zeichenfolge aba.
Alternativen
Alternativen werden durch das Operatorsymbol / definiert. Eine Produktion der From mumble = foo
/ bar liefert die durch foo oder bar definierte Zeichenfolge. Da es oftmals sinnvoll ist, eine Liste von
Alternativen in Fragmente zu definieren, gibt es hierfür eine besondere Notation:
mumble = foo
mumble =/ bar
mumble =/ baz
Offenbar läßt sich diese inkrementelle Notation von Alternativen einfach in die normale Notation für Alternativen umformen und erhöht also nur die Lesbarkeit. Ebenso lassen sich letztlich auch literale Zeichenketten
als eine Alternative schreiben.
124
KAPITEL 5. INTERNET ANWENDUNGSSCHICHT
Wertebereiche
Bereiche von alternativen Werten lassen sich durch eine Notation darstellen, bei der zwei Konstante durch
ein Bindestrich voneinander getrennt sind. Beide Konstanten teilen sich die Notation der Zahlenbasis.
DIGIT
DIGIT
=
=
%x30-39
"0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9"
Gruppierungen
Mehrere Elemente einer Regel können durch Klammern zu einer Gruppe zusammengefaßt werden werden,
die als einzelnes Element behandelt wird. Die Notation mumble = (foo bar) / (bar foo) liefert
die durch foo bar oder die durch bar foo definierte Zeichenfolge.
Wiederholungen
Wiederholungen können allgemein durch den parametrisierten Operator * definiert werden. Das allgemeine
Format ist n*m element wobei n die minimale Anzahl von Wiederholungen ist und m die maximale
Anzahl von Wiederholungen. Die Angabe von n und m ist optional. Beim Fehlen von n wird 0 angenommen
und beim Fehlen von m der Wert unendlich. Für häufig auftretende Spezialfälle gibt es folgende kompakte
Notationen:
• Die Notation * foo steht also für eine beliebig häufige Wiederholung von foo.
• Die Notation n foo mit einer positiven Zahl n steht für genau n Wiederholungen, also n*n foo.
• Optionale Elemente können als [foo] geschrieben werden und entsprechen *1 foo.
Kommentare
Kommentare werden durch ein Semikolon ; eingeleitet und erstecken sich bis zum Ende der Zeile.
5.5.3
Kerndefinitionen
Die folgenden Kerndefinitionen stammen aus der Spezifikation der ABNF und werden in vielen ABNFDefinitionen verwendet.
ALPHA
=
%x41-5A / %x61-7A
; A-Z / a-z
BIT
=
"0" / "1"
CHAR
=
%x01-7F
; any 7-bit US-ASCII character, excluding NUL
CR
=
%x0D
; carriage return
CRLF
=
CR LF
; Internet standard newline
CTL
=
%x00-1F / %x7F
5.5. AUGMENTED BACKUS-NAUR FORM (ABNF)
125
; controls
DIGIT
=
%x30-39
; 0-9
DQUOTE
=
%x22
; " (Double Quote)
HEXDIG
=
DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
HTAB
=
%x09
; horizontal tab
LF
=
%x0A
; linefeed
LWSP
=
*(WSP / CRLF WSP)
; linear white space (past newline)
OCTET
=
%x00-FF
; 8 bits of data
SP
=
%x20
; space
VCHAR
=
%x21-7E
; visible (printing) characters
WSP
=
SP / HTAB
; White space
5.5.4
ABNF in ABNF
Die Syntax einer gültigen ABNF-Definition läßt sich selbst wieder in ABNF beschreiben.
rulelist
=
1*( rule / (*c-wsp c-nl) )
rule
=
rulename defined-as elements c-nl
; continues if next line starts with white space
rulename
=
ALPHA *(ALPHA / DIGIT / "-")
defined-as
=
*c-wsp ("=" / "=/") *c-wsp
; basic rules definition and incremental alternatives
elements
=
alternation *c-wsp
c-wsp
=
WSP / (c-nl WSP)
c-nl
=
comment / CRLF
; comment or newline
comment
=
";" *(WSP / VCHAR) CRLF
126
KAPITEL 5. INTERNET ANWENDUNGSSCHICHT
alternation
=
concatenation
*(*c-wsp "/" *c-wsp concatenation)
concatenation
=
repetition *(1*c-wsp repetition)
repetition
=
[repeat] element
repeat
=
1*DIGIT / (*DIGIT "*" *DIGIT)
element
=
rulename / group / option /
char-val / num-val / prose-val
group
=
"(" *c-wsp alternation *c-wsp ")"
option
=
"[" *c-wsp alternation *c-wsp "]"
char-val
=
DQUOTE *(%x20-21 / %x23-7E) DQUOTE
; quoted string of SP and VCHAR without DQUOTE
num-val
=
"%" (bin-val / dec-val / hex-val)
bin-val
=
"b" 1*BIT
[ 1*("." 1*BIT) / ("-" 1*BIT) ]
; series of concatenated bit values
; or single ONEOF range
dec-val
=
"d" 1*DIGIT
[ 1*("." 1*DIGIT) / ("-" 1*DIGIT) ]
hex-val
=
"x" 1*HEXDIG
[ 1*("." 1*HEXDIG) / ("-" 1*HEXDIG) ]
prose-val
=
"<" *(%x20-3D / %x3F-7E) ">"
; bracketed string of SP and VCHAR without angles
; prose description, to be used as last resort
127
5.6. SIMPLE MAIL TRANSFER PROTOCOL (SMTP)
5.6 Simple Mail Transfer Protocol (SMTP)
Einer der grundlegenden Dienste im Internet ist elektronische Post (email). Das Simple Mail Transfer Protocol (SMTP) ist das wesentliche Protokoll zur Übertragung von elektronischer Post im Internet obwohl zu
einem funktionierenden System eine Reihe weiterer Definitionen über das Format der Nachrichten notwendig
sind. SMTP basiert in der Regel auf TCP und benutzt standardmäßig die Portnummer 25.
5.6.1
Grundlagen
Elektronische Post wird auch nach dem store-and-forward-Prinzip weitergeleitet bei dem jeweils ein Knoten die aktuelle Kopie einer Nachricht hat und Verantwortung für deren Weiterleitung übernimmt. Bei der
Weiterleitung wird zunächst auf dem nächsten Knoten eine neue Kopie erzeugt. Ist der Vorgang erfolgreich
beendet worden, so kann die lokale Kopie vernichtet werden, da der nächste Knoten jetzt für die Zustellung
zuständig ist.
Eine typische Konfiguration zum Versenden, Weiterleiten und Lesen von elektronischer Post im Internet zeigt
Abbildung 5.25.
sender host system
sender host system
mail
queue
user
agent
local
MTA
user
agent
SMTP
mail
queue
relay
MTA
organization A
SMTP
organization B
mail
queue
relay
MTA
user
mailbox
SMTP
user
agent
user
mailbox
receiver host system
local
MTA
IMAP
user
agent
receiver host system
Abbildung 5.25: Typische Konfigurationen für elektronische Post
• Der mail user agent (MUA) führt den Dialog mit dem Benutzer und nimmt eine neue elektronische
Nachricht entgegen. Die Nachricht wird anschließend entweder dem lokalen MTA oder einem relay
MTA (siehe unten) übergeben.
128
KAPITEL 5. INTERNET ANWENDUNGSSCHICHT
• Ein mail transfer agent (MTA) ist für die Weiterleitung von elektronischen Nachrichten durch das Internet zuständig. Ein relay MTA ist ein Zwischensystem das einzig zur Weiterleitung von Nachrichten
im Internet dient. Ein gateway MTA ist ein Zwischensystem das zur Weiterleitung von Nachrichten in
andere Netze dient (z.B. ISO/OSI Netzwerke auf der Basis des X.400 Protokolls).
• Am Zielsystem angekommen wird die elektronische Post in einem benutzerspezifischen Zwischenspeicher (mailbox) abgelegt. Der Zugriff auf diesen Zwischenspeicher erfolgt entweder über das
Dateisystem oder mit Hilfe spezieller Protokolle wie z.B. IMAP (siehe nächstes Kapitel).
• Bei der Übertragung von elektronischer Post unterscheidet man analog zu der gelben Post zwischen
einem Umschlag (envelop) der für die Weiterleitung und Zustellung einer Nachricht wichtig ist, einem
Nachrichtenkopf (header) der allgemeine Parameter einer Nachricht beschreibt und dem eigentlichen
Inhalt (body).
• Der Inhalt (body) ist zunächst nicht weiter struktuiert und auf die 7-Bit US-ASCII Zeichen reduziert.
Zusätzliche Standards beschreiben wie der Inhalt strukturiert werden kann und insbesondere mehrteilige Dokumente mit verschiedenen Dokumenttypen realisiert werden (MIME).
5.6.2
Kommandos und Antworten
Die Übertragung von elektronischer Post erfolgt mit Hilfe des Simple Mail Transfer Protocols (SMTP) [62].
Das Protokoll definiert eine relativ kleine Menge von Kommandos die von einem SMTP Client aufgerufen
und vom SMTP Server ausgeführt werden. Die Ausführung wird durch numerische Ergebniscodes bestätigt.
HELO
EHLO
MAIL
RCPT
DATA
RSET
VRFY
EXPN
HELP
NOOP
QUIT
Identifikation eines SMTP Clients gegenüber einen SMTP Server (HELLO)
Erweiterte Identifikation mit Anzeige unterstützter SMTP Optionen (EXTENDED HELLO)
Start einer Nachrichtenübertragung (MAIL)
Identifikation eines Empfängers (RECIPIENT)
Beginn der Übertragung des Inhalts (DATA)
Abbruch einer begonnenen Transaktion (RESET)
Überprüfung einer Adresse (VERIFY)
Auflösung einer Mailing-Liste (EXPAND)
Hilfe über die verfügbaren Kommandos (HELP)
Kommando ohne Wirkung (NOOP)
Beendung der Transportverbindung (QUIT)
Die genaue Syntax der SMTP-Kommandos ist in ABNF definiert:
;
; Syntax der Kommandos
;
helo
ehlo
mail
rcpt
=
=
=
=
data
rset
vrfy
expn
help
noop
quit
=
=
=
=
=
=
=
;
"HELO" SP Domain CRLF
"EHLO" SP Domain CRLF
"MAIL FROM:" ("<>" / Reverse-Path) [SP Mail-Parameters] CRLF
"RCPT TO:" ("<Postmaster@" domain ">" / "<Postmaster>" /
Forward-Path) [SP Rcpt-Parameters CRLF
"DATA" CRLF
"RSET" CRLF
"VRFY" SP String CRLF
"EXPN" SP String CRLF
"HELP" [ SP String ] CRLF
"NOOP" [ SP String ] CRLF
"QUIT" CRLF
5.6. SIMPLE MAIL TRANSFER PROTOCOL (SMTP)
; Syntax der Kommandoparameter
;
Reverse-path = Path
Forward-path = Path
Path
= "<" [ A-d-l ":" ] Mailbox ">"
A-d-l
= At-domain *( "," A-d-l )
; Note that this form, the so-called "source route",
; MUST BE accepted, SHOULD NOT be generated, and SHOULD be
; ignored.
At-domain
= "@" domain
Mail-parameters = esmtp-param *(SP esmtp-param)
Rcpt-parameters = esmtp-param *(SP esmtp-param)
esmtp-param
= esmtp-keyword ["=" esmtp-value]
esmtp-keyword
= (ALPHA / DIGIT) *(ALPHA / DIGIT / "-")
esmtp-value
= 1*(%d33-60 / %d62-127)
; any CHAR excluding "=", SP, and control characters
Keyword = Ldh-str
Argument = Atom
Domain = (sub-domain 1*("." sub-domain)) / address-literal
sub-domain = Let-dig [Ldh-str]
address-literal = "[" IPv4-address-literal /
IPv6-address-literal /
General-address-literal "]"
Mailbox = Local-part "@" Domain
Local-part = Dot-string / Quoted-string
Dot-string = Atom *("." Atom)
Atom = 1*atext
Quoted-string = DQUOTE *qcontent DQUOTE
String = Atom / Quoted-string
;
; Syntax f"ur IPv4/IPv6 Adressen
;
IPv4-address-literal = Snum 3("." Snum)
IPv6-address-literal = "IPv6:" IPv6-addr
General-address-literal = Standardized-tag ":" 1*dcontent
Standardized-tag = Ldh-str
; MUST be specified in a standards-track RFC
; and registered with IANA
Snum = 1*3DIGIT ; representing a decimal integer
; value in the range 0 through 255
129
130
KAPITEL 5. INTERNET ANWENDUNGSSCHICHT
Let-dig = ALPHA / DIGIT
Ldh-str = *( ALPHA / DIGIT / "-" ) Let-dig
IPv6-addr
IPv6-hex
IPv6-full
IPv6-comp
= IPv6-full / IPv6-comp / IPv6v4-full / IPv6v4-comp
= 1*4HEXDIG
= IPv6-hex 7(":" IPv6-hex)
= [IPv6-hex *5(":" IPv6-hex)] "::" [IPv6-hex *5(":"
IPv6-hex)]
; The "::" represents at least 2 16-bit groups of zeros
; No more than 6 groups in addition to the "::" may be
; present
IPv6v4-full = IPv6-hex 5(":" IPv6-hex) ":" IPv4-address-literal
IPv6v4-comp = [IPv6-hex *3(":" IPv6-hex)] "::"
[IPv6-hex *3(":" IPv6-hex) ":"] IPv4-address-literal
; The "::" represents at least 2 16-bit groups of zeros
; No more than 4 groups in addition to the "::" and
; IPv4-address-literal may be present
Als Reaktion auf die Kommandos schickt der Server dreistellige numerische Antwortcodes mit zusätzlichen
textuellen Erklärungen, die allerdings nicht für das Protokoll signifikant sind. Die Antwortcodes sind nach
einem festen Muster aufgebaut (theory of reply codes).
• Die erste Stelle des dreistelligen Antwortcodes gibt darüber Auskunft, um was für eine Art von Antwortcode es sich handelt:
1yz Vorläufige positive Antwort, wobei zur Ausführung der Aktion weitere Informationen notwendig sind (positive preliminary reply).
2yz Endgültige positive Antwort über die erfolgreiche Ausführung einer Aktion (positive completion
reply).
3yz Zwischenzeitliche positive Antwort, wobei weitere Informationen zur Beendigung einer Aktion
notwendig sind (positive intermediate reply).
4yz Transiente negative Antwort, wobei der Fehler temporärer Natur ist und das Kommando wiederholt werden kann (transient negative completion reply).
5yz Endgültige negative Antwort, wobei eine automatische Wiederholung des Kommandos nicht
sinnvoll ist (permanent negative completion reply).
• Mit der zweiten Stelle gruppiert man Antworten in spezielle Kategorien:
x0z Syntaktische Probleme.
x1z Informelle Antworten und Statusinformationen.
x2z Antworten, die sich auf den Übertragungskanal beziehen.
x3z Nicht definiert.
x4z Nicht definiert.
x5z Status des Servers im Kontext der eingeleiteten Aktionen.
• Die dritte Stelle gibt die genaue Bedeutung der Antwort in der jeweiligen Kategorie an.
Durch die Benutzung dieser dreistufigen Antwortcodes kann eine Implementation auch auf unbekannte neue
Antwortcodes relativ sinnvoll reagieren. Die im SMTP-Protokoll definierten Antwortcodes sind unten nach
funktionalen Kriterien geordnet angegeben:
5.6. SIMPLE MAIL TRANSFER PROTOCOL (SMTP)
500
501
502
503
504
131
Syntax error, command unrecognized
Syntax error in parameters or arguments
Command not implemented (see section 4.2.4)
Bad sequence of commands
Command parameter not implemented
211 System status, or system help reply
214 Help message
220 <domain> Service ready
221 <domain> Service closing transmission channel
421 <domain> Service not available, closing transmission channel
250
251
252
450
550
451
551
452
552
553
354
554
Requested mail action okay, completed
User not local; will forward to <forward-path>
Cannot VRFY user, but will accept message and attempt delivery
Requested mail action not taken: mailbox unavailable
Requested action not taken: mailbox unavailable
Requested action aborted: error in processing
User not local; please try <forward-path>
Requested action not taken: insufficient system storage
Requested mail action aborted: exceeded storage allocation
Requested action not taken: mailbox name not allowed
Start mail input; end with <CRLF>.<CRLF>
Transaction failed (Or, in the case of a connection-opening
response, "No SMTP service here")
5.6.3
Nachrichtenköpfe
Das Format der Nachrichtenköpfe ist in RFC 2822 [63] festgelegt. Die wesentliche Produktion der ABNF
sieht folgendermaßen aus:
fields
=
*(trace *resent-field) *regular-field
resend-field
resend-field
= resent-date / resent-from / resent-sender /
=/ resent-to / resent-cc / resent-bcc / resent-msg-id
regular-field
regular-field
regular-field
= orig-date / from / sender / reply-to / to / cc / bcc
=/ message-id / in-reply-to / references / subject
=/ comments / keywords
• Die resend-field Elemente werden bei der Übertragung von Nachrichten von MTAs erzeugt. Sie
dienen der Fehlersuche und der Erkennung von Schleifen.
• Die übrigen Felder haben die vermutlich mittlerweile allgemein bekannten Bedeutungen.
5.6.4
Multipurpose Internet Mail Extensions (MIME)
Die Multipurpose Internet Mail Extensions (MIME) [64] sind Konventionen, mit denen der Inhalt einer
Nachricht strukturiert werden kann und insbesondere auch die Übertragung verschiedener Dokumenttypen
(inklusive binärer Format) ermöglicht wird.
132
KAPITEL 5. INTERNET ANWENDUNGSSCHICHT
Zusätzliche Nachrichtenkopffelder
Die MIME-Spezifikationen definieren einige neue Felder für den Nachrichtenkopf:
• Das Feld Mime-Version definiert die MIME-Versionsnummer (derzeit 1.0).
• Das Feld Content-Type beschreibt, welchen Medientyp die Nachricht enthält. Es gibt zusammengesetzte Medientypen, bei denen jedes enhaltene Dokument selbst seinen Content-Type beschreibt.
• Das Feld Content-Transfer-Encoding legt fest, wie die Daten während der Übertragung kodiert werden. Dies ist notwendig, da SMTP klassisch nur 7-Bit ASCII verlangt und um Mehrdeutigkeiten zu
vermeiden.
• Das optionale Feld em Content-Description enthält eine kurze Beschreibung und ist insbesondere dann
sinnvoll, wenn nicht garantiert ist, daß ein Empfänger in der Lage ist den Dokumenttypen auszugeben.
Medientypen
MIME unterscheidet fünf primitive Medientypen (media types):
1. Der Medientyp (text) kann für beliebigen Text verwendet werden. Der einfachste Untertyp ist
plain. Beim Medientyp (text) kann über Parameter der Zeichensatz (charset) angegeben werden.
2. Der Medientyp (image) kann für beliebige Bildformate verwendet werden. Typische Untertypen sind
jpeg oder png.
3. Der Medientyp (audio) steht für ein Dokument, das einen Audiokanal zur Ausgabe benötigt.
4. Der Medientyp (video) steht für Sequenzen von bewegten Bilddaten. Ein typischer Untertyp ist
mpeg.
5. Der Medientyp (application) steht für Datenformate, die von bestimmten Applikationen verstanden werden. Typische Vertreter sind postscript oder pdf.
Neben den primitiven Medientypen gibt es auch zusammengesetzte Medientypen:
1. Der Medientyp (multipart) wird für Dokumente benutzt, die aus Teilen mit jeweils unterschiedlichen Medientypen bestehen.
2. Der Medientyp (message) kann selbst wieder eine Nachricht enthalten, wobei diese Nachricht allerdings nicht selbst vom Typ (message) sein darf.
Bei zusammengesetzten Inhalten werden die einzelnen Teil durch Markierungen voneinander getrennt, die jeweils an Anfang der Zeile mit zwei Minuszeichen (--) beginnen. Außerdem muß im Feld Content-Type
mit dem Parameter boundary eine zusätzliche Trennzeichenfolge festgelegt werden, die nach den zwei
Minuszeichen (--) folgen muß. Die letzte Markierung wird zusätzlich durch zwei Minuszeichen (--) abgeschlossen.
From: Nathaniel Borenstein <[email protected]>
To: Ned Freed <[email protected]>
Date: Sun, 21 Mar 1993 23:56:48 -0800 (PST)
Subject: Sample message
MIME-Version: 1.0
Content-type: multipart/mixed; boundary="simple boundary"
This is the preamble.
It is to be ignored, though it
133
5.6. SIMPLE MAIL TRANSFER PROTOCOL (SMTP)
is a handy place for composition agents to include an
explanatory note to non-MIME conformant readers.
--simple boundary
This is implicitly typed plain US-ASCII text.
It does NOT end with a linebreak.
--simple boundary
Content-type: text/plain; charset=us-ascii
This is explicitly typed plain US-ASCII text.
It DOES end with a linebreak.
--simple boundary-This is the epilogue.
It is also to be ignored.
Base64 Encoding
Bei dieser Kodierung werden jeweils drei Byte (also 24 Bit) durch ein vier Zeichen dargestellt, die aus einem
6-Bit Zeichenvorrat entnommen werden. Die sich ergebende Zeichenfolge wird so umgebrochen, daß Zeilen
niemals länger sind als 76 Zeichen.
Value
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
Encoding
A
B
C
D
E
F
G
H
I
J
K
L
M
N
O
P
Q
Value
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
Encoding
R
S
T
U
V
W
X
Y
Z
a
b
c
d
e
f
g
h
Value
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
Encoding
i
j
k
l
m
n
o
p
q
r
s
t
u
v
w
x
y
Value
51
52
53
54
55
56
57
58
59
60
61
62
63
Encoding
z
0
1
2
3
4
5
6
7
8
9
+
/
(pad) =
Sollten bei der Kodierung am Ende weniger als drei Byte übrig bleiben, so werden Füllbytes angehängt und
das besondere Zeichen = an die Kodierung angefügt, um die Anzahl der benutzten Füllbytes anzuzeigen.
Offensichtlich ist ein Text nach einer Base64-Kodierung nicht mehr ohne weitere Hilfsmittel lesbar.
Quoted-Printable Encoding
Beim Quoted-Printable Encoding wird versucht, soviel wie möglich von dem darstellbaren Text zu erhalten.
Nur Zeichen, die nicht in US-ASCII darstellbar sind, werden besonders kodiert. Das grundlegende Prinzip
ist es, nicht darstellbare Zeichen durch die entsprechende Hexadezimalzahl darzustellen, wobei das Zeichen
= zur Identifikation benutzt wird (=0A=0D).
Die genauen Regel sind in Wirklichkeit relativ komplex. Siehe RFC 2045 [64] für die Details.
134
KAPITEL 5. INTERNET ANWENDUNGSSCHICHT
5.7 Internet Message Access Protocol (IMAP)
Das Internet Message Access Protocol (IMAP) [65] erlaubt den Zugriff auf Nachrichten, die auf einem
Server physikalisch gespeichert werden. Dabei können verschiedenen Zwischenspeicher (folder, mailboxes)
verwaltet werden und es ist auch ein offline Betrieb mit späterer Synchronisation möglich. (IMAP erlaubt
außerdem auch den Zugriff auf Usenet News, indem News-Gruppen als weitere Zwischenspeicher betrachtet
werden.) Folgende Funktionen werden im Detail unterstützt:
• Erzeugen, löschen und umbenennen von Zwischenspeichern.
• Prüfen auf neu eingegangene elektronische Post.
• Löschen von elektronischer Port.
• Setzen und Löschen von Markierungen für elektronische Post.
• Suchen nach bestimmter elektronischer Post.
• Selektiver Zugriff auf Attribute und Inhalte von Teilen der elektronischen Post.
IMAP basiert in der Regel auf TCP und benutzt standardmäßig die Portnummer 143. Da ursprünglich die
Authentifizierung durch die Übertragung von Paßworten im Klartext geschah, wird oftmals IMAP über TLS
bzw. SSL verwendet. Interaktionen zwischen einem Client und einem Server sind in der Regel zeilenorientiert, wobei Zeilen durch ein CRLF abgeschlossen werden.
5.7.1
Identifikation und Zustände
Nachrichten werden in verschiedenen Zwischenspeichern verwaltet. Die Zwischenspeichern werden über
Namen identifiziert, wobei ein hierarchischer Namensraum unterstützt wird.
Die Nachrichten in einem Zwischenspeichern werden über Nummern identifiziert:
• Die Positionsnummer einer Nachricht message sequence number ist die relative Position einer Nachricht in einem Zwischenspeicher (gezählt wird ab 1). Die Positionsnummer einer Nachricht kann sich
durch Löschungen und Einfügungen verändern.
• Die Identifikationsnummer einer Nachricht unique identifier identifiziert eine Nachricht in einem Zwischenspeicher unabhängig von der Position der Nachricht im Zwischenspeicher. Die Identifikationsnummern bleiben über mehrere IMAP-Sitzungen erhalten und erlauben daher die Synchronisierung
beim off-line Betrieb.
Natürlich können auch bei der Verwendung von Identifikationsnummern Probleme auftreten, insbesondere
wenn externe Programme einen Zwischenspeicher umorganisieren oder ganze Zwischenspeicher gelöscht
und neue mit demselben Namen angelegt werden. Daher gibt es einen zusätzlichen globalen Zähler, der bei
solchen Ereignissen inkrementiert wird und mit dem angezeigt wird, daß die aktuellen Identifikationsnummern nicht mehr mit alten gespeicherten Identifikationsnummern identisch sein müssen.
5.7.2
Zustände
Das IMAP-Protokoll unterscheidet verschiedene Zustände. Abhängig vom jeweiligen Zustand stehen einem
Client unterschiedliche Kommandos zur Verfügung.
5.7. INTERNET MESSAGE ACCESS PROTOCOL (IMAP)
135
connection established and server greeting
non−authenticated
authenticated
selected
logout and connection release
Abbildung 5.26: IMAP Zustandsdiagramm
• Der Startzustand connection established and server greeting wird nach dem Aufbau der Transportverbindung angenommen. Der Server schickt in diesem Zustand eine Begrüßungsnachricht.
• Anschließend findet normalerweise eine Transition in den Zustand non-authenticated statt. In diesem
Zustand sind im wesentlichen nur die Kommandos zulässig, die zu einer Authentifikation notwendig
sind.
• Nach erfolgreicher Authentifikation findet eine Transition in den Zustand authenticated statt. In diesem Zustand kann im wesentlichen ein Zwischenspeichern zur weiteren Bearbeitung ausgewählt werden.
• Im Zustand selected kann auf den Inhalt des selektierten Zwischenspeichers zugegriffen werden, und
es können Änderungen vorgenommen werden. Man kann den selektierten Zwischenspeichers wieder
freigeben (Transition in den authenticated Zustand oder aber auch die IMAP-Sitzung beeinden.
• Im Zustand logout and connection release wird die Sitzung beendet und die Transportverbindung
ordnungsgemäß abgebaut.
5.7.3
Kommandos
Die einzelnen IMAP-Kommandos sind immmer nur in den verschiedenen Zuständen erlaubt. Die folgende
Liste der Kommandos ist daher nach den jeweiligen Zuständen sortiert:
Beliebiger Zustand
CAPABILITY
NOOP
LOGOUT
Liefert eine Liste der Faehigkeiten des Servers
Leeres Kommando (kann für Statusaktualisierungen benutzt werden)
Beendigung der IMAP-Sitzung
Zustand non-authenticated
AUTHENTICATE
LOGIN
Auswahl eines Authentifizierungsverfahrens
Triviale Authentifizierung mit einem Klartext Paßwort
136
KAPITEL 5. INTERNET ANWENDUNGSSCHICHT
Zustand authenticated
SELECT
EXAMINE
CREATE
DELETE
RENAME
SUBSCRIBE
UNSUBSCRIBE
LIST
LSUB
STATUS
APPEND
Auswahl eines Zwischenspeichers (read-write)
Auswahl eines Zwischenspeichers (read-only)
Anlegen eines neuen Zwischenspeichers
Löschen eines neuen Zwischenspeichers
Umbenennen eines Zwischenspeichers
Eintrag eines Zwischenspeichers in die Liste der aktiven Zwischenspeicher
Austragung eines Zwischenspeichers aus der Liste der aktiven Zwischenspeicher
Auflisten der Namen der Zwischenspeicher
Auflisten der Namen der aktiven Zwischenspeicher
Statusabfrage von einem Zwischenspeicher
Anfügen von Daten an einen Zwischenspeicher
Zustand selected
CHECK
CLOSE
EXPUNGE
SEARCH
FETCH
STORE
COPY
UID
5.7.4
Anlegen einer Sicherungskopie des Zwischenspeiches
Schließen des aktuellen Zwischenspeichers
Löschen aller Nachrichten, die zum Löschen markiert sind.
Suchen von Nachrichten, die bestimmte Kriterien erfüllen
Lesen von Daten einer Nachricht aus dem Zwischenspeicher
Ändern von Daten einer Nachricht in dem Zwischenspeicher
Kopieren von Nachrichten an das Ende eines Zwischenspeichers
Tagging
IMAP unterstützt nebenläufige Operationen auf dem Server. Ein Client kann also mehrere Kommandos absetzen, die dann vom Server asynchron ausgeführt werden. Ein Client versieht seine Kommandos daher mit
eindeutigen Tags, um später Antworten den verschiedenen Kommandos zuordnen zu können. Die Syntax
eines Kommandos ist damit:
command
= tag SPACE (command_any / command_auth /
command_nonauth / command_select) CRLF
Der Server antwortet auf Kommandos mit Antworten. Dabei werden wiederum drei Arten von Antwortzeilen
unterschieden:
1. Antwortzeilen, die weitere Informationen zur Bearbeitung eines Kommandos anfordern, werden durch
ein + markiert.
2. Antwortzeilen, die eine Statusmeldung beinhalten und nicht das Ende einer Kommandobearbeitung
implizieren, werden durch ein * markiert.
3. Alle anderen Antworten beginnen mit dem vom Client gesetzten Tag und zeigen die (erfolgreiche oder
erfolglose) Beendigung der Bearbeitung eines Kommandos an.
Die Rückmeldungen über die erfolgreiche/erfolglose Bearbeitung erfolgt durch Schlüsselworte (OK, NO,
BAD) und nicht wie beim SMTP durch strukturierte Antwortcodes.
5.7. INTERNET MESSAGE ACCESS PROTOCOL (IMAP)
5.7.5
137
Nachrichtenformat
Das IMAP-Nachrichtenformat selbst ist wiederum in ABNF beschrieben. Einen Ausschnitt der ABNFDefinitionen fuer die grundlegensten Elemente ist hier angegeben. Für die recht umfangreiche vollständige
Version sei jedoch auch RFC 2060 [65] verwiesen.
tag
= 1*<any ATOM_CHAR except "+">
; top-level productions for IMAP commands:
command
= tag SPACE (command_any / command_auth /
command_nonauth / command_select) CRLF
;; Modal based on state
command_any
= "CAPABILITY" / "LOGOUT" / "NOOP" / x_command
;; Valid in all states
command_auth
= append / create / delete / examine / list / lsub /
rename / select / status / subscribe / unsubscribe
;; Valid only in Authenticated or Selected state
command_nonauth = login / authenticate
;; Valid only when in Non-Authenticated state
command_select
= "CHECK" / "CLOSE" / "EXPUNGE" /
copy / fetch / store / uid / search
;; Valid only when in Selected state
; top-level productions for IMAP responses:
response
= *(continue_req / response_data) response_done
continue_req
= "+" SPACE (resp_text / base64)
response_data
= "*" SPACE (resp_cond_state / resp_cond_bye /
mailbox_data / message_data / capability_data) CRLF
response_done
= response_tagged / response_fatal
response_fatal
= "*" SPACE resp_cond_bye CRLF
;; Server closes connection immediately
response_tagged = tag SPACE resp_cond_state CRLF
138
KAPITEL 5. INTERNET ANWENDUNGSSCHICHT
5.8 Hypertext Transfer Protocol (HTTP)
Das Hypertext Transfer Protocol (HTTP) [66] ist eine der Grundsäulen World-Wide Webs. Es ist ein einfaches Request/Response Protokoll, mit dem Dokumente zwischen einem Client und einem Server ausgetauscht werden können. Die Dokumente sind unter Benutzung der MIME Konventionen strukturiert. HTTP
wird über TCP abgewickelt und benutzt normalerweise den wohl-bekannten Port 80.
Die Identifikation von Dokumenten geschieht über sogenannte Uniform Resource Identifier (URIs) [67]. Die
von HTTP angebotenen Methoden beziehen sich immer auf eine Dokument, das durch einen URI identifiziert
wird. Die von HTTP 1.1 unterstützten Methoden sind:
OPTIONS Abfrage der Optionen, die mit einem URI assoziiert sind
GET
Lesen aller Informationen, die zu einem URI gehören
HEAD
Lesen der Meta-Informationen, die zu einem URI gehören
POST
Schreiben von Parametern unter einem URI
PUT
Schreiben von Informationen unter einem URI
DELETE
Löschen aller Informationen assoziiert mit einem URI
TRACE
Indirekte Ausführung einer Methode zur Fehleridentifikation
CONNECT Reserviert für einen Tunnelmodus (z.B. SSL Tunnel)
Der grundlegende Aufbau der HTTP-Nachrichten ist in folgenden vereinfachter ABNF dargestellt:
HTTP-Message =
Start-Line
=
Start-Line *(message-header CRLF) CRLF [ message-body ]
Request-Line / Status-Line
Request-Line =
Method SP Request-URI SP HTTP-Version CRLF
Status-Line
=
HTTP-Version SP Status-Code SP Reason-Phrase CRLF
Method
Method
Method
= "OPTIONS" / "GET" / "HEAD" / "POST"
=/ "PUT" / "DELETE" / "TRACE" / "CONNECT"
=/ Extension-Method
Extension-Method = token
Request-URI
HTTP-Version
Status-Code
Reason-Phrase
=
=
=
=
"*" | absoluteURI | abs_path | authority
"HTTP" "/" 1*DIGIT "." 1*DIGIT
3DIGIT
*<TEXT, excluding CR, LF>
message-header
field-name
field-value
field-content
=
=
=
=
field-name ":" [ field-value ]
token
*( field-content / LWS )
<the OCTETs making up the field-value
and consisting of either *TEXT or combinations
of token, separators, and quoted-string>
Wichtiger Aspekt bei der Entwicklung von HTTP 1.1 war die bessere Unterstützung von Caches. Viele
Proxies und Web-Browser unterhalten Caches um die Zugriffsgeschwindigkeit zu verbessern. Die Effizienz
dieser lose organisierten Caches kann durch zusätzliche Informationen in den Nachrichtenköpfen deutlich
verbessert werden. Außerdem unterstützt HTTP 1.1 besser die Aushandlung von Optionen und Preferenzen
und löst einige Effizienzprobleme. Beispielsweise können in HTTP 1.1 mehrere Methoden über eine TCPVerbindung abgewickelt werden und es können mehrere logische Server auf einem physikalischen Server
realisiert werden, ohne dem Server mehrere IP-Adressen zuweisen zu müssen.
139
5.9. FILE TRANSFER PROTOCOL (FTP)
5.9 File Transfer Protocol (FTP)
Das File Transfer Protocol (FTP) [68] ist eins der ganz alten elementaren Internet Protokolle zum Austausch
von Dateien. Das Protokoll zeichnet sich dadurch aus, daß es für jede Dateiübertragung eine eigene TCPVerbindung etabliert, wodurch man viele der Probleme die man sonst durch umständliche Markierungen
oder Kodierungen auf einer TCP-Verbindung hat umgeht. Allerdings ist das Verfahren natuerlich bei relativ
kleinen Datenmenge nicht besonders effektiv, da jedesmal zum Auf- und Abbau der Verbindung ein entsprechender Nachrichten-Austausch durchgeführt werden muß.
user
interface
control
process
file
system
data transfer
process
FTP Server
commands
replies
control
process
data
data transfer
process
file
system
FTP Client
Abbildung 5.27: FTP Ablaufmodell
• Die Kontrollverbindung benutzt ein textuelles Protokoll, das sehr dem SMTP Protokoll ähnelt. Es werden vom Client zeilenweise Kommandos übertragen, die vom Server bearbeitet und mit dreistelligen
Antwortcodes bestätigt werden.
• Für jede Datenübertragung wird eine eigene TCP-Verbindung etabliert. Die Verbindung kann wahlweise vom Client zum Server oder vom Server zum Client hin aufgebaut werden. Wenn der Server
die Verbindung initiiert, muß vorher dem Server eine Portnummer bekannt gemacht worden sein. In
der anderen Richtung benutzt man einfach eine wohl-bekannte Portnummern (20). Die Kontrollverbindung wird normalerweise zur Portnummer 21 etabliert.
• FTP erlaubt es auch, bei abgebrochenen unvollständigen Übertragungsversuchen die Übertragung wieder aufzusetzen, was bei großen Datenmengen und instabilen Netzen eine wichtige Eigenschaft ist.
• Mit FTP kann man eine Übertragung zwischen zwei entfernten Systemen veranlassen. Allerdings hat
diese Eigenschaft durchaus einige Sicherheitprobleme zur Folge [69].
140
KAPITEL 5. INTERNET ANWENDUNGSSCHICHT
Anhang A
Packet Capturing
Netzwerke funktionieren gelegentlich nicht wie gewünscht und es ist in diesen Fällen notwendig, den Nachrichtenaustausch zu erfassen und zu analysieren. Dazu dienen spezielle Programme wie z.B. tcpdump,
ethereal oder ngrep, die Datenpakete analysieren. Kritisch bei solchen Programmen ist allerdings das
effiziente Zusammenspiel zwischen Betriebssystem und Analyseprogrammen.
• Pakete sollten möglichst frühzeitig gefiltert werden.
• Das Kopieren von Paketen ist teuer und sollte vermieden werden.
• Die Anzahl der erforderlichen Systemaufrufe sollte minimiert werden.
Offensichtlich läßt sich dieses Ziel erreichen, wenn unwichtige Pakete möglichst früh im Kern des Betriebssystems gefiltert werden — noch bevor sie aus dem Speicherbereich des Gerätetreibers kopiert werden.
A.1
BSD Packet Filter (BPF)
Der BSD Packet Filter (BPF) [70] basiert auf einer einfachen Kontrollfußmaschine, die im Betriebssystemkern realisiert ist und eine effektive Filterung ohne zusätzliche teure Kopieraktionen ermöglicht. Der BPF
wird durch ein Benutzerprozeß programmiert, der üblicherweise einen benutzerfreundlichen Filterausdruck
in eine entsprechende Sequenz von BPF-Befehlen umwandelt und dann die BPF-Sequenz im Betriebssystem installiert. Pakete, die den Filter bestehen, werden zunächst im Kern gesammelt und als Sammlung
dem Benutzerprozeß übergeben, um so die Anzahl der Systemaufrufe und die damit verbundenen Kosten zu
reduzieren.
Die BPF-Maschine ist folgendermaßen aufgebaut:
• Ein Akkumulator für alle Berechnungen.
• Ein Indexregister (x), mit dem relativ zu einer Position auf Daten zugegriffen werden kann.
• Speicher zum Ablegen von Zwischenergebnissen.
• Alle Register und Speicher sind 32 Bit breit.
Der Befehlssatz der BPF-Maschine benutzt ein festes Format, das effizient interpretiert werden kann. Für
genauere Details sei an dieser Stelle auf [70] verwiesen.
Beispiel 1 Alle Ethernet-Rahmen, die IP-Pakete enthalten (ip):
141
142
ANHANG A. PACKET CAPTURING
user
kernel
buffer
buffer
buffer
protocol
stack
filter
filter
filter
BPF
link−level
driver
link−level
driver
link−level
driver
kernel
network
Abbildung A.1: Einbettung des BPF in den Unix Kern
(000)
(001)
(002)
(003)
ldh
jeq
ret
ret
[12]
#0x800
#96
#0
jt 2
;
jf 3 ;
;
;
load ethernet type field
compare with 0x800
return snaplen
filter failed
Beispiel 2 Alle Ethernet-Rahmen, die IP-Pakete enthalten, die nicht aus den Netzen 128.3.112/24 und 128.3.254/24
stammen (ip and not src net 128.3.112/24 and not src net 128.3.254/24):
(000)
(001)
(002)
(003)
(004)
(005)
(006)
(007)
ldh
jeq
ld
and
jeq
jeq
ret
ret
[12]
#0x800
jt 2
[26]
#0xffffff00
#0x80037000 jt 7
#0x8003fe00 jt 7
#96
#0
A.2
libpcap
;
jf 7 ;
;
;
jf 5 ;
jf 6 ;
;
;
load ethernet type field
compare with 0x800
load ipv4 address field
mask the network part
compare with 128.3.112.0
compare with 128.3.254.0
return snaplen
filter failed
Hinter dem Namen libpcap1 verbirgt sich eine C-Bibliothek, die mehrere Funktionen bereitstellt:
• Portable API für verschiedenen Paketfilter in verschiedenen Betriebssystemen.
• Übersetzung von Filterausdrücken in PBF-Programme.
• Interpreter von BPF-Programmen, mit dem auch im Benutzermodus Pakete gefiltert werden können.
• Funktionen zum Schreiben und Lesen von Paketen in/aus Dateien.
Am einfachsten kann die Benutzung der libpcap API durch ein Beispiel erläutert werden. Der folgende
C-Quelltext realisiert ein Programm, daß zunächst eine Datei mit gespeicherten Paketdaten öffnet, optional
einen Filter installiert und anschließend über die einzelnen Pakete mit Hilfe einer Callback-Funktion iteriert.
1
http://www.tcpdump.org/
A.2. LIBPCAP
143
/*
* pcapdemo.c -*
*
Demonstrates the usage of the libpcap API to read pcap save
*
files. The packets are optionally filtered before the packet
*
handler function is called to print some meta information for
*
each filtered paket.
*
* Copyright (c) 2002 J. Schoenwaelder, University of Osnabrueck.
*/
#include <stdio.h>
#include <pcap.h>
static int count = 0;
static void
handler(u_char *user, const struct pcap_pkthdr *pkthdr, const u_char *data)
{
count++;
fprintf(stdout, "%d: %lu.%lus (%d)\n", count,
pkthdr->ts.tv_sec, pkthdr->ts.tv_usec, pkthdr->len);
}
int
main(int argc, char **argv)
{
char ebuf[PCAP_ERRBUF_SIZE];
pcap_t *pc;
if (argc < 2 || argc > 3) {
fprintf(stderr, "usage: pcapdemo <file> [<filter>]\n");
exit(1);
}
pc = pcap_open_offline(argv[1], ebuf);
if (! pc) {
fprintf(stderr, "failed to open file: %s\n", ebuf);
exit(2);
}
if (argc == 3) {
struct bpf_program bpf;
if (pcap_compile(pc, &bpf, argv[2], 1, 0) == -1) {
fprintf(stderr, "failed to compile filter: %s\n", pcap_geterr(pc));
exit(3);
}
if (pcap_setfilter(pc, &bpf) == -1) {
fprintf(stderr, "failed to set filter: %s\n", pcap_geterr(pc));
exit(4);
}
}
if (pcap_loop(pc, -1, handler, NULL) == -1) {
fprintf(stderr, "failed to process packets: %s\n", pcap_geterr(pc));
exit(5);
}
pcap_close(pc);
144
ANHANG A. PACKET CAPTURING
return 0;
}
Eine genauere Beschreibung der libpcap API findet man in der pcap(3) Manualseite. Die Syntax der erlaubten
Filterausdrücke ist in tcpdump(1) beschrieben.
A.3
jpcap
Für Java-Programmierer gibt es analog ein Paket jpcap2 mit dem Pakete von Java Programmen verarbeitet werden
können. Implementiert ist jpcap durch direkte Aufrufe der libpcap API.
Das C-Programm aus dem vorigen Abschnitt sieht in Java folgendermaßen aus:
import
import
import
import
import
import
net.sourceforge.jpcap.capture.PacketCapture;
net.sourceforge.jpcap.capture.InvalidFilterException;
net.sourceforge.jpcap.capture.CapturePacketException;
net.sourceforge.jpcap.capture.CaptureFileOpenException;
net.sourceforge.jpcap.capture.RawPacketListener;
net.sourceforge.jpcap.net.RawPacket;
public class JPcapDemo
{
PacketCapture pc;
public JPcapDemo(String file, String filter)
throws CaptureFileOpenException,
InvalidFilterException,
CapturePacketException
{
pc = new PacketCapture();
pc.openOffline(file);
if (filter.length() > 0) {
pc.setFilter(filter, true);
}
pc.addRawPacketListener(new JPcapDemoRawPacketListener());
pc.capture(-1);
pc.close();
}
public static void main(String args[]) {
JPcapDemo foo;
if (args.length < 1 || args.length > 2) {
System.err.println("arguments: <file> [<filter>]");
System.exit(1);
}
try {
foo = new JPcapDemo(args[0], args.length == 2 ? args[1] : "");
} catch (CaptureFileOpenException e) {
System.err.println("failed to open file: " + e.getMessage());
System.exit(2);
} catch (InvalidFilterException e) {
System.err.println("failed to set filter: " + e.getMessage());
System.exit(3);
} catch (CapturePacketException e) {
2
http://www.sf.net/projects/jpcap
145
A.3. JPCAP
System.err.println("failed to capture packets: " + e.getMessage());
System.exit(4);
}
}
private class JPcapDemoRawPacketListener implements RawPacketListener
{
int count = 0;
public void rawPacketArrived(RawPacket rawPacket)
{
byte[] data = rawPacket.getData();
count++;
System.out.println(count + ": "
+ rawPacket.getTimeval()
+ " (" + data.length + ")");
}
}
}
Für eine genaue Beschreibung der jpcap API sei auf die entsprechende Java Dokumentation verwiesen. Man sollte
allerdings bei der Verwendung von Java berücksichtigen, daß unter Umständen sehr leistungsfähige Rechner notwendig
sind, um mit den Datenraten heutiger Netze mithalten zu können.
146
ANHANG A. PACKET CAPTURING
Anhang B
Fragen zur Selbstkontrolle
1. Einführung
(a) Erläutern Sie den Unterschied zwischen Daten- und Telekommunikation.
(b) Nennen Sie verschiedene physikalische Topologien. Welche Funktion haben die verschiedenen Koppelelemente?
(c) Was versteht man unter einen nachrichtentechnischen Kanal? Welche Faktoren können eine Störung eines
Signals im nachrichtentechnischen Kanal bewirken?
(d) Nennen Sie mehrere Übertragungsmedien und vergleichen Sie die Eigenschaften der Medien miteinander.
(e) Was versteht man unter differentieller Codierung? Welchen wesentlichen Vorteile bietet die Manchester
Codierung gegenüber einfachen RZ und NRZ Codierungen?
(f) Erläutern Sie den Zusammenhang zwischen Bitrate und Baudrate.
(g) Erläutern Sie das Prinzip der zyklischen Blocksicherung. Welche Fehler können mit der zyklischen Blocksicherung nicht erkannt werden?
(h) Was versteht man unter dem Begriff Hamming-Abstand? Wozu kann man einen Hamming-Code benutzen?
(i) Erklären Sie den Unterschied zwischen Frequenz- und Zeitmultiplex.
(j) Was versteht man unter einem probabilistischen und einem deterministischen Medienzugangsverfahren?
(k) Erläutern Sie das Prinzip des Medienzugangsverfahrens CSMA/CD. Kann man CSMA/CD in Funknetzen
verwenden?
(l) Welche Probleme werden durch die Einführung von Sequenznummern, Quittungen und Zeitüberwachungen gelöst? Was ist der Unterschied zwischen einem ACK, NACK, SACK und SNACK?
(m) Erklären sie die Begriffe Flusskontrolle und Staukontrolle. Was versteht man in diesem Zusammenhang
unter dem Begriff Fenstertechnik?
(n) Was ist der Unterschied zwischen einem Dienst und einem Protokoll?
(o) Das ISO/OSI Referenzmodell definiert sieben Schichten zur Strukturierung von Kommunikationssystemen. Erläutern sie die Funktion der einzelnen Schichten.
2. Lokale Netze nach IEEE 802
(a) Ordnen Sie die IEEE 802 Standards in das ISO/OSI Referenzmodell ein. Welche Funktion haben die IEEE
802 Teilschichten?
(b) Wozu dient im IEEE 802.3 Rahmen die Präambel und das Startbyte?
(c) Der IEEE 802.3 Standard fordert eine Mindestrahmenlänge von 64 Byte. Von welchen Parametern hängt
diese Mindestrahmenlänge ab?
(d) Skizzieren Sie die Ablauflogik beim Senden/Empfangen von IEEE 802.3 Rahmen. Was ist ein Interframegap?
(e) Erklären Sie das Prinzip einer IEEE 802 Brücke. Was ist der Unterschied zwischen einer Source Routing
Brücke und einer transparenten Brücke?
147
148
ANHANG B. FRAGEN ZUR SELBSTKONTROLLE
(f) Was versteht man im Zusammenhang mit Brücken unter backward learning und einem spanning tree?
(g) Was versteht man unter einem virtuellen LAN? Wie werden Stationen den virtuellen LANs zugeordnet?
(h) Benötigt man pro VLAN einen Spannbaum (spanning tree) oder reicht ein globaler Spannbaum?
3. Internet Netzwerkschicht
(a) Diskutieren Sie die grundlegenden Prinzipien der Internet-Protokollfamilie.
(b) Erläutern Sie den Unterschied zwischen Link-MTU und Path-MTU. Was versteht man unter Path-MTU
”
Discover“?
(c) Wozu dienen autonome Systeme im Internet?
(d) Was versteht man im Zusammenhang mit Internet-Adressen unter einer Zone und einem Scope?
(e) Was versteht man unter einem IP-Adresspräfix?
(f) Erläutern Sie den Begriff Fragmentierung. Wie gehen die Protokolle IPv4 und IPv6 jeweils mit Fragmentierung um?
(g) Was versteht man unter der Internet-Prüfsumme? Warum wurde die IPv4-Prüfsumme in IPv6 abgeschafft?
(h) Beschreiben Sie die Weiterleitung von Datagrammen IP-Netzen.
(i) Wie funktioniert die Übertragung von IP Datagrammen über IEEE 802.3 Netze? Erläutern Sie die dynamische Adreßumsetzung in IPv4 und IPv6.
(j) Beschreiben Sie die wesentlichen Unterschiede zwischen IPv4 und IPv6.
(k) Wann sollte man einen IPv6 Erweiterungsprotokollkopf verwenden und wann eine IPv6 Option?
(l) Welche Sicherheitseigenschaften besitzt IPv6 im Vergleich zu IPv4? Was ist der Unterschied zwischen AH
und ESP?
(m) Erläutern Sie den Bellman-Ford-Algorithmus zur Ermittlung kürzester Wege. Welche Probleme gibt es bei
der Anwendung innerhalb des RIP-2 Protokolls?
(n) Erläutern Sie den Dijkstra-Algorithmus zur Ermittlung kürzester Wege. Vergleichen Sie den DijkstraAlgorithmus mit dem Bellman-Ford-Algorithmus.
(o) Beschreiben Sie das Open Shortest Path First (OSPF) Protokoll.
4. Internet Transportschicht
(a) Welche Aufgabe besitzen Portnummern im Internet?
(b) Was versteht man unter einem Pseudo-Header?
(c) Beschreiben Sie die Dienste, die von den Transportprotokollen UDP und TCP erbracht werden.
(d) Erläutern Sie den TCP Verbindungsaufbau und -abbau. Was ist bei der Wahl der Sequenznummern zu
beachten?
(e) Erklären sie die Funktionsweise der Flusskontrolle im TCP. Was versteht man unter den Begriffen Nagle”
Algorithmus“ und Silly Window Syndrome“?
”
(f) Erklären sie die Funktionsweise der Staukontrolle im TCP. Was versteht man unter den Begriffen Slow
”
Start“ und Karn’s Algorithm“?
”
(g) Wie funktionieren selektive Quittungen in TCP?
5. Internet Anwendungsschicht
(a) Beschreiben Sie die Struktur des Domain Name Systems (DNS). Was ist der Unterschied zwischen einem
Resolver und einem Name Server?
(b) Was versteht man unter einem Resource Record? Erklären Sie anhand von Beispielen die Struktur von
Resource Records.
(c) Beschreiben Sie die Funktionsweise des DNS Protokolls.
(d) Erläutern Sie die Begriffe Abstrakte Syntax“, Transfersyntax“ und lokale Syntax“.
”
”
”
(e) Definieren Sie eine Datenstruktur für eine Person in ASN.1. Skizzieren Sie an dem Beispiel, wie eine
Serialisierung mit Hilfe der Basic Encoding Rules (BER) aussehen würde.
(f) Erläutern Sie die Begriffe Managed Object“ und Management Information Base“.
”
”
149
(g) Wie werden Instanzen von MIB-Variablen in SNMP identifiziert? Welche Bedeutung hat die SMIv2 INDEX
Klausel?
(h) Was versteht man im Zusammenhang mit SNMP unter lexikographischer Ordnung?
(i) Erläutern Sie die sechs Protokolloperationen von SNMPv2c/SNMPv3. Zeigen Sie an einem Beispiel, wie
eine konzeptionelle Tabelle mit SNMP gelesen werden kann.
(j) Welche Sicherheitsmechanismen existieren in SNMPv3?
(k) Beschreiben Sie eine Datenstruktur für eine Person in ABNF.
(l) Erläutern Sie anhand einer Skizze die Begriffe MTA und MUA und wie die Protokolle SMTP und IMAP
zur Übertragung von elektronischer Post verwendet werden. Welche Bedeutung hat das Domain Name
System in diesem Zusammenhang?
(m) Wie können im Internet elektronische Nachrichten mit binärem Inhalt und verschiedenen Medientypen
verteilt werden?
(n) Beschreiben Sie die Funktionsweise der Kodierung Base64.
(o) Welche Aufgabe haben Tags im IMAP-Protokoll?
(p) Welche Methoden existieren im HTTP-Protokoll?
(q) Beschreiben Sie den Ablauf einer Datenübertragung mit Hilfe des FTP-Protokolls.
150
ANHANG B. FRAGEN ZUR SELBSTKONTROLLE
Literaturverzeichnis
[1] F. Halsall. Data Communications, Computer Networks and Open Systems. Addison-Wesley, 4 edition, 1996.
[2] A. S. Tanenbaum. Computer Networks. Prentice Hall, 3. edition, 1996.
[3] C. Huitema. Routing in the Internet. Prentice Hall, 2 edition, 1999.
[4] W. R. Stevens. TCP/IP Illustrated, Volume 1: The Protocols. Addison Wesley, 1994.
[5] R. Braden, D. Borman, and C. Partridge. Computing the Internet Checksum. RFC 1071, Cray Research, BBN
Laboratories, September 1988.
[6] T. Mallory and A. Kullberg. Incremental Updating of the Internet Checksum. RFC 1141, BBN Communications,
January 1990.
[7] A. Rijsinghani. Computation of the Internet Checksum via Incremental Update. RFC 1624, Digital Equipment
Corporation, May 1994.
[8] R. Hinden and S. Deering. IP Version 6 Addressing Architecture. RFC 1884, Ipsilon Networks, Xerox PARC,
December 1995.
[9] R. Elz. A Compact Representation of IPv6 Addresses. RFC 1924, University of Melbourne, April 1996.
[10] D. Waitzman. A Standard for the Transmission of IP Datagrams on Avian Carriers. RFC 1149, BBN STC, April
1990.
[11] P. Hoffman and S. Bradner. Defining the IETF. RFC 3233, Internet Mail Consortium, Harvard University, February
2002.
[12] S. Bradner. The Internet Standards Process – Revision 3. RFC 2026, Harvard University, October 1996.
[13] ANSI/IEEE. Local Area Networks: CSMA/CD, Std 802.3, 1988.
[14] B. Carpenter. Architectural Principles of the Internet. RFC 1958, IAB, June 1996.
[15] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6) Specification. RFC 2460, Cisco, Nokia, December
1998.
[16] J. Postel. Internet Protocol. RFC 791, ISI, September 1981.
[17] Y. Rekhter, B. Moskowitz, D. Karrenberg, G.J. deGroot, and E. Lear. Address Allocation for Private Internets. RFC
1918, Cisco Systems, Chrysler Corp., RIPE NCC, Silicon Graphics, Inc., February 1996.
[18] K. Nichols, S. Blake, F. Baker, and D. Black. Definition of the Differentiated Services Field (DS Field) in the IPv4
and IPv6 Headers. RFC 2474, Cisco Systems, Torrent Networking Technologies, EMC Corporation, December
1998.
[19] K. Ramakrishnan, S. Floyd, and D. Black. The Addition of Explicit Congestion Notification (ECN) to IP. RFC
3168, TeraOptic Networks, ACIRI, EMC, September 2001.
[20] D. Grossman. New Terminology and Clarifications for Diffserv. RFC 3260, Motorola, Inc., April 2002.
[21] F. Baker. Requirements for IP Version 4 Routers. RFC 1812, Cisco Systems, June 1995.
[22] G. Trotter. Terminology for Forwarding Information Base (FIB) based Router Performance. RFC 3222, Agilent
Technologies, December 2001.
[23] J. Postel. Internet Control Message Protocol. RFC 792, ISI, September 1981.
[24] J. Mogul and S. Deering. Path MTU Discovery. RFC 1191, DECWRL, Stanford University, November 1990.
[25] C. Hornig. A Standard for the Transmission of IP Datagrams over Ethernet Networks. RFC 894, Symbolics
Cambridge Research Center, April 1984.
151
152
LITERATURVERZEICHNIS
[26] D.C. Plummer. An Ethernet Address Resolution Protocol. RFC 826, MIT, November 1982.
[27] R. Finlayson, T. Mann, J. Mogul, and M. Theimer. A Reverse Address Resolution Protocol. RFC 903, Stanford
University, June 1984.
[28] R. Droms. Dynamic Host Configuration Protocol. RFC 2131, Bucknell University, March 1997.
[29] S. Kent and R. Atkinson. IP Authentication Header. RFC 2402, BBN Corporation, At Home Network, November
1998.
[30] S. Kent and R. Atkinson. IP Encapsulating Security Payload (ESP). RFC 2406, BBN Corporation, At Home
Network, November 1998.
[31] A. Conta and S. Deering. Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6)
Specification. RFC 2463, Lucent, Cisco Systems, December 1998.
[32] M. Crawford. Transmission of IPv6 Packets over Ethernet Networks. RFC 2464, Fermilab, December 1998.
[33] T. Narten, E. Nordmark, and W. Simpson. Neighbor Discovery for IP Version 6 (IPv6). RFC 2461, IBM, Sun
Microsystems, Daydreamer, December 1998.
[34] G. Malkin. RIP Version 2. RFC 2453, Bay Networks, November 1998.
[35] F. Baker and R. Atkinson. RIP-2 MD5 Authentication. RFC 2082, Cisco Systems, January 1997.
[36] J. Moy. OSPF Version 2. RFC 2328, Ascend Communications, April 1998.
[37] J. Postel. User Datagram Protocol. RFC 768, ISI, August 1980.
[38] J. Postel. Transmission Control Protocol. RFC 793, ISI, September 1981.
[39] L. Ong and J. Yoakum. An Introduction to the Stream Control Transmission Protocol (SCTP). RFC 3286, Ciena
Corporation, Nortel Networks, May 2002.
[40] R. Stewart, Q. Xie, K. Morneault, C. Sharp, H. Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, L. Zhang, and V. Paxson. Stream Control Transmission Protocol. RFC 2960, Motorola, Cisco, Siemens, Nortel Networks, Ericsson,
Telcordia, UCLA, ACIRI, October 2000.
[41] P. Mockapetris. Domain Names - Concepts and Facilities. RFC 1034, ISI, November 1987.
[42] P. Mockapetris. Domain Names - Implementation and Specification. RFC 1035, ISI, November 1987.
[43] S. Thomson and C. Huitema. DNS Extensions to support IP version 6. RFC 1886, Bellcore, INRIA, December
1995.
[44] D. Eastlake. Domain Name System Security Extensions. RFC 2535, IBM, March 1999.
[45] M. Crawford and C. Huitema. DNS Extensions to Support IPv6 Address Aggregation and Renumbering. RFC
2874, Fermilab, Microsoft Corporation, July 2000.
[46] ITU. Information technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation. Recommendation ITU-T X.680, International Telecommunication Union, December 1997.
[47] ITU. Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules (DER). Recommendation ITU-T X.690, International
Telecommunication Union, December 1997.
[48] D. Steedman. Abstract Syntax Notation One (ASN.1): The Tutorial and Reference. Technology Appraisals, 1990.
[49] M. Rose and K. McCloghrie. Structure and Identification of Management Information for TCP/IP-based Internets.
RFC 1155, Performance Systems International, Hughes LAN Systems, May 1990.
[50] J. Case, M. Fedor, M. Schoffstall, and J. Davin. A Simple Network Management Protocol. RFC 1157, SNMP
Research, PSI, MIT, May 1990.
[51] K. McCloghrie, D. Perkins, J. Schönwälder, J. Case, M. Rose, and S. Waldbusser. Structure of Management
Information Version 2 (SMIv2). RFC 2578, Cisco Systems, SNMPinfo, TU Braunschweig, SNMP Research, First
Virtual Holdings, International Network Services, April 1999.
[52] K. McCloghrie, D. Perkins, J. Schönwälder, J. Case, M. Rose, and S. Waldbusser. Textual Conventions for SMIv2.
RFC 2579, Cisco Systems, SNMPinfo, TU Braunschweig, SNMP Research, First Virtual Holdings, International
Network Services, April 1999.
[53] K. McCloghrie, D. Perkins, J. Schönwälder, J. Case, M. Rose, and S. Waldbusser. Conformance Statements for
SMIv2. RFC 2580, Cisco Systems, SNMPinfo, TU Braunschweig, SNMP Research, First Virtual Holdings, SNMP
Research, International Network Services, April 1999.
LITERATURVERZEICHNIS
153
[54] K. McCloghrie and F. Kastenholz. The Interfaces Group MIB. RFC 2863, Cisco Systems, Argon Networks, June
2000.
[55] J. Schönwälder and A. Müller. Reverse Engineering Internet MIBs. In Proc. 7th IFIP/IEEE International Symposium on Integrated Network Management, Seattle, May 2001.
[56] K. McCloghrie and A. Bierman. Entity MIB (Version 2). RFC 2737, Cisco Systems, December 1999.
[57] S. Waldbusser and P. Grillo. Host Resources MIB. RFC 2790, Lucent Technologies Inc., WeSync.com, March
2000.
[58] D. Harrington, R. Presuhn, and B. Wijnen. An Architecture for Describing SNMP Management Frameworks. RFC
2571, Cabletron Systems, BMC Software, IBM T. J. Watson Research, April 1999.
[59] J. Case, K. McCloghrie, M. Rose, and S. Waldbusser. Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2). RFC 1905, SNMP Research, Cisco Systems, Dover Beach Consulting, International
Network Services, January 1996.
[60] U. Blumenthal and B. Wijnen. User-based Security Model (USM) for version 3 of the Simple Network Management
Protocol (SNMPv3). RFC 2574, IBM T. J. Watson Research, April 1999.
[61] D. Crocker and P. Overell. Augmented BNF for Syntax Specifications: ABNF. RFC 2234, Internet Mail Consortium, Demon Internet Ltd., November 1997.
[62] J. Klensin. Simple Mail Transfer Protocol. RFC 2821, AT&T Laboratories, April 2001.
[63] P. Resnick. Internet Message Format. RFC 2822, QUALCOMM Incorporated, April 2001.
[64] N. Freed and N. Borenstein. Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message
Bodies. RFC 2045, Innosoft, First Virtual, November 1996.
[65] M. Crispin. Internet Message Access Protocol - Version 4rev1. RFC 2060, University of Washington, December
1996.
[66] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, and T. Berners-Lee. Hypertext Transfer Protocol
– HTTP/1.1. RFC 2616, UC Irvine, Compaq/W3C, Compaq, W3C/MIT, Xerox, Microsoft, W3C/MIT, June 1999.
[67] T. Berners-Lee, R. Fielding, and L. Masinter. Uniform Resource Identifiers (URI): Generic Syntax. RFC 2396,
MIT/LCS, U.C. Irvine, Xerox Corporation, August 1998.
[68] J. Postel and J. Reynolds. File Transfer Protocol (FTP). RFC 959, ISI, October 1985.
[69] M. Allman and S. Ostermann. FTP Security Considerations. RFC 2577, NASA Glenn/Sterling Software, Ohio
University, May 1999.
[70] S. McCanne and V. Jacobson. The BSD Packet Filter: A New Architecture for User-level Packet Capture. In Proc.
Usenix Winter Conference, January 1993.