encore 'linux'... mais y'a pas que linux meme en non spécialisé...

OSEF de linux. Mais netfilter est un comparateur.

Tu penses faire mieux? Explique comment.

est cher par rapport a quoi? a un vrai CGN fourni par Cisco ?

Le NAPT 1:1 comme proposé, à l'opposé de ce que tu suggères.

tu sais combien ca coute ces trucs pour tenir du 1Gbps par client (ou ne serait-ce que pour tenir X ports de 10Gbps ) ?

Non.

bref de toute facon on est dans le spéculatif total la, autant attendre d'en savoir plus sur leur infra.

C'est marrant la spéculation.

Seulement j'ai découvert que la fibre orange ne bénéficiait pas d'IP fixe donc je reste avec mon ADSL et mes débits complètement à la ramasse.

Donc ma question d'ou vient cette info qu'Orange allait donner des IP Fixes ?

Le passage en IPv4 fixe se fait concomitamment avec le déploiement de l'IPv6 (la nouvelle architecture réseau s'appelle FBN - Flexible Backhaul Network).

C'est documenté sur ce sujet : https://lafibre.info/orange-les-news/actualites-ipv6-orange/

Le planning de déploiement :

- 100 000 clients fibre et VDSL d'ici la fin 2015
- tous les clients fibre et VDSL d'ici la fin 2016
- les clients ADSL à partir de début 2017... sans date de fin de déploiement

- la limitation de vitesse en IPv4 pourrait provenir de la Freebox (cf https://lafibre.info/free-la-fibre/vrai-1gbps-sur-freebox-v6/msg281830/#msg281830, le checksum IPv6 doit être généré en software), plus que du réseau (où le A+P ne devrait pas être trop lourd à implèmenter)

Uniquement en mode bridge il me semble, ce qui n'est pas le cas ici.

Uniquement en mode bridge il me semble, ce qui n'est pas le cas ici.

Le test en question montre que la Freebox n'arrive pas à générer des paquets IPv6 aussi vite que des paquets IPv4, et l'info donnée par mbizon est quelle ne sait pas gérer le checksum IPv6 en hardware.
Si les paquets IPv4 sont encapsulés dans des paquets IPv6, il faut ajouter un entête IPv6 et calculer le checksum à l'émission (mais ce n'est peut-être pas un problème compte tenu de la limite de l'upload à 200Mbps), mais à la réception il faut normalement le vérifier.
En 6rd, c'est différent : le paquet IPv6 est encapsulé dans un paquet IPv4 : sur un paquet reçu, le checksum IPv4 est probablement vérifié par le hardware, et peut-être que le checksum IPv6 est ignoré (si la vérification IPv6 a été faite par les routeurs, le checksum IPv4 suffit pour assurer que le paquet est à priori intègre).

En 6rd, c'est différent : le paquet IPv6 est encapsulé dans un paquet IPv4 : sur un paquet reçu, le checksum IPv4 est probablement vérifié par le hardware, et peut-être que le checksum IPv6 est ignoré (si la vérification IPv6 a été faite par les routeurs, le checksum IPv4 suffit pour assurer que le paquet est à priori intègre).

Il ne me semble pas, il parlait d'optimisation de path mais faites uniquement en mode routeur :

3) les performances en routage IPv6 seront bien meilleures en mode routeur qu'en mode bridge, je n'ai pas optimisé le path du mode bridge étant donné le très faible pourcentage de la base abonné qui l'utilise (0.0028%)

A la réception, le checksum IPv4 (qui dépend du header régénéré, et des données) doit être calculé (ce qui veut d'ailleurs dire qu'il n'apporte aucune sécurité, en 4rd on perd le checksum IP, et on se repose uniquement sur celui du protocole de niveau 4 (TCP, UDP, ...)) pour que le paquet soit ensuite accepté par le PC.

Le checksum IPv4 est bien là, donc l'intégrité des adresses et protocoles IPv4 sont toujours garanties.
C'est uniquement la longueur du paquet IPv4 qui n'est plus contrôlée, mais ce contrôle est redondant avec ceux les couches supérieures :

NOTE 1: The need to save in the IPv6 header a checksum of both IPv4
   addresses and the IPv4 protocol field results from the following
   facts: (1) header checksums, present in IPv4 but not in IPv6, protect
   addresses or protocol integrity; (2) in IPv4, ICMP messages and
   null-checksum UDP datagrams depend on this protection because, unlike
   other datagrams, they have no other address-and-protocol integrity
   protection.  The sum MUST be performed in ordinary two's complement
   arithmetic.

   IP-layer Packet length is another field covered by the IPv4 header
   checksum.  It is not included in the saved checksum because (1) doing
   so would have conflicted with [RFC6437] (flow labels must be the same
   in all packets of each flow); (2) ICMPv4 messages have good enough
   protection with their own checksums; (3) the UDP length field
   provides to null-checksum UDP datagrams the same level of protection
   after Domain traversal as without Domain traversal (consistency
   between IP-layer and UDP-layer lengths can be checked).