Re: [IPv6-Tech] Problématique de dual stack
Bonjour, Le 6 janv. 2015 à 10:57, Julien VAUBOURG a écrit : Le 06/01/2015 10:31, CHABIRAND Gael a écrit : [...] - L'abonné ne dispose *PAS* d'une connectivité IPv6 effective, bien que son poste soit en dual stack. Par exemple les abonnés grand public d'Orange, avec des OS modernes sur les ordinateurs, mais pas de routage IPv6 via leur FAI. Dans ce cas de figure, est-ce qu'ouvrir le service IPv6 (ie renseigner un enregistrement pour le service dès que celui-ci dispose d'une connectivité IPv6 fonctionnelle) ne risque pas de dégrader énormément la qualité de service pour les postes dual-stack sans connectivité IPv6 réelle Si le poste dual-stack de l'abonné n'a pas accès à un routage IPv6, il n'aura qu'une adresse de lien local sur son interface réseau et pas de route IPv6 par défaut dans sa table de routage. Par conséquent, lorsqu'il voudra accéder au service web, le nom de domaine ne sera résolu qu'en IPv4 (A), puisqu'il ne dispose de toutes façons d'aucun moyen pour le contacter en IPv6. Il n'y a donc simplement pas d'happy eyeball dans ce cas. Le seul problème avec le happy eyeball, c'est quand il y a un accès IPv6, que le service dispose d'un , mais que le serveur correspondant à ce ne répond pas correctement. Ça arrive assez souvent, parce que les fournisseurs de services ont tendance à ne pas vérifier régulièrement le fonctionnement de leur IPv6, alors que les utilisateurs basculent automatiquement en IPv4 en cas de problème (avec une petite lenteur) et ne peuvent donc pas le signaler. A noter que Google fait énormément de statistiques sur le sujet. On peut voir des résultats intéressants ici : http://www.google.fr/ipv6/statistics.html#tab=per-country-ipv6-adoption Pour chaque pays est indiqué le pourcentage d'adoption (intéressant mais non pertinent pour la question), la latence et l'impact. La France est notée avec une latence de 0% (pas de différence entre IPv4 et IPv6) et un impact de 0.07% (je suppose 7 connexions sur 1 sont non fonctionnelles). Le concept de Happy Eyeballs s'applique également à ces connexions là, c'est à dire que le client reçoit un préfixe IPv6 de son FAI mais pour une raison ou une autre ses paquets n'atteignent pas le serveur. La raison d'une perte de paquet entre le client et le service peut être au niveau du service (enregistrement mais service non fonctionnel en IPv6), du transit (chemin congestionné en IPv6 uniquement entre le FAI et le fournisseur de contenu) ou du FAI (infrastructure IPv6 non fonctionnelle). Happy Eyeballs traite indifféremment ces trois cas là. Cordialement Emmanuel Thierry ___ G6 -- Association Francophone pour la promotion d'IPv6 (http://www.g6.asso.fr) Liste IPv6tech IPv6tech@g6.asso.fr Info : http://mailman.g6.asso.fr/mailman/listinfo/ipv6tech
Re: [IPv6-Tech] Réponse d'A.Lemaire à la question de C.Erhel sur IPv6
Le 8 déc. 2014 à 12:24, Alexandru Petrescu a écrit : Le 08/12/2014 12:09, Pierre Beyssac a écrit : Bonjour, On Mon, Dec 08, 2014 at 12:04:23PM +0100, Alexandru Petrescu wrote: À moi cela tient à questionner d'abord les qualificatifs « plus grand que l'autre », et tout type de taux exprimé en pourcentage. Dire « être à 5% » (débit ? http ou ping ?) fait trop penser aux anciens compteurs sur les premières pages web... Typiquement il y a 3 types de stats : - nombre d'adresses IP (v4/v6) individuelles utilisées pour l'accès aux services type Google (stats données par les services concernés) Cela prend en compte que chaque ordi à au moins 2 adresses différentes par interface et que les derniers ordis changent une à chaque redémarrage ? (« privacy »). Le serveur peut voir bcp d'adresses IP source et ça se trouve c'est le même unique ordi :-) Pas vraiment. Si je ne me trompe, le fonctionnement des stats google est que, à chaque requête faite sur google.com, ils chargent un script qui va requêter en simultanné un service témoin IPv4/IPv6 et un service IPv6 only. Ils comparent ensuite la différence entre les deux pour savoir qui est IPv6 enabled et qui est IPv6 preferred. Dans cette situation, adresses privacy ou non, il n'y a qu'une requête qui est faite, et l'hôte en question n'est comptabilisé qu'une seule fois par accès au service. Cordialement Emmanuel Thierry ___ G6 -- Association Francophone pour la promotion d'IPv6 (http://www.g6.asso.fr) Liste IPv6tech IPv6tech@g6.asso.fr Info : http://mailman.g6.asso.fr/mailman/listinfo/ipv6tech
Re: [IPv6-Tech] Réponse d'A.Lemaire à la question de C.Erhel sur IPv6
Le 8 déc. 2014 à 13:43, Pierre Beyssac a écrit : On Mon, Dec 08, 2014 at 01:03:49PM +0100, Alexandru Petrescu wrote: requête qui est faite, et l'hôte en question n'est comptabilisé qu'une seule fois par accès au service. Mais alors un ordinateur faisant 100 requetes google compterait plus en pourcentage qu'un ordinateur faisant seulement 50 requetes google ? Je vous conseille d'aller voir la méthodologie publiée par Google en 2008, a priori la méthode ne semble pas stupide même si les éléments découverts en 2008 (6to4, etc) sont largement caducs. https://www.ietf.org/proceedings/73/slides/v6ops-4.pdf Et les statistiques à jour (France effectivement dans le peloton de queue, Belgique à 28 %) : http://www.google.com/intl/en/ipv6/statistics.html Disons la France dans le milieu plutôt (5,5%) ! ;) Et plus particulièrement dans la moyenne mondiale. Cordialement Emmanuel Thierry ___ G6 -- Association Francophone pour la promotion d'IPv6 (http://www.g6.asso.fr) Liste IPv6tech IPv6tech@g6.asso.fr Info : http://mailman.g6.asso.fr/mailman/listinfo/ipv6tech
[IPv6-Tech] Recherche d'un ingénieur systèmes et réseaux
Bonjour, YoGoKo, startup en cours de formation, recherche un ingénieur système et réseau confirmé pour participer au développement de ses solutions, ainsi qu'à leur déploiement. La particularité de ce poste est qu'il est centré sur IPv6. Veuillez trouver ci-après la fiche de poste. Cordialement Emmanuel Thierry Descriptif du poste - Vous évoluerez dans une jeune société innovante où vous effectuerez des missions variées (à définir selon profil) : * Définition de cahier des charges et spécification fonctionnelles d'équipements réseau * Mise en oeuvre, principalement à partir de composants logiciels open-source * Déploiement des équipements en test ou en production * Veille technologique sur les protocoles/logiciels réseau * Animation d'équipe et de projet De par votre expérience, vous serez force de proposition dans les choix de RD et référent technique sur les questions relatives à vos compétences propres. Compte-tenu de la taille et de l'expansion rapide de l'entreprise, de fortes perspectives d'évolution de carrière sont possibles. Le poste est à pourvoir à Rennes courant juin. Le salaire est à définir selon profil et expérience. Nous vous invitons à nous communiquer vos candidatures ou demandes d'informations à cont...@yogoko.fr Profil recherché - De formation ingénieur ou Bac +5 (ou inférieur si expérience significative) vous avez au minimum de 3 ans d'expérience en administration ou conception système/réseau, vous maîtrisez les OS et logiciels Open-source, en particulier appliqués au réseau. Seront appréciés en particulier la maîtrise : * de l'administration d'équipements réseau (CPE, routeurs, firewall, switches, etc) * des distributions Linux type Debian et/ou CentOS * de langages de scripts (bash, perl, python, etc) * d'IPv6 et protocoles associés (MIPv6, transition IPv4/IPv6, etc) * d'IPsec et protocoles associés (IKEv2, etc) * des protocoles de routage * de logiciels open-source mettant en oeuvre ces protocoles Une bonne maîtrise de l'anglais est également attendue. La société -- YoGoKo est une société en cours de formation, spécialisée dans la conception et le développement d'équipements réseaux embarqués basés sur IPv6, notamment à destination des transports routiers. Elle industrialise des technologies issues de laboratoires de recherche (Inria, Institut Mines Telecom). L'entreprise bénéficie du soutien d'organismes publics et de grands comptes, ainsi que des laboratoires ayant participé à son essaimage. ___ G6 -- Association Francophone pour la promotion d'IPv6 (http://www.g6.asso.fr) Liste IPv6tech IPv6tech@g6.asso.fr Info : http://mail.g6.asso.fr/mailman/listinfo/ipv6tech
Re: [IPv6-Tech] RFC 7157: IPv6 Multihoming without Network Address Translation
Le 2 mai 2014 à 10:26, Stephane Bortzmeyer a écrit : On Fri, Apr 25, 2014 at 12:13:49PM +0200, Emmanuel Thierry m...@sekil.fr wrote a message of 19 lines which said: C'est marrant, personne ne pense jamais à citer MIPv6 Ce n'est pas uniquement pour les mobiles ? Le RFC 7157 concerne des réseaux locaux fixes. Define uniquement. Le protocole est agnostique au fait que le noeud soit effectivement mobile ou non. Peut-être que la signalisation n'est pas optimale pour du réseau fixe mais il n'y a pas de contre-indication (qui peut le plus peut le moins). Cordialement Emmanuel Thierry ___ G6 -- Association Francophone pour la promotion d'IPv6 (http://www.g6.asso.fr) Liste IPv6tech IPv6tech@g6.asso.fr Info : http://mail.g6.asso.fr/mailman/listinfo/ipv6tech
Re: [IPv6-Tech] Firefox - compatibilité IPv6 ?
Le 14 janv. 2014 à 10:54, Emmanuel Thierry a écrit : Le 14 janv. 2014 à 10:36, Bruno STEVANT a écrit : Le 14 janv. 2014 à 10:31, Julien VAUBOURG jul...@vaubourg.com a écrit : Le 2014-01-14 09:53, Jérôme BERTHIER a écrit : [...] En revanche, la navigation vers le site g6.asso.fr via Firefox se fait en IPv4 : trafic capturé sur une sonde et confirmé par la bannière Vous utilisez encore IPv4 As-tu essayé de passer cette option à false : network.http.fast-fallback-to-IPv4 Si le lien IPv6 est lent, Firefox passe automatiquement à IPv4, ce que ne font peut-être pas les autres navigateurs que tu as testé (ou avec un seuil plus haut). ju. J'ai en effet vu des comportements similaires rapportés dans ce bug-report https://bugzilla.mozilla.org/show_bug.cgi?id=725587 D'après les commentaires, Firefox repasse en IPv4 s'il n'a pas reçu de réponse au premier SYN TCP sur IPv6 avant 250ms (seuil modifiable). Vois-tu ce message TCP SYN / IPv6 dans tes traces réseau ? -- Ce qui n'est pas l'idéal. Je ne me souviens pas bien d'Happy Eyeballs, il ne devrait pas continuer avec la première réponse qu'il reçoit une fois que les deux connexions sont ouvertes ? A titre d'exemple je suis à 25ms du serveur, et en http il met entre 180ms et 300ms à m'envoyer la réponse. Dans le cas d'une connexion venant de l'extérieur de Télécom Bretagne, on doit être systématiquement hors des 250ms de Firefox. Le coup des 250ms, c'est un peu du doigt mouillé... Emmanuel ___ G6 -- Association Francophone pour la promotion d'IPv6 (http://www.g6.asso.fr) Liste IPv6tech IPv6tech@g6.asso.fr Info : http://mail.g6.asso.fr/mailman/listinfo/ipv6tech
