Résumé

  • RFC 2260 organise le multihoming autour d’un état ordinaire agrégé et de plusieurs façons de payer le secours : annoncer temporairement une route plus spécifique, établir une session EBGP non directe avec encapsulation, accepter un chemin sous-optimal ou diffuser des routes supplémentaires dans un périmètre contrôlé.
  • Le choix des préfixes attribués par les fournisseurs protège l’agrégation, mais inscrit la topologie dans les adresses et impose un renumérotage lorsqu’un fournisseur change. L’espace indépendant des fournisseurs déplace au contraire le coût vers la table globale.
  • Chaque annonce BGP décrite par le RFC reste une intention de contrôle, pas une preuve d’acceptation par un opérateur, de propagation universelle, de transfert effectif ni de livraison applicative.

Le second circuit n’est que le commencement

Au moment de signer avec un deuxième fournisseur d’accès, une entreprise peut avoir l’impression que le problème est résolu par la géographie : deux fibres, deux points de raccordement, deux chemins. RFC 2260, publié à titre informatif en janvier 1998 par Tony Bates et Yakov Rekhter, déplace immédiatement le regard. La résilience ne tient pas seulement à l’existence d’une voie de rechange. Elle dépend de la manière dont le reste d’Internet apprend qu’il doit l’emprunter, de la durée pendant laquelle cette information subsiste et du nombre de routeurs qui doivent la mémoriser.

Le document part d’une contrainte d’échelle. Conserver une route propre à chaque entreprise multifournisseur dans tous les routeurs sans route par défaut n’est pas jugé soutenable. La solution recherchée doit donc préserver l’agrégation et limiter la coordination, notamment avec les fournisseurs qui ne sont pas directement raccordés à l’entreprise. Le RFC cite la fiabilité, la répartition de charge et, potentiellement, un meilleur routage géographique parmi les motivations du multihoming. Il ne mesure cependant aucun de ces bénéfices.

Sa contribution est une série de stratégies et de propriétés attendues, non le compte rendu d’une expérience de production.

Cette distinction commande toute lecture sérieuse du texte. Dire qu’un routeur annonce un préfixe ne signifie pas que l’amont l’accepte. Une acceptation ne garantit pas une propagation complète. Une route reçue n’atteste ni le transfert des paquets, ni la survie d’une session de transport, ni la disponibilité d’une application. Dans RFC 2260, le plan de contrôle dessine des possibilités ; il ne délivre pas de reçu.

L’état ordinaire : plusieurs préfixes, toujours agrégés

Le schéma de base attribue à l’entreprise raccordée à N fournisseurs N préfixes, chacun provenant du bloc d’un fournisseur selon la logique de prêt d’adresses exposée dans RFC 2008. À l’intérieur du réseau, l’adressage peut suivre la proximité topologique d’un nœud avec une interconnexion donnée. Un équipement peut porter une adresse issue d’un seul de ces préfixes ou plusieurs adresses issues de plusieurs préfixes. L’adresse influence ainsi le point d’entrée qui paraît naturel au trafic entrant.

Dans l’état ordinaire, chaque routeur de bordure n’annonce à son fournisseur directement connecté que le préfixe reçu de celui-ci. Le fournisseur peut conserver cette route dans son agrégat : aucune route spécifique à l’entreprise n’a besoin d’entrer dans la zone sans route par défaut. Le gain d’échelle vient précisément de ce silence. Tant que les deux côtés fonctionnent, le second raccordement ne se traduit pas nécessairement par une entrée supplémentaire dans chaque table globale.

Mais l’agrégation n’est pas gratuite. Une partie de l’adressage de l’entreprise appartient topologiquement à chaque fournisseur. Si l’entreprise quitte l’un d’eux, la partie utilisant son bloc doit être renumérotée. RFC 2260 présente cette conséquence comme celle du prêt d’adresses, non comme une anomalie propre au multihoming. Il mentionne la traduction d’adresses parmi les pistes possibles face aux questions d’affectation et de renumérotage, tout en laissant explicitement le NAT multifournisseur hors de son périmètre.

Le premier arbitrage est donc déjà visible. L’agrégation réduit l’état global, mais rend les adresses dépendantes du choix des amonts et fait du changement de fournisseur un projet interne. L’espace indépendant des fournisseurs inverse le placement du coût : l’entreprise possède un préfixe qui ne dépend pas de ses amonts, mais sa route spécifique ne peut pas être absorbée dans l’agrégat d’un fournisseur. RFC 2260 décrit alors une charge de la zone sans route par défaut en O(N), N étant le nombre d’entreprises multifournisseurs.

La panne rend visible ce qui était agrégé

La première stratégie de secours est l’injection automatique de route. Supposons deux préfixes, Pref-A et Pref-B, alloués respectivement par ISP-A et ISP-B. Tant que le routeur de bordure côté A constate que les ensembles de routes joignables via A et B ont une intersection non vide, il n’annonce que Pref-A à ISP-A. Si cette intersection devient vide, il en déduit que la connectivité par B est perdue et annonce aussi Pref-B à A. Une route supplémentaire peut alors apparaître dans la zone sans route par défaut. Lorsque l’intersection redevient non vide, l’annonce de secours est retirée.

Le modèle cherche ainsi à faire payer l’état global uniquement pendant la défaillance. Il suppose que toutes les entreprises multifournisseurs ne perdront pas simultanément un accès et en conclut que le nombre moyen de routes supplémentaires devrait rester une fraction du nombre total d’entreprises concernées. C’est une attente fondée sur une hypothèse, pas une mesure d’une table BGP réelle.

Le déclencheur exige lui-même de la connaissance. Le routeur doit déterminer l’état de l’autre chemin et connaître le préfixe attribué de l’autre côté. Une relation IBGP et la comparaison des routes accessibles constituent un mécanisme proposé. Comme calculer l’intersection de grands ensembles peut coûter cher, le RFC suggère aussi de surveiller un ou plusieurs préfixes choisis dans le cœur du fournisseur distant. Leur disparition via IBGP sert alors de signal pour injecter son préfixe.

Cette simplification transforme le choix du témoin en choix opérationnel. Un préfixe observé peut disparaître sans que toute la connectivité distante soit perdue, ou rester visible alors que le service utile est dégradé ailleurs. Le document définit une condition de commande ; il ne prouve pas qu’elle représente chaque panne pertinente. Il avertit en outre que des filtres de longueur de préfixe peuvent empêcher la route injectée d’assurer une connectivité à l’échelle d’Internet. Même correctement déclenchée, une annonce plus spécifique peut s’arrêter bien avant tous les réseaux dont dépend l’entreprise.

Garder la panne locale : EBGP non direct et encapsulation

RFC 2260 décrit ensuite une autre façon de placer le coût. Un routeur de bordure d’entreprise maintient une session EBGP non seulement avec le routeur du fournisseur directement connecté, mais aussi avec un routeur du fournisseur raccordé à l’autre bordure. Chaque fournisseur transmet le même ensemble de routes sur les relations directe et non directe. L’entreprise, elle, n’annonce à chaque fournisseur que le préfixe que celui-ci lui a attribué. De part et d’autre, la route apprise directement est préférée à celle apprise indirectement.

Lorsque le lien direct entre ISP-B et l’entreprise tombe, le trafic destiné à Pref-B continue d’atteindre ISP-B. Le fournisseur peut alors encapsuler les paquets vers la bordure survivante de l’entreprise en traversant l’autre côté ; le routeur de bordure les décapsule et les transfère sur le réseau interne. Le texte cite GRE, défini dans RFC 1773, pour cette encapsulation.

Dans l’architecture décrite, aucune route supplémentaire propre à l’entreprise ne doit alors être injectée dans la zone sans route par défaut. Le secours ne dépend pas non plus de l’acceptation lointaine d’une route plus spécifique susceptible d’être filtrée. En contrepartie, l’état et l’effort se concentrent dans une relation inter-opérateurs particulière : session EBGP multihop, préférence de chemins, tunnel, authentification, surveillance et exploitation coordonnée.

Il serait abusif de lire cette propriété architecturale comme la preuve que deux fournisseurs ont accepté commercialement et techniquement la relation, authentifié la session, installé le tunnel ou transféré correctement le trafic. Le chapitre de sécurité demande une authentification adaptée pour les sessions EBGP multihop ; il laisse les questions de sécurité de l’IBGP et de l’EBGP à un saut hors périmètre. Là encore, le texte établit ce que le montage doit faire s’il est correctement accepté et exploité, non qu’il l’a été quelque part.

L’optimalité s’achète avec de la visibilité

L’EBGP non direct évite l’état global supplémentaire, mais une panne peut produire un chemin moins direct. RFC 2260 propose donc de le combiner avec une version modifiée de l’injection automatique : des routes supplémentaires améliorent le chemin, mais leur propagation est volontairement limitée. Une communauté BGP, telle que celles définies par RFC 1997, peut servir à borner leur distribution.

Le même problème existe même sans panne. Si l’entreprise n’annonce à chaque fournisseur que le préfixe attribué par celui-ci, un client d’ISP-A qui cherche un nœud numéroté dans Pref-B peut suivre un itinéraire sous-optimal. L’entreprise peut annoncer davantage de préfixes pour offrir un meilleur choix d’entrée. Toutefois, si leur diffusion est mal contenue, cette optimisation ajoute un état significatif dans la partie d’Internet sans route par défaut.

Le cœur de RFC 2260 tient dans cette courbe de coût. Une visibilité plus large peut acheter un meilleur choix d’entrée ou une récupération plus directe. Préserver l’agrégation peut exiger des adresses liées aux fournisseurs, un tunnel, une coordination locale ou l’acceptation de chemins plus longs. Une solution à préfixe unique fourni par un opérateur et sélectivement transporté par les autres demande, pour sa part, une agrégation par procuration, davantage de coordination entre opérateurs et une configuration plus complexe. Aucun agencement ne supprime simultanément l’état, la dépendance, la coordination et la sous-optimalité.

Les perspectives officielles ultérieures renforcent cette lecture sans démontrer un déploiement de RFC 2260. RFC 2519 explique pourquoi l’agrégation réduit la taille des tables, le traitement et l’étendue des oscillations, tandis que l’information plus spécifique peut rester locale ou porter l’attribut no-export. RFC 4116 classe l’approche de RFC 2260 parmi les solutions fondées sur des adresses agrégables par fournisseur : sous sa forme de base, elle n’ajoute pas de charge à la table globale, mais ne satisfait pas tous les objectifs couramment associés au multihoming, notamment la survie des communications au niveau transport. RFC 8678 observe encore, dans le contexte IPv6 qu’il traite en 2019, que l’adressage fourni par les opérateurs évite l’ajout de routes indépendantes dans la table globale tout en exigeant une coordination du choix de l’adresse source et de la sortie. Ce recul ne doit pas être projeté comme un mécanisme déjà présent en 1998.

RFC 2260 s’applique, selon ses auteurs, à IPv4 comme à IPv6. Cette affirmation est architecturale. Elle ne prouve ni une mise en œuvre équivalente, ni une adoption comparable, ni un résultat identique. Le document reste surtout précieux pour la discipline intellectuelle qu’il impose : demander, pour chaque promesse de résilience, où se trouvent désormais l’état, le déclencheur, la coordination et la preuve manquante.