Zum Hauptinhalt springen

1. Einführung

1.1. Motivation

Das Internet-Protokoll (Internet Protocol) ist für die Verwendung in miteinander verbundenen Systemen von paketvermittelnden Computerkommunikationsnetzwerken konzipiert. Ein solches System wurde als „Catenet" [1] bezeichnet. Das Internet-Protokoll bietet die Übertragung von Datenblöcken, die Datagramme (datagrams) genannt werden, von Quellen zu Zielen, wobei Quellen und Ziele Hosts sind, die durch Adressen fester Länge identifiziert werden. Das Internet-Protokoll bietet auch die Fragmentierung (fragmentation) und Reassemblierung (reassembly) langer Datagramme, falls erforderlich, für die Übertragung durch „kleine Paket"-Netzwerke.

Grundlegende Designziele

1. Vernetzung

Netzwerk A ←→ Gateway ←→ Netzwerk B ←→ Gateway ←→ Netzwerk C
↓ ↓ ↓
Host 1 Host 2 Host 3

IP ermöglicht die Vernetzung verschiedener Netzwerktypen

2. Datagramm-Zustellung

  • Verbindungsloser Dienst (connectionless)
  • Jedes Datagramm wird unabhängig geroutet
  • Keine Garantie für Zustellung, Reihenfolge oder Schutz vor Duplizierung

3. Adressierung

  • 32-Bit-Adressen fester Länge
  • Eindeutige Identifikation jedes Hosts im Internet
  • Hierarchische Struktur (Netzwerk + Host)

4. Fragmentierung und Reassemblierung

Großes Datagramm (1500 Bytes)
↓ Fragmentierung
Fragment 1 (500 Bytes) + Fragment 2 (500 Bytes) + Fragment 3 (500 Bytes)
↓ Übertragung durch Kleinpaket-Netzwerk
↓ Reassemblierung
Großes Datagramm (1500 Bytes)

1.2. Umfang

Das Internet-Protokoll ist im Umfang speziell darauf beschränkt, die Funktionen bereitzustellen, die zum Zustellen eines Bitpakets (eines Internet-Datagramms) von einer Quelle zu einem Ziel über ein miteinander verbundenes Netzwerksystem erforderlich sind. Es gibt keine Mechanismen zur Verbesserung der End-to-End-Datenzuverlässigkeit, Flusskontrolle, Sequenzierung oder anderer Dienste, die häufig in Host-to-Host-Protokollen zu finden sind. Das Internet-Protokoll kann (kann) die Dienste seiner unterstützenden Netzwerke nutzen, um verschiedene Arten und Qualitäten von Diensten bereitzustellen.

Was IP NICHT bereitstellt

|| Funktion | IP stellt bereit | Bereitgestellt durch | ||----------|------------------|----------------------| || Zuverlässige Zustellung | ❌ Nein | TCP | || Flusskontrolle | ❌ Nein | TCP | || Sequenzierung | ❌ Nein | TCP | || Fehlerwiederherstellung | ❌ Nein | TCP | || Verbindungsverwaltung | ❌ Nein | TCP | || Staukontrolle | ❌ Nein | TCP |

Was IP bereitstellt

|| Funktion | Beschreibung | ||----------|--------------| || ✅ Adressierung | 32-Bit-IP-Adressen | || ✅ Routing | Datagramm-Weiterleitung | || ✅ Fragmentierung/Reassemblierung | Anpassung an unterschiedliche MTUs | || ✅ Lebensdauer | TTL verhindert Schleifen | || ✅ Diensttyp | ToS-Feld | || ✅ Header-Prüfsumme | Erkennung von Header-Fehlern |

Designphilosophie

End-to-End-Prinzip:
- IP-Schicht einfach halten
- Komplexe Funktionen an Endpunkten implementiert
- Netzwerkkern führt nur Weiterleitung durch

Vorteile:
✅ Netzwerkskalierbarkeit
✅ Unterstützung mehrerer Protokolle oberer Schichten
✅ Isolation der Fehlerdomäne

1.3. Schnittstellen

Dieses Protokoll wird von Host-to-Host-Protokollen in einer Internet-Umgebung aufgerufen. Dieses Protokoll ruft lokale Netzwerkprotokolle auf, um das Internet-Datagramm zum nächsten Gateway oder Ziel-Host zu transportieren.

Schnittstelle der oberen Schicht

Beispiel: TCP ruft IP auf

Das TCP-Modul würde das Internet-Modul aufrufen, um ein TCP-Segment 
(einschließlich TCP-Header und Benutzerdaten) als Datenteil eines
Internet-Datagramms zu nehmen. Das TCP-Modul würde die Adressen und
andere Parameter im Internet-Header dem Internet-Modul als Argumente
des Aufrufs bereitstellen.

Schnittstellenfluss:

Anwendungsschicht
↓ Daten
Transportschicht (TCP/UDP)
↓ TCP-Segment/UDP-Datagramm
Netzwerkschicht (IP) ← IP-Header hinzufügen
↓ IP-Datagramm
Sicherungsschicht (Ethernet/etc)
↓ Frame
Physikalische Schicht

Schnittstelle der unteren Schicht

Beispiel: IP ruft lokales Netzwerk auf

Im Fall von ARPANET würde das Internet-Modul beispielsweise ein 
lokales Netzmodul aufrufen, das den 1822-Leader [2] zum Internet-
Datagramm hinzufügt und eine ARPANET-Nachricht erstellt, die an
den IMP (Interface Message Processor) übermittelt werden soll.
Die ARPANET-Adresse würde von der lokalen Netzwerkschnittstelle
aus der Internet-Adresse abgeleitet.

1822-Protokollbeispiel:

+------------------+------------------+
|| 1822-Leader | IP-Datagramm |
|| (ARPANET-spezifisch) | (Generisches Format) |
+------------------+------------------+

Schnittstellenparameter

IP-Sende-Schnittstelle:

send_ip_datagram(
source_address, // Quell-IP-Adresse
dest_address, // Ziel-IP-Adresse
protocol, // Protokoll oberer Schicht (TCP=6, UDP=17)
tos, // Diensttyp
ttl, // Lebensdauer
data, // Daten
length, // Datenlänge
options // IP-Optionen (optional)
);

IP-Empfangs-Schnittstelle:

receive_ip_datagram(
source_address, // Quell-IP-Adresse
dest_address, // Ziel-IP-Adresse
protocol, // Protokoll oberer Schicht
data, // Daten
length // Datenlänge
);

1.4. Betrieb

Das Internet-Protokoll implementiert zwei grundlegende Funktionen: Adressierung und Fragmentierung.

Adressierung

Die Internet-Module verwenden die im Internet-Header mitgeführten Adressen, um Internet-Datagramme zu ihren Zielen zu übertragen. Die Auswahl eines Pfades für die Übertragung wird als Routing bezeichnet.

Adressstruktur:

32-Bit-IP-Adresse = Netzwerkanteil + Hostanteil

Klasse A: [0][7-Bit-Netzwerk][24-Bit-Host]
Klasse B: [10][14-Bit-Netzwerk][16-Bit-Host]
Klasse C: [110][21-Bit-Netzwerk][8-Bit-Host]

Routing-Entscheidung:

def route_datagram(dest_ip):
if dest_ip in local_network:
# Direkte Zustellung
send_to_host(dest_ip)
else:
# An Gateway weiterleiten
gateway = lookup_routing_table(dest_ip)
send_to_gateway(gateway, datagram)

Fragmentierung

Die Internet-Module verwenden Felder im Internet-Header, um Internet-Datagramme bei Bedarf für die Übertragung durch „kleine Paket"-Netzwerke zu fragmentieren und zu reassemblieren.

Fragmentierungsprozess:

Ursprüngliches Datagramm (MTU=1500):
+--------+------------------------+
|| IP-Header | 1480 Bytes Daten |
+--------+------------------------+

Nach Fragmentierung durch MTU=500-Netzwerk:

Fragment 1:
+--------+--------+
|| IP-Header | 480 Bytes | MF=1, Offset=0
+--------+--------+

Fragment 2:
+--------+--------+
|| IP-Header | 480 Bytes | MF=1, Offset=60
+--------+--------+

Fragment 3:
+--------+--------+
|| IP-Header | 520 Bytes | MF=0, Offset=120
+--------+--------+

Fragmentierungsfelder:

  • Identification: Identifiziert das ursprüngliche Datagramm
  • Flags:
    • DF (Don't Fragment): Nicht fragmentieren
    • MF (More Fragments): Weitere Fragmente folgen
  • Fragment Offset: Position des Fragments im ursprünglichen Datagramm (8-Byte-Einheiten)

Betriebsmodell

Das Betriebsmodell besagt, dass ein Internet-Modul in jedem Host, der an der Internet-Kommunikation beteiligt ist, und in jedem Gateway, das Netzwerke miteinander verbindet, vorhanden ist. Diese Module teilen gemeinsame Regeln für die Interpretation von Adressfeldern und für die Fragmentierung und Zusammensetzung von Internet-Datagrammen. Darüber hinaus haben diese Module (insbesondere in Gateways) Verfahren für Routing-Entscheidungen und andere Funktionen.

Das Internet-Protokoll behandelt jedes Internet-Datagramm als unabhängige Entität, die nicht mit einem anderen Internet-Datagramm zusammenhängt. Es gibt keine Verbindungen oder logischen Schaltungen (virtuell oder anderweitig).

Sender:
1. Daten von oberer Schicht empfangen
2. IP-Header hinzufügen
3. Routing-Tabelle nachschlagen
4. Bei Bedarf fragmentieren
5. An lokales Netzwerk übergeben

Zwischengateway:
1. IP-Datagramm empfangen
2. Zieladresse prüfen
3. Routing-Tabelle nachschlagen
4. TTL dekrementieren
5. Bei Bedarf fragmentieren
6. Zum nächsten Hop weiterleiten

Empfänger:
1. IP-Datagramm empfangen
2. Zieladresse prüfen (ist es für mich?)
3. Reassemblieren, falls fragmentiert
4. An Protokoll oberer Schicht übergeben

Schlüsselmechanismen

Das Internet-Protokoll verwendet vier Schlüsselmechanismen zur Bereitstellung seines Dienstes: Diensttyp, Lebensdauer, Optionen und Header-Prüfsumme.

Diensttyp (Type of Service)

  • Wird verwendet, um die gewünschte Dienstqualität anzugeben
  • Abstrakter oder verallgemeinerter Parametersatz
  • Wird von Gateways zur Auswahl von Übertragungsparametern verwendet
  • Leitet Routing- und Netzwerkauswahlentscheidungen

Lebensdauer (Time to Live)

  • Obergrenze für die Lebensdauer des Datagramms
  • Vom Sender festgelegt, bei jedem Hop dekrementiert
  • Datagramm wird zerstört, wenn TTL Null erreicht
  • Kann als Selbstzerstörungszeitlimit betrachtet werden

Optionen

  • Kontrollfunktionen, die in einigen Situationen benötigt werden
  • Für die meisten gängigen Kommunikationen unnötig
  • Umfassen Bestimmungen für Zeitstempel, Sicherheit und spezielles Routing

Header-Prüfsumme

  • Überprüfung, dass der Header korrekt übertragen wurde
  • Daten können (may) Fehler enthalten (nicht von IP geprüft)
  • Wenn die Prüfsumme fehlschlägt, wird das Datagramm sofort verworfen

Zuverlässigkeitsmodell

Das Internet-Protokoll bietet keine zuverlässige Kommunikationseinrichtung. Es gibt keine Bestätigungen, weder End-to-End noch Hop-by-Hop. Es gibt keine Fehlerkontrolle für Daten, nur eine Header-Prüfsumme. Es gibt keine Neuübertragungen. Es gibt keine Flusskontrolle.

Erkannte Fehler können (may) über das Internet Control Message Protocol (ICMP) [3] gemeldet werden, das im Internet-Protokollmodul implementiert ist.


Zusammenfassung der Schlüsselkonzepte

Datagramm

  • Unabhängiges Paket
  • Enthält vollständige Adressierungsinformationen
  • Kann unabhängig geroutet werden

Verbindungslos

  • Keine Verbindungseinrichtung erforderlich
  • Jedes Datagramm wird unabhängig behandelt
  • Einfach und effizient

Best Effort

  • Keine Garantie für Zustellung
  • Keine Garantie für Reihenfolge
  • Keine Garantie gegen Duplizierung
  • Zuverlässigkeit wird von Protokollen oberer Schichten behandelt

Designphilosophie: Das IP-Protokoll folgt der Designphilosophie „einfaches Netzwerk, intelligente Endpunkte", die Komplexität an die Netzwerkränder schiebt und den Netzwerkkern einfach und skalierbar hält. Dieses Design ermöglicht es dem Internet, eine große Vielfalt an Anwendungen und Diensten zu unterstützen.