5.3. Tunnel Header Field Descriptions (Tunnel-Header-Feldbeschreibungen)

Inner Header (IH, Innerer Header): Der innere Header ist der Header auf dem Datagramm, das vom ursprünglichen Host empfangen wurde. Die Quell- und Ziel-IP-Adressen sind EIDs [RFC0791] [RFC2460].

Outer Header (OH, Äußerer Header): Der äußere Header ist ein neuer Header, der von einem ITR vorangestellt wird. Die Adressfelder enthalten RLOCs, die aus dem EID-zu-RLOC-Cache des Eingangsrouters erhalten wurden. Die IP-Protokollnummer ist "UDP (17)" aus [RFC0768]. Die Einstellung des Don't Fragment (DF)-Bits im Flags-Feld erfolgt gemäß den in den Abschnitten 5.4.1 und 5.4.2 aufgeführten Regeln.

UDP Header (UDP-Header): Der UDP-Header enthält einen vom ITR ausgewählten Quellport beim Kapseln eines Pakets. Siehe Abschnitt 6.5 für Details zum Hash-Algorithmus, der verwendet wird, um einen Quellport basierend auf dem 5-Tupel des inneren Headers auszuwählen. Der Zielport MUSS auf den bekannten von IANA zugewiesenen Portwert 4341 gesetzt werden.

UDP Checksum (UDP Checksum-Feld): Das UDP Checksum-Feld SOLLTE von einem ITR als Null übertragen werden, entweder für IPv4 [RFC0768]- oder IPv6-Kapselung [UDP-TUNNELS] [UDP-ZERO]. Wenn ein Paket mit einer Null-UDP-Prüfsumme von einem ETR empfangen wird, MUSS der ETR das Paket zur Entkapselung akzeptieren. Wenn ein ITR einen Nicht-Null-Wert für die UDP-Prüfsumme überträgt, MUSS er einen korrekt berechneten Wert in diesem Feld senden. Wenn ein ETR ein Paket mit einer Nicht-Null-UDP-Prüfsumme empfängt, KANN er wählen, den Prüfsummenwert zu verifizieren. Wenn er sich entscheidet, eine solche Verifizierung durchzuführen, und die Verifizierung fehlschlägt, MUSS das Paket stillschweigend verworfen werden. Wenn der ETR sich entscheidet, die Verifizierung nicht durchzuführen, oder die Verifizierung erfolgreich durchführt, MUSS das Paket zur Entkapselung akzeptiert werden. Die Handhabung von UDP-Prüfsummen für alle Tunneling-Protokolle, einschließlich LISP, wird innerhalb der IETF aktiv diskutiert. Wenn diese Diskussion abgeschlossen ist, werden alle notwendigen Änderungen vorgenommen, um LISP mit dem Ergebnis der breiteren Diskussion in Einklang zu bringen.

UDP Length (UDP Length-Feld): Das UDP Length-Feld wird für ein IPv4-gekapseltes Paket auf die Summe der inneren Header-IPv4-Gesamtlänge plus UDP- und LISP-Header-Längen gesetzt. Für ein IPv6-gekapseltes Paket ist das UDP Length-Feld die Summe der inneren Header-IPv6-Payload-Länge, der Größe des IPv6-Headers (40 Oktette) und der Größe der UDP- und LISP-Header.

N: Das N-Bit ist das Nonce-Present-Bit. Wenn dieses Bit auf 1 gesetzt ist, enthalten die niederwertigen 24 Bits der ersten 32 Bits des LISP-Headers eine Nonce. Siehe Abschnitt 6.3.1 für Details. Sowohl N- als auch V-Bits DÜRFEN NICHT im selben Paket gesetzt werden. Wenn sie es sind, MUSS ein entkapselnder ETR das Nonce/Map-Version-Feld so behandeln, als ob ein Nonce-Wert vorhanden wäre.

L: Das L-Bit ist das Locator-Status-Bits-Feld-Aktivierungsbit. Wenn dieses Bit auf 1 gesetzt ist, sind die Locator-Status-Bits in den zweiten 32 Bits des LISP-Headers in Verwendung.

    x 1 x x 0 x x x
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |N|L|E|V|I|flags|            Nonce/Map-Version                  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                      Locator-Status-Bits                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

E: Das E-Bit ist das Echo-Nonce-Request-Bit. Dieses Bit MUSS ignoriert werden und hat keine Bedeutung, wenn das N-Bit auf 0 gesetzt ist. Wenn das N-Bit auf 1 und dieses Bit auf 1 gesetzt ist, fordert ein ITR an, dass der Nonce-Wert im Nonce-Feld in LISP-gekapselten Paketen zurück-ge-echot wird, wenn der ITR auch ein ETR ist. Siehe Abschnitt 6.3.1 für Details.

V: Das V-Bit ist das Map-Version-Present-Bit. Wenn dieses Bit auf 1 gesetzt ist, MUSS das N-Bit 0 sein. Siehe Abschnitt 6.6.3 für weitere Details. Dieses Bit zeigt an, dass der LISP-Header in diesem Fall wie folgt kodiert ist:

    0 x 0 1 x x x x
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |N|L|E|V|I|flags|  Source Map-Version   |   Dest Map-Version    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                 Instance ID/Locator-Status-Bits               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

I: Das I-Bit ist das Instance-ID-Bit. Siehe Abschnitt 5.5 für weitere Details. Wenn dieses Bit auf 1 gesetzt ist, wird das Locator-Status-Bits-Feld auf 8 Bits reduziert, und die hochwertigsten 24 Bits werden als Instance-ID verwendet. Wenn das L-Bit auf 0 gesetzt ist, werden die niederwertigen 8 Bits als Null übertragen und beim Empfang ignoriert. Das Format des LISP-Headers würde folgendermaßen aussehen:

    x x x x 1 x x x
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |N|L|E|V|I|flags|            Nonce/Map-Version                  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                 Instance ID                   |     LSBs      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

flags: Das flags-Feld ist ein 3-Bit-Feld, das für zukünftige Flag-Verwendung reserviert ist. Es MUSS beim Senden auf 0 gesetzt werden und MUSS beim Empfang ignoriert werden.

LISP Nonce: Das LISP-Nonce-Feld ist ein 24-Bit-Wert, der von einem ITR zufällig generiert wird, wenn das N-Bit auf 1 gesetzt ist. Nonce-Generierungsalgorithmen sind eine Implementierungsfrage, müssen jedoch unterschiedliche Nonces generieren, wenn an unterschiedliche Ziele gesendet wird. Jedoch kann für einen Zeitraum dieselbe Nonce für dasselbe Ziel verwendet werden. Die Nonce wird auch verwendet, wenn das E-Bit gesetzt ist, um anzufordern, dass der Nonce-Wert von der anderen Seite zurück-ge-echot wird, wenn Pakete zurückgegeben werden. Wenn das E-Bit gelöscht, aber das N-Bit gesetzt ist, echot ein entfernter ITR entweder eine zuvor angeforderte Echo-Nonce oder liefert eine zufällige Nonce. Siehe Abschnitt 6.3.1 für weitere Details.

LISP Locator-Status-Bits (LSBs): Wenn das L-Bit ebenfalls gesetzt ist, wird das Locator-Status-Bits-Feld im LISP-Header von einem ITR gesetzt, um einem ETR den Auf/Ab-Status der Lokatoren an der Quell-Site anzuzeigen. Jedem RLOC in einer Map-Reply wird ein Ordinalwert von 0 bis n-1 zugewiesen (wenn es n RLOCs in einem Zuordnungseintrag gibt). Die Locator-Status-Bits sind von 0 bis n-1 vom niedrigstwertigen Bit des Feldes nummeriert. Das Feld ist 32 Bits, wenn das I-Bit auf 0 gesetzt ist, und 8 Bits, wenn das I-Bit auf 1 gesetzt ist. Wenn ein Locator-Status-Bit auf 1 gesetzt ist, zeigt der ITR dem ETR an, dass der mit der Bit-Ordinalzahl verbundene RLOC den Status "up" hat. Siehe Abschnitt 6.3 für Details, wie ein ITR den Status der ETRs an derselben Site bestimmen kann. Wenn eine Site mehrere EID-Präfixe hat, die zu mehreren Zuordnungen führen (wobei jede einen anderen Locator-Set haben könnte), MUSS die Locator-Status-Bits-Einstellung in einem gekapselten Paket die Zuordnung für das EID-Präfix widerspiegeln, mit dem die innere Header-Quell-EID-Adresse übereinstimmt. Wenn das LSB für einen Anycast-Lokator auf 1 gesetzt ist, dann gibt es mindestens einen RLOC mit dieser Adresse, und der ETR wird als "up" betrachtet.

Beim Durchführen von ITR/PITR-Kapselung:

Das Time to Live-Feld des äußeren Headers (oder Hop Limit-Feld im Fall von IPv6) SOLLTE aus dem Time to Live-Feld des inneren Headers kopiert werden.
Das Type of Service-Feld des äußeren Headers (oder das Traffic Class-Feld im Fall von IPv6) SOLLTE aus dem Type of Service-Feld des inneren Headers kopiert werden (mit einer Ausnahme; siehe unten).

Beim Durchführen von ETR/PETR-Entkapselung:

Das Time to Live-Feld des inneren Headers (oder Hop Limit-Feld im Fall von IPv6) SOLLTE aus dem Time to Live-Feld des äußeren Headers kopiert werden, wenn der Time to Live-Wert des äußeren Headers kleiner ist als der Time to Live-Wert des inneren Headers. Wenn diese Prüfung nicht durchgeführt wird, kann dies dazu führen, dass die Time to Live des inneren Headers über Kapselungs-/Entkapselungszyklen inkrementiert wird. Diese Prüfung wird auch bei der anfänglichen Kapselung durchgeführt, wenn ein Paket zu einem ITR oder PITR kommt, das für eine LISP-Site bestimmt ist.
Das Type of Service-Feld des inneren Headers (oder das Traffic Class-Feld im Fall von IPv6) SOLLTE aus dem Type of Service-Feld des äußeren Headers kopiert werden (mit einer Ausnahme; siehe unten).

Beachten Sie, dass, wenn ein ETR/PETR auch ein ITR/PITR ist und sich entscheidet, nach dem Entkapseln erneut zu kapseln, der Nettoeffekt darin besteht, dass der neue äußere Header dieselbe Time to Live wie der alte äußere Header minus 1 trägt.

Das Kopieren der Time to Live (TTL) dient zwei Zwecken: Erstens bewahrt es die Entfernung, die der Host für die Übertragung des Pakets vorgesehen hatte; zweitens und wichtiger noch, sorgt es für die Unterdrückung von Schleifenpaketen im Falle einer Schleife von verketteten Tunneln aufgrund von Fehlkonfiguration. Siehe Abschnitt 9.3 für TTL-Ausnahmebehandlung bei Traceroute-Paketen.

Das Explicit Congestion Notification (ECN)-Feld belegt die Bits 6 und 7 sowohl des IPv4-Type of Service-Feldes als auch des IPv6-Traffic Class-Feldes [RFC3168]. Das ECN-Feld erfordert eine spezielle Behandlung, um das Verwerfen von Überlastungsanzeigen zu vermeiden [RFC3168]. ITR-Kapselung MUSS das 2-Bit-ECN-Feld vom inneren Header zum äußeren Header kopieren. Wieder-Kapselung MUSS das 2-Bit-ECN-Feld vom entfernten äußeren Header zum neuen äußeren Header kopieren. Wenn das ECN-Feld einen Congestion-Indication-Codepoint enthält (der Wert ist '11', der Congestion Experienced (CE)-Codepoint), dann MUSS die ETR-Entkapselung das 2-Bit-ECN-Feld vom entfernten äußeren Header zum überlebenden inneren Header kopieren, der zum Weiterleiten des Pakets über den ETR hinaus verwendet wird. Diese Anforderungen bewahren CE-Anzeigen, wenn ein Paket, das ECN verwendet, einen LISP-Tunnel durchquert und aufgrund von Überlastung zwischen den Tunnel-Endpunkten mit einer CE-Anzeige markiert wird.

5.3. Tunnel Header Field Descriptions (Tunnel-Header-Feldbeschreibungen)​

5.3. Tunnel Header Field Descriptions (Tunnel-Header-Feldbeschreibungen)