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
- 2. Internetarchitektur
- 3. Verbindungsschicht
- 4. Internetschicht - Protokolle
- 5. Internetschicht - Weiterleitung
- 6. Transportschicht
- 7. Anwendungsschicht - Routingprotokolle
- 8. Anwendungsschicht - Netzwerkverwaltungsprotokolle
- 9. Anwendungsschicht - Sonstige Protokolle
- 10. Betrieb und Wartung
- 11. Referenzen
- Anhang A. Anforderungen an Source-Routing-Hosts
- Anhang B. Glossar
- Anhang C. Zukünftige Entwicklungen
- Anhang D. Multicast-Routingprotokolle
- Anhang E. Zusätzliche Next-Hop-Auswahlalgorithmen
- Anhang F. Historische Routingprotokolle
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
info@internic.net
+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.
2. INTERNET-ARCHITEKTUR
Dieses Kapitel enthält keine Anforderungen. Es enthält jedoch nützliche Hintergrundinformationen zur allgemeinen Architektur des Internets und von Routern.
Allgemeine Hintergrundinformationen und Erörterungen zur Internet-Architektur und zum unterstützenden Protokoll-Stack finden sich im DDN Protocol Handbook [ARCH:1]; als Hintergrund siehe beispielsweise [ARCH:2], [ARCH:3] und [ARCH:4]. Die Internet-Architektur und -Protokolle werden auch in einer wachsenden Zahl von Lehrbüchern behandelt, wie [ARCH:5] und [ARCH:6].
2.1 Einleitung
Das Internetsystem besteht aus einer Reihe miteinander verbundener Paketnetze, die die Kommunikation zwischen Host-Rechnern unter Verwendung der Internet-Protokolle unterstützen. Diese Protokolle umfassen das Internet Protocol (IP), das Internet Control Message Protocol (ICMP), das Internet Group Management Protocol (IGMP) und eine Reihe von Transport- und Anwendungsprotokollen, die von ihnen abhängen. Wie in Abschnitt [1.2] beschrieben, veröffentlicht die Internet Engineering Steering Group periodisch ein Official Protocols-Memo, das alle Internet-Protokolle auflistet.
Alle Internet-Protokolle verwenden IP als grundlegenden Datentransportmechanismus. IP ist ein Datagramm- oder verbindungsloser Internetwork-Dienst und umfasst Bestimmungen für Adressierung, Type-of-Service-Spezifikation, Fragmentierung und Reassemblierung sowie Sicherheit. ICMP und IGMP werden als integrale Bestandteile von IP betrachtet, obwohl sie architektonisch über IP geschichtet sind. ICMP bietet Fehlerberichterstattung, Flusskontrolle, First-Hop-Router-Umleitung und andere Wartungs- und Steuerungsfunktionen. IGMP stellt die Mechanismen bereit, mit denen Hosts und Router IP-Multicast-Gruppen beitreten und verlassen können.
Zuverlässige Datenübermittlung wird im Internet-Protokoll-Stack durch Transport-Layer-Protokolle wie das Transmission Control Protocol (TCP) bereitgestellt, das End-to-End-Neuübertragung, Neuanordnung und Verbindungssteuerung bietet. Transport-Layer-Verbindungsloser Dienst wird durch das User Datagram Protocol (UDP) bereitgestellt.
2.2 Elemente der Architektur
2.2.1 Protokoll-Schichtung
Um mit dem Internetsystem zu kommunizieren, muss ein Host den geschichteten Satz von Protokollen implementieren, aus denen der Internet-Protokoll-Stack besteht. Ein Host muss typischerweise mindestens ein Protokoll aus jeder Schicht implementieren.
Die im Internet verwendeten Protokollschichten sind wie folgt [ARCH:7]:
o Application Layer (Anwendungsschicht) Die Application Layer ist die oberste Schicht des Internet-Protokoll-Stacks. Der Internet-Stack unterteilt die Application Layer nicht weiter, obwohl einige Anwendungsschicht-Protokolle eine interne Sub-Schichtung enthalten. Die Anwendungsschicht des Internet-Stacks kombiniert im Wesentlichen die Funktionen der beiden obersten Schichten - Presentation und Application - des OSI-Referenzmodells [ARCH:8]. Die Application Layer im Internet-Protokoll-Stack umfasst auch einige der Funktionen, die im OSI-Referenzmodell der Session Layer zugeordnet sind.
Wir unterscheiden zwei Kategorien von Application-Layer-Protokollen: Benutzerprotokolle, die Dienste direkt für Benutzer bereitstellen, und Support-Protokolle, die allgemeine Systemfunktionen bereitstellen. Die gebräuchlichsten Internet-Benutzerprotokolle sind:
- Telnet (Remote Login)
- FTP (Dateiübertragung)
- SMTP (E-Mail-Zustellung)
Es gibt eine Reihe weiterer standardisierter Benutzerprotokolle und viele private Benutzerprotokolle.
Support-Protokolle, die für Host-Namenszuordnung, Booting und Verwaltung verwendet werden, umfassen SNMP, BOOTP, TFTP, das Domain Name System (DNS)-Protokoll und eine Reihe von Routing-Protokollen.
Anwendungsschicht-Protokolle, die für Router relevant sind, werden in den Kapiteln 7, 8 und 9 dieses Memos erörtert.
o Transport Layer (Transportschicht) Die Transport Layer bietet End-to-End-Kommunikationsdienste. Diese Schicht entspricht ungefähr der Transport Layer des OSI-Referenzmodells, mit der Ausnahme, dass sie auch einige der Establishment- und Destruction-Funktionen der OSI-Session Layer integriert.
Es gibt derzeit zwei primäre Transport-Layer-Protokolle:
- Transmission Control Protocol (TCP)
- User Datagram Protocol (UDP)
TCP ist ein zuverlässiger verbindungsorientierter Transportdienst, der End-to-End-Zuverlässigkeit, Neuanordnung und Flusskontrolle bietet. UDP ist ein verbindungsloser (Datagramm-)Transportdienst. Weitere Transportprotokolle wurden von der Forschungsgemeinschaft entwickelt, und der Satz der offiziellen Internet-Transportprotokolle kann in Zukunft erweitert werden.
Transport-Layer-Protokolle, die für Router relevant sind, werden in Kapitel 6 erörtert.
o Internet Layer Alle Internet-Transportprotokolle verwenden das Internet Protocol (IP), um Daten vom Quell-Host zum Ziel-Host zu transportieren. IP ist ein verbindungsloser oder Datagramm-Internetwork-Dienst, der keine End-to-End-Zustellungsgarantien bietet. IP-Datagramme können beim Ziel-Host beschädigt, dupliziert, ungeordnet oder gar nicht ankommen. Die über IP liegenden Schichten sind für den zuverlässigen Zustelldienst verantwortlich, wenn dieser benötigt wird. Das IP-Protokoll umfasst Bestimmungen für Adressierung, Type-of-Service-Spezifikation, Fragmentierung und Reassemblierung sowie Sicherheit.
Die Datagramm- oder verbindungslose Natur von IP ist ein grundlegendes und charakteristisches Merkmal der Internet-Architektur.
Das Internet Control Message Protocol (ICMP) ist ein Steuerungsprotokoll, das als integraler Bestandteil von IP betrachtet wird, obwohl es architektonisch über IP geschichtet ist - es verwendet IP, um seine Daten End-to-End zu transportieren. ICMP bietet Fehlerberichterstattung, Stau-Berichterstattung und First-Hop-Router-Umleitung.
Das Internet Group Management Protocol (IGMP) ist ein Internet-Layer-Protokoll, das zur Einrichtung dynamischer Host-Gruppen für IP-Multicasting verwendet wird.
Die Internet-Layer-Protokolle IP, ICMP und IGMP werden in Kapitel 4 erörtert.
o Link Layer Um in einem direkt verbundenen Netz zu kommunizieren, muss ein Host das Kommunikationsprotokoll implementieren, das zur Schnittstelle zu diesem Netz verwendet wird. Wir nennen dies ein Link-Layer-Protokoll.
Einige ältere Internet-Dokumente bezeichnen diese Schicht als Network Layer, aber sie ist nicht identisch mit der Network Layer des OSI-Referenzmodells.
Diese Schicht enthält alles unterhalb der Internet Layer und oberhalb der Physical Layer (die die Medienkonnektivität darstellt, normalerweise elektrisch oder optisch, die Nachrichten codiert und transportiert). Ihre Verantwortung ist die korrekte Zustellung von Nachrichten, zwischen denen sie nicht unterscheidet.
Protokolle in dieser Schicht liegen im Allgemeinen außerhalb des Bereichs der Internet-Standardisierung; das Internet verwendet (absichtlich) nach Möglichkeit bestehende Standards. Daher adressieren Internet-Link-Layer-Standards normalerweise nur Adressauflösung und Regeln für die Übertragung von IP-Paketen über spezifische Link-Layer-Protokolle. Internet-Link-Layer-Standards werden in Kapitel 3 erörtert.
2.2.2 Netze
Die konstituierenden Netze des Internetsystems müssen nur Paket- (verbindungslosen) Transport bereitstellen. Gemäß der IP-Dienstspezifikation können Datagramme ungeordnet zugestellt werden, verloren gehen oder dupliziert werden und/oder Fehler enthalten.
Für eine angemessene Leistung der Protokolle, die IP verwenden (z. B. TCP), sollte die Verlustrate des Netzes sehr niedrig sein. In Netzen, die verbindungsorientierten Dienst bereitstellen, erhöht die zusätzliche Zuverlässigkeit, die durch virtuelle Schaltungen geboten wird, die End-to-End-Robustheit des Systems, ist aber für den Internet-Betrieb nicht erforderlich.
Konstituierende Netze lassen sich im Allgemeinen in zwei Klassen einteilen:
o Local-Area Networks (LANs)
LANs können eine Vielzahl von Designs haben. LANs decken normalerweise ein kleines geographisches Gebiet ab (z. B. ein einzelnes Gebäude oder Werkgelände) und bieten hohe Bandbreite bei niedrigen Verzögerungen. LANs können passiv sein (ähnlich wie Ethernet) oder aktiv (wie ATM).
o Wide-Area Networks (WANs)
Geographisch verstreute Hosts und LANs werden durch Wide-Area Networks, auch long-haul networks genannt, miteinander verbunden. Diese Netze können eine komplexe interne Struktur aus Leitungen und Paketvermittlungsknoten aufweisen oder so einfach wie Point-to-Point-Leitungen sein.
2.2.3 Router
Im Internet-Modell werden die konstituierenden Netze durch IP-Datagramm-Forwarder verbunden, die als Router oder IP-Router bezeichnet werden. In diesem Dokument ist jede Verwendung des Begriffs Router äquivalent zu IP-Router. Viele ältere Internet-Dokumente bezeichnen Router als Gateways.
Historisch wurden Router mit Paketvermittlungs-Software realisiert, die auf einer General-Purpose-CPU ausgeführt wird. Da jedoch die Entwicklung von Custom-Hardware günstiger wird und höherer Durchsatz erforderlich ist, wird spezielle Hardware zunehmend üblicher. Diese Spezifikation gilt für Router unabhängig davon, wie sie implementiert sind.
Ein Router verbindet sich mit zwei oder mehr logischen Schnittstellen, die durch IP-Subnetze oder unnummerierte Point-to-Point-Leitungen (in Abschnitt [2.2.7] erörtert) dargestellt werden. Daher hat er mindestens eine physische Schnittstelle. Das Forwarding eines IP-Datagramms erfordert normalerweise, dass der Router die Adresse und die relevante Schnittstelle des Next-Hop-Routers oder (für den letzten Hop) des Ziel-Hosts wählt. Diese Wahl, genannt Relaying oder Forwarding, hängt von einer Routen-Datenbank innerhalb des Routers ab. Die Routen-Datenbank wird auch als Routing-Tabelle oder Forwarding-Tabelle bezeichnet. Der Begriff "Router" leitet sich vom Prozess des Aufbaus dieser Routen-Datenbank ab; Routing-Protokolle und Konfiguration interagieren in einem Prozess namens Routing.
Die Routing-Datenbank sollte dynamisch gepflegt werden, um die aktuelle Topologie des Internetsystems widerzuspiegeln. Ein Router erreicht dies normalerweise durch die Teilnahme an verteilten Routing- und Erreichbarkeitsalgorithmen mit anderen Routern.
Router bieten nur Datagramm-Transport und bemühen sich, die zur Aufrechterhaltung dieses Dienstes notwendigen Zustandsinformationen im Interesse der Routing-Flexibilität und -Robustheit zu minimieren.
Paketvermittlungsgeräte können auch auf der Link Layer betreiben; solche Geräte werden normalerweise Bridges genannt. Netzsegmente, die durch Bridges verbunden sind, teilen sich denselben IP-Netzpräfix und bilden ein einzelnes IP-Subnetz. Diese anderen Geräte liegen außerhalb des Bereichs dieses Dokuments.
2.2.4 Autonome Systeme
Ein Autonomous System (AS) ist ein verbundenes Segment einer Netzwerktopologie, das aus einer Sammlung von Subnetzen (mit angehängten Hosts) besteht, die durch einen Satz von Routen miteinander verbunden sind. Die Subnetze und die Router sollen unter der Kontrolle einer einzigen Operations and Maintenance (O&M)-Organisation stehen. Innerhalb eines AS können Router ein oder mehrere Interior-Routing-Protokolle und manchmal mehrere Sätze von Metriken verwenden. Ein AS soll anderen ASs den Anschein eines kohärenten Interior-Routing-Plans und ein konsistentes Bild der über den AS erreichbaren Ziele vermitteln. Ein AS wird durch eine Autonomous System Number identifiziert.
Das Konzept eines AS spielt eine wichtige Rolle im Internet-Routing (siehe Abschnitt 7.1).
2.2.5 Adressierungsarchitektur
Ein IP-Datagramm trägt 32-Bit-Quell- und Zieladressen, von denen jede in zwei Teile partitioniert ist - ein konstituierender Netzpräfix und eine Host-Nummer in diesem Netz. Symbolisch:
IP-address ::= { <Network-prefix>, <Host-number> }
Um das Datagramm endgültig zuzustellen, muss der letzte Router in seinem Pfad den Host-number- (oder rest-)Teil einer IP-Adresse der Link-Layer-Adresse des Hosts zuordnen.
2.2.5.1 Klassische IP-Adressierungsarchitektur
Obwohl andernorts gut dokumentiert [INTERNET:2], ist es nützlich, den historischen Gebrauch des Netzpräfix zu beschreiben. Die Sprache, die entwickelt wurde, um ihn zu beschreiben, wird in diesem und anderen Dokumenten verwendet und durchdringt das Denken hinter vielen Protokollen.
Der einfachste klassische Netzpräfix ist der Class-A-, B-, C-, D- oder E-Netzpräfix. Diese Adressbereiche werden durch Beobachtung der Werte der höchstwertigen Bits der Adresse unterschieden und brechen die Adresse in einfache Präfix- und Host-Nummer-Felder auf. Dies ist in [INTERNET:18] beschrieben. Kurz gesagt ist die Klassifikation:
0xxx - Class A - generische Unicast-Adressen mit Standard-8-Bit-Präfix
10xx - Class B - generische Unicast-Adressen mit Standard-16-Bit-Präfix
110x - Class C - generische Unicast-Adressen mit Standard-24-Bit-Präfix
1110 - Class D - IP-Multicast-Adressen - 28-Bit-Präfix, nicht aggregierbar
1111 - Class E - für experimentelle Nutzung reserviert
Dieser einfache Begriff wurde durch das Konzept der Subnetze erweitert. Diese wurden eingeführt, um beliebige Komplexität von miteinander verbundenen LAN-Strukturen innerhalb einer Organisation zu erlauben, während das Internetsystem gegen explosionsartiges Wachstum zugewiesener Netzpräfixe und Routing-Komplexität isoliert wird. Subnetze bieten eine mehrschichtige hierarchische Routing-Struktur für das Internetsystem. Die Subnetz-Erweiterung, in [INTERNET:2] beschrieben, ist ein erforderlicher Teil der Internet-Architektur. Die Grundidee ist, das
IP-address ::=
{ <Network-number>, <Subnet-number>, <Host-number> }
Die miteinander verbundenen physischen Netze innerhalb einer Organisation verwenden denselben Netzpräfix, aber unterschiedliche Subnet-Nummern. Der Unterschied zwischen den Subnetzen eines solchen subnettierten Netzes ist normalerweise außerhalb dieses Netzes nicht sichtbar. Daher verwendet das Routing im Rest des Internets nur den
{ <Network-number>, <Subnet-number> }
Die Bitpositionen, die diese erweiterte Netznummer enthalten, wurden historisch durch eine 32-Bit-Maske namens Subnetz-Maske angezeigt. Die
Die Erfinder des Subnetz-Mechanismus nahmen an, dass jedes Stück eines Netzes einer Organisation nur eine einzige Subnet-Nummer hätte. In der Praxis hat es sich oft als notwendig oder nützlich erwiesen, mehrere Subnetze ein einziges physisches Kabel teilen zu lassen. Aus diesem Grund SOLLTEN (SHOULD) Router in der Lage sein, mehrere Subnetze auf denselben physischen Schnittstellen zu konfigurieren und sie (aus Routing- oder Forwarding-Sicht) so zu behandeln, als wären sie verschiedene physische Schnittstellen.
2.2.5.2 Classless Inter Domain Routing (CIDR)
Das explosionsartige Wachstum des Internets hat eine Überprüfung der Adresszuweisungsrichtlinien erzwungen. Die traditionelle Nutzung von generischen (Class-A-, B- und C-)Netzen wurde modifiziert, um eine bessere Nutzung des 32-Bit-Adressraums von IP zu erreichen. Classless Inter Domain Routing (CIDR) [INTERNET:15] ist eine Methode, die derzeit in den Internet-Backbones eingesetzt wird, um diese zusätzliche Effizienz zu erreichen. CIDR hängt von der Bereitstellung und dem Routing zu beliebig großen Netzen ab. In diesem Modell machen Hosts und Router keine Annahmen über die Verwendung der Adressierung im Internet. Der Class-D- (IP-Multicast-) und Class-E- (Experimentell-)Adressraum werden beibehalten, obwohl dies primär eine Zuweisungsrichtlinie ist.
Definitionsgemäß umfasst CIDR drei Elemente:
o topologisch signifikante Adresszuweisung,
o Routing-Protokolle, die in der Lage sind, Netzwerkschicht-Erreichbarkeitsinformationen zu aggregieren, und
o konsistenter Forwarding-Algorithmus ("longest match").
Die Verwendung von Netzen und Subnetzen ist nun historisch, obwohl die Sprache, die zu ihrer Beschreibung verwendet wird, weiterhin in Gebrauch ist. Sie wurden durch das besser handhabbare Konzept eines Netzpräfix ersetzt. Ein Netzpräfix ist definitionsgemäß ein zusammenhängender Satz von Bits am bedeutenderen Ende der Adresse, der eine Menge von Systemen definiert; Host-Nummern wählen unter diesen Systemen aus. Es gibt keine Anforderung, dass das gesamte Internet einheitlich Netzpräfixe verwendet. Um Routing-Informationen zu kollabieren, ist es nützlich, das Internet in Adressierungsdomänen zu unterteilen. Innerhalb einer solchen Domäne sind detaillierte Informationen über konstituierende Netze verfügbar; außerhalb werden nur der gemeinsame Netzpräfix angekündigt.
Die klassische IP-Adressierungsarchitektur verwendete Adressen und Subnetz-Masken, um die Host-Nummer von dem Netzpräfix zu unterscheiden. Bei Netzpräfixen genügt es, die Anzahl der Bits im Präfix anzugeben. Beide Darstellungen sind gebräuchlich. Architektonisch korrekte Subnetz-Masken sind fähig, durch die Präfixlängenbeschreibung dargestellt zu werden. Sie umfassen jene Teilmenge aller möglichen Bitmuster, die aufweisen:
o eine zusammenhängende Kette von Einsen am bedeutenderen Ende,
o eine zusammenhängende Kette von Nullen am weniger bedeutenden Ende, und
o keine dazwischenliegenden Bits.
Router SOLLTEN (SHOULD) immer eine Route als Netzpräfix behandeln und Konfigurations- und Routing-Informationen, die mit diesem Modell unvereinbar sind, zurückweisen.
IP-address ::= { <Network-prefix>, <Host-number> }
Eine Wirkung der Verwendung von CIDR ist, dass die Menge der mit Adresspräfixen in der Routing-Tabelle verbundenen Ziele eine Teilmengenbeziehung aufweisen kann. Eine Route, die eine kleinere Menge von Zielen beschreibt (ein längeres Präfix), wird als spezifischer bezeichnet als eine Route, die eine größere Menge von Zielen beschreibt (ein kürzeres Präfix); ähnlich wird eine Route, die eine größere Menge von Zielen beschreibt (ein kürzeres Präfix), als weniger spezifisch bezeichnet als eine Route, die eine kleinere Menge von Zielen beschreibt (ein längeres Präfix). Router MÜSSEN (MUST) die spezifischste übereinstimmende Route (das längste übereinstimmende Netzpräfix) verwenden, wenn sie Datenverkehr weiterleiten.
2.2.6 IP-Multicasting
IP-Multicasting ist eine Erweiterung von Link-Layer-Multicast auf IP-Internets. Unter Verwendung von IP-Multicasts kann ein einzelnes Datagramm an mehrere Hosts adressiert werden, ohne es an alle zu senden. Im erweiterten Fall können diese Hosts in verschiedenen Adressdomänen resideren. Diese Sammlung von Hosts wird eine Multicast-Gruppe genannt. Jede Multicast-Gruppe wird durch eine Class-D-IP-Adresse dargestellt. Ein an die Gruppe gesendetes IP-Datagramm soll jedem Gruppenmitglied mit derselben Best-Effort-Zustellung zugestellt werden wie für Unicast-IP-Verkehr bereitgestellt. Der Sender des Datagramms muss selbst kein Mitglied der Zielgruppe sein.
Die Semantik der IP-Multicast-Gruppenmitgliedschaft ist in [INTERNET:4] definiert. Jenes Dokument beschreibt, wie Hosts und Router Multicast-Gruppen beitreten und verlassen. Es definiert auch ein Protokoll, das Internet Group Management Protocol (IGMP), das die IP-Multicast-Gruppenmitgliedschaft überwacht.
Das Forwarding von IP-Multicast-Datagrammen wird entweder durch statische Routing-Informationen oder über ein Multicast-Routing-Protokoll erreicht. Geräte, die IP-Multicast-Datagramme weiterleiten, werden Multicast-Router genannt. Sie können IP-Unicasts weiterleiten oder auch nicht. Multicast-Datagramme werden auf Basis sowohl ihrer Quell- als auch ihrer Zieladressen weitergeleitet. Das Forwarding von IP-Multicast-Paketen wird in Abschnitt [5.2.1] detaillierter beschrieben. Anhang D erörtert Multicast-Routing-Protokolle.
2.2.7 Unnummerierte Leitungen und Netzpräfixe
Traditionell hat jede Netzwerkschnittstelle auf einem IP-Host oder Router ihre eigene IP-Adresse. Dies kann eine ineffiziente Nutzung des knappen IP-Adressraums bewirken, da es die Zuweisung eines IP-Netzpräfix an jeden Point-to-Point-Link erzwingt.
Um dieses Problem zu lösen, haben mehrere Personen das Konzept unnummerierter Point-to-Point-Leitungen vorgeschlagen und implementiert. Eine unnummerierte Point-to-Point-Leitung hat keinen damit verbundenen Netzpräfix. Folglich haben die mit einer unnummerierten Point-to-Point-Leitung verbundenen Netzwerkschnittstellen keine IP-Adressen.
Da die IP-Architektur traditionell angenommen hat, dass alle Schnittstellen IP-Adressen hatten, verursachen diese unnummerierten Schnittstellen einige interessante Dilemmata. Zum Beispiel spezifizieren einige IP-Optionen (z. B. Record Route), dass ein Router die Schnittstellenadresse in die Option einfügen muss, aber eine unnummerierte Schnittstelle hat keine IP-Adresse. Noch fundamentaler (wie wir in Kapitel 5 sehen werden) ist, dass Routen die IP-Adresse des Next-Hop-Routers enthalten. Ein Router erwartet, dass diese IP-Adresse auf einem IP-(Sub)Netz liegt, mit dem der Router verbunden ist. Diese Annahme wird natürlich verletzt, wenn die einzige Verbindung eine unnummerierte Point-to-Point-Leitung ist.
Um diese Schwierigkeiten zu umgehen, wurden zwei Schemata ersonnen. Das erste Schema besagt, dass zwei durch eine unnummerierte Point-to-Point-Leitung verbundene Router eigentlich gar keine zwei Router sind, sondern vielmehr zwei Halb-Router, die zusammen einen einzigen virtuellen Router bilden. Die unnummerierte Point-to-Point-Leitung wird im Wesentlichen als interner Bus im virtuellen Router betrachtet. Die beiden Hälften des virtuellen Routers müssen ihre Aktivitäten so koordinieren, dass sie genau wie ein einziger Router agieren.
Dieses Schema fügt sich gut in die IP-Architektur ein, leidet aber unter zwei wichtigen Nachteilen. Der erste ist, dass es, obwohl es den häufigen Fall einer einzelnen unnummerierten Point-to-Point-Leitung behandelt, nicht ohne Weiteres erweiterbar ist, um den Fall eines Maschennetzes aus Routern und unnummerierten Point-to-Point-Leitungen zu behandeln. Der zweite Nachteil ist, dass die Interaktionen zwischen den Halb-Routern notwendigerweise komplex sind und nicht standardisiert sind, was effektiv den Anschluss von Ausrüstung verschiedener Anbieter über unnummerierte Point-to-Point-Leitungen ausschließt.
Wegen dieser Nachteile hat dieses Memo ein alternatives Schema übernommen, das mehrmals erfunden wurde, aber wahrscheinlich ursprünglich Phil Karn zuzuschreiben ist. In diesem Schema hat ein Router, der unnummerierte Point-to-Point-Leitungen besitzt, auch eine spezielle IP-Adresse, die in diesem Memo als router-id bezeichnet wird. Die router-id ist eine der IP-Adressen des Routers (ein Router muss mindestens eine IP-Adresse haben). Diese router-id wird so verwendet, als ob sie die IP-Adresse aller unnummerierten Schnittstellen wäre.
2.2.8 Bemerkenswerte Besonderheiten
2.2.8.1 Eingebettete Router
Ein Router kann ein eigenständiges Computersystem sein, das seinen IP-Router-Funktionen gewidmet ist. Alternativ ist es möglich, Router-Funktionen in ein Host-Betriebssystem einzubetten, das Verbindungen zu zwei oder mehr Netzen unterstützt. Das bekannteste Beispiel eines Betriebssystems mit eingebettetem Router-Code ist das Berkeley BSD-System. Das eingebettete Router-Feature scheint den Aufbau eines Netzes einfach zu machen, hat aber eine Reihe versteckter Fallstricke:
(1) Wenn ein Host nur eine einzige konstituierende Netzwerkschnittstelle hat, sollte er nicht als Router agieren.
Zum Beispiel verursachen Hosts mit eingebettetem Router-Code, die grundlos Broadcast-Pakete oder Datagramme im selben Netz weiterleiten, oft Paketlawinen.
(2) Wenn ein (multihomed) Host als Router agiert, unterliegt er den in diesem Dokument enthaltenen Anforderungen für Router.
Zum Beispiel sind die Routing-Protokoll-Fragen und die Router-Steuerungs- und Überwachungsprobleme für eingebettete Router ebenso schwer und wichtig wie für eigenständige Router.
Internet-Router-Anforderungen und -Spezifikationen können unabhängig von Betriebssystemänderungen variieren. Einer Administration, die einen eingebetteten Router im Internet betreibt, wird dringend empfohlen, den Router-Code zu pflegen und zu aktualisieren. Dies könnte Router-Quellcode erfordern.
(3) Wenn ein Host eingebetteten Router-Code ausführt, wird er Teil der Internet-Infrastruktur. Daher können Fehler in Software oder Konfiguration die Kommunikation zwischen anderen Hosts behindern. Als Konsequenz muss der Host-Administrator etwas Autonomie verlieren.
In vielen Umständen wird ein Host-Administrator den im Betriebssystem eingebetteten Router-Code deaktivieren müssen. Aus diesem Grund sollte es unkompliziert sein, eingebettete Router-Funktionalität zu deaktivieren.
(4) Wenn ein Host, der eingebetteten Router-Code ausführt, gleichzeitig für andere Dienste genutzt wird, können die Operation-and-Maintenance-Anforderungen für die beiden Nutzungsmodi in Konflikt geraten.
Zum Beispiel wird Router-O&M in vielen Fällen fernbedient von einem Operations-Center durchgeführt; dies kann privilegierten Systemzugriff erfordern, den der Host-Administrator normalerweise nicht verteilen möchte.
2.2.8.2 Transparente Router
Es gibt zwei grundlegende Modelle für die Vernetzung von Local-Area-Networks und Wide-Area- (oder long-haul-)Netzwerken im Internet. Im ersten wird dem Local-Area-Network ein Netzpräfix zugewiesen, und alle Router im Internet müssen wissen, wie man zu diesem Netz routet. Im zweiten teilt sich das Local-Area-Network (einen kleinen Teil von) den Adressraum des Wide-Area-Networks. Router, die dieses zweite Modell unterstützen, werden Address-Sharing-Router oder transparente Router genannt. Der Fokus dieses Memos liegt auf Routern, die das erste Modell unterstützen, aber dies ist nicht als Ausschluss der Verwendung transparenter Router gedacht.
Die Grundidee eines transparenten Routers ist, dass die Hosts im Local-Area-Network hinter einem solchen Router den Adressraum des Wide-Area-Networks vor dem Router teilen. In bestimmten Situationen ist dies ein sehr nützlicher Ansatz, und die Einschränkungen stellen keine signifikanten Nachteile dar.
Die Worte vor und hinter deuten eine der Einschränkungen dieses Ansatzes an: Dieses Vernetzungsmodell ist nur für eine geographisch (und topologisch) begrenzte Stub-Umgebung geeignet. Es erfordert, dass es eine Form logischer Adressierung in der Netzwerkebene-Adressierung des Wide-Area-Networks gibt. IP-Adressen in der lokalen Umgebung werden auf wenige (normalerweise eine) physische Adressen im Wide-Area-Network abgebildet. Diese Abbildung erfolgt konsistent mit der { IP-Adresse <-> Netzwerkadresse }-Abbildung, die im gesamten Wide-Area-Network verwendet wird.
Multihoming ist in einem Wide-Area-Network möglich, kann aber Routing-Probleme verursachen, wenn die Schnittstellen geographisch oder topologisch getrennt sind. Multihoming auf zwei (oder mehr) Wide-Area-Networks ist ein Problem wegen der Verwirrung von Adressen.
Das Verhalten, das Hosts von anderen Hosts in dem, was offensichtlich dasselbe Netz ist, sehen, kann abweichen, wenn der transparente Router den normalen Wide-Area-Network-Dienst nicht vollständig emulieren kann. Zum Beispiel verwendete das ARPANET ein Link-Layer-Protokoll, das eine Destination-Dead-Anzeige als Reaktion auf einen Versuch lieferte, an einen Host zu senden, der offline war. Wenn es jedoch einen transparenten Router zwischen dem ARPANET und einem Ethernet gäbe, würde ein Host im ARPANET keine Destination-Dead-Anzeige für Ethernet-Hosts erhalten.
2.3 Router-Eigenschaften
Ein Internet-Router führt folgende Funktionen aus:
(1) Erhält sich an spezifische Internet-Protokolle, die in diesem Dokument spezifiziert sind, einschließlich des Internet Protocol (IP), des Internet Control Message Protocol (ICMP) und anderer nach Bedarf.
(2) Schnittstellen zu zwei oder mehr Paketnetzen. Für jedes verbundene Netz muss der Router die von diesem Netz geforderten Funktionen implementieren. Diese Funktionen umfassen typischerweise:
o Kapseln und Entkapseln der IP-Datagramme mit dem verbundenen Netz-Framing (z. B. einem Ethernet-Header und Checksumme),
o Senden und Empfangen von IP-Datagrammen bis zur maximalen Größe, die von diesem Netz unterstützt wird; diese Größe ist die Maximum Transmission Unit (MTU) des Netzes,
o Übersetzen der IP-Zieladresse in eine angemessene Netzwerkebenen-Adresse für das verbundene Netz (z. B. eine Ethernet-Hardware-Adresse), falls benötigt, und
o Reagieren auf Netzwerk-Flusskontrolle und Fehleranzeigen, falls vorhanden.
Siehe Kapitel 3 (Link Layer).
(3) Empfängt und leitet Internet-Datagramme weiter. Wichtige Themen in diesem Prozess sind Pufferverwaltung, Stau-Kontrolle und Fairness.
o Erkennt Fehlerbedingungen und generiert ICMP-Fehler- und Informationsmeldungen nach Bedarf.
o Verwirft Datagramme, deren Time-to-Live-Felder Null erreicht haben.
o Fragmentiert Datagramme, wenn nötig, um in die MTU des nächsten Netzes zu passen.
Siehe Kapitel 4 (Internet Layer - Protokolle) und Kapitel 5 (Internet Layer - Forwarding) für weitere Informationen.
(4) Wählt ein Next-Hop-Ziel für jedes IP-Datagramm basierend auf den Informationen in seiner Routing-Datenbank. Siehe Kapitel 5 (Internet Layer - Forwarding) für weitere Informationen.
(5) (Normalerweise) unterstützt ein Interior Gateway Protocol (IGP), um verteilte Routing- und Erreichbarkeitsalgorithmen mit den anderen Routern im selben autonomen System auszuführen. Zusätzlich werden einige Router ein Exterior Gateway Protocol (EGP) unterstützen müssen, um topologische Informationen mit anderen autonomen Systemen auszutauschen. Siehe Kapitel 7 (Application Layer - Routing-Protokolle) für weitere Informationen.
(6) Bietet Netzwerkmanagement- und Systemunterstützungsfunktionen, einschließlich Laden, Debuggen, Statusbericht, Ausnahmebericht und Steuerung. Siehe Kapitel 8 (Application Layer - Network Management-Protokolle) und Kapitel 10 (Operation and Maintenance) für weitere Informationen.
Ein Router-Anbieter wird viele Wahlmöglichkeiten hinsichtlich Leistung, Komplexität und Funktionen für ein bestimmtes Router-Produkt haben. Es kann hilfreich sein zu beobachten, dass das Internetsystem weder homogen noch vollständig verbunden ist. Aus technischen und geographischen Gründen wächst es zu einem globalen Interconnect-System plus einem Rand aus LANs am Rande. Immer mehr werden diese Rand-LANs reichlich miteinander verbunden, wodurch sie weniger am Rande und anspruchsvoller auf Router-Anforderungen werden.
o Das globale Interconnect-System besteht aus einer Reihe von Wide-Area-Networks, an die Router mehrerer Autonomous Systems (AS) angeschlossen sind; relativ wenige Hosts sind direkt mit dem System verbunden.
o Die meisten Hosts sind mit LANs verbunden. Viele Organisationen haben Cluster von LANs, die durch lokale Router miteinander verbunden sind. Jeder solche Cluster ist an einem oder mehreren Punkten in das globale Interconnect-System eingebunden. Wenn er nur an einem Punkt verbunden ist, wird ein LAN als Stub-Netz bezeichnet.
Router im globalen Interconnect-System erfordern im Allgemeinen:
o Erweiterte Routing- und Forwarding-Algorithmen
Diese Router benötigen Routing-Algorithmen, die hochgradig dynamisch sind, minimale Verarbeitungs- und Kommunikationslasten auferlegen und Type-of-Service-Routing bieten. Stau (congestion) ist immer noch kein vollständig gelöstes Problem (siehe Abschnitt [5.3.6]). Verbesserungen in diesen Bereichen werden erwartet, da die Forschungsgemeinschaft aktiv an diesen Problemen arbeitet.
o Hohe Verfügbarkeit
Diese Router müssen hochzuverlässig sein und 24 Stunden am Tag, 7 Tage die Woche Dienst bieten. Geräte- und Softwarefehler können weitreichende (manchmal globale) Auswirkungen haben. Im Falle eines Ausfalls müssen sie schnell wiederherstellen. In jeder Umgebung muss ein Router hochgradig robust sein und in der Lage, möglicherweise in einem degradierten Zustand, unter Bedingungen extremer Überlastung oder Ausfalls von Netzressourcen zu operieren.
o Erweiterte O&M-Funktionen
Internet-Router arbeiten normalerweise im unbeaufsichtigten Modus. Sie werden typischerweise fernbedient von einem zentralisierten Überwachungs-Center betrieben. Sie müssen ausgefeilte Mittel zur Überwachung und Messung von Datenverkehr und anderen Ereignissen sowie zur Fehlerdiagnose bereitstellen.
o Hohe Leistung
Long-haul-Leitungen im Internet heute sind am häufigsten Vollduplex 56 KBPS, DS1 (1,544 Mbps) oder DS3 (45 Mbps) Geschwindigkeiten. LANs, die Halbduplex-Multiaccess-Medien sind, sind typischerweise Ethernet (10Mbps) und in geringerem Maße FDDI (100Mbps). Netzwerkmedientechnologie schreitet jedoch ständig voran, und höhere Geschwindigkeiten sind in Zukunft wahrscheinlich.
Die Anforderungen für Router, die im LAN-Rand (z. B. Campus-Netzen) verwendet werden, hängen stark von den Anforderungen der lokalen Netze ab. Dies können Hoch- oder Mittelleistungsgeräte sein, wahrscheinlich wettbewerbsorientiert von mehreren verschiedenen Anbietern bezogen und von einer internen Organisation (z. B. einem Campus-Rechenzentrum) betrieben. Das Design dieser Router sollte niedrige durchschnittliche Latenz und gute Burst-Leistung betonen, zusammen mit verzögerungs- und Type-of-Service-empfindlicher Ressourcenverwaltung. In dieser Umgebung kann es weniger formelle O&M geben, aber sie wird nicht weniger wichtig sein. Die Notwendigkeit, dass der Routing-Mechanismus hochgradig dynamisch ist, wird wichtiger, da Netze komplexer und vernetzter werden. Benutzer werden mehr aus ihren lokalen Verbindungen verlangen, wegen der Geschwindigkeit der globalen Interconnects.
Da Netze gewachsen sind und da mehr Netze alt genug geworden sind, dass sie ältere Ausrüstung ausmustern, ist es zunehmend zwingend erforderlich, dass Router mit Routern anderer Anbieter interoperieren.
Obwohl das Internetsystem nicht vollständig vernetzt ist, benötigen viele Teile des Systems redundante Konnektivität. Reiche Konnektivität erlaubt zuverlässigen Dienst trotz Ausfällen von Kommunikationsleitungen und Routern, und sie kann den Dienst auch verbessern, indem sie Internet-Pfade verkürzt und zusätzliche Kapazität bereitstellt. Leider kann diese reichere Topologie es viel schwieriger machen, den besten Pfad zu einem bestimmten Ziel zu wählen.
2.4 Architektonische Annahmen
Die aktuelle Internet-Architektur basiert auf einem Satz von Annahmen über das Kommunikationssystem. Die für Router relevantesten Annahmen sind wie folgt:
o Das Internet ist ein Netz von Netzen.
Jeder Host ist direkt mit einigen bestimmten Netz(en) verbunden; seine Verbindung zum Internet ist nur konzeptionell. Zwei Hosts im selben Netz kommunizieren miteinander unter Verwendung desselben Satzes von Protokollen, den sie verwenden würden, um mit Hosts in entfernten Netzen zu kommunizieren.
o Router behalten keine Verbindungszustandsinformationen.
Um die Robustheit des Kommunikationssystems zu verbessern, sind Router so konzipiert, dass sie zustandslos sind und jedes IP-Paket unabhängig von anderen Paketen weiterleiten. Als Ergebnis können redundante Pfade ausgenutzt werden, um robusten Dienst trotz Ausfällen von zwischengeschalteten Routern und Netzen zu bieten.
Alle für End-to-End-Flusskontrolle und Zuverlässigkeit benötigten Zustandsinformationen werden in den Hosts, in der Transportschicht oder in Anwendungsprogrammen implementiert. Alle Verbindungssteuerungsinformationen sind somit mit den Endpunkten der Kommunikation kolokalisiert, sodass sie nur verloren gehen, wenn ein Endpunkt ausfällt. Router steuern den Nachrichtenfluss nur indirekt, indem sie Pakete verwerfen oder Netzwerkverzögerung erhöhen.
Beachten Sie, dass zukünftige Protokollentwicklungen sehr wohl dazu führen könnten, etwas mehr Zustand in Router zu legen. Dies ist besonders wahrscheinlich für Multicast-Routing, Reservierung von Ressourcen und flussbasiertes Forwarding.
o Routing-Komplexität sollte in den Routern liegen.
Routing ist ein komplexes und schwieriges Problem und sollte von den Routern, nicht von den Hosts ausgeführt werden. Ein wichtiges Ziel ist es, Host-Software vor Änderungen zu isolieren, die durch die unvermeidliche Evolution der Internet-Routing-Architektur verursacht werden.
o Das System muss große Netzvariation tolerieren.
Ein grundlegendes Ziel des Internet-Designs ist es, eine weite Spanne von Netzmerkmalen zu tolerieren - z. B. Bandbreite, Verzögerung, Paketverlust, Paketneuanordnung und maximale Paketgröße. Ein weiteres Ziel ist Robustheit gegen Ausfälle einzelner Netze, Router und Hosts unter Verwendung jeglicher noch verfügbarer Bandbreite. Schließlich ist das Ziel volle Open-System-Interconnection: Ein Internet-Router muss robust und effektiv mit jedem anderen Router oder Internet-Host über diverse Internet-Pfade interoperieren können.
Manchmal haben Implementierer für weniger ehrgeizige Ziele entworfen. Zum Beispiel ist die LAN-Umgebung typischerweise viel gutartiger als das Internet als Ganzes; LANs haben niedrigen Paketverlust und Verzögerung und ordnen Pakete nicht neu an. Einige Anbieter haben Implementierungen auf den Markt gebracht, die für eine einfache LAN-Umgebung ausreichen, aber für allgemeine Interoperation schlecht funktionieren. Der Anbieter rechtfertigt ein solches Produkt als wirtschaftlich innerhalb des beschränkten LAN-Marktes. Isolierte LANs bleiben jedoch selten lange isoliert. Sie werden bald miteinander verbunden, mit unternehmensweiten Internets and finally mit dem globalen Internetsystem. Am Ende wird weder dem Kunden noch dem Anbieter von unvollständigen oder minderwertigen Routern gedient.
Die Anforderungen in diesem Dokument sind für einen Vollfunktions-Router entworfen. Es ist beabsichtigt, dass vollständig konforme Router in fast jedem Teil des Internets verwendbar sein werden.
3. LINK LAYER (Sicherungsschicht)
Obwohl [INTRO:1] Link-Layer-Standards (IP über verschiedene Link-Layer, ARP usw.) abdeckt, geht dieses Dokument davon aus, dass Link-Layer-Material in einem separaten Link-Layer-Requirements-Dokument behandelt wird. Ein Link-Layer-Requirements-Dokument würde sowohl für Hosts als auch für Router gelten. Daher macht dieses Dokument die Teile von [INTRO:1], die sich mit Link-Layer-Themen befassen, nicht obsolet.
3.1 EINLEITUNG
Router haben im Wesentlichen dieselben Link-Layer-Protokoll-Anforderungen wie andere Arten von Internetsystemen. Diese Anforderungen sind in Kapitel 3 von Requirements for Internet Gateways [INTRO:1] angegeben. Ein Router MUSS (MUST) dessen Anforderungen erfüllen und SOLLTE (SHOULD) dessen Empfehlungen erfüllen. Da ein Teil des Materials in jenem Dokument etwas veraltet ist, sind einige zusätzliche Anforderungen und Erklärungen unten enthalten.
DISKUSSION Es wird erwartet, dass die Internet-Gemeinschaft einen Standard Requirements for Internet Link Layer erstellt, der sowohl dieses Kapitel als auch das Kapitel mit dem Titel "INTERNET LAYER PROTOCOLS" in [INTRO:1] ersetzt.
3.2 LINK/INTERNET-LAYER-SCHNITTSTELLE
Dieses Dokument versucht nicht, die Schnittstelle zwischen der Link Layer und den oberen Schichten zu spezifizieren. Es ist jedoch wohl zu beachten, dass andere Teile dieses Dokuments, insbesondere Kapitel 5, verschiedene Arten von Informationen erfordern, die über diese Schichtgrenze hinweg übertragen werden.
Dieser Abschnitt verwendet die folgenden Definitionen:
o Source physical address (Quell-Physikalische-Adresse) Die Quell-Physikalische-Adresse ist die Link-Layer-Adresse des Hosts oder Routers, von dem das Paket empfangen wurde.
o Destination physical address (Ziel-Physikalische-Adresse) Die Ziel-Physikalische-Adresse ist die Link-Layer-Adresse, an die das Paket gesendet wurde.
Die Informationen, die für jedes empfangene Paket von der Link Layer an die Internetwork Layer übergeben werden müssen, sind:
(1) Das IP-Paket [5.2.2],
(2) Die Länge des Datenanteils (d. h. ohne das Link-Layer-Framing) des Link-Layer-Frames [5.2.2],
(3) Die Identität der physischen Schnittstelle, von der das IP-Paket empfangen wurde [5.2.3], und
(4) Die Klassifizierung der paketziel-Physikalischen-Adresse als Link-Layer-Unicast, -Broadcast oder -Multicast [4.3.2], [5.3.4].
Zusätzlich SOLLTE (SHOULD) die Link Layer auch bereitstellen:
(5) Die Quell-Physikalische-Adresse.
Die Informationen, die für jedes übertragene Paket von der Internetwork Layer an die Link Layer übergeben werden müssen, sind:
(1) Das IP-Paket [5.2.1]
(2) Die Länge des IP-Pakets [5.2.1]
(3) Die Ziel-Physikalische-Schnittstelle [5.2.1]
(4) Die Next-Hop-IP-Adresse [5.2.1]
Zusätzlich SOLLTE (SHOULD) die Internetwork Layer auch bereitstellen:
(5) Den Link-Layer-Priority-Wert [5.3.3.2]
Die Link Layer MUSS (MUST) die Internetwork Layer auch benachrichtigen, falls das zu übertragende Paket einen Link-Layer-Precedence-bezogenen Fehler verursacht [5.3.3.3].
3.3 SPEZIFISCHE THEMEN
3.3.1 Trailer Encapsulation
Router, die an 10-Megabit-Ethernets angeschlossen werden können, KÖNNEN (MAY) in der Lage sein, Ethernet-Pakete zu empfangen und weiterzuleiten, die unter Verwendung der in [LINK:1] beschriebenen Trailer-Kapselung gekapselt sind. Ein Router SOLLTE (SHOULD) jedoch keine trailer-gekapselten Pakete erzeugen. Ein Router DARF (MUST NOT) keine trailer-gekapselten Pakete erzeugen, ohne zuvor mit dem in [INTRO:2] beschriebenen Mechanismus zu überprüfen, dass das unmittelbare Ziel des Pakets bereit und in der Lage ist, trailer-gekapselte Pakete zu akzeptieren. Ein Router SOLLTE (SHOULD) nicht zustimmen (unter Verwendung dieser Mechanismen), trailer-gekapselte Pakete zu akzeptieren.
3.3.2 Address Resolution Protocol - ARP
Router, die ARP implementieren, MÜSSEN (MUST) konform und SOLLTEN (SHOULD) bedingungslos konform mit den Anforderungen in [INTRO:2] sein.
Die Link Layer DARF (MUST NOT) allein deshalb einen Destination-Unreachable-Fehler an IP melden, weil kein ARP-Cache-Eintrag für ein Ziel existiert; sie SOLLTE (SHOULD) bis zu eine kleine Anzahl von Datagrammen kurzzeitig in eine Warteschlange stellen, während sie die ARP-Request/Reply-Sequenz ausführt, und dem einen der wartenden Datagramme melden, dass das Ziel unerreichbar ist, nur wenn sich dies als fruchtlos erweist.
Ein Router DARF (MUST NOT) einer beliebigen ARP-Reply glauben, die behauptet, dass die Link-Layer-Adresse eines anderen Hosts oder Routers eine Broadcast- oder Multicast-Adresse sei.
3.3.3 Ethernet- und 802.3-Koexistenz
Router, die an 10-Megabit-Ethernets angeschlossen werden können, MÜSSEN (MUST) konform und SOLLTEN (SHOULD) bedingungslos konform mit den Ethernet-Anforderungen von [INTRO:2] sein.
3.3.4 Maximum Transmission Unit - MTU
Die MTU jeder logischen Schnittstelle MUSS (MUST) innerhalb des Bereichs der zulässigen MTUs für die Schnittstelle konfigurierbar sein.
Viele Link-Layer-Protokolle definieren eine maximale Frame-Größe, die gesendet werden kann. In solchen Fällen DARF (MUST NOT) ein Router eine MTU zulassen, die das Senden von Frames erlauben würde, die größer sind als die vom Link-Layer-Protokoll erlaubten. Ein Router SOLLTE (SHOULD) jedoch bereit sein, ein Paket zu empfangen, das so groß wie die maximale Frame-Größe ist, selbst wenn dies größer als die MTU ist.
DISKUSSION Beachten Sie, dass dies eine strengere Anforderung ist als die, die [INTRO:2] Hosts auferlegt, welches verlangt, dass die MTU jeder physischen Schnittstelle konfigurierbar sei.
Wenn ein Netz eine MTU verwendet, die kleiner als die maximale Frame-Größe für die Link Layer ist, kann ein Router Pakete erhalten, die größer als die MTU sind, von falsch konfigurierten und unvollständig initialisierten Hosts. Das Robustness-Prinzip besagt, dass der Router diese Pakete nach Möglichkeit erfolgreich empfangen sollte.
3.3.5 Point-to-Point Protocol - PPP
Im Gegensatz zu [INTRO:1] hat das Internet ein Standard-Point-to-Point-Leitungsprotokoll: das Point-to-Point Protocol (PPP), definiert in [LINK:2], [LINK:3], [LINK:4] und [LINK:5].
Eine Point-to-Point-Schnittstelle ist jede Schnittstelle, die entworfen ist, um Daten über eine Point-to-Point-Leitung zu senden. Solche Schnittstellen umfassen Telefon-, gemietete, dedizierte oder Direktleitungen (sowohl 2- als auch 4-adrig) und können Point-to-Point-Kanäle oder virtuelle Schaltungen von multiplexierten Schnittstellen wie ISDN verwenden. Sie verwenden normalerweise eine standardisierte Modem- oder Bit-Seriell-Schnittstelle (wie RS-232, RS-449 oder V.35), entweder mit synchroner oder asynchroner Taktung. Multiplexierte Schnittstellen haben oft spezielle physische Schnittstellen.
Eine General-Purpose-Serial-Schnittstelle verwendet dasselbe physische Medium wie eine Point-to-Point-Leitung, unterstützt aber die Verwendung von Link-Layer-Netzen ebenso wie Point-to-Point-Konnektivität. Link-Layer-Netze (wie X.25 oder Frame Relay) verwenden eine alternative IP-Link-Layer-Spezifikation.
Router, die Point-to-Point- oder General-Purpose-Serial-Schnittstellen implementieren, MÜSSEN (MUST) PPP IMPLEMENTIEREN.
PPP MUSS (MUST) auf allen General-Purpose-Serial-Schnittstellen eines Routers unterstützt werden. Der Router KANN (MAY) zulassen, dass die Leitung so konfiguriert wird, dass sie Point-to-Point-Leitungsprotokolle anderen als PPP verwendet. Point-to-Point-Schnittstellen SOLLTEN (SHOULD) entweder standardmäßig PPP verwenden, wenn sie aktiviert werden, oder erfordern die Konfiguration des Link-Layer-Protokolls, bevor sie aktiviert werden. General-Purpose-Serial-Schnittstellen SOLLTEN (SHOULD) die Konfiguration des Link-Layer-Protokolls verlangen, bevor sie aktiviert werden.
3.3.5.1 Einführung
Dieser Abschnitt bietet Richtlinien für Router-Implementierer, damit sie die Interoperabilität mit anderen Routern gewährleisten können, die PPP über synchronize oder asynchrone Leitungen verwenden.
Es ist entscheidend, dass ein Implementierer die Semantik des Optionsaushandlungs-Mechanismus versteht. Optionen sind ein Mittel für ein lokales Gerät, einem entfernten Peer anzuzeigen, was das lokale Gerät vom entfernten Peer akzeptieren wird, nicht was es zu senden wünscht. Es liegt beim entfernten Peer zu entscheiden, was innerhalb der Grenzen des Satzes von Optionen, den das lokale Gerät angegeben hat, dass es akzeptieren kann, am bequemsten zu senden ist. Daher ist es völlig akzeptabel und normal, dass ein entfernter Peer alle in einem LCP Configuration Request (CR) angezeigten Optionen ACKt, selbst wenn der entfernte Peer keine dieser Optionen unterstützt. Erneut sind die Optionen einfach ein Mechanismus für eines der Geräte, seinem Peer anzuzeigen, was es akzeptieren wird, nicht notwendigerweise was es senden wird.
3.3.5.2 Link Control Protocol (LCP) Options
Das PPP Link Control Protocol (LCP) bietet eine Reihe von Optionen, die ausgehandelt werden können. Diese Optionen umfassen (unter anderen) Adress- und Control-Feld-Kompression, Protokollfeld-Kompression, asynchrone Zeichenzuordnung, Maximum Receive Unit (MRU), Link Quality Monitoring (LQM), Magic Number (für Loopback-Erkennung), Password Authentication Protocol (PAP), Challenge Handshake Authentication Protocol (CHAP) und die 32-Bit Frame Check Sequence (FCS).
Ein Router KANN (MAY) Adress-/Control-Feld-Kompression auf synchronen oder asynchronen Leitungen verwenden. Ein Router KANN (MAY) Protokollfeld-Kompression auf synchronen oder asynchronen Leitungen verwenden. Ein Router, der angibt, dass er diese Kompressionen akzeptieren kann, MUSS (MUST) auch in der Lage sein, unkomprimierte PPP-Header-Informationen zu akzeptieren.
DISKUSSION Diese Optionen steuern das Erscheinungsbild des PPP-Headers. Normalerweise besteht der PPP-Header aus der Adresse, dem Control-Feld und dem Protokollfeld. Die Adresse ist auf einer Point-to-Point-Leitung 0xFF und zeigt "Broadcast" an. Das Control-Feld ist 0x03 und zeigt "Unnumbered Information" an. Der Protocol Identifier ist ein Zwei-Byte-Wert, der den Inhalt des Datenbereichs des Frames angibt. Wenn ein System Adress- und Control-Feld-Kompression aushandelt, zeigt es seinem Peer an, dass es PPP-Frames akzeptieren wird, die diese Felder am Anfang des Headers haben oder nicht haben. Es zeigt nicht an, dass es Frames ohne diese Felder senden wird.
Protokollfeld-Kompression, wenn ausgehandelt, zeigt an, dass das System bereit ist, Protokollfelder auf ein Byte komprimiert zu empfangen, wenn dies zulässig ist. Es besteht keine Anforderung, dass der Sender dies tut.
Die Verwendung von Adress-/Control-Feld-Kompression ist inkonsistent mit der Verwendung von Numbered Mode (reliable) PPP.
IMPLEMENTIERUNG Einige Hardware kommt nicht gut mit variabler Header-Länge zurecht. In diesen Fällen macht es am meisten Sinn, dass der entfernte Peer den vollen PPP-Header sendet. Implementierungen können dies sicherstellen, indem sie dem entfernten Peer nicht die Adress-/Control-Feld- und Protokollfeld-Kompressionsoptionen senden. Selbst wenn der entfernte Peer eine Fähigkeit zum Empfang komprimierter Header angezeigt hat, besteht keine Anforderung für den lokalen Router, komprimierte Header zu senden.
Ein Router MUSS (MUST) die Asynchronous Control Character Map (ACCM) für asynchrone PPP-Leitungen aushandeln, SOLLTE (SHOULD) aber die ACCM nicht für synchrone Leitungen aushandeln. Wenn ein Router einen Versuch erhält, die ACCM über eine synchrone Leitung auszuhandeln, MUSS (MUST) er die Option ACKnowledge und dann ignorieren.
DISKUSSION Es gibt Implementierungen, die sowohl synchrone als auch asynchrone Betriebsmodi anbieten und möglicherweise denselben Code verwenden, um die Optionsaushandlung zu implementieren. In dieser Situation ist es möglich, dass das eine oder andere Ende die ACCM-Option über eine synchrone Leitung sendet.
Ein Router SOLLTE (SHOULD) die Maximum Receive Unit (MRU) ordnungsgemäß aushandeln. Selbst wenn ein System eine MRU aushandelt, die kleiner als 1.500 Byte ist, MUSS (MUST) es in der Lage sein, ein 1.500-Byte-Frame zu empfangen.
Ein Router SOLLTE (SHOULD) die Link Quality Monitoring (LQM)-Option aushandeln und aktivieren.
DISKUSSION Dieses Memo spezifiziert keine Richtlinie für die Entscheidung, ob die Qualität der Leitung angemessen ist. Es ist jedoch wichtig (siehe Abschnitt [3.3.6]), dass ein Router fehlgeschlagene Leitungen deaktiviert.
Ein Router SOLLTE (SHOULD) die Magic-Number-Option für Loopback-Erkennung implementieren und aushandeln.
Ein Router KANN (MAY) die Authentifizierungsoptionen unterstützen (PAP - Password Authentication Protocol, und/oder CHAP - Challenge Handshake Authentication Protocol).
Ein Router MUSS (MUST) die 16-Bit-CRC Frame Check Sequence (FCS) unterstützen und KANN (MAY) die 32-Bit-CRC unterstützen.
3.3.5.3 IP Control Protocol (IPCP) Options
Ein Router KANN (MAY) anbieten, IP-Adress-Aushandlung durchzuführen. Ein Router MUSS (MUST) eine Ablehnung (REJect), die IP-Adress-Aushandlung durchzuführen, vom Peer akzeptieren.
Router, die bei Leitungsgeschwindigkeiten von 19.200 BPS oder weniger betreiben, SOLLTEN (SHOULD) Van-Jacobson-Header-Kompression implementieren und anbieten. Router, die VJ-Kompression implementieren, SOLLTEN (SHOULD) eine administrative Steuerung implementieren, die sie aktiviert oder deaktiviert.
3.3.6 Schnittstellentest
Ein Router MUSS (MUST) einen Mechanismus haben, der der Routing-Software ermöglicht festzustellen, ob eine physische Schnittstelle zum Senden von Paketen verfügbar ist oder nicht; bei multiplexierten Schnittstellen, bei denen permanente virtuelle Schaltungen für begrenzte Nachbarnmengen geöffnet werden, muss der Router auch in der Lage sein festzustellen, ob die virtuellen Schaltungen lebensfähig sind. Ein Router SOLLTE (SHOULD) einen Mechanismus haben, der der Routing-Software ermöglicht, die Qualität einer physischen Schnittstelle zu beurteilen. Ein Router MUSS (MUST) einen Mechanismus haben, um die Routing-Software zu informieren, wenn eine physische Schnittstelle durch administrative Maßnahme verfügbar oder nicht verfügbar zum Senden von Paketen wird. Ein Router MUSS (MUST) einen Mechanismus haben, um die Routing-Software zu informieren, wenn er erkennt, dass eine Link-Level-Schnittstelle aus irgendeinem Grund verfügbar oder nicht verfügbar geworden ist.
DISKUSSION Es ist entscheidend, dass Router brauchbare Mechanismen haben, um festzustellen, dass ihre Netzverbindungen ordnungsgemäß funktionieren. Das Versäumnis, Link-Verlust zu erkennen, oder das Versäumnis, die richtigen Maßnahmen zu ergreifen, wenn ein Problem erkannt wird, kann zu Black Holes führen.
Die Mechanismen, die für die Erkennung von Problemen mit Netzverbindungen verfügbar sind, variieren beträchtlich, abhängig von den verwendeten Link-Layer-Protokollen und der Schnittstellenhardware. Die Absicht ist, die Fähigkeit zur Erkennung von Fehlern innerhalb der Link-Layer-Einschränkungen zu maximieren.
4. INTERNET LAYER - PROTOKOLLE
4.1 EINLEITUNG
Dieses Kapitel und Kapitel 5 erörtern die Protokolle, die auf der Internet Layer verwendet werden: IP, ICMP und IGMP. Da das Forwarding in einem Dokument über Router offensichtlich ein entscheidendes Thema ist, beschränkt sich Kapitel 5 auf die Aspekte der Protokolle, die sich direkt auf das Forwarding beziehen. Das aktuelle Kapitel enthält den Rest der Erörterung der Internet-Layer-Protokolle.
4.2 INTERNET PROTOCOL - IP
4.2.1 EINLEITUNG
Router MÜSSEN (MUST) das IP-Protokoll implementieren, wie in [INTERNET:1] definiert. Sie MÜSSEN (MUST) auch dessen zwingende Erweiterungen implementieren: Subnetze (definiert in [INTERNET:2]), IP-Broadcast (definiert in [INTERNET:3]) und Classless Inter-Domain Routing (CIDR, definiert in [INTERNET:15]).
Router-Implementierer müssen die Konformität mit dem Abschnitt von [INTRO:2] mit dem Titel "Internet Protocol -- IP" nicht berücksichtigen, da jener Abschnitt in diesem Dokument vollständig dupliziert oder ersetzt wird. Ein Router MUSS (MUST) konform und SOLLTE (SHOULD) bedingungslos konform mit den Anforderungen des Abschnitts mit dem Titel "SPECIFIC ISSUES" in Bezug auf IP in [INTRO:2] sein.
Im Folgenden ist die in bestimmten Fällen angegebene Aktion, ein empfangenes Datagramm still zu verwerfen (silently discard). Dies bedeutet, dass das Datagramm ohne weitere Verarbeitung verworfen wird und dass der Router keine ICMP-Fehlermeldung sendet (siehe Abschnitt [4.3]) als Ergebnis. Für die Diagnose von Problemen SOLLTE (SHOULD) ein Router jedoch die Fähigkeit bereitstellen, den Fehler zu protokollieren (siehe Abschnitt [1.3.3]), einschließlich des Inhalts des still verworfenen Datagramms, und SOLLTE (SHOULD) verworfene Datagramme zählen.
4.2.2 PROTOKOLL-DURCHGANG
RFC 791 [INTERNET:1] ist die Spezifikation für das Internet Protocol.
4.2.2.1 Optionen: RFC 791 Abschnitt 3.2
In Datagrammen, die vom Router selbst empfangen werden, MUSS (MUST) die IP-Schicht die IP-Optionen, die sie versteht, interpretieren und den Rest unverändert für die Verwendung durch höhere Schicht-Protokolle bewahren.
Höhere Schicht-Protokolle können die Fähigkeit benötigen, IP-Optionen in den von ihnen gesendeten Datagrammen zu setzen oder IP-Optionen in den von ihnen empfangenen Datagrammen zu untersuchen. Spätere Abschnitte dieses Dokuments erörtern spezifische IP-Options-Unterstützung, die von höheren Schicht-Protokollen verlangt wird.
DISKUSSION Weder dieses Memo noch [INTRO:2] definieren die Reihenfolge, in der ein Empfänger mehrere Optionen im selben IP-Header verarbeiten muss. Hosts und Router, die Datagramme mit mehreren Optionen erzeugen, müssen sich bewusst sein, dass dies eine Mehrdeutigkeit in der Bedeutung bestimmter Optionen einführt, wenn sie mit einer Source-Route-Option kombiniert werden.
Hier sind die Anforderungen für spezifische IP-Optionen:
(a) Security-Option
Einige Umgebungen verlangen die Security-Option in jedem Paket, das erzeugt oder empfangen wird. Router SOLLTEN (SHOULD) die in [INTERNET:5] beschriebene überarbeitete Security-Option IMPLEMENTIEREN.
DISKUSSION Beachten Sie, dass die in [INTERNET:1] und RFC 1038 ([INTERNET:16]) beschriebenen Security-Optionen veraltet sind.
(b) Stream Identifier Option
Diese Option ist veraltet; Router SOLLTEN (SHOULD) diese Option nicht in ein Datagramm einfügen, das der Router erzeugt. Diese Option MUSS (MUST) in vom Router empfangenen Datagrammen ignoriert werden.
(c) Source Route Options
Ein Router MUSS (MUST) in der Lage sein, als finales Ziel einer Source Route zu fungieren. Wenn ein Router ein Paket empfängt, das eine vollständige Source Route enthält, hat das Paket sein finales Ziel erreicht. In einer solchen Option zeigt der Zeiger über das letzte Feld hinaus und die Zieladresse im IP-Header adressiert den Router. Die Option wie empfangen (die aufgezeichnete Route) MUSS (MUST) an die Transportschicht (oder an die ICMP-Nachrichtenverarbeitung) weitergegeben werden.
Im allgemeinen Fall durchläuft eine korrekte Antwort auf ein source-geroutetes Datagramm dieselbe Route. Ein Router MUSS (MUST) ein Mittel bereitstellen, wodurch Transport-Protokolle und Anwendungen die Source Route in einem empfangenen Datagramm umkehren können. Diese umgekehrte Source Route MUSS (MUST) in die von ihnen erzeugten Datagramme eingefügt werden (siehe [INTRO:2] für Details), wenn der Router sich keiner Policy-Einschränkungen bewusst ist. Wenn der Router jedoch Policy-bewusst ist, KANN (MAY) er einen anderen Pfad wählen.
Einige Anwendungen im Router KÖNNEN (MAY) verlangen, dass der Benutzer eine Source Route eingeben kann.
Ein Router DARF (MUST NOT) kein Datagramm erzeugen, das mehrere Source Route-Optionen enthält. Was ein Router tun soll, wenn ihm aufgetragen wird, ein Paket weiterzuleiten, das mehrere Source Route-Optionen enthält, ist in Abschnitt [5.2.4.1] beschrieben.
Wenn eine Source Route-Option erstellt wird (was geschehen würde, wenn der Router ein source-geroutetes Datagramm erzeugt oder eine Source Route-Option als Ergebnis eines speziellen Filters einfügt), MUSS (MUST) sie korrekt gebildet sein, selbst wenn sie durch Umkehrung einer aufgezeichneten Route erstellt wird, die fälschlicherweise den Quell-Host einschließt (siehe Fall (B) in der Erörterung unten).
DISKUSSION Angenommen, ein source-geroutetes Datagramm soll von Quelle S zu Ziel D über Router G1, G2, Gn geroutet werden. Quelle S konstruiert ein Datagramm mit G1s IP-Adresse als Zieladresse und einer Source Route-Option, um das Datagramm den Rest des Weges zu seinem Ziel zu bringen. Es gibt jedoch eine Mehrdeutigkeit in der Spezifikation darüber, ob die Source Route-Option in einem von S gesendeten Datagramm (A) oder (B) sein sollte:
(A): {>>G2, G3, ... Gn, D} <--- KORREKT
(B): {S, >>G2, G3, ... Gn, D} <---- FALSCH
(wobei >> den Zeiger darstellt). Wenn (A) gesendet wird, wird das bei D empfangene Datagramm die Option enthalten: {G1, G2, ... Gn >>}, mit S und D als IP-Quell- und Zieladressen. Wenn (B) gesendet würde, würde das bei D empfangene Datagramm wieder S und D als dieselben IP-Quell- und Zieladressen enthalten, aber die Option wäre: {S, G1, ...Gn >>}; d. h., der Ursprungs-Host wäre der erste Hop in der Route.
(d) Record Route Option
Router KÖNNEN (MAY) die Record Route-Option in vom Router erzeugten Datagrammen unterstützen.
(e) Timestamp Option
Router KÖNNEN (MAY) die Timestamp-Option in vom Router erzeugten Datagrammen unterstützen. Die folgenden Regeln gelten:
o Beim Erzeugen eines Datagramms, das eine Timestamp-Option enthält, MUSS (MUST) ein Router einen Zeitstempel in die Option einfügen, wenn
- Seine Internet-Adressfelder nicht vorab spezifiziert sind oder
- Seine erste vorab spezifizierte Adresse die IP-Adresse der logischen Schnittstelle ist, über die das Datagramm gesendet wird (oder die router-id des Routers, wenn das Datagramm über eine unnummerierte Schnittstelle gesendet wird).
o Wenn der Router selbst ein Datagramm empfängt, das eine Timestamp-Option enthält, MUSS (MUST) der Router die aktuelle Zeit in die Timestamp-Option einfügen (wenn Platz in der Option dafür vorhanden ist), bevor er die Option an die Transportschicht oder an ICMP zur Verarbeitung übergibt. Wenn kein Platz vorhanden ist, MUSS (MUST) der Router den Overflow Count in der Option inkrementieren.
o Ein Zeitstempelwert MUSS (MUST) den in [INTRO:2] definierten Regeln folgen.
IMPLEMENTIERUNG Um den Nutzen der Zeitstempel in der Timestamp-Option zu maximieren, sollte der eingefügte Zeitstempel, so praktisch wie möglich, die Zeit sein, zu der das Paket beim Router eintraf. Für vom Router erzeugte Datagramme sollte der eingefügte Zeitstempel, so praktisch wie möglich, die Zeit sein, zu der das Datagramm zur Übertragung an die Link Layer übergeben wurde.
Die Timestamp-Option erlaubt die Verwendung einer nicht standardmäßigen Zeituhr, aber die Verwendung einer nicht synchronisierten Uhr begrenzt den Nutzen des Zeitstempels. Daher wird Routern dringend empfohlen, das Network Time Protocol zu implementieren, um ihre Uhren zu synchronisieren.
4.2.2.2 Adressen in Optionen: RFC 791 Abschnitt 3.1
Router werden aufgefordert, ihre Adresse in Record Route-, Strict Source and Record Route-, Loose Source and Record Route- oder Timestamp-Optionen einzufügen. Wenn ein Router seine Adresse in eine solche Option einfügt, MUSS (MUST) er die IP-Adresse der logischen Schnittstelle verwenden, über die das Paket gesendet wird.
Wo diese Regel nicht befolgt werden kann, weil die Ausgabeschnittstelle keine IP-Adresse hat (d. h., eine unnummerierte Schnittstelle ist), MUSS (MUST) der Router stattdessen seine router-id einfügen. Die router-id des Routers ist eine der IP-Adressen des Routers. Die Router-ID kann systemweit oder linkweit angegeben werden. Welche der Adressen des Routers als router-id verwendet wird, DARF (MUST NOT) sich nicht ändern (selbst über Neustarts hinweg), es sei denn, sie wird vom Netzmanager geändert. Relevante Management-Änderungen umfassen die Neukonfiguration des Routers derart, dass die als router-id verwendete IP-Adresse aufhört, eine der IP-Adressen des Routers zu sein. Router mit mehreren unnummerierten Schnittstellen KÖNNEN (MAY) mehrere router-ids haben. Jede unnummerierte Schnittstelle MUSS (MUST) mit einer bestimmten router-id assoziiert sein. Diese Assoziation DARF (MUST NOT) sich (selbst über Neustarts hinweg) ohne Neukonfiguration des Routers nicht ändern.
DISKUSSION Diese Spezifikation lässt keine Router zu, die nicht mindestens eine IP-Adresse haben. Wir betrachten dies nicht als ernsthafte Einschränkung, da ein Router eine IP-Adresse benötigt, um die Manageability-Anforderungen von Kapitel [8] zu erfüllen, selbst wenn der Router nur an Point-to-Point-Leitungen angeschlossen ist.
IMPLEMENTIERUNG
Eine mögliche Methode zur Wahl der router-id, die diese Anforderung erfüllt, ist die Verwendung der numerisch kleinsten (oder größten) IP-Adresse (Behandlung der Adresse als 32-Bit-Ganzzahl), die dem Router zugewiesen ist.
4.2.2.3 Unbenutzte IP-Header-Bits: RFC 791 Abschnitt 3.1
Der IP-Header enthält zwei reservierte Bits: eines im Type-of-Service-Byte und das andere im Flags-Feld. Ein Router DARF (MUST NOT) eines dieser Bits auf Eins setzen in Datagrammen, die vom Router erzeugt werden. Ein Router DARF (MUST NOT) ein Paket lediglich deshalb verwerfen (empfangen oder weiterleiten verweigern), weil einer oder mehrere dieser reservierten Bits einen von Null verschiedenen Wert haben; d. h., der Router DARF (MUST NOT) die Werte dieser Bits prüfen.
DISKUSSION Zukünftige Überarbeitungen des IP-Protokolls können diese unbenutzten Bits nutzen. Diese Regeln sollen sicherstellen, dass diese Überarbeitungen eingesetzt werden können, ohne dass alle Router im Internet gleichzeitig aktualisiert werden müssen.
4.2.2.4 Type of Service: RFC 791 Abschnitt 3.1
Das Type-of-Service-Byte im IP-Header ist in drei Abschnitte unterteilt: das Precedence-Feld (höchstwertige 3 Bits), ein Feld, das üblicherweise Type of Service oder TOS genannt wird (nächste 4 Bits), und ein reserviertes Bit (das niederwertigste Bit).
Regeln für das reservierte Bit wurden in Abschnitt [4.2.2.3] beschrieben.
Eine ausführlichere Erörterung des TOS-Felds und seiner Verwendung findet sich in [ROUTE:11].
Die Beschreibung des IP-Precedence-Felds wird durch Abschnitt [5.3.3] ersetzt. RFC 795, Service Mappings, ist veraltet und SOLLTE (SHOULD) nicht implementiert werden.
4.2.2.5 Header Checksum: RFC 791 Abschnitt 3.1
Wie in Abschnitt [5.2.2] angegeben, MUSS (MUST) ein Router die IP-Prüfsumme jedes empfangenen Pakets verifizieren und MUSS (MUST) Nachrichten mit ungültigen Prüfsummen verwerfen. Der Router DARF (MUST NOT) ein Mittel bereitstellen, diese Prüfsummenverifizierung zu deaktivieren.
Ein Router KANN (MAY) inkrementelle IP-Header-Prüfsummen-Aktualisierung verwenden, wenn die einzige Änderung am IP-Header die Time to Live ist. Dies wird die Möglichkeit unentdeckter Korruption des IP-Headers durch den Router verringern. Siehe [INTERNET:6] für eine Erörterung der inkrementellen Aktualisierung der Prüfsumme.
IMPLEMENTIERUNG Eine ausführlichere Beschreibung der IP-Prüfsumme, einschließlich umfangreicher Implementierungshinweise, findet sich in [INTERNET:6] und [INTERNET:7].
4.2.2.6 Nicht erkannte Header-Optionen: RFC 791 Abschnitt 3.1
Ein Router MUSS (MUST) IP-Optionen ignorieren, die er nicht erkennt. Eine Korollarbedingung dieser Anforderung ist, dass ein Router die End of Option List-Option und die No Operation-Option implementieren MUSS (MUST), da keine von beiden eine explizite Länge enthält.
DISKUSSION Alle zukünftigen IP-Optionen werden eine explizite Länge enthalten.
4.2.2.7 Fragmentierung: RFC 791 Abschnitt 3.2
Fragmentierung, wie in [INTERNET:1] beschrieben, MUSS (MUST) von einem Router unterstützt werden.
Wenn ein Router ein IP-Datagramm fragmentiert, SOLLTE (SHOULD) er die Anzahl der Fragmente minimieren. Wenn ein Router ein IP-Datagramm fragmentiert, SOLLTE (SHOULD) er die Fragmente in Reihenfolge senden. Eine Fragmentierungsmethode, die ein IP-Fragment erzeugen kann, das signifikant kleiner als das andere ist, KANN (MAY) das erste IP-Fragment als das kleinere machen.
DISKUSSION Es gibt mehrere Fragmentierungstechniken, die im Internet häufig verwendet werden. Eine besteht darin, das IP-Datagramm in IP-Fragmente zu spalten, wobei das erste MTU-groß ist und die anderen ungefähr gleich groß, kleiner als die MTU sind. Der Grund dafür ist zweifach. Das erste IP-Fragment in der Sequenz wird die effektive MTU des aktuellen Pfads zwischen den Hosts sein, und die folgenden IP-Fragmente sind so dimensioniert, dass eine weitere Fragmentierung des IP-Datagramms minimiert wird. Eine andere Technik besteht darin, das IP-Datagramm in MTU-große IP-Fragmente zu spalten, wobei das letzte Fragment das einzige kleinere ist, wie in [INTERNET:1] beschrieben.
Ein häufiger Trick, der von einigen Implementierungen von TCP/IP verwendet wird, besteht darin, ein IP-Datagramm in IP-Fragmente zu fragmentieren, die nicht größer als 576 Byte sind, wenn das IP-Datagramm durch einen Router reisen soll. Dies soll bewirken, dass die resultierenden IP-Fragmente den Rest des Pfads ohne weitere Fragmentierung passieren. Dies würde jedoch mehr Last auf den Ziel-Host erzeugen, da er eine größere Anzahl von IP-Fragmenten zu einem IP-Datagramm reassemblieren müsste. Es wäre auch auf Netzen ineffizient, wo sich die MTU nur einmal ändert und viel größer als 576 Byte bleibt. Beispiele sind LAN-Netze wie ein IEEE 802.5-Netz mit einer MTU von 2048 oder ein Ethernet-Netz mit einer MTU von 1500.
Eine andere erörterte Fragmentierungstechnik bestand darin, das IP-Datagramm in ungefähr gleich große IP-Fragmente zu spalten, mit einer Größe kleiner oder gleich der MTU des Next-Hop-Netzes. Dies soll die Anzahl der Fragmente minimieren, die aus zusätzlicher Fragmentierung weiter unten im Pfad resultieren würden, und gleiche Verzögerung für jedes Fragment sicherstellen.
Router SOLLTEN (SHOULD) die geringstmögliche Anzahl von IP-Fragmenten erzeugen.
Arbeit mit langsamen Maschinen lässt uns glauben, dass, wenn es notwendig ist, Nachrichten zu fragmentieren, das Senden des kleinen IP-Fragments zuerst die Chance eines Hosts mit langsamer Schnittstelle maximiert, alle Fragmente zu empfangen.
4.2.2.8 Reassembly: RFC 791 Abschnitt 3.2
Wie im entsprechenden Abschnitt von [INTRO:2] spezifiziert, MUSS (MUST) ein Router die Reassemblierung von Datagrammen unterstützen, die er an sich selbst zustellt.
4.2.2.9 Time to Live: RFC 791 Abschnitt 3.2
Time-to-Live(TTL)-Handling für vom Router erzeugte oder empfangene Pakete wird durch [INTRO:2] geregelt; dieser Abschnitt ändert keine seiner Bestimmungen. Da jedoch der Rest des IP-Protocol-Abschnitts von [INTRO:2] umgeschrieben wird, gilt dies auch für diesen Abschnitt.
Beachten Sie insbesondere, dass ein Router die TTL eines Pakets NICHT (MUST NOT) prüfen darf, außer wenn er es weiterleitet.
Ein Router DARF (MUST NOT) ein Datagramm mit einem Time-to-Live(TTL)-Wert von Null erzeugen oder weiterleiten.
Ein Router DARF (MUST NOT) ein Datagramm allein deshalb verwerfen, weil es mit TTL gleich Null oder Eins empfangen wurde; wenn es an den Router gerichtet ist und ansonsten gültig, MUSS (MUST) der Router versuchen, es zu empfangen.
Bei Nachrichten, die der Router erzeugt, MUSS (MUST) die IP-Schicht ein Mittel bereitstellen, damit die Transportschicht das TTL-Feld jedes gesendeten Datagrams setzen kann. Wenn ein fester TTL-Wert verwendet wird, MUSS (MUST) er konfigurierbar sein. Die Zahl SOLLTE (SHOULD) den typischen Internet-Durchmesser überschreiten, und die aktuelle Weisheit schlägt vor, dass sie den doppelten Internet-Durchmesser überschreiten sollte, um Wachstum zu ermöglichen. Aktuelle vorgeschlagene Werte sind normalerweise in der Assigned Numbers RFC veröffentlicht. Das TTL-Feld hat zwei Funktionen: die Lebensdauer von TCP-Segmenten begrenzen (siehe RFC 793 [TCP:1], S. 28) und Internet-Routing-Schleifen beenden. Obwohl TTL eine Zeit in Sekunden ist, hat es auch einige Attribute eines Hop-Counts, da jeder Router verpflichtet ist, das TTL-Feld um mindestens eins zu reduzieren.
TTL-Ablauf ist darauf ausgelegt, dass Datagramme von Routern, aber nicht vom Ziel-Host verworfen werden. Hosts, die als Router fungieren, indem sie Datagramme weiterleiten, müssen daher den TTL-Regeln des Routers folgen.
Ein höheres Schicht-Protokoll möchte möglicherweise die TTL setzen, um eine "expanding scope"-Suche nach einer Internet-Ressource zu implementieren. Dies wird von einigen Diagnosewerkzeugen verwendet und wird voraussichtlich nützlich sein, um den "nächsten" Server einer bestimmten Klasse unter Verwendung von IP-Multicasting zu lokalisieren, zum Beispiel. Ein bestimmtes Transport-Protokoll möchte möglicherweise auch seine eigene TTL-Grenze für maximale Datagramm-Lebensdauer spezifizieren.
Ein fester Standardwert muss mindestens groß genug für den Internet-"Durchmesser", d. h. den längsten möglichen Pfad, sein. Ein vernünftiger Wert ist etwa der doppelte Durchmesser, um weiteres Internet-Wachstum zu ermöglichen. Zum Zeitpunkt dieses Schreibens durchqueren Nachrichten, die die USA kreuzen, häufig 15 bis 20 Router; dies spricht für einen Standard-TTL-Wert über 40, und 64 ist ein häufiger Wert.
4.2.2.10 Multi-subnet Broadcasts: RFC 922
All-subnets-Broadcasts (in [INTERNET:3] multi-subnet broadcasts genannt) sind veraltet. Siehe Abschnitt [5.3.5.3].
4.2.2.11 Addressing: RFC 791 Abschnitt 3.2
Wie in 2.2.5.1 bemerkt, gibt es nun fünf Klassen von IP-Adressen: Class A bis Class E. Class-D-Adressen werden für IP-Multicasting [INTERNET:4] verwendet, während Class-E-Adressen für experimentelle Nutzung reserviert sind. Der Unterschied zwischen Class-A-, B- und C-Adressen ist nicht mehr wichtig; sie werden als generalisierte Unicast-Netzpräfixe mit nur historischem Interesse an ihrer Klasse verwendet.
Eine IP-Multicast-Adresse ist eine 28-Bit-logische Adresse, die für eine Gruppe von Hosts steht, und kann entweder permanent oder vorübergehend sein. Permanente Multicast-Adressen werden von der Internet Assigned Number Authority [INTRO:7] zugewiesen, während vorübergehende Adressen dynamisch an vorübergehende Gruppen zugewiesen werden können. Die Gruppenmitgliedschaft wird dynamisch unter Verwendung von IGMP [INTERNET:4] bestimmt.
Wir fassen nun die wichtigen Sonderfälle für allgemeine Unicast-IP-Adressen zusammen, unter Verwendung der folgenden Notation für eine IP-Adresse:
{ <Network-prefix>, <Host-number> }
und der Notation -1 für ein Feld, das alle 1-Bits enthält, und der Notation 0 für ein Feld, das alle 0-Bits enthält.
(a) { 0, 0 }
Dieser Host auf diesem Netz. Er DARF (MUST NOT) nicht als Quelladresse von Routern verwendet werden, außer der Router KANN (MAY) dies als Quelladresse als Teil eines Initialisierungsverfahrens verwenden (z. B., wenn der Router BOOTP verwendet, um seine Konfigurationsinformationen zu laden).
Eingehende Datagramme mit einer Quelladresse von { 0, 0 }, die für lokale Zustellung empfangen werden (siehe Abschnitt [5.2.3]), MÜSSEN (MUST) akzeptiert werden, wenn der Router das zugehörige Protokoll implementiert und dieses Protokoll angemessene Maßnahmen definiert, die zu ergreifen sind. Andernfalls MUSS (MUST) ein Router jedes lokal zugestellte Datagramm, dessen Quelladresse { 0, 0 } ist, still verwerfen.
DISKUSSION Einige Protokolle definieren spezifische Maßnahmen als Reaktion auf ein empfangenes Datagramm, dessen Quelladresse { 0, 0 } ist. Zwei Beispiele sind BOOTP und ICMP Mask Request. Der ordnungsgemäße Betrieb dieser Protokolle hängt oft von der Fähigkeit ab, Datagramme zu empfangen, deren Quelladresse { 0, 0 } ist. Für die meisten Protokolle ist es jedoch am besten, Datagramme mit Quelladresse { 0, 0 } zu ignorieren, da sie wahrscheinlich von einem falsch konfigurierten Host oder Router erzeugt wurden. Wenn also ein Router weiß, wie er mit einem gegebenen Datagramm mit Quelladresse { 0, 0 } umgeht, MUSS (MUST) er es akzeptieren. Andernfalls MUSS (MUST) er es verwerfen.
Siehe auch Abschnitt [4.2.3.1] für eine nicht standardmäßige Verwendung von { 0, 0 }.
(b) { 0,
Spezifizierter Host auf diesem Netz. Er DARF (MUST NOT) nicht von Routern gesendet werden, außer dass der Router dies als Quelladresse als Teil eines Initialisierungsverfahrens verwenden KANN (MAY), durch das er seine eigene IP-Adresse lernt.
(c) { -1, -1 }
Limited Broadcast. Er DARF (MUST NOT) nicht als Quelladresse verwendet werden.
Ein Datagramm mit dieser Zieladresse wird von jedem Host und Router auf dem verbundenen physischen Netz empfangen, aber nicht außerhalb dieses Netzes weitergeleitet.
(d) {
Directed Broadcast - ein an den spezifizierten Netzpräfix gerichteter Broadcast. Er DARF (MUST NOT) nicht als Quelladresse verwendet werden. Ein Router KANN (MAY) Network Directed Broadcast-Pakete erzeugen. Ein Router MUSS (MUST) Network Directed Broadcast-Pakete empfangen; ein Router KANN (MAY) jedoch eine Konfigurationsoption haben, um den Empfang dieser Pakete zu verhindern. Eine solche Option MUSS (MUST) standardmäßig den Empfang erlauben.
(e) { 127, <any> }
Interne Host-Loopback-Adresse. Adressen dieser Form DÜRFEN (MUST NOT) nicht außerhalb eines Hosts erscheinen.
Der <Network-prefix> wird administrativ so zugewiesen, dass sein Wert im Routing-Domänen, mit dem das Gerät verbunden ist, eindeutig ist.
IP-Adressen dürfen nicht den Wert 0 oder -1 für die Felder <Host-number> oder <Network-prefix> haben, außer in den oben aufgeführten Sonderfällen. Dies impliziert, dass jedes dieser Felder mindestens zwei Bits lang sein wird.
DISKUSSION Frühere Versionen dieses Dokuments vermerkten auch, dass Subnetz-Nummern weder 0 noch -1 sein dürfen und mindestens zwei Bits lang sein müssen. In einer CIDR-Welt ist die Subnetz-Nummer offensichtlich eine Erweiterung des Netzpräfix und kann ohne den Rest des Präfix nicht interpretiert werden. Diese Einschränkung von Subnetz-Nummern ist daher im Hinblick auf CIDR bedeutungslos und kann sicher ignoriert werden.
Für eine weitere Erörterung von Broadcast-Adressen siehe Abschnitt [4.2.3.1].
Wenn ein Router ein beliebiges Datagramm erzeugt, MUSS (MUST) die IP-Quelladresse eine seiner eigenen IP-Adressen sein (aber keine Broadcast- oder Multicast-Adresse). Die einzige Ausnahme ist während der Initialisierung.
Für die meisten Zwecke wird ein an eine Broadcast- oder Multicast-Zieladresse gerichtetes Datagramm so verarbeitet, als ob es an eine der IP-Adressen des Routers gerichtet worden wäre; das heißt:
o Ein Router MUSS (MUST) jedes Paket mit einer Broadcast-Zieladresse normal empfangen und verarbeiten.
o Ein Router MUSS (MUST) jedes Paket, das an eine Multicast-Zieladresse gesendet wird, die der Router zu empfangen gebeten hat, normal empfangen und verarbeiten.
Der Begriff specific-destination address bedeutet die äquivalente lokale IP-Adresse des Hosts. Die specific-destination address ist definiert als die Zieladresse im IP-Header, es sei denn, der Header enthält eine Broadcast- oder Multicast-Adresse, in welchem Fall die specific-destination eine dem physischen Interface, auf dem das Datagramm eintraf, zugewiesene IP-Adresse ist.
Ein Router MUSS (MUST) jedes empfangene Datagramm, das eine nach den Regeln dieses Abschnitts ungültige IP-Quelladresse enthält, still verwerfen. Diese Validierung könnte entweder von der IP-Schicht oder (wenn angemessen) von jedem Protokoll in der Transportschicht durchgeführt werden. Wie bei jedem Datagramm, das ein Router verwirft, SOLLTE (SHOULD) der Datagramm-Verwurf gezählt werden.
DISKUSSION Ein falsch adressiertes Datagramm könnte durch einen Link-Layer-Broadcast eines Unicast-Datagramms oder durch einen anderen Router oder Host verursacht werden, der verwirrt oder falsch konfiguriert ist.
4.2.3 SPEZIFISCHE THEMEN
4.2.3.1 IP Broadcast-Adressen
Aus historischen Gründen gibt es eine Reihe von IP-Adressen (einige standard und einige nicht), die verwendet werden, um anzuzeigen, dass ein IP-Paket ein IP-Broadcast ist. Ein Router
(1) MUSS (MUST) Pakete, die an 255.255.255.255 oder {
(2) SOLLTE (SHOULD) bei Empfang jedes an 0.0.0.0 oder {
(3) SOLLTE (SHOULD) (standardmäßig) die Limited Broadcast-Adresse (255.255.255.255) verwenden, wenn er einen für ein verbundenes (Sub)Netz bestimmten IP-Broadcast erzeugt (außer beim Senden einer ICMP Address Mask Reply, wie in Abschnitt [4.3.3.9] erörtert). Ein Router MUSS (MUST) Limited Broadcasts empfangen.
(4) SOLLTE (SHOULD) keine an 0.0.0.0 oder {
DISKUSSION
Im zweiten Aufzählungspunkt kann der Router offensichtlich Adressen der Form {
4.2.3.2 IP Multicasting
Ein IP-Router SOLLTE (SHOULD) die Host Requirements in Bezug auf IP-Multicasting erfüllen, wie in [INTRO:2] spezifiziert. Ein IP-Router SOLLTE (SHOULD) lokalen IP-Multicast auf allen verbundenen Netzen unterstützen. Wenn eine Abbildung von IP-Multicast-Adressen auf Link-Layer-Adressen spezifiziert wurde (siehe die verschiedenen IP-over-xxx-Spezifikationen), SOLLTE (SHOULD) er diese Abbildung verwenden und KANN (MAY) konfigurierbar sein, stattdessen den Link-Layer-Broadcast zu verwenden. Auf Point-to-Point-Leitungen und allen anderen Schnittstellen werden Multicasts als Link-Layer-Broadcasts gekapselt. Die Unterstützung für lokalen IP-Multicast umfasst das Erzeugen von Multicast-Datagrammen, das Beitreten zu Multicast-Gruppen und Empfangen von Multicast-Datagrammen sowie das Verlassen von Multicast-Gruppen. Dies impliziert Unterstützung für alles von [INTERNET:4] einschließlich IGMP (siehe Abschnitt [4.4]).
DISKUSSION Obwohl [INTERNET:4] mit "Host Extensions for IP Multicasting" betitelt ist, gilt es für alle IP-Systeme, sowohl Hosts als auch Router. Insbesondere können Router, da sie Multicast-Gruppen beitreten können, korrekterweise den Host-Teil von IGMP ausführen, indem sie ihre Gruppenmitgliedschaften allen Multicast-Routern melden, die auf ihren angehängten Netzen möglicherweise vorhanden sind (ungeachtet dessen, ob sie selbst Multicast-Router sind).
Einige Router-Protokolle können spezifisch Unterstützung für IP-Multicasting erfordern (z. B. OSPF [ROUTE:1]) oder empfehlen (z. B. ICMP Router Discovery [INTERNET:13]).
4.2.3.3 Path MTU Discovery
Um Fragmentierung zu eliminieren oder zu minimieren, ist es wünschenswert zu wissen, was die Path MTU entlang des Pfads von der Quelle zum Ziel ist. Die Path MTU ist das Minimum der MTUs jedes Hops im Pfad. [INTERNET:14] beschreibt eine Technik zur dynamischen Entdeckung der maximum transmission unit (MTU) eines beliebigen Internet-Pfads. Für einen Pfad, der durch einen Router führt, der [INTERNET:14] nicht unterstützt, könnte diese Technik die korrekte Path MTU nicht entdecken, aber sie wird immer eine Path MTU wählen, die so genau ist wie und in vielen Fällen genauer als die Path MTU, die von älteren Techniken oder der aktuellen Praxis gewählt würde.
Wenn ein Router ein IP-Datagramm erzeugt, SOLLTE (SHOULD) er das in [INTERNET:14] beschriebene Schema verwenden, um die Größe des Datagramms zu begrenzen. Wenn die Route des Routers zum Ziel des Datagramms von einem Routing-Protokoll gelernt wurde, das Path-MTU-Informationen liefert, wird das in [INTERNET:14] beschriebene Schema dennoch verwendet, aber die Path-MTU-Informationen aus dem Routing-Protokoll SOLLTEN (SHOULD) als anfängliche Schätzung der Path MTU und auch als obere Grenze der Path MTU verwendet werden.
4.2.3.4 Subnetting
Unter bestimmten Umständen kann es wünschenswert sein, Subnetze eines bestimmten Netzes zu unterstützen, die nur durch einen Pfad miteinander verbunden sind, der nicht Teil des subnettierten Netzes ist. Dies ist als discontiguous subnetwork support bekannt.
Router MÜSSEN (MUST) discontiguous Subnetze unterstützen.
IMPLEMENTIERUNG In klassischen IP-Netzen war dies sehr schwer zu erreichen; in CIDR-Netzen ist es ein natürliches Nebenprodukt. Daher SOLLTE (SHOULD) ein Router keine Annahmen über Subnetz-Architektur treffen, sondern SOLLTE (SHOULD) jede Route als generalisierten Netzpräfix behandeln.
DISKUSSION Das Internet wächst in letzter Zeit mit enormer Rate. Dies setzt die IP-Adressierungstechnologie stark unter Spannung. Ein wesentlicher Faktor bei dieser Spannung sind die strengen IP-Adress-Klassengrenzen. Diese machen es schwierig, Netzpräfixe effizient auf ihre Netze abzustimmen und mehrere Netzpräfixe in einer einzigen Route-Ankündigung zu aggregieren. Durch Eliminierung der strengen Klassengrenzen der IP-Adresse und Behandlung jeder Route als generalisierter Netzpräfix können diese Spannungen stark reduziert werden.
Die Technologie, dies derzeit zu tun, ist Classless Inter Domain Routing (CIDR) [INTERNET:15].
Aus ähnlichen Gründen könnte ein mit einem bestimmten Netzpräfix assoziierter Adressblock in Subblöcke unterschiedlicher Größe unterteilt werden, so dass die mit den Subblöcken assoziierten Netzpräfixe unterschiedliche Länge hätten. Zum Beispiel könnte innerhalb eines Blocks, dessen Netzpräfix 8 Bits lang ist, ein Subblock ein 16-Bit-Netzpräfix haben, ein anderer ein 18-Bit-Netzpräfix und ein dritter ein 14-Bit-Netzpräfix.
4.2.3.5 Address Resolution Protocol (ARP)
Ein Router MUSS (MUST) das Address Resolution Protocol (ARP) [INTERNET:2] implementieren, wenn er direkt mit Netzen verbunden ist, die ARP verwenden.
Ein Router SOLLTE (SHOULD) eine ARP-Cache-Bereinigung implementieren, die Einträge nach einer kurzen Zeitspanne entfernt.
Die ARP-Spezifikation [INTERNET:2] besagt, dass ein Host aktiv an einem ARP-Request für eine gegebene Ziel-IP-Adresse teilnehmen kann, indem er eine ARP-Reply sendet, die besagt, dass die Hardware-Adresse des Hosts die IP-Adresse ist. Ein Router DARF (MUST NOT) dies tun (außer er ist für die Proxy-ARP-Agent-Funktion konfiguriert).
DISKUSSION Ein Problem, das auftreten kann, wenn ARP-Cache-Einträge auf diese Weise verwaltet werden, ist, dass ein Host oder Router für eine erweiterte Periode ausfallen könnte, während sein ARP-Cache-Eintrag noch in anderen Hosts und Routern existiert. Wenn dies geschieht, können Pakete zu einem toten Host oder Router weitergeleitet werden, bis ihre ARP-Cache-Einträge ablaufen. Da ARP-Cache-Einträge typischerweise für relativ kurze Zeiträume (minutenlang) aufbewahrt werden, ist das Ausmaß des Problems begrenzt. Hosts und Router, die ARP verwenden, lösen das Problem, indem sie eine ARP-Request für den toten Host oder Router senden, bevor sie sein ARP-Cache ableiten.
Ein Router, der ARP verwendet, SOLLTE (SHOULD) in der Lage sein, Proxy-ARP zu betreiben (mit anderen Worten, auf einem Netz zu antworten, dass er die IP-Adresse eines Routers auf einem anderen netzverbundenen Netz hat).
4.3 INTERNET CONTROL MESSAGE PROTOCOL - ICMP
Ein Router MUSS (MUST) die in [INTERNET:8] definierte ICMP-Protokoll-Spezifikation implementieren und MUSS (MUST) mit den in [INTRO:2] (dort als "Internet Control Message Protocol -- ICMP" bezeichnet) definierten Anforderungen konform sein. Es wird dringend empfohlen, dass die Implementierung fehlerfrei ist, da ICMP eine wichtige Rolle im Internet spielt. Ein Router SOLLTE (SHOULD) die folgenden ICMP-Nachrichtentypen zumindest generieren: Destination Unreachable, Time Exceeded, Source Quench, Redirect, Echo (Reply), Timestamp Reply und Parameter Problem. Weitere Einzelheiten finden sich in späteren Abschnitten. Der Router MUSS (MUST) zudem die ICMP-Mask Reply und ICMP Router Advertisement-Nachrichtentypen generieren (wie in [4.3.3.9] bzw. [4.3.3.10] erörtert) und SOLLTE (SHOULD) den ICMP Information Reply-Nachrichtentyp generieren. Ein Router KANN (MAY) die ICMP Timestamp Reply-Nachricht generieren.
Ein Router MUSS (MUST) die ICMP-Nachrichtentypen Destination Unreachable, Time Exceeded, Redirect, Echo (Request), Timestamp Request, Address Mask Request, Router Solicitation, Router Advertisement und Parameter Problem (Code 0) verarbeiten. Ein Router MUSS (MUST) auch ICMP-Nachrichten verarbeiten, die Informationen über Fehler im IP-Header oder in IP-Optionen tragen. Ein Router MUSS (MUST) ICMP-Mask Reply-Nachrichten verarbeiten (siehe [4.3.3.9]) und SOLLTE (SHOULD) ICMP Information Reply-Nachrichten verarbeiten.
Ein Router DARF (MUST NOT) ICMP-Nachrichten anders als als Antwort auf ein IP-Datagramm oder als Ergebnis einer Verarbeitung eines IP-Datagramms erzeugen. Ein Router DARF (MUST NOT) als Reaktion auf ein ICMP-Fehler-Nachrichten-Datagramm ein ICMP-Fehler-Nachrichten-Datagramm erzeugen.
Ein Router MUSS (MUST) jede in diesem Dokument angegebene ICMP-Nachricht, die er empfängt, still verwerfen, die keine der folgenden ist:
(1) eine ICMP-Echo-Anfrage (Typ 8),
(2) eine ICMP-Timestamp-Anfrage (Typ 13),
(3) eine ICMP-Adressmasken-Anfrage (Typ 17),
(4) eine ICMP-Information-Anfrage (Typ 15), oder
(5) eine ICMP-Router-Solicitation (Typ 10).
Ein Router SOLLTE (SHOULD) alle ICMP-Anfragen, die an eine seiner eigenen IP-Adressen gerichtet sind (d. h. für die er das Ziel ist), verarbeiten, wie in [INTRO:2] spezifiziert.
Ein Router MUSS (MUST) als Antwort auf einen Empfang eine ICMP-Fehlermeldung (Destination Unreachable, Time Exceeded, Redirect, Source Quench oder Parameter Problem) erzeugen, die das in [INTRO:2] angegebene Format verwendet.
ICMP-Nachrichten, die Fehler anzeigen, MÜSSEN (MUST) die gesamte Internet-Header plus die ersten 64 Datenbits des ursprünglichen Datagramms enthalten, das den Fehler verursacht hat.
ICMP-Nachrichten (Typ 4 (Source Quench) ausgenommen) SOLLTEN (SHOULD) die Datagramme bis zum nächsten Vielfachen von 32 Bit gegenüber dem Beginn des IP-Headers auffüllen, um die Einfachheit der Verarbeitung durch die empfangende Implementierung zu maximieren.
ICMP-Nachrichten sind in Abschnitt [4.3.3.1] bis [4.3.3.10] erörtert.
Um eine ICMP-Fehlernachricht zu erzeugen, MUSS (MUST) ein Router das in Abschnitt [5.2.1] angegebene Verfahren verwenden, um den Next-Hop für die Nachricht auszuwählen.
4.3.1 EINLEITUNG
Dieser Abschnitt beschreibt die für Router erforderlichen ICMP-Funktionen.
4.3.2 GENERIERUNG VON ICMP-FEHLERNACHRICHTEN
Ein Router MUSS (MUST) in der Lage sein, ICMP-Fehlernachrichten zu erzeugen.
Eine ICMP-Fehlernachricht MUSS (MUST) als Ergebnis der Verarbeitung eines IP-Datagramms generiert werden, das nicht die ICMP-Fehlernachricht selbst ist, die generiert wird. Ein Router DARF (MUST NOT) eine ICMP-Fehlernachricht als direktes Ergebnis des Empfangs einer ICMP-Fehlernachricht erzeugen.
Ein Router SOLLTE (SHOULD) die Rate begrenzen, mit der er ICMP-Fehlernachrichten erzeugt. Ein Router SOLLTE (SHOULD) drei Arten von Rate-Limiting-Mechanismen unterstützen: Token-Bucket, Bandbreitenbasiert und nach Quelle isoliert.
DISKUSSION Token-Bucket ist ein Mechanismus, bei dem Tokens mit einer konstanten Rate generiert werden; wenn ein Token verfügbar ist, wenn eine Nachricht generiert werden muss, wird die Nachricht gesendet und das Token verbraucht; wenn kein Token verfügbar ist, wird die Nachricht verworfen. Dies begrenzt (a) die maximale Rate, mit der Nachrichten gesendet werden, und (b) die durchschnittliche Rate. Die Token-Bucket-Größe bestimmt, wie viel Burst zulässig ist.
In Anbetracht dieses Algorithmus ist es wünschenswert, die erlaubte Burst-Größe zu konfigurieren.
Die nach Quelle isolierte Begrenzung bedeutet, dass die Begrenzung pro Quell-Host oder insgesamt höchstens einmal pro T Millisekunden angewendet wird.
(3) Bandbreitenbasiert - zum Beispiel die Rate begrenzen, mit der ICMP-Nachrichten über eine bestimmte Schnittstelle gesendet werden, auf einen Bruchteil der Bandbreite des angeschlossenen Netzes.
4.3.3 SPEZIFISCHE PROBLEME
4.3.3.1 Destination Unreachable
Wenn ein Router ein Paket nicht weiterleiten kann, weil er überhaupt keine Routen (einschließlich keiner Default-Route) zum im Paket angegebenen Ziel hat, dann MUSS (MUST) der Router eine Destination Unreachable, Code 0 (Network Unreachable) ICMP-Nachricht erzeugen. Wenn der Router Routen zum im Paket angegebenen Zielnetz hat, aber der TOS, der für die Routen angegeben ist, weder der Standard-TOS (0000) noch der TOS des Pakets ist, das der Router zu routen versucht, dann MUSS (MUST) der Router eine Destination Unreachable, Code 11 (Network Unreachable for TOS) ICMP-Nachricht erzeugen.
Wenn ein Paket an einen Host auf einem Netz weitergeleitet werden soll, das direkt mit dem Router verbunden ist (d. h., der Router ist der Last-Hop-Router) und der Router festgestellt hat, dass es keinen Pfad zum Ziel-Host gibt, dann MUSS (MUST) der Router eine Destination Unreachable, Code 1 (Host Unreachable) ICMP-Nachricht erzeugen. Wenn ein Paket an einen Host weitergeleitet werden soll, der auf einem Netz ist, das direkt mit dem Router verbunden ist, und der Router das Paket nicht weiterleiten kann, weil keine Route zum Ziel einen TOS hat, der entweder gleich dem im Paket angeforderten TOS ist oder der Standard-TOS (0000) ist, dann MUSS (MUST) der Router eine Destination Unreachable, Code 12 (Host Unreachable for TOS) ICMP-Nachricht erzeugen.
DISKUSSION Die Absicht ist, dass ein Router die "generische" Host/Network-Unreachable erzeugt, wenn er überhaupt keinen Pfad (einschließlich Default-Routen) zum Ziel hat. Wenn der Router einen oder mehrere Pfade zum Ziel hat, aber keiner dieser Pfade einen akzeptablen TOS hat, dann erzeugt der Router die "unreachable for TOS"-Nachricht.
4.3.3.2 Redirect
Die ICMP-Redirect-Nachricht wird generiert, um einen lokalen Host zu informieren, dass er für bestimmten Datenverkehr einen anderen Next-Hop-Router verwenden sollte.
Im Gegensatz zu [INTRO:2] KANN (MAY) ein Router ICMP-Redirects ignorieren, wenn er einen Pfad für ein vom Router erzeugtes Paket auswählt, falls der Router ein Routing-Protokoll ausführt oder falls Forwarding auf dem Router und auf der Schnittstelle, über die das Paket gesendet wird, aktiviert ist.
4.3.3.3 Source Quench
Ein Router SOLLTE (SHOULD) keine ICMP-Source-Quench-Nachrichten erzeugen. Wie in Abschnitt [4.3.2] angegeben, MUSS (MUST) ein Router, der Source-Quench-Nachrichten erzeugt, in der Lage sein, die Rate zu begrenzen, mit der sie generiert werden.
DISKUSSION Forschung scheint zu suggerieren, dass Source Quench Netzwerkbandbreite verbraucht, aber ein ineffektives (und unfaires) Gegenmittel gegen Stau (congestion) ist. Siehe zum Beispiel [INTERNET:9] und [INTERNET:10]. Abschnitt [5.3.6] erörtert das aktuelle Denken darüber, wie Router mit Überlast und Netzwerkstau umgehen sollten.
Ein Router KANN (MAY) alle empfangenen ICMP-Source-Quench-Nachrichten ignorieren.
DISKUSSION Ein Router selbst kann einen Source Quench als Ergebnis des Sendens eines Pakets an einen anderen Router oder Host erhalten. Solche Datagramme könnten z. B. ein EGP-Update sein, das an einen anderen Router gesendet wird, oder ein Telnet-Strom, der an einen Host gesendet wird. Es wurde ein Mechanismus vorgeschlagen ([INTERNET:11], [INTERNET:12]), der die IP-Schicht direkt auf Source Quench reagieren lässt, indem er die Rate steuert, mit der Pakete gesendet werden; dieser Vorschlag ist jedoch derzeit experimentell und nicht empfohlen.
4.3.3.4 Time Exceeded
Wenn ein Router ein Paket weiterleitet und das TTL-Feld des Pakets auf 0 reduziert wird, gelten die Anforderungen von Abschnitt [5.2.3.8].
Wenn der Router ein Paket reassembliert, das für den Router bestimmt ist, agiert er als Internet-Host. Daher gelten [INTRO:2]s Reassembly-Anforderungen.
Wenn der Router eine Time Exceeded-Nachricht empfängt (d. h., für den Router bestimmt ist), MUSS (MUST) er [INTRO:2] entsprechen.
4.3.3.5 Parameter Problem
Ein Router MUSS (MUST) eine Parameter Problem-Nachricht für jeden Fehler erzeugen, der nicht spezifisch von einer anderen ICMP-Nachricht abgedeckt ist. Das IP-Header-Feld oder die IP-Option einschließlich des durch das Zeigerfeld angezeigten Bytes MUSS (MUST) unverändert in den IP-Header aufgenommen werden, der mit dieser ICMP-Nachricht zurückgegeben wird. Abschnitt [4.3.2] definiert eine Ausnahme von dieser Anforderung.
Eine neue Variante der Parameter Problem-Nachricht wurde in [INTRO:2] definiert: Code 1 = required option is missing.
DISKUSSION Diese Variante wird derzeit in der militärischen Gemeinschaft für eine fehlende Security-Option verwendet.
4.3.3.6 Echo Request/Reply
Ein Router MUSS (MUST) eine ICMP-Echo-Server-Funktion implementieren, die Echo-Anfragen empfängt, die an den Router gesendet werden, und entsprechende Echo-Antworten sendet. Ein Router MUSS (MUST) darauf vorbereitet sein, ein ICMP-Echo-Anfragen-Datagramm von mindestens der Größe des Maximums von 576 und den MTUs aller verbundenen Netze zu empfangen, zu reassemblieren und zu echoen.
Die Echo-Server-Funktion KANN (MAY) wählen, nicht auf ICMP-Echo-Anfragen zu antworten, die an IP-Broadcast- oder IP-Multicast-Adressen gerichtet sind.
Ein Router SOLLTE (SHOULD) eine Konfigurationsoption haben, die, falls aktiviert, den Router veranlasst, alle ICMP-Echo-Anfragen still zu ignorieren; falls bereitgestellt, MUSS (MUST) diese Option standardmäßig Antworten erlauben.
DISKUSSION Die neutrale Bestimmung über das Antworten auf Broadcast- und Multicast-Echo-Anfragen leitet sich von [INTRO:2]s "Echo Request/Reply"-Abschnitt ab.
Wie in Abschnitt [10.3.3] angegeben, MUSS (MUST) ein Router auch eine Benutzer/Anwendungsschicht-Schnittstelle zum Senden einer Echo-Anfrage und Empfangen einer Echo-Antwort zu Diagnosezwecken implementieren. Alle ICMP-Echo-Antwort-Nachrichten MÜSSEN (MUST) an diese Schnittstelle weitergegeben werden.
Die IP-Quelladresse in einer ICMP-Echo-Antwort MUSS (MUST) dieselbe wie die specific-destination-Adresse der entsprechenden ICMP-Echo-Anfrage-Nachricht sein.
In einer ICMP-Echo-Anfrage empfangene Daten MÜSSEN (MUST) vollständig in die resultierende Echo-Antwort aufgenommen werden.
Wenn eine Record Route- und/oder Timestamp-Option in einer ICMP-Echo-Anfrage empfangen wird, SOLLTE (SHOULD) diese Option (diese Optionen) aktualisiert werden, um den aktuellen Router einzuschließen, und in den IP-Header der Echo-Antwort-Nachricht ohne Abschneiden aufgenommen werden. So wird die aufgezeichnete Route für die gesamte Hin- und Rückreise sein.
Wenn eine Source Route-Option in einer ICMP-Echo-Anfrage empfangen wird, MUSS (MUST) die Rückroute umgekehrt und als Source Route-Option für die Echo-Antwort-Nachricht verwendet werden, es sei denn, der Router ist sich einer Policy bewusst, die die Zustellung der Nachricht verhindern würde.
4.3.3.7 Information Request/Reply
Ein Router SOLLTE (SHOULD) diese Nachrichten nicht erzeugen oder darauf antworten.
DISKUSSION Das Information Request/Reply-Paar war dazu gedacht, sich selbst konfigurierende Systeme wie disless Workstations zu unterstützen, damit sie ihre IP-Netzpräfixe beim Booten entdecken können. Diese Nachrichten sind jedoch nun veraltet. Die RARP- und BOOTP-Protokolle bieten bessere Mechanismen für einen Host, um seine eigene IP-Adresse zu entdecken.
4.3.3.8 Timestamp und Timestamp Reply
Ein Router KANN (MAY) Timestamp und Timestamp Reply implementieren. Wenn sie implementiert sind, dann:
o Die ICMP-Timestamp-Server-Funktion MUSS (MUST) eine Timestamp Reply auf jede empfangene Timestamp-Nachricht zurückgeben. Sie SOLLTE (SHOULD) für minimale Variabilität in der Verzögerung ausgelegt sein.
o Eine ICMP-Timestamp-Anfrage-Nachricht an eine IP-Broadcast- oder IP-Multicast-Adresse KANN (MAY) still verworfen werden.
o Die IP-Quelladresse in einer ICMP-Timestamp-Antwort MUSS (MUST) dieselbe wie die specific-destination-Adresse der entsprechenden Timestamp-Anfrage-Nachricht sein.
o Wenn eine Source Route-Option in einer ICMP-Timestamp-Anfrage empfangen wird, MUSS (MUST) die Rückroute umgekehrt und als Source Route-Option für die Timestamp-Antwort-Nachricht verwendet werden, es sei denn, der Router ist sich einer Policy bewusst, die die Zustellung der Nachricht verhindern würde.
o Wenn eine Record Route- und/oder Timestamp-Option in einer Timestamp-Anfrage empfangen wird, SOLLTE (SHOULD) diese (diese) Option(en) aktualisiert werden, um den aktuellen Router einzuschließen, und in den IP-Header der Timestamp-Antwort-Nachricht aufgenommen werden.
o Wenn der Router eine Anwendungsschicht-Schnittstelle zum Senden von Timestamp-Anfrage-Nachrichten bereitstellt, dann MÜSSEN (MUST) eingehende Timestamp-Antwort-Nachrichten an die ICMP-Benutzerschnittstelle weitergegeben werden.
Die bevorzugte Form für einen Zeitstempelwert (der Standardwert) ist Millisekunden seit Mitternacht, Universal Time. Es kann jedoch schwierig sein, diesen Wert mit Millisekundenauflösung bereitzustellen. Zum Beispiel verwenden viele Systeme Uhren, die nur mit Netzfrequenz aktualisieren, 50 oder 60 Mal pro Sekunde. Daher ist einige Toleranz in einem Standardwert erlaubt:
(a) Ein Standardwert MUSS (MUST) mindestens 16 Mal pro Sekunde aktualisiert werden (d. h., höchstens die sechs niederwertigen Bits des Werts dürfen undefiniert sein).
(b) Die Genauigkeit eines Standardwerts MUSS (MUST) der von vom Bediener eingestellten CPU-Uhren approximieren, d. h., korrekt innerhalb weniger Minuten.
IMPLEMENTIERUNG Um die zweite Bedingung zu erfüllen, kann ein Router beim Booten oder Neustart einen Zeit-Server abfragen müssen. Es wird empfohlen, das UDP Time Server Protocol zu diesem Zweck zu verwenden. Eine fortgeschrittenere Implementierung würde das Network Time Protocol (NTP) verwenden, um eine nahezu millisekunden-genaue Uhrsynchronisation zu erreichen; dies ist jedoch nicht erforderlich.
4.3.3.9 Address Mask Request/Reply
Ein Router MUSS (MUST) Unterstützung für den Empfang von ICMP-Adressmasken-Anfragen-Nachrichten und das Antworten mit ICMP-Adressmasken-Antwort-Nachrichten implementieren. Diese Nachrichten sind in [INTERNET:2] definiert.
Ein Router SOLLTE (SHOULD) für jede logische Schnittstelle eine Konfigurationsoption haben, die angibt, ob der Router Adressmasken-Anfragen für diese Schnittstelle beantworten darf; diese Option MUSS (MUST) standardmäßig Antworten erlauben. Ein Router DARF (MUST NOT) auf eine Adressmasken-Anfrage antworten, bevor der Router die korrekte Adressmaske kennt.
Ein Router DARF (MUST NOT) auf eine Adressmasken-Anfrage antworten, die eine Quelladresse von 0.0.0.0 hat und auf einer physischen Schnittstelle eintrifft, die mit mehreren logischen Schnittstellen assoziiert ist, und die Adressmasken für diese Schnittstellen nicht alle gleich sind.
Ein Router SOLLTE (SHOULD) alle ICMP-Adressmasken-Antworten, die er empfängt, untersuchen, um zu bestimmen, ob die enthaltenen Informationen mit dem Wissen des Routers über die Adressmaske übereinstimmen. Wenn die ICMP-Adressmasken-Antwort fehlerhaft erscheint, SOLLTE (SHOULD) der Router die Adressmaske und die IP-Adresse des Senders protokollieren. Ein Router DARF (MUST NOT) den Inhalt einer ICMP-Adressmasken-Antwort verwenden, um die korrekte Adressmaske zu bestimmen.
Da Hosts möglicherweise die Adressmaske nicht lernen können, wenn ein Router ausgeschaltet ist, wenn der Host hochfährt, KANN (MAY) ein Router eine unaufgeforderte (gratuitous) ICMP-Adressmasken-Antwort auf jeder seiner logischen Schnittstellen nach der Konfiguration seiner eigenen Adressmasken broadcasten. Dieses Feature kann jedoch in Umgebungen, die variabel lange Adressmasken verwenden, gefährlich sein. Daher, wenn dieses Feature implementiert ist, DÜRFEN (MUST NOT) unaufgeforderte Adressmasken-Antworten über irgendeine logische Schnittstelle(n) broadcastet werden, die entweder:
o Nicht konfiguriert sind, um unaufgeforderte Adressmasken-Antworten zu senden. Jede logische Schnittstelle MUSS (MUST) einen Konfigurationsparameter haben, der dies steuert, und dieser Parameter MUSS (MUST) standardmäßig das Senden der unaufgeforderten Adressmasken-Antworten nicht zulassen.
o Subsumierende (aber nicht identische) Netzpräfixe und physische Schnittstelle teilen.
Die {
DISKUSSION Die Fähigkeit, das Senden von Adressmasken-Antworten durch Router zu deaktivieren, ist an einigen wenigen Standorten erforderlich, die ihren Hosts absichtlich über die Adressmaske lügen. Der Bedarf hierfür wird erwartet wegzufallen, da immer mehr Hosts mit den Host Requirements-Standards konform werden.
Der Grund für sowohl den zweiten Aufzählungspunkt oben als auch die Anforderung bezüglich der zu verwendenden IP-Broadcast-Adresse ist, Probleme zu verhindern, wenn mehrere IP-Netzpräfixe im selben physischen Netz verwendet werden.
4.3.3.10 Router Advertisement und Solicitations
Ein IP-Router MUSS (MUST) den Router-Teil des ICMP-Router-Discovery-Protokolls [INTERNET:13] auf allen verbundenen Netzen unterstützen, auf denen der Router entweder IP-Multicast oder IP-Broadcast-Adressierung unterstützt. Die Implementierung MUSS (MUST) alle für Router spezifizierten Konfigurationsvariablen mit den angegebenen Standardwerten enthalten.
DISKUSSION Router sind nicht verpflichtet, den Host-Teil des ICMP-Router-Discovery-Protokolls zu implementieren, könnten ihn jedoch nützlich finden für den Betrieb, während IP-Forwarding deaktiviert ist (d. h., wenn er als Host agiert).
DISKUSSION Wir bemerken, dass es sehr üblich ist, dass Hosts RIP Version 1 als Router-Discovery-Protokoll verwenden. Solche Hosts hören auf RIP-Verkehr und verwenden Informationen aus diesem Verkehr, um Router zu entdecken und Entscheidungen darüber zu treffen, welchen Router sie als First-Hop-Router für ein gegebenes Ziel verwenden. Während dieses Verhalten entmutigt wird, ist es immer noch üblich, und Implementierer sollten sich dessen bewusst sein.
4.4 INTERNET GROUP MANAGEMENT PROTOCOL - IGMP
IGMP [INTERNET:4] ist ein Protokoll, das zwischen Hosts und Multicast-Routern in einem einzelnen physischen Netz verwendet wird, um die Mitgliedschaft der Hosts in bestimmten Multicast-Gruppen zu etablieren. Multicast-Routern verwenden diese Informationen in Verbindung mit einem Multicast-Routing-Protokoll, um IP-Multicast-Forwarding über das Internet zu unterstützen.
Ein Router SOLLTE (SHOULD) den Host-Teil von IGMP implementieren.