4 Conclusion et bibliographie
1.1 Description de l’en-tˆ ete
VERS 4 bits qui sp´ecifient la version du protocol IP. L’objet de ce champ est la v´erification que l’´emetteur et le destinataire des datagrammes sont bien en phases avec la mˆeme version. Actuellement c’est la version 4 qui est principalement utilis´e sur l’Internet, bien que quelques impl´ementations de la version 6 existent et soient d´ej`a en exp´erimentation1.
HLEN 4bits qui donnent la longueur de l’en-tˆete en mots de 4 octets. La taille standard de cette en-tˆete fait 5 mots, la taille maximale fait : (23+ 22+ 21+ 20)×4 = 60 octets2
TOTAL LENGTH Donne la taille du datagramme, en-tˆete plus donn´ees. S’il y fragmentation (voir plus loin) il s’agit ´egalement de la taille du fragment (chaque datagramme est ind´ependant des autres).
1Nous examinerons les caract´eristiques de la version 6 d’IP `a la fin de ce cycle de cours
2On encore plus simple 24−1
Description de l’en-tˆete 45 La taille des donn´ees est donc `a calculer par soustraction de la taille de
l’en-tˆete.
16 bits autorisent la valeur 65535. . .La limitation vient le plus souvent du support physique (MTU) qui impose une taille plus petite, sauf sur les “ hyperchannel ”.
TYPE OF SERVICE 8 bits (4 utiles) qui indiquent au routeur l’attitude `a avoir vis `a vis de ce datagramme. Suivant les valeurs de ce champ, le routeur peut privil´egier un datagramme par rapport `a un autre.
Par exemple, des datagrammes d’un transfert de fichier (ftp) peuvent avoir `a laisser passer un datagramme rep´er´e comme contenant des ca-ract`eres frapp´es au clavier (session telnet).
0x00 Service normal Transfert banal 0x02 Minimiser le coˆut “ news ” (nntp) 0x04 Maximiser la qualit´e ICMP
0x10 Minimiser le d´elai Session telnet 0x08 Maximiser le d´ebit Transfert ftp
IDENTIFICATION, FLAGS et FRAGMENT OFFSET Ces mots sont pr´evus pour contrˆoler la fragmentation des datagrammes. Les donn´ees sont frag-ment´ees car les datagrammes peuvent avoir `a traverser des r´eseaux avec des MTU plus petits que celui du premier support physique employ´e.
Consulter la section suivanteFragmentation IP.
TTL “ Time To Live ” 8 bits, 255 secondes maximum de temps de vie pour un datagramme sur le net.
Pr´evu `a l’origine pour d´ecompter un temps, ce champ n’est qu’un comp-teur d´ecr´ement´e d’une unit´e `a chaque passage dans un roucomp-teur.
Couramment la valeur de d´epart est 32 ou mˆeme 64. Son objet est d’´eviter la pr´esence de paquets fantˆomes circulant ind´efiniment. . . Si un routeur passe le compteur `a z´ero avant d´elivrance du datagramme, un message d’erreur — ICMP (consultez le paragraphe 4) — est renvoy´e
`a l’´emetteur avec l’indication du routeur. Le paquet en lui-mˆeme est perdu.
PROTOCOL 8 bits pour identifier le format et le contenu des donn´ees, un peu comme le champ “ type ” d’une trame Ethernet. Il permet `a IP d’adres-ser les donn´ees extraites `a l’une ou l’autre des couches de transport.
Dans le cadre de ce cours, nous utiliserons essentiellement ICMP, IGMP, UDP et TCP.
HEADER CHECKSUM 16 bits pour s’assurer de l’int´egrit´e de l’en-tˆete. Lors du calcul de ce “ checksum ” ce champ est `a 0.
A la r´eception de chaque paquet, la couche calcule cette valeur, si elle ne correspond pas `a celle trouv´ee dans l’en-tˆete le datagramme est oubli´e (“ discard ”) sans message d’erreur.
SOURCE ADDRESS Adresse IP de l’´emetteur, `a l’origine du datagramme.
DESTINATION ADDRESS Adresse IP du destinataire du datagramme.
IP OPTIONS 24 bits pour pr´eciser des options de comportement des couches IP travers´ees et destinatrices. Les options les plus courantes concernent :
– Des probl`emes de s´ecurit´e – Des enregistrements de routes – Des enregistrements d’heure
– Des sp´ecifications de route `a suivre – . . .
Historiquement ces options ont ´et´e pr´evues d`es le d´ebut mais leur impl´ementation n’a pas ´et´e termin´ee.
Pour des raisons de s´ecurit´e, la tendance est d’ignorer ce champ. Cer-tains sites consid`erent mˆeme comme suspects les datagrammes conte-nants des “ IP OPTIONS ” !
PADDING Remplissage pour aligner sur 32 bits. . .
En conclusion partielle que peut-on dire du travail de la couche IP ? 1. Il consiste `a router les datagrammes en les acheminant “ au mieux ”,
on verra plus loin de quelle mani`ere. C’est son travail principal.
2. Il peut avoir `a fragmenter les donn´ees de taille sup´erieure au MTU du support physique `a employer.
Fragmentation IP 47
1.2 Fragmentation IP
La couche de liaison (Couche 2 “ Link ”) impose une taille limite, le
“ Maximum Transfert Unit ”. Par exemple cette valeur est de 1500 pour une trame Ethernet, elle peut ˆetre de 256 avec SLIP (“ Serial Line IP ”) sur liaison s´erie (RS232. . .).
Dans ces conditions, si la couche IP doit transmettre un bloc de donn´ees de taille sup´erieure au MTU `a employer, il y a fragmentation !
Par exemple, un bloc de 1481 octets sur Ethernet sera d´ecompos´e en un datagramme de 1480 (1480 + 20 = 1500) et un datagramme de 1 octet !
Il existe une exception `a cette op´eration, due `a la pr´esence active du bit
“ Don’t Fragment bit ” du champ FLAGS de l’en-tˆete IP. La pr´esence `a 1 de ce bit interdit la fragmentation dudit datagramme par la couche IP qui en aurait besoin. C’est une situation de blocage, la couche ´emettrice est tenue au courant par un message ICMP (consultez le paragraphe 4)Fragmentation needed but don’t fragment bit setet bien sˆur le datagramme n’est pas transmis plus loin.
X25 (128)
A G1
G2 B
802.2 (1492)
Ethernet (1500)
figure IV.03
Fragmentation
– Quand un datagramme est fragment´e, il n’est r´eassembl´e que par la couche IP destinatrice finale. Cela implique trois remarques :
1. La taille des datagrammes re¸cus par le destinataire final est direc-tement d´ependante du plus petit MTU rencontr´e.
2. Les fragments deviennent des datagrammes `a part enti`ere.
3. Rien ne s’oppose `a ce qu’un fragment soit `a nouveau fragment´e.
– Cette op´eration est absolument transparente pour les couches de trans-port qui utilisent IP.
– Quand un datagramme est fragment´e, chaque fragment est identifi´e de mani`ere unique, relativement au datagramme initial. Cette valeur est inscrite dans le champ IDENTIFICATION.
S’il y a encore des fragments, un des bits du champFLAGSest positionn´e
`a 1 pour indiquer “ More fragment ” ! Ce champ a une longueur de 3 bits.
FRAGMENT OFFSET contient l’offset du fragment, relativement au data-gramme initial.
Cet offset est cod´e sur 13 bits.
transmettre Le fragment à Ce qui reste à transmettre Offset : données transmises
figure IV.04 Pour tous les fragments :
– Les donn´ees doivent faire un multiple de 8 octets, sauf pour le dernier fragment, ´evidement.
– Le champ TOTAL LENGTHchange.
– Chaque fragment est un datagramme ind´ependant, susceptible d’ˆetre
`a son tour fragment´e.
Pour le dernier fragment : – FLAGS est remis `a z´ero.
– Les donn´ees ont une taille quelconque.
R´eassemblage
– Tous les datagrammes issus d’une fragmentation deviennent des data-grammes IP comme (presque) les autres.
– Ils arrivent `a destination, peut ˆetre dans le d´esordre, dupliqu´es. IP doit faire le tri.
– il y a suffisamment d’information dans l’en-tˆete pour r´eassembler les fragments ´epars.
– Maissi un fragment manque, la totalit´e du datagramme est perdu car aucun m´ecanisme de contrˆole n’est impl´ement´e pour cela dans IP.
La figure IV.05 r´esume l’op´eration de fragmentation d’un datagramme IP.
Fragmentation IP 49
Datagramme initial
0
N multiple entier de 8
M, reste de la division entière de L par 8.
L octets à transmettre
H H1 H2 H3 H4 H5
N
2N
3N
4N N−1
5 datagrammes différents
figure IV.05
H1 H2 H3 H4 H5
IDENTIFICATION I I I I I
FLAG MF MF MF MF 0
OFFSET 0 N 2×N 3×N 4×N
TOTAL LENGTH H+N H+N H+N H+N H+M HEADER CHECKSUM C1 C2 C3 C4 C5 Notez les variations de certains champs de l’en-tˆete :
1. IDENTIFICATION est le mˆeme pour tous 2. FLAG est 0 pour le dernier datagramme 3. OFFSET croˆıt de la taille du fragment, ici N.
4. TOTAL LENGTHest g´en´eralement diff´erent pour le dernier fragment, sauf cas particulier.
5. HEADER CHECKSUM change `a chaque fois car l’OFFSET change (rappel : il ne tient pas compte des donn´ees).