IPv6 sans NAT

Éditorial

Avec IPv6, chaque appareil d'un réseau domestique ou d'une petite structure reçoit une adresse joignable depuis internet, et la traduction d'adresses qui tenait lieu de protection disparaît. Le NAT n'a jamais été un pare-feu, mais il en tenait le rôle par accident : cet éditorial explique ce qui le remplace vraiment, ce que les adresses temporaires protègent et ne protègent pas, et ce qu'il faut vérifier sur sa box.

Mis à jour le 25 septembre 2026~25 min de lecture13 sections

papy cyber

Explication de la marmotte

Pendant longtemps, les appareils de la maison ont été protégés un peu par hasard, un peu comme dans un immeuble sans numéros sur les portes, où un inconnu ne sait pas où frapper. Avec la nouvelle version d’Internet, chaque appareil reçoit sa propre adresse. Ce texte explique ce qui garde vraiment la porte, et comment vérifier qu’elle est bien fermée.

→ Lire l’explication complète de la marmotte

Constats datés

Ce texte examine ce qui change pour la sécurité d’un petit réseau quand IPv6 attribue à chaque appareil une adresse globale. Les comportements des box et des systèmes varient selon les fournisseurs, les modèles et les versions logicielles, et ils évoluent : aucun modèle n’est décrit ici, seulement des mécanismes et des vérifications. Les éléments factuels datent de septembre 2026 ; le raisonnement devrait leur survivre, et il y a de bonnes chances qu’il survive aussi à la fin annoncée d’IPv4, qu’on annonce depuis que j’ai des cheveux.

La croyance qui protégeait les salons

Il existe, dans la population des gens raisonnables, une croyance aussi répandue que la conviction que les chats retombent toujours sur leurs pattes : celle que la box protège le réseau de la maison. On ne sait pas très bien comment, mais on sait qu’elle le fait. D’ailleurs, cela fait vingt ans que l’imprimante, la caméra du palier et le vieux serveur de fichiers dans le placard n’ont pas été piratés, ce qui constitue, pour l’esprit humain, une preuve à peu près aussi solide qu’une étude en double aveugle.

Cette croyance n’était pas fausse. Elle était juste pour de mauvaises raisons. Ce qui empêchait internet de joindre la caméra du palier, ce n’était pas une politique de sécurité décidée par quelqu’un de compétent : c’était une conséquence mécanique de la pénurie d’adresses IPv4. Le foyer n’avait qu’une adresse publique ; les appareils se partageaient cette adresse par traduction ; et un paquet arrivant de l’extérieur sans avoir été attendu ne savait tout simplement pas à qui s’adresser. La protection était un effet secondaire de la pauvreté, comme la sobriété de ceux qui n’ont pas de quoi s’offrir un verre.

IPv6 met fin à la pauvreté. Chaque appareil reçoit une adresse globale, routable, joignable en principe depuis n’importe quel point d’internet. Le NAT disparaît, puisqu’il n’y a plus rien à traduire. Et avec lui disparaît l’effet secondaire.

La thèse de cet éditorial est que cette disparition n’est pas un problème en soi, à une condition précise : que la protection qui fonctionnait vraiment, et qu’on attribuait à tort au NAT, soit présente et active. Elle a un nom, le pare-feu à états, et elle est presque toujours déjà là. Presque toujours. Tout le sujet tient dans cet adverbe.

Ce que faisait réellement le NAT

Il faut commencer par démonter la machine, parce que la confusion vient de ce qu’on a toujours regardé l’ensemble sans en distinguer les pièces.

Une box IPv4 ordinaire fait, pour le trafic sortant, deux choses en même temps.

Elle traduit. Quand la tablette envoie un paquet vers un serveur, la box remplace l’adresse privée de la tablette par l’adresse publique du foyer, et souvent le port source par un port choisi par elle. Elle note la correspondance dans une table. Quand la réponse revient, elle consulte la table et remet l’adresse privée d’origine.

Elle suit les connexions. Pour pouvoir traduire les réponses, la box doit savoir quelles connexions sont en cours, dans quel état, et depuis quand. C’est une table d’états, la même que celle qu’utilise un pare-feu à états.

Un paquet qui arrive de l’extérieur sans correspondre à aucune entrée de la table n’a pas de destination interne connue. La box, ne sachant qu’en faire, le jette, ou le traite elle-même s’il s’adresse à un service qu’elle expose. C’est ce comportement qu’on a baptisé « protection du NAT ».

Or ce comportement n’est pas une politique, c’est une incapacité. La box ne refuse pas le paquet parce qu’elle a décidé qu’il était indésirable ; elle le refuse parce qu’elle ne sait pas où l’envoyer. La différence paraît byzantine. Elle cesse de l’être dès qu’on regarde les cas où l’incapacité disparaît.

Les redirections de port. Dès qu’on configure une redirection, pour une console de jeu, une caméra ou un serveur domestique, on crée une entrée permanente : la box sait désormais où envoyer. La prétendue protection s’efface pour ce port, sans filtrage, sans journal, sans limite de source.

Les ouvertures automatiques. Les protocoles d’ouverture automatique, dont UPnP est le plus répandu, permettent à un appareil du réseau local de demander à la box d’ouvrir un port à son profit. Aucune authentification sérieuse n’est demandée : il suffit d’être sur le réseau local. Un appareil connecté mal conçu, ou un logiciel malveillant, peut ainsi s’exposer lui-même sans que personne ne l’ait décidé. Le NAT, dans ce cas, n’est pas une porte fermée, c’est une porte dont chacun des locataires a la clé et le droit de faire des doubles.

Les comportements de filtrage laxistes. Toutes les traductions ne filtrent pas de la même façon. Certaines, une fois une correspondance créée pour un port, acceptent des paquets venant de n’importe quelle adresse extérieure vers ce port, et pas seulement du serveur contacté. C’est utile pour certaines applications en pair à pair, et c’est une ouverture que personne n’a vraiment choisie.

Les attaques qui ne viennent pas de l’extérieur. Le NAT ne fait rien contre ce qui est déjà dedans : l’appareil compromis, le visiteur sur le Wi-Fi, la page web malveillante qui fait exécuter au navigateur des requêtes vers les adresses internes. Il n’a jamais prétendu le faire, mais on lui a prêté cette vertu par une généralisation que rien ne justifiait.

Ce que la page consacrée au NAT et à la publication de services résume sobrement, je le dis plus brutalement : le NAT n’a jamais été un pare-feu. Il a seulement, par une coïncidence d’architecture, empêché ce qu’un pare-feu aurait empêché, tant que personne ne lui demandait rien.

Ce qui protégeait vraiment : la table d’états

Si l’on retire la traduction et qu’on garde la table d’états, qu’obtient-on ? Un pare-feu à états avec une politique simple : le trafic sortant est autorisé, les réponses au trafic sortant sont autorisées, le trafic entrant non sollicité est refusé.

C’est exactement la protection qu’on attribuait au NAT, et elle est meilleure. Elle est explicite : on peut la lire, la vérifier, la journaliser. Elle est paramétrable : on peut ouvrir un port vers un appareil précis, pour une source précise, et le refermer. Et elle ne dépend pas d’une incapacité : elle refuse parce qu’on lui a dit de refuser.

Les recommandations de l’IETF pour les équipements d’accès résidentiels en IPv6 décrivent depuis longtemps ce comportement par défaut : filtrer le trafic entrant non sollicité, laisser passer ce qui relève du fonctionnement normal du protocole, et permettre à l’utilisateur d’ouvrir explicitement ce qu’il veut publier. La plupart des box actuelles l’appliquent. Toutes ne l’ont pas toujours fait, et toutes ne le font pas dans la configuration où elles sont livrées.

Il faut ici dissiper une confusion fréquente. On entend parfois qu’IPv6 « expose » les appareils parce qu’ils ont une adresse publique. C’est mélanger deux choses : être adressable et être joignable. Une adresse publique rend un appareil adressable, c’est-à-dire qu’un paquet peut lui être destiné. Qu’il soit joignable dépend de ce que laissent passer les équipements sur le chemin. Derrière un pare-feu à états correctement réglé, un appareil doté d’une adresse IPv6 globale n’est pas plus joignable depuis internet que son équivalent IPv4 derrière un NAT. Il est même mieux protégé, puisque les ouvertures y sont explicites.

L’IPv6 n’a donc pas créé le problème. Il a retiré une béquille, et l’on s’aperçoit qu’on ne savait pas si l’on avait des jambes.

Chaque appareil a une adresse : ce qui change vraiment

Si le pare-feu fait son travail, qu’est-ce qui change réellement ? Plus qu’on ne le dit, et pas forcément là où on le cherche.

L’erreur de configuration devient immédiatement exploitable. Avec le NAT, un pare-feu mal réglé laissait encore la traduction faire barrage par défaut. Sans NAT, le pare-feu est la seule barrière. S’il est désactivé, réglé en mode « ouvert », ou si une mise à jour de la box change son comportement, tous les appareils du foyer deviennent joignables d’un coup. Il n’y a plus de deuxième ligne par accident. On passe d’un régime où l’erreur était rattrapée par l’architecture à un régime où elle est rattrapée par personne.

Chaque appareil devient responsable de ce qu’il écoute. Sur un réseau à NAT, un appareil pouvait écouter sur tous les ports sans conséquence visible depuis l’extérieur. Sur un réseau IPv6, s’il existe une ouverture (volontaire, automatique ou accidentelle), c’est l’appareil lui-même qui reçoit le paquet. Les objets connectés, dont la page consacrée aux réseaux personnels et à l’IoT décrit la fragilité, n’ont souvent jamais été conçus pour cette éventualité. Leur pile réseau a été écrite par des gens pressés, testée par des gens optimistes et mise à jour par personne.

Le préfixe identifie le foyer. Chaque foyer reçoit de son fournisseur un préfixe, souvent stable dans le temps, dont les appareils tirent leurs adresses. Même si l’identifiant de chaque appareil change, le préfixe, lui, désigne le foyer. Pour la vie privée, c’est un identifiant au moins aussi précis que l’adresse IPv4 publique d’autrefois, et parfois plus durable, selon la politique du fournisseur.

Les ouvertures automatiques changent de nature. Les protocoles d’ouverture de port existent aussi en IPv6, et ils n’ont plus à gérer de traduction : ils ouvrent un trou, un « pinhole », directement vers l’adresse de l’appareil. Si la box les accepte, un appareil du réseau local peut encore s’exposer lui-même. Le risque est le même qu’en IPv4 ; il est seulement plus direct.

La publication devient simple, donc tentante. Héberger un service à la maison ne demande plus de redirection de port ni de bricolage : il suffit d’ouvrir le pare-feu vers l’adresse de la machine. C’est une bonne nouvelle pour ceux qui savent ce qu’ils font, et une nouvelle nettement moins bonne pour ceux qui croient le savoir.

Le mythe du réseau introuvable

Un argument revient souvent pour rassurer : un réseau IPv6 domestique contient, pour un seul segment, un nombre d’adresses possibles si astronomique que le balayage systématique est impossible. Un attaquant qui voudrait essayer toutes les adresses d’un sous-réseau y passerait un temps qui ferait passer l’âge de l’univers pour une pause café. Donc personne ne trouvera jamais la caméra du palier.

La première moitié du raisonnement est exacte. La seconde est une imprudence.

Le balayage aveugle est effectivement vain. Essayer au hasard les adresses d’un sous-réseau de taille standard n’a aucune chance de rien trouver. De ce point de vue, IPv6 rend obsolète une technique qui, en IPv4, permettait de parcourir tout internet en quelques heures.

Mais personne ne cherche au hasard. Les adresses ne sont pas réparties uniformément dans l’espace, et il existe de nombreuses façons de les trouver sans balayer.

Les adresses prévisibles. Les adresses configurées à la main suivent souvent des motifs faciles à deviner : les premières valeurs du sous-réseau, des suites simples, des mots écrits en hexadécimal. Les routeurs et serveurs en particulier en portent volontiers. Les appareils qui dérivent encore leur identifiant de leur adresse matérielle (le mode dit EUI-64, que la page sur l’autoconfiguration IPv6 décrit) réduisent l’espace à explorer aux plages de numéros attribués à chaque fabricant, ce qui reste grand mais n’est plus astronomique, et révèle au passage la marque de l’appareil à quiconque sait lire.

Les fuites. Chaque fois qu’un appareil contacte un serveur, il lui communique son adresse. Les serveurs journalisent, les journaux se partagent, les services publics très sollicités voient passer des adresses par millions. Les enregistrements DNS publics, les en-têtes de courriel, les traces laissées dans des protocoles bavards : autant de sources à partir desquelles on peut constituer des listes d’adresses actives, puis explorer leur voisinage. Des travaux de recherche publics ont montré que ce genre de collecte permettait de découvrir une part significative des adresses réellement utilisées, sans le moindre balayage exhaustif.

Le préfixe suffit parfois. Connaître le préfixe d’un foyer, obtenu par n’importe laquelle des fuites précédentes, permet de concentrer la recherche sur des identifiants plausibles dans ce préfixe.

La conclusion ne fait pas plaisir, mais elle est simple : la taille de l’espace d’adressage n’est pas une mesure de sécurité. C’est une propriété qui gêne l’attaquant le plus paresseux, ce qui n’est pas négligeable, mais qui ne remplace en rien un filtrage. Compter sur l’obscurité d’une adresse pour protéger un service, c’est cacher la clé sous un paillasson d’une taille galactique, en laissant sur chaque lettre envoyée l’adresse du paillasson.

Adresses temporaires : ce qu’elles protègent, et ce qu’elles ne protègent pas

IPv6 prévoit plusieurs manières de fabriquer l’identifiant d’interface, c’est-à-dire la seconde moitié de l’adresse. Elles ont des propriétés différentes, et elles répondent toutes à une question de vie privée, pas de contrôle d’accès.

L’identifiant dérivé de l’adresse matérielle est le mode historique. Il est stable, il suit l’appareil d’un réseau à l’autre, et il permet donc de reconnaître le même appareil au café, au bureau et à la maison. C’est un défaut de vie privée tellement évident qu’on se demande qui a pu le trouver acceptable ; la réponse est qu’à l’époque, personne ne pensait qu’on promènerait des ordinateurs dans sa poche.

L’identifiant stable mais opaque est dérivé d’un secret local et du préfixe du réseau. Il est constant sur un réseau donné, ce qui est pratique pour les services et le diagnostic, mais différent d’un réseau à l’autre, ce qui empêche le suivi de l’appareil entre réseaux.

Les adresses temporaires sont aléatoires et renouvelées régulièrement, typiquement de l’ordre d’une journée pour leur durée préférée. L’appareil les utilise pour ses connexions sortantes, si bien qu’un serveur contacté ne peut pas, à partir de l’identifiant, relier les visites d’un jour à celles du lendemain.

Voilà pour ce qu’elles protègent. Voici ce qu’elles ne protègent pas.

Elles ne cachent pas le foyer. Le préfixe reste le même. Un serveur qui voit défiler plusieurs adresses temporaires dans le même préfixe sait qu’il a affaire au même foyer, exactement comme il le savait en IPv4 avec l’adresse publique partagée.

Elles ne ferment aucun port. Une adresse temporaire est une adresse supplémentaire, pas une adresse de remplacement. L’appareil conserve en général une adresse stable à côté, et un service qui écoute sur toutes les interfaces écoute sur toutes les adresses, temporaires comprises. Si le pare-feu laisse passer, l’adresse temporaire n’y change rien.

Elles ne concernent pas tous les appareils. Les systèmes des ordinateurs et des téléphones récents les activent généralement par défaut, avec des variations selon les distributions. Les objets connectés, les imprimantes, les téléviseurs font ce que leur fabricant a décidé, ce qui recouvre un spectre allant de l’excellent au navrant.

Il est utile de savoir ce que font ses propres machines :

# Linux : adresses IPv6 globales, avec leur caractère temporaire ou non
ip -6 addr show scope global

# Linux : politique d'adresses temporaires (0 = désactivées,
# 1 = générées mais non préférées, 2 = générées et préférées)
sysctl net.ipv6.conf.all.use_tempaddr net.ipv6.conf.default.use_tempaddr

# Linux : mode de génération de l'identifiant stable
sysctl net.ipv6.conf.default.addr_gen_mode

# Windows (invite de commandes) : état des adresses temporaires
netsh interface ipv6 show privacy

# Windows (PowerShell) : adresses IPv6 et leur origine
Get-NetIPAddress -AddressFamily IPv6 | Format-Table IPAddress, PrefixOrigin, SuffixOrigin

Pour les objets connectés, la vérification se fait depuis la box, qui liste souvent les appareils et leurs adresses. Un identifiant qui contient la séquence caractéristique ff:fe en son milieu trahit généralement un identifiant dérivé de l’adresse matérielle.

La découverte et le lien local

Il reste un domaine où IPv6 change la sécurité à l’intérieur du réseau, indépendamment de l’extérieur, et il est trop souvent ignoré parce qu’il ne se voit pas depuis internet.

IPv6 remplace le protocole de résolution d’adresses d’IPv4 par un mécanisme de découverte des voisins porté par ICMPv6, et confie aux routeurs le soin d’annoncer le préfixe et la route par défaut au moyen d’annonces périodiques. C’est élégant, sans état, et cela a une propriété déplaisante : sur un réseau local, n’importe quel appareil peut prétendre être un routeur. Un appareil compromis, ou simplement mal configuré, qui émet des annonces de routeur peut détourner le trafic de ses voisins, leur attribuer un préfixe fantaisiste ou se placer au milieu de leurs échanges. C’est l’équivalent IPv6 des attaques par empoisonnement de résolution d’adresses, en plus commode.

Les commutateurs d’entreprise disposent de protections (le filtrage des annonces de routeur sur les ports où aucun routeur n’est attendu). Les réseaux domestiques n’en ont généralement pas, et la page consacrée à la résolution locale et à ICMP rappelle que ces mécanismes sont la face cachée de la configuration automatique.

Deux conséquences pratiques.

IPv6 est souvent actif là où l’on croit qu’il ne l’est pas. Les systèmes modernes l’activent par défaut et se configurent dès qu’une annonce de routeur passe. Un réseau que son propriétaire croit « en IPv4 uniquement » peut très bien héberger un trafic IPv6 local, voire global si un appareil annonce un préfixe. Désactiver IPv6 sur la box ne le désactive pas sur les appareils ; cela les laisse simplement à l’écoute du premier qui voudra leur en proposer.

ICMPv6 ne se filtre pas comme ICMP. Des générations d’administrateurs ont appris qu’on bloque ICMP à la frontière par hygiène. En IPv6, c’est une erreur : la découverte des voisins, la découverte de la taille maximale des paquets sur le chemin et d’autres fonctions essentielles reposent sur ICMPv6. Le bloquer en bloc casse des connexions de façon intermittente et incompréhensible, ce qui est le pire genre de panne. Il faut filtrer finement, en laissant passer les types nécessaires, ce que les pare-feu de box font en principe d’eux-mêmes.

Ce qu’il faut vérifier sur sa box

Venons-en aux vérifications. Elles ne demandent aucune compétence particulière, seulement un peu de méthode et l’accès à l’interface d’administration de la box.

Le pare-feu IPv6 existe-t-il, et dans quel mode ? Cherchez dans l’interface une rubrique consacrée au pare-feu, et plus précisément à IPv6. Certaines box proposent plusieurs niveaux, dont un mode qui laisse tout passer en entrée. Le réglage attendu bloque le trafic entrant non sollicité. Si la box ne propose aucun réglage de pare-feu IPv6, il faut se renseigner auprès du fournisseur sur son comportement par défaut, et ne pas le deviner.

Quelles ouvertures existent ? Listez les ouvertures de port ou de pare-feu IPv6 configurées. Chacune doit correspondre à un besoin que vous connaissez. Celles dont personne ne se souvient sont à fermer, avec la philosophie de celui qui vide son grenier : si l’on ne sait plus à quoi cela sert, c’est que cela ne sert plus.

Les ouvertures automatiques sont-elles autorisées ? Si la box permet à UPnP ou à un protocole équivalent d’ouvrir des ports, y compris en IPv6, demandez-vous si vous en avez besoin. Certaines consoles de jeu et applications de visioconférence s’en servent ; la plupart des foyers vivent très bien sans. Si vous le laissez actif, consultez régulièrement la liste des ouvertures qu’il a créées.

Le préfixe est-il stable ? Selon le fournisseur, le préfixe délégué peut être fixe ou changer. Cela n’a pas de conséquence directe sur la sécurité, mais cela en a sur la vie privée et sur les règles de pare-feu qui feraient référence à des adresses précises.

Qu’écoutent les appareils ? Sur les machines que vous administrez, regardez ce qui écoute en IPv6 :

# Linux : services en écoute sur IPv6 (TCP et UDP), avec le processus
sudo ss -6 -tulnp

Un service qui écoute sur [::] écoute sur toutes les adresses IPv6 de la machine. C’est souvent voulu. Parfois non.

Tester depuis l’extérieur. La seule vérification qui compte vraiment se fait depuis un autre réseau, puisque c’est de là que viendrait l’attaque. Un téléphone en partage de connexion sur le réseau mobile, s’il dispose d’IPv6, suffit. Depuis un ordinateur connecté à ce partage, on peut vérifier si les ports d’une de ses propres machines sont joignables :

# Depuis un AUTRE réseau, vers l'adresse IPv6 globale d'une de VOS machines
# -Pn : ne pas se fier au ping, tester les ports directement
nmap -6 -Pn -p 22,80,443,445,3389,8080 2001:db8:1234:5678::abcd

Uniquement vos propres adresses

Tester les ports d’une machine qui ne vous appartient pas, ou sans l’accord de son responsable, peut être illégal et est toujours discourtois. Remplacez l’adresse d’exemple (qui appartient à une plage réservée à la documentation) par celle d’une de vos propres machines, et limitez-vous à cela. Certains opérateurs mobiles filtrent eux-mêmes une partie du trafic : un résultat « filtré » peut venir de leur côté et non de votre box. En cas de doute, recoupez avec un service de test externe dont vous connaissez l’exploitant.

Le résultat attendu, derrière une box correctement réglée, est que tous les ports apparaissent filtrés, sauf ceux que vous avez explicitement ouverts. Un port ouvert que vous n’attendiez pas est une découverte précieuse ; elle ne vous rend pas service, mais elle vous le rendra.

Segmenter si possible. Beaucoup de box proposent un réseau invité. Y placer les objets connectés les moins fiables, en plus des visiteurs, réduit ce qu’un appareil compromis peut atteindre. La page sur le filtrage et la segmentation développe le principe ; à l’échelle d’un foyer, un réseau invité en est la version modeste, et c’est déjà beaucoup.

Le meilleur argument contraire : remettre du NAT, ou couper IPv6

Il existe une position qui refuse toute la démonstration précédente, et elle a des partisans sérieux.

Elle dit ceci. Puisque la protection par NAT marchait, pourquoi s’en priver ? Il existe des mécanismes de traduction pour IPv6, qu’il s’agisse de traduction d’adresses complète ou de traduction de préfixe. On peut attribuer des adresses privées aux appareils et traduire à la frontière, comme en IPv4. On garde ainsi la défense en profondeur : même si le pare-feu est mal réglé, les adresses internes ne sont pas routables depuis l’extérieur.

Et elle va plus loin. Pour un particulier ou une petite structure sans compétences réseau, le plus sûr est de désactiver IPv6. On revient en terrain connu, on supprime une surface que personne ne maîtrise, et l’on ne perd rien, puisque presque tout internet reste accessible en IPv4.

Je reconnais à cet argument une qualité : il part d’un constat vrai. La défense en profondeur vaut mieux qu’une barrière unique, et une box dont on ne connaît pas le comportement IPv6 est un inconnu qu’on a raison de craindre.

Je m’en sépare pourtant, pour trois raisons.

Le NAT en IPv6 ne restaure pas la protection, il en restaure l’illusion. Ce qui empêchait les paquets d’entrer, on l’a vu, c’était la table d’états, pas la traduction. Une traduction sans table d’états n’empêche rien ; une traduction avec table d’états n’apporte rien de plus que la table d’états seule. Quant à la traduction de préfixe, qui est sans état par conception, elle ne filtre rien du tout : elle réécrit les adresses dans les deux sens, et un appareil derrière elle reste joignable. On réintroduirait une complexité réelle pour une protection qui venait d’ailleurs. On y perdrait en outre la simplicité du bout en bout, ce qui casse certains usages et oblige à réinventer les contournements qu’IPv4 avait déjà rendus pénibles.

Désactiver IPv6 sur la box ne le désactive pas dans le réseau. Les appareils continuent de le parler entre eux sur le lien local, et restent prêts à accepter le premier routeur qui se présentera. On supprime la surface qu’on voit pour conserver celle qu’on ne voit pas. C’est une mesure de confort psychologique plus que de sécurité.

Le terrain connu recule. Une part croissante du trafic passe en IPv6, certains fournisseurs attribuent déjà des adresses IPv4 partagées entre clients, et les usages futurs supposent de plus en plus IPv6. Désactiver IPv6, c’est repousser un apprentissage qu’il faudra faire, et le faire plus tard dans de moins bonnes conditions.

Là où l’argument a raison, je le rejoins : si l’on ne peut pas vérifier le comportement du pare-feu IPv6 de sa box, et qu’on n’a pas besoin d’IPv6, le désactiver à la box est un pis-aller défendable, en attendant de pouvoir vérifier. Mais c’est un pis-aller, et il faut savoir qu’il ne règle pas le lien local.

Ce que je ne sais pas

Je ne connais pas le comportement par défaut de chaque box. Les fournisseurs, les modèles et les versions logicielles diffèrent, et les réglages changent au fil des mises à jour. Tout cet éditorial suppose qu’on vérifie la sienne ; il ne peut pas le faire à votre place, et je me garde de désigner des bons et des mauvais élèves sur la foi de souvenirs.

Je ne sais pas mesurer l’exposition réelle des réseaux domestiques en IPv6. Des travaux de recherche ont montré que la découverte d’adresses était possible à grande échelle ; ce qu’ils disent de la proportion de foyers effectivement joignables, et de l’évolution de cette proportion, je ne peux pas le résumer avec assez de certitude pour l’écrire.

Je ne sais pas ce que feront les objets connectés. Leur gestion d’IPv6 est aussi hétérogène que leur qualité logicielle en général. Certains sont irréprochables, d’autres exposent des services inattendus sur toutes leurs adresses. Aucune règle générale n’est possible, seulement une vérification au cas par cas.

Je ne sais pas comment évolueront les protocoles d’ouverture automatique. Leur prise en charge en IPv6 par les box et les applications est inégale, et les règles de sécurité qu’ils appliquent (qui a le droit d’ouvrir quoi) varient. C’est un point à surveiller plus qu’un point que je peux trancher.

Ce qui reste

Le NAT nous a rendu un service, et nous l’en avons remercié en lui attribuant une vertu qu’il n’avait pas. C’est une forme d’ingratitude assez courante envers les objets : on leur prête des intentions quand ils ont seulement des limites.

Trois choses me semblent acquises. Que la protection venait de la table d’états, et pas de la traduction : IPv6 garde la première et retire la seconde, si bien que rien d’essentiel n’est perdu, à condition que la table d’états soit présente, active et réglée pour refuser l’entrant non sollicité. Que l’erreur n’est plus rattrapée par l’architecture : sans NAT, un pare-feu mal réglé est une porte ouverte, et c’est une raison de vérifier plutôt qu’une raison de revenir en arrière. Et que les adresses temporaires relèvent de la vie privée, pas du contrôle d’accès, pas plus que la taille de l’espace d’adressage ne relève de la sécurité : elles compliquent le suivi et le balayage, elles ne ferment aucune porte.

Le reste tient en une courte liste de vérifications, à faire une fois puis à chaque changement de box ou de mise à jour majeure : le mode du pare-feu IPv6, la liste des ouvertures, les ouvertures automatiques, ce qu’écoutent les machines, et un test depuis l’extérieur. Une demi-heure, un téléphone, et parfois une surprise.

Il est d’ailleurs assez réjouissant que la réponse à une question de sécurité posée par un protocole moderne consiste, pour l’essentiel, à aller lire les réglages de sa box. C’est la sécurité domestique dans ce qu’elle a de plus noble : un mélange de rigueur technique et de spéléologie dans des menus mal traduits.

🐝 Ce qui arrive si on s’en passe

Sans pare-feu à états actif sur la box, chaque appareil du foyer répond directement à Internet avec ce qu’il a sous le capot, et ce sont rarement les machines les mieux tenues : imprimantes, caméras et téléviseurs exposent des services pensés pour un salon, dont le micrologiciel n’est mis à jour par personne. Une compromission par cette voie ne laisse aucune trace sur la box, qui s’est contentée d’acheminer des paquets, et l’appareil touché n’a souvent aucun moyen de montrer ce qu’on lui a fait. Le préfixe stable du foyer permet en outre de revenir, jour après jour, exactement au même endroit, pendant que le propriétaire continue de croire que la box veille.

🦫 Explication de la marmotte 🍫

Chaque appareil connecté à Internet a besoin d’une adresse. Avec l’ancienne version du protocole Internet, IPv4, les adresses sont rares : un foyer n’en reçoit qu’une, partagée par tous ses appareils grâce à la box. Pour cela, la box pratique la traduction d’adresses, appelée NAT : elle remplace l’adresse interne de chaque appareil par l’adresse du foyer et note dans une table chaque connexion en cours. Quand un paquet arrive de l’extérieur sans correspondre à une connexion connue, la box ne sait pas à qui l’envoyer et le jette. Ce refus servait de protection, mais il venait de la table des connexions, pas de la traduction. Avec IPv6, la nouvelle version, les adresses sont si nombreuses que chaque appareil reçoit la sienne, et la traduction disparaît. La protection reste possible grâce à un pare-feu à états : il laisse sortir le trafic, accepte les réponses et refuse ce qui arrive sans avoir été demandé. S’il est désactivé ou mal réglé, tous les appareils deviennent joignables d’un coup. Le nombre immense d’adresses ne protège pas, car les adresses fuient ou se devinent. Les adresses temporaires, renouvelées environ chaque jour, limitent le suivi d’un appareil mais ne ferment aucun accès. Sur le réseau local, n’importe quel appareil peut se déclarer routeur et détourner le trafic de ses voisins. Il faut donc vérifier le pare-feu de la box et ses ouvertures, puis tester depuis un autre réseau.

À lire aussi

• Pare-feu, architectures et NAT en une pageFiltrage sans état, pare-feu à états, proxy applicatif, DMZ et NAT : ce qui laisse passer un paquet, ce qui le refuse, et pourquoi le NAT n'y est pour rien, sur un schéma animé.
• L'adressage IP en une pagePréfixe, masque, sous-réseaux, plages réservées et différences IPv4/IPv6 : l'adressage IP résumé sur un seul schéma, idées reçues comprises.
• WireGuard et VPN maillés, fonctionnement, AllowedIPs et limitesCe que WireGuard garantit, ce qu'il laisse volontairement de côté, et ce que les réseaux maillés bâtis dessus changent pour l'architecture et la confiance.
• Le DNS, le protocole qu'on ne regarde jamaisChaque connexion commence par une question posée en clair à un résolveur que l'on n'a, le plus souvent, pas choisi. DNSSEC, DoT et DoH corrigent chacun une partie du problème, et aucun ne dispense de la vraie décision : à qui confier la liste de tout ce qu'on consulte.

Pages voisines

La citent

• Pare-feu, architectures et NAT en une page

IPv6 sans NAT

Elle cite

• ⇄Lien dans les deux sens :IPv6, autoconfiguration et coexistence
• ⇄Lien dans les deux sens :NAT, translations et publication de services
• ⇄Lien dans les deux sens :Résolution locale, ICMP, MTU et multicast
• Concevoir une défense en profondeur par couches
• Filtrage, segmentation, NAC et Zero Trust
• Réseaux personnels, IoT et objets contraints
• Sécuriser les caméras IP et le stockage vidéo cloud
• Sécuriser les imprimantes réseau en entreprise

⇄ : les deux pages se citent l’une l’autre.