Journal Routage avancé avec marquage de paquet et rp_filter

Posté par  . Licence CC By‑SA.
15
22
sept.
2018

Sommaire

Aujourd'hui, c'est routage. Je pars du principe que vous savez ajouter une route IP, utiliser un minimum ip rule, et une bonne connaissance de iptables.

Ce journal est dupliqué (en anglais) sur ServerFault.

Problème

J'ai une Freebox en mode bridge avec liaison ADSL, une Livebox en mode DMZ avec liaison fibre optique.
Je veux faire passer la majorité du trafic via la Freebox, et du trafic particulier via la Livebox.
C'est comme ça, et si c'était l'inverse, ce serait pareil.

Je vais parler, pour faire simple, du trafic qui transite par le routeur sous Debian GNU/Linux, et pas du trafic qui est généré par ce routeur.

Mon adresse ADSL est 82.236.xxx.xxx et fibre 90.76.xxx.xxx.

Ce qui devrait marcher

On part du principe que la table mangle est vierge.

> ip route show table livebox
default via 192.168.1.1 dev eth_livebox src 192.168.1.253 
82.236.xxx.0/24 dev eth_adsl scope link src 82.236.xxx.xxx 
192.168.0.0/24 dev bridge_local scope link src 192.168.0.253 
192.168.1.0/24 dev eth_livebox scope link src 192.168.1.253 

iptables -t mangle -I PREROUTING --destination 23.23.114.123 -j MARK --set-mark 1
ip rule add from all fwmark 0x1 lookup livebox

Et ça, ça ne marche pas. C'est-à-dire que quand je fais

curl http://api.ipify.org/ --resolve api.ipify.org:80:23.23.114.123

depuis un client sur le réseau local du routeur, ça ne renvoie rien.

Ce qui marche

La table livebox ne change pas.
Par contre, après vidage de la table mangle, on fait ceci :

iptables -t mangle -I PREROUTING --source 23.23.114.123 -j TOS --set-tos 0x10
iptables -t mangle -I PREROUTING --destination 23.23.114.123 -j TOS --set-tos 0x10
ip rule add from all tos 0x10 lookup livebox

Et là :

> curl http://api.ipify.org/ --resolve api.ipify.org:80:23.23.114.123
90.76.xxx.xxx

Pourquoi ?

Entre les deux tentatives, j'ai changé deux choses :
1. J'ai utilisé l'entête TOS du paquet IP au lieu de la marque de pare-feu gérée en interne par le noyau et ses modules.
2. J'ai marqué les paquets qui reviennent.

J'ai menti (par omission) : rp_filter

J'ai oublié de dire que sur toutes mes interfaces, le paramètre rp_filter est à 1.
D'après la documentation du noyau, la valeur de 1 correspond à une vérification stricte du chemin (de routage) inverse selon la RFC 3704.
Pour faire simple, lorsqu'un paquet arrive par une interface, le noyau inverse les champs source et destination des adresses IP et tente de choisir un chemin de routage. Si le chemin choisi sort par l'interface dont vient le paquet, c'est bon, ça passe. Sinon, le paquet est ignoré.

Donc, d'après ma section Ce qui devrait marcher, vu que le paquet qui rentre n'est pas marqué avec la valeur 1, la vérification de routage inverse échoue. En effet, le paquet arrive par l'interface eth_livebox mais sans marque, c'est la table main qui est consulté, et dans cette table, le paquet sort par l'interface eth_adsl. C'est un échec. Et c'est donc la raison du changement nº2.

Pourquoi TOS et pas MARK ?

Ah. Oui, évidemment, j'ai essayé d'utiliser -j MARK sur les paquets qui reviennent. Et ça ne marche pas. À force de chercher, je suis tombé sur ce vieux message :

OK, looking at fib_validate_source(), it looks like how rp_filter
works is just that the kernel takes the packet, reverses src & dst
addrs and interfaces, and tries to do a routing lookup. It totally
ignores marking when building the routing key, but weirdly enough,
it does check the TOS.

Ah. Donc je me documente un peu, et comme je suis en recherche de solution, je fais du vite fait mal fait. Et ça marche. C'est donc la raison du changement nº1.

Peut-on faire mieux ?

Je vous laisse regarder par vous-même le code de fib_validate_source(). Personnellement, c'est trop pour moi :)

Mais pour moi, le résultat est incohérent. Je sais bien que TOS fait partie de l'en-tête IP, et que les marques sont des attributs spécifiques à l'hôte. Sauf que voilà, ip rule permet justement de faire une route soit sur la valeur de l'en-tête TOS, soit sur la valeur d'une marque du pare-feu avec fwmark.

Je suis un peu partagé sur la suite, et voici les solutions, non exclusives d'ailleurs.

Laisser tomber rp_filter sur les interfaces publiques

Le but de rp_filter, c'est d'éviter les DDoS, mais aussi d'éviter de laisser sortir des paquets de clients un peu malicieux sur le réseau public. C'est un peu comme SPF, ça protège les autres.
Sur mes interfaces publiques, j'ai déjà une règle de routage de type defaut via IP, donc de toutes façons, rp_filter va dire « ah ouais ok, c'est bon, je vais pouvoir lui répondre ». Et effectivement, si un paquet est arrivé jusque là, bon, c'est que mes fournisseurs d'accès l'ont laissé passer, et surtout ont réussi à le router.

Donc je pourrais laisser tomber et mettre rp_filter à 0 sur ces interfaces (attention, c'est la valeur maximale entre net.ipv4.conf.eth_livebox.rp_filter et net.ipv4.conf.all.rp_filter qui est appliquée).

Rapporter ce « bogue » aux développeurs du noyau

Pour moi, c'est vraiment incohérent, et surtout mal documenté. D'un côté ip rule permet de faire des règles qui marchent pour les paquets qui sortent, mais pas pour ceux qui rentrent : anomalie de fonctionnement.

Seulement voilà, je n'ai pas le temps d'acquérir les compétences pour lire le code, le comprendre, et tenter de le corriger. Sans compter qu'il y a peut-être une bonne raison pour que ça soit fait comme ça, comme le fait que les informations du pare-feu ne sont pas disponibles lors de l'appel à fib_validate_source.

Mais si quelqu'un ici me dit qu'on peut le rapporter à quelqu'un qui va m'écouter, et m'expliquer, voire corriger et améliorer, je veux bien prendre la peine de le faire.

  • # pourquoi pas ?

    Posté par  . Évalué à 7.

    si tu te sent de le faire en anglais, traduire ton journal par exemple

    et le poster sur la lkml après un petit mail d'introduction explicatif : http://vger.kernel.org/vger-lists.html

    dans la bonne section, ouais directement, tu ne risque rien Linus est en vacances (lol), pour certain bug ca c'est résolu comme ca. Par contre si c'est un bug, tu aura probablement des patch et à recompiler ton noyau toi meme, au fil de la tentative de résolution. JUSQU'A sa résolution.

    c'est délicat que quelqu'un d'autre le fasse a ta place car il faudrait la même configuration

    et essayer le dernier linux de kernel.org peut etre un bon debut (pas pour resoudre le pb) mais pour avoir une oreille attentive.

    perso, ca se tente, si tu es motiver et que tu as un peu de temps pour cela.

    exemple de bug resolu comme cela, je trouve plus le fil, c'est un pb d'ordonnaceur que le dev Mplayer a levé et a resolu ainsi directement sur la lkml. Dommage ca t'aurais montré la démarche … si qqun d'autre le trouve ?

    • [^] # Re: pourquoi pas ?

      Posté par  . Évalué à 4.

      Je vais donc creuser cette piste. En fonction de mon temps libre, c'est sûr.

      Mais c'est bien, c'est exactement ce que je demandais, merci beaucoup.

  • # En rapport avec la choucroute

    Posté par  (site web personnel) . Évalué à 4.

    • [^] # Re: En rapport avec la choucroute

      Posté par  . Évalué à 3. Dernière modification le 23 septembre 2018 à 21:27.

      Merci pour la référence. J'en ai trouvé pas mal des explications comme ça. Mais dans les rares qui mentionnaient rp_filter, personne ne disait pourquoi. Mais au moins, c'est une référence synthétique et en français. C'est bien :)

  • # rp_filter déprécier

    Posté par  . Évalué à 10.

    Pour info, le paramètre sysctl net.ipv4.conf.*.rp_filter n’étant pas compatible avec la version courante d’IP, il a été déprécier et devrait être géré directement dans netfilter/iptables : https://linuxfr.org/nodes/101254/comments/1520769.

    • [^] # Re: rp_filter déprécier

      Posté par  . Évalué à 4.

      Alors là, ça m'avait échappé. Oui, il y a bien le module rpfilter. Le genre de commentaire bien qu'on trouve sur linuxfr. Et ça a le GROS GROS avantage d'être visible au même niveau que les règles de pare-feu. Plutôt que dans l'obscur /etc/sysctl.conf.

      Merci !

    • [^] # Re: rp_filter déprécier

      Posté par  . Évalué à 7.

      Je confirme qu'utiliser le module rpfilter de iptables sur la table raw a résolu mon problème. Merci beaucoup pour cette ouverture de connaissance.

  • # Comment on aurait fait en IPv6

    Posté par  . Évalué à 10.

    Dans un monde « idéal », en IPv6, tu n'aurais pas forcément besoin de routeur intermédiaire, et tu aurais directement branché tes machinbox sur ton switch Ethernet, en précisant à ta box ADSL qu'elle est moins préférée (RFC 4191 https://tools.ietf.org/html/rfc4191), par exemple en syntaxe radvd.conf :

    AdvRoutePreference low;
    

    Et c'est tout.

    Voilà, plutôt que de perdre du temps à continuer à bidouiller pour faire marcher IPv4, on pourrait se dire qu'il vaudrait mieux passer son temps à essayer de voir comment on pourrait faire mieux avec IPv6, et aider à corriger les problèmes de migration et les quelques défauts restants de ce « nouveau protocole », car oui IPv6 n'est pas parfait. À chaque fois que je dis ça on trouve mille excuses et on continue à « perdre » des millions d'heures d'ingénieur à essayer de trouver des rustines à IPv4, sans jamais s'arrêter, et sans jamais arriver à stopper l'érosion de ce protocole : on commence à ne vraiment plus avoir d'IP publique pour tout le monde, même sur les boxs, et bientôt le peer-to-peer sera tout simplement impossible. Plus personne ne pourra s'héberger, et la fiabilité du réseau sera exécrable, excepté pour ceux qui auront payé la bonne « qualité de service » (aussi bien pour les internautes que pour les fournisseurs de contenus ; notez la dichotomie, vous ne pourrez pas vous-même fournir de contenu) et seront capables de mettre les ressources serveurs adéquates en face pour mitiger le partage d'identifiant gigantesque qui arrivera, et de faire le tracking de connexion nécessaire. On arrivera bien sûr un jour à la limite du partage IP + port (ça n'ajoute que 16 bits en plus), et ça sera encore plus drôle à ce moment-là (j'imagine qu'on essayera de faire du multiplexage à l'intérieur de connexion TCP, voire UDP ; oups pardon https://en.wikipedia.org/wiki/Quic certains ont déjà prévu ce beau futur…).

    Le multihoming — connecter son réseau à plusieurs fournisseurs d'accès — n'est pas un problème simple, et IPv6 n'a pas forcément de solution idéale à ce problème, mais le setup que je décrie respecte les principes de base de l'architecture d'Internet : l'intelligence n'est pas dans le réseau, et les décisions sur quelle liaison utiliser reviendraient aux machines utilisateur. Ça permet également de déporter la décision d'utiliser l'ADSL pour une raison particulière directement aux applications qui tournes sur les « extrémités » du réseau, sans avoir à toucher à un élément soit-disant intelligent au milieu (ton routeur). On ne fait également pas de routage source-specific (ton mangle + rule), qui est en général prompt aux erreurs de routage, cf. ton rp_filter qui est mignon, mais on voit bien que c'est chiant à gérer.

    Note que si tu voulais un routeur intermédiaire — qui annoncerait deux préfixes issus de chacun des préfixe délégués plus larges alloués par chacun de tes opérateurs —, tu aurais toute de même à faire du routage source-specific avec un petit "ip rule" pour éviter le filtrage des opérateurs sur la source (BCP 38 https://tools.ietf.org/html/rfc2827 ; un peu comme ton rp_filter, en fait), mais ça se ferait sans marquage ni rien de compliqué, juste avec une sélection sur le préfixe utilisé en source qui détermine le next-hop adéquat :

    ip -6 rule add from 2001:db8:1::/64 table isp1
    ip -6 rule add from 2001:db8:2::/64 table isp2
    ip -6 route add default table isp1 via fe80::XXX dev eth_livebox
    ip -6 route add default table isp2 via fe80::XXX dev eth_adsl
    

    Voilà. Pas d'état, pas de tracking, ça ne prend pas de mémoire, pas de resource, ça scale jusqu'à des Tbps, etc.

    Bref, merci quand même pour ton journal, c'est marrant le « routage avancé » en IPv4, mais ça ne résoudra jamais le problème existentiel de l'Internet de l'ancien monde qui est en train de se dégrader : ça permettra juste à « ceux qui connaissent » de tenir encore un peu mieux que les autres, mais c'est tout. La seule solution universelle et durable s'appelle IPv6.

    • [^] # Re: Comment on aurait fait en IPv6

      Posté par  . Évalué à 4.

      en précisant à ta box ADSL qu'elle est moins préférée (RFC 4191 https://tools.ietf.org/html/rfc4191), par exemple en syntaxe radvd.conf :

      AdvRoutePreference low;

      Bien sûr je suis allé un peu vite, et ça n'est pas exactement cette option : celle-ci parle de la préférence d'une route qu'on annonce en particulier. La préférence du routeur en tant que routeur par défaut se fait avec :

      AdvDefaultPreference low;
      

      Bref, il y a encore quelques trucs auxquels faire attention en IPv6, mais ça avance !

    • [^] # Re: Comment on aurait fait en IPv6

      Posté par  . Évalué à 4.

      Ouais, un super commentaire !
      Ouais, plein de choses à répondre ! Par quoi commencer ?

      Oui, l'IPv6 résoudrait tellement de problèmes. Ça serait vraiment bien si seulement… Si seulement les gens lisaient les RFC, et arrêtaient d'avoir un esprit commercial à court terme.
      IPv6 fonctionne chez moi depuis au moins 5 ans, via ma Freebox v5. J'ai dû bien bidouiller, à base de mélange de NPD6 et de règle de routage complexe parce que la Freebox n'annonce qu'un /64 en pensant qu'elle est toute seule.
      En passant chez Orange, je ne comptais pas sur mieux, et pourtant, j'ai vu ça dans l'interface de la Livebox :

      IPv6 activé vous permet de disposer d'adresses IPv6 pour les équipements de votre réseau local. En cas d'incompatibilité IPv6 de certains équipements, il est possible de désactiver la connectivité IPv6.

      Le préfixe IPv6 est : 2a01:cb19:XXXX:c000::/56

      Ooooh, un /56 rien que pour moi ? Ça c'est gentil, merci. Bon j'aurais bien aimé de la délégation de préfixe, mais soit. Je teste donc avec 2a01:cb19:XXXX:c000::2/64 sur eth_livebox (oui, c'est un serveur, c'est donc statique, c'est peut-être bête, je sais pas trop), et hop ça marche. Bien. Voyons voir avec 2a01:cb19:XXXX:c001::2/64 (qui est dans le sous-réseau suivant) : paf, ça répond plus.
      Alors je suis peut-être une quiche, j'ai raté un truc, je ne sais pas, mais la Livebox envoie des RA comme ça :

      #
      # radvd configuration generated by radvdump 2.17
      # based on Router Advertisement from fe80::a63e:51ff:fe73:c7f6
      # received by interface eth_livebox
      #
      
      interface eth_livebox
      {
          AdvSendAdvert on;
          # Note: {Min,Max}RtrAdvInterval cannot be obtained with radvdump
          AdvManagedFlag off;
          AdvOtherConfigFlag on;
          AdvReachableTime 0;
          AdvRetransTimer 0;
          AdvCurHopLimit 64;
          AdvDefaultLifetime 600;
          AdvHomeAgentFlag off;
          AdvDefaultPreference high;
          AdvLinkMTU 1500;
          AdvSourceLLAddress on;
      
          prefix 2a01:cb19:XXXX:c000::/64
          {
              AdvValidLifetime 1800;
              AdvPreferredLifetime 600;
              AdvOnLink on;
              AdvAutonomous on;
              AdvRouterAddr off;
          }; # End of prefix definition
      
      
          RDNSS fe80::a63e:51ff:fe73:c7f6
          {
              AdvRDNSSLifetime 600;
          }; # End of RDNSS definition
      
      
          DNSSL home
          {
              AdvDNSSLLifetime 600;
          }; # End of DNSSL definition
      
      }; # End of interface definition
      

      Et j'ai essayé un client DHCPv6 : pas de réponse. Donc on en est là, toujours à faire du routage complexe pour rien, juste parce qu'il n'y a pas une case à cocher pour faire mieux qu'un simple /64 annoncé par la « box » elle-même, soit à peu près aussi utile que le NAT en IPv4. Oui c'est mieux, mais c'est tout aussi utile.

      Pour revenir sur l'intelligence dans le réseau je suis partagé. D'un côté, j'aime bien quand les routeurs n'en font pas trop, et de l'autre, beeeen, j'aimerais bien pouvoir choisir moi-même ce qui passe par où, sans avoir à le configurer sur toutes mes machines terminales. Du coup, en IPv4, vu qu'il y a un SNAT, c'est pas trop dur : certains paquets sont marqués par iptables, et les paquets marqués passent via la règle de SNAT différente.
      En IPv6, évidemment, c'est pas le même raisonnement, et je pense que je vais effectivement laisser faire les machines terminales. Pas question de faire du SNAT, c'est vraiment malpropre.

      Et pour finir le module rpfilter. Le but, c'est bien d'éviter d'envoyer des paquets forgés via une machine potentiellement infectée. Je ne pense pas qu'une telle règle filtre quoi que ce soit pour les paquets qui arrivent de l'extérieur. Vu que le principe est de tester si le routeur peut router le paquet dans l'autre sens, à part si l'adresse source contient une adresse non routable (dans ce cas, mon FAI laisse vraiment passer des trucs bizarres), tout le reste va passer le test.
      Mais oui, j'ai déjà bien ces règles mentionnées dans mes tables, pour router correctement ce qui sort.

      La conclusion, c'est qu'il y a des centaines de personnes très qualifiées qui ont pondu un écosystème très perfectionné, et répondant parfaitement à quasiment tous les problèmes de IPv4, qui était quand même déjà bien conçu pour son époque. Mais on se retrouve avec des tas de gens qui n'ont rien compris, ou ne veulent pas comprendre, et qui cassent tout ce beau travail.

      • [^] # Re: Comment on aurait fait en IPv6

        Posté par  . Évalué à 4.

        Voyons voir avec 2a01:cb19:XXXX:c001::2/64 (qui est dans le sous-réseau suivant) : paf, ça répond plus.

        La livebox a un /56, mais ça ne de dit pas comment elle le route. Visiblement, :c001::/64 n'est pas un préfixe sur le lien Ethernet directement branché dessus. C'est classique, un seul préfixe — en l'occurrence :c000::/64 — est utilisé sur ce lien, et c'est suffisant. Comment crois-tu que sinon ta livebox saurait où aller chercher tous les périphériques dans ton /56 si elle devait au préalable interroger les machines branchées directement sur l'Ethernet ? (hint : il faut le temps du timeout NDP, qui n'est pas négligeable)

        Alors je suis peut-être une quiche, j'ai raté un truc, je ne sais pas, mais la Livebox envoie des RA comme ça :

        Non tu n'es pas une quiche, tu semble même plutôt bien informé. Regardons :

        interface eth_livebox
        {
        […]
        AdvManagedFlag off;

        Aïe ça commence mal, elle indique qu'il n'y a à priori pas de DHCPv6 sur ce réseau.

        AdvOtherConfigFlag on;

        Mais elle a un setup typique pour faire plaisir aux machines Windows qui n'impélementent(-aient ?) pas le RDNSS ; on sent les mecs qui veulent faire plaisir aux particularités pas très standards de MS.

        AdvDefaultPreference high;

        Et qui est du genre neuneu-proof.

        prefix 2a01:cb19:XXXX:c000::/64

        Donc, le préfixe que tu utilises normalement.

        RDNSS fe80::a63e:51ff:fe73:c7f6

        Une jolie configuration DNS par IPv6, bien.

        DNSSL home

        Ils n'ont pas l'air d'aimer suivre les standard http://www.bortzmeyer.org/7788.html même si la pratique « de fait » de ce genre de réservation sauvage à conduit à laisser faire ce genre de truc http://www.bortzmeyer.org/8244.html.

        }

        Bon, du coup on sent que faire « standard » avec ce routeur va être peut-être un peu difficile.

        Et j'ai essayé un client DHCPv6 : pas de réponse.

        Aïe : tu as suivi la bonne piste, DHCPv6-PD étant la manière standard de déléguer un préfixe à un autre routeur, mais malheureusement les implémentations des FAI ne suivent pas.

        Donc on en est là, toujours à faire du routage complexe pour rien, juste parce qu'il n'y a pas une case à cocher pour faire mieux qu'un simple /64 annoncé par la « box » elle-même, soit à peu près aussi utile que le NAT en IPv4. Oui c'est mieux, mais c'est tout aussi utile.

        Effectivement. Et c'est exactement ce genre de problème qui fait partie des choses à changer pour rendre IPv6 praticable : changer la mentalité des opérateurs et leur faire comprendre qu'il faut suivre les standards. Ça n'est pas un problème technique, c'est quelque-chose de complètement politique, mais c'est indispensable pour qu'IPv6 marche bien.

        Pour revenir sur l'intelligence dans le réseau je suis partagé. D'un côté, j'aime bien quand les routeurs n'en font pas trop, et de l'autre, beeeen, j'aimerais bien pouvoir choisir moi-même ce qui passe par où, sans avoir à le configurer sur toutes mes machines terminales. Du coup, en IPv4, vu qu'il y a un SNAT, c'est pas trop dur : certains paquets sont marqués par iptables, et les paquets marqués passent via la règle de SNAT différente.

        Oui, l'opposition management centralisé vs. réparti aux extrémités est une question qui n'a pas de bonne réponse, et il existera toujours une tension entre les deux. Les organismes de standardisation tels que l'IETF sont remplis de gens qui ont des avis opposés là-dessus, et essayent de trouver un consensus. Néanmoins, les constatations empiriques font qu'en général, selon moi, il est plus pertinent de faire du décentralisé. Il est connu que les infrastructures réseau ont tendance à se scléroser, et que du coup toute configuration faite « au cœur » du réseau aura tendance à ne plus jamais bouger avec le temps. C'est d'après cette constatation qu'a été conçu IPv6 : il faut le protocole qui codifie le moins de choses possibles (on a dégagé la fragmentation des routeurs car ça fout la merde, encore énormément aujourd'hui en IPv4 avec la prolifération des tunnels de tunnels de tunnels et la frénésie du blackholing ICMP). Mais oui, centraliser la configuration est quelque-chose de désirable quand on administre beaucoup de machines : c'est alors qu'on invente des protocoles de configuration qui vont chercher la configuration (standardisée) de manière standard sur le réseau : c'est DHCPv6. Ainsi, tu propages ta configuration à tous les éléments de ton réseau depuis le cœur, mais sans dépendre d'un mécanisme qui va faire un truc intelligent au milieu. Pour moi, c'est le meilleur des deux mondes.

        Sans parler après des problématique politiques de la volonté du réseau de contrôler ceux qui l'utilisent, quand ceux-ci sont issus d'autorités différentes : on tombe dans le débat sur la neutralité du Net. Je note en particulier que beaucoup d'admin réseau qui se bâtent pour la neutralité de leur FAI le sont beaucoup moins en ce qui concerne « leur » réseau à la maison, où leurs utilisateurs sont parfois sous la férule d'une non-neutralité imposée…

        Le but, c'est bien d'éviter d'envoyer des paquets forgés via une machine potentiellement infectée.

        Franchement, je suis sceptique sur l'utilité de se prémunir de ça : ton FAI filtrera de toutes façons, et si c'est comme tu dis du trafic illégitime, pas la peine d'essayer de le « traiter bien ».

        Je ne pense pas qu'une telle règle filtre quoi que ce soit pour les paquets qui arrivent de l'extérieur.

        On a dû mal se comprendre, je ne pense pas avoir dit ça.

        La conclusion, c'est qu'il y a des centaines de personnes très qualifiées qui ont pondu un écosystème très perfectionné, et répondant parfaitement à quasiment tous les problèmes de IPv4, qui était quand même déjà bien conçu pour son époque.

        C'est clair qu'IPv4 était déjà très bien foutu et est assez flexible pour s'adapter à un nombre de situations assez phénoménal. C'est le problème classique d'un protocole « assez bon » pour 80% des usages, qui fait qu'on a du mal à se motiver pour vouloir corriger les 20% restant (mais qui dans notre cas augmente de plus en plus).

        Mais on se retrouve avec des tas de gens qui n'ont rien compris, ou ne veulent pas comprendre, et qui cassent tout ce beau travail.

        Voilà, tu as bien compris le problème d'IPv6 : arriver à le faire comprendre. Malheureusement, avec la tendance actuelle à la pseudo-« sécurité » à tout prix, qui à tendance à favoriser le NAT pour de mauvaises raison, j'ai peur pour l'avenir d'IPv6. Mais oui, l'éducation reste la seule solution.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.