dhclient, resolv.conf et ipv6

Le
Thomas Preud'homme
--nextPart27925208.nKgHWSNMhA
Content-Type: text/plain;
charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Bonjour à tous,

je souhaiterai avoir une machine qui récupère une adresse une IPv=
4 et IPv6 si
cela est possible (c'est fait) et fasse par défaut des requêtes D=
NS IPv6. Je
souhaite aussi avoir systématiquement un search sur 3 domaines en plus=
de
ceux fourni par l'éventuel DHCP IPv4 disponible.

J'ai réussi à faire tout ceci de manière propre avec né=
anmoins une perte de
contrôle sur le fichier resolv.conf généré. Là est=
mon problème.

Voici ce que j'ai fait pour obtenir ce résultat.

1) Au début j'avais ajouté append domain-search domaine1 domaine2=
domain3 à
dhclient.conf afin d'inclure systématiquement les domaines 1 2 et 3 au=
x
recherches par défaut, en plus de ceux reçus par DHCP.

2) Ensuite, j'ai regardé du côté du man de resolv.conf et ai=
découvert
l'option inet6. Celle-ci marche bien puisque je peux voir la tortue de
kame.net qui danse. Malgré tout au premier invoke-rc.d networking rest=
art
venu, le fichier resolv.conf est régénéré et "options i=
net6" disparait. Il ne
semble y avoir aucune option dans dhclient.conf pour ajouter au fichier
resolv.conf généré l'option inet6, ce qui est assez logique =
puisque
dhclient.conf ne concerne que le DHCP IPv4.

3) J'ai donc regardé du côté de resolvconf et ai pu obtenir =
ma configuration
actuelle en ajoutant options inet6 dans le
fichier /etc/resolvconf/resolv.conf.d/tail et search domain1 domain2 domain=
3
dans /etc/resolvconf/resolv.conf.d/base

Là où le bas blesse c'est que d'après le fichier README.gz, =
la fusion entre le
fichier base et ce que retourne dhclient se fait en ajoutant les informatio=
ns
après celles du fichier base :

- resolv.conf.d/base
Information always included in the resolv.conf file. Dynamic
information gets merged with this information. E.g., if base
contains 'search a.b.c' and another record is added that contains
'search x.y.z' then the resulting file will have
'search a.b.c x.y.z'.

resolvconf semble être donc beaucoup moins souple que dhclient qui per=
met de
remplacer, ajouter au début ou ajouter à la fin certaines informa=
tions. La
seule solution que je vois serait d'utiliser uniquement dhclient.conf (et
donc supprimer resolvconf) et modifier les hook de dhclient pour ajouter
options inet6 à la fin du resolv.conf. Mais je ne trouve pas cela tr=
ès joli,
qu'en pensez-vous ?

J'en profite au passage pour vous notifier d'un avantage à IPv6 auquel=
je
n'avais jamais pensé. Si je fais un reconfigure les interfaces ré=
seaux en
écoutant un flux radio, celui-ci se poursuivra (éventuellement av=
ec une
coupure si le buffer est trop petit) sans problème, n'ayant aucune m=
émoire
contrairement au NAT.

En espérant que mon petit bricolage serve un jour à quelqu'un.

Cordialement,

Thomas Preud'homme

--
Why debian : http://www.debian.org/intro/why_debian

--nextPart27925208.nKgHWSNMhA
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part.

--BEGIN PGP SIGNATURE--
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEABECAAYFAkk5Z2wACgkQuQM2KpxEui5PNwCglwYK7G71acsrRY6zg7WzbpuG
/d0AnRudksGQJ8Ex4KOjrwiqqELDYHk4
=+Fpo
--END PGP SIGNATURE--

--nextPart27925208.nKgHWSNMhA--

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/DebFrFrenchLists
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Pascal Hambourg
Le #18057461
Salut,

Thomas Preud'homme a écrit :

2) Ensuite, j'ai regardé du côté du man de resolv.conf et ai découvert
l'option inet6. Celle-ci marche bien puisque je peux voir la tortue de
kame.net qui danse.



Jamais eu besoin de cette option pour faire les résolutions DNS en
adresse IPv6 en premier. C'est le cas par défaut, ce que certains
regrettent.

Malgré tout au premier invoke-rc.d networking restart
venu, le fichier resolv.conf est régénéré et "options inet6" disparait.



Et alors, ensuite la tortue ne danse plus ? Si c'est le cas, ça ne vient
probablement pas de l'option inet6 manquante.

J'en profite au passage pour vous notifier d'un avantage à IPv6 auquel je
n'avais jamais pensé. Si je fais un reconfigure les interfaces réseaux en
écoutant un flux radio, celui-ci se poursuivra (éventuellement avec une
coupure si le buffer est trop petit) sans problème, n'ayant aucune mémoire
contrairement au NAT.



Je ne vois pas le rapport. Tu peux détailler ?

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/DebFrFrenchLists
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Thomas Preud'homme
Le #18059511
--nextPart2522249.vOIU8Ypeuq
Content-Type: text/plain;
charset="iso-8859-15"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

The Friday 05 December 2008 20:24:39 Pascal Hambourg, you wrote :
Salut,

Thomas Preud'homme a écrit :
> 2) Ensuite, j'ai regardé du côté du man de resolv.conf et ai dé couvert
> l'option inet6. Celle-ci marche bien puisque je peux voir la tortue de
> kame.net qui danse.

Jamais eu besoin de cette option pour faire les résolutions DNS en
adresse IPv6 en premier. C'est le cas par défaut, ce que certains
regrettent.



Pas chez moi en tout cas. Si je retire inet6 la tortue ne danse plus. As-tu
quelque chose de spécial dans sysctl.conf ?


> Malgré tout au premier invoke-rc.d networking restart
> venu, le fichier resolv.conf est régénéré et "options inet6" di sparait.

Et alors, ensuite la tortue ne danse plus ? Si c'est le cas, ça ne vient
probablement pas de l'option inet6 manquante.



Oui si je retire cette option la tortue ne danse plus. En plus d'après le man
de resolv.conf options inet6 sert précisément à demander à faire de s requêtes
IPv6 avant IPv4 donc cela me semble cohérent comme comportement, non ? Je
suis curieux de savoir ce qui te donne le même comportement sans l'option
inet6 dans resolv.conf


> J'en profite au passage pour vous notifier d'un avantage à IPv6 auque l je
> n'avais jamais pensé. Si je fais un reconfigure les interfaces rése aux en
> écoutant un flux radio, celui-ci se poursuivra (éventuellement avec une
> coupure si le buffer est trop petit) sans problème, n'ayant aucune
> mémoire contrairement au NAT.

Je ne vois pas le rapport. Tu peux détailler ?



Mmmmmmh maintenant que tu me demandes j'avoue que je ne vois effectivement pas
le rapport. Les bails du serveur DHCP n'ont rien à voir avec le suivi de
connexion d'iptables. Donc même en renouvelant la requête dhcp ça ne devrait
avoir aucun effet sur la règle qui laisse passer les connexions établie s. Et
sinon le fait de redémarrer l'interface réseau devrait effectivement m ême
dans ce cas purger iptables et donc considérer les paquets arrivant à p artir
de ce moment comme une nouvelle connexion. Pourtant il y a bien un effet
quelque part, avant un restart me faisait systématiquement perdre le flux ,
plus maintenant...


Cordialement,

Thomas Preud'homme

--
Why debian : http://www.debian.org/intro/why_debian

--nextPart2522249.vOIU8Ypeuq
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEABECAAYFAkk5zF8ACgkQuQM2KpxEui5pkQCdHX1FSbfbffuQSUbd6dhvLnG0
WkgAnROrVHPHZ3HgOfzjpppmdRwZUg7D
=OKYA
-----END PGP SIGNATURE-----

--nextPart2522249.vOIU8Ypeuq--

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/DebFrFrenchLists
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Stephane Bortzmeyer
Le #18066281
On Fri, Dec 05, 2008 at 06:39:56PM +0100,
Thomas Preud'homme a message of 112 lines which said:

2) Ensuite, j'ai regardé du côté du man de resolv.conf et ai découvert
l'option inet6.



Je ne me suis jamais servi de cette option (et j'utilise
IPv6). D'après le manuel, elle sert à demander des enregistrements
AAAA même lorsque l'application client a utilisé gethostbyname(), le
vieux sous-programme de traduction de nom en adresse, remplacé depuis
dix ans par getaddrinfo(). Cette option me semble donc inutile.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/DebFrFrenchLists
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Stephane Bortzmeyer
Le #18066271
On Fri, Dec 05, 2008 at 08:24:39PM +0100,
Pascal Hambourg a message of 34 lines which said:

C'est le cas par défaut, ce que certains regrettent.



Pourquoi n'éditent-ils pas leur /etc/gai.conf s'ils préfèrent IPv4 ?

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/DebFrFrenchLists
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Pascal Hambourg
Le #18069971
Stephane Bortzmeyer a écrit :

Pourquoi n'éditent-ils pas leur /etc/gai.conf s'ils préfèrent IPv4 ?



Peut-être parce qu'ils ne connaissent pas (et moi non plus).

L'exemple de la page de manuel ne contient que des préfixes IPv6, et la
RFC 3484 à laquelle elle se réfère ne concerne que les adresses IPv6.
Comment peut-on utiliser gai.conf pour favoriser les adresses IPv4 ?

Au fait, c'est utilisable avec la glibc d'etch ? Le paquet libc6 ne
contient ni ce fichier ni sa page de manuel.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/DebFrFrenchLists
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Pascal Hambourg
Le #18069961
Stephane Bortzmeyer a écrit :
Thomas Preud'homme a message of 112 lines which said:

2) Ensuite, j'ai regardé du côté du man de resolv.conf et ai découvert
l'option inet6.



Je ne me suis jamais servi de cette option (et j'utilise
IPv6). D'après le manuel, elle sert à demander des enregistrements
AAAA même lorsque l'application client a utilisé gethostbyname(), le
vieux sous-programme de traduction de nom en adresse, remplacé depuis
dix ans par getaddrinfo(). Cette option me semble donc inutile.



J'ai eu des résultats bizarres avec nc lorsque je l'ai spécifiée. Faut
que je creuse un peu plus.

La page de manuel dit "mapping IPv4 responses in IPv6 tunnelled form".
As-tu une idée de quelle "tunnelled form" il s'agit ? 6to4,
IPv4-compatible, IPv4-mapped... ?

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/DebFrFrenchLists
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Pascal Hambourg
Le #18070551
Thomas Preud'homme a écrit :
The Friday 05 December 2008 20:24:39 Pascal Hambourg, you wrote :
Thomas Preud'homme a écrit :
2) Ensuite, j'ai regardé du côté du man de resolv.conf et ai découvert
l'option inet6. Celle-ci marche bien puisque je peux voir la tortue de
kame.net qui danse.


Jamais eu besoin de cette option pour faire les résolutions DNS en
adresse IPv6 en premier. C'est le cas par défaut, ce que certains
regrettent.



Pas chez moi en tout cas. Si je retire inet6 la tortue ne danse plus. As-tu
quelque chose de spécial dans sysctl.conf ?



Concernant IPv6, sur certaines machines j'ai net.ipv6.bindv6only=1 pour
empêcher les communications IPv4 sur les sockets IPv6. Au départ c'était
pour contourner un bug de BIND9, mais ça a aussi un effet de bord
intéressant : les adresses IPv4 n'apparaissent plus sous la forme
::ffff:x.y.z.t dans les logs. Mais la résolution DNS se comporte de la
même façon sur toutes mes Debian (sarge et etch), même celles qui n'ont
pas ce réglage. Et puis je ne vois pas trop en quoi un paramètre du
noyau pourrait influencer la résolution DNS de la glibc qui est en userland.

Il faudrait creuser un peu plus pour voir ce qui se passe, notamment
faire une capture des paquets DNS, et utiliser des outils plus bas
niveau qu'un navigateur, par exemple telnet qui fonctionne en IPv4 et
IPv6, et affiche l'adresse destination effectivement choisie pour
établir la connexion.

J'en profite au passage pour vous notifier d'un avantage à IPv6 auquel je
n'avais jamais pensé. Si je fais un reconfigure les interfaces réseaux en
écoutant un flux radio, celui-ci se poursuivra (éventuellement avec une
coupure si le buffer est trop petit) sans problème, n'ayant aucune
mémoire contrairement au NAT.


Je ne vois pas le rapport. Tu peux détailler ?



Mmmmmmh maintenant que tu me demandes j'avoue que je ne vois effectivement pas
le rapport. Les bails du serveur DHCP n'ont rien à voir avec le suivi de
connexion d'iptables.



En effet. Sauf si la machine utilise la cible MASQUERADE sur ces
connexions. Quand l'adresse IPv4 de l'interface de sortie change, les
connexions masquées avec l'ancienne adresse sont supprimées.

Donc même en renouvelant la requête dhcp ça ne devrait
avoir aucun effet sur la règle qui laisse passer les connexions établies. Et
sinon le fait de redémarrer l'interface réseau devrait effectivement même
dans ce cas purger iptables et donc considérer les paquets arrivant à partir
de ce moment comme une nouvelle connexion.



Pas forcément. Hors le cas de MASQUERADE mentionné plus haut, pour
purger la table de suivi des connexions il faut décharger le module
noyau correspondant ou le faire explicitement avec le programme
'conntrack' du paquet du même nom.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/DebFrFrenchLists
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Thomas Preud'homme
Le #18072421
--nextPart1258880.5nrW7fpVSX
Content-Type: text/plain;
charset="iso-8859-15"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

The Sunday 07 December 2008 14:27:49 Pascal Hambourg, you wrote :
Thomas Preud'homme a écrit :
> The Friday 05 December 2008 20:24:39 Pascal Hambourg, you wrote :
>> Thomas Preud'homme a écrit :
>>> 2) Ensuite, j'ai regardé du côté du man de resolv.conf et ai d écouvert
>>> l'option inet6. Celle-ci marche bien puisque je peux voir la tortue de
>>> kame.net qui danse.
>>
>> Jamais eu besoin de cette option pour faire les résolutions DNS en
>> adresse IPv6 en premier. C'est le cas par défaut, ce que certains
>> regrettent.
>
> Pas chez moi en tout cas. Si je retire inet6 la tortue ne danse plus.
> As-tu quelque chose de spécial dans sysctl.conf ?

Concernant IPv6, sur certaines machines j'ai net.ipv6.bindv6only=1 pour
empêcher les communications IPv4 sur les sockets IPv6. Au départ c' était
pour contourner un bug de BIND9, mais ça a aussi un effet de bord
intéressant : les adresses IPv4 n'apparaissent plus sous la forme

::ffff:x.y.z.t dans les logs. Mais la résolution DNS se comporte de la

même façon sur toutes mes Debian (sarge et etch), même celles qui n 'ont
pas ce réglage. Et puis je ne vois pas trop en quoi un paramètre du
noyau pourrait influencer la résolution DNS de la glibc qui est en
userland.

Il faudrait creuser un peu plus pour voir ce qui se passe, notamment
faire une capture des paquets DNS, et utiliser des outils plus bas
niveau qu'un navigateur, par exemple telnet qui fonctionne en IPv4 et
IPv6, et affiche l'adresse destination effectivement choisie pour
établir la connexion.



Je veux bien regarder mais a priori il n'y a juste aucune tentative pour
récupérer un champ AAAA. Ou en tout cas s'il y en a une c'est pas l'adr esse
choisie. Il doit bien y avoir un paramètre chez moi qui pose problème.
Pourriez-vous coller un /etc/network/interfaces à tout hasard (je doute q ue
le problème se situe dans ce fichier mais sait-on jamais).


>>> J'en profite au passage pour vous notifier d'un avantage à IPv6 auq uel
>>> je n'avais jamais pensé. Si je fais un reconfigure les interfaces
>>> réseaux en écoutant un flux radio, celui-ci se poursuivra
>>> (éventuellement avec une coupure si le buffer est trop petit) sans
>>> problème, n'ayant aucune mémoire contrairement au NAT.
>>
>> Je ne vois pas le rapport. Tu peux détailler ?
>
> Mmmmmmh maintenant que tu me demandes j'avoue que je ne vois
> effectivement pas le rapport. Les bails du serveur DHCP n'ont rien à voir
> avec le suivi de connexion d'iptables.

En effet. Sauf si la machine utilise la cible MASQUERADE sur ces
connexions. Quand l'adresse IPv4 de l'interface de sortie change, les
connexions masquées avec l'ancienne adresse sont supprimées.



Ce n'est pas le cas, c'est le routeur qui l'utilise. Et je n'ai plus de
routeur depuis deux mois environ. De plus mon IP externe était fixe comme les
IPs du réseau local (fixée par adresse MAC dans dhcpd.conf).


> Donc même en renouvelant la requête dhcp ça ne devrait
> avoir aucun effet sur la règle qui laisse passer les connexions éta blies.
> Et sinon le fait de redémarrer l'interface réseau devrait effective ment
> même dans ce cas purger iptables et donc considérer les paquets arr ivant
> à partir de ce moment comme une nouvelle connexion.

Pas forcément. Hors le cas de MASQUERADE mentionné plus haut, pour
purger la table de suivi des connexions il faut décharger le module
noyau correspondant ou le faire explicitement avec le programme
'conntrack' du paquet du même nom.




Cordialement,

Thomas Preud'homme

--
Why debian : http://www.debian.org/intro/why_debian

--nextPart1258880.5nrW7fpVSX
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEABECAAYFAkk7+58ACgkQuQM2KpxEui4gOQCffCpaMpYdjZvFtVAxZUR2OfWI
XKsAnj+1uIgykGgPQZF0ZjKMopspJ3I/
=hFTH
-----END PGP SIGNATURE-----

--nextPart1258880.5nrW7fpVSX--

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/DebFrFrenchLists
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Thomas Preud'homme
Le #18072401
--nextPart1434950.UyHTufNil9
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

The Saturday 06 December 2008 21:37:46 Stephane Bortzmeyer, you wrote :
On Fri, Dec 05, 2008 at 06:39:56PM +0100,
Thomas Preud'homme
a message of 112 lines which said:
> 2) Ensuite, j'ai regardé du côté du man de resolv.conf et ai dé couvert
> l'option inet6.

Je ne me suis jamais servi de cette option (et j'utilise
IPv6). D'après le manuel, elle sert à demander des enregistrements
AAAA même lorsque l'application client a utilisé gethostbyname(), le
vieux sous-programme de traduction de nom en adresse, remplacé depuis
dix ans par getaddrinfo(). Cette option me semble donc inutile.




Ah intéressant. Tout du moins si je rencontre des problèmes avec des vi eux
programmes. Ceci dit je ne vois pas pourquoi je n'ai pas d'IPv6 sans inet6.
Quelqu'un aurait-il une idée d'un fichier qui pourrait poser problème ? Il
doit bien y avoir un fichier sur le système pour spécifier la préfé rence
entre IPv6 et IPv4. J'ai regardé gai.conf mais tout est commenté donc c ela ne
doit pas venir de là.

Merci pour vos réponses, j'ai au moins appris des choses ce qui en soit e st
déjà très bien.

Cordialement,

Thomas Preud'homme

--
Why debian : http://www.debian.org/intro/why_debian

--nextPart1434950.UyHTufNil9
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEABECAAYFAkk7/IkACgkQuQM2KpxEui57SwCbBlKy6wkzCCs7MLNBJ0TndprF
3b4An3WvbN+eHqh/SpzrkTlPYESe+KsL
¾GS
-----END PGP SIGNATURE-----

--nextPart1434950.UyHTufNil9--

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/DebFrFrenchLists
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Stephane Bortzmeyer
Le #18074091
On Sun, Dec 07, 2008 at 12:59:13PM +0100,
Pascal Hambourg a message of 21 lines which said:

Peut-être parce qu'ils ne connaissent pas (et moi non plus).



http://www.bortzmeyer.org/5220.html

L'exemple de la page de manuel ne contient que des préfixes IPv6, et
la RFC 3484 à laquelle elle se réfère ne concerne que les adresses
IPv6. Comment peut-on utiliser gai.conf pour favoriser les adresses
IPv4 ?



% cat /etc/gai.conf
# For testing purposes, always use IPv6 for AFNIC
precedence 2001:660:3003:2::/48 200
precedence 2001:660:3003:3::/48 200
# Otherwise, always prefer IPv4
precedence ::ffff:0:0/96 100

(C'est documenté dans /etc/gai.conf lui-même, dans les commentaires.)

Au fait, c'est utilisable avec la glibc d'etch ?



En effet, ça semble être apparu avec lenny.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/DebFrFrenchLists
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Publicité
Poster une réponse
Anonyme