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