le 14/08/2008 à 00:20, Thomas a écrit dans le message :
si, mais que en ipv4 et il y a bien un pb, puisque sshd n'écoute que en ipv6 ....
qqn a une idée ?
Rien dans les log ?
#ListenAddress 0.0.0.0
Tu peux toujours essayé de décommenter cette ligne bien que ce soit la configuration par défaut.
-- Benoit Izac
Pascal Hambourg
Thomas a écrit :
Nicolas George <nicolas$ wrote:
Thomas wrote in messag
alors pourquoi netstat n'a rien dit ??
Parce que tu ne lui as pas demandé d'afficher les sockets en écoute.
si, mais que en ipv4
Ah, j'y avais pensé...
et il y a bien un pb, puisque sshd n'écoute que en ipv6 ....
qqn a une idée ?
Il n'y a pas vraiment de problème. C'est le comportement par défaut du noyau Linux qui considère qu'une socket IPv6 en écoute sur :: écoute aussi en IPv4 sur 0.0.0.0. Par défaut, sshd crée d'abord la socket IPv6 puis la socket IPv4. Mais comme la socket IPv6 écoute déjà sur 0.0.0.0, la création de la socket IPv4 échoue. Mais ce n'est pas bien grave. Tu peux tester que sshd est bien accessible en IPv4 avec par exemple :
$ telnet 127.0.0.1 22
qui devrait afficher la bannière du sshd.
L'inconvénient, c'est que les adresses IPv4 des clients sont vues sous forme d'adresses IPv6 "IPv4-mapped" ::ffff:w.x.y.z. Cela pourrait éventuellement perturber des ACL ou des outils de vérification de logs.
Si tu n'as pas besoin que sshd écoute en IPv6, tu peux décommenter la directive "ListenAddress 0.0.0.0" dans sshd_config et relancer sshd, ou bien lancer sshd avec l'option -4. Si tu veux que sshd écoute en IPv4 et IPv6 mais sur des sockets séparées, tu peux mettre le paramètre du noyau /proc/sys/net/ipv6/bindv6only à 1 pour empêcher les communications en IPv4 avec une socket IPv6. Attention, cela s'applique à toutes les sockets IPv6 créées après qu'il ait été modifié. Une autre solution consiste à lister chaque adresse IPv4 et IPv6 sur laquelle sshd doit écouter avec des directives ListenAddress.
Thomas a écrit :
Nicolas George <nicolas$george@salle-s.org> wrote:
Thomas wrote in messag
alors pourquoi netstat n'a rien dit ??
Parce que tu ne lui as pas demandé d'afficher les sockets en écoute.
si, mais que en ipv4
Ah, j'y avais pensé...
et il y a bien un pb, puisque sshd n'écoute que en ipv6 ....
qqn a une idée ?
Il n'y a pas vraiment de problème. C'est le comportement par défaut du
noyau Linux qui considère qu'une socket IPv6 en écoute sur :: écoute
aussi en IPv4 sur 0.0.0.0. Par défaut, sshd crée d'abord la socket IPv6
puis la socket IPv4. Mais comme la socket IPv6 écoute déjà sur 0.0.0.0,
la création de la socket IPv4 échoue. Mais ce n'est pas bien grave. Tu
peux tester que sshd est bien accessible en IPv4 avec par exemple :
$ telnet 127.0.0.1 22
qui devrait afficher la bannière du sshd.
L'inconvénient, c'est que les adresses IPv4 des clients sont vues sous
forme d'adresses IPv6 "IPv4-mapped" ::ffff:w.x.y.z. Cela pourrait
éventuellement perturber des ACL ou des outils de vérification de logs.
Si tu n'as pas besoin que sshd écoute en IPv6, tu peux décommenter la
directive "ListenAddress 0.0.0.0" dans sshd_config et relancer sshd, ou
bien lancer sshd avec l'option -4. Si tu veux que sshd écoute en IPv4 et
IPv6 mais sur des sockets séparées, tu peux mettre le paramètre du noyau
/proc/sys/net/ipv6/bindv6only à 1 pour empêcher les communications en
IPv4 avec une socket IPv6. Attention, cela s'applique à toutes les
sockets IPv6 créées après qu'il ait été modifié. Une autre solution
consiste à lister chaque adresse IPv4 et IPv6 sur laquelle sshd doit
écouter avec des directives ListenAddress.
Parce que tu ne lui as pas demandé d'afficher les sockets en écoute.
si, mais que en ipv4
Ah, j'y avais pensé...
et il y a bien un pb, puisque sshd n'écoute que en ipv6 ....
qqn a une idée ?
Il n'y a pas vraiment de problème. C'est le comportement par défaut du noyau Linux qui considère qu'une socket IPv6 en écoute sur :: écoute aussi en IPv4 sur 0.0.0.0. Par défaut, sshd crée d'abord la socket IPv6 puis la socket IPv4. Mais comme la socket IPv6 écoute déjà sur 0.0.0.0, la création de la socket IPv4 échoue. Mais ce n'est pas bien grave. Tu peux tester que sshd est bien accessible en IPv4 avec par exemple :
$ telnet 127.0.0.1 22
qui devrait afficher la bannière du sshd.
L'inconvénient, c'est que les adresses IPv4 des clients sont vues sous forme d'adresses IPv6 "IPv4-mapped" ::ffff:w.x.y.z. Cela pourrait éventuellement perturber des ACL ou des outils de vérification de logs.
Si tu n'as pas besoin que sshd écoute en IPv6, tu peux décommenter la directive "ListenAddress 0.0.0.0" dans sshd_config et relancer sshd, ou bien lancer sshd avec l'option -4. Si tu veux que sshd écoute en IPv4 et IPv6 mais sur des sockets séparées, tu peux mettre le paramètre du noyau /proc/sys/net/ipv6/bindv6only à 1 pour empêcher les communications en IPv4 avec une socket IPv6. Attention, cela s'applique à toutes les sockets IPv6 créées après qu'il ait été modifié. Une autre solution consiste à lister chaque adresse IPv4 et IPv6 sur laquelle sshd doit écouter avec des directives ListenAddress.
Nicolas George
Thomas wrote in message :
si, mais que en ipv4
Non. netstat par défaut affiche les deux, IPv6 et IPv4, mais pas les sockets en écoute. Donc à moins que tu aies été assez crétin pour appeler netstat -4 mais pas essayer -6 juste après, c'est bien mon explication qui est la bonne.
et il y a bien un pb, puisque sshd n'écoute que en ipv6 ....
Et en quoi serait-ce un problème ?
Thomas wrote in message
<fantome.forums.tDeContes-DA256B.00205414082008@news.free.fr>:
si, mais que en ipv4
Non. netstat par défaut affiche les deux, IPv6 et IPv4, mais pas les sockets
en écoute. Donc à moins que tu aies été assez crétin pour appeler netstat -4
mais pas essayer -6 juste après, c'est bien mon explication qui est la
bonne.
et il y a bien un pb, puisque sshd n'écoute que en ipv6 ....
Non. netstat par défaut affiche les deux, IPv6 et IPv4, mais pas les sockets en écoute. Donc à moins que tu aies été assez crétin pour appeler netstat -4 mais pas essayer -6 juste après, c'est bien mon explication qui est la bonne.
et il y a bien un pb, puisque sshd n'écoute que en ipv6 ....
Et en quoi serait-ce un problème ?
Pascal Hambourg
Nicolas George a écrit :
Thomas wrote :
si, mais que en ipv4
Non. netstat par défaut affiche les deux, IPv6 et IPv4, mais pas les sockets en écoute. Donc à moins que tu aies été assez crétin pour appeler netstat -4 mais pas essayer -6 juste après, c'est bien mon explication qui est la bonne.
Thomas utilise peut-être --inet ou -4 pour ne pas afficher les sockets Unix. Il ne serait pas le premier à commettre cette erreur, tout le monde n'est pas familiarisé avec IPv6. Il devra ajouter --inet6 ou -6.
Nicolas George a écrit :
Thomas wrote :
si, mais que en ipv4
Non. netstat par défaut affiche les deux, IPv6 et IPv4, mais pas les sockets
en écoute. Donc à moins que tu aies été assez crétin pour appeler netstat -4
mais pas essayer -6 juste après, c'est bien mon explication qui est la
bonne.
Thomas utilise peut-être --inet ou -4 pour ne pas afficher les sockets
Unix. Il ne serait pas le premier à commettre cette erreur, tout le
monde n'est pas familiarisé avec IPv6. Il devra ajouter --inet6 ou -6.
Non. netstat par défaut affiche les deux, IPv6 et IPv4, mais pas les sockets en écoute. Donc à moins que tu aies été assez crétin pour appeler netstat -4 mais pas essayer -6 juste après, c'est bien mon explication qui est la bonne.
Thomas utilise peut-être --inet ou -4 pour ne pas afficher les sockets Unix. Il ne serait pas le premier à commettre cette erreur, tout le monde n'est pas familiarisé avec IPv6. Il devra ajouter --inet6 ou -6.
Thomas
In article <g7vr0e$1ifh$, Pascal Hambourg wrote:
Nicolas George a écrit : > Thomas wrote : > >>si, mais que en ipv4 > > Non. netstat par défaut affiche les deux, IPv6 et IPv4, mais pas les sockets > en écoute. Donc à moins que tu aies été assez crétin pour appeler netstat -4 > mais pas essayer -6 juste après, c'est bien mon explication qui est la > bonne.
Thomas utilise peut-être --inet ou -4 pour ne pas afficher les sockets Unix.
sous mac os x, (jusque là) tout ce qui apparaît en ipv6 apparaît "en doublon" en ipv4 donc, comme je ne m'occupe pas d'ipv6 pour l'instant, je me suis simplement dégagé l'écran :-)
Il ne serait pas le premier à commettre cette erreur, tout le monde n'est pas familiarisé avec IPv6. Il devra ajouter --inet6 ou -6.
In article <g7vr0e$1ifh$1@biggoron.nerim.net>,
Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> wrote:
Nicolas George a écrit :
> Thomas wrote :
>
>>si, mais que en ipv4
>
> Non. netstat par défaut affiche les deux, IPv6 et IPv4, mais pas les sockets
> en écoute. Donc à moins que tu aies été assez crétin pour appeler netstat -4
> mais pas essayer -6 juste après, c'est bien mon explication qui est la
> bonne.
Thomas utilise peut-être --inet ou -4 pour ne pas afficher les sockets
Unix.
sous mac os x, (jusque là) tout ce qui apparaît en ipv6 apparaît "en
doublon" en ipv4
donc, comme je ne m'occupe pas d'ipv6 pour l'instant, je me suis
simplement dégagé l'écran :-)
Il ne serait pas le premier à commettre cette erreur, tout le
monde n'est pas familiarisé avec IPv6. Il devra ajouter --inet6 ou -6.
Nicolas George a écrit : > Thomas wrote : > >>si, mais que en ipv4 > > Non. netstat par défaut affiche les deux, IPv6 et IPv4, mais pas les sockets > en écoute. Donc à moins que tu aies été assez crétin pour appeler netstat -4 > mais pas essayer -6 juste après, c'est bien mon explication qui est la > bonne.
Thomas utilise peut-être --inet ou -4 pour ne pas afficher les sockets Unix.
sous mac os x, (jusque là) tout ce qui apparaît en ipv6 apparaît "en doublon" en ipv4 donc, comme je ne m'occupe pas d'ipv6 pour l'instant, je me suis simplement dégagé l'écran :-)
Il ne serait pas le premier à commettre cette erreur, tout le monde n'est pas familiarisé avec IPv6. Il devra ajouter --inet6 ou -6.
Thomas a écrit : > Nicolas George <nicolas$ wrote: > >>Thomas wrote in messag >> >>>alors pourquoi netstat n'a rien dit ?? >> >>Parce que tu ne lui as pas demandé d'afficher les sockets en écoute. > > si, mais que en ipv4
Ah, j'y avais pensé...
> et il y a bien un pb, puisque sshd n'écoute que en ipv6 .... > > qqn a une idée ?
Il n'y a pas vraiment de problème. C'est le comportement par défaut du noyau Linux qui considère qu'une socket IPv6 en écoute sur :: écoute aussi en IPv4 sur 0.0.0.0. Par défaut, sshd crée d'abord la socket IPv6 puis la socket IPv4. Mais comme la socket IPv6 écoute déjà sur 0.0.0.0, la création de la socket IPv4 échoue. Mais ce n'est pas bien grave. Tu peux tester que sshd est bien accessible en IPv4 avec par exemple :
$ telnet 127.0.0.1 22
qui devrait afficher la bannière du sshd.
merci bcp, c'est bon :-)
L'inconvénient, c'est que les adresses IPv4 des clients sont vues sous forme d'adresses IPv6 "IPv4-mapped" ::ffff:w.x.y.z. Cela pourrait éventuellement perturber des ACL ou des outils de vérification de logs.
ah bon en tout cas c'est embêtant au moins pour des trucs comme netstat du coup, je vais être embêté (un peu) quand un socket va faire de l'ipv6 mais pas de l'ipv4
Si tu n'as pas besoin que sshd écoute en IPv6, tu peux décommenter la directive "ListenAddress 0.0.0.0" dans sshd_config et relancer sshd, ou bien lancer sshd avec l'option -4. Si tu veux que sshd écoute en IPv4 et IPv6 mais sur des sockets séparées, tu peux mettre le paramètre du noyau /proc/sys/net/ipv6/bindv6only à 1 pour empêcher les communications en IPv4 avec une socket IPv6. Attention, cela s'applique à toutes les sockets IPv6 créées après qu'il ait été modifié.
même si le socket est le même je suppose pour des raisons de simplicité ou de passage transparent, pourquoi est ce que ça ne fonctionne pas au niveau logiciel comme si c'était uniquement en ipv4 aussi ? amha ça serait plus simple
mais bon, ça dépend probablement de subtilités du pont entre ipv4 et ipv6 que je comprendrais plus tard :-)
In article <g7vqf4$1hmn$1@biggoron.nerim.net>,
Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> wrote:
Thomas a écrit :
> Nicolas George <nicolas$george@salle-s.org> wrote:
>
>>Thomas wrote in messag
>>
>>>alors pourquoi netstat n'a rien dit ??
>>
>>Parce que tu ne lui as pas demandé d'afficher les sockets en écoute.
>
> si, mais que en ipv4
Ah, j'y avais pensé...
> et il y a bien un pb, puisque sshd n'écoute que en ipv6 ....
>
> qqn a une idée ?
Il n'y a pas vraiment de problème. C'est le comportement par défaut du
noyau Linux qui considère qu'une socket IPv6 en écoute sur :: écoute
aussi en IPv4 sur 0.0.0.0. Par défaut, sshd crée d'abord la socket IPv6
puis la socket IPv4. Mais comme la socket IPv6 écoute déjà sur 0.0.0.0,
la création de la socket IPv4 échoue. Mais ce n'est pas bien grave. Tu
peux tester que sshd est bien accessible en IPv4 avec par exemple :
$ telnet 127.0.0.1 22
qui devrait afficher la bannière du sshd.
merci bcp, c'est bon :-)
L'inconvénient, c'est que les adresses IPv4 des clients sont vues sous
forme d'adresses IPv6 "IPv4-mapped" ::ffff:w.x.y.z. Cela pourrait
éventuellement perturber des ACL ou des outils de vérification de logs.
ah bon
en tout cas c'est embêtant au moins pour des trucs comme netstat
du coup, je vais être embêté (un peu) quand un socket va faire de l'ipv6
mais pas de l'ipv4
Si tu n'as pas besoin que sshd écoute en IPv6, tu peux décommenter la
directive "ListenAddress 0.0.0.0" dans sshd_config et relancer sshd, ou
bien lancer sshd avec l'option -4. Si tu veux que sshd écoute en IPv4 et
IPv6 mais sur des sockets séparées, tu peux mettre le paramètre du noyau
/proc/sys/net/ipv6/bindv6only à 1 pour empêcher les communications en
IPv4 avec une socket IPv6. Attention, cela s'applique à toutes les
sockets IPv6 créées après qu'il ait été modifié.
même si le socket est le même je suppose pour des raisons de simplicité
ou de passage transparent, pourquoi est ce que ça ne fonctionne pas au
niveau logiciel comme si c'était uniquement en ipv4 aussi ?
amha ça serait plus simple
mais bon, ça dépend probablement de subtilités du pont entre ipv4 et
ipv6 que je comprendrais plus tard :-)
Thomas a écrit : > Nicolas George <nicolas$ wrote: > >>Thomas wrote in messag >> >>>alors pourquoi netstat n'a rien dit ?? >> >>Parce que tu ne lui as pas demandé d'afficher les sockets en écoute. > > si, mais que en ipv4
Ah, j'y avais pensé...
> et il y a bien un pb, puisque sshd n'écoute que en ipv6 .... > > qqn a une idée ?
Il n'y a pas vraiment de problème. C'est le comportement par défaut du noyau Linux qui considère qu'une socket IPv6 en écoute sur :: écoute aussi en IPv4 sur 0.0.0.0. Par défaut, sshd crée d'abord la socket IPv6 puis la socket IPv4. Mais comme la socket IPv6 écoute déjà sur 0.0.0.0, la création de la socket IPv4 échoue. Mais ce n'est pas bien grave. Tu peux tester que sshd est bien accessible en IPv4 avec par exemple :
$ telnet 127.0.0.1 22
qui devrait afficher la bannière du sshd.
merci bcp, c'est bon :-)
L'inconvénient, c'est que les adresses IPv4 des clients sont vues sous forme d'adresses IPv6 "IPv4-mapped" ::ffff:w.x.y.z. Cela pourrait éventuellement perturber des ACL ou des outils de vérification de logs.
ah bon en tout cas c'est embêtant au moins pour des trucs comme netstat du coup, je vais être embêté (un peu) quand un socket va faire de l'ipv6 mais pas de l'ipv4
Si tu n'as pas besoin que sshd écoute en IPv6, tu peux décommenter la directive "ListenAddress 0.0.0.0" dans sshd_config et relancer sshd, ou bien lancer sshd avec l'option -4. Si tu veux que sshd écoute en IPv4 et IPv6 mais sur des sockets séparées, tu peux mettre le paramètre du noyau /proc/sys/net/ipv6/bindv6only à 1 pour empêcher les communications en IPv4 avec une socket IPv6. Attention, cela s'applique à toutes les sockets IPv6 créées après qu'il ait été modifié.
même si le socket est le même je suppose pour des raisons de simplicité ou de passage transparent, pourquoi est ce que ça ne fonctionne pas au niveau logiciel comme si c'était uniquement en ipv4 aussi ? amha ça serait plus simple
mais bon, ça dépend probablement de subtilités du pont entre ipv4 et ipv6 que je comprendrais plus tard :-)
sous mac os x, (jusque là) tout ce qui apparaît en ipv6 apparaît "en doublon" en ipv4
MacOS X est basé sur un noyau de je ne sais plus quelle variante de BSD, qui ne gère pas les sockets IPv6 de la même façon que Linux. Il est donc possible d'ouvrir des sockets IPv4 et IPv6 en écoute sur le même port sans conflit.
donc, comme je ne m'occupe pas d'ipv6 pour l'instant, je me suis simplement dégagé l'écran :-)
Mal t'en a pris cette fois-ci. :-p
Il ne serait pas le premier à commettre cette erreur, tout le monde n'est pas familiarisé avec IPv6. Il devra ajouter --inet6 ou -6.
il suffit de --tcp pour prendre les 2 à la fois
ah oui, vous voulez aussi voir l'udp :-)
Ouais, je veux. Et les sockets raw aussi, y a pas que TCP et UDP dans la vie.
sous mac os x, (jusque là) tout ce qui apparaît en ipv6 apparaît "en
doublon" en ipv4
MacOS X est basé sur un noyau de je ne sais plus quelle variante de BSD,
qui ne gère pas les sockets IPv6 de la même façon que Linux. Il est donc
possible d'ouvrir des sockets IPv4 et IPv6 en écoute sur le même port
sans conflit.
donc, comme je ne m'occupe pas d'ipv6 pour l'instant, je me suis
simplement dégagé l'écran :-)
Mal t'en a pris cette fois-ci. :-p
Il ne serait pas le premier à commettre cette erreur, tout le
monde n'est pas familiarisé avec IPv6. Il devra ajouter --inet6 ou -6.
il suffit de --tcp pour prendre les 2 à la fois
ah oui, vous voulez aussi voir l'udp :-)
Ouais, je veux. Et les sockets raw aussi, y a pas que TCP et UDP dans la
vie.
sous mac os x, (jusque là) tout ce qui apparaît en ipv6 apparaît "en doublon" en ipv4
MacOS X est basé sur un noyau de je ne sais plus quelle variante de BSD, qui ne gère pas les sockets IPv6 de la même façon que Linux. Il est donc possible d'ouvrir des sockets IPv4 et IPv6 en écoute sur le même port sans conflit.
donc, comme je ne m'occupe pas d'ipv6 pour l'instant, je me suis simplement dégagé l'écran :-)
Mal t'en a pris cette fois-ci. :-p
Il ne serait pas le premier à commettre cette erreur, tout le monde n'est pas familiarisé avec IPv6. Il devra ajouter --inet6 ou -6.
il suffit de --tcp pour prendre les 2 à la fois
ah oui, vous voulez aussi voir l'udp :-)
Ouais, je veux. Et les sockets raw aussi, y a pas que TCP et UDP dans la vie.
Pascal Hambourg
Thomas a écrit :
Pascal Hambourg wrote:
L'inconvénient, c'est que les adresses IPv4 des clients sont vues sous forme d'adresses IPv6 "IPv4-mapped" ::ffff:w.x.y.z. Cela pourrait éventuellement perturber des ACL ou des outils de vérification de logs.
en tout cas c'est embêtant au moins pour des trucs comme netstat
Oui, je trouve que ce ::ffff: rend l'affichage moins lisible.
du coup, je vais être embêté (un peu) quand un socket va faire de l'ipv6 mais pas de l'ipv4
J'ai indiqué plusieurs solutions pour éviter cela.
même si le socket est le même je suppose pour des raisons de simplicité ou de passage transparent,
Oui, d'après ce que j'ai compris l'intention était de faciliter la transition d'une application IPv4-seul vers une application IPv4+IPv6 sans doubler le nombre de sockets.
pourquoi est ce que ça ne fonctionne pas au niveau logiciel comme si c'était uniquement en ipv4 aussi ?
Une socket IPv6 ne peut manipuler que des adresses IPv6. Les adresses IPv4 sont donc représentées sous la forme d'adresses IPv6 équivalentes.
L'inconvénient, c'est que les adresses IPv4 des clients sont vues sous
forme d'adresses IPv6 "IPv4-mapped" ::ffff:w.x.y.z. Cela pourrait
éventuellement perturber des ACL ou des outils de vérification de logs.
en tout cas c'est embêtant au moins pour des trucs comme netstat
Oui, je trouve que ce ::ffff: rend l'affichage moins lisible.
du coup, je vais être embêté (un peu) quand un socket va faire de l'ipv6
mais pas de l'ipv4
J'ai indiqué plusieurs solutions pour éviter cela.
même si le socket est le même je suppose pour des raisons de simplicité
ou de passage transparent,
Oui, d'après ce que j'ai compris l'intention était de faciliter la
transition d'une application IPv4-seul vers une application IPv4+IPv6
sans doubler le nombre de sockets.
pourquoi est ce que ça ne fonctionne pas au
niveau logiciel comme si c'était uniquement en ipv4 aussi ?
Une socket IPv6 ne peut manipuler que des adresses IPv6. Les adresses
IPv4 sont donc représentées sous la forme d'adresses IPv6 équivalentes.
L'inconvénient, c'est que les adresses IPv4 des clients sont vues sous forme d'adresses IPv6 "IPv4-mapped" ::ffff:w.x.y.z. Cela pourrait éventuellement perturber des ACL ou des outils de vérification de logs.
en tout cas c'est embêtant au moins pour des trucs comme netstat
Oui, je trouve que ce ::ffff: rend l'affichage moins lisible.
du coup, je vais être embêté (un peu) quand un socket va faire de l'ipv6 mais pas de l'ipv4
J'ai indiqué plusieurs solutions pour éviter cela.
même si le socket est le même je suppose pour des raisons de simplicité ou de passage transparent,
Oui, d'après ce que j'ai compris l'intention était de faciliter la transition d'une application IPv4-seul vers une application IPv4+IPv6 sans doubler le nombre de sockets.
pourquoi est ce que ça ne fonctionne pas au niveau logiciel comme si c'était uniquement en ipv4 aussi ?
Une socket IPv6 ne peut manipuler que des adresses IPv6. Les adresses IPv4 sont donc représentées sous la forme d'adresses IPv6 équivalentes.
Nicolas George
Pascal Hambourg wrote in message <g80u2c$2kqn$:
Oui, d'après ce que j'ai compris l'intention était de faciliter la transition d'une application IPv4-seul vers une application IPv4+IPv6 sans doubler le nombre de sockets.
Doubler le nombre de sockets, ce n'est pas un problème. Ce qui en est un, c'est de passer de une socket à plusieurs, parce que manipuler une socket toute seule est vraiment simple, alors que boucler sur plusieurs sockets est beaucoup plus pénible.
Pascal Hambourg wrote in message <g80u2c$2kqn$1@biggoron.nerim.net>:
Oui, d'après ce que j'ai compris l'intention était de faciliter la
transition d'une application IPv4-seul vers une application IPv4+IPv6
sans doubler le nombre de sockets.
Doubler le nombre de sockets, ce n'est pas un problème. Ce qui en est un,
c'est de passer de une socket à plusieurs, parce que manipuler une socket
toute seule est vraiment simple, alors que boucler sur plusieurs sockets est
beaucoup plus pénible.
Oui, d'après ce que j'ai compris l'intention était de faciliter la transition d'une application IPv4-seul vers une application IPv4+IPv6 sans doubler le nombre de sockets.
Doubler le nombre de sockets, ce n'est pas un problème. Ce qui en est un, c'est de passer de une socket à plusieurs, parce que manipuler une socket toute seule est vraiment simple, alors que boucler sur plusieurs sockets est beaucoup plus pénible.
