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

Statut de ce mémoire

Ce document spécifie un protocole de suivi des normes Internet pour la communauté Internet, et nécessite des discussions et suggestions pour ses améliorations. Veuillez vous référer à l'édition courante du "Internet Official Protocol Standards" (STD 1) pour l'état de normalisation et le statut de ce protocole. La distribution de cette note est illimitée.

Copyright

Copyright (C) The Internet Society (2000). Tous droits réservés.

Résumé

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

1.   Introduction

Il existe actuellement différentes propositions [RFC1234, RFC1226] pour l'encapsulation d'un protocole sur un autre protocole. D'autre types d'encapsulations [RFC1241, RFC1479] ont été proposés pour transporter IP sur IP pour les besoins d'une politique. Le présent mémoire décrit un protocole qui est très semblable, mais plus général, que les propositions ci-dessus. En essayant d'être plus généraux, de nombreuses nuances spécifiques d'un protocole ont été ignorées. Le résultat est que cette proposition peut moins bien convenir pour une situation où une encapsulation spécifique "X sur Y" a été décrite. L'essai du présent protocole est de fournit un mécanisme simple, de portée générale, qui réduise le problème de l'encapsulation de sa taille actuelle O(n^2) à une taille plus gérable. Le présent mémoire ne traite pas, de propos délibéré, la question de savoir quand un paquet devrait être encapsulé. Le présent mémoire tient compte, mais n'en traite pas, de problèmes comme l'encapsulation mutuelle [RFC1326].

Dans le cas le plus général, un système a un paquet qui a besoin d'être encapsulé et livré à une certaine destination. On va appeler cela le paquet de charge utile. La charge utile est d'abord encapsulée dans un paquet GRE. Le paquet GRE résultant peut alors être encapsulé qans quelque autre protocole puis transmis. Nous appelons ce protocole "protocole de livraison". Les algorithmes pour traiter ce paquet seront discutés plus loin.

Enfin, la présente spécification décrit l'intersection des GRE actuellement déployés par plusieurs fabricants.

Les mots clés "DOIT", "NE DOIT PAS", "DEVRAIT", "NE DEVRAIT PAS", et "PEUT" du présent document doivent être interprétés tel que défini dans la RFC 2119 [RFC2119].

2.   Structure d'un paquet encapsulé GRE

Un paquet encapsulé GRE est de la forme :

La présente spécification s'occupe d'une façon générale de la structure de l'en-tête GRE, bien qu'une considération particulière soit apportée à certaines des questions qui entourent les charges utiles IPv4.

2.1   En-tête GRE

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

2.2   Checksum Present (bit 0)

Si le bit Checksum Present est mis à un, les champs Somme de contrôle et Reserved1 sont présents et le champ Somme de contrôle contient des informations valides. Noter qu'une mise en œuvre conforme DOIT accepter et traiter ce champ.

2.3   Reserved0 (bits 1-12)

Un receveur DOIT éliminer un paquet où un des bits 1 à 5 n'est pas à zéro, sauf si ce receveur met en œuvre la RFC 1701. Les bits 6 à 12 sont réservés pour une utilisation future. Ces bits DOIVENT être envoyés à zéro et DOIVENT être ignorés à réception.

2.3.1   Numéro de version (bits 13 à 15)

Le champ Numéro de version DOIT contenir la valeur zéro.

2.4   Type de protocole (2 octets)

Le champ Type de protocole contient le type du protocole du paquet de charge utile. Ces types de protocoles sont définis dans la [RFC1700] comme "ETHER TYPES" et dans [ETYPES]. Une mise en œuvre qui reçoit un paquet contenant un type de protocole qui ne figure pas sur la liste de la [RFC1700] ou [ETYPES] DEVRAIT éliminer le paquet.

2.5   Somme de contrôle (2 octets)

Le champ Somme de contrôle contient la somme de contrôle IP (complément à un) de tous les mots de 16 bits de l'en-tête GRE et du paquet de charge utile. Pour les besoins du calcul de la somme de contrôle, la valeur du champ Somme de contrôle est zéro. Ce champ n'est présent que si le bit Checksum Present est mis à un.

2.6   Reserved1 (2 octets)

Le champ Reserved1 est réservé pour une utilisation future, et s'il est présent, DOIT être transmis comme zéro. Le champ Reserved1 n'est présent que lorsque le champ Somme de contrôle est présent (c'est-à-dire si le bit Checksum Present est mis à un).

3.   IPv4 comme charge utile

Lorsque IPv4 est transporté comme charge utile GRE, le champ Type de protocole DOIT être réglé à 0x800.

3.1   Transmission de paquets de charge utile IPv4 décapsulés

Lorsqu'un point d'extrémité de tunnel désencapsule un paquet GRE qui a un paquet IPv4 comme charge utile, l'adresse de destination dans l'en-tête de paquet de charge utile IPv4 DOIT être utilisée pour transmettre le paquet et le TTL du paquet de charge utile DOIT être décrémenté. Il faut faire attention en transmettant un tel paquet, car si l'adresse de destination du paquet de charge utile est l'encapsuleur du paquet (c'est-à-dire, l'autre extrémité du tunnel), une boucle peut survenir. Dans ce cas, le paquet DOIT être éliminé.

4.   IPv4 comme protocole de livraison

Le protocole IPv4 47 [RFC1700] est utilisé lorsque des paquets GRE sont encapsulés dans IPv4. Voir dans la [RFC1122] les exigences se rapportant à la livraison des paquets sur les réseaux IPv4.

5.   Interopération avec les mises en œuvre conformes à la RFC 1701

Dans la RFC 1701, le champ décrit ici comme Reserved0 contenait un certain nombre de bits fanions que la présente spécification déconseille. En particulier, les bits Routing Present, Key Present, Sequence Number Present, et Strict Source Route ont été déconseillés, ainsi que le champ Recursion Control. Il en résulte que l'en-tête GRE ne devra jamais contenir les champs Clé, Numéro de séquence ou Acheminement spécifiés dans la RFC 1701.

Il y a cependant des mises en œuvre existantes de la RFC 1701. Les paragraphes suivants décrivent l'interopération correcte avec de telles mises en œuvre.

5.1   Receveurs conformes à la RFC 1701

Une mise en œuvre conforme à la présente spécification transmettra le champ Reserved0 réglé à zéro. Un receveur conforme à la RFC 1701 va interpréter cela comme ayant les bits Routing Present, Key Present, Sequence Number Present, et Strict Source Route réglés à zéro, et n'attendra pas la présence des champs Clé, Numéro de séquence ou Acheminement de la RFC 1701.

5.2   Émetteur conforme à la RFC 1701

Un émetteur conforme à la RFC 1701 peut régler à un n'importe lequel des bits Routing Present, Key Present, Sequence Number Present, et Strict Source Route, et peut donc transmettre les champs Clé, Numéro de séquence ou Acheminement de la RFC 1701 dans l'en-tête GRE. Comme indiqué au paragraphe 5.3, un paquet avec des bits qui ne sont pas à zéro dans la plage 1 à 5 DOIT être éliminé sauf si le receveur met en œuvre la RFC 1701.

6.   Considérations pour la sécurité

Dans un réseau utilisant GRE, la sécurité devrait être assez semblable à celle d'un réseau IPv4 normale, car l'acheminement utilisant GRE suit le même acheminement que celui qu'IPv4 utilise normalement. Le filtrage des chemins va rester inchangé. Cependant le filtrage des paquets exige soit qu'un pare-feu regarde à l'intérieur du paquet GRE, soit que le filtrage soit fait aux points d'extrémité du tunnel GRE. Dans les environnements dans lesquels ceci pose un problème de sécurité il peut être souhaitable de terminer le tunnel au pare-feu.

7.   Considérations relatives à l'IANA

Cette section considère l'allocation de numéros de version GRE et de types de protocoles supplémentaires.

7.1   Numéros de version GRE

Le présent document spécifie le numéro de version GRE 0. Le numéro de version GRE 1 est utilisé par PPTP [RFC2637]. Des numéros de version GRE supplémentaires seront alloués par consensus de l'IETF comme défini dans la RFC 2434 [RFC2434].

7.2   Types de protocoles

GRE utilise un ETHER Type comme type de protocole. Les nouveaux ETHER TYPES sont alloués par Xerox Systems Institute [RFC1700].

8.   Remerciements

le présent document est dérivé des idées originales des auteurs de la RFC 1701 et de la RFC 1702. Hitoshi Asaeda, Scott Bradner, Randy Bush, Brian Carpenter, Bill Fenner, Andy Malis, Thomas Narten, Dave Thaler, Tim Gleeson et quelques autres ont fourni beaucoup de commentaires constructifs et pertinents.

9.   Appendice – Problèmes connus

Le présent document spécifie le comportement des mises en œuvre GRE actuellement développées. Comme tel, il n'essaye pas de régler les problèmes connus suivants :

o   Interaction de découverte de MTU de chemin (PMTU) [RFC1191]

Les mises en œuvre existantes de GRE, lorsqu'elles utilisent IPv4 comme en-tête de livraison, ne mettent pas en œuvre la découverte de MTU de chemin et ne mettent pas à un le bit Ne pas fragmenter dans l'en-tête de livraison. Cela peut causer la fragmentation de grands paquets au sein du tunnel et leur réassemblage à la sortie du tunnel (indépendamment de fait que le paquet de charge utile utilise la PMTU). Si cependant un point d'entrée de tunnel devait utiliser la découverte de MTU de chemin, ce point d'entrée de tunnel aurait aussi besoin de relayer les messages d'erreur injoignable ICMP (en particulier le code "fragmentation nécessaire et DF mis") vers l'origine du paquet, ce qui n'est pas exigé par la présente spécification. L'échec à relayer correctement les informations de MTU de chemin jusqu'à l'origine peut résulter en le comportement suivant : l'origine établit le bit Ne pas fragmenter, le paquet est abandonné dans le tunnel, mais comme l'origine ne reçoit pas de retour approprié, il le retransmet avec la même PMTU, causant l'abandon des paquets transmis à la suite.

o   IPv6 comme protocole de livraison et/ou charge utile

La présente spécification décrit l'intersection du GRE actuellement présente par plusieurs fabricants. IPv6 comme protocole de livraison et/ou charge utile n'est pas inclus dans les versions de GRE actuellement mises sur le marché

o   Interaction avec ICMP

o   Interaction avec l'architecture de services différenciés (Diffserv)

o   Encapsulations multiples et bouclage.

10.   Références

[ETYPES]   ftp://ftp.isi.edu/in-notes/iana/assignments/ethernet-numbers

[RFC1122]   R. Braden, "Exigences pour les hôtes Internet – couches de communication", STD 3, RFC 1122, octobre 1989. (Mise à jour par les RFC 1349 et 4379)

[RFC1191]   J. Mogul et S. Deering, "Découverte de ma MTU de chemin", RFC 1191, novembre 1990.

[RFC1226]   B. Kantor, "Encapsulation de trames AX.25 dans le protocole Internet", RFC 1226, mai 1991.

[RFC1234]   D. Provan, "Tunnelage de trafic IPX à travers les réseaux IP", RFC 1234, juin 1991. (Historique)

[RFC1241]   R. Woodburn et D. Mills, "Schéma pour un protocole d'encapsulation Internet : version 1", RFC 1241, juillet 1991.

[RFC1326]   P. Tsuchiya, "L'encapsulation mutuelle est considérée comme dangereuse", RFC 1326, mai 1992.

[RFC1479]   M. Steenstrup, "Spécification du protocole d'acheminement inter domaines : version 1", RFC 1479, juillet 1993. (Historique)

[RFC1700]   J. Reynolds et J. Postel, "Numéros alloués", STD 2, RFC 1700, octobre 1994. (Historique)

[RFC1701]   S. Hanks, T. Li, D. Farinacci et P. Traina, "Encapsulation générique d'acheminement", RFC 1701, octobre 1994.

[RFC1702]   S. Hanks, T. Li, D. Farinacci et P. Traina, "Encapsulation générique d'acheminement sur réseaux IPv4", RFC 1702, octobre 1994.

[RFC2119]   S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, RFC 2119, mars 1997.

[RFC2408]   D. Maughan, M. Schertler, M. Schneider et J. Turner, "Association de sécurité Internet et protocole de gestion de clés (ISAKMP)", RFC 2408, novembre 1998. (Rendue obsolète par la RFC 4306)

[RFC2434]   T. Narten et H. Alvestrand, "Lignes directrices pour la rédaction d'une section Considérations relatives à l'IANA dans les RFC", BCP 26, RFC 2434, octobre, 1998. (Rendue obsolète par la RFC 5226)

[RFC2637]   K. Hamzeh et autres, "Protocole de tunnelage point à point (PPTP)", RFC 2637, juillet, 1999.

11.   Adresse des auteurs

12.   Déclaration complète de droits de reproduction

Copyright (C) The Internet Society (2000). Tous droits réservés.

Ce document et les traductions de celui-ci peuvent être copiés et diffusés, et les travaux dérivés qui commentent ou expliquent autrement ou aident à sa mise en œuvre peuvent être préparés, copiés, publiés et distribués, partiellement ou en totalité, sans restriction d'aucune sorte, à condition que l'avis de copyright ci-dessus et ce paragraphe soit inclus sur toutes ces copies et œuvres dérivées. Toutefois, ce document lui-même ne peut être modifié en aucune façon, par exemple en supprimant le droit d'auteur ou les références à l'Internet Society ou d'autres organisations Internet, sauf si c'est nécessaire à l'élaboration des normes Internet, auquel cas les procédures pour les copyrights définis dans les processus de normes pour Internet doivent être suivies, ou si nécessaire pour le traduire dans des langues autres que l'anglais.

Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Société Internet ou ses successeurs ou ayants droit.

Ce document et les renseignements qu'il contient sont fournis "TELS QUELS" et L'INTERNET SOCIETY ET L'INTERNET ENGINEERING TASK FORCE DÉCLINE TOUTE GARANTIE, EXPRESSE OU IMPLICITE, Y COMPRIS MAIS SANS S'Y LIMITER, TOUTE GARANTIE QUE L'UTILISATION DE L'INFORMATION ICI PRÉSENTE N'ENFREINDRA AUCUN DROIT OU AUCUNE GARANTIE IMPLICITE DE COMMERCIALISATION OU D'ADAPTATION A UN OBJET PARTICULIER.

Remerciement

Le financement de la fonction d'éditeur des RFC est actuellement fourni pat la Internet Society.