inetdoc.net

Comme vous avez pû le comprendre dans l'introduction sur le protocole IP, un paquet IP contient différentes parties dans l'en-tête. Celui-ci est méticuleusement divisé en plusieurs parties, et chaque partie est aussi petite que possible pour faire ce travail, ceci pour limiter le temps système au minimum. Vous verrez la configuration exacte d'une en-tête IP dans l'image Section 2.3, « En-Têtes IP ».

Note

Comprenez que les explications des différents en-têtes sont très brèves et que nous ne parlerons que des bases de ceux-ci. Pour chaque type d'en-tête dont nous parlons, nous indiquerons aussi sa RFC correspondante que vous devriez lire pour une meilleure compréhension et des explications techniques du protocole en question. En note marginale, les RFC (Request For Comments), ont aujourd'hui une signification totalement différente dans la communauté Internet. Elles définissent et standardisent l'ensemble de l'Internet, par rapport à ce pourquoi elles ont été écrites à l'origine. Au départ, il ne s'agissait que de simples RFC dont le but était de poser des questions pour avoir l'avis des autres chercheurs.

Le protocole IP est décrit principalement dans RFC 791 - Internet Protocol. Cependant, cette RFC est aussi mise à jour par la RFC 1349 - Type of Service in the Internet Protocol Suite, rendue obsolète par RFC 2474 - Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers, mise à jour par RFC 3168 - The Addition of Explicit Congestion Notification (ECN) to IP et RFC 3260 - New Terminology and Clarifications for Diffserv.

Astuce

Comme vous pouvez le voir, tous ces standards peuvent être un peu difficiles à suivre. Un tuyau, pour trouver les différentes RFC utilisez les fonctions de recherche disponibles sur RFC-editor.org. Dans le cas du protocole IP, considérez que la RFC 791 est la RFC de base, toutes les autres sont simplement des mises à jour par rapport au standard. Nous parlerons de ceci plus en détail quand nous verrons les en-têtes spécifiques modifiés par ces nouvelles RFC. Une chose à retenir, quelquefois une RFC peut être obsolète (plus utilisée du tout). Normalement cela signifie que la RFC a été si rigoureusement mise à jour, qu'il est mieux de tout revoir. Elle peut aussi devenir obsolète pour d'autres raisons. Quand une RFC devient obsolète, un champ est ajouté à la RFC d'origine qui pointe vers la nouvelle.

Version - bits 0-3. C'est le numéro de version du protocole IP en binaire. IPv4 est nommé par 0100, tandis que IPv6 par 0110. Ce champ n'est généralement pas très utilisé pour le filtrage. La version décrite dans la RFC 791 est IPv4.

IHL (Longueur d'en-tête Internet) - bits 4-7. Ce champ nous indique la longueur de l'en-tête IP en 32 bits. Comme vous pouvez le voir, nous avons partagé l'en-tête (32 bits par ligne) dans l'image. Le champ Options est de longueur variable, ainsi nous ne pouvons jamais être absolument sûrs de la longueur totale de l'en-tête sans ce champ.

Type of Service, DSCP, ECN - bits 8-15. C'est une des zones les plus complexes de l'en-tête IP pour la simple raison qu'elle a été mise à jour 3 fois. Elle a toujours eu la même utilisation de base, mais l'implémentation a changé plusieurs fois. En premier le champ fut appelé Type de Service. Le Bit 0-2 du champ fut appelé champ Précédence. Le Bit était de délai normal/bas, le Bit 4 de débit normal/haut, le Bit 5 de fiabilité normale/haute et le Bit 6-7 réservé pour un usage futur. Ceci est toujours en usage sur de nombreux sites qui ont du matériel ancien, ce qui cause toujours certains problèmes pour l'Internet. Parmi d'autres choses, le Bit 6-7 est spécifié pour être placé à 0. Dans les mises à jour ECN (RFC, nous partons du principe que ces bits réservés sont désormais placés à la valeur 0. Mais nombre de pare-feux et routeurs ont été programmés pour vérifier si ces bits sont placés à 1, et si les paquets le sont, le paquet est supprimé. Aujourd'hui, c'est clairement une violation de la RFC, mais vous ne pouvez pas faire grand chose, excepté vous plaindre.

La seconde itération fut lorsque le champ a été modifié dans le champ DS comme spécifié dans la RFC 2474. DS pour Differentiated Services. Selon ce standard les bits 8-14 sont Differentiated Services Code Point (DSCP) et les deux bits restants (15-16) sont toujours inutilisés. Le champ DSCP est à peu près utilisé comme le champ ToS avant, pour marquer pour quel type de service ce paquet serait traité comme si le routeur en question ne faisait pas de différence entre eux. Un gros changement est que le matériel doit ignorer les bits inutilisés pour être pleinement conforme à la RFC 2474, ce qui signifie que nous sommes délivrés des disputes comme expliqué précédemment, aussi longtemps que les fabricants de matériel suivent cette RFC.

Le troisième, et pratiquement dernier, changement du champ ToS a été quand les deux bits inutilisés furent utilisés par ECN (Explicit Congestion Notification), comme défini dans la RFC 3168. ECN est utilisé pour permettre de savoir s'il existe une congestion des routeurs, avant il démarre la suppression des paquets, ainsi le noeud final pourra ralentir la transmission des données. Précédemment, la suppression de données était le seul moyen qu'avait un routeur pour annoncer qu'il était en surcharge, et les nœuds terminaux devaient faire un redémarrage lent pour chaque paquet supprimé, et ensuite accélérer de nouveau. Les deux bits sont appelés ECT (ECN Capable Transport) et CE (Congestion Experienced).

L'itération finale de l'ensemble est la RFC 3260 qui apporte quelques terminologies et clarifications nouvelles pour l'utilisation du système DiffServ. Elle n'améliore pas énormément de choses, sauf la terminologie. La RFC est également utilisée pour clarifier certains points qui ont été discutés entre développeurs.

Total Length - bits 16 - 31. Ce champ nous renseigne sur la taille des paquets en octets, incluant les en-têtes. La taille maximum est 65535 octets. La taille minimum d'un paquet est de 576 octets, sans prendre en compte si le paquet arrive en fragments ou non. Il est recommandé d'envoyer des paquets plus gros que cette limite seulement si il est garanti que l'hôte puisse les recevoir, selon la RFC 791. Cependant, actuellement la plupart des réseaux fonctionnent avec des tailles de paquets de 1500 octets. Ceci inclut la majorité des connexions ethernet et Internet.

Identification - bits 32 - 46. Ce champ est utilisé pour aider a réassembler les paquets fragmentés.

Fanions - bits 47 - 49. Ce champ contient des fanions mélangés appartenant à la fragmentation. Le premier bit est réservé, mais toujours inutilisé, et doit être placé à 0. Le second bit est placé à 0 si le paquet peut être fragmenté, et à 1 s'il ne peut pas être fragmenté. Le troisième et dernier bit peut être placé à 0 s'il était le dernier fragment, et à 1 s'il y a des fragments supplémentaires de ce même paquet.

Fragment Offset - bits 50 - 63. Le champ fragment décalé indique de quel datagramme le paquet dépend. Les fragments sont calculés sur 64 bits, et le premier fragment a un décalage zéro.

Durée de vie - bits 64 - 72. Le champ TTL (Time To Live) nous indique le durée de vie d'un paquet, ou combien de "sauts" (hops) il peut réaliser sur l'Internet. Chaque processus qui touche le paquet doit supprimer un point du champ TTL, et si le TTL atteint zéro, le paquet doit être détruit ou écarté. C'est un usage de base fonctionnant comme une sécurité car si le paquet n'est pas supprimé/écarté il peut se transformer en boucle incontrôlable entre un ou plusieurs hôtes. Pour la destruction l'hôte renverra un message ICMP "Destination Unreachable" à l'expéditeur.

Protocole - bits 73 - 80. Dans ce champ le protocole du niveau de la couche suivante est indiqué. Par exemple, ce peut être TCP, UDP ou ICMP parmi d'autres. Tous ces nombres sont définis par la Internet Assigned Numbers Authority (IANA). Ces nombres peuvent être retrouvés sur le site Internet Assigned Numbers Authority.

Somme de contrôle d'en-tête - bits 81 - 96. C'est un contrôle de l'en-tête IP du paquet. Ce champ est recalculé au niveau de chaque hôte qui modifie l'en-tête, ce qui signifie à peu près chaque hôte que le paquet traverse, la modification se faisant le plus souvent au niveau du champ TTL.

Adresse de l'expéditeur - bits 97 - 128. C'est le champ adresse de la source. Elle est généralement écrite sur 4 octets, traduite du binaire en nombres décimaux avec des points entre eux. Par exemple, 127.0.0.1. Le champ permet au destinataire de connaître l'adresse d'expédition du paquet.

Adresse de destination - bits 129 - 160. Le champ adresse contient l'adresse de destination, et surprise, il est formaté de la même façon que l'adresse de l'expéditeur.

Options - bits 161 - 192 <> 478. Le champ options n'est pas optionnel, comme il pourrait le sembler. C'est un des champs les plus complexes dans les en-têtes IP. Le champ options contient divers réglages optionnels à placer dans l'en-tête, comme minuterie Internet, SACK ou enregistrement de route. Ces options sont toutes optionnelles, le champ options peut avoir des longueurs différentes, et donc l'en-tête IP complet. Cependant, nous calculons toujours l'en-tête IP sur 32 bits, nous devons toujours clore l'en-tête sur un même nombre, qui est un multiple de 32. Le champ peut contenir zéro ou plusieurs options.

Le champ options démarre avec un champ de 8 bits qui nous permet de savoir quelles options ont été utilisées dans le paquet. Les options sont toutes listées dans la table Tableau D.1, « TCP Options », dans l'annexe Annexe D, Options TCP. Pour plus d'information sur les différentes options, lisez les RFC correspondantes. Pour une liste des options IP mises à jour, voir Internet Assigned Numbers Authority.

Remplissage - bits variables. C'est un champ de remplissage utilisé pour la fin de l'en-tête à la frontière des 32 bits. Le champ doit toujours être une ligne de zéros jusqu'à la fin.