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.
# Comment on aurait fait en IPv6
Posté par benoar . En réponse au journal Routage avancé avec marquage de paquet et rp_filter. É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 :
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 :
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.