Entête IP

Entête IP

1 – Définition du protocole IP

IP signifie « Internet Protocol », protocole Internet. Il représente le protocole réseau le plus répandu. Il permet de découper l’information à transmettre en paquets, de les adresser, de les transporter indépendamment les uns des autres et de recomposer le message initial à l’arrivée. Ce protocole utilise ainsi une technique dite de commutation de paquets. Il apporte, en comparaison à Ipx/Spx et Netbeui, l’adressage en couche 3 qui permet, par exemple, la fonction principale de routage.

Il est souvent associé à un protocole de contrôle de la transmission des données appelé TCP, on parle ainsi du protocole TCP/IP. Cependant, TCP/IP est un ensemble de protocole dont voici les plus connu.

Vous trouverez tous les détails du protocole IP dans la RFC 791.

2 – Structure de l’entête

Voici la structure de l’entête IP basé sur 20 octets.

entete-ip entete ip

Voici le complément de l’entête IP qui est optionnel basé sur 4 octets.

entete-ip entete ip option

3 – Définition des différents champs

3.1 – Le champ Vers

Le champ version est codé sur 4 bits. Il représente le numéro de version du protocole IP. Il permet aux piles IP réceptionnant la trame de vérifier le format et d’interpréter correctement la suite du paquet. C’est d’ailleurs pour cette raison qu’il est placé au début, une version inconnue par un équipement conduit au rejet direct.

Voici la liste des différent codes.

  • 00 – Réservé
  • 01 – Non assigné
  • 02 – Non assigné
  • 03 – Non assigné
  • 04 – IP V4
  • 05 – ST Datagram Mode
  • 06 – IP V6
  • 07 – Non assigné
  • 08 – Non assigné
  • 09 – Non assigné
  • 10 – Non assigné
  • 11 – Non assigné
  • 12 – Non assigné
  • 13 – Non assigné    
  • 14 – Non assigné    
  • 15 – Réservé

3.2 – IHL

IHL signifie « Internet header lengh ». ce champ est codé sur 4 bits et représente la longueur en mots de 32 bits de l’entête IP. Par défaut, il est égal à 5 (20 octets), cependant, avec les options de l’entête IP, il peut être compris entre 6 et 15.

Le fait que le codage soit sur 4 bits, la taille maximum de l’entête IP est donc de 15*32bits/8 = 60 octets

3.3 – Service

Le champs service « Type Of Service » est codé sur 8 bits, il permet la gestion d’une qualité de service traitée directement en couche 3 du modèle OSI. Cependant, la plupart des équipements de Backbone, ne tiennent pas compte de ce champ et même certain le réinitialise à 0.

Voici la composition du champ Service :

entete-ip entete ip champ service

Vous trouverez tous les détails du champ Service TOS « Type Of Service » dans la RFC 1349.

3.3.1 – Priorité

Le champ Priorité « Precedence » est codé sur 3 bits. Il indique la priorité que possède la paquet. Voici les correspondances des différentes combinaisons :

  • 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

3.3.2 – Délai

Le champ Délai « Delay » est codé sur 1 bit. Il indique l’importance du délai d’acheminement du paquet. Voici les correspondances des différentes combinaisons :

  • 0 – Normal
  • 1 – Bas

3.3.3 – Débit

Le champ Débit « Throughput » est codé sur 1 bit. Il indique l’importance du débit acheminé. Voici les correspondances des différentes combinaisons :

  • 0 – Normal
  • 1 – Haut

3.3.4 – Fiabilité

Le champ Fiabilité « Reliability » est codé sur 1 bit. Il indique l’importance de la qualité du paquet. Voici les correspondances des différentes combinaisons :

  • 0 – Normal
  • 1 – Haute

3.3.5 – Coût

Le champ Coût « Cost » est codé sur 1 bit. Il indique le coût du paquet. Voici les correspondances des différentes combinaisons :

  • 0 – Normal
  • 1 – Faible

3.3.6 – MBZ

Le champ MBZ « Must Be Zero » est codé sur 1 bit. Comme son nom l’indique, il doit être mis à 0.

3.4 – Longueur totale

Le champ Longueur totale est codé sur 16 bits et représente la longueur du paquet incluant l’entête IP et les Data associées. La longueur totale est exprimée en octets, ceci permettant de spécifier une taille maximum de 216 = 65535 octets. La longueur des Data est obtenu par la combinaison des champs  IHL et Longueur totale :

  • Longueur_des_data = Longueur_totale – ( IHL * 4 );

3.5 – Identification

Le champ Identification est codé sur 16 bits et constitue l’identification utilisée pour reconstituer les différents fragments. Chaque fragment possède le même numéro d’identification, les entêtes IP des fragments sont identiques à l’exception des champs Longueur totale, Checksum et Position fragment.

 Vous trouverez tous les détails des mécanismes de fragmentation et de réassemblage dans la RFC 815.

3.6 – Flags

Le champ Flags est codé sur 3 bits et indique l’état de la fragmentation. Voici le détail des différents bits constituant ce champ.

3.6.1 – Reserved

Le premier bit est réservé et positionné à 0.

3.6.2 – DF

Appelé DF « Don’t Fragment », le second bit permet d’indiqué si la fragmentation est autorisée. Si un Datagramme devant être fragmenté possède le flag DF à 1, alors, il  sera alors détruit.

3.6.3 – MF

Appelé MF « More Fragments », le troisième bit indique s’il est à 1 que le fragment n’est pas le dernier.

3.7 – Position fragment

Le champ Position fragment est codé sur 13 bits et indique la position du fragment par rapport à la première trame. Le premier fragment possède donc le champ Position fragment à 0.

3.8 – TTL

Le champ TTL (Time To Live) est codé sur 8 bits et indique la durée de vie maximale du paquet. Il représente la durée de vie en seconde du paquet. Si le TTL arrive à 0, alors l’équipement qui possède le paquet, le détruira.

Attention, à chaque passage d’un routeur le paquet se verra décrémenté de une seconde. De plus, si le paquet reste en file d’attente d’un routeur plus d’une seconde, alors la décrémentation sera plus élevée. Elle sera égale au nombre de seconde passé dans cette même file d’attente. Par défaut, si les temps de réponse sont corrects, alors on peut, entre guillemet, en conclure que le Time To Live représente le nombre de saut maximum du niveau.

Le but du champ TTL est d’éviter de faire circuler des trames en boucle infinie.

3.9 – Protocole

Le champ Protocole est codé sur 8 bits et représente le type de Data qui se trouve derrière l’entête IP.

Vous trouverez tous les détails des types de protocole dans la RFC 1700 qui remplace désormais la RFC 1340.

Voici la liste des protocoles les plus connu :

  • 01 – 00001 – ICMP
  • 02 – 00010 – IGMP
  • 06 – 00110 – TCP
  • 17 – 10001 – UDP

3.10 – Checksum

Le champ Checksum est codé sur 16 bits et représente la validité du paquet de la couche 3. Pour pouvoir calculer le Checksum, il faut positionner le champ du checksum a 0 et ne considérer que l’entête IP. Donc par exemple, si deux trames ont la même entête IP (y compris le champ length) et deux entêtes ICMP et Data différentes (mais de même longueur), le checksum IP sera alors le même.

Voici un exemple de fonction permettant le calcul du checksum IP

unsigned short calcul_du_checksum(bool liberation, unsigned short *data, int taille)
     {
     unsigned long checksum=0;
     // ********************************************************
     // Complément à 1 de la somme des complément à 1 sur 16 bits
     // ********************************************************
     while(taille>1)
         {
         if (liberation==TRUE)
             liberation_du_jeton(); // Rend la main à la fenêtre principale
         checksum=checksum+*data++;
         taille=taille-sizeof(unsigned short);
         }
 
     if(taille)
         checksum=checksum+*(unsigned char*)data;
 
     checksum=(checksum>>16)+(checksum&0xffff);
     checksum=checksum+(checksum>>16);
 
     return (unsigned short)(~checksum);
     }

Vous trouverez tous les détails du Checksum IP dans la RFC 1071

Tous les équipements de niveau 3, tel que les routeurs, devront recalculer le Checksum, car il décrémente le champs TTL. De plus, toutes les fonctions de niveau 3 à 7, tel que la NAT, le PAT, modifiant le contenu de l’entête IP ou des Data, devront recalculer le Checksum.

3.11 – Adresse IP source

Le champ IP source est codé sur 32 bits et représente l’adresse IP source ou de réponse. Il est codé sur 4 octets qui forme l’adresse A.B.C.D.

3.12 – Adresse IP destination

Le champ IP destination est codé sur 32 bits et représente l’adresse IP destination. Il est codé sur 4 octets qui forme l’adresse A.B.C.D.

3.13 – Options

Le champ Options est codé entre 0 et 40 octets. Il n’est pas obligatoire, mais permet le « Tuning de l’entête IP ». Afin de bien gérer les Options, cela doit commencer par un octets de renseignement. Voici le détail de cette octet :

entete-ip entete ip champ options

3.13.1 – Copie

Le champ Copie est codé sur 1 bit et indique comment les options doivent être traitées lors de la fragmentation. Cela signifie que lorsqu’il est positionné à 1, il faut recopier les options dans chaque paquet fragmenté.

3.13.2 – Classe

Le champ Classe est codé sur 2 bits et indique les différentes catégorie d’options existantes. Voici la liste des différentes classe possible :

  • 0 – 00 – Supervision de réseau
  • 1 – 01 – Non utilisé
  • 2 – 10 – Debug et mesures
  • 3 – 11 – Non utilisé

3.13.3 – Numéro

Le champ Numéro est codé sur 5 bits et indique les différentes options existantes. Voici la liste des différents numéros possibles par Classe :

Classe 0,

  • 0 – 00000 – Fin de liste d’option. Utilisé si les options ne se terminent pas à la fin de l’entête (bourrage).
  • 1 – 00001 – Pas d’opération. Utilisé pour aligner les octets dans une liste d’options. 
  • 2 – 00010 – Restriction de sécurité et de gestion. Destiné aux applications militaires. 
  • 3 – 00011 – Routage lâche défini par la source. 
  • 7 – 00111 – Enregistrement de route. 
  • 8 – 01000 – Identificateur de connexion. 
  • 9 – 01001 – Routage strict défini par la source.

Classe 2,

  • 4 – 00100 – Horodatage dans l’Internet.

3.14 – Bourrage

Le champ Bourrage est de taille variable comprise entre 0 et 7 bits. Il permet de combler le champ option afin d’obtenir une entête IP multiple de 32 bits. La valeur des bits de bourrage est 0.

4 – Les vidéos

  • 4.1 - What is IPv4 exhaustion ? Vidéo en Anglais

    Cette video en anglais vous présente qu'est ce que l'épuissement des adresses IPv4. Unfortunately we are running out of IP version 4 (IPv4) addresses. There are a variety of reasons for this, and a variety of solutions that help address parts of the problem. But the real solution is a slow migration toward IP version 6 (IPv6) which provides a lot more addresses.

    What is IPv4 exhaustion ?

  • 4.2 - UDP, TCP, IP and Ethernet Header Vidéo en Anglais

    Video en anglais présentant en détail l'ensemble des champs des entêtes UDP, TCP, IP et Ethernet.

    UDP, TCP, IP and Ethernet Header

  • 4.3 - IP Header Vidéo en Anglais

    Video en anglais présentant en détail l'ensemble des champs de l'entête IP.

    IP Header

  • 4.4 - Détection d'erreur et retransmission Vidéo en Français

    Cette vidéo présente les différentes méthodes de contrôle d'erreur et de retransmission dans le monde Ethernet et IP.

    Détection d'erreur et retransmission

  • 4.5 - La fragmentation dans les réseaux IP Vidéo en Français

    Cette vidéo présente une cours sur la fragmentation dans les réseaux IP. Pour cela, vous découvrirait l'ensemble des champs de l'entête IP pour y identifier le DF en relation avec le MTU.

    La fragmentation dans les réseaux IP

  • 4.6 - L'entête IP, théorie et analyse de trame Vidéo en Français

    Cette vidéo présente l'entête IPv4 avec l'ensemble de ses champs associés. De plus, vous pourrez visionner des captures de trames montrant clairement l'entête IP et ses champs.

    L'entête IP, théorie et analyse de trame

5 – Suivi du document

Création et suivi de la documentation par _SebF

Modification de la documentation par _SebF

  • Complément de la définition du champ TTL en indiquant la décrémentation de 1 par seconde passé dans un routeur.

Modification de la documentation par _SebF

  • Indication des différentes classes et numéros du champ Options.

Modification de la documentation par _SebF

  • Correction sur le calcul du checksum qui ne s’effectue que sur l’entête elle même et ne prend pas en compte les couches supérieurs.

Modification de la documentation par Titouan

  • Correction de la valeur par défaut du flag reserved qui doit être égale à 0 (voir chapitre 3.6.1 et RFC 791 page 13).

6 – Discussion autour de l’entête IP

Vous pouvez poser toutes vos questions, faire part de vos remarques et partager vos expériences à propos de l’entête IP. Pour cela, n’hésitez pas à laisser un commentaire ci-dessous :

Commentaire et discussion

17 commentaires sur la page : “Entête IP”

  1. Bonjour,
    SVP, j’aimerais marquer trois types de paquets, audio, vidéo et partage d’écran.
    Connaîtriez-vous les bits spécifiques qui transportent ces informations ?

  2. Le protocole UDP prévoit un champ « checksum » dont le calcul porte sur le header et le payload.
    L’usage de ce checksum est dit « optionnel » pour UDP.
    Cette notion d’optionalité me laisse très perplexe.
    Comment une pile IP/UDP s’executant sur un host choisit-elle de tenir compte de ce champ ou pas ?
    Imaginons une instance source émettant un paquet UDP vers une instance destinataire.
    Admettons que cette instance source ait calculé le checksum et inséré le résultat du calcul dans le champ checksum.
    1- Comment sait-elle que l’instance destinataire va effectivement tenir compte de ce champ à reception ?
    2- Comment l’instance source a-t-elle décidé en premier lieu de mettre en oeuvre le checksum ? En vertu de quelle ordre / information / ?
    3- Comment l’instance destinataire sait-elle que l’instance source souhaite utiliser le checksum ? (Ici on peut imaginer que la présence d’une valeur différente de 0 soit un indicateur suffisant, mais au dela de l’imagination qu’en est-il dans la vraie vie des piles IP de nos OS ?)

    1. Lu Jellad,

      Le champ Option est là pour ça.

      Sinon, classiquement, pour ne pas changer la taille du datagramme, tu peux prendre le champ service si tu ne l’utilise pas.

      @+
      Sebastien FONTAINE

  3. Pourquoi dans un champ d’une trame ethernet nous commenç9ns par lire l’adresse mac de distinataire?
    Et dans un paquet IP on lit l’adresse IP source alors que logiquement sa devait être le contraire?

    1. Lu Elam,

      Non ce n’est pas possible. Tu dois confondre je pense.

      IHL indique la taille de l’entête IP et non pas du playload. Donc même dans le cas du dernier datargramme d’une fragmentation, ce datagramme possède forcement une entête IP.

      @+
      Sebastien FONTAINE

  4. Lu Oppza,

    IHL indique la longueur de l’entête IP. Elle est très souvent à 20, mais ce n’est pas une obligagtion, c’est pour cela qu’il faut le spécifier.

    En effet, il est possible d’ajouter des options (champs supplémentaire à l’entête IP) ce qui provoque donc une taille plus grande.

    Comme exemple d’option, on peux trouver les traces de routeurs transiter).

    @+
    Sebastien FONTAINE

    1. IHL est la longueur de l’entête IP sur la base d’une unité de taille de 32 bits.
      Elle est comprise entre 5 et 15 fois 32 bits (par défaut 5).

      Pour convertir cette longueur en octet, il faut multiplier par 32 ce qui donne la longueur en bits puis diviser par 8 pour obtenir la longueur en octets.

      Longueur 5: 5 * 32 / 8 = 20 octets
      Longueur 15: 15 * 32 / 8 = 60 octets

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *