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 Glandos . En réponse au journal Routage avancé avec marquage de paquet et rp_filter. É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 :
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 :
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.