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.
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.
[^] # Re: Comment on aurait fait en IPv6
Posté par benoar . En réponse au journal Routage avancé avec marquage de paquet et rp_filter. Évalué à 4.
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)
Non tu n'es pas une quiche, tu semble même plutôt bien informé. Regardons :
Aïe ça commence mal, elle indique qu'il n'y a à priori pas de DHCPv6 sur ce réseau.
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.
Et qui est du genre neuneu-proof.
Donc, le préfixe que tu utilises normalement.
Une jolie configuration DNS par IPv6, bien.
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.
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.
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.
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...
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 ».
On a dû mal se comprendre, je ne pense pas avoir dit ça.
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).
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.