Auteur Sujet: Comment les différents pays déploient IPv6 ? (Lu 19659 fois)

buddy · « **Réponse #60 le:** 21 mai 2019 à 18:53:51 »

Citation de: pioup le 17 mai 2019 à 22:06:19

A part connaître les bonnes personne qui gèrent la mise en place de l'ipv6 en interne, il y peu de chance qu'une escalade aboutisse. Il faut réussir à passer le niveau 1 et le niveau 2 qui valident l'escalade sans s'arrêter à " votre internet fonctionne-t-il ? Oui donc tout va bien. "

J'étais beta-testeur SFR (sur les firmwares IPV6 entre autre) il y a de çà 4 à 5 ans. J'avais fait remonter en "interne" le soucis d'ipv6 qui était en panne chez mes parents (SFR aussi à l'époque). ça n'a pas déclenché une opération immédiate de résolution (si je puis dire ainsi.) Je crois que ça a fini par remarcher au bout de 6 mois.

Breizh 29 · « **Réponse #61 le:** 26 mai 2019 à 09:59:16 »

Moi j'aimerai être au moins en DHCP au lieu du PPP.
J'aurai l'impression d'être dans l'air du temps.

raf · « **Réponse #62 le:** 27 mai 2019 à 14:35:55 »

Citation de: Breizh 29 le 26 mai 2019 à 09:59:16

Moi j'aimerai être au moins en DHCP au lieu du PPP.

En IPv6 tu as du DHCP meme si tu es en PPP(oE). Peut-etre par pour la WAN du CPE (qui n'a quasiment aucune importance) mais pour le prefixe delegue c'est forcement du DHCP(v6-PD).

renaud07 · « **Réponse #63 le:** 04 juin 2019 à 13:39:26 »

Je viens de lire cet article fort intéressant : https://www.swordarmor.fr/de-lipv6-dans-du-ppp.html

Il explique très bien pourquoi personne le fait (même si c'est donc possible en bidouillant un peu, voir beaucoup

).

vivien · « **Réponse #64 le:** 05 juin 2019 à 07:26:35 »

Très bon article du 28 Septembre 2017, rédigé par alarig sous licence Creative Commons Attribution - Pas d’Utilisation Commerciale 3.0 France que je me permet de recopier au cas où la page disparaîtrait :

De l’IPv6 dans du PPP

Que j’aurais aussi pu titrer « Pourquoi aucun opérateur ne fait de collecte IPv6 en PPP ».

Tout d’abord, un rappel du fonctionnement d’une collecte PPP s’impose

- L’abonné entre ses identifiants PPP dans son modem,
- De l’autre côté, le BAS regarde le realm, et l’envoie à qui de droit en fonction. Par exemple un realm en @neufpnp ira chez SFR alors qu’un @grifon.ptel.ipadsl ira chez grifon,
- Le LNS de l’opérateur vérifie les identifiants depuis une base RADIUS,
- Et s’ils sont corrects, envoie la configuration au client en allant également la chercher dans une base RADIUS.
J’ai volontairement omis certains détails, mais le plus gros y est.

Fonctionnement en IPv4

C’est tout simple, le LNS prend une IP (soit fixe soit dynamique en fonction de votre FAI), un résolveur DNS, et envoie tout ça en IPCP dans le PPP.
Le routeur a l’autre bout, il a son IP pour faire son NAT et tout, il peut partager une IP entre tous les membres de la maison, il est content (nous non, parce que le NAT, mais c’est une autre histoire).

Et en IPv6

Et bien ce n’est pas du tout la même chose !
Il existe bien sûr IPv6CP (RFC5072, section 4), sauf que ça ne permet que de transmettre les 64 derniers bits de l’adresse que doit prendre l’abonné. Mais quid du range utilisé pour cette adresse, des ranges éventuellement délégués et des résolveurs DNS à utiliser ?

C’est là que ça devient intéressant, parce que tout ça doit être géré par des programmes extérieurs à PPP, qui injecteront tout cela dans le tunnel PPP. D’un côté c’est intéressant car on peut continuer à utiliser les implèmentations dont on a l’habitude, mais d’un autre côté c’est embêtant, parce que l’on doit extraire les informations du RADIUS, pour configurer des RA et du DHCPv6 à la volée, et les implèmentations ne sont pas forcèment prévues pour.
Mais surtout, c’est plein de bugs partout, vous allez voir.

Père Castor, raconte nous une histoire

Voici donc mon histoire. Nous sommes un FAI, Grifon, et j’y ai mis en place un routeur de collecte ADSL. On trouve donc un opérateur de collecte, on se branche, on récupère le L2TP, tout va bien… jusqu’au moment où j’attaque IPv6.

Les attributs RADIUS

Je regarde les RFCs et mets donc les attributs qui vont bien pour ma connexion.

Code: [Sélectionner]

Framed-IPv6-Prefix = 2a00:5884:1100:1::/64,
Framed-IPv6-Address = 2a00:5884:1100:1::2,
Framed-Interface-Id = 0:0:0:2,
Delegated-IPv6-Prefix = 2a00:5884:1101::/48

Et là, rien ne se passe. Parce que dans le dictionnaire d’attributs utilisé par pppd, ils ne sont pas présents. Je les ajoute.

Code: [Sélectionner]

#IPv6
ATTRIBUTE       Framed-IPv6-Prefix      97      ipv6prefix
ATTRIBUTE       Framed-IPv6-Address     168     ipv6addr
ATTRIBUTE       Framed-Interface-Id     96      string
ATTRIBUTE       Delegated-IPv6-Prefix   123     ipv6prefix

Je recommence. Et :

Code: [Sélectionner]

Sep 21 22:18:23 judicael-adsl pppd[5239]: rc_avpair_gen: received unknown attribute 65 of length 4: 0x00000001
Sep 21 22:18:23 judicael-adsl pppd[5239]: rc_avpair_gen: received unknown attribute 67 of length 13: 0x38392E3233342E3138362E3131
Sep 21 22:18:23 judicael-adsl pppd[5239]: rc_avpair_gen: received unknown attribute 64 of length 4: 0x00000003
Sep 21 22:18:23 judicael-adsl pppd[5239]: rc_avpair_gen: received unknown attribute 97 of length 18: 0x00402A005884110000010000000000000000
Sep 21 22:18:23 judicael-adsl pppd[5239]: rc_avpair_gen: received unknown attribute 168 of length 16: 0x2A005884110000010000000000000001
Sep 21 22:18:23 judicael-adsl pppd[5239]: rc_avpair_gen: received unknown attribute 96 of length 8: 0x0000000000000002

Là, ça commence déjà à devenir plus sérieux. Mais qu’à cela ne tienne, dans notre jeunesse nous avions déjà eu ce souci sur notre première solution VPN (à base d’IPsec pour chiffrer et de L2TP et PPP pour se rapprocher d’une collecte ADSL) et nous avions publié un patch, c’est juste dommage qu’en un an et demi il n’ait pas été intégré.
Je le reprends donc, je remercie gentoo de permettre de patcher facilement le code et je recommence une nouvelle fois, et je ne reçois rien.

Extraire les informations du RADIUS

Et oui, parce que PPP n’envoie aucune information utile pour que je puisse configurer ma pile IPv6 de mon côté. Se pose alors la question de comment récupérer les attributs utiles. Je peux bien sûr parser le fichier de la base de données RADIUS, car c’est un fichier plat, mais rien ne prouve qu’il sera toujours sur cette machine et je ne sais pas dire a priori quel identifiant est sur quelle interface.
Heureusement, en cherchant un peu, il existe le module radattr.so qui permet d’écrire les attributs RADIUS dans un fichier.

Code: [Sélectionner]

Service-Type Framed-User
Framed-Protocol PPP
Framed-Routing None
Framed-IP-Address 89.234.186.21
Framed-IP-Netmask 255.255.255.255
Framed-MTU 1492
Framed-IPv6-Prefix 2a00:5884:1100:1::/64
Framed-IPv6-Address 2a00:5884:1100:1::1
Framed-Interface-Id
Delegated-IPv6-Prefix 2a00:5884:1101::/48

Voilà qui est facilement parsable, c’est parfait. Mais, comment je mets ça dans radvd ? Je peux echo >> /etc/radvd.conf mais ça va être compliqué de retirer une configuration quand quelqu’un se déconnecte.
La solution retenue a donc été d’écrire un fichier de configuration basique, d’écrire un fichier par utilisateur, et de faire cat /etc/radvd.conf.base > /etc/radvd.conf; cat /run/vpn/radvd-user.*.conf >> /etc/radvd.conf puis de recharger la conf à chaque nouvelle connexion.
Je retente donc une nouvelle fois, et cette fois-ci j’ai une IP et une route par défaut ! Je commençais à désespérer… Mais seulement, je n’ai qu’une IP dans le range d’interco (le /64). Évidemment, je n’ai rien fait de mon range routé dans la configuration de radvd. Il faut donc que je configure cette partie à la main si je veux redistribuer des IPv6 à mes machines. Ce n’est pas très grave pour moi, mais c’est plus grave si je veux que ça marche automatiquement chez tout le monde.

Histoire de vérifier un peu ma configuration quand même, je demande à un copain qui a un modem linksys censé supporter IPv6 de tester. Et évidemment, l’IPv4 monte directement et l’IPv6 reste bloquée.

Rajouter une couche de DHCPv6

En regardant les trames de plus près, je me rends compte que son modem demande du DHCPv6. Je me dis que ce n’est pas si grave, je prends une implèmentation connue, type celle de l’ISC, j’utilise la même méthode de configuration qu’avec radvd, et ça va le faire.
Sauf que non, parce qu’il échoue en disans « Unsupported device type 512 for "ppp0" ».

Il me faut alors chercher une autre implèmentation, par exemple kea, qui elle supporte le PPP. Par contre, la configuration est en JSON et fait environ 70 lignes là où celle de radvd en fait 10. Je ne peux donc pas toutes les concaténer dans le même fichier, ça deviendrait rapidement inexploitable si pour une raison ou une autre je dois aller regarder dedans.
J’écris donc un template, que je sed avec les vraies valeurs et que j’écris dans un autre fichier, que j’utilise comme configuration pour kea.

Documentation technique

Si jamais vous souhaitez savoir ce que donne la configuration complète et comment les différentes briques se mettent place, vous pouvez lire la page de wiki que j’ai écrite à ce sujet.

Conclusion

Pour faire marcher IPv6 sur PPP, il m’a donc fallu :
- Ajouter les attributs RADIUS dans le dictionnaire,
- patcher ppp,
- extraire la configuration IPv6 qui passe dans le PPP,
- bricoler la configuration de radvd,
- faire de même avec kea, en me prenant un bug sur isc-dhcp au passage.

Maintenant je comprends donc pourquoi personne ne fait d’IPv6 dans PPP. Ça demande beaucoup trop de bidouille pour que ça soit exploitable. Je comprends également pourquoi Orange attend de passer en collecte ethernet pour proposer de l’IPv6 et pourquoi Free utilise 6rd.
Je suis sacrèment attaché à IPv6, donc j’ai bien creusé pour le faire marcher, mais à plusieurs moments je me suis dit que faire de l’IPv4-only ce ne serait peut-être pas si mal.

Après, il est vrai que j’aurais pu utiliser l2tpns, mais il a aussi dû être patché pour faire fonctionner IPv6, sans que le code ne soit intégré en upstream, et il fait tout en un seul programme (L2TP et PPP).
De plus, il comporte un bug qui fait que le RA n’est envoyé qu’une fois en début de session et que si le routeur ne l’a pas reçu (mauvais câble, implèmentation qui ne s’attendait pas à le recevoir à ce moment, etc.), la route par défaut n’est jamais connue. De plus, il commençait à partir en buffer-overflow quand je l’ai testé chez moi.

raf · « **Réponse #65 le:** 05 juin 2019 à 16:11:34 »

Citation de: vivien le 05 juin 2019 à 07:26:35

En regardant les trames de plus près, je me rends compte que son modem demande du DHCPv6. Je me dis que ce n’est pas si grave, je prends une implèmentation connue, type celle de l’ISC, j’utilise la même méthode de configuration qu’avec radvd, et ça va le faire.
Sauf que non, parce qu’il échoue en disans « Unsupported device type 512 for "ppp0" ».

Pas la meilleure idee. Ma marche beaucoup mieux avec dibbler-client.

Citation de: vivien le 05 juin 2019 à 07:26:35

Pour faire marcher IPv6 sur PPP, il m’a donc fallu :
- Ajouter les attributs RADIUS dans le dictionnaire,
- patcher ppp,
- extraire la configuration IPv6 qui passe dans le PPP,
- bricoler la configuration de radvd,
- faire de même avec kea, en me prenant un bug sur isc-dhcp au passage.

Chez moi, sur un vieux Ubuntu, la partie client etait beaucoup plus simple. Pour la partie BRAS/LNS, voir juste apres.

Citation de: vivien le 05 juin 2019 à 07:26:35

Maintenant je comprends donc pourquoi personne ne fait d’IPv6 dans PPP. Ça demande beaucoup trop de bidouille pour que ça soit exploitable. Je comprends également pourquoi Orange attend de passer en collecte ethernet pour proposer de l’IPv6 et pourquoi Free utilise 6rd.

Quand on utilise du materiel fait par des constructeurs "connus", ces problemes n'existent pas. La partie DHCP over PPP ca juste marche, que ca soit cote BRAS/LNS ou cote CPE. Le choix PPP versus IPoE se fait sur d'autres criteres.

vivien · « **Réponse #66 le:** 05 juin 2019 à 16:15:39 »

Citation de: raf le 05 juin 2019 à 16:11:34

Quand on utilise du materiel fait par des constructeurs "connus", ces problemes n'existent pas. La partie DHCP over PPP ca juste marche, que ca soit cote BRAS/LNS ou cote CPE.

Grifon (Fournisseur d'Accès à Internet Associatif Rennais) utiliserait du MikroTik ?

Optix · « **Réponse #67 le:** 05 juin 2019 à 16:41:20 »

Citation de: vivien le 05 juin 2019 à 16:15:39

Grifon (Fournisseur d'Accès à Internet Associatif Rennais) utiliserait du MikroTik ?

(ça marche pas trop mal)

alarig · « **Réponse #68 le:** 05 juin 2019 à 16:52:02 »

Citation de: vivien le 05 juin 2019 à 16:15:39

Grifon (Fournisseur d'Accès à Internet Associatif Rennais) utiliserait du MikroTik ?

Non, les LNS c’est du Linux (en VM). Une stack PPP/xl2tp et une stack accel-ppp.

Les trucs constructeur que l’on a, c’est en bordure (ASR1001) et en switching (EX3300).

raf · « **Réponse #69 le:** 06 juin 2019 à 14:58:02 »

Citation de: vivien le 05 juin 2019 à 16:15:39

Grifon (Fournisseur d'Accès à Internet Associatif Rennais) utiliserait du MikroTik ?

Mikrotik ca peut aller comme CPE, mais pas plus. Et encore la, j'ai pas eu la chance de le tester pour voir si la partie IPv6 fonctionne comme chez les auttres.

Hugues · « **Réponse #70 le:** 06 juin 2019 à 15:30:58 »

Il ne sait pas prendre d'IPv6 via les attributs RADIUS je crois, il ne le fait que par DHCPv6-PD.

raf · « **Réponse #71 le:** 07 juin 2019 à 14:43:25 »

Citation de: Hugues le 06 juin 2019 à 15:30:58

Il ne sait pas prendre d'IPv6 via les attributs RADIUS je crois, il ne le fait que par DHCPv6-PD.

Le "Delegated-IPv6-Prefix" est uniquement utilisable sur les BRAS/BNG/LNS qui savent lier un reponse DHCP(v6) a un subscriber particulier. En effet, le PD est uniquement dispo via DHCPv6-PD. Si c'est pour faire du statique, il faut utiliser "Framed-IPv6-Route".