Logo English Web Page
Accueil Association BSD Linux Dev Reseau Infologisme Mac OSX
tl tr
Sujet Adresse IP Date 20-12-2010
Titre Datagramme IP Section Dev Reseau
Article

En-tête Datagramme TCP/IP

Les protocoles TCP/IP ont été conçue pour transmettre les données à travers le réseau ARPANET, qui était un réseau à communications de paquets. Un paquet est un bloc de données qui véhicule avec lui l‘information nécessaire pour qu‘il soit délivré, comme une lettre de votre factrice préférée. Un réseau à commutation de paquets utilise l‘information d‘adressage située dans les paquets pour commuter les paquets d‘un réseau physique en un autre, vers leur destination finale. Chaque paquet se déplace à travers le réseau indépendamment des autres paquets.

Le datagramme est le format de paquet définit par le protocole IP. Les cinq ou six premiers mots de 32 bits de ce datagramme sont des informations de contrôle appelées en-tête. Par défaut, l‘en-tête possède une taille de cinq mots. Le sixième est optionnel. Comme la taille de l‘en-tête est variable, il inclut un champ appelé IHL (Internet Header Lenght) qui indique la taille de l‘en-tête en mots. L‘en-tête du datagramme contient toujours toutes les informations nécessaires à l‘acheminement du paquet, c‘est à dire du datagramme.

Par structure, le datagramme IP rappelle les trames utilisées dans les couches inférieures des protocoles réseau. Il est composé des données des couches supérieures, c‘est à dire les données des applications contenues dans les messages TCP/UDP, précédées d‘un en-tête comportant les informations de contrôle propre au protocole IP.

En-tête Données

Le datagramme IP est véhiculé dans les trames des réseaux traversés. Par exemple, pour les réseaux Ethernet, les datagrammes sont encapsulés dans des trames Ethernet II, dont le champ type indique la valeur 0800.

@destination @source 0800 Datagramme IP CRC
Trame Ethernet II

Détaillons maintenant un en-tête du datagramme représenté en cinq ou six mots de 32 bits (4 octets).

0 4 8 12 16 20 24 28 32
Version IHL Type service Longueur Total
Identification FLAGS Déplacement fragmentation
Durée de vie Protocole Somme de contrôle
Adresse IP source
Adresse IP destination
Options Bourrage
Début de la zone de données

Version

Le champ version contient sur 4 bits le numéro de version du protocole IP utilisé par le datagramme. Il permet aux équipements de vérifier le format et d‘interpréter correctement la suite du datagramme. C‘est d‘ailleurs pour cette raison qu‘il est placé au début. Une version inconnue par un équipement conduit au rejet du datagramme.

Internet Protocole IP est actuellement implémenté en version 4 qui est IPV4, la version 5 fut expérimentale. La version 6, appelée IPV6 est utilisée également de nos jours. Les deux versions cohabitent dans leur utilisation pour un fondement matériel.

Longueur d‘en-tête - IHL

La longueur de l‘en-tête est codée sur 4 bits et comptée en mots de 32 bits. Tous les champs sont de taille fixe, à l‘exception du champ Option. Ce dernier est complété d‘un champ bourrage pour donner un multiple de 32 bits. Sans le champ option, l‘en-tête IP est composé de 5 mots de 32 bits. Avec des options, il peut varier de 6 à 15.

Type de service

Ce champ est composé de 6 sous-champs.

0 1 2 3 4 5 6 7 8
Priorité D T R C Inutil.

La plupart des implémentations IP (Stations et Routeurs) ignorent le champ Type de service, qui prend dans ce cas la valeur suivante : 00000000

Toutefois, il constitue un mécanisme intéressant pour assurer un meilleur acheminement des datagrammes.

La valeur Priorité permet d‘indiquer l‘importance du datagramme.
0 (000) Routine
1 (001) Prioritaire
2 (010) Immédiat
3 (011) Urgent
4 (100) Très urgent
5 (101) Critique
6 (110) Supervision interconnexion
7 (111) Supervision réseau
Les sous-champs D, T, R et C précisent des options désirées, mais non garanties.

Le sous-champ D précise le délai d‘acheminement (Delay) :
0 Délai normal
0 Délai court
Le sous-champ T précise le débit de transmission (Throughput) :
0 Débit normal
0 Débit élevé
Le sous-champ R précise le niveau de fiabilité (Reliability) :
0 Niveau de fiabilité normal
0 Niveau de fiabilité élevé
Le sous-champ C précise le cout :
0 Cout normal
0 Cout faible
Le dernier bit n‘est pas utilisé, il reste à 0. Il est qualifié de MBZ: Must Be Zero.

La description complète du champ Type de service est détaillé dans la RFC 1349.

Longueur du datagramme

La longueur du datagramme complet est exprimée en octets. Elle est codée sur 16 bits, ce qui permet d‘indiquer une taille maximale de 216 soit 65536 octets. La longueur du champ données peut être obtenue en déduisant la longueur de l‘en-tête.

Le mécanisme de fragmentation

Le deuxième mot contient des informations nécessaires au mécanisme de fragmentation des datagrammes.

Pour comprendre le mécanisme de fragmentation, il faut d‘abord se poser la question : Quelle taille optimale doit avoir un datagramme ?

Théoriquement, le datagramme est traité de manière logiciel et peut être de taille quelconque. Il n‘est limité que par la taille du champ longueur, soit 65536 octets.

En pratique, le datagramme est acheminé dans des trames spécifiques aux réseaux de données traversés. L‘idéal serait donc de pouvoir mettre un datagramme complet par trame. Hélas, ce n‘est pas évident. En fonction des réseaux, les trames peuvent contenir une quantité maximale d‘informations. Cette taille maximale est par exemple de 1500 octets sur les réseaux Ethernet et de 4470 octets sur les réseaux FDDI. Cette limite est appelée Maximum Transfer Unit (MTU). Certaines MTU peuvent être très petites. Régler la taille des datagrammes IP sur la plus petite MTU des réseaux traversés n‘est pas très efficace, notamment lorsque ce datagramme traverserait des réseaux avec une grande MTU. Ceci multiplierait le nombre de trames nécessaires. A l‘inverse, si le datagramme est trop grand, il ne peut être contenu dans une trame.

Le choix a été simple, plutôt que de tenir compte des particularités des réseaux physiques, les concepteurs du protocole IP ont choisi une taille initiale de 64 ko et ils ont implémenté un mécanisme permettant de découper les datagrammes en morceau lorsqu‘ils doivent traverser un réseau avec une plus petite MTU. Le mécanisme est appelé fragmentation et les morceaux sont dénommés fragments.

En pratique, la taille initiale des datagrammes n‘est pas toujours de 64 ko, mais elle peut être négociée au niveau de la connexion TCP. Par exemple, deux hôtes qui sont tout deux sur des réseaux Ethernet, négocieront une taille maximale de datagramme de 1500 octets.

Mais les deux hôtes ne connaissent pas les caractéristiques des réseaux traversés et il est fort probable que le datagramme soit amené à traverser un réseau avec une plus faible MTU et soit en conséquence fragmenté.

Prenons l‘exemple d‘un datagramme de 1500 octets avec un en-tête de 20 octets (5 mots de 32 bits). Pour traverser un réseau de MTU 500 octets, le datagramme sera fragmenté en morceaux de 500 octets, chacun avec l‘en-tête IP de 20 octets.
___ ___                                                            ___ ___
|       |                                                          |       |
|   P   |                                                          |   P   |
|___ ___|         MTU 1500                         MTU 1500        |___ ___|
________|________ ________________                ________________ ________|________
|                                                |
|________                                ________|
|                              |
___|___                        ___|___
|       |       MTU 1500       |       |
|   R   |______________________|   R   |
|___ ___|                      |___ ___|
Un rapide calcul nous donne :
    1500                       500                 500                  500                  60
(20  +  1480)    =    (20  + 480 )  +  (20  +  480)  +  (20  +  480)  +  (20  +  40)
Le datagramme sera donc fragmenté en 3 morceaux de 500 et un morceaux de 60 octets.

Que se passe-t-il si les fragments arrivent sur un réseau avec une plus grande MTU ?

On pourrait penser qu‘il serait judicieux de réassembler les fragments pour les adapter à la MTU traversée. Pourtant le mécanisme serait complexe et il n‘est pas certain que tous les fragments aient pris la même route et donc arrivent tous sur le même réseau. Que faire s‘il manque un fragment ? Le choix est de ne réassembler les fragments qu‘à l‘arrivée, c‘ est à dire sur l‘hôte final, lorsque tous les fragments sont arrivés.

Le deuxième mot de l‘en-tête IP fournit les informations permettant de réassembler les fragments.
0 1 2 3 4 5 6 7 8
Identification DF MF Offset
D‘abord il est nécessaire de bien identifier les fragments appartenant au un même datagramme. Il est possible que deux datagrammes soit envoyés entre les deux hôtes et que leurs fragments respectifs s‘intercalent. Le couple (adresse IP Source, Adresse IP destination) n‘est pas suffisant. Le champ identifiant fournit un numéro sur 16 bits commun à tous les fragments d‘un même datagramme.

Il faut ensuite les assembler dans l‘ordre. Les fragments ont pu suivre des routes différentes et dans ce cas, n‘arrivent pas nécessairement dans l‘ordre. L‘offset (ou décalage) fournit ainsi la position du fragment dans la datagramme d‘origine, comptée en blocs de huit octets. Elle est indiquée sur 13 bits, ce qui donne bien une position en octets sur 213 * 8, soit 65536 octets. Dans notre exemple, les offsets prendront les valeurs 0, 60, 120 et 180.

Le bit MF ( More Fragment) est positionné à 1 pour tous les fragments sauf sur le dernier ou il est positionné à 0.

Un datagramme non fragmenté est caractérisé par un offset de 0 et un bit MF également à 0. « Il est le premier et le dernier, donc il est seul et unique ».

Le bit DF signifie Don‘t Fragment. Lorsqu‘il est positionné à 1, le datagramme ne peut pas être fragmenté. Si c‘est nécessaire pour l‘acheminement, il est écarté et détruit. Le bit DF n‘est pas utilisé pour un transfert normal, mais pour l‘administration des réseaux. En le positionnant et en modifiant la taille des datagrammes initiaux, il est ainsi possible de connaître la plus petite MTU des réseaux traversés, à partir de la source.

Time To Live

Le troisième mot contient le champ TTL (Time To Live) qui indique le temps pendant lequel le datagramme peut circuler sur le réseau. Il est décrémenté de un lorsque le datagramme arrive sur un Routeur traversé, puis à chaque seconde passée en attente au niveau de ce Routeur.

Lorsque la durée de vie atteint la valeur 0, le Routeur détruit le datagramme et envoie un message d‘erreur à l‘hôte qui l‘a émis. La valeur initiale dépend des couches supérieures.

Son utilisation permet de détruire les datagrammes qui circuleraient en boucle lorsque parfois les tables de routage sont corrompues.

Protocole

Le champ protocole de transport indique le type de protocole supérieur utilisé dans le message véhiculé (couche transport).
0 Réservé
1 Internet Control Message Protocol (ICMP)
2 Internet Group Management Protocol (IGMP)
3 Gateway-to-Gateway Protocol (GGP)
4 IP (IP encapsulation)
5 Stream
6 Transmission Control (TCP)
8 Exterior Gateway Protocol (EGP)
9 Private Interior Routing Protocol
17 User Datagram (UDP)
89 Open Shortest Path First
La liste complète des numéros est fournie dans la RFC 1340 : Assigned Numbers

Checksum - Somme de contrôle

Le checksum d‘en-tête sur 16 bits est formé par le complément à 1 de la somme des mots de 16 bits de l‘en-tête Pour le calcul, le champ Cheksum contient la valeur 0.

Ce contrôle ne porte que sur l‘en-tête, ce qui offre un avantage celui d‘être particulièrement rapide, mais oblige les protocoles supérieurs à mettre en œuvre leurs propres mécanismes de contrôle d‘intégrité des données.

Enfin, le checksum doit être recalculé à chaque Routeur, en fonction de la nouvelle valeur du TTL.

Adresses IP

Les quatrième et cinquième mots contiennent l‘adresse IP source et l‘adresse IP destination.

Options

Le sixième mot permet de préciser différentes options sous forme d‘une liste. Il n‘est pas obligatoire et n‘est utilisé qu‘à des fins de test ou de mise au point. Les options sont indiquées sous forme de code d‘option sur un octet. Le code d‘option est défini par trois sous-champs :
0 1 2 3 4 5 6 7 8
Copie Classe d'option Numéro d'option

Format de l‘octet Code option

Le bit Copie indique comment les options doivent être traitées lors de la fragmentation. Lorsqu‘il est positionné à 1, il indique que les options doivent être recopiées dans chacun des fragments. Lorsqu‘il est à 0, les options ne sont recopiées que dans le premier fragment.

La classe d‘option et le numéro indiquent le type de l‘option. Actuellement seules deux classes sont définies sur les quatre possibles : 0 pour la supervision des datagrammes et 2 pour les mises au point et mesures ; les classes 1 et 3 ne sont pas utilisées.
Classe d‘option Description
0 Datagramme ou supervision de réseau
1 Réservé pour une utilisation future
2 Mise au point et mesures
3 Réservé pour une utilisation future
Classe d‘option Numéro d‘option Description
0 0 Fin de liste d‘option. Utilisé si les options ne se terminent pas à la fin de l‘en-tête (bourrage)
0 1 Pas d‘opération. Utilisé pour aligner les octets dans une liste d‘options.
0 2 Restriction de sécurité et de gestion. Destiné aux applications militaires.
0 3 Routage lâche défini par la source.
0 7 Enregistrement de route.
0 8 Identificateur de connexion.
0 9 Routage strict défini par la source.
2 4 Horodatage dans l‘internet.


Article connexe du sujet

Description du Protocole TCP/IP et Classes d‘Adresses Réseaux Privés
RFC 791 - Internet Protocol IP
RFC 793 - Transmission Control Protocol TCP

Auteur
Eric Douzet
Début de page
bl br
C-extra.com v. 1.2.2 © 2000-2014, tous droits réservés  –  Mise à jour le 12 Avril 2014 Infologisme.com