De toute manière, à mon avis ils ont certainement laissé un NAT au niveau de la freebox. Ça leur simplifie pas mal la tâche.

Je crois qu'il va falloir attendre encore un peu pour comprendre ce que veut dire "variante fait maison".
C'est pas forcèment simple en vrai. Si tu fais bien un double NAT comme ce que je pense, ça peut être pas trop compliqué.

Si tu commences à mettre à plusieurs endroits la même IP... la ça me semble déjà beaucoup plus poilu. Et source d'emmerde en pagaille.

Je pense que soit ils passent par IPv6, soit il y a bien un double NAT.
IP publique partagée <=> IP privée Free assignée à la Freebox <=> LAN
Je pense que la Freebox affiche l'IP publique pour ne pas perturber l'utilisateur (et peut-être qu'elle la donne via UPnP, et qu'elle remonte les demandes de redirection de port), mais elle ne travaille qu'avec son IP privée.

Je pense que soit ils passent par IPv6, soit il y a bien un double NAT.
IP publique partagée <=> IP privée Free assignée à la Freebox <=> LAN
Je pense que la Freebox affiche l'IP publique pour ne pas perturber l'utilisateur (et peut-être qu'elle la donne via UPnP, et qu'elle remonte les demandes de redirection de port), mais elle ne travaille qu'avec son IP privée.

c'est pas dit. Rien n'empeche d'avoir plusieurs Freebox avec la meme IP public du moment qu'elle arrivent toutes sur le meme equipement qui fait le pseudo CGN (qui lui gerera ca avec les adresses MAC). Il suffit que les switches entre les box et cet equipement gerent spécifiquement les broadcast arp pour eviter tout probleme (les switches ne voyant pas les IP de toute facon).

Tout le monde parle de NAT et CGN mais c'est pas forcement comme ca que cela marche. La personne de Free a mentionné explicitement le découpage en 4 zones des numéros de ports (on parle des ports ephemeres pour le retour des connections UDP et TCP).

Donc il se peut que les Freebox ne sachent meme pas qu'elles partagent leur IP. Chacune fait son NAT habituel sur son IP public. C'est completement transparent pour les Freebox.
C'est plus haut qu'a lieu a nouveau une translation de ports mais sans changer d'addresse: les ports sont mappés sur le 1/4 réservé a chaque box. L'equipement qui fait cela connait les 4 addresses MAC des 4 box, sait qu'ils ont la meme IP et suit leurs flux TCP et UDP et adapte les ports en conséquence. si c'est fait maison ca peut etre tres performant. Ca peut donc tres bien etre comme ca. On n'a juste rien pour ouvrir publiquement un port, sauf si Free a prévu le coup mais je ne pense a cause des conflits 'humains' possibles (comme a dit Marin: "Le port 80 est attribué à celui qui a la fève ?").

Ce que tu dis sur le "partage" me parait compliqué en terme réseau. Ca voudrait dire que tu affectes à plusieurs endroits différents la même adresse IPv4 publique. En terme de pure routage, ça veut dire que tu route sur le couple @ip+Port-Destination (ça me parait très chiant, mais pas impossible). Et d'un point de vue niveau 2, c'est le bordel à géré, car c'est juste un pur conflit d'adresse.

Plus compliqué que ça?

layer3+4

      This policy uses upper layer protocol information,
      when available, to generate the hash.  This allows for
      traffic to a particular network peer to span multiple
      slaves, although a single connection will not span
      multiple slaves.

      The formula for unfragmented TCP and UDP packets is

      hash = source port, destination port (as in the header)
      hash = hash XOR source IP XOR destination IP
      hash = hash XOR (hash RSHIFT 16)
      hash = hash XOR (hash RSHIFT
      And then hash is reduced modulo slave count.

      If the protocol is IPv6 then the source and destination
      addresses are first hashed using ipv6_addr_hash.

https://www.kernel.org/doc/Documentation/networking/bonding.txt

Peut être qu'en bidouillant avec des tunnels non basé sur ethernet tu peux arriver à qqch... Enfin ça me semble hyper bancal. Et le CGN, c'est pas ça (d'après moi)

Pardon mais le truc bancal par excellence est le NAT et le suivi de connexions en général. Tu as vu la quantité de code pour la gestion de ce truc dans linux?

Si la Freebox n'est pas au courant, elle peut choisir n'importe quel port dynamique, et il faut toujours une table entre les ports publics et ceux vus par la Freebox. Dans ce cas quel est l'intérêt de réserver précisèment 1/4 des ports (à part que c'est plus simple que de faire une répartition dynamique en fonction des besoins) ?
Si la Freebox se restreint dans les ports dynamiques, alors la translation devient bien plus simple : à part les ports ouverts publiquement à gérer éventuellement, une plage de port correspond à une Freebox, et est envoyée telle quelle (ou avec un décalage).

"précisèment 1/4 des ports", peut-etre pour des raisons de performance , plus rapide qu'une gestion dynamique. Cet 'equipement' doit gerer plein de freebox et des flux a tres haut débit, ca doit vraiment speedé et etre opti. En reservant un 1/4 fixe on garanti aussi que les 3 autres ne generont pas meme s'il est rare voir impossible de saturer vu le nombre de ports ephemeres dispo .

Je ne pense pas qu'ils changent le code des Freebox, ca complexifierait le code des freebox pour rien (testing, bugs, regression, etc).
En plus quelqu'un peut tres bien remplacer la freebox par son routeur qui lui ne choisira pas forcement les ports dans le bon 1/4. ca donc doit être fait plus en amont.

mais tout cela reste des suppositions, on n'en saura plus avec le temps.

Je ne vois pas bien comment vu que tu dois faire un NAT complet sauf que l'adresse ne change pas ce qui ne doit quasiment rien changer dans le code.

je ne comprend rien a cette phrase.

Donc UPnP IGD n'existe plus?

A priori oui. comment veux tu ?
ou alors premier arrivé, premier servi.
ou restriction a une plage de port imposée par Free ("vous pouvez utiliser UPnP IGD pour les port entre X et Y").

Je ne pense pas qu'ils changent le code des Freebox, ca complexifierait le code des freebox pour rien (testing, bugs, regression, etc).
En plus quelqu'un peut tres bien remplacer la freebox par son routeur qui lui ne choisira pas forcement les ports dans le bon 1/4. ca donc doit être fait plus en amont.

Effectivement, ça aurait l'avantage de rester compatible avec les routeurs.
En FTTH ZMD je ne pense pas que ça concerne beaucoup d'abonnés (routeur avec SFP, ou SFP+), mais ça a du sens s'ils veulent appliquer la même logique en ADSL.
Mais l'équipement se retrouve obligé de faire du suivi de connexion (TCP, UDP, et éventuellement des protocoles applicatifs comme FTP, SIP, ...),  sur un grand nombre de Freebox, est-ce que c'est faisable avec des performances correctes ?