La RC de RouterOS permet maintenant de récupérer un préfixe ipv6 chez Orange, le client DHCPv6 a été complété et gère l'envoi d'options dont celles attendues par leur serveur DHCPv6.

La configuration spécifique à Orange à faire est du même ordre que celle pour ipv4, testée quelques jours sans problèmes majeurs mais avec quelques bugs, c'est une RC.

Le principal problème étant que, en cas de reboot du routeur, il faut faire un RELEASE du bail à la mano ou par script : une histoire de link-local (FE80) qui change à chaque reboot du routeur ... en tout cas chez moi. La l-l est mémorisée par baobab et un REBIND ne lui suffit pas.

Maintenant, utiliser un prefixe Orange à la pérennité imprévisible, je vous laisse juge

Plus d'infos à suivre.

Environnement :

Mikrotik RB2011UiAS-IN
RouterOS 6.42rc49 (Release candidate)
Abonnement Zen 100/100 - ONT HUAWEI - LB3 reliée au RB2011

Le principal problème étant que, en cas de reboot du routeur, il faut faire un RELEASE du bail à la mano ou par script

Étrange. J’ai chez moi 2 ERL que j’intervertis à chaque mise à jour (donc l’adresse link-local change) et je n’ai jamais remarqué le problème (et pourtant je ne fais pas de release).

Mise en en place de l'ipv6 natif Orange sur un routeur Mikrotik

Mise à jour le 14/08/2019 :
précision concernant l'impact du bridge sur Fasttrack (en ipv4)
possibilité de faire sans bridge, avec la méthode de bob62
obligation maintenant de paramétrer en version longue les options DHCPvX 90 et 11
précision sur 'untracked' et son match des RA et NS

Mise à jour le 23/09/2019 :
Précisions sur SLAAC et les résolveurs dns


Bonsoir à tous,

Tout d'abord un grand merci à tous ceux sur ce forum qui par leur partage d'expérience m'ont permis d'utiliser RouterOS sur le réseau Orange. Donc à mon tour de partager une nouveauté intéressante pour ceux qui voudraient utiliser ipv6 by Orange

RouterOS ne pouvait pas jusqu'à présent opérer ipv6 en natif chez Orange car les options envoyées par son client DHCPv6 au serveur n'étaient pas paramétrables. C'est maintenant possible, depuis la version 6.42 Release Candidate, qui permet aussi d'ailleurs de gérer les options de son serveur DHCPv6.

Je vous propose de voir comment récupérer le préfixe ipv6 alloué par le FAI à votre ligne puis de l'utiliser dans un LAN interne, avec tout d'abord le contexte où les tests ont eu lieu puis les paramétrages utilisés pour y parvenir.
 
NB : le passage à une version non stable (Release Candidate) peut impacter très négativement votre réseau. De même pour les commandes ci-dessous, elles doivent être analysées et adaptées par vos soins à votre environnement. Je décline toute responsabilité sur leur utilisation.


OK ? On y va !


Le contexte

Les tests ont été faits dans cet environnement :

* Abonnement Fibre Zen (100/100 devenus 300/300 par la suite)

* ONT HUAWEI- Livebox 3 (Play) - Décodeur TV

* Routeur Mikrotik RB2011UiAS-IN    https://mikrotik.com/product/RB2011UiAS-IN

* RouterOS 6.42 (la branche RC de la 6.42 est maintenant devenue la version stable) :

         * le package ipv6 a été activé
         * la configuration du routeur a été réalisée from scratch (celle par défaut a été supprimée).


Pour situer, les interfaces du RB2011 que j'utilise :

Ether1 : vers l'ONT HUAWEI
Ether2 : vers le LAN domestique
Ether3 : vers la Livebox, avec derrière la téléphonie et le décodeur TV


La liaison Internet passe par un bridge, créé pour forcer la CoS à 6 des paquets DHCPv4. Par effet de bord cela désactive Fasttrack dans le sens WAN > routeur (il reste actif dans le sens routeur > WAN). En fait, ce n'est pas la mise en place du bridge qui désactive Fasttrack, mais l'utilisation de règles '/interface bridge filter'.


/interface vlan          add name=<le_vlan_832_de_ether1> interface=ether1 vlan-id=832 comment="ETHER1-VLAN832-ONT"
/interface bridge        add name=<le_bridge_vers_l'ONT> protocol-mode=none
/interface bridge port   add bridge=<le_bridge_vers_l'ONT> interface=<le_vlan_832_de_ether1>
/interface bridge filter add chain=output action=set-priority new-priority=6 mac-protocol=ip ip-protocol=udp dst-port=67 out-interface=<le_vlan_832_de_ether1>


1 - Si vous êtes déjà obligé de marquer en CoS 6 (802.1p) les trames DHCPv4 pour qu'elles soient acceptées par le réseau Orange

Il faudra adapter et ajouter cette nouvelle règle à votre bridge vers le vlan832 de l'ONT, elle est similaire à celle que vous utilisez pour ipv4. Le serveur DHCPv6 écoute sur le port 547. Au fait, Fasttrack n'est pas implèmenté par MTK en ipv6.

/interface bridge filter
add chain=output action=set-priority new-priority=6 mac-protocol=ipv6 ip-protocol=udp dst-port=547 out-interface=<le_vlan_832_de_ether1>


Edit : bob62 a présenté le moyen de forcer la CoS à 6 pour DHCPv4 sans utiliser de bridge, ceci en utilisant les 'rules' du Switch Chip. D'après le wiki RouterOS cela semble transposable pour DHCPv6, je ne l'ai pas testé.
https://lafibre.info/remplacer-livebox/configuration-routeros-mikrotik-pour-livebox/msg628648/#msg628648

Les routeurs MTK n'acceptant pas tous ces rules, vérifiez si le chip de votre routeur est compatible ici :
https://wiki.mikrotik.com/wiki/Manual:Switch_Chip_Features#Introduction


Si vous n'utilisez pas de bridge pour marquer la CoS, remplacez dans les commandes ci-dessous <le_bridge_vers_l'ONT> par <le_vlan_832_de_ether1>.


2 - Indiquez à RouterOS de prendre en compte les Router Advertisements venant du réseau Orange

/ipv6 settings set accept-router-advertisements=yes

Il semble qu'un reboot du routeur soit nécessaire après, le Wiki de Mikrotik n'est pas très clair pour moi sur ce point :
https://wiki.mikrotik.com/wiki/Manual:IPv6/Settings


3 - Evitez le filtrage par le firewall des réponses du serveur DHCPv6 d'Orange

J'ai retrouvé un problème vu il y a longtemps sous ArchLinux : le firewall ne matche pas comme ETABLISHED les réponses du serveur DHCPv6, elles sont donc rejetées même si vous acceptez de l'extérieur ce qui est initié de l'intérieur. Une explication du problème ici :
https://unix.stackexchange.com/questions/176717/what-is-dhcpv6-client-service-in-firewalld-and-can-i-safely-remove-it#176773

En fonction de la sécurité appliquée dans votre firewall, vous devrez (ou non) adapter et ajouter la règle suivante par 'ipv6 firewall filter'. Le client DHCPv6 écoute sur le port 546.

add chain=input action=accept in-interface=<le_bridge_vers_l'ONT> src-address=fe80::ba0:bab/128 protocol=udp dst-port=546

Notez que cela crée une adhérence à l'adrese link-local de boabab, on peut décider d'être moins strict :

add chain=input action=accept in-interface=<le_bridge_vers_l'ONT> src-address=fe80::/10 protocol=udp dst-port=546


4 - Créez les options à envoyer au serveur DHCPv6, spécifiques à Orange

La nouveauté est là, la gestion des options.

Elles sont similaires à celles en ipv4, mais avec des codes et un formattage spécifiques à ipv6 :

/ipv6 dhcp-client option

# option sagem :
add code=16 name=class-identifier value=0x0000040e0005736167656d

# option SVDSL_livebox.Internet.softathome.Livebox3 :
add code=15 name=userclass        value=0x002b46535644534c5f6c697665626f782e496e7465726e65742e736f66746174686f6d652e6c697665626f7833

# option 'version courte' fti/<votre_identifiant_Orange> :             >>>  la version courte n'est plus supportée par Orange  !!!
# remplacer XXX...... par fti/<votre_identifiant_Orange> en héxa
add code=11 name=authsend         value=0x0000000000000000000000XXXXXXXXXXXXXXXXXXXXXX

en ipv4, pour certains abonnements, l'option 90 (équivalente de l'option 11 ci-dessus) doit obligatoirement être envoyée en 'version longue' cf :
https://lafibre.info/remplacer-livebox/remplacement-de-la-livebox-par-un-routeur-lede-fork-dopenwrt/msg527359/#msg527359

Il est possible d'en faire autant en ipv6, je l'ai testé aussi, capturez l'option 11 (ipv6) sur un dialogue LB <> Orange et ajoutez-là dans votre configuration.

Edit : l'option 90 version courte n'est plus supportée par Orange depuis Septembre 2018 : il faut maintenant utiliser sa version longue tant pour DHCPv4 que pour DHCPv6 (option 11) cf :
https://lafibre.info/remplacer-livebox/cacking-nouveau-systeme-de-generation-de-loption-90-dhcp/msg579668/#msg579668


5 - Récupérez le préfixe assigné à votre ligne

La commande suivante va permettre de récupérer le préfixe de longueur /56 routé vers votre ligne. Il sera affecté au pool 'pool_FT_6' et redistribuable par PD de longueur /64 si vous activez le serveur DHCPv6-PD de RouterOS.

'pool_FT_6' servira aussi à affecter un sous-préfixe au LAN (sans avoir besoin du serveur DHCPv6-PD de RouterOS), c'est cette fonction que nous utiliserons plus tard.

/ipv6 dhcp-client add \
 interface=<le_bridge_vers_l'ONT> \
 dhcp-options=authsend,userclass,class-identifier \
 request=prefix \
 pool-name=pool_FT_6 \
 pool-prefix-length=64 \
 add-default-route=yes

Pour vérifier la récupération du préfixe :

/ipv6 pool print detail
Flags: D - dynamic
 0 D name="pool_FT_6" prefix=2a01:cb1d:xxxx:xx00::/56 prefix-length=64 expires-after=2d12h44m49s


On a le préfixe, voici maintenant comment l'utiliser.


6 - Affectez un sous-préfixe au LAN et annoncez-le

l'interface du LAN prendra comme adresse <1er_préfixe_64_libre_du pool_56>::1/64 :

/ipv6 address add address=::1/64 from-pool=pool_FT_6 interface=ether2 advertise=yes

Un exemple de délégation :

le préfixe reçu du FAI                                   2001:07A8:AAAA:BB00::   /56
le 1er préfixe, alloué à ether2                          2001:07A8:AAAA:BB00::   /64
l'adresse de l'interface ether2                          2001:07A8:AAAA:BB00::1  /64
un 2° préfixe alloué à une autre interface du routeur    2001:07A8:AAAA:BB01::   /64
et son adresse                                           2001:07A8:AAAA:BB01::9  /64


Et pour vérifier l'adresse allouée :

/ipv6 pool used print detail
 pool=pool_FT_6 prefix=2a01:cb1d:xxxx:xx00::/64 owner="Address" info="ether2"

/ipv6 address print detail where interface=ether2
Flags: X - disabled, I - invalid, D - dynamic, G - global, L - link-local
 0  G address=2a01:cb1d:xxxx:xx00::1/64 from-pool=pool_FT_6 interface=ether2 actual-interface=ether2 eui-64=no advertise=yes no-dad=no
 1 DL address=fe80::66d1:54ff:fexx:xxxx/64 from-pool="" interface=ether2 actual-interface=ether2 eui-64=no advertise=no no-dad=no


Activez ipv6 sur un host du LAN et vous y aurez maintenant accès à Internet en ipv6 natif

NB : ipv6 est activé par défaut sur la quasi-totalité des OS. Pour le vérifier, par exemple sous Windows : dans la carte réseau, la case 'protocole Internet ipv6' doit être cochée. Le protocole utillisé par défaut entre routeur et hosts est SLAAC : les RA envoyés par le routeur permettent à l'OS de récupérer et configurer automatiquement ses adresses, masque et passerelle. Avec cette méthode la mise en place d'un serveur DHCPv6 n'est pas indispensable.


7 - Et pour les DNS ?

Le plus simple est ... de ne rien faire. Ni sur les hosts ni sur le routeur. De cette façon, sur mes hosts, ce sont les résolveurs dns configurés sur la carte réseau pour ipv4 qui font le travail aussi pour ipv6, rien à modifier n'y à ajouter.

Les points suivants concernent un usage plus avancé, à mettre en oeuvre avec une bonne connaissance de DHCPv6, des RA et de leurs interactions.

RouterOS offre deux façons de communiquer aux clients ipv6 les adresses (ipv6 uniquement) des résolveurs DNS :

Par le serveur DHCPv6 du routeur :

la 6.42 amène aussi la possibilité d'en paramétrer les options. On peut diffuser les adresses des résolveurs de son choix en paramétrant l'option 23 (OPTION_DNS_SERVER), en mode DHCPv6 stateless. Attention : Les RA vers le LAN devront diffuser le flag 'other-configuration'. Plus d'informations ici :
https://forum.mikrotik.com/viewtopic.php?f=2&t=132657#p651811

Par les RA envoyés au LAN par le routeur :

les adresses des résolveurs seront diffusées par les RA si on y ajoute l'option 'advertise-dns=yes'. Mais ... l'implèmentation par Mikrotik est inachevée : les résolveurs distribués par ces RA sont ceux déclarés par '/ip dns set servers=' (c'est à dire les résolveurs utilisés par le routeur lui-même), donc on ne peut pas personnaliser la liste des résolveurs envoyée aux clients ni utiliser le routeur comme cache pour les clients du réseau. A noter que, côté hosts, cette fonction n'est pas implèmentée sur tous les OS.


8 - Concernant le firewall ?

Voici un exemple de règles à passer avec '/ipv6 firewall filter' et à adapter suivant votre usage et la sécurité que voulez mettre, filtrage des bogons, des RA et NS,  filtrage en sortie, accès du WAN vers le LAN etc :

chain=input action=accept connection-state=established,related,untracked
chain=input action=drop connection-state=invalid
chain=input action=accept in-interface=ether2
chain=input action=accept protocol=udp src-address=fe80::ba0:bab/128 in-interface=<le_bridge_vers_l'ONT> dst-port=546
chain=input action=drop

chain=forward action=accept connection-state=established,related,untracked
chain=forward action=drop connection-state=invalid
chain=forward action=accept in-interface=ether2
chain=forward action=drop

NB1 : les messages Neighbor Solicitation et Router Advertisement émis par baobab vers le routeur passent par la 1ère règle, du fait du 'untracked'. Il n'y a donc pas besoin d'une règle spécifique pour les accepter.

NB2 : Fasttrack n'est pas implèmenté pour ipv6 dans RouterOS.


9 - Et pour pinger ?

Très sommaire avec RouterOS :

 '/ping ipv6.google.com' ne marche tout simplement pas et retourne un message d'erreur car ping ne sait pas résoudre des adresses ipv6 (AAAA).

resolve peut être utilisé dans le ping :
/ping [resolve ipv6.google.com] et là ça marche !

Mais ... il faut que le nom ne résolve qu'en adresse ipv6 (i.e. juste en AAAA et pas en A) ce qui est le cas de ipv6.google.com.

A contrario, le nom www.free.fr possède un AAAA ET un A. La commande suivante ne marchera pas comme souhaité :
/ping [resolve www.free.fr] pingera l'ipv4 de free.fr, et pas son ipv6.

pour pinger www.free.fr en ipv6, on devra donc saisir son adresse :
/ping 2a01:e0c:1::1


10 - Et pour finir, si vous perdez ipv6 comme moi après un reboot du routeur

Si vous n'utilisez pas de bridge pour la CoS, vous pouvez ignorer cette partie.

Pour une raison que je n'ai pas encore bien identifiée, cf mon message plus haut dans ce sujet, après un reboot du routeur la re-synchronisation avec le serveur DHCPv6 se fait mal et il faut attendre 10 minutes avant que ipv6 soit à nouveau opérationnel.

la commande suivante permet de contourner le problème, elle fait un release du bail et redémarre le client dhcpv6 pour le ré-obtenir. A lancer par la console ou dans un script exécuté au reboot du routeur.

/ipv6 dhcp-client release [find interface=<le_bridge_vers_l'ONT>]

Une autre façon de contourner plus ciblée : figer l'adresse ipv6 link-local du bridge vers l'ONT. En effet cette adresse change à chaque reboot du routeur et cela semblerait être le souci. On le fait indirectement en forçant l'adresse MAC du bridge, dont est dérivée sa l-l :

/interface bridge set [find name=<le_bridge_vers_l'ONT>] auto-mac=no admin-mac=<adresse_MAC_de_ether1>
# faire un reboot puis lancer (une fois suffit) :
/ipv6 dhcp-client release [find interface=<le_bridge_vers_l'ONT>]


Et voilà, depuis la version stable 6.42 est arrivée !

très sympa tout cela !

pour ma part, je vais attendre que cela soit plus stable.

à bientôt donc.

Idem , c'est hyper cool de partager , mais je ne fais pas tourner mon routeur de prod sur des RC.
Connaissant pas mal RouterOS ... il arrive souvent qu'ils pètent des trucs dans les stables ... Alors j'imagine pas les RC  :-D

J'attends la prochaine stable et je regarde ;-)

ROS 6.42 est sortie en stable.

Vais-je enfin pouvoir me connecter à Orange en IPV6 ?   

Je ferai bientot un retour 

J'ai pas testé encore, mais je n'ai pas de bridge ;-)