Zum Hauptinhalt springen

3. Spezifikation

Dieses Kapitel bietet die vollständige Spezifikation des Internet-Protokolls (Internet Protocol, IP), einschließlich des Header-Formats, detaillierter Feldbeschreibungen, Betriebsverfahren und Schnittstellendefinitionen.

3.1. Internet-Header-Format​

Eine Zusammenfassung des Inhalts des Internet-Headers folgt:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
||Version|  IHL  |Type of Service|          Total Length         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
||         Identification        |Flags|      Fragment Offset    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
||  Time to Live |    Protocol   |         Header Checksum       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
||                       Source Address                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
||                    Destination Address                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
||                    Options                    |    Padding    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Beispiel Internet-Datagramm-Header (Abbildung 4)

Beachten Sie, dass jede Markierung eine Bitposition darstellt.

Feldbeschreibungen​

Version: 4 Bits​

Das Versionsfeld gibt das Format des Internet-Headers an. Dieses Dokument beschreibt Version 4.

IHL (Internet Header Length, Internet-Header-Länge): 4 Bits​

Die Internet-Header-Länge ist die Länge des Internet-Headers in 32-Bit-Wörtern und zeigt somit auf den Beginn der Daten. Beachten Sie, dass der Mindestwert für einen korrekten Header 5 ist.

Type of Service (Diensttyp): 8 Bits​

Der Diensttyp bietet eine Angabe der abstrakten Parameter der gewünschten Dienstqualität. Diese Parameter sollen (are to) verwendet werden, um die Auswahl der tatsächlichen Dienstparameter bei der Übertragung eines Datagramms durch ein bestimmtes Netzwerk zu leiten.

Bits 0-2:  Priorität (Precedence)
Bit    3:  0 = Normale Verzögerung,      1 = Niedrige Verzögerung
Bit    4:  0 = Normaler Durchsatz, 1 = Hoher Durchsatz
Bit    5:  0 = Normale Zuverlässigkeit, 1 = Hohe Zuverlässigkeit
Bits 6-7:  Reserviert für zukünftige Verwendung

     0     1     2     3     4     5     6     7
  +-----+-----+-----+-----+-----+-----+-----+-----+
  |                 |     |     |     |     |     |
  |   PRIORITÄT     |  D  |  T  |  R  |  0  |  0  |
  |                 |     |     |     |     |     |
  +-----+-----+-----+-----+-----+-----+-----+-----+

Prioritätswerte:

  • 111 - Network Control
  • 110 - Internetwork Control
  • 101 - CRITIC/ECP
  • 100 - Flash Override
  • 011 - Flash
  • 010 - Immediate
  • 001 - Priority
  • 000 - Routine

Total Length (Gesamtlänge): 16 Bits​

Die Gesamtlänge ist die Länge des Datagramms, gemessen in Oktetten, einschließlich Internet-Header und Daten. Dieses Feld ermöglicht eine Datagrammlänge von bis zu 65.535 Oktetten. Alle Hosts müssen (must) darauf vorbereitet sein, Datagramme von bis zu 576 Oktetten zu akzeptieren. Es wird empfohlen (recommended), dass Hosts nur Datagramme größer als 576 Oktetten senden, wenn sie die Gewissheit haben, dass das Ziel bereit ist, die größeren Datagramme zu akzeptieren.

Identification (Kennung): 16 Bits​

Ein vom Sender zugewiesener Identifikationswert, um beim Zusammensetzen der Fragmente eines Datagramms zu helfen.

Flags (Flaggen): 3 Bits​

Verschiedene Kontroll-Flags.

  • Bit 0: reserviert, muss (must) Null sein
  • Bit 1: (DF) 0 = Darf fragmentieren (May Fragment), 1 = Nicht fragmentieren (Don't Fragment)
  • Bit 2: (MF) 0 = Letztes Fragment, 1 = Weitere Fragmente

Fragment Offset (Fragment-Offset): 13 Bits​

Dieses Feld gibt an, wo im Datagramm dieses Fragment hingehört. Der Fragment-Offset wird in Einheiten von 8 Oktetten (64 Bits) gemessen. Das erste Fragment hat einen Offset von Null.

Time to Live (Lebensdauer): 8 Bits​

Dieses Feld gibt die maximale Zeit an, die das Datagramm im Internet-System verbleiben darf. Wenn dieses Feld den Wert Null enthält, dann muss (must) das Datagramm zerstört werden. Dieses Feld wird bei der Internet-Header-Verarbeitung geändert. Die Zeit wird in Sekunden gemessen, aber da jedes Modul, das ein Datagramm verarbeitet, die TTL um mindestens eins dekrementieren muss (must), auch wenn es das Datagramm in weniger als einer Sekunde verarbeitet, muss (must) die TTL nur als Obergrenze für die Zeit betrachtet werden, die ein Datagramm existieren kann (may).

Protocol (Protokoll): 8 Bits​

Dieses Feld gibt das Protokoll der nächsten Ebene an, das im Datenteil des Internet-Datagramms verwendet wird. Die Werte für verschiedene Protokolle sind in „Assigned Numbers" [9] angegeben.

Häufige Werte:

  • 1 = ICMP
  • 6 = TCP
  • 17 = UDP

Header Checksum (Header-Prüfsumme): 16 Bits​

Eine Prüfsumme nur für den Header. Da sich einige Header-Felder ändern (z. B. Lebensdauer), wird diese an jedem Punkt neu berechnet und verifiziert, an dem der Internet-Header verarbeitet wird.

Der Prüfsummenalgorithmus lautet: Das Prüfsummenfeld ist das 16-Bit-Einerkomplement der Einerkomplement-Summe aller 16-Bit-Wörter im Header. Für die Berechnung der Prüfsumme ist der Wert des Prüfsummenfeldes Null.

Source Address (Quelladresse): 32 Bits​

Die Quelladresse.

Destination Address (Zieladresse): 32 Bits​

Die Zieladresse.

Options (Optionen): variabel​

Die Optionen können (may) in Datagrammen erscheinen oder nicht. Sie müssen (must) von allen IP-Modulen (Hosts und Gateways) implementiert werden. Was optional ist, ist ihre Übertragung in einem bestimmten Datagramm, nicht ihre Implementierung.

3.2. Diskussion​

Adressierung​

Um Flexibilität bei der Zuweisung von Adressen an Netzwerke zu bieten und eine große Anzahl kleiner bis mittelgroßer Netzwerke zu ermöglichen, ist die Interpretation des Adressfeldes so kodiert, dass sie eine kleine Anzahl von Netzwerken mit einer großen Anzahl von Hosts, eine moderate Anzahl von Netzwerken mit einer moderaten Anzahl von Hosts und eine große Anzahl von Netzwerken mit einer kleinen Anzahl von Hosts spezifiziert.

Adressformate:

|| Höchstwertige Bits | Format | Klasse | ||-------------------|--------|--------| || 0 | 7 Bits Netzwerk, 24 Bits Host | a | || 10 | 14 Bits Netzwerk, 16 Bits Host | b | || 110 | 21 Bits Netzwerk, 8 Bits Host | c | || 111 | Escape zum erweiterten Adressierungsmodus | - |

Fragmentierung und Reassemblierung​

Das Internet-Kennungsfeld (ID) wird zusammen mit den Quell- und Zieladressen sowie dem Protokollfeld verwendet, um Datagramm-Fragmente für die Reassemblierung zu identifizieren.

Das More Fragments-Flag-Bit (MF) wird gesetzt, wenn das Datagramm nicht das letzte Fragment ist. Das Fragment-Offset-Feld identifiziert die Position des Fragments relativ zum Anfang des ursprünglichen, nicht fragmentierten Datagramms. Fragmente werden in Einheiten von 8 Oktetten gezählt.

Jedes Internet-Modul muss (must) in der Lage sein, ein Datagramm von 68 Oktetten ohne weitere Fragmentierung weiterzuleiten. Dies liegt daran, dass ein Internet-Header bis zu 60 Oktetten groß sein kann und das minimale Fragment 8 Oktetten beträgt.

Jedes Internet-Ziel muss (must) in der Lage sein, ein Datagramm von 576 Oktetten entweder in einem Stück oder in zu reassemblierenden Fragmenten zu empfangen.

3.3. Schnittstellen​

Die funktionale Beschreibung von Benutzerschnittstellen zum IP ist bestenfalls fiktiv, da jedes Betriebssystem unterschiedliche Möglichkeiten haben wird. Jedoch müssen (must) alle IPs einen bestimmten Mindestsatz von Diensten bereitstellen, um zu garantieren, dass alle IP-Implementierungen dieselbe Protokollhierarchie unterstützen können (can).

Beispiel für eine Schnittstelle der oberen Ebene​

Die folgenden zwei Beispielaufrufe erfüllen die Anforderungen für die Kommunikation zwischen Benutzer und Internet-Protokollmodul („=>" bedeutet gibt zurück):

SEND (SENDEN)

SEND (src, dst, prot, TOS, TTL, BufPTR, len, Id, DF, opt => result)

wobei:

  • src = Quelladresse
  • dst = Zieladresse
  • prot = Protokoll
  • TOS = Diensttyp
  • TTL = Lebensdauer
  • BufPTR = Pufferzeiger
  • len = Pufferlänge
  • Id = Kennung
  • DF = Nicht fragmentieren (Don't Fragment)
  • opt = Optionsdaten
  • result = Antwort
    • OK = Datagramm erfolgreich gesendet
    • Error = Fehler in Argumenten oder lokaler Netzwerkfehler

RECV (EMPFANGEN)

RECV (BufPTR, prot, => result, src, dst, TOS, len, opt)

wobei:

  • BufPTR = Pufferzeiger
  • prot = Protokoll
  • result = Antwort
    • OK = Datagramm erfolgreich empfangen
    • Error = Fehler in Argumenten
  • len = Pufferlänge
  • src = Quelladresse
  • dst = Zieladresse
  • TOS = Diensttyp
  • opt = Optionsdaten

Zusammenfassung​

Diese Spezifikation definiert das Internet-Protokoll Version 4 (IPv4), das Folgendes bereitstellt:

  • Verbindungslose Datagramm-Zustellung
  • Best-Effort-Dienst (keine Zuverlässigkeitsgarantien)
  • Fragmentierungs- und Reassemblierungsfähigkeiten
  • Adressierung für bis zu 2^32 Hosts
  • Routing durch miteinander verbundene Netzwerke
  • Diensttyp-Angabe
  • Lebensdauer-Verwaltung
  • Optionen für spezielle Behandlung

Das Protokoll ist so konzipiert, dass es einfach, skalierbar und flexibel ist und dem Internet ermöglicht, verschiedene Anwendungen und Netzwerktechnologien zu unterstützen.

Für vollständige Details zu allen IP-Optionen, Fragmentierungsverfahren, Reassemblierungsalgorithmen und Implementierungsanforderungen konsultieren Sie bitte den vollständigen Text von RFC 791.

Hinweis: Dies ist eine verkürzte Version von RFC 791 Abschnitt 3. Für die vollständige Spezifikation einschließlich detaillierter Optionsformate, Fragmentierungs-/Reassemblierungs-Pseudocode und aller Randfälle konsultieren Sie das offizielle RFC 791-Dokument.

Letztes Update am