RFCs | Contact | Bibliographie
Limites actuelles

  • Approche au niveau routage

    • L'approche utilisée pour le support du multihoming en IPv4 est de préserver la sémantique de l'adresse IPv4 du point de vue identifiant et localisation. Pour que cela fonctionne dans un contexte " multihoming ", il est nécessaire que les providers fassent transiter une route distincte en plus du préfixe CIDR qui lui a été attribué. Cette approche peut être utilisée en IPv6 sans modifications d'architecture.

    La problématique est la suivante: le préfixe d'adresse du système autonome " multi-homed " a un préfixe plus long que celui de son provider. Le provider communiquera par défaut aux autres réseaux un préfixe englobant plusieurs sites locaux. Pour qu'un routage soit effectué dans un contexte " multihoming " le provider doit transmettre la route complète du système autonome car ce dernier doit pouvoir être accessible depuis un autre provider.

    Une solution proposée : tous les providers de transit acceptent un préfixe du système autonome " multi-homed " (ce dernier serait fourni par un intermédiare tiers), et renseignent ce préfixe globalement dans dans les tables de routage inter-domaine.

    Cette solution est confome aux buts à atteindre pour IPv6 avec une exception: scaleability. La conséquence de cette méthode est l'addition d'un nombre important d'entrées dans les tables de routage.

    Il reste aussi à déterminer si la couche transport sera apte à gérer ce type de situation convenablement.

  • Approche au niveau transport

    • Actuellement, TCP utilise la même identitification qu'IP (l'adresse IP). Si une même session de la couche transport devait supporter plusieurs chemins vers des Ips différentes, certains changements devraient être opérés au niveau de l'identification et de la localisation. Ce changement devrait permettre d'utiliser un identifiant unique au niveau de la couche transport qui serait maintenu en cas de changement de chemin.

  • Approche au niveau applicatif / nommage

    • Dans l'espace de routage inter-domaine, l'approche utilisée en IPv4 et IPv6 est d'aligner le déploiement des adresses avec la topologie du réseau (CIDR en IPv4, differents niveaux de préfixes en IPv6).
    Dans le scénario de plus classique, le site " multi-homed " possède 2 préfixes fournis par ses 2 providers. Si un hôte distant contacte un hôte sur le site local " multi-homed ", il fera une requête au DNS. Dans ce contexte, le DNS retournera 2 adresses : une avec le préfixe du provider A, une aves le préfixe du provider B. Il ne reste plus qu'à l'hôte distant de choisir une des 2 adresses. Le problème est le suivant : si l'hôte distant sait qu'il contacte un hôte " multi-homed ", et dans le cas ou un des 2 providers n'est plus capable d'assurer son rôle, comment l'hôte distant peut-il commuter pour utiliser le provider B ? Et inversement si c'est l'hôte " multi-homed " qui souhaite contacter l'hôte distant.