Une étude récente effectuée par échantillonnage sur des hits (par)
google montre une adoption progressive du nouveau protocole IPv6, mais
part d'un niveau très bas. A ce rythme, on ne peut qu'être sceptique
vis-à-vis des deadlines annoncées pour 2011/2012.
"Evaluating IPv6 Adoption in the Internet"
http://www.pam2010.ethz.ch/papers/full-length/15.pdf
La France est l'un des pays en pointe, mais c'est uniquement dû à un
seul opérateur, Free, qui offre depuis plusieurs mois le support IPv6
par un simple clic.
"Note the ASes in both tables are the same. 6 out of 7 ASes shown in
Table 1 and 2 are universities or research institutions. The only
exception - Free (AS12322) contributes to most of the French IPv6 native
hits (presented in Fig. 7)."
Les conclusions: un niveau encore très bas de connectivité, mais qui
monte de manière progressive, une lattence comparable à IPv4. Un des
facteurs d'adoption est la configuration par défaut des OS, ce qui n'est
guère surprenant.
"Pascal Hambourg" a écrit dans le message de news: 4c49f14d$0$27578$
Williamhoustra a écrit :
L'IPv4 ne fonctionne déjà plus bien depuis longtemps (pénurie d'adresses IP et toutes ses conséquences), et ça date d'avant la démocratisation d'internet. En fait c'est peut-être ça le problème, le bon peuple n'a connu que cette situation et trouve ça normal.
vous avez vu ou qu' IPV4 ne fonctionne "plus bien" ???
"Pascal Hambourg" <boite-a-spam@plouf.fr.eu.org> a écrit dans le message de
news: 4c49f14d$0$27578$ba4acef3@reader.news.orange.fr...
Williamhoustra a écrit :
L'IPv4 ne fonctionne déjà plus bien depuis longtemps (pénurie d'adresses
IP et toutes ses conséquences), et ça date d'avant la démocratisation
d'internet. En fait c'est peut-être ça le problème, le bon peuple n'a
connu que cette situation et trouve ça normal.
vous avez vu ou qu' IPV4 ne fonctionne "plus bien" ???
"Pascal Hambourg" a écrit dans le message de news: 4c49f14d$0$27578$
Williamhoustra a écrit :
L'IPv4 ne fonctionne déjà plus bien depuis longtemps (pénurie d'adresses IP et toutes ses conséquences), et ça date d'avant la démocratisation d'internet. En fait c'est peut-être ça le problème, le bon peuple n'a connu que cette situation et trouve ça normal.
vous avez vu ou qu' IPV4 ne fonctionne "plus bien" ???
Eric Masson
"Telco67" writes:
'Lut,
vous avez vu ou qu' IPV4 ne fonctionne "plus bien" ???
Le principe de communication de bout en bout est invalidé par les dispositifs nat.
Deux petits exemples pour la route : - h323 qui nécessite une modification à la volée de la payload des paquets dès lors qu'un dispositif nat est présent sur le trajet. - ipsec qui nécessite l'utilisation de l'extension NAT-T pour fonctionner correctement dans les mêmes conditions.
On peut donc effectivement dire qu'ipv4 du fait de l'usage généralisé de la NAT ne fonctionne plus bien et que l'on empile des hacks plus ou moins heureux pour minimiser les dégâts.
-- «Je suis en train de peaufiner les definitions de locales pour le vietnamien; est-ce que pour l'ordre alphabetique les lettres A(, A^, DD, E^, O^, O+ et U+ sont bien considerées comme des lettres à part ?» Pablo in Guide du linuxien pervers : "Les locales ? C'est simple !"
"Telco67" <telco67@widevoip.com> writes:
'Lut,
vous avez vu ou qu' IPV4 ne fonctionne "plus bien" ???
Le principe de communication de bout en bout est invalidé par les
dispositifs nat.
Deux petits exemples pour la route :
- h323 qui nécessite une modification à la volée de la payload des
paquets dès lors qu'un dispositif nat est présent sur le trajet.
- ipsec qui nécessite l'utilisation de l'extension NAT-T pour
fonctionner correctement dans les mêmes conditions.
On peut donc effectivement dire qu'ipv4 du fait de l'usage généralisé de
la NAT ne fonctionne plus bien et que l'on empile des hacks plus ou
moins heureux pour minimiser les dégâts.
--
«Je suis en train de peaufiner les definitions de locales pour le vietnamien;
est-ce que pour l'ordre alphabetique les lettres A(, A^, DD, E^, O^, O+ et U+
sont bien considerées comme des lettres à part ?»
Pablo in Guide du linuxien pervers : "Les locales ? C'est simple !"
vous avez vu ou qu' IPV4 ne fonctionne "plus bien" ???
Le principe de communication de bout en bout est invalidé par les dispositifs nat.
Deux petits exemples pour la route : - h323 qui nécessite une modification à la volée de la payload des paquets dès lors qu'un dispositif nat est présent sur le trajet. - ipsec qui nécessite l'utilisation de l'extension NAT-T pour fonctionner correctement dans les mêmes conditions.
On peut donc effectivement dire qu'ipv4 du fait de l'usage généralisé de la NAT ne fonctionne plus bien et que l'on empile des hacks plus ou moins heureux pour minimiser les dégâts.
-- «Je suis en train de peaufiner les definitions de locales pour le vietnamien; est-ce que pour l'ordre alphabetique les lettres A(, A^, DD, E^, O^, O+ et U+ sont bien considerées comme des lettres à part ?» Pablo in Guide du linuxien pervers : "Les locales ? C'est simple !"
Pascal Hambourg
Eric Masson a écrit :
Le principe de communication de bout en bout est invalidé par les dispositifs nat.
Le premier responsable de cette remise en cause est l'utilisation d'adresses privées non routées sur l'internet public. Le NAT sert à restaurer une certaine connectivité pour les machines utilisant ce type d'adresse, mais il a ses faiblesses et ses limites.
Deux petits exemples pour la route : - h323 qui nécessite une modification à la volée de la payload des paquets dès lors qu'un dispositif nat est présent sur le trajet.
On peut généraliser aux protocoles "complexes" impliquant une connexion de contrôle transportant des informations pour l'établissement dynamique de connexions de données séparées : FTP, SIP, RTP... La modification à la volée est impossible dans le cas de protocoles chiffrés comme FTPS.
- ipsec qui nécessite l'utilisation de l'extension NAT-T pour fonctionner correctement dans les mêmes conditions.
Là encore même si le cas d'IPSec est particulier (interdiction de modifier les paquets), on peut généraliser aux protocoles non TCP ou UDP qui n'ont pas la notion de ports (utilisés par le NAT pour différencier les connexions), notamment les protocoles de tunnelling comme GRE ou le protocole 41 de tunnel IPv6 (d'où la création de protocoles usines à gaz basés sur UDP comme Teredo).
Eric Masson a écrit :
Le principe de communication de bout en bout est invalidé par les
dispositifs nat.
Le premier responsable de cette remise en cause est l'utilisation
d'adresses privées non routées sur l'internet public. Le NAT sert à
restaurer une certaine connectivité pour les machines utilisant ce type
d'adresse, mais il a ses faiblesses et ses limites.
Deux petits exemples pour la route :
- h323 qui nécessite une modification à la volée de la payload des
paquets dès lors qu'un dispositif nat est présent sur le trajet.
On peut généraliser aux protocoles "complexes" impliquant une connexion
de contrôle transportant des informations pour l'établissement dynamique
de connexions de données séparées : FTP, SIP, RTP...
La modification à la volée est impossible dans le cas de protocoles
chiffrés comme FTPS.
- ipsec qui nécessite l'utilisation de l'extension NAT-T pour
fonctionner correctement dans les mêmes conditions.
Là encore même si le cas d'IPSec est particulier (interdiction de
modifier les paquets), on peut généraliser aux protocoles non TCP ou UDP
qui n'ont pas la notion de ports (utilisés par le NAT pour différencier
les connexions), notamment les protocoles de tunnelling comme GRE ou le
protocole 41 de tunnel IPv6 (d'où la création de protocoles usines à gaz
basés sur UDP comme Teredo).
Le principe de communication de bout en bout est invalidé par les dispositifs nat.
Le premier responsable de cette remise en cause est l'utilisation d'adresses privées non routées sur l'internet public. Le NAT sert à restaurer une certaine connectivité pour les machines utilisant ce type d'adresse, mais il a ses faiblesses et ses limites.
Deux petits exemples pour la route : - h323 qui nécessite une modification à la volée de la payload des paquets dès lors qu'un dispositif nat est présent sur le trajet.
On peut généraliser aux protocoles "complexes" impliquant une connexion de contrôle transportant des informations pour l'établissement dynamique de connexions de données séparées : FTP, SIP, RTP... La modification à la volée est impossible dans le cas de protocoles chiffrés comme FTPS.
- ipsec qui nécessite l'utilisation de l'extension NAT-T pour fonctionner correctement dans les mêmes conditions.
Là encore même si le cas d'IPSec est particulier (interdiction de modifier les paquets), on peut généraliser aux protocoles non TCP ou UDP qui n'ont pas la notion de ports (utilisés par le NAT pour différencier les connexions), notamment les protocoles de tunnelling comme GRE ou le protocole 41 de tunnel IPv6 (d'où la création de protocoles usines à gaz basés sur UDP comme Teredo).
Xavier Roche
Eric Masson wrote:
Deux petits exemples pour la route : - h323 qui nécessite une modification à la volée de la payload des paquets dès lors qu'un dispositif nat est présent sur le trajet.
Je confirme que essayer de faire fonctionner l'usine à gaz H323 sans IP publique, c'est comme essayer de trouver un bureau de poste ouvert un dimanche de 15 août.
J'ajoute aussi la multiplication des appareils mobiles sur WiFi qui demandent des allocations d'IP publiques à la volée pour les mêmes besoins (eh oui, ipv6 c'est pas juste plus d'IP, c'est surtout la moitié de l'espace d'adressage qui reviens au client final)
Eric Masson wrote:
Deux petits exemples pour la route :
- h323 qui nécessite une modification à la volée de la payload des
paquets dès lors qu'un dispositif nat est présent sur le trajet.
Je confirme que essayer de faire fonctionner l'usine à gaz H323 sans IP
publique, c'est comme essayer de trouver un bureau de poste ouvert un
dimanche de 15 août.
J'ajoute aussi la multiplication des appareils mobiles sur WiFi qui
demandent des allocations d'IP publiques à la volée pour les mêmes
besoins (eh oui, ipv6 c'est pas juste plus d'IP, c'est surtout la moitié
de l'espace d'adressage qui reviens au client final)
Deux petits exemples pour la route : - h323 qui nécessite une modification à la volée de la payload des paquets dès lors qu'un dispositif nat est présent sur le trajet.
Je confirme que essayer de faire fonctionner l'usine à gaz H323 sans IP publique, c'est comme essayer de trouver un bureau de poste ouvert un dimanche de 15 août.
J'ajoute aussi la multiplication des appareils mobiles sur WiFi qui demandent des allocations d'IP publiques à la volée pour les mêmes besoins (eh oui, ipv6 c'est pas juste plus d'IP, c'est surtout la moitié de l'espace d'adressage qui reviens au client final)
Telco67
Le 28/07/2010 18:54, Eric Masson a écrit :
"Telco67" writes:
'Lut,
vous avez vu ou qu' IPV4 ne fonctionne "plus bien" ???
Le principe de communication de bout en bout est invalidé par les dispositifs nat.
Deux petits exemples pour la route : - h323 qui nécessite une modification à la volée de la payload des paquets dès lors qu'un dispositif nat est présent sur le trajet. - ipsec qui nécessite l'utilisation de l'extension NAT-T pour fonctionner correctement dans les mêmes conditions.
On peut donc effectivement dire qu'ipv4 du fait de l'usage généralisé de la NAT ne fonctionne plus bien et que l'on empile des hacks plus ou moins heureux pour minimiser les dégâts.
H323 et IPSEC ne sont pas prévu a la base pour faire de la NAT c'est d'autant plus vrai pour IPSEC qui est un destiné à garantir la confidentialité et l'intégrité de la donnée donc il se met en bordure de réseau et non pas dans le réseau privé ce qui invalide le besoin de NAT.
Bonne soirée
Le 28/07/2010 18:54, Eric Masson a écrit :
"Telco67"<telco67@widevoip.com> writes:
'Lut,
vous avez vu ou qu' IPV4 ne fonctionne "plus bien" ???
Le principe de communication de bout en bout est invalidé par les
dispositifs nat.
Deux petits exemples pour la route :
- h323 qui nécessite une modification à la volée de la payload des
paquets dès lors qu'un dispositif nat est présent sur le trajet.
- ipsec qui nécessite l'utilisation de l'extension NAT-T pour
fonctionner correctement dans les mêmes conditions.
On peut donc effectivement dire qu'ipv4 du fait de l'usage généralisé de
la NAT ne fonctionne plus bien et que l'on empile des hacks plus ou
moins heureux pour minimiser les dégâts.
H323 et IPSEC ne sont pas prévu a la base pour faire de la NAT
c'est d'autant plus vrai pour IPSEC qui est un destiné à garantir la
confidentialité et l'intégrité de la donnée donc il se met en bordure de
réseau et non pas dans le réseau privé ce qui invalide le besoin de NAT.
vous avez vu ou qu' IPV4 ne fonctionne "plus bien" ???
Le principe de communication de bout en bout est invalidé par les dispositifs nat.
Deux petits exemples pour la route : - h323 qui nécessite une modification à la volée de la payload des paquets dès lors qu'un dispositif nat est présent sur le trajet. - ipsec qui nécessite l'utilisation de l'extension NAT-T pour fonctionner correctement dans les mêmes conditions.
On peut donc effectivement dire qu'ipv4 du fait de l'usage généralisé de la NAT ne fonctionne plus bien et que l'on empile des hacks plus ou moins heureux pour minimiser les dégâts.
H323 et IPSEC ne sont pas prévu a la base pour faire de la NAT c'est d'autant plus vrai pour IPSEC qui est un destiné à garantir la confidentialité et l'intégrité de la donnée donc il se met en bordure de réseau et non pas dans le réseau privé ce qui invalide le besoin de NAT.
Bonne soirée
Eric Masson
Telco67 writes:
'Lut,
H323 et IPSEC ne sont pas prévu a la base pour faire de la NAT
La nat est un hack prévu pour pallier à une situation qui n'avait pas été anticipée (pénurie de l'espace d'adressage ipv4)
c'est d'autant plus vrai pour IPSEC qui est un destiné à garantir la confidentialité et l'intégrité de la donnée donc il se met en bordure de réseau et non pas dans le réseau privé ce qui invalide le besoin de NAT.
Non, les RFC IPsec prévoient deux modes (tunnel ou transport) et il est tout à fait légitime de déployer IPsec en mode transport indépendamment de la localisation des hôtes.
Ce qui a donc amené à NAT-Traversal (encapsulation udp des paquets IPsec) qui permet d'utiliser ipsec en présence d'équipements nat.
Quelque soit le sens dans lequel on prend le problème, la nat est une plaie dont ipv6 permet de s'affranchir.
-- - Tous les messages annulés ne sont pas nécéssairement à reposter... - Quitte à reposter, serait-il possible de corriger les fautes d'orthographe, par la même occasion ? -+- JL in <http://www.le-gnu.net> : Comme une lettre à la [Repost]
Telco67 <telco67@widevoip.com> writes:
'Lut,
H323 et IPSEC ne sont pas prévu a la base pour faire de la NAT
La nat est un hack prévu pour pallier à une situation qui n'avait pas
été anticipée (pénurie de l'espace d'adressage ipv4)
c'est d'autant plus vrai pour IPSEC qui est un destiné à garantir la
confidentialité et l'intégrité de la donnée donc il se met en bordure de
réseau et non pas dans le réseau privé ce qui invalide le besoin de NAT.
Non, les RFC IPsec prévoient deux modes (tunnel ou transport) et il est
tout à fait légitime de déployer IPsec en mode transport indépendamment
de la localisation des hôtes.
Ce qui a donc amené à NAT-Traversal (encapsulation udp des paquets
IPsec) qui permet d'utiliser ipsec en présence d'équipements nat.
Quelque soit le sens dans lequel on prend le problème, la nat est une
plaie dont ipv6 permet de s'affranchir.
--
- Tous les messages annulés ne sont pas nécéssairement à reposter...
- Quitte à reposter, serait-il possible de corriger les fautes
d'orthographe, par la même occasion ?
-+- JL in <http://www.le-gnu.net> : Comme une lettre à la [Repost]
H323 et IPSEC ne sont pas prévu a la base pour faire de la NAT
La nat est un hack prévu pour pallier à une situation qui n'avait pas été anticipée (pénurie de l'espace d'adressage ipv4)
c'est d'autant plus vrai pour IPSEC qui est un destiné à garantir la confidentialité et l'intégrité de la donnée donc il se met en bordure de réseau et non pas dans le réseau privé ce qui invalide le besoin de NAT.
Non, les RFC IPsec prévoient deux modes (tunnel ou transport) et il est tout à fait légitime de déployer IPsec en mode transport indépendamment de la localisation des hôtes.
Ce qui a donc amené à NAT-Traversal (encapsulation udp des paquets IPsec) qui permet d'utiliser ipsec en présence d'équipements nat.
Quelque soit le sens dans lequel on prend le problème, la nat est une plaie dont ipv6 permet de s'affranchir.
-- - Tous les messages annulés ne sont pas nécéssairement à reposter... - Quitte à reposter, serait-il possible de corriger les fautes d'orthographe, par la même occasion ? -+- JL in <http://www.le-gnu.net> : Comme une lettre à la [Repost]
Telco67
"Eric Masson" a écrit dans le message de groupe de discussion :
Telco67 writes:
Non, les RFC IPsec prévoient deux modes (tunnel ou transport) et il est tout à fait légitime de déployer IPsec en mode transport indépendamment de la localisation des hôtes.
Le mode transport c'est pour du point à point comme comme utilisé maintenant en IPV6 pour crypter les sessions OSPF par exemple
Le mode tunnel est prévu pour TRANSPORTER depuis les pattes internes sans possibilité de routage c'est pourquoi on fait du GRE over IPSEC par exemple
les modes TRANSPORT et TUNNEL n'ont rien à voir avec la NAT
http://www.frameip.com/ipsec/ est une très bonne introduction à la réalité d'IPSEC
bonne journée
"Eric Masson" <emss@free.fr> a écrit dans le message de groupe de discussion
: grlnl7-h6i.ln1@srvbsdfenssv.interne.associated-bears.org...
Telco67 <telco67@widevoip.com> writes:
Non, les RFC IPsec prévoient deux modes (tunnel ou transport) et il est
tout à fait légitime de déployer IPsec en mode transport indépendamment
de la localisation des hôtes.
Le mode transport c'est pour du point à point comme comme utilisé maintenant
en IPV6 pour crypter les sessions OSPF par exemple
Le mode tunnel est prévu pour TRANSPORTER depuis les pattes internes sans
possibilité de routage c'est pourquoi on fait du GRE over IPSEC par exemple
les modes TRANSPORT et TUNNEL n'ont rien à voir avec la NAT
http://www.frameip.com/ipsec/ est une très bonne introduction à la réalité
d'IPSEC
"Eric Masson" a écrit dans le message de groupe de discussion :
Telco67 writes:
Non, les RFC IPsec prévoient deux modes (tunnel ou transport) et il est tout à fait légitime de déployer IPsec en mode transport indépendamment de la localisation des hôtes.
Le mode transport c'est pour du point à point comme comme utilisé maintenant en IPV6 pour crypter les sessions OSPF par exemple
Le mode tunnel est prévu pour TRANSPORTER depuis les pattes internes sans possibilité de routage c'est pourquoi on fait du GRE over IPSEC par exemple
les modes TRANSPORT et TUNNEL n'ont rien à voir avec la NAT
http://www.frameip.com/ipsec/ est une très bonne introduction à la réalité d'IPSEC
bonne journée
Eric Masson
"Telco67" writes:
'Lut,
Le mode transport c'est pour du point à point
Vu que c'est sa définition, cela s'appelle un truisme...
Mais rien n'empêche d'utiliser une connexion en mode transport entre un hôte sur un lan accédant à l'Internet par un dispositif nat et un hote accessible sur l'Internet.
Et dans ce cas, on en revient toujours au même, la nat met le bronx et avant la spécification et la généralisation de NAT-T, il n'y avait pas de solution.
Donc encore une fois la nat est un hack dont les effets de bord sont loin d'être anodins.
Au passage, on peut faire des trucs amusants avec le mode transport, comme interconnecter deux lans, voir la rfc3884 par exemple.
les modes TRANSPORT et TUNNEL n'ont rien à voir avec la NAT
La seule chose qui a été dite est que la présence d'un équipement nat entre deux hôtes/routeurs à connecter via ipsec nécessite l'utilisation de NAT-T qui ne fait pas partie de la spécification initiale d'ipsec.
-- c'est qui tous ces gens bizarres ? c'est un cross post involontaire ou une invasion extraterrestre ? Y a pas qqun qui est censé faire cesse ce genre de c*nneries, genre un moderator ou un truc dans le genre .... -+- PM in: <http://www.le-gnu.net> - Bien configurer son moderator -+-
"Telco67" <telco67@widevoip.com> writes:
'Lut,
Le mode transport c'est pour du point à point
Vu que c'est sa définition, cela s'appelle un truisme...
Mais rien n'empêche d'utiliser une connexion en mode transport entre un
hôte sur un lan accédant à l'Internet par un dispositif nat et un hote
accessible sur l'Internet.
Et dans ce cas, on en revient toujours au même, la nat met le bronx et
avant la spécification et la généralisation de NAT-T, il n'y avait pas
de solution.
Donc encore une fois la nat est un hack dont les effets de bord sont
loin d'être anodins.
Au passage, on peut faire des trucs amusants avec le mode transport,
comme interconnecter deux lans, voir la rfc3884 par exemple.
les modes TRANSPORT et TUNNEL n'ont rien à voir avec la NAT
La seule chose qui a été dite est que la présence d'un équipement nat
entre deux hôtes/routeurs à connecter via ipsec nécessite l'utilisation
de NAT-T qui ne fait pas partie de la spécification initiale d'ipsec.
--
c'est qui tous ces gens bizarres ? c'est un cross post involontaire ou
une invasion extraterrestre ? Y a pas qqun qui est censé faire cesse ce
genre de c*nneries, genre un moderator ou un truc dans le genre ....
-+- PM in: <http://www.le-gnu.net> - Bien configurer son moderator -+-
Vu que c'est sa définition, cela s'appelle un truisme...
Mais rien n'empêche d'utiliser une connexion en mode transport entre un hôte sur un lan accédant à l'Internet par un dispositif nat et un hote accessible sur l'Internet.
Et dans ce cas, on en revient toujours au même, la nat met le bronx et avant la spécification et la généralisation de NAT-T, il n'y avait pas de solution.
Donc encore une fois la nat est un hack dont les effets de bord sont loin d'être anodins.
Au passage, on peut faire des trucs amusants avec le mode transport, comme interconnecter deux lans, voir la rfc3884 par exemple.
les modes TRANSPORT et TUNNEL n'ont rien à voir avec la NAT
La seule chose qui a été dite est que la présence d'un équipement nat entre deux hôtes/routeurs à connecter via ipsec nécessite l'utilisation de NAT-T qui ne fait pas partie de la spécification initiale d'ipsec.
-- c'est qui tous ces gens bizarres ? c'est un cross post involontaire ou une invasion extraterrestre ? Y a pas qqun qui est censé faire cesse ce genre de c*nneries, genre un moderator ou un truc dans le genre .... -+- PM in: <http://www.le-gnu.net> - Bien configurer son moderator -+-
Telco67
"Eric Masson" a écrit dans le message de groupe de discussion :
"Telco67" writes:
La seule chose qui a été dite est que la présence d'un équipement nat entre deux hôtes/routeurs à connecter via ipsec nécessite l'utilisation de NAT-T qui ne fait pas partie de la spécification initiale d'ipsec.
hello c'est bien ce que je dis depuis le départ !!!
"Eric Masson" <emss@free.fr> a écrit dans le message de groupe de discussion
: dfdjo7-kat.ln1@srvbsdfenssv.interne.associated-bears.org...
"Telco67" <telco67@widevoip.com> writes:
La seule chose qui a été dite est que la présence d'un équipement nat
entre deux hôtes/routeurs à connecter via ipsec nécessite l'utilisation
de NAT-T qui ne fait pas partie de la spécification initiale d'ipsec.
hello
c'est bien ce que je dis depuis le départ !!!
"Eric Masson" a écrit dans le message de groupe de discussion :
"Telco67" writes:
La seule chose qui a été dite est que la présence d'un équipement nat entre deux hôtes/routeurs à connecter via ipsec nécessite l'utilisation de NAT-T qui ne fait pas partie de la spécification initiale d'ipsec.
hello c'est bien ce que je dis depuis le départ !!!
Eric Masson
"Telco67" writes:
c'est bien ce que je dis depuis le départ !!!
Et ce qui a été dit dans ce thread depuis le départ est qu'aucun protocole n'a été explicitement défini avec la nat en tête vu que ce n'est qu'un hack qui a permis de contourner une situation qui n'avait pas été prévue initialement...
-- tu ne veux plus de frjv ben pas compliquer il suffisais de cliquer avec le bouton droit de la souri (outlook) et de choisir annuler l'abonnement ! la destruction étais active mais pas pour tous le monde -+- L in GNU - Détruire, oui, mais tout en gardant -+-
"Telco67" <telco67@widevoip.com> writes:
c'est bien ce que je dis depuis le départ !!!
Et ce qui a été dit dans ce thread depuis le départ est qu'aucun
protocole n'a été explicitement défini avec la nat en tête vu que ce
n'est qu'un hack qui a permis de contourner une situation qui n'avait
pas été prévue initialement...
--
tu ne veux plus de frjv ben pas compliquer il suffisais de cliquer
avec le bouton droit de la souri (outlook) et de choisir annuler
l'abonnement ! la destruction étais active mais pas pour tous le monde
-+- L in GNU - Détruire, oui, mais tout en gardant -+-
Et ce qui a été dit dans ce thread depuis le départ est qu'aucun protocole n'a été explicitement défini avec la nat en tête vu que ce n'est qu'un hack qui a permis de contourner une situation qui n'avait pas été prévue initialement...
-- tu ne veux plus de frjv ben pas compliquer il suffisais de cliquer avec le bouton droit de la souri (outlook) et de choisir annuler l'abonnement ! la destruction étais active mais pas pour tous le monde -+- L in GNU - Détruire, oui, mais tout en gardant -+-
