4. IP-Tunneling über HTTP

Um die Aushandlung eines Tunnels für IP über HTTP zu ermöglichen, definiert dieses Dokument das HTTP-Upgrade-Token "connect-ip". Die resultierenden IP-Tunnel verwenden das Kapselprotokoll (siehe Abschnitt 3.2 von HTTP-DGRAM) mit HTTP-Datagrammen im in Abschnitt 6 definierten Format.

Um einen IP-Tunnel zu initiieren, der einem einzelnen HTTP-Stream zugeordnet ist, gibt ein Client eine Anfrage aus, die das Upgrade-Token "connect-ip" enthält.

Beim Senden seiner IP-Proxying-Anfrage MUSS der Client eine URI-Vorlagenerweiterung durchführen, um den Pfad und die Abfrage seiner Anfrage zu bestimmen; siehe Abschnitt 3.

Aufgrund der Definition des Kapselprotokolls (siehe Abschnitt 3.2 von HTTP-DGRAM) enthalten IP-Proxying-Anfragen keinen Nachrichteninhalt. Ebenso enthalten erfolgreiche IP-Proxying-Antworten keinen Nachrichteninhalt.

IP-Proxying über HTTP MUSS über TLS- oder QUIC-Verschlüsselung oder ein anderes gleichwertiges Verschlüsselungsprotokoll betrieben werden, um Vertraulichkeit, Integrität und Authentifizierung zu gewährleisten.

4.1. IP-Proxy-Handhabung

Nach Erhalt einer IP-Proxying-Anfrage:

• Wenn der Empfänger so konfiguriert ist, dass er einen anderen HTTP-Server verwendet, fungiert er als Vermittler, indem er die Anfrage an den anderen HTTP-Server weiterleitet. Beachten Sie, dass solche Vermittler die Anfrage möglicherweise neu codieren müssen, wenn sie sie unter Verwendung einer Version von HTTP weiterleiten, die sich von der unterscheidet, die zum Empfang verwendet wurde, da sich die Anforderungscodierung je nach Version unterscheidet (siehe unten).

• Andernfalls fungiert der Empfänger als IP-Proxy. Der IP-Proxy kann sich entscheiden, die IP-Proxying-Anfrage abzulehnen. Andernfalls extrahiert er die optionalen Variablen "target" und "ipproto" aus der URI, die er aus den Anforderungsheadern rekonstruiert hat, decodiert ihre Prozentcodierung und baut einen IP-Tunnel auf.

IP-Proxys MÜSSEN validieren, ob die decodierten Variablen "target" und "ipproto" die Anforderungen in Abschnitt 4.6 erfüllen. Wenn dies nicht der Fall ist, MUSS der IP-Proxy die Anfrage als fehlerhaft behandeln; siehe Abschnitt 8.1.1 von HTTP/2 und Abschnitt 4.1.2 von HTTP/3. Wenn die Variable "target" ein DNS-Name ist, MUSS der IP-Proxy eine DNS-Auflösung durchführen (um die entsprechenden IPv4- und/oder IPv6-Adressen über A- und/oder AAAA-Einträge zu erhalten), bevor er auf die HTTP-Anfrage antwortet. Wenn während dieses Prozesses Fehler auftreten, MUSS der IP-Proxy die Anfrage ablehnen und SOLLTE Details unter Verwendung eines geeigneten Proxy-Status-Headerfelds [PROXY-STATUS] senden. Wenn beispielsweise die DNS-Auflösung einen Fehler zurückgibt, kann der Proxy den Proxy-Fehlertyp dns_error aus Abschnitt 2.3.2 von PROXY-STATUS verwenden.

Die Lebensdauer des IP-Weiterleitungstunnels ist an den IP-Proxying-Anfragestream gebunden. Der IP-Proxy MUSS alle IP-Adress- und Routenzuweisungen, die mit dem IP-Weiterleitungstunnel verbunden sind, aufrechterhalten, solange der Anfragestream offen ist. IP-Proxys KÖNNEN sich entscheiden, den Tunnel aufgrund einer Zeit der Inaktivität abzubauen, aber sie MÜSSEN den Anfragestream schließen, wenn sie dies tun.

Eine erfolgreiche IP-Proxying-Antwort (wie in Abschnitt 4.3 und 4.5 definiert) zeigt an, dass der IP-Proxy einen IP-Tunnel aufgebaut hat und bereit ist, IP-Nutzlasten per Proxy zu übertragen. Jede andere Antwort als eine erfolgreiche IP-Proxying-Antwort zeigt an, dass die Anfrage fehlgeschlagen ist; daher MUSS der Client die Anfrage abbrechen.

Zusammen mit einer erfolgreichen IP-Proxying-Antwort kann der IP-Proxy Kapseln senden, um dem Client Adressen zuzuweisen und Routen anzukündigen (Abschnitt 4.7). Der Client kann dem IP-Proxy auch Adressen zuweisen und Routen für das Netzwerk-zu-Netzwerk-Routing ankündigen.

4.2. HTTP/1.1-Anfrage

Bei Verwendung von HTTP/1.1 [HTTP/1.1] erfüllt eine IP-Proxying-Anfrage die folgenden Anforderungen:

• Die Methode MUSS "GET" sein.

• Die Anfrage MUSS ein einzelnes Host-Headerfeld enthalten, das den Host und den optionalen Port des IP-Proxys enthält.

• Die Anfrage MUSS ein Connection-Headerfeld mit dem Wert "Upgrade" enthalten (beachten Sie, dass diese Anforderung gemäß Abschnitt 7.6.1 von HTTP nicht zwischen Groß- und Kleinschreibung unterscheidet).

• Die Anfrage MUSS ein Upgrade-Headerfeld mit dem Wert "connect-ip" enthalten.

Eine IP-Proxying-Anfrage, die diesen Einschränkungen nicht entspricht, ist fehlerhaft. Der Empfänger einer solchen fehlerhaften Anfrage MUSS mit einem Fehler antworten und SOLLTE den Statuscode 400 (Bad Request) verwenden.

Wenn der Client beispielsweise mit der URI-Vorlage "https://example.org/.well-known/masque/ip/{target}/{ipproto}/" konfiguriert ist und einen IP-Weiterleitungstunnel ohne Ziel- oder Protokolleinschränkungen öffnen möchte, könnte er die folgende Anfrage senden:

GET https://example.org/.well-known/masque/ip/*/*/ HTTP/1.1
Host: example.org
Connection: Upgrade
Upgrade: connect-ip
Capsule-Protocol: ?1

Abbildung 2: Beispiel für eine HTTP/1.1-Anfrage

4.3. HTTP/1.1-Antwort

Der Server zeigt eine erfolgreiche IP-Proxying-Antwort an, indem er mit den folgenden Anforderungen antwortet:

• Der HTTP-Statuscode in der Antwort MUSS 101 (Switching Protocols) sein.

• Die Antwort MUSS ein Connection-Headerfeld mit dem Wert "Upgrade" enthalten (beachten Sie, dass diese Anforderung gemäß Abschnitt 7.6.1 von HTTP nicht zwischen Groß- und Kleinschreibung unterscheidet).

• Die Antwort MUSS ein einzelnes Upgrade-Headerfeld mit dem Wert "connect-ip" enthalten.

• Die Antwort MUSS die Anforderungen von HTTP-Antworten erfüllen, die das Kapselprotokoll starten; siehe Abschnitt 3.2 von HTTP-DGRAM.

Wenn eine dieser Anforderungen nicht erfüllt ist, MUSS der Client diesen Proxy-Versuch als fehlgeschlagen behandeln und die Verbindung schließen.

Der Server könnte beispielsweise antworten mit:

HTTP/1.1 101 Switching Protocols
Connection: Upgrade
Upgrade: connect-ip
Capsule-Protocol: ?1

Abbildung 3: Beispiel für eine HTTP/1.1-Antwort

4.4. HTTP/2- und HTTP/3-Anfragen

Bei Verwendung von HTTP/2 [HTTP/2] oder HTTP/3 [HTTP/3] verwenden IP-Proxying-Anfragen HTTP Extended CONNECT. Dies erfordert, dass Server eine HTTP-Einstellung senden, wie in [EXT-CONNECT2] und [EXT-CONNECT3] angegeben, und dass Anfragen HTTP-Pseudo-Headerfelder mit den folgenden Anforderungen verwenden:

• Das Pseudo-Headerfeld :method MUSS "CONNECT" sein.

• Das Pseudo-Headerfeld :protocol MUSS "connect-ip" sein.

• Das Pseudo-Headerfeld :authority MUSS die Autorität des IP-Proxys enthalten.

• Die Pseudo-Headerfelder :path und :scheme DÜRFEN NICHT leer sein. Ihre Werte MÜSSEN das Schema und den Pfad aus der URI-Vorlage enthalten, nachdem der URI-Vorlagenerweiterungsprozess abgeschlossen wurde; siehe Abschnitt 3. Variablen in der URI-Vorlage können den Geltungsbereich der Anfrage bestimmen, z. B. das Anfordern einer vollständigen Tunnel-IP-Paketweiterleitung oder eines bestimmten Proxy-Flows; siehe Abschnitt 4.6.

Eine IP-Proxying-Anfrage, die diesen Einschränkungen nicht entspricht, ist fehlerhaft; siehe Abschnitt 8.1.1 von HTTP/2 und Abschnitt 4.1.2 von HTTP/3.

Wenn der Client beispielsweise mit der URI-Vorlage "https://example.org/.well-known/masque/ip/{target}/{ipproto}/" konfiguriert ist und einen IP-Weiterleitungstunnel ohne Ziel- oder Protokolleinschränkungen öffnen möchte, könnte er die folgende Anfrage senden:

HEADERS
:method = CONNECT
:protocol = connect-ip
:scheme = https
:path = /.well-known/masque/ip/*/*/
:authority = example.org
capsule-protocol = ?1

Abbildung 4: Beispiel für eine HTTP/2- oder HTTP/3-Anfrage

4.5. HTTP/2- und HTTP/3-Antworten

Der Server zeigt eine erfolgreiche IP-Proxying-Antwort an, indem er mit den folgenden Anforderungen antwortet:

• Der HTTP-Statuscode in der Antwort MUSS im Bereich 2xx (Erfolgreich) liegen.

• Die Antwort MUSS die Anforderungen von HTTP-Antworten erfüllen, die das Kapselprotokoll starten; siehe Abschnitt 3.2 von HTTP-DGRAM.

Wenn eine dieser Anforderungen nicht erfüllt ist, MUSS der Client diesen Proxy-Versuch als fehlgeschlagen behandeln und die Anfrage abbrechen. Als Beispiel wird jeder Statuscode im Bereich 3xx als Fehler behandelt und veranlasst den Client, die Anfrage abzubrechen.

Der Server könnte beispielsweise antworten mit:

HEADERS
:status = 200
capsule-protocol = ?1

Abbildung 5: Beispiel für eine HTTP/2- oder HTTP/3-Antwort

4.6. Begrenzung des Anfragebereichs

Im Gegensatz zu UDP-Proxying-Anfragen, bei denen ein Zielhost angegeben werden muss, können IP-Proxying-Anfragen Endpunkten ermöglichen, beliebige IP-Pakete an einen beliebigen Host zu senden. Der Client kann sich dafür entscheiden, eine bestimmte Anfrage auf ein bestimmtes IP-Präfix oder IP-Protokoll zu beschränken, indem er seiner Anfrage Parameter hinzufügt. Wenn der IP-Proxy weiß, dass eine Anfrage auf ein Zielpräfix oder -protokoll beschränkt ist, kann er diese Informationen nutzen, um seine Ressourcenzuweisung zu optimieren; beispielsweise kann der IP-Proxy zwei IP-Proxying-Anfragen, die auf unterschiedliche Präfixe und/oder unterschiedliche Protokolle beschränkt sind, dieselbe öffentliche IP-Adresse zuweisen.

Der Geltungsbereich der Anfrage wird dem IP-Proxy vom Client über die Variablen "target" und "ipproto" der URI-Vorlage angezeigt; siehe Abschnitt 3. Sowohl die Variable "target" als auch "ipproto" sind optional; wenn sie nicht enthalten sind, wird davon ausgegangen, dass sie den Wildcard-Wert "*" tragen.

target: Die Variable "target" enthält einen Hostnamen oder ein IP-Präfix eines bestimmten Hosts, an den der Client Pakete per Proxy senden möchte. Wenn die Variable "target" nicht angegeben ist oder ihr Wert "*" ist, fordert der Client die Kommunikation mit einem beliebigen zulässigen Host an. "target" unterstützt die Verwendung von DNS-Namen, IPv6-Präfixen und IPv4-Präfixen. Beachten Sie, dass IPv6-Zonenbezeichner für die adressierte Adressierung [IPv6-ZONE-ID] nicht unterstützt werden. Wenn das Ziel ein IP-Präfix ist (IP-Adresse, optional gefolgt von einem prozentcodierten Schrägstrich, gefolgt von der Präfixlänge in Bits), unterstützt die Anfrage nur eine einzelne IP-Version. Wenn das Ziel ein Hostname ist, wird erwartet, dass der IP-Proxy eine DNS-Auflösung durchführt, um zu bestimmen, welche Route(n) dem Client angekündigt werden sollen. Der IP-Proxy SOLLTE eine ROUTE_ADVERTISEMENT-Kapsel senden, die Routen für alle Adressen enthält, die für den angeforderten Hostnamen aufgelöst wurden, die für den IP-Proxy zugänglich sind und zu einer Adressfamilie gehören, für die der IP-Proxy auch eine zugewiesene Adresse sendet.

ipproto: Die Variable "ipproto" enthält eine Internetprotokollnummer; siehe die definierte Liste im IANA-Register "Assigned Internet Protocol Numbers" [IANA-PN]. Wenn vorhanden, gibt sie an, dass ein Client für diese Anfrage nur ein bestimmtes IP-Protokoll per Proxy übertragen möchte. Wenn der Wert "*" ist oder die Variable nicht enthalten ist, fordert der Client die Verwendung eines beliebigen IP-Protokolls an. Das in der Variablen "ipproto" angegebene IP-Protokoll stellt einen zulässigen nächsten Header-Wert dar, der in IP-Headern übertragen wird, die direkt in HTTP-Datagrammen (den äußersten IP-Headern) gesendet werden. ICMP-Verkehr ist unabhängig vom Wert dieses Feldes immer erlaubt.

Unter Verwendung der Begriffe IPv6address, IPv4address und reg-name aus [URI] MÜSSEN die Variablen "target" und "ipproto" dem Format in Abbildung 6 entsprechen, unter Verwendung der Notation aus [ABNF]. Zusätzlich:

• Wenn "target" ein IPv6-Literal oder -Präfix enthält, MÜSSEN die Doppelpunkte (":") prozentcodiert werden. Wenn der Zielhost beispielsweise "2001:db8::42" ist, wird er in der URI als "2001%3Adb8%3A%3A42" codiert.

• Falls vorhanden, MUSS der IP-Präfixlänge in "target" ein prozentcodierter Schrägstrich ("/") vorangestellt werden: "%2F". Die IP-Präfixlänge MUSS eine dezimale Ganzzahl zwischen 0 und der Länge der IP-Adresse in Bits einschließlich darstellen.

• Wenn "target" ein IP-Präfix enthält und die Präfixlänge strikt kleiner als die Länge der IP-Adresse in Bits ist, MÜSSEN die niedrigeren Bits der IP-Adresse, die nicht von der Präfixlänge abgedeckt werden, alle auf 0 gesetzt werden.

• "ipproto" MUSS eine dezimale Ganzzahl zwischen 0 und 255 einschließlich oder den Wildcard-Wert "*" darstellen.

target = IPv6prefix / IPv4prefix / reg-name / "*"
IPv6prefix = IPv6address ["%2F" 1*3DIGIT]
IPv4prefix = IPv4address ["%2F" 1*2DIGIT]
ipproto = 1*3DIGIT / "*"

Abbildung 6: URI-Vorlagenvariablenformat

IP-Proxys KÖNNEN eine Zugriffskontrolle unter Verwendung der vom Client bereitgestellten Bereichsinformationen durchführen, d. h., wenn der Client nicht berechtigt ist, auf eines der im Bereich enthaltenen Ziele zuzugreifen, kann der IP-Proxy die Anfrage sofort ablehnen.

4.7. Kapseln

Dieses Dokument definiert mehrere neue Kapseltypen, die es Endpunkten ermöglichen, IP-Konfigurationsinformationen auszutauschen. Beide Endpunkte KÖNNEN eine beliebige Anzahl dieser neuen Kapseln senden.

4.7.1. ADDRESS_ASSIGN-Kapsel

Die ADDRESS_ASSIGN-Kapsel (Kapseltyp 0x01) ermöglicht es einem Endpunkt, seinem Peer eine Liste von IP-Adressen oder Präfixen zuzuweisen. Jede Kapsel enthält die vollständige Liste der IP-Präfixe, die dem Empfänger derzeit zugewiesen sind. Jede dieser Adressen kann als Quelladresse für IP-Pakete verwendet werden, die vom Empfänger dieser Kapsel stammen.

ADDRESS_ASSIGN Capsule {
  Type (i) = 0x01,
  Length (i),
  Assigned Address (..) ...,
}

Abbildung 7: ADDRESS_ASSIGN-Kapselformat

Die ADDRESS_ASSIGN-Kapsel enthält eine Sequenz von null oder mehr zugewiesenen Adressen.

Assigned Address {
  Request ID (i),
  IP Version (8),
  IP Address (32..128),
  IP Prefix Length (8),
}

Abbildung 8: Format der zugewiesenen Adresse

Jede zugewiesene Adresse enthält die folgenden Felder:

Request ID (Anfrage-ID): Anfragekennung, codiert als Ganzzahl variabler Länge. Wenn diese Adresszuweisung als Antwort auf eine Adressanfrage (siehe Abschnitt 4.7.2) erfolgt, MUSS dieses Feld den Wert des entsprechenden Feldes in der Anfrage enthalten. Andernfalls MUSS dieses Feld null sein.

IP Version (IP-Version): IP-Version dieser Adresszuweisung, codiert als vorzeichenlose 8-Bit-Ganzzahl. Sie MUSS entweder 4 oder 6 sein.

IP Address (IP-Adresse): Zugewiesene IP-Adresse. Wenn das Feld IP-Version den Wert 4 hat, MUSS das Feld IP-Adresse eine Länge von 32 Bits haben. Wenn das Feld IP-Version den Wert 6 hat, MUSS das Feld IP-Adresse eine Länge von 128 Bits haben.

IP Prefix Length (IP-Präfixlänge): Die Anzahl der Bits in der IP-Adresse, die verwendet werden, um das zugewiesene Präfix zu definieren, codiert als vorzeichenlose 8-Bit-Ganzzahl. Dies MUSS kleiner oder gleich der Länge des Feldes IP-Adresse in Bits sein. Wenn die Präfixlänge gleich der Länge der IP-Adresse ist, darf der Empfänger dieser Kapsel Pakete von einer einzigen Quelladresse senden. Wenn die Präfixlänge kleiner als die Länge der IP-Adresse ist, darf der Empfänger dieser Kapsel Pakete von einer beliebigen Quelladresse senden, die in das Präfix fällt. Wenn die Präfixlänge strikt kleiner als die Länge der IP-Adresse in Bits ist, MÜSSEN die niedrigeren Bits des Feldes IP-Adresse, die nicht von der Präfixlänge abgedeckt werden, alle auf 0 gesetzt werden.

Wenn eines der Kapselfelder beim Empfang fehlerhaft ist, MUSS der Empfänger der Kapsel das in Abschnitt 3.3 von HTTP-DGRAM definierte Fehlerbehandlungsverfahren befolgen.

Wenn eine ADDRESS_ASSIGN-Kapsel keine Adresse enthält, die zuvor in einer anderen ADDRESS_ASSIGN-Kapsel übertragen wurde, zeigt dies an, dass die Adresse entfernt wurde. Eine ADDRESS_ASSIGN-Kapsel kann auch leer sein, was anzeigt, dass alle Adressen entfernt wurden.

Bei einigen Bereitstellungen von IP-Proxying in HTTP muss einem Endpunkt von seinem Peer eine Adresse zugewiesen werden, bevor er weiß, welche Quelladresse er für seine eigenen Pakete festlegen soll. Im Fall des Remote-Access-VPN (Abschnitt 8.1) kann der Client beispielsweise keine IP-Pakete senden, bis er weiß, welche Adresse er verwenden soll. In diesen Bereitstellungen MUSS der Endpunkt, der eine Adresszuweisung erwartet, eine ADDRESS_REQUEST-Kapsel senden. Dies ist nicht erforderlich, wenn der Endpunkt keine Adresszuweisung benötigt, beispielsweise wenn er out-of-band mit statischen Adressen konfiguriert ist.

Während ADDRESS_ASSIGN-Kapseln üblicherweise als Antwort auf ADDRESS_REQUEST-Kapseln gesendet werden, KÖNNEN Endpunkte ADDRESS_ASSIGN-Kapseln unaufgefordert senden.

4.7.2. ADDRESS_REQUEST-Kapsel

Die ADDRESS_REQUEST-Kapsel (Kapseltyp 0x02) ermöglicht es einem Endpunkt, die Zuweisung von IP-Adressen von seinem Peer anzufordern. Die Kapsel ermöglicht es dem Endpunkt, optional eine Präferenz anzugeben, welche Adresse ihm zugewiesen werden soll.

ADDRESS_REQUEST Capsule {
  Type (i) = 0x02,
  Length (i),
  Requested Address (..) ...,
}

Abbildung 9: ADDRESS_REQUEST-Kapselformat

Die ADDRESS_REQUEST-Kapsel enthält eine Sequenz von einer oder mehreren angeforderten Adressen.

Requested Address {
  Request ID (i),
  IP Version (8),
  IP Address (32..128),
  IP Prefix Length (8),
}

Abbildung 10: Format der angeforderten Adresse

Jede angeforderte Adresse enthält die folgenden Felder:

Request ID (Anfrage-ID): Anfragekennung, codiert als Ganzzahl variabler Länge. Dies ist die Kennung dieser spezifischen Adressanfrage. Jede Anfrage von einem bestimmten Endpunkt trägt eine andere Kennung. Anfrage-IDs DÜRFEN NICHT von einem Endpunkt wiederverwendet werden und DÜRFEN NICHT null sein.

IP Version (IP-Version): IP-Version dieser Adressanfrage, codiert als vorzeichenlose 8-Bit-Ganzzahl. Sie MUSS entweder 4 oder 6 sein.

IP Address (IP-Adresse): Angeforderte IP-Adresse. Wenn das Feld IP-Version den Wert 4 hat, MUSS das Feld IP-Adresse eine Länge von 32 Bits haben. Wenn das Feld IP-Version den Wert 6 hat, MUSS das Feld IP-Adresse eine Länge von 128 Bits haben.

IP Prefix Length (IP-Präfixlänge): Länge des angeforderten IP-Präfixes in Bits, codiert als vorzeichenlose 8-Bit-Ganzzahl. Sie MUSS kleiner oder gleich der Länge des Feldes IP-Adresse in Bits sein. Wenn die Präfixlänge strikt kleiner als die Länge der IP-Adresse in Bits ist, MÜSSEN die niedrigeren Bits des Feldes IP-Adresse, die nicht von der Präfixlänge abgedeckt werden, alle auf 0 gesetzt werden.

Wenn die IP-Adresse nur aus Nullen besteht (0.0.0.0 oder ::), zeigt dies an, dass der Absender eine Adresse dieser Adressfamilie anfordert, aber keine Präferenz für eine bestimmte Adresse hat. In diesem Szenario zeigt die Präfixlänge immer noch die Präferenz des Absenders für die angeforderte Präfixlänge an.

Wenn eines der Kapselfelder beim Empfang fehlerhaft ist, MUSS der Empfänger der Kapsel das in Abschnitt 3.3 von HTTP-DGRAM definierte Fehlerbehandlungsverfahren befolgen.

Nach Erhalt der ADDRESS_REQUEST-Kapsel SOLLTE ein Endpunkt seinem Peer eine oder mehrere IP-Adressen zuweisen und dann mit einer ADDRESS_ASSIGN-Kapsel antworten, um den Peer über die Zuweisung zu informieren. Für jede angeforderte Adresse MUSS der Empfänger der ADDRESS_REQUEST-Kapsel mit einer zugewiesenen Adresse mit einer passenden Anfrage-ID antworten. Wenn die angeforderte Adresse zugewiesen wurde, MÜSSEN die Felder IP-Adresse und IP-Präfixlänge in der Antwort der zugewiesenen Adresse auf die zugewiesenen Werte gesetzt werden. Wenn die angeforderte Adresse nicht zugewiesen wurde, MUSS die IP-Adresse nur aus Nullen bestehen und die IP-Präfixlänge MUSS die maximale Länge (0.0.0.0/32 oder ::/128) haben, um anzuzeigen, dass keine Adresse zugewiesen wurde. Diese Adressablehnungen SOLLTEN NICHT in nachfolgenden ADDRESS_ASSIGN-Kapseln enthalten sein. Beachten Sie, dass andere Einträge für zugewiesene Adressen, die keiner Anfrage-ID entsprechen, ebenfalls in derselben ADDRESS_ASSIGN-Antwort enthalten sein können.

Wenn ein Endpunkt eine ADDRESS_REQUEST-Kapsel empfängt, die null angeforderte Adressen enthält, MUSS er den IP-Proxying-Anfragestream abbrechen.

Beachten Sie, dass die Reihenfolge der angeforderten Adressen keine Semantik trägt. Ebenso ist die Anfrage-ID nur als eindeutige Kennung gedacht; sie vermittelt keine Priorität oder Wichtigkeit.

4.7.3. ROUTE_ADVERTISEMENT-Kapsel

Die ROUTE_ADVERTISEMENT-Kapsel (Kapseltyp 0x03) ermöglicht es einem Endpunkt, seinem Peer mitzuteilen, dass er bereit ist, Datenverkehr an einen Satz von IP-Adressbereichen zu leiten. Dies zeigt an, dass der Absender eine bestehende Route zu jedem Adressbereich hat, und benachrichtigt seinen Peer, dass, wenn der Empfänger der ROUTE_ADVERTISEMENT-Kapsel IP-Pakete für einen dieser Bereiche in HTTP-Datagrammen sendet, der Absender der Kapsel diese entlang seiner bereits bestehenden Route weiterleitet. Jede Adresse, die sich in einem der Adressbereiche befindet, kann als Zieladresse für IP-Pakete verwendet werden, die vom Empfänger dieser Kapsel stammen.

ROUTE_ADVERTISEMENT Capsule {
  Type (i) = 0x03,
  Length (i),
  IP Address Range (..) ...,
}

Abbildung 11: ROUTE_ADVERTISEMENT-Kapselformat

Die ROUTE_ADVERTISEMENT-Kapsel enthält eine Sequenz von null oder mehr IP-Adressbereichen.

IP Address Range {
  IP Version (8),
  Start IP Address (32..128),
  End IP Address (32..128),
  IP Protocol (8),
}

Abbildung 12: IP-Adressbereichsformat

Jeder IP-Adressbereich enthält die folgenden Felder:

IP Version (IP-Version): IP-Version dieses Bereichs, codiert als vorzeichenlose 8-Bit-Ganzzahl. Sie MUSS entweder 4 oder 6 sein.

Start IP Address und End IP Address (Start-IP-Adresse und End-IP-Adresse): Inklusive Start- und End-IP-Adresse des angekündigten Bereichs. Wenn das Feld IP-Version den Wert 4 hat, MÜSSEN diese Felder eine Länge von 32 Bits haben. Wenn das Feld IP-Version den Wert 6 hat, MÜSSEN diese Felder eine Länge von 128 Bits haben. Die Start-IP-Adresse MUSS kleiner oder gleich der End-IP-Adresse sein.

IP Protocol (IP-Protokoll): Die Internetprotokollnummer für Datenverkehr, der an diesen Bereich gesendet werden kann, codiert als vorzeichenlose 8-Bit-Ganzzahl. Wenn der Wert 0 ist, sind alle Protokolle erlaubt. Wenn der Wert nicht 0 ist, stellt er einen zulässigen nächsten Header-Wert dar, der in IP-Headern übertragen wird, die direkt in HTTP-Datagrammen (den äußersten IP-Headern) gesendet werden. ICMP-Verkehr ist unabhängig vom Wert dieses Feldes immer erlaubt.

Wenn eines der Kapselfelder beim Empfang fehlerhaft ist, MUSS der Empfänger der Kapsel das in Abschnitt 3.3 von HTTP-DGRAM definierte Fehlerbehandlungsverfahren befolgen.

Nach Erhalt der ROUTE_ADVERTISEMENT-Kapsel KANN ein Endpunkt seinen lokalen Status bezüglich dessen, was sein Peer bereit ist zu routen (vorbehaltlich lokaler Richtlinien), aktualisieren, z. B. durch Installieren von Einträgen in einer Routingtabelle.

Jedes ROUTE_ADVERTISEMENT enthält die vollständige Liste der Adressbereiche. Wenn mehrere ROUTE_ADVERTISEMENT-Kapseln in eine Richtung gesendet werden, ersetzt jede ROUTE_ADVERTISEMENT-Kapsel die vorherigen. Mit anderen Worten, wenn ein bestimmter Adressbereich in einer früheren Kapsel vorhanden war, aber die zuletzt empfangene ROUTE_ADVERTISEMENT-Kapsel ihn nicht enthält, betrachtet der Empfänger diesen Bereich als zurückgezogen.

Wenn sich mehrere Bereiche, die dasselbe IP-Protokoll verwenden, überschneiden würden, könnten einige Routingtabellenimplementierungen diese ablehnen. Um Überschneidungen zu vermeiden, sind die Bereiche geordnet; dies bürdet dem Absender die Last auf und macht die Überprüfung durch den Empfänger viel einfacher. Wenn ein IP-Adressbereich A einem IP-Adressbereich B in derselben ROUTE_ADVERTISEMENT-Kapsel vorausgeht, MÜSSEN sie diese Anforderungen erfüllen:

• Die IP-Version von A MUSS kleiner oder gleich der IP-Version von B sein.

• Wenn die IP-Version von A und B gleich sind, MUSS das IP-Protokoll von A kleiner oder gleich dem IP-Protokoll von B sein.

• Wenn die IP-Version und das IP-Protokoll von A und B beide gleich sind, MUSS die End-IP-Adresse von A strikt kleiner sein als die Start-IP-Adresse von B.

Wenn ein Endpunkt eine ROUTE_ADVERTISEMENT-Kapsel empfängt, die diese Anforderungen nicht erfüllt, MUSS er den IP-Proxying-Anfragestream abbrechen.

Da das Setzen des IP-Protokolls auf null anzeigt, dass alle Protokolle erlaubt sind, ermöglichen die oben genannten Anforderungen, dass sich zwei Routen überschneiden, wenn eine ihr IP-Protokoll auf null und die andere es auf ungleich null gesetzt hat. Endpunkte DÜRFEN KEINE ROUTE_ADVERTISEMENT-Kapsel mit Routen senden, die sich auf diese Weise überschneiden. Die Validierung dieser Anforderung ist OPTIONAL, aber wenn ein Endpunkt den Verstoß erkennt, MUSS er den IP-Proxying-Anfragestream abbrechen.

4.8. IPv6-Erweiterungsheader

Sowohl die Bereichsbegrenzung der Anfrage (siehe Abschnitt 4.6) als auch die ROUTE_ADVERTISEMENT-Kapsel (siehe Abschnitt 4.7.3) verwenden Internetprotokollnummern. Diese Nummern repräsentieren sowohl obere Schichten (wie in Abschnitt 2 von IPv6 definiert, mit Beispielen, die TCP und UDP einschließen) als auch IPv6-Erweiterungsheader (wie in Abschnitt 4 von IPv6 definiert, mit Beispielen, die Fragment- und Optionsheader einschließen). IP-Proxys KÖNNEN Anfragen ablehnen, den Bereich auf Protokollnummern zu beschränken, die für Erweiterungsheader verwendet werden. Nach Erhalt von Paketen MÜSSEN Implementierungen, die Bereichsbegrenzung oder Routing nach Internetprotokollnummer unterstützen, die Kette von Erweiterungen durchlaufen, um die äußerste Nicht-Erweiterungs-Internetprotokollnummer zu finden, die mit der Bereichsbegrenzungsregel abgeglichen werden soll. Beachten Sie, dass die ROUTE_ADVERTISEMENT-Kapsel die Internetprotokollnummer 0 verwendet, um anzuzeigen, dass alle Protokolle erlaubt sind; sie beschränkt die Route nicht auf den IPv6-Hop-by-Hop-Optionsheader (Abschnitt 4.3 von IPv6).