Le draft Happy Eyeballs est finalement devenu la RFC 6555
Il s’agit ici de faciliter le déploiement IPv6 en mettant en oeuvre des mécanismes supplémentaires pour améliorer l’expérience utilisateur.
Supposons qu’un utilisateur cherche à aller sur un site. La requête DNS donnera éventuellement une adresse IPv4 et une adresse IPv6 (si le site en question en possède une). Dans la plupart des cas le browser utilisera l’adresse IPv6 et tentera donc d’établir une connexion TCP vers le serveur en utilisant un transport IPv6. Si pour une raison quelconque ce tranport IPv6 n’est pas assuré de bout en bout (ou mal assuré), la requête terminera en timeout et il faudra recommencer une tentative de connexion sur un transport IPv4. On peut imaginer aussi que l’établissement de la connexion soit extrêmement longue. Dans les deux cas de figure, l’expérience utilisateur se révèlera mauvaise.
En effet l’état du DNS n’est pas forcément cohérent avec la réalité du déploiement. Un serveur peut très bien avoir une adresse IPv6 et pour autant le chemin entre un client et ce serveur ne pas être full IPv6. On peut aussi avoir le cas de déploiement pas pensé et reposant sur toute une série de tunnels. On peut aussi avoir des black holes.
Une solution mise en place par certains content providers consistait à utiliser des whitelists DNS. Seuls les providers considérés comme sérieux dans leur déploiement IPv6 recevaient une réponse avec une adresse IPv6.
Happy Eyeballs fournit une nouvelle solution qui sera progressivement intégrée dans les Operating Systems et autres applications.
En une phrase (pas facile), l’idée de Happy Eyeballs est d’établir deux connexions simultanées, une sur IPv4 et l’autre sur IPv6 et ensuite de choisir celle qui sera la meilleure pour ensuite continuer avec. Résultat : l’utilisateur aura une très bonne expérience, puisqu’utilisant la connexion ayant la meilleure “performance”.
Pour avoir une vue plus complète sur le problème, on se reportera à l’excellente présentation de Geoff Huston:
https://ripe64.ripe.net/presentations/78-2012-04-16-ripe64.pdf
L’idée de départ est donc séduisante bien sur mais je me dis aussi qu’elle peut aussi conduire à retarder le déploiement d’IPv6 .. au même titre que les optimisations faites par Apple sur Lion pour choisir la connexion ayant le meilleur RTT et non plus IPv6 en priorité … L’expérience utilisateur est certes privilégiée mais au risque d’impacter un vrai déploiement IPv6.
Authors
1 commentaires