Oui effectivement mon raisonnement n'est valable que si routeur et serveur DHCP sont sur la même machine, en IPv6.

Pour ceux que cela pourrait intéresser, j'ai réalisé une feuille de calcul pour obtenir simplement la chaîne de caractères nécessaire à la mise en place de l'option DHCP 121, pour la distribution de routes en IPv4 par DHCP, sans nécessiter un protocole de routage. Elle a un intérêt pratique mais surtout didactique, j'y ai intégré notamment quelques aspects pratiques relatifs à l'utilisation de cette option (peu connue) avec Windows et Linux.

https://www.stonerecording.art/createur-de-chaines-pour-loption-dhcp-121/

J'avais également utilisé cette possibilité sur mon réseau avant de finalement utiliser RIPv2, pour lequel il existe un client Windows assez ancien (Qbik Ripv2). Il fonctionne toujours sous Windows 10. Finalement c'est plus simple et c'est dynamique. Pas besoin de modifier l'option 121 si une nouvelle route doit être diffusée.

L'option 121 a surtout un intérêt pour diffuser un petit nombre de routes qui ne changent que rarement. Elle peut éviter la mise en place d'un protocole de routage et de ses clients. On peut l'utiliser sur un LAN avec des PC, mais il y a peut être quelques autres utilisations possibles. Je n'ai jamais essayé entre routeurs, cela fonctionne peut être.

A noter que chez Mikrotik avec RouterOS 7 il est désormais possible de spécifier des routes dans une une réservation d'adresse DHCP. Je n'ai pas encore essayé mais je suppose que cela génère automatiquement cette chaîne et l'option 121. Pour le moment c'est limité à une réservation d'adresse, on ne peut pas définir une liste de routes pour un network, à moins de définir et spécifier manuellement une option 121.

Je ne crois qu'il soit nécessaire de modifier la L2 MTU, elle est implicite et s'ajuste en fonction (je me demande si c'est possible d'ailleurs). Si le chip du routeur ne prend pas plus de 1500 en L3 (donc 1518 L2) le paquet sera rejeté de toute façon et tu vas sans doute avoir une erreur si tu essaies de set la L3 à plus de 1500 (j'ai le cas sur un vieux raspbery pi).

En théorie, tout doit être automatique puisque Free annonce la MTU dans les RA, fixée à 1700 L3. Le WAN ne se configure pas tout seul ? Un cas à tester sur mon LAB tiens.

Bonjour Mikrotik,

Saurais-tu partager ta configuration, car j'ai commencé à regarder celle de certains autres fils, mais elle me semble incomplète.
Par exemple, modifier le MTU n'est pas suffisant, car sans effet si on ne modifie pas le L2 MTU. Combien de plus, 8 bits? Pour les vlan quel MTU?
Bref, un bon petit partage de conf pour les adorateurs de Mtk serait top. Je suis aussi en 7.14 beta (qui ne corrige toujours pas mon problème actuel)

Merci d'avance.

Stéphane.

Pour la config avec un routeur Mikrotik, je donne les grandes lignes (une config routeur, ça se mérite .

Pour ceux qui ne se sentent pas capable de réussir cette configuration à partir des informations données ici, je leur conseil d'apprendre et de se documenter sur IPv4, IPv6 et RouterOS pour arriver au niveau requis, sous peine de créer des problèmes de sécurité sur leur installation, voir vers l'extérieur, ou d'encombrer le support Free qui de toutes façons ne prendra pas en charge la demande avec un routeur tierce.
Ne pas oublier également que rien ne garantit que cela fonctionnera dans le futur, même si on peut supposer (et fortement espérer) que Free ne se coupera pas de ses clients passionnés qui ont aussi permis son succès.

Prérequis : une Freebox avec un boitier ONTv2 externe, demander et obtenir une adresse IP full stack. Un routeur puissant, au moins un RB5009 pour obtenir un débit proche du maxi, upgradé en RouterOS 7.15 (version testée ici), upgrader également le firmware dans le menu system/routerboard. Config testée sur RB5009, et partiellement sur RB3011. Même avec un RB5009, le tunnel MAP-E saturera un cœur de processeur au débit maxi. Malheureusement ces tunnels, comme les autres tunnels d'ailleurs, ne sont pas accélérés en hardware sur les routeurs Mikrotik (ni probablement sur tous les autres routeurs dans la gamme SOHO chez les autres fabricants).

Pour IPv6 :

1) Vérifier la configuration du Firewall pour éviter tout risque. Autoriser l'ICMPv6, et le DHCPv6 (udp 546) pour les adresses sources fe80::/10 en input.

2) Changer l'adresse MAC de l'interface SFP pour celle de la FreeBOX (à récupérer sur l'étiquette de la Freebox ou sur l'interface web), ne peut se faire qu'en ligne de commande. Aide disponible dans l'aide RouterOS.

3) Si le SFP est dans un bridge, le retirer du bridge. Vérifier que le lien monte (link ok) lorsque le câble DAC en provenance du boitier ONTv2 est branché sur le port SFP du routeur. S'il ne monte pas, c'est probablement un problème d'autonégociation. Retirer les options autres que 1G BaseX dans l'autonégociation. On peut laisser tout ce qui est en 1G, 2.5G, 5G, 10G sans normalement que cela ne pose de problème. Si le lien ne monte pas, ce n'est pas la peine d'aller plus loin. Problème avec la fibre, le boitier ONTv2, le câble DAC, éventuellement un problème de compatibilité SFP.

4) Passer le L2MTU du SFP à 1704 puis le MTU à 1704.

5) Ajouter une interface vlan 836 sur l'interface SFP avec un MTU à 1700. Mettre l'interface vlan 836 dans la liste des interfaces WAN (pour simplifier la reconfiguration du Firewall lors de changements de configuration éventuels). L'interface SFP parente n'a pas besoin d'être dans cette liste. Vérifier que les règles du firewall utilisent bien cette liste d'interfaces au lieu de l'interface VLAN 836 en elle-même.

6) Ajouter un client DHCPv6, avec demande d'adresse seulement, sur l'interface VLAN 836. Ne pas cocher "Request Info" ni "prefix". Cocher "Use Interface DUID" et "Add default route". On doit obtenir une IPv6 globale dans un préfixe autre que le /60 délivré par Free. Cette adresse semble ne pas servir, tout du moins avec un routeur. On obtient donc aussi une route dynamique par défaut vers l'adresse link-local de l'équipement Free en face. Cette requête DHCPv6 est obligatoire pour ouvrir la connectivité Internet, y compris pour avoir accès au border router MAP-E. Une configuration manuelle sans DHCPv6 ne fonctionnera pas. Pour faire comme la Freebox, on peut éventuellement ajouter une option 6 dans la requête, avec en valeur 0x0017005e pour demander les DNS et l'adresse du border router MAP-E. Mais ce n'est pas utile, juste éventuellement intéressant pour observer la réponse dans Wireshark. En plus, l'adresse de Border Router MAP-E fournie par la réponse DHCPv6 n'est pas celle du serveur BR pour les IPv4 full stack, mais celle du serveur pour les IP partagées
Si on veut utiliser le DNS IPv6 Free, cocher "Use Peer DNS", sinon ajouter un serveur DNS IPv6 custom dans le menu IP/DNS.

A partir de là, on doit avoir une connectivité IPv6 au moins depuis le routeur.

Edit : j'ai du ajouter un script de démarrage pour stopper et relancer le serveur DHCPv6 au reboot du routeur, sinon perte de connectivité.
Il semble que le problème se produit uniquement si l'interface VLAN 836 est montée sur un Bridge Vlan aware, ce qui est mon cas. C'est probablement un bug sur RouterOS. Le problème provient de la route par défaut qui est corrompue après reboot.
-------------------------------------------------------------
add name="DHCPv6 restart" on-event=\
    "delay 2\r\
    \n/ipv6/dhcp-client/disable numbers=0\r\
    \ndelay 3\r\
    \n/ipv6/dhcp-client/enable numbers=0\r\
    \n" policy=ftp,reboot,read,write,policy,test,password,sniff,sensitive,romon start-time=startup
-------------------------------------------------------------

Une autre solution : mettre la route par défaut en statique, et décocher "Add default route" dans le client DHCPv6.

7) Pour chaque interface LAN, ajouter une adresse IPv6 dans un préfixe /64 issu du /60 délivré par Free (16 préfixes disponibles

Activer le ND pour chaque interface LAN afin de distribuer les préfixes sur les LANs.

9) Vérifier la configuration du firewall, vers le WAN, entre LANs, etc... A partir de là, on doit obtenir de l'IPv6 dans tous les LANs. Penser à bien fermer l'accès depuis le WAN en forward, car étant donné qu'il n'y a pas de NAT en IPv6, le trafic entrant est autorisé par défaut si aucune configuration firewall.

Pour IPv4 :

1) Vérifier la configuration du Firewall IPv4 pour éviter tout risque. NAT et règles de forwarding, règles Input, etc...
Dans le firewall IPv6, Ouvrir le protocole ipencap (4) sur l'interface Vlan 836 en input.

2) Déterminer l'adresse IP source pour le tunnel MAP-E. Elle est composée du premier sous réseau / 64 issu du /60 délivré par Free, auquel on ajoute 0:ffff:ffff:0 à la fin. Si vous ne connaissez pas le /60, il est dispo sur l'interface WEB Free, ou bien on peut l'obtenir en le demandant dans la requête DHCPv6.

3) Ajouter cette adresse, en /128, sur le Vlan 836. Les autres adresses du /64 dont elle est issue restent éventuellement disponible pour utilisation sur une interface LAN.

4) Ajouter un tunnel MAP-E (IPIPv6) et y mettre un MTU de 1500.

local address : Ip source précédemment déterminée

remote address : normalement c'est toujours 2a01:e00:29:200a::fffd

Attention, j'ai remarqué que l'option KeepAlive posait problème avec le border router qui délivre les IP partagée. Le tunnel se coupe régulièrement avec cette option. Pour le serveur des IP full stack dont on parle ici, elle semble utilisable sans soucis.

5) Ajouter l'interface du tunnel dans la liste des interfaces WAN

6) Ajouter l'IPv4 publique full stack sur l'interface du tunnel, en /32

7) Ajouter la route par défaut IPv4 (0.0.0.0) avec l'interface du tunnel comme gateway

Revérifier et si besoin ajuster les règles de firewall pour la configuration IPv4 décrite ci-dessus.


Edit : sur mon RB5009, où j'ai le port WAN dans le bridge principal (mettre le port WAN dans le bridge permet de bridger certains VLAN sans utiliser un switch externe), le MTU de l'interface VLAN 836 saute et revient à 1500 à chaque redémarrage. Pour l'instant j'ai corrigé le problème avec un script de démarrage pour remettre le MTU du VLAN 836 à 1700, en passant par 1600 sinon ça ne marche pas.
NB : Le problème a été résolu dans RouterOS version 7.15.

delay 15
/interface vlan set VLAN-Free mtu=1600
delay 4
/interface vlan set VLAN-Free mtu=1700

J'ai remonté le problème à Mikrotik qui a pu le reproduire. Cela devrait être corrigé dans la version Ros 7.15 à venir. C'est corrigé.

Pour l'IP partagée, cela fonctionnait à moitié, trafic montant possible, mais pas de retour. Il est possible que je n'ai pas la bonne IP publique partagée. Ou bien que l'iP partagée ne soit pas routée en retour lorsqu'on est en IP full stack. J'ai trouvé cette IP partagée en écoutant dans le second tunnel, mais je n'en suis pas sur. Et on ne peut pas l'obtenir en DHCP puisque les tunnels sont en IP. Il faudra que j'essaie avec mon ancienne IP partagée, c'est peut être la même.

Et oui cela occasionne une modification au niveau niveau du NAT et du firewall, ainsi que le changement de la route par défaut, ou mise en place de règles de routage par mangle, ou mise en place d'un VRF pour isoler cette partie. On rentre dans les joies du multihoming.

Je n'ai pas bien saisi à quoi servent ces règles sur OpenWRT, elles permettent de calculer quelles adresses exactement ? Au niveau des ports cela permet de trouver le range utilisé par l'IP partagée ?

Sinon je pense qu'on peut utiliser cela pour trouver le range de ports de l'IP partagée :

http://ip.bieringer.net/cgn-test.html


Au passage, en faisant des tests de NAT avec l'IP full stack, je n'ai pas réussi à obtenir un NAT full cone (Endpoint Independent Mapping et Endpoint Independent Filtering, selon la nouvelle RFC5780). Pourtant RouterOS 7.13 ou 7.14 supporte ce type de NAT avec la nouvelle action NAT endpoint-independant-nat.

Voir ici :

https://help.mikrotik.com/docs/display/ROS/NAT#NAT-Endpoint-IndependentNAT

J'ai réalisé les tests avec NatType Tester version 8.02.

https://github.com/HMBSbige/NatTypeTester/releases
https://github.com/HMBSbige/NatTypeTester/blob/master/README.md

J'ai l'impression que Free (et probablement d'autres opérateurs) réalise un filtrage sur l'IP full stack dans son réseau pour éviter l'ouverture du NAT en Full Cone.

Pourtant chez Mikrotik leurs tests montrent que la nouvelle action NAT fonctionne correctement. Il faudrait tester avec un serveur Stun privé pour vérifier que c'est bien Free qui verrouille le NAT full cone.

J'ai testé aussi avec un NAT 1:1 en utilisant des règles Netmap qui devrait également donner une ouverture Full Cone et le résultat est un NAT avec adresses et ports dépendants en entrée.

Je me doutais que ce n'était pas aussi simple. Rien que si tu loupes ta plage de ports, ça ne risque pas de fonctionner.
...

Possible que j'ai fait une erreur sur le DNAT. Par contre je pense connaitre ma plage de ports. Quelque chose de spécial à faire sur les règles NAT ? La config NAT m'intéresse.

Bon j'avais juste oublié de spécifier mes ports de sortie dans les règles Src-nat  Donc l'adresse IP était bonne. Ainsi que le range de ports que j'avais détecté mais oublié de mettre dans les règles Src-nat.

Donc ça fonctionne. IP partagée et IP full stack en même temps.

A noter : il faut deux règles Src-NAT, une pour le TCP et une pour l'UDP, pour pouvoir spécifier les ports de sortie. Par contre le ping ne passe pas évidement. Est-ce-qu'il passe sur une FreeBOX depuis l'intérieur vers l'extérieur avec une IP partagée ?