Internet Protocol version 4

Protocol Data Unit

To view this page you need an SVG viewer.
Feld 1: Version
Erlaubt die Unterscheidung und damit prinzipiell den parallelen Einsatz verschiedener IP Versionen. Diese Idee wurde jedoch bei der Entwicklung von IPv6 weitgehend ergänzt, durch die Definition eines eigenen Werts (0x86DD) für IPv6 im Type Feld (IANA: ethernet-numbers). Das war notwendig geworden, weil es IPv4 Implementierungen gibt, die aus Performancegründen, das Versionsfeld beim Empfang eines Pakets nicht untersuchen. Die Unterscheidung findet nun also schon im Data Link Layer statt. Folgende IP Versionsnummern wurden bisher definiert:
  1. Internet Protocol
  2. ST Datagram Mode
  3. SIP, SIPP, IPv6
  4. TP/IX
  5. PIP
  6. TUBA
Feld 2: Header Length
Gibt die Länge des IP Headers in 32 Bit Worten ( =4 Byte) an. Die Länge des IP-Headers ist meistens konstant 20 Byte bzw. 5*32 Bit. Wird allerdings das Option-Feld verwendet, verändert sich die IP-Header Länge um einen variablen - von der jeweiligen Option abhängigen - Wert. Darum ist das Header Length Feld nötig, um den so erweiterten Header vom Datenteil des IP Pakets unterscheiden zu können. Mit seinen vier Bit kann das Header Length Feld maximal eine Länge von 24-1 ( =15) darstellen; ein IP Header kann also nicht länger als 15*32 Bit ( =60 Byte) lang sein. Das ist mitunder der Grund warum z.B. die Option Record Route auf maximal 4 Hops beschränkt - und damit praktisch nutzlos ist.
Feld 3: Type of Service (ToS)
   0     1     2     3     4     5     6     7
+-----+-----+-----+-----+-----+-----+-----+-----+
|   PRECEDENCE    |  D  |  T  |  R  |  0  |  0  |
+-----+-----+-----+-----+-----+-----+-----+-----+
 

Die ersten drei Bit bilden zusammen das PRECEDENCE Feld und können die Reihenfolge beeinflussen, in der ein Router Pakete weiterleitet (Queueing). Die nächsten drei bzw. vier Bit (D, T, R, C) können die Wegewahl des Routers (Routing) beeinflussen, im Fall daß dieser über mehrere gleichwertige Routen zu einem Zielnetz verfügt. DiffServ (Differentiated Services) nutzt das ToS Feld für ähnliche Zwecke, aber auf unterschiedliche Art und Weise.

Ein Aprilscherz zur PRECEDENCE findet sich in der c't 7/1999, Seite 194: Surfen auf der Überholspur [ € ].

Anfänglich wurde das ToS Feld in RFC 791 (Internet Protocol, September 1981) definiert. Eine veränderte Nutzung wurde in RFC 1349 (Type of Service in the Internet Protocol Suite, Juli 1992) angeregt. Dort wurden verschiedenen IP Applikationen sinnvolle ToS Werte zugeordnet und die D,T,R-Bits um das Cost Bit ergänzt. Die Nutzung dieser Features blieb in der Praxis hinter den Erwartungen zurück und man suchte schließlich nach einer Möglichkeit diese acht Bits anderweitig zu nutzen. In RFC2474, 4.2.1, IP Precedence History and Evolution in Brief liest man dazu: Although early BBN IMPs implemented the Precedence feature, early commercial routers and UNIX IP forwarding code generally did not.

   0     1     2     3     4     5     6     7
+-----+-----+-----+-----+-----+-----+-----+-----+
|               DSCP                |    C U    |
+-----+-----+-----+-----+-----+-----+-----+-----+

  DSCP: differentiated services codepoint
  CU:   currently unused
 

DiffServ schließlich ist erstmals in RFC 2474 (Definition of the Differentiated Services Field in the IPv4 and IPv6 Headers, Dezember 1998) definiert. Hierbei werden nur die ersten sechs Bit (DSCP - Differentiated Services Code Point) des nun Differentiated Services (DS) genannten Felds verwendet. Weitere Informationen zu DiffServ findet man in einem White Paper von Juniper: Supporting Differentiated Service Classes in Large IP Networks und Cisco: DiffServ - The Scalable End-to-End QoS Model

   0     1     2     3     4     5     6     7
+-----+-----+-----+-----+-----+-----+-----+-----+
|          DS FIELD, DSCP           | ECN FIELD |
+-----+-----+-----+-----+-----+-----+-----+-----+

  DSCP: differentiated services codepoint
  ECN:  Explicit Congestion Notification
 

1999 wurde dann mit dem RFC 2481 (A Proposal to add ECN to IP, Januar 1999) ein erster Vorschlag unterbreitet, die letzten zwei Bits (6, 7) für einen Early Congestion Notification Mechanismus zu nutzen. Mit dem RFC 3168 (The Addition of ECN to IP, September 2001) wurde diese Methode zum offiziellen Standard. Mehr Informationen zum Thema ECN findet man in ECN in TCP/IP von Sally Floyd.

Feld 4: Total Length

Kennzeichnet die Länge des gesamten IP Pakets, also Header plus Daten. Mit seinen sechzehn Bit kann das Total Length Feld eine maximale IP Paketlänge von 216-1 ( =65.535) Bytes darstellen; das ist somit die maximale IP Paketgröße.

Ethernet Frames mußten zwecks Kollisionserkennung in shared media Umgebungen mindestens 64 Byte lang sein. Der Payload eines solchen Frames muß demnach mindestens 46 Byte lang sein. Es gibt jedoch PDUs mit geringerer Länge, z.B. ARP Nachrichten. Um hier die geforderte Mindestlänge einzuhalten werden an das Ende der ARPDU so viele (mehr oder minder zufällige) Auffüllbits angefügt - das sogenannte Padding, bis die minimale Framelänge erreicht ist. IEEE-konforme Ethernet Frames kennzeichnen das Ende des eigentlichen Payloads und den Beginn des Padding mit Hilfe des Längenfelds im Frame-Header. Ethernet II Frames bieten diesen Service nicht. Deswegen muß jedes PDU, das in einem Ethernet II Frame enkapsuliert wird, selbst die Information über seine Länge, in irgendeiner Form, tragen.

Bei IP wird diese Aufgabe dediziert vom TL-Feld übernommen, welches die Länge des IP Headers und der Nutzdaten zusammenfaßt, aber eben die Padding Bytes ausläßt.

Feld 5: Identification

Ermöglicht die Zuordnung von Fragmenten zu einem Paket. Die Vergabe der ID erfolgt i.d.R. durch eine höhere Schicht (z.B. TCP) und wird als Parameter an IP übergeben.

Selbst mit einem so 'langweiligen' Feld, kann man aber einige interessante Dinge anstellen:

Feld 6: Flags
          0   1   2
        +---+---+---+
        |   | D | M |
        | 0 | F | F |
        +---+---+---+
 

Bit 0: reserved, must be zero
Bit 1: (DF) 0 = Paket darf fragmentiert werden, 1 = Paket darf nicht fragmentiert werden.
Bit 2: (MF) 0 = dieses Fragment bildet das Ende einer Fragmentreihe, 1 = dieses Fragment hat einen Nachfolger.

Feld 7: Fragment Offset
Das Fragment Offset gibt die Position eines Fragments in Relation zum Anfang des ursprünglichen (unfragmentierten) Pakets an. Mit Hilfe des Fragment Offset kann der Empfänger alle zu einem Paket gehörenden Fragmente (identifizierbar durch den gemeinsamen Wert im Identification Feld) in die richtige Reihenfolge setzen um daraus das ursprüngliche Paket zurück zu gewinnen. Da das Fragment Offset 13 Bit lang ist und jede Einheit 8 Byte darstellt, können IP Pakete jeglicher Größe fragmentiert werden: 213 * 8 Byte = 8192 * 8 = 65536 = max. Total Length
Feld 8: Time to Live (TTL)
Werte: min=0, max=255 (Einheit: 'Sekunden') Ein Zählerfeld das pro passiertem Router um mind. 1 dekrementiert wird. Empfängt ein Router ein Paket mit einer TTL=1, verwirft er es.
Feld 9: Protocol
In IPv4 kennzeichnet dieses Feld das nach dem IP Header folgende, nächsthöhere Protokoll. Die zugewiesenen Protokollnummern werden von der IANA verwaltet.
Feld 10: Header Checksum
Enthält eine Prüfsumme, die nur den IP Header auf Fehler überprüft. Wird ein Paket geroutet, verändert sich die TTL und die Header Checksum muß neu berechnet werden.
Feld 11: Source Address
Wird durch Router nicht verändert
Feld 12: Destination Address
optionales Feld 13: Options
Feldlänge: variabel, Standard = 0 Bit IP unterstützt verschiedene Optionen Routenaufzeichnung (record route) Routenbestimmung (strict source routing, loose source routing) Zeitstempel (time stamp)
optionales Feld 14: Padding
Feldlänge: variabel Werte: 0 Wird dem Option Feld angefügt um eine Länge von 32 Bit zu gewährleisten