(je ne sais pas si c'est le groupe le plus approprié, mais comme il y a des cadors ici...)
Je me pointe chez des amis, tout fier, avec mon portable sous Ubuntu. Je la branche fièrement sur leur Livebox (en ethernet) et...
Connexion impossible.
Ah !
J'accuse tout, la livebox, le câble... Finalement je reboote sous W***** (y'en a un pour les tests). Et là : La connexion marche !
... *La honte*
Je fais les téléchargements d'urgence sous Windows (le but était de ravigorer leur PC sous W****). Je reboote quand même sous Ubuntu
et finalement, en réfléchissant (qu'est-ce qui différencie mon Windows de mon Ubuntu ?), je désactive le support IPV6 et là ça marche !
Une explication ?
Il faut que l'IPV6 soit effective sur le réseau pour que la connexion se fasse ?
Question subsidiaire : Orange ne connait pas encore IPV6 ?
--
Serge http://leserged.online.fr/
Mon blog: http://cahierdesergio.free.fr/
Soutenez le libre: http://www.framasoft.org
Oué mé bon, si tu poses des questions comme ça à des ingénieurs telecom, ils ne risquent pas de comprendre grand-chose...
Des ingénieurs : si. J'en connais un, malheureusement à la retraite. Je ne suis d'ailleurs pas sûr qu'il ait été remplacé depuis.
Mais je doute qu'une enquête de satisfaction soit initiée puis analysée par des ingénieurs télécom :-)
-- Dominique MICOLLET Adresse email : enlever deux francs
Erwan David
Eric Valette écrivait :
Faut pas oublier que pour faire fonctionner IPV6 correctement a travers des gateways, de nos jours, il faut aussi avoir l'accélération logicielle/matérielle IPV6 qui tienne la route (capable de travailler sur les entêtes IPV6 et de faire le tunneling 4to6 en hard et que malheureusement ca c'est pas Open Source). Avec un processeur de LB2, si tu le fais en soft, tu es mort surtout pour des offres fibre à 100 Mbits symétrique...
Il semble pourtant que free réussisse à le faire...
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
Eric Valette <EricNo.SPAMvalette@free.fr> écrivait :
Faut pas oublier que pour faire fonctionner IPV6 correctement a
travers des gateways, de nos jours, il faut aussi avoir l'accélération
logicielle/matérielle IPV6 qui tienne la route (capable de travailler
sur les entêtes IPV6 et de faire le tunneling 4to6 en hard et que
malheureusement ca c'est pas Open Source). Avec un processeur de LB2,
si tu le fais en soft, tu es mort surtout pour des offres fibre à 100
Mbits symétrique...
Il semble pourtant que free réussisse à le faire...
--
Le travail n'est pas une bonne chose. Si ça l'était,
les riches l'auraient accaparé
Faut pas oublier que pour faire fonctionner IPV6 correctement a travers des gateways, de nos jours, il faut aussi avoir l'accélération logicielle/matérielle IPV6 qui tienne la route (capable de travailler sur les entêtes IPV6 et de faire le tunneling 4to6 en hard et que malheureusement ca c'est pas Open Source). Avec un processeur de LB2, si tu le fais en soft, tu es mort surtout pour des offres fibre à 100 Mbits symétrique...
Il semble pourtant que free réussisse à le faire...
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
Pascal Hambourg
Eric Valette a écrit :
Au passage le 6to4 comme font certains avec IPV4 globale dans la boxe ca ne résout pas le PB de pénurie d'adresse V4.
L'IPv6 natif ne le résoud pas non plus. Rien ne résoudra le problème de pénurie d'adresses *IPv4*. C'est plein, point final. IPv6 ne fait que migrer dans un autre espace d'adressage, avec plein de place.
Eric Valette a écrit :
Au passage le 6to4 comme font certains avec IPV4 globale dans la boxe ca
ne résout pas le PB de pénurie d'adresse V4.
L'IPv6 natif ne le résoud pas non plus. Rien ne résoudra le problème de
pénurie d'adresses *IPv4*. C'est plein, point final. IPv6 ne fait que
migrer dans un autre espace d'adressage, avec plein de place.
Au passage le 6to4 comme font certains avec IPV4 globale dans la boxe ca ne résout pas le PB de pénurie d'adresse V4.
L'IPv6 natif ne le résoud pas non plus. Rien ne résoudra le problème de pénurie d'adresses *IPv4*. C'est plein, point final. IPv6 ne fait que migrer dans un autre espace d'adressage, avec plein de place.
Eric Masson
Eric Valette writes:
'Lut,
Oui mais autant ne pas retourner la AAAA tant que la boxe est pas dual stack en retournant une erreur propre (!!!) ca évite la tentative de connexion IPV6 pour rien (ce qui peut engendrer des latences assez longues).
Dans le cas de certaines LB, le dns local semble ne rien retourner du tout, comme cela a déjà été expliqué par Pascal, c'est là qu'est le problème pas dans un hypothétique réponse AAAA inexploitable pour cause d'absence de connectivité v6.
La latence induite par le fonctionnement en dual stack est quasi indétectable si la configuration du lan sur lequel la machine se connecte n'est pas trop moisie (mon portable de taf est en DS, les lans des clients et du taf en v4 seul et je n'ai que rarement de problèmes).
Faut pas oublier que pour faire fonctionner IPV6 correctement a travers des gateways, de nos jours, il faut aussi avoir l'accélération logicielle/matérielle IPV6 qui tienne la route (capable de travailler sur les entêtes IPV6 et de faire le tunneling 4to6 en hard et que malheureusement ca c'est pas Open Source).
Bof, Free fait déjà du 6rd sur des liens 100Mb/s en soft et ça tient, donc...
-- SB: Y a-t-il un médecin dans la salle ? RM: Oui, mais ils se manifestent surtout pour savoir comment faire avec Mac et Sesame Vitale ;-) RM in Guide du Macounet Pervers : Bien préparer son serment d'Hippocrate
Eric Valette <EricNo.SPAMvalette@free.fr> writes:
'Lut,
Oui mais autant ne pas retourner la AAAA tant que la boxe est pas dual
stack en retournant une erreur propre (!!!) ca évite la tentative de
connexion IPV6 pour rien (ce qui peut engendrer des latences assez
longues).
Dans le cas de certaines LB, le dns local semble ne rien retourner du
tout, comme cela a déjà été expliqué par Pascal, c'est là qu'est le
problème pas dans un hypothétique réponse AAAA inexploitable pour cause
d'absence de connectivité v6.
La latence induite par le fonctionnement en dual stack est quasi
indétectable si la configuration du lan sur lequel la machine se
connecte n'est pas trop moisie (mon portable de taf est en DS, les
lans des clients et du taf en v4 seul et je n'ai que rarement de
problèmes).
Faut pas oublier que pour faire fonctionner IPV6 correctement a travers
des gateways, de nos jours, il faut aussi avoir l'accélération
logicielle/matérielle IPV6 qui tienne la route (capable de travailler
sur les entêtes IPV6 et de faire le tunneling 4to6 en hard et que
malheureusement ca c'est pas Open Source).
Bof, Free fait déjà du 6rd sur des liens 100Mb/s en soft et ça tient,
donc...
--
SB: Y a-t-il un médecin dans la salle ?
RM: Oui, mais ils se manifestent surtout pour savoir comment faire avec
Mac et Sesame Vitale ;-)
RM in Guide du Macounet Pervers : Bien préparer son serment d'Hippocrate
Oui mais autant ne pas retourner la AAAA tant que la boxe est pas dual stack en retournant une erreur propre (!!!) ca évite la tentative de connexion IPV6 pour rien (ce qui peut engendrer des latences assez longues).
Dans le cas de certaines LB, le dns local semble ne rien retourner du tout, comme cela a déjà été expliqué par Pascal, c'est là qu'est le problème pas dans un hypothétique réponse AAAA inexploitable pour cause d'absence de connectivité v6.
La latence induite par le fonctionnement en dual stack est quasi indétectable si la configuration du lan sur lequel la machine se connecte n'est pas trop moisie (mon portable de taf est en DS, les lans des clients et du taf en v4 seul et je n'ai que rarement de problèmes).
Faut pas oublier que pour faire fonctionner IPV6 correctement a travers des gateways, de nos jours, il faut aussi avoir l'accélération logicielle/matérielle IPV6 qui tienne la route (capable de travailler sur les entêtes IPV6 et de faire le tunneling 4to6 en hard et que malheureusement ca c'est pas Open Source).
Bof, Free fait déjà du 6rd sur des liens 100Mb/s en soft et ça tient, donc...
-- SB: Y a-t-il un médecin dans la salle ? RM: Oui, mais ils se manifestent surtout pour savoir comment faire avec Mac et Sesame Vitale ;-) RM in Guide du Macounet Pervers : Bien préparer son serment d'Hippocrate
Pascal Hambourg
Eric Valette a écrit :
On 11/11/2010 18:45, Eric Masson wrote:
Ben en simplifiant, tentative de connexion en v6 qui n'aboutit pas, de là resolution puis connexion en v4, le comportement standard d'une machine dual stack avec préférence v6, non ?
En gros, oui. Excepté qu'a priori la résolution se fait en IPv6 et en IPv4 avant la première tentative de connexion.
Oui mais autant ne pas retourner la AAAA
Quand il y en a une. Tu noteras que la box merdoie avec les requêtes AAAA même quand il n'y a pas d'enregistrement.
tant que la boxe est pas dual stack
La résolution DNS des AAAA n'a rien à voir avec le fait que la box soit en dual stack. Si la machine derrière a l'IPv6 via un tunnel, elle a besoin de résoudre les AAAA. La plupart des box et modems-
en retournant une erreur propre (!!!)
C'est le point crucial. Retourner une erreur, et non faire la sourde oreille comme le fait la Livebox. Pour le coup, ça introduit de la latence.
ca évite la tentative de connexion IPV6 pour rien (ce qui peut engendrer des latences assez longues).
Normalement non. Si la machine n'a pas d'adresse IPv6 globale ni de route par défaut, une tentative de connexion en IPv6 va retourner immédiatement une erreur "network unreachable.
Faut pas oublier que pour faire fonctionner IPV6 correctement a travers des gateways, de nos jours, il faut aussi avoir l'accélération logicielle/matérielle IPV6 qui tienne la route (capable de travailler sur les entêtes IPV6 et de faire le tunneling 4to6 en hard et que malheureusement ca c'est pas Open Source). Avec un processeur de LB2, si tu le fais en soft, tu es mort surtout pour des offres fibre à 100 Mbits symétrique...
J'ai peine à croire que ce soit beaucoup plus exigeant en temps de traitement que le NAT IPv4. Et ça, les box y arrivent.
Eric Valette a écrit :
On 11/11/2010 18:45, Eric Masson wrote:
Ben en simplifiant, tentative de connexion en v6 qui n'aboutit pas, de
là resolution puis connexion en v4, le comportement standard d'une
machine dual stack avec préférence v6, non ?
En gros, oui. Excepté qu'a priori la résolution se fait en IPv6 et en
IPv4 avant la première tentative de connexion.
Oui mais autant ne pas retourner la AAAA
Quand il y en a une. Tu noteras que la box merdoie avec les requêtes
AAAA même quand il n'y a pas d'enregistrement.
tant que la boxe est pas dual stack
La résolution DNS des AAAA n'a rien à voir avec le fait que la box soit
en dual stack. Si la machine derrière a l'IPv6 via un tunnel, elle a
besoin de résoudre les AAAA. La plupart des box et modems-
en retournant une erreur propre (!!!)
C'est le point crucial. Retourner une erreur, et non faire la sourde
oreille comme le fait la Livebox. Pour le coup, ça introduit de la latence.
ca évite la tentative de
connexion IPV6 pour rien (ce qui peut engendrer des latences assez longues).
Normalement non. Si la machine n'a pas d'adresse IPv6 globale ni de
route par défaut, une tentative de connexion en IPv6 va retourner
immédiatement une erreur "network unreachable.
Faut pas oublier que pour faire fonctionner IPV6 correctement a travers
des gateways, de nos jours, il faut aussi avoir l'accélération
logicielle/matérielle IPV6 qui tienne la route (capable de travailler
sur les entêtes IPV6 et de faire le tunneling 4to6 en hard et que
malheureusement ca c'est pas Open Source). Avec un processeur de LB2, si
tu le fais en soft, tu es mort surtout pour des offres fibre à 100 Mbits
symétrique...
J'ai peine à croire que ce soit beaucoup plus exigeant en temps de
traitement que le NAT IPv4. Et ça, les box y arrivent.
Ben en simplifiant, tentative de connexion en v6 qui n'aboutit pas, de là resolution puis connexion en v4, le comportement standard d'une machine dual stack avec préférence v6, non ?
En gros, oui. Excepté qu'a priori la résolution se fait en IPv6 et en IPv4 avant la première tentative de connexion.
Oui mais autant ne pas retourner la AAAA
Quand il y en a une. Tu noteras que la box merdoie avec les requêtes AAAA même quand il n'y a pas d'enregistrement.
tant que la boxe est pas dual stack
La résolution DNS des AAAA n'a rien à voir avec le fait que la box soit en dual stack. Si la machine derrière a l'IPv6 via un tunnel, elle a besoin de résoudre les AAAA. La plupart des box et modems-
en retournant une erreur propre (!!!)
C'est le point crucial. Retourner une erreur, et non faire la sourde oreille comme le fait la Livebox. Pour le coup, ça introduit de la latence.
ca évite la tentative de connexion IPV6 pour rien (ce qui peut engendrer des latences assez longues).
Normalement non. Si la machine n'a pas d'adresse IPv6 globale ni de route par défaut, une tentative de connexion en IPv6 va retourner immédiatement une erreur "network unreachable.
Faut pas oublier que pour faire fonctionner IPV6 correctement a travers des gateways, de nos jours, il faut aussi avoir l'accélération logicielle/matérielle IPV6 qui tienne la route (capable de travailler sur les entêtes IPV6 et de faire le tunneling 4to6 en hard et que malheureusement ca c'est pas Open Source). Avec un processeur de LB2, si tu le fais en soft, tu es mort surtout pour des offres fibre à 100 Mbits symétrique...
J'ai peine à croire que ce soit beaucoup plus exigeant en temps de traitement que le NAT IPv4. Et ça, les box y arrivent.
Xavier Roche
Pascal Hambourg a écrit :
J'ai peine à croire que ce soit beaucoup plus exigeant en temps de traitement que le NAT IPv4. Et ça, les box y arrivent.
Si on prend comme référence (c'est discutable, mais ce n'est qu'un exemple) un brave catalyst 4948(E) (*1) (utilisé notamment par proxad si je ne m'abuse pas :p), les perfs sont identiques avec la version standard, et quasi-identiques dans la version "E" (IPv6 en hardware). (Le passage en hard n'a quasiment rien fait gagner, au passage)
J'imagine que le traitement est fortement analogue, bien qu'il y ait des différences: * pas de checksum pour ipv6 * mais adresse plus longue à traiter
Pascal Hambourg a écrit :
J'ai peine à croire que ce soit beaucoup plus exigeant en temps de
traitement que le NAT IPv4. Et ça, les box y arrivent.
Si on prend comme référence (c'est discutable, mais ce n'est qu'un
exemple) un brave catalyst 4948(E) (*1) (utilisé notamment par proxad si
je ne m'abuse pas :p), les perfs sont identiques avec la version
standard, et quasi-identiques dans la version "E" (IPv6 en hardware).
(Le passage en hard n'a quasiment rien fait gagner, au passage)
J'ai peine à croire que ce soit beaucoup plus exigeant en temps de traitement que le NAT IPv4. Et ça, les box y arrivent.
Si on prend comme référence (c'est discutable, mais ce n'est qu'un exemple) un brave catalyst 4948(E) (*1) (utilisé notamment par proxad si je ne m'abuse pas :p), les perfs sont identiques avec la version standard, et quasi-identiques dans la version "E" (IPv6 en hardware). (Le passage en hard n'a quasiment rien fait gagner, au passage)
J'imagine que le traitement est fortement analogue, bien qu'il y ait des différences: * pas de checksum pour ipv6 * mais adresse plus longue à traiter
Xavier Roche
Pascal Hambourg a écrit :
J'ai peine à croire que ce soit beaucoup plus exigeant en temps de traitement que le NAT IPv4. Et ça, les box y arrivent.
Si on prend comme référence (c'est discutable, mais ce n'est qu'un exemple) un brave catalyst 4948(E) (*1) (utilisé notamment par proxad si je ne m'abuse :p), les perfs sont identiques avec la version standard, et quasi-identiques dans la version "E" (IPv6 en hardware). (Le passage en hard n'a quasiment rien fait gagner, au passage)
J'imagine que le traitement est fortement analogue, bien qu'il y ait des différences: * pas de checksum pour ipv6 * mais adresse plus longue à traiter
Pascal Hambourg a écrit :
J'ai peine à croire que ce soit beaucoup plus exigeant en temps de
traitement que le NAT IPv4. Et ça, les box y arrivent.
Si on prend comme référence (c'est discutable, mais ce n'est qu'un
exemple) un brave catalyst 4948(E) (*1) (utilisé notamment par proxad si
je ne m'abuse :p), les perfs sont identiques avec la version
standard, et quasi-identiques dans la version "E" (IPv6 en hardware).
(Le passage en hard n'a quasiment rien fait gagner, au passage)
J'ai peine à croire que ce soit beaucoup plus exigeant en temps de traitement que le NAT IPv4. Et ça, les box y arrivent.
Si on prend comme référence (c'est discutable, mais ce n'est qu'un exemple) un brave catalyst 4948(E) (*1) (utilisé notamment par proxad si je ne m'abuse :p), les perfs sont identiques avec la version standard, et quasi-identiques dans la version "E" (IPv6 en hardware). (Le passage en hard n'a quasiment rien fait gagner, au passage)
