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 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).