2. Sicherungsschicht (LINK LAYER)

2.1 Einleitung (INTRODUCTION)

Alle Internetsysteme, ob Hosts oder Gateways, haben dieselben Anforderungen an die Sicherungsschicht-Protokolle. Diese Anforderungen sind in Kapitel 3 von „Anforderungen an Internet-Gateways“ [INTRO:2] angegeben und werden durch diesen Abschnitt ergänzt.

2.2 Protokoll-Durchgehung (PROTOCOL WALK-THROUGH)

Keine (None).

2.3 Spezifische Probleme (SPECIFIC ISSUES)

2.3.1 Trailer-Protokoll-Aushandlung (Trailer Protocol Negotiation)

Das Trailer-Protokoll der Sicherungsschicht-Kapselung [LINK:1] KANN (MAY) verwendet werden, aber nur wenn verifiziert wurde, dass beide an der Sicherungsschicht-Kommunikation beteiligten Systeme (Hosts oder Gateways) Trailer implementieren. Wenn das System die Trailer-Protokoll-Verwendung nicht dynamisch pro Zieladresse aushandelt, MUSS (MUST) die Standardkonfiguration das Protokoll deaktivieren.

DISCUSSION (Diskussion):

Das Trailer-Protokoll ist eine Sicherungsschicht-Kapselungstechnik, die den Dateninhalt der über das physische Netzwerk gesendeten Pakete umordnet. In einigen Fällen verbessert der Trailer den Durchsatz der höheren Protokolle, indem er die Datenkopiemenge innerhalb des Betriebssystems reduziert. Die höheren Protokolle wissen nichts von der Trailer-Verwendung, aber wenn das Protokoll verwendet wird, müssen (MUST) sowohl der sendende als auch der empfangende Host das Protokoll verstehen.

Unsachgemäße Trailer-Verwendung verursacht sehr verwirrende Symptome. Nur Pakete mit bestimmten Größenattributen verwenden die Trailer-Kapselung, und normalerweise haben nur ein kleiner Bruchteil der ausgetauschten Pakete diese Attribute. Wenn daher ein System, das Trailer verwendet, Pakete mit einem System austauscht, das keine verwendet, verschwinden einige Pakete in einem Schwarzen Loch, während andere erfolgreich zugestellt werden.

IMPLEMENTATION (Implementierung):

Auf Ethernet verwenden Trailer-gekapselte Pakete einen anderen Ethernet-Typ [LINK:1], und die Trailer-Aushandlung erfolgt bei der Ermittlung der Link-Schicht-Adresse des Zielsystems mittels ARP.

Genauer gesagt wird der ARP-Austausch auf die übliche Weise mit dem normalen IP-Protokolltyp durchgeführt, aber ein Host, der Trailer verwenden möchte, sendet eine zusätzliche „Trailer-ARP-Antwort (trailer ARP reply)“, d.h. eine ARP-Antwort, die den Trailer-Kapselungsprotokolltyp angibt, aber ansonsten das Format einer normalen ARP-Antwort hat. Wenn ein für Trailer konfigurierter Host eine Trailer-ARP-Antwortnachricht von einer entfernten Maschine erhält, kann er diese Maschine zur Liste der Trailer verstehenden Maschinen hinzufügen, z.B. durch Markieren des entsprechenden Eintrags im ARP-Cache.

Ein Host, der Trailer-gekapselte Pakete empfangen möchte, sendet bei jedem Abschluss eines normalen IP-ARP-Nachrichtenaustauschs eine Trailer-ARP-Antwort. Daher sendet ein Host, der eine ARP-Anfrage für seine IP-Protokolladresse erhält, zusätzlich zur normalen IP-ARP-Antwort eine Trailer-ARP-Antwort; ein Host, der eine IP-ARP-Anfrage gesendet hat, sendet bei Erhalt der entsprechenden IP-ARP-Antwort eine Trailer-ARP-Antwort. Auf diese Weise kann sowohl der anfragende als auch der antwortende Host des IP-ARP-Austauschs den Empfang von Trailer-Kapselung anfordern.

Dieses Schema verwendet zusätzliche Trailer-ARP-Antwortpakete anstatt, für den Trailer-Protokolltyp eine ARP-Anfrage zu senden, um einen ständigen ARP-Paketaustausch mit einem Host zu vermeiden, der sich entgegen jeder Spezifikation oder dem gesunden Menschenverstand verhält (behaving contrary to any specification or common sense) und mit einer anderen IP-ARP-Antwort auf eine Trailer-ARP-Antwort reagieren würde. Dieses Problem wird vermieden, indem eine Trailer-ARP-Antwort nur gesendet wird, wenn eine IP-ARP-Antwort auf eine ausstehende Anfrage empfangen wird; das ist der Fall, wenn die Hardware-Adresse des Hosts bei Erhalt der IP-ARP-Antwort noch unbekannt ist. Die Trailer-ARP-Antwort kann stets zusammen mit der IP-ARP-Antwort gesendet werden, die auf eine IP-ARP-Anfrage antwortet.

2.3.2 Address Resolution Protocol -- ARP (Address Resolution Protocol -- ARP)

2.3.2.1 ARP-Cache-Validierung (ARP Cache Validation)

Die Implementierung des Address Resolution Protocol (ARP) [LINK:2] MUSS (MUST) einen Mechanismus bereitstellen, um veraltete Cache-Einträge zu löschen. Wenn dieser Mechanismus ein Timeout beinhaltet, SOLLTE (SHOULD) der Timeout-Wert konfigurierbar sein.

Es MUSS (MUST) ein Mechanismus enthalten sein, der ARP-Fluten (wiederholtes Senden von ARP-Anfragen für dieselbe IP-Adresse in hoher Rate) verhindert. Die empfohlene maximale Rate pro Zieladresse beträgt 1 pro Sekunde.

DISCUSSION (Diskussion):

Die ARP-Spezifikation [LINK:2] schlägt einen Timeout-Mechanismus vor, fordert ihn aber nicht, um Cache-Einträge ungültig zu machen, wenn ein Host seine Ethernet-Adresse ändert. Die Allgegenwart von Proxy-ARP (siehe Abschnitt 2.4 von [INTRO:2]) erhöht die Wahrscheinlichkeit, dass Cache-Einträge auf einem Host ungültig werden, erheblich, daher ist nun ein ARP-Cache-Ungültigmachungsmechanismus auf Hosts notwendig. Selbst ohne Proxy-ARP ist ein langer Cache-Timeout-Zyklus nützlich, um automatisch falsche ARP-Daten zu korrigieren, die zwischengespeichert worden sein könnten.

IMPLEMENTATION (Implementierung):

Vier Mechanismen wurden verwendet, manchmal in Kombination, um veraltete Cache-Einträge zu löschen.

(1) Timeout —— lässt Cache-Einträge periodisch verfallen, selbst wenn sie verwendet werden. Beachten Sie, dass das Timeout neu gestartet werden sollte, wenn ein Cache-Eintrag „aktualisiert (refreshed)“ wird (durch Beobachtung des Quellfelds der ARP-Broadcasts der betreffenden Systeme, unabhängig von der Zieladresse). Für den Proxy-ARP-Fall sollte der Timeout im Bereich einer Minute liegen.

(2) Unicast-Polling (Unicast Poll) —— sondert den entfernten Host aktiv, indem er eine Point-to-Point-ARP-Anfrage sendet, und löscht den Eintrag, wenn bei N aufeinanderfolgenden Abfragen keine ARP-Antwort empfangen wird. Ebenso sollte der Timeout im Bereich einer Minute liegen, und normalerweise ist N 2.

(3) Link-Schicht-Rat (Link-Layer Advice) —— wenn der Link-Schicht-Treiber ein Zustellproblem erkennt, wird der entsprechende ARP-Cache-Eintrag gelöscht.

(4) Rat der höheren Schicht (Higher-layer Advice) —— stellt einen Aufruf von der Internet-Schicht an die Link-Schicht bereit, um ein Zustellproblem anzuzeigen. Die Wirkung dieses Aufrufs ist, den entsprechenden Cache-Eintrag ungültig zu machen. Dieser Aufruf ähnelt dem „ADVISE_DELIVPROB()“-Aufruf von der Transportschicht an die Internet-Schicht (siehe Abschnitt 3.4), und tatsächlich kann die ADVISE_DELIVPROB-Routine wiederum die Link-Schicht-Routine aufrufen, um den ARP-Cache-Eintrag ungültig zu machen.

Die Methoden (1) und (2) beinhalten ein ARP-Cache-Timeout von etwa einer Minute oder weniger. Ohne Proxy-ARP kann ein so kurzes Timeout auf sehr großen Ethernets einen erheblichen Overhead-Verkehr erzeugen. Daher kann es notwendig sein, den Host so zu konfigurieren, dass das ARP-Cache-Timeout verlängert wird.

2.3.2.2 ARP-Paketwarteschlange (ARP Packet Queue)

Die Link-Schicht SOLLTE (SHOULD) mindestens ein (das neueste) Paket jeder Gruppe, die an dieselbe unaufgelöste IP-Adresse gesendet wird, speichern (statt verwerfen) und das gespeicherte Paket übertragen, sobald die Adresse aufgelöst ist.

DISCUSSION (Diskussion):

Wird diese Empfehlung nicht befolgt, geht das erste Paket jedes Austauschs verloren. Obwohl höhere Protokolle Paketverluste normalerweise durch Retransmission bewältigen können, beeinträchtigt Paketverlust die Leistung. Beispielsweise übertreibt der Verlust einer TCP-Öffnungsanforderung die anfängliche RTT-Schätzung. Auf UDP basierende Anwendungen (wie das Domain Name System) sind stärker betroffen.

2.3.3 Ethernet- und IEEE-802-Kapselung (Ethernet and IEEE 802 Encapsulation)

Die IP-Kapselung auf Ethernet ist in RFC-894 [LINK:3] beschrieben, und RFC-1042 [LINK:4] beschreibt die IP-Kapselung auf IEEE-802-Netzwerken. RFC-1042 erläutert und ersetzt die Diskussion in Abschnitt 3.4 von [INTRO:2].

Jeder an ein 10-Mbps-Ethernet-Kabel angeschlossene Internet-Host:

• MUSS (MUST) in der Lage sein, Pakete mit RFC-894-Kapselung zu senden und zu empfangen;
• SOLLTE (SHOULD) in der Lage sein, RFC-1042-Pakete zu empfangen und mit RFC-894-Paketen zu mischen; und
• KANN (MAY) in der Lage sein, Pakete mit RFC-1042-Kapselung zu senden.

Ein Internet-Host, der das Senden sowohl von RFC-894- als auch RFC-1042-Kapselung implementiert, MUSS (MUST) einen Konfigurationsschalter bereitstellen, um auszuwählen, welche gesendet wird, und dieser Schalter MUSS (MUST) RFC-894 als Standard haben.

Beachten Sie, dass die Standard-IP-Kapselung von RFC-1042 den von IEEE für IP reservierten Protokoll-id-Wert (K1=6) nicht verwendet; stattdessen wird ein Wert (K1=170) verwendet, der eine Erweiterung („SNAP“) andeutet, die das Ether-Type-Feld enthalten kann. Internetsysteme DÜRFEN NICHT (MUST NOT) 802-Pakete senden, die K1=6 verwenden.

Die Übersetzung von Internet-Adressen in Link-Schicht-Adressen auf Ethernet- und IEEE-802-Netzwerken MUSS (MUST) vom Address Resolution Protocol (ARP) verwaltet werden.

Die MTU von Ethernet beträgt 1500 und die MTU von 802.3 beträgt 1492.

DISCUSSION (Diskussion):

Die IEEE-802.3-Spezifikation sieht den Betrieb auf einem 10-Mbps-Ethernet-Kabel vor, bei dem Ethernet- und 802.3-Rahmen physisch gemischt werden können. Der Empfänger kann Ethernet- und 802.3-Rahmen am Wert des 802.3-Längenfelds unterscheiden; dieses Zweibytefeld befindet sich im Header an derselben Position wie das Ether-Type-Feld der Ethernet-Rahmen. Insbesondere muss das 802.3-Längenfeld kleiner oder gleich 1500 sein, während alle gültigen Ether-Type-Werte größer als 1500 sind.

Ein weiteres Kompatibilitätsproblem tritt bei der Link-Schicht-Broadcast auf. Ein in einem Rahmenformat gesendeter Broadcast wird von Hosts, die nur das andere Rahmenformat empfangen können, nicht gesehen.

Die Bestimmungen dieses Abschnitts zielen darauf ab, wo immer möglich die direkte Interoperabilität auf demselben Kabel zwischen 894-fähigen und 1042-fähigen Systemen zu ermöglichen. Ziel ist es, die derzeit von 894-Allein-Systemen dominierte Situation zu unterstützen und gleichzeitig einen reibungslosen Übergang zu einer Zukunft zu bieten, in der 1042-Systeme verbreitet sein könnten.

Beachten Sie, dass ein 894-Allein-System nicht direkt mit einem 1042-Allein-System interoperieren kann. Wenn diese beiden Systemtypen als zwei verschiedene logische Netzwerke auf demselben Kabel konfiguriert sind, können sie nur über ein IP-Gateway kommunizieren. Zudem macht es das Link-Schicht-Broadcast-Problem unmöglich, automatisch zu erkennen, welches Format gesendet werden soll.

2.4 Sicherungs-/Internetschicht-Schnittstelle (LINK/INTERNET LAYER INTERFACE)

Die Paketempfangsschnittstelle zwischen der IP-Schicht und der Link-Schicht MUSS (MUST) ein Flag enthalten, das angibt, ob das eingehende Paket an eine Link-Schicht-Broadcast-Adresse adressiert ist.

DISCUSSION (Diskussion):

Obwohl die IP-Schicht normalerweise die Link-Schicht-Adressen nicht kennt (da jedes andere Netzwerkmedium normalerweise ein anderes Adressformat hat), ist die Broadcast-Adresse auf einem Broadcast-fähigen Medium ein wichtiger Sonderfall. Siehe Abschnitt 2.4, insbesondere die Diskussion über Broadcast-Stürme.

Die Paketsendeschnittstelle zwischen IP und der Link-Schicht MUSS (MUST) das 5-Bit-TOS-Feld enthalten (siehe Abschnitt 3.2.1.6).

Die Link-Schicht DARF NICHT (MUST NOT) nur deshalb, weil für eine Zieladresse kein ARP-Cache-Eintrag existiert, einen „Ziel nicht erreichbar (Destination Unreachable)“-Fehler an IP melden.

2.5 Zusammenfassung der Sicherungsschicht-Anforderungen (LINK LAYER REQUIREMENTS SUMMARY)

Merkmal (Feature)	Abschnitt	MUST	SHOULD	MAY	SHOULD NOT	MUST NOT
Trailer-Kapselung (Trailer encapsulation)	2.3.1			x
Trailer ohne Aushandlung standardmäßig senden (Send Trailers by default without negotiation)	2.3.1					x
ARP	2.3.2
Veraltete ARP-Cache-Einträge löschen (Flush out-of-date ARP cache entries)	2.3.2.1	x
ARP-Fluten verhindern (Prevent ARP floods)	2.3.2.1	x
Cache-Timeout konfigurierbar (Cache timeout configurable)	2.3.2.1		x
Mindestens ein (neuestes) unaufgelöstes Paket speichern (Save at least one (latest) unresolved pkt)	2.3.2.2		x
Ethernet- und IEEE-802-Kapselung (Ethernet and IEEE 802 Encapsulation)	2.3.3
Host fähig: (Host able to:)	2.3.3
- RFC-894-Kapselung senden & empfangen (- Send & receive RFC-894 encapsulation)	2.3.3	x
- RFC-1042-Kapselung empfangen (- Receive RFC-1042 encapsulation)	2.3.3		x
- RFC-1042-Kapselung senden (- Send RFC-1042 encapsulation)	2.3.3			x
Konfigurationsschalter zur Auswahl, Standard RFC-894 (Then config. sw. to select, RFC-894 dflt)	2.3.3	x
K1=6-Kapselung senden (Send K1=6 encapsulation)	2.3.3					x
ARP auf Ethernet und IEEE-802-Netzen verwenden (Use ARP on Ethernet and IEEE 802 nets)	2.3.3	x
Sicherungs-/Internetschicht-Schnittstelle (Link/Internet Layer Interface)	2.4
Link-Schicht meldet Broadcasts an IP-Schicht (Link layer report b'casts to IP layer)	2.4	x
IP-Schicht übergibt TOS an Link-Schicht (IP layer pass TOS to link layer)	2.4	x
Fehlender ARP-Cache-Eintrag als Zielunreach behandelt (No ARP cache entry treated as Dest. Unreach.)	2.4					x

---

Referenzen (References):

• [LINK:1] Leffler, S., and M. Karels, "Trailer Encapsulations", RFC-893, Univ. of California at Berkeley, April 1984.
• [LINK:2] Plummer, D., "An Ethernet Address Resolution Protocol", RFC-826, November 1982.
• [LINK:3] Hornig, C., "A Standard for the Transmission of IP Datagrams over Ethernet Networks", RFC-894, April 1984.
• [LINK:4] Postel, J., and J. Reynolds, "A Standard for the Transmission of IP Datagrams over IEEE 802 Networks", RFC-1042, February 1988.