Vous êtes sur la page 1sur 38

TP 4, Annexe et Corrigé

Réseaux 1ère Année 2005-2006

IUT Informatique Aix-en-Provence © Cyril Pain-Barre

Sommaire
I. Mise en place de l'arborescence ...................................................................................................... 1
II. Analyse de trames ........................................................................................................................... 1
II.1. Première trame capturée........................................................................................................... 2
II.2. Deuxième trame capturée ......................................................................................................... 3
II.3. Troisième trame capturée ......................................................................................................... 5
II.4. Quatrième trame capturée ........................................................................................................ 7
III. Encapsulation de messages et production de trames. ................................................................. 10
III.1. Première trame à produire ..................................................................................................... 10
III.2. Deuxième trame à produire.................................................................................................... 11
III.3. Troisième trame à produire .................................................................................................... 13
IV. Fragmentation et réassemblage de datagrammes IP .................................................................. 16
IV.1. Technique de fragmentation .................................................................................................. 16
IV.2. Technique de réassemblage.................................................................................................. 19
V. Annexe........................................................................................................................................... 22
V.1. Format des messages ............................................................................................................ 22
V.1.A. Trame Ethernet ................................................................................................................ 23
V.1.B. Datagramme ARP............................................................................................................ 24
V.1.C. Datagramme RARP ......................................................................................................... 26
V.1.D. Datagramme IP................................................................................................................ 27
V.1.E. Datagramme UDP............................................................................................................ 31
V.1.F. Segment TCP................................................................................................................... 33
V.2. Quelques ports réservés de UDP et de TCP.......................................................................... 37
V.3. Extrait de la table des caractères ASCII ................................................................................. 38

I. Mise en place de l'arborescence


Il n'y a pas à programmer au cours de ce TP mais vous pouvez créer un répertoire tp4 dans
tpres pour y stocker les fichiers contenant les réponses aux exercices.

II. Analyse de trames


Dans ces exercices, il s'agit d'analyser des trames et d'effectuer tous les démultiplexages réalisés
par différentes couches, à commencer par celui de la couche Liaison d'Ethernet. On dispose pour
chaque exercice de la "capture" d'une trame Ethernet, exprimée par une suite d'octets écrits en
hexadécimal (2 digits hexadécimaux par octet).
Les trames peuvent véhiculer des messages pour le compte de différents protocoles (ARP,
RARP, IP, XNS, IPX,...) identifiés par une valeur différente du champ EtherType (ou Type). Il
s'agira notamment de déterminer le protocole impliqué et d'expliquer l'objet du message envoyé.
Certains protocoles comme IP, IPX ou XNS, peuvent transporter des messages pour le compte
d'autres protocoles comme UDP ou TCP qui eux-même peuvent transporter des messages pour le
compte d'applications.

IUT Informatique Aix-en-Provence 1ère Année © Cyril Pain-Barre


TP 4, Annexe et Corrigé Réseaux 2005-2006 Page 2/38

Les applications engagées dans la discussion observée sont parfois identifiables si un port source
ou destination correspond à un port d'un service bien connu, ce qui permet de déterminer le client,
le serveur et le protocole d'application utilisé (SMTP, TELNET, POP3, HTTP, etc.).
Il faudra donc extraire toutes les informations qu'il est possible d'extraire des trames, tous les
champs des messages échangés et de les exprimer selon leur représentation courante en
indiquant ce qu'ils permettent de déduire, expliquer l'objet des messages, vérifier les checksums si
présents, indiquer les applications impliquées s'il y a lieu, et le texte qu'elles échangent, etc. En cas
de discussion client/serveur, préciser le client et le serveur. De plus, il se peut que certains
messages échangés soient incohérents, ce qu'il faut indiquer le cas échéant.
Afin d'éviter le calcul fastidieux des checksums, on peut utiliser l'utilitaire checksum disponible
dans le répertoire ~cpb/public qui demande les octets (en hexadécimal) faisant l'objet du calcul
et qui écrit le checksum calculé. Les espaces sont ignorés. Attention, il faut que le nombre d'octets
soit pair pour réaliser le calcul. Compléter si besoin par un dernier octet à 0.
Les différents formats des messages échangés par les protocoles Ethernet, ARP, RARP, IP, UDP
et TCP sont disponibles dans le document : Annexe du TP4, de même qu'un extrait des ports
réservés pour les services bien connus et un extrait de la table ASCII (pour extraire le texte échangé
par des applications de haut niveau).

! Ni le préambule ni le CRC des trames Ethernet ne figurent dans les captures :

! le premier octet appartient à l'adresse Ethernet de destination ;


! le dernier appartient aux données de la trame.

II.1. Première trame capturée


La première trame capturée est la suivante, où les octets sont groupés par deux (2 digits
hexadécimaux par octet) :
ffff ffff ffff 09ab 14d8 0548 0806 0001
0800 0604 0001 09ab 14d8 0548 7d05 300a
0000 0000 0000 7d12 6e03

Les retours à la ligne ne sont pas significatifs et servent juste à la lisibilité.


Analyser cette trame comme indiqué en introduction. Est-ce que les messages échangés sont
corrects ? Sinon, expliquer pourquoi.

Corrigé :

On commence par extraire les champs de la trame Ethernet, cela donne :

Adresse Ethernet Destination : ff:ff:ff:ff:ff:ff (diffusion Ethernet)


Adresse Ethernet Source : 09:ab:14:d8:05:48
EtherType : 0x0806 (ARP)

IUT Informatique Aix-en-Provence 1ère Année © Cyril Pain-Barre


TP 4, Annexe et Corrigé Réseaux 2005-2006 Page 3/38

Données : 0001 0800 0604 0001 09ab 14d8 0548


7d05 300a 0000 0000 0000 7d12 6e03

! Le champ EtherType indique que les données forment un datagramme ARP.

! La trame a été émise en diffusion. Toutes les machines du réseau vont la recevoir et la traiter.

On extrait les champs du datagramme ARP à partir des données Ethernet :

Type de réseau : 1 donc Ethernet


Protocole : 0x0800 donc IP
L. @phy : 6 octets pour adresses Ethernet
L. @pro : 4 octets pour adresses IP
Opération : 1 donc requête ARP
Adresse physique source : 09:ab:14:d8:05:48
Adresse proto source : 125.5.48.10
Adresse physique destination : 00:00:00:00:00:00 (inconnue)
Adresse proto destination : 125.18.110.3

! Il s'agit donc d'une requête ARP émise par la machine d'adresse IP 125.5.48.10,
demandant l'adresse physique Ethernet de la machine 125.18.110.3.

! Elle est correcte car tous les champs du datagramme ARP sont cohérents, il est bien
véhiculé par une trame émise en diffusion à partir de la carte qui correspond à l'adresse
physique source du datagramme.

II.2. Deuxième trame capturée


La deuxième trame capturée est la suivante :
086c d7b4 198a 04a8 5b13 422f 8035 0001
0800 0604 0004 04a8 5b13 422f c697 05d2
096c d7b4 198a c697 0516

Est-ce que les messages échangés sont corrects ? Sinon, expliquer pourquoi.

IUT Informatique Aix-en-Provence 1ère Année © Cyril Pain-Barre


TP 4, Annexe et Corrigé Réseaux 2005-2006 Page 4/38

Corrigé :
Champs de la trame Ethernet :

Adresse Ethernet Destination : 08:6c:d7:b4:19:8a


Adresse Ethernet Source : 04:a8:5b:13:42:2f
EtherType : 0x8035 (RARP)
Données : 0001 0800 0604 0004 04a8 5b13 422f
c697 05d2 096c d7b4 198a c697 0516

! Le champ EtherType indique que les données forment un datagramme RARP. La trame
est émise en unicast et seule la machine d'adresse 08:6c:d7:b4:19:8a doit la traiter.

Datagramme RARP :

Type de réseau : 1 donc Ethernet


Protocole : 0x0800 donc IP
L. @phy : 6 octets pour adresses Ethernet
L. @pro : 4 octets pour adresses IP
Opération : 4 donc réponse RARP
Adresse physique source : 04:a8:5b:13:42:2f
Adresse proto source : 198.151.5.210
Adresse physique destination : 09:6c:d7:b4:19:8a
Adresse proto destination : 198.151.5.22

! Il s'agit donc d'une réponse RARP émise par la machine d'adresse IP 198.151.5.210,
indiquant à la machine qui possède la carte Ethernet d'adresse 09:6c:d7:b4:19:8a que
son adresse IP est 198.151.5.22.

! Il y a toutefois un problème car l'Adresse Ethernet Destination n'est pas la même


que dans le datagramme. Cette réponse ne pourra donc pas être reçue ou traitée. Soit la
destination de la trame est bonne mais la machine ne se reconnaîtra pas dans le
datagramme, soit la destination n'est pas bonne et la machine qui devait recevoir la
trame ne la recevra pas. Dans tous les cas, la machine qui avait émis la requête RARP
devra la réémettre.

IUT Informatique Aix-en-Provence 1ère Année © Cyril Pain-Barre


TP 4, Annexe et Corrigé Réseaux 2005-2006 Page 5/38

II.3. Troisième trame capturée


La troisième trame capturée est la suivante :

0800 2076 3ec8 0800 2075 197d 0800 4500


0036 98b2 4000 ff11 c1b4 8b7c 051d 8b7c
053a 000d ad09 0022 4394 4d6f 6e20 4170
7220 2032 2031 313a 3433 3a30 3220 3230
3031 0a0d

Est-ce que les messages échangés sont corrects ? Sinon, expliquer pourquoi.

Corrigé :

Champs de la trame Ethernet :

Adresse Ethernet Destination : 08:00:20:76:3e:c8


Adresse Ethernet Source : 08:00:20:75:19:7d
EtherType : 0x0800 (IP)
Données :
4500 0036 98b2 4000 ff11 c1b4 8b7c 051d 8b7c
053a 000d ad09 0022 4394 4d6f 6e20 4170 7220
2032 2031 313a 3433 3a30 3220 3230 3031 0a0d

! Le champ EtherType indique que les données de la trame correspondent à un datagramme IP.

! La trame est émise en unicast et seule la machine d'adresse 08:00:20:76:3e:c8 doit la


traiter.

Champs du datagramme IP :

Version : 0x4 soit 4


IHL : 0x5 soit 20 octets d'en-tête

! Il n’y a pas d’options.

Type of Service (TOS) : 0x00 soit 00000000 en binaire


donc Priorité : 000 (routine)
bit d : 0 donc pas de souhait de faible délai
bit t : 0 donc pas de souhait de gros débit
bit r : 0 donc pas de souhait pour privilégier la fiabilité

! il n'y a donc pas de traitement particulier à réaliser pour ce datagramme.

IUT Informatique Aix-en-Provence 1ère Année © Cyril Pain-Barre


TP 4, Annexe et Corrigé Réseaux 2005-2006 Page 6/38

Longueur Totale : 0x0036 soit 54 octets (il y a donc 54-20 octets de données)
Identification : 0x98b2 soit 39090
Bit Don't Fragment : 1 (le datagramme ne doit pas être fragmenté)
Bit More : 0 donc pas de fragment qui suit ce datagramme
Offset : 0 donc pas de fragment qui précède ce datagramme

! Ce datagramme n'est pas fragmenté .

Time To Live : 0xff soit 255


Proto : 0x11 soit 17 (UDP)
Checksum : 0xc1b4 (correct)
Adresse IP source : 0x8b7c051d soit 139.124.5.29
Adresse IP destination : 0x8b7c053a soit 139.124.5.58
Données :
000d ad09 0022 4394 4d6f 6e20
4170 7220 2032 2031 313a 3433
3a30 3220 3230 3031 0a0d

! Le champ Proto indique que les données contiennent un datagramme UDP. Puisque le
datagramme n'est pas fragmenté et le Checksum est correct, les données sont communiquées à
UDP de la machine 139.124.5.58.

Champs du datagramme UDP :

Port source : 0x000d soit 13 (serveur daytime)


Port destination : 0xad09 soit 44297
Longueur : 0x0022 soit 34 octets (il y a 34-8 octets de données).
Checksum : 0x4394 (correct)
Données :
4d6f 6e20 4170 7220 2032
2031 313a 3433 3a30 3220
3230 3031 0a0d

! Le Checksum étant correct, UDP communique les données à l’application liée au port
44297. Le champ Port source nous indique qu'il s'agit d'un message envoyé par un serveur
daytime. Il s'agit donc de la date du jour codée en ASCII.

Message du serveur daytime :


Mon Apr 2 11:43:02 2001\n\r

IUT Informatique Aix-en-Provence 1ère Année © Cyril Pain-Barre


TP 4, Annexe et Corrigé Réseaux 2005-2006 Page 7/38

! La date du jour a été envoyée par le serveur daytime de la machine 139.124.5.29, à un


client situé sur la machine 139.124.5.58. Le protocole de transport est UDP. Le serveur a été
préalablement contacté par le client qui lui a envoyé un message quelconque (même vide)
transporté par un datagramme UDP. Cette trame contient la réaction (réponse) du serveur à la
réception du message.

II.4. Quatrième trame capturée


La quatrième trame capturée est la suivante :
0800 2112 8ef6 0900 1071 d85a 0800 4500
0053 d3e0 4000 f006 2109 8b5e 41ac a56f
2341 0017 a65a 6bd9 61ef d3fe efa0 5018
2442 a876 0000 4c61 7374 206c 6f67 696e
3a20 4d6f 6e20 4170 7220 2032 2031 313a
3037 3a30 3320 6672 6f6d 2073 7276 310d
0a

Est-ce que les messages échangés sont corrects ? Sinon, expliquer pourquoi.

Corrigé :

Champs de la trame Ethernet :

Adresse Ethernet Destination : 08:00:21:12:8e:f6


Adresse Ethernet Source : 09:00:10:71:d8:5a
EtherType : 0x0800 (IP)
Données :
4500 0053 d3e0 4000 f006 2109 8b5e 41ac
a56f 2341 0017 a65a 6bd9 61ef d3fe efa0
5018 2442 a876 0000 4c61 7374 206c 6f67
696e 3a20 4d6f 6e20 4170 7220 2032 2031
313a 3037 3a30 3320 6672 6f6d 2073 7276
310d 0a

! Le champ EtherType indique que les données de la trame correspondent à un datagramme


IP. La trame est émise en unicast à destination de 08:00:21:12:8e:f6.

IUT Informatique Aix-en-Provence 1ère Année © Cyril Pain-Barre


TP 4, Annexe et Corrigé Réseaux 2005-2006 Page 8/38

Champs du datagramme IP :

Version : 0x4 soit 4


IHL : 0x5 soit 20 octets d'en-tête

! Il n’y a pas d’options.

Type of Service (TOS) : 0x00 soit 00000000 en binaire


donc Priorité : 000 (routine)
bit d : 0 donc pas de souhait de faible délai
bit t : 0 donc pas de souhait de gros débit
bit r : 0 donc pas de souhait pour privilégier la fiabilité

! il n'y a donc pas de traitement particulier à réaliser pour ce datagramme.

Longueur Totale : 0x0053 soit 83 octets (il y a donc 83-20 octets de données)
Identification : 0xd3e0 soit 54240
Bit Don't Fragment : 1 (le datagramme ne doit pas être fragmenté)
Bit More : 0 donc pas de fragment qui suit ce datagramme
Offset : 0 donc pas de fragment qui précède ce datagramme

! Ce datagramme n'est pas fragmenté .

Time To Live : 0xf0 soit 240


Proto : 0x06 soit 6 (TCP)
Checksum : 0x2109 (correct)
Adresse IP source : 0x8b5e41ac soit 139.94.65.172
Adresse IP destination : 0xa56f2341 soit 165.111.35.65
Données :
0017 a65a 6bd9 61ef d3fe efa0
5018 2442 a876 0000 4c61 7374
206c 6f67 696e 3a20 4d6f 6e20
4170 7220 2032 2031 313a 3037
3a30 3320 6672 6f6d 2073 7276
310d 0a

! Le champ Proto indique que les données contiennent un segment TCP. Puisque le
datagramme n'est pas fragmenté et le Checksum est correct, les données sont communiquées à
TCP de la machine 165.111.35.65.

IUT Informatique Aix-en-Provence 1ère Année © Cyril Pain-Barre


TP 4, Annexe et Corrigé Réseaux 2005-2006 Page 9/38

Champs du segment TCP :

Port source : 0x0017 soit 23 (serveur Telnet)


Port destination : 0xa65a soit 42586
Num Séquence : 0x6bd961ef soit 1809408495
le premier octet de données du segment a pour le numéro de séquence 1809408495
Num Acquittement : 0xd3feefa0 soit 3556700064
si le bit ACK est à 1, c'est le numéro du prochain octet attendu par l'émetteur du segment.
LET : 0x5 soit 20 octets d'en-tête

! Il n’y a pas d’options.

La partie Réservé et les Flags sont représentés dans 0x018 d'où :


bit URG : 0 (pas de données urgentes)
bit ACK : 1 (le champ Acquittement doit être pris en compte)
bit PSH : 1 (délivrer les données à l'application destinataire dès que reçues et avant d'acquitter)
bit RST : 0 (pas de réinitialisation brutale de la connexion)
bit SYN : 0 (ce n'est pas un établissement de connexion)
bit FIN : 0 (pas de demande de fin de connexion)
Fenêtre : 0x2442 soit 9282

! l'émetteur annonce qu'il peut recevoir encore 9282 octets (pour l'instant).

Checksum : 0xa876

! La longueur du segment placée dans le pseudo en-tête est communiquée par IP


(Longueur Totale - En-Tête du datagramme IP). Le checksum est correct.

Pointeur urgent : 0x0000

Données :
4c61 7374 206c 6f67 696e 3a20
4d6f 6e20 4170 7220 2032 2031
313a 3037 3a30 3320 6672 6f6d
2073 7276 310d 0a

! Si le TCP récepteur attendait les octets à partir du numéro 1809408495 pour cette
connexion, il communiquera ces données à l'application liée au port TCP 42586, car le
Checksum est correct. Il devra aussi acquitter les données reçues. Ici, il y a 43 octets de
données : il faudra envoyer un segment avec le bit ACK positionné à 1 et le champ Num
Acquittement à 1809408495 + 43.

IUT Informatique Aix-en-Provence 1ère Année © Cyril Pain-Barre


TP 4, Annexe et Corrigé Réseaux 2005-2006 Page 10/38

! Le champ Port source nous indique qu'il s'agit d'un message envoyé par un serveur Telnet.
Ce message est constitué de caractères ASCII.

Message du serveur Telnet :

Last login: Mon Apr 2 11:07:03 from srv1\r\n

! Telnet permet d'ouvrir une session shell à distance. Ici, il s'agit du message envoyé suite
à la bonne authentification de l'utilisateur, indiquant la dernière fois qu'il s'en logé sur la
machine et depuis quelle machine s'il s'agissait d'une session à distance.

III. Encapsulation de messages et production de trames.


Dans ces exercices, il s'agit d'écrire la trame Ethernet qui est émise pour véhiculer le message
indiqué. Selon la nature de ce message, différents protocoles peuvent être utilisés pour l'encapsuler.
La trame véhiculera alors tous les messages des protocoles impliqués dans ces encapsulations, de la
même manière que les trames analysées précédemment. Il n'est pas demandé de faire figurer le
préambule ni le CRC des trames.

III.1. Première trame à produire


En supposant que la machine d'adresse IP 125.18.110.3 a pour adresse Ethernet
06:79:04:5e:8f:12, déterminer la trame véhiculant la réponse à la requête de l'exercice II.1
(la première trame analysée).

Corrigé :
Il s'agit donc de la réponse ARP émise par la machine d'adresse IP 125.18.110.3 pour indiquer
que l'adresse de sa carte Ethernet associée à 125.18.110.3 est 06:79:04:5e:8f:12. Cette
réponse est envoyée à la carte 09:ab:14:d8:05:48 de la machine 125.5.48.10, qui avait posé
la question.
Pour fabriquer la trame, on commence par fabriquer le datagramme ARP :

Type de réseau : Ethernet (0x0001)


Protocole : IP (0x0800)
L. @phy : 6 (0x06)
L. @pro : 4 (0x04)
Opération : réponse ARP (0x0002)
Adresse physique source : 06:79:04:5e:8f:12
Adresse proto source : 125.18.110.3 (0x7d126e03)

IUT Informatique Aix-en-Provence 1ère Année © Cyril Pain-Barre


TP 4, Annexe et Corrigé Réseaux 2005-2006 Page 11/38

Adresse physique destination : 09:ab:14:d8:05:48


Adresse proto destination : 125.5.48.10 (0x7d05300a)

Le datagramme ARP est donc :


0001 0800 0604 0002
0679 045e 8f12
7d12 6e03
09ab 14d8 0548
7d05 300a

Les champs de la trame Ethernet véhiculant ce datagramme sont :

Adresse Ethernet Destination : 09:ab:14:d8:05:48


Adresse Ethernet Source : 06:79:04:5e:8f:12
EtherType : ARP (0x0806)
Données :
0001 0800 0604 0002 0679 045e 8f12
7d12 6e03 09ab 14d8 0548 7d05 300a

La trame elle-même est :


09ab 14d8 0548 0679 045e 8f12 0806 0001
0800 0604 0002 0679 045e 8f12 7d12 6e03
09ab 14d8 0548 7d05 300a

III.2. Deuxième trame à produire


Déterminer la trame émise par la machine d'adresse physique 08:6c:d7:b4:19:8a dont la
réponse est la trame de l'exercice II.2 où l'erreur portait sur le champ @physique destination du
datagramme.

IUT Informatique Aix-en-Provence 1ère Année © Cyril Pain-Barre


TP 4, Annexe et Corrigé Réseaux 2005-2006 Page 12/38

Corrigé :
Il s'agit de la requête RARP émise par la carte Ethernet d'adresse 08:6c:d7:b4:19:8a d'une
machine demandant son adresse IP. Cette requête est émise en diffusion car on ne sait pas à qui elle
s'adresse.
Datagramme RARP :

Type de réseau : Ethernet


Protocole : IP
L. @phy : 6
L. @pro : 4
Opération : requête RARP (0x0003)
Adresse physique source : 08:6c:d7:b4:19:8a
Adresse proto source : 0.0.0.0 (inconnue)
Adresse physique destination : 00:00:00:00:00:00 (inconnue)
Adresse proto destination : 255.255.255.255 (diffusion)

Le datagramme ARP est donc :


0001 0800 0604 0003
086c d7b4 198a
0000 0000
0000 0000 0000
ffff ffff

Trame Ethernet :

Adresse Ethernet Destination : ff:ff:ff:ff:ff:ff


Adresse Ethernet Source : 08:6c:d7:b4:19:8a
EtherType : RARP (0x8035)
Données :
0001 0800 0604 0003 086c d7b4 198a
0000 0000 0000 0000 0000 ffff ffff

La trame elle-même est :


ffff ffff ffff 086c d7b4 198a 8035 0001
0800 0604 0003 086c d7b4 198a 0000 0000
0000 0000 0000 ffff ffff

IUT Informatique Aix-en-Provence 1ère Année © Cyril Pain-Barre


TP 4, Annexe et Corrigé Réseaux 2005-2006 Page 13/38

III.3. Troisième trame à produire


Déterminer la trame émise pour qu'une application A transmette le message :
« Message TCP prioritaire »
à une application distante B sachant que :

• le protocole de transport utilisé par les applications est TCP :


o la connexion TCP a déjà été établie
o le port TCP utilisé par A est 60001
o le port TCP utilisé par B est 25005
o le numéro de séquence du premier octet prochainement transmis par A est 128543
o A vient de recevoir 25 octets de données provenant de B dont le premier portait le
numéro de séquence 654962, et TCP doit les acquitter
o la taille de la fenêtre du TCP de A est 4000
o au niveau TCP, il n'y a pas de désir particulier formulé par A pour envoyer ce message

• le protocole réseau utilisé par TCP est IP :


o l'adresse IP de A est 124.125.126.127
o l'adresse IP de B est 124.125.126.128
o le prochain datagramme qui sera émis par le IP de A portera l'identification 20937
o le datagramme devra avoir une priorité immédiate, son acheminement doit privilégier la
fiabilité, il ne doit pas être fragmenté et son temps de vie doit être limité à 10 secondes

• les stations se trouvent sur le même réseau physique Ethernet :


o l'adresse Ethernet de A est 08:00:20:f6:3e:d8
o l'adresse Ethernet de B est 08:00:20:f0:5c:a9
o le MTU du réseau est 1500

• tous les checksums doivent être calculés.

IUT Informatique Aix-en-Provence 1ère Année © Cyril Pain-Barre


TP 4, Annexe et Corrigé Réseaux 2005-2006 Page 14/38

Corrigé :
Pour fabriquer la trame, on commence par traduire le message en hexadécimal (codage ASCII),
puis fabriquer le segment TCP, puis le datagramme IP puis enfin la trame.

Codage ASCII du message en hexadécimal (23 cars) :


4d65 7373 6167 6520 5443
5020 7072 696f 7269 7461
6972 65

Segment TCP :

! Il faut penser à acquitter les données reçues en disant que l'on attend l'octet numéro
654962+25.

Port source : 60001 => 0xea61


Port destination : 25005 =>0x61ad
Num Séquence : 128543 => 0x0001f61f
Num Acquittement : 654987 => 0x0009fe8b
LET : 20 octets d'en-tête car pas d'option => 0x5
La partie Réservé et les flags sont représentés dans 0x010 car :
bit URG : 0 (pas de données urgentes)
bit ACK : 1 (le champ Num Acquittement doit être pris en compte)
bit PSH : 0 (pas nécessaire de remettre à l'application dès que reçu)
bit RST : 0 (pas de réinitialisation brutale de la connexion)
bit SYN : 0 (ce n'est pas un établissement de connexion)
bit FIN : 0 (pas de demande de fin de connexion)
Fenêtre : 4000 => 0x0fa0
Checksum : 0xae7a
Pointeur urgent : 0x0000
Données :
4d65 7373 6167 6520 5443
5020 7072 696f 7269 7461
6972 65

Le segment TCP est :

ea61 61ad 0001 f61f 0009


fe8b 5010 0fa0 ae7a 0000
4d65 7373 6167 6520 5443
5020 7072 696f 7269 7461
6972 65

IUT Informatique Aix-en-Provence 1ère Année © Cyril Pain-Barre


TP 4, Annexe et Corrigé Réseaux 2005-2006 Page 15/38

Datagramme IP :

Version : 4 => 0x4


IHL : 20 octets d'en-tête car pas d'option => 0x5
Type of Service (TOS) : 0x44 soit 01000100 en binaire car :
Priorité : 010 (immédiate)
bit d : 0 car pas de souhait de faible délai
bit t : 0 car pas de souhait de gros débit
bit r : 1 car il faut privilégier la fiabilité
Longueur Totale : 43 + 20 => 0x003f
Identification : 20937 => 0x51c9
Partie Flags + Déplacement : 0x4000 car
Bit Don't Fragment : 1 (le datagramme ne doit pas être fragmenté)
Bit More : 0 car pas de fragment qui suit ce datagramme
Offset : 0 car pas de fragment qui précède ce datagramme
Time To Live : 10 => 0x0a
Proto : TCP => 0x06
Checksum : 0x28b2
Adresse IP source : 124.125.126.127 => 0x7c7d7e7f
Adresse IP destination : 124.125.126.128 => 0x7c7d7e80
Données :
ea61 61ad 0001 f61f 0009
fe8b 5010 0fa0 ae7a 0000
4d65 7373 6167 6520 5443
5020 7072 696f 7269 7461
6972 65

Le datagramme IP est :

4544 003f 51c9 4000 0a06


28b2 7c7d 7e7f 7c7d 7e80
ea61 61ad 0001 f61f 0009
fe8b 5010 0fa0 ae7a 0000
4d65 7373 6167 6520 5443
5020 7072 696f 7269 7461
6972 65

Trame Ethernet :

Adresse Ethernet Destination : 08:00:20:f0:5c:a9


Adresse Ethernet Source : 08:00:20:f6:3e:d8
EtherType : IP => 0x0800
Données :
4544 003f 51c9 4000 0a06
28b2 7c7d 7e7f 7c7d 7e80
ea61 61ad 0001 f61f 0009
fe8b 5010 0fa0 ae7a 0000
4d65 7373 6167 6520 5443
5020 7072 696f 7269 7461
6972 65

IUT Informatique Aix-en-Provence 1ère Année © Cyril Pain-Barre


TP 4, Annexe et Corrigé Réseaux 2005-2006 Page 16/38

La trame émise est :

0800 20f0 5ca9 0800 20f6


3ed8 0800 4544 003f 51c9
4000 0a06 28b2 7c7d 7e7f
7c7d 7e80 ea61 61ad 0001
f61f 0009 fe8b 5010 0fa0
ae7a 0000 4d65 7373 6167
6520 5443 5020 7072 696f
7269 7461 6972 65

IV. Fragmentation et réassemblage de datagrammes IP


La taille du champ données transporté par une trame est généralement limitée. Cette limite
s'appelle le Maximum Transfer Unit (MTU). Il peut être très différent selon les réseaux (1 500
octets pour Ethernet, 4 470 octets pour FDDI, ...). IP, s'appuyant sur n'importe quel type de réseau,
doit s'adapter à leur MTU. Lorsqu'il doit émettre un datagramme sur un réseau dont le MTU est
inférieur à la taille du datagramme, il doit fragmenter le datagramme.
Cette adaptation est nécessaire pour les routeurs qui acheminent des datagrammes à travers des
réseaux divers, mais aussi pour les hôtes qui sont à l'origine d'un datagramme. En effet, lorsque la
couche transport confie des données à IP, celui-ci fabrique d'abord un datagramme qui encapsule
ces données. Ensuite, selon le MTU du réseau que doit emprunter le datagramme (il n'y
généralement qu'un seul réseau possible pour un hôte), IP le fragmente.
La technique de fragmentation est relativement simple : il s'agit de fabriquer autant de
datagrammes IP qu'il est nécessaire pour transporter la totalité des données contenues dans le
datagramme à fragmenter. Les datagrammes fabriqués sont appelés les fragments du datagramme
d'origine. Chaque fragment contient une partie des données du datagramme d'origine. Les fragments
ont exactement le même format que les datagrammes IP (ce sont des datagrammes). Le bit More et
le champ Déplacement permettent de distinguer un fragment d'un datagramme.
Les fragments sont acheminés indépendamment les uns des autres à travers l'internet. Il peuvent
suivre des chemins différents et peuvent être à leur tour fragmentés. C'est la station
destinataire du datagramme d'origine (et des fragments) qui doit réassembler les fragments
pour reconstituer le datagramme d'origine avant d'en communiquer les données au protocole
destinataire.

IV.1. Technique de fragmentation


La plupart des champs du datagramme d'origine sont copiés dans l'en-tête des fragments. Il s'agit
des champs :

• VER;

• TOS;

• Identification;

• bit Don't Fragment, qui doit être à 0 sinon on ne peut fragmenter.

IUT Informatique Aix-en-Provence 1ère Année © Cyril Pain-Barre


TP 4, Annexe et Corrigé Réseaux 2005-2006 Page 17/38

• TTL;

• Protocole;

• Adresse IP Source;

• Adresse IP Destination.
Certaines options sont copiées dans tous les fragments (ex: option routage à la source), d'autres
ne le sont que dans le premier fragment (ex: enregistrement de route). De ce fait, la taille de l'en-
tête des fragments (et donc le champ HLEN) peut varier d'un fragment à l'autre. En l'absence
d'options dans le datagramme d'origine, tous les fragments possèdent 20 octets d'en-tête.
La taille des données contenues dans chaque fragment ne peut excéder le MTU moins la taille de
l'en-tête du fragment. En outre, elle doit être multiple de 8 (à cause du champ Déplacement), sauf
pour le dernier fragment. IP choisira le plus grand multiple de 8, inférieur à MTU moins l'en-tête.
Ainsi le nombre de fragments créés dépend du MTU, de la taille des données du datagramme
d'origine et de la taille des en-têtes des fragments. Mais il suffit de créer les fragments les uns après
les autres : le premier contenant le plus grand "morceau" possible des données à partir du début, le
second contenant le plus grand "morceau" qui suit, etc.
Les champs More et Déplacement dépendent du datagramme d'origine et des fragments que l'on
vient de créer :

• bit More :
o si le datagramme d'origine a son bit More à 1 (il s'agissait d'un fragment), alors il
est à 1 dans tous les fragments. En d'autres termes, si le datagramme d'origine
avait une "suite", alors tous les fragments qui en découlent aussi.
o sinon, il est à 1 dans tous les fragments sauf dans le dernier créé où il est à 0. En
d'autres termes, si le datagramme d'origine était le dernier fragment d'un
datagramme ou un datagramme complet, alors seul son dernier fragment n'a pas
de suite.

• champ Déplacement : il vaut la somme entre le champ Déplacement du datagramme


d'origine et la position divisée par 8 du premier octet de données du fragment par
rapport au début des données du datagramme d'origine. Encore une fois, il suffit de
faire évoluer Déplacement au fur et à mesure de la création des fragments, en se basant
sur le champ Déplacement et la taille des données du fragment précédent. Le premier
fragment ayant le même déplacement que le datagramme d'origine.
Les champs suivants sont aussi recalculés pour chaque fragment :

• HLEN : dépend des options;

• Longueur Totale : taille en-tête + taille des données du fragment;

• Checksum.

IUT Informatique Aix-en-Provence 1ère Année © Cyril Pain-Barre


TP 4, Annexe et Corrigé Réseaux 2005-2006 Page 18/38

Exercice :
Soit un hôte dont le logiciel IP doit envoyer un datagramme sans option contenant 5 000 octets de
données à travers un réseau de MTU 1 800 :
1. Indiquer les champs suivants du datagramme d'origine :
a. HLEN,
b. Longueur Totale,
c. bit More
d. Déplacement.
2. Fragmenter le datagramme et indiquer ces mêmes champs pour tous les fragments obtenus.
3. Le premier fragment et le troisième sont arrivés à un routeur qui doit les réexpédier par un
réseau de MTU 1 000. Indiquer les champs précédents pour les fragments fabriqués par ce
routeur.

Corrigé :
Les réponses sont illustrées par la figure suivante. Au sommet, on trouve le datagramme d'origine
qui se trouve fragmenté en 3 fragments par l'hôte émetteur. Ces fragments suivent chacun une route
propre, éventuellement différente. Le premier et le dernier ont été reçus par un routeur (pas
orcément le même) qui les fragmente aussi :

IUT Informatique Aix-en-Provence 1ère Année © Cyril Pain-Barre


TP 4, Annexe et Corrigé Réseaux 2005-2006 Page 19/38

IV.2. Technique de réassemblage


Un hôte peut recevoir des fragments et des datagrammes complets provenant de plusieurs
sources. On reconnaît un datagramme non fragmenté quand les deux conditions suivantes sont
satisfaites :

• le bit More est 0;

• le champ Déplacement vaut 0.


Dans ce cas, les données du datagramme peuvent être remises au protocole indiqué dans le
champ Protocole.
Sinon, il s'agit d'un fragment et IP doit attendre que tous les fragments soient arrivés pour
reconstituer le datagramme d'origine et remettre les données. Le couple (Identification, Adresse IP
Source) permet de reconnaître les fragments issus du même datagramme. IP regroupe les fragments
qui possèdent le même couple, et tente de reconstruire le bloc de données du datagramme d'origine
en se basant sur le bit More, et les champs HLEN, Longueur Totale et Déplacement des fragments.
La reconstitution aura abouti lorsque le fragment avec Déplacement à 0, et celui avec le bit More à
0 ont été reçus, et qu'il n'y a pas de "trous" dans le bloc de données reconstitué.
Puisque des fragments peuvent être perdus, le TTL des fragments reçus est décrémenté de 1 à
chaque seconde passée sur l'hôte. Si l'un d'eux parvient à 0, tous les fragments possédant le même

IUT Informatique Aix-en-Provence 1ère Année © Cyril Pain-Barre


TP 4, Annexe et Corrigé Réseaux 2005-2006 Page 20/38

couple (Identification, Adresse IP Source) sont détruits, et un message ICMP est envoyé à
l'émetteur.

Exercice :
Une station a reçu les 11 datagrammes ci-dessous. Analyser ces datagrammes pour reconstituer si
possible le(s) bloc(s) de données du (des) datagramme(s) d'origine. Les datagrammes sont copiables
dans le répertoire ~cpb/public/tpres/tp4/datagrammes :

• datagramme n°1 (fichier recu_01.txt)

• datagramme n°2 (fichier recu_02.txt)

• datagramme n°3 (fichier recu_03.txt)

• datagramme n°4 (fichier recu_04.txt)

• datagramme n°5 (fichier recu_05.txt)

• datagramme n°6 (fichier recu_06.txt)

• datagramme n°7 (fichier recu_07.txt)

• datagramme n°8 (fichier recu_08.txt)

• datagramme n°9 (fichier recu_09.txt)

• datagramme n°10 (fichier recu_10.txt)

• datagramme n°11 (fichier recu_11.txt)

Remarque : un petit script appelé dataglue est disponible dans le répertoire ~cpb/public. Il met
bout à bout les données des datagrammes passés en arguments (dans l'ordre). En passant en
arguments tous les fragments ordonnés d'un même datagramme, on obtient ainsi le bloc de données
du datagramme d'origine ;-)

Corrigé :
Il faut regrouper les datagrammes qui possèdent le même couple (Adresse IP Source,
Identification). On obtient les 3 groupes suivants :

• groupe 1 : recu_01.txt, recu_05.txt et recu_08.txt

• groupe 2 : recu_02.txt, recu_04.txt et recu_09.txt

• groupe 3 : recu_03.txt, recu_06.txt, recu_07.txt, recu_10.txt et recu_11.txt


Ensuite, il faut ordonner les fragments de chaque groupe en fonction du champ Déplacement,
vérifier qu'il y a bien le premier (Déplacement à 0) et le dernier fragment (bit More à 0) et qu'il ne
manque aucun fragment en se basant sur le champ Déplacement et la taille des données contenues
dans les fragments :

IUT Informatique Aix-en-Provence 1ère Année © Cyril Pain-Barre


TP 4, Annexe et Corrigé Réseaux 2005-2006 Page 21/38

• groupe 1 : l'ordre est recu_01.txt, recu_05.txt puis recu_08.txt.


recu_01.txt est bien le premier fragment et recu_08.txt est le dernier. De plus, il n'y a
pas de trous car 34 = 272 / 8 et 68 = 34 + (272 / 8). Tous les fragments du
datagramme ont été reçus. On en reconstitue les données en collant les données des
fragments. Le bloc de données obtenu est visualisable en tapant (où dataglue est
dans ~cpb/public et les datagrammes sont dans
~cpb/public/tpres/tp4/datagrammes) :

Il faut lire « OK !! »...

• groupe 2 : l'ordre est recu_04.txt, recu_02.txt puis recu_09.txt.


recu_04.txt est bien le premier fragment et recu_09.txt est le dernier. Cependant, il
manque un ou plusieurs fragments car recu_02.txt à un Déplacement à 41 et une
longueur de données de 200, et 41 + (200 / 8) n'égale pas 82 qui est le Déplacement
annoncé par recu_09.txt. On ne peut donc reconstituer les données d'origine.
Si on visualise quand même les données avec dataglue, on voit apparaître
"INCOMPLET!"...

• groupe 3 : l'ordre est recu_07.txt, recu_03.txt, recu_06.txt, recu_10.txt puis recu_11.txt.


recu_07.txt est bien le premier fragment et recu_11.txt est le dernier. De plus, il n'y a
pas de trous car 39 = 312 / 8, 78 = 39 + (312 / 8), 156 = 78 + (624 / 8) et 234 = 156
+ (624 / 8). Tous les fragments du datagramme ont été reçus. On en reconstitue les
données en collant les données des fragments. Le bloc de données obtenu est
visualisable en tapant :

IUT Informatique Aix-en-Provence 1ère Année © Cyril Pain-Barre


TP 4, Annexe et Corrigé Réseaux 2005-2006 Page 22/38

Il faut lire « DAMNED, JE SUIS DECOUVERT »...


PS :
Je lance un appel à ceux qui auraient des images sous forme de texte pour
remplacer ces messages d'une inspiration phénoménale. Je serais ravi de les
recevoir à l'adresse cpb@iut.univ-aix.fr. Merci d'avance :-)

V. Annexe

V.1. Format des messages


Le format des messages diffère selon les protocoles, même si ils appartiennent à la même couche.
Les formats des messages Ethernet, ARP, RARP, IP, UDP et TCP sont présentés dans ce qui suit.
Des exemples de valeur des champs servant au multiplexage/démultiplexage sont donnés pour les
protocoles pratiquant cette technique. Ces valeurs sont internationalement reconnues et décrites
dans le RFC 1700.

! Toutes les valeurs des champs des en-têtes des protocoles décrits sont codées en format
réseau.

IUT Informatique Aix-en-Provence 1ère Année © Cyril Pain-Barre


TP 4, Annexe et Corrigé Réseaux 2005-2006 Page 23/38

V.1.A. Trame Ethernet

Les messages transmis par Ethernet sont appelés des trames puisque Ethernet inclut la couche
Liaison.

Format de la Trame Ethernet

Préambule : (8 octets)
Annonce le début de la trame et permet la synchronisation.
Il n'est pas présent dans les captures.
Adresse Destination : (6 octets)
Adresse physique de la carte Ethernet destinataire de la trame. La représentation courante
d'une adresse Ethernet est composée de ses 6 octets en hexadécimal séparés par des ':'.
Exemple : 08:00:07:5c:10:0a

La destination peut être une adresse de (multi-)diffusion. En particulier, l’adresse


ff:ff:ff:ff:ff:ff (diffusion ou broadcast) correspond à toutes les stations du réseau
physique Ethernet.
Adresse Source : (6 octets)
Adresse physique de la carte Ethernet émettrice de la trame.
EtherType : ou type de trame (2 octets)
Indique quel protocole est concerné par le message. La carte réalise un démultiplexage en
fournissant les données au protocole concerné. Sa représentation courante est en
hexadécimal, suivi du nom du protocole concerné.
Quelques types courants (en hexadécimal) :
• 0x0600 : Xerox Network Systems
• 0x0800 : IP (Internet Protocol)
• 0x0806 : ARP (Address Resolution Protocol)
• 0x8035 : RARP (Reverse ARP)
• 0x8137 et 0x8138 : Novell.

IUT Informatique Aix-en-Provence 1ère Année © Cyril Pain-Barre


TP 4, Annexe et Corrigé Réseaux 2005-2006 Page 24/38

Données : (46 à 1500 octets)


Les données véhiculées par la trame. Sur la station destinataire de la trame, ces octets seront
communiqués à l’entité (protocole) indiquée par le champ EtherType. Notons que la taille
minimale des données est 46 octets. Des octets à 0, dits de « bourrage », sont utilisés pour
compléter des données dont la taille est inférieure à 46 octets.
Ces octets de bourrage ne sont pas présents dans les captures de trame.
CRC : Cyclic Redundancy Code (4 octets)
Permet de s'assurer que la trame a été correctement transmise et que les données peuvent
donc être délivrées au protocole destinataire.
Il ne figure pas dans les captures.

V.1.B. Datagramme ARP

Les messages échangés par ARP (Address Resolution Protocol) sont appelés des datagrammes.

Format du Datagramme ARP

Type de réseau : (16 bits)


Indique le type de réseau physique utilisé. Doit valoir 1 pour Ethernet.
La représentation courante de ce champ est en décimal, suivi de l’identificateur du type de
réseau physique.
Protocole : (16 bits)
Indique le protocole pour lequel on veut l'adresse logique. Doit valoir 0x0800 pour IP.
La représentation courante de ce champ est en hexadécimal, suivi de l’identificateur du
protocole.

IUT Informatique Aix-en-Provence 1ère Année © Cyril Pain-Barre


TP 4, Annexe et Corrigé Réseaux 2005-2006 Page 25/38

L. @phy : Longueur de l'adresse physique (8 bits)


Indique le nombre d'octets de l'adresse physique de ce type de réseau. Pour Ethernet, les
adresses sont codées sur 6 octets.
Permet de connaître la taille de @physique source et @physique destination.
La représentation courante de ce champ est en décimal.
L. @pro : Longueur de l'adresse logique (8 bits)
Indique le nombre d'octets de l'adresse logique utilisée par le protocole indiqué dans le
champ Protocole. Pour IP, c'est 4.
Permet de connaître la taille de @proto source et @proto destination, qui est variable selon
le réseau logique. La représentation courante de ce champ est en décimal.
Opération : (16 bits)
Indique l'objet du message échangé. Vaut 1 pour une requête ARP; 2 pour une réponse ARP.
La représentation courante de ce champ est l'indication de la nature du message.
@physique source : (taille variable)
Contient l'adresse physique de l'émetteur. Sa représentation courante est celle des adresses
physiques du réseau indiqué dans le champ Type de réseau.
@proto source : (taille variable)
Contient l'adresse logique de l'émetteur si connue, ou 0 (pour requête RARP). Sa
représentation courante est celle des adresses logiques du protocole indiqué dans le champ
Protocole.
@physique destination : (taille variable)
Contient l'adresse physique du destinataire, ou 0 si inconnue. Sa représentation courante est
celle des adresses physiques du réseau indiqué dans le champ Type de réseau.
@proto destination : (taille variable)
Contient l'adresse logique du destinataire, ou 0 si inconnue. Sa représentation courante est
celle des adresses logiques du protocole indiqué dans le champ Protocole.

IUT Informatique Aix-en-Provence 1ère Année © Cyril Pain-Barre


TP 4, Annexe et Corrigé Réseaux 2005-2006 Page 26/38

V.1.C. Datagramme RARP

Les messages échangés par RARP (Reverse Address Resolution Protocol, ou Reverse ARP) sont
appelés des datagrammes.

Format du Datagramme RARP

L'interprétation de ces champs est la même que pour ARP. La différence se situe principalement
dans le code Opération :
Opération : (16 bits)
Indique l'objet du message échangé. Vaut 3 pour une requête RARP et 4 pour une réponse
RARP. La représentation courante de ce champ est l'indication de la nature du message.

IUT Informatique Aix-en-Provence 1ère Année © Cyril Pain-Barre


TP 4, Annexe et Corrigé Réseaux 2005-2006 Page 27/38

V.1.D. Datagramme IP

Les messages transmis par IP (Internet Protocol) sont appelés des datagrammes. Certains
datagrammes sont des fragments d’un datagramme qui a dû être fragmenté.

Format du Datagramme IP

VER : (4 bits)
Version du protocole IP qui doit interpréter ce datagramme. La version actuelle la plus
« déployée » est 4 (soit 0100 en binaire). Sa représentation courante est en décimal.
HLEN : (ou IHL) Internet Header Length (4 bits)
Cette valeur est à multiplier par 4 pour connaître le nombre d'octets constituant l'en-tête.
L'en-tête correspond au début du datagramme jusqu'au données. Permet notamment de
savoir si il y a des options et où commencent les données. Peut varier de 5 (soit 20 octets
d'entête) à 15 (60 octets d'entête). Cette variation s'explique par la présence ou non
d'options. Sa représentation courante est en décimal, où sa valeur est multipliée par 4. On
indique par la même occasion si le datagramme contient des options ou pas.

IUT Informatique Aix-en-Provence 1ère Année © Cyril Pain-Barre


TP 4, Annexe et Corrigé Réseaux 2005-2006 Page 28/38

TOS : Type Of Service (8 bits)


Indique la qualité du service demandé pour ce datagramme (ou le flot de datagrammes dans
lequel il s’inscrit) où les 8 bits sont décomposés comme suit (les deux derniers devant être à
0) :

• Priorité : (3 bits)
Indique la priorité voulue pour le datagramme. La priorité augmente avec la valeur de ce
champ. Les valeurs possibles sont les suivantes :
o 000 : Routine ;
o 001 : Priority ;
o 010 : Immediate ;
o 011 : Flash ;
o 100 : Flash Override ;
o 101 : Critic ;
o 110 : InterNetwork Control
o 111 : Network Control
Sa représentation courante est l'intitulé correspondant à sa valeur.
• Bit D(elay) : à 1, indique que l’acheminement du datagramme doit privilégier le délai (il
doit arriver le plus rapidement possible).
• Bit T(hroughput) : à 1, indique que le datagramme fait partie d'une communication ayant
besoin d'un gros débit
• Bit R(eliability) : à 1, indique qu'il faut privilégier la fiabilité : un effort particulier doit
être fait pour acheminer correctement ce datagramme
• Bits inutilisés : doivent être à 0.

La représentation courante de ces bits est l'indication des traitements souhaités pour le
datagramme.
Longueur Totale : (16 bits)
Donne la taille totale en octets du datagramme (ou du fragment). Ainsi, un datagramme ne
peut pas excéder 65535 octets (216-1). La norme impose à toute implémentation de pouvoir

IUT Informatique Aix-en-Provence 1ère Année © Cyril Pain-Barre


TP 4, Annexe et Corrigé Réseaux 2005-2006 Page 29/38

traiter des datagrammes d'au moins 576 octets. Si un datagramme devant traverser un réseau
est de taille supérieure à ce que le réseau peut transmettre (càd au Maximum Transfer Unit
ou MTU du réseau), il doit être fragmenté par le routeur ou la station l'injectant dans le
réseau. Fragmenter veut dire que le datagramme sera découpé en datagrammes plus petits
(des fragments) qui pourront être transmis. Ces fragments auront pour Longueur Totale la
taille des données qu'ils transportent plus la longueur de l'en-tête. Le datagramme d'origine
sera reconstitué par le destinataire.
La représentation courante de ce champ est en décimal.
Identification : (16 bits)
Numéro identifiant le datagramme de façon non ambiguë par rapport à sa source (identifiée
par l’adresse IP source). Permet de rassembler les fragments d’un même datagramme afin
de le reconstituer. Sa représentation courante est en hexadécimal.
Flags : Indicateurs de fragmentation (3 bits).
Ces indicateurs se composent des 3 bits suivants dont le premier est inutilisé et doit être à 0 :

• bit 0 : bit inutilisé et à 0.


• bit Don't Fragment : si positionné à 1, indique que ce datagramme ne doit pas être
fragmenté
• bit More : si positionné à 1, indique que le datagramme n'est qu'une partie
(fragment) du datagramme d'origine et que ce n’est pas le dernier fragment. Si à 0,
indique que le datagramme est le dernier fragment du datagramme d'origine. On
reconnaît un datagramme non fragmenté lorsque le bit More est à 0 et que le
Déplacement est aussi à 0.
La représentation courante de ces bits est l'indication si le datagramme peut être fragmenté,
si c'est un fragment, et si c'est le dernier fragment.
Offset : Déplacement (13 bits).
La valeur de ce champ est à multiplier par 8 pour connaître l'emplacement du premier octet
de données par rapport au datagramme d'origine. Le Déplacement est différent de 0
uniquement si le datagramme a été fragmenté.
La représentation courante de ce champ est en décimal. On indique par la même occasion si
le datagramme est un fragment et si c’est le premier fragment du datagramme d’origine.

IUT Informatique Aix-en-Provence 1ère Année © Cyril Pain-Barre


TP 4, Annexe et Corrigé Réseaux 2005-2006 Page 30/38

TTL : Time To Live (8 bits).


Valeur fixant la durée de vie en secondes du datagramme. Le but est d'éliminer un
datagramme qui ne serait pas arrivé à destination dans le délai imparti, ou d'éliminer les
fragments d'un datagramme lorsqu'il ne peut être reconstitué (fragment perdu ou trop
retardé). En pratique, tout routeur devant transmettre le datagramme va décrémenter sa
durée de vie d'au moins 1. Il en résulte que le TTL est une limite du nombre de routeurs
pouvant être traversés jusqu'à la destination.
Sa représentation courante est en décimal.
Proto : Protocole (8 bits).
Sert au démultiplexage car indique à quel protocole il faut remettre les données transportées
dans le datagramme.
Quelques protocoles reconnus par IP (en décimal) :
0 : IP
1 : ICMP
6 : TCP
17 : UDP

Sa représentation courante est en décimal, suivi du nom du protocole concerné.


Checksum : Contrôle de l'entête (16 bits).
Permet de contrôler l'intégrité de l'entête (mais pas des données). Voir le cours pour la
méthode de calcul. Si le checksum calculé par le destinataire est différent de celui figurant
dans le datagramme, celui-ci est détruit.
La représentation courante du Checksum est en hexadécimal.
Adresse IP Source : (32 bits)
Entier non signé identifiant l'adresse IP de l'émetteur du datagramme.
Sa représentation courante est la notation décimale pointée.
Adresse IP Destination : (32 bits)
Entier non signé identifiant l'adresse IP du destinataire du datagramme.
Options : (taille variable, pouvant être nulle).
Elles comprennent la découverte du MTU, l'enregistrement d'une route suivie par un
datagramme, le routage à la source, etc.
En cas de fragmentation, certaines options sont copiées dans tous les datagrammes (comme
le routage à la source), d'autres ne le sont que dans le premier (comme enregistrement de la
route).
Voir champ HLEN pour la présence d'options.
Bourrage : (Taille variable, pouvant être nulle).
N'est présent que pour compléter la taille des options jusqu'à un multiple de 4 octets.
Ceci parce que la taille de l'en-tête est HLEN × 4 octets.

IUT Informatique Aix-en-Provence 1ère Année © Cyril Pain-Barre


TP 4, Annexe et Corrigé Réseaux 2005-2006 Page 31/38

Données : (taille variable)


Les données véhiculées par le datagramme. Sur la station destinataire du datagramme, ces
octets seront communiqués à l’entité (protocole) indiquée par le champ Protocole si le
Checksum est confirmé. La taille maximale de ce champ est 65535 moins la longueur de
l’en-tête.

V.1.E. Datagramme UDP

Les messages transmis par UDP (User Datagram Protocol), via IP, sont appelés des
datagrammes.

Format du Datagramme UDP

Port UDP source : (16 bits)


Entier non signé servant à identifier l'application émettrice du datagramme.
Cette application correspond à un service (serveur) bien connu si le port est un port réservé.
Quelques ports réservé sont indiqués en fin de l'annexe.
La représentation courante de ce champ est en décimal, en précisant, s’il y a lieu, quel
serveur est impliqué dans la communication.

IUT Informatique Aix-en-Provence 1ère Année © Cyril Pain-Barre


TP 4, Annexe et Corrigé Réseaux 2005-2006 Page 32/38

Port UDP Destination : (16 bits)


Entier non signé servant à identifier l'application destinataire du datagramme. Cette
application correspond à un service (serveur) bien connu si le port est un port réservé.
Longueur : (16 bits)
Donne la taille totale en octets du datagramme.
La représentation courante de ce champ est en décimal.
Checksum : (16 bits)
Total de contrôle portant sur la totalité du datagramme plus le pseudo en-tête UDP,
permettant de vérifier la validité de l'ensemble du datagramme (données comprises). La
méthode de calcul est la même que celle du checksum IP. Celle-ci utilise des mots de 16 bits
: si les données comportent un nombre impair d'octets, il faut rajouter un octet fictif à 0 à la
fin des données pour calculer le checksum UDP.
La représentation courante du checksum est en hexadécimal.
Le pseudo en-tête utilisé par UDP est le suivant (informations provenant de IP) :

Données : (taille variable, peut être vide)


Données à transmettre à l'application (ou serveur) destinataire du datagramme.

IUT Informatique Aix-en-Provence 1ère Année © Cyril Pain-Barre


TP 4, Annexe et Corrigé Réseaux 2005-2006 Page 33/38

V.1.F. Segment TCP

Les messages transmis par TCP (Transmission Control Protocol), normalement via IP, sont
appelés des segments.

Format du Segment TCP

Port TCP source : (16 bits)


Entier non signé servant à identifier l'application émettrice du datagramme. Cette
application correspond à un service (serveur) bien connu si le port est un port réservé.
Quelques ports réservé sont indiqués en fin de l'annexe.
La représentation courante de ce champ est en décimal, en précisant, s’il y a lieu, quel
serveur est impliqué dans la communication.
Port TCP Destination : (16 bits)
Entier non signé servant à identifier l'application destinataire du datagramme. Cette
application correspond à un service (serveur) bien connu si le port est un port réservé.

IUT Informatique Aix-en-Provence 1ère Année © Cyril Pain-Barre


TP 4, Annexe et Corrigé Réseaux 2005-2006 Page 34/38

Numéro de séquence : (32 bits)


Numéro indiquant la place du 1er octet des données, dans le flot d'octets transmis par la
source depuis le début de la connexion. Le numéro de séquence est choisi aléatoirement à
l'établissement de la connexion puis croît avec les (nouveaux) octets transmis.
La représentation courante de ce champ est en décimal.
Numéro de l'Accusé de réception : (32 bits)
Ce champ permet d'acquitter la réception d'octets. N'est interprété que si le bit ACK est à 1.
Indique le numéro de séquence du prochain octet attendu, et ainsi que les octets portant un
numéro inférieur ont bien été reçus. La présence de ce champ dans un segment TCP
correspond à la technique du piggybacking qui permet d'accuser réception d'un segment tout
en envoyant des données.
La représentation courante de ce champ est en décimal.
LET : (ou Data Offset) Longueur de l'entête du segment TCP (4 bits).
La valeur de ce champ est à multiplier par 4 pour connaître le nombre d'octets constituant
l'en-tête. Ceci à cause de la présence d'éventuelles options (comme pour IP).
La représentation courante de ce champ est en décimal, où sa valeur a été multipliée par 4, et
on indique par la même occasion s’il y a des options.
Bits Réservés : ces 6 bits doivent être à 0.
Flags : (6 bits).
Indicateurs pour interprétation du segment et de ses champs. Ces indicateurs sont contenus
dans les 6 bits suivants :

• bit URG : si positionné à 1, indique que le segment comporte des données urgentes
dont le dernier octet est indiqué par le Pointeur Urgent. Si positionné à 0, le Pointeur
Urgent doit être ignoré.
• bit ACK : Si positionné à 1, indique que le champ Numéro de l'Accusé de réception
doit être interprété. Si à 0, le champ Numéro de l'Accusé de réception doit être
ignoré.
• bit PSH : si positionné à 1, indique que les données doivent être transmises sans
tarder et que le (TCP) récepteur ne doit pas envoyer d'acquittement de ce segment
tant que les données n'ont pas été délivrées à l'application destinataire.

IUT Informatique Aix-en-Provence 1ère Année © Cyril Pain-Barre


TP 4, Annexe et Corrigé Réseaux 2005-2006 Page 35/38

• bit RST : si positionné à 1, demande une terminaison brutale de la connexion, sans


acquittement.
• bit SYN : sert uniquement à l'établissement de connexion, où il est positionné à 1.
Permet de synchroniser les numéros de séquence des 2 parties. Ensuite, il doit être à
0.
• bit FIN : si positionné à 1, indique que l'application côté émetteur n'a plus de
données à émettre et veut terminer la connexion. La connexion sera effectivement
terminée lorsque les 2 côtés auront transmis un segment avec ce bit à 1 et que ces
segments seront acquittés. Ainsi, même si une application n'a plus de données à
émettre, elle doit s'attendre à recevoir encore des données.
La représentation courante de ces bits est l'indication des champs à interpréter et le rôle du
segment.
Fenêtre : (16 bits)
Indique le nombre d'octets de données pouvant encore être reçus (pour l'instant) par
l'émetteur du segment. Si 0, le récepteur du segment ne doit plus envoyer de données,
jusqu'à ce qu'une "réouverture" de la fenêtre ait lieu (envoi d'un segment avec fenêtre non
nulle).
La représentation courante de ce champ est en décimal.
Checksum : (16 bits)
Total de contrôle portant sur la totalité du segment plus le pseudo en-tête TCP,
permettant de vérifier la validité de l'ensemble du segment (données comprises). La méthode
de calcul est la même que celle du checksum IP et UDP. Celle-ci utilise des mots de 16 bits :
si les données comportent un nombre impair d'octets, il faut rajouter un octet fictif à 0 à la
fin des données pour calculer le checksum TCP.
La représentation courante du checksum est en hexadécimal.
Le pseudo en-tête utilisé par TCP est le suivant (informations provenant de IP) :

IUT Informatique Aix-en-Provence 1ère Année © Cyril Pain-Barre


TP 4, Annexe et Corrigé Réseaux 2005-2006 Page 36/38

Pointeur Urgent : (16 bits)


Si le bit URG est positionné à 1, la valeur de ce champ indique la position du dernier octet
des données urgentes dans les données. Les données urgentes se trouvent toujours au début
des données du segment. Par exemple, si le bit URG est à 1 et que le Pointeur urgent vaut 3,
alors les données urgentes s'arrêtent au 3ème octet des données et les données normales
commencent au 4ème octet.
Options : (taille variable)
Leur présence est éventuelle et repérée par la longueur de l'entête. L'option véritablement
reconnue est celle permettant la négociation de la taille maximale des données des segments
échangés, appelée MSS (Maximum Segment Size) et codée sur 4 octets. Voir champ LET
pour la présence d'options.
Bourrage : (taille variable, peut être nulle).
N'est présent que pour compléter la taille des options jusqu'à un multiple de 4 octets. Ceci
parce que la taille de l'en-tête est LET × 4 octets.
Données : (taille variable, peut être vide)
Données à transmettre à l'application (ou au serveur); les données urgentes étant au début.

IUT Informatique Aix-en-Provence 1ère Année © Cyril Pain-Barre


TP 4, Annexe et Corrigé Réseaux 2005-2006 Page 37/38

V.2. Quelques ports réservés de UDP et de TCP


Ces ports sont réservés pour les services bien connus. Si un datagramme UDP ou un segment
TCP comprennent un port indiqué dans cette table, c'est que l'application correspondante est
impliquée dans la communication. Ces ports sont indiqués dans le RFC 1700. Normalement, les
ports ne sont réservés que pour les serveurs sauf exceptions. Les clients n’utilisent généralement
pas de numéros de ports particuliers et laissent le soin aux protocoles de transport de leur en
attribuer un.

Numéro de port
Service
(décimal)

7 echo (renvoie ce qu'il reçoit)

13 daytime (donne la date du jour)

15 netstat (informations sur le réseau)

20 données FTP

21 contrôle FTP (File Transfer Protocol)

23 TELNET (terminal virtuel)

25 SMTP (Simple Mail Transfer Protocol)

53 DNS (Domain Name Service)

69 TFTP (Trivial File Transfer Protocol)

79 Finger (qui est connecté ?)

80 HTTP

110 POP3 (relève du courrier à distance)

IUT Informatique Aix-en-Provence 1ère Année © Cyril Pain-Barre


TP 4, Annexe et Corrigé Réseaux 2005-2006 Page 38/38

V.3. Extrait de la table des caractères ASCII


Cette table donne la correspondance entre certains caractères ASCII (American Strandard Code
for Information Interchange) et leur codage (hexadécimal et décimal). Elle est consultable sous
Linux en tapant : man ascii
Les caractères suivants ne figurent pas dans la table présentée ci-dessous :
• 0x0a : Line Feed (ou '\n'). Sur un terminal, fait déplacer le curseur sur la ligne suivante.

• 0x0d : Carriage Return (ou '\r'). En C et C++, il représente le retour à la ligne. Il est
parfois interprété comme un simple retour en début de ligne (Windows).
En réseau, les applications qui échangent des caractères ASCII normalisent souvent les retours à
la ligne par la séquence "\r\n", plus rarement par "\n\r" et encore plus rarement avec simplement
"\n".

Valeur Valeur Valeur Valeur


Caractère Caractère Caractère Caractère
Déc. Hex. Déc. Hex. Déc. Hex. Déc. Hex.
32 20 ESPACE 56 38 8 80 50 P 104 68 h
33 21 ! 57 39 9 81 51 Q 105 69 i
34 22 " 58 3A : 82 52 R 106 6A j
35 23 # 59 3B ; 83 53 S 107 6B k
36 24 $ 60 3C < 84 54 T 108 6C l
37 25 % 61 3D = 85 55 U 109 6D m
38 26 & 62 3E > 86 56 V 110 6E n
39 27 ' 63 3F ? 87 57 W 111 6F o
40 28 ( 64 40 @ 88 58 X 112 70 p
41 29 ) 65 41 A 89 59 Y 113 71 q
42 2A * 66 42 B 90 5A Z 114 72 r
43 2B + 67 43 C 91 5B [ 115 73 s
44 2C , 68 44 D 92 5C \ 116 74 t
45 2D - 69 45 E 93 5D ] 117 75 u
46 2E . 70 46 F 94 5E ^ 118 76 v
47 2F / 71 47 G 95 5F _ 119 77 w
48 30 0 72 48 H 96 60 ` 120 78 x
49 31 1 73 49 I 97 61 a 121 79 y
50 32 2 74 4A J 98 62 b 122 7A z
51 33 3 75 4B K 99 63 c 123 7B {
52 34 4 76 4C L 100 64 d 124 7C |
53 35 5 77 4D M 101 65 e 125 7D }
54 36 6 78 4E N 102 66 f 126 7E ~
55 37 7 79 4F O 103 67 g 127 7F DEL

Dernière mise à jour : le mercredi 15 mars 2006, 11:10

IUT Informatique Aix-en-Provence 1ère Année © Cyril Pain-Barre

Vous aimerez peut-être aussi