Zum Hauptinhalt springen

RFC 1812 - Anforderungen an IPv4-Router

Status dieses Memos

Dieses Dokument beschreibt ein Internet-Standardprotokoll für die Internet-Gemeinschaft und bittet um Diskussion und Verbesserungsvorschläge. Den aktuellen Stand der Standardisierung dieses Protokolls entnehmen Sie bitte der neuesten Ausgabe von „Internet Official Protocol Standards" (STD 1). Die Verbreitung dieses Memos ist unbeschränkt.

Vorwort​

Dieses Dokument ist eine Aktualisierung von RFC 1716 (dem historischen Router-Anforderungsdokument). Dieses RFC enthielt wichtige Arbeitsergebnisse der Arbeitsgruppe, konnte jedoch die aktuelle Technik nicht ausreichend beschreiben, damit die IESG es als aktuellen Standard anerkennen konnte.

Der aktuelle Herausgeber wurde beauftragt, dieses Dokument so zu aktualisieren, dass es als Beschaffungsspezifikation und Implementierungsleitfaden verwendet werden kann. Dabei stützte er sich vollständig auf die Arbeit seiner Vorgänger und war in hohem Maße auf Texte angewiesen, die von fachkundigen Mitwirkenden bereitgestellt wurden. Alle Verdienste gebühren ihnen; Fehler liegen in seiner Verantwortung.

Inhalt und Form dieses Dokuments sind in hohem Maße dem Vorsitzenden der Arbeitsgruppe sowie dem ursprünglichen Herausgeber und Autor des Dokuments, Philip Almquist, zu verdanken. Ebenso dem früheren Herausgeber Frank Kastenholz. Ohne ihre Bemühungen würde dieses Dokument nicht existieren.

Inhaltsverzeichnis​

1. Einleitung​

Dieses Memo ersetzt RFC 1716 „Requirements for Internet Gateways" ([INTRO:1]).

Dieses Memo definiert und diskutiert die Anforderungen an Geräte, die Netzwerkschicht-Weiterleitungsfunktionen der Internet-Protokollfamilie ausführen. Die Internet-Gemeinschaft bezeichnet solche Geräte üblicherweise als IP-Router (IP routers) oder einfach als Router (routers). Die OSI-Gemeinschaft nennt diese Geräte Zwischensysteme (intermediate systems). Viele ältere Internet-Dokumente bezeichneten diese Geräte als Gateways (gateways); dieser Begriff wird heute kaum noch verwendet, um Verwechslungen mit Anwendungs-Gateways (application gateways) zu vermeiden.

Der Unterschied zwischen IP-Routern und anderen Arten von Paketvermittlungsgeräten besteht darin, dass Router den IP-Protokoll-Header während des Vermittlungsvorgangs untersuchen. In der Regel entfernen sie den beim Empfang einer Nachricht verwendeten Verbindungsschicht-Header, modifizieren den IP-Header und ersetzen den Verbindungsschicht-Header für die Weiterleitung.

Die Autoren und Leser dieses Memos müssen sich bewusst sein, dass viele Router mehrere Protokolle unterstützen. In Zukunft wird ein immer größerer Teil des Internets die Unterstützung von Multiprotokoll-Familien erfordern. Dieses Memo versucht jedoch nicht, Internet-Anforderungen für andere Protokollfamilien als TCP/IP festzulegen.

Dieses Dokument listet die Standardprotokolle auf, die von mit dem Internet verbundenen Routern verwendet werden MÜSSEN, und bezieht durch Verweis RFCs und andere Dokumente ein, die die aktuellen Spezifikationen dieser Protokolle beschreiben. Es korrigiert Fehler in den referenzierten Dokumenten und fügt zusätzliche Diskussionen und Anleitungen für Implementierer hinzu.

Für jedes Protokoll enthält dieses Memo auch eine explizite Menge von Anforderungen, Empfehlungen und Optionen. Der Leser muss verstehen, dass die Anforderungsliste dieses Memos selbst unvollständig ist. Der vollständige Anforderungssatz für einen Internet-Protokoll-Router ist hauptsächlich in den Standard-Protokollspezifikationsdokumenten definiert, kombiniert mit den in diesem Memo enthaltenen Korrekturen, Überarbeitungen und Ergänzungen.

Dieses Memo sollte zusammen mit den Requirements for Internet Hosts RFCs ([INTRO:2] und [INTRO:3]) gelesen werden. Sowohl Internet-Hosts als auch Router müssen in der Lage sein, IP-Datagramme zu initiieren und an sich selbst adressierte IP-Datagramme zu empfangen. Der Hauptunterschied zwischen Internet-Hosts und Routern besteht darin, dass Router den Weiterleitungsalgorithmus implementieren, während Internet-Hosts keine Weiterleitungsfunktion benötigen. Ein Internet-Host, der als Router fungiert, MUSS den in diesem Memo enthaltenen Anforderungen entsprechen.

Das Ziel offener Systeminteroperabilität erfordert, dass Router bei Bedarf korrekt als Internet-Hosts funktionieren MÜSSEN. Um dieses Ziel zu erreichen, bietet dieses Memo Leitlinien für solche Situationen. Zur Vereinfachung und leichteren Aktualisierung des Dokuments vermeidet dieses Memo Überschneidungen mit den Host-Anforderungsdiskussionen in [INTRO:2] und [INTRO:3] und bezieht die relevanten Anforderungen dieser Dokumente durch Verweis ein. In einigen Fällen ersetzt dieses Dokument die in [INTRO:2] und [INTRO:3] angegebenen Anforderungen.

Eine aufrichtige Implementierung, die nach sorgfältigem Lesen der RFCs erstellt wurde, sollte sich von den Anforderungen dieses Memos nur in geringfügigen Details unterscheiden. Die Erstellung einer solchen Implementierung erfordert in der Regel eine gewisse Interaktion mit der Internet-Technikgemeinschaft und die Einhaltung guter Kommunikationssoftware-Engineering-Praktiken. In vielen Fällen sind die Anforderungen dieses Dokuments in gewissem Sinne redundant, da sie bereits explizit oder implizit in den Standard-Protokolldokumenten angegeben sind. Sie wurden aufgenommen, weil einige frühere Implementierungen falsche Entscheidungen getroffen haben, die zu Interoperabilitäts-, Leistungs- und/oder Robustheitsproblemen geführt haben.

Dieses Memo enthält Diskussionen und Erläuterungen zu vielen Anforderungen und Empfehlungen. Eine einfache Anforderungsliste ist gefährlich, weil:

  • Einige Pflichtfunktionen wichtiger sind als andere, und einige Funktionen optional sind.

  • Einige Funktionen für bestimmte Anwendungen eines Routers wichtig, für andere jedoch irrelevant sind.

  • Bestimmte Herstellerprodukte, die für eingeschränkte Umgebungen konzipiert sind, möglicherweise berechtigte Gründe haben, andere Spezifikationen zu verwenden.

Um jedoch das übergeordnete Ziel der Interoperabilität beliebiger Router in der Vielfalt und Komplexität des Internets zu erreichen, MÜSSEN die Spezifikationen dieses Memos eingehalten werden. Obwohl die meisten aktuellen Implementierungen diese Anforderungen in verschiedenen Aspekten (einige geringfügig, einige erheblich) nicht erfüllen, ist diese Spezifikation das Ideal, nach dem wir streben sollten.

Diese Anforderungen basieren auf dem aktuellen Stand der Internet-Architektur. Dieses Memo wird bei Bedarf aktualisiert, um zusätzliche Informationen in Bereichen einzubeziehen, in denen Spezifikationen noch in der Entwicklung sind, oder um weitere Klarstellungen zu liefern.

1.1 Dieses Dokument lesen​

1.1.1 Aufbau​

Dieses Memo orientiert sich an der hierarchischen Struktur, die in [INTRO:2] und [INTRO:3] verwendet wird. Kapitel 2 beschreibt die Schichten der Internet-Architektur. Kapitel 3 behandelt die Verbindungsschicht. Kapitel 4 und 5 konzentrieren sich auf Netzwerkschicht-Protokolle und Weiterleitungsalgorithmen. Kapitel 6 behandelt die Transportschicht. Protokolle der oberen Schichten sind auf die Kapitel 7, 8 und 9 verteilt. Kapitel 7 beschreibt die Protokolle, die Router zum Austausch von Routing-Informationen untereinander verwenden. Kapitel 8 behandelt die Netzwerkverwaltung. Kapitel 9 behandelt andere Protokolle der oberen Schichten. Das letzte Kapitel behandelt Betriebs- und Wartungsfunktionen. Diese Struktur wurde aus Gründen der Einfachheit, Klarheit und Konsistenz mit den Host-Anforderungs-RFCs gewählt. Die Anhänge dieses Memos enthalten Referenzen, ein Glossar und einige Spekulationen über zukünftige Entwicklungen bei Router-Standards.

Bei der Beschreibung von Anforderungen wird angenommen, dass Implementierungen die Protokollhierarchie streng widerspiegeln. Eine strenge Schichtung ist jedoch sowohl für die Protokollfamilie als auch für empfohlene Implementierungsmethoden ein unvollständiges Modell. Protokolle verschiedener Schichten interagieren auf komplexe und manchmal subtile Weise, und bestimmte Funktionen umfassen oft mehrere Schichten. Es gibt viele Designentscheidungen bei der Implementierung, von denen viele eine kreative Durchbrechung der strikten Schichtung beinhalten. Jedem Implementierer wird dringend empfohlen, [INTRO:4] und [INTRO:5] zu lesen.

Jeder Hauptabschnitt dieses Memos ist in folgende Unterabschnitte gegliedert:

(1) Einleitung

(2) Protokoll-Durchgang (Protocol Walk-Through) – betrachtet das Protokollspezifikationsdokument Abschnitt für Abschnitt, korrigiert Fehler, formuliert Anforderungen, die möglicherweise mehrdeutig oder unklar sind, und bietet weitere Klarstellungen oder Erläuterungen.

(3) Spezifische Probleme (Specific Issues) – diskutiert Protokolldesign- und Implementierungsprobleme, die nicht im Durchgang behandelt werden.

Unter vielen einzelnen Themen in diesem Memo befinden sich eingeklammerte Materialien mit der Bezeichnung DISKUSSION oder IMPLEMENTIERUNG. Dieses Material soll eine Begründung, Klarstellung oder Erläuterung des vorangehenden Anforderungstexts liefern. Implementierungsmaterial enthält vorgeschlagene Ansätze, die Implementierer in Betracht ziehen sollten. DISKUSSIONS- und IMPLEMENTIERUNGSABSCHNITTE sind kein Teil des Standards.

1.1.2 Anforderungen​

In diesem Memo werden alle Wörter, die zur Definition der Wichtigkeit einer bestimmten Anforderung verwendet werden, in Großbuchstaben geschrieben. Diese Wörter sind:

  • MUSS (MUST) Dieses Wort bedeutet, dass der Punkt eine absolute Anforderung der Spezifikation ist. Ein Verstoß gegen eine solche Anforderung ist ein grundlegender Fehler. Keine Umstände rechtfertigen ihn.

  • MUSS IMPLEMENTIEREN (MUST IMPLEMENT) Diese Formulierung bedeutet, dass diese Spezifikation die Implementierung des Punktes erfordert, aber nicht unbedingt dessen standardmäßige Aktivierung.

  • DARF NICHT (MUST NOT) Diese Formulierung bedeutet, dass der Punkt ein absolutes Verbot der Spezifikation ist.

  • SOLLTE (SHOULD) Dieses Wort bedeutet, dass es in bestimmten Situationen berechtigte Gründe geben kann, einen bestimmten Punkt zu ignorieren, aber alle Auswirkungen müssen vollständig verstanden und sorgfältig abgewogen werden, bevor ein anderer Weg eingeschlagen wird.

  • SOLLTE IMPLEMENTIEREN (SHOULD IMPLEMENT) Die Bedeutung dieser Formulierung ähnelt SOLLTE, wird jedoch verwendet, wenn eine bestimmte Funktion empfohlen, aber nicht unbedingt standardmäßig aktiviert werden soll.

  • SOLLTE NICHT (SHOULD NOT) Diese Formulierung bedeutet, dass es in bestimmten Situationen berechtigte und nützliche Gründe geben kann, das beschriebene Verhalten zu akzeptieren. Dennoch müssen alle Auswirkungen vollständig verstanden und sorgfältig abgewogen werden, bevor ein mit diesem Label versehenes Verhalten implementiert wird.

  • KANN (MAY) Dieses Wort bedeutet, dass der Punkt wirklich optional ist. Ein Hersteller kann den Punkt einschließen, weil ein bestimmter Markt ihn verlangt oder weil er das Produkt verbessert. Ein anderer Hersteller kann denselben Punkt weglassen.

1.1.3 Konformität​

Einige Anforderungen gelten für alle Router. Andere Anforderungen gelten nur für Router, die bestimmte Funktionen oder Protokolle implementieren. In den folgenden Absätzen bedeutet „relevant" die Vereinigung der Anforderungsmenge, die für alle Router gilt, und der Anforderungsmenge, die für einen bestimmten Router aufgrund der implementierten Funktionen und Protokolle gilt.

Beachten Sie, dass nicht alle relevanten Anforderungen direkt in diesem Memo angegeben sind. Verschiedene Abschnitte dieses Memos beziehen Abschnitte der Host-Anforderungsspezifikationen [INTRO:2] und [INTRO:3] durch Verweis ein. Für die Bestimmung der Konformität mit diesem Memo ist es unerheblich, ob eine relevante Anforderung direkt in diesem Memo angegeben oder nur durch Verweis aus einem dieser Dokumente einbezogen wird.

Eine Implementierung wird als bedingt konform (conditionally compliant) bezeichnet, wenn sie alle relevanten MUSS-, MUSS IMPLEMENTIEREN- und DARF NICHT-Anforderungen erfüllt. Eine Implementierung wird als unbedingt konform (unconditionally compliant) bezeichnet, wenn sie bedingt konform ist und zusätzlich alle relevanten SOLLTE-, SOLLTE IMPLEMENTIEREN- und SOLLTE NICHT-Anforderungen erfüllt. Eine Implementierung, die nicht bedingt konform ist (d. h. eine oder mehrere relevante MUSS-, MUSS IMPLEMENTIEREN- oder DARF NICHT-Anforderungen nicht erfüllt), ist nicht konform.

Diese Spezifikation weist gelegentlich darauf hin, dass eine Implementierung eine Verwaltungsvariable implementieren SOLLTE und einen bestimmten Standardwert haben SOLLTE. Eine unbedingt konforme Implementierung implementiert das Standardverhalten und, falls andere Verhaltensweisen implementiert sind, die Variable. Eine bedingt konforme Implementierung dokumentiert entweder klar, was die Standardeinstellung der Variablen ist, oder was interpretiert werden kann, wenn die Variable nicht implementiert ist. Eine Implementierung, die die Variable nicht implementiert und ein anderes Verhalten wählt, ist nicht konform.

Für SOLLTE- und SOLLTE NICHT-Anforderungen KANN ein Router eine Konfigurationsoption bereitstellen, die den Router dazu veranlasst, sich anders zu verhalten als in der Anforderung angegeben. Das Vorhandensein einer solchen Konfigurationsoption macht die Erklärung der unbedingten Konformität eines Routers nicht ungültig, wenn die Option einen Standardwert hat, der den Router auf die geforderte Weise verhält.

Ebenso KANN ein Router, sofern nicht ausdrücklich durch dieses Memo verboten, Optionen bereitstellen, die MUSS- oder DARF NICHT-Anforderungen verletzen. Ein Router, der solche Optionen bereitstellt, ist nur dann (vollständig oder bedingt) konform, wenn jede solche Option einen Standardwert hat, der den Router konform mit diesem Memo verhält. Die Autoren dieses Memos erkennen die Marktgegebenheiten an, empfehlen jedoch dringend, solche Optionen nicht bereitzustellen. Anforderungen sind als MUSS oder DARF NICHT gekennzeichnet, weil Experten auf diesem Gebiet sie als besonders wichtig für die Interoperabilität oder das ordnungsgemäße Funktionieren im Internet erachten. Hersteller sollten die Kundensupportkosten sorgfältig abwägen, die durch das Bereitstellen von Optionen entstehen, die gegen diese Regeln verstoßen.

Natürlich ist dieses Memo keine vollständige Spezifikation eines IP-Routers; es ist eher das, was in der OSI-Welt als Profil (profile) bezeichnet wird. Dieses Memo erfordert beispielsweise die Implementierung vieler Protokolle. Der Großteil dieser Protokollspezifikationen wird in diesem Memo nicht wiederholt, aber Implementierer müssen die Protokolle gemäß diesen Spezifikationen implementieren.

1.2 Beziehungen zu anderen Standards​

Bei der Untersuchung von Protokollspezifikationen und Standardisierungsstatus gibt es mehrere relevante Referenzdokumente:

  • INTERNET OFFICIAL PROTOCOL STANDARDS

    Dieses Dokument beschreibt den Internet-Standardisierungsprozess und listet den Standardstatus von Protokollen auf. Zum Zeitpunkt der Erstellung war die aktuelle Version dieses Dokuments STD 1, RFC 1780, [ARCH:7]. Dieses Dokument wird regelmäßig neu herausgegeben. Es sollte stets das RFC-Repository konsultiert und die neueste Version dieses Dokuments verwendet werden.

  • Assigned Numbers (Zugewiesene Nummern)

    Dieses Dokument listet die zugewiesenen Werte von Parametern auf, die in verschiedenen Protokollen verwendet werden, z. B. IP-Protokollcodes, TCP-Portnummern, Telnet-Optionscodes, ARP-Hardwaretypen und Terminaltyp-Namen. Zum Zeitpunkt der Erstellung war die aktuelle Version dieses Dokuments STD 2, RFC 1700, [INTRO:7]. Dieses Dokument wird regelmäßig neu herausgegeben. Es sollte stets das RFC-Repository konsultiert und die neueste Version verwendet werden.

  • Host Requirements (Host-Anforderungen)

    Dieses Dokumentenpaar überprüft die für Hosts geltenden Spezifikationen und bietet Leitlinien und Klarstellungen zu Mehrdeutigkeiten. Beachten Sie, dass diese Anforderungen auch für Router gelten, sofern in diesem Memo nicht anders angegeben. Zum Zeitpunkt der Erstellung waren die aktuellen Versionen dieser Dokumente RFC 1122 und RFC 1123 (STD 3), [INTRO:2] und [INTRO:3].

  • Router Requirements (Router-Anforderungen, früher Gateway-Anforderungen)

    Dieses Memo.

Beachten Sie, dass diese Dokumente zu unterschiedlichen Zeiten überarbeitet und aktualisiert werden. Bei Unstimmigkeiten zwischen diesen Dokumenten MUSS das neueste Vorrang haben.

Diese und andere Internet-Protokolldokumente sind unter folgender Adresse erhältlich:

The InterNIC
DS.INTERNIC.NET
InterNIC Directory and Database Service
[email protected]
+1-908-668-6587
URL: http://ds.internic.net/

1.3 Allgemeine Überlegungen​

Internet-Software-Hersteller haben einige wichtige Lektionen gelernt, die neue Hersteller ernsthaft in Betracht ziehen sollten.

1.3.1 Kontinuierliche Weiterentwicklung des Internets​

Das enorme Wachstum des Internets hat Probleme bei der Verwaltung und Skalierung großer Datagramm-Paketkommunikationssysteme aufgezeigt. Da diese Probleme gelöst werden, werden sich die in diesem Memo beschriebenen Spezifikationen weiterentwickeln. Neue Routingprotokolle, Algorithmen und Architekturen werden kontinuierlich entwickelt. Neue Netzwerkschichtprotokolle und Änderungen an bestehenden Protokollen werden ebenfalls kontinuierlich entworfen. Router spielen eine wichtige Rolle im Internet, und die Anzahl der im Internet eingesetzten Router ist viel geringer als die Anzahl der Hosts. Daher sollten Hersteller damit rechnen, dass sich Router-Standards schneller weiterentwickeln als Host-Standards. Diese Änderungen werden sorgfältig geplant und kontrolliert, da Hersteller und für den Netzbetrieb verantwortliche Organisationen breit an der Planung beteiligt sind.

Entwicklung, Evolution und Überarbeitung sind Merkmale heutiger Computernetzwerkprotokolle, und diese Situation wird noch einige Jahre andauern. Hersteller, die Computerkommunikationssoftware für die Internet-Protokollfamilie (oder eine andere Protokollfamilie!) entwickeln und diese Software dann nicht pflegen und aktualisieren, um sich ändernden Spezifikationen gerecht zu werden, werden eine Reihe unzufriedener Kunden hinterlassen. Das Internet ist ein großes Kommunikationsnetz, und Benutzer stehen ständig in Kontakt. Die Erfahrung zeigt, dass Kenntnisse über Mängel in Herstellersoftware sich sehr schnell in der Internet-Technikgemeinschaft verbreiten.

1.3.2 Robustheitsprinzip​

Auf allen Protokollschichten gibt es eine allgemeine Regel von Jon Postel aus [TRANS:2], deren Anwendung große Vorteile für Robustheit und Interoperabilität bringen kann:

Sei konservativ in dem, was du sendest,
und tolerant in dem, was du von anderen akzeptierst.

Software muss so geschrieben werden, dass sie jeden erdenklichen Fehler behandelt, egal wie unwahrscheinlich er erscheint. Irgendwann wird ein Paket mit genau dieser Fehler- und Attributkombination eintreffen, und wenn die Software nicht vorbereitet ist, gerät sie in Verwirrung. Es ist am besten anzunehmen, dass das Netzwerk mit bösartigen Entitäten gefüllt ist, die Pakete senden, die darauf ausgelegt sind, die schlimmsten Auswirkungen zu erzeugen. Diese Annahme führt zu einem angemessenen Schutzdesign. Die schwerwiegendsten Probleme im Internet werden durch unerwartete Mechanismen verursacht, die durch Ereignisse mit geringer Wahrscheinlichkeit ausgelöst werden. Einfache menschliche Bosheit nimmt nie so verschlungene Wege!

Die Fähigkeit zur Anpassung an Veränderungen muss in alle Schichten der Router-Software eingebaut werden. Als einfaches Beispiel betrachte man eine Protokollspezifikation, die eine Aufzählung möglicher Werte eines bestimmten Header-Felds enthält, z. B. ein Typfeld, eine Portnummer oder einen Fehlercode. Diese Aufzählung muss als unvollständig angesehen werden. Wenn eine Protokollspezifikation vier mögliche Fehlercodes definiert, darf die Software nicht abstürzen, wenn ein fünfter Code definiert wird. Undefinierte Codes können protokolliert werden, dürfen aber niemals einen Fehler verursachen.

Der zweite Teil des Prinzips ist fast ebenso wichtig: Software auf Hosts oder anderen Routern kann Fehler enthalten, und es ist daher unklug, legitime, aber obskure Protokollfunktionen zu nutzen. Es ist unklug, von offensichtlichen und einfachen Praktiken abzuweichen, da dies anderswo nachteilige Auswirkungen haben kann. Die Konsequenz dieses Punktes lautet: Achten Sie auf fehlerhafte Hosts. Router-Software muss in der Lage sein, in Gegenwart fehlerhafter Hosts zu überleben. Eine der wichtigen Funktionen von Routern im Internet ist es, den Schaden zu begrenzen, den solche Hosts an gemeinsam genutzten Kommunikationseinrichtungen verursachen können.

1.3.3 Fehlerprotokollierung​

Das Internet enthält eine Vielzahl von Systemen, von denen jedes viele Protokolle und Protokollschichten implementiert. Einige davon enthalten Fehler oder irreführende Funktionen in der Internet-Protokollsoftware. Aufgrund der Komplexität, Vielfalt und Verteilung der Funktionen kann die Diagnose von Problemen sehr schwierig sein.

Wenn Router eine sorgfältig gestaltete Einrichtung zur Protokollierung von Fehlern oder ungewöhnlichen Ereignissen enthalten, hilft dies bei der Diagnose von Problemen. Bei der Protokollierung von Fehlern ist es wichtig, so viele Diagnoseinformationen wie möglich einzuschließen. Insbesondere ist es oft nützlich, die Header des Pakets zu protokollieren, das den Fehler verursacht hat. Es muss jedoch darauf geachtet werden, dass die Fehlerprotokollierung keine übermäßigen Ressourcen verbraucht oder den Betrieb des Routers anderweitig beeinträchtigt.

Ungewöhnliche, aber harmlose Protokollereignisse neigen dazu, Fehlerprotokolldateien zu überfluten. Dies kann durch die Verwendung von Umlaufprotokollen oder durch die Aktivierung der Protokollierung nur bei der Diagnose bekannter Fehler vermieden werden. Es kann nützlich sein, doppelte aufeinanderfolgende Meldungen zu filtern und zu zählen. Eine Strategie, die sich als sehr effektiv erwiesen hat, ist gleichzeitig:

  • Ungewöhnliche Situationen immer zu zählen und diese Zählungen über Verwaltungsprotokolle zugänglich zu machen (siehe Kapitel 8); und
  • Die selektive Aktivierung der Protokollierung verschiedener Ereignisse zu ermöglichen, z. B. die Protokollierung von allem oder die Protokollierung von allem für Host X.

Dieses Thema wird in [MGT:5] weiter diskutiert.

1.3.4 Konfiguration​

In einer idealen Welt wären Router einfach zu konfigurieren und könnten sich sogar vollständig selbst konfigurieren. Die praktische Erfahrung in der realen Welt zeigt jedoch, dass dies ein unerreichbares Ziel ist, und viele Versuche von Herstellern, die Konfiguration zu vereinfachen, haben Kunden tatsächlich mehr Probleme bereitet als verhindert. Als extremes Beispiel: Ein Router, der ohne Konfigurationsinformationen startet und beginnt, Pakete zu routen, wird mit ziemlicher Sicherheit einige falsche Parameter wählen und ernsthafte Probleme in den angeschlossenen unglücklichen Netzwerken verursachen.

Dieses Memo verlangt häufig, dass Parameter konfigurierbare Optionen sein müssen. Dafür gibt es mehrere Gründe. In einigen wenigen Fällen gibt es derzeit eine gewisse Unsicherheit oder Meinungsverschiedenheit über den optimalen Wert, und der empfohlene Wert muss möglicherweise in Zukunft aktualisiert werden. In anderen Fällen hängt der Wert von externen Faktoren ab, z. B. der Verteilung der Kommunikationslast oder der Geschwindigkeit und Topologie benachbarter Netzwerke, und es sind keine selbstanpassenden Algorithmen verfügbar oder ausreichend. In einigen Fällen ist Konfigurierbarkeit aus Verwaltungsgründen erforderlich.

Schließlich sind einige Konfigurationsoptionen für die Kommunikation mit älteren oder fehlerhaften Implementierungen von Protokollen erforderlich, die in vielen Teilen des Internets vorhanden sind und für die kein Quellcode verfügbar ist. Damit korrekte Systeme mit diesen fehlerhaften Systemen koexistieren können, müssen Administratoren korrekte Systeme gelegentlich falsch konfigurieren. Dieses Problem löst sich mit der Außerbetriebnahme fehlerhafter Systeme allmählich von selbst, kann aber von Herstellern nicht ignoriert werden.

Wenn wir sagen, dass ein Parameter konfigurierbar sein muss, meinen wir nicht, dass sein Wert bei jedem Start explizit aus einer Konfigurationsdatei gelesen werden muss. Viele Parameter haben Werte, die für alle außer den ungewöhnlichsten Situationen geeignet sind. In diesem Fall ist es sehr vernünftig, dass der Parameter auf diesen Wert zurückfällt, wenn er nicht explizit gesetzt wird.

In einigen Fällen verlangt dieses Memo bestimmte Werte für solche Standardwerte. Wenn ein Konfigurationselement die Anpassung an bestehende fehlerhafte Systeme steuert, ist die Wahl des Standardwerts eine heikle Angelegenheit. Damit das Internet erfolgreich zur vollständigen Interoperabilität konvergiert, müssen die in Implementierungen eingebauten Standardwerte das offizielle Protokoll implementieren, nicht eine Fehlkonfiguration zur Anpassung an fehlerhafte Implementierungen. Die Marktgegebenheiten werden dazu führen, dass einige Hersteller fehlerhafte Standardwerte wählen, aber wir fordern Hersteller dringend auf, standardkonforme Standardwerte zu wählen.

Schließlich sei darauf hingewiesen, dass Hersteller eine ausreichende Dokumentation aller Konfigurationsparameter, ihrer Grenzen und Auswirkungen bereitstellen müssen.

1.4 Algorithmen​

An einigen Stellen in diesem Memo werden spezifische Algorithmen angegeben, denen Router folgen sollen. Diese Algorithmen selbst sind keine Pflichtanforderungen für Router. Ein Router muss nicht jeden Algorithmus genau so implementieren, wie er in diesem Dokument beschrieben ist. Stattdessen muss eine Implementierung der Außenwelt dasselbe Verhalten präsentieren wie eine strenge, wörtliche Implementierung des angegebenen Algorithmus.

Die Art und Weise, wie Algorithmen beschrieben werden, unterscheidet sich von der Art und Weise, wie ein guter Implementierer sie implementieren würde. Für Erklärungszwecke wurde ein Stil gewählt, der Prägnanz, Klarheit und Unabhängigkeit von Implementierungsdetails betont. Ein guter Implementierer wird Algorithmen und Implementierungsmethoden wählen, die dieselben Ergebnisse wie diese Algorithmen erzeugen, aber möglicherweise effizienter oder weniger allgemein sind.

Beachten Sie, dass die Technik effizienter Router-Implementierungen den Rahmen dieses Memos übersteigt.

Letztes Update am