1. Einführung (Introduction)

Dieses Dokument ist Teil eines Paares, das die Anforderungen für Host-System-Implementierungen der Internet-Protokollsuite definiert und diskutiert. Dieser RFC behandelt die Kommunikationsprotokollebenen: Verbindungsschicht (link layer), IP-Schicht (IP layer) und Transportschicht (transport layer). Sein Begleit-RFC "Requirements for Internet Hosts -- Application and Support" [INTRO:1] behandelt die Anwendungsschichtprotokolle. Dieses Dokument sollte auch in Verbindung mit "Requirements for Internet Gateways" [INTRO:2] gelesen werden.

Diese Dokumente sollen Herstellern, Implementierern und Benutzern von Internet-Kommunikationssoftware Anleitung bieten. Sie repr

äsentieren den Konsens eines großen Korpus technischer Erfahrung und Weisheit, der von Mitgliedern der Internet-Forschungs- und Herstellergemeinschaften beigetragen wurde.

Dieser RFC listet Standard-Protokolle auf, die ein mit dem Internet verbundener Host verwenden muss (MUST), und er beinhaltet durch Verweis die RFCs und andere Dokumente, die die aktuellen Spezifikationen für diese Protokolle beschreiben. Er korrigiert Fehler in den referenzierten Dokumenten und fügt zusätzliche Diskussionen und Anleitungen für einen Implementierer hinzu.

Für jedes Protokoll enthält dieses Dokument auch einen expliziten Satz von Anforderungen, Empfehlungen und Optionen. Der Leser muss verstehen, dass die Liste der Anforderungen in diesem Dokument für sich genommen unvollständig ist; der vollständige Satz von Anforderungen für einen Internet-Host ist primär in den Standard-Protokollspezifikationsdokumenten definiert, mit den Korrekturen, Änderungen und Ergänzungen, die in diesem RFC enthalten sind.

Eine gutgläubige Implementierung der Protokolle, die nach sorgfältiger Lektüre der RFCs und mit einiger Interaktion mit der Internet-Technologie-Community erstellt wurde und guter Kommunikationssoftware-Engineering-Praktiken folgte, sollte von den Anforderungen dieses Dokuments nur in geringfügigen Punkten abweichen. Daher sind in vielen Fällen die "Anforderungen" in diesem RFC bereits in den Standard-Protokolldokumenten angegeben oder impliziert, so dass ihre Aufnahme hier in gewissem Sinne redundant ist. Sie wurden jedoch aufgenommen, weil einige frühere Implementierungen die falsche Wahl getroffen haben, was zu Problemen bei Interoperabilität, Leistung und/oder Robustheit führte.

Dieses Dokument enthält Diskussionen und Erklärungen zu vielen der Anforderungen und Empfehlungen. Eine einfache Liste von Anforderungen wäre gefährlich, weil:

• Einige erforderliche Funktionen wichtiger sind als andere, und einige Funktionen optional (optional) sind.
• Es gültige Gründe geben kann, warum bestimmte Herstellerprodukte, die für eingeschränkte Kontexte entwickelt wurden, andere Spezifikationen verwenden könnten.

Die Spezifikationen dieses Dokuments müssen jedoch befolgt werden (MUST), um das allgemeine Ziel der beliebigen Host-Interoperation über die Vielfalt und Komplexität des Internet-Systems zu erreichen. Obwohl die meisten aktuellen Implementierungen diese Anforderungen auf verschiedene Weise nicht erfüllen, einige geringfügig und einige erheblich, ist diese Spezifikation das Ideal, auf das wir uns zubewegen müssen.

Diese Anforderungen basieren auf dem aktuellen Stand der Internet-Architektur. Dieses Dokument wird nach Bedarf aktualisiert, um zusätzliche Klarstellungen zu bieten oder zusätzliche Informationen in den Bereichen aufzunehmen, in denen sich die Spezifikationen noch entwickeln.

Dieser einleitende Abschnitt beginnt mit einem kurzen Überblick über die Internet-Architektur im Hinblick auf Hosts und gibt dann einige allgemeine Ratschläge an Host-Softwarehersteller. Schließlich gibt es einige Anleitungen zum Lesen des restlichen Dokuments und einige Terminologie.

1.1 Die Internet-Architektur (The Internet Architecture)

Allgemeine Hintergrundinformationen und Diskussionen über die Internet-Architektur und die unterstützende Protokollsuite finden sich im DDN Protocol Handbook [INTRO:3]; für Hintergrund siehe beispielsweise [INTRO:9], [INTRO:10] und [INTRO:11]. Referenz [INTRO:5] beschreibt das Verfahren zum Erhalt von Internet-Protokolldokumenten, während [INTRO:6] eine Liste der in Internet-Protokollen zugewiesenen Nummern enthält.

1.1.1 Internet-Hosts

Ein Host-Computer, oder einfach "Host", ist der ultimative Verbraucher von Kommunikationsdiensten. Ein Host führt im Allgemeinen Anwendungsprogramme im Auftrag von Benutzer(n) aus und nutzt Netzwerk- und/oder Internet-Kommunikationsdienste zur Unterstützung dieser Funktion. Ein Internet-Host entspricht dem Konzept eines "End-Systems (End-System)", das in der OSI-Protokollsuite [INTRO:13] verwendet wird.

1.1.2 Architektonische Annahmen (Architectural Assumptions)

Die Internet-Architektur basiert auf einem spezifischen Satz von Annahmen über das Kommunikationssystem, und Implementierungen müssen (MUST) diese Annahmen widerspiegeln. Die wichtigsten architektonischen Annahmen sind wie folgt:

• Das Internet ist ein großes verteiltes System: Es gibt keine zentrale Kontrolle; stattdessen gibt es autonome Verwaltungsdomänen oder "Autonome Systeme (Autonomous Systems, AS)".
• Heterogenität: Das Internet ist aus vielen verschiedenen Kommunikationssystemen aufgebaut, einschließlich verschiedener Datenverbindungstechnologien und verschiedener Router-Implementierungen.
• Robustheit: Das System muss angesichts von Komponentenausfällen weiter funktionieren (MUST).

1.1.3 Internet-Protokollsuite (Internet Protocol Suite)

Um das Internet-System für die Kommunikation zu verwenden, muss (MUST) ein Host den geschichteten Satz von Protokollen implementieren, der die Internet-Protokollsuite umfasst. Ein Host muss typischerweise mindestens ein Protokoll von jeder Schicht implementieren.

Die in der Internet-Architektur verwendeten Protokollschichten sind:

• Anwendungsschicht (Application Layer)
• Transportschicht (Transport Layer)
• Internet-Schicht (Internet Layer)
• Verbindungsschicht (Link Layer)

1.1.4 Eingebetteter Gateway-Code (Embedded Gateway Code)

Einige Internet-Hosts werden mit Netzwerken verbunden sein, die als Stub-Netzwerke bezeichnet wurden. Ein Stub-Netzwerk ist als Netzwerk definiert, das nur Verkehr für direkt damit verbundene Hosts überträgt. Häufige Beispiele für Stub-Netzwerke sind Abteilungs-LANs.

1.2 Allgemeine Überlegungen (General Considerations)

1.2.1 Kontinuierliche Internet-Evolution (Continuing Internet Evolution)

Das Internet-System ist seit seinen Anfängen im ARPANET vor über 20 Jahren kontinuierlich gewachsen und hat sich weiterentwickelt. Daher müssen Implementierungsanforderungen und Spezifikationen flexibel sein, um sich an kontinuierliche Veränderungen anzupassen.

1.2.2 Robustheitsprinzip (Robustness Principle)

Auf jeder Ebene der Protokolle gibt es eine allgemeine Regel, deren Anwendung zu enormen Vorteilen bei Robustheit und Interoperabilität führen kann:

"Sei liberal in dem, was du akzeptierst, und konservativ in dem, was du sendest"

Software sollte geschrieben werden, um mit jedem denkbaren Fehler umzugehen, egal wie unwahrscheinlich; früher oder später wird ein Paket mit dieser bestimmten Kombination von Fehlern und Attributen ankommen, und wenn die Software nicht vorbereitet ist, kann Chaos entstehen. Im Allgemeinen ist es am besten anzunehmen, dass das Netzwerk mit böswilligen Entitäten gefüllt ist, die Pakete senden werden, die darauf ausgelegt sind, die schlechtmöglichste Wirkung zu haben. Diese Annahme wird zu einem angemessenen Schutzdesign führen.

1.2.3 Fehlerprotokollierung (Error Logging)

Die Internet-Protokollsuite enthält mehrere Mechanismen zum Melden von Fehlern zurück an den Quell-Host. Nicht alle Fehler werden jedoch über Protokollmechanismen gemeldet; einige werden einfach lokal im Host-System protokolliert. Die Ausgereiftheit der Fehlerprotokollierungsfunktion und die Details ihrer Verwendung können von System zu System variieren.

1.2.4 Konfiguration (Configuration)

Die Konfiguration eines Host-Systems wird im Allgemeinen nicht durch die Internet-Protokolldokumente spezifiziert. Es gibt jedoch bestimmte Konfigurationsparameter, die in jedem Internet-Host konfigurierbar sein müssen (MUST).

1.3 Lesen dieses Dokuments (Reading this Document)

1.3.1 Organisation

Dieses Dokument deckt die folgenden Hauptbereiche ab:

• Verbindungsschicht (Link Layer) (Abschnitt 2)
• Internet-Schicht-Protokolle (Internet Layer protocols) (Abschnitt 3)
• Transportschicht-Protokolle (Transport Layer protocols) (Abschnitt 4)

1.3.2 Anforderungen (Requirements)

In diesem Dokument werden die Wörter, die zur Definition der Bedeutung jeder bestimmten Anforderung verwendet werden, großgeschrieben. Diese Wörter sind:

• MUST: Dieses Wort oder das Adjektiv "REQUIRED" bedeutet, dass das Element eine absolute Anforderung der Spezifikation ist.
• SHOULD: Dieses Wort oder das Adjektiv "RECOMMENDED" bedeutet, dass es unter bestimmten Umständen gültige Gründe geben kann, dieses Element zu ignorieren, aber die vollständigen Auswirkungen sollten verstanden und der Fall sorgfältig abgewogen werden, bevor ein anderer Kurs gewählt wird.
• MAY: Dieses Wort oder das Adjektiv "OPTIONAL" bedeutet, dass dieses Element wirklich optional ist.

1.3.3 Terminologie (Terminology)

Dieses Dokument verwendet die folgenden technischen Begriffe:

• Segment: Ein Segment ist die Einheit der Ende-zu-Ende-Übertragung im TCP-Protokoll.
• Nachricht (Message): In dieser Beschreibung der unteren Schichtprotokolle ist eine Nachricht die Einheit der Übertragung in einem Transportschichtprotokoll.
• Datagramm (Datagram): Ein Datagramm ist ein IP-Paket.
• Paket (Packet): Ein Paket ist ein beliebiger formatierter Datenblock.
• Frame: Ein Frame ist ein Verbindungsschicht-Paket.
• Verbundenes Netzwerk (Connected Network): Ein verbundenes Netzwerk ist ein beliebiges Netzwerk, mit dem ein Host verbunden ist, sei es physisch, virtuell oder logisch.
• Multihomed: Ein Host wird als multihomed bezeichnet, wenn er mehrere IP-Adressen hat.

1.4 Danksagungen (Acknowledgments)

Dieses Dokument enthält Beiträge und Kommentare von vielen Mitgliedern der Internet-Community.

---