|
|
| Zeile 110: |
Zeile 110: |
|
| |
|
| [[Kategorie:Entwurf]] | | [[Kategorie:Entwurf]] |
|
| |
| = TMP =
| |
| == Version ==
| |
| * Version des IP-Protokolls
| |
| * 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
| |
|
| |
| == Servicetypen ==
| |
| [[File:ipServicetypes.png|200px]]
| |
|
| |
| Mit den Precedence-Bit (0-2) kann eine Priorität von 0 - 7 angegeben werden
| |
| * 1000 Minimize-delay
| |
| * 0100 Maximize throughput
| |
| * 0010 Maximize reliability
| |
| * 0001 Minimize monetary costs
| |
| * 0000 Normal service
| |
| * Bit 7 ohne Bedeutung (reserviert)
| |
| Servicetypen werden nicht von allen Routern unterstützt
| |
|
| |
| 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 (''[[DiffServ|differentiated services]]'') ersetzt, dessen erste sechs Bits als ''differentiated services code point'' (DSCP) und dessen letzte beiden Bits als ''[[Explicit Congestion Notification|explicit congestion notification]]'' (ECN) benutzt werden.
| |
|
| |
| == Paketlä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 ==
| |
|
| |
| == TTL ==
| |
| ; Time To Live
| |
| : Anzahl der Router, die ein IP-Datagramm passieren darf
| |
|
| |
| ; Problem
| |
| * Beim Routen durch vermaschte Netze, können Datagramme/ Fragmente ziellos und unendlich lange kreisen
| |
| * Die verbrauchten Ressourcen können ein Netzwerk bis zum Stillstand belasten
| |
|
| |
| ; 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
| |
|
| |
| == Sender- und Empfänger-Adressen ==
| |
| ; 32-Bit IP-Adresse (IPv4)
| |
|
| |
| ; 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)
| |
|
| |
| == 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
| |
|
| |
| == 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
| |
|
| |
| == 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
| |
|
| |
| == Nutzdaten ==
| |
| * Segmente und Datagramme höherer Protokolle
| |
| * Meist TCP oder UDP
| |
|
| |
| == Optionen ==
| |
| Erweiterbarkeit des Headers
| |
| * Variable Länge (max. 40 Byte)
| |
|
| |
| === 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 ===
| |
| IP-Adresse und Zeitpunkt des Durchlaufes werden aufgezeichnet
| |
|
| |
| == Füllzeichen ==
| |
| Auffüllen des Wortes auf 32-Bit
| |
|
| |
|
| [[Kategorie:IPv4]] | | [[Kategorie:IPv4]] |
topic kurze Beschreibung
Beschreibung
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.
- Ohne Optionen ist der IPv4-Header 20 Bytes lang
- Wortlänge 32 Bit (4 Byte)
- Daten im Feld Optionen können den Header auf maximal 60 Bytes (in 32-Bit-Worten) verlängern (selten)
- Im Typfeld des Ethernet-Frames wird für IPv4 080016 eingetragen
Dokumentation
RFC
Man-Pages
Info-Pages
Siehe auch
Links
Projekt-Homepage
Weblinks
Einzelnachweise
Testfragen