Résumé

  • La RFC 5220 décrit un réseau IPv6 « semi-fermé » où la règle par défaut de sélection de l’adresse source peut choisir un préfixe inaccessible depuis l’Internet public.
  • L’hôte choisit la source et le réseau choisit le premier saut : ce sont deux décisions distinctes. La RFC documente un décalage possible, pas un déploiement identifié, un taux de panne ou le comportement de tous les hôtes multiraccordés.

Deux préfixes valides, une réponse injoignable

Publiée en juillet 2008, la RFC 5220 est un texte informatif qui recense les difficultés de choix d’adresse IPv6 sur un lien portant plusieurs préfixes. Elle n’ajoute aucun format de paquet. Elle rassemble plutôt des situations dans lesquelles les règles par défaut de la RFC 3484 deviennent difficiles à exploiter, notamment sur des hôtes non administrés dont les utilisateurs ne peuvent pas maintenir eux-mêmes une table de politique.

Son cas le plus parlant s’appelle un « réseau semi-fermé ». Un petit site est relié à deux réseaux amont : l’un fournit l’accès ordinaire à Internet, l’autre est un réseau fermé accessible par VPN. L’hôte possède une adresse IPv6 valide dans chacun. Une personne du réseau fermé peut le joindre par son adresse interne ; un serveur public ne peut pas, lui, acheminer une réponse vers cette adresse par l’Internet ouvert.

Le problème apparaît quand l’hôte ouvre une connexion vers une destination publique. Dans l’exemple de la RFC 5220, la règle du plus long préfixe peut sélectionner l’adresse du réseau fermé comme source. Pourtant, la route par défaut du site peut envoyer le paquet sortant au fournisseur Internet. Celui-ci peut rejeter un préfixe qu’il n’a pas délégué ; même si le paquet sort, la réponse du serveur public vise le préfixe fermé et ne peut revenir par le chemin public. « Adresse valide » et « conversation fonctionnelle » ne désignent pas la même chose.

Le texte distingue deux ruptures. Le filtrage à l’entrée peut rejeter le paquet sortant, car sa source n’appartient pas au réseau de ce fournisseur. Le domaine de retour semi-fermé peut rendre la réponse injoignable même si le paquet a été accepté. Ce n’est ni simplement une question de DNS ni la preuve que l’adresse de l’hôte était mal formée.

Le préfixe ne révélait pas la politique de l’amont

La RFC 3484 proposait des règles par défaut pour comparer des adresses candidates. Elles n’indiquaient pas automatiquement à l’hôte quel fournisseur transporterait le paquet, ni si le préfixe source pouvait recevoir une réponse sur ce chemin. La RFC 5220 traite donc plusieurs échecs comme un problème de coordination entre le choix d’adresse de l’hôte et la politique de routage du réseau. Dans son exemple, configurer la table de politique de l’hôte pouvait éviter le mauvais choix, mais il fallait connaître la topologie et actualiser cette configuration.

Le document délimite soigneusement son propos. Il sépare les cas compatibles avec le cadre de sélection existant de ceux qui peuvent exiger davantage d’informations ou un autre mécanisme. Il n’affirme pas que tout site IPv6 multiraccordé était défaillant, et ne mesure pas la fréquence de ses exemples en production. Un schéma établit un mode de panne à examiner, pas un compte rendu d’incident.

Les textes ultérieurs rendent certaines frontières plus explicites. La RFC 6724 a fini par remplacer la RFC 3484. En 2016, la RFC 8028, de la filière Standards Track, a décrit le choix du premier routeur dans les réseaux à préfixes multiples et le lien entre le préfixe annoncé, l’adresse source choisie et le routeur emprunté. Elle éclaire l’évolution du raisonnement normatif ; elle ne prouve ni la prévalence des scénarios de 2008 ni la nécessité de vérifier le chemin de retour d’un réseau réel.

Un avertissement normatif n’est pas une mesure de trafic

L’apport historique de la RFC 5220 est la séparation qu’elle impose : choix d’adresse, choix du prochain saut, filtrage du fournisseur et joignabilité du retour sont liés, mais aucun ne constitue la preuve des autres. La RFC décrit des configurations plausibles et les analyse. Elle ne fournit ni recensement des systèmes, ni capture, ni panne nommée, ni mesure avant-après. Pour savoir combien d’hôtes ont réellement fait le mauvais choix, ou dans quelle mesure les travaux suivants ont amélioré les connexions, il faut des preuves d’implémentation et d’exploitation extérieures à la RFC.

Sources

  1. RFC 5220 — Problématique de sélection d’adresse par défaut dans les environnements à préfixes multiples
  2. RFC 3484 — Sélection d’adresses par défaut pour IPv6
  3. RFC 6724 — Sélection d’adresses par défaut pour IPv6
  4. RFC 8028 — Sélection du premier routeur par les hôtes dans un réseau à préfixes multiples
  5. RFC 2827 — Filtrage du trafic entrant
  6. RFC 4193 — Adresses unicast IPv6 locales uniques
  7. Notice de l’éditeur RFC pour la RFC 5220
  8. Notice de l’éditeur RFC pour la RFC 8028