Internet Protocol Version 4: Unterschied zwischen den Versionen
KKeine Bearbeitungszusammenfassung |
|||
Zeile 39: | Zeile 39: | ||
</div> | </div> | ||
[[Kategorie: | [[Kategorie:Netzwerke:IPv4]] | ||
= TMP = | |||
'''IPv4''' | |||
Internet Protokoll Version 4 | |||
'''IP – Einordnung ins DoD-Modell''' | |||
'''ExkursBezeichnung der Daten im Protokoll-Stapel''' | |||
'''Eigenschaften von IP''' | |||
'''Grundlage des TCP/IP-Stapels (TCP/IP-Stack) ''' | |||
'''Teil der Netzwerkschicht des DoD-Modells (Layer 2)''' | |||
Setzt auf Data Link Layer auf | |||
Ethernetypfeld: 08-00 | |||
'''Um 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-Headerenglisch''' | |||
'''IP-Header im Detail 1Version 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''' | |||
'''IP-Header im Detail 2Servicetypen''' | |||
'''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)''' | |||
'''Leider werden die Servicetypen meist von kommerziellen Produkten nicht (vollständig) unterstützt''' | |||
'''IP-Header im Detail 3Paketlä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 4Lebenszeit (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 5Sender- 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 6DF, 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 Layer 3 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 | |||
'''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!''' | |||
= TMP = | = TMP = |
Version vom 9. März 2022, 22:48 Uhr
topic kurze Beschreibung
Beschreibung
Installation
Syntax
Parameter
Optionen
Konfiguration
Dateien
Anwendungen
Dokumentation
Man-Pages
Info-Pages
Links
Intern
Weblinks
Kontrollfragen
Testfrage 1
Testfrage 2
Testfrage 3
Testfrage 4
Testfrage 5
TMP
IPv4
Internet Protokoll Version 4
IP – Einordnung ins DoD-Modell
ExkursBezeichnung der Daten im Protokoll-Stapel
Eigenschaften von IP
Grundlage des TCP/IP-Stapels (TCP/IP-Stack)
Teil der Netzwerkschicht des DoD-Modells (Layer 2)
Setzt auf Data Link Layer auf
Ethernetypfeld: 08-00
Um 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-Headerenglisch
IP-Header im Detail 1Version 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
IP-Header im Detail 2Servicetypen
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)
Leider werden die Servicetypen meist von kommerziellen Produkten nicht (vollständig) unterstützt
IP-Header im Detail 3Paketlä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 4Lebenszeit (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 5Sender- 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 6DF, 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 Layer 3 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
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!
TMP
IP – Einordnung ins DoD-Modell
ExkursBezeichnung der Daten im Protokoll-Stapel
Eigenschaften von IP
Grundlage des TCP/IP-Stapels (TCP/IP-Stack)
Teil der Netzwerkschicht des DoD-Modells (Layer 2)
Um 1977 entwickelt
In der Version 4 das Standard-Protokoll im Internet
Hardwareunabhängig
Paketorientierter verbindungsloser Datagram-Dienst
Keine Fehlerkorrektur
IP - Aufgaben
Gewährleistung des Transports von Daten über heterogene Netzwerktopologien
Definition eines Adressschemas
Definition von Datagrammen
Datagram-Service
Routing zwischen Netzen
Fragmentierung / Reassemblierung von Datagrammen
Übermittlung der Daten vom Transport- zu Networklayer
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-Headerenglisch
IP-Header im Detail 1Version und Länge
Version
Die Version des IP-Protokolls
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
IP-Header im Detail 2Servicetypen
Mit den Precedence-Bit (0-2) kann eine Priorität von 0 - 7 angegeben werden
Bit 3 – 6 haben folgende Bedeutung
Bit 7 ist reserviert (ohne Bedeutung)
Leider werden die Servicetypen meist von kommerziellen Produkten nicht (vollständig) unterstützt
IP-Header im Detail 3Paketlä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
Paketübertragung im Internet
IP-Header im Detail 4Lebenszeit (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
IP-Header im Detail 5Sender- und Empfänger-Adressen
32-Bit IP-Adresse (IPv4), 128-Bit IP-Adresse (IPv6)
Das Internet-Protokoll definiert also eine rein logische Netztopologie
Die Vergabe der IP-Adressen wird international von der IANA (Internet Assigned Numbers Association) geregelt
IP-Header im Detail 6DF, 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 Layer 3 zuständig ist (demultiplexing)
gemäß RFC 1700 (Assigned Numbers)
Ausgewählte IP-Protokollnummern
IP-Header im Detail 7 Weitere Felder
Prüfsumme
wird über den gesamten IP Header berechnet
Berechnung beim Sender:
Check beim Emfänger:
Füllzeichen
Auffüllen des Headers auf ein Vielfaches von 32-Bit
Nutzdaten
Segmente und Datagramme höherer Protokolle
IP-Header im Detail 8 Optionen
Flexible Erweiterbarkeit des Headers
Variable Länge (max. 40 Byte)
Folgende Optionen sind möglich
Source Routing
Record Route
Zeitstempel
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
IP - Fragmentierung
Felder: DF, MF, Identifikation, Fragmentabstand
Fragmentierung
Alle Fragmente haben dieselbe Kennung
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
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.
Ein Empfänger eines IP Paketes überprüft, ob die Liste vollständig abgearbeitet wurde.
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
strict
Source Routing ist nahezu überall abgeschaltet da es ein Sicherheitsrisiko darstellt - IP Spoofing!