Je me permets de vous signaler l'article de
Stéphane Bortzmeyer, « Fragmentation IPv6 : se résigner à couper à 1280
octets ? », 2010-11-12,
http://www.bortzmeyer.org/fragmentation-ip-1280.html ,
sur l'augmentation de la taille des paquets ethernet, IPv4, IPv6...
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
Pascal Hambourg
[Suivi à fr.comp.reseaux.ip]
Salut,
Nicolas Krebs a écrit :
Je me permets de vous signaler l'article de Stéphane Bortzmeyer, « Fragmentation IPv6 : se résigner à couper à 1280 octets ? », 2010-11-12, http://www.bortzmeyer.org/fragmentation-ip-1280.html , sur l'augmentation de la taille des paquets ethernet, IPv4, IPv6...
Triste. L'extermination totale des administrateurs réseaux qui bloquent l'ICMP, ça me plaisait pourtant bien...
[Suivi à fr.comp.reseaux.ip]
Salut,
Nicolas Krebs a écrit :
Je me permets de vous signaler l'article de
Stéphane Bortzmeyer, « Fragmentation IPv6 : se résigner à couper à 1280
octets ? », 2010-11-12,
http://www.bortzmeyer.org/fragmentation-ip-1280.html ,
sur l'augmentation de la taille des paquets ethernet, IPv4, IPv6...
Triste. L'extermination totale des administrateurs réseaux qui bloquent
l'ICMP, ça me plaisait pourtant bien...
Je me permets de vous signaler l'article de Stéphane Bortzmeyer, « Fragmentation IPv6 : se résigner à couper à 1280 octets ? », 2010-11-12, http://www.bortzmeyer.org/fragmentation-ip-1280.html , sur l'augmentation de la taille des paquets ethernet, IPv4, IPv6...
Triste. L'extermination totale des administrateurs réseaux qui bloquent l'ICMP, ça me plaisait pourtant bien...
Eric Masson
Pascal Hambourg writes:
'Lut,
Triste. L'extermination totale des administrateurs réseaux qui bloquent l'ICMP, ça me plaisait pourtant bien...
Il n'en resterait pas des masses alors.
-- Pourquoi les internautes français ce mobiliseraient pas pour se regrouper un société ou association pour pouvoir avoir des numéro vert Il faudrait que louer les lignes téléphoniques à FT et on ne paierai qu'un abonnement -+- BT in : Guide du Neuneu Usenet - Neuneu se met au vert -+-
Triste. L'extermination totale des administrateurs réseaux qui bloquent
l'ICMP, ça me plaisait pourtant bien...
Il n'en resterait pas des masses alors.
--
Pourquoi les internautes français ce mobiliseraient pas pour se regrouper
un société ou association pour pouvoir avoir des numéro vert Il faudrait
que louer les lignes téléphoniques à FT et on ne paierai qu'un abonnement
-+- BT in : Guide du Neuneu Usenet - Neuneu se met au vert -+-
Triste. L'extermination totale des administrateurs réseaux qui bloquent l'ICMP, ça me plaisait pourtant bien...
Il n'en resterait pas des masses alors.
-- Pourquoi les internautes français ce mobiliseraient pas pour se regrouper un société ou association pour pouvoir avoir des numéro vert Il faudrait que louer les lignes téléphoniques à FT et on ne paierai qu'un abonnement -+- BT in : Guide du Neuneu Usenet - Neuneu se met au vert -+-
Az Sam
"Nicolas Krebs" a écrit dans le message de news:ibn0nf$obe$
Je me permets de vous signaler l'article de Stéphane Bortzmeyer, « Fragmentation IPv6 : se résigner à couper à 1280 octets ? », 2010-11-12, http://www.bortzmeyer.org/fragmentation-ip-1280.html , sur l'augmentation de la taille des paquets ethernet, IPv4, IPv6...
De la conclusion de cet article me viennent 3 questions : - quelle importance que la taille relative des en tètes augmente ? (d'autant qu'il dit lui même que la majorité des autres paquets sont des tailles inferieures au max.) - pourquoi l'IPV6 impose t il un minimal de 1280 quand il aurait pu imposer un minima plus élevé ? - pourquoi des équipements sur la route, comme le 6erd donné en exemple, ne savent ils pas gérer des paquets plus grands, au minimum des paquets de 1500 ?
En un mot, qu'est ce qui a conduit a les concevoir ainsi ?
-- Cordialement, Az Sam.
"Nicolas Krebs" <nicolas1.krebs3@netcourrier.com> a écrit dans le message de
news:ibn0nf$obe$1@news.le-studio75.com...
Je me permets de vous signaler l'article de
Stéphane Bortzmeyer, « Fragmentation IPv6 : se résigner à couper à 1280
octets ? », 2010-11-12,
http://www.bortzmeyer.org/fragmentation-ip-1280.html ,
sur l'augmentation de la taille des paquets ethernet, IPv4, IPv6...
De la conclusion de cet article me viennent 3 questions :
- quelle importance que la taille relative des en tètes augmente ? (d'autant
qu'il dit lui même que la majorité des autres paquets sont des tailles
inferieures au max.)
- pourquoi l'IPV6 impose t il un minimal de 1280 quand il aurait pu imposer
un minima plus élevé ?
- pourquoi des équipements sur la route, comme le 6erd donné en exemple, ne
savent ils pas gérer des paquets plus grands, au minimum des paquets de 1500
?
En un mot, qu'est ce qui a conduit a les concevoir ainsi ?
"Nicolas Krebs" a écrit dans le message de news:ibn0nf$obe$
Je me permets de vous signaler l'article de Stéphane Bortzmeyer, « Fragmentation IPv6 : se résigner à couper à 1280 octets ? », 2010-11-12, http://www.bortzmeyer.org/fragmentation-ip-1280.html , sur l'augmentation de la taille des paquets ethernet, IPv4, IPv6...
De la conclusion de cet article me viennent 3 questions : - quelle importance que la taille relative des en tètes augmente ? (d'autant qu'il dit lui même que la majorité des autres paquets sont des tailles inferieures au max.) - pourquoi l'IPV6 impose t il un minimal de 1280 quand il aurait pu imposer un minima plus élevé ? - pourquoi des équipements sur la route, comme le 6erd donné en exemple, ne savent ils pas gérer des paquets plus grands, au minimum des paquets de 1500 ?
En un mot, qu'est ce qui a conduit a les concevoir ainsi ?
-- Cordialement, Az Sam.
Pascal Hambourg
[Suivi à fr.comp.reseaux.ip]
Az Sam a écrit :
"Nicolas Krebs" a écrit :
Je me permets de vous signaler l'article de Stéphane Bortzmeyer, « Fragmentation IPv6 : se résigner à couper à 1280 octets ? », 2010-11-12, http://www.bortzmeyer.org/fragmentation-ip-1280.html , sur l'augmentation de la taille des paquets ethernet, IPv4, IPv6...
De la conclusion de cet article me viennent 3 questions : - quelle importance que la taille relative des en tètes augmente ? (d'autant qu'il dit lui même que la majorité des autres paquets sont des tailles inferieures au max.)
Cela diminue l'efficacité des protocoles utilisant la taille maximum, typiquement les transferts en TCP. D'une part cela diminue le débit atteignable, et d'autre part il faut plus de paquets pour transmettre la même quantité de données, et du coup plus d'acquittements et donc encore plus de paquets au final.
- pourquoi l'IPV6 impose t il un minimal de 1280 quand il aurait pu imposer un minima plus élevé ?
C'est une marge pour intercaler d'éventuels en-têtes (encapsulation, tunnel...) entre la couche de liaison et la couche IPv6, qui diminuent d'autant la taille maximum utile.
- pourquoi des équipements sur la route, comme le 6erd donné en exemple, ne savent ils pas gérer des paquets plus grands, au minimum des paquets de 1500 ?
Gérer, ils doivent savoir : si un paquet dépasse 1480 octets, il est jeté avec envoi d'un message d'erreur ICMPv6 "Packet too big" à la source, conformément aux RFC.
Je ne pense pas que l'encapsulation 6in4 (IPv6 dans IPv4) utilisée par 6rd interdise de fragmenter les paquets IPv4 encapsulant les paquets IPv6. Mais cela augmenterait la charge des routeurs, le risque de perte de paquet (il suffit qu'un fragment IPv4 soit perdu pour perdre le paquet IPv6 tout entier), et cela dégraderait les performances puisque pour transmettre les 20 octets de données supplémentaires il faudrait générer un fragment supplémentaire avec ses en-têtes IP, ethernet soit une surcharge protocolaire largement supérieure à 20 octets... Il vaut mieux envoyer un peu plus de paquets un peu plus petits que fragmenter des paquets plus gros.
[Suivi à fr.comp.reseaux.ip]
Az Sam a écrit :
"Nicolas Krebs" <nicolas1.krebs3@netcourrier.com> a écrit :
Je me permets de vous signaler l'article de
Stéphane Bortzmeyer, « Fragmentation IPv6 : se résigner à couper à 1280
octets ? », 2010-11-12,
http://www.bortzmeyer.org/fragmentation-ip-1280.html ,
sur l'augmentation de la taille des paquets ethernet, IPv4, IPv6...
De la conclusion de cet article me viennent 3 questions :
- quelle importance que la taille relative des en tètes augmente ? (d'autant
qu'il dit lui même que la majorité des autres paquets sont des tailles
inferieures au max.)
Cela diminue l'efficacité des protocoles utilisant la taille maximum,
typiquement les transferts en TCP. D'une part cela diminue le débit
atteignable, et d'autre part il faut plus de paquets pour transmettre la
même quantité de données, et du coup plus d'acquittements et donc encore
plus de paquets au final.
- pourquoi l'IPV6 impose t il un minimal de 1280 quand il aurait pu imposer
un minima plus élevé ?
C'est une marge pour intercaler d'éventuels en-têtes (encapsulation,
tunnel...) entre la couche de liaison et la couche IPv6, qui diminuent
d'autant la taille maximum utile.
- pourquoi des équipements sur la route, comme le 6erd donné en exemple, ne
savent ils pas gérer des paquets plus grands, au minimum des paquets de 1500
?
Gérer, ils doivent savoir : si un paquet dépasse 1480 octets, il est
jeté avec envoi d'un message d'erreur ICMPv6 "Packet too big" à la
source, conformément aux RFC.
Je ne pense pas que l'encapsulation 6in4 (IPv6 dans IPv4) utilisée par
6rd interdise de fragmenter les paquets IPv4 encapsulant les paquets
IPv6. Mais cela augmenterait la charge des routeurs, le risque de perte
de paquet (il suffit qu'un fragment IPv4 soit perdu pour perdre le
paquet IPv6 tout entier), et cela dégraderait les performances puisque
pour transmettre les 20 octets de données supplémentaires il faudrait
générer un fragment supplémentaire avec ses en-têtes IP, ethernet soit
une surcharge protocolaire largement supérieure à 20 octets... Il vaut
mieux envoyer un peu plus de paquets un peu plus petits que fragmenter
des paquets plus gros.
Je me permets de vous signaler l'article de Stéphane Bortzmeyer, « Fragmentation IPv6 : se résigner à couper à 1280 octets ? », 2010-11-12, http://www.bortzmeyer.org/fragmentation-ip-1280.html , sur l'augmentation de la taille des paquets ethernet, IPv4, IPv6...
De la conclusion de cet article me viennent 3 questions : - quelle importance que la taille relative des en tètes augmente ? (d'autant qu'il dit lui même que la majorité des autres paquets sont des tailles inferieures au max.)
Cela diminue l'efficacité des protocoles utilisant la taille maximum, typiquement les transferts en TCP. D'une part cela diminue le débit atteignable, et d'autre part il faut plus de paquets pour transmettre la même quantité de données, et du coup plus d'acquittements et donc encore plus de paquets au final.
- pourquoi l'IPV6 impose t il un minimal de 1280 quand il aurait pu imposer un minima plus élevé ?
C'est une marge pour intercaler d'éventuels en-têtes (encapsulation, tunnel...) entre la couche de liaison et la couche IPv6, qui diminuent d'autant la taille maximum utile.
- pourquoi des équipements sur la route, comme le 6erd donné en exemple, ne savent ils pas gérer des paquets plus grands, au minimum des paquets de 1500 ?
Gérer, ils doivent savoir : si un paquet dépasse 1480 octets, il est jeté avec envoi d'un message d'erreur ICMPv6 "Packet too big" à la source, conformément aux RFC.
Je ne pense pas que l'encapsulation 6in4 (IPv6 dans IPv4) utilisée par 6rd interdise de fragmenter les paquets IPv4 encapsulant les paquets IPv6. Mais cela augmenterait la charge des routeurs, le risque de perte de paquet (il suffit qu'un fragment IPv4 soit perdu pour perdre le paquet IPv6 tout entier), et cela dégraderait les performances puisque pour transmettre les 20 octets de données supplémentaires il faudrait générer un fragment supplémentaire avec ses en-têtes IP, ethernet soit une surcharge protocolaire largement supérieure à 20 octets... Il vaut mieux envoyer un peu plus de paquets un peu plus petits que fragmenter des paquets plus gros.
De la conclusion de cet article me viennent 3 questions : - quelle importance que la taille relative des en tètes augmente ? (d'a utant qu'il dit lui même que la majorité des autres paquets sont des taille s inferieures au max.)
Le titre de ce fil "augmenter la taille des paquets Ethernet" est impropre. Aujourd'hui, dans les réseaux WAN, la taille des trames Ethernet peut s'élever à presque 1540 octets. Pour cela, iI faut considérer les trames PBB avec la présence de tous les tags. On doit arriver à un en-tête Ethernet de près de 40 octets.
...Auquel, il faut rajouter tous les en-têtes des protocoles au- dessous d'Ethernet.
Cordialement, Michelot
Bonjour,
De la conclusion de cet article me viennent 3 questions :
- quelle importance que la taille relative des en tètes augmente ? (d'a utant
qu'il dit lui même que la majorité des autres paquets sont des taille s
inferieures au max.)
Le titre de ce fil "augmenter la taille des paquets Ethernet" est
impropre. Aujourd'hui, dans les réseaux WAN, la taille des trames
Ethernet peut s'élever à presque 1540 octets. Pour cela, iI faut
considérer les trames PBB avec la présence de tous les tags. On doit
arriver à un en-tête Ethernet de près de 40 octets.
...Auquel, il faut rajouter tous les en-têtes des protocoles au-
dessous d'Ethernet.
De la conclusion de cet article me viennent 3 questions : - quelle importance que la taille relative des en tètes augmente ? (d'a utant qu'il dit lui même que la majorité des autres paquets sont des taille s inferieures au max.)
Le titre de ce fil "augmenter la taille des paquets Ethernet" est impropre. Aujourd'hui, dans les réseaux WAN, la taille des trames Ethernet peut s'élever à presque 1540 octets. Pour cela, iI faut considérer les trames PBB avec la présence de tous les tags. On doit arriver à un en-tête Ethernet de près de 40 octets.
...Auquel, il faut rajouter tous les en-têtes des protocoles au- dessous d'Ethernet.
Cordialement, Michelot
Nicolas Krebs
Michelot écrivit dans l'article news:
Le titre de ce fil "augmenter la taille des paquets Ethernet" est impropre.
Pourquoi ?
Michelot écrivit dans l'article
news:40a50faa-bcb6-4c03-9fed-9c20b14cbab2@29g2000prb.googlegroups.com
Le titre de ce fil "augmenter la taille des paquets Ethernet" est
impropre.