(Courriels de diversion: <defaites@platonique-therapeutes.com> <toleraient@expatrierait-demarchent.com> <classifions@vanteriez-frola.com> <cloner@parques-subventionnerait.com> <butins@cheques-restaurant-murs.com> <goberai@constituant-caracterisee.com> <embrouillements@compatirais-neurologue.com> <epinglee@faillit-quadrillerai.com> <commentions@carminee-accuser.com> <devaluerais@cambres-edifierons.com> )
jdd sur free a écrit :
Pascal Hambourg a écrit :BSD, je connais pas des masses.on va avoir une conf :-)
Excellent. Je viendrai sauf empêchement.
à priori c'est assez basique (dans le sens de simple, ca doit plutôt être prévu pour un serveur que pour faire joli)
Tant mieux.
au fait, si j'active la connection ipv6 de free, chez moi, est-ce que c'est sans danger?
Non, ce n'est pas sans risque, comme expliqué dans mon long message. Moi-même qui ai l'IPv6 sur mon LAN depuis des années, il m'arrive d'avoir de petits problèmes que je n'aurais pas sans IPv6, souvent liés à des bugs plus ou moins spécifiques à IPv6 dans des logiciels.
Quelques exemples vécus qui me viennent en-tête :- Problème de routage IPv6 entre le RIPE et mon FAI, mais un bug dans le programme whois compatible IPv6 de Debian sarge faisait qu'il ne réessayait pas en IPv4 ; résultat, les recherches whois impliquant directement ou indirectement le serveur whois du RIPE échouaient. Contourné en réinterrogeant l'adresse IPv4 du serveur whois du RIPE.
- Un bug dans BIND 9 de Debian sarge qui plantait la réception de requêtes en UDP après que la socket IPv6 avait reçu un paquet UDPv4 ; cela arrive lorsque l'adresse de destination ne correspond à aucune socket UDPv4 ouverte, la socket UDPv6 se comportant alors comme un "wildcard", ce qui se produisait de temps en templs lors de la reconnexion PPP. Contourné avec un réglage du noyau qui empêche les sockets IPv6 de recevoir des paquets IPv4, ce qui n'est pas si mal finalement.
- ftp.netfilter.org a une adresse IPv6, mais seule l'adresse IPv4 répond en FTP (oui, c'est mal) ; en IPv6 le port 21 est fermé (jusque là ça va) mais les ports non priviliégiés sont silencieusement bloqués. Or un bug du moteur FTP de Firefox faisait qu'il réessayait de se connecter d'abord en IPv6 pour les connexions de données alors qu'il s'était finalement connecté en IPv4 pour la connexion de commande, ce qui combiné au filtrage des ports du serveur occasionnait de très longs délais. Le bug de Firefox n'était pas spécifique à IPv6 mais plutôt lié au fait qu'un site FTP ait plusieurs adresses qui ne répondent pas toutes, cependant c'était dans la situation exposée ci-dessus qu'il avait le plus de chances de s'exprimer.
- Suite au remplacement d'un équipement sur le réseau de Nerim, l'adresse link local de la passerelle d'un LAN serveurs change, mais pour une raison inconnue certains serveurs gardent l'ancienne adresse de passerelle et ne sont plus joignables en IPv6.
- Récemment, un problème de MTU et de fragmentation spécifique à IPv6 sur une version d'IOS (firmware Cisco) des nouveaux routeurs d'accès de Nerim qui "mangeait" les paquets IPv6 de taille supérieure à 1460, ce qui bloquait les communications impliquant la réception de blocs de données de taille supérieure. Contourné pour TCPv6 en baissant le MTU local (et donc le MSS annoncé). Corrigé en changeant la version d'IOS des nouveaux routeurs.
----------------------------------------------------------------- Les listes de diffusion du CULTe - Pour une informatique libre http://www.CULTe.org/listes/ Pour se desabonner: mailto:linux-31-unsubscribe@CULTe.org?subject=Cliquez_sur_ENVOYER