RFC 1234

Auteur: D. Provan, Novell Inc. 06/1991

Traduction : Franck "Linuxshell" Verrot 03/2002

Révisée par Claude Brière de L’Isle 06/2008

------------------------------------------------------------------------------

Tunnelage de trafic IPX sur un réseau IP

Note du traducteur
==============

Ce document est une traduction non-officielle de la RFC 1234 sur le tunnelage de trafic IPX à travers les réseaux IP.

L'auteur de cette traduction décline toute responsabilité sur l'utilisation de ce document et/ou sur d'éventuelles erreurs de traduction. Concernant les droits du traducteur : le traducteur renonce à ses droits sur la reproduction de ce document si l'ensemble de ces conditions est respecté : les reproductions doivent être complètes (contenant cette note), d'un seul tenant (un seul fichier ou un ensemble de pages physiquement reliées), sans aucune modification du contenu et réalisées à partir de la dernière version de ce document disponible ici ou bien en envoyant un message au traducteur.

A noter, et l'information est importante, que les licenses sont traduites, procurez-vous la RFC officielle pour les versions originales.

Statut de ce document
================

Ce document dérit une méthode d'encapsulation de datagrammes IP à l'intérieur de paquets UPD afin que le trafic IPX puisse voyager à travers un réseau internet IP. Cette RFC spécifie un protocole en cours de normalisation par IAB pour la communauté Internet, et appelle à discussions et suggestions pour son amélioration. Veuillez vous référer à l'édition actuelle de "IAB Official Protocol Standards" pour l'état de la normalisation et le statut de ce protocole.

La distribution de ce document n’est soumise à aucune restriction.

Introduction
=========

Le protocole d'échange de paquets sur Internet (Internet Packet eXchange ou IPX) est le protocole inter-réseau utilisé par la suite de protocoles NetWare de Novell. Pour les besoins de ce document, IPX est équivalent onctionnellement au protocole des datagrammes Internet (IDP, Internet Datagram Protocol) tiré de la suite de protocoles Xerox Network Systems[1]. Ce document décrit une méthode d'encapsulation de datagrammes IPX à l'intérieur de paquets UDP [2] afin que le trafic UDP puisse voyager à travers un réseau internet IP [3].

Cette RFC permet à une mise en œuvre IPX de voir un internet IP comme un simple réseau IPX. Une mise en œuvre de ce mémo encapsulera des datagrammes IPX dans des paquets UDP de la même manière que toute mise en œuvre physique encapsulerait des datagrammes IPX dans les trames de ce matériel. Des réseaux d'IPX peuvent donc être connectés ensemble à travers des internets qui portent uniquement du trafic IP.

Format de paquet
=============

Chaque datagramme IPX est porté dans la portion des données(data portion) d'un paquet UDP. Tous les champs IP et UDP sont initialisés normalement. Les ports de source et destination du paquet UDP doivent tous deux être initialisés à la valeur du port UDP allouée par l’Autorité d'allocation des numéros de l’Internet (Internet Assigned Numbers Authority) pour la mise en œuvre de cette méthode d'encapsulation.

Comme avec toute application UDP, la partie qui émet a l'option d'éviter la surcharge des sommes de contrôle en mettant la somme de contrôle UDP à zéro. Comme les mises en œuvre IPX n'utilisent jamais la somme de contrôle UDP afin de préserver les paquets IPX des dommages, l’utilisation de la somme de contrôle UDP est vivement recommandée pour l'encapsulation IPX.

Figure 1 : Paquet IPX porté comme données dans un paquet UDP.

Paquets réservés
=============

Les deux premiers octets de l'en-tête IPX contiennent la somme de contrôle IPX.

Les paquets IPX ne sont jamais envoyés avec une somme de contrôle, donc chaque en-tête IPX commence par deux octets de FF en héxadécimal. Les mises en œuvre de ce schéma d'encapsulation doivent ignorer les paquets avec n'importe quelle autre valeur dans les deux premiers octets suivant immédiatement l'en-tête UDP.

Les autres valeurs sont réservées pour des améliorations éventuelles futures de ce protocole d'encapsulation.

Transposition d'adresse en envoi individuel
================================

Les adresses IPX sont formées d'un numéro réseau de 4 octets et d’un numéro d'hôte de 6 octets. IPX utilise le numéro de réseau pour acheminer chaque paquet à travers l'internet IPX jusqu’au réseau de destination. Une fois que le paquet arrive au réseau de destination, IPX utilise les six octets du numéro d'hôte de 6 octets comme adresse de matériel sur ce réseau.

Les numéros d'hôte sont également échangés dans les en-têtes IPX des paquets du protocole de routage d'information IPX("IPX Routing Information Protocol" ou également RIP). Cela fournit aux nœuds d’extrémité aussi bien qu’aux routeurs les informations d'adresse matériel requises pour transmettre les paquets à travers les réseaux intermédiaires sur le chemin des réseaux de destination.

Pour la mise en œuvre de ce document, les deux premiers octets du numéro d'hôte seront toujours mis à zéro et les quatre derniers octets seront toujours les quatre octets de l'adresse IP du nœud. Cela rend la transposition d'adresse triviale pour des transmissions en envoi individuel : les deux premiers numéros d'hôte sont abandonnés, laissant place à une adresse IP normale de quatre octets. Le code d'encapsulation devrait utiliser cette adresse IP comme adresse de destination du tunnel de paquet UPD/IP.

Diffusions entre serveurs homologues
============================

IPX requiert des facilités de diffusion de sorte que les serveurs NetWare et les routeurs IPX partageant un réseau puissent se retrouver les uns les autres. Comme la diffusion IP sur tout l'Internet n'est ni appropriée ni disponible, d'autres mécanismes sont requis. Pour ce document, chaque serveur et routeur doit entretenir une liste des adresses IP des autres serveur IPX et routeurs sur l'internet IP. Je me réfèrerai à cette liste sous le nom de "liste des homologues"("peer list"), aux membres individuels comme "homologues", et à tous les homologues pris ensemble, incluant le nœud local, comme le "groupe des homologues". Quand IPX demande une diffusion, la mise en œuvre de l'encapsulation simule la diffusion en transmettant un paquet en envoi individuel séparé à chaque homologue dans la liste des homologues.

Du fait que chaque liste des homologues est construite à la main, plusieurs groupes d’homologues peuvent partager le même internet IP sans rien savoir sur les autres. Cela diffère d'un réseau IPX normal où tous les clients se trouveraient les uns les autres automatiquement en utlisant les facilités de diffusion du matériel.

La liste des homologues à chaque nœud devrait contenir tous les autres homologues dans le groupe des homologues. Dans la plupart des cas, la connectivité souffrira si les diffusions d'un homologue échouent systématiquement à joindre un autre homologue dans le groupe.

La liste des homologues pourrait être mise en œuvre en utilisant la diffusion groupée IP [4], mais comme les facilités de diffusion groupée ne sont pas largement disponibles à l’heure actuelle, aucune adresse de diffusion groupée bien connue n'a été allouée et aucune mise en œuvre utilisant la diffusion groupée n'existe. Comme la diffusion groupée IP est déployée dans les mises en œuvre IP, elle peut être utilisée en incluant simplement dans la liste des homologues une adresse IP en diffusion groupée pour les serveurs IPX et les routeurs. L'adresse IP en diffusion groupée devra remplacer les adresses IP de tous les homologues qui recevront les paquets IP en diffusion groupée envoyés depuis cet homologue.

Diffusions par les clients
==================

Typiquement, les nœuds client NetWare n'ont pas besoin de recevoir de diffusions, donc normalemment un nœud client NetWare sur un internet IP ne nécessitera pas d'être inclus dans les listes d’homologues sur les serveurs.

D'un autre côté, les clients sur un réseau IPX ont besoin d'envoyer des diffusions de manière à localiser les serveurs et découvrir des routes. Une mise en œuvre client d'encapsulation UDP peut gérer cela en ayant une liste configurée des adresses IP de tous les serveurs et routeurs dans le groupe des homologues fonctionnant sur l’inter-réseau IP. Comme avec la liste des homologues sur un serveur, la mise en œuvre client devra simuler une diffusion en envoyant une copie du paquet à chaque adresse IP de sa liste des serveurs et routeurs IPX. Une des adresses IP dans la liste, peut-être la seule, pourrait être une adresse de diffusion ou, quand ce sera disponible, une adresse en diffusion groupée. Cela permet au client de communiquer avec les membres du groupe d’homologues sans avoir à connaître leurs adresses IP spécifiques.

Il est important de réaliser que les paquets en diffusion envoyés depuis un client IPX doivent être capable d’atteindre tous les serveurs et routeurs dans le groupe d’homologues du serveur. Contrairement à IP, qui a un mécanisme de redirection d’envoi individuel, les systèmes d’extrémité IPX sont responsables de la découverte des informations de routage en diffusant un paquet demandant un routeur qui puisse transmettre des paquets à la destination désirée. Si de tel paquets ne tendent pas à atteindre la totalité du groupe d’homologues du serveur, des ressources dans l'internet IPX peuvent être visibles à un système d’extrémité, bien qu’il ne puisse les joindre.

Unité de transmission maximale
=======================

Bien que de plus grands paquets IPX soient possibles, l'unité de transmission maximale standard pour IPX est de 576 octets. Par conséquent, 576 octets est l'unité de transmission recommandée par défaut pour les paquets IPX destinés à être envoyés avec cette technique d'encapsulation. Avec les huit octets de l'en-tête IDP et les vingt octets de l'en-tête IP, le paquet IP résultant fera ainsi 604 octets. À noter que ceci est plus grand que les 576 octets de la taille maximale que les mises en œuvre IP sont requises d'accepter [3]. Toute mise en œuvre IP acceptant cette technique d'encapsulation doit être capable de recevoir des paquets IP de 604 octets.

Comme les amélioration des protocoles et des matériels permettent des unités de transmission IP non fragmentées plus grandes, la taille de paquet maximale de 576 octets peut devenir une obligation. Pour cette raison, il est recommandé que la taille d’unité maximale de transmission IPX soit configurable dans les mises en œuvre de ce document.

Questions de sécurité
================

Dans une large zone, un réseau général tel qu’un internet IP dans une position normalement occupée par un câblage physique introduit quelques problèmes de sécurité qui ne sont normalement pas rencontrés dans des inter-réseaux IPX.

Les supports normaux sont typiquement protégés physiquement contre l’accès extérieur ; les internets IP autorisent typiquement un accès extérieur.

Le résultat principal est que la sécurité de l'inter-réseau IPX est seulement aussi bonne que la sécurité de l'internet IP entier à travers lesquels il passe en tunnel. Les grandes classes d'attaque suivantes sont possibles :

1) Des clients IPX non-autorisés peuvent obtenir l’accès à des ressources à travers des attaques de contrôle d'accès normal tel que le cassage de mot de passe.

2) Des routeurs IPX non autorisés peuvent détourner le traffix IPX sur des destinations non voulues.

3) Des agents non autorisés peuvent surveiller et manipuler le trafic IPX s’écoulant sur les supports physiques utilisés par l'internet IP et sous le contrôle de l'agent.

Dans une large mesure, ces risques de sécurité sont typiques des risques recontrés sur toute autre application utilisant un internet IP. Ils ne sont mentionnés ici que parce que IPX n'est pas normalement suspicieux à l’égard de ses supports. Les administrateurs d'un réseau IPX devront être conscients de ces risques de sécurité additionnels.

Numéros alloués
============

L’Autorité d'allocation des numéros de l’Internet alloue des numéros d’accès UDP bien-connus. Elle a alloué le numéro d’accès 213 en décimal à la technique d'encapsulation IPX décrite dans ce document [5].

Remerciements
===========

Cette technique d'encapsulation a été developpée indépendamment par Schneider & Koch et par Novell. Je voudrais remercier Thomas Ruf de Schneider & Koch pour avoir relu ce document pour l'accorder avec la mise en œuvre de Schneider & Koch et aussi pour ses autres suggestions utiles.

Références
=========

[1] Xerox, Corp., "Internet Transport Protocols", XSIS 028112, Xerox Corporation, décembre 1981.

[2] J. Postel, "Protocole de datagramme d’utilisateur", RFC 768, USC/Information Sciences Institute, août 1980.

[3] J. Postel, "Protocole Internet", RFC 791, DARPA, septembre 1981.

[4] S. Deering, "Extensions d’hôte pour diffusion groupée sur IP", RFC 1112, Stanford University, août 1989.

[5] J. Reynolds et J. Postel, "Numéros alloués", RFC-1060, USC/Information Sciences Institute, mars 1990.

Adresse de l'auteur
===============

Don Provan
Novell, Inc.
2180 Fortune Drive
San Jose, California, 95131
Téléphone : (408)473-8440
mèl : donp@Novell.Com