Logo GNT
Actualités Tests & Guides Bons Plans
Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11
Entraide Matériel Réseaux et Internet IP A propos de la fragmentation IP

A propos de la fragmentation IP

19 réponses
Avatar
Angelot
Bonsoir,

Une question de protocole IP avant dodo.

Supposez qu'un datagramme IP soit fragmenté (par un routeur par exemple) en
3 datagrammes pour continuer son chemin.

Le mode IP étant non connecté, le 3ème fragment (MF=0, offset != 0) pourrait
bien arriver à destination avant le 1er (MF=1, offset =0). A mon avis, les 3
fragments vont à la poubelle, je vois mal la machine destinatrice faire une
remise en ordre (ên s'appuyant sur le numéro d'identification).

Et vous, quel est votre avis ?

Certains objecteront qu'on évite la fragmentation grâce au MTU. Est-ce
vraiment toujours le cas ?

Cordialement,
Angelot
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
1 2
Avatar
_SebF - www.frameip.com
"Angelot" a écrit dans le message de news:
cal450$uk9$

Bonsoir,


Re

Le mode IP étant non connecté, le 3ème fragment (MF=0, offset != 0)
pourrait

bien arriver à destination avant le 1er (MF=1, offset =0).


Oui

A mon avis, les 3
fragments vont à la poubelle, je vois mal la machine destinatrice faire
une

remise en ordre (ên s'appuyant sur le numéro d'identification).
Et vous, quel est votre avis ?


A mon avis, la couche IP est là pour s'occuper du réassemblage. Comme tous
les paquets doivent comporter le même ID, la couche Ip pourra facilement
regrouper les fragments dans un même groupe afin de les remettrent dans
l'ordre grâce au positionnement de l'offset.

Comme tu le dis, IP est bien en mode non connecté, car si il manque un
fragment, étant donnée qu'il n'y a pas de contrôle à ce niveau, le fragment
manquant ne sera pas renvoyé.


Certains objecteront qu'on évite la fragmentation grâce au MTU. Est-ce
vraiment toujours le cas ?


J'ai pas compris où tu désirais en venir, car je dirais plutôt :
on provoque la fragmentation grâce au MTU. :)

--

_SebF

http://www.frameip.com
Pour ceux qui aiment TCPIP

Avatar
Angelot
Merci Seb de ces éléments,

A mon avis, les 3
fragments vont à la poubelle, je vois mal la machine destinatrice faire
une

remise en ordre (ên s'appuyant sur le numéro d'identification).
Et vous, quel est votre avis ?


A mon avis, la couche IP est là pour s'occuper du réassemblage. Comme tous
les paquets doivent comporter le même ID, la couche Ip pourra facilement
regrouper les fragments dans un même groupe afin de les remettrent dans
l'ordre grâce au positionnement de l'offset.


ça paraîtrait logique en effet, mais pour l'instant je n'ai pas encore
trouvé trace de ce mécanisme dans les RFC.
Quelqu'un a une idée de recherche ?

Comme tu le dis, IP est bien en mode non connecté, car si il manque un
fragment, étant donnée qu'il n'y a pas de contrôle à ce niveau, le
fragment

manquant ne sera pas renvoyé.


En principe, un timer est déclenché au 1er fragment et, s'il en manque un,
le timer claque avec envoi d'une erreur ICMP.

Mais, pour revenir au point précédent, comment le timer pourrait-il se
déclencher si le dernier fragment arrive en premier !!!!

Certains objecteront qu'on évite la fragmentation grâce au MTU. Est-ce
vraiment toujours le cas ?


J'ai pas compris où tu désirais en venir, car je dirais plutôt :
on provoque la fragmentation grâce au MTU. :)


Dans les machines traditionnelles(!), il ne devrait pas avoir de
fragmentation IP. Un MTU de valeur 1472 serait remonté à la couche transport
afin que le SDU-IP ne puisse pas être fragmenté pour réussir son
encapsulation entière dans Ethernet.

Cordialement,
Angelot


Avatar
Jacques Caron
Salut,

On Mon, 14 Jun 2004 23:08:47 +0200, Angelot
wrote:

Le mode IP étant non connecté, le 3ème fragment (MF=0, offset != 0)
pourrait bien arriver à destination avant le 1er (MF=1, offset =0).
A mon avis, les 3 fragments vont à la poubelle, je vois mal la machine
destinatrice faire une remise en ordre (ên s'appuyant sur le numéro
d'identification).


Et pourtant si, c'est ce que doit faire la machine, d'après la RFC 760
(section 3.2, pages 24 et suivantes).

Certains objecteront qu'on évite la fragmentation grâce au MTU. Est-ce
vraiment toujours le cas ?


On peut éviter la fragmentation avec pMTUd (path MTU discovery). Mais
pMTUd n'est pas possible si quelqu'un s'amuse à filtrer les ICMP sans
distinction (et en particulier need to fragment but DF bit set), donc
pMTUd peut parfois être désactivé, ou certains équipements qui encapsulent
(endpoints de tunnels IPsec ou PPPoE par exemple) et augmentent donc la
taille des paquets (et diminuent la MTU) peuvent ignorer DF (pour éviter
le problème du filtrage ICMP). Pas de garantie qu'il n'y aura pas de
fragmentation, donc.

Jacques.
--
Interactive Media Factory
Création, développement et hébergement
de services interactifs: SMS, SMS+, Audiotel...
http://www.imfeurope.com/

Avatar
Patrick_91
Bonsoir,

Angelot wrote:

Merci Seb de ces éléments,

A mon avis, les 3
fragments vont à la poubelle, je vois mal la machine destinatrice faire
une

remise en ordre (ên s'appuyant sur le numéro d'identification).
Et vous, quel est votre avis ?


A mon avis, la couche IP est là pour s'occuper du réassemblage. Comme
tous les paquets doivent comporter le même ID, la couche Ip pourra
facilement regrouper les fragments dans un même groupe afin de les
remettrent dans l'ordre grâce au positionnement de l'offset.


ça paraîtrait logique en effet, mais pour l'instant je n'ai pas encore
trouvé trace de ce mécanisme dans les RFC.
Quelqu'un a une idée de recherche ?


Si si la mecanique de fragmentation et reassemblage est parfaitement
decrite, voici un link par exemple :
http://www.linktionary.com/f/fragmentation.html

Comme tu le dis, IP est bien en mode non connecté, car si il manque un
fragment, étant donnée qu'il n'y a pas de contrôle à ce niveau, le
fragment

manquant ne sera pas renvoyé.


En principe, un timer est déclenché au 1er fragment et, s'il en manque un,
le timer claque avec envoi d'une erreur ICMP.

Mais, pour revenir au point précédent, comment le timer pourrait-il se
déclencher si le dernier fragment arrive en premier !!!!

Certains objecteront qu'on évite la fragmentation grâce au MTU. Est-ce
vraiment toujours le cas ?


J'ai pas compris où tu désirais en venir, car je dirais plutôt :
on provoque la fragmentation grâce au MTU. :)


Dans les machines traditionnelles(!), il ne devrait pas avoir de
fragmentation IP. Un MTU de valeur 1472 serait remonté à la couche
transport afin que le SDU-IP ne puisse pas être fragmenté pour réussir son
encapsulation entière dans Ethernet.


Pourquoi cela ?? le 'MTU' est le (maximum transmission unit) et c'est une
carracteristique de host ip qui n'est a priori pas fixé .
IL est vrai que la valeur 1500 pour les machines équipées de ports ethernet
semble optimale mais rien n'oblige pour de gros debits a fonctionner sous
ethernet (!!) dans ce cas des valeurs de MTU beaucoup plus importante
seront utilisees. En revanche ce qui est bien decrit ce sont les processus
de fragmentation et de reassemblage, de facon a conformer tous les
datagrams aux carracteristiques de tous les hosts traversés .
Ce qui ne va pas en general lorsqu'on dit vulgairement qu'on a un probleme
de MTU c'est qu'un host ip quelque part sur le trajet source -->destination
fait mal son boulot de fragmentation ... forcement ca coince et c'est de la
faute de l'un des maillons traverses, pas de l'internaute. En effet,si
celui ci met par exemple le MTU a 1500 et que l'un des hosts sur le
parcours presente un MTU inferieur, il doit s'en suivre une fragmentation
(accompagnee d'une tres legere perte d'efficacite ) mais aucun blocage
ne devrait se produire ... ...
Serait interessant de savoir quels sont les types d'equipement qui coincent
ainsi ...

Amicalement




Cordialement,
Angelot




Avatar
Jacques Caron
On Tue, 15 Jun 2004 01:59:01 +0200, Patrick_91
wrote:

Ce qui ne va pas en general lorsqu'on dit vulgairement qu'on a un
probleme de MTU c'est qu'un host ip quelque part sur le trajet
source-->destination fait mal son boulot de fragmentation ...
forcement ca coince et c'est de la faute de l'un des maillons traverses,
pas de l'internaute. En effet,si celui ci met par exemple le MTU a 1500
et que l'un des hosts sur le parcours presente un MTU inferieur, il doit
s'en suivre une fragmentation (accompagnee d'une tres legere perte
d'efficacite ) mais aucun blocage ne devrait se produire ... ...
Serait interessant de savoir quels sont les types d'equipement qui
coincent ainsi ...


Le problème ne vient pas en général d'équipements qui ne fragmentent pas
correctement, mais de filtres un peu abusifs qui interdisent tous les
messages ICMP sans restriction, en particulier "need to fragment but DF
bit set". Un firewall devant un serveur web qui filtrerait ces messages
empêche pMTUd de fonctionner, et donc le serveur essaie vainement
d'envoyer des paquets avec sa MTU à lui avec DF à 1, et l'équipement qui
doit fragmenter plus loin sur le chemin essaie vainement de lui dire que
la MTU est plus petite que ce qu'il pense.

Jacques.
--
Interactive Media Factory
Création, développement et hébergement
de services interactifs: SMS, SMS+, Audiotel...
http://www.imfeurope.com/

Avatar
Patrick_91
bonsoir
Jacques Caron wrote:

On Tue, 15 Jun 2004 01:59:01 +0200, Patrick_91
wrote:

Ce qui ne va pas en general lorsqu'on dit vulgairement qu'on a un
probleme de MTU c'est qu'un host ip quelque part sur le trajet
source-->destination fait mal son boulot de fragmentation ...
forcement ca coince et c'est de la faute de l'un des maillons traverses,
pas de l'internaute. En effet,si celui ci met par exemple le MTU a 1500
et que l'un des hosts sur le parcours presente un MTU inferieur, il doit
s'en suivre une fragmentation (accompagnee d'une tres legere perte
d'efficacite ) mais aucun blocage ne devrait se produire ... ...
Serait interessant de savoir quels sont les types d'equipement qui
coincent ainsi ...


Le problème ne vient pas en général d'équipements qui ne fragmentent pas
correctement, mais de filtres un peu abusifs qui interdisent tous les
messages ICMP sans restriction, en particulier "need to fragment but DF
bit set". Un firewall devant un serveur web qui filtrerait ces messages
empêche pMTUd de fonctionner, et donc le serveur essaie vainement
d'envoyer des paquets avec sa MTU à lui avec DF à 1, et l'équipement qui
doit fragmenter plus loin sur le chemin essaie vainement de lui dire que
la MTU est plus petite que ce qu'il pense.


Yes ce peut etre ca en effet mais interdire les messages ICMP sans
restriction pour un gateway ce n'est pas correct .. la preuve ..
Dans ces conditions les messages indiquant une congestion seraient bloques
de la meem maniere .. ce n'est pas du boulot ...
Amicalement
patrick




Jacques.



Avatar
Angelot
Bonsoir Patrick,

Si si la mecanique de fragmentation et reassemblage est parfaitement
decrite, voici un link par exemple :
http://www.linktionary.com/f/fragmentation.html


Le début de l'explication est aguichant, mais pour continuer le texte, il
faut se procurer l'ouvrage !

Pourquoi cela ?? le 'MTU' est le (maximum transmission unit) et c'est une
carracteristique de host ip qui n'est a priori pas fixé .
IL est vrai que la valeur 1500 pour les machines équipées de ports
ethernet

semble optimale mais rien n'oblige pour de gros debits a fonctionner sous
ethernet (!!) dans ce cas des valeurs de MTU beaucoup plus importante
seront utilisees.


Sapristi, on peut mettre plus de 1500 octets en charge utile de la trame MAC
!
D'où vous vient cette information ?
Si j'ai bien lu IEEE 802.3 la charge utile d'une trame MAC normale est
comprise entre 46 et 1500 octets, celle d'une trame étiquetée entre 42 et
1500 octets.

Cordialement,
Angelot

Avatar
Angelot
Bonsoir Jacques,

Et pourtant si, c'est ce que doit faire la machine, d'après la RFC 760
(section 3.2, pages 24 et suivantes).


Exact, l'algorithme est aussi décrit dans RFC 815. J'avais loupé ces
développements.

On peut éviter la fragmentation avec pMTUd (path MTU discovery).


En fait qui fragmente réellement ?

Le cas le plus exposé est celui du routeur qui réceptionne un datagramme
dont la taille est supérieure au MTU du bond suivant.

A-t-on des cas où cette fragmentation est engendrée par la machine source
parce que TCP par exemple envoie un segment de taille importante ?
Normalement, un paramètre MTU (au pire par défaut) devrait remonter dans la
couche transport pour éviter cette fragmentation qui réduit les
performances.

Cordialement,
Angelot

Avatar
Zythum

Sapristi, on peut mettre plus de 1500 octets en charge utile de la
trame MAC !


En giga et 10 giga ethernet il existe les "jumbo frame" qui te permettent
une charge utile de 9000 octets

D'où vous vient cette information ?


au hasard IEEE 802.3 ;-)

--
Zythum

Avatar
Patrick_91
Bonjour,
Angelot wrote:

Bonsoir Patrick,

Si si la mecanique de fragmentation et reassemblage est parfaitement
decrite, voici un link par exemple :
http://www.linktionary.com/f/fragmentation.html


Le début de l'explication est aguichant, mais pour continuer le texte, il
faut se procurer l'ouvrage !
Comment quel ouvrage ?? les RFC's suivants sont accessibles :

791 815 1122 879 1180

Ca c'est gratos ...

Sapristi, on peut mettre plus de 1500 octets en charge utile de la trame
MAC !
D'où vous vient cette information ?
Bien sur , l'information vient des carracteristiques des équipements niv 2

(point a point) et j'avais pris la precaution de dire qu'on etait pas
obligé de rester en ethernet classique ...ou IEE 802.3
voir ce link ...
http://www2.rad.com/networks/2003/largemtu/avlnets.htm
des MTU de 4k à 65.280 k sont mentionnées.Heureusement , si non le reseau
INternet serait bien peu performant ...
Si j'ai bien lu IEEE 802.3 la charge utile d'une trame MAC normale est
comprise entre 46 et 1500 octets, celle d'une trame étiquetée entre 42 et
1500 octets.
Trame MAC normale pour IEE 802.3 absolument ..!


Cordialement,
Angelot
Amicalement



1 2