Mon blog

Le multihoming, ou capacité pour un site Internet d'être relié à plusieurs fournisseurs d'accès Internet (FAI), est à la fois une très forte demande de la part des utilisateurs et un problème très complexe, qui n'a pas encore de solution satisfaisante. Le protocole IPv6 apporte quelques outils supplémentaires mais ne résout pas magiquement le problème.

Si tous les FAI étaient parfaitement fiables, et merveilleusement connectés, il n'y aura guère besoin de multihoming. Mais, en pratique, tout site qui veut une bonne fiabilité et une bonne connexion avec tout le monde a souvent intérêt à avoir plusieurs fournisseurs. La technique "normale" pour cela est d'avoir des adresses IP indépendantes (PI pour Provider Independant) et de faire du BGP avec tous ses fournisseurs. C'est techniquement assez complexe et c'est surtout très coûteux, sans compter la difficulté d'obtenir des adresses PI auprès des RIR (IPv6 ne change rien à ce sujet).

En attendant, le client de base reste donc très dépendant de son FAI.

Le groupe de travail Multi6 de l'IETF travaille sur la question et ce RFC explique son analyse des différentes architectures envisageables (le RFC 3582 détaillait le cahier des charges du multihoming IPv6). On est encore loin d'une solution.

Le RFC identifie cinq architectures possibles. Pour les comprendre, il faut d'abord lire la section 2 du RFC, qui rappelle que l'adresse IP est actuellement utilisée pour deux choses bien différentes, comme identificateur d'une machine et comme index dans les tables de routage (certaines solutions de multihoming vont séparer les deux fonctions) :

• Adresses PI et routage BGP, comme vu plus haut. Le problème est de passage à l'échelle : que deviendront les routeurs BGP si un million de sites publient leur route ? Le problème n'est pas celui du nombre d'adresses IP (qu'IPv6 résoud) mais celui du nombre de routes.
• Utilisation des techniques de mobilité : être connecté à un deuxième FAI n'est pas différent d'être en voyage et connecté par un FAI distinct de son FAI habituel.
• Les trois dernières architectures prévoient toutes une séparation des deux fonctions de l'adresse IP. Les sessions (par exemple TCP) seraient maintenus entre deux machines identifiées, non pas par une adresse IP, mais par un identifiant de plus haut niveau.

Le RFC décrit ensuite en détail les différentes façons de réaliser cette séparation et ces conséquences (il s'agit de remettre en cause un principe central des applications Internet).