Dernière bizarrerie sur ces histoires de débit et charge CPU :
En local, c-a-d entre deux bridges du MkT portant chacun leur préfixe public IPv6 ou leur LAN privé IPv4, je n'ai pas vu cette limitation (speedtest web self hosted en HTML5) même si v6 semble provoquer plus de charge que v4, je sature le gigabit du MkT dans les deux cas.
Ceci-dit, je ne voyais pas non plus les connexions au niveau du firewall v6 du MkT alors que je suis sur de passer en v6 (et pas en link-local !)... 

Sinon, en ce qui concerne le bypass de la box (mais pas du MDCONU) : je comprends que cela a finalement été fait dans un thread La Fibre de Dec 2018 !
=> https://lafibre.info/remplacer-freebox/remplacer-le-boitier-onu/48/ (les post intéressants commencent à cette page mais ca part dans tous les sens...)

C'est pas encore très clair pour moi, mais voici en gros les étapes :

• Spoofer la MAC de la Box : celle du port SFP de la Freebox => compliqué de connaitre cette MAC sans matos pour faire une capture...
• Monter le lien IPv6 : configurer le port SFP avec une requête DHCPv6 sur le VLAN 836 => on devrais obtenir une IP dans le range de l'abonné (je suppute la ...XXXX:XXX0::1). On peut alors en profiter pour faire un capture et confirmer les infos pour l'étape suivante (cf détails dans réponses DHCPv6 et échanges RA/ND)
• Monter le lien IPv4 (en 4rd) : Ajouter un tunnel ipip6 sur le SFP avec l'IPv4 full stack de l'abonné et les options suivantes : Local IP = 2a01:e0a:XXXX:XXX0:0:ffff:ffff:0 avec XXXX:XXX le préfixe attribué à l'abonné, Remote IP = 2a01:e00:29:200a::fffd ou 2a01:e00:29:200a::ffff et encap limit = none

=> Bon, je vais essayer de trouver un cable SFP-SFP pour faire une capture au cul de ma box... 

Je suis pas sûr Florian : c'est peut être juste les RA...

J'ai quand même mis un ND sur le WAN mais j'ai pas l'impression que ce soit nécessaire :/ipv6 nd
set [ find default=yes ] disabled=yes
add advertise-dns=yes hop-limit=64 interface="Root bridge" managed-address-configuration=yes other-configuration=yes ra-interval=20s-1m
add advertise-dns=yes hop-limit=64 interface="Guest bridge" managed-address-configuration=yes other-configuration=yes ra-interval=20s-1m
add hop-limit=64 interface=eth1

Du coup dans les neighbors on a l'Pv6 LL de la box :/ipv6 neighbor print
Flags: R - router
 0 R address=fe80::e69e:12ff:feXX:XXXX interface=eth1 mac-address=E4:9E:12:XX:XX:XX status="stale"
(...)
Note 1 : le "stale" m'inquiétait au début, on devrais avoir "reachable"mais ca semble OK...
Note 2 : elle apparaît également sans ND sur le WAN, mais j'ai pas eu la patiente de rebooter pour purger les caches des bidouilles précédentes pour confirmer, alors je laisse le ND comme cela...

Et les routes dynamiques vers chaque préfixe :/ipv6 route print   
Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, o - ospf, b - bgp, U - unreachable
 #      DST-ADDRESS              GATEWAY                  DISTANCE
 0 ADC  2a01:e0a:XXX:XXX0::/64   eth1                            0
 1 ADC  2a01:e0a:XXX:XXX1::/64   Root bridge                     0
 2 ADC  2a01:e0a:XXX:XXX2::/64   Guest bridge                    0
=> On note qu'il ny 'a pas de gateway par défaut, mais ca fonctionne.
Coté client j'ai le préfixe (pas son IP !!) IPv6 en GW dans mes routes (clients Linux/Android configurés soit en statique soit en SLAAC avec private extensions) :# ip -6 r
2a01:e0a:XXX:XXXX::/64 dev enp0s31f6 proto kernel metric 256 pref medium
fe80::/64 dev enp0s31f6 proto kernel metric 256 pref medium
default via fe80::4e5e:cff:feYY:YYYY dev enp0s31f6 proto ra metric 1024 expires 1759sec hoplimit 64 pref medium
Certainement des packets RA qui doivent annoncer tout cela, faudrait capturer et analyser mais ca marche très bien comme ca... puis je préfère passer mon temps à creuser le bypass de la box : je verrais si y'a un cable SFP-SFP qui traîne chez les collègues du rézo au boulot pour avancer sur ce point 

Sinon, en  reconfigurant le RB941 (aka "hAP lite") qui me sert de spare et de point d'accès mobile, j'ai fini par le "flinguer" et j'ai donc fait un reset (pas un netinstall, juste un reset). A ma grande surprise il y avait des règles de firewall IPv6 par défaut que je n'ai pas eu dans le RB2011 à l'activation du package IPv6 (et j'ai pas eu le temps de voir pour le RB940  )...

J'ai donc revu mes règles et intégré quelques unes du package de base, voici ce que ca donne (sans mes règles perso) :/ipv6 firewall address-list
add address=::/128 comment="defconf: unspecified address" list=bad_ipv6
add address=::1/128 comment="defconf: lo" list=bad_ipv6
add address=fec0::/10 comment="defconf: site-local" list=bad_ipv6
add address=::ffff:0.0.0.0/96 comment="defconf: ipv4-mapped" list=bad_ipv6
add address=::/96 comment="defconf: ipv4 compat" list=bad_ipv6
add address=100::/64 comment="defconf: discard only " list=bad_ipv6
add address=2001:db8::/32 comment="defconf: documentation" list=bad_ipv6
add address=2001:10::/28 comment="defconf: ORCHID" list=bad_ipv6
add address=3ffe::/16 comment="defconf: 6bone" list=bad_ipv6
add address=::224.0.0.0/100 comment="defconf: other" list=bad_ipv6
add address=::127.0.0.0/104 comment="defconf: other" list=bad_ipv6
add address=::/104 comment="defconf: other" list=bad_ipv6
add address=::255.0.0.0/104 comment="defconf: other" list=bad_ipv6
add address=fe80::/16 list=allowed
add address=ff02::/16 comment=multicast list=allowed

/ipv6 firewall filter
add action=accept chain=input comment="INPUT : Accept established, related" connection-state=established,related
add action=drop chain=input comment="INPUT : Drop invalid" connection-state=invalid in-interface-list=WAN
add action=accept chain=input comment="INPUT : Accept ICMPv6" protocol=icmpv6
add action=accept chain=input comment="defconf : allow allowed addresses" src-address-list=allowed
add action=drop chain=input comment="INPUT : Drop everything else"
add action=accept chain=forward comment="FWD : Accept established, related" connection-state=established,related
add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid
add action=drop chain=forward comment="defconf: drop packets with bad src ipv6" src-address-list=bad_ipv6
add action=drop chain=forward comment="defconf: drop packets with bad dst ipv6" dst-address-list=bad_ipv6
add action=drop chain=forward comment="defconf: rfc4890 drop hop-limit=1" hop-limit=equal:1 protocol=icmpv6
add action=accept chain=forward comment="FWD : Accept ICMPv6" protocol=icmpv6
add action=drop chain=forward comment="FWD : Drop everything else" in-interface-list=WAN

=> Tout semble bien fonctionner comme cela : 19/20 sur https://ipv6-test.com.

Nope justement j'ai modifié le post, d'où la note "Update" au début...
=> C'était juste une route par défaut (::/0) vers l'IPv6 globale de la box en gateway.

Vu que le mode bridge déconne (perte de la connexion ipv4 quand la box fait une déco/reco), je pensais à du routeur et indiquer mon mikro comme dmz dans la box. Ca, c'est pour l'ipv4.

Par contre, au niveau de l'ipv6, quel est l'impact ? Si j'utilise toujours ton tuto, et je joue toujours avec les next hop+ra/nd , l'ipv6 devrait toujours fonctionner, non ?


EDIT : je me réponds, l'ipv6 marche toujours nickel en cas de freebox en mode routeur + dmz vers le mikrotik pour l'ipv4. Si ça reste stable, c'est un peu le meilleur des deux mondes pour mon utilisation...A suivre.

Hey : je savais pas que le mode bridge avait une feature "DMZ" !!
=> Très bonne idée : je l'ai mise en pratique dès que j'ai lu ton message, et ca tourne nickel

Et en effet :

• je n'ai plus la limitation à 30 Mb/s du mode bridge
• j'avais remarqué la perte de connectivité IPv4 de temps à autres (alors que la stack IPv6 continue de fonctionner) et identifié que seul un reboot de la box corrigeait cela, mais ne savais pas que c'était lié au mode bridge...
  

Code: [Sélectionner]

wget --show-progress -O /dev/null http://mafreebox.freebox.fr:8095/
--2019-12-08 17:32:13--  http://mafreebox.freebox.fr:8095/
Resolving mafreebox.freebox.fr (mafreebox.freebox.fr)... 212.27.38.253
Connecting to mafreebox.freebox.fr (mafreebox.freebox.fr)|212.27.38.253|:8095... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [application/octet-stream]
Saving to: ‘/dev/null’

/dev/null                    [           <=>                     ] 201.55M  72.9MB/s


=> C'est donc un peu le meilleur des deux mondes comme tu dis, sauf peut être pour l'inconfort psychologique que j'éprouve à faire du double NAT pour rien, mais bon ca corrige deux problèmes d'importance majeure...

Thanks Florian !!

Pour la partie en gras, j'ai repassé la box en mode routeur et utilisé la dmz hein, je n'ai pas bridge+dmz. Donc, ipv4 pas dmz, ipv6 de la même manière quelque soit le cas.

D'ailleurs le mode dmz vers un routeur, c'est techniquement du double nat ? 

On va pas se mentir, dans un monde idéal, que le routeur porte l'ip publique serait plus clean, mais en attendant (si jamais...) que le mode bridge soit sans bug embettant, ça marche très bien comme ça.

Du coup, j'ai fait la même chose avec mon routeur 4g, relié de la même manière à mon mikrotik, avec une gestion des routes qui fait que la connex 4g ne sera utilisée que si la fibre n'arrive plus à joindre 8.8.4.4 . On est bien. Merci encore pour ton tuto ipv6.