rfc·explained

RFC 791 · · Internet Standard

IPv4, der Umschlag, in dem jedes Paket reist.

Der offizielle Titel lautet "Internet Protocol." Worüber der RFC wirklich entscheidet: das Format jedes Pakets, das durchs Internet reist, wo die Adressen stehen und was ein Router unterwegs damit machen darf.

Status
✓ Weiterhin gültig
Auch bekannt als
STD 5
Ersetzt
RFC 760
Aktualisiert durch
RFC 1349, RFC 2474, RFC 6864

Geschrieben von Noel Lang · IT-Trainer

Kurzfassung

RFC 791 ist die Spezifikation für IPv4, das Format fast jedes Pakets im Internet. Er definiert die 32-Bit-Adresse, den Paket-Header (Datagramm) und die Regeln, nach denen ein Router weiterleitet und, wenn nötig, fragmentiert. Von Grund auf ist er unzuverlässig: IP stellt nach dem Best-Effort-Prinzip zu und überlässt Garantien den Schichten darüber, etwa TCP. 1981 von Jon Postel geschrieben und bis heute STD 5, läuft er still unter dem Großteil des Verkehrs, den du heute sendest.

Welches Problem er löst

Vor 1981 konnten Netze nicht miteinander reden. Das ARPANET, Satellitenstrecken, Paketfunk: jedes bewegte Daten auf seine eigene Art, und keines einigte sich auf ein gemeinsames Format. RFC 791 löste das mit einer einzigen Idee, und sie ist fast langweilig simpel: einigt euch auf einen gemeinsamen Umschlag. Gebt ihm einen festen Platz für eine Zieladresse, eine Absenderadresse und gerade genug Buchhaltung, damit jede Maschine unterwegs eine einzige Entscheidung treffen kann, nämlich wohin als Nächstes.

Jon Postel, der die Spec für die DARPA redigierte, schrieb sie so, dass die Maschinen in der Mitte dumm bleiben. Ein Router liest das Ziel, leitet das Paket dorthin weiter und vergisst, dass es je existiert hat. Er merkt sich deine Verbindung nicht, verfolgt nicht, ob das Paket ankam, und kümmert sich nicht um die Reihenfolge. Das klingt nach einem Fehler. Es ist die wichtigste Design-Entscheidung in der Geschichte des Internets, und im nächsten Abschnitt geht es darum, warum.

Stell dir jedes Paket als Postkarte vor

Stell dir jedes IP-Paket als Postkarte vor. Vorne: eine Zieladresse und eine Absenderadresse, nichts, was das Postsystem nicht unbedingt braucht. Hinten: deine Nachricht, so viel wie auf eine Karte passt.

Wirf sie in einen Briefkasten, und das Postsystem gibt sein Bestes. Es liest das Ziel, reicht die Karte an das nächste Sortierzentrum in die richtige Richtung weiter und macht weiter. Niemand quittiert sie. Niemand verspricht, dass sie ankommt. Nehmen zwei Karten verschiedene Wege und überholt die zweite die erste, bringt sie niemand wieder in die Reihenfolge. Und ist ein Postsack voll, wird deine Karte klammheimlich weggeworfen.

Das ist nicht die Post, die faul ist. Das ist die Post, die schnell und billig in gewaltigem Maßstab arbeitet, gerade weil sie sich weigert, Versprechen zu machen, die sie nachhalten müsste. IP ist genauso. Jedes Paket trägt seine eigene Adresse und reist allein. Router schauen kurz hin, leiten weiter, vergessen. Die Unzuverlässigkeit ist das Feature: sie ist es, die das Netz einfach genug hält, um den ganzen Planeten zu umspannen.

Brauchst du ein echtes Gespräch, jedes Wort in der Reihenfolge und nichts verloren, dann nummerierst du deine Postkarten selbst und bittest die Gegenseite, jede fehlende noch einmal zu schicken. Diese Schicht des Nummerierens und Nachsendens ist TCP, definiert in RFC 793 , und sie wohnt auf den beiden Endpunkten, nie im Netz. Das ist das Ende-zu-Ende-Prinzip: das Netz bewegt Pakete, die Enden machen sie zuverlässig.

Was IP eigentlich tut

Zieht man die Folklore ab, hat IP genau drei Aufgaben. Zwei sind echte Arbeit, eine ist ein Versprechen, das es bewusst nicht macht:

  • Adressierung 32 Bit · ~4,3 Milliarden

    Jeder Host bekommt eine 32-Bit-Adresse, geschrieben als vier Zahlen wie 203.0.113.7. Jedes Paket trägt eine Quelle und ein Ziel, sodass jeder Router es weiterleiten kann, ohne irgendetwas über das Gespräch zu wissen. Der gesamte Raum umfasst etwa 4,3 Milliarden Adressen, was 1981 unendlich schien und um 2011 ausging.

  • Fragmentierung 8-Oktett-Stücke

    Verschiedene Verbindungen akzeptieren verschiedene Maximalgrößen. Ist ein Paket zu groß für den nächsten Sprung, kann IP es in Fragmente zerlegen, die unabhängig reisen und am Ziel wieder zusammengesetzt werden. Clever, aber fragil: geht ein Stück verloren, ist das ganze Paket weg.

  • Best-Effort-Zustellung keine Garantien

    IP versucht es einmal und verspricht nichts: keine Zustellung, keine Reihenfolge, nicht einmal, dass ein Paket nur einmal ankommt. Das ist die Design-Entscheidung, kein Mangel. Sie hält Router einfach und zustandslos, und genau deshalb skalierte das Internet. Garantien wohnen eine Schicht höher, in TCP.

Der IPv4-Header, das Deckblatt eines Pakets

Jedes IPv4-Paket beginnt mit diesem Header, normalerweise 20 Byte. Das meiste davon ist Buchhaltung. Die beiden Zeilen, die für einen Router am meisten zählen, stehen unten: wohin das Paket geht und woher es kam. Spätere RFCs benannten das eine oder andere Feld um (das Type-of-Service-Byte ist heute DiffServ, siehe RFC 2474 ), aber die Form ist Postels.

32 Bit breitVer4 BitIHL4 BitType of Service8 BitGesamtlänge16 BitIdentification16 BitFlags3Fragment Offset13 BitTime to Live8 BitProtokoll8 BitHeader-Prüfsumme16 BitQuelladresse · 32 BitZieladresse · 32 BitOptions + Padding (optional)↑ der Zähler, der verlorene Pakete am ewigen Kreisen hindertdie beiden Adressen, die jeder Router unterwegs liest
Die vierzehn Felder des IPv4-Headers. Hervorgehoben: die beiden 32-Bit-Adressen, die jeder Router liest, und der Time-to-Live-Zähler, der ein verlorenes Paket am ewigen Kreisen hindert.

Was der RFC wirklich sagt

Das Original ist etwa 45 Seiten lang und für eine Spec von 1981 recht lesbar. Hier die Landkarte, falls du vorbeischauen willst:

Abschnitt In einfachen Worten
1 · Introduction Warum ein gemeinsames Protokoll nötig ist und wo IP sitzt: eine dünne Schicht, die jedes darunterliegende Netz tragen und jedes Protokoll darüber nutzen kann.
2 · Overview Das mentale Modell: Hosts, Gateways (Router), Datagramme. Zwei echte Aufgaben werden hier benannt, Adressierung und Fragmentierung, dazu ein bewusstes Nicht-Ziel, Zuverlässigkeit.
3.1 · Header format Das Herzstück: jedes Feld des Headers, Bit für Bit ausgezeichnet. Das ist das Diagramm, das am Ende jeder auswendig kann.
3.2 · Discussion Die Begründung hinter den Feldern, samt dem berühmten Robustheitsprinzip: sei konservativ beim Senden, großzügig beim Empfangen.
3.3 · Interfaces Wie die Schicht darüber (etwa TCP) und die Schicht darunter Datagramme an IP übergeben und zurück. Die Nahtstellen zwischen den Schichten.
Anhänge A/B Durchgerechnete Fragmentierungsbeispiele und die genaue Byte- und Bit-Übertragungsreihenfolge, die pedantischen Details, die Implementierer wirklich brauchen.

Was Leute falsch verstehen

  • "IP sorgt dafür, dass meine Daten ankommen."

    Hat es nie versprochen. RFC 791 beschreibt einen Best-Effort-Dienst: er versucht es einmal, ohne Garantie auf Zustellung, Reihenfolge oder dass ein Paket nur einmal ankommt. Ein Router mit voller Warteschlange verwirft das Paket einfach und macht weiter. Zuverlässigkeit ist die Aufgabe eines anderen Dokuments: RFC 793 (TCP) läuft auf den beiden Endpunkten und sendet neu, was IP verliert. IP "unzuverlässig" zu nennen ist keine Kritik, es ist die Spezifikation.

  • "IPv4 ist tot, alles ist jetzt IPv6."

    Nicht mal ansatzweise. Die IPv6-Verbreitung steigt zwar stetig, aber bis weit in die 2020er reist der Großteil des Verkehrs, den deine Geräte senden, noch über IPv4, genau das Paketformat, das RFC 791 1981 definierte. Die Adressknappheit war real und IPv6 ist die langfristige Lösung, doch IPv4 wurde durch private Adressierung (RFC 1918) und NAT am Leben gehalten und ist auf einem riesigen Teil des Internets weiterhin die Voreinstellung.

  • "Postels Robustheitsprinzip ist Folklore, es steht nicht im RFC."

    Doch, und man kann auf die Zeile zeigen. Abschnitt 3.2 von RFC 791 sagt, eine Implementierung "must be conservative in its sending behavior, and liberal in its receiving behavior." Dieser Satz, meist verkürzt zu "sei großzügig darin, was du annimmst," prägte Jahrzehnte des Protokolldesigns. Er wurde später dafür kritisiert, schlampige Implementierungen am Leben zu halten, aber er steht tatsächlich im Text von 1981, keine spätere Erfindung.

  • "Router setzen fragmentierte Pakete wieder zusammen."

    Meistens nicht. Ist ein Paket zu groß für die nächste Verbindung, darf ein Router unterwegs es in Fragmente zerlegen, aber zusammengesetzt wird am Ziel-Host, der über das Identification-Feld die Stücke einander zuordnet. Ein Router in der Mitte leitet Fragmente weiter wie jedes andere Paket. Auch deshalb ist Fragmentierung fragil: geht ein Fragment verloren, ist das ganze Original nicht wiederherstellbar.

Wo dir RFC 791 begegnet

Diesem Header begegnest du jeden Tag, ohne ihn zu sehen. Ein Feldführer für die verräterischen Zeichen:

Du siehst Du schaust auf
TTL=64 oder TTL=128 Eine Ping-Antwort. Linux und macOS starten den Time-to-Live-Zähler bei 64, Windows bei 128. Jeder Router-Sprung zieht eins ab, der Restwert verrät also grob, wie weit der Host entfernt ist.
traceroute / tracert Das TTL-Feld wird zum Werkzeug: schicke Pakete mit TTL 1, 2, 3 ... und jeder Router, der ein abgelaufenes verwirft, verrät sich. Die ganze Route, kartiert mit dem Schleifenschutz-Zähler von RFC 791.
"Fragmentation needed", MTU 1500 Die Längen- und Fragmentierungsfelder des Headers bei der Arbeit. 1500 Byte ist die klassische Ethernet-Grenze; ein Paket, das größer ist als der Pfad erlaubt, muss fragmentieren oder wird abgewiesen.
Protokoll 6, 17, 1 Das Protokoll-Feld des Headers, das angibt, was drinsteckt: 6 ist TCP, 17 ist UDP, 1 ist ICMP. So weiß der empfangende Host, welcher Schicht er die Nutzlast übergeben muss.
Jede Zeile in Wireshark Öffne irgendeinen Mitschnitt und der Block "Internet Protocol Version 4" ist RFC 791, Feld für Feld, immer noch genau so benannt, wie es die Spec von 1981 tat.

Fragen, die wirklich gestellt werden

Wird RFC 791 heute noch verwendet? +

Ja. RFC 791 ist die zentrale IPv4-Spezifikation und definiert nach wie vor die Pakete hinter dem meisten Internetverkehr. Spätere RFCs haben einzelne Header-Felder angepasst (aus dem Type-of-Service-Byte wurde DiffServ in RFC 2474), aber das Paketformat ist das, was Jon Postel 1981 geschrieben hat, und es ist weiterhin Internet Standard STD 5.

Was ist der Unterschied zwischen RFC 791 und IPv6? +

RFC 791 ist IPv4, mit 32-Bit-Adressen, etwa 4,3 Milliarden davon. IPv6 (RFC 8200) nutzt 128-Bit-Adressen, um dieser Grenze zu entkommen, und vereinfacht den Header. Gleiche Aufgabe, Pakete zwischen Hosts bewegen, nur ein viel größerer Adressraum. IPv4 ist nicht veraltet: beide laufen im Großteil des Internets nebeneinander.

Was steht eigentlich im IP-Header? +

Eine Version und Header-Länge, ein Type-of-Service-Byte, die Gesamtlänge, die Fragmentierungsfelder (Identification, Flags, Fragment Offset), ein Time-to-Live-Zähler, ein Protokoll-Feld, das angibt, was drinsteckt (TCP, UDP, ICMP), eine Header-Prüfsumme und die 32-Bit-Quell- und -Zieladresse. RFC 791 legt alle vierzehn Felder Bit für Bit fest; der Header ist normalerweise 20 Byte groß.

Warum heißt IP unzuverlässig oder Best-Effort? +

Weil es keine Versprechen macht. IP leitet jedes Paket genau einmal weiter und garantiert nicht, dass es ankommt, in der richtigen Reihenfolge ankommt oder nur einmal ankommt. Das ist Absicht: es hält Router einfach und zustandslos. Zuverlässigkeit kommt obendrauf durch TCP (RFC 793), das auf den Endpunkten läuft und alles Verlorene neu sendet.

Steht das Robustheitsprinzip wirklich in RFC 791? +

Ja. Abschnitt 3.2 sagt, eine Implementierung "must be conservative in its sending behavior, and liberal in its receiving behavior." Oft verkürzt zu "sei großzügig darin, was du annimmst," ist das Postels Robustheitsprinzip, und es stammt tatsächlich aus der IP-Spec von 1981, nicht aus späterer Folklore.

Wurde RFC 791 ersetzt oder für obsolet erklärt? +

Nein. RFC 791 ist als Internet Standard STD 5 weiterhin gültig. Er ersetzte 1981 RFC 760 und wurde seitdem aktualisiert (nicht ersetzt) durch RFC 1349, RFC 2474 und RFC 6864, die einzelne Felder verfeinern. Die Kernspezifikation steht.

Verweise hierher

Andere Erklärseiten auf dieser Website, die auf diesen RFC zurückverweisen:

Wie RFC 791 zusammenhängt

Was vorher kam

  1. RFC 760 RFC 760 (1980) war die vorherige Auflage. RFC 791 erklärte ihn ein Jahr später für obsolet und wurde die stabile Spezifikation, die vier Jahrzehnte hielt.

Teil eines geführten Clusters: Die Netzwerk-Grundlagen, erklärt