1. Einleitung (INTRODUCTION)

Dieses Dokument definiert zusammen mit einem weiteren Dokument die Anforderungen an die Implementierung von Hostsystemen der Internet-Protokollfamilie und erörtert sie. Dieses RFC behandelt die Kommunikationsprotokollschichten: die Sicherungsschicht, die Internetschicht und die Transportschicht; sein Schwesterdokument RFC „Anforderungen an Internet-Hosts -- Anwendung und Unterstützung“ [INTRO:1] behandelt die Anwendungsschicht-Protokolle. Dieses Dokument sollte zudem zusammen mit „Anforderungen an Internet-Gateways“ [INTRO:2] gelesen werden.

Diese Dokumente sollen Anbietern, Implementierern und Benutzern von Internet-Kommunikationssoftware Leitlinien bieten. Sie stellen einen Konsens aus umfangreicher technischer Erfahrung und Weisheit dar, der von Mitgliedern der Internet-Forschungs- und Anbietercommunity beigesteuert wurde.

Dieses RFC listet die Standardprotokolle auf, die ein an das Internet angeschlossener Host verwenden muss, und übernimmt durch Referenz die RFCs und anderen Dokumente, die die aktuellen Spezifikationen dieser Protokolle beschreiben. Es korrigiert zudem Fehler in den zitierten Dokumenten und ergänzt zusätzliche Diskussionen und Anleitungen für Implementierer.

Für jedes Protokoll enthält dieses Dokument zudem eine Reihe expliziter Anforderungen, Empfehlungen und Optionen. Der Leser muss verstehen, dass die Anforderungsliste in diesem Dokument für sich allein unvollständig ist; die vollständige Menge der Anforderungen an Internet-Hosts ist primär in den Standard-Protokollspezifikationsdokumenten definiert und umfasst die Korrekturen, Überarbeitungen und Ergänzungen dieses RFC.

Nach sorgfältigem Lesen des RFC und einigem Austausch mit der Internet-Technik-Community, bei ehrlicher Implementierung der Protokolle und Befolgung guter Praktiken des Kommunikationssoftware-Engineering, sollte die resultierende Implementierung nur geringfügig von den Anforderungen dieses Dokuments abweichen. Daher sind die „Anforderungen“ in diesem RFC in vielen Fällen bereits in den Standard-Protokolldokumenten dargelegt oder impliziert, sodass ihre Aufnahme in gewissem Sinne redundant ist. Sie wurden jedoch aufgenommen, weil einige Implementierungen in der Vergangenheit falsche Entscheidungen trafen, was zu Problemen bei Interoperabilität, Leistung und/oder Robustheit führte.

Dieses Dokument enthält Diskussionen und Erklärungen zu vielen Anforderungen und Empfehlungen. Eine bloße Liste von Anforderungen ist gefährlich, denn:

• Einige erforderliche Merkmale sind wichtiger als andere, und einige Merkmale sind optional.
• Es kann gute Gründe geben, warum ein bestimmtes Herstellerprodukt, das für eine eingeschränkte Umgebung entworfen ist, eine andere Spezifikation wählen könnte.

Um jedoch das Gesamtziel der Interoperabilität eines beliebigen Hosts über die Vielfalt und Komplexität der Internetsysteme hinweg zu erreichen, müssen die Normen dieses Dokuments befolgt werden. Obwohl die meisten Implementierungen heute in unterschiedlichem Maße (teilweise geringfügig, teils erheblich) diese Anforderungen nicht erfüllen, ist diese Spezifikation das Ideal, dem wir uns annähern sollten.

Diese Anforderungen basieren auf dem aktuellen Stand der Internet-Architektur. Diese Datei wird bei Bedarf aktualisiert, um in Bereichen, in denen sich die Normen noch entwickeln, zusätzliche Klarstellungen bereitzustellen oder zusätzliche Informationen einzubringen.

Dieser Einleitungsteil gibt zunächst einen kurzen Überblick über die für Hosts relevante Internet-Architektur, gibt dann einige allgemeine Empfehlungen an Host-Software-Anbieter und schließlich Hinweise zum Lesen des restlichen Dokuments sowie einige Begriffe.

1.1 Die Internet-Architektur (The Internet Architecture)

Für allgemeinen Hintergrund und Diskussionen zur Internet-Architektur und der zugrunde liegenden Protokollfamilie siehe das DDN Protocol Handbook [INTRO:3]; Hintergrundmaterialien finden sich beispielsweise in [INTRO:9], [INTRO:10] und [INTRO:11]. Die Referenz [INTRO:5] beschreibt das Verfahren zum Erhalt von Internet-Protokolldokumenten, und [INTRO:6] enthält die Liste der in den Internet-Protokollen zugewiesenen Nummern.

1.1.1 Internet-Hosts (Internet Hosts)

Ein Host-Computer, kurz „Host“, ist der Endverbraucher der Kommunikationsdienste. Hosts führen typischerweise Anwendungen im Auftrag von Benutzern aus und nutzen Netzwerk- und/oder Internet-Kommunikationsdienste zur Unterstützung dieser Funktion. Ein Internet-Host entspricht dem in der OSI-Protokollfamilie [INTRO:13] verwendeten Konzept des „End-Systems (End-System)“.

Ein Internet-Kommunikationssystem besteht aus miteinander verbundenen Paketnetzwerken, die die Internet-Protokolle zur Unterstützung der Kommunikation zwischen Host-Computern verwenden. Diese Netzwerke sind über paketvermittelnde Computer verbunden, die als „Gateways“ oder „IP-Router“ (Bezeichnung der Internet-Community), „Intermediate Systems“ (OSI-Welt) [INTRO:13] bezeichnet werden. Das RFC „Anforderungen an Internet-Gateways“ [INTRO:2] enthält die offizielle Spezifikation für Internet-Gateways. Dieses RFC, zusammen mit diesem Dokument und seinem Schwesterdokument [INTRO:1], definiert die Regeln für die Implementierung der aktuellen Internet-Architektur.

Internet-Hosts variieren erheblich in Größe, Geschwindigkeit und Funktion. Ihre Größe reicht vom Mikroprozessor über die Workstation bis zum Mainframe und Supercomputer. In der Funktion reichen sie vom Host mit Einzelzweck (wie einem Terminal-Server) bis zum Full-Service-Host, der viele Online-Netzwerkdienste unterstützt, in der Regel einschließlich Remote-Login, Dateiübertragung und E-Mail.

Wenn ein Host mehrere Schnittstellen zum selben oder zu verschiedenen Netzwerken besitzt, wird er üblicherweise als multihomed (mehrfach vernetzt) bezeichnet. Siehe Abschnitt 3.3.4 zu Multihoming.

1.1.2 Architektonische Annahmen (Architectural Assumptions)

Die aktuelle Internet-Architektur basiert auf einer Reihe von Annahmen über Kommunikationssysteme. Die für Hosts relevantesten Annahmen sind:

(a) Das Internet ist ein Netzwerk von Netzwerken.

Jeder Host ist direkt mit einem bestimmten Netzwerk verbunden; seine Verbindung zum Internet ist nur konzeptionell. Zwei Hosts im selben Netzwerk kommunizieren mit demselben Protokollsatzes wie bei der Kommunikation mit einem Host in einem entfernten Netzwerk.

(b) Gateways behalten keine Verbindungszustandsinformationen.

Um die Robustheit des Kommunikationssystems zu erhöhen, sind Gateways zustandslos konzipiert und leiten jedes IP-Datagramm unabhängig von anderen Datagrammen weiter. Daher können redundante Pfade genutzt werden, um bei Ausfällen von Zwischengateways und -netzwerken einen robusten Dienst bereitzustellen.

Alle für die End-to-End-Flusskontrolle und -zuverlässigkeit benötigten Zustandsinformationen werden in den Hosts, in der Transportschicht oder der Anwendung, implementiert. Daher befinden sich alle Verbindungssteuerungsinformationen bei den Kommunikationsendpunkten, sodass sie nur bei einem Endpunktausfall verloren gehen.

(c) Die Komplexität des Routings sollte in die Gateways gelegt werden.

Routing ist ein komplexes und schwieriges Problem, das von Gateways und nicht von Hosts ausgeführt werden sollte. Ein wichtiges Ziel ist es, die Host-Software von der unvermeidlichen Weiterentwicklung der Internet-Routing-Architektur zu isolieren.

(d) Systeme müssen eine große Bandbreite an Netzwerkunterschieden tolerieren.

Ein grundlegendes Ziel des Internet-Designs ist es, eine breite Palette von Netzwerkmerkmalen zu tolerieren — beispielsweise Bandbreite, Latenz, Paketverlust, Neuordnung und maximale Paketgröße. Ein weiteres Ziel ist die Robustheit gegenüber Ausfällen einzelner Netzwerke, Gateways und Hosts, indem verfügbare Bandbreite genutzt wird. Das Endziel ist die vollständige „Open Systems Interconnection“: Ein Internet-Host muss in der Lage sein, mit jedem anderen Internet-Host über diverse Internet-Pfade robust und effektiv zu interoperieren.

Manchmal entwerfen Host-Implementierer für ein weniger ehrgeiziges Ziel. Beispielsweise ist die LAN-Umgebung im Allgemeinen viel sanfter als das gesamte Internet; LANs weisen geringen Paketverlust, geringe Latenz und keine Neuordnung auf. Einige Anbieter haben Host-Implementierungen auf den Markt gebracht, die nur für einfache LAN-Umgebungen geeignet sind, aber bei der allgemeinen Interoperabilität schlecht abschneiden. Anbieter rechtfertigen solche Produkte mit der Wirtschaftlichkeit in eingeschränkten LAN-Märkten. Isolierte LANs bleiben jedoch selten lange isoliert; sie werden bald miteinander, mit unternehmensweiten Internets und schließlich mit dem globalen Internet-System verbunden. Letztendlich schaden unvollständige oder unzureichende Internet-Host-Software sowohl dem Kunden als auch dem Anbieter.

Die in diesem Dokument detailliert festgelegten Anforderungen sind für voll funktionsfähige Internet-Hosts konzipiert, die auf jedem beliebigen Internet-Pfad eine vollständige Interoperabilität erreichen können.

1.1.3 Die Internet-Protokollfamilie (Internet Protocol Suite)

Um über das Internetsystem zu kommunizieren, müssen Hosts den Satz hierarchischer Protokolle implementieren, aus denen die Internet-Protokollfamilie besteht. Hosts müssen in der Regel mindestens ein Protokoll jeder Schicht implementieren.

Die in der Internet-Architektur verwendeten Protokollschichten sind [INTRO:4]:

Anwendungsschicht (Application Layer)

Die Anwendungsschicht ist die oberste Schicht der Internet-Protokollfamilie. Die Internet-Protokollfamilie unterteilt die Anwendungsschicht nicht weiter, obwohl einige Anwendungsschicht-Protokolle des Internets tatsächlich einige interne Unterteilungen aufweisen. Die Anwendungsschicht der Internet-Protokollfamilie kombiniert im Wesentlichen die Funktionen der beiden obersten Schichten des OSI-Referenzmodells — Darstellungsschicht und Anwendungsschicht.

Wir unterscheiden zwei Klassen von Anwendungsschicht-Protokollen: Benutzerprotokolle, die direkt Dienste für Benutzer bereitstellen, und Unterstützungsprotokolle, die allgemeine Systemfunktionen bereitstellen. Die Anforderungen für Benutzer- und Unterstützungsprotokolle finden sich im Schwester-RFC [INTRO:1].

Die gebräuchlichsten Internet-Benutzerprotokolle sind:

• Telnet (Remote-Login)
• FTP (Dateiübertragung)
• SMTP (E-Mail-Zustellung)

Es gibt viele weitere standardisierte Benutzerprotokolle [INTRO:4] sowie viele private Benutzerprotokolle.

Zu den Unterstützungsprotokollen für Host-Namenszuordnung, Bootstrap und Verwaltung gehören SNMP, BOOTP, RARP und das Domain Name System (DNS).

Transportschicht (Transport Layer)

Die Transportschicht bietet Anwendungen End-to-End-Kommunikationsdienste. Derzeit gibt es zwei Haupt-Transportprotokolle:

• Transmission Control Protocol (TCP)
• User Datagram Protocol (UDP)

TCP ist ein zuverlässiger, verbindungsorientierter Transportdienst, der End-to-End-Zuverlässigkeit, Neuordnung und Flusskontrolle bietet. UDP ist ein verbindungsloser („Datagramm“) Transportdienst.

Forscher haben weitere Transportprotokolle entwickelt, und die offizielle Sammlung der Internet-Transportprotokolle könnte künftig erweitert werden.

Die Transportprotokolle werden in Kapitel 4 erörtert.

Internetschicht (Internet Layer)

Alle Internet-Transportprotokolle verwenden das Internet-Protokoll (IP), um Daten vom Quell-Host zum Ziel-Host zu übertragen. IP ist ein verbindungsloser oder Datagramm-Internetwork-Dienst, der keine End-to-End-Zustellgarantie bietet. Daher können IP-Datagramme beim Ziel-Host korrumpiert, dupliziert, unsortiert ankommen oder gar nicht ankommen. Wenn Zuverlässigkeit gefordert ist, sind die Schichten über IP dafür verantwortlich, einen zuverlässigen Zustelldienst bereitzustellen. Das IP-Protokoll enthält Bestimmungen für Adressierung, Diensttypfestlegung, Fragmentierung und Reassemblierung sowie Sicherheitsinformationen.

Die Datagramm- oder verbindungslose Eigenschaft des IP-Protokolls ist ein grundlegendes und charakteristisches Merkmal der Internet-Architektur. Das Internet-IP ist das Modell des OSI-Verbindungslosen-Netzwerkprotokolls [INTRO:12].

ICMP ist ein Kontrollprotokoll, das als Teil von IP angesehen wird, obwohl es architektonisch über IP liegt, d.h. es verwendet wie TCP oder UDP IP, um seine Daten End-to-End zu transportieren. ICMP bietet Fehlerberichterstattung, Stauungsberichterstattung und First-Hop-Gateway-Redirect.

IGMP ist ein Internet-Schicht-Protokoll, das zur Einrichtung dynamischer Hostgruppen für IP-Multicast verwendet wird.

Die Internet-Schicht-Protokolle IP, ICMP und IGMP werden in Kapitel 3 erörtert.

Sicherungsschicht (Link Layer)

Um auf dem direkt verbundenen Netzwerk zu kommunizieren, muss ein Host die Kommunikationsprotokolle implementieren, die zur Verbindung mit diesem Netzwerk verwendet werden. Wir nennen diese Protokolle Sicherungsschicht- oder Medienzugriffsschicht-Protokolle.

Es gibt viele verschiedene Sicherungsschicht-Protokolle, die vielen verschiedenen Netzwerktypen entsprechen. Siehe Kapitel 2.

1.1.4 Eingebetteter Gateway-Code (Embedded Gateway Code)

Einige Internet-Host-Software enthält eingebettete Gateway-Funktionen, die es diesen Hosts ermöglichen, Pakete wie Gateways weiterzuleiten, während sie weiterhin die Anwendungsschichtfunktionen des Hosts ausführen.

Diese Zwei-Zweck-Systeme müssen die Gateway-Anforderungs-RFC [INTRO:2] in ihren Gateway-Funktionen und dieses Dokument in ihren Host-Funktionen befolgen. In allen überlappenden Fällen sollten die beiden Spezifikationen konsistent sein.

Die Internet-Community ist uneins über eingebettete Gateway-Funktionen. Die Hauptargumente sind:

Dafür (Pro): In informellen LAN-Umgebungen oder isolierten Internets kann die Verwendung vorhandener Host-Systeme als Gateways bequem und wirtschaftlich sein.

Es gibt auch ein architektonisches Argument für eingebettete Gateway-Funktionen: Multihoming ist viel häufiger als ursprünglich angenommen, und Multihoming zwingt Hosts, Routing-Entscheidungen wie Gateways zu treffen. Wenn ein Multihome-Host ein eingebettetes Gateway enthält, verfügt er über vollständiges Routing-Wissen und kann bessere Routing-Entscheidungen treffen.

Dagegen (Con): Gateway-Algorithmen und -Protokolle entwickeln sich weiter und werden sich weiter ändern, wenn das Internetsystem wächst. Zu versuchen, eine generische Gateway-Funktion in die IP-Schicht eines Hosts einzubauen, zwingt die Betreuer der Host-Systeme, diese (häufigeren) Änderungen zu verfolgen. Zudem erschwert ein größerer Pool von Gateway-Implementierungen die Koordination von Änderungen. Schließlich ist die Komplexität der IP-Schicht eines Gateways geringfügig höher als die eines Hosts, was Implementierungs- und Betriegsaufgaben komplexer macht.

Zudem eignen sich einige Betriebsstile von Hosts nicht zur Bereitstellung eines stabilen und robusten Gateway-Dienstes.

Beide Sichtweisen haben durchaus Berechtigung. Eine Schlussfolgerung ist, dass Host-Administratoren eine bewusste Kontrolle darüber haben müssen, ob ein bestimmter Host als Gateway fungiert. Detaillierte Anforderungen siehe Abschnitt 3.1.

1.2 Allgemeine Erwägungen (General Considerations)

Internet-Host-Software-Anbieter haben zwei wichtige Lektionen gelernt, die neue Anbieter ernsthaft beachten sollten.

1.2.1 Die fortlaufende Evolution des Internets (Continuing Internet Evolution)

Das enorme Wachstum des Internets hat Probleme bei Verwaltung und Skalierung eines großen, datagrammbasierten Paketkommunikationssystems aufgezeigt. Diese Probleme werden gelöst, und daher werden sich die in diesem Dokument beschriebenen Normen weiter entwickeln. Diese Änderungen werden sorgfältig geplant und gesteuert, da Anbieter und für den Netzbetrieb zuständige Organisationen an dieser Planung breit beteiligt sind.

Entwicklung, Evolution und Überarbeitung sind Merkmale von Computernetzwerkprotokollen heute und werden über mehrere Jahre so bleiben. Ein Anbieter, der Computersoftware für die Internet-Protokollfamilie (oder irgendeine andere Protokollfamilie!) entwickelt und diese Software dann nicht entsprechend den sich ändernden Spezifikationen wartet und aktualisiert, wird eine Reihe unzufriedener Kunden hinterlassen. Das Internet ist ein großes Kommunikationsnetz, in dem Benutzer in ständigem Kontakt bleiben. Die Erfahrung zeigt, dass Kenntnisse über Softwarefehler von Anbietern sich schnell in der Internet-Technik-Community verbreiten.

1.2.2 Das Robustheitsprinzip (Robustness Principle)

Auf jeder Protokollschicht gibt es eine allgemeine Regel, deren Anwendung enorme Vorteile für Robustheit und Interoperabilität bringt [IP:1]:

„Sei großzügig in dem, was du akzeptierst, und konservativ in dem, was du sendest (Be liberal in what you accept, and conservative in what you send)“

Software sollte so geschrieben sein, dass sie jeden vorstellbaren Fehler behandeln kann, so unwahrscheinlich er auch sei; früher oder später wird ein Paket mit genau dieser Kombination aus Fehler und Attributen eintreffen, und wenn die Software nicht darauf vorbereitet ist, kann das Chaos folgen. Im Allgemeinen ist es gut, anzunehmen, dass das Netzwerk voller bösartiger Entitäten ist, die Pakete senden, die die schlimmste Wirkung erzielen sollen. Diese Annahme führt zu einem angemessenen Schutzdesign, wenngleich die schwerwiegendsten Probleme des Internets durch unerwartete Mechanismen ausgelöst werden, die durch Ereignisse mit geringer Wahrscheinlichkeit ausgelöst werden; bloße menschliche Böswilligkeit würde einen so umständlichen Weg nie einschlagen!

Internet-Host-Software aller Ebenen muss für Anpassungsfähigkeit an Veränderungen ausgelegt sein. Ein einfaches Beispiel: Betrachte eine Protokollspezifikation, die eine Aufzählung von Werten für ein bestimmtes Header-Feld enthält — etwa ein Typfeld, eine Portnummer oder ein Fehlercode; man muss annehmen, dass diese Aufzählung unvollständig ist. Wenn die Spezifikation also vier mögliche Fehlercodes definiert, darf die Software niemals abstürzen, wenn ein fünfter Code erscheint. Nicht definierte Codes dürfen protokolliert werden (siehe unten), dürfen aber keinen Fehler verursachen.

Der zweite Teil dieses Prinzips ist fast ebenso wichtig: Software auf anderen Hosts kann Fehler enthalten, die es unklug machen, selten genutzte, aber legale Protokollmerkmale auszunutzen. Vom Offensichtlichen und Einfachen abzuweichen ist gefährlich, um andernorts nachteilige Auswirkungen zu vermeiden. Die Folgerung lautet „hüte dich vor fehlerhaften Hosts“; Host-Software muss nicht nur darauf vorbereitet sein, in Gegenwart anderer fehlerhafter Hosts zu überleben, sondern auch kooperieren, um das Ausmaß der Schäden zu begrenzen, die solche Hosts der gemeinsamen Kommunikationseinrichtung zufügen können.

1.2.3 Fehlerprotokollierung (Error Logging)

Das Internet enthält eine große Vielfalt von Host- und Gateway-Systemen, von denen jedes viele Protokolle und Protokollschichten implementiert, von denen einige Fehler und Defektmerkmale in ihrer Internet-Protokollsoftware enthalten. Aufgrund der Komplexität, Vielfalt und Verteilung der Funktionen ist die Diagnose von Internet-Problemen oft sehr schwierig.

Wenn die Host-Implementierung eine gut gestaltete Einrichtung zum Protokollieren von Fehlern oder „seltsamen“ Protokollereignissen enthält, wird dies bei der Problemdiagnose helfen. Beim Protokollieren von Fehlern ist es wichtig, so viele Diagnoseinformationen wie möglich einzuschließen. Insbesondere ist es oft nützlich, den Header des Pakets zu protokollieren, das den Fehler verursacht hat. Es muss jedoch sichergestellt werden, dass das Fehlerprotokoll keine übermäßigen Ressourcen verbraucht oder den Betrieb des Hosts anderweitig stört.

Anormale, aber harmlose Protokollereignisse können die Fehlerprotokolldatei zum Überlaufen bringen; dies kann durch Verwendung eines „zirkulären“ Protokolls oder durch Aktivieren des Protokolls nur bei der Diagnose bekannter Fehler vermieden werden. Das Filtern und Zählen aufeinanderfolgender doppelter Nachrichten kann nützlich sein. Eine Strategie, die gut zu funktionieren scheint, ist: (1) Anomalien immer zählen und den Zugriff auf diese Zähler über ein Verwaltungsprotokoll (siehe [INTRO:1]) ermöglichen; und (2) das selektive Aktivieren der Protokollierung großer Ereignismengen erlauben. Es kann beispielsweise nützlich sein, „alles protokollieren“ oder „alles vom Host X protokollieren“ zu können.

Beachten Sie, dass verschiedene Administratoren unterschiedliche Strategien dazu haben können, wie viel Fehlerprotokollierung üblicherweise aktiviert sein soll. Einige sagen „solange es mir nicht schadet, will ich es nicht wissen“, während andere eine wachsamere, proactive Haltung zur Erkennung und Beseitigung von Protokollanomalien bevorzugen.

1.2.4 Konfiguration (Configuration)

Es wäre ideal, wenn die Host-Implementierung der Internet-Protokollfamilie vollständig selbstkonfigurierend wäre. Dies würde die Implementierung der gesamten Protokollfamilie in ROM oder das Einbrennen in Silizium ermöglichen, Diskless-Workstations vereinfachen und sowohl beschäftigten LAN-Administratoren als auch Systemanbietern ein großer Segen sein. Wir haben dieses Ideal noch nicht erreicht; tatsächlich sind wir noch weit davon entfernt.

An vielen Stellen in diesem Dokument finden Sie die Anforderung, dass ein bestimmter Parameter eine konfigurierbare Option sein muss. Hinter solchen Anforderungen stehen verschiedene Gründe. In wenigen Fällen besteht derzeit Unsicherheit oder Uneinigkeit über den besten Wert, und es kann nötig sein, den empfohlenen Wert künftig zu aktualisieren. In anderen Fällen hängt der Wert tatsächlich von externen Faktoren ab — etwa der Größe des Hosts und der Verteilung seiner Kommunikationslast oder der Geschwindigkeit und Topologie benachbarter Netzwerke — und selbsttunende Algorithmen sind nicht verfügbar oder unzureichend. In einigen Fällen ist Konfigurierbarkeit aufgrund von Verwaltungsanforderungen erforderlich.

Schließlich sind einige Konfigurationsoptionen erforderlich, um mit fehlerhaften oder veralteten Protokollimplementierungen zu kommunizieren, die ohne Quellcode-Verteilung im Internet noch immer verbreitet sind. Damit ein korrektes System mit diesen fehlerhaften Systemen koexistieren kann, müssen Administratoren das korrekte System oft „falsch konfigurieren“. Mit der Außerbetriebnahme fehlerhafter Systeme wird sich dieses Problem allmählich selbst korrigieren, aber Anbieter können es nicht ignorieren.

Wenn wir sagen, ein Parameter muss konfigurierbar sein, verlangen wir nicht, dass sein Wert bei jedem Start explizit aus einer Konfigurationsdatei gelesen wird. Wir empfehlen Implementierern, für jeden Parameter einen Standardwert festzulegen, sodass die Konfigurationsdatei nur zum Überschreiben unpassender Standardwerte in einer bestimmten Installation verwendet wird. Die Konfigurierbarkeitsanforderung ist somit eine Garantie, dass der Standardwert bei Bedarf überschrieben werden kann, selbst in einem binären oder ROM-basierten Produkt.

Dieses Dokument verlangt in einigen Fällen, dass diese Standardwerte bestimmte Werte annehmen. Wenn ein Konfigurationselement die Kompatibilität mit vorhandenen fehlerhaften Systemen steuert, ist die Wahl des Standardwerts ein sensibles Thema. Damit sich das Internet zu voller Interoperabilität hin entwickelt, müssen die in Implementierungen eingebauten Standardwerte das offizielle Protokoll implementieren, nicht eine „Falschkonfiguration“ zur Anpassung an fehlerhafte Implementierungen. Obwohl Markterwägungen einige Anbieter dazu bewogen haben, falsch konfigurierte Standardwerte zu wählen, drängen wir Anbieter, konforme Standardwerte zu wählen.

Schließlich stellen wir fest, dass Anbieter angemessene Dokumentation für alle Konfigurationsparameter, ihre Grenzen und Auswirkungen bereitstellen müssen.

1.3 Lesen dieses Dokuments (Reading this Document)

1.3.1 Organisation (Organization)

Die Protokollhierarchie wird üblicherweise als Organisationsprinzip zur Implementierung von Netzwerksoftware und zur Organisation dieses Dokuments verwendet. Bei der Beschreibung der Regeln nehmen wir an, dass Implementierungen die Protokollhierarchie tatsächlich strikt abbilden. Daher legen die folgenden drei Hauptkapitel jeweils die Anforderungen für die Sicherungsschicht, die Internetschicht und die Transportschicht fest. Das Schwester-RFC [INTRO:1] behandelt die Anwendungsschicht-Software. Diese hierarchische Organisation wurde der Einfachheit und Klarheit halber gewählt.

Die strikte Schichtung ist jedoch ein unvollkommenes Modell sowohl für die Protokollfamilie als auch für die empfohlene Implementierungsmethode. Protokolle verschiedener Schichten interagieren auf komplexe und manchmal subtile Weise, und bestimmte Funktionen betreffen oft mehrere Schichten. Es gibt viele Designentscheidungen in Implementierungen, von denen viele das kreative „Aufbrechen“ der strikten Schichtung beinhalten. Wir drängen jeden Implementierer, die Referenzen [INTRO:7] und [INTRO:8] zu lesen.

Dieses Dokument verwendet eine funktionale („Prozeduraufruf“-)Notation, um die konzeptionellen Dienstschnittstellen zwischen den Schichten zu beschreiben, ähnlich der in der TCP-Spezifikation [TCP:1] verwendeten. Host-Implementierungen müssen den von diesen Aufrufen implizierten logischen Informationsfluss unterstützen, müssen die Aufrufe selbst aber nicht wörtlich implementieren. Viele Implementierungen spiegeln beispielsweise die Kopplung zwischen Transportschicht und IP-Schicht durch gemeinsame Datenstrukturen wider. Diese Datenstrukturen werden dann — statt expliziter Prozeduraufrufe — zum Medium zur Übertragung vieler benötigter Informationen.

Im Allgemeinen ist jedes Hauptkapitel dieses Dokuments wie folgt gegliedert:

1. Einleitung (Introduction)
2. Protokoll-Durchgehung (Protocol Walk-Through) — untersucht das Protokollspezifikationsdokument abschnittsweise, korrigiert Fehler, stellt möglicherweise unklare oder unzureichend definierte Anforderungen dar und liefert weitere Klarstellungen oder Erklärungen.
3. Spezifische Probleme (Specific Issues) — erörtert Protokoll-Design- und Implementierungsprobleme, die nicht in der Durchgehung enthalten sind.
4. Schnittstellen (Interfaces) — erörtert die Dienstschnittstelle zur nächsten höheren Schicht.
5. Zusammenfassung (Summary) — enthält eine Zusammenfassung der Anforderungen dieses Abschnitts.

Unter vielen einzelnen Themen dieses Dokuments finden sich mit „DISCUSSION“ oder „IMPLEMENTATION“ versehene Materialien. Der Zweck dieser Materialien ist es, den vorangegangenen Anforderungstext zu erklären und zu verdeutlichen. Sie enthalten auch einige Vorschläge für mögliche zukünftige Richtungen oder Entwicklungen. Implementierungsmaterialien enthalten vorgeschlagene Methoden, die Implementierer in Betracht ziehen könnten.

Der Zusammenfassungsunterabschnitt dient als Leitfaden und Index zum Haupttext, ist aber notwendigerweise knapp und unvollständig. Die Zusammenfassung sollte niemals getrennt vom vollständigen RFC allein verwendet oder zitiert werden.

1.3.2 Anforderungen (Requirements)

In diesem Dokument werden die Wörter, die zur Definition der Wichtigkeit jeder spezifischen Anforderung verwendet werden, in Großbuchstaben geschrieben. Diese Wörter sind:

„MUST“ (MUSS)

Dieses Wort oder das Adjektiv „REQUIRED“ besagt, dass der Punkt eine absolute Anforderung der Norm ist.

„SHOULD“ (SOLLTE)

Dieses Wort oder das Adjektiv „RECOMMENDED“ besagt, dass es in bestimmten Situationen ggf. gerechtfertigte Gründe geben kann, den Punkt zu ignorieren, aber alle Implikationen verstanden und sorgfältig abgewogen werden müssen, bevor eine andere Vorgehensweise gewählt wird.

„MAY“ (KANN)

Dieses Wort oder das Adjektiv „OPTIONAL“ besagt, dass der Punkt tatsächlich optional ist. Ein Anbieter könnte den Punkt beispielsweise aufgrund eines spezifischen Marktbedarfs oder zur Produktverbesserung einbeziehen; ein anderer Anbieter kann denselben Punkt weglassen.

Wenn eine Implementierung eine oder mehrere MUST-Anforderungen des Protokolls, das sie implementiert, nicht erfüllt, ist die Implementierung nicht konform mit der Spezifikation. Eine Implementierung, die alle MUST- und alle SHOULD-Anforderungen ihres Protokolls erfüllt, wird als „bedingungslos konform (unconditionally compliant)“ bezeichnet; eine Implementierung, die alle MUST- aber nicht alle SHOULD-Anforderungen erfüllt, wird als „bedingt konform (conditionally compliant)“ bezeichnet.

1.3.3 Terminologie (Terminology)

Dieses Dokument verwendet die folgenden technischen Begriffe:

Segment

Ein Segment ist die Einheit der End-to-End-Übertragung im TCP-Protokoll. Ein Segment besteht aus einem TCP-Header gefolgt von Anwendungsdaten. Ein Segment wird transportiert, indem es in einem IP-Datagramm gekapselt wird.

Nachricht (Message)

In der Beschreibung von Protokollen niedrigerer Schicht ist eine Nachricht die Übertragungseinheit im Transportprotokoll. Insbesondere ist ein TCP-Segment eine Nachricht. Eine Nachricht besteht aus einem Transportprotokoll-Header gefolgt von Anwendungsprotokolldaten. Um End-to-End über das Internet transportiert zu werden, muss eine Nachricht in einem Datagramm gekapselt werden.

IP-Datagramm (IP Datagram)

Ein IP-Datagramm ist die Einheit der End-to-End-Übertragung im IP-Protokoll. Ein IP-Datagramm besteht aus einem IP-Header gefolgt von Transportschichtdaten, d.h. einem IP-Header gefolgt von einer Nachricht.

In der Beschreibung der Internetschicht (Abschnitt 3) bezieht sich der nicht qualifizierte Begriff „Datagramm (datagram)“ auf ein IP-Datagramm.

Paket (Packet)

Ein Paket ist die Dateneinheit, die über die Schnittstelle zwischen Internetschicht und Sicherungsschicht übertragen wird. Es enthält einen IP-Header und Daten. Ein Paket kann ein vollständiges IP-Datagramm oder ein Fragment eines IP-Datagramms sein.

Rahmen (Frame)

Ein Rahmen ist die Übertragungseinheit im Sicherungsschicht-Protokoll und besteht aus einem Sicherungsschicht-Header gefolgt von einem Paket.

Verbundenes Netzwerk (Connected Network)

Das Netzwerk, mit dem ein Host verbunden ist, wird im Allgemeinen als „lokales Netzwerk (local network)“ oder „Subnetz (subnetwork)“ in Bezug auf diesen Host bezeichnet. Diese Begriffe können jedoch verwirrend sein, daher verwenden wir in diesem Dokument den Begriff „verbundenes Netzwerk (connected network)“.

Multihomed

Wenn ein Host mehrere IP-Adressen besitzt, wird er als multihomed bezeichnet. Eine Diskussion zu Multihoming finden Sie in Abschnitt 3.3.4.

Physische Netzwerkschnittstelle (Physical network interface)

Dies ist die physische Schnittstelle zum verbundenen Netzwerk und besitzt eine (möglicherweise eindeutige) Sicherungsschicht-Adresse. Mehrere physische Netzwerkschnittstellen auf einem einzelnen Host dürfen dieselbe Sicherungsschicht-Adresse teilen, diese Adresse muss jedoch für verschiedene Hosts im selben physischen Netzwerk eindeutig sein.

Logische [Netzwerk-]Schnittstelle (Logical [network] interface)

Wir definieren die logische [Netzwerk-]Schnittstelle als einen logischen Pfad zum verbundenen Netzwerk, der durch eine eindeutige IP-Adresse unterschieden wird. Siehe Abschnitt 3.3.4.

Spezifische Zieladresse (Specific-destination address)

Dies ist die gültige Zieladresse des Datagramms, auch wenn es sich um eine Broadcast- oder Multicast-Adresse handelt; siehe Abschnitt 3.2.1.3.

Pfad (Path)

Zu einem bestimmten Zeitpunkt werden alle IP-Datagramme von einem bestimmten Quell-Host zu einem bestimmten Ziel-Host normalerweise dieselbe Gateway-Sequenz durchlaufen. Wir bezeichnen diese Sequenz als „Pfad (Path)“. Beachten Sie, dass der Pfad unidirektional ist; es ist nicht ungewöhnlich, in den beiden Richtungen zwischen einem bestimmten Host-Paar unterschiedliche Pfade zu haben.

MTU

Maximum Transfer Unit, d.h. die maximal übertragbare Paketgröße.

Die Begriffe Rahmen, Paket, Datagramm, Nachricht und Segment werden durch das folgende Schema veranschaulicht:

A. Übertragung auf einem verbundenen Netzwerk:

_______________________________________________
| LL hdr | IP hdr |         (data)              |
|________|________|_____________________________|

<---------- Frame ----------------------------->
         <----------Packet -------------------->

B. Vor IP-Fragmentierung oder nach IP-Reassemblierung:

______________________________________
| IP hdr | transport| Application Data |
|________|____hdr___|__________________|

<--------  Datagram ------------------>
          <-------- Message ----------->

Oder, für TCP:

______________________________________
| IP hdr |  TCP hdr | Application Data |
|________|__________|__________________|

<--------  Datagram ------------------>
          <-------- Segment ----------->

1.4 Danksagungen (Acknowledgments)

Dieses Dokument integriert Beiträge und Kommentare einer großen Zahl von Internet-Protokollexperten (einschließlich Vertretern von Universitäten und Forschungslabors, Anbietern und Regierungsbehörden). Es wurde hauptsächlich vom Host Requirements Working Group der IETF (Internet Engineering Task Force) zusammengestellt.

Der Herausgeber möchte insbesondere den folgenden Personen für ihren unermüdlichen Einsatz danken, die über die letzten 18 Monate an vielen langen Sitzungen teilnahmen und 3 Millionen Byte E-Mail erzeugten, um dieses Dokument zu erreichen: Philip Almquist, Dave Borman (Cray Research), Noel Chiappa, Dave Crocker (DEC), Steve Deering (Stanford), Mike Karels (Berkeley), Phil Karn (Bellcore), John Lekashman (NASA), Charles Lynn (BBN), Keith McCloghrie (TWG), Paul Mockapetris (ISI), Thomas Narten (Purdue), Craig Partridge (BBN), Drew Perkins (CMU) und James Van Bokkelen (FTP Software).

Zudem haben die folgenden Personen wesentliche Beiträge zu dieser Arbeit geleistet: Bill Barns (Mitre), Steve Bellovin (AT&T), Mike Brescia (BBN), Ed Cain (DCA), Annette DeSchon (ISI), Martin Gross (DCA), Phill Gross (NRI), Charles Hedrick (Rutgers), Van Jacobson (LBL), John Klensin (MIT), Mark Lottor (SRI), Milo Medin (NASA), Bill Melohn (Sun Microsystems), Greg Minshall (Kinetics), Jeff Mogul (DEC), John Mullen (CMC), Jon Postel (ISI), John Romkey (Epilogue Technology) und Mike StJohns (DCA). Die folgenden Personen haben ebenfalls in spezifischen Bereichen wichtige Beiträge geleistet: Eric Allman (Berkeley), Rob Austein (MIT), Art Berggreen (ACC), Keith Bostic (Berkeley), Vint Cerf (NRI), Wayne Hathaway (NASA), Matt Korn (IBM), Erik Naggum (Naggum Software, Norway), Robert Ullmann (Prime Computer), David Waitzman (BBN), Frank Wancho (USA), Arun Welch (Ohio State), Bill Westfield (Cisco) und Rayan Zachariassen (Toronto).

Wir danken allen, einschließlich aller Beitragenden, die möglicherweise versehentlich auf der Liste fehlen.