4. Internet Layer - Protocols (Internetschicht - Protokolle)

4.1 Introduction (Einführung)

Dieses Kapitel und Kapitel 5 behandeln die von der Internetschicht verwendeten Protokolle: IP, ICMP und IGMP. Da die Weiterleitung offensichtlich ein zentrales Thema in einem Dokument über Router ist, beschränkt sich Kapitel 5 auf die Aspekte der Protokolle, die direkt mit der Weiterleitung zusammenhängen. Dieses Kapitel enthält den Rest der Diskussion über Internetschichtprotokolle.

4.2 Internet Protocol - IP (Internetprotokoll)

4.2.1 Introduction (Einführung)

Router MÜSSEN das durch [INTERNET:1] definierte IP-Protokoll implementieren. Sie MÜSSEN auch seine obligatorischen Erweiterungen implementieren: Subnetze (definiert in [INTERNET:2]), IP-Broadcast (definiert in [INTERNET:3]) sowie Classless Inter-Domain Routing (CIDR, definiert in [INTERNET:15]).

Implementierer von Routern brauchen die Anforderungen des Kapitels "Internet Protocol -- IP" in [INTRO:2] nicht zu beachten, da dieses Kapitel vollständig in diesem Dokument wiederholt oder ersetzt wird. Router MÜSSEN konform sein und SOLLTEN bedingungslos konform sein mit den IP-bezogenen Anforderungen im Abschnitt "SPECIFIC ISSUES" von [INTRO:2].

Im Folgenden wird in einigen Fällen die Operation als stilles Verwerfen empfangener Datagramme spezifiziert. Dies bedeutet, dass das Datagramm ohne weitere Verarbeitung verworfen wird und der Router als Folge davon keine ICMP-Fehlermeldung sendet (siehe Abschnitt [4.3]). Jedoch SOLLTE der Router zur Diagnose von Problemen die Fähigkeit bieten, Fehler zu protokollieren (siehe Abschnitt [1.3.3]), einschließlich des Inhalts still verworfener Datagramme, und SOLLTE verworfene Datagramme zählen.

4.2.2 Protocol Walk-Through (Protokolldurchgang)

RFC 791 [INTERNET:1] ist die Spezifikation des Internetprotokolls.

4.2.2.1 Options: RFC 791 Section 3.2 (Optionen)

In Datagrammen, die der Router selbst empfängt, MUSS die IP-Schicht die IP-Optionen interpretieren, die sie versteht, und den Rest unverändert für Protokolle höherer Schichten belassen.

Protokolle höherer Schichten benötigen möglicherweise die Fähigkeit, IP-Optionen in den von ihnen gesendeten Datagrammen zu setzen oder die IP-Optionen in den von ihnen empfangenen Datagrammen zu prüfen. Spätere Abschnitte dieses Dokuments diskutieren die spezifische IP-Optionsunterstützung, die von Protokollen höherer Schichten benötigt wird.

DISCUSSION (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 initiieren, müssen sich bewusst sein, dass dies bei Kombination mit Source-Route-Optionen gewisse Mehrdeutigkeiten in der Bedeutung von Optionen einführt.

Folgendes sind die Anforderungen für spezifische IP-Optionen:

(a) Security Option (Sicherheitsoption)

Einige Umgebungen erfordern die Security-Option in jedem initiierten oder empfangenen Paket. Router SOLLTEN die in [INTERNET:5] beschriebene überarbeitete Sicherheitsoption implementieren.

DISCUSSION (Diskussion)

Beachten Sie, dass die in [INTERNET:1] und RFC 1038 ([INTERNET:16]) beschriebene Sicherheitsoption veraltet ist.

(b) Stream Identifier Option (Stream-Identifikator-Option)

Diese Option ist veraltet; Router SOLLTEN diese Option NICHT in von ihnen initiierten Datagrammen platzieren. Diese Option in von Routern empfangenen Datagrammen MUSS ignoriert werden.

(c) Source Route Options (Source-Route-Optionen)

Router MÜSSEN in der Lage sein, als Endziel einer Source-Route zu fungieren. Wenn ein Router ein Paket mit einer abgeschlossenen Source-Route empfängt, hat dieses Paket sein Endziel erreicht. In einer solchen Option zeigt der Zeiger über das letzte Feld hinaus, und die Zieladresse im IP-Header ist die Adresse des Routers. Die empfangene Option (aufgezeichnete Route) MUSS an die Transportschicht (oder ICMP-Nachrichtenverarbeitung) weitergegeben werden.

Im allgemeinen Fall wird die korrekte Antwort auf ein Source-Route-Datagramm dieselbe Route durchlaufen. Router MÜSSEN einen Weg bieten, mit dem Transportprotokolle und Anwendungen die Source-Route im empfangenen Datagramm umkehren können. Wenn der Router keine Richtlinienbeschränkungen kennt, MUSS diese umgekehrte Source-Route in die von ihm initiierten Datagramme eingefügt werden (siehe [INTRO:2] für Details). Wenn der Router jedoch richtlinienbewusst ist, KANN er einen anderen Pfad wählen.

Einige Anwendungen in Routern KÖNNEN erfordern, dass der Benutzer eine Source-Route eingeben kann.

Router DÜRFEN NICHT Datagramme initiieren, die mehrere Source-Route-Optionen enthalten. Wie ein Router beim Weiterleiten eines Pakets mit mehreren Source-Route-Optionen vorgehen soll, wird in Abschnitt [5.2.4.1] beschrieben.

Wenn eine Source-Route-Option erstellt wird (was geschieht, wenn der Router ein Source-Route-Datagramm initiiert oder wenn eine Source-Route-Option aufgrund eines speziellen Filters eingefügt wird), MUSS sie korrekt geformt sein (siehe Fall (B) in der folgenden Diskussion), selbst wenn sie durch Umkehrung einer aufgezeichneten Route erstellt wird, die fälschlicherweise den Quellhost enthält.

DISCUSSION (Diskussion)

Angenommen, ein Source-Route-Datagramm soll von der Quelle S über die Router G1, G2, Gn zum Ziel D geleitet werden. Die Quelle S konstruiert ein Datagramm, dessen Zieladresse die IP-Adresse von G1 ist, und eine Source-Route-Option, um das Datagramm zum Rest seines Ziels zu übermitteln. Es gibt jedoch eine Mehrdeutigkeit in der Spezifikation, ob die Source-Route-Option im von S ausgehenden Datagramm (A) oder (B) sein sollte:

(A): {>>G2, G3, ... Gn, D} &lt;--- korrekt

(B): {S, >>G2, G3, ... Gn, D} &lt;---- falsch

(wobei >> den Zeiger anzeigt). Wenn (A) gesendet wird, enthält das bei D empfangene Datagramm die Option: {G1, G2, ... Gn >>}, mit S und D als IP-Quell- und Zieladresse. Wenn (B) gesendet wird, enthält das bei D empfangene Datagramm wieder S und D als dieselbe IP-Quell- und Zieladresse, aber die Option wird sein: {S, G1, ...Gn >>}; d.h., der initiierende Host wäre der erste Hop in der Route.

(d) Record Route Option (Record-Route-Option)

Router KÖNNEN die Record-Route-Option in von ihnen initiierten Datagrammen unterstützen.

(e) Timestamp Option (Zeitstempel-Option)

Router KÖNNEN die Timestamp-Option in von ihnen initiierten Datagrammen unterstützen. Die folgenden Regeln gelten:

Beim Initiieren eines Datagramms mit einer Timestamp-Option MUSS der Router einen Zeitstempel in der Option aufzeichnen, wenn
- ihr Internet-Adressfeld nicht vorspezifiziert ist, oder
- ihre erste vorspezifizierte Adresse die IP-Adresse der logischen Schnittstelle ist, die das Datagramm sendet (oder die Router-ID des Routers, wenn das Datagramm über eine nicht nummerierte Schnittstelle gesendet wird).
Wenn der Router selbst ein Datagramm mit einer Timestamp-Option empfängt, MUSS der Router die aktuelle Zeit in die Timestamp-Option einfügen (falls in der Option Platz dafür ist), bevor er die Option an die Transportschicht oder ICMP zur Verarbeitung weitergibt. Wenn kein Platz vorhanden ist, MUSS der Router den Overflow-Zähler in der Option erhöhen.
Zeitstempelwerte MÜSSEN den in [INTRO:2] definierten Regeln entsprechen.

IMPLEMENTATION (Implementierung)

Um den Nutzen von Zeitstempeln in der Timestamp-Option zu maximieren, sollten eingefügte Zeitstempel so nah wie möglich an der Zeit liegen, zu der das Paket beim Router eintrifft. Bei vom Router initiierten Datagrammen sollten eingefügte Zeitstempel so nah wie möglich an der Zeit liegen, zu der das Datagramm der Verbindungsschicht zur Übertragung übergeben wird.

Die Timestamp-Option ermöglicht die Verwendung nicht standardmäßiger Zeituhren, aber die Verwendung nicht synchronisierter Uhren schränkt den Nutzen des Zeitstempels ein. Daher wird empfohlen, dass Router das Network Time Protocol implementieren, um ihre Uhren zu synchronisieren.

4.2.2.2 Addresses in Options: RFC 791 Section 3.1 (Adressen in Optionen)

Von Routern wird verlangt, 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 solche Optionen einfügt, MUSS er die IP-Adresse der logischen Schnittstelle verwenden, die das Paket sendet. Wenn diese Regel nicht eingehalten werden kann, weil die Ausgabeschnittstelle keine IP-Adresse hat (d.h., eine nicht nummerierte Schnittstelle ist), MUSS der Router stattdessen seine Router-ID einfügen. Die Router-ID eines Routers ist eine der IP-Adressen des Routers. Die Router-ID KANN systembasis oder pro Link angegeben werden. Die als Router-ID verwendete Router-Adresse DARF sich NICHT ändern (auch nicht nach einem Neustart), es sei denn, sie wird von einem Netzwerkadministrator geändert. Relevante administrative Änderungen umfassen die Neukonfiguration des Routers so, dass die als Router-ID verwendete IP-Adresse nicht mehr eine der IP-Adressen des Routers ist. Router mit mehreren nicht nummerierten Schnittstellen KÖNNEN mehrere Router-IDs haben. Jede nicht nummerierte Schnittstelle MUSS mit einer bestimmten Router-ID verbunden sein. Diese Zuordnung DARF sich NICHT ändern (auch nicht nach einem Neustart) ohne Neukonfiguration des Routers.

DISCUSSION (Diskussion)

Diese Spezifikation erlaubt keinen Router ohne mindestens eine IP-Adresse. Wir betrachten dies nicht als ernsthafte Einschränkung, da ein Router eine IP-Adresse benötigt, um den Verwaltbarkeitsanforderungen von Kapitel [8] zu genügen, selbst wenn der Router nur an Punkt-zu-Punkt-Links angeschlossen ist.

IMPLEMENTATION (Implementierung)

Eine mögliche Methode zur Auswahl einer Router-ID, die diese Anforderung erfüllt, ist die Verwendung der numerisch kleinsten (oder größten) IP-Adresse, die dem Router zugewiesen ist (wobei die Adresse als 32-Bit-Integer betrachtet wird).

4.2.2.3 Unused IP Header Bits: RFC 791 Section 3.1 (Ungenutzte IP-Header-Bits)

Der IP-Header enthält zwei reservierte Bits: eines im Type-of-Service-Byte und eines im Flags-Feld. Router DÜRFEN NICHT eines dieser Bits auf 1 setzen in von ihnen initiierten Datagrammen. Router DÜRFEN NICHT Pakete verwerfen (ablehnen zu empfangen oder weiterzuleiten) nur weil eines oder mehrere dieser reservierten Bits einen Wert ungleich Null haben; d.h., Router DÜRFEN NICHT die Werte dieser Bits prüfen.

DISCUSSION (Diskussion)

Zukünftige Revisionen des IP-Protokolls könnten diese ungenutzten Bits verwenden. Diese Regeln sollen sicherstellen, dass diese Revisionen bereitgestellt werden können, ohne gleichzeitig alle Router im Internet aktualisieren zu müssen.

4.2.2.4 Type of Service: RFC 791 Section 3.1 (Diensttyp)

Das Type-of-Service-Byte im IP-Header ist in drei Teile unterteilt: das Precedence-Feld (die oberen 3 Bits), das üblicherweise als Type of Service oder TOS bezeichnete Feld (die nächsten 4 Bits) und das reservierte Bit (das niedrigste Bit).

Die Regeln für das reservierte Bit werden in Abschnitt [4.2.2.3] beschrieben.

Eine umfassendere Diskussion über das TOS-Feld und seine 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 NICHT implementiert werden.

4.2.2.5 Header Checksum: RFC 791 Section 3.1 (Header-Prüfsumme)

Wie in Abschnitt [5.2.2] beschrieben, MÜSSEN Router die IP-Prüfsumme aller empfangenen Pakete verifizieren und MÜSSEN Nachrichten mit ungültiger Prüfsumme verwerfen. Router DÜRFEN NICHT die Möglichkeit bieten, diese Prüfsummenverifizierung zu deaktivieren.

Router KÖNNEN inkrementelle IP-Header-Prüfsummenaktualisierung verwenden, wenn die einzige Änderung am IP-Header die Time-to-Live ist. Dies verringert die Wahrscheinlichkeit, dass der Router nicht erkannte Beschädigungen des IP-Headers hat. Für eine Diskussion über inkrementelle Aktualisierung von Prüfsummen siehe [INTERNET:6].

IMPLEMENTATION (Implementierung)

Eine umfassendere Beschreibung der IP-Prüfsumme (einschließlich zahlreicher Implementierungshinweise) findet sich in [INTERNET:6] und [INTERNET:7].

4.2.2.6 Unrecognized Header Options: RFC 791 Section 3.1 (Nicht erkannte Header-Optionen)

Router MÜSSEN IP-Optionen ignorieren, die sie nicht erkennen. Eine Folge dieser Anforderung ist, dass Router die End-of-Option-List-Option und die No-Operation-Option implementieren MÜSSEN, da beide keine explizite Länge enthalten.

DISCUSSION (Diskussion)

Alle zukünftigen IP-Optionen werden eine explizite Länge enthalten.

4.2.2.7 Fragmentation: RFC 791 Section 3.2 (Fragmentierung)

Router MÜSSEN die in [INTERNET:1] beschriebene Fragmentierung unterstützen.

Wenn ein Router ein IP-Datagramm fragmentiert, SOLLTE er die Anzahl der Fragmente minimieren. Wenn ein Router ein IP-Datagramm fragmentiert, SOLLTE er die Fragmente in Reihenfolge senden. Fragmentierungsmethoden, die ein IP-Fragment erzeugen können, das deutlich kleiner ist als ein anderes, KÖNNEN das erste IP-Fragment als das kleinere machen.

DISCUSSION (Diskussion)

Es gibt mehrere gängige Fragmentierungstechniken im Internet. Eine Technik umfasst das Aufteilen des IP-Datagramms in IP-Fragmente, wobei das erste MTU-Größe hat und die anderen ungefähr gleich groß und kleiner als die MTU sind. Dies geschieht aus zwei Gründen. Das erste IP-Fragment in der Sequenz wird die effektive MTU des aktuellen Pfads zwischen den Hosts sein, und die Größe der nachfolgenden IP-Fragmente ist so bemessen, dass die weitere Fragmentierung des IP-Datagramms minimiert wird. Eine andere Technik ist das Aufteilen des IP-Datagramms in IP-Fragmente von MTU-Größe, wobei das letzte Fragment das einzige kleinere ist, wie in [INTERNET:1] beschrieben.

Ein gängiger Trick, der von einigen TCP/IP-Implementierungen verwendet wird, besteht darin, ein IP-Datagramm, das durch einen Router geleitet werden soll, in IP-Fragmente von nicht mehr als 576 Bytes zu fragmentieren. Dies soll es den resultierenden IP-Fragmenten ermöglichen, den Rest des Pfads ohne weitere Fragmentierung zu durchlaufen. Dies belastet jedoch den Zielhost stärker, da er mehr IP-Fragmente zu einem IP-Datagramm zusammensetzen muss. Es ist auch nicht effektiv in Netzwerken, in denen sich die MTU nur einmal ändert und weit über 576 Bytes bleibt. Beispiele sind LAN-Netzwerke wie IEEE 802.5-Netzwerke mit einer MTU von 2048 oder Ethernet mit einer MTU von 1500.

Eine weitere diskutierte Fragmentierungstechnik besteht darin, das IP-Datagramm in ungefähr gleich große IP-Fragmente aufzuteilen, deren Größe kleiner oder gleich der MTU des nächsten Hop-Netzwerks ist. Dies soll die Anzahl der Fragmente minimieren, die eine weitere Fragmentierung stromabwärts des Pfads verursachen würde, und sicherstellen, dass jedes Fragment die gleiche Verzögerung hat.

Router SOLLTEN so wenig IP-Fragmente wie möglich erzeugen.

Arbeiten mit langsamen Maschinen lassen uns glauben, dass das Senden des kleinen IP-Fragments zuerst, wenn es notwendig ist, eine Nachricht zu fragmentieren, die Chance maximiert, dass ein Host mit langsamen Schnittstellen alle Fragmente empfängt.

4.2.2.8 Reassembly: RFC 791 Section 3.2 (Reassemblierung)

Wie im entsprechenden Abschnitt von [INTRO:2] spezifiziert, MÜSSEN Router die Reassemblierung von Datagrammen unterstützen, die sie an sich selbst übergeben.

4.2.2.9 Time to Live: RFC 791 Section 3.2 (Lebenszeit)

Die Behandlung der Time to Live (TTL) für vom Router initiierte oder empfangene Pakete wird durch [INTRO:2] geregelt; dieser Abschnitt ändert keine seiner Bestimmungen. Da jedoch der Rest des IP-Protokollabschnitts von [INTRO:2] neu geschrieben wird, wird auch dieser Abschnitt neu geschrieben.

Insbesondere DÜRFEN Router NICHT die TTL eines Pakets zu irgendeinem anderen Zeitpunkt als beim Weiterleiten des Pakets prüfen.

Router DÜRFEN NICHT Datagramme mit Time-to-Live (TTL)-Wert Null initiieren oder weiterleiten.

Router DÜRFEN NICHT Datagramme nur deshalb verwerfen, weil die TTL beim Empfang gleich Null oder Eins ist; wenn es an den Router adressiert ist und ansonsten gültig ist, MUSS der Router versuchen, es zu empfangen.

Für vom Router initiierte Nachrichten MUSS die IP-Schicht der Transportschicht die Möglichkeit bieten, das TTL-Feld für jedes gesendete Datagramm zu setzen. Bei Verwendung eines festen TTL-Werts MUSS dieser konfigurierbar sein. Diese Zahl SOLLTE den typischen Durchmesser des Internets überschreiten; die aktuelle Weisheit legt nahe, dass sie mehr als das Doppelte des Internet-Durchmessers betragen sollte, um Wachstum zu ermöglichen. Die derzeit empfohlenen Werte werden normalerweise im Assigned Numbers RFC veröffentlicht. Das TTL-Feld hat zwei Funktionen: die Begrenzung der Lebensdauer von TCP-Segmenten (siehe RFC 793 [TCP:1], S. 28) und die Beendigung von Internet-Routing-Schleifen. Obwohl TTL in Sekunden als Zeit gemessen wird, hat es auch einige Eigenschaften der Hop-Anzahl, da jeder Router mindestens das TTL-Feld um 1 verringern muss.

TTL-Ablauf soll dazu führen, dass ein Datagramm von einem Router verworfen wird, aber nicht vom Zielhost. Daher MÜSSEN Hosts, die als Router fungieren, indem sie Datagramme weiterleiten, die TTL-Regeln für Router befolgen.

Protokolle höherer Schichten möchten möglicherweise die TTL setzen, um eine "erweiterte Reichweite"-Suche nach einigen Internet-Ressourcen zu implementieren. Dies wird von einigen Diagnosetools verwendet und es wird erwartet, dass es nützlich ist, um mit IP-Multicast den "nächstgelegenen" Server einer bestimmten Klasse zu lokalisieren. Bestimmte Transportprotokolle möchten möglicherweise auch ihre eigene TTL-Grenze für die maximale Datagramm-Lebensdauer angeben.

Der feste Standardwert muss groß genug sein, um den Internet-"Durchmesser" zu berücksichtigen, d.h. den längstmöglichen Pfad. Ein vernünftiger Wert ist ungefähr das Doppelte des Durchmessers, um das kontinuierliche Wachstum des Internets zu ermöglichen. Zum Zeitpunkt dieses Schreibens durchlaufen Nachrichten, die die Vereinigten Staaten durchqueren, häufig 15 bis 20 Router; dies legt nahe, dass der Standard-TTL-Wert 40 überschreiten sollte, und 64 ist ein gebräuchlicher Wert.

4.2.2.10 Multi-subnet Broadcasts: RFC 922 (Multi-Subnetz-Broadcasts)

All-subnets Broadcasts (in [INTERNET:3] als Multi-Subnet-Broadcasts bezeichnet) sind veraltet. Siehe Abschnitt [5.3.5.3].

4.2.2.11 Addressing: RFC 791 Section 3.2 (Adressierung)

Wie in 2.2.5.1 beschrieben, gibt es jetzt fünf Klassen von IP-Adressen: Klasse A bis Klasse E. Klasse-D-Adressen werden für IP-Multicast verwendet [INTERNET:4], während Klasse-E-Adressen für experimentelle Zwecke reserviert sind. Die Unterscheidung zwischen Klasse A-, B- und C-Adressen ist nicht mehr wichtig; sie werden als generische Unicast-Netzwerk-Präfixe verwendet, die nur hinsichtlich ihrer Klasse historische Bedeutung haben.

IP-Multicast-Adressen sind 28-Bit-logische Adressen, die eine Gruppe von Hosts repräsentieren und entweder permanent oder temporär sein können. Permanente Multicast-Adressen werden von der Internet Assigned Number Authority [INTRO:7] zugewiesen, während temporäre Adressen dynamisch temporären Gruppen zugewiesen werden können. Die Gruppenmitgliedschaft wird mit IGMP [INTERNET:4] dynamisch bestimmt.

Wir fassen nun die wichtigen Sonderfälle generischer Unicast-IP-Adressen zusammen, wobei wir die folgende IP-Adressnotation verwenden:

{ &lt;Network-prefix>, &lt;Host-number> }

und die Notation -1 zur Darstellung eines Feldes, das alle 1-Bits enthält, und 0 zur Darstellung eines Feldes, das alle 0-Bits enthält.

(a) { 0, 0 }

Dieser Host in diesem Netzwerk. Router DÜRFEN dies NICHT als Quelladresse verwenden, außer ein Router KANN dies während der Initialisierung als Quelladresse verwenden (z.B. wenn der Router BOOTP verwendet, um seine Konfigurationsinformationen zu laden).

Für lokal zugestellte (siehe Abschnitt [5.2.3]) eingehende Datagramme mit einer Quelladresse von { 0, 0 } MÜSSEN sie akzeptiert werden, wenn der Router das relevante Protokoll implementiert und dieses Protokoll klar die zu ergreifenden Maßnahmen definiert. Andernfalls MUSS der Router jedes lokal zugestellte Datagramm mit einer Quelladresse von { 0, 0 } still verwerfen.

DISCUSSION (Diskussion)

Einige Protokolle definieren spezifische Maßnahmen, die beim Empfang eines Datagramms mit einer Quelladresse von { 0, 0 } zu ergreifen sind. Zwei Beispiele sind BOOTP und ICMP Mask Request. Der normale Betrieb dieser Protokolle hängt normalerweise von der Fähigkeit ab, Datagramme mit einer Quelladresse von { 0, 0 } zu empfangen. Für die meisten Protokolle ist es jedoch am besten, Datagramme mit einer Quelladresse von { 0, 0 } zu ignorieren, da sie möglicherweise von falsch konfigurierten Hosts oder Routern erzeugt werden. Daher MUSS der Router ein gegebenes Datagramm mit einer { 0, 0 } Quelladresse akzeptieren, wenn er weiß, wie er damit umgehen soll. Andernfalls MUSS der Router es verwerfen.

Siehe auch Abschnitt [4.2.3.1] für nicht standardmäßige Verwendungen von { 0, 0 }.

(b) { 0, <Host-number> }

Angegebener Host in diesem Netzwerk. Router DÜRFEN dies NICHT senden, außer ein Router KANN dies während der Initialisierung als Quelladresse verwenden, durch die er seine eigene IP-Adresse erfährt.

(c) { -1, -1 }

Eingeschränkter Broadcast. Es DARF NICHT als Quelladresse verwendet werden.

Ein Datagramm mit dieser Zieladresse wird von jedem Host und Router im angeschlossenen physischen Netzwerk empfangen, aber nicht über dieses Netzwerk hinaus weitergeleitet.

(d) { <Network-prefix>, -1 }

Directed Broadcast - Broadcast an das angegebene Netzwerk-Präfix gerichtet. Es DARF NICHT als Quelladresse verwendet werden. Router KÖNNEN Netzwerk-Directed-Broadcast-Pakete initiieren. Router MÜSSEN Netzwerk-Directed-Broadcast-Pakete empfangen; Router KÖNNEN jedoch eine Konfigurationsoption haben, um den Empfang dieser Pakete zu verhindern. Eine solche Option MUSS standardmäßig den Empfang erlauben.

(e) { 127, <any> }

Interne Host-Loopback-Adresse. Adressen dieser Form DÜRFEN NICHT außerhalb eines Hosts erscheinen.

Das <Network-prefix> wird administrativ zugewiesen, sodass sein Wert innerhalb der Routing-Domäne, mit der das Gerät verbunden ist, eindeutig ist.

IP-Adressen erlauben nicht, dass die <Host-number> oder <Network-prefix> Felder die Werte 0 oder -1 haben, außer in den oben aufgeführten Sonderfällen. Dies bedeutet, dass jedes dieser Felder mindestens zwei Bits lang ist.

DISCUSSION (Diskussion)

Frühere Versionen dieses Dokuments haben auch angegeben, dass die Subnetznummer weder 0 noch -1 sein darf und mindestens zwei Bits lang sein muss. In einer CIDR-Welt ist die Subnetznummer offensichtlich eine Erweiterung des Netzwerk-Präfixes und kann ohne den Rest des Präfixes nicht interpretiert werden. Daher ist diese Subnetznummernbeschränkung angesichts von CIDR bedeutungslos und kann sicher ignoriert werden.

Für weitere Diskussionen über Broadcast-Adressen siehe Abschnitt [4.2.3.1].

Wenn ein Router ein Datagramm initiiert, MUSS die IP-Quelladresse eine seiner eigenen IP-Adressen sein (aber keine Broadcast- oder Multicast-Adresse). Die einzige Ausnahme ist während der Initialisierung.

In den meisten Fällen wird die Verarbeitung von Datagrammen, die an ein Broadcast- oder Multicast-Ziel gerichtet sind, so behandelt, als wären sie an eine der IP-Adressen des Routers gerichtet; das heißt:

Router MÜSSEN jedes Paket mit einer Broadcast-Zieladresse normal empfangen und verarbeiten.
Router MÜSSEN jedes Paket, das an eine Multicast-Zieladresse gesendet wird, normal empfangen und verarbeiten, für die der Router den Empfang angefordert hat.

Der Begriff specific-destination address bezeichnet das lokale IP-Adressäquivalent eines Hosts. Die spezifische Zieladresse ist definiert als die Zieladresse im IP-Header, es sei denn, der Header enthält eine Broadcast- oder Multicast-Adresse, in diesem Fall ist das spezifische Ziel die IP-Adresse, die der physischen Schnittstelle zugewiesen ist, an der das Datagramm ankam.

Router MÜSSEN jedes empfangene Datagramm still verwerfen, das eine IP-Quelladresse enthält, die nach den Regeln dieses Abschnitts ungültig ist. Diese Validierung KANN von der IP-Schicht oder (falls angemessen) von jedem Protokoll in der Transportschicht durchgeführt werden. Wie bei allen vom Router verworfenen Datagrammen SOLLTE das Verwerfen von Datagrammen gezählt werden.

DISCUSSION (Diskussion)

Fehlgeleitete Datagramme können durch Link-Layer-Broadcasts von Unicast-Datagrammen oder durch einen verwirrten oder falsch konfigurierten anderen Router oder Host verursacht werden.

4.2.3 Specific Issues (Spezifische Fragen)

4.2.3.1 IP Broadcast Addresses (IP-Broadcast-Adressen)

Aus historischen Gründen gibt es viele IP-Adressen (einige Standard und einige nicht-Standard), die verwendet werden, um anzuzeigen, dass ein IP-Paket ein IP-Broadcast ist. Router

(1) MÜSSEN Pakete, die an 255.255.255.255 oder { <Network-prefix>, -1 } gerichtet sind, als IP-Broadcast behandeln.

(2) SOLLTEN beim Empfang still verwerfen (d.h. nicht einmal an Anwendungen im Router weitergeben) alle Pakete, die an 0.0.0.0 oder { <Network-prefix>, 0 } gerichtet sind. Wenn diese Pakete nicht still verworfen werden, MÜSSEN sie als IP-Broadcast behandelt werden (siehe Abschnitt [5.3.5]). Es KANN eine Konfigurationsoption geben, um den Empfang dieser Pakete zu ermöglichen. Diese Option SOLLTE standardmäßig so eingestellt sein, dass sie diese verwerfen.

(3) SOLLTEN (standardmäßig) die eingeschränkte Broadcast-Adresse (255.255.255.255) beim Initiieren eines IP-Broadcasts an ein verbundenes (Sub-)Netzwerk verwenden (außer beim Senden einer ICMP-Adress-Masken-Antwort, wie in Abschnitt [4.3.3.9] beschrieben). Router MÜSSEN eingeschränkte Broadcasts empfangen.

(4) SOLLTEN NICHT Datagramme initiieren, die an 0.0.0.0 oder { <Network-prefix>, 0 } gerichtet sind. Es KANN eine Konfigurationsoption geben, um die Erzeugung dieser Datagramme zu ermöglichen (anstatt die zugehörigen 1s-Format-Broadcasts zu verwenden). Diese Option SOLLTE standardmäßig so eingestellt sein, dass sie diese nicht erzeugt.

DISCUSSION (Diskussion)

Im zweiten Aufzählungspunkt kann der Router offensichtlich keine Adresse der Form { <Network-prefix>, 0 } erkennen, wenn der Router keine Schnittstelle zu diesem Netzwerk-Präfix hat. In diesem Fall gelten die Regeln des zweiten Aufzählungspunkts nicht, weil aus Sicht des Routers das Paket kein IP-Broadcast-Paket ist.

4.2.3.2 IP Multicasting (IP-Multicasting)

IP-Router SOLLTEN die in [INTRO:2] angegebenen Host-Anforderungen bezüglich IP-Multicast erfüllen. IP-Router SOLLTEN lokales IP-Multicast auf allen angeschlossenen Netzwerken unterstützen. Wenn eine Zuordnung von der IP-Multicast-Adresse zur Link-Layer-Adresse angegeben ist (siehe die verschiedenen IP-over-xxx-Spezifikationen), SOLLTE sie diese Zuordnung verwenden und KANN so konfiguriert werden, dass stattdessen ein Link-Layer-Broadcast verwendet wird. Auf Punkt-zu-Punkt-Links und allen anderen Schnittstellen ist Multicast als Link-Layer-Broadcast verkapselt. Die Unterstützung für lokales IP-Multicast umfasst das Initiieren von Multicast-Datagrammen, das Beitreten zu Multicast-Gruppen und das Empfangen von Multicast-Datagrammen sowie das Verlassen von Multicast-Gruppen. Dies bedeutet Unterstützung für alle [INTERNET:4], einschließlich IGMP (siehe Abschnitt [4.4]).

DISCUSSION (Diskussion)

Obwohl der Titel von [INTERNET:4] Host Extensions for IP Multicasting lautet, gilt er für alle IP-Systeme, einschließlich Hosts und Router. Insbesondere ist es richtig, dass Router den Host-Teil von IGMP ausführen, da sie Multicast-Gruppen beitreten können, und sie melden ihre Gruppenmitgliedschaft an alle Multicast-Router, die möglicherweise auf ihren angeschlossenen Netzwerken vorhanden sind (unabhängig davon, ob sie selbst Multicast-Router sind).

Einige Router-Protokolle können speziell Unterstützung für IP-Multicast erfordern (z.B. OSPF [ROUTE:1]) oder können es empfehlen (z.B. ICMP Router Discovery [INTERNET:13]).

4.2.3.3 Path MTU Discovery (Pfad-MTU-Entdeckung)

Um Fragmentierung zu eliminieren oder zu minimieren, ist es wünschenswert zu wissen, was die Pfad-MTU von der Quelle zum Ziel ist. Die Pfad-MTU ist das Minimum der MTU jedes Hops im Pfad. [INTERNET:14] beschreibt eine Technik zur dynamischen Entdeckung der maximalen Übertragungseinheit (MTU) eines beliebigen Internet-Pfads. Bei Pfaden, die Router durchlaufen, die [INTERNET:14] nicht unterstützen, kann diese Technik möglicherweise nicht die korrekte Pfad-MTU entdecken, aber sie wird immer eine Pfad-MTU wählen, die genauso genau ist wie die von alten Techniken oder aktuellen Praktiken gewählte Pfad-MTU, in vielen Fällen genauer.

Wenn ein Router IP-Datagramme initiiert, SOLLTE 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 Pfad-MTU-Informationen bereitstellt, wird das in [INTERNET:14] beschriebene Schema immer noch verwendet, aber die Pfad-MTU-Informationen des Routing-Protokolls SOLLTEN als anfängliche Vermutung der Pfad-MTU und als Obergrenze für die Pfad-MTU verwendet werden.

4.2.3.4 Subnetting (Subnetting)

In einigen Fällen kann es wünschenswert sein, die Subnetze eines bestimmten Netzwerks nur über Pfade zu verbinden, die nicht Teil des subnetting Netzwerks sind. Dies wird als Unterstützung für diskontinuierliche Subnetze bezeichnet.

Router MÜSSEN diskontinuierliche Subnetze unterstützen.

IMPLEMENTATION (Implementierung)

In klassischen IP-Netzwerken ist dies schwer zu implementieren; in CIDR-Netzwerken ist dies ein natürliches Nebenprodukt. Daher SOLLTEN Router KEINE Annahmen über die Subnetz-Architektur treffen, sondern SOLLTEN jede Route als generisches Netzwerk-Präfix behandeln.

DISCUSSION (Diskussion)

Das Internet wächst seit kurzem mit erstaunlicher Geschwindigkeit. Dies hat ernsthafte Belastungen für die IP-Adressierungstechniken verursacht. Ein Hauptfaktor für diese Belastung sind die starren IP-Adress-Klassengrenzen. Dies erschwert es, die Größe des Netzwerk-Präfixes für ihre Netzwerke effizient anzupassen und mehrere Netzwerk-Präfixe in einer einzelnen Routing-Ankündigung zusammenzufassen. Durch die Beseitigung der starren Klassengrenzen von IP-Adressen und die Behandlung jeder Route als generisches Netzwerk-Präfix können diese Belastungen erheblich reduziert werden.

Die Technik, die dies derzeit tut, ist Classless Inter Domain Routing (CIDR) [INTERNET:15].

Aus ähnlichen Gründen kann der einem gegebenen Netzwerk-Präfix zugeordnete Adressblock in Unterblöcke unterschiedlicher Größe unterteilt werden, sodass die mit den Unterblöcken verbundenen Netzwerk-Präfixe unterschiedliche Längen haben. Zum Beispiel könnte innerhalb eines Blocks, in dem das Netzwerk-Präfix 8 Bits lang ist, ein Unterblock ein 16-Bit-Netzwerk-Präfix haben, ein anderer könnte ein 18-Bit-Netzwerk-Präfix haben und ein dritter ein 14-Bit-Netzwerk-Präfix.

Router MÜSSEN Netzwerk-Präfixe variabler Länge in ihrer Schnittstellenkonfiguration und Routing-Datenbank unterstützen.

4.3 Internet Control Message Protocol - ICMP (Internet Control Message Protocol)

4.3.1 Introduction (Einführung)

ICMP ist ein Hilfsprotokoll, das Routing-, Diagnose- und Fehlerfunktionen für IP bereitstellt. Es wird in [INTERNET:8] beschrieben. Router MÜSSEN ICMP unterstützen.

ICMP-Nachrichten fallen in zwei Kategorien, die in den folgenden Abschnitten diskutiert werden:

ICMP-Fehlermeldungen:

Destination Unreachable (Ziel nicht erreichbar) Abschnitt 4.3.3.1
Redirect (Umleitung) Abschnitt 4.3.3.2
Source Quench (Quelle gedrosselt) Abschnitt 4.3.3.3
Time Exceeded (Zeit überschritten) Abschnitt 4.3.3.4
Parameter Problem (Parameterproblem) Abschnitt 4.3.3.5

ICMP-Abfragemeldungen:

Echo (Echo) Abschnitt 4.3.3.6
Information (Information) Abschnitt 4.3.3.7
Timestamp (Zeitstempel) Abschnitt 4.3.3.8
Address Mask (Adressmaske) Abschnitt 4.3.3.9
Router Discovery (Router-Entdeckung) Abschnitt 4.3.3.10

Allgemeine ICMP-Anforderungen und Diskussionen finden Sie im nächsten Abschnitt.

4.3.2 General Issues (Allgemeine Fragen)

4.3.2.1 Unknown Message Types (Unbekannte Nachrichtentypen)

Wenn eine ICMP-Nachricht eines unbekannten Typs empfangen wird, MUSS sie an die ICMP-Benutzerschnittstelle übergeben werden (wenn der Router eine hat) oder still verworfen werden (wenn der Router keine hat).

4.3.2.2 ICMP Message TTL (ICMP-Nachrichten-TTL)

Wenn eine ICMP-Nachricht initiiert wird, MUSS der Router die TTL initialisieren. Die TTL einer ICMP-Antwort DARF NICHT aus dem Paket übernommen werden, das die Antwort ausgelöst hat.

4.3.2.3 Original Message Header (Originalnachrichten-Header)

Historisch gesehen enthält jede ICMP-Fehlermeldung den Internet-Header und mindestens die ersten 8 Datenworte des Datagramms, das den Fehler ausgelöst hat. Aufgrund der Verwendung von IP-in-IP-Tunneling und anderen Techniken reicht dies nicht mehr aus. Daher SOLLTEN ICMP-Datagramme so viel des ursprünglichen Datagramms wie möglich enthalten, ohne dass das ICMP-Datagramm länger als 576 Bytes wird. Der zurückgegebene IP-Header (und Benutzerdaten) MUSS mit dem empfangenen identisch sein, außer dass der Router nicht verpflichtet ist, Änderungen am IP-Header rückgängig zu machen, die normalerweise beim Weiterleiten vor der Fehlererkennung durchgeführt werden (z.B. Dekrementieren der TTL oder Aktualisieren von Optionen). Beachten Sie, dass die Anforderungen von Abschnitt [4.3.3.5] diese Anforderung in einigen Fällen überschreiben (d.h. für Parameter-Problem-Nachrichten muss der Router die Änderung rückgängig machen, wenn das Problem in einem modifizierten Feld liegt). Siehe Abschnitt [4.3.3.5]).

4.3.2.4 ICMP Message Source Address (ICMP-Nachrichten-Quelladresse)

Sofern in diesem Dokument nicht anders angegeben, MUSS die IP-Quelladresse in einer vom Router initiierten ICMP-Nachricht eine der IP-Adressen sein, die mit der physischen Schnittstelle verbunden sind, die die ICMP-Nachricht überträgt. Wenn die Schnittstelle keine IP-Adresse hat, die ihr zugeordnet ist, wird stattdessen die Router-ID des Routers verwendet (siehe Abschnitt [5.2.5]).

4.3.2.5 TOS and Precedence (TOS und Vorrang)

ICMP-Fehlermeldungen SOLLTEN ihre TOS-Bits auf denselben Wert setzen wie die TOS-Bits im Paket, das das Senden der ICMP-Fehlermeldung veranlasst hat, es sei denn, das Setzen auf diesen Wert würde dazu führen, dass die ICMP-Fehlermeldung sofort verworfen wird, weil sie nicht zu ihrem Ziel geroutet werden kann. Andernfalls MÜSSEN ICMP-Fehlermeldungen mit normalem (d.h. Null) TOS gesendet werden. ICMP-Antwortnachrichten SOLLTEN ihre TOS-Bits auf denselben Wert setzen wie die TOS-Bits in der ICMP-Anfrage, die die Antwort veranlasst hat.

ICMP Source Quench Fehlermeldungen (falls gesendet) MÜSSEN ihr IP-Precedence-Feld auf denselben Wert setzen wie das IP-Precedence-Feld im Paket, das das Senden der ICMP Source Quench-Nachricht veranlasst hat. Alle anderen ICMP-Fehlermeldungen (Destination Unreachable, Redirect, Time Exceeded und Parameter Problem) SOLLTEN ihren Vorrangswert auf 6 (INTERNETWORK CONTROL) oder 7 (NETWORK CONTROL) setzen. Der IP-Vorrangswert dieser Fehlermeldungen KANN einstellbar sein.

ICMP-Antwortnachrichten MÜSSEN ihr IP-Precedence-Feld auf denselben Wert setzen wie das IP-Precedence-Feld in der ICMP-Anfrage, die die Antwort veranlasst hat.

4.3.2.6 Source Route (Quellroute)

Wenn das Paket, das das Senden einer ICMP-Fehlermeldung veranlasst hat, eine Source-Route-Option enthält, SOLLTE die ICMP-Fehlermeldung auch eine Source-Route-Option desselben Typs (strikt oder lose) enthalten, die durch Umkehrung des aufgezeichneten Teils der Route vor dem Zeiger in der Source-Route-Option des ursprünglichen Pakets erstellt wurde, es sei denn, die ICMP-Fehlermeldung ist eine ICMP-Parameter-Problem-Nachricht, die sich über die Source-Route-Option im ursprünglichen Paket beschwert, oder es sei denn, der Router von einer Richtlinie weiß, die die Zustellung der ICMP-Fehlermeldung verhindern würde.

DISCUSSION (Diskussion)

In Umgebungen, die die U.S. Department of Defense Security Option (definiert in [INTERNET:5]) verwenden, müssen ICMP-Nachrichten möglicherweise eine Sicherheitsoption enthalten. Details zu diesem Thema sollten von der Defense Communications Agency erhältlich sein.

4.3.2.7 When Not to Send ICMP Errors (Wann ICMP-Fehler nicht gesendet werden sollen)

ICMP-Fehlermeldungen DÜRFEN NICHT als Folge des Empfangs von Folgendem gesendet werden:

eine ICMP-Fehlermeldung, oder
ein Paket, das die in Abschnitt [5.2.2] beschriebenen IP-Header-Validierungstests nicht bestanden hat (es sei denn, dieser Abschnitt erlaubt ausdrücklich das Senden einer ICMP-Fehlermeldung), oder
ein Paket, das an eine IP-Broadcast- oder IP-Multicast-Adresse gerichtet ist, oder
ein Paket, das als Link-Layer-Broadcast oder Multicast gesendet wurde, oder
ein Paket, dessen Quelladresse ein Netzwerk-Präfix von Null hat oder eine ungültige Quelladresse ist (wie in Abschnitt [5.3.7] definiert), oder
irgendein Fragment eines Datagramms außer dem ersten Fragment (d.h. ein Paket mit einem Fragment-Offset ungleich Null im IP-Header).

Darüber hinaus DÜRFEN ICMP-Fehlermeldungen in allen Fällen, in denen dieses Memo angibt, dass ein Paket still verworfen werden soll, NICHT gesendet werden.

Hinweis: Diese Einschränkungen haben Vorrang vor jeder Anforderung zum Senden von ICMP-Fehlermeldungen an anderer Stelle in diesem Dokument.

DISCUSSION (Diskussion)

Diese Regeln sollen Broadcast-Stürme verhindern, die auftreten, weil Router oder Hosts auf Broadcast-Pakete mit ICMP-Fehlermeldungen antworten. Zum Beispiel könnte ein Broadcast-UDP-Paket an einen nicht existierenden Port eine Flut von ICMP-Destination-Unreachable-Datagrammen von allen Geräten auslösen, die diesen Zielport nicht haben. Auf einem großen Ethernet könnten die resultierenden Kollisionen das Netzwerk für eine Sekunde oder länger unbrauchbar machen.

Jedes auf einem angeschlossenen Netzwerk gesendete Broadcast-Datagramm sollte eine gültige IP-Broadcast-Adresse als IP-Ziel haben (siehe Abschnitt [5.3.4] und [INTRO:2]). Einige Geräte verstoßen jedoch gegen diese Regel. Daher muss der Router, um Broadcast-Pakete zuverlässig zu erkennen, auf Link-Layer-Broadcasts sowie auf IP-Layer-Adressen prüfen.

IMPLEMENTATION+ (Implementierung)

Dies erfordert, dass die Link-Schicht die IP-Schicht benachrichtigt, wenn ein Link-Layer-Broadcast-Paket empfangen wird; siehe Abschnitt [3.1].

4.3.2.8 Rate Limiting (Ratenbegrenzung)

Router, die ICMP Source Quench-Nachrichten senden, MÜSSEN in der Lage sein, die Rate der Nachrichtenerzeugung zu begrenzen. Router SOLLTEN auch in der Lage sein, die Rate zu begrenzen, mit der sie andere Arten von ICMP-Fehlermeldungen senden (Destination Unreachable, Redirect, Time Exceeded, Parameter Problem). Die Ratenbegrenzungsparameter SOLLTEN als Teil der Router-Konfiguration einstellbar sein. Wie die Begrenzung angewendet wird (z.B. pro Router oder pro Schnittstelle), bleibt dem Implementierer überlassen.

DISCUSSION (Diskussion)

Zwei Probleme beim Senden von ICMP-Fehlermeldungen durch Router sind: (1) der Verbrauch von Bandbreite auf dem Rückweg, und (2) die Nutzung von Router-Ressourcen (z.B. Speicher, CPU-Zeit)

Um bei diesen Problemen zu helfen, können Router die Häufigkeit begrenzen, mit der sie ICMP-Fehlermeldungen erzeugen. Aus ähnlichen Gründen können Router die Häufigkeit begrenzen, mit der bestimmte andere Arten von Nachrichten erzeugt werden (z.B. ICMP Echo Replies).

IMPLEMENTATION (Implementierung)

Verschiedene Mechanismen wurden verwendet oder vorgeschlagen, um die Rate des Sendens von ICMP-Nachrichten zu begrenzen:

(1) Zählbasiert - zum Beispiel das Senden einer ICMP-Fehlermeldung für jedes N-te verworfene Paket oder für jeden gegebenen Quellhost. Dieser Mechanismus kann für ICMP Source Quench geeignet sein (falls verwendet), ist aber möglicherweise nicht für andere Arten von ICMP-Nachrichten geeignet.

(2) Timerbasiert - zum Beispiel das Senden von höchstens einer ICMP-Fehlermeldung an einen gegebenen Quellhost oder insgesamt alle T Millisekunden.

(3) Bandbreitenbasiert - zum Beispiel das Begrenzen der Rate des Sendens von ICMP-Nachrichten durch eine bestimmte Schnittstelle auf einen bestimmten Bruchteil der Bandbreite des angeschlossenen Netzwerks.

4.3.3 Specific Issues (Spezifische Fragen)

4.3.3.1 Destination Unreachable (Ziel nicht erreichbar)

Wenn ein Router ein Paket nicht weiterleiten kann, weil es keine Route zum Ziel im Paket gibt (einschließlich keiner Standardroute), MUSS der Router eine Destination Unreachable, Code 0 (Network Unreachable) ICMP-Nachricht erzeugen. Wenn der Router tatsächlich eine Route zum Zielnetzwerk hat, das im Paket angegeben ist, aber die Route, die der Router hat, einen TOS angibt, der weder der Standard-TOS (0000) noch der TOS des Pakets ist, das der Router zu routen versucht, MUSS der Router eine Destination Unreachable, Code 11 (Network Unreachable for TOS) ICMP-Nachricht erzeugen.

Wenn ein Paket zu einem Host weitergeleitet werden soll, der direkt an ein Netzwerk angeschlossen ist, das direkt am Router angeschlossen ist (d.h., der Router ist der letzte Hop-Router) und der Router festgestellt hat, dass es keinen Pfad zum Zielhost gibt, MUSS der Router eine Destination Unreachable, Code 1 (Host Unreachable) ICMP-Nachricht erzeugen. Wenn ein Paket zu einem Host weitergeleitet werden soll, der direkt an ein Netzwerk angeschlossen ist, das direkt am Router angeschlossen ist, und der Router das Paket nicht weiterleiten kann, weil keine Route zum Ziel einen TOS hat, der gleich dem im Paket angeforderten TOS oder dem Standard-TOS (0000) ist, MUSS der Router eine Destination Unreachable, Code 12 (Host Unreachable for TOS) ICMP-Nachricht erzeugen.

DISCUSSION (Diskussion)

Die Absicht ist, dass der Router "generische" Host/Network Unreachable erzeugt, wenn der Router überhaupt keinen Pfad zum Ziel hat (einschließlich einer Standardroute). Wenn der Router einen oder mehrere Pfade zum Ziel hat, aber keiner dieser Pfade einen akzeptablen TOS hat, erzeugt der Router "für TOS unreachable"-Nachrichten.

4.3.3.2 Redirect (Umleitung)

ICMP Redirect-Nachrichten werden erzeugt, um lokale Hosts darüber zu informieren, dass sie einen anderen nächsten Hop-Router für bestimmten Verkehr verwenden sollten.

Im Gegensatz zu [INTRO:2] KANN ein Router ICMP Redirects beim Auswählen eines Pfads für vom Router initiierte Pakete ignorieren, wenn der Router ein Routing-Protokoll ausführt oder wenn Weiterleitung auf dem Router und auf der Schnittstelle, die das Paket sendet, aktiviert ist.

4.3.3.3 Source Quench (Quelldrosselung)

Router SOLLTEN KEINE ICMP Source Quench-Nachrichten initiieren. Wie in Abschnitt [4.3.2] spezifiziert, MÜSSEN Router, die Source Quench-Nachrichten initiieren, in der Lage sein, deren Erzeugungsrate zu begrenzen.

DISCUSSION (Diskussion)

Forschungen scheinen darauf hinzudeuten, dass Source Quench Netzwerkbandbreite verbraucht, aber ein unwirksames (und unfaires) Gegenmittel gegen Stau ist. Siehe zum Beispiel [INTERNET:9] und [INTERNET:10]. Abschnitt [5.3.6] diskutiert das aktuelle Denken darüber, wie Router mit Überlastung und Netzwerkstau umgehen sollten.

Router KÖNNEN alle empfangenen ICMP Source Quench-Nachrichten ignorieren.

DISCUSSION (Diskussion)

Router selbst können Source Quench aufgrund des Initiierens von Paketen empfangen, die an einen anderen Router oder Host gesendet werden. Solche Datagramme können zum Beispiel EGP-Updates an einen anderen Router oder einen Telnet-Stream an einen Host sein. Ein Mechanismus wurde vorgeschlagen ([INTERNET:11], [INTERNET:12]), um die IP-Schicht direkt auf Source Quench reagieren zu lassen, indem die Rate des Sendens von Paketen kontrolliert wird, aber dieser Vorschlag ist derzeit experimentell und wird derzeit nicht empfohlen.

4.3.3.4 Time Exceeded (Zeit überschritten)

Wenn ein Router ein Paket weiterleitet und das TTL-Feld des Pakets auf Null verringert wird, gelten die Anforderungen von Abschnitt [5.2.3.8].

Wenn ein Router ein an den Router gerichtetes Paket reassembliert, fungiert es als Internet-Host. Daher gelten die Reassemblierungsanforderungen von [INTRO:2].

Wenn ein Router eine Time Exceeded-Nachricht empfängt (d.h. an den Router gerichtet), MUSS er [INTRO:2] entsprechen.

4.3.3.5 Parameter Problem (Parameterproblem)

Für jeden Fehler, der nicht speziell von anderen ICMP-Nachrichten abgedeckt wird, MUSS der Router eine Parameter Problem-Nachricht erzeugen. Das IP-Header-Feld oder die IP-Option, die das Byte enthält, das durch das Pointer-Feld angegeben wird, MUSS unverändert im IP-Header bleiben, der in dieser ICMP-Nachricht zurückgegeben wird. Abschnitt [4.3.2] definiert Ausnahmen von dieser Anforderung.

Eine neue Variante der Parameter Problem-Nachricht ist in [INTRO:2] definiert:

Code 1 = Erforderliche Option fehlt.

DISCUSSION (Diskussion)

Diese Variante wird derzeit in der militärischen Gemeinschaft für fehlende Sicherheitsoptionen verwendet.

4.3.3.6 Echo Request/Reply (Echo-Anfrage/Antwort)

Router MÜSSEN die ICMP Echo-Serverfunktion implementieren, die Echo Requests empfängt, die an den Router gesendet werden, und entsprechende Echo Replies sendet. Router MÜSSEN bereit sein, ICMP Echo Request-Datagramme zu empfangen, zu reassemblieren und zu beantworten, die mindestens die Größe von 576 und das Maximum der MTUs aller angeschlossenen Netzwerke haben.

Die Echo-Serverfunktion KANN wählen, auf ICMP-Echo-Anfragen, die an eine IP-Broadcast- oder IP-Multicast-Adresse gerichtet sind, nicht zu antworten.

Router SOLLTEN eine Konfigurationsoption haben, die, wenn aktiviert, dazu führt, dass der Router alle ICMP-Echo-Anfragen still ignoriert; falls bereitgestellt, MUSS diese Option standardmäßig so eingestellt sein, dass Antworten erlaubt sind.

DISCUSSION (Diskussion)

Die neutrale Regel über das Reagieren auf Broadcast- und Multicast-Echo-Anfragen stammt aus dem Abschnitt "Echo Request/Reply" von [INTRO:2].

Wie in Abschnitt [10.3.3] beschrieben, MÜSSEN Router auch eine Benutzer-/Anwendungsschichtschnittstelle zum Senden von Echo Requests und Empfangen von Echo Replies für Diagnosezwecke implementieren. Alle ICMP Echo Reply-Nachrichten MÜSSEN an diese Schnittstelle übergeben werden.

Die IP-Quelladresse in einer ICMP Echo Reply MUSS dieselbe sein wie die specific-destination address der entsprechenden ICMP Echo Request-Nachricht.

Die in einer ICMP Echo Request empfangenen Daten MÜSSEN vollständig in der erzeugten Echo Reply enthalten sein.

Wenn eine Record Route- und/oder Timestamp-Option in einer ICMP Echo Request empfangen wird, SOLLTE diese Option (diese Optionen) aktualisiert werden, um den aktuellen Router einzuschließen, und im IP-Header der Echo Reply-Nachricht enthalten sein, nicht abgeschnitten. Daher wird die aufgezeichnete Route für den gesamten Hin- und Rückweg verwendet.

Wenn eine Source Route-Option in einer ICMP Echo Request empfangen wird, MUSS die Rückroute umgekehrt und als Source Route-Option der Echo Reply-Nachricht verwendet werden, es sei denn, der Router weiß von einer Richtlinie, die die Nachrichtenzustellung verhindern würde.

4.3.3.7 Information Request/Reply (Informationsanfrage/Antwort)

Router SOLLTEN diese Nachrichten NICHT initiieren oder beantworten.

DISCUSSION (Diskussion)

Information Request/Reply-Paare waren dazu bestimmt, Selbstkonfigurationssysteme (wie plattenlose Workstations) zu unterstützen, damit diese beim Booten ihr IP-Netzwerk-Präfix entdecken können. Diese Nachrichten sind jedoch jetzt veraltet. Die RARP- und BOOTP-Protokolle bieten bessere Mechanismen für Hosts, um ihre eigene IP-Adresse zu entdecken.

4.3.3.8 Timestamp and Timestamp Reply (Zeitstempel und Zeitstempel-Antwort)

Router KÖNNEN Timestamp und Timestamp Reply implementieren. Wenn sie implementiert sind, dann:

Die ICMP Timestamp-Serverfunktion MUSS für jede empfangene Timestamp-Nachricht eine Timestamp Reply zurückgeben. Sie SOLLTE so konzipiert sein, dass die Varianz der Verzögerung minimiert wird.
ICMP Timestamp Request-Nachrichten, die an eine IP-Broadcast- oder IP-Multicast-Adresse gerichtet sind, KÖNNEN still verworfen werden.
Die IP-Quelladresse in einer ICMP Timestamp Reply MUSS dieselbe sein wie die specific-destination address der entsprechenden Timestamp Request-Nachricht.
Wenn eine Source Route-Option in einer ICMP Timestamp Request empfangen wird, MUSS die Rückroute umgekehrt und als Source Route-Option der Timestamp Reply-Nachricht verwendet werden, es sei denn, der Router weiß von einer Richtlinie, die die Nachrichtenzustellung verhindern würde.
Wenn eine Record Route- und/oder Timestamp-Option in einem Timestamp Request empfangen wird, SOLLTE diese (diese) Option(en) aktualisiert werden, um den aktuellen Router einzuschließen, und im IP-Header der Timestamp Reply-Nachricht enthalten sein.
Wenn der Router eine Anwendungsschichtschnittstelle zum Senden von Timestamp Request-Nachrichten bereitstellt, MÜSSEN eingehende Timestamp Reply-Nachrichten zur ICMP-Benutzerschnittstelle nach oben übergeben werden.

Die bevorzugte Form (Standardwert) von Zeitstempelwerten ist Millisekunden seit Mitternacht, Weltzeit. Es kann jedoch schwierig sein, diesen Wert mit Millisekundenauflösung bereitzustellen. Zum Beispiel verwenden viele Systeme eine Uhr, die nur mit der Netzfrequenz aktualisiert wird, 50 oder 60 Mal pro Sekunde. Daher erlaubt der Standardwert etwas Spielraum:

(a) Der Standardwert MUSS mindestens 16 Mal pro Sekunde aktualisiert werden (d.h., höchstens die sechs niedrigen Bits des Werts können undefiniert sein).

(b) Die Genauigkeit des Standardwerts MUSS der Genauigkeit der vom Betreiber eingestellten CPU-Uhr nahe kommen, d.h. innerhalb weniger Minuten korrekt.

IMPLEMENTATION (Implementierung)

Um die zweite Bedingung zu erfüllen, muss ein Router möglicherweise beim Booten oder Neustart des Routers einen Zeitserver abfragen. Die Verwendung des UDP Time Server Protocol wird für diesen Zweck empfohlen. Fortgeschrittenere Implementierungen werden das Network Time Protocol (NTP) verwenden, um nahezu millisekundengenaue Uhrsynchronisation zu erreichen; dies ist jedoch nicht erforderlich.

4.3.3.9 Address Mask Request/Reply (Adressmasken-Anfrage/Antwort)

Router MÜSSEN die Unterstützung zum Empfangen von ICMP Address Mask Request-Nachrichten und zum Antworten mit ICMP Address Mask Reply-Nachrichten implementieren. Diese Nachrichten sind in [INTERNET:2] definiert.

Router SOLLTEN für jede logische Schnittstelle eine Konfigurationsoption haben, die angibt, ob der Router auf Address Mask Requests für diese Schnittstelle antworten darf; diese Option MUSS standardmäßig so eingestellt sein, dass Antworten erlaubt sind. Router DÜRFEN NICHT auf Address Mask Requests antworten, bevor der Router die korrekte Adressmaske kennt.

Router DÜRFEN NICHT auf Address Mask Requests antworten, deren Quelladresse 0.0.0.0 ist und die auf einer physischen Schnittstelle ankommen, die mit mehreren logischen Schnittstellen verbunden ist, deren Adressmasken nicht alle gleich sind.

Router SOLLTEN alle empfangenen ICMP Address Mask Replies überprüfen, um festzustellen, ob die enthaltenen Informationen mit dem Wissen des Routers über die Adressmaske übereinstimmen. Wenn eine ICMP Address Mask Reply falsch zu sein scheint, SOLLTE der Router die Adressmaske und die IP-Adresse des Absenders protokollieren. Router DÜRFEN NICHT den Inhalt einer ICMP Address Mask Reply verwenden, um die korrekte Adressmaske zu bestimmen.

Da Hosts möglicherweise nicht in der Lage sind, die Adressmaske zu erfahren, wenn der Router beim Start des Hosts ausgefallen ist, KANN der Router auf jeder seiner logischen Schnittstellen unaufgeforderte ICMP Address Mask Replies senden, nachdem er seine eigene Adressmaske konfiguriert hat. Diese Funktion kann jedoch in Umgebungen, die Adressmasken variabler Länge verwenden, gefährlich sein. Daher DÜRFEN unaufgeforderte Address Mask Replies NICHT auf einer der folgenden logischen Schnittstellen gesendet werden:

die nicht für das Senden unaufgeforderter Address Mask Replies konfiguriert sind. Jede logische Schnittstelle MUSS einen Konfigurationsparameter haben, der dies steuert, und dieser Parameter MUSS standardmäßig so eingestellt sein, dass keine unaufgeforderten Address Mask Replies gesendet werden.
die ein enthaltendes (aber nicht identisches) Netzwerk-Präfix und eine physische Schnittstelle teilen.

Die { <Network-prefix>, -1 } Form der IP-Broadcast-Adresse MUSS zum Senden von Address Mask Replies verwendet werden.

DISCUSSION (Diskussion)

Die Fähigkeit für Router, das Senden von Address Mask Replies zu deaktivieren, ist an einer kleinen Anzahl von Standorten erforderlich, die ihren Hosts absichtlich die Adressmaske falsch mitteilen. Es wird erwartet, dass dieser Bedarf mit zunehmender Anzahl von Hosts, die den Host-Requirements-Standard erfüllen, verschwindet.

Der Grund für den zweiten Aufzählungspunkt oben und die Anforderung, welche IP-Broadcast-Adresse zu verwenden ist, besteht darin, Probleme zu vermeiden, wenn mehrere IP-Netzwerk-Präfixe im selben physischen Netzwerk verwendet werden.

4.3.3.10 Router Advertisement and Solicitations (Router-Ankündigungen und -Anfragen)

IP-Router MÜSSEN den Router-Teil des ICMP Router Discovery Protocol [INTERNET:13] auf allen angeschlossenen Netzwerken unterstützen, auf denen der Router IP-Multicast- oder IP-Broadcast-Adressierung unterstützt. Die Implementierung MUSS alle für den Router spezifizierten Konfigurationsvariablen mit den angegebenen Standardwerten enthalten.

DISCUSSION (Diskussion)

Router müssen den Host-Teil des ICMP Router Discovery Protocol nicht implementieren, können es jedoch nützlich für den Betrieb finden, wenn die IP-Weiterleitung deaktiviert ist (d.h., wenn sie als Host laufen).

DISCUSSION (Diskussion)

Wir stellen fest, dass es üblich ist, dass Hosts RIP Version 1 als Router-Entdeckungsprotokoll verwenden. Solche Hosts hören auf RIP-Verkehr und verwenden die aus diesem Verkehr extrahierten Informationen, um Router zu entdecken und zu entscheiden, welchen Router als ersten Hop-Router für ein bestimmtes Ziel zu verwenden. Obwohl dieses Verhalten entmutigt wird, ist es immer noch üblich, und Implementierer sollten sich dessen bewusst sein.

4.4 Internet Group Management Protocol - IGMP (Internet Group Management Protocol)

IGMP [INTERNET:4] ist ein Protokoll, das zwischen Hosts und Multicast-Routern auf einem einzelnen physischen Netzwerk verwendet wird, um die Mitgliedschaft von Hosts in bestimmten Multicast-Gruppen festzulegen. Multicast-Router verwenden diese Informationen in Kombination mit einem Multicast-Routing-Protokoll, um die IP-Multicast-Weiterleitung über das Internet zu unterstützen.

Router SOLLTEN den Host-Teil von IGMP implementieren.