J'aime pas trop cette approche SPOF: si ce serveur tombe, tout tombe dans la maison.

D'un côté, si ta box tombe aujourd'hui, plus rien ne fonctionne non plus ?

J'aurais quelque chose de similaire à faire, je partirai sur l'option 2. Serveur que tu mets en DMZ et qui potentiellement sera le premier et seul à bouffer.

Tu as pas mal de posts au sujet du remplacement de l'ONT par un routeur avec le SFP à l'intérieur. Globalement, ça semble plus ou moins compliqué en fonction du type de fibre que tu as. Tu as déjà gratté la dessus ?

Quelques mois plus tard,
- j'ai acheté un TPLink MC220L pour connecter l'ONT de mon abonnement free fibre (ZMD 10G EPON) en direct
- vers un futur routeur à base de NanoPi R4S + OpenWrt.

Ce que j'ai fait pour le moment:

1- j'ai compris que chez Free on est soit:
  * dans une situation Free fibre en ZMD (mon cas), on a une connectivité IPv6 de base + encapsulation des paquets IPv4 dans l'IPv6 = 4rd.
  * soit avec un setup 'inverse' en ZTD (pas mon cas): une connectivité IPv4 de base + encapsulation des paquets IPv6 dans l'IPv4 = 6rd (?)

2- j'ai découvert OpenWrt avec l'image FriendlyWrt proposée sur friendlyarm.com

3- j'ai lu avec attention le post ici-même de clecle26 (merci à lui) pour un setup openWrt sans freebox, avec une IP (full stack) + 0.25 IP
    * + l'article de son blog: https://liberty.noknow.ovh/article/NoBox-Free
    * perso, mon objectif n'est d'avoir que l'IP full-stack, ça me suffira

3b- même lecture attentive du tuto pour Ubuquity: Tuto: Remplacer sa freebox (non Delta) par un routeur Ubiquiti en ZMD (10G-EPON)

4- j'ai compris qu'il me faudrait comme infos:
    * mon IPv4 full stack (visible dans l'interface "mafreebox.freebox.fr > Etat de la box" et/ou dans mon compte abonné sur free.fr)
    * de mon adresse MAC ; pas trouvé d'étiquette sur ma freebox, la seule que je connaisse est celle visible dans l'interface "mafreebox.freebox.fr > Etat de la box" (F4:CA:XX:XX:XX:XX)
    * de mon prefixe IPv6 (2a01:xxxx:xx:xxxx::/64)
    * d'une IP locale, forgée avec mon préfixe IPv6 + suffixe ":0:ffff:ffff:0"
    * l'IPv6 du border router côté free ? il vaut apparemment toujours "2a01:e00:29:200a::fffd"

5- pour OpenWrt, j'ai compris qu'il me faudrait installer le package 'map' pour le 4rd (besoin only pour l'IPv4 ou pour l'IPv6 aussi ?)
    * or l'image FriendlyWrt fournie ne contient pas les dépendance nécessaires => besoin de compiler mon propre OpenWrt.
    * sur le forum OpenWrt le 'work in progress' pour le support du NanoPi R4S dans OpenWrt

7- j'ai buildé mon image openWrt pour le NanoPI R4S
    * le fork d'openWrt incluant le WiP pour le NanoPi R4S: https://github.com/1715173329/openwrt-official/tree/nanopi-r4s (en attente de PR)
    * j'ai donc compilé mon image et je l'ai installée sur mon nanoPi R4S, en incluant le  packet "Network ---> map"
    * (pas bloquant mais) il faudra que je "use r8168-8.048.03 realtek kernel module(much better than r8169)" + repo GitHub pour le module kernel openwrt-r8168,
      => je ne sais pas encore comment on intègre ça au moment du build (si quelqu'un a un tuto / l'explication, je prends).
    * j'ai fait un premier setup de base pour mon LAN (= remplacer le DHCPv4 fourni jusqu'ici par la freebox server par celui sur l'interface lan de mon openWrt)

8- j'ai fait une première tentative de setup du wan juste pour l'IPv6 déjà
    * j'ai compris que côté wan, il faudrait passer par le VLAN 836
    * il me faudrait donc définir une nouvelle interface eth0.836 et la mettre en 'client DHCPv6'
    * pour que la requête DHCP soit acceptée, besoin de MAC spoofing avec la MAC de la freebox ci-dessus

MAIS ma config ne marche pas en l'état (EDIT: ça a changé, cf ci-après)
- je vois quelques paquets RX et TX dans LuCi, et un root@openwrt:~# ping6 google.com plante.
- le tuto de clecle26 parle de modifier dans /etc/config/network une "config switch_vlan" existante mais la section 'switch_vlan' n'existe pas du tout chez moi ; la page 'Switch' dans LuCi non plus

=> est-ce parce que je n'ai pas un "VLAN-enabled switch hardware" ?

=> si je définis simplement mon interface en "eth0.836", ça devrait passer crème ? Quelque chose dans ce style ?
config interface 'wan6'
option ifname 'eth0.836'
        option proto 'dhcpv6'
        option reqprefix 'auto'
        option reqaddress 'try'
        option macaddr 'F4:CA:XX:XX:XX:XX'
        option mtu '1700'
        list dns '2001:4860:4860::8888'
        option peerdns '0'
=> avec quoi en plus / en moins ?
=> on est d'accord qu'au stade 'stack IPv6 only', on n'a pas (encore) besoin de 'map', qui sert à l'encapsulation IPv4 dans IPv6 (4rd) ? EDIT: oui
=> suis-je censé renseigner où l'IPv6 du border router côté free ? où ça ? EDIT: non, pas besoin
=> suis-je censé renseigner quelque part mon IPv6 locale, forgée avec mon préfixe IPv6 + suffixe ":0:ffff:ffff:0" ? EDIT: non, pas besoin

Bref, beaucoup d'interrogations à ce stade, je suis un peu paumé, toute aide serait la bienvenue.

Bon ... ça marche maintenant ... mais je ne sais pas pourquoi 

J'ai fini par recompiler une nouvelle image incluant tcpdump pour faire du wireshark en remote ssh (depuis mon desktop).
Je lance alors une session wireshark, et là surprise: je vois plein de traffic !

Un refresh de la page LuCi lus tard, et à ma grande surprise: wan6 a enfin attrappé une IPv6 et j'ai mes deux nouvelles interfaces de map:
- WAN6_4_ (eth0.836)
- WAN6_4 (map-wan6_4) qui a attrappé une IPv4 'shared' 91.161.x.y

Il semblerait que l'activation du mode promiscuous quand je lance la session wireshark soit à l'origine de la solution.
Quelques tests plus tard, et effectivement: il me suffit d'activer le promiscuous sur eth0 pour que tout démarre comme par magie:
root@OpenWrt:~# ifconfig eth0 promisc

J'ai trouvé sur le forum d'openWrt un post relatant le même problème, sans qu'aucune explication ni solution ne soit fournie: IPv6 works only with wan in promiscuous mode

Bref, j'ai une connectivité IPv6 + IPv4 (partagée) qui fonctionne, je ne sais pas vraiment ni pourquoi ni comment.
Le souci initial serait-il dû à un problème de driver (cf. le "use r8168-8.048.03 realtek kernel module(much better than r8169)" de mon post précédent) ?

Un premier bench avec ce NanoPI R4S + un iperf3 donne:
iperf3 -c ping6.online.net -p 5200 -i 0 -t 60
Connecting to host ping6.online.net, port 5200
[  5] local 2a01:e0a:69:xxxx:xxxx:xxxx:xxxx:xxxx port 48306 connected to 2001:bc8:1::40 port 5200
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-60.00  sec  2.90 GBytes   415 Mbits/sec  290    453 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-60.00  sec  2.90 GBytes   415 Mbits/sec  290             sender
[  5]   0.00-60.00  sec  2.89 GBytes   414 Mbits/sec                  receiver

Sur les 6 cores du Rockchip 3399, les n°5 et 6 (les deux seuls à monter en charge) se stabilisaient aux alentours de 50% pour le premier, 55% pour le second.

merci pour ton feedback.

J’arrive trop tard de toute évidence, mais pour le VLAN: je sais pas le pourquoi du comment exactement, mais le VLAN logiciel n’est pas toujours présent par défaut.

Ma compréhension de l'histoire du switch_vlan (en tant que noob) semble bien reliée aux capacités du hardware sous jacent: certains matériels intègrent du hardware capable de jouer le rôle de switch entre différents ports physiques ; cela sans doute pour décharger le CPU principal de cette charge de travail (et donc avoir un routeur avec un CPU minuscule capable pourtant de switcher du Gb/s).

J'imagine que ce genre de 'switch' hardware se trouve dans du matos 'spécialisé' pour gérer du trafic réseau (un routeur/AP WiFi, genre le Xiaomi).  (*)

Dans ce cas de 'switching géré en hardware', il faut bien informer le hard sous-jacent que tel ou tel port doit tagger/détagger tel ou tel VLAN, d'où, j'imagine, la config additionnelle que tu présentes dans ton billet. Dans mon cas, avec le nanoPI, on est plutôt sur du hardware type 'ordi à vocation généraliste', donc sans ce genre de switching hardwareintégré.

Et donc avec mon nanopi, je n'ai pas eu ce besoin de configurer un 'switch hardware' qui n'existe pas ; eth0.836 dans mon wan6 +  mon firmware compilé avec 'map' inclus ont suffit pour faire fonctionner l'IPv6 + l'IPv4 partagée (modulo mon souci de promiscuous mode à set manuellement).

Tu as finalement réussi à accrocher l’IP full-stack?

J'ai fait une première tentative avec le patch de map.sh que tu as partagé (seconde version, pour la full stack only = celle qui fait un 'exit 1' sur le cas "::ffff")

J'ai manifestement un souci avec cette config: le CPU est à 30% en IDLE (<1% normalement) et j'ai eu la vague impression en faisant un htop que le script map.sh était ré-exécuté sans cesse.

Un rapide bench m'a alors confirmé qu'il y avait un souci, avec un download intermittent, et <3Mb/s de débit (là où j'ai 500Mb/s avec l'IP partagée).

Il était tard hier, j'ai fini par capituler, mais ce n'est que partie remise.
Si tu as une piste à explorer, je suis preneur.



(*) EDIT: ceci corrobore mon assertion: "Many embedded devices with more than 1 port contain a VLAN-capable switch (all routers with a WAN port have a VLAN-capable switch for example). Single-port devices and devices where there is an ethernet controller for each port (like for example PCEngines boards or most PC hardware in general) will have VLAN managed by OS drivers."

Un début de réponse: logread me sort les 3 lignes suivantes en boucle 20x par seconde:
Mon Feb 22 19:25:35 2021 daemon.notice netifd: Interface 'wan6_4' is setting up now
Mon Feb 22 19:25:35 2021 daemon.notice netifd: wan6_4 (31467): Interface wan6_4_ not found
Mon Feb 22 19:25:35 2021 daemon.notice netifd: Interface 'wan6_4' is now down

avec:
1) l'ajout dans map.sh:
        [ -z "${RULE_DATA##*2a01:e00:29:200a::fffd*}" ] && sed -i "s/RULE_1_IPV6ADDR=.*/RULE_1_IPV6ADDR=${ip6prefix%?}0:ffff:ffff:0/" /tmp/map-$cfg.rules
        [ -z "${RULE_DATA##*2a01:e00:29:200a::ffff*}" ] && exit 1
        RULE_DATA=`cat "/tmp/map-$cfg.rules"`

2) mon /etc/config/network:
config interface 'lan'
        option type 'bridge'
        option ifname 'eth1'
        option proto 'static'
        option ip6assign '60'
        list dns '8.8.8.8'
        list dns '8.8.4.4'
        list dns '9.9.9.9'
        option ipaddr '192.168.0.254'
        option netmask '255.255.255.0'

config device 'lan_eth1_dev'
        option name 'eth1'
        option macaddr YY:YY:YY:YY:YY:YY'

config interface 'wan'
       option ifname 'eth0.836'                 # L'interface sur laquel le tunnel va communiquer
       option delegate '0'                      # On desactive l'integration de l'IPv6 automatique sur cette interface, car on est en IPv4
       option tunlink 'wan6'                    # On remet l'interface sur laquel il communique
       option proto 'map'                       # Le protocole
       option type 'map-e'                      # Le sous-protocole (map-e pour nous, pas lw6over4)
       option peeraddr '2a01:e00:29:200a::fffd' # L'adresse du tunnel cote serveur
       option ipaddr '82.xx.xx.xx'              # L'ip full stack qui vous a ete attribue et qui se trouve sur votre espace client
       option ip4prefixlen '32'                 # Le prefixe de l'IP
       option ip6prefix '2a01:xxxx:xxxx:xxxx::'    # la plage/prefix IPv6 fournie par Free
       option ip6prefixlen '60'                 # La longueur du prefix
       option mtu '1500'                        # 1500, pour etre en dessous de l'IPv6 a 1700
       option encaplimit 'ignore'               # pas d'encapsulation limit
       option defaultroute '1'                  # definir comme route par defaut
       # defini, le nombre de port attribues, rang, etc... ici pour du full-stack.
       option ealen '32'
       option psidlen '1'
       option offset '16'
       option psid '65535'

config interface 'wan6_4'
        option delegate '0'                     # Pas d'IPv6
        option defaultroute '0'                 # On ne definit pas comme route par defaut
        option proto 'static'                   # On lui dit que c'est une adresse static(le protocole map s'occupera de faire le lien)
        option force_link '0'                   # pas besoin de forcer le lien
        list ipaddr '91.yy.yy.yy/32'            # Votre adresse IP ephemere.


config interface 'wan6'
        option ifname 'eth0.836'                # Correspond au num..ro de l'interface dans le routeur g..n..ralement 0 pour le WAN, parfois 1 suivi du vlan de Free.
        option proto 'dhcpv6'                   # correspond au protocole. Ici, du dhcpv6 standard.
        option reqprefix 'auto'                 # On le laisse demander la plage IPv6 obtenu (normalement un /60)
        option reqaddress 'try'                 # On laisse en try pas besoin de forcer la requete
        option macaddr 'XX:XX:XX:XX:XX:XX'      # On change l...adresse MAC du routeur pour celui de la freebox
        option mtu '1700'                       # On augmente le mtu standard, pour avoir un tunnel plus grand en IPv4
        list dns '2001:4860:4860::8888'         # On attribue les dns IPv6 de google. (optionnel), c...est juste le temps d'avoir un internet fonctionnel le temps de hijacking le dns (si vous le souhaitez)
        option peerdns '0'                      # On refuse les dns proposer par Free (il pue un peu la m****e), mais vous pouvez toujours les autoriser si vous le souhaiter.

Les interfaces dans LuCi ressemblent au screenshot ci-après en configuration avec 'wan6' seulement, et pas de path de 'map' (donc avec l'ip shared only):

Quelques tests faits ce soir:
- j'ai recompilé la version FriendlyWrt pour le nanopi 4s avec le support de map (et kernel 5.10)
- pas la moindre amélioration concernant mon interface WAN qui ne voit pas les paquets taggués VLAN 836 tant que je ne passe pas eth0 en mode 'promiscuous'

J'arrive à accrocher mon IP full stack, mais ça semble dans les mêmes conditions qu'avec openWrt:

 * toujours les même logs incessants de netifd, qui semble setup puis kill 'wan_6_4' en boucle, faute de trouver 'WAN6_4_'

 * une charge CPU élevée en idle, c'est bien netifd qui mange le temps CPU (cf screenshots d'un htop ci-dessous: en haut avec netifd ; en bas avec netifd killed).

 * j'atteins avec mon IPv4 Free full stack (82.x) les 600mb/s sans trop sourciller sur un iperf3 vers un de mes serveurs dédiés (51.x).
Accepted connection from 82.xx.xx.xx, port 54322
[  5] local 51.xx.xx.xx port 5201 connected to 82.xx.xx.xx port 54324
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-1.00   sec  59.0 MBytes   495 Mbits/sec                 
[  5]   1.00-2.00   sec  69.8 MBytes   585 Mbits/sec                 
[  5]   2.00-3.00   sec  69.9 MBytes   586 Mbits/sec                 
[  5]   3.00-4.00   sec  70.1 MBytes   588 Mbits/sec                 

A noter que si je supprime le patch dans map.sh (je n'ai plus possibilité d'avoir ma full stack mais) je n'ai plus les logs incessants.
il y a peut-être quelque chose à améliorer de ce côté là ?
        [ -z "${RULE_DATA##*2a01:e00:29:200a::fffd*}" ] && sed -i "s/RULE_1_IPV6ADDR=.*/RULE_1_IPV6ADDR=${ip6prefix%?}0:ffff:ffff:0/" /tmp/map-$cfg.rules
        [ -z "${RULE_DATA##*2a01:e00:29:200a::ffff*}" ] && exit 1
        RULE_DATA=`cat "/tmp/map-$cfg.rules"`
- Le 'exit 1' du patch ne serait-il pas trop brutal pour netifd ?
- N'y aurait-il pas possibilité de le laisser aller jusqu'au bout du map pour l'IP shared, quitte à lui rajouter une option pour la forcer en down ?