5.3. Tunnel Header Field Descriptions (Descriptions des champs d'en-tête de tunnel)
5.3. Tunnel Header Field Descriptions (Descriptions des champs d'en-tête de tunnel)
Inner Header (IH, En-tête interne): L'en-tête interne est l'en-tête sur le datagramme provenant de l'hôte source. Les adresses IP source et destination sont des EIDs [RFC0791] [RFC2460].
Outer Header (OH, En-tête externe): L'en-tête externe est un nouvel en-tête préfixé par l'ITR. Les champs d'adresse contiennent des RLOCs obtenus à partir du cache EID vers RLOC du routeur d'entrée. Le numéro de protocole IP est "UDP (17)" de [RFC0768]. Le positionnement du bit Don't Fragment (DF) dans le champ Flags suit les règles énumérées dans les sections 5.4.1 et 5.4.2.
UDP Header (En-tête UDP): L'en-tête UDP contient un port source sélectionné par l'ITR lors de l'encapsulation du paquet. Voir la section 6.5 pour les détails de l'algorithme de hachage utilisé pour sélectionner un port source basé sur le 5-tuple de l'en-tête interne. Le port de destination DOIT être défini sur la valeur de port bien connue attribuée par l'IANA 4341.
UDP Checksum (Champ UDP Checksum): Pour les transmissions encapsulées IPv4 [RFC0768] ou IPv6 [UDP-TUNNELS] [UDP-ZERO], l'ITR DEVRAIT transmettre le champ UDP Checksum à zéro. Lorsque l'ETR reçoit un paquet avec une somme de contrôle UDP de zéro, l'ETR DOIT accepter le paquet pour désencapsulation. Lorsque l'ITR transmet une valeur non nulle pour la somme de contrôle UDP, il DOIT transmettre une valeur correctement calculée dans ce champ. Lorsque l'ETR reçoit un paquet avec une somme de contrôle UDP non nulle, il PEUT choisir de vérifier la valeur de la somme de contrôle. S'il choisit d'effectuer une telle vérification et que la vérification échoue, le paquet DOIT être abandonné silencieusement. Si l'ETR choisit de ne pas effectuer la vérification, ou si la vérification réussit, le paquet DOIT être accepté pour désencapsulation. Le traitement de la somme de contrôle UDP pour tous les protocoles de tunnel, y compris LISP, fait toujours l'objet de discussions actives au sein de l'IETF. Lorsque les discussions se concluront, les modifications nécessaires seront apportées pour aligner LISP sur les résultats de la discussion plus large.
UDP Length (Champ UDP Length): Pour les paquets encapsulés IPv4, le champ UDP Length est défini sur la somme de la longueur totale IPv4 interne plus les longueurs des en-têtes UDP et LISP. Pour les paquets encapsulés IPv6, le champ UDP Length est la somme de la longueur de charge utile IPv6 interne, la taille de l'en-tête IPv6 (40 octets) et les tailles des en-têtes UDP et LISP.
N: Le bit N est le bit nonce-present. Lorsque ce bit est défini sur 1, les 24 bits de poids faible des 32 premiers bits de l'en-tête LISP contiennent un nonce. Voir la section 6.3.1 pour les détails. Le bit N et le bit V ne DOIVENT PAS être définis dans le même paquet. S'ils le sont tous les deux, l'ETR désencapsulant DOIT traiter le champ Nonce/Map-Version comme ayant une valeur de nonce présente.
L: Le bit L est le bit d'activation du champ Locator-Status-Bits. Lorsque ce bit est défini sur 1, les Locator-Status-Bits dans le deuxième mot de 32 bits de l'en-tête LISP sont en cours d'utilisation.
x 1 x x 0 x x x
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N|L|E|V|I|flags| Nonce/Map-Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator-Status-Bits |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
E: Le bit E est le bit echo-nonce-request. Ce bit DOIT être ignoré et n'a aucune signification lorsque le bit N est défini sur 0. Lorsque le bit N est défini sur 1 et que ce bit est défini sur 1, l'ITR demande que la valeur du nonce dans le champ Nonce soit renvoyée en écho dans les paquets encapsulés LISP retournés lorsque l'ITR est également un ETR. Voir la section 6.3.1 pour plus de détails.
V: Le bit V est le bit Map-Version present. Lorsque ce bit est défini sur 1, le bit N DOIT être 0. Reportez-vous à la section 6.6.3 pour plus de détails. Ce bit indique que l'en-tête LISP est encodé dans ce cas comme:
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: Le bit I est le bit Instance ID. Voir la section 5.5 pour plus de détails. Lorsque ce bit est défini sur 1, le champ Locator-Status-Bits est réduit à 8 bits et les 24 bits de poids fort sont utilisés comme Instance ID. Si le bit L est 0, les 8 bits de poids faible sont transmis à zéro et ignorés à la réception. Le format de l'en-tête LISP est le suivant:
x x x x 1 x x x
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N|L|E|V|I|flags| Nonce/Map-Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Instance ID | LSBs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
flags: Le champ flags est un champ de 3 bits réservé pour les indicateurs futurs. Il DOIT être défini sur 0 en transmission et DOIT être ignoré à la réception.
LISP Nonce: Le champ LISP Nonce est une valeur de 24 bits générée aléatoirement par l'ITR lorsque le bit N est défini sur 1. L'algorithme de génération du nonce est un détail d'implémentation, mais il est nécessaire de générer des nonces différents lors de l'envoi vers des destinations différentes. Cependant, le même nonce peut être utilisé pour la même destination pendant une période de temps. Lorsque le bit E est défini sur 1, le nonce est également utilisé pour demander que la valeur du nonce soit renvoyée en écho par l'homologue lorsque les paquets sont retournés. Lorsque le bit E est effacé mais que le bit N est défini, l'ITR distant renvoie soit en écho un echo-nonce précédemment demandé, soit fournit un nonce aléatoire. Voir la section 6.3.1 pour plus de détails.
LISP Locator-Status-Bits (LSB): Lorsque le bit L est également défini, le champ Locator-Status-Bits dans l'en-tête LISP est défini par l'ITR pour informer l'ETR du statut up/down des localisateurs dans le site source. Chaque RLOC dans un Map-Reply se voit attribuer une valeur ordinale de 0 à n-1 (il y a n RLOCs dans l'entrée de mappage). Les Locator-Status-Bits sont numérotés de 0 à n-1 à partir du bit de poids le plus faible du champ. Le champ fait 32 bits lorsque le bit I est 0 et 8 bits lorsque le bit I est 1. Lorsqu'un Locator-Status-Bit est défini sur 1, l'ITR informe l'ETR que le RLOC associé à l'ordinal de ce bit est up. Voir la section 6.3 pour des détails sur la façon dont un ITR peut déterminer le statut des ETRs du même site. Lorsqu'un site dispose de plusieurs EID-Prefixes qui donnent lieu à plusieurs mappages (chacun pouvant avoir un Locator-Set différent), les Locator-Status-Bits définit dans le paquet encapsulé DOIVENT refléter le mappage pour l'EID-Prefix qui correspond à l'adresse EID source de l'en-tête interne. Si le LSB pour un localisateur anycast est défini sur 1, alors il existe au moins un RLOC avec cette adresse et l'ETR est considéré comme up.
Lors de l'encapsulation ITR/PITR:
o Le champ Time to Live de l'en-tête externe (champ Hop Limit dans le cas IPv6) DEVRAIT être copié à partir du champ Time to Live de l'en-tête interne.
o Le champ Type of Service de l'en-tête externe (champ Traffic Class dans le cas IPv6) DEVRAIT être copié à partir du champ Type of Service de l'en-tête interne (avec une exception, voir ci-dessous).
Lors de la désencapsulation ETR/PETR:
o Lorsque la valeur du Time to Live de l'en-tête externe est inférieure à la valeur du Time to Live de l'en-tête interne, le champ Time to Live de l'en-tête interne (champ Hop Limit dans le cas IPv6) DEVRAIT être copié à partir du champ Time to Live de l'en-tête externe. Si cette vérification n'est pas effectuée, le Time to Live de l'en-tête interne peut être incrémenté dans une boucle d'encapsulation/désencapsulation. Cette vérification est également effectuée lors de l'encapsulation initiale, lorsqu'un paquet arrive à un ITR ou PITR à destination d'un site LISP.
o Le champ Type of Service de l'en-tête interne (champ Traffic Class dans le cas IPv6) DEVRAIT être copié à partir du champ Type of Service de l'en-tête externe (avec une exception, voir ci-dessous).
Notez que si l'ETR/PETR est également un ITR/PITR et choisit de réencapsuler après la désencapsulation, l'effet net est que le nouvel en-tête externe portera le même Time to Live moins 1 que l'ancien en-tête externe.
La copie du Time to Live (TTL) a deux objectifs: premièrement, préserver l'intention de l'hôte quant à la distance de transmission du paquet, et deuxièmement, plus important encore, supprimer les paquets en boucle en présence de boucles de tunnel en tandem dues à des configurations erronées. Voir la section 9.3 pour le traitement exceptionnel du TTL pour les paquets traceroute.
Le champ Explicit Congestion Notification (ECN) occupe les bits 6 et 7 du champ IPv4 Type of Service et du champ IPv6 Traffic Class [RFC3168]. Le champ ECN nécessite un traitement spécial pour éviter de perdre l'indication de congestion [RFC3168]. L'encapsulation ITR DOIT copier le champ ECN de 2 bits de l'en-tête interne vers l'en-tête externe. La réencapsulation DOIT copier le champ ECN de 2 bits de l'en-tête externe supprimé vers le nouvel en-tête externe. La désencapsulation ETR DOIT copier le champ ECN de 2 bits de l'en-tête externe supprimé vers l'en-tête interne survivant utilisé pour le transfert au-delà de l'ETR si le champ ECN contient le point de code d'indication de congestion (valeur 11, c'est-à-dire le point de code Congestion Experienced (CE)). Ces exigences préservent l'indication CE lorsque des paquets ECT traversent un tunnel LISP et sont marqués avec l'indication CE en raison de la congestion entre les points de terminaison du tunnel.