Non, J'ai désactivé le tunnel pour faire des tests. Le problème à la base est sur la connectivité IPv6.

En effet il y a bien deux adresses IPv6 globales utilisées par la Freebox, une pour le tunnel IPIPv6, qu'il faut mettre manuellement, et une autre en /64, bizarrement en dehors du prefix IPV6 /60 attribué, qui est récupérée par la requête DHCPv6.

Cette adresse en /64 est en dehors du prefix /60, mais elle est bien routée par Free, j'ai pu la pinger depuis l'extérieur. Elle sert peut être dans la Freebox pour l'accès de FreeBox OS depuis l'extérieur, si l'option est activée. Si on la supprime dans le routeur, cela ne change rien.

En IPv6 il n'y a pas d'ARP effectivement, il y a des adresses IPv6 locales, commençant par FE80, qui sont déterminées lors du boot du routeur pour chaque interface, forgées sur les adresses MAC. Ces adresses en FE80 sont non routables, elles servent seulement à établir les liaisons point à point. Celle de l'interface WAN du routeur chez Free est utilisée par exemple dans la route par défaut du routeur client.

Je ne pense pas qu'il y ait un problème de ND. Je pense qu'il y a plutôt une règle de firewall qui s'ouvre chez Mikrotik, uniquement lorsque la FreeBox fait la requête IPV6, elle doit y ajouter quelque chose en plus. Ce qui est étrange c'est que cela ne semble pas être le cas pour tout le monde.

J'obtiens un bail de 30 jours en réponse à la requête IPv6 sur le VLAN 836. Cela semble différent du bail de 1 semaine obtenu par d'autres.

Bon, mon problème semble avoir disparu. Je ne suis pas certain de la raison exacte. Donc je peux maintenant couper l'alimentation du boitier ONTv2, et le lien remonte sans problème. Je peux aussi redémarrer le routeur.

Je pense néanmoins que le problème provenait simplement de l'autonégociation avec le boitier ONTv2, après redémarrage de ce dernier. C'est peut être  une mise à jour de RouterOS qui a résolu le problème (actuellement en 7.14.beta9). Ou peut être le boitier ONTv2 qui se serait mis à jour depuis les serveurs Free.

J'ai ajouté une option 6 dans la requête DHCPv6, pour demander la configuration MAP-E, pour faire comme la Freebox, mais cela n'a aucune influence au final. Cela marche sans.

Donc configuration pour le moment validée avec un RB5009.

La requête DHCPv6 semble obligatoire pour ouvrir le trafic IPv6 vers Internet. Par contre la mise en place du VLAN 835 n'est pas obligatoire, et ICMPv6 (ND, Router sollicitation, Router Advertisement...) n'est pas nécessaire, coté WAN.

Enfin, l'adresse source pour le tunnel MAP-E est obligatoire, mais on peut la mettre en /128 sur le VLAN 836 ou sur l'interface de bouclage local du routeur pour éviter de perdre un /64 complet.


Au passage, j'ai remarqué quelque chose d'étrange : Free présente un border router MAP-E avec une adresse qui ne fonctionne pas.

Dans la réponse DHCPv6 de Free, suite à la sollicitation DHCPv6 de la FreeBox, il est indiqué 2a01:e00:29:200a::fff9 comme adresse de border router MAP-E ; elle ne fonctionne pas.


La bonne adresse, pour moi, est 2a01:e00:29:200a::fffd

Je suppose que la Freebox n'utilise donc pas DHCPv6 pour établir le tunnel MAP-E.

T'as bien une IP fullstack ? Dans ce cas c'est normal. Le DHCPv6 ne délivre que les paramètres pour l'IP partagée (c'est comme ça depuis le début à priori).

Le paramétrage pour le fullstack doit se faire manuellement par le VLAN 835 comme plusieurs fois évoqué, d'où l'adresse de BR différente. Il ne font à priori pas de reconfiguration de leur DHCP pour envoyer les bonnes options à chaque client qui en fait la demande. J'imagine que c'est lourd à gérer et que c'est plus simple de le faire avec un bête fichier de conf.

Oui j'ai une IP fullstack. Je comprends maintenant. Pourquoi VLAN 835 ? C'est le 836 pour Internet ??

Oui les configurations spécifiques se font peut être par provisionning.

Si je comprends bien quand on est en fullstack, l'adresse IPv6 reçue par DHCPv6 serait une adresse IPv6 CGNAT ? C'est bizarre car chez moi elle est pingable depuis l'extérieur. Je pensais que c'était une IPv6 normale. Y'a t'il un intérêt pour un opérateur à faire du CGNAT en IPv6 ?

Je pensais que la différenciation CGNAT / Fullstack était limité à IPv4.

Autre chose intéressante, Free envoit un prefixe IPv6 en /80 dans son Router Advertisement, (ainsi que l'option MTU = 1700, ce qui est normal pour laisser de la place au tunnel MAP-E). Ce préfixe correspond avec l'adresse IPv6 reçue en DHCP 

Pourquoi /80 ? A noter, 128 - 80 = 48, soit la taille d'une adresse MAC.

Oui c'est une IP coté WAN, mais à quoi sert-elle ? Pour la configuration à distance de FreeBox OS ?

S'il n'y a pas de CGNAT en IPv6, je ne comprends pas trop pourquoi l'adresse IPv6 délivré dans DHcPv6 n'est pas dans le prefix en /60.

En plus, il n'y a pas besoin d'adresse Globale IPv6 sur le WAN, sauf l'adresse source pour le tunnel MAP-E. Si on a pas besoin d'IPv4, l'IPv6 fonctionne sans IPv6 globale sur le WAN. L'adresse link local en FE80 de l'interface WAN suffit pour le routage.


Non c'est bien un préfixe en /80, qui inclut l'adresse délivrée en DHcPv6 :

Le RA des équipements Free :

Internet Control Message Protocol v6
    Type: Router Advertisement (134)
    Code: 0
    Checksum: 0xc868 [correct]
    [Checksum Status: Good]
    Cur hop limit: 128
    Flags: 0xc8, Managed address configuration, Other configuration, Prf (Default Router Preference): High
    Router lifetime (s): 9000
    Reachable time (ms): 3600
    Retrans timer (ms): 0
    ICMPv6 Option (Prefix information : 2a01:e00:30:xxxx:xxxx::/80)
    ICMPv6 Option (Route Information : High ::/0)
    ICMPv6 Option (MTU : 1700)
    ICMPv6 Option (Source link-layer address : 00:07:cb:xx:xx:xx)

Oui c'est bien 0 pour le flag Autonomous address-configuration.

Donc c'est une annonce de route. Qui ne doit pas servir à grand chose d'ailleurs puisqu'il y a déjà une route par défaut attribuée par DHcPv6 ??

En tout cas sans la FreeBOX, la route par défaut obtenue en DHcPv6 suffit.

Effectivement pour un routeur, on y peut y accéder par n'importe quelle adresse IP située sur l'une de ses interfaces. Même par une IP qui ne se trouve pas sur une interface physique, par exemple une IP montée sur une interface de bouclage locale (lo). Sauf filtrage spécifique par le firewal évidement.
On peut même éventuellement en IPv4 avoir la même adresse IP sur plusieurs interfaces ! (adresses IP unumbered, pas dispo sous linux ou Mikrotik d'ailleurs)

Dans le cas de la FreeBox, le tunnel MAP-E utilise aussi une adresse source dans le préfixe délégué /60; et en adresse destination une adresse située dans le préfixe en /80 annoncé dans le RA, et dont une adresse est distribuée par DHcPv6. Simple n'est ce pas ?

Le flag du RA :

ICMPv6 Option (Prefix information : 2a01:e00:30:xxxx:xxxx::/80)
    Type: Prefix information (3)
    Length: 4 (32 bytes)
    Prefix Length: 80
    Flag: 0x80, On-link flag(L)
        1... .... = On-link flag(L): Set
        .0.. .... = Autonomous address-configuration flag(A): Not set
        ..0. .... = Router address flag(R): Not set
        ...0 0000 = Reserved: 0
    Valid Lifetime: 86400
    Preferred Lifetime: 14400
    Reserved
    Prefix: 2a01:e00:30:xxxx:xxxx::


Pour IPv6 qu j'avais étudié quelque peu il y a bien longtemps, il me semblait que rien n'empêchait d'utiliser des préfixes plus petits que /64. Avec une restriction majeure qui est que l'autoconfiguration stateless ne fonctionne plus sur des sous réseaux plus petits que /64. Évidemment, pour des réseaux LANs avec des PCs, c'est plus que gênant 

On ne peut pas annoncer de route par DHCPv6

....

Je pense que si. Un client peut demander les options de routes dans sa sollicitation DHCPv6. (OPTION_IA_RT). Même principe qu'en DHCP IPv4 avec l'option 121 (static classless route distribution).

J'ai testé cette option 121 en IPv4, elle fonctionne sans problème avec Windows 7 et probablement 10 voir 11. Elle permet de distribuer une route par défaut explicite, si besoin avec d'autres routes classless. Cela peut être utile pour éviter de devoir installer un client RIP sur les PC qui ont besoin de recevoir des routes spécifiques (par exemple pour ne pas perdre l'accès à des sous réseaux locaux lors du montage d'une interface VPN qui change la route par défaut).

Dans le cas de Mikrotik RouterOS, on peut demander au client DHCP (v4 ou v6) de monter une route par défaut. Sur le serveur DHCP en IPv4, c'est le champ gateway qui définit la passerelle. En IPv6 c'est l'adresse link local du serveur DHCP qui est utilisée comme passerelle pour la route par défaut. Idem pour les clients Windows et Linux de mémoire.