Groupe de travail Réseau

E. Krol

Request for Comments : 1118

University of Illinois Urbana

Statut : Information

 

Traduction Claude Brière de L'Isle

septembre 1989

 

 

Guide touristique de l'Internet

 

Statut de ce mémoire

 

La présente RFC est distribuée aux membres de la communauté de l'Internet afin de rendre disponibles certains "conseils" qui permettront aux participants du réseau de comprendre dans quelle direction va l'Internet, comment acquérir des informations en ligne et comment être un bon voisin sur l'Internet. Bien que les informations présentées puissent n'être pas pertinentes pour les problèmes de recherche sur l'Internet, elles peuvent intéresser un certain nombre de chercheurs et développeurs. Aucune norme n'est définie ou spécifiée dans le présent mémoire. Sa distribution n'est soumise à aucune restriction.

 

Remarque :

Ce guide touristique de l'Internet est un mémoire de qualité très inégale qui contient de nombreux passages qui paraissaient sur le moment une bonne idée aux éditeurs. C'est un compagnon indispensable pour toux ceux qui aiment comprendre les choses de la vie dans un Internet infiniment complexe et confus, car bien qu'il ne puisse espérer être utile ou apporter des informations sur tous les sujets, il revendique de façon rassurante que lorsque il n'est pas approprié, c'est de façon radicale qu'il est inapproprié. Dans les cas de discordance majeure, c'est toujours la réalité qui va de travers. Et souvenez vous, PAS DE PANIQUE (et nos excuses à Douglas Adams.)

 

Objet et destination

 

Le présent document suppose que les lecteur est familiarisé avec le fonctionnement d'un simple réseau IP non connecté (par exemple, quelques systèmes BSD 4.3 sur un Ethernet non connecté ailleurs). L'Appendice A contient des informations de référence sur ce point. Son objectif est de convaincre une personne, familiarisée avec un réseau simple, versée dans la "tradition orale" de l'Internet, que ce réseau peut être connecté à l'Internet avec peu de dangers pour quiconque. Ce n'est pas un didacticiel, il comporte des pointeurs sur d'autres places, œuvre littéraires, et des conseils qui ne sont normalement pas documentés. Comme l'Internet est un environnement dynamique, des changements seront faits régulièrement à ce document. L'auteur accueille volontiers commentaires et suggestions. Ceci est particulièrement vrai pour les termes du glossaire (les définitions ne sont pas nécessaires).

 

Qu'est-ce que l'Internet ?

 

Au début, il y avait l'ARPANET, un réseau expérimental sur une grande zone qui connectait ensemble des hôtes et des terminaux. Des procédures ont été établies pour réguler l'allocation des adresses et pour créer des normes volontaires pour le réseau. Comme les réseaux de zone locale devenaient plus courants, de nombreux hôtes sont devenus des passerelles vers les réseaux locaux. Il a été développé une couche réseau pour permettre l'interfonctionnement de ces réseaux, et elle a été appelée le protocole Internet (IP, Internet Protocol). Au fil du temps, d'autres groupes ont créé les réseaux à longue portée fondés sur IP (NASA, NSF, les états...). Ces réseaux, eux aussi, interopèrent grâce à IP. La collection de tous ces réseaux interopérants est l'Internet.

 

Quelques groupes fournissent la plupart des services d'information sur l'Internet. L'Institut des sciences de l'information (ISI, Information Sciences Institute) fait la plus grande partie du travail de normalisation et d'allocation de l'Internet en agissant comme Autorité d'allocation des numéros de l'Internet (IANA, Internet Assigned Numbers Authority). SRI International fournit les principaux services d'information pour l'Internet en faisant fonctionner le Centre d'informations du réseau (NIC, Network Information Center). En fait, après vous être connectés à l'Internet, la plupart des informations du présent document peuvent être retrouvées auprès du SRI-NIC. Bolt Beranek and Newman (BBN) fournit des services d'information pour le CSNET (le CIC) et le NSFNET (le NNSC), et Merit fournit des services d'information pour NSFNET (le NIS).

 

Fonctionnement de l'Internet

 

Chaque réseau, que ce soit l'ARPANET, NSFNET ou un réseau régional, a son propre centre de fonctionnement. L'ARPANET est géré par BBN, Inc. sous contrat du DCA (au nom du DARPA). Leur service s'appelle le Centre des opérations du réseau (NOC, Network Operations Center). Merit, Inc. gère NSFNET pour un autre NOC complètement indépendant du premier. Il s'occupe des régions qui ont des facilités similaires pour surveiller et rester en veille sur le fonctionnement de leur portion de l'Internet. De plus, ils doivent tous être plus ou moins au courant de ce qui se passe sur l'Internet globalement. Si un problème survient, il est suggéré qu'une liaison de réseau de campus contacte l'opérateur du réseau auquel il est directement connecté. C'est à dire que si vous êtes connectés à un réseau régional (qui a une passerelle avec le NSFNET, qui est connecté à l'ARPANET...) et que vous avez un problème, vous devriez contacter le centre d'opérations de votre réseau régional.

 

Les RFC

 

Les travaux internes de l'Internet sont définis par un ensemble de documents appelés demandes de commentaires (RFC, Request for Comments). Le processus général de création d'une RFC est que lorsque quelqu'un veut formaliser quelque chose, il écrit un document qui décrit la question et il l'envoie par messagerie à Jon Postel (Postel@ISI.EDU). Celui-ci agit comme un arbitre des propositions. Tous ceux qui souhaitent participer à la discussion font alors leurs commentaires (par messagerie électronique, bien sûr). Il peut y avoir plusieurs révisions. Si il est généralement accepté comme une bonne idée, il lui sera alloué un numéro est il sera archivé avec les RFC.

 

Il y a deux catégories indépendantes de protocoles. La première est l'état de normalisation qui est dans la série "norme", "projet de norme", "proposition de norme, "expérimental", ou "historique". La seconde est le statut de ce protocole dans la série "exigé", "recommandé", "au choix", ou "non recommandé". On peut attendre d'un protocole particulier qu'il se déplace sur l'échelle des statuts de "au choix" à "exigé" à un certain moment lorsqu'il passe sur l'échelle de normalisation de "norme proposée" à "norme".

 

Un protocole "norme exigée" (par exemple , la RFC-791, Protocole Internet) doit être mis en œuvre sur tout hôte connecté à l'Internet. Les protocoles 'norme recommandée" sont généralement mis en œuvre par les hôtes du réseau. Leur absence n'empêche pas l'accès à l'Internet, mais peut avoir un impact sur l'utilisation. La RFC-793 (Protocole de contrôle de transmission) est un protocole "norme recommandée". Les protocoles proposés au choix ont été discutés et approuvés, mais leur application n'a jamais été de large utilisation. Cela peut être dû à l'absence d'un large besoin de l'application spécifique (RFC-937, Protocole Post Office) ou que, bien que techniquement supérieur, il aille à l'encontre d'approches bien établies. Il est suggéré que si la facilité est exigée par un site particulier, une mise en œuvre puisse être effectuée conformément à la RFC. Cela assure que, si l'idée est mûre, la mise en œuvre sera conforme à une norme et pourra être d'utilisation générale.

 

Les RFC pour information contiennent des informations factuelles sur l'Internet et son fonctionnement (RFC-1010, Numéros alloués). Finalement, avec la croissance de l'Internet et les progrès des technologies, certaines RFC sont devenues non nécessaires. Ces RFC obsolètes ne peuvent cependant pas être ignorées. Fréquemment, lorsque un changement est apporté à une RFC qui cause la publication d'une nouvelle RFC et en rend d'autres obsolètes, la nouvelle RFC peut ne contenir que des explications et les motifs du changement. Comprendre le modèle sur lequel se fonde cette disposition toute entière peut impliquer la lecture de la RFC d'origine et des RFC suivantes sur le sujet. (L'Appendice B contient une liste de ce qui est considéré comme étant les RFC majeurs nécessaires pour la compréhension de l'Internet).

 

Seules quelques RFC spécifient réellement des normes, la plupart des RFC sont pour information ou pour les besoins de la discussion. Pour trouver quels sont les normes actuelles voir la RFC intitulée "Normes de protocole officielles de l'IAB" (la plus récemment publiée étant la RFC-5000).

 

Le Centre d'informations du réseau (NIC)

 

Le NIC est une facilité à la disposition de tous les utilisateurs de l'Internet, qui fournit des informations à la communauté. Il y a trois moyens pour contacter le NIC : le réseau, le téléphone, et la messagerie électronique. Les accès réseau sont les plus courants. L'accès interactif est fréquemment utilisé pour interroger les services généraux du NIC, faire des recherches sur les noms d'utilisateur et d'hôtes, et examiner les listes des documents du NIC. Il est disponible à "%telnet nic.ddn.mil" sur un système BSD, et en suivant les indications fournies par guidage convivial. En se promenant dans les bases de données fournies, chacun peut décider qu'un document nommé NETINFO:NUG.DOC (Le guide de l'utilisateur de l'ARPANET) vaut la peine d'être téléchargé. Il peut être restitué via FTP anonyme. Un FTP anonyme va se dérouler à peu près comme ceci. (Le dialogue peut un peu varier selon la mise en œuvre de FTP que vous utilisez).

 

%ftp nic.ddn.mil

Connected to nic.ddn.mil

220 NIC.DDN.MIL FTP Server 5Z(47)-6 at Wed 17-Jun-87 12:00 PDT

Name (nic.ddn.mil:myname): anonymous

331 ANONYMOUS user ok, send real ident as password.

Password: myname

230 User ANONYMOUS logged in at Wed 17-Jun-87 12:01 PDT, job 15.

ftp> get netinfo:nug.doc

200 Port 18.144 at host 128.174.5.50 accepted.

150 ASCII retrieve of <NETINFO>NUG.DOC.11 started.

226 Transfer Completed 157675 (8) bytes transferred

local: netinfo:nug.doc remote:netinfo:nug.doc

157675 bytes in 4.5e+02 seconds (0.34 Kbytes/s)

ftp> quit

221 QUIT command received. Goodbye.

 

(Un autre bon document initial à consulter est NETINFO:WHAT-THE-NIC-DOES.TXT).

 

Les questions peuvent être posées au NIC ou les problèmes avec les services rapportés en utilisant la messagerie électronique. On peut utiliser les adresses suivantes :

 

NIC@NIC.DDN.MIL   Assistance générale aux utilisateurs, demandes de documents

REGISTRAR@NIC.DDN.MIL   Enregistrement des utilisateurs et mises à jour de WHOIS (qui est qui)

HOSTMASTER@NIC.DDN.MIL   Changements et mises à jour de noms d'hôtes et de domaines

ACTION@NIC.DDN.MIL   Opérations d'ordinateur SRI-NIC

SUGGESTIONS@NIC.DDN.MIL   Commentaires sur les publications et services du NIC

 

Pour les personnes sans accès réseau, ou si il s'agit d'un grand nombre de documents, de nombreux documents du NIC sont disponibles sous forme imprimée pour un faible coût. Un document fréquemment commandé pour les sites de démarrage est un compendium des RFC majeures. L'accès par téléphone est principalement utilisé pour les questions ou problèmes avec l'accès réseau. (Voir en appendice B les numéros de contact mél/téléphone).

 

Le centre de service réseau de NSFNET

 

Le centre de service réseau NSFNET (NNSC), situé chez BBN Systems and Technologies Corp., est un projet de la corporation universitaire pour la recherche atmosphérique sous contrat avec la Fondation nationale pour la science. Le NNSC fournit une assistance aux utilisateurs de NSFNET pour répondre à leurs questions ou lorsqu'ils rencontrent des problèmes de traversée du réseau.

 

Le NNSC, qui a des informations et documents en ligne et sous forme imprimée, distribue des nouvelles par des listes de diffusion sur le réseau, des bulletins, et des rapports en ligne. Les publications du NNSC incluent une lettre d'informations imprimée, les NSF Network News, qui contient des articles intéressants pour les utilisateurs du réseau et le Guide des ressources de l'Internet (Internet Resource Guide), qui fait la liste des facilités (telles que les centres de super calculateurs et les catalogues de bibliothèques en ligne) accessibles à partir de l'Internet. Le Guide des ressources peut être obtenu via FTP anonyme à nnsc.nsf.net dans le répertoire resource-guide, ou en se joignant à la liste de diffusion du guide des ressource (envoyer une demande d'abonnement à Resource-Guide-Request@NNSC.NSF.NET.)

 

Les réflecteurs de messagerie

 

La façon dont la plupart des gens se tiennent au courant des nouvelles du réseau est par l'abonnement à un certain nombre de réflecteurs de messagerie (appelés aussi des exploseurs de messagerie). Les réflecteurs de messagerie sont des boîtes aux lettres électroniques particulières qui, lorsqu'elles reçoivent un message, le renvoient à une liste d'autres boîtes aux lettres. Cela a pour effet de créer un groupe de discussion sur un sujet particulier. Chaque abonné voit tous les messages transmis par le réflecteur, et si l'un d'eux veut y mettre son "grain de sel" il envoie un message avec ses commentaires au réflecteur.

 

Le format général pour s'abonner à une liste de messagerie est de trouver l'adresse du réflecteur et d'ajouter la chaîne -REQUEST au nom de la boîte aux lettres (pas au nom de l'hôte). Par exemple, si vous voulez prendre part à la liste de messagerie pour NSFNET reflétée par NSFNET-INFO@MERIT.EDU, vous envoyez une demande à NSFNET-INFO-REQUEST@MERIT.EDU. Cela peut être un schéma merveilleux, mais le problème est que vous devez connaître d'abord l'existence de la liste. Il est suggéré que, si vous êtes intéressés, vous lisiez d'abord un message d'une liste (comme NSFNET-INFO) et vous serez probablement bientôt familiarisés avec l'existence des autres. Un service d'enregistrement pour les réflecteurs de messagerie est fourni par le NIC dans les fichiers NETINFO:INTEREST-GROUPS-1.TXT, NETINFO:INTEREST-GROUPS-2.TXT, NETINFO:INTEREST-GROUPS-3.TXT, par NETINFO:INTEREST-GROUPS-9.TXT.

 

Le réflecteur de messagerie NSFNET-INFO vise les personnes qui portent in intérêt quotidien aux nouvelles du NSFNET (ceux qui travaillent sur le cœur de réseau, le réseau régional, et le site d'interconnexion Internet). Les messages sont réfléchis par une localisation centrale et sont envoyés par des messages séparés à chaque abonné. Cela crée des centaines de messages sur les réseaux de grande zone où la bande passante est la plus rare.

 

Il y a deux façons dont un campus peut diffuser les nouvelles et ne pas faire que ces messages submergent les réseaux de grande zones. L'une est de refléter le message sur le campus. C'est-à-dire d'établir un réflecteur sur une machine locale qui transmet le message à une liste de distribution sur le campus. L'autre est de créer un alias sur une machine du campus qui va placer les messages dans un fichier sur le sujet. Les utilisateurs du campus qui veulent les informations peuvent accéder au fichiers et voir les messages qui ont été envoyés depuis leur dernier accès. On peut aussi choisir d'avoir une liaison au niveau du réseau du campus qui examine les messages dans tous les cas et ne transmet que ceux qui sont considérés comme intéressants. L'un et l'autre schéma permet qu'un message soit envoyé sur le campus, tout en permettant une large distribution en interne.

 

L'allocation des adresses

 

Avant qu'un réseau local puisse être connecté à l'Internet, il doit recevoir une adresse IP univoque. Ces adresses sont allouées par le SRI-NIC. Le processus d'allocation consiste à obtenir un formulaire d'adhésion. Envoyer un message à Hostmaster@NIC.DDN.MIL et demander un formulaire d'adresse de connexion. Ce formulaire est rempli et renvoyé par messagerie au responsable. Une adresse est allouée et vous est renvoyée par messagerie. Cela peut aussi être fait pas la poste (Appendice B).

 

Les adresses IP sont longues de 32 bits. Elles sont habituellement écrites sous la forme de quatre chiffres décimaux séparés par des points (par exemple, 192.17.5.100). Chaque nombre est la valeur d'un octet des 32 bits. Certains réseaux peuvent choisir de s'organiser eux-mêmes comme très plats (un réseau avec beaucoup de nœuds) et d'autres peuvent s'organiser de façon hiérarchisée (beaucoup de réseaux interconnectés avec moins de nœuds chacun et un cœur de réseau). Pour faire face à ces différents cas, les adresses ont été différenciées en réseaux de classe A, B, et C. Cette classification est en rapport avec l'interprétation des octets. Les réseaux de classe A ont le premier octet comme adresse réseau et les trois restants comme adresse d'hôte sur ce réseau. Les adresses de classe C ont trois octets d'adresse réseau et un d'hôte. La classe B est partagée en deux et deux. Donc, il y a un espace d'adresse pour quelques grands réseaux, un nombre raisonnable de réseaux moyens et un grand nombre de petits réseaux. Les bits de plus fort poids dans le premier octet sont codés pour dire le format de l'adresse. Il y a très peu de réseaux de classe A non alloués, aussi on doit leur faire une très bonne place. En pratique, on a à choisir entre la classe B et la classe C lorsqu'on passe commande. (Il y a aussi des formats de classe D (diffusion groupée) et E (expérimental). Les adresses de diffusion groupée vont vraisemblablement devenir très utilisées dans un futur proche, mais ne sont pas encore très utilisées actuellement).

 

Autrefois, les sites qui avaient besoin de plusieurs adresses réseau demandaient plusieurs adresses distinctes (normalement de classe C). Cela se faisait parce que la plupart des logiciels disponibles (notamment 4.2BSD) ne pouvaient pas traiter des adresses de sous-réseau. Les informations sur la façon d'atteindre un réseau particulier (les informations d'acheminement) doivent être mémorisées dans les routeurs et les commutateurs de paquets Internet. Certains de ces nœuds ont des capacités limitées pour mémoriser et échanger les information d'acheminement (limitées à environ 700 réseaux). Il est donc suggéré qu'aucun campus n'annonce (ne fasse connaître à l'Internet) plus de deux numéros de réseau séparés.

 

Si un campus considère que cette contrainte le gène, il devrait considérer la possibilité de se mettre en sous-réseaux. La mise en sous-réseaux (RFC-950) permet d'annoncer une adresse à l'Internet et d'utiliser un ensemble d'adresses sur le campus. Très simplement, on définit un gabarit qui permet au réseau de faire la différence entre la portion réseau et la portion hôte de l'adresse. En utilisant un gabarit différent sur l'Internet et sur le campus, l'adresse peut être interprétée de plusieurs façons. Par exemple, si un campus exige deux réseaux en interne et qu'il a 32 000 adresses commençant par 128.174.X.X (une adresse de classe B) qui lui sont allouées, le campus pourrait allouer 128.174.5.X à une partie du campus et 128.174.10.X à l'autre. En annonçant 128.174 à l'Internet avec un gabarit de sous-réseau de FF.FF.00.00, l'Internet traiterait ces deux adresses comme une seule. Au sein du campus un gabarit de FF.FF.FF.00 serait utilisé, permettant au campus de traiter les adresses comme des entités distinctes. (En réalité, on ne passe pas le gabarit de sous-réseau de FF.FF.00.00 à l'Internet, la signification des octets étant implicite dans le fait que c'est une adresse de classe B.)

 

Un mot d'avertissement est nécessaire. Tous les systèmes ne savent pas comment faire la mise en sous-réseau. Certains systèmes 4.2BSD exigent un logiciel additionnel. Les systèmes 4.3BSD traitent les sous-réseau comme indiqué ici. D'autres appareils et systèmes d'exploitation ont des solutions variées pour la façon dont ils traitent les sous-réseaux. Fréquemment, ces machines peuvent être utilisées comme un système terminal sur un réseau, mais pas comme un routeur au sein de la portion en sous-réseau du réseau. Avec le temps de plus en plus de systèmes se fondent sur 4.3BSD, et ces problèmes devraient disparaître.

 

Il y a eu un peu de confusion dans le passé sur le format d'une adresse IP de diffusion. Certaines machines utilisaient une adresse toute à zéro pour signifier la diffusion et certaines autres une adresse toute à un. Cela créait la confusion lorsque des machines des deux types étaient connectées au même réseau. L'adresse de diffusion toute à un a été adoptée pour clore le débat. Certains systèmes (par exemple, 4.3 BSD) permettent de choisir le format de l'adresse de diffusion. Si un système permet de choix, il faut veiller à choisir le format tout à un. (Ceci est expliqué dans la RFC-1009 et la RFC-1010).

 

Problèmes de l'Internet

 

L'Internet pose un certain nombre de problèmes. La gamme de leurs solutions va des changements de logiciel à des projets de recherche à long terme. Certains des problèmes majeurs sont précisés ci-dessous.

 

Nombre des réseaux

 

Lorsque l'Internet a été conçu il était prévu qu'il ait une cinquantaine de réseaux connectés. Avec l'explosion du réseautage, le nombre approche maintenant les 1000. Le logiciel d'un groupe de routeurs critiques (appelés les routeurs centraux) n'est pas capable de passer ou mémoriser beaucoup plus que ce nombre de réseaux. À court terme, la réallocation et le recodage ont un petit peu relevé ce nombre.

 

Problèmes d'acheminement

 

À côté de la simple masse des données nécessaire pour acheminer les paquets à un grand nombre de réseaux, il y a de nombreux problèmes de mise à jour, de stabilité, et d'optimisation des algorithmes d'acheminement. De nombreuses recherches sont faites dans ce domaine, mais la solution optimales à ces problèmes d'acheminement est encore pour dans plusieurs années. Dans la plupart des cas, l'acheminement que nous avons aujourd'hui fonctionne, mais de façon sous optimale et parfois de façon imprévisible. Le meilleur espoir actuel d'un bon protocole d'acheminement est parfois connu sous le nom de OSPFIGP qui sera généralement disponible dans moins d'un an chez la plupart des fabricants de routeurs.

 

Problèmes de confiance

 

Les routeurs échangent des informations d'acheminement du réseau. Actuellement, la plupart des routeurs acceptent de confiance que les informations fournies sur l'état du réseau sont correctes. Dans le passé, cela ne posait pas de gros problèmes car la plupart des routeurs appartenaient à une seule entité administrative (DARPA). Maintenant, avec de multiples réseaux de grande couverture appartenant à différentes administrations, un routeur défectueux quelque part dans la toile peut handicaper l'Internet. Il y a un travail de conception à faire pour résoudre à la fois le problème d'un routeur qui fait des choses déraisonnables et pour fournir suffisamment d'informations pour acheminer raisonnablement les données entre des réseaux à connexions multiples (réseaux multi-rattachement).

 

Capacités et encombrement

 

Certaines portions de l'Internet sont très encombrées durant les heures ouvrables. La croissance est dramatique dans certains réseaux qui rencontrent une croissance de trafic supérieure à 20 % par mois. De la bande passante supplémentaire est prévue, mais les délais de livraison et les budgets pourraient ne pas permettre de tenir la cadence.

 

Établissement des directives et des priorités

 

Le Bureau des activités de l'Internet (IAB), actuellement présidé par Vint Cerf de NRI, est chargé d'assurer la direction technique, d'établir les normes et de résoudre les problèmes dans l'Internet.

 

Les membres actuels de l'IAB

 

Vinton Cerf   - Président

David Clark   - Président de l'IRTF

Phillip Gross   - Président de l'IETF

Jon Postel   - Éditeur des RFC

Robert Braden   - Directeur exécutif

Hans-Werner Braun   - Liaison avec NSFNET

Barry Leiner   - Liaison avec CCIRN

Daniel Lynch   - Liaison avec les fabricants

Stephen Kent   - Sécurité de l'Internet

 

Ce bureau est soutenu par une équipe de recherche (présidée par Dave Clark du MIT) et une équipe d'ingénierie (présidée par Phill Gross du NRI).

 

L'équipe de recherche de l'Internet (Internet Research Task Force) possède les groupes de recherche suivants :

 

Réseaux autonomes   Deborah Estrin

Services de bout en bout   Bob Braden

Confidentialité   Steve Kent

Interfaces d'utilisateur   Keith Lantz

 

L'équipe d'ingénierie de l'Internet couvre les domaines techniques suivants :

 

Applications   à définir

Protocoles d'hôtes   Craig Partridge

Protocoles Internet    Noel Chiappa

Acheminement   Robert Hinden

Gestion de réseau   David Crocker

Interopérabilité OSI   Ross Callon, Robert Hagen

Fonctionnement   à définir

Sécurité   à définir

 

L'équipe d'ingénierie de l'Internet possède les groupes de travail suivants :

 

ALERTMAN   Louis Steinberg

Authentification   Jeff Schiller

CMIP sur TCP   Lee LaBarre

Noms de domaines   Paul Mockapetris

Configuration dynamique d'hôte   Ralph Droms

Exigences pour les hôtes   Bob Braden

Interconnectivité   Guy Almes

MIB de l'Internet   Craig Partridge

Gestion conjointe   Susan Hares

MIB de gestion de LAN   Amatzia Ben-Artzi

NISI   Karen Bowers

Interface série de gestion de réseau   Jeff Case

Outils NOC   Bob Enger

OSPF   Mike Petry

Acheminement des systèmes ouverts   Marianne Lepp

Interopérabilité OSI   Ross Callon

Groupe d'accheminement PDN   CH Rokitansky

Performances et CC   Allison Mankin

IP en point à point   Drew Perkins

ST et CO-IP   Claudio Topolcic

Telnet   Dave Borman

Documents d'utilisateur   Karen Roubicek

Services d'utilisateur   Karen Bowers

 

Acheminement

 

L'acheminement est l'algorithme par lequel un réseau dirige un paquet de sa source à sa destination. Pour apprécier le problème, observez un petit enfant qui essaye de trouver une table dans un restaurant. Du point de vue d'un adulte, la structure de la salle à manger est vue et une route optimale facilement choisie. L'enfant, cependant, est en face d'un ensemble de chemins entre les tables dont un bon, sans parler du chemin optimal, vers le but est indiscernable.

 

Il serait approprié de faire un petit retour sur les fondamentaux. Les passerelles IP (plus correctement nommées routeurs) sont des boîtes qui ont des connexions avec plusieurs réseaux et passent le trafic entre ces réseaux. Elles décident comment envoyer le paquet sur la base des informations de l'en-tête IP du paquet et de l'état du réseau. Chaque interface d'un routeur a une unique adresse appropriée au réseau auquel elle est connectée. Les informations de l'en-tête IP qui est utilisé sont principalement l'adresse de destination. Les autres informations (par exemple, le type de service) sont largement ignorées à ce stade. L'état du réseau est déterminé par les routeurs qui se passent entre eux des informations. La répartition de la base de données (que chaque nœud connaît), la forme des mises à jour, et la métrique utilisée pour mesurer la valeur d'une connexion, sont les paramètres qui déterminent les caractéristiques d'un protocole d'acheminement.

 

Dans certains algorithmes, chaque nœud du réseau a une connaissance complète de l'état du réseau (l'algorithme de l'adulte). Cela implique que les nœuds doivent avoir de grandes quantités de mémoire locale et suffisamment de CPU pour chercher dans de gros tableaux en un temps assez court (rappelez vous, cela doit être fait pour chaque paquet). Aussi, les mises à jour de l'acheminement contiennent habituellement seulement les modifications aux informations existantes (ou alors vous allez dépenser une grande partie de la capacité du réseau à passer des mégaoctets de mises à jour d'acheminement). Ce type d'algorithme pose plusieurs problèmes. Comme la seule façon de passer les informations d'acheminement tout autour est de passer à travers le réseau et que le temps de propagation n'est pas trivial, la vue du réseau à chaque nœud est une vue historique correcte du réseau à différents instants du passé. (L'algorithme de l'adulte, mais au lieu de regarder directement dans la salle à manger, on regarde une photographie de celle-ci. On va vraisemblablement prendre le chemin optimal et découvrir qu'un énorme truc a bloqué le chemin après la prise de la photo). Ces incohérences peuvent causer des chemins circulaires (qu'on appelle des acheminements en boucle) où une fois qu'un paquet est entré, il est dans une impasse jusqu'à ce que sont champ de durée de vie (TTL) arrive à expiration et qu'il soit éliminé.

 

D'autres algorithmes peuvent ne connaître qu'un sous-ensemble du réseau. Pour empêcher les boucles dans ces protocoles, ils sont normalement utilisés dans un réseau hiérarchisé. Ils savent tout de leur propre zone, mais pour la quitter, ils vont à un endroit particulier (le routeur par défaut). Normalement, ceux-là sont utilisée dans de plus petits réseaux (campus ou régional).

 

Les protocoles d'acheminent actuellement utilisés sont :

 

Statiques (pas de tableaux de protocole/acheminement par défaut)

 

Ne riez pas ! C'est probablement, pour un petit réseau ou un réseau d'extrémité sur l'Internet, le plus fiable, facile à mettre en œuvre, et celui qui a le moins de chances d'avoir des ennuis. C'est aussi la seule méthode disponible sur certaines combinaisons de CPU et de système d'exploitation. Si un hôte est connecté à un Ethernet qui n'a qu'un seul routeur de sortie, on n'a qu'à prendre le routeur par défaut pour l'hôte et il n'y a pas d'autre acheminement. (Bien sûr, ce routeur peut passer les informations d'accessibilité de quelque façon de l'autre côté de lui-même.)

 

Un mot d'avertissement : ce n'est qu'avec une extrême prudence qu'on devrait utiliser les chemins statiques au milieu d'un réseau qui utilise aussi l'acheminement dynamique. Les routeurs qui passent les informations dynamiques sont parfois bernés par des chemins dynamiques et statiques en conflit. Si votre hôte est sur un Ethernet qui a plusieurs routeurs sur d'autres réseau, et que les routeurs font de l'acheminement dynamique entre eux, il est habituellement préférable de prendre part à l'acheminement dynamique que d'utiliser l'acheminement statique.

 

RIP

 

RIP est un protocole d'acheminement fondé sur XNS (Xerox Network System) adapté pour les réseaux IP. Il est utilisé par de nombreux routeurs (Proteon, cisco, UB...) et de nombreux systèmes Unix BSD. Les systèmes BSD fonctionnent normalement avec un programme appelé "routed" pour échanger des informations avec d'autres systèmes fonctionnant avec RIP. RIP fonctionne mieux pour des réseaux de faible diamètre (peu de bonds) où les liaisons sont de vitesse égale. La raison en est que la métrique utilisée pour déterminer quel est le meilleur chemin est le compte de bonds. Un bond est une traversée d'un routeur. Ainsi, toutes les machines sur le même Ethernet sont à zéro bond. Si un routeur connecte directement deux réseaux, une machine de l'autre côté du routeur est à un bond. Lorsque les informations d'acheminement sont passées à travers un routeur, le routeur ajoute un au compte de bonds pour le garder cohérent à travers le réseau. Le diamètre d'un réseau est défini comme le plus grand compte de bonds possible au sein d'un réseau. Malheureusement, un compte de bonds de 16 est défini comme l'infini par RIP ce qui signifie que la liaison est morte. Donc, RIP ne va pas permettre que des hôtes soient séparés par plus de 15 routeurs dans l'espace RIP pour qu'ils puissent communiquer.

 

L'autre problème avec la métrique du compte des bonds est que si les liaisons ont des vitesses différentes, cette différence n'est pas reflétée dans le compte des bonds. Ainsi une liaison satellite à un bond (avec un délai de 0,5 s) à 56 kbit/s sera utilisée au lieu d'une connexion T1 à deux bonds. L'encombrement peut être vu comme une baisse de l'efficacité d'une liaison. Ainsi, lorsque une liaison devient plus encombrée, RIP va toujours croire qu'elle est le meilleur chemin selon le compte de bonds et va l'encombrer encore plus en lançant plus de paquets sur la file d'attente de cette liaison.

 

RIP n'était pas bien documenté à l'origine dans la communauté de l'Internet et les gens lisait le code BSD pour trouver comment fonctionnait réellement RIP. Finalement, il a été documenté dans la RFC-1058.

 

Routed

 

Le programme routed, qui fait RIP pour les systèmes 4.2BSD, a de nombreuses options. Une des plus fréquemment utilisées est : "routed -q" (mode quiet) ce qui signifie écouter les informations de RIP, mais ne jamais les diffuser. Ce serait utilisé par une machine sur un réseau avec plusieurs routeurs parlant RIP. Il permet à l'hôte de déterminer quel routeur est le meilleur (en termes de bonds) à utiliser pour atteindre un réseau distant. (Bien sûr, vous pourriez vouloir avoir un routeur par défaut pour éviter de passer toutes les adresses connues dans l'Internet avec RIP.)

 

Il y a deux façons d'insérer des chemins statiques dans routed ; le fichier/etc/gateways, et la commande "route add". Les chemins statiques sont utiles si vous savez comment atteindre un réseau distant, mais vous ne recevrez pas ce chemin en utilisant RIP. Dans la plupart des cas, il est préférable d'utiliser la commande "route add". La raison en est que la commande ajoute le chemin au tableau d'acheminement de la machine, mais ne l'exporte pas avec RIP. Le fichier /etc/gateways prend le pas sur toute autre information d'acheminement reçue par une mise à jour RIP. Il est aussi diffusé en fait dans les mises à jour de RIP produites sans remise en question par l'hôte, de sorte que si une faute est commise dans le fichier /etc/gateways, cette faute va bientôt infecter tout l'espace RIP et peut mettre le réseau à genoux.

 

Un des problèmes avec routed est qu'on a très peu de contrôle sur ce qui est diffusé et ce qui ne l'est pas. Dans de plus grands réseaux où diverses parties du réseau sont soue le contrôle d'administrations différentes, vous aimeriez souvent passer par RIP les seuls réseaux que vous recevez de RIP et dont vous savez qu'ils sont raisonnables. Cela empêche les gens d'ajouter des adresses IP au réseau qui peut être illégal et vous êtres responsables lorsque vous les passez sur l'Internet. Ce type de vérification d'acceptabilité n'est pas disponible avec routed et le laisse utilisable, mais inadéquat pour les grands réseaux.

 

Hello (RFC-891)

 

Hello est un protocole d'acheminement qui a été conçu et mis en œuvre dans un routeur de logiciel expérimental appelé un "Fuzzball" qui fonctionne sur un PDP-11. Il n'a pas une très large utilisation, mais c'est le protocole d'acheminement anciennement utilisé sur le cœur de réseau initial de NSFNET. Les données transférées entre les nœuds sont similaires à celles de RIP (une liste de réseaux et leur métrique). La métrique est cependant en millisecondes de délai. Cela permet à Hello d'être utilisé sur des réseaux de vitesses de liaison variées et de mieux se comporter dans des situations d'encombrement.

 

Un des effets collatéraux les plus intéressants des réseaux fondés sur Hello est leur grande capacité à tenir les délais. Si vous considérez le problème de la mesure des délais pour la métrique sur une liaison, vous allez trouver que ce n'est pas si facile à faire. Vous ne pouvez pas mesurer le délai d'aller retour dans la mesure où la liaison de retour peut être plus encombrée, d'une vitesse différente, ou même absente. Il n'est pas réellement faisable pour chaque nœud du réseau d'avoir un récepteur WWV (norme d'heure nationale par radio) incorporé. Ainsi, vous devez concevoir un algorithme pour diffuser l'heure sur les nœuds du réseau par les liaisons du réseau alors que le délai de transmission peut seulement être approximatif. Les routeurs Hello font cela et dans un réseau à l'échelle nationale maintiennent la synchronisation horaire à la milliseconde. (Voir aussi le Protocole de l'heure du réseau, RFC-1059.)

 

Protocole de routeur à routeur (GGP) RFC-823

 

Les routeurs centraux utilisaient à l'origine GGP pour échanger des informations entre eux. C'est un algorithme de "vecteur de distance". Les nouveaux routeurs centraux utilisent un algorithme "d'état de liaison".

 

SPF de NSFNET (RFC-1074)

 

Les routeurs de cœur de réseau NSFNET actuels utilisent une version du protocole d'acheminement ANSI IS-IS et ISO ES-IS. C'est un algorithme de plus court chemin en premier (SPF, shortest path first) qui est dans la classe des algorithmes "d'état de liaison".

 

Protocole de routeur extérieur (EGP RFC-904)

 

EGP n'est pas strictement parlant un protocole d'acheminement, c'est un protocole d'accessibilité. Il dit quels réseaux peuvent être atteints à travers quels routeurs, mais pas si la connexion est bonne. C'est le standard selon lequel les routeurs échangent les informations d'accessibilité de réseau avec les routeurs centraux. Il est généralement utilisé entre systèmes autonomes. EGP fait circuler une métrique, mais son usage n'est pas formellement normalisé. La valeur de la métrique s'étage de 0 à 255, les plus petites valeurs étant considérées comme "meilleures". Certaines mises en œuvre considèrent que la valeur 255 signifie inaccessible. De nombreux routeurs parlent EGP de sorte qu'il peut être utilisé pour servir d'interface entre des routeurs de fabricants différents ou gérés par des administrations différentes. Par exemple, lorsque un routeur du cœur de réseau NSFNET échange des informations d'acheminement ou d'accessibilité avec un routeur d'un réseau régional, c'est EGP qui est utilisé.

 

Gated

 

Ainsi, nous avons des réseaux régionaux et de campus qui parlent RIP entre eux et le DDN et NSFNET qui parlent EGP. Comment interopèrent –ils ? Au début, il y avait l'acheminement statique. Le problème quand on fait de l'acheminement statique au milieu du réseau est qu'on diffuse dans l'Internet si il est utilisable ou non. Donc, si un réseau devient injoignable et que vous essayez d'y aller, l'acheminement dynamique va immédiatement vous envoyer un message réseau injoignable. Dans l'acheminement statique, les routeurs vont penser que le réseau peut être atteint et vont continuer d'essayer jusqu'à ce que l'application abandonne (en 2 minutes ou plus). Mark Fedor, alors chez Cornell, a tenté de résoudre ces problèmes avec un remplacement de routed appelé gated.

 

Gated parle RIP aux hôtes qui parlent RIP, EGP à ceux qui parlent EGP, et Hello à ceux qui parlent Hello. Ces différents locuteurs résident fréquemment tous sur un Ethernet, mais heureusement (ou malheureusement) ne peuvent pas comprendre les ruminations des autres. De plus, avec le contrôle des fichiers de configuration, il peut filtrer la conversion. Par exemple, l'un peut produire une configuration dit qu'elle annonce les réseaux RIP via Hello seulement si ils sont spécifiés dans une liste et sont joignables aussi au moyen d'une diffusion RIP. Cela signifie que si un réseau pourri apparaît dans l'espace RIP de votre site local, il ne sera pas passé à la partie Hello du reste du monde. Il y a aussi des options de configuration pour faire de l'acheminement statique et des routeurs de confiance.

 

Cela peut paraître la plus grande invention depuis le fil à couper le beurre, mais il y a une chose qu'on appelle la conversion de métrique. Vous avez RIP qui mesure en bonds, Hello qui mesure en millisecondes, et EGP qui utilise des nombres arbitrairement petits. La grande questions est combien de bonds dans une milliseconde, combien de millisecondes dans le nombre 3 d'EGP.... Et aussi, se souvenir que l'infini (inaccessibilité) est 16 pour RIP, 30 000 ou à peu près pour Hello, et 8 pour le DDN avec EGP. Faire bien fonctionner toutes ces métriques ensemble n'est pas une petite fête. Si c'est fait de travers et que vous traduisez un RIP de 16 en un EGP de 6, tout le monde dans l'ARPANET va penser que votre routeur peut joindre l'injoignable et va vous envoyer tous les paquets du monde. Gated est disponible via FTP anonyme à partir de devvax.tn.cornell.edu in directory pub/gated.

 

Noms

 

Tout acheminement à travers le réseau est fait au moyen de l'adresse IP associée à un paquet. Comme les humains trouvent difficile de se souvenir d'adresses telles que 128.174.5.50, un registre de noms symboliques a été établi au NIC où les gens peuvent dire, "J'aimerai que mon hôte soit nommé uiucuxc". Les machines connectées à l'Internet au travers du pays vont se connecter au NIC au milieu de la nuit, vérifier les dates de modification sur les fichiers d'hôtes, et si c'est modifié, le passent à leur machine locale. Avec l'avènement des stations de travail et des micro-ordinateurs, les changements de fichier d'hôte doivent être faits de nuit. C''est aussi un gros travail qui consomme une partie de la bande passante du réseau. La RFC-1034 et un certain nombre d'autres décrivent le service des noms de domaines (DNS, Domain Name Service), un système de base de données réparties pour la transposition des noms en adresses.

 

On doit regarder d'un peu plus près à ce qu'il y a dans un nom. D'abord, noter qu'une adresse spécifie une connexion particulière sur une réseau spécifique. Si la machine est déplacée, l'adresse change. Ensuite, une machine peut avoir un ou plusieurs noms et une ou plusieurs adresses réseau (connexions) à différents réseaux. Les noms pointes sur quelque chose qui fait un travail utile (c'est-à-dire, la machine) et les adresses IP pointent sur une interface de ce fournisseur. Un nom est une représentation purement symbolique d'une liste d'adresses sur le réseau. Si une machine est déplacée sur un réseau différent, l'adresses va changer mais le nom peut rester le même.

 

Les noms de domaines sont une arborescence structurée avec la racine de l'arbre à droite. Par exemple : uxc.cso.uiuc.edu est une machine appelée "uxc" (purement arbitraire), au sein des sous-domaines du U de I, et "uiuc" (l'Université de l'Illinois à Urbana), est enregistrée avec "edu" (l'ensemble des institutions d'éducation).

 

Un modèle simplifié de la façon dont un nom est résolu est qu'il y a un résolveur sur la machine de l'utilisateur. Le résolveur sait comment contacter un serveur racine de noms à travers le réseau. Les serveurs racine sont la base du système de restitution des données structurées en arborescence. Ils savent qui est chargé du traitement des domaines de premier niveau (par exemple, 'edu'). Quels serveurs racine utiliser est un paramètre d'installation. À partir du serveur racine, le résolveur trouve qui fournit le service 'edu'. Il contacte le serveur de noms 'edu' qui lui fournit une liste d'adresses de serveurs pour les sous-domaines (comme 'uiuc'). Cette action est répétée avec les serveurs de sous-domaines jusqu'à ce que le sous-domaine final retourne une liste des adresses des interfaces sur l'hôte en question. La machine de l'utilisateur à alors le choix de l'adresse à utiliser pour la communication.

 

Un groupe peut s'affilier à son propre nom de domaine (comme 'uiuc' ci-dessus). Cela se fait d'une façon similaire à l'allocation des adresses IP. Les seules exigences sont que le demandeur ait deux machines joignables à partir de l'Internet, qui vont agir comme serveurs de noms pour ce domaine. Ces serveurs pourraient aussi agir comme serveurs pour des suus-domaines ou d'autres serveurs pourraient être désignés comme tels. Noter que les serveurs n'ont pas besoin d'être localisés en un endroit particulier, tant qu'ils sont joignables pour la résolution des noms. (L'Université de l'Illinois pourrait demander à l'État du Michigan d'agir en son nom, et il n'y aurait pas de problème.) Le plus gros problème est que quelqu'un doit faire la maintenance de la base de données. Si la machine ne convient pas pour cela, ce peut n'être pas fait à temps. L'autre point à noter est qu'une fois que le domaine est alloué à une entité administrative, cette entité peut librement allouer des sous-domaines de la manière qui lui paraît appropriée.

 

Le serveur de noms de domaine Internet de Berkeley (BIND, Berkeley Internet Name Domain) met en œuvre le serveur de noms Internet pour les systèmes UNIX. Le serveur de noms est un système de base de données répartie qui permet aux clients de nommer leurs ressources et de partager ces informations avec les hôtes des autres réseaux. BIND est intégré avec 4.3BSD et est utilisé pour chercher et mémoriser les noms d'hôtes, les adresses, les agents de messagerie, les informations d'hôtes, et plus encore. Il remplace le fichier /etc/hosts ou les recherches de nom d'hôte. BIND est encore un programme évolutif. Pour se tenir au courant des rapports sur les problèmes de fonctionnement, des décisions sur les concepts du futur, etc., se joindre à la liste de diffusion de BIND en envoyant une demande à Bind-Request@UCBARPA.BERKELEY.EDU. BIND peut aussi être obtenu via FTP anonyme à partir de ucbarpa.berkeley.edu.

 

Il y a plusieurs avantages à utiliser BIND. Un des plus importants est qu'il libère un hôte de la contrainte d'avoir à mettre à jour /etc/hosts complet. Au sein du domaine .uiuc.edu, seuls quelques hôtes sont inclus dans le tableau des hôtes distribué par le SRI. Le reste figure sur des listes locales, au sein des tableaux de BIND sur uxc.cso.uiuc.edu (le serveur pour la plupart du domaine .uiuc.edu). Toutes sont également joignables à partir de tout autre hôte Internet fonctionnant avec BIND, ou de tout résolveur DNS.

 

BIND peut aussi fournir des informations de transmission de messagerie pour les hôtes intérieurs non directement joignables à partir de l'Internet. Ces hôtes sont soit sur des réseaux non publiés, soit pas connectés du tout à un réseau IP, comme dans le cas des hôtes joignables par UUCP (voir la RFC-974). Plus d'informations sur BIND sont disponibles dans le "Name Server Operations Guide for BIND" dans le Manuel de gestionnaire de système UNIX, édition 4.3BSD.

 

Il y a quelques domaines particuliers dans le réseau, comme NIC.DDN.MIL. La base de données des hôtes du NIC. Il y en a d'autres de la forme NNSC.NSF.NET. Ces domaines spéciaux sont utilisés avec parcimonie, et exigent des justifications précises. Ils se réfèrent à des serveurs sous le contrôle administratif du réseau plutôt que d'une seule organisation. Cela permet au serveur réel d'être déplacé dans le réseau alors que l'interface d'utilisateur avec cette machine reste constante. C'est-à-dire que, même si le BBN abandonnait son contrôle sur le NNSC, le nouveau fournisseur serait pointé par ce nom.

 

En réalité, le système des domaines est un système beaucoup plus général et complexe que ce qui a été décrit. Les résolveurs et certains serveurs mettent les informations en antémémoire pour permettre de sauter des étapes dans la résolution. Les informations fournies par les serveurs peuvent être arbitraires, et pas simplement des adresses IP. Cela permet que le système soit utilisé à la fois par des réseaux non IP et pour la messagerie, où il peut être nécessaire de donner des informations sur des ponts de messagerie intermédiaires.

 

Ce qui ne va pas avec l'Unix Berkeley

 

L'Université de Californie à Berkeley a été mandatée par le DARPA pour modifier le système Unix de plusieurs façons. Parmi ces modifications figure la prise en charge des protocoles de l'Internet. Dans les précédentes versions (par exemple, BSD 4.2) il y avait une bonne prise en charge des protocoles de base de l'Internet (TCP, IP, SMTP, ARP) qui lui permettait de fonctionner correctement sur les Ethernets IP et les plus petits Internets. Il y avait cependant des déficiences, lorsque il était connecté à des réseaux compliqués. La plupart de ces problèmes ont été résolus avec la dernière version (BSD 4.3). Comme il est le tremplin sur lequel de nombreux fabricants ont lancé les mises en œuvre Unix (soit en y portant le code existant soit en l'utilisant comme modèle), de nombreuses mises en œuvre (par exemple, Ultrix) sont encore fondées sur BSD 4.2. Donc, de nombreuses mises en œuvre existent encore avec les problèmes du BSD 4.2. Avec le temps, BSD 4.3 se répandant parmi le fabricants comme la nouvelle version, beaucoup des problèmes se trouveront résolus. Ci-après figure une liste de certains scénarios de problèmes et leurs traitement dans chacune de ces versions.

 

Redirections ICMP

Dans le modèle Internet, tout ce qu'un système a besoin de savoir pour aller n'importe où dans l'Internet est sa propre adresse, l'adresse de là où il veut aller, et comment trouver un routeur qui connaisse l'Internet. Il n'a pas besoin d'être le meilleur des routeurs. Si le système est sur un réseau avec plusieurs routeurs, et qu'un hôte envoie un paquet à livrer à un routeur qui pense qu'un autre routeur directement connecté est plus approprié, le routeur envoie un message à l'envoyeur. Ce message est un message ICMP redirect, qui dit poliment "Je livrerai ce message pour vous, mais vous devriez vraiment utiliser tel routeur pour atteindre cet hôte". BSD 4.2 ignore ces messages. Cela crée des charges supplémentaires aux routeurs et au réseau local, car pour chaque paquet envoyé, le routeur envoie un paquet à l'origine. BSD 4.3 utilisera les redirections pour mettre à jour ses tableaux d'acheminement, utilisera le chemin jusqu'à son expiration, puis reviendra à l'utilisation du chemin qu'il pense qu'il devrait utiliser. Tout le processus se répète alors, mais c'est bien mieux qu'un message par paquet.

 

En queues

Une application (comme FTP) envoie une chaîne d'octets à TCP qui la coupe en tronçons, et ajoute un en-tête TCP. TCP envoie alors des blocs de données à IP qui ajoute ses propres en-têtes et expédie les paquets sur le réseau. Toute cette augmentation des données avec les en-têtes cause des mouvements de mémoire aussi bien chez la machine d'envoi que chez celle de réception. Quelqu'un a eu la brillante idée que si les paquets étaient longs et qu'on collait les en-têtes à la fin (ils deviennent des en-queues), la machine receveuse pourrait mettre le paquet au début d'une limite de page et si l'en-queue est correct, simplement le supprimer et transférer le contrôle de la page sans impliquer de mouvements de mémoire. Le problème est que les en-queues n'ont jamais été normalisés et la plupart des routeurs ne savent pas chercher les informations d'acheminement à la fin du bloc. Lorsque des en-queue sont utilisés, la machine travaille normalement bien sur le réseau local (pas de routeur impliqué) et pour les blocs courts à travers les routeurs (sur lesquels les en-queues ne sont pas utilisés). Ainsi ceux de TELNET et de FTP fonctionnent très bien avec des fichiers très court et ceux de FTP pour des fichiers longs semblent accrocher. Sur BSD 4.2 les en-queues sont une option d'amorçage et on devrait s'assurer qu'ils sont désactivés quand on utilise l'Internet. BSD 4.3 négocie les en-queues, de sort qu'il les utilise sur son réseau local et ne les utilise pas quand il faut passer à travers le réseau.

 

Retransmissions

TCP élimine les blocs de son partenaire à l'extrémité distante de la connexion. Si il ne reçoit pas un accusé de réception dans un délais raisonnable, il retransmet les blocs. La détermination de ce qui est raisonnable est fait par l'algorithme de retransmission de TCP.

 

Il n'y a pas d'algorithme correct mais certains sont meilleurs que d'autres, et le pire est mesuré par le nombre de retransmissions inutiles. BSD 4.2 a un algorithme de retransmission qui retransmet rapidement et souvent. C'est exactement ce que vous voudriez si vous aviez plein de machines sur un Ethernet (un réseau à faible délai et large bande passante). Si vous avez un réseau à délai relativement plus long et peu de bande passante (par exemple, des lignes à 56 kbit/s), il tend à retransmettre de façon trop agressive. Donc, il fait que les réseaux et routeurs passent plus de trafic qu'il n'est en réalité nécessaire pour une conversation donnée. Les algorithmes de retransmission s'adaptent au délai du réseau après quelques paquets, mais celui du 4.2 s'adapte lentement dans des situations de retard. Le BSD 4.3 fait un peu mieux et essaye de faire pour le mieux pour les deux mondes. Il élimine quelques retransmissions réellement rapides en supposant qu'elles sont sur un réseau à faible délai, puis dégage très rapidement. Il permet aussi que le délai soit d'environ 4 minutes avant d'abandonner et de déclarer la connexion interrompue.

 

Encore meilleure que le code 4.3 original est une version de TCP avec un algorithme de retransmission développé par Van Jacobson de LBL. Il a fait de nombreuses recherche sur la façon dont travaille l'algorithme sur les réseaux réels et l'a modifié pour obtenir un meilleur débit et soit plus facile à traiter pour le réseau. Ce code a été intégré à la dernière livraison de BSD 4.3 et peut être téléchargé de façon anonyme à ucbarpa.berkeley.edu dans le répertoire 4.3.

 

Durée de vie

L'en-tête de paquet IP contient un champ appelé durée de vie (TTL, time to live). Il est décrémenté à chaque fois que le paquet traverse un routeur. Le TTL a été conçu pour empêcher les paquets pris dans des boucles d'acheminement de passer indéfiniment sans espoir d'être livrés. Comme la définition s'inspire un peu du compte de bonds de RIP, certains systèmes mal inspirés ont réglé le champ TTL à 15 parce que le fanion injoignable dans RIP est 16. Visiblement, aucun réseau ne pourrait avoir plus de 15 bonds. L'espace RIP où les bonds sont limités se termine lorsque RIP n'est plus utilisé comme un protocole d'acheminement (par exemple, lorsque NSFnet commence à transporter le paquet). Donc, il est assez facile à un paquet d'exiger plus de 15 bonds. Ces machines vont avoir pour comportement d'être capables d'atteindre certains endroits mais pas d'autres mêmes si les informations d'acheminement paraissent correctes.

 

Résoudre le problème exige normalement des remèdes au niveau du noyau, aussi cela peut être difficile si la source n'est pas disponible.

 

Appendice A - Références à des informations complémentaires

 

1]   Quarterman and Hoskins, "Notable Computer Networks", Communications of the ACM, Vol. 29, n°10, pp. 932-971, octobre 1986.

 

2]   Tannenbaum, A., "Computer Networks", Prentice Hall, 1981.

 

[3]   Hedrick, C., "Introduction to the Internet Protocols", Via FTP anonyme sur topaz.rutgers.edu, directory pub/tcp-ip-docs, file tcp-ip-intro.doc.

 

[4]   Comer, D., "Internetworking with TCP/IP: Principles, Protocols, and Architecture", Copyright 1988, by Prentice-Hall, Inc., Englewood Cliffs, NJ, 07632 ISBN 0-13-470154-2.

 

Appendice B – Liste des RFC majeures

 

Cette liste des RFC "de base" clés a été compilée par J.K. Reynolds. C'est l'édition du 30 août 1989 de la liste.

 

RFC-768   Protocole de datagramme d'utilisateur (UDP, User Datagram Protocol)

RFC-791   Protocole Internet (IP, Internet Protocol)

RFC-792   Protocole de message de contrôle Internet (ICMP)

RFC-793   Protocole de contrôle de transmission (TCP)

RFC-821   Protocole simple de transfert de messagerie (SMTP)

RFC-822   Norme pour le format des messages de texte Internet ARPA

RFC-826   Protocole de résolution d’adresses Ethernet : conversion des adresses de protocole réseau en adresses Ethernet à 48 bits pour transmission sur un matériel Ethernet

RFC-854   Protocole Telnet

RFC-862   Protocole d'écho

RFC-894   Norme pour la transmission des datagrammes IP sur les réseaux expérimentaux Ethernet

RFC-904   Spécification formelle du protocole de passerelle extérieure

RFC-919   Diffusion des datagrammes Internet

RFC-922   Diffusion des datagrammes Internet en présence de sous-réseaux

RFC-950   Procédure standard de sous-réseautage Internet

RFC-951   Protocole Bootstrap (BOOTP)

RFC-959   Protocole de transfert de fichiers (FTP)

RFC-966   Groupes d’hôtes : une extension de diffusion groupée au protocole Internet

RFC-974   L’acheminement de la messagerie et le système des domaines

RFC-1000   Guide de référence des Request for Comments

RFC-1009   Exigences pour les routeurs de l'Internet

RFC-1010   Numéros alloués

RFC-1011   Protocoles officiels de l'Internet

RFC-1012   Bibliographie des RFC de 1 à 999

RFC-1034   Noms de domaines - Concepts et facilités

RFC-1035   Noms de domaines – Mise en œuvre et spécification

RFC-1042   Norme pour la transmission des datagrammes IP sur les réseaux IEEE 802

RFC-1048   Extensions d'informations de fabricant BOOTP

RFC-1058   Protocole d'informations d'acheminement

RFC-1059   Protocole de l'heure du réseau (NTP)

RFC-1065   Structure et identification des informations de gestion pour les internets fondés sur TCP/IP

RFC-1066   Base de données d'informations de gestion de réseau pour les internets fondés sur TCP/IP

RFC-1084   Extensions d'informations de fabricant BOOTP

RFC-1087   L'éthique et l'Internet

RFC-1095   Services et protocole communs d'informations de gestion sur TCP/IP (CMOT)

RFC-1098   Protocole simple de gestion de réseau (SNMP)

RFC-1100   Normes officielles de protocole de l'IAB

RFC-1101   Codage par le DNS des noms de réseau et autres types

RFC-1112   Extensions d'hôte pour diffusion groupée sur IP

RFC-1117   Numéros de l'Internet

 

Note : Cette liste est une portion de la liste des RFC par sujets qui peut être retrouvée au NIC à NETINFO:RFC-SETS.TXT (bien sûr, avec FTP anonyme).

 

La liste suivante n'est pas nécessaire pour la connexion à l'Internet, mais est utile pour comprendre le système des domaines, le système de la messagerie, et les routeurs.

 

RFC-974   L’acheminement de la messagerie et le système des domaines

RFC-1009   Exigences pour les routeurs de l'Internet

RFC-1034   Noms de domaines - Concepts et facilités

RFC-1035   Noms de domaines – Mise en œuvre et spécification

RFC-1101   Codage par le DNS des noms de réseau et autres types

 

 

Appendice C - Points de contact pour des informations sur le réseau

 

Centre d'informations du réseau (NIC, Network Information Center)

 

DDN Network Information Center

SRI International, Room EJ291

333 Ravenswood Avenue

Menlo Park, CA 94025

(800) 235-3155 or (415) 859-3695

mél : NIC@NIC.DDN.MIL

 

NSF Network Service Center (NNSC)

 

NNSC

BBN Systems and Technology Corporation

10 Moulton St.

Cambridge, MA 02238

(617) 873-3400

mél : NNSC@NNSC.NSF.NET

 

NSF Network Information Service (NIS)

 

NIS

Merit Inc.

University of Michigan

1075 Beal Avenue

Ann Arbor, MI 48109

(313) 763-4897

mél : INFO@NIS.NSF.NET

 

CIC

 

CSNET Coordination and Information Center

Bolt Beranek and Newman Inc.

10 Moulton Street

Cambridge, MA 02238

(617) 873-2777

mél : INFO@SH.CS.NET

 

Glossaire

 

système autonome (AS, autonomous system)

C'est un ensemble de routeurs sous le contrôle d'une seule administration qui utilisent des procédures d'acheminement compatibles et cohérentes. Généralement parlant, ce sont les routeurs gérés par une organisation particulière. Comme un routeur est connecté à deux réseaux (ou plus) il n'est habituellement pas correct de dire qu'un routeur est dans un réseau. Par exemple, le routeur qui connecte les réseaux régionaux au cœur de réseau NSF est géré par Merit et forme un système autonome. Un autre exemple, les routeurs qui connectent les campus au NYSERNET sont gérés par NYSER et forment un système autonome.

 

routeur central (core gateway)

Les routeurs sui sont au cœur de l'Internet. Ces routeurs ont une vision complète de l'accessibilité de tous les réseaux connus de l'Internet. Ils redistribuent alors les informations d'accessibilité à leurs voisins routeurs qui parlent EGP. C'est à partir d'eux que votre agent EGP (il y en a un qui agit pour vous quelque part si vous pouvez atteindre le cœur de l'Internet) trouve comment il peut joindre tous les réseaux sur l'Internet. Qui vous sont alors passés via Hello, gated, RIP. Le routeur central connecte surtout les campus à l'ARPANET, ou interconnecte l'ARPANET et le MILNET, et ils sont gérés par le BBN.

 

compte infini (count to infinity)

Symptôme d'un problème d'acheminement lorsque les informations d'acheminement sont passées en boucle à travers plusieurs routeurs. Chaque routeur incrémente la métrique de la façon appropriée et la passe au suivant. Alors que la métrique passe le long de la boucle, elle s'incrémente de valeurs toujours croissantes jusqu'à ce qu'elle atteigne le maximum pour le protocole d'acheminement utilisé, ce qui marque typiquement une panne de liaison.

 

maintien (hold down)

Lorsque un routeur découvre qu'un chemin sur le réseau est en panne, il met un temps minimum à annoncer que ce chemin est en panne (habituellement au moins deux minutes). Cela permet la propagation de l'information d'acheminement à travers le réseau et empêche la formation de chemins en boucle.

 

horizon partagé (split horizon)

Lorsque un routeur (ou groupe de routeurs travaillant de concert) accepte des informations d'acheminement provenant de plusieurs réseaux externes, mais ne passe les informations acquises d'un réseau externe à aucun des autres. C'est pour essayer d'empêcher la propagation de mauvais chemins à un réseau à cause de commérages ou d'un compte infini.

 

DDN (Defense Data Network)

Réseau de données de la Défense est le nom collectif de l'ARPANET et du MILNET. Utilisé fréquemment parce que bien que séparés, ces réseaux ont des buts opérationnels et informationnels communs.

 

Considérations pour la sécurité

 

La protection de la sécurité et de la confidentialité est un sujet sérieux et trop souvent, rien n'est fait à son sujet. Il y a quelques failles de sécurité connues (en particulier dans le contrôle d'accès) dans le BSD Unix et dans certaines mises en œuvre de services réseau. Le guide touristique n'expose pas ces problèmes (dommage).

 

Adresse de l'auteur

 

Ed Krol

University of Illinois

195 DCL

1304 West Springfield Avenue

Urbana, IL 61801-4399

téléphone : (217) 333-7886

mél : Krol@UXC.CSO.UIUC.EDU