Anastrophe

1. Pour faire le réassemblage, il faut d'abord regrouper les paquets appartenant à un même message; c'est-à-dire les paquets avec une même valeur du champs ``identification'', mais aussi de même adresse source (la norme RFC791 ajoute aussi la même adresse destination et le même numéro de protocole). Nos douze paquets correspondent à 3 messages différents : Ident=4235 et Src=18.113.0.53, Ident=4235 et Src=18.181.0.31, Ident=5432 et Src=18.181.0.31.

   L'ordre des paquets d'un même message sera alors donné par les valeurs croissantes du champs Offset. Il reste alors à regarder les champs Offset, Length, et le bit MF de chaque paquet pour savoir si le message est complet.

   1. Message 1 : Ident=4235 et Src=18.113.0.53

      4	5	0	44
      4235			001	0
      42		17	Checksum
      18.113.0.53
      157.159.100.21
      ********_belle_marquise_

      
      

      4	5	0	44
      4235			001	3
      42		17	Checksum
      18.113.0.53
      157.159.100.21
      ,_Mesrine_belle_baronne_

      
      

      4	5	0	34
      4235			000	6
      40		17	Checksum
      18.113.0.53
      157.159.100.21
      Michel_Jonasz.

      
      

      Le message est complet :

      ``********_belle_marquise_,_Mesrine_belle_baronne_Michel_Jonasz.''

      (NB : Joueurs de blues )

   2. Message 2 : Ident=4235 et Src=18.181.0.31

      4	5	0	36
      4235			001	0
      42		17	Checksum
      18.181.0.31
      157.159.100.21
      ********_mourir_

      
      

      4	5	0	28
      4235			001	2
      40		17	Checksum
      18.181.0.31
      157.159.100.21
      d'amour_

      
      

      4	5	0	36
      4235			001	3
      41		17	Checksum
      18.181.0.31
      157.159.100.21
      _belle_marquise_

      
      

      4	5	0	28
      4235			001	5
      42		17	Checksum
      18.181.0.31
      157.159.100.21
      me_font_

      
      

      4	5	0	36
      4235			001	6
      41		17	Checksum
      18.181.0.31
      157.159.100.21
      _vos_beaux_yeux_

      
      

      4	5	0	28
      4235			000	8
      42		17	Checksum
      18.181.0.31
      157.159.100.21
      Moliere.

      
      

      Le message est complet :

      ``********_mourir_d'amour__belle_marquise_me_font__vos_beaux_yeux_Moliere.''

      (NB : Le Bourgeois Gentilhomme )

   3. Message 3 : Ident=5432 et Src=18.181.0.31

      4	5	0	36
      5432			001	0
      42		17	Checksum
      18.181.0.31
      157.159.100.21
      ********pensez-y

      
      

      4	5	0	36
      5432			001	2
      43		17	Checksum
      18.181.0.31
      157.159.100.21
      _belle_marquise_

      
      

      4	5	0	30
      5432			000	8
      42		17	Checksum
      18.181.0.31
      157.159.100.21
      Corneille.

      
      

      Le message n'est pas complet :

      ``********pensez-y_belle_marquise_.........Corneille.''

      Il manque 32 octets avant ``Corneille.'' qui est la fin du message.

      (NB : Stances à la Marquise, cf. aussi Marquise de Brassens qui rajoute dans la bouche de la Marquise : ``J'ai 26 ans mon vieux Corneille et je t'emmerde en attendant.'')

      Pour plus d'infos sur ces belles marquises, cf. http://www-inf.int-evry.fr/~hennequi/CoursRD/Marquise.

2. En ``dé-encapsulant'', le message délivré par IP à la couche supérieure va a priori commencer par l'entête du protocole de la couche supérieure. Ici, il s'agit donc de l'entête UDP qui fait effectivement 8 octets (portsrc, portdest, length, checksum chacun sur 2 octets). Les parties textes sont alors les données au niveau des applications. On notera (bien évidemment) que l'entête du protocole transport n'apparait que dans le premier fragment et pas dans les autres.
3. Le codage de l'Offset en mots de 8 octets implique que le début d'un fragment est toujours à une position multiple de 8 en octets dans le message initial. Le fragment précédent doit alors se terminer par un octet qui précède un multiple de 8. Donc, sauf pour le dernier fragment, la taille des données en octets (Length-4*IHL) est obligatoirement un multiple de 8. CQFD.
4. Contrairement à X25 où les tailles de paquets sont des puissances de 2, les MTUs dans IP peuvent être quelconques. Dans le cas de segmentations successives, cela donne des tailles de paquet peu homogènes.

   Compte tenu de Nostradamus, la segmentation de 72 octets de données sur une liaison de MTU 50 octets va donner 3 paquets de 44 octets au total (20 entête + 24 données). Sur la liaison de MTU 40 octets ces paquets donneront alors chacun un paquet de 36 octets (20+16) et un paquet de 28 octets (20+8). Le résultat correspond aux paquets du message ``Bourgeois Gentilhomme'' dans notre exemple. Ce défaut de IP peut être très gênant dans le cas de resegmentations sur des valeurs de MTU très voisines. Cela se rencontre en particulier dans le cadre des réseaux locaux comme Ethernet où l'on trouve plusieurs valeurs de MTU proches de 1500 octets. L'envoi d'un gros fichier peut alors se traduire par la génération de paquets de 1480 octets de données qui seront chacun resegmentés au premier routeur en un paquet de 1472 octets de données et un paquet de 8 octets de données!!!

5. Lorsque l'on fragmente un message, les différents fragments héritent de la même valeur du champ TTL. Si l'on reçoit des fragments d'un même message avec des TTL différents, c'est donc que le TTL a été décrémenté différemment pour les fragments. Ceci correspond en pratique à un nombre de routeurs traversés différents et donc une route différente pour chaque TTL. En théorie, il serait toutefois possible d'avoir des TTL différents en utilisant une même route dans la mesure où un routeur qui devient lent pour acheminer peut réduire le TTL de plus de 1.
6. Dans les fragments IP non terminaux (MF=1), il est impossible de connaître directement la longueur totale du message transport. C'est uniquement avec le fragment terminal (MF=0), que l'on a cette longueur; elle vaudra alors 8*Offset + Length -4 *IHL. Le dernier fragment est donc nécessaire et suffisant pour déterminer la longueur totale du message. Ceci est un peu gênant pour le développeur qui aimerait bien savoir au départ la taille des buffers pour stocker les fragments qui arrivent.

7. Pour les options, cela dépend. Certaines options ont vocation à être recopiées dans les fragments, d'autres non. Les options source route qui forcent ou contraignent le chemin à suivre dans le réseau seront naturellement recopiées dans les différents fragments. Idem pour l'option Sécurité. Par contre, l'option Record Route n'est pas prévue pour être recopiée et ne doit exister que dans un seul fragment d'un message (le premier en général).