0,0028% ? Je pensais qu'il y en aurai plus. Si on part sur 140 000 clients Free FTTH, cela fait.... seulement 392 clients !

c'était 0.28% en fait mais ton chiffre est le bon

cette stats est sur l'ensemble des v6 toutefois (FTTH + xdsl), il y a peut être plus de gens en bridge en FTTH qu'en xdsl

c'était 0.28% en fait mais ton chiffre est le bon

cette stats est sur l'ensemble des v6 toutefois (FTTH + xdsl), il y a peut être plus de gens en bridge en FTTH qu'en xdsl

Oui, parce que le mode (soi-disant) "bridge" est vraiment limité et celui que des précédentes Freebox était mieux!

Avant des optimisations, je pense que les freenautes voudraient des fonctionnalités.

Oui, parce que le mode (soi-disant) "bridge" est vraiment limité et celui que des précédentes Freebox était mieux!

sachant que c'est le même code...

la seule différence sur la v6 est qu'il n'y a pas de wifi sur le mode bridge, le but étant de mettre un routeur à l'arrière.

Avant des optimisations, je pense que les freenautes voudraient des fonctionnalités.

donnez les liens du bugtracker concernant les features demandées sur le mode bridge

sachant que le 6RD est fait par la freebox, je ne vois pas ce que ça change pour l'abonné

on passerait en natif en gardant les même préfixes, personne ne verrait la différence.

la MTU plus basse à l'heure de l'IPv6 n'est plus un problème, car annoncée par RA.

Est-ce que le MTU serait plus grand en natif ?
Est-ce que le 6RD utilise beaucoup de CPU ou est-il accéléré en hardware ? Ce qui pourrait impacter les débits en IPv6 par rapport à l'IPv4.

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...

Tout simplement parce que je ne connais pas assez bien l'IPv6.

En réalité, à part l'ajout des adresses routables autoconf (l'autoconf n'existait en IPv4 qu'en local non-routable : adresse APIPA), IPv6 ressemble à IPv4.

En IPv4, tu peux utiliser un tunnel sur IP exactement comme 6in4 utilisé chez Free : le 4in4.
En IPv4, tu peux annoncer la MTU aussi bien en DHCP qu'en PPP.

La MTU sera enregistrée par le composant IP qui va la transmettre aux couches UDP, TCP...

J’apprends dès maintenant car je suis sûr que ce sera "hype" dans quelques années de maitriser l'IPv6

C'est déjà "hype"!

C'est facile parce que les concepts IPv6 sont proches ou équivalents à ceux de IPv4 raisonnable (donc sans le NAT pour économiser les adresses).

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....).

Le MSS ne concerne que TCP, il n'y pas que TCP pour les communications client-serveur dans la vie. Et Google Chrome remet à l'honneur UDP pour surfer sur le Web.

Fixer la MTU dans par interface ou bien la table de routage concerne tous les protocoles.

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...

Il y a aussi le critère de "pureté".