IPv4

Internet-Protokoll Version 4 ⓘ

Protokollstapel
IPv4-Paket
Zweck	Internetworking-Protokoll
Entwickler(n)	DARPA
Einführung	1981; vor 42 Jahren
Beeinflusst	IPv6
RFC(s)	791

Internet Protocol Version 4 (IPv4) ist die vierte Version des Internet Protocol (IP). Es ist eines der Kernprotokolle der standardbasierten Internetworking-Methoden im Internet und anderen paketvermittelten Netzen. IPv4 war die erste Version, die 1982 im SATNET und im Januar 1983 im ARPANET in Betrieb genommen wurde. Es wird auch heute noch für den größten Teil des Internet-Verkehrs verwendet, auch wenn das Nachfolgeprotokoll Internet Protocol Version 6 (IPv6) gerade eingeführt wird. ⓘ

IPv4 verwendet einen 32-Bit-Adressraum, der 4.294.967.296 (2³²) eindeutige Adressen bietet, aber große Blöcke sind für spezielle Netzwerkzwecke reserviert. ⓘ

IPv4 im TCP/IP-Protokollstapel: ⓘ

Anwendung	HTTP	IMAP	SMTP	DNS	…
Transport	TCP			UDP
Internet	IPv4
Netzzugang	Ethernet	Token Bus	Token Ring	FDDI	…

Geschichte

Internet Protocol Version 4 wird in der IETF-Veröffentlichung RFC 791 (September 1981) beschrieben und ersetzt eine frühere Definition vom Januar 1980 (RFC 760). Im März 1982 beschloss das US-Verteidigungsministerium, die Internet Protocol Suite (TCP/IP) als Standard für alle militärischen Computernetzwerke zu verwenden. ⓘ

Zweck

Das Internet-Protokoll ist das Protokoll, das Internetworking auf der Internet-Schicht der Internet Protocol Suite definiert und ermöglicht. Im Wesentlichen bildet es das Internet. Es verwendet ein logisches Adressierungssystem und führt ein Routing durch, d. h. die Weiterleitung von Paketen von einem Quellhost zum nächsten Router, der einen Schritt näher am beabsichtigten Zielhost in einem anderen Netz liegt. ⓘ

IPv4 ist ein verbindungsloses Protokoll und arbeitet nach dem Best-Effort-Zustellungsmodell, d. h. es garantiert weder die Zustellung noch die richtige Reihenfolge oder die Vermeidung von Doppelzustellungen. Diese Aspekte, einschließlich der Datenintegrität, werden von einem Transportprotokoll der oberen Schicht, wie dem Transmission Control Protocol (TCP), behandelt. ⓘ

Adressierung

Zerlegung der vierfach gepunkteten IPv4-Adressdarstellung in ihren Binärwert ⓘ

IPv4 verwendet 32-Bit-Adressen, wodurch der Adressraum auf 4294967296 (2³²) Adressen begrenzt ist. ⓘ

IPv4 reserviert spezielle Adressblöcke für private Netze (~18 Millionen Adressen) und Multicast-Adressen (~270 Millionen Adressen). ⓘ

Darstellung der Adressen

IPv4-Adressen können in jeder Notation dargestellt werden, die einen 32-Bit-Ganzzahlwert ausdrückt. Am häufigsten werden sie in Punkt-Dezimal-Notation geschrieben, die aus vier Oktetten der Adresse besteht, die einzeln in Dezimalzahlen ausgedrückt und durch Punkte getrennt werden. ⓘ

Die IP-Adresse 192.0.2.235 mit vier Punkten steht beispielsweise für die 32-Bit-Dezimalzahl 3221226219, die im Hexadezimalformat 0xC00002EB ist. ⓘ

Die CIDR-Notation kombiniert die Adresse mit ihrem Routing-Präfix in einem kompakten Format, in dem auf die Adresse ein Schrägstrich (/) und die Anzahl der führenden aufeinanderfolgenden 1-Bits im Routing-Präfix (Subnetzmaske) folgt. ⓘ

Andere Adressdarstellungen waren üblich, als die klassenorientierte Vernetzung praktiziert wurde. So wird beispielsweise die Loopback-Adresse 127.0.0.1 üblicherweise als 127.1 geschrieben, da sie zu einem Klasse-A-Netz mit acht Bits für die Netzwerkmaske und 24 Bits für die Hostnummer gehört. Wenn weniger als vier Ziffern in der Adresse in punktierter Notation angegeben sind, wird der letzte Wert als Ganzzahl mit so vielen Bytes behandelt, wie zum Auffüllen der Adresse auf vier Oktette erforderlich sind. So entspricht die Adresse 127.65530 der Adresse 127.0.255.250. ⓘ

Zuweisung

Beim ursprünglichen Entwurf von IPv4 war eine IP-Adresse in zwei Teile unterteilt: Die Netzwerkkennung war das höchstwertige Oktett der Adresse, die Hostkennung der Rest der Adresse. Letzterer wurde auch als Restfeld bezeichnet. Diese Struktur erlaubte maximal 256 Netzkennungen, was sich schnell als unzureichend erwies. ⓘ

Um diese Begrenzung zu überwinden, wurde 1981 das signifikanteste Adressoktett neu definiert, um Netzwerkklassen zu schaffen, in einem System, das später als Classful Networking bekannt wurde. In dem überarbeiteten System wurden fünf Klassen definiert. Die Klassen A, B und C hatten unterschiedliche Bitlängen für die Netzwerkidentifikation. Der Rest der Adresse wurde wie zuvor zur Identifizierung eines Hosts innerhalb eines Netzwerks verwendet. Aufgrund der unterschiedlichen Größe der Felder in den verschiedenen Klassen hatte jede Netzwerkklasse eine andere Kapazität für die Adressierung von Hosts. Zusätzlich zu den drei Klassen für die Adressierung von Hosts wurde die Klasse D für die Multicast-Adressierung definiert und die Klasse E war für zukünftige Anwendungen reserviert. ⓘ

Die Unterteilung bestehender klassifizierter Netze in Subnetze begann 1985 mit der Veröffentlichung von RFC 950. Diese Unterteilung wurde mit der Einführung von Subnetzmasken variabler Länge (VLSM) in RFC 1109 im Jahr 1987 flexibler gestaltet. Auf der Grundlage dieser Arbeit wurde 1993 mit RFC 1517 das Classless Inter-Domain Routing (CIDR) eingeführt, bei dem die Anzahl der Bits (vom höchstwertigen ausgehend) z. B. als /24 ausgedrückt wurde und das klassenbasierte Schema im Gegensatz dazu als classful bezeichnet wurde. CIDR wurde entwickelt, um eine Neuaufteilung eines beliebigen Adressraums zu ermöglichen, so dass den Benutzern kleinere oder größere Adressblöcke zugewiesen werden können. Die durch CIDR geschaffene hierarchische Struktur wird von der Internet Assigned Numbers Authority (IANA) und den regionalen Internet-Registern (RIRs) verwaltet. Jedes RIR unterhält eine öffentlich durchsuchbare WHOIS-Datenbank, die Informationen über die Zuweisung von IP-Adressen enthält. ⓘ

Adressen zur besonderen Verwendung

Die Internet Engineering Task Force (IETF) und die IANA haben verschiedene reservierte IP-Adressen für besondere Zwecke von der allgemeinen Nutzung ausgeschlossen. Diese Adressen werden vor allem für den Multicast-Verkehr und zur Bereitstellung von Adressierungsraum für die uneingeschränkte Nutzung in privaten Netzen verwendet.

Spezielle Adressblöcke

Adressblock	Adressbereich	Anzahl der Adressen	Umfang	Beschreibung
0.0.0.0/8	0.0.0.0–0.255.255.255	16777216	Software	Aktuelles Netzwerk
10.0.0.0/8	10.0.0.0–10.255.255.255	16777216	Privates Netzwerk	Wird für die lokale Kommunikation innerhalb eines privaten Netzwerks verwendet.
100.64.0.0/10	100.64.0.0–100.127.255.255	4194304	Privates Netzwerk	Gemeinsamer Adressraum für die Kommunikation zwischen einem Dienstanbieter und seinen Abonnenten bei Verwendung eines Carrier-Grade-NAT.
127.0.0.0/8	127.0.0.0–127.255.255.255	16777216	Host	Wird für Loopback-Adressen zum lokalen Host verwendet.
169.254.0.0/16	169.254.0.0–169.254.255.255	65536	Subnetz	Wird für link-local-Adressen zwischen zwei Hosts auf einem einzelnen Link verwendet, wenn keine IP-Adresse angegeben ist, wie sie normalerweise von einem DHCP-Server abgerufen wird.
172.16.0.0/12	172.16.0.0–172.31.255.255	1048576	Privates Netzwerk	Wird für die lokale Kommunikation innerhalb eines privaten Netzwerks verwendet.
192.0.0.0/24	192.0.0.0–192.0.0.255	256	Privates Netzwerk	IETF-Protokoll-Zuweisungen.
192.0.2.0/24	192.0.2.0–192.0.2.255	256	Dokumentation	Zugewiesen als TEST-NET-1, Dokumentation und Beispiele.
192.88.99.0/24	192.88.99.0–192.88.99.255	256	Internet	Reserviert. Wurde früher für IPv6-zu-IPv4-Relay verwendet (enthielt den IPv6-Adressblock 2002::/16).
192.168.0.0/16	192.168.0.0–192.168.255.255	65536	Privates Netzwerk	Wird für die lokale Kommunikation innerhalb eines privaten Netzwerks verwendet.
198.18.0.0/15	198.18.0.0–198.19.255.255	131072	Privates Netzwerk	Wird für Benchmark-Tests der netzübergreifenden Kommunikation zwischen zwei separaten Subnetzen verwendet.
198.51.100.0/24	198.51.100.0–198.51.100.255	256	Dokumentation	Zugewiesen als TEST-NET-2, Dokumentation und Beispiele.
203.0.113.0/24	203.0.113.0–203.0.113.255	256	Dokumentation	Zugewiesen als TEST-NET-3, Dokumentation und Beispiele.
224.0.0.0/4	224.0.0.0–239.255.255.255	268435456	Internet	In Verwendung für IP-Multicast. (Ehemaliges Klasse-D-Netz.)
233.252.0.0/24	233.252.0.0-233.252.0.255	256	Dokumentation	Zugewiesen als MCAST-TEST-NET, Dokumentation und Beispiele.
240.0.0.0/4	240.0.0.0–255.255.255.254	268435455	Internet	Reserviert für zukünftige Nutzung. (Ehemaliges Klasse-E-Netz.)
255.255.255.255/32	255.255.255.255	1	Subnetz	Reserviert für die "Limited Broadcast"-Zieladresse.

ⓘ

Private Netze

Von den etwa vier Milliarden Adressen, die in IPv4 definiert sind, sind etwa 18 Millionen Adressen in drei Bereichen für die Verwendung in privaten Netzen reserviert. Pakete, die in diesen Bereichen liegen, können im öffentlichen Internet nicht geroutet werden; sie werden von allen öffentlichen Routern ignoriert. Daher können private Hosts nicht direkt mit öffentlichen Netzen kommunizieren, sondern benötigen zu diesem Zweck eine Netzwerkadressübersetzung an einem Routing-Gateway. ⓘ

Name!!CIDR-Block!!Adressbereich!!Anzahl der Adressen!!Klassenbezogene Beschreibung

Reservierte private IPv4-Netzbereiche

24-Bit-Block	10.0.0.0/8	10.0.0.0 - 10.255.255.255	16777216	Einzelne Klasse A.
20-bit Block	172.16.0.0/12	172.16.0.0 - 172.31.255.255	1048576	Zusammenhängender Bereich von 16 Blöcken der Klasse B.
16-bit Block	192.168.0.0/16	192.168.0.0 - 192.168.255.255	65536	Zusammenhängender Bereich von 256 Blöcken der Klasse C.

ⓘ

Da zwei private Netze, z. B. zwei Zweigstellen, nicht direkt über das öffentliche Internet zusammenarbeiten können, müssen die beiden Netze über ein virtuelles privates Netz (VPN) oder einen IP-Tunnel über das Internet überbrückt werden, bei dem die Pakete einschließlich ihrer Kopfzeilen, die die privaten Adressen enthalten, während der Übertragung über das öffentliche Netz in eine Protokollschicht eingekapselt werden. Zusätzlich können die gekapselten Pakete für die Übertragung über öffentliche Netze verschlüsselt werden, um die Daten zu sichern. ⓘ

Link-lokale Adressierung

RFC 3927 definiert den speziellen Adressblock 169.254.0.0/16 für die link-lokale Adressierung. Diese Adressen sind nur auf der Verbindung (z. B. einem lokalen Netzwerksegment oder einer Punkt-zu-Punkt-Verbindung) gültig, die direkt mit einem Host verbunden ist, der sie verwendet. Diese Adressen sind nicht routingfähig. Wie private Adressen können auch diese Adressen nicht Quelle oder Ziel von Paketen sein, die das Internet durchqueren. Diese Adressen werden hauptsächlich für die automatische Adresskonfiguration (Zeroconf) verwendet, wenn ein Host keine IP-Adresse von einem DHCP-Server oder anderen internen Konfigurationsmethoden erhalten kann. ⓘ

Als der Adressblock reserviert wurde, gab es keine Standards für die automatische Adressenkonfiguration. Microsoft schuf eine Implementierung mit der Bezeichnung Automatic Private IP Addressing (APIPA), die auf Millionen von Rechnern eingesetzt wurde und sich als De-facto-Standard durchsetzte. Viele Jahre später, im Mai 2005, definierte die IETF in RFC 3927 mit dem Titel Dynamic Configuration of IPv4 Link-Local Addresses einen formalen Standard. ⓘ

Einige Netzwerke sind für spezielle Zwecke reserviert. Siehe RFC 6890:

Adressblock (Präfix)	Verwendung	Referenz ⓘ
0.0.0.0/8	Das vorliegende Netzwerk	RFC 1122
10.0.0.0/8	1 privates 8-Bit-Netzwerk	RFC 1918
100.64.0.0/10	Shared Transition Space	RFC 6598
127.0.0.0/8	Loopback (Lokaler Computer)	RFC 1122
169.254.0.0/16	Privates Netzwerk (link local), APIPA	RFC 3927
172.16.0.0/12	16 private 16-Bit-Netzwerke	RFC 1918
192.0.0.0/24	IETF Protocol Assignments	RFC 6890
192.0.2.0/24	Test-Netzwerke	RFC 6890
192.88.99.0/24	IPv6 zu IPv4 Relay (Veraltet)	RFC 7526
192.168.0.0/16	256 private 24-Bit-Netzwerke	RFC 1918
198.18.0.0/15	Netzwerk-Benchmark-Tests	RFC 2544
198.51.100.0/24	Test-Netzwerke	RFC 6890
203.0.113.0/24	Test-Netzwerke	RFC 6890
224.0.0.0/4	Multicasts	RFC 5771
240.0.0.0/4	Reserviert	RFC 1700
255.255.255.255/32	Limited Broadcast	RFC 919, RFC 922

Routing

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 Netzwerke. Die Gesamtheit aller über Router verbundenen Netzwerke bildet das Internet (siehe auch Internetworking). ⓘ

IPv4 ist für LANs und WANs gleichermaßen geeignet. Ein Paket kann verschiedene Netzwerke vom Sender zum Empfänger durchlaufen, die Netzwerke sind durch Router verbunden. Anhand von Routingtabellen, die jeder Router individuell pflegt, wird der Netzwerkteil einem Zielnetzwerk 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 Netzwerks 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. ⓘ

Das Klasse-A-Netzwerk 127.0.0.0 (klassenloses Netzwerk 127.0.0.0/8) ist für Loopback reserviert. IP-Pakete, deren Quelladressen zu diesem Netz gehören, sollten niemals außerhalb eines Hosts erscheinen. Pakete, die auf einer Nicht-Loopback-Schnittstelle mit einer Loopback-Quell- oder Zieladresse empfangen werden, müssen verworfen werden. ⓘ

Erste und letzte Subnetzadresse

Die erste Adresse in einem Subnetz wird zur Identifizierung des Subnetzes selbst verwendet. Bei dieser Adresse sind alle Hostbits 0. Um Mehrdeutigkeiten in der Darstellung zu vermeiden, ist diese Adresse reserviert. Bei der letzten Adresse sind alle Host-Bits auf 1 gesetzt. Sie wird als lokale Broadcast-Adresse verwendet, um Nachrichten an alle Geräte im Subnetz gleichzeitig zu senden. Bei Netzen der Größe /24 oder größer endet die Broadcast-Adresse immer auf 255. ⓘ

Im Subnetz 192.168.5.0/24 (Subnetzmaske 255.255.255.0) wird beispielsweise die Kennung 192.168.5.0 verwendet, um das gesamte Subnetz zu bezeichnen. Die Broadcast-Adresse des Netzes ist 192.168.5.255. ⓘ

	Binäre Form	Punkt-Dezimale Schreibweise ⓘ
Netzwerkbereich	11000000.10101000.00000101.00000000	192.168.5.0
Broadcast-Adresse	11000000.10101000.00000101.11111111	192.168.5.255
In Rot ist der Host-Teil der IP-Adresse dargestellt; der andere Teil ist das Netzwerk-Präfix. Der Host wird invertiert (logisches NICHT), aber das Netzwerk-Präfix bleibt erhalten.

Dies bedeutet jedoch nicht, dass jede Adresse, die auf 0 oder 255 endet, nicht als Host-Adresse verwendet werden kann. Im /16-Subnetz 192.168.0.0/255.255.0.0, das dem Adressbereich 192.168.0.0-192.168.255.255 entspricht, lautet die Broadcast-Adresse beispielsweise 192.168.255.255. Man kann folgende Adressen für Hosts verwenden, auch wenn sie mit 255 enden: 192.168.1.255, 192.168.2.255 usw. Außerdem ist 192.168.0.0 die Netzwerkkennung und darf nicht einer Schnittstelle zugewiesen werden. Die Adressen 192.168.1.0, 192.168.2.0 usw. dürfen zugewiesen werden, obwohl sie mit 0 enden. ⓘ

In der Vergangenheit kam es zu Konflikten zwischen Netzwerkadressen und Broadcast-Adressen, weil manche Software nicht standardisierte Broadcast-Adressen mit Nullen anstelle von Einsen verwendete. ⓘ

In Netzwerken, die kleiner als /24 sind, enden Broadcast-Adressen nicht unbedingt mit 255. Ein CIDR-Subnetz 203.0.113.16/28 hat zum Beispiel die Broadcast-Adresse 203.0.113.31. ⓘ

	Binäre Form	Punkt-Dezimale Schreibweise ⓘ
Netzwerkbereich	11001011.00000000.01110001.00010000	203.0.113.16
Broadcast-Adresse	11001011.00000000.01110001.00011111	203.0.113.31
In Rot ist der Host-Teil der IP-Adresse dargestellt; der andere Teil ist das Netzwerk-Präfix. Der Host wird invertiert (logisches NICHT), aber das Netzwerk-Präfix bleibt erhalten.

Ein Sonderfall ist ein /31-Netz, das nur Platz für zwei Hosts bietet. Diese Netze werden normalerweise für Punkt-zu-Punkt-Verbindungen verwendet. Für diese Netze gibt es weder eine Netzwerkkennung noch eine Broadcast-Adresse. ⓘ

Adressauflösung

Hosts im Internet sind in der Regel durch Namen bekannt, z. B. www.example.com, und nicht in erster Linie durch ihre IP-Adresse, die für das Routing und die Identifizierung von Netzwerkschnittstellen verwendet wird. Die Verwendung von Domänennamen erfordert eine Übersetzung, die so genannte Auflösung, dieser Namen in Adressen und umgekehrt. Dies ist vergleichbar mit dem Nachschlagen einer Telefonnummer in einem Telefonbuch anhand des Namens des Empfängers. ⓘ

Die Übersetzung zwischen Adressen und Domänennamen erfolgt durch das Domain Name System (DNS), ein hierarchisches, verteiltes Namenssystem, das die Unterdelegation von Namensräumen an andere DNS-Server ermöglicht. ⓘ

Unnumerierte Schnittstelle

Eine nicht nummerierte Punkt-zu-Punkt-Verbindung (PtP), auch Transitverbindung genannt, ist eine Verbindung, der keine IP-Netzwerk- oder Subnetznummer zugeordnet ist, die aber dennoch eine IP-Adresse hat. Phil Karn von Qualcomm wurde 1993 erstmals vorgestellt und gilt als der ursprüngliche Entwickler. ⓘ

Der Zweck eines Transit-Links ist die Weiterleitung von Datagrammen. Sie werden verwendet, um IP-Adressen aus einem knappen IP-Adressraum freizugeben oder um die Verwaltung der IP-Zuweisung und die Konfiguration der Schnittstellen zu reduzieren. Früher brauchte jeder Link ein eigenes /30- oder /31-Subnetz mit 2-4 IP-Adressen pro Punkt-zu-Punkt-Link. Wenn eine Verbindung nicht nummeriert ist, wird eine Router-ID verwendet, eine einzelne IP-Adresse, die von einer definierten Schnittstelle (normalerweise eine Loopback-Schnittstelle) entlehnt wird. Dieselbe Router-id kann auf mehreren Schnittstellen verwendet werden. ⓘ

Einer der Nachteile von nicht nummerierten Schnittstellen ist, dass es schwieriger ist, Ferntests und -verwaltung durchzuführen. ⓘ

Erschöpfung des Adressraums

In den 1980er Jahren wurde deutlich, dass sich der Bestand an verfügbaren IPv4-Adressen in einem Tempo erschöpfte, mit dem bei der ursprünglichen Planung des Netzes nicht gerechnet worden war. Zu den wichtigsten Marktkräften, die die Erschöpfung des Adressbestands beschleunigten, gehörte die rasch wachsende Zahl der Internetnutzer, die zunehmend mobile Computer wie Laptops, PDAs (Personal Digital Assistants) und Smartphones mit IP-Datendiensten verwendeten. Darüber hinaus basierte der Hochgeschwindigkeits-Internetzugang auf Geräten, die ständig eingeschaltet sind. Die drohende Erschöpfung motivierte die Einführung einer Reihe von Abhilfetechnologien, wie z. B.:

• Classless Inter-Domain Routing (CIDR), für kleinere ISP-Zuweisungen
• Unnumbered Interface, wodurch der Bedarf an Transitverbindungen entfällt.
• Netzwerkadressübersetzung, wodurch das Ende-zu-Ende-Prinzip überflüssig wurde.

Mitte der 1990er Jahre wurde die Netzwerkadressübersetzung (NAT) in den Systemen der Netzzugangsanbieter flächendeckend eingesetzt, zusammen mit strengen nutzungsbasierten Zuweisungsrichtlinien bei den regionalen und lokalen Internet-Registrierungsstellen. ⓘ

Der primäre Adresspool des Internets, der von der IANA verwaltet wird, war am 3. Februar 2011 erschöpft, als die letzten fünf Blöcke an die fünf RIRs vergeben wurden. APNIC war das erste RIR, das seinen regionalen Pool am 15. April 2011 erschöpfte, mit Ausnahme eines kleinen Teils des Adressraums, der für die Übergangstechnologien zu IPv6 reserviert ist und im Rahmen einer eingeschränkten Politik zugewiesen werden soll. ⓘ

Die langfristige Lösung für die Erschöpfung des Adressraums war die Spezifikation einer neuen Version des Internet-Protokolls, IPv6, im Jahr 1998. Es bietet einen erheblich größeren Adressraum, ermöglicht aber auch eine verbesserte Bündelung von Routen im gesamten Internet und bietet große Teilnetzzuweisungen von mindestens 2⁶⁴ Hostadressen für Endnutzer. Allerdings ist IPv4 nicht direkt mit IPv6 kompatibel, so dass Hosts, die nur IPv4 nutzen, nicht direkt mit Hosts kommunizieren können, die nur IPv6 nutzen. Mit dem Auslaufen des experimentellen 6bone-Netzes im Jahr 2004 begann im Jahr 2006 die endgültige Einführung von IPv6. Es wird erwartet, dass die Einführung von IPv6 noch einige Zeit in Anspruch nehmen wird, so dass Übergangstechnologien erforderlich sind, die es Hosts ermöglichen, mit beiden Versionen des Protokolls am Internet teilzunehmen. ⓘ

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. 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 Internet erst in den 2010er Jahren knapp wurde (siehe Abschnitt Adressknappheit). ⓘ

Aufbau der Pakete

Ein IP-Paket besteht aus einem Kopfteil und einem Datenteil. Ein IP-Paket hat keine Datenprüfsumme oder einen anderen Fußteil nach dem Datenteil. In der Regel kapselt die Verbindungsschicht IP-Pakete in Rahmen mit einem CRC-Footer, der die meisten Fehler erkennt; viele Protokolle der Transportschicht, die von IP übertragen werden, haben auch ihre eigene Fehlerprüfung. ⓘ

Kopfzeile

Der IPv4-Paketkopf besteht aus 14 Feldern, von denen 13 erforderlich sind. Das 14. Feld ist optional und trägt den treffenden Namen "Optionen". Die Felder im Header werden mit dem höchstwertigen Byte zuerst gepackt (Big Endian), und für das Diagramm und die Diskussion wird davon ausgegangen, dass die höchstwertigen Bits zuerst kommen (MSB 0 Bit-Nummerierung). Das höchstwertige Bit ist mit 0 nummeriert, so dass sich das Versionsfeld z. B. in den vier höchstwertigen Bits des ersten Bytes befindet. ⓘ

IPv4-Header-Format ⓘ

Offsets	Oktett	0								1								2								3
Oktett	Bit	0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31
0	0	Version				IHL				DSCP						ECN		Gesamtlänge
4	32	Kennzeichnung																Flaggen			Fragment-Offset
8	64	Lebendige Zeit								Protokoll								Header-Prüfsumme
12	96	Quell-IP-Adresse
16	128	Ziel-IP-Adresse
20	160	Optionen (wenn IHL > 5)
⋮	⋮
56	448

Version

Das erste Header-Feld in einem IP-Paket ist das Vier-Bit-Versionsfeld. Bei IPv4 ist es immer gleich 4.

Internet-Header-Länge (IHL)

Der IPv4-Header ist aufgrund des optionalen 14. Feldes (Optionen) in seiner Größe variabel. Das IHL-Feld enthält die Größe des IPv4-Headers; es hat 4 Bits, die die Anzahl der 32-Bit-Wörter im Header angeben. Der Mindestwert für dieses Feld ist 5, was einer Länge von 5 × 32 Bit = 160 Bit = 20 Byte entspricht. Als 4-Bit-Feld beträgt der Maximalwert 15; das bedeutet, dass die maximale Größe des IPv4-Headers 15 × 32 Bit = 480 Bit = 60 Byte beträgt.

Differentiated Services Code Point (DSCP)

Ursprünglich als Type of Service (ToS) definiert, spezifiziert dieses Feld differenzierte Dienste (DiffServ) gemäß RFC 2474. Das DSCP-Feld wird für das Echtzeit-Datenstreaming verwendet. Ein Beispiel ist Voice over IP (VoIP), das für interaktive Sprachdienste verwendet wird.

Explizite Überlastungsbenachrichtigung (ECN)

Dieses Feld ist in RFC 3168 definiert und ermöglicht eine Ende-zu-Ende-Benachrichtigung bei Netzüberlastung, ohne dass Pakete verworfen werden. ECN ist eine optionale Funktion, die verfügbar ist, wenn beide Endpunkte sie unterstützen, und die wirksam ist, wenn sie auch vom zugrunde liegenden Netz unterstützt wird.

Gesamtlänge

Dieses 16-Bit-Feld definiert die gesamte Paketgröße in Bytes, einschließlich Header und Daten. Die Mindestgröße beträgt 20 Byte (Header ohne Daten) und die Höchstgröße 65.535 Byte. Alle Hosts müssen in der Lage sein, Datagramme mit einer Größe von bis zu 576 Byte wieder zusammenzusetzen, aber die meisten modernen Hosts können viel größere Pakete verarbeiten. Verbindungen können weitere Beschränkungen für die Paketgröße auferlegen, in diesem Fall müssen die Datagramme fragmentiert werden. Die Fragmentierung wird bei IPv4 entweder im sendenden Host oder in Routern durchgeführt. Die Wiederzusammensetzung erfolgt auf dem empfangenden Host.

Kennzeichnung

Dieses Feld ist ein Identifikationsfeld und dient in erster Linie zur eindeutigen Identifizierung der Gruppe von Fragmenten eines einzelnen IP-Datagramms. In einigen experimentellen Arbeiten wurde vorgeschlagen, das ID-Feld für andere Zwecke zu verwenden, z. B. zum Hinzufügen von Paketverfolgungsinformationen, um die Verfolgung von Datagrammen mit gefälschten Quelladressen zu erleichtern, aber RFC 6864 verbietet jetzt jede derartige Verwendung.

Flaggen

Es folgt ein Drei-Bit-Feld, das zur Kontrolle oder Identifizierung von Fragmenten verwendet wird. Sie lauten (in der Reihenfolge vom höchsten zum niedrigsten Wert)

• Bit 0: Reserviert; muss Null sein.
• Bit 1: Nicht fragmentieren (DF)
• Bit 2: Weitere Fragmente (MF)

Wenn das DF-Flag gesetzt ist und eine Fragmentierung für die Weiterleitung des Pakets erforderlich ist, wird das Paket verworfen. Dies kann verwendet werden, wenn Pakete an einen Host gesendet werden, der nicht über die Ressourcen verfügt, um die Fragmente wieder zusammenzusetzen. Es kann auch zur Ermittlung der Pfad-MTU verwendet werden, entweder automatisch durch die IP-Software des Hosts oder manuell mit Diagnosewerkzeugen wie ping oder traceroute.

Bei nicht fragmentierten Paketen wird das MF-Flag gelöscht. Bei fragmentierten Paketen ist bei allen Fragmenten außer dem letzten das MF-Flag gesetzt. Das letzte Fragment hat ein Fragment-Offset-Feld ungleich Null, wodurch es sich von einem unfragmentierten Paket unterscheidet.

Fragment-Versatz

Dieses Feld gibt den Offset eines bestimmten Fragments relativ zum Anfang des ursprünglichen, nicht fragmentierten IP-Datagramms in Einheiten von 8-Byte-Blöcken an. Das erste Fragment hat einen Offset von Null. Das 13-Bit-Feld erlaubt einen maximalen Versatz von (2¹³ - 1) × 8 = 65.528 Byte, was unter Einbeziehung der Headerlänge (65.528 + 20 = 65.548 Byte) die Fragmentierung von Paketen unterstützt, die die maximale IP-Länge von 65.535 Byte überschreiten.

Lebenszeit (TTL)

Ein Acht-Bit-Time-to-Live-Feld begrenzt die Lebensdauer eines Datagramms, um einen Netzwerkausfall im Falle einer Routing-Schleife zu verhindern. Es wird in Sekunden angegeben, wobei Zeitintervalle von weniger als einer Sekunde auf 1 aufgerundet werden. In der Praxis wird das Feld als Hop Count verwendet: Wenn das Datagramm bei einem Router ankommt, verringert der Router das TTL-Feld um eins. Wenn das TTL-Feld Null erreicht, verwirft der Router das Paket und sendet normalerweise eine ICMP-Zeitüberschreitung an den Absender.

Das Programm traceroute sendet Nachrichten mit angepassten TTL-Werten und verwendet diese ICMP-Zeitüberschreitungsnachrichten, um die Router zu identifizieren, die die Pakete von der Quelle zum Ziel durchlaufen haben.

Protokoll

Dieses Feld definiert das im Datenteil des IP-Datagramms verwendete Protokoll. Die IANA unterhält eine Liste von IP-Protokollnummern gemäß RFC 790.

Header-Prüfsumme

Das 16-Bit-IPv4-Header-Prüfsummenfeld wird zur Fehlerprüfung des Headers verwendet. Wenn ein Paket bei einem Router ankommt, berechnet der Router die Prüfsumme des Headers und vergleicht sie mit dem Prüfsummenfeld. Wenn die Werte nicht übereinstimmen, verwirft der Router das Paket. Fehler im Datenfeld müssen von dem gekapselten Protokoll behandelt werden. Sowohl UDP als auch TCP haben separate Prüfsummen, die für ihre Daten gelten.

Wenn ein Paket bei einem Router ankommt, verringert der Router das TTL-Feld im Header. Folglich muss der Router eine neue Header-Prüfsumme berechnen.

Quelladresse

Dieses Feld ist die IPv4-Adresse des Absenders des Pakets. Beachten Sie, dass diese Adresse während der Übertragung durch ein Netzwerkadressübersetzungsgerät geändert werden kann.

Zieladresse

Bei diesem Feld handelt es sich um die IPv4-Adresse des Empfängers des Pakets. Wie die Quelladresse kann auch diese Adresse während der Übertragung durch ein Netzwerkadressübersetzungsgerät geändert werden.

Optionen

Das Optionsfeld wird nicht oft verwendet. Pakete, die einige Optionen enthalten, können von einigen Routern als gefährlich angesehen und blockiert werden. Es ist zu beachten, dass der Wert im IHL-Feld genügend zusätzliche 32-Bit-Wörter enthalten muss, um alle Optionen zu speichern, sowie alle Auffüllungen, die erforderlich sind, um sicherzustellen, dass der Header eine ganzzahlige Anzahl von 32-Bit-Wörtern enthält. Wenn IHL größer als 5 ist (d. h. zwischen 6 und 15 liegt), bedeutet dies, dass das Optionsfeld vorhanden ist und berücksichtigt werden muss. Die Liste der Optionen kann mit einer EOOL-Option (End of Options List, 0x00) abgeschlossen werden; dies ist nur notwendig, wenn das Ende der Optionen sonst nicht mit dem Ende des Headers zusammenfallen würde. Die möglichen Optionen, die in den Header gesetzt werden können, sind wie folgt:

Feld	Größe (Bits)	Beschreibung
Kopiert	1	Wird auf 1 gesetzt, wenn die Optionen in alle Fragmente eines fragmentierten Pakets kopiert werden sollen.
Optionsklasse	2	Eine allgemeine Optionskategorie. 0 ist für Kontrolloptionen, und 2 ist für Debugging und Messungen. 1 und 3 sind reserviert.
Optionsnummer	5	Gibt eine Option an.
Optionslänge	8	Gibt die Größe der gesamten Option an (einschließlich dieses Feldes). Dieses Feld darf bei einfachen Optionen nicht vorhanden sein.
Optionsdaten	Variable	Optionsspezifische Daten. Dieses Feld darf bei einfachen Optionen nicht vorhanden sein.

Die folgende Tabelle zeigt die definierten Optionen für IPv4. Die Spalte Optionstyp ist von den oben definierten Bits Copied, Option Class und Option Number abgeleitet.

Optionstyp (dezimal / hexadezimal)	Option Name	Beschreibung
0 / 0x00	EOOL	Ende der Optionsliste
1 / 0x01	NOP	Keine Operation
2 / 0x02	SEC	Sicherheit (defekt)
7 / 0x07	RR	Route aufzeichnen
10 / 0x0A	ZSU	Experimentelle Messung
11 / 0x0B	MTUP	MTU Probe
12 / 0x0C	MTUR	MTU Antwort
15 / 0x0F	ENCODE	ENCODE
25 / 0x19	QS	Schnellstart
30 / 0x1E	EXP	RFC3692-artiges Experiment
68 / 0x44	TS	Zeitstempel
82 / 0x52	TR	Traceroute
94 / 0x5E	EXP	RFC3692-artiges Experiment
130 / 0x82	SEC	Sicherheit (RIPSO)
131 / 0x83	LSR	Lose-Quellen-Route
133 / 0x85	E-SEC	Erweiterte Sicherheit (RIPSO)
134 / 0x86	CIPSO	Kommerzielle IP-Sicherheitsoption
136 / 0x88	SID	Strom-ID
137 / 0x89	SSR	Strict Source Route
142 / 0x8E	VISA	Experimentelle Zugangskontrolle
144 / 0x90	IMITD	IMI-Verkehrsbeschreibung
145 / 0x91	EIP	Erweitertes Internetprotokoll
147 / 0x93	ADDEXT	Adresserweiterung
148 / 0x94	RTRALT	Router-Warnung
149 / 0x95	SDB	Selektive gerichtete Sendung
151 / 0x97	DPS	Dynamischer Paketstatus
152 / 0x98	UMP	Upstream Multicast Pkt.
158 / 0x9E	EXP	RFC3692-Stil Experiment
205 / 0xCD	FINN	Experimentelle Flusskontrolle
222 / 0xDE	EXP	RFC3692-artiges Experiment

ⓘ

Daten

Die Nutzlast des Pakets ist nicht in der Prüfsumme enthalten. Ihr Inhalt wird auf der Grundlage des Wertes des Protokoll-Header-Feldes interpretiert. ⓘ

Liste der IP-Protokollnummern enthält eine vollständige Liste der Nutzdatenprotokolltypen. Einige der üblichen Nutzdatenprotokolle sind:

Protokollnummer	Name des Protokolls	Abkürzung ⓘ
1	Internet Control Message Protocol	ICMP
2	Internet-Gruppenverwaltungsprotokoll	IGMP
6	Übertragungssteuerungsprotokoll	TCP
17	Benutzer-Datagramm-Protokoll	UDP
41	IPv6-Kapselung	ENCAP
89	Open Shortest Path First	OSPF
132	Stream Control Übertragungsprotokoll	SCTP

Fragmentierung und Neuzusammensetzung

Das Internet-Protokoll ermöglicht den Datenverkehr zwischen Netzen. Es ist unabhängig von der zugrunde liegenden Übertragungstechnologie, die auf der Verbindungsschicht verwendet wird. Netze mit unterschiedlicher Hardware unterscheiden sich normalerweise nicht nur in der Übertragungsgeschwindigkeit, sondern auch in der maximalen Übertragungseinheit (MTU). Wenn ein Netz Datagramme an ein Netz mit einer kleineren MTU übertragen will, kann es seine Datagramme fragmentieren. Bei IPv4 wurde diese Funktion auf der Internet-Schicht angesiedelt und wird von IPv4-Routern ausgeführt, so dass die Hosts von diesen Problemen nicht betroffen sind. ⓘ

Bei IPv6, der nächsten Generation des Internet-Protokolls, können Router dagegen keine Fragmentierung vornehmen; Hosts müssen vor dem Senden von Datagrammen eine Path MTU Discovery durchführen. ⓘ

Fragmentierung

Wenn ein Router ein Paket empfängt, prüft er die Zieladresse und bestimmt die zu verwendende ausgehende Schnittstelle sowie deren MTU. Wenn die Paketgröße größer als die MTU ist und das "Do not Fragment"-Bit (DF) im Header des Pakets auf 0 gesetzt ist, dann kann der Router das Paket fragmentieren. ⓘ

Der Router unterteilt das Paket in Fragmente. Die maximale Größe jedes Fragments entspricht der MTU des ausgehenden Pakets abzüglich der Größe des IP-Headers (mindestens 20 Byte, höchstens 60 Byte). Der Router packt jedes Fragment in ein eigenes Paket, wobei jedes Fragment-Paket die folgenden Änderungen aufweist:

• Das Feld für die Gesamtlänge entspricht der Fragmentgröße.
• Das Kennzeichen für mehr Fragmente (MF) wird für alle Fragmente gesetzt, außer für das letzte, das auf 0 gesetzt wird.
• Das Fragment-Offset-Feld wird auf der Grundlage des Offsets des Fragments in der ursprünglichen Datennutzlast gesetzt. Dies wird in Einheiten von 8-Byte-Blöcken gemessen.
• Das Header-Prüfsummenfeld wird neu berechnet. ⓘ

Bei einer MTU von 1.500 Byte und einer Header-Größe von 20 Byte wären die Fragment-Offsets beispielsweise Vielfache von ${\frac {1{,}500-20}{8}}=185$ (0, 185, 370, 555, 740, usw.). ⓘ

Es ist möglich, dass ein Paket an einem Router fragmentiert wird und dass die Fragmente an einem anderen Router weiter fragmentiert werden. Zum Beispiel wird ein Paket von 4.520 Bytes, einschließlich eines 20 Bytes großen IP-Headers, auf einer Verbindung mit einer MTU von 2.500 Bytes in zwei Pakete fragmentiert:

Fragment	Größe (Bytes)	Header-Größe (Bytes)	Datengröße (Bytes)	Kennzeichen Weitere Fragmente	Fragment-Versatz (8-Byte-Blöcke) ⓘ
1	2,500	20	2,480	1	0
2	2,040	20	2,020	0	310

Die Gesamtgröße der Daten bleibt erhalten: 2.480 Bytes + 2.020 Bytes = 4.500 Bytes. Die Offsets sind $0$ und ${\frac {0+2{,}480}{8}}=310$. ⓘ

Bei der Weiterleitung an eine Verbindung mit einer MTU von 1.500 Byte wird jedes Fragment in zwei Fragmente zerlegt:

Fragment	Größe (Bytes)	Header-Größe (Bytes)	Datengröße (Bytes)	Kennzeichen Weitere Fragmente	Fragment-Versatz (8-Byte-Blöcke) ⓘ
1	1,500	20	1,480	1	0
2	1,020	20	1,000	1	185
3	1,500	20	1,480	1	310
4	560	20	540	0	495

Auch hier bleibt die Datengröße erhalten: 1.480 + 1.000 = 2.480, und 1.480 + 540 = 2.020. ⓘ

Auch in diesem Fall bleibt das Bit "Weitere Fragmente" für alle Fragmente, die mit einer 1 ankamen, auf 1, und für das letzte Fragment, das ankommt, funktioniert es wie üblich, d. h. das MF-Bit wird nur im letzten Fragment auf 0 gesetzt. Und natürlich hat das Identifikationsfeld in allen neu fragmentierten Fragmenten weiterhin denselben Wert. Auf diese Weise weiß der Empfänger auch bei neu fragmentierten Fragmenten, dass sie ursprünglich alle von demselben Paket ausgegangen sind. ⓘ

Der letzte Offset und die letzte Datengröße werden zur Berechnung der Gesamtdatengröße verwendet: $495\times 8+540=3{,}960+540=4{,}500$. ⓘ

Neuzusammensetzung

Ein Empfänger weiß, dass ein Paket ein Fragment ist, wenn mindestens eine der folgenden Bedingungen erfüllt ist:

• Das Flag more fragments ist gesetzt, was für alle Fragmente außer dem letzten zutrifft.
• Das Feld fragment offset ist ungleich Null, was für alle Fragmente außer dem ersten zutrifft. ⓘ

Der Empfänger identifiziert passende Fragmente anhand der Quell- und Zieladresse, der Protokoll-ID und des Identifikationsfeldes. Der Empfänger setzt die Daten aus Fragmenten mit derselben ID unter Verwendung des Fragment-Offsets und des Flags "more fragments" wieder zusammen. Wenn der Empfänger das letzte Fragment empfängt, bei dem das "More fragments"-Flag auf 0 gesetzt ist, kann er die Größe der ursprünglichen Datennutzlast berechnen, indem er den Offset des letzten Fragments mit acht multipliziert und die Datengröße des letzten Fragments addiert. Im gegebenen Beispiel war diese Berechnung $495\times 8+540=4{,}500$ Bytes. Wenn der Empfänger alle Fragmente hat, können sie in der richtigen Reihenfolge entsprechend den Offsets wieder zusammengesetzt werden, um das ursprüngliche Datagramm zu bilden. ⓘ

Hilfsprotokolle

IP-Adressen sind nicht dauerhaft an die Netzwerkhardware gebunden, und in modernen Betriebssystemen kann eine Netzwerkschnittstelle sogar mehrere IP-Adressen haben. Damit ein IP-Paket ordnungsgemäß an den Zielhost auf einer Verbindung zugestellt werden kann, benötigen Hosts und Router zusätzliche Mechanismen, um eine Verbindung zwischen der Hardware-Adresse von Netzwerkschnittstellen und IP-Adressen herzustellen. Das Address Resolution Protocol (ARP) führt diese Übersetzung von IP-Adressen in Hardware-Adressen für IPv4 durch. Darüber hinaus ist häufig die umgekehrte Korrelation erforderlich. Wenn beispielsweise eine Adresse nicht von einem Administrator vorkonfiguriert wurde, muss ein IP-Host, wenn er hochgefahren oder mit einem Netz verbunden wird, seine IP-Adresse ermitteln. Zu den Protokollen für solche Rückwärtskorrelationen gehören das Dynamic Host Configuration Protocol (DHCP), das Bootstrap Protocol (BOOTP) und, seltener, Reverse ARP. ⓘ

Adressformat

Beispiele

Beispiel: (24-Bit-Netzwerk) ⓘ

Subnetzmaske	=	11111111.11111111.11111111.00000000	(255.255.255.0) ⓘ
Der Besitzer legt den Netzteil auf 192.168.0 fest:
Netzteil	=	11000000.10101000.00000000
Das führt zu folgender Adressverteilung:
Netzname	=	11000000.10101000.00000000.00000000	(192.168.0.0)
Erste Adr.	=	11000000.10101000.00000000.00000001	(192.168.0.1)
Letzte Adr.	=	11000000.10101000.00000000.11111110	(192.168.0.254)
Broadcast	=	11000000.10101000.00000000.11111111	(192.168.0.255)
Anzahl zu vergebende Adressen: 28 − 2 = 254

Beispiel: (21-Bit-Netzwerk) ⓘ

Subnetzmaske	=	11111111.11111111.11111000.00000000	(255.255.248.0) ⓘ
Der Besitzer legt den Netzteil auf 192.168.120 fest (wobei im dritten Oktett nur die fünf höchstwertigen Bits zum Netzteil gehören):
Netzteil	=	11000000.10101000.01111
Das führt zu folgender Adressverteilung:
Netzname	=	11000000.10101000.01111000.00000000	(192.168.120.0)
Erste Adr.	=	11000000.10101000.01111000.00000001	(192.168.120.1)
Letzte Adr.	=	11000000.10101000.01111111.11111110	(192.168.127.254)
Broadcast	=	11000000.10101000.01111111.11111111	(192.168.127.255)
Anzahl zu vergebende Adressen: 211 − 2 = 2046

IPv4 auf Ethernet

IPv4 kann auf vielen verschiedenen Medien aufsetzen, zum Beispiel auf seriellen Schnittstellen (PPP oder SLIP), Satellitenverbindungen usw. Im LAN-Bereich wird heute fast immer Ethernet eingesetzt. Ethernet verwaltet eigene 48-Bit-Adressen. Wenn IP über Ethernet gesendet wird, wird ein 14 (oder bei VLAN 18) Byte großer Ethernet-Header vor dem IP-Header gesendet. Nach den Daten folgt eine 32-Bit-CRC-Prüfsumme. Neben der maximalen Paketlänge von 1522 (bzw. 1518) Bytes kann Ethernet keine kleineren Pakete als 64 Bytes übertragen, so dass zu kurze IP-Pakete (Datenlänge kleiner als 46 Bytes) mit Nullbytes erweitert werden (sogenanntes Padding). Die Länge im IP-Header gibt dann Auskunft über die tatsächliche Paketgröße. ⓘ

Im Ethernet hat jede Netzwerkkarte ihre eigene, herstellerbezogene 48-Bit-Adresse, zusätzlich gibt es eine Ethernet-Broadcastadresse. Ein Sender muss die Ethernetadresse der Zielnetzwerkkarte kennen, bevor ein IP-Paket gesendet werden kann. Dazu wird ARP (Address Resolution Protocol) verwendet. Jeder Rechner verwaltet einen ARP-Cache, in dem er ihm bekannte Zuordnungen von Ethernet-Kartenadressen speichert. Unbekannte Adressen erfährt er über ARP mittels einer Anfrage (ARP-Request) über einen Ethernet-Broadcast (Nachricht an alle Empfänger), die der zugehörige Empfänger beantwortet (ARP-Reply). ⓘ

Adressknappheit

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

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. Gemäß einer Vereinbarung aus dem Jahr 2009 wurde am 3. Februar 2011 schließlich der verbliebene Adressraum gleichmäßig auf die regionalen Adressvergabestellen verteilt: jeweils ein /8-Adressblock pro Vergabestelle. 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. Am 14. September 2012 folgte dann RIPE NCC mit der letzten regulären Zuteilung in der Region Europa/Naher Osten. 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. ⓘ

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. ⓘ

Adressfragmentierung

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. ⓘ