Berichte zur Rechnerarchitektur - uni-jena.deehp-head/c3/tcpip.pdf · 2010. 10. 28. · Berichte...

Berichte zur RechnerarchitekturBand 12 ISSN 0949-3042 Nr. 1 (2006)

'

&

$

%

Technischer Bericht

Friedrich-Schiller-Universität JenaInstitut für InformatikLehrstuhl für Rechnerarchitekturund -kommunikation

Hrsg.: Prof. Dr.-Ing. W. Erhard

Seminarband

„TCP/IP Illustrated“

Christian Kauhaus (Hrsg.)

Christian Kauhaus (Hrsg.)Seminarband „TCP/IP Illustrated“

Berichte zur Rechnerarchitektur

Seminarband

TCP/IP Illustrated

Christian Kauhaus (Hrsg.)

Sommersemester 2006

Herausgeber der Reihe:Prof. Dr.-Ing. Werner ErhardLehrstuhl für Rechnerarchitektur und -kommunikationInstitut für InformatikErnst-Abbe-Platz 1–207743 Jena, Deutschland

ISSN 0949-3042

23. Dezember 2006

c© Friedrich-Schiller-Universität Jena

Inhaltsverzeichnis

0. Vorwort 1

I. Internetschicht 3

1. Internet Protocol (IP) 51.1. Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.1.1. Das TCP/IP-Referenzmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.1.2. Einordnung des IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.2. Aufgaben des IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.3. Eigenschaften des IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.4. Das IP-Datagramm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.4.1. Aufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.4.2. Der IP-Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.5. IP-Adressierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.5.1. Die Transportprotokollnummer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.5.2. Die Internet-Adresse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.5.3. Classful Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.5.4. Subnet Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.5.5. Classless Inter-Domain Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

1.6. IP-Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131.7. IP Version 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

1.7.1. Adressierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141.7.2. Der IPv6-Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141.7.3. IPv6-Neuerungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151.7.4. Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

1.8. Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2. Internet Control Message Protocol (ICMP) 172.1. Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.2. Einordnung des ICMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.3. Aufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.4. Aufgaben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.4.1. Fehlermeldungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.4.2. Anfragen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.5. Kleiner Exkurs: Mobile IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3. IP – Routing und Traceroute 293.1. Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.2. Grundlagen des IP-Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.2.1. Optimale Wege in Netzwerken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.3. Statisches (Next-Hop-)Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.3.1. Versenden von Daten im Netzwerk . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.3.2. IP-Routing-Algorithmus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.3.3. Routing-Tabelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

V

Inhaltsverzeichnis

3.3.4. Aufbau und Modifikation der Routing-Tabelle . . . . . . . . . . . . . . . . . . . . . . 343.4. Traceroute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.4.1. Funktionsweise von Traceroute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353.4.2. Ausgabe von Traceroute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353.4.3. Anwendungsmöglichkeiten von Traceroute . . . . . . . . . . . . . . . . . . . . . . . 37

3.5. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4. Dynamic Routing: RIP, OSPF, BGP 394.1. Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394.2. Dynamic Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394.3. Routing Information Protocol (RIP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.3.1. Nachrichtenformat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394.3.2. Standard-Operationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404.3.3. Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.3.4. Nachteile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.4. Open Shortest Path First (OSPF) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.5. Autonome Systeme und das Border Gateway Protocol . . . . . . . . . . . . . . . . . . . . . . 424.6. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

II. Transportschicht 45

5. User Datagram Protocol (UDP) 475.1. Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475.2. UDP im Detail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

5.2.1. Eigenschaften . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475.2.2. Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

5.3. Experimente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485.3.1. Vorüberlegungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485.3.2. Experiment: Input-Queue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485.3.3. Experiment: Restricting Local IP Address . . . . . . . . . . . . . . . . . . . . . . . . 495.3.4. Experiment: Restricting Foreign IP Address . . . . . . . . . . . . . . . . . . . . . . . 49


6. Transmission Control Protocol (TCP) – Interactive Data Flow 516.1. Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 516.2. Eigenschaften von TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 516.3. TCP-Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

6.3.1. Aufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 536.3.2. TCP-Pseudoheader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

6.4. Datentransfer mittels TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 546.4.1. Experiment: Interaktiver Datenaustausch . . . . . . . . . . . . . . . . . . . . . . . . 556.4.2. Experiment: Delayed Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . 566.4.3. Experimente: Nagle-Algorithmus . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

7. TCP – Verbindungsaufbau und -abbau 597.1. Verbindungsaufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

7.1.1. Drei-Wege-Verbindungsaufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 597.1.2. Wiederholte Übermittlung von SYN-Segmenten . . . . . . . . . . . . . . . . . . . . 61

7.2. Verbindungsabbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 627.2.1. Allgemeiner Vier-Wege-Verbindungsabbau . . . . . . . . . . . . . . . . . . . . . . . 627.2.2. Half-Close . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

7.3. Zustandsdiagramm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

VI

Inhaltsverzeichnis

7.3.1. Der Zustand TIME_WAIT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 667.4. Resetsegmente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

7.4.1. Verbindungsaufbau zu einem unbesetzten Port . . . . . . . . . . . . . . . . . . . . . 677.4.2. Verbindungsabbruch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67


8. TCP Bulk Data Flow 698.1. Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

8.1.1. Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 698.1.2. Sliding Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 708.1.3. Window Scaling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

8.2. Congestion Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 728.2.1. Slow Start . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 728.2.2. Congestion Avoidance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

8.3. Experiment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 738.3.1. Idee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 738.3.2. Durchführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 738.3.3. Beobachtungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

8.4. Weitere Probleme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 778.4.1. Long Fat Pipe Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 778.4.2. Silly Window Syndrome . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

8.5. Abschließendes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

9. TCP – Timeout und Retransmission 799.1. Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 799.2. TCP Timer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

9.2.1. Connection Establishment Timer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 799.2.2. Delayed Acknowledgement Timer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 799.2.3. Keep Alive Timer und Idle Timer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 809.2.4. TCP Persist Timer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 809.2.5. Maximum Segment Life Wait Timer . . . . . . . . . . . . . . . . . . . . . . . . . . . 809.2.6. Retransmission Timer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

9.3. TCP Retransmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 819.3.1. Retransmission via Timeout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 819.3.2. Fast Retransmit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

9.4. Verbesserungen für WLAN-Netzwerke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 849.4.1. NewReno-Modifikation des Fast Recovery . . . . . . . . . . . . . . . . . . . . . . . 849.4.2. Erweiterung der SACK-Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 849.4.3. SACK-basierter Loss-Recovery-Algorithmus . . . . . . . . . . . . . . . . . . . . . . 849.4.4. Forward RTO-Recovery (F-RTO) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

9.5. SYN-Flood-Angriff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 849.6. Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

III. Anwendungsschicht 87

10.Domain Name System (DNS) 8910.1. Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

10.1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8910.1.2. Was ist das DNS? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8910.1.3. Entstehung des DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

10.2. Konzepte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9010.2.1. Lexikalischer Aufbau eines Namens . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

VII

Inhaltsverzeichnis

10.2.2. Namensraum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9010.2.3. Zonen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9010.2.4. Resource Records . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9210.2.5. Inverssuche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

10.3. DNS-Protokoll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9310.3.1. Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9310.3.2. Question Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9410.3.3. Answer, Authority und Additional Section . . . . . . . . . . . . . . . . . . . . . . . . 9410.3.4. Kompressionsschema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

10.4. DNS-Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9510.4.1. Resolver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9510.4.2. Nameserver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9510.4.3. Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9610.4.4. Beispiel für eine DNS-Anfrage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

10.5. Erweiterungen, Wirtschaft und Politik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

11.File Transfer Protocol (FTP) 9911.1. Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9911.2. FTP-Verbindungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

11.2.1. Die Steuerverbindung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10011.2.2. Die Datenverbindung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

11.3. Verbindungs-Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10211.3.1. Verbindungsaufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10211.3.2. Datenübertragung und Übertragungsmodi . . . . . . . . . . . . . . . . . . . . . . . . 10611.3.3. Verbindungsabbau und Wiederaufnahme der Übertragung . . . . . . . . . . . . . . . 107

11.4. Das File eXchange Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10811.5. Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

12.Simple Mail Transfer Protocol (SMTP) 11112.1. Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11112.2. Funktionsweise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11112.3. SMTP-Befehle und SMTP-Status-Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

12.3.1. SMTP-Befehle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11212.3.2. SMTP-Status-Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

12.4. Extended SMTP (ESMTP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11212.4.1. AUTH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11412.4.2. STARTTLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11412.4.3. ESMTP-Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

12.5. Mail-Relaying . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11512.5.1. Offenes Mail-Relay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11512.5.2. SMTP-Relay-Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11512.5.3. Beispiele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

12.6. E-Mail-Routing über SMTP und DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11612.6.1. Beispiel: MX-Record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11612.6.2. Beispiel: Zielhost nicht erreichbar . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

12.7. Aufbau einer E-Mail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11812.7.1. Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11812.7.2. Multimedia Internet Mail Extensions (MIME) . . . . . . . . . . . . . . . . . . . . . . 119


VIII

Inhaltsverzeichnis

13.Network File System (NFS) 12113.1. Allgemeine Informationen zu NFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12113.2. Remote Procedure Call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

13.2.1. Funktionsweise von RPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12113.2.2. Aufbau von SunRPC-Nachrichten . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12213.2.3. External Data Representation (XDR) . . . . . . . . . . . . . . . . . . . . . . . . . . 12313.2.4. Portmapper und Daemons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

13.3. Das NFS-Protokoll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12413.3.1. Ablauf eines NFS-Zugriffs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12413.3.2. Dateizugriff via File Handles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12413.3.3. Einbinden von NFS auf dem Client . . . . . . . . . . . . . . . . . . . . . . . . . . . 12413.3.4. Die NFS-Prozeduren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12613.3.5. Zustandslosigkeit und Idempotenz . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

13.4. Experimente rund um NFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12713.4.1. Experiment: Einfache NFS-Zugriffe . . . . . . . . . . . . . . . . . . . . . . . . . . . 12713.4.2. Experiment: NFS-Zugriffe während eines Verbindungsabbruchs . . . . . . . . . . . . 127

13.5. Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

Literaturverzeichnis 131

IX

Abbildungsverzeichnis

1.1. Vergleich von ISO/OSI- und TCP/IP-Referenzmodell. . . . . . . . . . . . . . . . . . . . . . . . 61.2. Header eines IP-Datagramms. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.3. Übersicht über die Netzklassen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.4. Klasse-B-Netz mit 32 Subnets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.5. Format des IPv6-Headers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.1. ICMP im TCP/IP-Schichtenmodell. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.2. Aufbau des ICMP-Headers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.3. Lebenszeit überschritten. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.4. ICMP-Pakete von verschiedenen Fehlermeldungen. . . . . . . . . . . . . . . . . . . . . . . . . 202.5. Ungültige Parameter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.6. Source Quench. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.7. Redirect. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.8. Destination Unreachable. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.9. Synchronisation zweier Uhren durch ICMP Timestamps. . . . . . . . . . . . . . . . . . . . . . . 242.10. ICMP-Pakete für verschiedene Anfragen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242.11. Router Discovery. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.12. Pfad-MTU. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262.13. Mobile IP mit Hilfe von ICMP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262.14. Erweiterter ICMP-Header mit Daten zum Erhalt der Router. . . . . . . . . . . . . . . . . . . . . 27

3.1. Schema des Internet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.2. Graphenbeschreibung einer Netzwerktopologie. . . . . . . . . . . . . . . . . . . . . . . . . . . 303.3. Minimum Spanning Tree. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.4. Direkte und indirekte Zustellung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.5. Beispielnetzwerk. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323.6. IP-Routing-Algorithmus. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323.7. Routing-Tabelle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.8. Funktionsweise von Traceroute. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363.9. Ausgabe von Traceroute. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.1. Übersicht des Routing-Vorgangs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404.2. RIP-Einkapselung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404.3. RIP-Header. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404.4. RIP-Metrics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.5. OSPF-Header. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5.1. UDP-Header. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485.2. UDP-Pseudoheader. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

6.1. Verbindungsorientierte Kommunikation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 516.2. TCP-Header. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 536.3. TCP-Pseudoheader. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 546.4. TCP-Traffic-Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 556.5. Aufbau Experiment 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

XI


6.6. Variante 1 der Übertragung eines Zeichens an ein Remote-System. . . . . . . . . . . . . . . . . 566.7. Variante 2 der Übertragung eines Zeichens an ein Remote-System. . . . . . . . . . . . . . . . . 566.8. Delayed Acknowledgement auf Client-Seite. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 566.9. Aufbau Experiment 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 576.10. Datenstrom Experiment 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 576.11. Aufbau Experiment 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 586.12. Betätigen einer Funktionstaste. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 586.13. Datenstrom Experiment 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

7.1. Der Drei-Wege-Verbindungsaufbau. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 607.2. (a) Der 500ms-Timer und (b) Vier-Wege-Verbindungsabbau. . . . . . . . . . . . . . . . . . . . . 627.3. Half-Close. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 647.4. TCP-Zustandsüberführungsdiagramm. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

8.1. Sliding Window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 708.2. Zyklisches Verhalten der Sequenznummern. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 718.3. Verlauf des Congestion Window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 728.4. Verlauf des CWND und Slow Start Threshold bei Paketverlusten. . . . . . . . . . . . . . . . . . 738.5. Slow Start. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 748.6. Start mit kleinem Receive Window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 748.7. Slow Start nach schwerem Paketverlust. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 758.8. Congestion Avoidance nach leichtem Paketverlust. . . . . . . . . . . . . . . . . . . . . . . . . . 758.9. Überblick des Datenstroms vom ersten Rechner. . . . . . . . . . . . . . . . . . . . . . . . . . . 768.10. Überblick des Datenstroms vom zweiten Rechner. . . . . . . . . . . . . . . . . . . . . . . . . . 76

9.1. Prinzipieller Ablauf des Retransmission via Timeout. . . . . . . . . . . . . . . . . . . . . . . . 819.2. Fast Retransmit in der Praxis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

10.1. DNS-Protokoll im TCP/IP-Protokollstapel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8910.2. Namensbaum und ein paar Begriffe. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9110.3. Namensbaum mit Zonenmarkierungen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9110.4. DNS-Protokoll – allgemeines Paketformat. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9310.5. DNS-Protokoll – Flags. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9310.6. DNS-Protokoll – Question Section. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9410.7. DNS-Protokoll – Nonquestion Section. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

11.1. FTP im TCP/IP-Schichtenmodell. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9911.2. Eine Client-Server-Architektur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9911.3. Darstellung einer Client-Server-Verbindung des File Transfer Protocols. . . . . . . . . . . . . . 10111.4. Aufbau der Steuerverbindung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10311.5. Befehlsabfolge zur Anmeldung am Server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10311.6. Aufbau der Datenverbindung im Standard-Modus. . . . . . . . . . . . . . . . . . . . . . . . . . 10411.7. Aufbau der Datenverbindung im Port-Modus. . . . . . . . . . . . . . . . . . . . . . . . . . . . 10511.8. Aufbau der Datenverbindung im Passive-Modus. . . . . . . . . . . . . . . . . . . . . . . . . . . 10511.9. Übertragung der Daten beim File Transfer Protocol. . . . . . . . . . . . . . . . . . . . . . . . . 10611.10. Abbau der Steuerverbindung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10711.11. Befehlsabfolge bei der Wiederaufnahme der Datenübertragung. . . . . . . . . . . . . . . . . . . 10811.12. Darstellung einer FXP-Verbindung zwischen einem Client und zwei Servern. . . . . . . . . . . . 10911.13. Befehlsabfolge zum Aufbau der Datenverbindung beim File eXchange Protocol. . . . . . . . . . 109

12.1. SMTP-Kommunikationsmodell. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11212.2. Ein Relay-System von zwei Organisationen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11612.3. E-Mail-Routing über SMTP und DNS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11812.4. Typischer E-Mail-Header. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

XII


12.5. Eine einfache Multipart-Message. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

13.1. NFS im OSI-Schichtenmodell. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12113.2. Aufruf eines RPC und Rückgabe eines RPC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12213.3. Aufbau eines aufrufenden RPC und Antwort unter Verwendung von UDP. . . . . . . . . . . . . 12313.4. Aufbau eines NFS-Systems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12513.5. Ablauf eines Aufruf des mount-Befehls. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12513.6. Verzeichnisstruktur aus Sicht des Clients. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12613.7. Struktureller Aufbau und Ablauf des 1. Experiments . . . . . . . . . . . . . . . . . . . . . . . . 12813.8. Struktureller Aufbau und Ablauf des 2. Experiments. . . . . . . . . . . . . . . . . . . . . . . . . 128

XIII

Tabellenverzeichnis

1.1. Ausgewählte Transportprotokollnummern. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.2. Netzmasken. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.1. Nachrichtentypen bei ICMP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

9.1. Typische Werte von TCP-Timern in der Praxis. . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

11.1. Eine Auswahl verschiedener FTP-Befehle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10111.2. Bedeutung des 3-stelligen Antwortcodes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

12.1. SMTP im TCP/IP-Protokollstapel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11112.2. Grundlegende SMTP-Befehle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11312.3. Übersicht der SMTP-Status-Codes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11312.4. ESMTP-Befehle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

XV

0. Vorwort

Christian Kauhaus

Der vorliegende Band ist entstanden aus denArbeiten zum Rechnerarchitektur-Hauptseminar„TCP/IP Illustrated“ im Sommersemester 2006an der Friedrich-Schiller-Universität Jena. In demSeminar ging es darum, sich auf die Spuren vonW. Richard Stevens’ gleichnamigem Netzwerkklas-siker [Ste94] zu begeben. Obwohl das Werk fürInformatik-Verhältnisse schon sehr alt ist, besticht esdurch den bemerkenswerten didaktischen Ansatz, dieGrundlagen der Netzwerktechnik durch eine Reihevon einfachen Versuchen dem Leser nahezubringen.Das wollten wir im Seminar nachvollziehen.

Freilich hat sich in den vergangen 12 Jahren vielesverändert, und nicht alles von dem, was Stevens ver-mittelt, ist noch aktuell. Daher war ein weiteres An-liegen des Seminars, die Inhalte des Werks mit demaktuellen Stand der Netzwerktechnik in Beziehung zusetzen. Es ist interessant zu sehen, welche der da-mals angesprochenen „aktuellen Probleme“ auch heu-te noch Bestand haben und über welche man nur nochschmunzeln kann. Die Beiträge im vorliegenden Bandbeziehen aktuelle Entwicklungen so weit wie möglichmit ein.

Da Stevens’ Werk dick und das Semester kurz ist,musste eine Stoffauswahl getroffen werden. Das Se-minar gliederte sich in drei Hauptteile, die den Ebe-nen 2 bis 4 des TCP/IP-Referenzmodells entspre-chen: Internet-, Transport- und Anwendungsschicht.Auch der vorliegende Band entspricht dieser Grob-gliederung. Aus jeder dieser drei Ebenen wurden re-präsentative Einzelthemen herausgegriffen. Dennochsind Lücken zu verzeichnen; beispielsweise fehlt aufder Anwendungsschicht das wichtige HTTP. Auch dieunterste Ebene des Referenzmodells war im Seminarnicht umfangreich vertreten und konnte im Band garnicht berücksichtigt werden. Weiterhin werden vie-le der Experimente, die wir im Seminar durchgeführthaben, aus Platzgründen hier nur angedeutet oder garnicht erwähnt. Dennoch hoffe ich, dass die angebote-ne Stoffauswahl trotz ihrer Lücken einen guten Ein-stieg in die Welt der TCP/IP-Netzwerke bietet und

Lust aufs Weiterlesen weckt. Als umfassendere Ein-führungen bieten sich z. B. die Werke von Comer oderTanenbaum [Com00, Tan02] an.

Danken möchte ich allen, die zum Gelingen die-ses Bandes beigetragen haben. An erster Stelle sindhier die Seminarteilnehmer zu nennen, die bei derVorbereitung der Vorträge und Zusammenstellung derAusarbeitungen einen großen Einsatz gezeigt haben.Weiterhin danke ich auch allen Kollegen am Lehr-stuhl für Rechnerarchitektur und -kommunikation, diemich unterstützt haben.

Jena, im Dezember 2006 Christian Kauhaus

1

Teil I.

Internetschicht

1. Internet Protocol (IP)

Pascal Lenzner

1.1. Einleitung

1.1.1. Das TCP/IP-Referenzmodell

Das TCP/IP-Referenzmodell ist ein aus vier Ebenenbestehendes Schichtenmodell für die Kommunikati-on in Netzwerken. Jede Schicht besteht aus mehrerenProtokollen, welche das genaue Verhalten für den In-formationsaustausch festlegen. Die Schichten werdendabei nach ihren Kernaufgaben abstrahiert und es giltdas Prinzip, dass eine Schicht einerseits ihrem über-geordneten Nachbarn Dienste anbietet und anderer-seits die bereitgestellten Dienste der darunter liegen-den Schicht nutzt. Die oberste Ebene bildet die An-wendungsschicht und enthält alle anwendungsnahenProtokolle, wie zum Beispiel das Hypertext TransferProtocol (HTTP), das File Transfer Protocol (FTP)oder das Simple Mail Transfer Protocol (SMTP). Da-nach folgt die Transportschicht, welche für den Auf-bau einer Ende-zu-Ende-Verbindung zwischen Quell-und Zielhost verantwortlich ist. Die Internetschichtbildet die nächste Ebene und diese steuert die Pa-ketzustellung im Netzwerk. Auf der untersten Ebenedes Modells befindet sich die Netzwerkschicht, wel-che die physikalische Übertragung der Nachrichten-signale organisiert.

Beim Übergang zwischen den Schichten findet ei-ne Kapselung statt, d. h. jede Schicht versieht die be-handelten Daten mit spezifischen Kontrollinformatio-nen, welche aufgrund ihrer vorangestellten Positionals Header bezeichnet werden, und gibt das Gesamt-paket an die nächste Ebene weiter.

Obwohl das TCP/IP-Referenzmodell eigenständigentwickelt wurde, ist es vom Aufbau her eng mit demISO/OSI-Referenzmodell verwandt. Abbildung 1.1zeigt einen direkten Vergleich zwischen beiden.

1.1.2. Einordnung des IP

Einer der Namensgeber dieser Protokollfamilie istdas in diesem Kapitel betrachtete Internet Protocol

(IP), welches als Herzstück der Internetschicht imTCP/IP-Referenzmodell zwischen der darüberliegen-den Transportschicht und der Netzwerkschicht liegt.

Es nimmt die Segmente des Transmission ControlProtocol (TCP) und die Pakete des User DatagramProtocol (UDP) entgegen und sendet diese in Formvon IP-Datagrammen weiter an das zugehörige Pro-tokoll in der Netzwerkschicht.

Stevens [Ste94] bezeichnet IP als das Arbeitspferddes gesamten Protokollstapels und in den folgendenAusführungen wird erklärt, warum dies eine sehr tref-fende Formulierung ist.

1.2. Aufgaben des IP

Die Aufgaben des Internet-Protokolls werden im zu-gehörigen RFC 791 [Pos81b] wie folgt zusammenge-fasst:

The function or purpose of Internet Proto-col is to move datagrams through an in-terconnected set of networks. This is doneby passing the datagrams from one internetmodule to another until the destination isreached.

Doch was hier als Paketvermittlung in Netzwer-ken beschrieben ist, besteht vielmehr aus einer Mengevon Funktionalitäten, welche das Internet-Protokollbereitstellt.

Als Erstes werden im Protokoll IP-Datagramme alsBasiseinheit für die Übermittlung von Daten definiert.Jede zu übertragende Information wird in ein odermehrere Datagramme aufgeteilt und mit der entspre-chenden Kontrollinformation durchs Netzwerk ge-schickt. Diese Fragmentierung, welche eine weitereAufgabe des IP darstellt, ist keineswegs trivial, dennes muss garantiert werden, dass die ankommendenDaten ohne Verlust auf die erforderliche Anzahl anDatagrammen aufgeteilt und später beim Empfängerim korrekter Weise wieder zusammengesetzt werdenkönnen. Die Eigenschaften des IP werden im Detail

5


Anwendungsschicht

Präsentationsschicht

Sitzungsschicht

Transportschicht

Vermittlungsschicht

Sicherungsschicht

Übertragungsschicht

Anwendungsschicht

Transportschicht

Internetschicht

Netzwerkschicht

ISO/OSI-Referenzmodell TCP/IP-Referenzmodell

Abbildung 1.1.: Vergleich von ISO/OSI- und TCP/IP-Referenzmodell.

im Abschnitt „Eigenschaften des IP“ (1.3) bespro-chen.

Weiterhin leitet das IP die nun korrekt „verpack-ten“ Daten (zum Aufbau des Header vgl. Abschnitt„Das IP-Datagramm“, 1.4) an das entsprechende Pro-tokoll aus der Netzwerkschicht, welches für die phy-sikalische Übertragung auf dem jeweils vorhandenenTransportmedium zuständig ist, weiter. Ein Beispielfür eine solche Vorschrift wäre das Ethernet-Protokollnach IEEE-Standard 802.3.

Doch damit ist die Vermittlung der Daten zwischenQuell- und Zielhost noch nicht vollzogen. Eine weite-re wichtige Aufgabe ergibt sich durch die Frage, wiedenn der Zielhost überhaupt ausfindig gemacht wer-den soll. Auch hier bietet das Internet-Protokoll dieLösung an: ein Addressierungsschema, mittels dessenalle Hosts im Netzwerk eindeutig identifiziert werdenkönnen. Genauere Ausführungen zur dieser Thematikfinden sich im Abschnitt „IP-Adressierung“ (1.5).

Eine letzte Kernaufgabe des Internet-Protokollsstellt das Routing dar. Damit Daten vom senden-den zum empfangenden Host gelangen, müssen dieDatagramme im Netzwerk korrekt weitergeleitet wer-den. Auch dies ist eine schwierige Aufgabe, denndie Topologie des Netzwerks ist dem sendenden Hostim Normalfall nicht bekannt. Die Lösung hierfür istein Routingalgorithmus, der die Pakete „hop-by-hop“weitersendet, bis diese das spezifizierte Ziel erreichthaben. Nähere Erläuterungen liefert der Abschnitt„IP-Routing“ (1.6).

1.3. Eigenschaften des IP

Obwohl das Internet-Protokoll für solch grundlegen-de Aufgaben bei der Datenübertragung zuständig ist,zeichnet es sich durch zwei vielleicht überraschendeEigenschaften aus: Es ist unzuverlässig und zusam-menhangslos.

Die Unzuverlässigkeit bezieht sich darauf, dass eskeine Garantie gibt, dass ein Datagramm auch wirk-lich sein designiertes Ziel im Netzwerk erreicht. IPbietet lediglich Routing „nach bestem Bemühen“ anund überlässt es den höher liegenden Protokollen,für eine sichere Übertragung zu sorgen. Weiterhinwird für die Paketübertragung keine Ende-zu-Ende-Verbindung etabliert.

Auch die Fehlerbehandlung, sofern man diese alssolche bezeichnen kann, trägt zu dieser Eigenschaftbei. Tritt bei der Übertragung eines Datagramms einProblem auf, so ist die Vorgehensweise des Internet-Protokolls die Folgende: Zuerst wird das Datagrammverworfen, danach wird versucht, eine Internet-Control-Message-Protocol-(ICMP)-Nachricht an denSender zu verschicken (zu ICMP siehe Kapitel 2). Al-lerdings gibt es dabei keine Überprüfung, ob dieseFehlermeldung auch wirklich bei der Quelle des Da-tagramms ankommt.

Ein weiterer Fakt, der die Einstufung als unzu-verlässig rechtfertigt, ist die nicht vorhandene Mög-lichkeit zur Entdeckung von Datenfehlern. Im Head-

6

1.4. Das IP-Datagramm

er wird lediglich eine Prüfsumme des Headerinhaltsmitgeschickt, die Daten an sich werden durch keiner-lei Maßnahmen überprüft. Auch hier verlässt sich dasInternet-Protokoll auf die Vorarbeit der Protokolle ausder Anwendungs- und Transportschicht.

Die Eigenschaft zusammenhangslos steht dafür,dass das IP keine Informationen über aufeinander fol-gende Datagramme verarbeitet. Sind die ankommen-den Daten erst einmal in IP-Datagramme aufgeteilt,so wird jedes von ihnen als eigenständig angesehenund unabhängig von allen anderen Paketen behandelt.So ist es möglich, dass die einzelnen Datagramme aufjeweils unterschiedlichen Routen zum Zielhost gelan-gen und dass diese dort in einer anderen Reihenfolgeankommen.

Noch zu erwähnen ist hier die Unabhängigkeit vonder vorliegenden Netzwerkstruktur, welche man auchals Robustheit bezeichnen könnte. Die Paketzustel-lung erfolgt immer auf die gleiche Weise, egal ob derZielhost direkt mit dem Sender verbunden ist oder obdieser weit entfernt liegt und nur durch mehrere an-dere Netzwerke erreichbar ist. Diese Tatsache und zu-sätzlich die einfache Spezifikation des Protokolls so-wie die Konzentration auf die Kernaufgaben der Pa-ketübermittlung haben wohl zum großen Erfolg desIP und seiner bis heute zentralen Stellung geführt.

1.4. Das IP-Datagramm

1.4.1. Aufbau

Ein IP-Datagramm besteht aus den zu übertragendenDaten und den zugehörigen Kontrollinformationen,dem Header.

Der Header ist mindestens 20B groß, kann abernoch einen optionalen Teil mit variabler Länge be-sitzen. Enthalten sind alle wichtigen Informationenum ein Datagramm im Netzwerk korrekt zustellen zukönnen.

Insgesamt kann ein IP-Datagramm theoretisch biszu 64KiB einnehmen, in der Praxis wird die Grö-ße aber meist auf die maximale Kapazität der Fra-mes (Übertragungseinheiten) der Protokolle aus derNetzwerkschicht beschränkt. Ein gängiger Wert isteine Gesamtgröße von 1500B, welche der Maxi-mum Transfer Unit (MTU) des Ethernetprotokolls ent-spricht.

1.4.2. Der IP-Header

Der Inhalt des Headers wird in RFC 791 [Pos81b] ex-akt vorgegeben und ist Thema dieses Abschnitts.

Der Aufbau wird in Abbildung 1.2 verdeutlicht.Dabei gilt, dass das höchstwertige Bit das Bit 0 ganzlinks und das niederwertigste Bit das Bit 31 am rech-ten Rand ist. Die einzelnen Bytes werden hierbei imModus big endian1 übermittelt.

Die einzelnen Felder haben folgende Bedeutung:

Version Dieses Feld gibt an welche Version desInternet-Protokolls verwendet wird. Dabei gibt esheute nur zwei Möglichkeiten: Version 4, auch IPv4genannt und Version 6, welches als IPv6 oder IP nextgeneration (IPnG) bezeichnet wird. Erstere ist zurZeit noch der Standard.

IHL Die Abkürzung IHL steht für Internet Head-er Length und bezeichnet die Länge des Headers in32bit-Worten. Dabei ist das Minimum 5, also 20Bund das Maximum 15, was 60B entspricht. DieserMaximalwert der Headerlänge schränkt somit denPlatz für das Optionsfeld auf 40B ein.

Type Of Service Wird auch mit TOS bezeichnetund legt die Behandlung des Datagramms fest.

Die 8bit dieses Felds setzen sich wie folgt zusam-men: Bits 1–3 haben keine Bedeutung und werdenignoriert, die Bits 4–7 sind die eigentlichen TOS-Bitsund Bit 8 hat keine Funktion, muss allerdings auf 0gesetzt sein. Die vier TOS-Bits stehen für minimizedelay, maximize throughput, maximize reliability undminimize monetary cost. Bei der Nutzung gilt, dassnur jeweils eines der Bits den Wert 1 haben kann. Fallskein TOS-Bit geschalten ist, so steht dies für Normal-betrieb.

Für viele verschiedene Applikationen gibt esempfohlene TOS-Werte. Zum Beispiel für Telnet-, FTP/Control- und UDP-Anfragen des DNS-Protokolls wird eine Behandlung mit minimize de-lay vorgeschlagen. FTP/Data sollte mit maximizethroughput betrieben werden.

Die TOS-Einstellungen werden von heutigenTCP/IP-Implementierungen allerdings meist nichtmehr unterstützt und es wird standardmäßig im Nor-malbetrieb gearbeitet.

Total Length Hier wird die Gesamtgröße des IP-Datagramms in Bytes angegeben. In Kombination mitdem IHL-Feld kann genau bestimmt werden, wo dieeigentlichen Daten beginnen und wie groß diese sind.

1 Hierbei werden bei einem 32-Bit-Wert zunächst die Bits 0-7,dann 8-15, danach 16-23 und zuletzt die niederwertigsten Bits24-31 übertragen.

7


Version IHL Type of service Total length

0 8 16 24

Identification Fragment offsetDF

MF

Time to live Protocol Header checksum

Source address

Destination address

Options

Abbildung 1.2.: Header eines IP-Datagramms.

Da hier 16bit zur Verfügung stehen, beträgt der Ma-ximalwert 64KiB.

Doch nicht jeder Host ist gezwungen, so großeDatagramme zu akzeptieren: Im RFC 791 wird vor-geschrieben, dass nur Datagramme bis 576B Längeangenommen werden müssen.

Die Gesamtlängenangabe wird noch aus einemweiteren Grund benötigt. Manche Protokolle derNetzwerkschicht füllen die ankommenden Daten biszu einer gewissen Mindestgröße auf. Um nun in ei-nem solchen Frame noch zu erkennen, welche Dateneigentlich zum IP-Datagramm gehören, wird der Wertdes Total-Length-Felds abgefragt.

Identification Der hier übermittelte Wert wird ei-nerseits für die eindeutige Identifizierung der Paketeund andererseits für die korrekte Zusammensetzungvon Datenfragmenten gebraucht.

Teilt das Internet-Protokoll ankommende Daten inmehrere IP-Datagramme auf, so erhalten diese alle diegleiche Nummer im Identification-Feld. Der Empfän-ger der Fragmente weiß somit, welche Pakete wiederzusammengesetzt werden müssen. Pakete, die nichtfragmentiert wurden, bekommen beim Versenden ei-ne fortlaufend inkrementierte Nummer, um diese ein-deutig zu kennzeichnen.

Flags Die folgenden drei Bits im IP-Header sindfür Flags reserviert. Das erste Bit hat keinerlei Ver-

wendung, das DF-Flag steht für Don’t Fragment unddas MF-Flag bedeutet More Fragments Follow.

Die Auswirkungen dieser Bits sind schon am Na-men erkennbar. Ist das DF-Flag gesetzt, so wird ver-hindert, dass ein Datenpaket fragmentiert wird. Solltedadurch ein Paket nicht mehr weitertransportiert wer-den können, so wird dieses verworfen. Ein geschalte-tes MF-Flag steht dafür, dass das Paket fragmentiertwurde und noch weitere Fragmente folgen.

Fragment Offset Für die Zusammensetzungmehrerer Fragmente ist noch eine weitere Angabenötig: Die Position des Fragments im Gesamtpaket.Der Fragment Offset liefert diesen Wert relativ zumBeginn des Originalpakets. Aufgrund der Feldgrößevon 13bit können somit insgesamt 8192 Fragmentepro Datagramm erstellt werden. Die elementareFragmenteinheit ist dabei 8B und deshalb müssenalle Offset-Werte Vielfache von 8B sein.

Time To Live Dieses Feld, welches auch abge-kürzt als TTL bezeichnet wird, beinhaltet einen Zäh-ler, der die Lebensdauer eines Datagramms begrenzt.Dieser Wert wird einerseits jede Sekunde und ande-rerseits bei jedem Host, den das Datagramm passiert,um 1 herabgesetzt. Somit gilt als Obergrenze eine Le-bensdauer von 255s. Erreicht der Zähler den Wert 0,so wird das Paket sofort verworfen und es wird ver-sucht, eine ICMP-Warnmeldung an den Sender zu-rück zu schicken. Mit diesem Vorgehen wird verhin-

8

1.5. IP-Adressierung

dert, dass Datagramme endlos im Netzwerk unter-wegs sind.

Protocol Dieses Feld gibt eine Nummer des Pro-tokolls an, an welches das Datagramm beim Empfän-ger weitergeleitet werden muss. Die Protokollnum-mern sind weltweit eindeutig festgelegt und werdenvon der Internet Assigned Numbers Authority (IANA)verwaltet. Die Funktionsweise der Protokollnummerwird genauer in Abschnitt 1.5.1 beschrieben.

Header Checksum Hier wird eine Prüfsummedes Headerinhalts mitgeführt. Wie bereits erwähnt,gibt es keine Prüfsumme der eigentlichen Nutzdatendes Datagramms.

Wichtig ist hierbei, dass diese Prüfsumme von je-dem durchlaufenen Host im Netzwerk neu berech-net werden muss, da sich der TTL-Wert ändert. Eswird aus diesem Grund ein sehr effizientes Verfah-ren genutzt: Es wird das 1-er Komplement aller 16bit-Halbwörter der Headerdaten verwendet. Als Voraus-setzung dafür wird angenommen, dass die Prüfsummezu Beginn der Berechnung Null war.

Source address Dieses Feld enthält die 32bitlange Internetadresse des Quellhosts.

Destination address Hier wird die 32bit-Addresse des Empfängers festgehalten.

Options Dieses Feld variabler Länge bietet Zu-satzinformation über das Datagramm und wurde ausErweiterungsgründen mit in den Header aufgenom-men. Jede Option beginnt mit einem ein Byte langemCode zur Identifizierung, bei manchen folgt noch einweiteres Byte für Optionen und danach kommen einoder mehrere zur Option gehörige Datenbytes. DasFeld wird am Ende immer auf ein Vielfaches von 4Baufgefüllt und maximal kann es 40B groß sein.

Folgende Optionen können verwendet werden:

• End of Option List kennzeichnet das Ende derListe der Optionen.

• No Option kann zum Auffüllen verwendet wer-den.

• Security bezeichnet, wie geheim das Datagrammist. Allerdings wird diese Option in der Praxisvernachlässigt.

• Source Routing – bei dieser Option ist eineListe von Internet-Adressen vorgegeben, welche

das Datagramm durchlaufen soll. Hierfür gibt eszwei Varianten: Zum einen das Loose Source andRecord Route und zum anderen Strict Source andRecord Route. In beiden Fällen sollen die ange-geben Hosts passiert werden und die genomme-ne Route wird aufgezeichnet, doch beim letzte-ren Fall müssen die Hosts genau in der Reihen-folge und ohne Zwischenstationen passiert wer-den.

Allerdings ist diese Option durch den geringenverfügbaren Platz stark eingeschränkt und heuteim Normalfall unbrauchbar.

• Record Route – diese Option weist alle durch-laufenen Hosts an, ihre Adresse an das Options-feld anzuhängen um somit eine Aufzeichnungder im Netzwerk zurückgelegten Route zu er-halten. Doch auch diese Option ist durch dengeringen Platz für derartige Einträge stark ein-geschränkt. Ohne andere Optionen können le-diglich neun 32bit-Adressen aufgenommen wer-den, heute werden aber meistens deutlich mehrHosts von Quelle zu Ziel passiert. Eine besse-re Alternative bietet heute das Traceroute (Ab-schnitt 3.4).

• Timestamp – ähnlich wie Record Route, nur dasshierbei zusätzlich noch die Zeit beim Passierender Netzwerkknoten aufgezeichnet wird.


Aufgrund des schon dargestellten Kapselungsprinzipsder TCP/IP-Familie sind vier unterschiedliche Adres-sen notwendig, um mit einer Applikation auf einemanderen Host im Netzwerk kommunizieren zu kön-nen:

• Für die Netzwerkschicht die Netzwerkadres-se, welche eine physikalische Verbindung zumZiel ermöglicht. Ein Beispiel für eine sol-che Adresse wäre die Media-Access-Control-(MAC)-Adresse.

• Für die Internetschicht die Internet-Adresse.

• Für die Transportschicht die Transportprotokoll-nummer.

• Für die Anwendungsschicht die Portnummer.

Die Internet-Adresse und die Transportproto-kollnummer befinden sich im Header eines IP-Datagramms und stehen somit im Mittelpunkt der Be-trachtung dieses Abschnitts.

9


# Keyword Protocol

0 HOPOPT IPv6 Hop-by-Hop Option1 ICMP Internet Control Message2 IGMP Internet Group Management3 GGP Gateway-to-Gateway4 IP IP in IP (encapsulation)5 ST Stream6 TCP Transmission Control7 CBT CBT8 EGP Exterior Gateway Protocol

Tabelle 1.1.: Ausgewählte Transportprotokoll-nummern.

1.5.1. Die Transportprotokollnummer

Damit die Adressierung in der Transportschicht im-mer korrekt erfolgen kann, werden die Nummern derProtokolle in dieser Schicht von einer zentralen Or-ganisation, der Internet Assigned Numbers Authority(IANA), verwaltet und aktualisiert.

Als Beispiel soll in Tabelle 1.1 ein Auszug aus derListe der zugewiesenen Protokollnummern [Int06d]dienen. Soll nun zum Beispiel das TCP adressiert wer-den, so muss im Protocol-Feld im IP-Header der Wert6 eingetragen sein und IP wird das ankommende Pa-ket dorthin weiterleiten.

1.5.2. Die Internet-Adresse

Die Internet-Adresse besteht beim IP Version 4 (IPv4)aus 32bit und die Adressen von Quell- und Zielhoststehen in jedem IP-Datagramm im Header.

Wichtig ist, dass eine solche Adresse, welche oftauch als IP-Adresse bezeichnet wird, für eine Ver-bindung (Interface) eines Hosts mit einem Netzwerksteht. Jeder Rechner in einem Netzwerk hat somitmindestens eine Internet-Adresse, falls dieser aberüber mehrere Verbindungen mit diesem Netz kommu-niziert, so hat der Host für jede dieser Verbindungenzum Netzwerk eine eigene Adressnummer.

1.5.2.1. Zuständigkeit

Ähnlich wie bei anderen Adressen muss auch dieIP-Adresse im Netzwerk eindeutig sein, denn sie istdafür verantwortlich, Datenpakete zum richtigen Be-stimmungsort gelangen zu lassen. Für das größteNetzwerk der Welt, das Internet, bedeutet dies natür-lich, dass jeder angeschlossene Host eine eigene ein-deutige Adresse benötigt, was bei einer geschätztenZahl von einer Milliarde Hosts [Int06e] eine schwie-

rig zu bewältigende Aufgabe ist. Die Lösung basiertauch hier auf einer zentralen Organisation, die dieVergabe der IP-Adressen regelt: Die Internet Coope-ration for Assigned Names and Numbers (ICANN).Zuständig für den europäischen Raum ist die Rés-seaux IP Européens (RIPE).

Als Grundlage für die Vergabe der Internet-Adressen dient das RFC 2050 [HKC+96], welches die„Internet Registry IP Allocation Guidelines“ festlegt.

Die vergebenen Adressen unterscheidet man inProvider-Aggregated (PA) und Provider-Independent(PI). Die PA-Adressen sind Eigentum einer Einrich-tung oder eines Unternehmens, wie zum Beispiel einInternet Service Provider (ISP), der die IP-Adresseneigenständig verwaltet. Die unabhängigen Adressenhingegen sind direkt an einen Endnutzer gebunden.

1.5.2.2. Aufbau

Üblicherweise wird der 32bit-Wert nicht binär, son-dern durch eine gepunktete Dezimalschreibweise dar-gestellt, z. B. als

141.35.12.1 .

Dabei ist die niedrigste mögliche Adresse die 0.0.0.0und die höchste Adresse die 255.255.255.255.

Jede Adresse besteht aus einer Netzadresse und ei-ner Hostadresse, am Beispiel könnte der Netzanteildie ersten 16bit umfassen und somit 141.35 lauten,der Hostanteil würde dann aus den letzten 16bit be-stehen und hätte den Wert 12.1.

Weiterhin gibt es noch ein paar spezielle IP-Adressen:

• Besteht die Netzadresse aus lauter Nullen, so be-zeichnet diese Adresse einen Host im eigenenNetz.

• Hat die Adresse die Form 127.x.y.z, so steht diesfür die Loopback-Adresse und das Datagrammwird lediglich intern verarbeitet und nicht insNetzwerk geschickt.

• Sind alle Bits der Hostadresse Nullen, so be-zeichnet dies die Adresse des gesamten Netzes.

• Sind hingegen alle Hostadress-Bits geschalten,so handelt es sich hierbei um einen Broadcastund das Datagramm wird an alle Hosts im Netz-werk weitergeleitet.

• Die Adresse 255.255.255.255 ist für den loka-len Broadcast reserviert: Hierbei wird das Data-gramm an alle Hosts im Netz geschickt, darf je-doch nicht weitergeleitet werden.

10


Die Gesamtanzahl der im Internet zu vergebendenAdressen beläuft sich somit auf 4 294 967 296 Stück.

Neben diesen beiden Varianten gibt es noch spezi-elle Adressen für private Netzwerke, d. h. Netzwerke,die in sich abgeschlossen und nicht direkt mit dem In-ternet verbunden sind. Diese Adressen dürfen im In-ternet nicht weitergeleitet werden, es bedarf bei derNutzung allerdings auch keiner Erlaubnis von Seitender ICANN.

Die vordefinierten Bereiche für private Netzwerkesind:

• 10.0.0.0: Privates Klasse A Netzwerk

• 172.16.0.0 bis 172.31.0.0: Hier können maximal16 private Klasse B Netzwerke adressiert wer-den.

• 192.168.0.0 bis 192.168.255.0: Dieser Bereichkann maximal 254 Klasse C Netzwerke umfas-sen.

1.5.3. Classful AddressingNun stellt sich die Frage, wie denn bei einer Internet-Adresse die Netzadresse und die Hostadresse ermitteltwird.

Ein grundlegender Ansatz dafür war das so genann-te Classful Addressing, welches jedem Netz eine eige-ne Netzadresse zugewiesen hat. Dabei gab es je nachder Größe des zu adressierenden Netzwerks unter-schiedliche Klassen von Netzen, welche anhand derführenden Bits der IP-Adresse unterschieden wurden.

In Abbildung 1.3 sind die Netzwerkklassen darge-stellt. Ersichtlich ist auch, welcher Adressraum fürNetzadressen und Hostadressen jeweils in den ent-sprechenden Klassen zur Verfügung gestellt wird.

Sonderfälle sind die Klassen D und E. Die Adres-sen der Klasse D sind so genannte Multicast-Adressenund sind dafür bestimmt, Datagramme an mehrereHostadressen gleichzeitig zu schicken. Erreicht einDatagramm eine solche Adresse, so wird versucht,dieses Paket an alle Mitglieder der adressierten Grup-pe unter Benutzung des Internet Group MessagingProtocol (IGMP) zu senden. Die Klasse E wird nor-malerweise nicht verwendet und ist für experimentel-le Zwecke reserviert.

Problematisch beim Classful Addressing ist jedochdie verschwenderische Adressverteilung. Mit demGrundprinzip der Zuweisung von je einer Netzadressepro physikalischem Netzwerk wurde der zur Verfü-gung stehende Adressraum sehr ineffizient vergebenund die ICANN stand bereits nach wenigen Jahrenvor dem Problem, dass der Adressraum knapp wurde.

Ein Beispiel für diese Fehlverteilung stellt fol-gende Situation dar: Angenommen es liegt ein phy-sikalisches Netzwerk mit etwa 1000 angeschlosse-nen Hosts vor und dieses soll adressiert werden. Als„angemessene“ Netzklasse kommt hierfür nur Klas-se B in Frage, da man mit einem Klasse-C-Netz le-diglich 254 Hosts adressieren kann. Doch mit ei-ner solchen Klasse-B-Netzadresse ist es möglich,65534 Netzwerkknoten anzusteuern und somit wer-den circa 64534 mögliche IP-Adressen verschwendetund können nicht mehr an andere Netzwerke verge-ben werden.

Dieser Trend wurde noch dadurch verstärkt, dasssich zu Beginn des Internets große und einflussreicheInstitutionen ganze Klasse-A-Netzadressen sichertenund somit seither einen beträchtlichen Teil des IP-Adressraums belegen.

Als Lösung der Adressknappheit schwenkte manauf das so genannte Subnet Addressing um.

1.5.4. Subnet AddressingDie Idee dieses Ansatzes steckt schon im Name: Net-ze werden in kleinere Netze, die so genannten Sub-nets, unterteilt.

Alle Subnets, die zu einer Netzadresse gehören,werden von der zugehörigen Einrichtung zentral ver-waltet und somit erscheinen die Netze nach Außen hinweiterhin wie ein großes Netzwerk.

Die Umsetzung dieses Prinzips, welches imRFC 950 [MP85] festgelegt wurde, erfolgt meistdurch die Verwendung der höherwertigen Bits derHostadresse als Subnet-Adresse. Abhängig von derAnzahl der gewünschten Subnets werden die Bits re-serviert und mit der Subnet-ID belegt. Die übrigenBits der Hostadresse dienen weiterhin zur Adressie-rung der Hosts.

Die für das Subnet genutzten Bits werden in derSubnet-Maske markiert. Die Subnet-Maske ist beiIPv4 ein weiterer 32bit-Wert, bei dem die einzelnenBits für die entsprechenden Bits der IP-Adresse ste-hen. Alle Bits der Netzadresse sowie alle Bits derSubnet-Adresse haben hier den Wert 1. Die Host-adressbits müssen den Wert 0 zugewiesen bekommen.Mit diesem Verfahren ist es also möglich, die Subnet-Bits zu identifizieren und die Adressierung der Teil-netze korrekt durchzuführen.

In Abbildung 1.4 ist ein Beispiel für eine sol-che Unterteilung zu sehen. Hier wurde ein Klasse-B-Netzwerk in 32 Subnets mit jeweils 2046 möglichenHosts unterteilt. Die Zahl der Subnets ergibt sich ausder Länge der Subnet-Adresse, welche hier 5bit be-trägt. Die Subnet-Maske hat hier den binären Wert:

11


Klasse A

Klasse B

Klasse C

Klasse D

Klasse E

1 0

1 01

1 1 1 0

1 1 1 1

0 8 16 24

0 Netzadresse

Netzadresse

Netzadresse

Hostadresse

Hostadresse

Hostadresse

Multicast

reserviert

Abbildung 1.3.: Übersicht über die Netzklassen.

Klasse B

Klasse B mitSubnetz-ID

Subnetzmaske

1 0

0 8 16 24

Netzadresse

Hostadresse

Hostadresse

Netzadresse1 0

Subnetz

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0

Abbildung 1.4.: Klasse-B-Netz mit 32 Subnets.

11111111 11111111 11111000 00000000 .

Dies entspricht 255.255.248.0 in gepunkteter Dezi-maldarstellung.

Noch ein weiterer Vorteil ergibt sich durch das Sub-netting: Da externe Router den internen Netzaufbaunicht kennen, wird für jeden Host in solch einem auf-geteiltem Netz nur eine Route, nämlich die zum ge-meinsamen Gateway, in der Routingtabelle benötigt.Im Gegensatz dazu wären bei 32 eigenständigen Netz-werken für jedes Netzwerk ein solcher Eintrag not-wendig.

1.5.5. Classless Inter-DomainRouting

Mit Subnet Addressing wurde schon ein Schritt indie richtige Richtung getan, doch auch diese Methodestieß bald an ihre Grenzen, denn die Routingtabellenwurden immer größer und es bestand die Gefahr, dassdie zur Verfügung stehende Hardware den Routing-aufwand nicht mehr bewältigen kann. Weiterhin hatdas Subnetting nicht die Adressknappheit wie erwar-tet gelöst. Um Zeit für die Entwicklung einer lang-

fristigen Lösung zu gewinnen, hat man eine weitereVerbesserung eingesetzt: das Classless Inter-DomainRouting (CIDR), das im RFC 1519 [FLYV93] be-schrieben wird. Der Grundgedanke ist, dass die Zu-ordnung von IP-Adresse zur Netzklasse und den Un-terklassen vollkommen entfällt. Die Aufteilung vonNetz- und Hostadresse geschieht hierbei durch eineNetzmaske. Diese Netzmaske, die vom Prinzip hergenau wie die Subnetzmaske funktioniert, wird meistals Suffix bezeichnet. Der Begriff stammt von der neu-artigen Schreibweise der CIDR-Adressen: Angenom-men, bei der IP-Adresse 141.35.12.1 sind die ersten16bit die Netzadresse, dann wird das wie folgt ge-schrieben:

141.35.12.1/16 .

Das Suffix „/16“ gibt also an, wie viele Bits der Netz-maske, angefangen vom höchstwertigen, den Wert 1haben.

Vorteilhaft an diesem Vorgehen ist, dass man nunIP-Adressen verstärkt hierarchisch vergeben kann,d. h. dass man die Adressierung der vorhandenen In-frastruktur anpasst. Wird der Verkehr eines kleine-ren Netzwerks über die Infrastruktur eines größeren

12

1.6. IP-Routing

Suffix Hosts Netzmaske

/8 16777216 255.0.0.0/9 128 x 65536 255.128.0.0/10 64 x 65536 255.192.0.0/11 32 x 65536 255.224.0.0/12 16 x 65536 255.240.0.0/13 8 x 65536 255.248.0.0/14 4 x 65536 255.252.0.0/15 2 x 65536 255.254.0.0/16 65536 255.255.0.0/17 128 x 256 255.255.128.0/18 64 x 256 255.255.192.0/19 32 x 256 255.255.224.0/20 16 x 256 255.255.240.0/21 8 x 256 255.255.248.0/22 4 x 256 255.255.252.0/23 2 x 256 255.255.254.0/24 256 255.255.255.0/25 128 255.255.255.128/26 64 255.255.255.192/27 32 255.255.255.224/28 16 255.255.255.240/29 8 255.255.255.248/30 4 255.255.255.252

Tabelle 1.2.: Netzmasken.

ISPs abgewickelt, so bekommt dieses Netzwerk ei-ne Adresse, die hierarchisch unter der des ISP liegt.Zum Beispiel könnte der ISP ein /16-Netzwerk al-lokiert haben und das kleinere Netzwerk könnte ein/28-Netzwerk im gleichen Adressbereich sein. DieseAdressvergabe führt dazu, dass weniger Einträge inden Routingtabellen benötigt werden.

Weiterhin trägt dieses Schema auch zu einer effek-tiveren Adressvergabe bei, da jetzt gezielt noch unge-nutzte Adressbereiche allokiert werden können.

Allerdings kann man diese Adressvergabe nicht aufalle Situationen anwenden. Ein Beispiel ist das Multi-homing, d. h. dass es mehrere unabhängige Verbin-dungen eines Netzwerks mit dem Internet gibt, da hieraufgrund der unterschiedlichen Routen die Routen-einträge in der Routingtabelle verbleiben müssen.

Eine Übersicht über die mögliche Anzahl vonHosts pro Netzwerk gibt Tabelle 1.2. Diese Adres-sierungsart ist momentan aktuell, doch die schon be-schriebene langfristige Lösung für das Problem derAdressknappheit wurde schon entwickelt und ist be-reits im Einsatz: IP Version 6. Mehr dazu findet sichin Abschnitt 1.7.

1.6. IP-Routing

Eine weitere Hauptaufgabe des Internet-Protokollsist das Weiterleiten von Datagrammen im Netz: dasRouting. Dieser Abschnitt dient als Einführung, fürtiefer gehende Einblicke gibt es die beiden Kapitel 3und 4 zu dieser Thematik.

Die zentrale Frage ist: Wie kommt ein Data-gramm vom Sender zum Empfänger? Die Lösung istein simpler Algorithmus, der für jedes ankommen-de Datagramm durchlaufen wird. Aus der Sicht ei-nes Hosts kann man den Ablauf folgendermaßen be-schreiben:

1. Prüfen, ob das Datagramm für meine IP-Adressebestimmt ist. Falls dies der Fall ist, dann wird dasPaket angenommen und verarbeitet.

2. Prüfen, ob das Datagramm für einen Host be-stimmt ist, der direkt mit mir verbunden ist. Fallsja, dann wird das Paket an diesen weitergeleitet.

3. Prüfen, ob das Datagramm für ein mit mir ver-bundenes Netzwerk bestimmt ist. Falls ja, dannwird das Paket an den Next-Hop-Router diesesNetzwerks weitergeleitet.

4. Falls keiner der Fälle 1–3 eingetreten ist, dannwird das Paket an den Default-Router weiterge-leitet.

Sollten alle Fälle scheitern, so wird versucht, eineentsprechende ICMP-Fehlermeldung an den Senderzu schicken.

Damit das IP die obigen Fälle unterscheiden kann,ist es nötig zu wissen, welche Hosts direkt erreichtwerden können, welche Router von anderen Netz-werken angeschlossen sind und welche IP-Adresseder Default-Router hat. Dies wird mit der schon öf-ters erwähnten Routingtabelle erreicht. In ihr stehendie benötigten IP-Adressen, mit denen dann die Zie-ladresse des ankommenden Pakets verglichen wird.In Schritt 2 wird dabei auf vollständige Übereinstim-mung geprüft. Bei Schritt 3 ist lediglich die Netz-adresse relevant, wird hier eine Übereinstimmung ge-funden, d. h. es gibt einen bekannten Router, der sichim gleichen Netz befindet, so wird das Datagramm andiesen Router geschickt. Auf jeden Fall muss aber inder Routingtabelle die Adresse des Default-Routers,oft auch als „Next-Hop“ bezeichnet, eingetragen sein.

Prinzipiell gilt hierbei immer die Annahme, dassder Next-Hop-Router „näher“ am Ziel liegt und übereine umfangreichere Routingtabelle verfügt. Auf die-se Weise gelangt ein Datagramm also „hop-by-hop“durchs Netzwerk zu seinem Zielhost.

13


Weiterhin zu erwähnen ist die Tatsache, dass in derRoutingtabelle für jedes erreichbare Netzwerk nur ei-ne Route eingetragen ist, nämlich die IP-Adresse desentsprechenden Routers. Würden alle Hosts eines an-geschlossenen Netzwerks einen eigenen Eintrag be-nötigen, so würde die Tabellengröße rasant anwach-sen und die Routingvergleiche würden viel Zeit undHardwareaufwand benötigen.

1.7. IP Version 6

Der Nachfolger von IPv4 lautet IPv6. Er wird auchals IP Next Generation bezeichnet und soll in diesemAbschnitt kurz vorgestellt werden.

Aufgrund der früh erkannten Probleme der Adress-knappheit und der immer stärker wachsendenRoutingtabellen wurde ab 1995 intensiv an der sechs-ten Version des Internet-Protokolls gearbeitet undnach vielen Tests und einigen Änderungen 1998 dieSpezifikation im zugehörigen RFC 2460 [DH98] fest-gehalten. IPv6 ist bereits im Einsatz, doch es ist bishernoch nicht stark verbreitet.

1.7.1. Adressierung

Die alten 32bit-Adressen haben ausgedient undwerden durch 128bit lange Adressen ausgetauscht.Durch diese Maßnahme sollten zukünftig genug IP-Adressen zur Verfügung stehen, denn es sind circa340 Sextillionen (= 3.4 ·1038) Adressen möglich.

Auch die gepunktete Dezimalnotation wird nichtmehr verwendet, die Adressen werden ab jetzt inhexadezimaler Notation mit Doppelpunkten geschrie-ben. Eine Adresse besteht aus 8 Blöcken, wobei jederBlock für 16bit der Adresse steht. Hier ein Beispieleiner IPv6-Adresse:

2001:cf8:84b3:3a3:1d49:8a2f:260:7144 .

Dabei können ein oder mehrere Gruppen von 0-Blöcken durch zwei aufeinander folgende Doppel-punkte ersetzt werden. Jedoch darf die Adresse nuran einer Stelle auf diese Weise abgekürzt werden, dasie sonst nicht mehr eindeutig wäre. Auch dürfen füh-rende Nullen in den Blöcken weggelassen werden.

Das Prinzip der Aufteilung in Netzadresse undHostadresse wurde beibehalten und wird ähnlich wiebei CIDR geschrieben:

2001:cf8:84b3:3a3:1d49:8a2f:260:7144/64 .

Bei dieser Adresse sind folglich die ersten 64bit dieNetzadresse, diese wäre also 2001:cf8:84b3:3a3::/64.

Auch wurde das Hierarchieprinzip hier weiterge-führt, somit müsste das obige Netz ein Teilnetz von2001:cf8:84b3::/48 sein.

Außerdem gibt es jetzt unterschiedliche Arten vonAdressen, die man an ihrem Präfix erkennt, d. h. ander ersten 16bit-Gruppe. Beim hier aufgeführten Bei-spiel mit dem Präfix 2001 handelt es sich um eineAdresse, die an Provider vergeben wird, damit diesesie an Endnutzer weitergeben.

Andere Adressarten und spezielle IP-Adressensowie weitere detaillierte Informationen zur IPv6-Adressierung sind im zugehörigen RFC 3513 [HD03]zu finden.

1.7.2. Der IPv6-HeaderIm Gegensatz zum Version-4-Header hat der IPv6-Header eine feste Länge von 40B. Dieser kann al-lerdings durch das Anhängen von weiteren Headernnoch erweitert werden.

Der Aufbau ist dem von IPv4 sehr ähnlich, dochman erkennt deutlich, dass der Header vereinfachtwurde, um ihn schneller verarbeiten zu können. InAbbildung 1.5 ist eine Darstellung des Headerinhaltszusehen.

Es folgt eine kurze Beschreibung der einzelnen Fel-der:

Version Exakt wie bei IPv4 steht dieses Feld für dieProtokollversion und ist bei IPv6 mit dem Wert6 belegt.

Traffic Class Dieses Feld steht für einen Prioritäts-wert, mit dem das Datagramm verarbeitet wer-den soll, und hat somit ähnliche Funktionalitätwie das TOS-Feld bei IPv4.

Flow label Hiermit können zusammengehörige Pa-kete speziell gekennzeichnet werden.

Payload Length Dies gibt die Länge des Gesamt-pakets exklusive dem Header an. Erweiterungs-header sind hier allerdings mit inbegriffen.

Next Header In diesem Feld steckt die große Flex-ibilität von IPv6. Hier wird der Typ des alsnächstes folgenden Erweiterungsheaders ange-geben, damit dieser auch korrekt verarbeitet wer-den kann. Beispiele für solche Erweiterungensind spezielle Header für Routingoptionen, Au-thentifikation, Datenintegrität und Datensicher-heit. Zu bemerken ist, dass jeder Header den Typdes ihm folgenden Headers enthält. Eine Aus-nahme davon bildet der letzte Erweiterungshea-

14

1.7. IP Version 6

Version Traffic class Flow label

0 8 16 24

Payload length Next header Hop limit

Source address

Destination address

Abbildung 1.5.: Format des IPv6-Headers.

der, dieser enthält die Transportprotokollnum-mer, ähnlich wie im Protocol-Feld bei IPv4.

Hop Limit Dies ist ähnlich wie der TTL-Wert beiIPv4 ein Zähler für die bereits passierten Kno-ten im Netzwerk. Erreicht er den Wert Null, sowird auch hier das Datagramm verworfen.

Source Address Die 128bit-Adresse des Quell-hosts.

Destination Address Hier befindet sich die IP-Adresse des Empfängers, allerdings kann diesauch nur eine Zwischenstation sein, falls ein Er-weiterungsheader für das Routing vorhanden ist.

1.7.3. IPv6-Neuerungen

Viele neue Features wurden in IPv6 integriert und einAuszug davon soll hier vorgestellt werden.

Als erstes zu nennen wäre hier die Möglichkeit derAutokonfiguration von IPv6-Hosts. Allein anhand sei-ner MAC-Adresse kann sich ein Host selbst eine lo-kal gültige IP-Adresse berechnen und mit dieser perMulticast auf einer speziellen Adresse mit den fürihn zuständigen Routern kommunizieren. Vom Rou-ter bekommt der Host dann einen Adressbereich zu-gewiesen, aus welchem er sich eine Adresse aus-wählen kann. Anschließend wird noch überprüft, obdiese Adresse bereits vergeben ist. Dabei ist zu be-merken, dass dieser gesamte Vorgang vollautomatisch

abläuft. Vom Grundprinzip her unterscheidet er sichvon den bisherigen Methoden, wie zum Beispiel dieAdressvergabe durch das Dynamic Host Configurati-on Protocol (DHCP) [Dro97], dahingehend, dass hierkeine zentrale Instanz über die vergebenen AdressenBuch führen muss.

Auch ist bei IPv6 das Renumbering, welches beiIPv4 keineswegs trivial ist und meist durch manuellesEingreifen erfolgen muss, vereinfacht worden. Durchdie Autokonfiguration und den vereinfachten Betriebvon mehreren parallelen IP-Adressen ist es nun ohneProbleme möglich, seine IP-Adresse, etwa bei einemProviderwechsel, zu ändern.

Eine später in die Spezifikation eingefügte Erwei-terung ist das so genannte Mobile IPv6. Der Kernge-danke bezieht sich darauf, dass ein Host überall unterder selben IP-Adresse erreichbar ist, egal, ob er sich inseinem Heimnetzwerk befindet oder mobil unterwegsist. Dabei wird im Heimnetz ein Home Agent, wel-cher das Mobilgerät vertritt, betrieben. Gelangt dasMobilgerät in einen anderen Adressbereich, so erhältes von dem für ihn zuständigen Router eine temporä-re Adresse, die Care-Of-Address (COA), welche dasGerät dem Heimagent mitteilt. Dieser kann nun ein-gehende Datagramme korrekt an den mobilen Hostzustellen. Diese Neuerung ist gerade in der heutigenZeit der aufkommenden internetfähigen mobilen Ge-räte von großem Nutzen.

Bei IPv6 gibt es keine Fragmentierung der Pake-te mehr. Standardmässig muss jeder Host Pakete bis

15


zu einer Größe von 1280B akzeptieren, was bei einerEthernet-MTU von 1500B kaum noch eine Auftei-lung der Daten nötig macht. Sind dem Empfänger dieankommenden Datagramme trotzdem zu groß, so teilter dies dem Sender via ICMP-Nachrichten mit und so-mit wird vor der Übertragung die maximal möglichePaketgröße ermittelt, was eine Steigerung der Effizi-enz zur Folge hat.

Weiterhin ist das neue Internet-Protokoll sichererund schneller als sein Vorgänger. Durch die bereits er-wähnten Erweiterungsheader sind nun Mechanismenzur sicheren Datenübertragung, wie Authentifikationund Datenintegritätsschutz, möglich und durch denvereinfachten Basis-Header und spezielle Routinger-weiterungen gelangen Datagramme schneller zu ih-rem Ziel.

Auffällig ist weiterhin, dass bei IPv6 keine Header-Prüfsumme mehr gebildet wird. Dies wurde in Fach-kreisen kontrovers diskutiert und man einigte sichdarauf, die beim Routing aufwändige Prüfsummen-berechnung wegzulassen. Dies wurde damit begrün-det, dass bei höherschichtigen Protokollen eben-falls eine Prüfsumme gebildet wird und man durchden Verzicht das Weiterleiten von Datagrammen be-schleunigt.

Als letzte Neuerung soll hier die einfache Erweiter-barkeit angeführt werden. Es ist auffällig, dass beimEntwurf von IPv6 besonders darauf geachtet wurde,zukünftige Neuerungen ohne große Änderungen ein-bauen zu können. Das Prinzip der Erweiterungshea-der bietet hierfür die Basis. Bereits jetzt existieren vie-le solcher Erweiterungsformen, doch diese alle zu be-handeln würde den Rahmen dieses Abschnitts spren-gen. Sie sind in den jeweiligen RFCs gut dokumen-tiert.

1.7.4. Ausblick

Momentan gibt es noch keine weltweit verbreiteteAnwendung, die ohne IPv6 nicht funktionieren würdeund es wird wohl auch noch dauern, bis sich die neueVersion durchgesetzt hat. Doch aufgrund der Adress-knappheit, vor allem im asiatischen Raum, wird wohlkein Weg daran vorbeiführen. Außerdem werden erstnoch einige Probleme, wie zum Beispiel die schwieri-ge Namensauflösung, die Gewährleistung der Kompa-tibilität zu IPv4 und den bestehenden höherschichti-gen Protokollen oder auch die aufkommenden Daten-schutzbedenken durch die „festen“ IP-Adressen, ge-löst werden müssen, damit IPv6 global das Steuer imInternet übernehmen kann.

1.8. Fazit

Das Internet-Protokoll ist von grundlegender Bedeu-tung für das heutige Internet oder Netzwerkkommuni-kation im Allgemeinen. Es organisiert die Fragmen-tierung, Adressierung und Zustellung von Datenpa-keten auf eine sehr simple, aber dennoch erstaunlichleistungsfähige und robuste Art und Weise. Diese istwohl auch der Grund für das relativ problemlose An-wachsen des Internets bis auf seine derzeitige Größeund lässt hoffen, dass auch zukünftige Aufgaben er-füllt werden können.

Unsere Netzwerke wachsen und das Internet-Protokoll ist sprichwörtlich der Leim, der alles zu-sammenhält.

16

2. Internet Control Message Protocol (ICMP)

Stephan Arenswald

2.1. Einführung

Das Internet Control Message Protocol (ICMP) ist einProtokoll, welches wie TCP und UDP (Kapitel 5ff)zur IP-Protokollfamilie gehört. Es bietet die Möglich-keit, in Netzwerken Fehlerinformationen und einfa-che Anfragen auszutauschen. Demzufolge ist es keinweiteres Transportprotokoll, obwohl es direkt auf IPaufbaut. Da TCP bereits eine verbindungsorientierteKommunikation bietet und durch UDP auch die ver-bindungslose Kommunikation abgedeckt ist, ist diesauch nicht nötig.

Bei den genannten Transportprotokollen gibt eseinen entscheidenden Nachteil. Was passiert zum Bei-spiel, wenn ein Paket abgeschickt wurde? Vielleichtkommt es an, aber vielleicht auch nicht. Jetzt könnteman argumentieren, dass TCP verbindungsorientiertist und eine einwandfreie Übertragung garantiert. ImFehlerfall wird die Verbindung aber abgebrochen, oh-ne dass genau das Problem angegeben wird. Es wur-de nicht dafür ausgelegt, den Grund zu ermitteln. Hierkommt ICMP ins Spiel. Dieses Protokoll ist für genaudiese Aufgabe konzipiert.

Das Internet Control Message Protocol wurde 1981von J. Postel im RFC 792 [Pos81a] spezifiziert. ICMPsetzt wie bereits erwähnt auf der IP-Protokoll-Familieauf. Trotzdem ist es ein unerlässlicher Teil des IP-Protokolls, weshalb jedes IP-Modul eine Implemen-tierung von ICMP beinhalten muss. Es wurde 1985durch RFC 950 [MP85] von J. Postel und J. Mogul er-weitert. Darauf wird hier allerdings nicht näher einge-gangen.

Wie zu Beginn angesprochen, dient das ICMP-Protokoll zur Übermittlung von Fehlermeldungen,z. B. falls eine Nachricht unterwegs verloren geht.Auf einige dieser Fehlermeldungen wird in Ab-schnitt 2.4.1 näher eingegangen. Als Anwendungsge-biet gelten aber auch Informationsaustausch und An-fragen. Der berühmteste Vertreter in dieser Kategorieist Ping. Dieses kleine Programm sendet eine Nach-richt an einen entfernten Computer und wartet, ob ei-

Layer Protokolle

App. HTTP FTP SMTP POP3 IRC DNS

Transp. TCP UDP

Network IP (IPv4,IPv6), ICMP

Link Ethernet WLAN

⇐

Abbildung 2.1.: ICMP im TCP/IP-Schichtenmodell.

datagram

IP-Datagramm

�� @@

IP-Header

type code checksum

Abbildung 2.2.: Aufbau des ICMP-Headers.

ne Antwort kommt. Dieses und einige andere Beispie-le werden in Abschnitt 2.4.2 behandelt. Des Weiterenfolgt ein kleiner Exkurs in das Gebiet Mobile IP. Auchdort spielt ICMP eine wichtige Rolle. In Abschnitt 2.5wird auf dieses Thema näher eingegangen.

2.2. Einordnung des ICMP

Obwohl das ICMP-Protokoll zu dem Network-Layergehört (siehe Abbildung 2.1), kann es nicht anstelledes IP-Protokolls eingesetzt werden. Es ist eine Er-gänzung zu diesem. Der Grund liegt darin, dass sichICMP nicht um den Transport selbst kümmert. D. h.es verwaltet weder Absender, Empfänger noch ande-re zur Übertragung wichtige Informationen.

17


2.3. Aufbau

Der Aufbau ist im Vergleich zu anderen Protokollensehr einfach. In Abbildung 2.2 ist zu sehen, dass derHeader (Kopf des Paketes, grau umrandet) lediglichaus 3 Feldern besteht:

Type Dieses Feld ist 8bit lang und gibt, dem Namennach, den Typ der ICMP-Nachricht an. Dazu ge-hören zum Beispiel 0=Echo Reply, 3=Destinati-on Unreachable oder 11=Time Exceeded.

Code Durch dieses ebenfalls 8bit lange Feld wirdder Typ näher spezifiziert. So kann Typ 11 (TimeExceeded) zusätzlich durch Code 0=TTL Excee-ded oder 1=Fragment Reassembly Timeout ge-nauer eingegrenzt werden. Dadurch ist eine ge-nauere Fehlerunterscheidung und demzufolge ei-ne bessere Fehlerbehandlung möglich.

Checksum Diese Prüfsumme dient dazu, festzu-stellen, ob die übertragene Nachricht so ange-kommen ist, wie sie abgesendet wurde. Soll-te ein Bit bei der Übertragung umgekippt sein,kann das damit erkannt werden. Die 16bit lan-ge Prüfsumme ergibt sich aus dem 16bit-1er-Komplement der Summe des 1er-Komplementsder ICMP-Nachricht. Das ist der gleiche Algo-rithmus, wie er bei dem IP-Protokoll verwendetwird.

In Tabelle 2.1 sind alle Message Types aufgeführt,welche im ursprünglichen RFC eingeführt wurden.Die aktuelle Liste (Juli 2006) umfasst mittlerweile48 Typen und mehrere hinzugefügte Codes. Bei Typ 3(Destination unreachable) zum Beispiel ist die An-zahl der Codes von 5 auf 15 gestiegen. Diese Listewird von der IANA verwaltet [Int06b].

Die Typen 9 und 10 aus Tabelle 2.1 gehören nichtzu RFC 792. Da sie jedoch in Abschnitt 2.4.2 behan-delt werden, sind sie zur Vollständigkeit mit eingetra-gen.

Das ICMP-Datagramm besteht aus den Nutzdaten,welche zur zusätzlichen Information für die jewei-ligen Typen und Codes dient. D. h. das Datagrammwird in zusätzliche Felder mit spezifischen Daten un-terteilt. Die Auswertung dieser Informationen erfolgtdemzufolge in Abhängigkeit von Typ und Code.

2.4. Aufgaben

Der Aufgabenbereich für ICMP erstreckt über al-le Arten von Netzwerken. Dazu gehören sowohl

LANs als auch WANs (Internet). Es werden allerdingskeine ICMP-Nachrichten aufgrund von Multicast-Nachrichten erzeugt. Diese könnten einen Host, wel-cher ein Paket an viele andere geschickt hat, völligüberlasten, da er von jedem Empfänger eine Nach-richt mit dem gleichen Problem erhalten könnte.

2.4.1. Fehlermeldungen

Lifetime Exceeded Eine Fehlermeldung auf-grund der Lebenszeitüberschreitung kann aus zweiGründen generiert werden. Der erste ist, dass die TTL(Time To Live) abgelaufen ist. Als zweites gibt eseinen Timeout beim Zusammensetzen von Fragmen-ten.

Sollte ein Router ein Paket erhalten, dessen TTLgleich 0 ist, muss es verworfen werden (siehe Abbil-dung 2.3). Jetzt kann der Host, welcher das Paket ur-sprünglich versendet hat, darüber informiert werden.Die Adresse zu diesem steht im IP-Header. Der Rou-ter schickt also eine ICMP-Nachricht an den Host undinformiert ihn, dass die Lebenszeit abgelaufen ist. DerAufbau dieser Nachricht ist in Abbildung 2.4(a) zu se-hen.

Wie bereits angesprochen, kann diese Fehlermel-dung auch gesendet werden, wenn beim Zusammen-setzen von Fragmenten ein Timeout auftritt. Fehlt einTeil, wartet der empfangende Host eine gewisse Zeit.Ist diese abgelaufen, wird eine ICMP-Nachricht anden Absender geschickt. Der Rest des Datagrammswird verworfen.

Parameter Problem Angenommen, ein Host ver-sendet ein Paket mit Hilfe von IP Version 4 (IPv4).Dafür wird im IP-Header das Feld „Version“ auf01002 = 410 gesetzt. Auf dem Weg zum Empfän-ger kippen nun 3 Bits um, so dass sich das Feld auf00112 = 310 ändert. Diese Version gibt es nicht. DerEmpfänger kann das Paket nicht verarbeiten. Entspre-chend wird der Absender informiert, das es ein Pro-blem im IP-Header gibt. Abbildung 2.5 verdeutlichtdas Beispiel anhand einer Grafik.

Die ICMP-Nachricht besitzt nach dem Header ein8bit langes Feld für einen Pointer. Dieser zeigt aufdas fehlerbehaftete Oktett im IP-Header. Für den be-schriebenen Fehlerfall (Fehler im Versionsfeld) wür-de der Pointer auf 1, also das erste Oktett im IP-Header zeigen (siehe Abbildung 2.4(b)).

Source Quench Übersetzt heißt Source Quenchden „Absender dämpfen“. Diese Nachricht wird voneinem beliebigen Zielhost (Router sind damit nicht

18

2.4. Aufgaben

Type Code Description RFC

0 0 echo reply 792 [Pos81a]

3 destination unreachable: 792 [Pos81a]0 network unreachable1 host unreachable2 protocol unreachable3 port unreachable4 fragmentation needed but don’t fragment bit set5 source route failed

4 0 source quench 792 [Pos81a]

5 redirect 792 [Pos81a]0 Redirect datagrams for the network1 Redirect datagrams for the host2 Redirect datagrams for the type of service and network3 Redirect datagrams for the type of service and host

8 0 echo request 792 [Pos81a]

9 0 router advertisement 1256 [Dee91]10 0 router solicitation 1256 [Dee91]

11 time exceeded 792 [Pos81a]0 time to live exceeded in transit1 fragment reassembly time exceeded

12 header problem 792 [Pos81a]0 IP header problem

13 0 timestamp message 792 [Pos81a]14 0 timestamp reply message 792 [Pos81a]

15 0 information request message 792 [Pos81a]16 0 information reply message 792 [Pos81a]

Tabelle 2.1.: Nachrichtentypen bei ICMP.

Abbildung 2.3.: Lebenszeit überschritten.

19


unused

Internet Header + 64bit des Original-Datagramms

11 0 od. 1 checksum

(a) Lifetime Exceeded

00000001 unused

Internet Header + 64bit des Original-Datagramms

12 0 od. 1 checksum

(b) Parameter Problem

unused

Internet Header + 64 des Original-Datagramms

4 0 checksum

(c) Source Quench

unused


5 0 - 1 checksum

(d) Redirect

unused


3 1 checksum

(e) Destination Unreachable

Abbildung 2.4.: ICMP-Pakete von verschiedenen Fehlermeldungen.

Abbildung 2.5.: Ungültige Parameter.

20

2.4. Aufgaben

ausgeschlossen) an den Absender eines Paketes ge-schickt. Dafür kann es zwei Gründe geben: entwedereine zu hohe Auslastung der Serververbindung oderdass der Server die Pakete nicht schnell genug abar-beiten kann.

Angenommen, ein Netzwerk besteht aus einemDatenbankserver und zehn Clients (siehe Abbil-dung 2.6). Diese führen permanent sehr viele Anfra-gen auf dem Server aus. Dadurch entsteht eine ho-he Netzwerkauslastung. Kommt nun ein elfter Clienthinzu, welcher ebenfalls einen hohen Datenverkehrerzeugt, schickt der Server eine ICMP-Nachricht andiesen, wenn der Pufferplatz nicht ausreichen sollte.Das Format dieser Nachricht ist in Abbildung 2.4(c)zu sehen.

Wie bereits erwähnt, ist es auch möglich, dass einClient zu schnell Nachrichten sendet. Der Server ver-sucht darauf hin mit Source-Quench-Nachrichten dieSenderate des Absenders zu drosseln. Er schickt solange ICMP-Nachrichten, bis die Datenrate auf sei-nem gewünschten Niveau liegt. Durch ein langsa-mes Herantasten an die Übertragungsgrenze kann derClient eine bestmögliche Übertragungsrate erzielen.

Redirect Dieser Nachrichtentyp wird für das fol-gende Problem, welches in Abbildung 2.7 dargestelltist, verwendet. Ein Computer C1 möchte mit einemzweiten (C2) kommuniziere

Berichte zur Rechnerarchitektur - uni-jena.deehp-head/c3/tcpip.pdf · 2010. 10. 28. · Berichte...

Documents

Transcript of Berichte zur Rechnerarchitektur - uni-jena.deehp-head/c3/tcpip.pdf · 2010. 10. 28. · Berichte...