-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathAdvanced_Communications.tex
3966 lines (3539 loc) · 224 KB
/
Advanced_Communications.tex
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
\documentclass{article} %A4
\usepackage[a4paper,left=1.9cm, right=2.1cm,top = 1.2cm,bottom=2.3cm]{geometry}
\usepackage[utf8]{inputenc}%Umlaute
\usepackage[ngerman]{babel} %Texttrennung
\usepackage{graphicx} %Grafiken
\usepackage{amssymb}
\usepackage{amsmath}
\usepackage{url}
\usepackage{listings}
\usepackage{color}
\usepackage{hyperref}
\usepackage{framed}
\usepackage{algpseudocode}
\usepackage{tikz}
\usepackage{enumitem}
\usepackage{multicol}
\usepackage[xindy,nonumberlist]{glossaries}
\makeglossaries
\usepackage[labelformat=empty]{caption}
\title{Zusammenfassung - Advanced Communications}
\author{
Marc Meier, CD
}
\begin{document}
\maketitle
\begin{framed}Korrektheit und Vollständigkeit der Informationen sind nicht gewährleistet.
Macht euch eigene Notizen oder ergänzt/korrigiert meine Ausführungen!
\end{framed}
\setcounter{tocdepth}{1}
\tableofcontents
\newpage
\section{Grundlagen}
% 010, 020
\subsection{Grundprinzipien und Entwicklung des Internets}
Das Internet entwickelte sich ab den 1960er Jahren.
Es ging aus dem am Ende des Jahrzehnts entstandenen, vornehmlich militärisch und akademisch geprägten ARPA-Net hervor.
Heutzutage wird es international kommerziell, industriell und auch akademisch (Katzenbilder) genutzt.
Bei seiner Entstehung war vor allem eine dezentrale Struktur ohne zentrale Verwaltung von Interesse.
Grund hierfür war die Angst des amerikanischen Department of Defense, dass eine atomarer Angriff zentrale Kommunikationspunkte außer Kraft setzen könnte.
Die Kommunikation findet über hochgradig vernetzte Knoten mithilfe von Paketen statt.
Literatur: \cite{abbate2000inventing, baran1964distributed}
\subsection{Packet Switching}
Paketvermittelte Übertragung bedeutet die Abkehr von der leitungsbasierten Vermittlung.
Dabei werden längere Nachrichten in Datenpakete aufgeteilt und voneinander unabhängig versendet.
Dies ermöglicht eine faire Verteilung der Leistungskapazität und redundante Wege bei einem Ausfall von Knoten oder Verbindungen.
Im Gegenzug können konstante Bandbreiten nicht ohne Weiteres (Abschnitt \ref{sec:qos}) gewährleistet werden, ebenso ergeben sich unterschiedliche Laufzeiten von Paketen.
\subsection{Dezentrale Verwaltung des Internets}
\subsubsection{Prinzipien}
\begin{itemize}
\item Keine zentrale Verwaltung oder Behörde (trotz Einflussnahme)
\item Demokratisches Zusammenwirken der Beteiligten / Wahlen
\item Selbstorganisation
\item Standards dort, wo sie erforderlich sind
\item Dynamisch, offen für Neuigkeiten
\end{itemize}
\subsubsection{Organisationen}
\begin{description}
\item[ICANN:] Vergibt IP-Adressen und betreibt die DNS-Rootserver.
\item[IETF:] Standardisierung von Protokollen in RFCs \cite{rfc3233}
\item[RIPE:] Administration und technische Koordination
\item[RIPE NCC:] Adressvergabe in Europa und Zentralasien, Verwaltung der WHOIS-Datenbank.
\item[DENIC eG:] Domain-Verwaltung für die Zone .de
\end{description}
\subsection{Standards}
Standards ermöglichen die Kooperation im Netzwerk, nur durch sie können Geräte verschiedener Hersteller miteinander kommunizieren.
Sie können textuell, mithilfe einer Referenzimplementierung oder anhand von Automaten (meist für zustandsbehaftete Protokolle) festgelegt werden.\\
Sie müssen verschiedenen Ansprüchen genügen: Vollständig, eindeutig (widerspruchsfrei) und stabil
\begin{description}
\item[Protokoll] Standardisierte Regeln (Vorschriften) und Vereinbarungen zu
Form, Ablauf, Steuerung und Sicherung (Fehler) der
Datenübertragung in und zwischen Rechnernetzen, zwischen
Einzel-Rechnern und zwischen Rechnern und
Peripheriegeräten.
\item[Standard] Ein Standard wird von den verschiedensten internationalen und
nationalen Organisationen sowie von großen Firmen erstellt.
Ein Standard wird als verbindliche oder unverbindliche
(empfohlene) Festlegungen schriftlich niedergelegt.
\end{description}
Ablauf einer Standardisierung bei RFCs:
\begin{enumerate}
\item \textbf{Proposed Standard}: Vollständige, konsistente Spezifikation vorhanden
\item \textbf{Draft Standard}: Mindestens 2 unabhängige, interoperable Implementierungen
\item \textbf{Standard}: Operationell stabil
\end{enumerate}
\textbf{Weitere Status:} \emph{Experimental}, \emph{Informational} und \emph{Historic}.
\subsection{Netze, Autonome Systeme und Schichten}
Große Teile des Internet-Backbones werden von wenigen Firmen bereitgestellt (Tier-1).
Diese werden an einigen Knotenpunkten verbunden.
Wichtiger Knotenpunkt in Deutschland ist DE-CIX in Frankfurt/Main.
Man unterteilt folgende \textbf{Netzwerk-Schichten}:
\begin{description}
\item[Tier 1]: Ein Netzwerk, das mit allen anderen Tier-1-Netzwerken verbunden ist; \emph{Internet-Backbone}; z.B. ATDN, GX, AT\&T...
\item[Tier 2]: Netzwerk, das mit vielen Netzwerken verbunden ist, aber Transit \emph{einkauft}, um einige Bereiche des Internets zu erreichen; z.B. Deutsche Telekom
\item[Tier 3]: Ein Netzwerk, das ausschließlich Transit \emph{einkauft}, um das
Internet zu erreichen
\end{description}
\textbf{Autonome Systeme} sind Ansammlungen von IP-Netzen, die als Einheit verwaltet werden.
Innerhalb kommt ein einheitliches Routing-Protokoll zum Einsatz.
Autonome Systeme sind untereinander verbunden und
bilden das Internet.
\subsection{Begriffe}
\begin{description}
\item[Jitter] wird als Varianz der Laufzeit von Datenpaketen bezeichnet.
\item[Latenz] das Zeitintervall, um das ein Ereignis verzögert wird.
\item[Datendurchsatz] gibt die Netto-Datenmenge pro Zeit an, die über ein kabelgebundenes oder kabelloses Netz übertragen werden kann. Beim Datendurchsatz werden die reinen Nutzdaten berücksichtigt. Bei der Datenübertragungsrate hingegen werden eventuelle Steuerdaten (englisch: Overhead) mitgerechnet.
\item[Datenrate] bezeichnet die digitale Datenmenge, die innerhalb einer Zeiteinheit über einen Übertragungskanal übertragen wird.
\item[Routing] bezeichnet in der Telekommunikation das Festlegen von Wegen für Nachrichtenströme bei der Nachrichtenübermittlung in Rechnernetzen. Insbesondere in paketvermittelten Datennetzen ist hierbei zwischen den beiden verschiedenen Prozessen des Routings und Forwardings zu unterscheiden: Das Routing bestimmt den gesamten Weg eines Nachrichtenstroms durch das Netzwerk; das Forwarding beschreibt hingegen den Entscheidungsprozess eines einzelnen Netzknotens, über welchen seiner Nachbarn er eine vorliegende Nachricht weiterleiten soll.
\end{description}
\section{Protokolle}
Protokolle können als Vorschrift betrachtet werden, wie sich verhalten werden soll. Um Interaktion zu ermöglichen, wird beschrieben, wann etwas geschickt werden darf und wie das Datenformat auszusehen hat.
\subsection{Zustandslose und zustandsbehaftete Protokolle}
Bei \textbf{zustandslosen Protokollen} wird jede Anfrage in einer eigenständigen Transaktion ausgeführt, es existieren keine Vorbedingungen oder Sitzungsinformationen (UDP, HTTP, TFTP).
\textbf{Zustandsbehaftete Protokolle} hingegen merken sich den aktuellen Zustand mithilfe einer Sitzung.
Nachfolgende Anfragen können auf die Sitzungsinformationen zugreifen.
Diese Zustandsübergänge können durch endliche Automaten dargestellt werden.
Beispiele sind FTP, TCP und SMTP.
\subsection{OSI-7-Schichten-Modell}
\begin{enumerate}
\item Physical Layer / Bitübertragung
\item Data Link Layer / Sicherungsschicht / Datenübertragungsschicht
\item Network Layer / Vermittlungsschicht
\item Transport Layer
\item Session Layer / Sitzungsschicht
\item Presentation Layer / Darstellungsschicht
\item Application Layer / Anwendungsschicht
\end{enumerate}
Gute \textbf{Eselsbrücken} sind:
\begin{itemize}
\item Alle deutschen Studenten trinken verschiedene Sorten Bier (deutsche Bezeichnungen, 7-1)
\item An dem Samstag trug Verena 'nen String in Blau (deutsche Bezeichnungen, 7-1)
\item Alle poppen Susis Tante nach der Party (deutsche Bezeichnungen, 7-1)
\item Physiker, die nicht trinken sind potentielle Attentäter (deutsche/englische Bezeichnungen, 1-7)
\item Alibaba präsentiert sich täglich nackt dem Personal
\item Please Do Not Throw Salami Pizza Away (englisch, 1-7)
\end{itemize}
Jede Schicht $n$ nutzt die darunterliegende Schicht $n-1$ um mit dem Kommunikationspartner zu kommunizieren.
Daten höherer Schichten werden in niederen Schichten umkapselt.
Die Bezeichnung der Pakete ist je nach Schicht unterschiedlich:
\begin{description}
\item[Data Link Layer]: (Ethernet-)Frame
\item[Network Layer]: Paket
\item[Transport Layer]: Fragment
\end{description}
\subsection{Ethernet}
\label{subsec:ethernet}
Das Ethernet-Protokoll wirkt auf den Layern 1 + 2 und wird im Standard \textbf{IEEE 802.3} definiert.
Es kümmert sich um
\begin{itemize}
\item Elektrokrams (Physikalische Eigenschaften, Stecker, Stromversorung, Kabel etc.),
\item Zugriffsverfahren auf das Medium,
\item Adressierung (MAC),
\item Protocol-Multiplexing,
\item Flow Control (Logical Link Control),
\item Fehlererkennung (CRC).
\end{itemize}
Es ähnelt den Standards \textbf{802.11} (WLAN), \textbf{802.15.1} (Bluetooth) und \textbf{802.16} (WiMAX).
Ein \textbf{Ethernet-Frame} hat eine Größe von 64 - 1518 Byte.
Davon ausgenommen sind die Präambel und der SFD.
Wird das VLAN-Tag genutzt, sind 1522 Byte möglich.
Das \textbf{Ethernet-Paket} (Offensichtlich Präambel + SFD + Ethernet-Frame) umfasst folgende Felder:
\includegraphics[width=16cm]{img/EthernetFrame.jpg}
\begin{description}
\item[Präambel]: Zum Synchronisieren von Sender und Empfänger, \emph{Einschwingphase} (8 Byte)
\item[SFD]: Festgelegte Sequenz 10101011 (1 Byte)
\item[Ziel-Mac-Adresse]: Adresse des Empfängers (8 Byte)
\item[Quell-Mac-Adresse]: Adresse des Senders (8 Byte)
\item[VLAN-Tag]: Nach IEEE 802.1q, optional (4 Byte)
\item[Typ-Feld]: Identifiziert die Art des nachfolgenden Inhalts, z.B. IP, ARP, etc...
\item[Nutzlast]
\item[PAD-Füllfeld]: Wird optional benötigt, um die Mindestlänge von 64 Byte einzuhalten \footnote{Rausfinden, warum mindestens 64 Byte nötig. Vermutung: Kollisionserkennung}
\item[CRC-Prüfsumme]: Zur Fehlererkennung (4 Byte)
\end{description}
\subsubsection{CSMA/CD}
CSMA/CD regelt den Zugriff auf ein von mehreren Teilnehmern genutztes Medium (Kabel).
Dazu prüft der sendende Host, ob das Medium frei ist, bevor er sendet.
Beim Übertragen von Daten können Kollisionen erkannt werden.
Der Sendevorgang wird dann nach einer zufälligen Zeit wiederholt.
Aufgrund der verbreiteten Nutzung von Switches sind echte geteilte Medien inzwischen eher die Ausnahme.
$\Rightarrow$ Jeder Port am Switch bildet eine eigene \emph{Kollisionsdomäne}.
Die Bustopologie mit Koaxialkabeln (aber auch mit Hubs) wird nicht mehr genutzt.
\subsubsection{Duplex / Half Duplex}
Beim \textbf{Full Duplex} sind beide Seiten in der Lage, gleichzeitig zu Senden und zu Empfangen.
Im Falle von \textbf{Half Duplex} ist dies nur wechselseitig möglich (vgl Walkie Talkie).
Es sind verschiedene Realisierungen einer geteilten Nutzung eines Mediums möglich:
\begin{description}
\item [Zeitduplex (TDD)]: Übertragung in verschiedenen Zeitschlitzen
\item [Frequenzduplex (FDD)]: Übertragung auf verschiedenen Frequenzen
\item [Codeduplex]: (nicht im Skript)
\end{description}
\subsection{Switching}
\textbf{Switches} sind Geräte auf dem OSI-Layer 2.
Sie empfangen Ethernet-Frames und leiten sie anhand ihrer Empfänger-MAC-Adresse weiter.
Im Gegensatz zum Hub wird dabei nur über den Port ausgegeben, hinter dem sich der Empfänger befindet.
Die Ausnahme ist hierbei, wenn der Port des Empfängers nicht bekannt ist.
Anhand der empfangenen Frames lernt ein Switch, wo sich Geräte befinden.
\subsubsection{Realisierungsmöglichkeiten}
%PRÜFEN Switches - Realisierungsmöglichkeiten
Im Groben existieren drei Realisierungsmöglichkeiten für Switches:
\begin{description}
\item[Shared Memory] | Alle Schnittstellen kommunizieren über einen zentralen Speicher.
Genutzt wird ein einfacher interner Rechnerbus.
Diese Realisierungsart ist sehr preisgünstig.
\item[Common Bus] | Schnittstellen verfügen über lokalen Speicher und gemeinsamen Bus.
Bus ist in der Regel schneller getaktet als die externen Schnittstellen (Zeitmultiplex) oder erlaubt als so genannte Backplane mehrere parallele Verbindungen (Raummultiplex)
\item[Crosspoint Matrix] | Schnittstellen verfügen über lokalen Speicher.
Die Kommunikation zwischen den Ports findet über \emph{spontan} geschaltete Verdrahtungen statt.
\end{description}
\begin{center}
\includegraphics[width=8cm]{img/crosspoint_matrix}
\end{center}
\subsubsection{Cut-Through und Store-and-Forward}
Beim \textbf{Cut-Through} (auch \emph{On The Fly Forwarding}) werden Pakete sofort nach Empfang der Empfängeradresse auf dem entsprechenden Port weitergeleitet, sofern dieser frei ist.
Diese Methode ist sehr schnell (Verzögerung ca. 40$\mu$s), leitet jedoch gegebenenfalls auch fehlerhafte Frames weiter, da CRC umgangen wird.
\textbf{Store-and-Forward} hingegen empfängt zuerst den gesamten Frame, prüft diesen und leitet ihn anschließend weiter.
Offensichtlich werden keine fehlerhaften Pakete mehr in benachbarte Segmente weitergeleitet, dies wird jedoch durch erhöhte Latenz erkauft.
In der Praxis arbeiten Switches häufig im Cut-Through-Modus und schalten bei erhöhter Fehlerrate in den Store-and-Forward-Modus.
\subsubsection{VLAN}
Ermöglicht die Aufteilung von Switches in mehrere virtuelle LANs.
Den Ports werden dabei einzelne VLANs zugeordnet.
Auf diese Weise kann Hardware eingespart werden.
Realisiert wird dies mit einem 4 Byte langen Feld im Ethernet-Frame:
\begin{itemize}
\item 2 Bytes \textbf{TPID} - Tag Protocol Identifier – Fester Wert 0x8100. Frame
trägt die 802.1q/802.1p-Tag-Information
\item 3 Bit \textbf{Priorität} (user\_priority) – Benutzer-Prioritätsinformationen
\item 1 Bit \textbf{CFI} - Canonical Format Indicator – Gilt für alle vorhandenen
MAC-Adressinformationen im MAC-Datenpaket des Frames. Wert 0
das Format ist kanonisch (am wenigsten signifikante Bit zuerst); Wert
1 Format nicht-kanonisch. Benutzung im Token Ring/Source-Routed-
FDDI-Media-Zugang, um die Bit-Order der Adressinformationen des
verkapselten Frames festzulegen
\item 12 Bit \textbf{VID} - VLAN Identifier – Identifizierung des VLANs zu dem der
Frame gehört
\end{itemize}
Erleichtert die Arbeit eines Administrators, da es viele Probleme von physikalischen Verbindungen umgeht. (bspw. Viel Hardware, unflexibel, Anpassungen nur mit hohem Aufwand)\\
\glqq Faulheit ist die Mutter der Ingenieurswissenschaften\grqq\\
\subsubsection{Trunking / Link Aggregation}
Ermöglicht die Zusammenfassung mehrerer Ports zur Erhöhung des Datensatzes.
\subsection{Asynchronous Transfer Mode - ATM}
\begin{itemize}
\item ATM kann als Protokoll für Internettelefonie eingesetzt werden und bietet eine geringe Latenz (von unter 200ms).
\item Im Gegensatz zu Ethernet bietet ATM Garantien(!) und besitzt einen geringen Header von 5 Byte. Es wird eine Leitung für den Datenstrom geschaltet.
\item Später mehr
\end{itemize}
\subsection{Internet Protocol}
\label{subsec:ip}
Beim Internet Protocol handelt es sich um ein Layer-3-Protkoll, weches auf die Layer-2-Protokolle Ethernet, ATM und FDDI aufsetzen kann.
Es verwendet globale, logische Adressen.
Aufgrund der Erschöpfung des IPv4-Adressraumes\footnote{Weitere Maßnahmen, dem entgegenzuwirken sind etwa: NAT, CIDR, DHCP, Private Adressräume} (32 Bit) wird nach und nach IPv6 eingeführt (128 Bit)
\subsubsection{IPv4}
Wurde im RFC 791\cite{rfc791} definiert.
Der Header eines IPv4 Paketes ist insgesamt 20 Byte lang.
Davon sind insbesondere die folgenden von Interesse:
\begin{description}
\item [Version]: In diesem Fall \emph{4}, bei IPv6 offensichtlich \emph{6} (4 Bit)
\item [Header Length]: Gesamtlänge des Headers kann 20 Byte überschreiben, wenn zusätzliche Optionen gesetzt werden. Angabe in 32-Bit langen Blöcken (4 Bit)
\item [Total Length]: Gesamtgröße des Pakets. Nach RFC muss jeder Host in der Lage sein, mindestens Pakete mit einer Länge von 576 Bytes zu verarbeiten. (16 Bit)
\item [Type of Service]: Type of Service nach RFC791(ursprünglich für Quality-of- Service-Anwendungen gedacht)
\begin{itemize}
\item bits 0-2: precedence
\item bit 3: 0 = Normal Delay, 1 = Low Delay
\item bit 4: 0 = Normal Throughput, 1 = High Throughput
\item bit 5: 0 = Normal Reliability, 1 = High Reliability
\item bits 6-7: Reserved for future use
\end{itemize}
Heute anders verwendet zur Servicebeschreibung durch Dienstklassen (DiffServ, 8 Bit)
\item [Identification]: Falls ein Paket fragmentiert wird, haben alle Fragmente die selbe Identification.
\item [Flags]: Reserved\cite{rfc3514}, Don't Fragment, More Fragments (3 Bit)
\item [Fragment Offset]: Kann ein Paket nicht auf einmal übertragen werden (z.B. bei
kleinerer Maximum Transfer Unit, MTU), wird es fragmentiert.
FO gibt an, ab welcher Stelle (gemessen in Blöcken von 8 Byte)
dieses Paket die Daten enthält (MF Flag ist gesetzt) (13 Bit)
\item[TTL]: Anzahl der Hops, bis Paket verworfen wird (wird bei jedem Routingvorgang reduziert)
\item[Protocol]: Enthält für die darüber liegenden Layer Informationen, \glqq sodass diese etwas damit anfangen können\grqq
\item[Checksum] wird selbst als 0 betrachtet, und fließt so nicht in die Kalkulation mit ein
\item [Options]: Beispielsweise für Source Routing (Route ist im Paket vorgegeben); Sehr selten verwendet, häufig blockiert oder ignoriert
\end{description}
\begin{center}
\includegraphics[width=8cm]{img/IP_packet}
\end{center}
Nutzung von Adressklassen\footnote{Class A 1.x.y.z-126.x.y.z; Class B 128.0.y.z-191.255.y.z; Class C 192.0.0.z-223.255.255.z} aufgrund der Verknappung der Adressen durch CIDR\cite{rfc1519} abgelöst.
Dies ermöglichte Super- und Subnetting.
Adressangabe bei CIDR im Format a.b.c.d/x, wobei x angibt, wie viele Bits zum Netz-Anteil der Adresse gehören.
Subnetze dienen zur Aufspaltung von Netzen in Teile, um diese besser handhaben zu können (Broadcast-Domains, Logische Strukturierung, Dezentrale Verwaltbarkeit)
\subsubsection{IPv6}
Die auffälligste Änderung von IPv4 zu IPv6 ist die vergrößerte Adressgröße (128 Bit).
Damit ergeben sich $3,4 \cdot 10^{38}$ Adressen.
IP - Adressen werden im Hexadezimalsystem zu je acht Wort-Gruppen á 2 Bytes dargestellt.
Verkürzte Darstellung möglich durch Verzicht auf "`Nullen"' in einer Gruppe (einmal je Adresse).
Es existieren IPv4-kompatible Adressen und die CIDR-Darstellung für Subnetze bleibt erhalten.
Weiterhin wurde die Anzahl der Felder im Header reduziert und (optionale) Erweiterungsheader hinzugefügt.
Wichtige Felder sind:
\begin{description}
\item [Traffic Class]: \begin{itemize}
\item 0 uncharakterisierter Verkehr
\item 1 "`Füllmaterial", z.B. Newsgroups
\item 2 zeitunkritischer Verkehr, z.B. E-Mail
\item 3 reserviert
\item 4 Mengendaten, z.B. FTP, NFS
\item 5 reserviert
\item 6 Interaktive Anwendungen, z.B. telnet
\item 7 Steuerung, z.B. SNMP
\end{itemize}
\item [Flow Label]: Anwendung kann Datenstrom mit einem Flow-Label versehen, z. B. bei Streaming-Anwendungen.
Flow nicht notwendigerweise an Verbindung gebunden (logisch, da IP nicht verbindungsorientiert arbeitet).
Empfänger kann Datenstrom am Flow Label erkennen. \cite{rfc3697, rfc6437}
\item[Next Header]: Gibt an, dass ein weiterer Header folgt.
In IPv6 sind viele Felder weggefallen.
Next Header ermöglicht das Anfügen eines weiteren Headers.
RFC 2460\cite{rfc2460} bietet beispielsweise:
\begin{itemize}
\item Hop – by – Hop Options Header
\item Routing Header
\item Fragmentation Header
\item Authentication Header
\item Encapsulated Security Payload (ESP) Header
\item Destination – Option – Header
\end{itemize}
\end{description}
\begin{center}
\includegraphics[width=10cm]{img/IPv6_header}
\end{center}
\subsubsection{Migration von IPv4 nach IPv6}
\emph{Wie migriert man Millionen von Hosts im Internet auf IPv6?}
Langsam, nach und nach.
Alle Hosts auf einmal sind nicht realisierbar.
RFC 1933\cite{rfc1933} schlägt drei Migrationsstrategien vor.
\begin{description}
\item [Tunneling]: Zwischen zwei IPv6-Knoten wird ein virtueller Link aufgebaut.
Die IPv6-Pakete werden (als Payload) in IPv4-Pakete verpackt und \emph{normal} über das Internet geroutet.
\item [Dual Stack]: Auf Hosts und Routern werden sowohl IPv4 als auch IPv6 eingerichtet.
DNS kann A- oder AAAA-Records zurück geben, entsprechender Stack wird dann genutzt.
%PRÜFEN Hier ist inhaltliche Überprüfung notwendig.
Wird häufig mit Automatic Tunneling\footnote{\textquotedblleft IPv6-over-IPv4 tunneling where the IPv4 tunnel endpoint address is determined from the IPv4 address embedded in the IPv4-compatible destination address of the IPv6 packet.\textquotedblright} genutzt.
Außerdem besteht die Möglichkeit von \textbf{Assignment of IPv4 Global Addresses to IPv6 Hosts} (AIIH).
Dabei wird eine IPv4-kompatible IPv6-Adresse genutzt.
Diese entspricht dem 96-bit Präfix 0:0:0:0:0:0, gefolgt von der IPv4-Adresse.
Ist der Client der Dual-Stack-Hosts und der Server IPv4-only, verlangt der Client für die Dauer der Kommunikation eine temporäre IPv4 Adresse beim AIIH Server (Kooperation von DNS und DHCPv6).
Andernfalls (Client IPv4-only; Server Dual-Stack): DNS verlangt bei DHCPv6 eine temporäre IPv4 Adresse für Dual-Stack Host, welcher mit dieser rekonfiguriert wird.
\item [Übersetzung der Header](Header Translation): Hierbei wird die IPv4 Unterstützung auf Systemen entfernt. Die IPv4-Pakete werden in IPv6-Pakete übersetzt; ein Translator übersetzt IP und ICMP Meldungen.
%FRAGE Ist mit den Erweiterungsheadern das Options-Zeugs bei IPv4 gemeint?
Erweiterungsheader werden nicht, oder nur bedingt übersetzt.
Probleme entstehen, weil sich einige Felder nicht immer übersetzen lassen und Adressumwandlung Datenbanken-Lookups erfordern.
\end{description}
\subsection{User Datagram Protocol}
Bei UDP handelt es sich um ein Layer-4-Protokoll.\cite{rfc768}
Es dient zur Übermittlung kurzer Nachrichten an andere Systeme und garantiert weder Zuverlässigkeit noch Einhaltung der Reihenfolge der Pakete beim Empfänger.
Die Adressierung geschieht über Ports (16 Bit).
Der Header enthält 4 Felder (je 16 Bit): Quellport, Zielport, Datagram-Länge und eine Checksumme.
\subsection{Transmission Control Protocol}
TCP ist ebenfalls ein Layer-4-Protokoll.\cite{rfc793}
Es garantiert eine Ankunft der Pakete in korrekter Reihenfolge.
Clienten sehen die Verbindung als bidirektionalen Datenstrom, tatsächlich findet die Kommunikation über Pakete statt. Die Kommunikation erfolgt durch TCP zustandsbehaftet.
TCP arbeitet Byte-orientiert.
\subsubsection{Paketstruktur}
Der Header des TCP-Fragments ist 20 Byte groß. Neben Sender, Empfänger, Länge, Quell- und Zielport, ACK-Nummer und optionalen Options sind wichtige Felder:
\begin{description}
\item [Sequence Number / Acknowledgement Number]: Zerlegung des Datenstroms in nummerierte Blöcke.
Größe der Blöcke ist variabel (Nagle Algorithmus).
Verwerfen von Segmenten mit fehlerhafter Prüfsumme.
Bestätigung empfangener Segmente.
Nicht unbedingt für jedes Segment einzeln (Windowing).
Erneuter Transport unbestätigter Segmente.
Zusammensetzung des Datenstroms auf Empfängerseite
\item [Flags]: dienen unter anderem zur Steuerung des Verbindungsauf- und –abbaus.
\begin{description}
\item [URG] - Urgent Flag (Urgent Pointer enthält
Sequenznummer, die bevorzugt übertragen werden soll)
\item [ACK] – Acknowledgement
\item [PSH] – Push (Paket wird sofort an Anwendung weitergeleitet, ohne Zwischenpuffer)
\item [RST] – Reset (Unterbrechung der Verbindung)
\item [SYN] – Synchronized (Aufbau der Verbindung)
\item [FIN] – Finish (Beenden der Verbindung)
\end{description}
\item [Window Size]: Anzahl der Daten, die gesendet werden können bis ein Acknowledgement gesendet werden muss (in Bytes oder mit speziellem Option Header nach RFC1323 \cite{rfc1323} auch bis zu 1GB, dann Linksverschiebung um bis zu 14 Bits, $2^{14} \cdot 64k = 1G$).
\end{description}
\subsubsection{Zustände}
Zum Aufbau einer Verbindung wird der \textbf{3-Way-Handshake} durchgeführt:
\begin{enumerate}
\item $\rightarrow$ SYN
\item $\leftarrow$ SYN + ACK
\item $\rightarrow$ ACK
\end{enumerate}
Ein Timeout findet typischerweise nach 75 Sekunden statt. Zum Abbau der Verbindung genügt das Senden und Quittieren eines FIN.
\subsubsection{Sliding Window \& Nagle-Algorithmus}
%PRÜFEN Sliding Window & Nagle Algorithmus
\textbf{Hinweis:} Konnte in den Folien hierzu nix groß finden, Infos stammen aus dem Tanenbaum\footnote{Das Kapitel heißt in der deutschen Fassung ernsthaft \emph{TCP-Schiebefenster}. Barbaren!}\cite{tanenbaum2003computer}.
Die Flusskontrolle von TCP funktioniert im Groben folgendermaßen:
Nach Erhalt der Daten quittiert der Empfänger das letzte Empfangene Segment im \texttt{ACK}-Feld.
Empfängt er beispielsweise eine 2kB große Nachricht mit den Segmenten 0 - 2048, sendet er \texttt{ACK=2048}.
Gleichzeitig ermöglicht das \textbf{Window Size} (WIN) Feld eine Angabe, wie viele Segmente der Empfänger noch annehmen kann, etwa weil er nur einen begrenzt großen Puffer hat, der erst gelesen und geleert werden muss.
Bei \texttt{WIN=0} wird dem Sender signalisiert, dass der Puffer des Empfängers voll ist und keine Daten empfangen werden können.
Ausnahmen sind hier priorisierte Nachrichten und \emph{window probes}\footnote{Fenstersondieranfragen}.
Letztere fordern den Empfänger dazu auf, wiederholt das nächste erwartete Byte und die Fenstergröße zu übermitteln, um Deadlocks vorzubeugen.
Es muss nicht zwingend jedes TCP-Segment einzeln bestätigt werden.
Anwendungen, wie Telnet oder SSH etwa, könnten für jeden Tastaturanschlag ein einzelnes Segment verschicken, was eigentlich zu bestätigen ist.
Stattdessen werden hier häufig \text{verzögerte Bestätigungen} eingesetzt.
Dabei kann bis zu 500ms auf weitere eintreffende Daten gewartet werden, die dann gleich mitbestätigt werden.
Da der durch viele kurze Pakete erzeugte Overhead die Effizienz der Kommunikation negativ beeinflusst, wird häufig der \textbf{Nagle-Algorithmus} eingesetzt.
Hierbei wird, wenn die Daten vom Sender byteweise kommen, immer nur das erste Byte gesendet und die nachfolgenden Nachrichten im Puffer gehalten.
Wird das erste Byte bestätigt, so werden alle sich im Puffer befindlichen Daten gesendet.
So werden viele kleine Daten in großen Segmenten zusammengefasst.
Aufgrund der Verzögerung kann diese Technik auch unerwünschte Folgen haben, etwa bei Spielen oder Konsolenanwendungen.
\subsubsection{TCP-Slow-Start}
%Prüfen TCP Slow Start
Die Geschwindigkeit der Datenübertragung zwischen Sender und Empfänger muss zuvor ausgehandelt werden.
TCP verwaltet das Congestion Window (Überlastungsfenster, cwnd), welches angibt, wie viele Bytes der Sender zeitgleich im Netz haben kann.
Kann der Empfänger etwa noch 64 kb puffern (Window Size, siehe letzter Abschnitt), das Überlastungsfenster beträgt allerdings nur 32 kb (etwa, weil langsame Teilstrecken vorhanden sind), so können eben nur 32 kb versendet werden.
Zur Ermittlung des CWNDs wird der Slow-Start-Algorithmus angewandt.
Dieser sendet eine exponentiell wachsende Anzahl $n$ von Segmenten (1,2,4,8...) an den Empfänger.
Der Sender erwartet $n$ ACKs, erhöht die Größe des CWNDs entsprechend und versendet die nächste Gruppe von Paketen.
Dies wird fortgesetzt, bis die \emph{Slow-Start-Threshold} erreicht ist.
Die exponentielle Phase ist beendet und die Anzahl der zu Übertragenden Segmente wird linear erhöht, bis die vom Empfänger festgelegte Fenstergröße (Window Size) erreicht und das Überlastungsfenster ermittelt ist.
Findet in der exponentiellen Phase ein Timeout statt (ACKs erreichen den Sender erst nach einer bestimmten Zeit), startet das Verfahren erneut mit einer geringeren \emph{Slow-Start-Threshold}.
Das Verfahren ist auch als \textbf{Jacobson-Algorithmus} bekannt.
\subsection{SCTP}
%PRÜFEN SCTP
Das \textbf{Stream Control Transmission Protocol}\cite{rfc4960} ist ein zuverlässiges (Reihenfolge, Duplikate, Veränderungen, Fehlende Daten) Transportprotokoll für Unicast-Kommunikation.
Es arbeitet nachrichten-orientiert, die Nachrichten\footnote{Auch als Chunks bezeichnet} haben eine interne Struktur.
SCTP ermöglicht multi-streaming, Daten können in parallelen Streams übertragen werden.
Dies ist beispielsweise dann hilfreich, wenn Webseiten mit mehreren Ressourcen übertragen werden.
Streams werden einzeln nummeriert (Retransmits müssen nur für den jeweiligen Stream erfolgen).
Daten-Chunks können einzeln bestätigt werden. (\textbf{Selective ACK})
Retransmits nur für fehlende Pakete.
Es bietet \textbf{Schutz gegen SYN Flooding} (Cookie-Mechanismus) - Anfrager bekommt Cookie und muss das nachfolgend wieder vorweisen, dies bedeutet keinen Ressourcenverbrauch beim Server:
Der Server speichert dazu bei einer Verbindungsanfrage (\texttt{INITPaket}) keine Zustandsinformationen, sondern schickt diese in Form eines Cookies (\texttt{INIT-ACK-Paket}) an den Client.
Der Client muss dieses Cookie in seine Antwort (\texttt{COOKIEECHO}-Paket) einfügen und wird damit vom Server als zum Verbindungsaufbau berechtigt erkannt.
Eine Bestätigung geschieht durch ein \texttt{COOKIE-ACK}-Paket.
SCTP ermöglich \textbf{Multi homing}.
Dabei haben beide Kommunikationspartner eine primäre und potentiell mehrere sekundäre (IP-)Adressen.
Auf diese Weise ist es möglich, eine stabile Verbindung aufrecht zu erhalten, auch wenn ein Interface inaktiv wird.
Offensichtlich können hierbei die Nachrichten unterschiedliche Pfade nutzen.
\subsubsection{Paketaufbau}
Ein allgemeines Paket besteht aus einem \textbf{Common Header} und mehreren nummerierten \textbf{Chunks}.
Der Header besteht aus \textbf{Source-} und \textbf{Destinationport}, einem \textbf{Verification Tag} und einer \textbf{Checksum}.
Chunks bestehen aus einem \textbf{Typen}, einer Reihe von \textbf{Flags}, einem \textbf{Längenfeld}, sowie dem \textbf{Wert (Value)}.
Letzteres setzt sich, je nach Chunk-Type, aus mehreren Feldern zusammen.
Weiter unten wird zur Veranschaulichung ein Payload Data Chunk beschrieben.
Der Typ des Chunks wird durch das 8-Bit lange Type-Feld bestimmt.
Dafür sind die Werte 0-254 verfügbar.
Wert 255 ist für eine zukünftige Erweiterung des Feldes reserviert.
Im Folgenden einige Beispiele für Typenfelder.
Weitere Werte sind verfügbar oder bereits reserviert.
\begin{multicols}{2}
\begin{enumerate}
\setcounter{enumi}{-1}
\item Payload Data \texttt{DATA}
\item Initiation \texttt{INIT}
\item Initiation Acknowledgement \texttt{INIT ACK}
\item Selective Acknowledgement \texttt{SACK}[sic!]
\item Heartbeat Request \texttt{HEARTBEAT}
\item Heartbeat Acknowledgement \texttt{HEARTBEAT ACK}
\item Abort \texttt{ABORT}
\item Shutdown \texttt{SHUTDOWN}
\item Shutdown Acknowledgement \texttt{SHUTDOWNACK}
\item Operation Error \texttt{ERROR}
\item State Cookie \texttt{COOKIE ECHO}
\setcounter{enumi}{13}
\item Shutdown Complete \texttt{SHUTDOWN COMPLETE}
\end{enumerate}
\end{multicols}
Das \textbf{Verification Tag} im Header wird vom Empfänger genutzt, um den Sender des Pakets zu validieren.
Es entspricht dem Wert des Initiate Tag\footnote{Das Initiate Tag ist ein Feld im \texttt{INIT Chunk}.}.
\textbf{Ausnahmen:} Beinhaltet das Paket einen \texttt{INIT Chunk}, ist das Verification Tag Null.
Wenn ein Paket einen \texttt{SHUTDOWN COMPLETE Chunk} enthält, bei dem das T-Bit gesetzt ist, so wird das Verification Tag vom \texttt{SHITDOWN ACK chunk} kopiert.
Zu guter Letzt wird das Verification Tag eines \texttt{ABORT chunks} vom ABORT-verursachenden Paket übernommen.
\textbf{Payload Data} Chunks sollen im Folgenden kurz besprochen werden.
Sie haben den Type-Wert 0.
Im Flag-Feld sind die letzten 3 Bits von besonderem Interesse, gefolgt vom Längen-Feld.
Die Flags haben haben die folgende Bedeutung:
\begin{description}
\item[U] | Ist das \emph{Unordered} Bit gesetzt, wird die Stream Sequence Number ignoriert.
Das bedeutet, dass empfangene Chunks, ohne vorher sortiert zu werden, an den darüberliegenden Layer weitergereicht werden.
Ist eine Nachricht fragmentiert, so wird dieses Bit bei jedem Fragment gesetzt.
\item[B] | Das \emph{Beginning} fragment Bit gibt an, dass es sich um das erste Fragment einer Nachricht handelt
\item[E] | Das \emph{Ending} fragment Bit gibt an, dass es sich um das letzte Fragment einer Nachricht handelt.
\end{description}
Das Value-Feld ist beim DATA Chunk wie folgt aufgebaut:
\begin{description}
\item[Transmission Sequence Number (TSN)] | enthält einen Wert zwischen 0 und $2^{32}-1$.
Sie identifiziert einen Chunk und wird zur Bestätigung des Erhalts genutzt.
Nach erreichen des maximalen Wert beginnt die Nummerierung wieder bei 0.
\item {Stream Identifier S} | identifiziert den Stream, zu dem der Chunk gehört.
Dies ist notwendig, wenn parallele Streams versendet werden.
\item {Payload Protocol Identifier} | identifiziert das genutzte Protokoll.
Das Feld wird von SCTP selbst nicht genutzt, sondern nur an höhere Schichten weitergereicht, beziehungsweise von Zwischenstationen interpretiert.
\item {User Data} | enthält letztendlich die zu transportierenden Daten.
\end{description}
\section{Adressierung}
% 030
\subsection{MAC-Adressen}
\begin{itemize}
\item Layer-2-Adressen für Ethernet
\item 6 Byte / 48 Bit groß
\item \emph{Eigentlich} weltweit eindeutig
\item \emph{Eigentlich} in Hardware gegossen, trotzdem fälschbar
\item Darstellung: Hexadezimal, Bits getrennt durch [.:-]
\item Bit 3 bis Bit 24 an Hersteller gebunden (z.B. 00-60-2F-xx-xx-xx für Cisco)
\item Broadcast: FF-FF-FF-FF-FF-FF
\end{itemize}
\subsection{VPI und VCI bei ATM}
ATM beruht auf Verbindungen, die sowohl fest eingerichtet oder nur für eine bestimmte Zeit geschaltet werden können. Für diesen Zweck wurden Virtual Paths (VPs) und Virtual Channels (VCs) definiert. Jede ATM-Zelle enthält im Header einen Virtual Path Identifier (VPI, 8 bzw. 12 Bit) und einen Virtual Channel Identifer (VCI, 16 Bit).\\
Ein ATM-Paket besteht aus 5 Byte Header und 48 Byte Nutzlast. Es gibt zwei Arten von ATM-Paket-Formaten:
\begin{enumerate}
\item NNI (Network-Network-Interface)\\
Wird von öffentlichen ATM-Netzen verwendet.
\item UNI (User-Network-Interface)\\
Wird für private ATM-Verbindungen genutzt. UNI besitzt ein GFC-Feld für eine (bis heute undefinierte) lokale Flusskontrolle zwischen Netz und User.
\end{enumerate}
\subsection{IP-Adressen}
Siehe Abschnitt \ref{subsec:ip}.
\subsection{Ports}
Für die Layer-4-Protokolle UDP und TCP werden 16-Bit-Adressen verwendet.
Diese werden als Ports bezeichnet.
Ports 0-1023 sind dabei standardisiert.
Wichtige Portnummern sind beispielsweise:
\begin{center}
\begin{tabular}{|c|c|c|c|}
\hline Port & TCP & UDP & Beschreibung \\
\hline 20 & Ja & Nein & FTP - Datenübertragung \\
\hline 21 & Ja & Nein & FTP - Kontrolle \\
\hline 22 & Ja & (Ja) & SSH \\
\hline 23 & Ja & Nein & Telnet \\
\hline 25 & Ja & Nein & SMTP \\
\hline 53 & Ja & Ja & DNS \\
\hline 80 & Ja & Nein & HTTP \\
\hline 110 & Ja & Nein & POP3 \\
\hline 123 & Nein & Ja & NTP \\
\hline 443 & Ja & Nein & HTTPS \\
\hline
\end{tabular}
\end{center}
\subsection{URIs, URNs und URLs}
\begin{description}
\item [Uniform Resource Identifier]: String; Benennt oder identifiziert eine Ressource z.B. \textbackslash\textbackslash139.30.3.23\textbackslash iukp\textbackslash beispiel.txt
\item [Uniform Resource Name]: Sonderform der URI, die eine Ressource in einem bestimmten
Namespace benennt | urn:ip-addr:139.30.3.23
\item [Uniform Resource Locator]: Sonderform der URI, die zusätzlich das Protokoll angibt, über das die Ressource erreichbar ist z.B. http://139.30.3.23/beispiel.txt
\end{description}
\subsection{*cast}
\begin{description}
\item[Unicast]: Einer sendet an einen, wie beispielsweise in einer TCP-Verbindung für HTTP. Adressierung durch Angabe des Empfängers.
\item[Broadcast]: Einer sendet an alle, wie beispielsweise in ARP oder DHCP. Hierzu werden spezielle Adressen (MAC: FF-FF-FF-FF-FF-FF; IP: höchste Adresse im Subnetz) verwendet. Broadcastbereiche sollten klein gehalten werden, um möglichst wenig Teilnehmer zu belästigen.
\item[Multicast]: Einer sendet an viele Mitglieder einer Gruppe. Siehe Abschnitt \ref{sec:muliticast}.
\item[Concast]: Viele senden an einen, Nachrichten werden so früh wie möglich zusammengefasst. Verhindert Implosion, Überlastung des Empfängers. Beispielswiese sinnvoll, wenn Fehlermeldungen zusammengefasst werden können. Keine direkte Unterstützung in IP, MAC, Ethernet
\end{description}
\subsection{ICMPv6 Neighbor Discovery Protocol (NDP)}
\begin{itemize}
\item Dient als Ablösung von ARP
\item Mechanismus von IPv6 für Auflösung (Übersetzung) von Netzwerkadressen in Hardwareadressen\cite{rfc4861}.
\item Es existieren verschiedene Typen:
\begin{itemize}
\item Router Solicitation – Type 133 \\
Alle Router im selben Netz werden aufgefordert, sich zu melden und senden an Router-Multicast-Adresse
\item Router Advertisement – Type 134 \\
Router verkünden Anwesenheit im Netz, periodisch oder als Antwort auf \textit{Router Solicitation}
\item Neighbor Solicitation – Type 135 \\
Zur Auflösung von IPv6-Adressen zu Link-Layer-Adressen. Umgesetzt als Broadcast an Link-Layer-Broadcast-Adressen.
\item Neighbor Advertisement – Type 136
\item Redirect – Type 137 \\
Router teilt mit, dass es besseren next hop gibt
\end{itemize}
\end{itemize}
%290
\subsection{Domainverwaltung}
\begin{itemize}
\item Adressierung mit Hilfe von IP-Adressen ist für menschliche Nutzer sehr unpraktisch. Daher werden Namen zur Adressierung verwendet.
\item Namen sind in einem paketvermittelten Netzwerk unpraktikabel. Daher ist eine Umwandlung der Namen in IP-Adressen notwendig.
\item Domain Name Service (DNS) erledigt diese Aufgabe.
\item Verteilung der Verantwortlichkeiten.
\begin{itemize}
\item Keine einzelne Institution verwaltet alle Namen im Baum.
\item NIC verwaltet die Top-Level Domain.
\item Die Verwaltung der unteren Ebenen wird entsprechend verteilt.
\end{itemize}
\item Wird die Verantwortung für eine Zone delegiert, dann ist die entsprechende "`Person"' für diese Zone verantwortlich (Zerlegung der Aufgabe in kleinere Teilaufgaben).
\begin{itemize}
\item Zuordnung von Namen und IP-Adressen.
\item Betrieb von Primary Name Server und mindestens ein Secondary Name Server.
\end{itemize}
\end{itemize}
\subsection{Informationen in der Domain Registry}
\begin{itemize}
\item IPv4-Adressen (A-Records)
\item IPv6-Adressen (AAAA-Records)
\item Adresse des Mail-Servers (MX-Records)
\item Referenzen auf andere Einträge (CNAME)
\end{itemize}
\section{ARP, RARP}
% Ende 030, 040
ARP (Address Resolution Protocol) wandelt Layer-3-Adressen in Layer-2-Adressen um.
Es beschränkt sich nicht auf das Erfragen von MAC-Adressen zu IP-Adressen, sondern ermöglicht beispielsweise auch ATM ARP, IP over FDDI und IP over Token Ring.
\begin{itemize}
\item Erfragt für gegebene IP-Adresse eine MAC-Adresse.
\item Host erzeugt Broadcast.
\item Der angefragte Host darf darauf antworten (Unicast).
\item Nachdem der Sender der Broadcast-Nachricht die Antwort erhalten hat, kann er die IP-Adresse der Ethernet-Adresse zuordnen.
\item Diese Ethernet-Adresse wird dann für alle folgenden Pakete an diese Internet-Adresse verwendet, solange bis die Cache-Zeit abgelaufen ist.
\item RFC 826 \cite{rfc826}
\end{itemize}
\subsection{Einsatzfälle}
\begin{enumerate}
\item Zwei Hosts möchten im selben Netzwerk (ausschließlich Layer 2) miteinander kommunizieren und kennen nur die Layer-3-Adresse (z.B. IP-Adresse) des Empfängers.
\item Ein Host benötigt die Layer-2-Adresse des Gateways, um andere Netze zu erreichen (Sonderfall des zuvor genannten)
\item Zwei Gateways wollen kommunizieren.
\end{enumerate}
\subsection{Paketstruktur}
Wichtige Felder eines ARP-Requests sind:
\begin{description}
\item[Hardware type]: Kennzeichen für die verwendeten Hardware-Adressen (1 für Ethernet, 2 Byte)
\item[Protocol type]: Kennzeichen für die verwendeten Protokoll-Adressen (L3) (0x0800 für IPv4, 2 Byte).
\item[Hardware length]: Länge der Hardware-Adresse in Bytes (6 für Ethernet, 1 Byte)
\item[Protocol Length]: Länge der Protokoll-Adressen (L3) (4 für IPv4, 1 Byte)
\item[Operation]: Unterscheidung von 1 Request und 2 Reply, da für beides gleiche Pakete verwendet werden (2 Byte, warum zur Hölle reserviert man für 2 Werte 2 Byte?)
\end{description}
Es folgen Sender hardware address, Sender protocol address, Target hardware address und Target protocol address
\subsection{ARP-Caching}
Um nicht für jedes IP-Paket einen neuen ARP Request zu stellen, werden die Ergebnisse zwischengespeichert.
Typischerweise 10 Minuten lang.
Kommt es während der Cache-Zeit zu einem Fehler (Host nicht erreichbar), wird erneut ein ARP-Request ausgeführt.
\subsection{ARP-Announcements}
Der anfragende Host sendet bekanntlich einen Broadcast, alle Host im gleichen Netz können folglich diese Information ebenfalls verwenden, und auf diese Weise eigene Anfragen sparen.
Anwendungen:
\begin{itemize}
\item Unterbrechungslose Übernahme einer Protokoll-Adresse (z.B. IP-Adresse) in hochverfügbaren Systemen.
\item Der anfragende Host kann auf diese Weise feststellen, ob eine Protokoll-Adresse bereits vergeben ist (Gratuitous ARP). Dieser Mechanismus wird bei IP-Autoconf verwendet.
\end{itemize}
IP-Autoconf \cite{rfc3927} ist eine einfache Möglichkeit zur Adresskonfiguration ohne Server (DHCP, RARP).
\begin{itemize}
\item Host wählt zufällig eine Adresse.
\item Überprüft mittels Gratuitous ARP, ob diese Adresse bereits vergeben ist.
\item Falls ja, andere Adresse zufällig wählen und erneut überprüfen.
\item Falls nein, Adresse benutzen und andere ARP Requests für diese Adresse beantworten.
\end{itemize}
\subsection{ARP-Spoofing}
Da ARP nicht kryptografisch abgesichert ist, kann jeder Host auf ARP Requests antworten oder ARP Announcements erzeugen.
Ziel ist das Umleiten von Datenpaketen.
Es gibt Programme, die Änderungen der Hardware-Adressen erkennen (z.B. arpwatch).
Der Administrator muss dann die Ursache überprüfen.
\subsection{Proxy ARP}
Wird von speziellen Routing-Protokollen verwendet.
Jeder Nachbar (One-Hop-Neighbor), der auf der Route zum Ziel liegt, beantwortet einen eintreffenden ARP-Request mit seiner Hardware-Adresse.
Pakete werden so von Host zu Host weitergeleitet
\subsection{Reverse ARP}
Erfragt eine IP-Adresse bei bekannter MAC-Adresse und ist nicht unbedingt für die Funktionsfähigkeit von IP über Ethernet notwendig.
RARP wird in RFC 903 \cite{rfc903} standardisiert.
Haupteinsatzzweck ist die automatische Konfiguration der Protokoll-Adresse.
Dabei sendet der Host einen RARP-Request mit der eigenen Hardware-Adresse (z.B. MAC).
Ein RARP-Server beantwortet diesen Request und liefert die hinterlegte Protokoll-Adresse (z.B.IP).
Da RARP Link-Local-Broadcasts verwendet, ist ein RARP-Server pro Netz notwendig.
Benutzt gleiche Paketstruktur wie ARP, lediglich anderen EtherType\footnote{Feld im Ethernet-Header, siehe Abschnitt \ref{subsec:ethernet}} (0x8035)
\section{DNS und WHOIS}
% 050
Die Aufgabe des Domain Name Systems/Service ist die Übersetzung von (Layer-4) IP-Adressen in, für den menschlichen Gebrauch besser verwendbare Namen.
Der Name wird dabei aus hierarchischen Domains, getrennt durch Punkte (.) zusammengesetzt.
\subsection{Aufgaben von Namensdiensten}
\begin{itemize}
\item Ortstransparenz (Physikalische Adressen versteckt, Durch logische Adressen ersetzt, Reduziert Komplexität)
\item Namensdienste (Basis für Ortstransparenz)
\item Andere Bezeichnung
\end{itemize}
\subsection{Domains}
Direkt unter der Wurzel steht hierbei die sogenannte Top-Level-Domain.
Bei Top-Level-Domains wird zwischen \textbf{länderspezifischen} (ccTLD) und \textbf{generischen} (gTLD) Domains unterschieden.\\
Länderspezifische, bestehend aus zwei Buchstaben, werden durch lokal verantwortliche Institutionen\footnote{Network Information Centers z.B. DENIC für .de} verwaltet.\\
Generische werden durch die \textbf{ICANN} oder beauftragte Institutionen vergeben und haben drei oder mehr Buchstaben. Bei der Vergabe gilt das \emph{first come, first serve}-Prinzip.
Für die Namensbildung gelten gewisse Regelungen, z.B. Ziffern 0-9, Bindestriche, Buchstaben, sowie einige ausgewählte lokale Buchstaben. Groß- und Kleinschreibung werden nicht unterschieden.
Letztere müssen ASCII-kodierbar sein (ACE)\cite{rfc3490}.
Jede (Teil-) Domain ist mindestens 3 und maximal 63 Zeichen lang, insgesamt ist der vollständige Pfad jedoch 255 Zeichen lang.
\subsection{Domainanmeldung}
Network Information Center (NIC) ist für Vergabe und Verwaltung der Domains zuständig.
Folgende Daten sind bei der Domainanmeldung von Interesse:
\begin{description}
\item[Domaininhaber](Holder): Person, der die Domain \emph{gehört}
\item[Administrativer Ansprechpartner]: Vom Inhaber Bevollmächtiger, darf Entscheidungen treffen (Admin-C)
\item[Technischer Ansprechpartner, Zonenverwalter]: Typ. Kontaktadresse der Firma (Tech-C, Zone-C)
\item [Technische Daten]: z.B. Nameserver
\end{description}
Hoster tragen oft nicht den Inhaber selbst als Admin-C ein, sondern sich selbst.
Außerdem stellen sie in der Regel den Nameserver zur Verfügung.
Die Registrierung einer Domain gilt immer für einen bestimmten Zeitraum.
Ein Wechsel erfordert eine Freigabe beim alten Provider durch Inhaber oder Admin-C.\\
Alle Informationen werden in einer Datenbank abgelegt und in regelmäßigen Abständen erfolgt die Übertragung in das Domain Name System (DNS), dann ist die Domain nutzbar. (Bei der wird DENIC zweimal täglich übertragen)
\subsection{Probleme}
\begin{itemize}
\item Häufig benötigt ($\rightarrow$ Caching für Geschwindigkeit)
\item Dauernd benötigt ($\rightarrow$ Replikation für Verfügbarkeit)
\item Keine 2 Rechner dürfen den gleichen Namen haben ($\rightarrow$ Hierarchischer Namensraum)
\item Zentrale Verwaltung skaliert schlecht ($\rightarrow$ Datenbank verteilen)
\item Zu viel Traffic ($\rightarrow$ Datenbanken verteilen.)
\end{itemize}
\subsection{Weiteres Bla zu DNS}
Beim Domain Name System handelt es sich um ein \textbf{sehr großes}, \textbf{hierarchisch strukturiertes}, \textbf{verteiltes}, \textbf{repliziertes} und \textbf{lokal verwaltetes System} \cite{rfc1034,rfc1035}.\\
Aus dem hierarchischen Benennungsschema resultiert das verteilte Datenbanksystem des DNS.
Jede Domain bestimmt selbst, wie die unter ihr liegenden Domains zugewiesen werden, hat dementsprechend eigene Verantwortlichkeiten.
Ist ein Namensserver für eine solche Zone verantwortlich, kann er Anfragen autoritativ beantworten(Autoritäskonzept).
Andernfalls wird die Anfrage aus dem Cache beantwortet oder an einen anderen Nameserver delegiert (Delegationskonzept).
Das kann der Nameserver einer Subdomain oder (default) ein Root Name server sein.\\
Die Aufteilung in die Zonen erfolgt anhand von Punkten - Bsp: www.spiegel.de
\subsection{Servertypen}
\begin{description}
\item[Root Nameserver]: sind Server zur Namensauflösung an der Wurzel des DNS. Die Zone der Root-Server umfasst Namen und IP-Adressen aller Nameserver aller Top-Level-Domains (TLD).
\item[Primary Server]: Ist Hauptserver einer Domain und autorisiert, Anfragen zu seiner Domain verbindlich zu
beantworten.
Er verfügt über alle Daten dieser Domain, welche in Zonen-Dateien abgelegt sind, die der Verwalter des
Servers erstellt
\item[Secondary Server]: Ist ebenfalls autorisiert, verbindliche Antworten zu seiner
Domain zu liefern, lädt die Domain-Datenbank von einem Primary Server und aktualisiert sie bei Bedarf
\item[Caching-only Server]: Verfügt über keine eigenen Domain-Informationen.
Fragt bei dem für die Domain zuständigen Primary oder Secondary Server nach und speichert die Antwort zwischen.
Ist zur Beantwortung von Anfragen zu einer Domain "`nicht autorisiert"' (kann die Genauigkeit und Aktualität nicht gewährleisten)
\item[Slave Server]: Reicht alle Anfragen, die er selbst nicht aus seinem eigenen Cache beantworten kann, an eine zuvor festgelegte Liste von anderen Servern (Forwarders) weiter.
Forwarders fragen ihrerseits den zuständigen Server und speichern das Ergebnis zwischen (Caching)
\end{description}
\subsection{Server kennt die Antwort nicht}
\begin{enumerate}
\item \textbf{Rekursive Query}: Der angefragter Server soll Antwort selber besorgen und an Client senden. Dies kann aber nicht jeder Server (z.B. Top Level Server).
\item \textbf{Iterative Query}: Angefragter Server soll Liste anderer Nameserver übergeben, welche die Antworten haben könnten.
\end{enumerate}
\subsection{DNS Nachrichten}
Besitzen verschiedene Header-Informationen um verschiedenes zu kennzeichnen:
\begin{itemize}
\item Ob es eine Query oder Response ist \textbf{(QR)}
\item Welch ein Query-Typ es ist (Standard, iterativ, rekursive)
\item Von wem die Query beantwortet werden soll (Server, "`authoritative answer"',...)
\end{itemize}
Es wird außerdem angegeben von welcher Art die Anfrage ist \textbf{(Query Type)}
\begin{description}
\item[SOA]: Liefert den Namen der primären Informationsquelle über die Zone des Nameservers, die E-Mail-Adresse des Verwalters, eine eindeutige Seriennummer und verschiedene Flags und Timeouts
\item[A]: Datensatz enthält eine 32 Bit lange IP - Adresse für einen bestimmten Host
\item[MX]: Name des Hosts, der E-Mails für eine betreffende Domäne annehmen kann
\item[NS]: Spezifiziert den zuständigen Nameserver für eine Domäne - Jede DNS-Datenbank hat normalerweise einen NS-Satz für jede Domäne der obersten Ebene
\item[CNAME]: Ermöglicht das Erstellen von Alias-Namen
\item[PTR]: Pointer auf einen anderen Namen. Ermöglicht durch die Umkehrung des Address Records das Auffinden eines Host-Names anhand einer IP-Adresse.
\end{description}
\subsection{Resource Records}
Ein Resource Record (RR) ist die grundlegende Informationseinheit im DNS.
Mehrere Ressourcensätze (Resource Records) können mit einer Domäne in Verbindung stehen. Ein üblicher Ressourcensatz für einen einzelnen Host ist seine IP - Adresse (es gibt aber noch wesentlich mehr Arten). Eine Übergabe eines Domännamens ans DNS über einen Resolver liefert die Ressourcensätze in Verbindung mit dem Namen.\\
\noindent Ressourcensatz ist 5er Tupel (binär codiert) - oft auch als ASCII Text dargestellt
\begin{description}
\item[Domain Name]: Name auf den sich die folgenden Daten beziehen
\item[Type]: Spezifiziert einen der RR Type Codes
\item[Class]: Gewöhnlich Wert = IN für Internet Daten.
\item[Time-to-live]: Anzahl der Sekunden, die ein RR vom Client gecacht werden kann
\item[Resource Data Length]: Gibt die Länge der folgenden Resource Data an
\end{description}
\subsection{WHOIS}
WHOIS ist ein Protokoll, mit dem von einem verteilten Datenbanksystem Informationen zu Internet-Domains und IP-Adressen und deren Eigentümern abgefragt werden können.\\
Aus Datenschutzgründen können Informationen über Eigentümer von .de Domains nicht mehr wie früher über das whois-Protokoll abgefragt werden. Dies geht nur noch über eine Seite der DENIC.
\section{Timeouts, ACK, Bestätigungen}
\subsection{Begriffe}
\begin{itemize}
\item \textbf{Positive Bestätigung}
\begin{itemize}
\item Bestätigung, wenn ein Protokollschritt erfolgreich ausgeführt wurde.
\item Wartezeit ist ein Nachteil.
\item Reaktion auf verloren gegangene Bestätigungen muss
vorgesehen werden.
\end{itemize}
\item \textbf{Negative Bestätigung}
\begin{itemize}
\item Fehlermeldung, wenn ein Protokollschritt nicht erfolgreich war.
\item Ausbleiben der Fehlermeldung ist nur eine notwendige
Bedingung, keine hinreichende, dafür, dass Protokollschritt
erfolgreich war.
\end{itemize}
\item \textbf{Timeouts}
\begin{itemize}
\item Ein Kontrollsignal in einem technischen System, das die Überschreitung der normalerweise für eine Aktion benötigten Zeit anzeigt. Damit sollen unkontrollierte Zustände (Warten, Endlosschleifen) verhindert und die Systemressourcen geschont werden.\cite{timeout}
\end{itemize}
\item \textbf{Acknowledgements}
\begin{itemize}
\item Ein ACK dient der Bestätigung eines empfangenen Datenpakets.
\end{itemize}
\end{itemize}
\subsection{TFTP - Trivial File Transfer Protocol}
\begin{itemize}
\item TFTP ist ein vereinfachtes Datei-Übertragungs-Protokoll, das auf UDP aufbaut (FTP verwendet TCP) \cite{rfc1350}.
\item Das Ziel von TFTP ist zum einen ein einfacher \textbf{Datentransfer} und zum anderen das Ermöglichen des \textbf{Bootens einer Workstation} ohne Diskettenlaufwerk.
\item An TFTP gestellte Anforderungen sind, dass es kompakt sein soll (um ins ROM zu passen), keine Authentifikation.
\item TFTP ist ein stop-and-wait Protokoll.
\begin{itemize}
\item Kein neuer Protokollschritt, solange nicht der vorhergehende erfolgreich (korrekt) abgeschlossen ist.
\item Niedrige Protokoll-Leistung (Datendurchsatz).
\item Dafür einfache Implementierung.
\item Geänderte Reihenfolge stellen kein Problem dar, da stop-and-wait Protokoll nur jeweils ein Paket hängig hat.
\end{itemize}
\item Alternative
\begin{itemize}
\item Positive Bestätigung kann verzögert werden (sliding window).
\item Übersendung mehrerer Pakete und dann erst warten auf eine Bestätigung.
\item Höherer Datentransfer (Beispiel TCP).
\end{itemize}
\item Doppelte Pakete werden aufgrund der Blocknummer erkannt, während verlorene Pakete über Timeouts beider Partner erkannt werden.
\item TFTP Nachricht hat keine Checksumme, Datenveränderungen müssen durch die UDP-Checksumme abgefangen werden.
\item Retransmission Timer
\begin{itemize}
\item Wert sollte je timeout um bestimmten Faktor multipliziert werden (sog. Exponential backoff).
\item Retransmission timeout je Paket = 5 s.
\item Retransmission timeout für \glqq Verbindung\grqq = 25 s.
\end{itemize}
\end{itemize}
\begin{center}
\includegraphics[width=10cm]{img/tftp.png}
\end{center}
% 070
\section{Routing}
% 080, 090, 095, 100, 110, 120, 130
Routing optimiert den Weg zum Ziel einzelner Pakete.
Dabei gewährt es Dienstgüten (z.B. Konstante Latenz, Bitrate, Durchsatz, sowie Priorisierung von Paketen) und minimiert Kosten.
\subsection{Begriffe}
\begin{description}
\item[Router] - Gerät, welches mindestens zwei unterschiedliche Netzwerke verbindet.
Ist in der Lage, den besten Weg für eine Nachricht durch ein Netzwerksystem bis zum Empfänger zu bestimmen.
\item[Routing] - bezeichnet das Transportieren von Daten innerhalb eines Netzes
\item[Passives/Source Routing] - Route ist durch das zu versendende Datenpaket vorgegeben (z.B. im Header enthalten)
\item[Aktives Routing] - Router kann sich den Versandweg selbst aussuchen
\item[Globales Routing] - Ein Knoten hat vollständige Informationen zu Topologie und Kosten.
Informationen über das komplette Netz sind vorhanden.
Optimierung läuft an einer Stelle oder repliziert an mehreren.
\item[Dezentrales Routing] - Keine vollständigen Informationen in einem Knoten.
Jeder Knoten kennt zunächst (initial) nur die Kosten verbundener Links.
Berechnung erfolgt iterativ und dezentral.
\item[Distanz-Vektor-Algorithmen] - Kein Knoten hat Wissen über das komplette Netz und kennt daher nie die komplette Route von einer Quelle zu seiner Senke.
\item[Link-State-Algorithmen] - Knoten haben Wissen über die gesamte Netztopologie.
Daher haben im stabilen Zustand alle Knoten die gleiche Sicht auf das Netz.
\item[Statisches/nichtadaptives Routing] - Ist beim Starten/Hochfahren des Systems fixiert.
\item[Dynamisches/adaptives Routing] - Routen ändern sich im laufenden Betrieb und passen sich so an Änderungen von Topologie, Netzlast, Kosten etc. an.
Setzt zwingend ein Protokoll voraus.
\end{description}
\subsection{Anforderungen}
Die Anforderungen an Routing-Algorithmen sind:
\begin{description}
\item[Einfachheit] - Algorithmus muss in kurzer Zeit mit wenig Ressourcen berechnet werden können.
\item[Robustheit] - Bewältigung von Änderungen der Topologie.
\item[Stabilität] - Erreichung eines stabilen Zustandes.
\item[Fairness] - Alle Knoten werden gleich bedient.
\item[Optimalität] - Gemäß der Kostenfunktion günstigster Weg wird gefunden.
\end{description}
\textbf{Anmerkung:} Ohne weiteres können sich diese Anforderungen widersprechen!
So kann etwa die Kommunikation der Knoten $x \rightarrow x'$ die Kommunikation $a \rightarrow a', b \rightarrow b' und c \rightarrow c'$ stark negativ beeinflussen und damit den Gesamtdurchsatz (Optimalität) verringern.
\subsection{Spannbäume}
\textbf{Optimalitätsprinzip:} \emph{Wenn ein Router J auf dem optimalen Pfad von Router I zu Router K liegt, dann gehört der optimale Weg von J nach K zum gleichen Pfad}\cite{tanenbaum2003computer}.
So lässt sich eine allgemeine Aussage über optimale Pfade treffen, ohne dass konkrete Kenntnisse der Topologie des Netzwerkes vonnöten sind.
Alle optimalen Routen von den Knoten zu einem bestimmten Ziel (Senke), bilden einen \textbf{Spannbaum}\footnote{Im Tanenbaum\cite{tanenbaum2003computer}, welcher für die Entstehung des Skripts offensichtlich Modell gestanden hat, wird dieser als \textbf{Quelle-Senke-Baum} (sink tree) bezeichnet}.
\begin{itemize}
\item Senke muss nicht zwangsläufig eindeutig sein (auf den
gleichen Pfadstrecken kann es auch andere Bäume geben).
\item Da Senke ein Baum ist, enthält sie keine Schleifen.
\item Pakete werden auf einer endlichen, begrenzten Anzahl von
Teilstrecken übertragen.
\end{itemize}
\subsection{Algorithmen}
\textbf{Eingabe:} Graph G des Netzes, wobei jeder Knoten im Graphen einen Router und jede Kante eine Übertragungsleitung darstellt.\\
\textbf{Problemstellung:} Finde für einen Startknoten $s$ und einen Endknoten $e$ eines gewichteten Graphen $G = (V,E)$ und der Kostenfunktion $k(E)$, einen Weg zwischen $s$ und $e$ mit minimalen Kosten bezüglich k.
\subsubsection{Dijkstra-Algorithmus und Link-State-Routing}