7. IP-Paket-Handhabung

Dieses Dokument definiert einen Tunnelmechanismus, der konzeptionell eine IP-Verbindung ist. Da Verbindungen jedoch an IP-Router angeschlossen sind, müssen Implementierungen möglicherweise einige der Verantwortlichkeiten von IP-Routern übernehmen, wenn sie diese nicht an eine andere Implementierung, wie z. B. einen Kernel, delegieren.

7.1. Verbindungsbetrieb

Die in diesem Dokument beschriebenen IP-Weiterleitungstunnel sind keine voll ausgestatteten "Schnittstellen" im Sinne der IPv6-Adressierungsarchitektur [IPv6-ADDR]. Insbesondere haben sie nicht unbedingt IPv6-Link-Local-Adressen. Darüber hinaus werden IPv6-Stateless-Autokonfiguration oder Router-Advertisement-Nachrichten in solchen Schnittstellen nicht verwendet, ebenso wenig wie Neighbor Discovery.

Bei Verwendung von HTTP/2 oder HTTP/3 KANN ein Client optimistisch mit dem Senden von IP-Paketen per Proxy beginnen, bevor er die Antwort auf seine IP-Proxying-Anfrage erhält, wobei jedoch zu beachten ist, dass diese möglicherweise nicht vom IP-Proxy verarbeitet werden, wenn er auf die Anfrage mit einem Fehler antwortet oder wenn die Datagramme vom IP-Proxy vor der Anfrage empfangen werden. Da der Empfang von Adressen und Routen erforderlich ist, um zu wissen, dass ein Paket durch den Tunnel gesendet werden kann, könnten solche optimistischen Pakete vom IP-Proxy verworfen werden, wenn er sich entscheidet, andere Adressierungs- oder Routing-Informationen bereitzustellen als die, die der Client angenommen hat.

Beachten Sie, dass es möglich ist, dass mehrere Proxy-IP-Pakete im selben äußeren Paket gekapselt werden, beispielsweise weil ein QUIC-Paket mehr als einen QUIC DATAGRAM-Frame tragen kann. Es ist auch möglich, dass sich ein Proxy-IP-Paket über mehrere äußere Pakete erstreckt, da eine DATAGRAM-Kapsel über mehrere QUIC- oder TCP-Pakete aufgeteilt werden kann.

7.2. Routing-Betrieb

Die Anforderungen in diesem Abschnitt sind eine Wiederholung von Anforderungen, die für IP-Router im Allgemeinen gelten und möglicherweise nicht für Implementierungen von IP-Proxying gelten, die für das Routing auf externe Software angewiesen sind.

Wenn ein Endpunkt ein HTTP-Datagramm empfängt, das ein IP-Paket enthält, analysiert er den IP-Header des Pakets, führt alle lokalen Richtlinienprüfungen durch (z. B. Quelladressvalidierung), überprüft seine Routingtabelle, um eine ausgehende Schnittstelle auszuwählen, und sendet dann das IP-Paket auf dieser Schnittstelle oder übergibt es an eine lokale Anwendung. Der Endpunkt kann sich auch dafür entscheiden, alle empfangenen Pakete zu verwerfen, anstatt sie weiterzuleiten. Wenn ein empfangenes IP-Paket eine Korrektheits- oder Richtlinienprüfung nicht besteht, handelt es sich um einen Weiterleitungsfehler, nicht um eine Protokollverletzung, soweit es IP-Proxying betrifft; siehe Abschnitt 7.2.1. IP-Proxying-Endpunkte KÖNNEN zusätzliche Filterrichtlinien für die von ihnen weitergeleiteten IP-Pakete implementieren.

In der anderen Richtung prüft ein Endpunkt, wenn er ein IP-Paket empfängt, ob das Paket mit den für einen IP-Tunnel abgebildeten Routen übereinstimmt, und führt die gleichen Weiterleitungsprüfungen wie oben durch, bevor er das Paket über HTTP-Datagramme überträgt.

Wenn IP-Proxying-Endpunkte IP-Pakete zwischen verschiedenen Verbindungen weiterleiten, verringern sie den IP-Hop-Count (oder TTL) bei der Kapselung, aber nicht bei der Entkapselung. Mit anderen Worten, der Hop-Count wird direkt vor der Übertragung eines IP-Pakets in einem HTTP-Datagramm verringert. Dies verhindert Endlosschleifen bei Vorhandensein von Routing-Schleifen und entspricht den Entscheidungen in IPsec [IPSEC]. Dies gilt nicht für IP-Pakete, die vom IP-Proxying-Endpunkt selbst generiert werden.

Implementierer müssen sicherstellen, dass sie keinen Link-Local-Verkehr über die IP-Proxying-Schnittstelle hinaus weiterleiten, auf der er empfangen wurde. IP-Proxying-Endpunkte müssen auch ordnungsgemäß auf Pakete antworten, die an Link-Local-Multicast-Adressen gerichtet sind.

IPv6 erfordert, dass jede Verbindung eine MTU von mindestens 1280 Bytes hat [IPv6]. Da IP-Proxying in HTTP IP-Pakete in HTTP-Datagrammen überträgt und diese wiederum in QUIC DATAGRAM-Frames gesendet werden können, die nicht fragmentiert werden können [DGRAM], kann die MTU eines IP-Tunnels durch die MTU der QUIC-Verbindung begrenzt sein, über die IP-Proxying betrieben wird. Dies kann zu Situationen führen, in denen die minimale IPv6-Verbindungs-MTU verletzt wird. IP-Proxying-Endpunkte, die als Router arbeiten und IPv6 unterstützen, MÜSSEN sicherstellen, dass die IP-Tunnel-Verbindungs-MTU mindestens 1280 Bytes beträgt (d. h., dass sie HTTP-Datagramme mit Nutzlasten von mindestens 1280 Bytes senden können). Dies kann mit verschiedenen Techniken erreicht werden:

• Wenn beide IP-Proxying-Endpunkte sicher wissen, dass keine HTTP-Vermittler verwendet werden, können die Endpunkte die QUIC INITIAL-Pakete der äußeren QUIC-Verbindung auffüllen, über die IP-Proxying läuft. (Unter der Annahme, dass QUIC-Version 1 verwendet wird, beträgt der Overhead 1 Byte für den Typ, 20 Bytes für die maximale Verbindungs-ID-Länge, 4 Bytes für die maximale Paketnummernlänge, 1 Byte für den DATAGRAM-Frametyp, 8 Bytes für die maximale Quarter Stream ID, 1 Byte für die Null-Kontext-ID und 16 Bytes für das Authenticated Encryption with Associated Data (AEAD)-Authentifizierungs-Tag, was insgesamt 51 Bytes Overhead ergibt, was dem Auffüllen von QUIC INITIAL-Paketen auf 1331 Bytes oder mehr entspricht.)

• IP-Proxying-Endpunkte können auch ICMPv6-Echoanforderungen mit 1232 Bytes Daten senden, um die Verbindungs-MTU zu ermitteln und den Tunnel abzubauen, wenn sie keine Antwort erhalten. Sofern Endpunkte keine Out-of-Band-Mittel haben, um zu garantieren, dass die vorherigen Techniken ausreichend sind, MÜSSEN sie diese Methode verwenden. Wenn ein Endpunkt eine IPv6-Adresse seines Peers nicht kennt, kann er die ICMPv6-Echoanforderung an die Link-Local-All-Nodes-Multicast-Adresse (ff02::1) senden.

Wenn ein Endpunkt QUIC DATAGRAM-Frames verwendet, um IPv6-Pakete zu übertragen, und feststellt, dass die QUIC-MTU zu niedrig ist, um das Senden von 1280 Bytes zu ermöglichen, MUSS er den IP-Proxying-Anfragestream abbrechen.

7.2.1. Fehlersignalisierung

Da IP-Proxying-Endpunkte IP-Pakete oft an andere Netzwerkschnittstellen weiterleiten, müssen sie Fehler im Weiterleitungsprozess behandeln. Die Weiterleitung kann beispielsweise fehlschlagen, wenn der Endpunkt keine Route für die Zieladresse hat, wenn er so konfiguriert ist, dass er ein Zielpräfix per Richtlinie ablehnt, oder wenn die MTU der ausgehenden Verbindung kleiner ist als die Größe des weiterzuleitenden Pakets. In solchen Szenarien SOLLTEN IP-Proxying-Endpunkte ICMP [ICMP] [ICMPv6] verwenden, um den Weiterleitungsfehler an ihren Peer zu signalisieren, indem sie ICMP-Pakete generieren und diese unter Verwendung von HTTP-Datagrammen senden.

Endpunkte können die am besten geeigneten ICMP-Fehler zum Senden frei wählen. Einige Beispiele, die für IP-Proxying relevant sind, umfassen Folgendes:

• Für ungültige Quelladressen senden Sie Destination Unreachable (Ziel nicht erreichbar) (Abschnitt 3.1 von ICMPv6) mit Code 5, "Source address failed ingress/egress policy" (Quelladresse hat Eingangs-/Ausgangsrichtlinie nicht bestanden).

• Für nicht routbare Zieladressen senden Sie Destination Unreachable (Ziel nicht erreichbar) (Abschnitt 3.1 von ICMPv6) mit Code 0, "No route to destination" (Keine Route zum Ziel), oder Code 1, "Communication with destination administratively prohibited" (Kommunikation mit Ziel administrativ verboten).

• Für Pakete, die nicht in die MTU der ausgehenden Verbindung passen, senden Sie Packet Too Big (Paket zu groß) (Abschnitt 3.2 von ICMPv6).

Um diese Fehler zu empfangen, müssen Endpunkte bereit sein, ICMP-Pakete zu empfangen. Wenn ein Endpunkt keine ROUTE_ADVERTISEMENT-Kapseln sendet, wie z. B. ein Client, der einen IP-Flow über einen IP-Proxy öffnet, SOLLTE er Proxy-ICMP-Pakete von seinem Peer verarbeiten, um diese Fehler zu empfangen. Beachten Sie, dass ICMP-Nachrichten von einer anderen Quelladresse als der des IP-Proxying-Peers und auch von außerhalb des Ziels stammen können, wenn Bereichsbegrenzung verwendet wird (siehe Abschnitt 4.6).