Wohl kaum ein anderes Protokoll hat sich in der Netzwerktechnik einen dermaßen großen Ruhm verschafft, wie das Internet Protokoll. Aufgrund der flexiblen Einsatzmöglichkeiten im LAN, WAN und dem Internet selbst, hat es im Laufe der Jahre andere Protokolle wie IPX oder AppleTalk fast vollständig verdrängt.

Das Internet Protokoll Version 4 ist ein verbindungsloses Protokoll und nimmt seinen Platz in der Vermittlungsschicht (Schicht 3) des OSI-Referenzmodells ein. Die Eigenschaft verbindunglos beruht darauf, dass das IPv4 selbst keine Mechanismen bereitstellt, um dem Sender die erfolgreiche oder nicht erfolgreiche Zustellung eines Datenpakets mitzuteilen. Diese Aufgabe übernehmen Protokolle in der darüberliegenden Transportschicht (Schicht 4). Beispielsweise TCP. Damit beschränken sich die Hauptaufgaben von IPv4 auf die Adressierung und im Fall der Fragmentierung auf die Markierung der einzelnen Fragmente .

IPv4 stellt zur Adressierung 32 Bit bereit, welche in vier Oktette aufgeteilt werden. Daraus folgt, dass jedes Oktett einen Dezimalwert von 0 bis 255 annehmen kann:

Welche IPv4-Adressen für welche Zwecke verwendet werden können oder in welchen logischen Netzen sie liegen dürfen, sind eigenständige Themenbereiche (CIDR, VLSM), beziehungsweise Prozesse (Routing) und haben grundsätzlich erstmal nichts mit dem Internet Protokoll Version 4 zu tun. Das IPv4 kennt nur 32 Bit Adressen. Die des Absenders und die des Empfängers.

Als bekannte Größe im Kapselungsprozess wird für den IPv4 Header samt den zugeöhrigen Nutzdaten eine feste Größe reserviert, damit bei der Übertragung die MTU des Protokolls der Sicherungsschicht eingehalten wird. In einem Netz wie dem Internet sind die verwendeten Übertragungstechnologien, respektive die Protokolle der Sicherungsschicht die auf dem Weg zum Ziel Anwendung finden nicht vorhersehbar. Somit kann es vorkommen, dass zwischen zwei Netzkoppelelementen das Datenpaket der Vermittlungsschicht nicht mehr komplett in den Frame der Sicherungsschicht passt. Es muss fragmentiert werden:

Der Header des IPv4 liefert alle notwendigen Felder mit, um die Fragmentierung und die spätere Zusammensetzung zu ermöglichen:

• Identification
  16 Bit Wert der Zusammen mit der Absenderadresse die Zusammengehörigkeit eines Datenpakets symbolisiert
• Fragment Flags
  3 Bit Wert der die Fragmentierung steuert
  1. Bit = immer 0
  2. Bit = 0 oder 1 (Fragmentierung erlaubt oder verboten)
  3. Bit = 0 oder 1 (Letztes Fragment oder weitere Fragmente folgen)
• Fragment Offset
  13 Bit Wert der die Reihenfolge der Fragmente angibt

Somit können die Daten unabhängig von der verwendeten Technologie der Sicherungsschicht übertragen werden. Ein gravierender Nachteil der Fragmentierung ist jedoch der erhöhte Arbeitsaufwand für die Netzkoppelelemente. Daraus folgt in aller Regel eine Reduzierung des Durchsatzes, also der realen Übertragungsgeschwindigkeit.

Um eine Fragmentierung auf dem Pfad zum Ziel so gut wie möglich zu vermeiden, setzen mittlerweile viele IPv4 Implementierungen das zweite Bit der Fragment Flags (Don't Fragment), in der Hoffnung, dass fragmentierende Router eine Fehlermeldung per ICMP zurückliefern. Daraufhin kann der Absender die MTU verkleinern. Diese Methode setzt aber voraus, dass die betreffenden Router auf dem Pfad zum Ziel auch alle ICMP Nachrichten behandeln.

Schließlich sollen noch der Aufbau des IPv4 Headers und die restlichen Felder betrachtet werden:

• Version
  Gibt die verwendete Version des Internet Protokolls an. Hier IPv4.
• IHL (Internet Header Length)
  Definiert die Größe des IP-Headers. Der Wert wird jeweils mit 32 Bit multipliziert. Üblich ist hier der Eintrag 0101. Dies entspricht dem Dezimalwert 5, welcher multipliziert mit 32 Bit auf die typische Länge von 20 Bytes kommt. Die maximale Länge des IP-Headers beträgt 60 Bytes.
• TOS (Type of Service)
  Ermöglicht beispielsweise Angaben zur Priorisierung der Daten. Die Interpretation dieses Feldes wurde im Laufe der Zeit oft geändert. Aktuell wird ein Teil der Bits 0 bis 5 zur Einteilung in Codepoints verwendet und die Bits 6 bis 7 werden zur Überlastkontrolle eingesetzt, womit Netzkoppelelemente die Teilnehmer bei drohender Überlast zur Reduzierung des Datenaufkommens auffordern können (ECN). Diese Werte werden am Netzzugangspunkt eines Internetproviders in der Regel überschrieben, damit kein Missbrauch betrieben werden kann. In lokalen WANs lässt sich damit aber eine qualitativ hochwertige Priorisierung einstellen, so lange die Netzwerkgeräte dies auch unterstützen. Weiterführender Weblink
• Total Length
  Gibt die Gesamtlänge eines IP-Datenpakets inklusive des Headers an. Maximal möglich sind 64 KB.
• TTL
  Definiert die Lebensdauer. Aufgrund der teilweise sehr hohen Komplexität von Netzen kann es mitunter vorkommen, dass IP-Pakete in Endlosschleifen rotieren und nie das Ziel erreichen. Um diesem Problem vorzubeugen, dekrementiert jeder Router die TTL um 1. Wird der Wert 0 erreicht, gilt das IP-Paket als verworfen und es erfolgt eine Mitteilung an den Absender.
• Protocol
  Hier wird das Protokoll angegeben, an dass das IP-Datenpaket beim Empfänger weitergegeben werden soll. Beispielsweise steht hier 6 für TCP und 17 für UDP.  Vollständige Liste
• Header Checksum
  Prüfsumme für den Header. Aufgrund der Dekrementierung des TTL-Wertes in jedem Router muss dieser die Prüfsumme auch immer neu berechnen und eintragen.
• Source Address
  IP-Adresse des Senders.
• Destination Adress
  IP-Adresse des Empfängers
• Optional/Padding
  Dieses Feld wird vorwiegend für Testzwecke eingesetzt. Mögliche Optionen:
  Record Route - Protokollierun des Netzpfades
  Loose Source Routing - Der Sender gibt eine Liste mit Netzknoten vor, die angesteuert werden sollen
  Strict Source Routing - Der Sender gibt eine Liste mit Netzknoten vor, die in selbiger Reihenfolge angesteuert werden müssen
  Timestamp - Jeder Netzknoten trägt die Zeit der Bearbeitung ein
  Security - Das IP-Datenpaket darf keinen Pfad über unzuverlässige Netze nehmen