guill.net - La page des réseaux

TCP : Transmission Control Protocol
IP : Internet Protocol
UDP : User Datagram Protocol
ICMP : Internet Control Message Protocol
ARP : Address Resolution Protocol
SNMP : Simple Network Management Protocol
RIP2 : Routing Information Protocol 2

Introduction à TCP

Le protocole TCP est défini dans le but de fournir un service de transfert de données de haute fiabilité entre deux ordinateurs "maîtres" raccordés sur un réseau de type "paquets commutés", et sur tout système résultant de l'interconnexion de ce type de réseaux.

La communication entre systèmes d'information joue un rôle croissant dans les domaines militaires, institutionnels, scientifiques et commerciaux.

Au fur et à mesure que les réseaux de communication informatiques à caractère stratégiques ou tactiques sont déployés, il devient essentiel de trouver un moyen d'interconnexion de ces réseaux, et des standards de transmission de données permettant de supporter une vaste gamme d'applications. Anticipant le besoin de tels standards, le député et sous-secrétaire d'état à la recherche de la Défense Américaine a officialisé le protocole décrit ici en tant que base pour la standardisation des processus d'intercommunication de données du Département de la Défense Américaine (DoD).

TCP est un protocole sécurisé orienté connexion conçu pour s'implanter dans un ensemble de protocoles multicouches, supportant le fonctionnement de réseaux hétérogènes. TCP fournit un moyen d'établir une communication fiable entre deux tâches exécutées sur deux ordinateurs autonomes raccordés à un réseau de données. Le protocole TCP s'affranchit le plus possible de la fiabilité intrinsèques des couches inférieures de communication sur lesquelles il s'appuie. TCP suppose donc uniquement que les couches de communication qui lui sont inférieures lui procurent un service de transmission de paquet simple, dont la qualité n'est pas garantie.

En principe, TCP doit pouvoir supporter la transmission de données sur une large gamme d'implémentations de réseaux, depuis les liaisons filaires câblées, jusqu'aux réseaux commutés, ou asynchrones.

TCP s'intègre dans une architecture multicouche des protocoles, juste au-dessus du protocole Internet IP. Ce dernier permet à TCP l'envoi et la réception de segments de longueur variable, encapsulés dans un paquet Internet appelé aussi "datagramme". Le datagramme Internet dispose des mécanismes permettant l'adressage d'un service TCP source et un destinataire, quelles que soient leur position dans le réseau. Le protocole IP s'occupe aussi de la fragmentation et du réassemblage des paquets TCP lors de la traversée de réseaux de plus faibles caractéristiques. Le protocole IP transporte aussi les informations de priorité, compartimentation et classification en termes de sécurité relatives aux segments TCP. Ces informations se retrouvent alors transmises de bout en bout de la communication.

De grandes parties de ce document sont écrites dans un contexte où les implémentations TCP sont concomitantes à d'autres protocoles de haut niveau dans la même machine. Certains systèmes informatiques seront raccordés au réseau via un frontal qui accueillera les fonctions TCP et IP, ainsi que les protocoles réseau de bas niveau. La spécification TCP décrit une interface à destination des applications de niveau supérieur, y compris dans le cas d'une architecture avec un frontal, pour autant que les protocoles "poste vers frontal" soient implémentés.

TCP prétend fournir un service de communication de processus à processus, dans un environnement réseau complexe. TCP est défini comme un protocole de communication "host to host", c'est à dire de maître à maître (par opposition à "central à terminal").

Spécifications fonctionnelles de TCP

Port source: 16 bits Le numéro de port de la source.

Port Destinataire : 16 bits Le numéro de port du destinataire.

Numéro de séquence : 32 bits Le numéro du premier octet de données par rapport au début de la transmission (sauf si SYN est marqué). Si SYN est marqué, le numéro de séquence est le numéro de séquence initial (ISN) et le premier octet à pour numéro ISN+1.

Accusé de réception : 32 bits Si ACK est marqué ce champ contient le numéro de séquence du prochain octet que le récepteur s'attend à recevoir. Une fois la connexion établie, ce champ est toujours renseigné.

Data Offset : 4 bits La taille de l'en-tête TCP en nombre de mots de 32 bits. Il indique là ou commence les données. L'en-tête TCP, dans tous les cas à une taille correspondant à un nombre entier de mots de 32 bits.

Réservé : 6 bits Réservés pour usage futur. Doivent nécessairement être à 0.

Bits de contrôle : 6 bits (de gauche à droite): URG: Pointeur de données urgentes significatif ACK: Accusé de réception significatif PSH: Fonction Push RST: Réinitialisation de la connexion SYN: Synchronisation des numéros de séquence FIN: Fin de transmission

Fenêtre : 16 bits Le nombre d'octets à partir de la position marquée dans l'accusé de réception que le récepteur est capable de recevoir.

Checksum : 16 bits Le Checksum est constitué en calculant le complément à 1 sur 16 bits de la somme des compléments à 1 des octets de l'en-tête et des données pris deux par deux (mots de 16 bits). Si le message entier contient un nombre impair d'octets, un 0 est ajouté à la fin du message pour terminer le calcul du Checksum. Cet octet supplémentaire n'est pas transmis. Lors du calcul du Checksum, les positions des bits attribués à celui-ci sont marqués à 0. Le Checksum couvre de plus une pseudo en-tête de 96 bits préfixée à l'en-tête TCP. Cette pseudo en-tête comporte les adresses Internet source et destinataires, le type de protocole et la longueur du message TCP. Ceci protège TCP contre les erreurs de routage. Cette information sera véhiculée par IP, et est donnée comme argument par l'interface TCP/Réseau lors des appels d'IP par TCP.

La longueur TCP compte le nombre d'octets de l'en-tête TCP et des données du message, en excluant les 12 octets de la pseudo en-tête.

Pointeur de données urgentes : 16 bits Communique la position d'une donnée urgente en donnant son décalage par rapport au numéro de séquence. Le pointeur doit pointer sur l'octet suivant la donnée urgente. Ce champs n'est interprété que lorsque URG est marqué.

Options : variable Les champs d'option peuvent occuper un espace de taille variable à la fin de l'en-tête TCP. Ils formeront toujours un multiple de 8 bits. Toutes les options sont prises en compte par le Checksum. Un paramètre d'option commence toujours sur un nouvel octet. Il est défini deux formats types pour les options: Cas 1: Option mono-octet. Cas 2: Octet de type d'option, octet de longueur d'option, octets de valeurs d'option. La longueur d'option prend en compte l'octet de type, l'octet de longueur lui-même et tous  les octets de valeur et est exprimée en octets. Notez que la liste d'option peut être plus courte que ce que l'offset de données pourrait le faire supposer. Un octet de remplissage (padding) devra être dans ce cas rajouté après le code de fin d'options. Ce octet est nécessairement à 0. TCP doit implémenter toutes les options. Actuellement, les options définies sont (type indiqué en octal):

Type  Longueur     Description
----    ------            -------
0           -           Fin de liste d'option
1           -           Nop
2           4          Taille de segment maximal

Définition des options spécifiques :

Fin de liste d'options

Ce code indique la fin du champ d'options. Sa position peut ne pas coïncider avec l'indication du début du champ de données marqué dans l'Offset de données. Il doit être placé après toutes les options, et non après chaque option. Il ne doit être utilisé que dans le cas ou la fin des options ne coïncide pas avec le début du champ de données.

No-Operation:

Cette option peut être utilisée entre deux options, par exemple pour aligner le début d'une option sur un début de mot de 16 bits. L'utilisation de ce séparateur n'est pas une obligation. L'implémentation doit donc prévoir de pouvoir prendre en compte un option même au milieu d'un mot.

Taille maximale de segment

Donnée d'option : Taille maximale de segment: 16 bits Si cette option est présente, elle communique à l'émetteur la taille maximale des segments qu'il pourra envoyer. Ce champ doit être envoyé dans la requête de connexion initiale (avec SYN marqué). Si cette option est absente, le segment pourra être pris de n'importe quelle taille.

Bourrage (padding): variable Les octets de bourrage terminent l'en-tête TCP: de sorte que le nombre d'octet de celle-ci soit toujours multiple de 4 (32 bits) de sorte que l'offset de données marqué dans l'en-tête corresponde bien au début des données applicatives.

Etablissement et rupture des connexions TCP

TCP indique un identificateur de port. Comme ces identificateurs sont choisis indépendamment par chaque extrémité, ils peuvent se révéler identiques. L'adresse unique d'une communication TCP est obtenue par la concaténation de l'adresse Internet avec l'identificateur du port sélectionné, constituant ainsi ce que l'on nome une "socket". Cette socket est alors unique dans l'ensemble du réseau.

Une connexion de base est définie par un couple de sockets, l'un définissant l'émetteur, l'autre le récepteur. Un socket peut devenir le destinataire ou la source pour plusieurs sockets distinctes. La connexion est résolument bidirectionnelle, et prend la dénomination de "full-duplex".

TCP est libre d'associer ses ports avec les processus exécutés sur sa machine. Cependant, quelques règles ont été établies pour l'implémentation. Ont été définis un certain nombre de sockets "réservés" que TCP ne doit associer qu'avec certains processus bien identifiés. Ceci revient à dire que certains processus peuvent s'attribuer la propriété de certains ports, et ne pourront initier de communication que sur ceux-ci. (Actuellement, cette "propriété" est issue d'une implémentation locale, mais nous envisageons une commande utilisateur Request Port, ou une autre méthode pour assigner automatiquement un ensemble de ports à une application, par exemple en utilisant quelques bits de poids fort du numéro de port pour coder l'application).

Une connexion est demandée par activation de la commande OPEN indiquant le port local et les paramètres du socket distant. En retour, TCP répond par un nom local (court) symbolique que l'application utilisera dans ses prochains appels. Plusieurs choses doivent être retenues à propos des connexions. Pour garder la trace de cette connexion, nous supposons l'existence d'une structure de données appelée Transmission Control Block (TCB). Une des stratégies d'implémentation est de dire que le nom local donné est un pointeur vers le TCB associé à cette connexion. La commande OPEN spécifie en outre si le processus de connexion doit être effectué jusqu'à son terme, ou s'il s'agit d'une ouverture en mode passif.

Une ouverture passive signifie que le processus de connexion se met en attente d'une demande de connexion plutôt que de l'initier lui-même. Dans la plupart des cas, ce mode est utilisé lorsque l'application est prête à répondre à tout appel. Dans ce cas, le socket distant spécifié n'est composé que de zéros (socket indéfini). Le socket indéfini ne peut être passé à TCP que dans le cas d'une connexion passive.

Un utilitaire désireux de fournir un service à un processus non identifié pourra initier une connexion passive. Tout appelant effectuant une requête de connexion sur le socket local sera reconnu. Il sera bon de garder en mémoire que ce socket est associé à ce service.

Les sockets "réservés" sont un bon moyen d'associer à priori des ports à des applications standard. Par exemple, le serveur "Telnet" est en permanence associé à un socket particulier, d'autres étant réservés pour les transferts de fichiers, sessions de terminal distant, générateur de texte, écho (ces deux pour des besoins de test), etc. Un socket peut être réservé à la fonction de serveur de domaines, transcodant les "noms explicites" de services en sockets Internet. Si le concept même de l'assignation à priori de sockets fait partie de TCP, l'assignation concrète des sockets "réservés" est définie dans un autre document.

Les processus peuvent ouvrir une connexion passive et attendre qu'une connexion active les impliquant provienne d'une autre machine. TCP aura la charge d'avertir l'application qu'une communication est établie. Deux processus émettant au même moment une requête de connexion l'un vers l'autre se retrouveront normalement connectés. Cette souplesse est indispensable pour assurer un bon fonctionnement du réseau composé d'éléments totalement asynchrones.

Les deux cas de conclusion d'une communication impliquant une connexion passive et une active sont les suivants. Soit le socket distant a été précisé lors de la requête de connexion passive, auquel cas seule une requête de connexion du distant attendu vers le local peut aboutir à l'établissement d'une communication. Soit le socket distant a été laissé indéfini, et toute requête de connexion sur le socket local, d'où qu'elle vienne aboutit à une communication valide. D'autres fonctionnalités permettront une acceptation sur correspondance partielle entre sockets.

Si plusieurs requêtes de connexion passive sont en attente (enregistrées dans la table de TCBs) pour le même socket local, et qu'une demande de connexion active provient de l'extérieur, le protocole prévoit de d'abord chercher s'il l'une des requêtes dont le socket distant a été clairement exprimé correspond à celui de la demande. Si tel est le cas, ce socket sera activé. Sinon, c'est une requête "indéfinie" qui sera activée.

La procédure de connexion utilise le bit de contrôle de synchronisation (SYN) et suppose la transmission de trois messages. Cet échange est appelé "négociation ternaire".

La connexion suppose le rendez-vous d'un segment marqué du bit SYN et d'une requête locale (TCB), chacun des deux étant créé par l'exécution d'une commande de connexion. La correspondance entre le socket arrivé et le socket attendu détermine l'opportunité de la connexion. Celle-ci ne devient réellement établie que lorsque les deux numéros de séquence ont été synchronisés dans les deux directions.

La rupture d'une connexion suppose l'émission de segments, marqués du bit FIN.

Communication de données avec TCP

Les données circulant dans la connexion ouverte doivent être vues comme un flux d'octets. L'application indique dans la commande SEND si les données soumises lors de cet appel (et toutes celles en attente) doivent être immédiatement émises par l'activation du flag PUSH.

Par défaut, TCP reste libre de stocker les données soumises par l'application pour les émettre à sa convenance, jusqu'à ce que le signal PUSH soit activé. Dans ce dernier cas, toutes les données non émises doivent être envoyées. Symétriquement, lorsque le TCP récepteur voit le flag PUSH marqué, il devra passer immédiatement toutes les données collectées à l'application destinataire.

Il n'y a à priori aucune corrélation entre la fonction PUSH et les limites des segments. Les données d'un segment peuvent être le résultat d'une seule commande SEND, en tout ou partie, ou celui de plusieurs appels SEND. La fonction de la fonction push et du flag PUSH est de forcer la transmission immédiate de toutes les données latentes entre les deux TCP. Il ne s'agit aucunement d'une fonction d'enregistrement (Cf. langage Perl).

Il y a par contre une relation entre la fonction push et l'usage des tampons dans l'interface TCP/application. Chaque fois qu'un flag PUSH est associé à des données stockées dans le tampon de réception, celui-ci est intégralement transmis à l'application même s'il n'est pas plein. Si le tampon est rempli avant qu'un flag PUSH soit vu, les données sont transmises à l'application par éléments de la taille du tampon.

TCP dispose d'un moyen d'avertir l'application que, dans le flux de données qu'il est en train de lire, au delà de la position de lecture courante, des données de caractère urgent sont apparues. TCP ne définit pas ce que l'application est sensée faire lorsqu'elle est avisée de la présence de ces données. En général, c'est l'implémentation de l'application qui traitera ces données urgentes selon ses besoins propres.

Priorité et sécurité dans TCP

TCP utilise le champ "type de service" et les options de sécurité du protocole Internet pour fournir les fonctions relatives à la priorité et la sécurité des communications TCP, sur un principe de "détection". Tous les modules TCP ne fonctionneront pas nécessairement dans un environnement sécurisé à plusieurs niveaux; certains pourront être limités à un fonctionnement sans sécurité, d'autres ne pourront prendre en compte qu'un seul niveau à la fois. Par conséquent, les implémentations TCP ne pourront répondre en termes de sécurité qu'à un sous ensembles de cas du modèle sécurisé multi-niveaux.

Les modules TCP opérant dans un environnement sécurisé à plusieurs niveaux devront correctement renseigner les segments sortants en termes de sécurité, niveau de sécurité, et priorité. De tels modules TCP doivent fournir aux applications supérieures telles que Telnet ou THP une interface leur permettant de spécifier ces paramètres. 

Introduction à IP

Description fonctionnelle

La fonction ou rôle du Protocole Internet est d'acheminer les datagrammes à travers un ensemble de réseaux interconnectés. Ceci est réalisé en transférant les datagrammes d'un module Internet à l'autre jusqu'à atteindre la destination. Les modules Internet sont des programmes exécutés dans des hôtes et des routeurs du réseau Internet. Les datagrammes sont transférés d'un module Internet à l'autre sur un segment particulier de réseau selon l'interprétation d'une adresse Internet. De ce fait, un des plus importants mécanismes du protocole Internet est la gestion de cette adresse Internet.

Lors de l'acheminement d'un datagramme d'un module Internet vers un autre, les datagrammes peuvent avoir éventuellement à traverser une section de réseau qui admet une taille maximale de paquet inférieure à celle du datagramme. Pour surmonter ce problème, un mécanisme de fragmentation est géré par le protocole Internet.

Adressage

Une distinction doit être faite entre noms, adresses, et chemins. Un nom indique ce que nous cherchons. Une adresse indique où cela se trouve. Un chemin indique comment y aboutir. Le protocole Internet s'occupe essentiellement des adresses. C'est à des protocoles de niveau plus élevé (ex., hôte-vers-hôte ou application) que revient la tâche de lier des noms à des adresses. Le module Internet déduit de l'adresse Internet une adresse réseau local. La tâche qui consiste à transcrire l'adresse de réseau local en termes de chemin (ex., sur un réseau local ou dans un routeur) revient au protocole de bas niveau.

Les adresses ont une longueur fixe de 4 octets (32 bits). Une adresse commence toujours par un numéro de réseau, suivi d'une adresse locale (appelée le champ "reste") codant l'adresse de l'hôte sur ce réseau. Il existe trois formats ou classes d'adresses Internet : pour la classe A, le bit de poids fort vaut zéro, les 7 bits suivants désignent le réseau, les derniers 24 bits désignent l'adresse locale de la machine; pour la classe B, les deux bits de poids fort valent 1 et 0, les 14 bits suivants désignent le réseau et les 16 derniers bits l'adresse locale de machine ; pour la classe C, les trois bits de poids fort forment le schème 110, les 21 bits suivants forment l'adresse réseau et les 8 derniers bits l'adresse locale.

La transcription d'adresse Internet en adresses de réseau local doit être sujette à quelques précautions ; un hôte physique unique peut abriter plusieurs adresses Internet distinctes comme s'il s'agissait de plusieurs hôtes indépendants. Certains hôtes peuvent disposer de plusieurs interfaces physiques (multi-homing).

De ce fait, il faudra pouvoir considérer le cas d'un hôte à plusieurs interfaces physiques chacune abritant plusieurs adresses Internet distinctes.

Des exemples de répartition d'adresses peuvent être trouvés dans "Address Mappings" (rfc 1060).

Fragmentation

La fragmentation du datagramme Internet devient nécessaire dès lors qu'un datagramme de grande taille arrive sur une portion de réseau qui n'accepte la transmission que de paquets plus courts.

Un datagramme Internet peut être spécifié "non fractionnable" Un tel datagramme Internet ne doit jamais être fragmenté quelques soient les circonstances. Si un datagramme Internet non fractionnable ne peut être acheminé jusqu'à sa destination sans être fragmenté, alors il devra être rejeté.

La fragmentation, la transmission et le réassemblage à travers un réseau local hors de vue d'un module de protocole Internet est appelée fragmentation Intranet .

Les procédures de fragmentation et réassemblage Internet doivent pouvoir "casser" un datagramme Internet en un nombre de "fragments" arbitraire et quelconque pourvu que le réassemblage soit possible. Le récepteur des fragments utilise le champ d'identification pour s'assurer que des fragments de plusieurs datagrammes ne puissent être mélangés. Le champ "Fragment Offset" indique au récepteur la position du fragment reçu dans le datagramme original. Les champs "Fragment Offset" et "Longueur Totale" déterminent la portion du datagramme original que représente le fragment. L'indicateur bit "Dernier Fragment" indique (lors de sa remise à zéro) au récepteur qu'il s'agit du dernier fragment. Ces champs véhiculent suffisamment d'information pour réassembler les datagrammes.

Le champ d'identification sert à distinguer les fragments d'un datagramme de ceux d'un autre datagramme. Le module Internet émetteur d'un datagramme Internet initialise le champ d'identification à une valeur qui doit être unique pour cette paire source-destination et pour ce protocole pendant toute la durée de transmission de ce datagramme. Le module Internet terminant l'émission d'un datagramme met le bit "Dernier Fragment" et le champ "Fragment Offset" à zéro.

Pour fragmenter un long datagramme, un module Internet (par exemple, dans un routeur), crée deux nouveaux datagrammes et copie le contenu des champs d'en-tête Internet originaux dans les deux nouvel en-têtes. Les données du datagramme original sont divisées en deux portions, la première d'une taille multiple de 8 octets (64 bit) (la taille de la seconde portion n'est donc pas nécessairement un multiple de 8 octets). Nous appellerons le nombre de blocs de 8 octets dans la première portion NBF (ou Nombre de Blocs du Fragment). La première portion de données est placée dans le premier des deux nouveaux datagramme, et le champ "Longueur Totale" est renseigné avec la taille de ce datagramme.

Le bit "Dernier Fragment" est basculé à 1. La seconde portion de données est placée dans le second des deux nouveaux datagrammes, et le champ "longueur totale" est renseigné avec la taille du second datagramme. Le bit "Dernier Fragment" est placé à la même valeur que celui du datagramme original. Le champ "Fragment Offset" du second datagramme constitué est renseigné avec la valeur du même champ du datagramme original plus NFB.

Cette procédure peut être généralisée à une fragmentation en n fragments, plutôt que les deux décrits ci-dessus.

Pour réassembler les fragments d'un datagramme Internet, un module Internet (par exemple dans un hôte destinataire) recombine les datagrammes dont les valeurs des quatre champs suivants sont identiques : identification, source, destination, et protocole. La recombinaison est réalisée en replaçant la portion de donnée contenue dans chaque fragment dans un tampon à la position relative indiquée par le champ "Fragment Offset" lu dans l'en-tête correspondant. Le premier fragment sera donc placé en début de tampon, et le dernier fragment récupéré aura le bit "Dernier Fragment" à zéro.

Spécification de IP

Un résumé du contenu de l'en-tête Internet suit :

Version : 4 bits

Le champ Version renseigne sur le format de l'en-tête Internet. Ce document décrit le format de la version 4 du protocole.

Longueur d'En-Tête : 4 bits

Le champ Longueur d'En-Tête (LET) code la longueur de l'en-tête Internet, l'unité étant le mots de 32 bits, et de ce fait, marque le début des données. Notez que ce champ ne peut prendre une valeur en dessous de 5 pour être valide.

Type de Service : 8 bits

Le Type de Service donne une indication sur la qualité de service souhaitée, qui reste cependant un paramètre "abstrait". Ce paramètre est utilisé pour "guider" le choix des paramètres des services actuels lorsqu'un datagramme transite dans un réseau particulier. Certains réseaux offrent un mécanisme de priorité, traitant préférentiellement un tel trafic par rapport à un trafic moins prioritaire (en général en acceptant seulement de véhiculer des paquets d'un niveau de priorité au dessus d'un certain seuil lors d'une surcharge momentanée). Principalement, le choix offert est une négociation entre les trois contraintes suivantes : faible retard, faible taux d'erreur, et haut débit.

Bits 0-2 : Priorité.
Bit 3 : 0 = Retard standard, 1 = Retard faible.
Bits 4 : 0 = Débit standard, 1 = Haut débit.
Bits 5 : 0 = Taux d'erreur standard 1 = Taux d'erreur faible.
Bit 6-7 : Réservé.

Priorité
111 -  Network Control
110 -  Internetwork Control
101 -  CRITIC/ECP
100 -  Flash Override
011 -  Flash
010 -  Immediate
001 -  Priority
000 -  Routine

L'utilisation des indications en termes de retard, débit, et qualité de transmission peut augmenter le "coût" (d'un certain point de vue) du service. Dans la plupart des réseaux, de meilleures performances pour l'un de ces paramètres s'obtient au prix d'une dégradation des performances pour un autre. A moins d'une situation exceptionnelle, il sera préférable de ne pas activer plus de deux optimisations sur les trois.

Le "Type de Service" sert à préciser le traitement effectué sur le datagramme pendant sa transmission à travers Internet. Des exemples d'association de ce code aux améliorations de service proposées par des réseaux existants comme AUTODIN II, ARPANET, SATNET, et PRNET sont données dans la RFC 795 "Service Mappings" [8].

La priorité dite "Network Control" est stipulée comme étant une priorité à l'intérieur d'un seul réseau. Le fait d'utiliser cette option instaure une priorité pour chaque section traversée. La priorité "Internetwork Control" n'est gérée que par les routeurs. Si l'utilisation de ces priorités ont une signification particulière ou supplémentaire pour l'un des réseaux, il est de la responsabilité de ce dernier de lire et d'interpréter les présentes informations.

Longueur Totale : 16 bits

Le champ "Longueur Totale" est la longueur du datagramme entier y compris en-tête et données, mesurée en octets. Ce champ ne permet de coder qu'une longueur de datagramme d'au plus 65,535 octets. Une telle longueur rendrait de toutes façon les datagrammes impossible à gérer pour la plus grande partie des réseaux. Les hôtes devront au moins pouvoir accepter des datagrammes d'une longueur jusqu'à 576 octets (qu'il s'agisse d'un datagramme unique ou d'un fragment). Il est de même recommandé que des hôtes ne décident d'envoyer des datagrammes de plus de 576 octets que dans la mesure où ils sont sûrs que la destination est capable de les accepter.

Le nombre 576 a été choisi pour permettre à un bloc de données de taille raisonnable d'être transmis dans un datagramme, tenant compte des données à ajouter pour constituer les en-têtes de protocole. Par exemple, cette taille permet la transmission d'un bloc de 512 octets, plus 64 octets d'en-tête dans un datagramme unique. (NdT : je rappelle ici que la taille de 512 octets correspond à un secteur sur la plupart des supports de stockage) La taille maximale d'un en-tête Internet étant de 60 octets, et sa taille typique étant de 20 octets, ce nombre permet de conserver une bonne marge pour les données protocolaires de plus haut niveau.

Identification : 16 bits

Une valeur d'identification assignée par l'émetteur pour identifier les fragments d'un même datagramme.

Flags : 3 bits
Divers commutateurs de contrôle.
Bit 0 : réservé, doit être laissé à zéro
Bit 1: (AF)              0 = Fragmentation possible, 1 = Non fractionnable.
Bit 2: (DF)              0 = Dernier fragment, 1 = Fragment intermédiaire.

 Fragment Offset : 13 bits

Ce champ indique le décalage du premier octet du fragment par rapport au datagramme complet. Cette position relative est mesurée en blocs de 8 octets (64 bits). Le décalage du premier fragment vaut zéro.

Durée de vie : 8 bits

Ce champ permet de limiter le temps pendant lequel un datagramme reste dans le réseau. Si ce champ prend la valeur zéro, le datagramme doit être détruit. Ce champ est modifié pendant le traitement de l'en-tête Internet. La durée de vie est mesurée en
secondes. Chaque module Internet doit retirer au moins une unité de temps à ce champ, même si le traitement complet du datagramme par le module est effectué en moins d'une seconde. De ce fait, cette durée de vie doit être interprétée comme la limite absolue maximale de temps pendant lequel un datagramme peut exister. Ce mécanisme est motivé par la nécessité de détruire les datagrammes qui n'ont pu être acheminés, en limitant la durée de vie même du datagramme.

Protocole : 8 bits

Ce champ indique quel protocole de niveau supérieur est utilisé dans la section données du datagramme Internet. Les différentes valeurs admises pour divers protocoles sont listée dans la RFC "Assigned Numbers"  [rfc1060].
 

Checksum d'en-tête : 16 bits

Un Checksum calculé sur l'en-tête uniquement. Comme certains champs de l'en-tête
sont modifiés (ex., durée de vie) pendant leur transit à travers le réseau, ce Checksum doit être recalculé et vérifié en chaque point du réseau où l'en-tête est réinterprétée.

L'algorithme utilisé pour le Checksum est le suivant :

On calcule le complément à un sur 16 bits de la somme des compléments à un de tous les octets de l'en-tête pris par paires (mots de 16 bits). Lorsque l'on calcule le Checksum, on considère une en-tête dont le champ réservé pour ce même Checksum
vaut zéro.

L'algorithme de Checksum peut paraître élémentaire mais l'expérimentation a montré que cette technique était suffisante. Il se peut que cet algorithme soit plus tard remplacé par un calcul de type CRC, suivant la nécessité future.

Adresse source : 32 bits
L'adresse Internet de la source.

Adresse destination : 32 bits
L'adresse Internet du destinataire.

Options : variable

Les datagrammes peuvent contenir des options. Celles-ci doivent être implémentées par tous les modules IP (hôtes et outeurs). Le caractère "optionnel" concerne leur transmission, et non leur implémentation.

Dans certains environnements, l'option de sécurité peut être obligatoire dans tous les datagrammes.

Le champ d'option est de longueur variable. Un datagramme peut comporter zéro ou plus options. Voici les deux formats possibles d'une option :

     Cas 1: Une option codée sur un seul octet.
     Cas 2: Un octet codant le type d'option, un octet donnant la taille de l'option, les octets de données d'option.
La taille de l'option compte tous les octets de l'option y compris le type, son propre octet et tous les octets de donnée d'option.

L'octet de type d'option est composé de trois champs de bits :
                        1 bit                             indicateur de recopie
                        2 bits                             classe d'option
                       5 bits                             numéro d'option.

Introduction

Le protocole User Datagram Protocol (UDP) est défini dans le but de fournir une communication par paquet unique entre deux processus dans un environnement réseau étendu. Ce protocole suppose l'utilisation du protocole IP comme support de base à la communication.

Ce protocole définit une procédure permettant à une application d'envoyer un message court à une autre application, selon un mécanisme minimaliste. Ce protocole est transactionnel, et ne garantit ni la délivrance du message, ni son éventuelle duplication. Les applications nécessitant une transmission fiabilisée et ordonnée d'un flux de données implémenteront de préférence le protocole TCP (Transmission Control Protocol) .

Format :

Champs

Le Port Source est un champ optionnel. Lorsqu'il est significatif, il indique le numéro de port du processus émetteur, et l'on supposera, en l'absence d'informations complémentaires, que toute réponse devra y être dirigée. S'il n'est pas utilisé, ce champ conservera une valeur 0.

Le Port Destinataire a une signification dans le cadre d'adresses Internet particulières.

La Longueur compte le nombre d'octets dans le datagramme entier y compris le présent en-tête. (Et par conséquent la longueur minimale mentionnée dans ce champ vaut huit, si le datagramme ne transporte aucune donnée).

Le Checksum se calcule en prenant le complément à un de la somme sur 16 bits des compléments à un calculé sur un pseudo en-tête constitué de l'information typique d'une en-tête IP, l'en-tête UDP elle-même, et les données, le tout additionné d'un octet nul éventuel afin que le nombre total d'octets soit pair.

La pré en-tête ajoutée avant l'en-tête UDP contient l'adresse IP source, l'adresse IP destinataire, le code de protocole, et la longueur du segment UDP. Cette information permet d'augmenter l'immunité du réseau aux erreurs de routage de datagrammes. La procédure de calcul du Checksum est la même que pour TCP.

Si le calcul du checksum vaut zéro, il sera transmis tous ses bits à un ( le complément à un ). UN Checksum transmis avec une valeur zéro a effectivement une signification particulière. Dans ce cas, le segment indique qu'aucun Checksum n'a été calculé
(pour des besoins de mise au point ou pour des protocoles de niveaux supérieurs qui rendent cette vérification inutile).

Interface Utilisateur

L'interface utilisateur doit permettre l'ouverture de nouveaux ports de réception, la réception des données et leur transmission ainsi que celle de l'adresse source à l'application sur le port de réception mis en place, et doit mettre en place une
commande permettant l'émission d'un datagramme, par laquelle seront spécifiés les données, l'adresse et ports source et destination à utiliser.

Interface IP
 

Le module UDP doit extraire les adresses source et destination de l'en-tête IP, et vérifier le numéro de protocole. Une interface UDP/IP plausible pourrait retourner le datagrammeentier y compris l'en-tête Internet en réponse du datagramme reçu. Une
interface devra pour cela permettre à UDP de passer un datagramme Internet complet avec une en-tête IP à la couche IP elle même pour émission. IP n'aura plus qu'à vérifier la cohérence des champs d'en-tête IP préparés par UDP et calculer le Checksum.

Applications du Protocole

Ce protocole sera utilisé principalement pour les communications avec les serveurs de noms de domaines , et dans les transactions utilisant le protocole Trivial File Transfer.

Numéro de protocole

Ce protocole porte le numéro 17 (21 en octal) lorsqu'il est transporté par le Protocole Internet. D'autres numéros de protocoles pour d'autres couches support sont données dans la référence .

Introduction

Le Protocole Internet (IP)  est utilisé pour la transmission de datagrammes de hôte à hôte à l'intérieur d'un système de réseaux interconnectés appelé Catenet . Les appareils raccordant les réseaux entre eux sont appelés des Routeurs. Ces
routeurs communiquent entre eux en utilisant le protocole Routeur à Routeur (GGP) afin d'échanger des informations de contrôle et de gestion du réseau. Occasionnellement, un routeur ou un hôte destinataire peut avoir à communiquer
vers l'émetteur du datagramme, par exemple, pour signaler une erreur de traitement du datagramme. C'est dans cette perspective qu'a été mis en place le protocole Internet Control Message Protocol (ICMP). Il s'appuie sur le support de base fourni par IP comme s'il s'agissait d'un protocole d'une couche supérieure. ICMP n'en reste pas moins une partie intégrante du protocole IP, et doit de ce fait être implémenté dans chaque module IP.

Les messages ICMP sont envoyés dans diverses situations: par exemple, lorsqu'un datagramme ne peut pas atteindre sa destination, lorsque le routeur manque de réserve de mémoire pour retransmettre correctement le datagramme, ou lorsque le
routeur décode de viser l'hôte destinataire via une route alternative pour optimiser le trafic.

Le protocole Internet n'est pas, dans sa définition, absolument fiable. Le but de ces messages de contrôle est de pouvoir signaler l'apparition d'un cas d'erreur dans l'environnement IP, pas de rendre IP fiable. Aucune garantie que le datagramme soit
acheminé ni qu'un message de contrôle soit retourné, de peut être donnée. Certains datagrammes pourront se perdre dans le réseau sans qu'aucun message de contrôle ne le signale. Les protocoles de niveau supérieur s'appuyant sur une
couche IP devront implémenter leurs propres mécanismes de contrôle d'erreur et de retransmission si leur objet nécessite un circuit de communication sécurisé.

Les messages ICMP reportent principalement des erreurs concernant le traitement d'un datagramme dans un module IP. Pour éviter de ne pas entrer dans un cercle vicieux de réémission de message de contrôle en réponse à un autre message de
contrôle et ce sans fin, aucun message ICMP ne sera réémis en réponse à un message ICMP. De même les messages ICMP ne seront transmis qu'en réponse à un traitement erroné du fragment zéro dans le cas d'un datagramme fragmenté. (Le fragment zéro est celui dont l'offset vaut zéro).

Formats de message

Les messages ICMP sont émis en utilisant l'en-tête IP de base. Le premier octet de la section de données du datagramme est le champ de type ICMP; Sa valeur détermine le format du reste des données dans le datagramme ICMP.

Résumé des types de Message (champ Type)
 0    Réponse Echo
 3    Destination non accessible
 4    Contrôle de flux
 5    Redirection
 8    Echo
 11  Durée de vie écoulée
 12  Erreur de Paramètre
 13  Marqueur temporelle
 14  Réponse à marqueur temporel
 15  Demande d'information
 16 Réponse à demande d'information

Champ Identifiant : un identifiant pour aider à qualifier les réponses/requêtes (souvent à zéro)

Champ Numéro de séquence : un numéro de séquence pour aider à qualifier les réponses/requêtes (à zéro)

1.Introduction

Les adresses IP sont attribuées indépendamment des adresses matérielles des machines. Pour envoyer un datagramme dans l'internet, le logiciel réseau doit convertir  l'adresse IP en une adresse physique qui est utilisée pour transmettre la trame. Si
l'adresse physique est un entier court, elle peut être facilement modifiée pour lui faire correspondre l'adresse machine IP. Sinon, la traduction doit être effectuée dynamiquement.

C'est le protocole ARP qui effectue cette traduction en s'appuyant sur le réseau physique. ARP permet aux machines de résoudre les adresses sans utiliser de table statique. Une machine utilise ARP pour déterminer l'adresse physique destinataire en diffusant (broadcast), sur le sous réseau, une requête ARP qui contient l'adresse IP à traduire. La machine possédant l'adresse IP concernée répond en renvoyant son adresse physique. Pour redre ARP plus performant, chaque machine tient à jour, en
mémoire, une table des adresses résolues et réduit ainsi le nombre d'émissions en mode broadcast.

2.Spécifications

La structure d'une trame ARP est définie ci-dessous :

Champs

Type Hardware : spécifie le type de l'interface hardware

Type de protocole : spécifie le type du protocole de haut niveau émis par l'expéditeur

Hlen : longueur de l'adresse hardware

Plen :  longueur de l'adresse de haut niveau

Opération : type de l'opération effectuée :
1 Requête ARP
2 Réponse ARP
3 Requête RARP
4 Réponse RARP
5 Requête RARP dynamique
6 Réponse RARP dynamique
7 Erreur RARP dynamique
8 Requête InARP
9 Réponse InARP

Adresse hardware de l'expéditeur : explicite

Adresse protocole de l'expéditeur : explicite

Adresse hardware du destinataire : explicite

Adresse protocole du destinataire : explicite 

1.Introduction

Le protocole SNMP est le langage que les agents et les stations de gestion (managers) utilisent pour communiquer. C'est un protocole de type question/réponse asynchrone. Ce protocole est situé au niveau application du modèle OSI, c'est lui qui définit la structure formelle des communications. SNMP est encapsulé dans des trames UDP.

La MIB (Management Information Base) regroupe l'ensemble des variables relatives aux matériels et aux logiciels supportés par le réseau, et définit les objets de gestion dans l'environnement TCP/IP.

La SMI (Structure of Management Information), définit comment sont représentées, dans la MIB, les informations relatives aux objets de gestion et comment sont obtenues ces informations.

Les stations interrogent donc les agents pour observer leur fonctionnement et leur envoient des commandes pour leur faire exécuter certaines taches. Les agents renvoient les informations requises  aux stations de gestion. Certains événements du
réseau, tels que des erreurs de transmission, peuvent déclencher des alarmes envoyées aux stations de gestion. Cependant, l'envoi de messages de façon spontanée de l'agent vers le manager est limité. Les managers effectuent une interrogation
périodique des agents de manière à vérifier leur état. La structure des paquets est définie en utilisant la syntaxe ASN1 (Abstract Syntax Notation).

SNMP a l'avantage d'être simple, cependant il a des capacités très limités au niveau sécurité, principalement pour l'authentification. Tous les systèmes SNMP doivent également supporter les protocoles DUPER et IP pour transporter les données entre les agents et les stations de gestion.

2.Spécifications

Le format de la trame SNMP est décrit ci-dessous :

Champs

Version : numéro de version SNMP. Le manager et l'agent doivent utiliser le même numéro.

Communauté : ce champ sert à identifier auprès du manager l'agent avant de lui accorder un accès.

PDU : il y a 5 types de PDU : GetRequest, GetNextRequest, GetResponse, SetRequest, et TRAP.
Une description de ces PDU est données ensuite.

Un premier format est utilisé pour les PDU du genre GET, ou SET :

Champs

Type de PDU :
0 : GetRequest
1 : GetNextRequest
2 : GetResponse
3 : SetRequest

ID de requête : champ qui coordonne la requête du manager et la réponse de l'agent.

Statut d'erreur : entier qui indique une opération normale (cas 0) ou bien une erreur ( cas ¹0)

Index d'erreur : identifie les entées avec la liste des variables qui ont causé l'erreur.

Obj/Val : association du nom de la variable à transmettre avec sa valeur.

Un second format est utilisé pour la TRAP  PDU :

Champs

Type de PDU : dans ce cas toujours égal à 4.

Entreprise : identifie l'entreprise de management qui a défini la Trap  .

Adresse Agent : adresse IP de l'agent.

Type Générique : décrit quel type de problème est survenu. (7 valeurs sont possibles).

Type Spécifique : est utilisé afin d'identifier une TRAP spécifique à une entreprise.

Timestamp : contient la valeur de l'objet sysUptime représentant le temps écoulé depuis la dernière initialisation..

Obj/Val : association du nom de la variable à transmettre avec sa valeur. 

1.Introduction

RIP2 est utilisé pour échanger des informations de routage. Il dérive d'un premier protocole développé par Xerox (RIP). Chaque machine qui utilise un protocole RIP2 a un processus qui envoie et reçoit des datagrammes transportés par de l'UDP port numéro 520.

La structure des trames RIP2 est décrite ci-dessous :

Commande : utilisé pour définir le sujet du datagramme
1 Requête
2 Réponse
3 Réservé (Utilisé par Sun microsystems)

Version : numéro de la version RIP.

Identifiant de la famille d'adresses : indique quel type d'adresse est utilisé cela car
RIP2 peut transporter d'autres informations de routage.

Route tag : (utilisé par RIP2 ; 0 pour RIP) attribue une route qui doit être préservée par
une route. Ce champ permet de séparer les routes RIP internes des routes externes
qui ont pu être importée d'un EGP ou d'un autre IGP.

Adresse IP : adresse IP de la destination.

Masque de sous-réseau : (utilisé par RIP2; 0 pour RIP) masque du sous réseau
destination.

Saut  suivant :  adresse IP à laquelle les paquets devront être envoyé au prochain saut.

Métrique : représente le coût total de la source à la destination (en nombre de sauts).