Mais pourquoi faire ça?
Tu peux pas diffuser le bonne MTU plutôt?
Tout simplement parce que je ne connais pas assez bien l'IPv6. J’apprends dès maintenant car je suis sûr que ce sera "hype" dans quelques années de maitriser l'IPv6
Je viens d'apprendre qu'il est possible de faire ça avec le RA, et je vous en remercie tous, je vais tester
(j'ai découvert le MSS clamping quand j'ai commencé à regarder pourquoi ça fragmente. Ça vient des explications sur le net qui concernent tous l'IPv4 et passent par le clamping....).
En tout c'est cool les forums, ça permet d'apprendre de ses erreurs afin d’éviter
ça par exemple.
J'ai rarement reçu une réponse technique d'aussi grande qualité de la part d'un abonné...
ça mérite un test, je vous tiens au courant
Ce n'est pas très qualitatif car c'est qu'un tas de données techniques bruts hors de tout contexte. Mais au moins j'étais sûr que vous comprendrez, ou qu'au moins vous saurez qui pourrait comprendre...
le 6161 c'est le switch, le 6281 c'est le kirkwood
bon c'était trop beau.
pour connaître la taille de TCP + DATA afin de faire l'opération de checksum, le hardware se sert du total_length IPv4.
Au même endroit dans l'IPv6 il y a le flow label, généralement à 0. Dans ce cas çà donne une taille négative et ça checksum aléatoirement n'importe quoi.
en patchant le flow label pour chaque paquet pour émuler total_length cela fonctionne parfaitement, mais vous serez d'accord que ce n'est pas une bonne idée.
Dure de trouver la spec du 6161, mais ils doivent tous beaucoup se ressembler n'est ce pas ?
Bon, sinon je pensais que le CRC se basait sur le champs "byte_count" du descripteur (et pas de l'entête IP). Tant pis.
Après s'il y a un loopback qui le permet, rien n’empêche de passer le paquet 2 fois, une fois juste pour le calcul du CRC, la seconde fois pour le transmettre. Mais bon, au final c'est complexifier le code pour bien peu de chose: au final seul le test débit local sera limité en IPv6
Je ne pense pas que les CRC sont recalculés pendant le "routage" du l'IPv6.
de 20 octets
Et dire que je râle sur le 6rd justement à cause de ces 20 octets... Il me semble qu'en utilisant le VC/Mux en ADSL, Free propose le meilleurs débit en ADSL justement parce que le VC/Mux permet de gagner quelques octets dans les entêtes ATM (bon OK, les entêtes ATM représentent un plus gros pourcentage sur une trame de 1500 octets). Et là on jette en pâture 20 octets/1500 quand on utilise l'IPv6 (en plus de "complexifier" le paramétrage d'un routeur en IPv6 derrière la box, ou du 6rd d'un modem pour supporter l'IPv6). Dommage...