TP 4, Annexe et Corrigé - powerduck1.free.frpowerduck1.free.fr/Cours/Reseau/TP4AnnexeEtCorrige.pdf · TP 4, Annexe et Corrigé Réseaux 2005-2006 Page 3/38 Données : 0001 0800 0604

TTPP 44,, AAnnnneexxee eett CCoorrrriiggéé

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

!! NNii llee pprrééaammbbuullee nnii llee CCRRCC ddeess ttrraammeess EEtthheerrnneett nnee ffiigguurreenntt ddaannss lleess ccaappttuurreess ::

!! llee pprreemmiieerr oocctteett aappppaarrttiieenntt àà ll''aaddrreessssee EEtthheerrnneett ddee ddeessttiinnaattiioonn ;;

!! llee ddeerrnniieerr aappppaarrttiieenntt aauuxx ddoonnnnééeess ddee llaa ttrraammee..

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)



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.



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.

!! IIll yy aa ttoouutteeffooiiss uunn pprroobbllèèmmee ccaarr ll''AAddrreessssee EEtthheerrnneett DDeessttiinnaattiioonn nn''eesstt ppaass llaa mmêêmmee qquuee ddaannss llee ddaattaaggrraammmmee.. CCeettttee rrééppoonnssee nnee ppoouurrrraa ddoonncc ppaass êêttrree rreeççuuee oouu ttrraaiittééee.. SSooiitt llaa ddeessttiinnaattiioonn ddee llaa ttrraammee eesstt bboonnnnee mmaaiiss llaa mmaacchhiinnee nnee ssee rreeccoonnnnaaîîttrraa ppaass ddaannss llee ddaattaaggrraammmmee,, ssooiitt llaa ddeessttiinnaattiioonn nn''eesstt ppaass bboonnnnee eett llaa mmaacchhiinnee qquuii ddeevvaaiitt rreecceevvooiirr llaa ttrraammee nnee llaa rreecceevvrraa ppaass.. DDaannss ttoouuss lleess ccaass,, llaa mmaacchhiinnee qquuii aavvaaiitt éémmiiss llaa rreeqquuêêttee RRAARRPP ddeevvrraa llaa rréééémmeettttrree..



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.



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



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



Champs du datagramme IP :

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


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.



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


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.



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



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.



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



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.



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



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



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.



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



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 :



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



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)











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 :



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



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 [email protected]. 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.

!! TToouutteess lleess vvaalleeuurrss ddeess cchhaammppss ddeess eenn--ttêêtteess ddeess pprroottooccoolleess ddééccrriittss ssoonntt ccooddééeess eenn ffoorrmmaatt rréésseeaauu..


mailto:[email protected]


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.



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.



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.



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.



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.



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



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.



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.



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.



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.


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.



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



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.


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.


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.



• 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) :



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.



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 (décimal) Service

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)




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 Déc. Hex.

Caractère Déc. Hex.



Caractère

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

Documents

TP 4, Annexe et Corrigé - powerduck1.free.frpowerduck1.free.fr/Cours/Reseau/TP4AnnexeEtCorrige.pdf · TP 4, Annexe et Corrigé Réseaux 2005-2006 Page 3/38 Données : 0001 0800 0604