Auteur Sujet: IPV6, Freebox et ULA (Lu 1574 fois)

nbanba · « **le:** 25 février 2025 à 10:52:17 »

Bonjour

Au niveau des GUA, la freebox permet de configurer des Next-Hop pour les 8 subnets (du premier /61) qui sont dédiés à l'abonné sur le /60 routé sur chaque connexion (le second /61 semble "bloqué" par l'utilisation de la dernière IP du bloc pour le player).

Quand on configure ces NH dans FreeboxOS, une note précise:

Citer

Attention si vous configurez un Next Hop pour le premier subnet, il ne sera plus annoncé par la Freebox sur votre réseau. Cela empêchera les appareils dépendant d’IPv6 de fonctionner sans un routeur tiers qui gère ce subnet."

OK, ici on parle bien des GUA

Qu'en est il des ULA ?

Retour d'expérience:

Quand un routeur tiers présent sur le segment gère les ULA (il peut également (ou pas) gérer les GUA dont le 1er /64 du /61), ses annonces RA sont ignorées par la Freebox.
Idem lorsque des NH sont définis pour les 8 prefix /64 (ce qui signifie à priori qu'on ne souhaite pas que la freebox gère l'IPv6)

Est ce normal ?

Cela à 2 conséquences assez gênante, à savoir :

1) la freebox ne met pas de route vers le routeur qui gère les ULA sur le segment dans sa table de routage et il devient par exemple impossible de communiquer avec la freebox en ULA sur son adresse local fd0f:ee:b0::1

2) le segment L2 présent derrière la Freebox (ce qui est communément appelé LAN) est en fait du LAN en IPv4 mais du WAN en IPv6

Je me trompe peut être mais cela ne me semble pas devoir fonctionner comme ça, et à mon sens soit il manque un champ NH pour les ULA soit la freebox doit apprendre des RA qu'elle reçoit sur le L2 côté "LAN"

Ainsi on pourrait également retirer cette dualité segment public IPv6 / segment privé IPv4 sur le L2 présent derrière la Freebox

Cordialement
nbanba

kgersen · « **Réponse #1 le:** 25 février 2025 à 11:20:15 »

Pour moi c'est normal que la freebox ignore des annonces de route (via RA) coté lan. je pense par sécurité. Elle doit toutefois pouvoir joindre une ULA sur son segment LAN non ?

La Freebox est toujours joinable sur son anycast public (freeplayer.freebox.fr) , quelque soit sa configuration bridge ou router.

Dans un scénario typique, il n'y a rien entre la freebox et le/les routeur(s) qui gere(nt) les prefixes (nh).Tout ce passe en link-local, pas besoin de GUA ou ULA.

Citation de: nbanba le 25 février 2025 à 10:52:17

2) le segment L2 présent derrière la Freebox (ce qui est communément appelé LAN) est en fait du LAN en IPv4 mais du WAN en IPv6

? c'est le principe d'IPv6 ...

ou je ne comprend ton argument.

nbanba · « **Réponse #2 le:** 25 février 2025 à 11:50:47 »

Bonjour

Déjà, merci pour la réponse

Citation de: kgersen le 25 février 2025 à 11:20:15

? c'est le principe d'IPv6 ...

Il ne me semble pas que le principe d'IPv6 soit "Tout le monde sur internet" mais plutôt "96bits de plus".

Si la classe fc00/7 plus utilisée dans sa partie fd00/8 existe, c'est bien pour permettre une "symétrie" avec le RFC1918 et pour permettre également le NAT/PAT

Car si c'est le principe d'IPv6, alors il est normal que le frigo connecté de madame michu soit en direct sur internet en IPv6...
Ça m'étonnerait que les éditeurs de sécurités voir l'ANSSI soient d'accord avec ça

Aussi, dans un tel cas, la Freebox devrait "faire firewall" et proposer une interface permettant de faire des règles et des ouvertures de ports en IPv6 et de source NAT en sortie
Si on regarde sur un FortiGate, à l'exception du statefull DHCP, de SLAAC et des RA soit les "features supplamentaires" d'IPv6 (et de l'impossibilité de fixer des leases statefull DHCP d'une même machine présente sur plusieurs segments et présentant un unique DUID), la gestion IPv6 ou IPv4 est exactement identique (même les policy sont mixtes IPv4 / IPv6 depuis FortiOS 6.4 ou 7.0 je ne sais plus) et notamment source NAT, destination NAT, PAT, etc...

Cordialement
nbanba

vocograme · « **Réponse #3 le:** 25 février 2025 à 12:32:04 »

Citation de: nbanba le 25 février 2025 à 11:50:47

Bonjour

Déjà, merci pour la réponse

Il ne me semble pas que le principe d'IPv6 soit "Tout le monde sur internet" mais plutôt "96bits de plus".

Si la classe fc00/7 plus utilisée dans sa partie fd00/8 existe, c'est bien pour permettre une "symétrie" avec le RFC1918 et pour permettre également le NAT/PAT

Car si c'est le principe d'IPv6, alors il est normal que le frigo connecté de madame michu soit en direct sur internet en IPv6...
Ça m'étonnerait que les éditeurs de sécurités voir l'ANSSI soient d'accord avec ça

Aussi, dans un tel cas, la Freebox devrait "faire firewall" et proposer une interface permettant de faire des règles et des ouvertures de ports en IPv6 et de source NAT en sortie
Si on regarde sur un FortiGate, à l'exception du statefull DHCP, de SLAAC et des RA soit les "features supplamentaires" d'IPv6 (et de l'impossibilité de fixer des leases statefull DHCP d'une même machine présente sur plusieurs segments et présentant un unique DUID), la gestion IPv6 ou IPv4 est exactement identique (même les policy sont mixtes IPv4 / IPv6 depuis FortiOS 6.4 ou 7.0 je ne sais plus) et notamment source NAT, destination NAT, PAT, etc...

Cordialement
nbanba

Bonjour,

Personnellement je ne vois pas le NAT et les IPs "privées" comme un mécanisme de sécurité. Les ULA servent à un contexte local, pour des machines qui n'ont pas besoin d'accéder à Internet ou pour avoir une interface qui a un préfixe fixe, si le préfixe GUA ne nous appartient pas.

Il n'y a pas de problème a adresser tous ces équipements en GUA (dont le frigo connecté qui a lui aussi besoin d'un accès Internet), si le pare-feu a l'entrée du réseau interdit tout trafic entrant.

kgersen · « **Réponse #4 le:** 25 février 2025 à 12:50:23 »

IPv6 a été conçu pour que toutes les machines aient une IPv6 public y compris le frigo. meme plusieurs.

les ULA ne sont pas conçues pour faire du NAT/PAT, le NAT est a proscrire en IPv6 (meme si ca existe). On a inventé IPv6 pour supprimer le NAT qui a été inventé a cause du manque d'adresses IPv4... la philosophie derriere IPv6 est une connectivité niveau 3 de bout en bout.

Les ULA sont conçues pour des relier des segments LAN entre eux avec des adresses privées (réseau étendu d'entreprise par exemple, containers, tunnels VPN, etc) car les link-local ne sont pas routables. Dans ce contexte une meme machine peux avoir une GUA (plusieurs en fait a cause des privacy extensions (rfc8981)) pour son accès Internet et une ou plusieurs ULA aussi pour acceder a des ressources privées.

Traiter et aborder IPv6 comme si c'etait IPv4 avec des adresses plus grandes est le meilleur moyen de mal faire les choses (on le répète souvent ici sur ces forums).

Quand on passe a IPv6 il faut mieux oublier ce qu'on faisait en IPv4 et repenser son réseau de zero.

Statefull DHCPv6 est a éviter si possible. SLAAC + éventuellement stateful DHCPv6 est la méthode recommandée.

oui la Freebox pèche niveau firewall IPv6 et encore y'en a un maintenant , pendant des années y'en avait pas du tout. C'est un gros probleme a mon avis mais elle a un mode bridge / routage des préfixes ipv6 donc ca peut se compenser avec son propre firewall.

Apres l'avenir c'est une simplification du réseau, lan d'entreprise ou lan (wifi) du macdo d'a coté c'est pareil. On ne fait plus de sécurité niveau 3/4 (access list, firewall, etc) mais au niveau 7 directement (application, authentification ,etc). Ca simplifie tout, notamment les PC pour le télétravail, etc. Tout les LAN sont considérés 'hostiles" et traité de la meme facon. Pourquoi parce aussi que les equipment's de sécurité niveau 3/4 ont du mal a suivre les débits fibres (10G et plus) ca devient cher et complexe (bon après les vendeurs de matos sécurité réseau diront bien sur le contraire).

Il reste les datacenters ou le traffic interne peut rester en IPv4 ou en IPv6 ULA et tout passe par des passerelles applicatives (firewall niveau 7, proxy, reverse proxy, etc). C'est de toute facon la "best practice" meme en IPv4.

Pendant des années on a recommandé le "dual stack", en grand public c'est facile, en entreprise c'est plutôt déconseillé il faut mieux faire du "ipv6 only" avec des ilots IPv4 et des mécanismes interop (DNS64/NAT64) ou juste des passerelles applicatives.

nbanba · « **Réponse #5 le:** 25 février 2025 à 12:57:11 »

Bonjour

En effet on ne parle pas d'1 mécanisme de sécurité
On parle juste d'une isolation publiques/privée au même titre que la séparation eaux grises /eaux brunes du service de collecte des eaux usées

Et depuis quand les ULA servent uniquement à un contexte local pour des machines ne devant pas accéder à internet ?
Il semble plutôt que ce soit le link local qui assume entre autre ce type de fonctions

Au niveau physique pure cette dichotomie publiques/privée sur le même segment a peu de sens et ouvre la porte à tous les 'magic packets'

Cordialement
nbanba

kgersen · « **Réponse #6 le:** 25 février 2025 à 13:14:32 »

Citation de: nbanba le 25 février 2025 à 12:57:11

Et depuis quand les ULA servent uniquement à un contexte local pour des machines ne devant pas accéder à internet ?

pas 'uniquement', on peut avoir toutes les combinaisons possibles deux (GUA, ULA et GUA, que ULA) et plusieurs de chaque.

Citation de: nbanba le 25 février 2025 à 12:57:11

On parle juste d'une isolation publiques/privée au même titre que la séparation eaux grises /eaux brunes du service de collecte des eaux usées
...
Au niveau physique pure cette dichotomie publiques/privée sur le même segment a peu de sens et ouvre la porte à tous les 'magic packets'

C'est un concept du passé et l'analogie n'est pas bonne.

Le trafic est de bout en bout, y'a pas d'eau grises et eaux brunes, une seule eau.

Apres ce genre de discussion tourne souvent au débat philosophique, surtout quand son propre métier (c'était mon cas) menace de disparaitre avec cette nouvelle façon de faire ou parce qu'on est trop dans le schéma mental du NAT et d'IPv4 qui la norme depuis 30 ans maintenant.

On peut faire les 2 méthodes de toute façon suivant son contexte, sa préférence.

nbanba · « **Réponse #7 le:** 25 février 2025 à 13:15:45 »

Citation de: kgersen le 25 février 2025 à 12:50:23

IPv6 a été conçu pour que toutes les machines aient une IPv6 public y compris le frigo. meme plusieurs.

les ULA ne sont pas conçues pour faire du NAT/PAT, le NAT est a proscrire en IPv6 (meme si ca existe). On a inventé IPv6 pour supprimer le NAT qui a été inventé a cause du manque d'adresses IPv4... la philosophie derriere IPv6 est une connectivité niveau 3 de bout en bout.

Les ULA sont conçues pour des relier des segments LAN entre eux avec des adresses privées (réseau étendu d'entreprise par exemple, containers, tunnels VPN, etc) car les link-local ne sont pas routables. Dans ce contexte une meme machine peux avoir une GUA (plusieurs en fait a cause des privacy extensions (rfc8981)) pour son accès Internet et une ou plusieurs ULA aussi pour acceder a des ressources privées.

Traiter et aborder IPv6 comme si c'etait IPv4 avec des adresses plus grandes est le meilleur moyen de mal faire les choses (on le répète souvent ici sur ces forums).

Quand on passe a IPv6 il faut mieux oublier ce qu'on faisait en IPv4 et repenser son réseau de zero.

Statefull DHCPv6 est a éviter si possible. SLAAC + éventuellement stateful DHCPv6 est la méthode recommandée.

oui la Freebox pèche niveau firewall IPv6 et encore y'en a un maintenant , pendant des années y'en avait pas du tout. C'est un gros probleme a mon avis mais elle a un mode bridge / routage des préfixes ipv6 donc ca peut se compenser avec son propre firewall.

Apres l'avenir c'est une simplification du réseau, lan d'entreprise ou lan (wifi) du macdo d'a coté c'est pareil. On ne fait plus de sécurité niveau 3/4 (access list, firewall, etc) mais au niveau 7 directement (application, authentification ,etc). Ca simplifie tout, notamment les PC pour le télétravail, etc. Tout les LAN sont considérés 'hostiles" et traité de la meme facon. Pourquoi parce aussi que les equipment's de sécurité niveau 3/4 ont du mal a suivre les débits fibres (10G et plus) ca devient cher et complexe (bon après les vendeurs de matos sécurité réseau diront bien sur le contraire).

Il reste les datacenters ou le traffic interne peut rester en IPv4 ou en IPv6 ULA et tout passe par des passerelles applicatives (firewall niveau 7, proxy, reverse proxy, etc). C'est de toute facon la "best practice" meme en IPv4.

Pendant des années on a recommandé le "dual stack", en grand public c'est facile, en entreprise c'est plutôt déconseillé il faut mieux faire du "ipv6 only" avec des ilots IPv4 et des mécanismes interop (DNS64/NAT64) ou juste des passerelles applicatives.

Bonjour

Désolé pas vu votre réponse avant mon dernier post ici.

Ce retour est intéressant et vous semblez bien informé.
Pourriez-vous fournir quelques sources pour illustrer ?

L'inspection L7 c'est ce qu'on fait tous (enfin je l'espère) mais elle nécessite des moyens peu accessibles pour les particuliers et pour le moment non gérés par les box grand publiques (sauf erreur de ma part)

Aussi avec la multiplication des app mobiles et du tls/ssl "pinning", il devient de plus en plus délicat pour madame Michu d'inspecter le trafic de son frigo et de l'appli IOS/Android associée sur son réseau ipv6 même avec sa propre pki

Merci
Cordialement
nbanba

kgersen · « **Réponse #8 le:** 25 février 2025 à 17:04:53 »

Le RIPE NCC a un bon training IPv6: https://learning.ripe.net/w/courses/3-ipv6-fundamentals-training-course (assez basic)

y'a ce livre qui fait une intro et donne des liens: https://www.daryllswer.com/ipv6-architecture-and-subnetting-guide-for-network-engineers-and-operators/

Les RFCs sur IPv6 sont de bonnes lectures.

Y'a une guide de l'ARCEP sur le déploiement IPv6 en entreprise, je ne l'ai pas lu: https://www.arcep.fr/la-regulation/grands-dossiers-internet-et-numerique/lipv6/task-force-ipv6.htm

Je n'ai pas parlé d'inspection L7. On n'inspecte plus trop car tout est chiffré (sauf éventuellement les ip source/dest on peut filtrer la Chine par exemple...)

La bonne pratique: on laisse tout passer et on fait du reverse proxy sur des gateway applicatives. en mode pull (le client va interroger un serveur) avec des sessions longues ou rafraichies.

Mme Michu n'a pas a inspecter le trafic de son frigo.

Dans les faits son frigo est un client web, donc tous ses ports sont fermés, il n'écoute rien.
C'est donc une boite noire qui peut-être 'a poil' sur Internet IPv6. Il va juste se connecter a un serveur web (en https), s'authentifier avec le service cloud de la marque du frigo et c'est tout. Ce n'est jamais dans le sens extérieur vers interieur, ni meme sur le LAN. En fait on traite le PC d'a coté sur le meme LAN comme un hostile aussi.

En général seul un statefull firewall L3 suffit donc si on veut un peu plus de protection. Mais meme ca ce n'est pas necessaire. C'est juste pour éviter un oubli ou un truc pas trop a jour.

A noter que les protocols L4 évoluent aussi. Il y a maintenant QUIC (sur UDP) qui remplace TCP+TLS de plus en plus (notamment chez les gros comme Google, Facebook, etc).

Beaucoup d'acteurs s'accordent a dire que l'avenir c'est IPv6 de bout en bout (GUA) et QUIC (chiffré donc) juste au dessus , au dessus chacun fait de qu'il veut. S'il n'y a plus de NAT , ca permet aussi le développement de nouveaux protocoles L4 et +. On est bloqué avec UDP ou TCP depuis 25+ ans a cause du NAT...

Si on veut de la sécurité point a point (style vpn), on a des solutions comme tailscale.com qui ne nécessite pas de serveur central (je recommande fortement).

nbanba · « **Réponse #9 le:** 25 février 2025 à 18:53:51 »

Bonjour

Merci beaucoup pour votre retour et les liens.
Le monde zero trust décrit est cependant bien parfait...
J'ai un exemple assez simple sous la main: 1 camera de sécurité fabriqué par un des leaders mondial de la vidéosurveillance.
Après contact avec cet éditeur suite à la découverte de vulnérabilités de type "authentication bypass", celui ci dit ne pas fournir de mises à jour pour les firmwares des caméras, en tout cas pour les modèles de cette série.
Derrière un routeur NAT, ce type de device n'est pas joignable directement sur internet, mais l'interface d'admin http(s) de la caméra est bien joignable en IPv6 sans un firewall statefull L3 en front
Espérons que ce "lent" passage à IPv6 permettra d'éduquer les éditeurs aux "bonnes pratiques" et au patching des CVE sur N années ...

Et perso le firgo connecté qui à 1 asic/1 SoC de moins d'1cm3 supportant une quelconque norme 802qqch et 300 lignes de code lui donnant de la connexion internet, eh bien je ne croirais jamais qu'il est armé pour une exposition directe à internet ! Et je suis à peu près certain qu'il n'y a même pas qq règles nftables dessus pour tout bloquer... Je dois devenir vieux et incrédule... mais je n'y crois pas.
Vous y croyez vraiment vous ?

Encore merci pour les détails et les liens
Cordialement
nbanba

kgersen · « **Réponse #10 le:** 25 février 2025 à 19:34:22 »

Citation de: nbanba le 25 février 2025 à 18:53:51

Et perso le firgo connecté qui à 1 asic/1 SoC de moins d'1cm3 supportant une quelconque norme 802qqch et 300 lignes de code lui donnant de la connexion internet, eh bien je ne croirais jamais qu'il est armé pour une exposition directe à internet ! Et je suis à peu près certain qu'il n'y a même pas qq règles nftables dessus pour tout bloquer... Je dois devenir vieux et incrédule... mais je n'y crois pas.

bloquer quoi ? si y'a pas de ports ouverts y'a pas besoin de nftables.

y'a un Linux minimaliste et une application cliente qui se connecte a un serveur dans le cloud.

Apres c'est certain que tous les constructeurs n'ont pas encore "solidifié" leur objects connectés a un monde sans NAT. Donc on recommande encore un statefull firewall sur les gateway domestiques.

y'a pas que le réseau qui a changé , les applications aussi.

avant une caméra connectée embarquait un serveur web, souvent sans authentification. Tu met ca en IPv6 GUA sans firewall c'est sur que c'est dangereux (encore qu'il faille trouver son ipv6).

de nos jours, les objets connectés n'ont pas de serveur web ou d'acces local (sauf pour la configuration et encore). Ce sont juste des clients web qui contacte un serveur dans le cloud (on peut regretté cela si on veut se faire une installation déconnectée d'Internet ou du provider du service).

par exemple: https://www.secureideas.com/blog/2019/10/security-review-of-nest-camera.html
La surface d'attaque est quasi nulle au niveau réseau. Tu peux mettre ce genre de caméra sur n'importe quel réseau wifi meme public.

d'ailleurs y'a des milliards d'objets connectés a poil sur Internet: les smartphones

Labure · « **Réponse #11 le:** 28 février 2025 à 23:08:00 »

Citation de: kgersen le 25 février 2025 à 19:34:22

Ce sont juste des clients web qui contacte un serveur dans le cloud (on peut regretté cela si on veut se faire une installation déconnectée d'Internet ou du provider du service).

Je suis d’accord, cette philosophie me gonfle, surtout pour des caméras. Perso, je n’en installe pas à cause de ça. Je n’ai pas envie de devoir faire confiance à des serveurs tiers pour lire mes caméras. Certains ici le font ?

Moi, je ne peux pas. Si je mets des caméras, elles devront tourner en local et ne dépendre d’aucun service cloud. Pour y accéder, ce sera par un VPN sur mon réseau local.

Et si le fournisseur ferme ses portes ou arrête le support, on fait quoi ?

Le nombre de devices achetés sur AliExpress, venant de Chine, et dont aucune mise à jour n’est disponible, ça fait vraiment peur. J’ai fait jeter à la poubelle une caméra qu’un pote avait chez lui : la société avait disparu et la caméra ouvrait des ports par UPNP (une grosse daube, ça aussi).

Pour revenir a la conversation d'origine je trouve aussi ça fou que free n'active pas le firewall IPv6 par default et qu'on puisse pas le configurer comme sur la livebox pour ouvrir des ports.