Um jemanden Daten über digitale Netzwerke zu senden, brauchen Sie ebenso wie beim Brief­ver­sand die richtige Adresse – in diesem Fall al­ler­dings eine IP-Adresse. So werden die Da­ten­pa­ke­te mit einer IP-Adresse versehen – genau so, wie man Brief­um­schlä­ge mit einer Post­an­schrift aus­zeich­net, damit der Brief den Empfänger erreicht. Anders als Post­adres­sen sind ihre digitalen Pendants al­ler­dings nicht an einen be­stimm­ten Ort gebunden, sondern werden dem Netz­werk­ge­rät beim Ver­bin­dungs­auf­bau au­to­ma­tisch oder manuell zu­ge­wie­sen. Bei diesem Prozess spielt das so­ge­nann­te Internet Protocol (im Deutschen oftmals auch als IP-Protokoll betitelt) eine wichtige Rolle.

KI-Assistent kostenlos – Ihr smarter All­tags­hel­fer
  • DSGVO-konform & sicher gehostet in Deutsch­land
  • Pro­duk­ti­vi­tät steigern – weniger Aufwand, mehr Output
  • Direkt im Browser starten – ohne In­stal­la­ti­on
De­fi­ni­ti­on Internet Protocol

Das Internet Protocol, kurz IP, ist das primäre Protokoll der In­ter­net­pro­to­koll­fa­mi­lie und damit von ele­men­ta­rer Bedeutung für den Nach­rich­ten­aus­tausch in Com­pu­ter­netz­wer­ken. Das ver­bin­dungs­lo­se Protokoll, das 1974 vom Institute of Elec­tri­cal and Elec­tro­nics Engineers (IEEE) ver­öf­fent­licht und in RFC 791 als Standard spe­zi­fi­ziert wurde, soll in erster Linie den er­folg­rei­chen Pa­ket­ver­sand vom Absender zum Adres­sa­ten ge­währ­leis­ten. Zu diesem Zweck gibt das Internet Protocol ein Format vor, das die Art der Be­schrei­bung dieser Da­ten­pa­ke­te (auch IP-Da­ta­gram­me genannt) definiert.

Internet Protocol: De­fi­ni­ti­on und Ge­schich­te

Das Internet Protocol (IP) ist ein ver­bin­dungs­lo­ses Protokoll, das als wichtiger Be­stand­teil der In­ter­net­pro­to­koll­fa­mi­lie – einer Sammlung von rund 500 Netz­werk­pro­to­kol­len – für die Adres­sie­rung und Frag­men­tie­rung von Da­ten­pa­ke­ten in digitalen Netz­wer­ken ver­ant­wort­lich ist. Gemeinsam mit dem Trans­port­pro­to­koll TCP (Trans­mis­si­on Control Protocol) bildet IP die Grundlage des Internets. Um ein Paket vom Absender zum Adres­sa­ten zu senden, definiert das Internet Protocol eine Pa­ket­struk­tur, die die zu ver­schi­cken­den Daten zu­sam­men­fasst. So legt das Protokoll fest, auf welche Art und Weise In­for­ma­tio­nen über Quelle und Ziel der Daten be­schrie­ben werden, und trennt diese In­for­ma­tio­nen im IP-Header von den ei­gent­li­chen Nutzdaten. Ein solches Pa­ket­for­mat wird auch als IP-Datagramm be­zeich­net.

1974 ver­öf­fent­lich­te das Institute of Elec­tri­cal and Elec­tro­nics Engineers (IEEE) eine For­schungs­ar­beit der ame­ri­ka­ni­schen In­for­ma­ti­ker Robert Kahn und Vint Cerf, die ein Protokoll-Modell für die ge­gen­sei­ti­ge Paket-Netz­ver­bin­dung auf der Basis des Internet-Vor­gän­gers ARPANET beschrieb. Haupt­kom­po­nen­te dieses Modells war neben dem Über­tra­gungs­kon­troll­pro­to­koll TCP erstmals auch das IP-Protocol, das – zuzüglich einer spe­zi­el­len Abs­trak­ti­ons­schicht – die Kom­mu­ni­ka­ti­on über ver­schie­de­ne phy­si­ka­li­sche Netze hinweg erlaubte. In der Folgezeit wurden immer mehr For­schungs­netz­wer­ke auf Basis dieser als „TCP/IP“ be­zeich­ne­ten Pro­to­koll­kom­bi­na­ti­on zu­sam­men­ge­schlos­sen, die 1981 endgültig im RFC 791 als Standard spe­zi­fi­ziert wurde.

IPv4 und IPv6: Das steckt hinter den un­ter­schied­li­chen Ver­si­ons­num­mern

Wer sich in der heutigen Zeit mit der Be­schaf­fen­heit einer solchen IP-Adresse aus­ein­an­der­setzt, um bei­spiels­wei­se Rechner im lokalen Netzwerk adres­sier­bar zu machen, stößt auf die zwei Varianten IPv4 und IPv6. Dabei handelt es sich jedoch kei­nes­wegs um die vierte bzw. sechste Ge­ne­ra­ti­on des IP-Pro­to­kolls, auch wenn dieses in der Ver­gan­gen­heit um­fas­sen­de Ver­än­de­run­gen erlebt hat. Bei IPv4 handelt es sich nämlich de facto sogar um die erste of­fi­zi­el­le Version des Internet Protocol, während die Ver­si­ons­num­mer einzig aus dem Umstand re­sul­tiert, dass die vierte Ausgabe des TCP-Pro­to­kolls genutzt wird. IPv6 ist wiederum der direkte Nach­fol­ger von IPv4 – die Ent­wick­lung des Pro­to­kolls IPv5 wurde aus öko­no­mi­schen Gründen vorzeitig ein­ge­stellt. Auch wenn es neben IPv4 und IPv6 keine weiteren Versions-Releases gibt, so ist das Internet Protocol wie bereits erwähnt seit 1974 (als es noch nicht ei­gen­stän­dig exis­tier­te und Be­stand­teil von TCP war) dennoch über­ar­bei­tet worden. Im We­sent­li­chen kon­zen­trier­te man sich dabei darauf, den Ver­bin­dungs­auf­bau und die Adres­sie­rung zu op­ti­mie­ren. So hob man bei­spiels­wei­se schon früh die Bit-Länge der Host-Adressen von 16 auf 32 Bit an, wodurch der Adress­raum auf rund vier Mil­li­ar­den mögliche Vertreter aus­ge­wei­tet wurde. Das zu­kunfts­wei­sen­de IPv6 lässt mit seinen 128-Bit-Adress­fel­dern sogar ca. 340 Sex­til­lio­nen – eine Zahl mit 37 Nullen – ver­schie­de­ne Adressen zu, womit der Bedarf an In­ter­net­adres­sen lang­fris­tig gedeckt ist.

So ist der IP-Header eines Da­ta­gramms aufgebaut

Wie bereits erwähnt, sorgt das Internet Protocol dafür, dass jedem Da­ten­pa­ket die wichtigen struk­tu­rel­len Ei­gen­schaf­ten in der Kopfzeile vor­an­ge­stellt und dem passenden Trans­port­pro­to­koll (ty­pi­scher­wei­se TCP) zu­ge­ord­net werden. Der Kopf­da­ten­be­reich wurde für Version 6 grund­le­gend über­ar­bei­tet, weshalb man zwischen dem IPv4- und dem IPv6-Header un­ter­schei­den muss.

Aufbau des IPv4-Headers

Jeder IP-Header beginnt also immer mit einer 4 Bit langen Angabe der Ver­si­ons­num­mer des Internet Protocols – IPv4 oder IPv6. Es folgen weitere 4 Bits, die In­for­ma­tio­nen über die Länge der Kopfzeile (IP Header Length) enthalten, da diese nicht konstant ist. Die Ge­samt­län­ge errechnet sich dabei immer aus diesem Wert mul­ti­pli­ziert mit 32 Bit. Der kleinst­mög­li­che Wert 5 steht also für eine Header-Länge von 160 Bit (ent­spricht 20 Byte). In diesem Fall sind keinerlei Optionen hin­zu­ge­fügt. Das Maximum ist der Wert 15 bzw. 480 Bit (ent­spricht 60 Byte). Die Bits 8 bis 15 (Type of Service) können An­wei­sun­gen zur Be­hand­lung und Priorität des Da­ta­gramms be­inhal­ten. Hier kann der Host also bei­spiels­wei­se angeben, wie wichtig ihm Punkte wie Zu­ver­läs­sig­keit, Durchsatz und Ver­zö­ge­rung bei der Da­ten­über­tra­gung sind. Die Ge­samt­län­ge gibt an, wie groß das Da­ten­pa­ket insgesamt ist, addiert mit anderen Worten also die Größe der Nutzdaten zur Header-Länge. Da das Feld eine Länge von 16 Bit hat, liegt die maximale Grenze bei 65.635 Byte. Im RFC 791 ist ferner fest­ge­legt, dass jeder Host in der Lage sein muss, min­des­tens 576 Bytes zu ver­ar­bei­ten. Ein IP-Datagramm kann auf dem Weg zum Zielhost von Routern und anderen Geräten nach Belieben frag­men­tiert werden, wobei die Fragmente jedoch nicht kleiner als die genannten 576 Bytes werden sollten. Die weiteren Felder des IPv4-Kopfes haben folgende Bedeutung:

  • Iden­ti­fi­ka­ti­on: Alle Fragmente eines Da­ta­gramms verfügen über die gleiche Iden­ti­fi­ka­ti­ons­num­mer, die sie vom Absender erhalten. Per Abgleich dieses 16-Bit-Feldes kann der Zielhost einzelne Fragmente also einem be­stimm­ten Datagramm zuweisen.
  • Flags: Jeder IP-Header enthält 3 Flag-Bits, die In­for­ma­tio­nen und Richt­li­ni­en zur Frag­men­tie­rung enthalten. Das erste Bit ist dabei re­ser­viert und hat immer den Wert 0. Das zweite Bit namens „Dont Fragment“ verrät, ob das Paket frag­men­tiert werden darf (0) oder nicht (1). Das letzte, so­ge­nann­te „More Fragments“-Bit gibt darüber Auf­schluss, ob weitere Fragmente folgen (1) oder ob das Paket voll­stän­dig oder mit dem aktuellen Fragment ab­ge­schlos­sen ist (0).
  • Fragment-Versatz: Dieses Feld in­for­miert den Zielhost darüber, an welche Stelle ein einzelnes Fragment gehört, sodass dieser das gesamte Datagramm wieder pro­blem­los zu­sam­men­set­zen kann. Die Länge von 13 Bit bedeutet, dass ein Datagramm maximal in 8192 Fragmente zerteilt werden kann.
  • Le­bens­dau­er (Time to Live, TTL): Damit ein Paket im Netzwerk nicht eine un­be­grenz­te Zeit lang von Knoten zu Knoten wandern kann, wird es beim Ver­schi­cken mit einer maximalen Le­bens­dau­er, der Time to Live, versehen. Der RFC-Standard sieht für dieses 8-Bit-Feld die Einheit Sekunden vor, die maximale Le­bens­dau­er beträgt 255 Sekunden. Für jeden pas­sier­ten Netz­werk­kno­ten wird die TTL um min­des­tens 1 ver­rin­gert. Wird der Wert 0 erreicht, wird das Da­ten­pa­ket au­to­ma­tisch verworfen.
  • Protokoll: Das Protokoll-Feld (8 Bit) weist dem Da­ten­pa­ket das jeweilige Trans­port­pro­to­koll zu – bei­spiels­wei­se stehen der Wert 6 für TCP oder der Wert 17 für das UDP-Protokoll. Die of­fi­zi­el­le Liste aller möglichen Pro­to­kol­le wird seit 2002 von der IANA (Internet Assigned Numbers Authority) geführt und gepflegt.
  • Header-Prüfsumme: Das 16 Bit breite „Checksum“-Feld enthält die Prüfsumme für den Header. Diese muss, aufgrund der schwin­den­den TTL pro Zwi­schen­halt, bei jedem Netz­werk­kno­ten neu berechnet werden. Die Kor­rekt­heit der Nutzdaten wird aus Gründen der Effizienz nicht ve­ri­fi­ziert.
  • Quell- und Ziel­adres­se: Je 32 Bit, also 4 Byte sind für die zu­ge­wie­se­ne IP-Adresse von Ausgangs- und Zielhost re­ser­viert. Ge­schrie­ben werden diese IP-Adressen üb­li­cher­wei­se in Form von 4 durch Punkte ge­trenn­ten De­zi­mal­zah­len. Die nied­rigs­te Adresse ist dabei 0.0.0.0, die höchste 255.255.255.255.
  • Optionen: Das Optionen-Feld erweitert das IP-Protokoll um Zu­satz­in­for­ma­tio­nen, die im Stan­dard­de­sign nicht vor­ge­se­hen sind. Da es sich hierbei lediglich um optionale Er­gän­zun­gen handelt, hat das Feld eine variable Länge, die allein durch die maximale Header-Länge begrenzt ist. Zu den möglichen Optionen zählen zum Beispiel „Security“ (kenn­zeich­net, wie geheim ein Da­ten­gramm ist), „Record Route“ (weist alle pas­sier­ten Netz­werk­kno­ten an, ihre IP-Adresse an­zu­hän­gen, um die Paket-Route nach­voll­zie­hen zu können) und „Time Stamp“ (fügt zu­sätz­lich den Zeitpunkt hinzu, zu dem ein be­stimm­ter Knoten passiert wurde).

Aufbau des IPv6-Headers

Der Kopf­da­ten­be­reich des IPv6-Pro­to­kolls hat im Gegensatz zu dem Header seines Vor­gän­gers eine feste Größe von 320 Bit (40 Bytes). Separat können – zwischen dem Standard-Header und den Nutzdaten – zu­sätz­li­che, seltener benötigte In­for­ma­tio­nen angehängt werden. Diese Er­wei­te­rungs-Kopf­zei­len (Extension Header) sind mit dem Op­ti­ons­feld des IPv4-Pro­to­kolls zu ver­glei­chen und können jederzeit angepasst werden, ohne den ei­gent­li­chen Header verändern zu müssen. Unter anderem lassen sich auf diese Weise Paket-Routen bestimmen, Frag­men­tie­rungs­in­for­ma­tio­nen angeben oder die ver­schlüs­sel­te Kom­mu­ni­ka­ti­on via IPSec in die Wege leiten. Eine Header-Prüfsumme existiert – unter anderem zugunsten der Per­for­mance – nicht. Der ei­gent­li­che IP-Header beginnt, wie auch bei IPv4, mit der 4 Bit langen Ver­si­ons­num­mer des Internet Protocols. Das nach­fol­gen­de Feld „Traffic Class“ ist mit dem „Type of Service”-Eintrag in der älteren Pro­to­koll­va­ri­an­te gleich­zu­set­zen. Diese 8 Bit in­for­mie­ren den Zielhost also wie in der Vor­gän­ger­ver­si­on über die qua­li­ta­ti­ve Ver­ar­bei­tung des Da­ten­gramms, wobei sogar dieselben Regeln gelten. Neu in IPv6 ist das Flow Label (20 Bit), mit dessen Hilfe es möglich ist, Da­ten­strö­me aus zu­sam­men­hän­gen­den Da­ten­pa­ke­ten zu iden­ti­fi­zie­ren, um Band­brei­te zu re­ser­vie­ren und das Routing zu op­ti­mie­ren. Die folgende Auf­lis­tung erläutert die weiteren Header-In­for­ma­tio­nen des ver­bes­ser­ten IP-Pro­to­kolls:

  • Nutz­da­ten­grö­ße: IPv6 über­mit­telt einen Wert für die Größe der trans­por­tier­ten Nutzdaten inklusive der Extension Header (insgesamt 16 Bit). In der Vor­gän­ger­ver­si­on musste dieser Wert separat aus der Ge­samt­län­ge abzüglich der Kopf­zei­len­län­ge errechnet werden.
  • Next Header: Das 8 Bit lange „Next Header“-Feld ist das Pendant zu der Protokoll-Angabe in IPv4 und hat als solches auch dessen Funktion über­nom­men – die Zuordnung des ge­wünsch­ten Trans­port­pro­to­kolls.
  • Hop-Limit: Das Hop-Limit (8 Bit) definiert die maximale Zahl an Zwi­schen­sta­tio­nen, die ein Paket durch­lau­fen darf, bevor es verworfen wird. Wie bei der TTL in IPv4 wird der Wert mit jedem Knoten um min­des­tens 1 ver­rin­gert.
  • Quell- und Ziel­adres­se: Den größten Teil des IPv6-Headers nehmen die Adressen von Absender und Adressat ein. Wie eingangs bereits kurz erwähnt, haben diese eine Länge von 128 Bit (das Vierfache von IPv4-Adressen). Auch hin­sicht­lich der üblichen Notation gibt es deutliche Un­ter­schie­de. Die jüngere Version des Internet Protocols greift auf He­xa­de­zi­mal­zah­len zurück und un­ter­teilt diese in 8 Blöcke mit jeweils 16 Bit. Für die Trennung werden Dop­pel­punk­te statt einfacher Punkte verwendet. So sieht eine voll­stän­di­ge IPv6-Adresse in etwa fol­gen­der­ma­ßen aus: 2001:0db8:85a3:08d3:1319:8a2e:0370:7344.

Wie funk­tio­niert die Internet-Protocol-Adress­ver­ga­be?

Damit die Da­ta­gram­me in ihrem Header die ele­men­ta­re Angabe von Ausgangs- und Ziel­adres­se überhaupt vornehmen können, müssen selbige zunächst an die Netz­werk­teil­neh­mer vergeben werden. Dabei gilt es tra­di­tio­nell, zwischen internen und externen bzw. öf­fent­li­chen IP-Adressen zu un­ter­schei­den. Für erstere, die der Kom­mu­ni­ka­ti­on in lokalen Netz­wer­ken dienen, sind drei Adress­be­rei­che re­ser­viert:

  • 10.0.0.0 bis 10.255.255.255
  • 172.16.0.0 bis 172.31.255.255
  • 192.168.0.0 bis 192.168.255.255

Für IPv6-Netzwerke ist das Präfix „fc00::/7“ vor­ge­se­hen. Adressen dieser Bereiche werden im Internet nicht geroutet und können daher in privaten Netzen oder Fir­men­netz­wer­ken frei aus­ge­wählt und genutzt werden. Die Zuordnung einer Adresse gelingt entweder per manueller Eingabe oder findet au­to­ma­tisch statt, sobald sich ein Gerät mit dem Netzwerk verbindet – sofern die au­to­ma­ti­sche Adress­zu­ord­nung aktiviert und ein DHCP-Server im Einsatz ist. Mithilfe einer Sub­netz­mas­ke kann ein solches lokales Netzwerk darüber hinaus wahlweise in weitere Bereiche seg­men­tiert werden. Externe IP-Adressen werden Routern au­to­ma­tisch vom je­wei­li­gen In­ter­net­pro­vi­der vergeben, wenn diese sich mit dem Internet verbinden. Alle Geräte, die über einen ge­mein­sa­men Router im Internet unterwegs sind, greifen dem­entspre­chend auf dieselbe externe IP zurück. Üb­li­cher­wei­se vergeben die Provider alle 24 Stunden eine neue In­ter­net­adres­se aus einem Adress­be­reich, der ihnen wiederum von der IANA zugeteilt wurde. Das gilt auch für das quasi un­er­schöpf­li­che Arsenal von IPv6-Adressen, das nur teilweise für die normale Nutzung frei­ge­ge­ben ist. Ferner wird es nicht nur in private und öf­fent­li­che Adressen un­ter­teilt, sondern zeichnet sich durch we­sent­lich viel­sei­ti­ge­re Ein­stu­fungs­mög­lich­kei­ten in so­ge­nann­te Gül­tig­keits­be­rei­che (Address Scopes) aus:

  • Host-Scope: Die als Loopback be­zeich­ne­te Adresse 0:0:0:0:0:0:0:1 kann ein Host dazu nutzen, um IPv6-Da­ta­gram­me an sich selbst zu ver­schi­cken.
  • Link-Local-Scope: Für die IPv6-Kon­nek­ti­vi­tät ist es von ele­men­ta­rer Bedeutung, dass jeder Host über eine eigene Adresse verfügt, selbst wenn diese nur in einem lokalen Netzwerk gültig ist. Diese Link-Local-Adresse ist durch das Präfix „fe80::/10“ ge­kenn­zeich­net und wird bei­spiels­wei­se für die Kom­mu­ni­ka­ti­on mit dem Standard-Gateway (Router) benötigt, um eine öf­fent­li­che IP-Adresse ge­ne­rie­ren zu können.
  • Unique-Local-Scope: Hierbei handelt es sich um den bereits the­ma­ti­sier­ten Adress­be­reich „fc00::/7“, der aus­schließ­lich für die Kon­fi­gu­ra­ti­on lokaler Netzwerke vor­be­hal­ten ist.
  • Site-Local-Scope: Der Site-Local-Scope ist ein mitt­ler­wei­le ver­al­te­ter Adress­be­reich mit dem Präfix „fec0::/10“, der ebenfalls für lokale Netzwerke definiert wurde. Beim Zu­sam­men­schluss ver­schie­de­ner Netzwerke oder bei der Her­stel­lung von VPN-Ver­bin­dun­gen zwischen Netzen, die mit Site-Local-Adressen num­me­riert waren, kam es jedoch zu Kom­pli­ka­tio­nen, weshalb der Standard als überholt ein­ge­stuft wurde.
  • Global-Scope: Jeder Host, der Ver­bin­dung mit dem Internet aufbauen möchte, benötigt min­des­tens eine eigene, öf­fent­li­che Adresse. Diese bezieht er per Au­to­kon­fi­gu­ra­ti­on, wobei er entweder auf das SLAAC (zu­stands­lo­se Adress­kon­fi­gu­ra­ti­on) oder auf DHCPv6 (zu­stands­ori­en­tier­te Adress­kon­fi­gu­ra­ti­on) zu­rück­greift.
  • Multicast-Scope: Netz­werk­kno­ten, Router, Server und andere Netz­werk­diens­te können mit IPv6 in Multicast-Gruppen zu­sam­men­ge­fasst werden. Jede dieser Gruppen verfügt über eine eigene Adresse, wodurch sich mit einem einzigen Paket alle in­vol­vier­ten Hosts erreichen lassen. Das Präfix „ff00::/8“ gibt an, dass eine Multicast-Adresse folgt.

Immer wenn ein Da­ten­pa­ket via TCP/IP ver­schickt werden soll, findet au­to­ma­tisch eine Über­prü­fung der Ge­samt­grö­ße statt. Liegt diese über der Maximum Trans­mis­si­on Unit (dt. maximale Über­tra­gungs­ein­heit) der je­wei­li­gen Netz­werk­schnitt­stel­le, werden die In­for­ma­tio­nen frag­men­tiert, also in kleinere Da­ten­blö­cke zerlegt. Diese Aufgabe übernimmt entweder der sendende Host (IPv6) oder ein zwi­schen­ge­schal­te­ter Router (IPv4). Stan­dard­mä­ßig wird das Paket vom Empfänger zu­sam­men­ge­setzt, wofür dieser auf die im IP-Header bzw. im Extension-Header hin­ter­leg­ten Frag­men­tie­rungs­in­for­ma­tio­nen zu­rück­greift. In Aus­nah­me­fäl­len kann das Re­as­sembling (dt. Wieder-Zu­sam­men­set­zen) auch von einer Firewall über­nom­men werden, insofern diese ent­spre­chend kon­fi­gu­riert ist.

Da IPv6 die Frag­men­tie­rung im All­ge­mei­nen nicht mehr vorsieht und die Frag­men­tie­rung durch Router nicht mehr erlaubt, muss das IP-Paket bereits vor dem Ver­schi­cken eine an­ge­mes­se­ne Größe haben. Erreichen einen Router IPv6-Da­ta­gram­me, die über der Maximum Trans­mis­si­on Unit liegen, verwirft er diese und in­for­miert den Absender in Form einer ICMPv6-Nachricht des Typs 2 „Packet Too Big“ (dt. Paket [ist] zu groß). Die da­ten­ver­schi­cken­de Anwendung kann nun entweder kleinere, nicht frag­men­tier­te Pakete erstellen oder eine Frag­men­tie­rung in die Wege leiten. An­schlie­ßend wird dem IP-Paket der passende Extension-Header hin­zu­ge­fügt, damit der Zielhost die einzelnen Fragmente nach dem Empfang auch wieder zu­sam­men­set­zen kann.

Zum Hauptmenü