RFC 791 - Internet Protocol - Summary

RFC 791 wurde 1981 für die DARPA (Defense Advanced Research Projects Agency) des Instituts für Informationswissenschaften der Universität Südkalifornien geschrieben. Das Dokument ist in drei Abschnitte unterteilt, Einführung, Übersicht und Spezifikationen. Obwohl die Einführung und die Übersicht sehr gute Informationen haben, wird diese Zusammenfassung sich auf die Spezifikationen konzentrieren, aber sie wird aus der Übersicht herausstellen.

Kopf

Wie in den Frames und Packets Artikel auf dieser Seite sieht die IP-Header aus:

Header Details

Wie Sie sehen können, enthält das Datagram mehrere Elemente. Die Funktion für jedes Element ist:

• Version - RFC 791 bezieht sich speziell auf Version 4
• Internet Header Länge (IHL) - Informiert die zurückgebenden Systeme die Länge des Headers und wenn Daten beginnen
• Art des Dienstes (TOS) - Dieser 8-Bit-Wert wird für die Qualität des Dienstes verwendet.
  • bit 0-2 sind für Vorangegangene
    • 000 - Routine
    • 001 - Priorität
    • 010 - Sofort
    • 011 - Flash
    • 100 - Flash Override
    • 101 - CRITIC/ECP
    • 110 - Internetbedienung
    • 111 - Netzwerksteuerung
  • bit 3 ist für normale Verzögerung (0) oder niedrige Verzögerung (1)
  • bit 4 ist für Normaldurchsatz (0) oder Hochdurchsatz (1)
  • bit 5 ist für normale Zuverlässigkeit (0) oder hohe Zuverlässigkeit (1)
  • Als RFC 791 Bit 6 und 7 geschrieben wurde, wo für die zukünftige Nutzung reserviert
• Gesamtlänge - Ist die Gesamtlänge des Datengramms in Bytes bis zu 65535 Oktetten. Ein System muss jedoch mindestens 567 Oktette aufnehmen können.
• Identifikation - Wird in der Neumontage von fragmentierten Datengrammen verwendet
• Fahnen - verwendet mit Datagram Fragmentation
  • bit 0 ist reserviert und muss 0 sein
  • bit 1 wenn auf 0 gesetzt erlaubt, ein Datengramm zu trennen. Wenn auf 1 gesetzt, kann das Datengramm nicht fragmentiert werden
  • bit 2, wenn auf 0 gesetzt, die letzte Fragment. Wenn auf 1 gesetzt, kommen weitere Fragmente
• Fragment Offset - Erklärt die Systeme, die das Datagram Fragmentation durchführen, wo es Fragment
• Zeit zu leben - Indiziert, wie lange das Datengramm im Netzwerk bestehen kann. Wenn es 0 erreicht, muss das Datengramm verworfen werden
• Protokoll - Zeigt das nächste Level-Protokoll, das im Datagram verwendet wird
• Header Checksum - Validiert das Datengramm an jedem Punkt durch das Netzwerk
• Quelle Adresse - 32 Bit
• Zieladresse - 32 Bit
• Optionen - Es gibt viele IPv4-Optionen, die angewendet werden können oder nicht. Für weitere Details lesen Sie bitte die vollständige RFC-spezifische Seite 15 - 22
• Am Ende des Headers wird das Datengramm mit 0's gepolstert, bis es auf einem 32-Bit-Band endet

Zusammenfassung

Wie bei allen RFCs erfordert dieser RFC, dass jedes Indivdual, das das IP-Datengramm implementiert, mit dem Standard so ausrichten, dass jede Partei mit dem Datengramm auf verschiedenen Systemen interagieren kann. In Abschnitt 3 wird das IPv4-Adressierungsschema ausführlich diskutiert, wie die oben zusammengefassten Funktionen. In Bezug auf IPv4 definiert diese RFC Netzwerkgrößen der Klasse A, B und C. Klasse A gibt 7 Bits für Netzwerk und 24 Bit für Hosts an. Die Klasse B vergibt 14 Bit für Netzwerk und 16 Bit für Hosts. Die Klasse C vergibt 21 Bit für Netzwerk und 8 Bit für Hosts. Neben der Adressierung von Schemata werden im RFC die spezifischen Funktionen von Datagrammfragmentierung und Neumontage ausführlich diskutiert. Geben Sie an, dass einige Optionen enthalten sein können oder nicht, wenn ein Paket fragmentiert ist.

In Bezug auf die Implementierung des IP-Datagrams gibt die RFC auch Beispiele dafür, was den oberen Schichtprotokollen für Konfigurationselemente zur Erleichterung der Kommunikation und Konfiguration zwischen Systemen vorgelegt werden soll. Diese elemenets sind die gleichen Elemente, die zur Erstellung des Datengramms verwendet werden.