Groupe de travail Réseau	S. Hanks, NetSmiths Ltd.	
Request for Comments : 1701	T. Li, D. Farinacci, P. Traina	
Catégorie : Information	cisco Systems	
Traduction Claude Brière de L'Isle	octobre 1994	

Encapsulation générique d'acheminement (GRE)

Statut de ce mémoire
Le présent mémoire apporte des informations à la communauté de l'Internet. Le présent mémoire ne spécifie aucune forme de norme de l'Internet. Sa distribution n'est soumise à aucune restriction.

Résumé
Le présent document spécifie un protocole pour effectuer l'encapsulation d'un protocole de couche réseau arbitraire sur un autre protocole de couche réseau arbitraire.

Introduction

Un certain nombre de propositions différentes [RFC1234, RFC1226] existent actuellement pour l'encapsulation d'un protocole sur un autre protocole. D'autres types d'encapsulations [RFC1241, SDRP, RFC1479] ont été proposés pour transporter IP sur IP pour des besoins de politique. Le présent mémoire décrit un protocole qui est très similaire, tout en étant plus général que les propositions ci-dessus. En essayant d'être plus général, de nombreuses nuances spécifiques d'un protocole ont été ignorées. Le résultat est que cette proposition convient moins bien à une situation où une encapsulation  spécifique de "X sur Y" a été décrite. Le présent protocole tente de fournir un mécanisme simple, d'utilisation générale qui réduise le problème de l'encapsulation de sa dimension actuelle de O(n^2) à un état plus gérable. Cette proposition tente aussi de fournir une encapsulation légère à utiliser dans les acheminements fondés sur la politique. Le présent mémoire ne s'adresse explicitement pas à la question de quand un paquet devrait être encapsulé. Le présent mémoire reconnaît sans les traiter les problèmes d'encapsulation mutuelle [RFC1326].

Dans le cas le plus général, un système a un paquet qui a besoin d'être encapsulé et acheminé. Nous appellerons cela le paquet de charge utile. La charge utile est la première encapsulée dans un paquet GRE, qui inclut éventuellement aussi un chemin. Le paquet GRE résultant peut alors être encapsulé dans un autre protocole puis transmis. Nous allons appeler ce protocole externe le protocole de livraison. Les algorithmes pour le traitement de ce paquet sont exposés plus loin.

Paquet global

Le paquet encapsulé entier va alors avoir la forme :

En-tête de livraison	
En-tête GRE	
Paquet de charge utile	

En-tête de paquet
L'en-tête du paquet GRE est de la forme :

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |C|R|K|S|s|Recur| Fanions | Ver |    Type de protocole          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Somme de contrôle (facult.)  |   Décalage (facultatif)       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Clé (facultatif)                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 Numéro de séquence (facultatif)               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                  Acheminement (facultatif) 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Fanions et version (2 octets)
Les fanions GRE sont codés dans les deux premiers octets. Le bit 0 est le bit de plus fort poids, le bit 15 est le bit de moindre poids. Les bits 13 à 15 sont réservés pour le champ Version. Les bits 5 à 12 sont réservés pour une utilisation future et DOIVENT être transmis à zéro.

Somme de contrôle présente (C, bit 0)
Si le bit Somme de contrôle présente est réglé à 1, le champ Somme de contrôle est alors présent et contient des informations valides.
Si le bit Somme de contrôle présente ou le bit Acheminement présent sont l'un ou l'autre établis (mis à 1) LES DEUX champs Somme de contrôle et Décalage sont présents dans le paquet GRE.

Acheminement présent (R, bit 1)
Si le bit Acheminement présent est réglé à 1, il indique alors que les champs Décalage et Acheminement sont présents et contiennent des informations valides.
Si le bit Somme de contrôle présente ou le bit Acheminement présent sont l'un ou l'autre établis, LES DEUX champs somme de contrôle et Décalage sont présents dans le paquet GRE.

Clé présente (K, bit 2)
Si le bit Clé présente est mis à 1, cela indique alors que le champ Clé est présent dans l'en-tête GRE. Autrement, le champ Clé n'est pas présent dans l'en-tête GRE.

Numéro de séquence présent (S, bit 3)
Si le bit Numéro de séquence présent est réglé à 1, cela indique alors que le champ Numéro de séquence est présent. Autrement, le champ Numéro de séquence n'est pas présent dans l'en-tête GRE.

Route de source stricte (s, bit 4)
La signification du bit Route de source stricte est définie dans d'autres documents. Il est recommandé que ce bit soit seulement mis à 1 si toutes les informations d'acheminement consistent en routes de source strictes.

Contrôle de récurrence (Récur, bits 5-7)
Le champ Contrôle de récurrence contient un entier non signé de trois bits qui donne le nombre d'encapsulations supplémentaires qui sont permissibles. Il DEVRAIT être à zéro par défaut.

Numéro de version (Ver, bits 13-15)
Le champ Numéro de version DOIT contenir la valeur 0. Les autres valeurs sont en dehors du domaine d'application de ce document.

Type de protocole (2 octets)
Le champ Type de protocole contient le type de protocole du paquet de charge utile. En général, la valeur sera le champ Type de protocole Ethernet pour le paquet. Les types de protocole actuellement définis sont énumérés ci-dessous. Des valeurs supplémentaires pourront être définies dans d'autres documents.

Décalage (2 octets)
Le champ Décalage indique le décalage d'octet depuis le début du champ Acheminement jusqu'au premier octet de l'entrée Route de source active à examiner. Ce champ est présent si le bit Acheminement présent ou le bit Somme de contrôle présente est réglé à 1, et il ne contient des informations valides que si le bit Acheminement présent est réglé à 1.

Somme de contrôle (2 octets)
Le champ Somme de contrôle contient la somme de contrôle IP (complément à un) de l'en-tête GRE et du paquet de charge utile. Ce champ est présent si le bit Acheminement présent ou le bit Somme de contrôle présente est réglé à 1, et il ne contient des informations valides que si le bit Somme de contrôle présente est mis à 1.

Clé (4 octets)
Le champ Clé contient un nombre de quatre octets qui a été inséré par l'encapsuleur. Il peut être utilisé par le receveur pour authentifier la source du paquet. Les techniques de détermination de l'authenticité sortent du domaine d'application de ce document. Le champ Clé n'est présent que si le champ Clé présente est réglé à 1.

Numéro de séquence (4 octets)
Le champ Numéro de séquence contient un entier non signé de 32 bits qui est inséré par l'encapsuleur. Il peut être utilisé par le receveur pour établir l'ordre dans lequel les paquets ont été transmis de l'encapsuleur au receveur. Les algorithmes exacts pour générer le numéro de séquence et la sémantique de leur réception sort du domaine d'application de ce document.

Acheminement (variable)
Le champ Acheminement est facultatif et n'est présent que si le bit Acheminement présent est réglé à 1.

Le champ Acheminement est une liste des entrées de route de source (SRE, Source Route Entry). Chaque SRE est de la forme :

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Famille d'adresse       | Décal. SRE    | Longueur SRE  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Informations d'acheminement ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Le champ Acheminement se termine par un SRE "NUL" contenant une famille d'adresse de type 0x0000 et une longueur de 0.

Famille d'adresse (2 octets)
Le champ Famille d'adresse contient une valeur de deux octets qui indique la syntaxe et la sémantique du champ Informations d'acheminement. Les valeurs pour ce champ et la syntaxe et sémantique correspondantes pour les informations d'acheminement sont définies dans d'autres documents.

Décalage de SRE (1 octet)
Le champ Décalage de SRE indique le décalage d'octet depuis le début du champ Informations d'acheminement jusqu'au premier octet de l'entrée active de l'entrée de route de source à examiner.

Longueur de SRE (1 octet)
Le champ Longueur de SRE contient le nombre d'octets du SRE. Si Longueur du SRE est 0, cela indique que c'est le dernier SRE dans le champ Acheminement.

Informations d'acheminement (variable)
Le champ Informations d'acheminement contient des données qui peuvent être utilisées dans l'acheminement de ce paquet. La sémantique exacte de ce champ est définie dans d'autres documents.

Transmission des paquets GRE

Normalement, un système qui transmet des paquets de couche livraison ne fera aucune différence entre les paquets GRE et les autres paquets. Cependant, un paquet GRE peut être reçu par un système. Dans ce cas, le système devrait utiliser des moyens spécifiques de la livraison pour déterminer qu'il s'agit d'un paquet GRE. Une fois que ceci est déterminé, les champs Clé, Numéro de séquence et Somme de contrôle peuvent être vérifiés pour voir si ils contiennent des informations valides comme indiqué par les fanions correspondants. Si le bit Acheminement présent est mis à 1, le champ Famille d'adresse devrait être vérifié pour déterminer la sémantique et l'utilisation des champs Longueur SRE, Décalage SRE et Informations d'acheminement. La sémantique exacte du traitement d'une SRE pour chaque famille d'adresse est définie dans d'autres documents.

Une fois que toutes les SRE ont été traitées, la route de source est alors complète, et l'en-tête GRE devrait être retiré, le TTL de la charge utile (s'il en existe un) DOIT être décrémenté et le paquet de charge utile devrait être transmis comme un paquet normal. La méthode exacte de transmission dépend du champ Type de protocole.

Liste des types de protocoles actuels
Les types de protocole actuellement alloués pour GRE sont les suivants. Les types de protocole futurs doivent être tirés du codage Ethernet DIX. Pour des raisons historiques, un certain nombre d'autres valeurs ont été utilisées pour certains protocoles. Le tableau des valeurs suivant DOIT être utilisé pour identifier les protocoles suivants :

Famille de protocoles	PTYPE	
Réservé	0000	
SNA	0004	
Couche réseau OSI	00FE	
PUP	0200	
XNS 	0600	
IP 	0800	
Chaos	0804	
ARP de la RFC 826	0806	
ARP de relais de trame	0808	
VINES	0BAD	
VINES Echo	0BAE	
VINES Loopback	0BAF	
DECnet (Phase IV)	6003	
Pontage Ethernet transparent	6558	
Relais de trame brut	6559	
Domaine Apollo 	8019	
Ethertalk (Appletalk)	809B	
Novell IPX	8137	
Compression TCP/IP de la RFC 1144	876B	
Systèmes IP autonomes	876C	
Secure Data	876D	
Réservé	FFFF	

Voir la liste des EtherTypes de l'IANA pour la liste complète de ces valeurs.URL = ftp://ftp.isi.edu/in-notes/iana/assignments/ethernet-numbers.

Références
[RFC1479]	M. Steenstrup, "Spécification du protocole d'acheminement inter domaines : version 1", juillet 1993. (Historique.)
[RFC1226]	B. Kantor, "Encapsulation de trames AX.25 dans le protocole Internet", mai 1991. (Expérimentale
[RFC1234]	D. Provan, "Tunnelage de trafic IPX à travers les réseaux IP", juin 1991. (Historique)
[RFC1241]	W. Woodburn et D. Mills, "Schéma pour un protocole d'encapsulation Internet v.1", juillet 1991. (Exp.)
[RFC1326]	P. Tsuchiya, "L'encapsulation mutuelle est considérée comme dangereuse", mai 1992. (Information)
SDRP	Estrin, D., Li, T., Y. Rekhter, "Source Demand Routing Protocol Specification (Version 1)", Travail en cours.
[RFC1702]	S. Hanks, T. Li, D. Farinacci et P. Traina, "Encapsulation générique d'acheminement sur réseaux IPv4", octobre 1994. (Info.)

Considérations pour la sécurité

Les questions de sécurité ne sont pas abordées dans le présent mémoire.

Remerciements

Les auteurs tiennent à remercier Yakov Rekhter (IBM) et Deborah Estrin (USC) pour leurs avis, encouragements et précieux commentaires.

Adresse des auteurs

Stan Hanks	Tony Li	Dino Farinacci	Paul Traina	
NetSmiths, Ltd.	cisco Systems, Inc.	cisco Systems, Inc.	cisco Systems, Inc.	
2025 Lincoln Highway	1525 O'Brien Drive	1525 O'Brien Drive	1525 O'Brien Drive	
Edison NJ, 08817	Menlo Park, CA 94025	Menlo Park, CA 94025	Menlo Park, CA 94025	
mél : stan@netsmiths.com	mél : tli@cisco.com	mél : dino@cisco.com	mél : pst@cisco.com