Internet Protocol Version 4: Unterschied zwischen den Versionen
Zeile 39: | Zeile 39: | ||
</div> | </div> | ||
= | ==IPv4== | ||
Internet Protokoll Version 4 | Internet Protokoll Version 4 | ||
== IP – Einordnung ins DoD-Modell == | |||
== Exkurs: Bezeichnung der Daten im Protokoll-Stapel == | |||
== Eigenschaften von IP == | |||
Grundlage des TCP/IP-Stapels (TCP/IP-Stack) | |||
Teil der Netzwerkschicht des DoD-Modells (02) | |||
Setzt auf Data Link Layer auf | Setzt auf Data Link Layer auf | ||
Zeile 58: | Zeile 57: | ||
Ethernetypfeld: 08-00 | Ethernetypfeld: 08-00 | ||
1977 entwickelt | |||
In der Version 4 das Standard-Protokoll im Internet | |||
Die Weiterentwicklung zur Version 6 ist abgeschlossen, aber noch wenig genutzt | Die Weiterentwicklung zur Version 6 ist abgeschlossen, aber noch wenig genutzt | ||
Hardwareunabhängig | |||
Die Adressierung ist nicht von der Netzwerktechnologie abhängig | Die Adressierung ist nicht von der Netzwerktechnologie abhängig | ||
Paketorientierter verbindungsloser Datagram-Dienst | |||
freie Routenwahl | freie Routenwahl | ||
Zeile 74: | Zeile 73: | ||
kein Verbindungsauf- oder abbau | kein Verbindungsauf- oder abbau | ||
Keine Fehlerkorrektur | |||
== IP - Aufgaben == | |||
Gewährleistung des Transports von Daten über heterogene Netzwerktopologien | |||
Abstraktion von Besonderheiten des darunter liegenden Layers 2(z.B. Ethernet, Token Ring oder ATM) | Abstraktion von Besonderheiten des darunter liegenden Layers 2(z.B. Ethernet, Token Ring oder ATM) | ||
Definition eines Adressschemas | |||
Definition von Datagrammen | |||
Datagram-Service | |||
Unzuverlässig | Unzuverlässig | ||
Keine Auslieferungs-Garantie | Keine Auslieferungs-Garantie | ||
Zeile 94: | Zeile 93: | ||
Keine Fehlerfreiheits-Garantie | Keine Fehlerfreiheits-Garantie | ||
Routing zwischen Netzen | |||
Fragmentierung / Reassemblierung von Datagrammen | |||
Übermittlung der Daten vom Transport- zu Networklayer | |||
Definition/ Adressierung höherer Protokolle | Definition/ Adressierung höherer Protokolle | ||
== IP - Wichtige RFCs == | |||
RFC 791IP-Protokoll | |||
RFC 815IP over X.25 Networks | |||
RFC 894IP over Ethernet-Networks | |||
RFC 948IP over 802.3 Networks | |||
RFC 1051IP over Arcnet-Networks | |||
RFC 1055IP over Serial Lines („SLIP“) | |||
RFC 1088IP over Netbios Networks | |||
RFC 1577IP over ATM Networks („Classical IP“) | |||
== Aufbau des IP-Headersdeutsch == | |||
== IP-Header englisch == | |||
== IP-Header im Detail 1 - Version und Länge == | |||
Version | |||
Die Version des IP-Protokolls | |||
Wir behandeln hier Version 4 | Wir behandeln hier Version 4 | ||
Länge | |||
Dieses Feld gibt die Länge des IP-Protokoll-Kopfes in 32-Bit-Worten an | |||
Die minimale Länge beträgt 5 Worte, was auch der Normalfall ist | |||
Vergrößerung durch Angabe von Optionen | |||
XX IP-Header im Detail 2 - Servicetypen | |||
Mit den Precedence-Bit (0-2) kann eine Priorität von 0 - 7 angegeben werden | |||
Bit 3 – 6 haben folgende Bedeutung | |||
1000 Minimize-delay | 1000 Minimize-delay | ||
0100 Maximize throughput | 0100 Maximize throughput | ||
0010 Maximize reliability | 0010 Maximize reliability | ||
0001 Minimize monetary costs | 0001 Minimize monetary costs | ||
0000 Normal service | 0000 Normal service | ||
Bit 7 ist reserviert (ohne Bedeutung) | |||
Servicetypen werden nicht von allen Routern unterstützt | |||
== IP-Header im Detail 3 - Paketlänge und Identifikation == | |||
Paket-Länge | |||
Die Länge des Paketes in Byte inklusive Protokoll-Kopf | |||
16 Bit – Feld (Maximale Paketgröße = 65.535 Byte) | |||
Identifikation | |||
Eine eindeutige Identifikation (Zähler) | |||
Diese Kennungen sollten sich nur nach längeren Zeitabständen wiederholen | |||
um nicht mit verspäteten PDU in Konflikt zu kommen | um nicht mit verspäteten PDU in Konflikt zu kommen | ||
Paketübertragung im Internet | |||
== IP-Header im Detail 4 - Lebenszeit (TTL = Time To Live) == | |||
Dieses Feld gibt an, wie lange das Paket maximal unterwegs sein darf | |||
Das Problem | |||
Beim Routen durch vermaschte Netze, können Datagramme/ Fragmente ziellos und unendlich lange kreisen | |||
Das verbraucht Ressourcen und kann Netzwerke bis zum Stillstand belasten | |||
Die Lösung | |||
Jeder Knoten (Router) verringert diesen Wert um mindestens 1 | |||
Hält ein Router ein Paket länger als eine Sekunde, verringert er die TTL um 1 je weitere Sekunde | Hält ein Router ein Paket länger als eine Sekunde, verringert er die TTL um 1 je weitere Sekunde | ||
Zeile 197: | Zeile 196: | ||
Bei Erreichen des Wertes „0“, wird Paket verworfen | Bei Erreichen des Wertes „0“, wird Paket verworfen | ||
== IP-Header im Detail 5 - Sender- und Empfänger-Adressen == | |||
32-Bit IP-Adresse (IPv4), 128-Bit IP-Adresse (IPv6) | |||
unabhängig von der zugrunde liegenden Netztechnologie | unabhängig von der zugrunde liegenden Netztechnologie | ||
Das Internet-Protokoll definiert also eine rein logische Netztopologie | |||
Die Vergabe der IP-Adressen wird international von der IANA (Internet Assigned Numbers Association) geregelt | |||
die IANA verteilt die Organisation auf mehrere Unterorganisationen | die IANA verteilt die Organisation auf mehrere Unterorganisationen | ||
Die in Europa zuständige Organisation ist das RIPE (Réseaux IP Européens) | Die in Europa zuständige Organisation ist das RIPE (Réseaux IP Européens) | ||
== IP-Header im Detail 6 - DF, MF und Fragmentabstand == | |||
DF (Don‘t Fragment) | |||
0 = May Fragment | |||
1 = Don‘t Fragment | |||
MF (More Fragment) | |||
0 = Last Fragment | |||
1 = More Fragment | |||
Fragmentabstand | |||
Länge relativ zum Beginn des ursprünglichen Datagram | |||
== IP-Header im Detail 7 - Protokoll == | |||
Nummer des Transportprotokolls | |||
Legt fest, welches Protokoll für die Weiterverarbeitung auf 03 zuständig ist (demultiplexing) | |||
gemäß RFC 1700 (Assigned Numbers) | |||
/etc/protocol | /etc/protocol | ||
%SYSTEMROOT%\system32\drivers\etc\protocol | %SYSTEMROOT%\system32\drivers\etc\protocol | ||
Ausgewählte IP-Protokollnummern | |||
== IP-Header im Detail 7 - Weitere Felder == | |||
Prüfsumme | |||
wird über den gesamten IP Header berechnet | |||
Berechnung beim Sender: | |||
setze das checksum Feld auf 0 | setze das checksum Feld auf 0 | ||
Zeile 257: | Zeile 256: | ||
das Ergebnis wird bitweise invertiert und stellt dann den Wert für das checksum Feld dar. | das Ergebnis wird bitweise invertiert und stellt dann den Wert für das checksum Feld dar. | ||
Check beim Emfänger: | |||
XOR über alle 16-bit Worte im Header (inkl. checksum) | XOR über alle 16-bit Worte im Header (inkl. checksum) | ||
Zeile 263: | Zeile 262: | ||
OK, wenn im Ergebnis alle bits auf 1 stehen | OK, wenn im Ergebnis alle bits auf 1 stehen | ||
Füllzeichen | |||
Auffüllen des Headers auf ein Vielfaches von 32-Bit | |||
Nutzdaten | |||
Segmente und Datagramme höherer Protokolle | |||
Meist TCP oder UDP | Meist TCP oder UDP | ||
XX IP-Header im Detail 8 - Optionen | |||
Flexible Erweiterbarkeit des Headers | |||
Variable Länge (max. 40 Byte) | |||
Folgende Optionen sind möglich | |||
Source Routing | |||
Liste von Routern, die ein Datagram durchlaufen soll | Liste von Routern, die ein Datagram durchlaufen soll | ||
Zeile 295: | Zeile 294: | ||
Source Routing ist nahezu überall abgeschaltet da, es ein Sicherheitsrisiko darstellt - IP Spoofing! | Source Routing ist nahezu überall abgeschaltet da, es ein Sicherheitsrisiko darstellt - IP Spoofing! | ||
Record Route | |||
Router hängen ihre IP-Adresse an das Optionsfeld an | Router hängen ihre IP-Adresse an das Optionsfeld an | ||
Zeitstempel | |||
Zusätzlich zur IP-Adresse wird die Uhrzeit des Durchlaufes angehangen | Zusätzlich zur IP-Adresse wird die Uhrzeit des Durchlaufes angehangen | ||
== Fragmentierung im Internet == | |||
== Warum Fragmentierung? == | |||
Anpassung der Datagramgrösse an die MTU der lokalen Netz-Technologie | |||
Definition des Protokolls / Beschränkung durch Norm | |||
Paketlänge in verschiedenen Netzen | |||
Token Ring32768 bit | Token Ring32768 bit | ||
Zeile 321: | Zeile 320: | ||
X.25 (Standard)1024 bit | X.25 (Standard)1024 bit | ||
== IP - Fragmentierung == | |||
Felder: DF, MF, Identifikation, Fragmentabstand | |||
kann nur bei DF=0 durchgeführt werden | kann nur bei DF=0 durchgeführt werden | ||
Zeile 333: | Zeile 332: | ||
Zielhost muss die Fragmente zusammensetzen | Zielhost muss die Fragmente zusammensetzen | ||
== Fragmentierung == | |||
Alle Fragmente haben dieselbe Kennung | |||
diese definiert keine Reihenfolge | diese definiert keine Reihenfolge | ||
Zu fragmentierende Pakete mit DF-Flag werden verworfen, da sie nicht in das nächste Netzwerk geleitet werden können | |||
Stationen, die nicht alle Fragmente eines IP-Datagrams innerhalb einer bestimmten Zeitspanne (i.d.R. 30-40s) zum Reassemblieren erhalten, verwerfen alle empfangenen Pakete | |||
== Fragment Offset == | |||
Gibt die Länge relativ in Byte zum Beginn des Datenbereichs im ursprünglichen Datagram an | |||
Ermöglicht dem Empfänger mehrere Fragmente in der richtigen Reihenfolge zusammenzusetzen | |||
Bei vollständigem Datagram (keine Fragmentierung) und beim ersten Fragment hat der Fragment Offset immer den Wert 0 | |||
== Fragment Offset (Grafik) == | |||
== IP - Fragmentierung: Beispiel == | |||
Netz1: MTU 1200Byte | |||
Netz2: MTU 532 Byte | |||
Netz3: MTU 276 Byte | |||
Paket mit Länge 1044Byte (= 20Byte Header + 1024Byte Daten) und nicht gesetztem DF-Bit soll über die 3 Netze übertragen werden | |||
Die Reihenfolge der Ankunft beim Zielhost spielt keine Rolle. | |||
Wenn nach Ablauf eines Timers nicht alle Teilpakete angekommen sind, wird das Paket verworfen. | |||
== IP - Fragmentierung: Beispiel - Paketlänge 1044 Byte == | |||
== Ausblick: IPv6 == | |||
Die Internet Engineering Task Force (IETF) hat eine neue IP-Version namens IPv6 entwickelt | |||
IPv6 hat eine Länge von 128 Bit = 2128 | |||
über 667 Billiarden IP-Adressen pro mm² Erde | |||
510 100 000 km2 Erdoberfläche | 510 100 000 km2 Erdoberfläche | ||
Verbesserte Sicherheit | |||
Verbesserte Header, um das Routing zu vereinfachen und zu beschleunigen | |||
Der Übergang von IPv4 zu IPv6 läuft fließend | |||
== IP Source Routing Option Paketformat == | |||
== IP Source Routing Funktionsweise == | |||
Der Sender nimmt die source route Liste von der Anwendung, und hängt die eigentliche Zieladresse an diese Liste an. | |||
Die Empfänger Adresse im IP Paket wird auf den ersten Eintrag in der Liste gesetzt | Die Empfänger Adresse im IP Paket wird auf den ersten Eintrag in der Liste gesetzt | ||
Zeile 398: | Zeile 397: | ||
Der Rest der Liste in die IP Source Routing Option geschrieben (max. 9 Eintäge!) | Der Rest der Liste in die IP Source Routing Option geschrieben (max. 9 Eintäge!) | ||
Ein Empfänger eines IP Paketes überprüft, ob die Liste vollständig abgearbeitet wurde. | |||
Wenn ja, dann ist er endgültiger Empfänger. | Wenn ja, dann ist er endgültiger Empfänger. | ||
Wenn nein, dann wird die IP Adresse auf die das pointer Feld zeigt als neue Empfänger Adresse in das IP Paket eingetragen. | Wenn nein, dann wird die IP Adresse auf die das pointer Feld zeigt als neue Empfänger Adresse in das IP Paket eingetragen. | ||
Die IP Adresse des Interfaces auf welches das IP Paket weitergeleitet wird, wird in das Feld geschrieben (auf die Position auf die das pointer Feld zeigt). | Die IP Adresse des Interfaces auf welches das IP Paket weitergeleitet wird, wird in das Feld geschrieben (auf die Position auf die das pointer Feld zeigt). | ||
Der Inhalt des pointer Feldes wird um 4 erhöht. | |||
== IP Source Routing Beispiel == | |||
== IP Source Routing Beispiel == | |||
== IP Source Routing Beispiel == | |||
IP Source Routing | |||
loose | |||
die Angegebenen IP Adressen müssen nicht benachbart sein | die Angegebenen IP Adressen müssen nicht benachbart sein | ||
strict | |||
die Angegebenen IP Adressen müssen benachbart sein, sonst wird das Paket verworfen und eine ICMP source route failed Nachricht an den Sender geschickt. | die Angegebenen IP Adressen müssen benachbart sein, sonst wird das Paket verworfen und eine ICMP source route failed Nachricht an den Sender geschickt. | ||
Source Routing ist nahezu überall abgeschaltet da es ein Sicherheitsrisiko darstellt - IP Spoofing! | |||
[[Kategorie:IPv4]] | [[Kategorie:IPv4]] | ||
= Wikipedia = | = Wikipedia = |
Version vom 1. Oktober 2022, 06:31 Uhr
topic kurze Beschreibung
Beschreibung
Installation
Syntax
Parameter
Optionen
Konfiguration
Dateien
Anwendung
Dokumentation
Man-Pages
Info-Pages
Links
Intern
Weblinks
Kontrollfragen
Testfrage 1
Testfrage 2
Testfrage 3
Testfrage 4
Testfrage 5
IPv4
Internet Protokoll Version 4
IP – Einordnung ins DoD-Modell
Exkurs: Bezeichnung der Daten im Protokoll-Stapel
Eigenschaften von IP
Grundlage des TCP/IP-Stapels (TCP/IP-Stack)
Teil der Netzwerkschicht des DoD-Modells (02)
Setzt auf Data Link Layer auf
Ethernetypfeld: 08-00
1977 entwickelt
In der Version 4 das Standard-Protokoll im Internet
Die Weiterentwicklung zur Version 6 ist abgeschlossen, aber noch wenig genutzt
Hardwareunabhängig
Die Adressierung ist nicht von der Netzwerktechnologie abhängig
Paketorientierter verbindungsloser Datagram-Dienst
freie Routenwahl
kein Verbindungsauf- oder abbau
Keine Fehlerkorrektur
IP - Aufgaben
Gewährleistung des Transports von Daten über heterogene Netzwerktopologien
Abstraktion von Besonderheiten des darunter liegenden Layers 2(z.B. Ethernet, Token Ring oder ATM)
Definition eines Adressschemas
Definition von Datagrammen
Datagram-Service
Unzuverlässig
Keine Auslieferungs-Garantie
Keine Fehlerfreiheits-Garantie
Routing zwischen Netzen
Fragmentierung / Reassemblierung von Datagrammen
Übermittlung der Daten vom Transport- zu Networklayer
Definition/ Adressierung höherer Protokolle
IP - Wichtige RFCs
RFC 791IP-Protokoll
RFC 815IP over X.25 Networks
RFC 894IP over Ethernet-Networks
RFC 948IP over 802.3 Networks
RFC 1051IP over Arcnet-Networks
RFC 1055IP over Serial Lines („SLIP“)
RFC 1088IP over Netbios Networks
RFC 1577IP over ATM Networks („Classical IP“)
Aufbau des IP-Headersdeutsch
IP-Header englisch
IP-Header im Detail 1 - Version und Länge
Version
Die Version des IP-Protokolls
Wir behandeln hier Version 4
Länge
Dieses Feld gibt die Länge des IP-Protokoll-Kopfes in 32-Bit-Worten an
Die minimale Länge beträgt 5 Worte, was auch der Normalfall ist
Vergrößerung durch Angabe von Optionen
XX IP-Header im Detail 2 - Servicetypen
Mit den Precedence-Bit (0-2) kann eine Priorität von 0 - 7 angegeben werden
Bit 3 – 6 haben folgende Bedeutung
1000 Minimize-delay
0100 Maximize throughput
0010 Maximize reliability
0001 Minimize monetary costs
0000 Normal service
Bit 7 ist reserviert (ohne Bedeutung)
Servicetypen werden nicht von allen Routern unterstützt
IP-Header im Detail 3 - Paketlänge und Identifikation
Paket-Länge
Die Länge des Paketes in Byte inklusive Protokoll-Kopf
16 Bit – Feld (Maximale Paketgröße = 65.535 Byte)
Identifikation
Eine eindeutige Identifikation (Zähler)
Diese Kennungen sollten sich nur nach längeren Zeitabständen wiederholen
um nicht mit verspäteten PDU in Konflikt zu kommen
Paketübertragung im Internet
IP-Header im Detail 4 - Lebenszeit (TTL = Time To Live)
Dieses Feld gibt an, wie lange das Paket maximal unterwegs sein darf
Das Problem
Beim Routen durch vermaschte Netze, können Datagramme/ Fragmente ziellos und unendlich lange kreisen
Das verbraucht Ressourcen und kann Netzwerke bis zum Stillstand belasten
Die Lösung
Jeder Knoten (Router) verringert diesen Wert um mindestens 1
Hält ein Router ein Paket länger als eine Sekunde, verringert er die TTL um 1 je weitere Sekunde
Bei Erreichen des Wertes „0“, wird Paket verworfen
IP-Header im Detail 5 - Sender- und Empfänger-Adressen
32-Bit IP-Adresse (IPv4), 128-Bit IP-Adresse (IPv6)
unabhängig von der zugrunde liegenden Netztechnologie
Das Internet-Protokoll definiert also eine rein logische Netztopologie
Die Vergabe der IP-Adressen wird international von der IANA (Internet Assigned Numbers Association) geregelt
die IANA verteilt die Organisation auf mehrere Unterorganisationen
Die in Europa zuständige Organisation ist das RIPE (Réseaux IP Européens)
IP-Header im Detail 6 - DF, MF und Fragmentabstand
DF (Don‘t Fragment)
0 = May Fragment
1 = Don‘t Fragment
MF (More Fragment)
0 = Last Fragment
1 = More Fragment
Fragmentabstand
Länge relativ zum Beginn des ursprünglichen Datagram
IP-Header im Detail 7 - Protokoll
Nummer des Transportprotokolls
Legt fest, welches Protokoll für die Weiterverarbeitung auf 03 zuständig ist (demultiplexing)
gemäß RFC 1700 (Assigned Numbers)
/etc/protocol
%SYSTEMROOT%\system32\drivers\etc\protocol
Ausgewählte IP-Protokollnummern
IP-Header im Detail 7 - Weitere Felder
Prüfsumme
wird über den gesamten IP Header berechnet
Berechnung beim Sender:
setze das checksum Feld auf 0
XOR über alle 16-bit Worte im Header
das Ergebnis wird bitweise invertiert und stellt dann den Wert für das checksum Feld dar.
Check beim Emfänger:
XOR über alle 16-bit Worte im Header (inkl. checksum)
OK, wenn im Ergebnis alle bits auf 1 stehen
Füllzeichen
Auffüllen des Headers auf ein Vielfaches von 32-Bit
Nutzdaten
Segmente und Datagramme höherer Protokolle
Meist TCP oder UDP
XX IP-Header im Detail 8 - Optionen
Flexible Erweiterbarkeit des Headers
Variable Länge (max. 40 Byte)
Folgende Optionen sind möglich
Source Routing
Liste von Routern, die ein Datagram durchlaufen soll
Der genommene Weg wird aufgezeichnet (max. 9 Hops)
loose: die Angegebenen IP Adressen müssen nicht benachbart sein
strict: die Angegebenen IP Adressen müssen benachbart sein
sonst wird das Paket verworfen und eine ICMP source route failed Nachricht an den Sender geschickt
Source Routing ist nahezu überall abgeschaltet da, es ein Sicherheitsrisiko darstellt - IP Spoofing!
Record Route
Router hängen ihre IP-Adresse an das Optionsfeld an
Zeitstempel
Zusätzlich zur IP-Adresse wird die Uhrzeit des Durchlaufes angehangen
Fragmentierung im Internet
Warum Fragmentierung?
Anpassung der Datagramgrösse an die MTU der lokalen Netz-Technologie
Definition des Protokolls / Beschränkung durch Norm
Paketlänge in verschiedenen Netzen
Token Ring32768 bit
Ethernet12144 bit
X.25 (Maximum)8192 bit
X.25 (Standard)1024 bit
IP - Fragmentierung
Felder: DF, MF, Identifikation, Fragmentabstand
kann nur bei DF=0 durchgeführt werden
wird von den Routern eigenständig vorgenommen
kann bei Bedarf wiederholt angewendet werden
Zielhost muss die Fragmente zusammensetzen
Fragmentierung
Alle Fragmente haben dieselbe Kennung
diese definiert keine Reihenfolge
Zu fragmentierende Pakete mit DF-Flag werden verworfen, da sie nicht in das nächste Netzwerk geleitet werden können
Stationen, die nicht alle Fragmente eines IP-Datagrams innerhalb einer bestimmten Zeitspanne (i.d.R. 30-40s) zum Reassemblieren erhalten, verwerfen alle empfangenen Pakete
Fragment Offset
Gibt die Länge relativ in Byte zum Beginn des Datenbereichs im ursprünglichen Datagram an
Ermöglicht dem Empfänger mehrere Fragmente in der richtigen Reihenfolge zusammenzusetzen
Bei vollständigem Datagram (keine Fragmentierung) und beim ersten Fragment hat der Fragment Offset immer den Wert 0
Fragment Offset (Grafik)
IP - Fragmentierung: Beispiel
Netz1: MTU 1200Byte
Netz2: MTU 532 Byte
Netz3: MTU 276 Byte
Paket mit Länge 1044Byte (= 20Byte Header + 1024Byte Daten) und nicht gesetztem DF-Bit soll über die 3 Netze übertragen werden
Die Reihenfolge der Ankunft beim Zielhost spielt keine Rolle.
Wenn nach Ablauf eines Timers nicht alle Teilpakete angekommen sind, wird das Paket verworfen.
IP - Fragmentierung: Beispiel - Paketlänge 1044 Byte
Ausblick: IPv6
Die Internet Engineering Task Force (IETF) hat eine neue IP-Version namens IPv6 entwickelt
IPv6 hat eine Länge von 128 Bit = 2128
über 667 Billiarden IP-Adressen pro mm² Erde
510 100 000 km2 Erdoberfläche
Verbesserte Sicherheit
Verbesserte Header, um das Routing zu vereinfachen und zu beschleunigen
Der Übergang von IPv4 zu IPv6 läuft fließend
IP Source Routing Option Paketformat
IP Source Routing Funktionsweise
Der Sender nimmt die source route Liste von der Anwendung, und hängt die eigentliche Zieladresse an diese Liste an.
Die Empfänger Adresse im IP Paket wird auf den ersten Eintrag in der Liste gesetzt
Der Rest der Liste in die IP Source Routing Option geschrieben (max. 9 Eintäge!)
Ein Empfänger eines IP Paketes überprüft, ob die Liste vollständig abgearbeitet wurde.
Wenn ja, dann ist er endgültiger Empfänger.
Wenn nein, dann wird die IP Adresse auf die das pointer Feld zeigt als neue Empfänger Adresse in das IP Paket eingetragen.
Die IP Adresse des Interfaces auf welches das IP Paket weitergeleitet wird, wird in das Feld geschrieben (auf die Position auf die das pointer Feld zeigt).
Der Inhalt des pointer Feldes wird um 4 erhöht.
IP Source Routing Beispiel
IP Source Routing Beispiel
IP Source Routing Beispiel
IP Source Routing
loose
die Angegebenen IP Adressen müssen nicht benachbart sein
strict
die Angegebenen IP Adressen müssen benachbart sein, sonst wird das Paket verworfen und eine ICMP source route failed Nachricht an den Sender geschickt.
Source Routing ist nahezu überall abgeschaltet da es ein Sicherheitsrisiko darstellt - IP Spoofing!
Wikipedia
Vorlage:Netzwerk-TCP-IP-Vermittlungsprotokoll 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 eine wichtige technische Grundlage des Internets. Es wurde in RFC 791 im Jahr 1981 definiert.
Geschichte
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.[1] 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.[2] 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.[3] 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.[4]
Adressformat
Die IP-Adresse kann in dezimal, binär, oktal und hexadezimal sowohl in der Punkt-, als auch in der Nichtpunktnotation dargestellt werden.
IPv4 benutzt 32-Bit-Adressen, daher können in einem Netz maximal 4.294.967.296 Adressen vergeben werden. IPv4-Adressen werden üblicherweise dezimal in vier Blöcken geschrieben, zum Beispiel 207.142.131.235. Ein- und zweistellige Zahlen dürfen hierbei nicht mit einer vorangestellten Ziffer 0 auf ein gleichförmiges Längenformat gebracht werden (eine führende 0 ist nach RFC nicht erlaubt, da sie häufig als Oktalzahl interpretiert wird). Jedes Oktett repräsentiert 8 Bit; somit ergibt sich für jedes Oktett ein Wertebereich von 0 bis 255. Bei der Weiterentwicklung IPv6 werden 128-Bit-Adressen verwendet.
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. Bei Verwendung dieser Maske würde die IP-Adresse in der CIDR-Notation dann als 192.168.0.23/24 geschrieben, wobei die „24“ bedeutet, dass die ersten 24 Bits der Subnetzmaske gleich 1 sind. Die Bits der Subnetzmaske, die „1“ sind, legen die Stellen der IP-Adresse fest, die zum Netzanteil gehören. Alle restlichen Stellen der IP-Adresse (entsprechend der Anzahl Bits der Maske die auf 0 gesetzt sind) gehören dann zum Hostanteil.
Beispiel:
dezimal | binär | ||||
IP-Adresse | 192.168.0 | .23 | → | 11000000.10101000.00000000 | .00010111 |
Subnetzmaske | 255.255.255 | .0 | → | 11111111.11111111.11111111 | .00000000 |
Netzanteil | Hostanteil | Netzanteil | Hostanteil |
Somit befinden sich mehrere Geräte in einem Teilnetz, wenn der Netzanteil ihrer Adresse gleich ist – das ist eine Voraussetzung, dass diese Geräte direkt miteinander kommunizieren können, beispielsweise über einen Hub, einen Switch oder mittels eines Crosslink-Kabels. Im selben Teilnetz darf kein Hostanteil mehrfach vergeben sein.
Für die Kommunikation zwischen unterschiedlichen Teilnetzen wird ein Router benötigt. Für jedes teilnehmende Gerät vergibt der zuständige Administrator den Hostanteil eindeutig. Den Netzanteil vergibt der Besitzer oder Planer des Netzwerks. Im Internet ist die IANA (Internet Assigned Numbers Authority) für die Vergabe der Netzanteile zuständig.
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) |
Früher gab es fest vorgeschriebene Einteilungen für Netzwerkklassen mit einer festen Länge. Da diese Einteilung sehr unflexibel ist, wird seit 1993 ausschließlich das Classless Inter-Domain Routing-Verfahren durchgeführt, welches bitvariable Netzmasken ermöglicht. Viele netzwerkfähige Betriebssysteme bestimmen die Standardnetzmaske anhand der alten Klassifikation, um dem einfachen Nutzer die Einrichtung des Netzwerks zu vereinfachen; Klassen sind jedoch heute nicht mehr in Gebrauch.
Die maximale Anzahl der zu vergebenen Host-Adressen in einem Netz ist
- 2Anzahl Bits der Hostadresse − 2
Zwei Host-Adressen sind gemäß einer Empfehlung in der RFC 950 reserviert – die erste Adresse (zum Beispiel 192.168.0.0) bezeichnet das Netz selbst, die letzte Adresse (zum Beispiel 192.168.0.255) ist für den Broadcast (alle Teilnehmer werden angesprochen) reserviert. Diese Einschränkung wird in der RFC 1878 aufgehoben, die sich jedoch nie durchsetzen konnte, sodass auch heute noch in praktisch jedem Netzwerk beide Adressen reserviert sind. Gängig ist außerdem, das Gateway (vgl. Routing) auf die erste oder die vorletzte IP-Adresse im Netz zu legen (z. B. 192.168.0.1 oder 192.168.0.254), wobei es dafür keinerlei Vorgaben gibt.
Besondere Netzwerkadressen
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 |
Lokale/Private Netzwerkadressen
Adressbereich | Beschreibung | größter CIDR-Block | Anzahl IP-Adressen |
---|---|---|---|
10.0.0.0–10.255.255.255 | privat, 1 8-Bit-Netz | 10.0.0.0/8 | 224 = 16.777.216 |
172.16.0.0–172.31.255.255 | privat, 16 16-Bit-Netze | 172.16.0.0/12 | 220 = 1.048.576 |
192.168.0.0–192.168.255.255 | privat, 1 16-Bit-Netz | 192.168.0.0/16 | 216 = 65.536 |
169.254.0.0–169.254.255.255 | link local, 1 16-Bit-Netz | 169.254.0.0/16 | 216 = 65.536 |
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 |
Subnetting
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 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.
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
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.[5] Gemäß einer Vereinbarung aus dem Jahr 2009[6] wurde am 3. Februar 2011 schließlich der verbliebene Adressraum gleichmäßig auf die regionalen Adressvergabestellen verteilt: jeweils ein /8-Adressblock pro Vergabestelle.[7][8] 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.[9] Am 14. September 2012 folgte dann RIPE NCC mit der letzten regulären Zuteilung in der Region Europa/Naher Osten.[10] 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.[11][12]
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.[13]
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.
Siehe auch
Weblinks
- RFC 791 – Internet Protocol
- L. Parziale et al.: TCP/IP Tutorial and Technical Overview (PDF; 8,1 MB) in IBM Redbooks, Armonk (NY, USA) 2006 (englisch)
- Subnetz-Rechner im Kapitel TCP/IP – Grundlagen Computernetze
- IANA IP Version Numbers – IANA assignment of version-numbers
Literatur
- 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, USA) 2000, ISBN 3-8266-4077-2.
Einzelnachweise
- ↑ Vorlage:RFC-Internet
- ↑ Vorlage:RFC-Internet
- ↑ Vorlage:RFC-Internet
- ↑ Vorlage:RFC-Internet
- ↑ Vorlage:Webarchiv APNIC, 1. Febr. 2011
- ↑ Global Policy for the Allocation of the Remaining IPv4 Address Space. ICANN
- ↑ WELT ONLINE: Alle Internetadressen weltweit sind aufgebraucht (3. Februar 2011)
- ↑ RIPE NCC Receives Final /8 of IPv4 Address Space from IANA (englisch).
- ↑ Vorlage:Webarchiv APNIC
- ↑ ripe.net
- ↑ Vorlage:Webarchiv APNIC, Abschnitt 3
- ↑ ripe.net, Abschnitt 5.6
- ↑