1. INTRODUCTION

1.1. Motivation

1.2. Cadre

1.3. Interfaces

Par exemple, un module TCP s'appuiera sur le module Internet pour transporter un segment TCP (comprenant un en-tête TCP plus les données utilisateur) considéré lui-même comme le segment de données du datagramme Internet. Le module TCP renseignera les adresse et les autres paramètres de l'en-tête Internet par passage de paramètres lors de l'appel. Le module Internet constituera alors le datagramme Internet et appellera à son tour l'interface réseau local pour transmettre le datagramme.

Dans le cas d'ARPAnet, par exemple, le module Internet appellera le module réseau local qui ajoutera l'en-tête 1822 [2] en début de datagramme, constituant ainsi un message ARPANET à transmettre à l'IMP. L'adresse ARPANET sera déduite de l'adresse Internet par l'interface réseau local et sera l'adresse d'un hôte raccordé à l'ARPAnet, celui-ci pouvant être un routeur vers d'autres réseaux.

1.4. Fonctionnement

Les modules Internet exploitent des champs de l'en-tête Internet pour fractionner et réassembler les datagrammes Internet lorsque le réseau à traverser n'accepte que des paquets de taille plus réduite.

Le modèle de fonctionnement est qu'il existera un module Internet dans chaque hôte concerné par la communication Internet ainsi que dans chaque routeur situé sur le chemin du datagramme. Ces modules partagent un certain nombre de règles communes pour l'interprétation des champs d'adresse et pour la fragmentation et le réassemblage des datagrammes Internet. De plus, ces modules (surtout dans les routeurs) disposeront de fonctions permettant de prendre des décisions de 1000 routage ainsi que quelques autres fonctions.

Le protocole Internet considère chaque datagramme Internet comme une entité indépendante et sans relation aucune avec d'autres datagrammes. Il n'y a dans ce concept aucune notion de circuit ou de communication (ni virtuelle ni d'aucun ordre).

Le protocole Internet utilise quatre mécanismes clefs pour procurer le service promis : Type de Service, Durée de Vie, Options, et Checksum d'en-tête.

Le Type de Service indique la qualité du service désiré. Le type de service est un ensemble générique de paramètres qui caractérisent les choix de service disponibles sur le réseau qui supporte la communication Internet. Cette indication de type de service sera utilisée par les routeurs pour commuter les paramètres de transmission actuels d'un réseau particulier, le réseau à utiliser sur le segment suivant, ou pour spécifier le routeur suivant lors du routage d'un datagramme.

La Durée de Vie indique une limite haute pour la durée d'existence d'un datagramme dans le réseau. Elle est initialisée par l'émetteur du datagramme et décrémentée par les éléments actifs situés sur le chemin que parcourt le datagramme. Si cette durée de vie atteint la valeur zéro avant que le datagramme Internet n'atteigne sa destination, ce dernier sera détruit. Cette durée de vie peut être vue comme une temporisation d'autodestruction du datagramme.

Les Options permettent le transport de signaux de contrôle utiles voire nécessaires dans certaines situations particulières mais secondaire pour la fonction essentielle de la communication. Les options permettent par exemple le marquage temporel, le codage de sécurité, et des commandes de routage spéciales.

Le Checksum d'en-tête permet de vérifier que les informations ajoutées par un module Internet ont été correctement transmises. Les données peuvent néanmoins contenir des erreurs. Si le Checksum échoue, le datagramme Internet est immédiatement rejeté par l'entité qui l'a reçu.

Le protocole Internet ne prend absolument pas en charge le contrôle d'intégrité des données transportées. Il n'intègre aucun mécanisme d'acquittement ni "bout en bout" ni "segment par segment". Aucun contrôle d'erreur n'est effectué sur les données, lequel sera à la charge des modules supérieurs, seule l'en-tête Internet est contrôlée. Il n'y a aucun mécanisme de retransmission de paquet. Il n'y a aucun mécanisme de contrôle de flux.

Les erreurs détectées pourront être signalées via l'Internet Control Message Protocol (ICMP) [3] implémenté dans le module Internet. 

2. VUE D'ENSEMBLE

2.1. Relations avec les autres protocoles

Le protocole Internet s'interface d'un côté avec un protocole hôte-vers-hôte de niveau supérieur et de l'autre côté avec un protocole de réseau local. Dans ce contexte, un "réseau local" peut être un petit réseau d'entreprise comme un réseau beaucoup plus étendu comme ARPAnet.

2.2. Modèle de fonctionnement

Nous supposons ici que la transmission traverse un routeur intermédiaire. L'application émettrice prépare les données à envoyer et appelle son module Internet local pour envoyer un datagramme en lui passant l'adresse de destination et quelques autres paramètres comme arguments.

Le module Internet prépare une en-tête de datagramme et lui ajoute les données. Le module Internet détermine une adresse réseau locale correspondant à cette adresse Internet, dans notre cas, il s'agit de l'adresse d'un routeur. Il envoie ensuite ce datagramme ainsi que l'adresse réseau locale à l'interface réseau local.

L'interface réseau local crée sa propre en-tête réseau local, et ajoute à son tour le datagramme, puis émet physiquement le paquet ainsi constitué sur le réseau.

Le datagramme arrive sur un routeur hôte encapsulé dans son en-tête réseau local, l'interface réseau local décapsule cette en-tête, et transfère le datagramme vers le module Internet routeur. Le module Internet routeur détermine en fonction de l'adresse Internet vers quel hôte et sur quel nouveau segment de réseau le datagramme doit être transmis. Le module Internet détermine une nouvelle adresse réseau local visant à ce moment l'ordinateur cible. Il appelle l'interface réseau local traitant ce segment pour y reporter le datagramme.

Cette interface réseau local crée une nouvel en-tête réseau local et y attache le datagramme puis transmet le tout sur le nouveau segment de réseau (lequel en l'occurrence supporte l'h&ocir 1000 c;te cible).

Arrivé à destination, le datagramme est extrait de son enrobage réseau local par l'interface réseau local destinataire, puis est transmis au module Internet destinataire.

Le module Internet détermine à quel programme applicatif le datagramme est destiné. Il passe alors les données au programme applicatif en réponse à un appel système, accompagné de l'adresse de la source et de quelques autres paramètres.
 
 

2.3. Description fonctionnelle

Lors de l'acheminement d'un datagramme 1000 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

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" [5].

Fragmentation

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 [6].

Les procédures de fragmentation et réassemblage Internet doivent pouvoir "ca 1000 sser" 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.

2.4. Routeurs

Dans un routeur, les protocoles de niveau supérieur n'ont pas à être reconnus. Les fonctions GGP sont ajoutées dans l'implémentation du module IP.

3. SPECIFICATION

3.1. Format d'en-tête Internet

Notez que chaque marque indique une position bit.

Version : 4 bits

Longueur d'En-Tête : 4 bits

Type de Service : 8 bits

Priorité

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 nombre 576 a été choisi pour permettre à un bloc de données de taille raisonnable d'&e 1000 circ;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

Flags : 3 bits

Position relative : 13 bits

Durée de vie : 8 bits

Protocole : 8 bits

Checksum d'en-tête : 16 bits

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

Adresse destination : 32 bits

Options : variable

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.

L'octet de type d'option est composé de trois champs de bits :

L'indicateur de recopie marque le fait que 1000 l'option est recopiée dans tous les segments d'un datagramme fragmenté.

Les classe d'option sont :

Les options suivantes sont actuellement définies :

Définition des options spécifiques

Fin de liste d'option

+--------+
|00000000|
+--------+
Type=0
 

Cette option indique la fin de la liste d'options qui ne coïncide pas nécessairement avec la fin de l'en-tête, selon la définition de la longueur de celle-ci. Cette option est utilisable une fois à la fin du bloc d'options, et non pas après chaque option, et peut n'être utilisée que dans le cas où la fin de liste d'options ne peut coïncider avec la fin de l'en-tête Internet. (NdT : Rappel, une en-tête IP comporte toujours un multiple de 4 octets).

Cet octet peut être recopié, introduit ou supprimé lors d'opérations de fragmentation, ou pour toute autre raison.

Pas d'opération

Cette option peut être utilisée entre deux options significatives, par exemple, pour aligner le début de l'option suivante sur le début d'un mot de 32 bits.

Peut être recopié, introduit, ou supprimé lors d'opérations de fragmentation, ou pour toute autre raison.

Sécurité

Cette option permet à un hôte d'envoyer des informations de sécurité, compartimentation, restrictions d'usage, et CCT (groupe fermé). Le format de cette option est le suivant :

Sécurité (Champ S) : 16 bits

Compartiments (Champ C): 16 bits

Restrictions d'usage (Champ H) : 16 bits

Code de Contrôle de Transmission (Champ CCT) : 24 bits

Cette option est à recopier impérativement lors d'une fragmentation. Elle doit apparaître au plus une fois dans un datagramme.

Routage lâche et enregistrement du chemin

NdT : le paragraphe ci-dessous est la traduction stricte de la norme. La rédaction originale pouvant apparaître comme quelque peu obscure, vous trouverez en fin de paragraphe un commentaire explicatif du principe de cette option.
 

Cette option débute avec l'octet de type de l'option. Le second octet donne la longueur de cette option en comptant les deux premiers octets, l'octet pointeur, et longueur-3 octets de données de chemin. Le troisième octet contient une valeur de décalage relatif pointant, dans le champ de chemin, le premier octet de l'adresse Internet de routage suivante à traiter. Ce décalage se calcule relativement au premier octet de l'option, et accepte comme valeur minimale la valeur 4.

Un chemin est composé d'une liste d'adresses Internet. Chaque adresse étant codée sur 32 bits, et donc 4 octets. Si la valeur du pointeur est plus grande que la longueur d'option, le chemin source est vide (et le chemin enregistré plein) et le routage doit prendre comme référence le champ d'adresse destinataire.

Si l'adresse contenue dans le champ d'adresse destinataire a été atteinte et le pointeur est supérieur à la longueur, l'adresse suivante de source remplace le contenu du champ d'adresse, et l'adresse enregistrée remplace l'adresse source utilisée, le pointeur est augmenté de quatre unités.

L'adresse enregistrée correspond à l'adresse du module Internet qui est en train de traiter l'en-tête pour réaliser l'acheminement.

Cette procédure qui consiste à remplacer l'adresse source par l'adresse enregistrée (bien que le chemin soit inscrit dans l'ordre inverse que ce qui serait nécessaire pour répondre au datagramme en utilisant le chemin inverse) permet de conserver à cette option (ainsi qu'à l'adresse IP en général) une longueur constante tout au long du "voyage" du datagramme à travers Internet.

Cette option spécifie un routage "lâche" en ce sens qu'un routeur ou un hôte IP est autorisé à choisir n'importe quel autre routeur ou hôte intermédiaire qui se situe entre lui même et le destinataire final.

Doit impérativement être reporté lors d'une fragmentation. Ne peut apparaître qu'une fois au plus dans un datagramme.

Note : Il faut comprendre le champ "chemin" comme une liste des adresses Internet de chaque module intermédiaire entre la source et le destinataire, constituant un chemin "préférentiel" tel que le connaît l'émetteur du datagramme. Au fur et à mesure que le datagramme progresse dans le réseau, chaque adresse est effectivement remplacée par celle du module réellement traversé par le datagramme. Le routage est dit "lâche" car le chemin suivi effectivement par le datagramme n'est pas obligatoirement celui qui est préconisé par la liste initiale fournie par la source.

Routage strict et enregistrement de chemin
 

Cette option débute avec l'octet de type de l'option. Le second octet donne la longueur de cette option en comptant les deux premiers octets, l'octet pointeur, et longueur-3 octets de données de chemin. Le troisième octet contient une valeur de décalage relatif pointant, dans le champ de chemin, le premier octet de l'adresse Internet de routage suivante à traiter. Ce décalage se calcule relativement au premier octet de l'option, et accepte comme valeur minimale la valeur 4.

Un chemin est composé d'une liste d'adresses Internet. Chaque adresse étant codée sur 32 bits, et donc 4 octets. Si la valeur du pointeur est plus grande que la longueur d'option, le chemin source est vide (et le chemin enregistré plein) et le routage doit prendre comme référence le champ d'adresse destinataire.

Si l'adresse contenue dans le champ d'adresse destinataire a été atteinte et le pointeur est supérieur à la longueur, l'adresse suivante de source remplace le contenu du champ d'adresse, et l'adresse enregistrée remplace l'adresse source utilisée, le pointeur est augmenté de quatre unités.

L'adresse enregistrée correspond à l'adresse du module Internet qui est en train de traiter l'en-tête pour réaliser l'acheminement.

Cette procédure qui consiste à remplacer l'adresse source par l'adresse enregistrée (bien que le chemin soit inscrit dans l'ordre inverse que ce qui serait nécessaire pour répondre au datagramme en utilisant le chemin inverse) permet de conserver à cette option (ainsi qu'à l'adresse IP en général) une longueur constante tout au long du "voyage" du datagramme à travers Internet.

Cette option spécifie un routage "strict" en ce sens qu'un routeur ou un hôte IP doit obligatoirement choisir le routeur ou hôte intermédiaire suivant tel que préconisé par la route source.

Doit impérativement être recopié lors d'une fragmentation. Doit apparaître au plus une fois dans un datagramme.

Traceur

Cette option débute avec l'octet de t 1000 ype de l'option. Le second octet donne la longueur de cette option en comptant les deux premiers octets, l'octet pointeur, et longueur-3 octets de données de chemin. Le troisième octet contient une valeur de décalage relatif pointant, dans le champ de chemin, le premier octet ou doit être enregistrée l'adresse Internet suivante. Ce décalage se calcule relativement au premier octet de l'option, et accepte comme valeur minimale la valeur 4.

Un chemin est composé d'une liste d'adresses Internet. Chaque adresse étant codée sur 32 bits, et donc 4 octets. Si la valeur du pointeur est plus grande que la longueur d'option, le chemin enregistré est plein. L'émetteur du datagramme devra composer cette option en prévoyant une taille de liste initiale suffisamment longue pour pouvoir enregistrer autant d'adresses de modules intermédiaires que le datagramme est supposé traverser. La taille de l'option ne doit effectivement plus changer lors de l'enregistrement effectif du chemin. Le chemin, au départ du datagramme est initialisé avec des zéros par l'émetteur.

Lorsqu'un module Internet traite un datagramme, il doit vérifier si celui-ci comporte un traceur. Si c'est le cas, il insère sa propre adresse Internet à la position de chemin indiquée par le pointeur, puis incrémente le pointeur de quatre unités.

Si cette liste d'adresse est entièrement remplie (le pointeur excède la longueur de l'option), le datagramme est retransmis sans enregistrer la nouvelle adresse du module Internet actuel. S'il reste de la place dans la liste, mais que cette place est trop petite pour insérer une adresse complète, alors cela indique une erreur et le datagramme doit être détruit. Dans ces deux cas, un message d'erreur ICMP doit être envoyé au hôte source [3].

Ne doit pas être recopié lors d'une fragmentation, mais apparaître seulement dans le premier fragment. Ne peut apparaître qu'une fois au plus dans un datagramme.

Identificateur de flux

Doit être recopié lors de fragmentation. Ne peut apparaître au plus une fois dans un datagramme.

Marqueur temporel

Le Pointeur contient une valeur qui pointe sur le premier octet de la première place libre pour un nouveau marqueur temporel. L'origine de ce décalage relatif est pris au début de l'option, et donc le décalage minimum acceptable est 5. La liste de marqueurs est pleine lorsque la valeur du pointeur dépasse la longueur de l'option.

Le champ de dépassement de capacité (oflw) [4 bits] compte le nombre de modules IP qui n'ont pas pu enregistrer de marqueur temporel faute de place dans la liste.

Les commutateurs ou bits de contrôle [4 bits] ont les significations suivantes :

L'étiquette temporelle compte sur 32-bits le temps écoulé depuis 0 heures UT en millisecondes, et est justifiée à droite. Si cette valeur n'est pas disponible en millisecondes ou ne peut être calculé à partir de la référence 0 heures UT, alors la valeur disponible sera marquée dans l'étiquette et le bit de poids fort sera marqué à un pour prévenir de l'utilisation d'un format non standard.

L'émetteur du datagramme devra composer cette option en prévoyant une taille de liste initiale suffisamment longue pour pouvoir enregistrer autant d'adresses de modules intermédiaires que le datagramme est supposé traverser. La taille de l'option ne doit effectivement plus changer lors de l'enregistrement effectif des étiquettes. Dans la liste initiale, les adresses auront été marquées par l'émetteur, et les étiquettes initialisées à zéro.

Si la liste d'étiquettes temporelles est pleine (le pointeur pointe au delà de l'en-tête), le datagramme est retransmis sans ajout de nouvelle étiquette, mais le compteur de dépassement de capacité est incrémenté.

< 1000 font size=-1>S'il reste de la place dans la liste, mais insuffisamment pour enregistrer une étiquette temporelle complète, ou si le champ de dépassement de capacité lui-même est au maximum de sa valeur, le datagramme est considéré en erreur et sera détruit. Dans ces deux cas, un message d'erreur ICMP doit être retourné à l'émetteur [3].

L'option de marquage temporel ne doit pas être recopiée lors d'une fragmentation. Elle est transportée dans le premier fragment. Doit apparaître au plus une fois dans un datagramme.

Bourrage : variable

3.2. Discussion

Les services de base d'Internet s'appuient sur le concept datagramme qui prévoit une possibilité de fragmentation par les routeurs, avec une fonction de réassemblage exécutée par le module Internet du destinataire. Bien sûr, la fragmentation et le réassemblage des datagrammes, localement à un segment de réseau ou suite à un accord particulier entre deux routeurs situés sur un même réseau sont permis, dans la mesure où cette technique est totalement transparente pour les protocoles Internet et à fortiori pour les protocoles de niveau supérieur. Ce type de fragmentation-réassemblage transparent est appelé "dépendant du réseau" (ou encore Intranet) et ne sera plus évoqué dans la suite.

Les adresses Internet distinguent les sources et les destinations en termes de "hôtes" et comportent de plus un champ "protocole". Il est supposé ici que chaque protocole de niveau supérieur disposera de toutes les fonctions de routage nécessaires à l'intérieur même du hôte.

Adressage

Formats d'adresse :

Une valeur zéro dans le champ réseau signifie "ce réseau". Ceci n'est utilisé que dans certains messages ICMP. Le mode d'adressage étendu est à ce jour non défini. Ces deux interprétations sont réservées pour un usage futur.

Les valeurs assignées actuellement pour les adresses de réseau sont données dans le document "Assigned Numbers" [9].

L'adresse locale, définie par rapport au réseau local, doit permettre à un hôte "physique" de pouvoir être considéré comme plusieurs hôtes Internet. Ceci veut dire qu'une table de transcription doit exister entre les adresses Internet d'hôte et les adresses d'interfaces réseau permettant à plusieurs adresses Internet d'être accessible par la même interface. Un hôte doit à l'inverse pouvoir dispose de plusieurs interfaces physiques au réseau et traiter les datagrammes y parvenant comme s'ils avaient été adressés à un hôte unique.

Les transcriptions d'adresses Internet en adresses ARPAN 1000 ET, SATNET, PRNET, ou d'autre réseaux sont définies dans le document "Address Mappings" [5].

Fragmentation et Réassemblage.

Le bit Dernier Fragment (DF) est marqué et si le datagramme ne porte pas le dernier fragment du datagramme original. Le champ Fragment Offset identifie la position relative du fragment transporté, par rapport au début du datagramme original non fragmenté. Les fragments sont mesurés par blocs de 8 octets. La stratégie de fragmentation est ainsi faite qu'un datagramme non fragmenté porte tous les champs de contrôle de fragmentation à zéro (DF = 0, fragment offset = 0). Si un datagramme Internet est fragmenté, alors le découpage devra être fait par blocs multiples de 8 octets excepté le dernier fragment.

Le format choisi pour Fragment Offset permet la numérotation de 2**13 = 8192 positions de blocs de 8 octets chacun pour un total de 65536 octets. Notez que ceci est cohérent avec le format du champ longueur totale (bien sûr, l'en-tête est comptée pour le calcul de la longueur totale, et pas pour la position relative des segments).

Lors d'une fragmentation, certaines options sont recopiées dans chaque en-tête de fragment, d'autres ne sont transmises qu'une fois dans l'en-tête du premier segment.

Tout module Internet doit être capable de traiter un datagramme d'au moins 68 octets sans fragmentation supplémentaire. Ceci est dû au fait qu'une en-tête Internet comprend au plus 60 octets, et le fragment minimal fait 8 octets.

Tout destinataire Internet doit être capable de recevoir un datagramme d'au moins 576 octets soit d'un seul morceau soit en plusieurs fragments à réassembler.

Les champs qui peuvent être modifiés lors d'une fragmentation sont :

1. les champs d'option
2. le bit Dernier Fragment
3. le champ Fragment Offset
4. le champ de longueur totale d'en-tête
5. le champ de longueur totale
6. le Checksum d'en-tête

Un exemple d'utilisation de cette fonctionnalité est lorsque l'on veut diminuer la charge en ligne d'un module de type "embarqué". Un tel hôte peut travailler sous un système d'exploitation minimum (bootstrap) acceptant un datagramme en entrée, l'enregistrant en mémoire, puis l'exécutant.

Les procédures de fragmentation et de réassemblage sont bien mieux décrites par des exemples. La procédure suivante est un exemple d'implémentation de fragmentation.

Dans les pseudo-programmes suivants, les conventions ci-après sont utilisées : "=<" signifie "inférieur ou égal", "#" signifie "différent de", "=" signifie "égal à", "<-" signifie "est initialisé avec". De plus, "x to y" inclue x et exclue y; par exemple, "4 to 7" comprend 4, 5, et 6 (mais pas 7).

Exemple de procédure de fragmentation

Si la longueur totale est inférieure ou égale à la taille de l'UTM alors le datagramme doit être directement transmis à l'étape suivant la fragmentation; autrement, le datagramme est coupé en deux, le premier de taille égale à la taille de l'UTM, et le second fragment avec ce qui reste. Le premier fragment est transmis à l'étape suivante, tandis que le deuxième est "réentré" dans la présente procédure, au cas où sa taille dépasserait encore la taille de l'UTM.

Notation :

                     FO    -  Fragment Offset         LET   -  Longueur d'en-tête         AF    -  Bit anti-fragmentation         DF    -  Bit Dernier fragment         LT    -  Longueur totale         OFO   -  Fragment Offset (tampon)         OLET  -  Longueur d'en-tête (tampon)         ODF   -  Bit Dernier Fragment (tampon)         OLT   -  Longueur totale (tampon)         NBF   -  Nombre de blocs de fragments         UTM   -  Unité de transmission maximumProcédure :

        IF LT =< UTM THEN              Soumettre le datagramme à l'étape suivante         ELSE IF AF = 1 THEN              détruire le datagramm 1000 e          ELSE         // Pour produire le premier fragment :         (1)  Copier l'en-tête originale ;         (2)  OLET <- LET; OLT <- LT; OFO <- FO; ODF <- DF;         (3)  NBF <- (UTM-LET*4)/8;         (4)  Attacher les NBF*8 premiers octets de donnée;         (5)  Corriger l'en-tête:              DF <- 1;  TL <- (LET*4)+(NBF*8);              Recalculer le Checksum;         (6)  Soumettre le fragment à l'étape suivante ;         // pour produire le deuxième fragment :         (7)  Copier sélectivement l'en-tête internet (seulement certaines options              cf. définitions);         (8)  attacher le reste des données;         (9)  Corriger l'en-tête:              LET <- (((OLET*4)-(longueur des options non copiées))+3)/4;              LT <- OLT - NBF*8 - (OLET-LET)*4);              FO <- OFO + NBF;  DF <- ODF;  Recalculer Checksum;         (10) Soumettre ce fragment au test de fragmentation; DONE.Dans la procédure ci-dessus, tous les fragments (sauf le dernier) ont la taille maximale qu'admet le réseau en sortie. Une autre implémentation pourrait produire des fragments d'une taille inférieure. Par exemple, une solution consisterait à diviser récursivement un datagramme en deux (en respectant la règle des blocs de 8 octets) tant que les datagrammes restent supérieurs à la taille de l'UTM.

Exemple de procédure de réassemblage

Si aucun autre fragment n'est actuellement en mémoire pour ce tampon d'identification, alors des nouvelles ressources sont allouées pour démarrer un réassemblage. Les ressources pour le réassemblage consistent en un tampon de données, un autre pour l'en-tête, une table bit des blocs de fragments, un champ de longueur totale, et un temporisateur. Les données du fragment sont copiées dans le tampon de données à leur position relative indiquée par le fragment offset et l'indication de longueur, et les bits correspondants de la table bit des blocs de fragments sont marqués pour les blocs traités.

S'il s'agit du premier fragment (fragment offset vaut zéro) son en-tête est copiée dans le tampon d'en-tête. S'il s'agit du dernier fragment (Le bit Dernier fragment vaut zéro) le champ de longueur totale est calculé. Si ce fragment, qu'il soit le dernier ou non, complète le datagramme (c'est à dire que tous les bits de la table des blocs de fragments attendus se retrouvent marqués), alors le datagramme est transféré à l'étape suivante de traitement; sinon, on compare la valeur actuelle du temporisateur avec la durée de vie notifiée dans ce fragment et on initialise le temporisateur avec la plus grande valeur des deux; la routine de réassemblage rend alors la main.

Si le temporisateur arrive en fin de course, toutes les ressources consommées pour ce tampon d'identification sont libérées. La valeur initiale de temporisation est la limite inférieure théorique du temps d'attente pour réassemblage. Ce choix se justifie du fait que le temps effectif de réassemblage peut augmenter si le champ durée de vie du fragment reçu est supérieur à la valeur courante de temporisation, mais en aucun cas diminuer étant donné le mécanisme mis en place. La valeur maximale que ce temporisateur peut prendre est la durée de vie maximum (approximativement 4,25 minutes). La valeur de temporisation initiale recommandée aujourd'hui est environ 15 secondes. Cette valeur sera susceptible de changement par l'usage. Notez que le choix de la valeur de paramètre est lié à la capacité du tampon disponible ainsi qu'à la vitesse de transmission du médium; c'est-à-dire, le débit * temporisation = taille du tampon (ex., 10Kb/s * 15s = 150Kb).

Notation :

        FO    -  Fragment Offset         LET   -  Longueur d'en-tête         DF    -  Bit Dernier Fragment         DdV   -  Durée de Vie         NBF   -  Nombre de Blocs de Fragments         LT    -  Longueur Totale         LTD   -  Longueur Totale des Données         BUFID -  Tampon d'identification         RCVBT -  Table bit des blocs reçus         LIT   -  Limite Inférieure de TemporisationProcédure :

        (1)  BUFID <- source|destination|protocole|identification;         (2)  IF FO = 0 AND DF = 0         (3)     THEN IF tampon alloué pour BUFID         (4)             THEN libérer toutes les ressources pour ce BUFID;         (5)          soumettre le datagramme à l'étape suivante; DONE.         (6)     ELSE IF aucun tampon alloué pour BUFID    1000       (7)             THEN réserver les ressource de réassemblage pour BUFID;                              TIMER <- LIT; LTD <- 0;         (8)          copier les données fragment dans le tampon associé à                      BUFID à partir de l'octet FO*8 jusqu'à                                          l'octet (LT-(LET*4))+FO*8;         (9)          marquer les bits RCVBT de FO à FO+((LT-(LET*4)+7)/8);         (10)         IF DF = 0 THEN LTD <- LT-(LET*4)+(FO*8)         (11)         IF FO = 0 THEN copier l'en-tête dans le tampon d'en-tête         (12)         IF LTD # 0         (13)          AND tous les bits de RCVBT de 0 à (LTD+7)/8 marqué         (14)            THEN LT <- LTD+(LET*4)         (15)                 Soumettre le datagramme au pas suivant;         (16)                 Libérer toutes les ressources pour ce BUFID; DONE.         (17)         TIMER <- MAX(TIMER,DdV);         (18)  Retour jusqu'au fragment suivant ou expiration de              temporisation;         (19) EXPIRATION: Libérer les ressources pour ce BUFID; DONE.Dans le cas où deux fragments contiennent les mêmes données soit intégralement, soit suite à un recoupement partiel, cette procédure utilisera la dernière version de données arrivées pour compléter le datagramme.

Identification

Il semble que le module Internet doive garder en mémoire une table des identificateurs, dans laquelle on trouvera une entrée par destinataire et 1000 protocole, laquelle sera maintenue dans la table au moins jusqu'à la fin de durée de vie maximale (théorique) du dernier fragment du datagramme émis vers cette destination.

Cependant, comme le champ d'identification autorise 65536 valeurs d'identificateurs distinctes, certains hôte choisiront des identificateurs pour chaque datagramme émis, indépendamment des valeurs de paire destination/protocole, par simple "rotation" des identificateurs.

Dans certains cas, il sera approprié de laisser le choix de cet identificateur à charge du protocole de plus haut niveau. Par exemple, lorsqu'un module TCP retransmet un segment TCP identique suite à une erreur, la probabilité d'une réception correcte sera augmentée si la retransmission porte le même identificateur que la transmission originale dans la mesure où les fragments des deux transmissions peuvent servir à reconstruire correctement le segment TCP entier.

Type de Service

• Priorité. Une mesure subjective de l'importance de ce datagramme.
• Retard. Des datagrammes marqués de ce bit doivent être transmis le plus rapidement possible.
• Débit. Ces datagrammes font partie d'une communication demandant un gros débit de données.
• Fiabilité ou taux d'erreur. Un effort particulier doit être fait pour assurer l'acheminement correct de ces datagrammes.

      Priorité  :    5       Retard    :    0       Débit     :    1       Fiabilité :    1Dans cet exemple, l'interprétation de ces paramètres en termes de paramètres de service ARPANET provoquerait

• un marquage du bit prioritaire ARPANET, dans la mesure où la priorité Internet est donn&eacut 1000 e;e dans la moitié supérieure de sa plage
• la sélection du type de messages "standard", au vu des contraintes demandées pour le débit et la fiabilité et aucune contrainte sur le temps d'acheminement. Plus de détails concernant cette interprétation dans le document "Service Mappings" [8].

Durée de vie

Ce champ doit être décrémenté à chaque point du réseau où l'en-tête Internet est interprétée, d'une valeur représentant à peu près le temps passé à traiter le datagramme. Même si le système local n'est pas en mesure de fournir une mesure de ce temps, ce champ doit être décrémenté au minimum d'une unité. Sinon, le temps doit être mesuré en secondes (c-à-d. qu'une unité correspond à une seconde). De ce fait, la durée de vie maximale codable est de 255 secondes soit 4,25 minutes. Comme chaque module Internet doit impérativement décrémenter ce champ d'au moins une unité (une seconde) même si le traitement du datagramme a demandé beaucoup moins de temps, la durée de vie initiale doit toujours être interprétée comme la durée théorique maximale pendant laquelle le datagramme peut exister. La justification de ce mécanisme est d'é