IPv4

aus Wikipedia, der freien Enzyklopädie
Dies ist eine alte Version dieser Seite, zuletzt bearbeitet am 2. September 2023 um 13:51 Uhr durch Matthäus Wander (Diskussion | Beiträge) (→‎Nutzbare Adressen: RFC 950 ist nicht die erste Erwähnung dieser Praxis → ersetzt durch RFC 923; konsistente Adressen in allen Beispielen). Sie kann sich erheblich von der aktuellen Version unterscheiden.
Zur Navigation springen Zur Suche springen
Eine gesichtete Version dieser Seite, die am 2. September 2023 freigegeben wurde, basiert auf dieser Version.
IPv4 im TCP/IP-Protokollstapel:
Anwendung HTTP IMAP SMTP DNS …
Transport TCP UDP
Internet IPv4
Netzzugang Ethernet Token
Bus 		Token
Ring 		FDDI …

IPv4 (Internet Protocol Version 4), vor der Entwicklung von IPv6 auch einfach IP, ist die vierte Version des Internet Protocols (IP). Es war die erste Version des Internet Protocols, welche weltweit verbreitet und eingesetzt wurde, und bildet als Teil der Internetprotokollfamilie eine wichtige technische Grundlage des Internets. Es wurde in RFC 791 im Jahr 1981 definiert.[1] IPv4 verwendet 32 Bit lange IP-Adressen.

Geschichte

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 Internet 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]

Adressformat

IPv4 benutzt 32-Bit-Adressen, wodurch ein Adressraum von knapp 4,3 Milliarden Adressen zur Verfügung stehen. 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 (nicht: 192.000.002.155).

Jedes der vier Oktetts besteht aus 8 Bit und stellt somit 28 = 256 verschiedene Werte dar. Daraus ergibt sich eine Gesamtzahl von 256 × 256 × 256 × 256 = 2564 = 232 = 4.294.967.296 IPv4-Adressen.

Netzanteil und Hostanteil

Eine IP-Adresse besteht aus einem Netzanteil und einem Hostanteil. Der Netzanteil identifiziert ein Teilnetz, der Hostanteil identifiziert ein Gerät (Host) innerhalb eines Teilnetzes.

Die genaue Aufteilung zwischen Netzanteil und Hostanteil wird durch eine Subnetzmaske festgelegt, beispielsweise 255.255.255.0, was in binärer Darstellung 11111111.11111111.11111111.00000000 entspricht. Die Bits der Subnetzmaske, die „1“ lauten, legen die Stellen der IP-Adresse fest, die zum Netzanteil gehören. Alle restlichen Stellen der IP-Adresse, die entsprechend in der Subnetzmaske auf „0“ gesetzt sind, gehören zum Hostanteil. In der CIDR-Notation wird die Länge des Netzanteils durch die Anzahl Bits angegeben und mit Schrägstrich getrennt als Suffix an die IP-Adresse angehängt, beispielsweise /24. Somit ist der Netzanteil 24 Bits lang, was der Subnetzmaske 255.255.255.0 entspricht. Die übrigen 8 Bits gehören somit zum Hostanteil.

Beispiel:

dezimal binär
IP-Adresse 192.0.2 .155 → 11000000.00000000.00000010 .10011011
Subnetzmaske 255.255.255 .0 → 11111111.11111111.11111111 .00000000
Netzanteil Hostanteil Netzanteil Hostanteil
CIDR-Notation 192.0.2.155/24

Die Unterscheidung zwischen Netzanteil ist Hostanteil ist erforderlich für die Entscheidung, ob sich eine Zieladresse in demselben lokalen Netz oder in einem anderen Netz befindet. Wenn der Netzanteil identisch ist, können die Endgeräte innerhalb einer Broadcast-Domäne direkt miteinander kommunizieren, beispielsweise per Ethernet oder WLAN. Im selben Teilnetz darf der Hostanteil nicht mehrfach vergeben sein, da es ansonsten zu einem IP-Adresskonflikt kommt. Für jedes Endgerät vergibt der zuständige Netzwerkadministrator den Hostanteil eindeutig durch eine manuelle oder automatische IP-Adresszuweisung.

Für die Kommunikation zwischen unterschiedlichen Netzen wird ein Router benötigt, siehe Abschnitt #Routing. Der Netzanteil muss ebenfalls eindeutig sein, damit es nicht zu Routing-Konflikten führt. Die Vergabe von IP-Netzbereichen erfolgt durch eine hierarchische Organisationsstruktur zwischen der Internet Assigned Numbers Authority, den Regional Internet Registrys und den Local Internet Registrys.

Subnetting

Ein Netz kann in weitere Teil- oder Subnetze unterteilt werden. Dies erfolgt, indem ein oder mehrere höchwertige Bits des Hostanteils zur Unterscheidung des Subnetzes verwendet werden. Innerhalb eines Subnetzes wird die Subnetzmaske angepasst, um den verkleinerten Hostanteil wiederzuspiegeln. Subnetting wird zur Segmentierung von Netzen verwendet. Für die Kommunikation zwischen den Subnetzen ist ein Router erforderlich.

Beispiel:

Netzadresse (CIDR) Subnetzmaske Netz-, Subnetz- und Hostanteil (binär)
Netz 192.0.2.0/24 255.255.255.0 11000000.00000000.00000010.xxxxxxxx
Subnetz 192.0.2.0/25 255.255.255.128 11000000.00000000.00000010.0xxxxxxx
Subnetz 192.0.2.128/26 255.255.255.192 11000000.00000000.00000010.10xxxxxx
Subnetz 192.0.2.192/26 255.255.255.192 11000000.00000000.00000010.11xxxxxx

Nach außen hin wird das Netz beim Routing als ein ganzes adressiert. Die innere Unterteilung in Subnetze ist nicht direkt ersichtlich. Das Gegenteil von Subnetting ist Supernetting und beschreibt die Zusammenfassung von mehreren angrenzenden Netzadressen in einer gemeinsamen Route. Der Zweck ist die Minimierung von Einträgen in einer Routingtabelle. Supernetting wird bei Classless Inter-Domain Routing als Routenaggregation bezeichnet.

Historische Netzklassen (nicht mehr in Gebrauch seit 1993)

Historische IP-Netzklassen
Bit 31–28 27–24 23–16 15–8 7–0
Class A: Netze 0.0.0.0/8 bis 127.255.255.255
0 … 128 8-Bit-Netze 24-Bit-Host
Class B: Netze 128.0.0.0/16 bis 191.255.255.255
1 0 … 16.384 16-Bit-Netze 16-Bit-Host
Class C: Netze 192.0.0.0/24 bis 223.255.255.255
1 1 0 … 2.097.152 24-Bit-Netze 8-Bit-Host
Class D: Multicast-Gruppen 224.0.0.0/4 bis 239.255.255.255
1 1 1 0 28-Bit-Multicast-Gruppen-ID
Class E: Reserviert 240.0.0.0/4 bis 255.255.255.255
1 1 1 1 0 27-Bit-Future-Use (zukünftige Anwendungen)

Ursprünglich gab es fest vorgeschriebene Einteilungen für Netzklassen mit einer festen Länge des Netzanteils. Die Größe des Netzanteils ergab sich aus den ersten Bits der Adresse; eine Subnetzmaske musste nicht angegeben werden. Da diese Einteilung sehr unflexibel ist, wird seit 1993 ausschließlich das Verfahren Classless Inter-Domain Routing angewandt, welches bitvariable Netzmasken ermöglicht. Obwohl das Konzept von Netzklassen seitdem nicht mehr im Einsatz ist, blieb der Begriff der Netzklasse über Jahre verbreitet. Hierbei steht „Klasse A“ für ein Netz der CIDR-Präfixlänge /8, „Klasse B“ für /16 und „Klasse C“ für /24. Die ursprüngliche Zuordnung zu festgelegten Adressbereichen wird für gewöhnlich ignoriert, sodass diese Begrifflichkeit nicht mit dem ursprünglichen Konzept der Netzklassen konform ist.

Nutzbare Adressen

Die jeweils erste und letzte Adresse eines Subnetzes haben eine besondere Bedeutung und stehen üblicherweise nicht zur Vergabe an Hosts zur Verfügung. Die maximale Anzahl der zu vergebenen Hostadressen in einem Netz beträgt somit effektiv:

2Anzahl Bits der Hostadresse − 2.

Diese Einschränkung geht auf die Praxis zurück, Adressen mit „0“ an allen Stellen als „dieses Netz“ und Adressen mit „1“ an allen Stellen als „alle Hosts“ zu interpretieren.[6] Die erste Adresse eines Subnetzes (zum Beispiel 192.0.2.0) bezeichnet das Netz selbst. Die letzte Adresse (zum Beispiel 192.0.2.255) bezeichnet die Broadcast-Adresse, unter der alle Hosts im Netz angesprochen werden können. Ein Versuch, diese Einschränkung aufzuheben hat sich nicht durchgesetzt,[7] sodass auch heute noch in praktisch jedem Netz beide Adressen reserviert sind. Gängig ist außerdem, das Default Gateway auf die zweite oder die vorletzte IP-Adresse im Netz zu legen (zum Beispiel 192.0.2.1 oder 192.0.2.254), wobei es dafür keinerlei Vorgaben gibt.

Besondere Netzwerkadressen

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

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

Private IP-Adressen

Bestimmte IP-Adressbereiche stehen zur freien Verfügung und können ohne vorherige Registrierung für private Netze verwendet werden. Im Internet werden diese IP-Adressbereiche nicht geroutet. Historisch befand sich jeder der Adressbereiche in einer anderen Netzklasse. Aus Gewohnheitsgründen ist es gängig für Subnetze im Adressblock 172.16.0.0/12 die Präfixlänge /16 und im Adressblock 192.168.0.0/16 die Präfixlänge /24 zu verwenden. Eine Vorgabe existiert diesbezüglich nicht.

CIDR-Adressblock Adressbereich Anzahl IP-Adressen
10.0.0.0/8 10.0.0.0 – 10.255.255.255 224 = 16.777.216
172.16.0.0/12 172.16.0.0 – 172.31.255.255 220 = 1.048.576
192.168.0.0/16 192.168.0.0 – 192.168.255.255 216 = 65.536

Beispiele

Beispiel: (24-Bit-Netz)
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 Host-Adresse = 11000000.10101000.00000000.00000001 (192.168.0.1)
letzte Host-Adresse = 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 Host-Adresse = 11000000.10101000.01111000.00000001 (192.168.120.1)
letzte Host-Adresse = 11000000.10101000.01111111.11111110 (192.168.127.254)
Broadcast = 11000000.10101000.01111111.11111111 (192.168.127.255)
Anzahl zu vergebende Adressen: 211 − 2 = 2046

Paketlänge

Ein IP-Paket besteht aus einem Header und den eigentlichen Daten. Der Datenteil enthält in der Regel ein weiteres Protokoll, meist TCP, UDP oder ICMP. Die maximale Länge eines IP-Pakets beträgt 65535 Bytes (216−1), die maximale Datenlänge 65515 Bytes (Paketlänge – minimale Headerlänge von 20 Byte). Normalerweise beschränkt der Sender die Paketlänge auf diejenige des zugrundeliegenden Mediums. Bei Ethernet beträgt die sogenannte MTU (Maximum Transmission Unit) 1500 Bytes, da ein Ethernet-Datenpaket maximal 1518 Bytes lang sein darf und 18 Bytes vom Ethernet selbst belegt werden. Für IP (Header und Daten) stehen also nur 1500 Bytes zur Verfügung. Deshalb ist die Länge von IP-Paketen oft auf 1500 Bytes festgesetzt.

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

ICMP

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. Wichtig ist zum Beispiel die ICMP-Source-Quench-Mitteilung, die den Sender über das Verwerfen von Paketen wegen Überlastung eines Routers informiert. Da jedes IP-Paket die Quell-IP-Adresse enthält, können Informationen an den Sender zurückübermittelt werden. Dieser kann nach einem „Source-Quench“ die Paketsendefrequenz verringern und so die Notwendigkeit eines weiteren Verwerfens minimieren oder vermeiden.

ICMP kann zusammen mit dem Don’t-Fragment-Bit des IP-Pakets auch eingesetzt werden, um die maximale Paketgröße MTU eines Übertragungsweges zu ermitteln (sogenannte PMTU Path Maximum Transmission Unit). Dies ist die MTU desjenigen Netzwerkes mit der kleinsten MTU aller passierten Netzwerke. Dadurch kann auf Fragmentierung verzichtet werden, wenn der Sender nur Pakete mit der maximalen Größe der PMTU erzeugt.

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

Header-Format

Der IPv4-Header ist normalerweise 20 Bytes lang. Bei Übertragung auf Basis von Ethernet folgt er dem Ethernet-Typfeld, das für IPv4-Pakete auf 080016 festgelegt ist. Auf anderen Übertragungsmedien und Protokollen kann der Header auch der erste Eintrag sein.

IPv4 bietet verschiedene, größtenteils ungenutzte Optionen, die den Header bis auf 60 Bytes (in 4-Byte-Schritten) verlängern können.

0–3 4–7 8–13 14–15 16–18 19–23 24–27 28–31
Version IHL DSCP ECN Gesamtlänge
Identifikation Flags Fragment Offset
TTL Protokoll Header-Prüfsumme
Quell-IP-Adresse
Ziel-IP-Adresse
evtl. Optionen …

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.

Datagrammfragmentierung

Auf dem Weg vom Sender zum Empfänger kann es vorkommen, dass ein Datagramm ein Netz durchlaufen muss, welches nur kleine Datagramme unterstützt. Jedes Datagramm erhält vom Sender eine Kennung (Identification). Stellt ein Router auf dem Weg zum Ziel fest, dass das Datagramm für das nächste Teilnetz zu groß ist, so kann er es in zwei Fragmente aufteilen. Dazu sind folgende Schritte notwendig:

  • Aufteilen der Nutzdaten an einer 64-Bit-Grenze (das zweite Fragment enthält dann nicht unbedingt ein Vielfaches von 64 Bit Daten)
  • Kopieren der Headerdaten des Originaldatagramms in die neuen Header
  • Setzen des „more-fragments“-Flags beim ersten Fragment
  • Beim zweiten Fragment erhält das more-fragments Flag den Wert des Originaldatagramms, da das Originaldatagramm bereits ein Fragment gewesen sein kann.
  • Erneutes Setzen der Länge-Felder in den Headern
  • Beim zweiten Fragment enthält Fragment-Offset die Summe aus Fragment-Offset des Originaldatagramms und die Anzahl der (Nutzdaten-)Bytes des ersten Fragments.

Das Fragmentieren in n > 2 Fragmente funktioniert entsprechend.

Um ein Paket wieder zusammenzusetzen, kombiniert der Empfänger alle Fragmente, welche die gleiche Kennung (Identifikation), den gleichen Absender, Empfänger und das gleiche Protokoll haben. Dabei erkennt er das erste Fragment daran, dass Fragment-Offset den Wert 0 hat. Das jeweils nächste Fragment erkennt er ebenfalls am Fragment-Offset und das letzte Fragment daran, dass more-fragments den Wert 0 hat.

Höhere Protokolle

IPv4 ist ein geroutetes Protokoll (Schicht 2 im TCP/IP-Referenzmodell – Schicht 3 im ISO/OSI-Modell). Auf IPv4 werden weitere Protokolle aufgesetzt, das heißt in den Datenteil des IP-Pakets werden die Header, Daten und eventuelle Trailer der oberen Protokolle eingefügt (Protokollstapel). Eine Liste der registrierten Protokolle findet sich in unixoiden Betriebssystemen in der Datei „/etc/protocols“.

Neben dem erwähnten ICMP wird TCP verwendet, das TCP/IP zusammen mit IP den Namen gegeben hat. TCP ist ein verbindungsorientiertes Protokoll, das einen byteorientierten, bidirektionalen, zuverlässigen Datenstrom zur Verfügung stellt. Es wird im WAN-Bereich praktisch für alle Arten von Daten- und Informationsübertragungen eingesetzt.

UDP, ein paketorientiertes Protokoll, setzt ebenfalls auf IP auf. Es ist ein einfaches Protokoll, das die Paketeigenschaften von IP im Wesentlichen beibehält (verbindungslos, unzuverlässig, erlaubt doppelte Pakete etc.). TCP und UDP fügen IP eine Prüfsumme über die Daten (die Prüfsumme im IP-Header prüft nur die Headerdaten) und als Quell- und Zielport jeweils eine 16-Bit-Zahl hinzu. Diese Ports bilden zusammen mit der jeweiligen Quell- und Zieladresse im IP-Paket sogenannte Endpunkte. Prozesse kommunizieren über diese Endpunkte. TCP baut eine Verbindung nicht zwischen IP-Adressen, sondern zwischen zwei Endpunkten auf.

Die weiteren Protokolle setzen alle entweder auf TCP oder auf UDP auf. Ein wichtiges Protokoll ist das Domain Name System DNS, das eine Umsetzung von Rechnernamen zu IP-Adressen erlaubt. Es überträgt Informationen normalerweise über UDP, der Abgleich zwischen zwei DNS-Servern kann aber auch TCP verwenden.

Die Ports teilen sich auf in:

  • privilegierte Ports (1–1023); diese dürfen nur vom Benutzer Root verwendet werden.
  • registrierte Ports (1024–49.151); die Registrierung unterliegt der IANA. Eine Liste findet sich auf Unix-Systemen in der Datei „/etc/services“.
  • nicht registrierte Ports (49.152–65.535)

Adressknappheit

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

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.[27]

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.

IPv6

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 2128 = 65.5368 ≈ 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

Siehe auch

Literatur

  • 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

Einzelnachweise

  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. ↑ a b c d e RFC 6890 – Special-Purpose IP Address Registries. April 2013 (englisch).
  9. ↑ a b RFC 1122 – Requirements for Internet Hosts – Communication Layers. Oktober 1989 (englisch).
  10. ↑ a b c 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. ↑ Two /8s allocated to APNIC from IANA. (Memento vom 17. August 2011 auf WebCite) APNIC, 1. Februar 2011.
  20. ↑ Global Policy for the Allocation of the Remaining IPv4 Address Space. ICANN.
  21. ↑ Alle Internetadressen weltweit sind aufgebraucht. Welt Online, 3. Februar 2011.
  22. ↑ RIPE NCC Receives Final /8 of IPv4 Address Space from IANA. ripe.net (englisch).
  23. ↑ APNIC IPv4 Address Pool Reaches Final /8. (Memento vom 17. August 2011 auf WebCite) APNIC
  24. ↑ ripe.net
  25. ↑ Policies for IPv4 address space management in the Asia Pacific region. (Memento vom 18. November 2011 im Internet Archive) APNIC, Abschnitt 3
  26. ↑ ripe.net, Abschnitt 5.6
  27. ↑ The RIPE NCC has run out of IPv4 Addresses. 25. November 2019, abgerufen am 26. November 2019 (englisch).
Abgerufen von „https://de.wikipedia.org/w/index.php?title=IPv4&oldid=236973326“