:: News .:. Documents .:. Forum .:. Downloads .:. Bibliographie .:. Liens .:. Contact  :: 


Home
  :. News
  .: Documents
    .: Notions
    .: Protocoles
    .: Sécurité
    .: Architecture
    .: Prog
    .: Systèmes
  :. Forum
  .: Downloads
  :. Bibliographie
  .: Liens
  :. Contact

Chat

  Nickname:


irc: #guill.net

Forum



 
RFC 791 : Internet Protocol (IP) - Specification  
 

 

Crédits : J. Postel, ISI,
Traduction : V.G. FREMAUX / Ingénieur Professeur / EISTI


1. INTRODUCTION
2. VUE D'ENSEMBLE
3. SPECIFICATION
APPENDICE A: Exemples & Scénarios
APPENDICE B: Ordre de transmission des données
GLOSSAIRE
REFERENCES


PREFACE

Ce document spécifie le Protocole Internet Standard du DoD (Department of Defense). Ce document est basé sur les six éditions précédentes de la spécification ARPA Internet Protocol, et le présent texte en découle fortement. De nombreuses contributions ont été apportées à ce travail à la fois en termes de concepts et en termes de rédactionnel. Cette édition revoit certains aspects concernant l'adressage, la gestion des erreurs, les codes d'options, ainsi que les aspects sécurité, priorité, compartimentation, et restrictions d'usage définies par le protocole Internet.

1. INTRODUCTION

1.1. Motivation

Le Protocole Internet est conçu pour supporter l'intercommunication desystèmes informatiques sur une base de réseau parcommutation de paquets. Un tel système est appelé "catenet"[1]. Le rôle du protocole Internet est la transmission deblocs de données, appelés datagrammes, d'une sourcevers une destination, la source et la destination étant desordinateurs hôtes identifiés par une adresse delongueur fixe. Le protocole Internet dispose des mécanismespermettant la fragmentation de longs datagrammes et leur réassemblage,lors de leur transmission à travers des réseaux de "dimension"inférieure.

1.2. Cadre

Le protocoleInternet est limité aux fonctions nécessaires àl'acheminement d'un paquet de bits (un datagramme Internet) depuisune source vers une destination via un ensemble de réseauxinterconnectés. Aucun mécanisme particulier destinéà augmenter la fiabilité des données de "bouten bout" n'y est implémenté, ni mécanismede contrôle de flux, de séquencement, ni aucun autreservice communément fourni par d'autres protocoles "hôtevers hôte". Le protocole Internet capitalisera lesservices des réseaux qui le supportent pour offrir diverstypes et le routeur le plus proche ou directement vers l'hôte destinataire.

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

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

1.4. Fonctionnement

Le protocoleInternet implémente deux fonctions de base : l'adressage etla fragmentation. Les modules Internet exploiteront les adressesinscrites dans l'en-tête Internet pour acheminer ledatagramme vers sa destination. La sélection d'un cheminpartant de la source vers la destination est appelée leroutage.

Les modulesInternet exploitent des champs de l'en-tête Internet pourfractionner et réassembler les datagrammes Internet lorsquele réseau à traverser n'accepte que des paquets detaille plus réduite.

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

Le protocoleInternet considère chaque datagramme Internet comme uneentité indépendante et sans relation aucune avecd'autres datagrammes. Il n'y a dans ce concept aucune notion decircuit 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 deService indique la qualité du service désiré.Le type de service est un ensemble générique deparamètres qui caractérisent les choix de servicedisponibles sur le réseau qui supporte la communicationInternet. Cette indication de type de service sera utiliséepar les routeurs pour commuter les paramètres detransmission actuels d'un réseau particulier, le réseauà utiliser sur le segment suivant, ou pour spécifierle routeur suivant lors du routage d'un datagramme.

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

Les Optionspermettent le transport de signaux de contrôle utiles voirenécessaires dans certaines situations particulièresmais secondaire pour la fonction essentielle de la communication.Les options permettent par exemple le marquage temporel, le codagede sécurité, et des commandes de routage spéciales.

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

Le protocoleInternet ne prend absolument pas en charge le contrôle d'intégritédes données transportées. Il n'intègre aucunmécanisme d'acquittement ni "bout en bout" ni "segmentpar segment". Aucun contrôle d'erreur n'est effectuésur les données, lequel sera à la charge des modulessupérieurs, seule l'en-tête Internet est contrôlée.Il n'y a aucun mécanisme de retransmission de paquet. Iln'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 diagramme suivant montre la position du protocole Internet dans la "pile" de protocoles :

+------+ +-----+ +-----+     +-----+
|Telnet| | FTP | | TFTP| ... | ... |
+------+ +-----+ +-----+     +-----+
   |   |         |          |
     +-----+     +-----+     +-----+
     | TCP |     | UDP | ... | ... |
     +-----+     +-----+     +-----+
     |          |           |
    +--------------------------+----+
    |   Protocole Internet & ICMP   |
    +--------------------------+----+
      |
      +---------------------------+
      | Protocole de réseau local |
      +---------------------------+
Relations entre les protocoles Figure 1.

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

Le modèle de fonctionnement de la transmission d'un datagramme d'un programme d'application vers un autre est illustré par le scénario suivant :

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 undatagramme en lui passant l'adresse de destination et quelquesautres paramètres comme arguments.

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

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

Le datagrammearrive sur un routeur hôte encapsulé dans son en-têteréseau local, l'interface réseau local décapsulecette en-tête, et transfère le datagramme vers lemodule Internet routeur. Le module Internet routeur détermineen fonction de l'adresse Internet vers quel hôte et sur quelnouveau segment de réseau le datagramme doit êtretransmis. Le module Internet détermine une nouvelle adresseréseau local visant à ce moment l'ordinateur cible.Il appelle l'interface réseau local traitant ce segmentpour y reporter le datagramme.

Cette interface réseaulocal crée une nouvel en-tête réseau local ety attache le datagramme puis transmet le tout sur le nouveausegment de réseau (lequel en l'occurrence supporte l'hôtecible).

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

Le moduleInternet détermine à quel programme applicatif ledatagramme est destiné. Il passe alors les donnéesau programme applicatif en réponse à un appel système,accompagné de l'adresse de la source et de quelques autresparamètres.

Application                                          Application
      \                                                  /
   Module Internet      Module Internet     Module Internet
         \                /       \               /
nbsp;        LNI-1          LNI-1     LNI-2         LNI-2
            \           /            \          /
           Réseau local 1          Réseau local 2

Chemin de transmission Figure 2

2.3. Description fonctionnelle

La fonction ou rôledu Protocole Internet est d'acheminer les datagrammes àtravers un ensemble de réseaux interconnectés. Ceciest réalisé en transférant les datagrammesd'un module Internet à l'autre jusqu'à atteindre ladestination. Les modules Internet sont des programmes exécutésdans 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 selonl'interprétation d'une adresse Internet. De ce fait, un desplus importants mécanismes du protocole Internet est lagestion de cette adresse Internet.

Lors del'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 taillemaximale de paquet inférieure à celle du datagramme.Pour surmonter ce problème, un mécanisme defragmentation est géré par le protocole Internet.

Adressage

Une distinctiondoit être faite entre noms, adresses, et chemins [4]. Un nomindique ce que nous cherchons. Une adresse indique où celase trouve. Un chemin indique comment y aboutir. Le protocoleInternet s'occupe essentiellement des adresses. C'est à desprotocoles de niveau plus élevé (ex., hôte-vers-hôteou application) que revient la tâche de lier des noms àdes adresses. Le module Internet déduit de l'adresseInternet une adresse réseau local. La tâche quiconsiste à transcrire l'adresse de réseau local entermes de chemin (ex., sur un réseau local ou dans unrouteur) revient au protocole de bas niveau.

Les adresses ontune longueur fixe de 4 octets (32 bits). Une adresse commencetoujours par un numéro de réseau, suivi d'uneadresse locale (appelée le champ "reste") codantl'adresse de l'hôte sur ce réseau. Il existe troisformats ou classes d'adresses Internet : pour la classe A, le bitde poids fort vaut zéro, les 7 bits suivants désignentle réseau, les derniers 24 bits désignent l'adresselocale de la machine; pour la classe B, les deux bits de poidsfort valent 1 et 0, les 14 bits suivants désignent le réseauet les 16 derniers bits l'adresse locale de machine ; pour laclasse C, les trois bits de poids fort forment le schème110, les 21 bits suivants forment l'adresse réseau et les 8derniers bits l'adresse locale.

La transcriptiond'adresse Internet en adresses de réseau local doit êtresujette à quelques précautions ; un hôtephysique unique peut abriter plusieurs adresses Internetdistinctes comme s'il s'agissait de plusieurs hôtes indépendants.Certains hôtes peuvent disposer de plusieurs interfacesphysiques (multi-homing).

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

Des exemples de répartitiond'adresses peuvent être trouvés dans "AddressMappings" [5].

Fragmentation

La fragmentationdu datagramme Internet devient nécessaire dès lorsqu'un datagramme de grande taille arrive sur une portion de réseauqui n'accepte la transmission que de paquets plus courts.

Un datagrammeInternet peut être spécifié "nonfractionnable" Un tel datagramme Internet ne doit jamais êtrefragmenté quelques soient les circonstances. Si undatagramme 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éseaulocal hors de vue d'un module de protocole Internet est appeléefragmentation Intranet [6].

Les procéduresde fragmentation et réassemblage Internet doivent pouvoir "casser"un datagramme Internet en un nombre de "fragments"arbitraire et quelconque pourvu que le réassemblage soitpossible. Le récepteur des fragments utilise le champd'identification pour s'assurer que des fragments de plusieursdatagrammes ne puissent être mélangés. Lechamp "Fragment Offset" indique au récepteur laposition du fragment reçu dans le datagramme original. Leschamps "Fragment Offset" et "Longueur Totale"déterminent la portion du datagramme original que représentele fragment. L'indicateur bit "Dernier Fragment" indique(lors de sa remise à zéro) au récepteur qu'ils'agit du dernier fragment. Ces champs véhiculentsuffisamment d'information pour réassembler lesdatagrammes.

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

Pour fragmenterun long datagramme, un module Internet (par exemple, dans unrouteur), crée deux nouveaux datagrammes et copie lecontenu des champs d'en-tête Internet originaux dans lesdeux nouvel en-têtes. Les données du datagrammeoriginal sont divisées en deux portions, la premièred'une taille multiple de 8 octets (64 bit) (la taille de laseconde portion n'est donc pas nécessairement un multiplede 8 octets). Nous appellerons le nombre de blocs de 8 octets dansla première portion NBF (ou Nombre de Blocs du Fragment).La première portion de données est placéedans le premier des deux nouveaux datagramme, et le champ "LongueurTotale" 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 lesecond des deux nouveaux datagrammes, et le champ "longueurtotale" est renseigné avec la taille du seconddatagramme. Le bit "Dernier Fragment" est placé àla même valeur que celui du datagramme original. Le champ "FragmentOffset" du second datagramme constitué est renseignéavec la valeur du même champ du datagramme original plusNFB.

Cette procédurepeut être généralisée à unefragmentation en n fragments, plutôt que les deux décritsci-dessus.

Pour réassemblerles fragments d'un datagramme Internet, un module Internet (parexemple dans un hôte destinataire) recombine les datagrammesdont les valeurs des quatre champs suivants sont identiques :identification, source, destination, et protocole. Larecombinaison est réalisée en replaçant laportion de donnée contenue dans chaque fragment dans untampon à la position relative indiquée par le champ "FragmentOffset" lu dans l'en-tête correspondant. Le premierfragment sera donc placé en début de tampon, et ledernier fragment récupéré aura le bit "DernierFragment" à zéro.

2.4. Routeurs

Les routeurs implémententle protocole Internet pour transférer les datagrammes entreréseaux différents. Les routeurs implémenterontde plus le protocole routeur vers routeur ou Gateway to GatewayProtocol (GGP) [7] leur servant à coordonner le routage et às'échanger d'autres informations de gestion du réseau.

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

  +-------------------------------+
  |Protocole Internet & ICMP & GGP|
  +-------------------------------+
  |                |
 +---------------+   +---------------+
 |  Réseau local |  |  Réseau local |
 +---------------+   +---------------+
Protocoles dans les routeurs Figure 3.

3. SPECIFICATION

3.1. Format d'en-tête Internet

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

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version | LET  |Type de Service|        longueur totale        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Identification        |Flags|      Fragment Offset    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  Durée de vie |   Protocole   |         Checksum d'en-tête    | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                       Adresse Source                          | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                    Adresse Destination                        | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                    Options                    |    Bourrage   | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Exemple d'en-tête de Datagramme Internet Figure 4.

Notez que chaque marque indique une position bit.

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 servicesouhaitée, qui reste cependant un paramètre "abstrait".Ce paramètre est utilisé pour "guider" lechoix des paramètres des services actuels lorsqu'undatagramme transite dans un réseau particulier. Certains réseauxoffrent un mécanisme de priorité, traitant préférentiellementun tel trafic par rapport à un trafic moins prioritaire (engénéral en acceptant seulement de véhiculerdes paquets d'un niveau de priorité au dessus d'un certainseuil lors d'une surcharge momentanée). Principalement, lechoix offert est une négociation entre les troiscontraintes suivantes : faible retard, faible taux d'erreur, ethaut 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é.

+  0     1     2     3     4     5     6     7  +                  
+-----+-----+-----+-----+-----+-----+-----+-----+ |    PRIORITE    
|  D  |  T  |  R  |  0  |  0  |
+-----+-----+-----+-----+-----+-----+-----+-----+                  

Priorité

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

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

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

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

Longueur Totale : 16 bits

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

Le nombre 576 a étéchoisi pour permettre à un bloc de données de tailleraisonnable d'être transmis dans un datagramme, tenantcompte des données à ajouter pour constituer lesen-têtes de protocole. Par exemple, cette taille permet latransmission d'un bloc de 512 octets, plus 64 octets d'en-têtedans un datagramme unique. (NdT : je rappelle ici que la taille de512 octets correspond à un secteur sur la plupart dessupports de stockage) La taille maximale d'un en-têteInternet étant de 60 octets, et sa taille typique étantde 20 octets, ce nombre permet de conserver une bonne marge pourles 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.

 0   1   2
+---+---+---+
|   | A | D |
| 0 | F | F |
+---+---+---+

Position relative : 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 permetde limiter le temps pendant lequel un datagramme reste dans le réseau.Si ce champ prend la valeur zéro, le datagramme doit êtredétruit. Ce champ est modifié pendant le traitementde l'en-tête Internet. La durée de vie est mesuréeen secondes. Chaque module Internet doit retirer au moins une unitéde temps à ce champ, même si le traitement complet dudatagramme par le module est effectué en moins d'uneseconde. De ce fait, cette durée de vie doit êtreinterprétée comme la limite absolue maximale detemps pendant lequel un datagramme peut exister. Ce mécanismeest motivé par la nécessité de détruireles datagrammes qui n'ont pu être acheminés, enlimitant 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" [9].

Checksum d'en-tête : 16 bits

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

L'algorithmeutilisé pour le Checksum est le suivant :

On calcule lecomplé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èreune en-tête dont le champ réservé pour ce mêmeChecksum vaut zéro.

L'algorithme deChecksum peut paraître élémentaire mais l'expérimentationa montré que cette technique était suffisante. Il sepeut que cet algorithme soit plus tard remplacé par uncalcul de type CRC, suivant la nécessité future.

Adresse source : 32 bits

L'adresse Internet de la source. Cf. section 3.2.

Adresse destination : 32 bits

L'adresse Internet du destinataire. Cf. section 3.2.

Options : variable

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

Dans certainsenvironnements, l'option de sécurité peut êtreobligatoire dans tous les datagrammes.

Le champ d'optionest de longueur variable. Un datagramme peut comporter zéroou 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.

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

0 = non recopiée
1 = recopiée

Les classe d'option sont :

0 = contrôle
1 = réservé pour usage futur
2 = débogage et mesure
3 = réservé pour usage futur

Les options suivantes sont actuellement définies :

CLASSE NUMERO LONGUEUR DESCRIPTION
------ ------ -------- -----------
0 0 - Fin de liste d'option. Sur un seul octet pas d'octet de taille.
0 1 - Pas d'opération. Sur un seul octet pas d'octet de taille.
0 2 11 Sécurité. Transporte les informations de sécurité, compartiment, Groupe utilisateur (TCC), et Codes de Restriction compatibles DOD (application militaire).
0 3 var. Routage lâche. Utilisé pour acheminer le datagramme selon des informations données par la source.
0 9 var. Routage strict. Utilisé pour acheminer le datagramme selon des informations données par la source.
0 7 var. Traceur. Utilisé pour mémoriser le chemin pris par un datagramme Internet.
0 8 4 ID de flux. Transporte l'identificateur du flux.
2 4 var. Marqueur temporel.

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

+--------+

|00000001|
+--------+
Type=1

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 :


+--------+--------+---//---+---//---+---//---+---//---+
|10000010|00001011|SSS  SSS|CCC  CCC|HHH  HHH|  CCT   |
+--------+--------+---//---+---//---+---//---+---//---+
 Type=130 Longueur=11

Sécurité (Champ S) : 16 bits

Définit un niveau de sécurité parmi 16 (dont 8 sont réservés pour usage futur).

00000000 00000000 - Non classé
11110001 00110101 - Confidentiel
01111000 10011010 - EFTO
10111100 01001101 - MMMM
01011110 00100110 - PROG
10101111 00010011 - Restreint
11010111 10001000 - Secret
01101011 11000101 - Top Secret
00110101 11100010 - (Réservé pour usage futur)
10011010 11110001 - (Réservé pour usage futur)
01001101 01111000 - (Réservé pour usage futur)
00100100 10111101 - (Réservé pour usage futur)
00010011 01011110 - (Réservé pour usage futur)
10001001 10101111 - (Réservé pour usage futur)
11000100 11010110 - (Réservé pour usage futur)
11100010 01101011 - (Réservé pour usage futur)

Compartiments (Champ C): 16 bits

Une valeur nulle de ce champ indique que l'information n'est pas compartimentée. Les autres valeurs admissibles sont attribuées par la "Defense Intelligence Agency" américaine.

Restrictions d'usage (Champ H) : 16 bits

Les valeurs pour marquer la prise de contrôle et la levée de restrictions sont des digraphes alphanumériques définis dans le "Defense Intelligence Agency Manual" DIAM 65-19, "Standard Security Markings".

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

Procure un moyen de différentier le trafic et de définir des groupes contingentés d'utilisateurs partageant un même centre d'intérêt. Les valeurs de CCT sont des trigraphes, et sont attribués par le HQ DCA Code 530.

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.



+--------+--------+--------+---------//--------+
|10000011| longeur|pointeur|     chemin        |
+--------+--------+--------+---------//--------+
Type=131

L'optionde routage lâche et d'enregistrement de chemin (LSRR) permetà la source d'un datagramme Internet de transmettre desinformations de routage à destination des routeurs quiacheminent le datagramme vers la destination, et d'enregistrer lesindications de chemin parcouru.

Cetteoption débute avec l'octet de type de l'option. Le secondoctet donne la longueur de cette option en comptant les deuxpremiers octets, l'octet pointeur, et longueur-3 octets de donnéesde chemin. Le troisième octet contient une valeur de décalagerelatif pointant, dans le champ de chemin, le premier octet del'adresse Internet de routage suivante à traiter. Ce décalagese calcule relativement au premier octet de l'option, et acceptecomme valeur minimale la valeur 4.

Unchemin est composé d'une liste d'adresses Internet. Chaqueadresse é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 champd'adresse destinataire.

Sil'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 champd'adresse, et l'adresse enregistrée remplace l'adressesource utilisée, le pointeur est augmenté de quatreunités.

L'adresseenregistrée correspond à l'adresse du moduleInternet qui est en train de traiter l'en-tête pour réaliserl'acheminement.

Cetteprocédure qui consiste à remplacer l'adresse sourcepar l'adresse enregistrée (bien que le chemin soit inscritdans l'ordre inverse que ce qui serait nécessaire pour répondreau 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" dudatagramme à travers Internet.

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

Doitimpérativement être reporté lors d'unefragmentation. Ne peut apparaître qu'une fois au plus dansun datagramme.

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

Routage strict et enregistrement de chemin

+--------+--------+--------+---------//--------+
|10001001|longueur|pointeur|     chemin        |
+--------+--------+--------+---------//--------+
Type=137

L'optionde routage lâche et d'enregistrement de chemin (LSRR) permetà la source d'un datagramme Internet de transmettre desinformations de routage à destination des routeurs quiacheminent le datagramme vers la destination, et d'enregistrer lesindications de chemin parcouru.

Cetteoption débute avec l'octet de type de l'option. Le secondoctet donne la longueur de cette option en comptant les deuxpremiers octets, l'octet pointeur, et longueur-3 octets de donnéesde chemin. Le troisième octet contient une valeur de décalagerelatif pointant, dans le champ de chemin, le premier octet del'adresse Internet de routage suivante à traiter. Ce décalagese calcule relativement au premier octet de l'option, et acceptecomme valeur minimale la valeur 4.

Unchemin est composé d'une liste d'adresses Internet. Chaqueadresse é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 champd'adresse destinataire.

Sil'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 champd'adresse, et l'adresse enregistrée remplace l'adressesource utilisée, le pointeur est augmenté de quatreunités.

L'adresseenregistrée correspond à l'adresse du moduleInternet qui est en train de traiter l'en-tête pour réaliserl'acheminement.

Cetteprocédure qui consiste à remplacer l'adresse sourcepar l'adresse enregistrée (bien que le chemin soit inscritdans l'ordre inverse que ce qui serait nécessaire pour répondreau 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" dudatagramme à travers Internet.

Cetteoption spécifie un routage "strict" en ce sensqu'un routeur ou un hôte IP doit obligatoirement choisir lerouteur ou hôte intermédiaire suivant tel que préconisépar la route source.

Doitimpérativement être recopié lors d'unefragmentation. Doit apparaître au plus une fois dans undatagramme.

Traceur

+--------+--------+--------+---------//--------+
|00000111|longueur|pointeur|     chemin        |
+--------+--------+--------+---------//--------+
Type=7

L'optiontraceur permet d'enregistrer le chemin parcouru par un datagrammeInternet.

Cetteoption débute avec l'octet de type de l'option. Le secondoctet donne la longueur de cette option en comptant les deuxpremiers octets, l'octet pointeur, et longueur-3 octets de donnéesde chemin. Le troisième octet contient une valeur de décalagerelatif pointant, dans le champ de chemin, le premier octet oudoit être enregistrée l'adresse Internet suivante. Cedécalage se calcule relativement au premier octet del'option, et accepte comme valeur minimale la valeur 4.

Unchemin est composé d'une liste d'adresses Internet. Chaqueadresse é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 dudatagramme devra composer cette option en prévoyant unetaille de liste initiale suffisamment longue pour pouvoirenregistrer autant d'adresses de modules intermédiaires quele datagramme est supposé traverser. La taille de l'optionne doit effectivement plus changer lors de l'enregistrementeffectif du chemin. Le chemin, au départ du datagramme estinitialisé avec des zéros par l'émetteur.

Lorsqu'unmodule Internet traite un datagramme, il doit vérifier sicelui-ci comporte un traceur. Si c'est le cas, il insère sapropre adresse Internet à la position de chemin indiquéepar le pointeur, puis incrémente le pointeur de quatre unités.

Sicette liste d'adresse est entièrement remplie (le pointeurexcède la longueur de l'option), le datagramme estretransmis sans enregistrer la nouvelle adresse du module Internetactuel. S'il reste de la place dans la liste, mais que cette placeest 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].

Nedoit pas être recopié lors d'une fragmentation, maisapparaître seulement dans le premier fragment. Ne peutapparaître qu'une fois au plus dans un datagramme.

Identificateur de flux

+--------+--------+--------+--------+
|10001000|00000010|    Stream ID    |
+--------+--------+--------+--------+
Type=136 Length=4

Permet la transmission d'un identificateur de flux 16-bits SATNET à travers des réseaux qui ne supportent pas la notion de flux.

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

Marqueur temporel

+--------+--------+--------+--------+
|01000100|longueur|pointeur|oflw|flg|
+--------+--------+--------+--------+
|         adresse Internet          |
+--------+--------+--------+--------+
|         marqueur temporel         |
+--------+--------+--------+--------+
|                 .                 |
Type = 68

La longueur compte le nombre d'octets de l'option y compris le type, la longueur (lui-même), le pointeur, et l'octet de dépassement de capacité/commutateurs (longueur maximale 40).

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 :

Etiquettes temporelles seules, enregistrées sous forme de mots consécutifs de 32 bits.
chaque étiquette est précédée de l'adresse Internet de l'entité qui l'a enregistrée.
les adresses Internet sont spécifiés dès le départ. Un module IP n'enregistre l'étiquette que si son adresse Internet propre correspond à l'adresse suivante spécifiée dans la liste.

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.

Sila liste d'étiquettes temporelles est pleine (le pointeurpointe au delà de l'en-tête), le datagramme estretransmis sans ajout de nouvelle étiquette, mais lecompteur de dépassement de capacité est incrémenté.

S'ilreste de la place dans la liste, mais insuffisamment pourenregistrer une étiquette temporelle complète, ou sile champ de dépassement de capacité lui-mêmeest au maximum de sa valeur, le datagramme est considéréen erreur et sera détruit. Dans ces deux cas, un messaged'erreur ICMP doit être retourné à l'émetteur[3].

L'optionde marquage temporel ne doit pas être recopiée lorsd'une fragmentation. Elle est transportée dans le premierfragment. Doit apparaître au plus une fois dans undatagramme.

Bourrage : variable

Le champ de bourrage n'existe que pour assurer à l'en-tête une taille totale multiple de 4 octets. Le bourrage se fait par des octets à zéro.

3.2. Discussion

L'implémentationd'un protocole doit répondre au principe de robustesse.Chaque implémentation doit s'attendre à pouvoir opérerface à une autre implémentation programméepar quelqu'un d'autre. Bien que la fonction de cette spécificationsoit de décrire explicitement ce protocole, il reste néanmoinsla possibilité de voir apparaître des interprétationsdivergentes. On adopte comme principe généralqu'implémentation doit être stricte quant à cequ'elle émet, et libérale par rapport à cequ'elle reçoit. C'est à dire qu'elle doit faireattention à émettre des datagrammes conformes etcorrectement constitués, mais doit accepter tout datagrammequ'elle est en mesure d'interpréter (ex., exempt d'erreursd'ordre technique et tant que sa signification reste déchiffrable).

Lesservices de base d'Internet s'appuient sur le concept datagrammequi prévoit une possibilité de fragmentation par lesrouteurs, avec une fonction de réassemblage exécutéepar le module Internet du destinataire. Bien sûr, lafragmentation 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êmeréseau sont permis, dans la mesure où cettetechnique est totalement transparente pour les protocoles Internetet à 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.

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

Adressage

Pour conserver toute la souplesse d'assignation d'adresse à des réseaux et pouvoir prendre en compte un grand nombre de réseaux de petite taille ou de taille moyenne, la structure des champs d'adresse est codée de sorte à désigner un petit nombre de réseaux accueillant un très grand nombre d'hôtes, un nombre modéré de réseaux accueillant un nombre modéré d'hôtes, et un grand nombre de réseaux accueillant un nombre restreint d'hôtes. De plus, un encodage spécial permet de prévoir un mode d'adressage étendu futur.

Formats d'adresse :

Poids forts Format Classe
----------- ------------------------------------------- -----
0 7 bits réseau, 24 bits hôte A
10 14 bits réseau, 16 bits hôte B
110 21 bits réseau, 8 bits hôte C
111 basculement en mode adressage étendu

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.

Lesvaleurs assignées actuellement pour les adresses de réseausont données dans le document "Assigned Numbers"[9].

L'adresselocale, définie par rapport au réseau local, doitpermettre à un hôte "physique" de pouvoir êtreconsidéré comme plusieurs hôtes Internet. Ceciveut dire qu'une table de transcription doit exister entre lesadresses Internet d'hôte et les adresses d'interfaces réseaupermettant à plusieurs adresses Internet d'êtreaccessible par la même interface. Un hôte doit àl'inverse pouvoir dispose de plusieurs interfaces physiques au réseauet traiter les datagrammes y parvenant comme s'ils avaient étéadressés à un hôte unique.

Lestranscriptions d'adresses Internet en adresses ARPANET, SATNET,PRNET, ou d'autre réseaux sont définies dans ledocument "Address Mappings" [5].

Fragmentation et Réassemblage.

Lechamp d'Identification (ID) permet, en combinaison avec lesadresses source et destination et le champ de protocole,d'identifier les segments appartement au même datagramme envue d'un réassemblage.

Lebit Dernier Fragment (DF) est marqué et si le datagramme neporte pas le dernier fragment du datagramme original. Le champFragment Offset identifie la position relative du fragmenttransporté, par rapport au début du datagrammeoriginal non fragmenté. Les fragments sont mesuréspar blocs de 8 octets. La stratégie de fragmentation estainsi faite qu'un datagramme non fragmenté porte tous leschamps 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 blocsmultiples de 8 octets excepté le dernier fragment.

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

Lorsd'une fragmentation, certaines options sont recopiées danschaque en-tête de fragment, d'autres ne sont transmisesqu'une fois dans l'en-tête du premier segment.

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

Toutdestinataire Internet doit être capable de recevoir undatagramme d'au moins 576 octets soit d'un seul morceau soit enplusieurs fragments à réassembler.

Leschamps qui peuvent être modifiés lors d'unefragmentation 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

Sile bit anti-fragmentation (AF) est marqué, alors toutefragmentation du datagramme Internet est rigoureusement INTERDITE,bien que le datagramme puisse être rejeté. Ceci peut êtreutilisé pour prévenir le cas où les modules récepteursne disposent pas de ressources mémoires suffisantes pour réassemblercorrectement les fragments.

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

Lesprocédures de fragmentation et de réassemblage sontbien mieux décrites par des exemples. La procéduresuivante est un exemple d'implémentation de fragmentation.

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

Exemple de procédure de fragmentation

Ledatagramme de taille la plus grande pouvant être transmisdans la section de réseau suivante est appelée unitéde transmission maximale (UTM).

Sila longueur totale est inférieure ou égale àla taille de l'UTM alors le datagramme doit être directementtransmis à l'étape suivant la fragmentation;autrement, le datagramme est coupé en deux, le premier detaille égale à la taille de l'UTM, et le secondfragment 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ù sataille 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 maximum

Procédure :

IF LT =< UTM THEN       Soumettre le datagramme à l'étape suivante ELSE IF AF = 1 THEN       détruire le datagramme  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

Pourchaque datagramme, le tampon d'identification est constituéen concaténant les adresses de source, de destination, lechamp protocole, et d'identification. Si le fragment reçucomplète un datagramme en cours de réception (c'est àdire que son fragment offset et le bit Dernier Fragment sont tousdeux à zéro), alors toutes les ressources allouéesà la fonction de réassemblage pour ce tampond'identification sont libérées et le datagrammeachevé est passé à l'étape suivante dutraitement.

Siaucun autre fragment n'est actuellement en mémoire pour cetampon d'identification, alors des nouvelles ressources sont allouéespour démarrer un réassemblage. Les ressources pourle réassemblage consistent en un tampon de données,un autre pour l'en-tête, une table bit des blocs defragments, un champ de longueur totale, et un temporisateur. Lesdonnées du fragment sont copiées dans le tampon dedonnées à leur position relative indiquée parle fragment offset et l'indication de longueur, et les bitscorrespondants de la table bit des blocs de fragments sont marquéspour les blocs traités.

S'ils'agit du premier fragment (fragment offset vaut zéro) sonen-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 fragmentsattendus se retrouvent marqués), alors le datagramme esttransféré à l'étape suivante detraitement; sinon, on compare la valeur actuelle du temporisateuravec la durée de vie notifiée dans ce fragment et oninitialise le temporisateur avec la plus grande valeur des deux;la routine de réassemblage rend alors la main.

Sile temporisateur arrive en fin de course, toutes les ressourcesconsommées pour ce tampon d'identification sont libérées.La valeur initiale de temporisation est la limite inférieurethéorique du temps d'attente pour réassemblage. Cechoix se justifie du fait que le temps effectif de réassemblagepeut augmenter si le champ durée de vie du fragment reçuest supérieur à la valeur courante de temporisation,mais en aucun cas diminuer étant donné le mécanismemis en place. La valeur maximale que ce temporisateur peut prendreest la durée de vie maximum (approximativement 4,25minutes). La valeur de temporisation initiale recommandéeaujourd'hui est environ 15 secondes. Cette valeur sera susceptiblede changement par l'usage. Notez que le choix de la valeur deparamètre est lié à la capacité dutampon disponible ainsi qu'à la vitesse de transmission dumé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 Temporisation

Procé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 (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

Le choix d'un identificateur de datagramme est motivé par la nécessité de pouvoir distinguer de façon unique les fragments appartenant à un datagramme particulier. Le module rassemblant les fragments juge que des fragments appartiennent à un même datagramme si ils ont une source, une destination, un protocole, et un identificateur identiques. De ce fait, l'émetteur doit choisir un identificateur unique pour telle paire de source et de destinataire, et pour tel protocole durant toute la durée de transit des fragments des datagrammes.

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 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

Le type of service (TdS) sélectionne la qualité de service Internet délivrée. Ce type de service est exprimé en termes de priorité, retard, débit, et fiabilité. Ces paramètres abstraits doivent être associés aux paramètres actuellement utilisés par chaque protocole local, pour chaque section de réseau traversée.

  • 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.

Par exemple, ARPANET marque le bit priorité, et un choix entre des messages "standard" (type 0) et messages "uncontrolled" (type 3), (le choix entre des messages de type paquet unique ou paquets multiples peut aussi être considéré comme un paramètre de type de service). Les messages "uncontrolled" ont tendance à être acheminés plus rapidement, mais au prix d'une certaine fiabilité. Supposons qu'un datagramme Internet doive transiter par ARPANET. Donnons un type de service défini selon :

      Priorité  :    5
      Retard    :    0 
      Débit     :    	1
      Fiabilité :    1

Dans 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é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

Ladurée de vie est initialisée par l'émetteurdu datagramme à la durée maximum pendant lequel ledatagramme pourra exister dans le réseau. Si un routeur ouautre module Internet intercepte un datagramme plus "vieux"que cette durée de vie, alors ce dernier doit être détruit.

Cechamp doit être décrémenté àchaque point du réseau où l'en-tête Internetest interprétée, d'une valeur représentant àpeu près le temps passé à traiter ledatagramme. Même si le système local n'est pas enmesure de fournir une mesure de ce temps, ce champ doit êtredé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 soit4,25 minutes. Comme chaque module Internet doit impérativementdé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 doittoujours être interprétée comme la duréethéorique maximale pendant laquelle le datagramme peutexister. La justification de ce mécanisme est d'écarterautomatiquement des datagrammes qui n'ont pu trouver leurdestinataire, ainsi qu'imposer une limite théorique àla charge globale du réseau.

Deplus, certains protocoles de niveau supérieur s'appuientsur la supposition qu'aucun "doublon" de datagrammeprovenant d'une connexion précédente ne peut arriverau delà d'un certain temps (Cf. TCP). Ce mécanismede durée de vie permet de garantir à ces protocolesla validité de cette supposition.

Options

Lesoptions sont optionnelles dans les datagrammes, mais les implémentationsdoivent nécessairement prévoir leur présence.En d'autres termes, la présence ou l'absence d'options dansle datagramme reste un choix de l'émetteur, mais toute implémentationde module Internet doit disposer des routines permettant leurtraitement. On pourra trouver diverses options dans le champd'en-tête.

L'insertiond'options peut conduire à une taille d'en-têtedistincte d'un multiple de 32 bits. Cette dernière doit êtrecomplétée par des octets nuls afin de respecter cepoint. Le premier de ces octets nuls sera interprétécomme l'option particulière "fin de liste d'options",les octets suivants étant appelés "octets debourrage".

Toutmodule Internet doit savoir réagir à toute option "officielle".L'option de sécurité doit être utiliséeen cas de transmission de trafic compartimenté, restreintou confidentiel.

Checksum

LeChecksum d'en-tête doit être recalculé àchaque fois que l'en-tête Internet a subi une modification.Par exemple, lorsque la durée de vie a été décrémentée,des options Internet ajoutées, modifiées ou supprimées,ou suite à une fragmentation. Ce Checksum Internet protègel'en-tête contre les erreurs de transmission.

Ilexiste certaines applications pour lesquelles quelques erreurs "bit"restent acceptables alors qu'un retard dû à uneretransmission ne l'est pas. Si le protocole Internet avaitintroduit la notion de contrôle de transmission sur les données,de telles applications n'auraient pu s'appuyer sur ce protocole.

Erreurs

Toutes les erreurs en rapport avec le protocole Internet devront être reportées à l'aide de messages ICMP [3].

3.3. Interfaces

Ladescription fonctionnelle des interfaces entre IP et la couche supérieurne peut être exposée que dans sa signification sémantiquethéorique, dans la mesure où chaque systèmed'exploitation proposera ses propres primitives. Par conséquent,nous nous devons d'avertir le lecteur que des implémentationsdistinctes d'IP pourront présenter des interfaces différentes.Cependant, tous les modules IP doivent fournir un ensemble minimumde fonctions d'accès pour garantir la cohérence dela hiérarchie des protocoles. Cette section spécifieles interfaces fonctionnelles requises pour toutes les implémentationsd'IP.

Lesdeux interfaces du protocole Internet visent d'un côtéle protocole réseau local, et de l'autre un protocole deniveau supérieur voire directement un programme applicatif.Dans ce qui suit, le protocole de niveau supérieur ou leprogramme applicatif (où même le logiciel d'unrouteur) sera assimilé à "l'utilisateur"dans la mesure où c'est lui qui "utilise" lemodule Internet. Comme le protocole Internet est basé surle principe du datagramme, la mémoire ou les étatsmaintenus entre deux transmissions de datagrammes sont réduitsau minimum, et chaque appel au module Internet fournit àcelui-ci toutes les informations nécessaires à l'émissioncorrecte et complète des données.

Un exemple d'interface supérieure

Les deux exemple d'appels suivants satisfont les exigences minimales de communication entre l'utilisateur et le module de protocole Internet ("=>" signifie "retour"):

SEND (src, dst, prot, TdS, TTL, BufPTR, lon, Id, AF, opt => result)

où :


      src = adresse source
      dst = adresse destinataire
      prot = protocole
      TdS = type de service
      DdV = durée de vie
      BufPTR = pointeur sur tampon
      lon = longueur de tampon
      Id  = Identificateur
      AF = Antifragmentation
      opt = donnée d'option
      result = réponse
        OK = datagramme émis
        Error = erreur dans les arguments ou erreur réseau local

Notez que la priorité est prise en compte dans le TdS et les données de sécurité/compartiment sont passés comme option.


RECV (BufPTR, prot, => result, src, dst, TdS, lon, opt)

dans laquelle :


      BufPTR = pointeur sur tampon
      prot = protocole
      result = réponse
        OK = datagramme reçu
        Error = erreur dans les arguments
      lon = longueur du tampon
      src = adresse source
      dst = adresse destination
      TdS = type de service
      opt = donnée d'option

Lorsquel'utilisateur envoie un datagramme, il exécute un appelSEND en fournissant tous les arguments. Le module Internet, sur réceptionde cet appel, vérifie les arguments, prépare etenvoie le message. Si les arguments sont corrects et le datagrammeest accepté par le module réseau local, alorsl'appel se termine par un retour normal. Dans le cas oùsoit les arguments sont erronés, soit que le datagramme a étérefusé par la couche réseau local, l'appel setermine par un retour d'erreur. Sur erreur, un rapport le plusexplicite devra être donné pour indiquer la cause duproblème, le degré de détail restant àla discrétion de l'implémenteur.

Lorsqu'undatagramme est remis au module Internet par le module réseaulocal, deux cas se présentent : soit un appel RECV émispar l'utilisateur est en attente, soit le module Internet n'a pasété sollicité. Dans le premier cas, il est réponduà l'appel en attente à l'aide des donnéescontenues dans le datagramme entrant. Dans le second cas,L'utilisateur est averti de la présence d'un datagramme luiétant destiné. Si l'utilisateur visé n'existepas, un message d'erreur ICMP doit être renvoyé àl'émetteur, et le datagramme détruit.

Lanotification à l'utilisateur pourra être faite viaune pseudo-interruption ou tout mécanisme similaire le plusapproprié en fonction des ressources et de la structure dusystème d'exploitation utilisé.

Ilsera ainsi possible de répondre immédiatement àun appel RECV et de n'envoyer le datagramme que lors de sa réception(interface asynchrone), ou au contraire de bloquer l'utilisateuren attendant que le datagramme soit parvenu au module Internet(interface synchrone).

L'adressesource doit être indiquée dans l'appel SEND au cas oùl'hôte émetteur disposerait de plusieurs adresses(raccordements physiques ou adresses logiques multiples). Lemodule Internet devra vérifier que l'adresse source donnéeest une adresse valide pour cet hôte.

Uneapplication pourra aussi permettre ou nécessiter un appelau module Internet pour indiquer son intérêt àou encore se réserver l'usage exclusif d'une certaineclasse de datagrammes (ex., tous ceux dont le champ protocole estégal à une certaine valeur).

APPENDICE A: Exemples & Scénarios

Exemple 1 :

Voici l'exemple d'un datagramme transmettant le minimum de données possible :


0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver= 4 |LET= 5 |Type de Service|     Longueur totale = 21      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Identification = 111     |Flg=0|   Fragment Offset = 0   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Temps = 123  | Protocole = 1 |            checksum           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         adresse source                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       adresse destination                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    données    |
+-+-+-+-+-+-+-+-+
Exemple de Datagramme Internet - Figure 5.

Notez que chaque marque vaut pour une position bit.

Cet exemple donne le datagramme minimum dans le protocole Internet de version 4 ; l'en-tête Internet est formée de 5 mots de 32 bits, et la longueur totale du datagramme est de 21 octets. Ce datagramme est un datagramme complet (pas un fragment).

Exemple 2 :

Dans cet exemple, nous exposons d'abord un datagramme Internet de taille moyenne (452 octets de données), puis deux datagrammes Internet portant les fragments de ce qui résulterait d'une fragmentation du premier datagramme pour un réseau dont la taille maximale de transmission vaut 280 octets.


0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver= 4 |LET= 5 |Type de Service|       Total Length = 472      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Identification = 111      |Flg=0|     Fragment Offset = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    DdV = 123  | Protocole = 6 |     checksum d'en-tête        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         adresse source                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      adresse destination                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             données                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             données                           |
\                                                               \
\                                                               \
|                             données                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             données           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Exemple de Datagramme Internet - Figure 6.

Et maintenant le premier fragment obtenu en coupant les données précédentes après le 256ème octet de données.


0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver= 4 |LET= 5 |Type de Service|    Longueur totale = 276      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Identification = 111      |Flg=1|     Fragment Offset = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   DdV = 119   | Protocole = 6 |      Checksum d'en-tête       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         adresse source                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      adresse destination                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            données                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             données                           |
\                                                               \
\                                                               \
|                             données                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             données                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Exemple de Fragment Internet - Figure 7.

Et le second fragment.


0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver= 4 |LET= 5 |Type de Service|    Longueur totale = 216      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Identification = 111      |Flg=0|  Fragment Offset  =  32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    DdV = 119  | Protocole = 6 |     Checksum d'en-tête        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         adresse source                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      adresse destination                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             données                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             données                           |
\                                                               \
\                                                               \
|                             données                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            données            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Exemple de dernier fragment Internet - Figure 8.

Exemple 3 :

Voici un exemple de datagramme contenant des options :


0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0  
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver= 4 |LET= 8 |Type de Service|    Longueur totale = 576      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Identification = 111    |Flg=0|     Fragment Offset = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   cDdV = 123  | Protocole = 6 |    Checksum d'en-tête         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        adresse source                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      adresse destination                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code  Opt.= x | Long. Opt.= 3 | valeur option | Code  Opt.= x |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lon. Opt. = 4 |           option value        | Code  Opt.= 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code  Opt.= y | Long. Opt.= 3 |  option value | Code  Opt.= 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             données                           |
\                                                               \
\                                                               \
|                             données                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             données                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Exemple Internet Datagramme - Figure 9.

APPENDICE B: Ordre de transmission des données

L'ordre de transmission de l'en-tête et des données décrites dans ce document se résout au niveau octet. Lorsqu'un datagramme contient un groupe d'octets, l'ordre de transmission de ces octets est l'ordre "naturel" dans lequel nous allons les lire en Français. Par exemple, dans le schéma ci-dessous les octets sont transmis dans l'ordre de leur numérotation.


0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       1       |       2       |       3       |       4       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       5       |       6       |       7       |       8       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       9       |      10       |      11       |      12       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Ordre de transmission des octets - Figure 10.

Lorsqu'un octet représente une valeur numérique, le bit de gauche dans le schéma ci-dessous est celui de poids le plus fort. Ici le bit noté 0. L'exemple suivant montre le codage de la valeur 170 (décimale).


 0 1 2 3 4 5 6 7 
+-+-+-+-+-+-+-+-+
|1 0 1 0 1 0 1 0|
+-+-+-+-+-+-+-+-+
Conventions sur la signification des bits - Figure 11.

Par extension, lorsqu'une valeur numérique est codée sur plusieurs octets, le bit de gauche du champ complet est celui de poids le plus fort. De ce fait, lorsqu'un champ multi-octets est transmis, l'octet de poids le plus fort est toujours transmis en premier.

GLOSSAIRE

1822
BBN Report 1822, "A Specification of the Interconnection of a Host and an IMP". La spécification de l'interface entre un hôte et ARPANET.

Adresse Internet
L'adresse sur 4 octets (32 bit) d'une source ou d'une destination composée d'une adresse Réseau et d'une adresse Locale.

Adresse Locale
L'adresse d'un hôte dans un réseau local. La transcription des adresses Internet en adresse physiques d'hôtes est assez libre, permettant des affectations non bijectives.

AF
Le bit AntiFragmentation dans les divers bits de contrôle.

Bit Dernier Fragment
Un bit indiquant si le fragment Internet contient les dernières données du datagramme qu'il transporte.

Bits de contrôle (flags)
Divers bits de signification booléenne dans l'en-tête Internet.

Bourrage
Ces octets sont ajoutés pour s'assurer que la section de données commence sur le début d'un mot de 32 bits. L'octet de bourrage vaut zéro.

Datagramme Internet
L'unité de transmission entre une paire de modules Internet (incluant l'en-tête Internet).

Destination
L'adresse du destinataire, un champ d'en-tête Internet.

DdV
Durée de Vie

DF
Le bit Dernier Fragment de l'en-tête Internet.

Durée de Vie
Champ d'en-tête Internet qui donne la durée de vie maximale pendant laquelle un datagramme peut exister dans le réseau.

En-tête
Information de contrôle au début d'un message, d'un segment, d'un datagramme, d'un paquet ou bloc de données.

Fragment Internet
Une portion de données d'un datagramme Internet associée à une en-tête.

Fragment Offset
Un champ permettant de coder la position relative du fragment par rapport au datagramme non fragmenté.

GGP
Protocole Routeur vers Routeur, le protocole utilisé entre routeurs pour s'échanger des informations de routage et autres fonctions.

ICMP
Internet Control Message Protocol. Implémenté dans le module Internet, le protocole ICMP est utilisé depuis les routeurs vers les hôtes et entre hôtes pour le report de fautes et des suggestions de routage.

Identification
Un champ d'en-tête Internet transportant une valeur d'identification temporaire destinée à aider au réassemblage des fragments d'un datagramme.

IHL
Un champ d'en-tête Internet codant la longueur de l'en-tête en mots de 32 bits.

IMP
L'Interface Message Processor, l'élément de commutation de paquet du réseau ARPANET.

Leader ARPANET
L'information de contrôle d'un message ARPANET au niveau de l'interface hôte-IMP.

Longueur Totale
Un champ d'en-tête Internet qui donne la longueur totale du datagramme en octets, y compris données et en-tête.

Message ARPANET
L'unité de transmission entre un hôte et un IMP dans ARPANET. La taille maximum est d'environ 1012 octets (8096 bits).

Module
Une implémentation, en général logicielle, d'un protocole ou d'une autre procédure.

NBF
Le Nombre de Blocs Fragment dans la portion données d'un fragment Internet. C'est à dire, le nombre de "mots" de 8 octets dans la section données d'un fragment.

Octet
Huit bits.

Options
Le champ d'en-tête Internet peut comporter plusieurs options, chaque option pouvant être constituée de plusieurs octets.

Paquet ARPANET
L'unité de transmission utilisé dans l'ARPANET entre deux IMPs. La taille maximum est d'environ 126 octets (1008 bits).

Protocole
Dans ce document, l'identificateur du protocole de niveau immédiatement supérieur, à qui doit être délivré le datagramme, champ d'en-tête Internet.

Reste
La partie d'une adresse Internet donnant l'adresse locale de la machine.

Source
L'adresse source, champ d'en-tête Internet.

TCP
Transmission Control Protocol : Un protocole sécurisé de transmission de données entre deux hôtes s'appuyant sur IP.

TFTP
Trivial File Transfer Protocol: Un protocole simple de transfert de fichiers basé sur UDP.

Segment TCP
L'unité de données échangé par un module TCP (avec une en-tête TCP).

TdS
Type de Service.

Type de Service
Un champ d'en-tête Internet qui indique le type (ou qualité) du service pour ce datagramme Internet.

UDP
User Datagramme Protocol: Un protocole de la couche "transport" pour des communications transactionnelles.

Utilisateur
L'utilisateur du protocole Internet. Celui-ci peut être un module de protocole de niveau supérieur, un programme d'application, ou un programme routeur.

Version
Le champ de version indique le format de l'en-tête Internet.

REFERENCES

[1] Cerf, V., "The Catenet Model for Internetworking," Information Processing Techniques Office, Defense Advanced Research Projects Agency, IEN 48, July 1978.

[2] Bolt Beranek and Newman, "Specification for the Interconnection of un Host and an IMP," BBN Technical Report 1822, Revised May 1978.

[3] Postel, J., "Internet Control Message Protocol - DARPA Internet Program Protocol Specification," RFC 792, USC/Information Sciences Institute, September 1981.

[4] Shoch, J., "Inter-Network Naming, Addressing, and Routing," COMPCON, IEEE Computer Society, Fall 1978.

[5] Postel, J., "Address Mappings," RFC 796, USC/Information Sciences Institute, September 1981.

[6] Shoch, J., "Packet Fragmentation in Inter-Network Protocols," Computer Networks, v. 3, n. 1, February 1979.

[7] Strazisar, V., "How to Build a Routeur", IEN 109, Bolt Beranek and Newman, August 1979.

[8] Postel, J., "Service Mappings," RFC 795, USC/Information Sciences Institute, September 1981.

[9] Postel, J., "Assigned Numbers," RFC 790, USC/Information Sciences Institute, September 1981.

 




Sondage

Quel est votre connexion à Internet aujourd'hui ?
 
RTC 56Kbps
ADSL simple de 128 à 2048 Kbps
ADSL + Téléphonie (+TV) de 128 à 2048 Kbps
ADSL simple jusqu'à 20Mbps
ADSL + Téléphonie (+TV) jusqu'à 20Mbps
Autres (RNIS, Satellites bi-directionnel...)
Total :
3241

Recherche


Docs
   Pflogsumm (Analyseur de log mail pour Postfix)
   Proftpd (Mise en service d'un serveur FTP avec proftpd sous Linux)
   Openldap (Mise en service d'un serveur LDAP sous Linux)
   Gestion des périphériques en c++ builder (Communication RS232 en C++ Builder)
   Les sockets windows (Windows Sockets : un cours accéléré)

guill.net©1999-2024