Ton FAI a raison : on ne doit pas publier dans son domaine une adresse IPv6 tant que le site n'est pas accessible à cette adresse IPv6.
En revanche, si le site en question a bien une connectivité et un routage défini avec son propre fournisseur de réseau, il peut publier une adresse IPv6 dans son domaine. À charge pour toi ensuite de configurer ton PC correctement pour ne PAS désactiver les services IPv6 nécessaires à la résolution et surtout au routage, dès le moment où une application sur ton PC cherchera à résoudre le nom de domaine aussi bien en IPv4 qu'en IPv6, avec une requête DNS de type A+AAAA, parce que **même** ton DNS accessible uniquement en IPv4 (local ou non) répondra à cette requête en te donnant soit une adresse de type A (IPv4) soit une adresse de type AAAA (IPv6). Si ton application en revanche fait une requête de résolution de domaine de type A uniquement, il n'obtiendra qu'une des adresses IPv4 inscrites dans le domaine. Si ton appli demande une requête de résolution du domaine de type AAAA uniquement, il n'obtiendra aussi qu’une des adresses IPv6 inscrites dans le domaine. Dans les deux cas, l'application ***doit*** accepter de prendre en charge l'ouverture d'une socket réseau avec le type d'adresse A ou AAAA qu'elle a elle-même demandée. Ce qui suppose aussi que les services IPv6 ne soient PAS désactivés sur ton PC. Hors on voit plein de mauvais conseils sur les sites prétendant optimiser les services tournant sur ton PC, qui ont pour effet de justement ne plus exécuter les services de connectivité IPv6 (par exemple ceux nécessaires si ton FAI ne te donne pas d'accès natif IPv6 (tel qu'un service de tunnel Teredo, 6to4, etc.). Parmi ces sites fort connus on trouve pourtant CNET (qui croit encore qu'IPv6 n'existe pas sur l'Internet !) et qui listent souvent ces services comme "non nécessaires" (particulièrement le service sous Windows appelé "IP Helper" qui est absolument nécessaire pour supporter les tunnels permettant d'encapsuler un trafic IPv6 via un serveur de tunnels accessible en IPv4) ! La situation sera plus simple quand ***enfin*** nos FAI français fourniront tous une connectivité IPv6 native (sans aucun tunnel comme le fait encore SFR avec son serveur de tunnels made in Cisco, complètement bogué, et totalement incompatible avec IPSEC, nécessaire par exemple pour HTTPS, sachant qu'IPSEC est un composant ***obligatoire*** de toute implémentation conforme d'IPv6). Orange ne fait pas mieux non plus (il utilise aussi le serveur de tunnel propriétaire made in Cisco, le même aussi bogué). A l'heure actuelle en France, parmi les FAI grand publics, il n'y a encore QUE Free qui propose la connectivité IPv6 native directement dans la session de connexion PPP, et directement aussi au sein de toutes les interfaces réseaux de sa box. Pour tous les autres FAIs français grand public, les accès IPv6 ne fonctionnent qu'avec des tunnels : Ne pas utiliser les tunnels fournis par SFR ou Orange (préconfigurés dans le firmware de leur box ADSL ou fibre), on peut créer d'autres tunnels conformes évitant totalement ces tunnels bogués. Personnelement ça fait un moment que je n'utilise pour l'instant QUE les tunnels d'un service gratuit situé aux Pays-Bas (avec aussi des points d'accès à Londres, Montréal, Hong Kong, et d'autres à venir et en préparation). Cela ne demande sur mes PC qu'une toute petite configuration de Teredo ou 6to4, ou bien d'exécuter un petit programme fourni gratuitement qui établit automatiquement ce tunnel, et lui attribue même non seukement un bloc d'adresses IPv6 complet privé de 48 bits, ainsi qu'un nom de domaine. Ce petit programme est même capable de traverser le NAT IPv4 de ta box, car il supporte aussi une encapsulation d'IPv6 via UDP en IPv4, qui ne nécessite aucune translation de ports (contrairement aux tunnels IPv4 basés sur TCP). Ce tunnel tiers est totalement conforme à la spécification IPv6 et supporte IPSEC nativement, de même que toutes les options de QoS natives dans IPv6 (le QoS n'est pas intégré nativement dans IPv4 et ne fonctionne correctement qu'avec des switches travaillant en couche de transport de niveau 3, mais pas les switches standards travaillant au niveau 2 sur la couche liaison, c'est-à-dire Ethernet ou WiFi par exemple). De plus ce tunnel aux Pays-Bas est ***beaucoup plus*** performant (et de très loin !) que le tunnel (bogué) fourni par SFR via le firmware de sa box : raison pour laquelle j'ai désactivé complètement la prise en charge d'IPv6 sur la box de SFR puisque cela génère des anomalies sérieuses et que ce tunnel ne fonctionne pas correctement avec les sites sécurisés (HTTPS par exemple et tous les services basés sur SSL). La raison de cette différence de performance vient du fait que les serveurs de tunnels de SFR et Orange sont sous-dimensionnés et ne peuvent pas gérer la bande passante de tout le monde (inutile de rêver : les vidéos en IPv6 fonctionnent très mal sur ces tunnels propriétaires de SFR et Orange). D'ailleurs Google fournit aussi gratuitement un serveur de tunnel IPv6 gratuit pour tous (mais il est encore en phase de démarrage, et pas assez performant). Il y a d'autres fournisseurs utilisables dès aujourd'hui, gratuits ou payants (les payants permettent d'augmenter les débits, car les serveurs de tunnels acceptent une bande passante supérieure avec moins de monde à se la partager)... La plupart sont basés sur le protocole d'encapsulation Teredo, plus souvent que 6to4. D'ailleurs Microsoft propose aussi un tel tunnel gratuit pour tous les utilisateurs de Windows : il est même préconfiguré par défaut (mais ne fonctionnera pas si vous avez désactivé le service appelé "IP Helper" pour qu'il ne démarre pas au démarrage de votre système puisque les tunnels fournis par Microsoft sont de type Teredo et nécessitent eux aussi ce service IP Helper pour prendre en charge ce protocole de tunnel). Microsoft ne vérifie pas qu'un utilisateur de son service de tunnels utilise Windows : il n'y a aucune authentification de licence pour s'y connecter, même un utilisateur de Linux ou MacOS pourrait utiliser le serveur de tunnels de Microsoft. En revanche ce serveur de tunnels de Microsoft est TRES LENT (même s'il est conforme à la spécification d'IPv6 et prend bien en charge IPSEC et le QoS natif), car il y a beaucoup trop de monde dessus et Microsoft l'a volontairement sous-dimensionné pour que ce service ne serve qu'à assurer une connectivité pour tout le monde, même au prix d'une faible bande passante utilisable (et d'un temps de latence pour le ping IPv6 assez mauvais): ce tunnel par défaut ne convient donc pas aux applis hautement interactives mais suffit pour accéder à des sites web classiques ne générant pas beaucoup de débit, ou pour un téléchargement de fichiers statiques depuis un serveur accessible uniquement en IPv6. Celui proposé par Google est bien plus performant, mais pas idéal non plus. Personnellement j'utilise le serveur de tunnels appelé "Gogonet" (cherchez sur Internet, c'est facile à trouver), qui à l'heure actuelle me semble être le meilleur service de tunnel IPv6 pour ceux qui n'ont pas encore de connectivité IPv6 réellement native (donc pour SFR et Orange, mais pas besoin pour Free et Alice). Le 4 avril 2012 05:35, Hendrik Oesterlin <hendrikmail2...@yahoo.de> a écrit : > Le 03/04/2012 à 14:46:32 +1100 "Philippe Verdy" verd...@wanadoo.fr a écrit > Objet: "[OSM-talk-fr] Re : Erreur IPv6 sur openstreetmap.org" : > >> Problème de configuration du nom de domaine DNS ? >> Essaye de vider ton cache local DNS en tapant : ipconfig /flushdns >> dans une fenêttre de commande (cette commande est pour Windows) > > Non, ce n'est pas un pb de mon cache local. Ca provenait du couple > DNS tiles.openstreetmap.org + proxy de mon FAI > > Mon FAI m'a ecrit: > > ,----- [ Nicolas ] > | J'ai rajouté une exception pour forcer le passage en Ipv4 pour le > | domaine .tile.openstreetmap.org, ce qui permet donc d'utiliser le > | proxy > | > | à cette fin. > | > | Toutefois, OpenStreetMap ne devrait pas publier d'adresse IPv6 dans le > | DNS pour ce sous-domaine tile.openstreetmap.org tant que le service ne > | peut pas être assuré entièrement en double pile. > | > | Et la raison pour laquelle le "fallback" attendu d'un client classique > | n'est pas possible avec le proxy, se référer à la doc de squid ci > | après, > | > | en version 3.1 : > | > | http://www.squid-cache.org/Doc/config/tcp_outgoing_address/ > `----- > > et voilà la réponse de Tom de chez osm: > > ,----- [ Tom Hughes ] > | I don't really understand what that page is trying to say, because I > | suspect there is a lot of context around the "bridge" function that > | would be found elsewhere. > | > | It certainly sounds like a combination of issues with squid's design > | and > | > | specific configuration choices though rather than a general problem. > | > | Squid is well known for being a bit backward with IPv6 anyway. > | > | It's largely irrelevant anyway, because Grant removed the DNS entry > | anyway, even though I still maintain that it should not cause any > | problems for a standards compliant client. > | > | Tom > `----- > > Perso, je n'ai pas d'opinion tranchée ni qualifiée, mais en attendant > ca re-marche très bien. > > Merci pour votre coup de pouce! > > > -- > Cordialement > Hendrik Oesterlin - Nouvelle-Calédonie > > > _______________________________________________ > Talk-fr mailing list > Talk-fr@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-fr _______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
