IPv4

Zahl der Rechner im Internet (1981 bis 2003)

IPv4 wurde als Teil der Internetprotokollfamilie für das Arpanet entwickelt und kam darin ab 1983 zum Einsatz. Damals waren nur einige hundert Rechner an das Netz angeschlossen. Das Arpanet entwickelte sich zum Internet und überschritt 1989 die Grenze von 100.000 Rechnern. Durch seine Verbreitung im Internet hat IPv4 schließlich auch LAN-Protokolle wie DECnet oder IPX verdrängt. NetWare, AppleTalk und NetBIOS wurden als neue Versionen hervorgebracht, die auf IP aufsetzen.

Am Anfang der 1990er Jahre war erkennbar, dass IP-Adressen bald knapp würden, da die damals übliche Netzklassen-basierte Adressvergabe erheblichen Verschnitt verursachte. Als kurzfristige Lösung wurde 1993 Classless Inter-Domain Routing eingeführt, das eine deutlich effizientere Adressvergabe ermöglichte. Eine weitere kurzfristige Lösung war das 1994 eingeführte Network Address Translation (NAT), das die Wiederverwendung von IP-Adressen ermöglichte.[2] In der Variante Network Address Port Translation (NAPT) ermöglichte es die gleichzeitige Mehrfachverwendung von IP-Adressen. Mit diesen Maßnahmen konnte der Adressbedarf soweit gedämpft werden, dass der Adressraum trotz immensen Wachstums des Internets erst in den 2010er Jahren knapp wurde (siehe Abschnitt Adressknappheit).

Als langfristige Lösung der Adressknappheit sollte ein neues Protokoll mit größerem Adressraum entwickelt werden. Dies führte zuerst zur Entwicklung des experimentellen Protokolls TP/IX, das die Versionsnummer 7 trug und 1993 veröffentlicht wurde.[3] TP/IX sollte dabei einen 64-Bit-Adressbereich unterstützen, wurde dann aber zugunsten von IPv6 verworfen. Die erste Fassung von IPv6 wurde 1995 veröffentlicht und verwendete einen 128-Bit-Adressraum.[4] Die Versionsnummer 5 wurde nicht für einen IPv4-Nachfolger verwendet, da sie bereits 1990 durch das experimentelle Internet Stream Protocol Version 2 (ST2) belegt war, einem für Streaming optimierten Protokoll.[5]

IPv4 benutzt 32-Bit-Adressen, wodurch ein Adressraum von knapp 4,3 Milliarden Adressen zur Verfügung steht. IPv4-Adressen werden meist in Dezimalpunktschreibweise dargestellt: vier Oktetts (je 8 Bit) werden durch Punkt getrennt mit vier Zahlen von 0 bis 255 dargestellt.

Beispiel: 192.0.2.155

Eine IPv4-Adresse kann in dezimal, binär, oktal und hexadezimal sowohl in der Punkt- als auch in der Nichtpunktnotation dargestellt werden. Eine führende Null zeigt eine Oktalzahl an. Daher dürfen in der Dezimalpunktschreibweise ein- und zweistellige Zahlen nicht auf ein gleichförmiges Längenformat gebracht werden (also nicht: 192.000.002.155).

Jedes der vier Oktette besteht aus 8 Bit und stellt somit 2⁸ = 256 verschiedene Werte dar. Daraus ergibt sich eine Gesamtzahl von 256 × 256 × 256 × 256 = 256⁴ = 2³² = 4.294.967.296 IPv4-Adressen.

Ein IP-Paket besteht aus einem Header und den eigentlichen Nutzdaten. Der IPv4-Header ist normalerweise 20 Bytes lang, kann aber durch zusätzliche Optionen in jeweils 4-Byte-Schritten auf bis zu 60 Bytes verlängert werden. Die Optionen sind größtenteils ungenutzt und IPv4-Pakete mit Optionen werden oft blockiert.[19]

IPv4 dient als Grundlage, um darüber andere Protokolle zu transportieren. In dem Datenteil eines IP-Pakets werden der Header, die Nutzdaten und ein eventueller Trailer eines anderen Netzwerkprotokolls gekapselt. Typische Beispiele sind TCP, UDP oder ICMP. Um welches Protokoll es sich handelt, wird durch eine Nummer im Protokoll-Feld des IP-Headers festgelegt. Die Internet Assigned Numbers Authority verwaltet eine Liste der registrierten Protokollnummern.[20]

Die maximale Länge eines IP-Pakets beträgt 65535 Bytes (2¹⁶−1) und die maximale Datenlänge 65515 Bytes (Paketlänge – minimale Headerlänge von 20 Byte). Die Paketlänge wird jedoch normalerweise von dem zugrundeliegenden Netzwerkprotokoll auf Netzzugangsschicht weiter eingeschränkt, woraus sich eine für das Netz spezifische maximale IP-Paketlänge ergibt, die Maximum Transmission Unit (MTU) genannt wird. Bei Ethernet beispielsweise beträgt die MTU 1500 Bytes. Die MTU reduziert sich, wenn ein IP-Paket über einen Tunnel oder ein Virtual Private Network transportiert wird. Die minimale Frame-Länge von Ethernet hat hingegen keine Auswirkung auf IPv4, da durch das Längenfeld im IPv4-Header ein beliebig kurzes IPv4-Paket transportiert werden kann, selbst wenn der Ethernet-Frame mit Nullbytes aufgefüllt werden muss.

Eine spezielle Bedeutung kommt in modernen Implementierungen dem früheren Feld Type of Service (ToS) im zweiten Oktett des IPv4-Headers zu. Ursprünglich diente dieses Feld bei der Vermittlung eines Datenpaketes als Entscheidungshilfe für die beteiligten Router bei der Wahl der Übertragungsparameter. In modernen Implementierungen wird dieses Feld im Zusammenhang mit der network congestion avoidance (Vermeidung von Überlastungen) verwendet. Das ToS-Feld wurde durch das DS-Feld (differentiated services) ersetzt, dessen erste sechs Bits als differentiated services code point (DSCP) und dessen letzte beiden Bits als explicit congestion notification (ECN) benutzt werden.

IPv4 unterscheidet nicht zwischen Endgeräten (Hosts) und Vermittlungsgeräten (Router). Jeder Computer und jedes Gerät kann gleichzeitig Endpunkt und Router sein. Ein Router verbindet dabei verschiedene Netze. Die Gesamtheit aller über Router verbundenen Netze bildet das Internet (siehe auch Internetworking).

IPv4 ist für LANs und WANs gleichermaßen geeignet. Ein Paket kann verschiedene Netze vom Sender zum Empfänger durchlaufen, die Netze sind durch Router verbunden. Anhand von Routingtabellen, die jeder Router individuell pflegt, wird der Netzteil einem Zielnetz zugeordnet. Die Einträge in die Routingtabelle können dabei statisch oder über Routingprotokolle dynamisch erfolgen. Die Routingprotokolle dürfen dabei sogar auf IP aufsetzen.

Bei Überlastung eines Netzwerks oder einem anderen Fehler darf ein Router Pakete auch verwerfen. Pakete desselben Senders können bei Ausfall eines Netzes auch alternativ „geroutet“ werden. Jedes Paket wird dabei einzeln „geroutet“, was zu einer erhöhten Ausfallsicherheit führt.

Beim Routing über IP können daher

• einzelne Pakete verlorengehen,
• Pakete doppelt beim Empfänger ankommen,
• Pakete verschiedene Wege nehmen,
• Pakete fragmentiert beim Empfänger ankommen.

Wird TCP auf IP aufgesetzt (d. h. die Daten jedes IP-Pakets enthalten ein TCP-Paket, aufgeteilt in TCP-Header und Daten), so wird neben dem Aufheben der Längenbeschränkung auch der Paketverlust durch Wiederholung korrigiert. Doppelte Pakete werden erkannt und verworfen. Die Kombination TCP mit IP stellt dabei eine zuverlässige bidirektionale Verbindung eines Datenstroms dar.

Auf dem Weg vom Sender zum Empfänger kann es vorkommen, dass ein IP-Paket ein Netz durchlaufen muss, bei dem das Paket länger ist als die vom Netz maximal unterstützte Paketlänge (MTU). In einem solchen Fall kann der Router entweder eine Fehlermeldung zurücksenden (siehe Abschnitt #ICMP) oder das Paket in Fragmente aufteilen und in separaten IP-Paketen weiter versenden. Jedes der Fragmente trägt dieselbe Identifikationsnummer im Header, mit denen der Empfänger eine Zusammensetzung vornehmen kann. Die Fragmentierung erfolgt in folgenden Schritten:

• Aufteilen der Nutzdaten an einer 8-Byte-Grenze (das letzte Fragment enthält dann nicht unbedingt ein Vielfaches von 8 Byte Daten).
• Kopieren der IP-Headerdaten des Originalpakets in die neuen Header der Fragmente.
• Setzen des Felds „More Fragments“ auf den Wert 1 bei allen bis auf das letzte Fragment.
• Beim letzten Fragment wird der Wert von „More Fragments“ aus dem Originalpaket kopiert. Im Regelfall ist der Wert 0, kann aber auch 1 sein, falls das Originalpaket bereits ein Fragment ist.
• Setzen der Längen-Felder und des Fragment-Offsets in den Headern. Das Fragment-Offset gibt die Position eines Datenfragments im Originalpaket an (als Vielfaches von 8 Bytes).

Um ein Paket wieder zusammenzusetzen, kombiniert der Empfänger alle Fragmente, welche die gleiche Identifikationsnummer, den gleichen Absender, Empfänger und das gleiche Protokoll haben. Die Reihenfolge der Fragmente ergibt sich aus dem jeweiligen Fragment-Offset im Header. Das letzte Fragment erkennt der Empfänger daran, dass das Feld „More Fragments“ auf 0 gesetzt ist.

IP ist eng verknüpft mit dem Internet Control Message Protocol (ICMP), das zur Fehlersuche und Steuerung eingesetzt wird. ICMP setzt auf IP auf, das heißt ein ICMP-Paket wird im Datenteil eines IP-Pakets abgelegt. Eine IP-Implementierung enthält stets auch eine ICMP-Implementierung. ICMP besteht aus verschiedenen Pakettypen, die unterschiedlichen Funktionen dienen. Ein prominentes Beispiel sind „Echo Request“ und „Echo Reply“, was für das Diagnosewerkzeug Ping verwendet wird. Auch Traceroute verwendet ICMP.

ICMP kann zusammen mit dem Don’t-Fragment-Bit des IP-Pakets auch eingesetzt werden, um die maximale Paketgröße eines Übertragungsweges zu einer Zieladresse zu ermitteln. Dies wird als Path MTU Discovery bezeichnet und ermittelt die kleinste MTU aller passierten Netze. Dadurch kann auf IP-Fragmentierung verzichtet werden, wenn der Sender nur Pakete mit der maximalen Größe der PMTU erzeugt.

IPv4 kann auf verschiedene Übertragungsmedien und Protokolle in der Netzzugangsschicht aufsetzen, zum Beispiel das Point-to-Point Protocol oder Serial Line Internet Protocol. In lokalen Netzen wird überwiegend Ethernet oder WLAN eingesetzt. Beide verwenden eine 48 Bit lange MAC-Adresse zur Adressierung von Netzwerkkarten. Ein Sender muss die MAC-Adresse des Ziels kennen, bevor ein IP-Paket gesendet werden kann. Um für eine gegebene IP-Adresse des Ziels die zugehörige MAC-Adresse zu ermitteln, wird das Address Resolution Protocol (ARP) verwendet. Unbekannte MAC-Adressen fragt der Sender mittels einer ARP-Anfrage an, die er als Broadcast an alle Netzwerkgeräte im lokalen Netz sendet. Das Ziel sendet daraufhin eine ARP-Antwort zurück, die die gesuchte MAC-Adresse enthält. Die Kommunikationsteilnehmer speichern die gelernten Zuordnungen von IP-Adresse zu MAC-Adresse in einem Cache zwischen.

Anzahl verfügbarer IPv4-Adressblöcke zwischen 1995 und 2015

Aufgrund des unvorhergesehenen Wachstums des Internets herrscht heute Adressknappheit. Im Januar 2011 teilte die IANA der asiatisch-pazifischen Regional Internet Registry APNIC die letzten zwei /8-Adressblöcke nach der regulären Vergabepraxis zu.[21] Gemäß einer Vereinbarung aus dem Jahr 2009[22] wurde am 3. Februar 2011 schließlich der verbliebene Adressraum gleichmäßig auf die regionalen Adressvergabestellen verteilt: jeweils ein /8-Adressblock pro Vergabestelle.[23][24] Seitdem hat die IANA auf der globalen Ebene keine weiteren /8-Adressblöcke mehr zu vergeben.

Auf der regionalen Ebene verschärften die Regional Internet Registrys ihre Vergabepraktiken, um aus dem letzten /8-Adressblock möglichst lange schöpfen zu können. Bei der APNIC traten diese am 15. April 2011 in Kraft, da die zuvor erhaltenen beiden /8-Adressblöcke bereits nach drei Monaten aufgebraucht waren.[25] Am 14. September 2012 folgte dann RIPE NCC mit der letzten regulären Zuteilung in der Region Europa/Naher Osten.[26] Mit der neuen Vergabepraxis hatten APNIC- und RIPE-NCC-Mitglieder jeweils nur noch Anspruch auf Zuteilung eines /22-Adressbereichs, selbst wenn sie einen größeren Bedarf nachweisen konnten.[27][28]

Am 25. November 2019 hat RIPE NCC ihren /8-Adressblock endgültig aufgebraucht. Seitdem werden nur noch /24-Kleinstblöcke per Warteliste aus Rückläufern vergeben.[29]

Die historische Entwicklung des Internets wirft ein weiteres Problem auf: Durch die mit der Zeit mehrmals geänderte Vergabepraxis von Adressen des IPv4-Adressraums ist dieser inzwischen stark fragmentiert, d. h., häufig gehören mehrere nicht zusammenhängende Adressbereiche zur gleichen organisatorischen Instanz. Dies führt in Verbindung mit der heutigen Routingstrategie (Classless Inter-Domain Routing) zu langen Routingtabellen, auf welche Speicher und Prozessoren der Router im Kernbereich des Internets ausgelegt werden müssen. Zudem erfordert IPv4 von Routern, Prüfsummen jedes weitergeleiteten Pakets neu zu berechnen, was eine weitere Prozessorbelastung darstellt.

Weil die IPv4-Adressen auszugehen drohten, wurde IPv6 als 128-Bit-Adressen entwickelt. Diese werden in acht hexadezimale 4er-Gruppen dargestellt und die Gruppen durch Doppelpunkte getrennt. Damit können 2¹²⁸ = 65.536⁸ ≈ 340 Sextillionen IPv6-Adressen vergeben werden, eine extrem hohe Zahl. Zusätzlich wurde die Systematik der Adress-Struktur wesentlich verbessert. Verfügbar sind die Adressen seit 2017.

IPv6-Beispiel: 2001:0db8:85a3:08d3:1319:8a2e:0370:7344

• IPTV
• IP-Telefonie
• Mobile IP

• A. Badach, E. Hoffmann: Technik der IP-Netze. Hanser, München 2007, ISBN 978-3-446-41089-3.
• D. Larisch: TCP/IP – Grundlagen und Praxis. Heise Medien, Hamburg 2011, ISBN 978-3-936931-69-3.
• J.D. Wegner, R. Rockwell: IP Addressing & Subnetting. Syngress, Rockland MA 2000, ISBN 3-8266-4077-2.

• RFC 791 – Internet Protocol. 1981 (englisch).
• L. Parziale et al.: TCP/IP Tutorial and Technical Overview. (PDF; 8,1 MB). In: IBM Redbooks, Armonk NY 2006 (englisch)
• Subnetz-Rechner im Kapitel TCP/IP – Grundlagen Computernetze
• IANA IP Version Numbers – IANA assignment of version-numbers

1. RFC 791 – Internet Protocol. 1981 (englisch).
2. K. Egevang, P. Francis: RFC 1631 – The IP Network Address Translator (NAT). Mai 1994 (englisch).
3. R. Ullmann: RFC 1475 – TP/IX: The Next Internet. Juni 1993 (englisch).
4. S. Deering, R. Hinden: RFC 1883 – Internet Protocol, Version 6 (IPv6). Dezember 1995 (englisch).
5. C. Topolcic: RFC 1190 – Experimental Internet Stream Protocol, Version 2 (ST-II). Oktober 1990 (englisch).
6. RFC 923 – Assigned numbers. Oktober 1984 (englisch).
7. RFC 1878 – Variable Length Subnet Table For IPv4. Dezember 1995 (englisch).
8. RFC 6890 – Special-Purpose IP Address Registries. April 2013 (englisch).
9. RFC 1122 – Requirements for Internet Hosts – Communication Layers. Oktober 1989 (englisch).
10. RFC 1918 – Address Allocation for Private Internets. Februar 1996 (englisch).
11. RFC 6598 – IANA-Reserved IPv4 Prefix for Shared Address Space. April 2012 (englisch).
12. RFC 3927 – Dynamic Configuration of IPv4 Link-Local Addresses. Mai 2005 (englisch).
13. RFC 7526 – Deprecating the Anycast Prefix for 6to4 Relay Routers. Mai 2015 (englisch).
14. RFC 2544 – Benchmarking Methodology for Network Interconnect Devices. März 1999 (englisch).
15. RFC 5771 – IANA Guidelines for IPv4 Multicast Address Assignments. (englisch).
16. RFC 1700 – Assigned Numbers. Oktober 1994 (englisch).
17. RFC 919 – Broadcasting Internet Datagrams. Oktober 1984 (englisch).
18. RFC 922 – Broadcasting Internet Datagrams in the Presence of Subnets. Oktober 1984 (englisch).
19. RFC 7126 – Recommendations on Filtering of IPv4 Packets Containing IPv4 Options. Februar 2014 (englisch).
20. Protocol Numbers. IANA, Juni 2023, abgerufen am 7. September 2023.
21. Two /8s allocated to APNIC from IANA. (Memento vom 17. August 2011 auf WebCite) APNIC, 1. Februar 2011.
22. Global Policy for the Allocation of the Remaining IPv4 Address Space. ICANN.
23. Alle Internetadressen weltweit sind aufgebraucht. Welt Online, 3. Februar 2011.
24. RIPE NCC Receives Final /8 of IPv4 Address Space from IANA. ripe.net (englisch).
25. APNIC IPv4 Address Pool Reaches Final /8. (Memento vom 17. August 2011 auf WebCite) APNIC
26. ripe.net
27. Policies for IPv4 address space management in the Asia Pacific region. (Memento vom 18. November 2011 im Internet Archive) APNIC, Abschnitt 3
28. ripe.net, Abschnitt 5.6
29. The RIPE NCC has run out of IPv4 Addresses. 25. November 2019, abgerufen am 26. November 2019 (englisch).